> ## Documentation Index
> Fetch the complete documentation index at: https://unity.farlocus.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 使用建议

## 以动态的视角理解 AI 能力

在一定程度上，可以将 AI 视为一位技术能力较强、但缺乏游戏审美与体验判断能力的技术策划或客户端开发同事。

目前的前沿模型在具体、明确的编程任务以及数学问题求解上，已经展现出超过大多数程序员的能力。然而，作为语言模型，它仍然缺乏对 Game Feel 的真实理解，也无法天然判断何种 UI 布局更合理、何种交互反馈更符合玩家预期。

在短期项目中，团队可以在不完全理解其实现细节的前提下，以较高速度完成原型开发与迭代，即通常所说的`Vibe Coding`。

但在严肃的长期项目中，开发者应当审阅 AI 作出的技术决策，并理解其具体实现方式。只有这样，问题出现时，团队才具备持续维护与修复的能力。若对其实现原理缺乏基本理解，后续排障与修复过程将高度依赖反复尝试；一旦 AI 无法继续修复，项目的可维护性与延续性都会受到直接影响。

对于大型项目，我们建议由程序开发者主要使用 Agent 进行框架层开发，由不具备技术背景的策划通过程序预先提供的 `Skill`（或某些具体限制）开发具体玩法功能。策划侧应避免直接提出框架层面的工程变更需求——例如“我想要玩家在雪上踩出脚印”这类听起来朴素的需求，可能会直接让 Agent 写出一个涉及底层架构设计的「虚拟纹理」系统。

同时，基础模型能力仍在快速演进。前沿模型的发布周期已经从过去的一年、半年，缩短至两个月左右。与之相应，Agent 的使用范式也会持续变化。一年多以前，受限于上下文长度与工具能力，模型尚难以独立完成今天常见的 Agent 任务。因此，本页提出的规范具有阶段性特征，未来数月内便可能需要调整。

现阶段，AI 在开发过程中出现错误属于正常现象。你可以在 Unity 中进行测试，并将结果反馈给它继续修正，很多问题经过数轮迭代后都可以得到解决。若某一问题长期无法修复，重新开启一个新对话，并让新的 AI 基于既有功能进行分析与排查，通常会更加有效。

后续我们还将通过两篇技术博客，更系统地阐述我们对游戏开发 Agent 的使用理解：

* Harness Engineering for Game Projects
* Building Dev Agent for Game Engines

## 具体且正确的指令优于模糊指令，模糊指令优于具体但错误的指令

应尽可能向 AI 提供充分且准确的上下文信息，使其明确理解需求目标。

例如：

* 当你希望实现某个功能时，应说明该功能的用途，以及预期的设计细节。
* 当你希望实现某种玩法时，应描述该玩法应呈现出的体验感受、可能的参考对象，以及关键设计细节。
* 当你希望修改项目中的既有功能时，应说明该功能当前的状态、修改原因，以及你设想中的可能调整方向。

对于不熟悉代码的策划、美术，或尚未对当前需求的技术实现形成清晰判断的成员，建议避免向 AI 描述过于具体且确定的技术路线。因为在技术前提判断存在偏差时，过度明确的实现路径往往会将 AI 引导到错误方向，并持续在该方向上投入实现细节。

## 复杂任务应先产出方案并完成 Review，再进入执行阶段

许多表面上看似简单的游戏逻辑，实现起来往往非常复杂。对于游戏策划与程序开发者而言，对此应该都有深有体会。

以横版跳跃游戏中的“跳跃”功能为例，其背后可能涉及很多复杂的技术决策，例如：角色动作逻辑是否需要采用状态机或状态树结构维护、是否需要加入“土狼时间”、起跳与落地过程中的速度变化参数如何设计以控制曲线等。

在传统开发流程中，客户端程序通常需要承担与策划反复沟通、将未明确写入策划案的隐含需求补足并落实为代码的职责。而默认状态下的 AI，更倾向于以最快速度完成表面需求。若仅用一句简短描述直接要求其实现功能，AI无法掌握项目的基本设计目标与长期演进方向，最终效果很可能与预期存在偏差。

因此，对于复杂需求，更推荐先要求 AI 不修改任何文件，而是先输出实现方案，与使用者通过对话充分确认需求、边界条件和关键设计，再进入实际编码阶段。

尽管 AI 无法真正理解 Game Feel，但它熟悉大量既有游戏的典型实现方式。对于已有成熟范式的内容，也可以主动向它询问“如何优化手感”。例如，一位缺乏横版跳跃游戏经验的开发者，未必会自然想到“土狼时间”这类设计；而 AI 往往能够给出具备参考价值的建议。

另一方面，过去策划希望推动某项功能落地，往往需要与程序进行充分沟通，因为开发成本较高。如今，功能实现与迭代速度已经显著提升，策划也可以用更低成本快速验证想法。因此，在很多场景下，策划无需像过去那样花费大量时间打磨完整方案、反复说服程序资源投入后再开始尝试，而是可以更快进入原型验证与玩法迭代阶段。Locus中AI从会话中总结设计文档的功能，也是基于这种想法产生的。

## 定期维护知识库

我们为 Locus 提供自动维护知识库的能力，是希望它能够在持续与你交流和参与项目的过程中，逐步形成对项目的更深入理解。

其中，`Design` 部分需要重点关注。它代表 AI 对你需求的总结与归纳，并会在后续任务中将这些内容视为需求依据。因此，确保其中信息准确，属于使用者的重要责任。

`Memory` 则是 AI 基于项目工程与上下文自行总结出的经验性信息。你也可以定期检查其内容是否准确，并根据实际情况手动修改或删除相关条目。

后续我们会提供一个专门的 Skill，用于帮助 AI 更系统地维护项目知识库。

## 独立的任务应该在独立的上下文（新会话）中完成

界面右下角会显示一个进度条，用于表示当前会话上下文的使用情况。

当前语言模型虽然可以处理较长文本，但上下文容量仍然有限。当下文混入很多不相关的工具调用结果与判断时，模型能力会显著下降。因此，针对相互独立的任务，仍然应尽量开启新的会话，在独立上下文中处理。除此之外，更长的上下文也意味着更高的 cache read 开销，以及每次工具调用时更高的成本。

为了提升模型效果并控制使用成本，建议尽可能将可拆分的任务进行拆分，并在独立上下文中分别处理。