在大型软件项目中使用AI进行编码的经验

本文总结了本人近期对接的一个 B 端项目的相关经验，该项目为前后端开发项目，其中 99% 100% 的代码由 AI 生成。如何在一个庞大的、时间跨度大的项目中重度使用 AI 进行编码，并最高限度地保证代码与需求的一致性和可维护性，是本文要讨论的核心问题。

信息源模型

把一切可复用的、跨会话的、跨角色的信息都放进文件系统中进行追踪。

> AGENTS.md 片段示例

## 信息源规则

当前项目的唯一文档来源是 .product/ 目录，包含以下内容：

- prd-v{n}.md：现行需求文档
- record-v{n}.md：与客户的对接记录
- todo-v{n}.md：待办任务清单
- memory.md：其他关键的持久化信息

每次从用户处获取到新的信息时，*如有必要*，请为其创建文档或写入到现有文档的合适位置。每份文档的头部*必须*写明修订日期及原始来源。

每次新会话开始时，*如果还没有阅读过*上述最新文档，*必须*先阅读这些文档，确保上下文信息完整。

唯一真相源

为了保证代码与需求的一致性，我们必须对信息源的来源途径进行限制——同一种信息只能有一个权威真相源。如果同一种信息在多个位置都有指定，那么在不同的会话中，AI 可能会引用过时的或不准确的需求，造成漂移。

在采用文件系统追踪信息源时，确保控制好这一点。例如，可以专门创建一个文件夹用于存储所有的文档和上下文信息。

会话交接闭环

要想使得每个会话之间都能携带正确的上下文信息，需要确保两点：一是每个会话在接收到来自用户的新信息时，都要将这些信息写入到可追踪的文件中；二是新会话启动时，必须读取这些文件以获取上下文信息。

基于文件的会话上下文交接能够确保每次新会话在启动时都不需要人工整理上下文信息，因为这些信息是自动进行维护的。

版本化及优先级

在一个不断迭代的项目中，信息会发生频繁变化。为了避免事实冲突，我们有必要对所有文档标注修订日期，让智能体以最新的版本为准。

即便如此，可能仍会有冲突的内容产生，此时要求我们指定所有类别的文档的优先级。例如，“现行 PRD > 客户对接记录 > 历史 PRD”。

提示词写作

这一章节梳理了我常用的提示词结构，以供参考。

开场提示词

每次创建新会话时使用的提示词，包含：

• 权威资料索引：给出可能涉及的所有文档资料的位置及优先级。
• 目标：列出本次会话需要完成的目标，最好提供可验证的预期结果。
• 资源条件：给出测试数据库、测试样本路径、测试账号、已启动的开发服务器等资源信息，避免中途请示。
• 工作流规范：说明提交规范、子智能体使用规则、工具调用限制及其他可能的约定。

> 提示词片段示例

在 @.product/record-v1.md 中给出了客户最新的反馈结果。你需要分析所有反馈条目，验证所有条目是否属实，并在 @.product/todo-v1.md 中撰写待修复的任务清单。本地测试样本位于 data/foobar。完成后暂不提交；建议使用 subagents 来探索大范围代码库。现在开始。

问题修复提示词

所有问题的本质都是实际行为与预期行为不符。在描述问题时，确保提供了最小复现三要素：操作路径、期望行为、原始错误。缺少任一复现要素的请求会导致问题修复效率降低。

有时，为了便于修复问题，还会额外提供标准样本或对照样本，以确保能够对齐。

子智能体委派

处理大型代码库时，主会话智能体容易积累大量对话上下文，这会导致两个问题：一是信息庞杂，智能体处理事务时的精准度下降，并且可能抵近上下文限制；二是开销，输入较长的上下文会导致响应时间和金钱成本增加。解决此问题的主要办法是将任务拆分给子智能体处理。

因智能体框架和所用的大语言模型而异，理想情况下，智能体可能会自动地在恰当的时机委派子智能体来处理任务。但仍值得我们在提示词中强调对于子智能体的高效利用。

> AGENTS.md 片段示例

## 关于子智能体

*适用时*，将任务拆分给子智能体处理。但不要“为了拆分而拆分”，仅做真实且有必要的委派。

通常而言，可以按照目录/层级、需求编号区间、功能域、审查视角、文件所有权或文件状态、流水线角色等维度来拆分任务。

委派时，必须告知子智能体所需材料的所有位置和细节，列出需强制阅读的文档项，并澄清条件限制和交付要求。