能进化的编程智能体

想象一下，你下班后醒来发现新功能已经被编码、测试并准备好供你审查。这是自主 AI 编码代理的承诺 - 利用像 Claude Code 这样的工具，在连续循环中改进和发布代码，同时你睡觉。

在这篇文章中，我将介绍如何设置这些自我改进的代理循环 - 从编排循环和结构化上下文文件到内存持久性、QA 验证、扩展、调试和风险管理。希望这里面有些内容对其他人有帮助。

这篇文章补充了 Ryan Carson 的优秀文章 如何让你的代理在你睡觉时学习和发布 ，我强烈推荐你阅读。 我们最近在晚餐时就代理编码的未来进行了一些精彩的讨论，我想扩展他概述的一些技术。

“连续编码循环”（Ralph Wiggum 技术）

这种方法的核心是一个迭代的 代理循环 ，通常被称为“Ralph Wiggum”技术（由 Geoffrey Huntley 和 Ryan Carson 等人推广）。关键思想是将开发分解为许多小任务，并运行一个 AI 代理在循环中一个接一个地处理它们。

循环的每次迭代都遵循一个 周期

1. 选择下一个任务 从一个待办事项列表中（例如 一个 JSON 任务列表 ）中选择一个尚未完成的任务。

2. 实现任务 - 代理为该特定功能/修复编写或修改代码。

3. 验证更改 - 运行测试、类型检查或该任务的其他质量检查。

4. 提交代码 如果检查通过，则将更改集成到代码库中。

5. 更新任务状态 （将其标记为已完成）并记录任何学习成果。

6. 重置代理上下文 并为下一个任务重复此过程，直到所有任务完成或达到停止条件。

通过在每次迭代中重置其内存，代理避免了来自先前任务的混淆，并保持专注。这一 “无状态但迭代” 的设计对于可靠性至关重要 - 它 解决了上下文溢出的问题 ，该问题困扰着要求 AI 一次构建整个功能的开发人员。

代理被反复给予一个新的、有界定的提示，用于单个明确定义的任务，而不是一个可能导致模型漂移或忘记细节的巨大提示。

结果是代码更干净，出现的幻觉（hallucinations）更少，因为每次运行都从一个清晰的状态和明确的指令开始。

这里，代理不断地选择任务、编写代码、运行测试并更新任务列表，直到所有任务都通过。

具有明确标准的小任务

将工作分解为 原子用户故事 或任务很重要。每个任务都应该 足够小，以适合一个 AI 会话 ，并且具有明确的通过/失败标准。

例如，不要说“构建整个仪表盘”，而是说“添加一个导航栏，包含指向主页、关于、联系的链接”，并指定确切的预期（例如“当前页面链接以蓝色突出显示”）。

这种粒度的方法可以确保代理知道每个步骤的“完成”是什么样子。它还减少了代理偏离正轨的机会 - 如果任务失败测试或标准，循环可以立即捕获并纠正它。

实现提示： 定义一个 SPEC 并将其转换为任务 JSON。 首先为功能编写一个明确的规范，可能需要 AI 的帮助来阐明边缘情况。

然后将其转换为一个结构化的任务列表（例如一个 prd.json 文件），其中包含所有小的用户故事和验收标准。像 Carson 的 /prd 和 /tasks 技能 之类的工具可以 自动执行此转换 。

结果是一个机器可读的待办事项列表，您的代理循环将逐步执行。

编排循环

可以通过一个简单的脚本运行循环。在 Carson 的实现 中，这是一个 类似 Bash 脚本 或 Python 脚本（例如 ralph.sh），它反复调用 AI 代理，使用一个提示模板。使用 Amp 或 Claude Code，您可能会使用它们的 CLI 命令或插件来实现相同的效果。例如，使用 Amp 的 CLI，您可以运行一个伪代码循环，如下所示：

while :; do    
   amp run \-s prompt.md \-o progress.txt  \# 运行 Amp，保存输出    
   if grep \-q "\<promise\>COMPLETE\</promise\>" progress.txt; then break; fi    
done

在实践中，循环脚本将加载任务列表，选择下一个未完成的任务，格式化一个提示（包括上下文，如相关代码文件和指南），并调用 AI 模型。当模型的响应指示成功或失败时，脚本处理应用代码更改和运行测试。这重复，直到所有任务完成或达到最大迭代次数限制。

关键是每次迭代都是隔离的 - 代理 每次都会重新启动 ，通常作为一个新的 Claude 或 GPT 进程，因此您真正地清除了状态，但每次都重新提供必要的上下文。

复合循环： 除了单个任务序列之外，高级工作流程还可以编排多个循环阶段。

例如，复合产品 是一个开源系统，它首先运行一个 分析循环 （AI 读取每日报告以确定要构建的内容），然后运行一个 规划循环 （生成 PRD 和任务），最后运行一个 执行循环 （实现任务的编码代理）。这种复合管道意味着代理不仅编写功能，还决定哪个功能具有最高优先级。

虽然并非每个项目都需要这种级别的自动化，但它展示了如何链接循环：一个代理的输出（例如任务列表或分支名称）成为另一个代理在更大的持续交付系统中的输入。

代理循环的最佳实践：AGENTS.md 手册

这些代理循环中最强大的机制之一是使用持久的 上下文文件 ，这些文件在迭代之间传递知识。

与其尝试“拉伸”一个单一的 AI 会话来记住一切（这在上下文窗口之外是不可能的），我们显式地将重要信息写入磁盘，以便在未来的提示中重新注入。用于此目的的主要文件通常被称为 AGENTS.md （尽管有些人使用 MEMORY.md 或类似）。

什么是 AGENTS.md？ 它基本上是一个代理的发现、项目惯例和您希望所有未来代理都知道的任何指导的运行笔记本。

在每个任务之后，循环可以追加关键学习：例如，“注意：代码库使用库 X 进行 Y，请遵循该模式”或“陷阱：每当更新用户模型时，也更新审计日志”。

随着时间的推移，这成为一个提示的宝库，引导代理远离重复过去的错误。在 Carson 的复合产品哲学中，“代理更新 AGENTS.md - 发现的模式记录在未来迭代中” 。这意味着每次改进实际上都使未来的改进变得更容易，因为代理积累了一个知识库，了解代码库的外观和如何与之合作。

结构化知识库： 将 AGENTS.md 组织成部分，以便人类和 AI 都可以轻松阅读。例如：

• 模式和约定： 高级别模式（例如“此项目使用 SSR，UI 组件位于 /components，API 位于 /routes”）。

• 陷阱： 曾经困扰过代理或开发人员的东西（“添加新枚举时，更新 constants.ts 文件，否则测试将失败”）。

• 样式/首选项： 编码样式说明（“遵循 ESLint 规则，如配置；更喜欢函数组件而不是类”，“使用 pytest 固件进行测试，如现有测试”）。

• 最近的学习/更改： 最近问题的摘要以及如何解决它们。

保持条目简洁和事实性 - 它们应该作为 提示添加剂 来指导模型。许多 AI 编码工具（Claude Code、Cursor、Amp）将 自动包含某些文件 ，如 AGENTS.md 或 README.md，如果它们存在。例如，当代理开始新迭代时，Amp 将扫描存储库并拉取 AGENTS.md 内容以向模型提供有关项目的上下文。

上下文注入策略： 注意上下文大小。随着知识文件的增长，您可能并不总是希望将所有内容注入到每个任务的提示中（上下文膨胀会降低性能或导致模型忽略指令）。

一个好的做法是保持 AGENTS.md 集中和最新，必要时将过时信息存档到另一个文件中。一些高级设置使用检索：例如，将 AGENTS.md 分成多个主题文件，并且只包含与当前任务相关的部分。但是，一个更简单的方法通常就足够了 - 保持文件精简到最相关的提示，并让它随着项目的增长而逐渐增长。

示例用法： 假设代理尝试使用过时的 API，并且您发现了它。

您可能会停止循环并在 AGENTS.md 中添加一个注释，例如：

“v1/users 端点已弃用；使用 v2/users 代替。”

下次代理处理相关任务时，它将看到此注释并避免弃用的 API。事实上，您可以指示代理自己执行此操作：

“不，别使用旧端点。相反，使用新的 v2/users API。将此记录在 AGENTS.md 中，然后继续。”

这种 实时反馈技术 由开发人员 Eric J. Ma 强调为一种方法，用于 “创建代理行为的持久记录，从而改进未来代理的行为” 。

代理将仔细地将更正追加到 AGENTS.md 并继续执行新指令 - 从而有效地从错误中学习。

最后，请考虑在代理或运行之间共享 AGENTS.md 知识。如果您运行多个循环（用于不同项目或并行任务），您可以集中一些常见的知识。Eric Ma 的 MCP（模型上下文协议）服务器 是一种将此类上下文统一地存储和提供给不同代理的系统示例。在更简单的术语中，即使是一个共享的 wiki 或一组所有代理会话都引用的 markdown 文件，也可以在您有多个自治代理共同工作时确保一致性。

内存持久性和复合学习策略

除了 AGENTS.md 之外，强大的代理循环还使用几个 持久性机制 来保留状态并在迭代之间避免健忘。Carson 的 Ralph 循环实现使用至少 四个内存通道 在运行之间：

• Git 提交历史： 每次迭代的代码更改都会被提交，这样下一次迭代就可以进行 git diff 或检查存储库以查看更改内容。这样，代理不需要回忆以前的代码 - 它可以从存储库中读取。提交消息本身也可以提供上下文（例如“第 5 次迭代：添加导航栏组件”）。像 Amp 或 Cursor 这样的工具允许代理 自主运行 git log 或 git diff （具有适当的权限）以从版本控制中收集上下文。

• 进度日志（progress.txt）： 每个周期追加的普通文本日志，描述了发生的事情 - 例如正在处理的任务以及它是否通过或失败，以及任何错误消息或发现。这作为一个时间顺序的内存。如果循环停止或您需要调试，您可以检查 progress.txt 以查看问题出在哪里。代理本身也可以在迭代开始时被提示读取 progress.txt（或其相关部分）以提醒它之前尝试过什么。把它当作代理的日记。

• 任务状态（prd.json 或任务列表）： 任务 JSON 文件在任务被标记为完成或具有通过：true/false 字段时会被更新。该文件持久保存每个要求的 状态 。如果代理崩溃并重启，它可以加载 prd.json 并知道确切哪些任务仍然存在。代理循环脚本将跳过已经完成的任务并专注于待处理的任务。这防止了重复工作并提供了进度感。

• 代理知识（AGENTS.md）： 如前所述，这是长期的语义内存 - 过去运行的积累智慧。

这些共同创建一个 复合学习循环 ：代理不是传统意义上的“在线学习”，但它是 系统地记录结果 ，以便下一次迭代（或下一个项目！）受益于这些学习。

代理弄清楚的每个修复或模式都会被纳入下次的上下文。正如 Compound Product README 所说，哲学是 “每次改进都应该使未来的改进更容易” 。

经过数十次迭代，代理的有效性实际上可以增加，因为它停止重复错误并遵循它所学的惯例。

还有一些 基于插件的内存扩展 可供利用。

例如，Claude Code 支持“技能”甚至市场插件 - 您可以想象（或构建）一个自动保存每个编码会话摘要并在下次加载的技能。Amp 的自动交接功能有效地充当短期内存 - 当上下文窗口即将溢出时，它可以将对话交给一个新的会话，带有到目前为止的总结。这防止了任务中途的上下文丢失，对于非常大的任务或复杂的重构很有用。

在更实验性的设置中，开发人员使用 向量数据库 来存储和检索内存。例如，在每次迭代后，您可以嵌入 diff 或错误消息并保存向量，带有描述。在新迭代之前，查询数据库以查找类似的过去案例，并将其提供给代理。

这可以帮助识别，例如，“哦，我以前见过这样的失败测试，并且知道如何解决它。”然而，这样的方法增加了复杂性，如果您勤勉地维护更简单的工件（文件和日志），代理可以直接读取，则可能不需要。

提示： 无论使用什么持久性机制，请定期 验证代理是否实际使用它。 内存文件只有在未来运行中注入到提示中时才有帮助。

检查您的提示模板或代理配置，以确保例如 AGENTS.md 和最近的 progress.txt 条目被包含。在 Amp 和 Claude 中，默认情况下可能不会自动加载 progress.txt 之类的文件，因此您可以修改提示以说：“以下是之前运行的笔记：” 并包含内容。

在 Carson 的设置中，根据项目自定义提示模板（例如 prompt.md 或 CLAUDE.md）是鼓励的 - 您可以添加加载项目特定上下文或强调特定指令的部分。

质量保证：测试和验证循环

对于自主代理可靠地生成工作代码，自动验证至关重要 。没有检查，代理可能会愉快地引入错误或导致构建失败，同时认为自己成功。强大的代理循环将测试和其他验证作为循环中的第一类公民：

• 单元测试和集成测试： 拥有一个坚实的测试套件会显著改善结果。代理可以在实现任务后运行 npm test 或 pytest。如果测试失败，循环知道任务尚未真正完成，可以提示代理修复代码。理想情况下，prd.json 中的每个用户故事都有至少一个关联的测试，或者在存储库的测试文件中。一些系统更进一步 - 例如，指示代理在编码之前编写一个新测试（测试驱动风格），或者快照应用程序的 UI 状态以进行比较。但至少，在每次迭代中运行现有的测试 。

• 类型检查和 linting： 静态分析工具（类型检查器，如 MyPy 或 tsc，linters，如 ESLint/Flake8）是很好的自动化反馈。它们快速捕获错误。这些可以作为循环质量检查的一部分在提交代码之前运行。例如，您可能会在 config.json 中配置循环在代理编写代码后执行 npm run typecheck && npm run lint，并且只有当它们成功退出时才继续。这防止代理堆叠错误。

• 循环中的持续集成（CI）： 一些高级设置甚至将 CI 管道集成到循环中。例如，Cursor 的多代理实验中有一个 “法官”代理，可以决定 项目是否完成，这可能涉及确保 GitHub Actions CI 是绿色的。在更简单的单代理循环中，您可以通过在循环的验证中运行构建脚本或任何 CI 检查来模拟这种情况。 循环应在红旗处停止 - 如果检查失败，代理应解决它（或将任务标记为仍然失败，并在尝试 N 次后可能继续）。

• AI 自我评估（可选）： 在无法轻松编写自动化测试的情况下（例如，对于没有测试框架的 UI 更改），您可能会使用代理本身进行验证。例如，对于前端任务，Carson 的代理使用 dev-browser 技能：代理可以启动一个无头浏览器，导航到一个页面，并确认 UI 元素存在或交互是否有效。这基本上是一个代理驱动的集成测试。如果验证失败，代理知道需要再试一次。虽然这可能很强大，但请确保您有沙盒（更多关于安全性的信息），因为这意味着代理正在执行代码或控制浏览器。

专家见解： 如何让 AI 代理编写好的测试？ 根据 Simon Willison 的说法，最佳方法是 以身作则 - 在代码库中维护高质量的测试，并且代理将自然地模仿这些模式。基于 LLM 的编码器倾向于遵循它们看到的样式。如果您的存储库有清晰、简单的现有组件测试，代理在添加新功能时通常会为新代码生成类似的测试。

Willison 指出，一旦项目有干净的测试，“代理添加的新测试往往与它们的质量相匹配” 。他还建议 积极地告诉代理参考已知的好例子 ：例如，“使用 [某个文件] 中的测试样式”或甚至指示它克隆另一个存储库以查看某些模式。这一上下文种子可以大大提高代理的输出并减少以后修复编写不良测试所花费的时间。

在实践中，您可能并不总是信任代理从头开始编写测试 - 许多开发人员更喜欢编写或至少审查测试。但即使那样，在循环中运行这些测试也至关重要 。这创建了一个反馈循环，其中代理只“认为”它完成了当代码真正符合规范（测试通过是该规范的代理）时。这种代理 QA 循环是将一个简单的“生成一些代码”的过程转变为可靠的工程工作流程的关键。

扩展：并发代理和多循环编排

到目前为止，我们专注于一个代理处理一个任务列表的串行处理。那么，如果你想加快速度并同时处理多个任务甚至多个项目呢？该领域的最近实验尝试了 并发运行数十或数百个代理 在一个代码库上。

虽然这仍然是前沿且尚未在日常开发中普遍使用，但它可以说明扩展这些循环的局限性和可能性。

并行代理的挑战： 如果您在同一个存储库上运行多个代理，您将遇到 协调和冲突 的问题。例如，两个代理可能会选择同一个任务，或者一个代理可能会更改另一个代理正在处理的代码。早期使用 共享文件锁定机制 的尝试显示代理卡住或浪费时间等待对方。它们也可能变得 风险规避 ，每个代理只进行微小的安全更改，并避免大型复杂任务 - 因为在自由系统中，没有单个代理感到“负责”处理棘手部分。

规划者-工作者模型： 更成功的模式是引入代理之间的层次结构或专业化。例如，Cursor 的 Wilson Lin 描述了使用 规划代理 和 工作者代理 在一个群体中。规划者就像项目经理：它们读取整个代码库，决定需要做什么，并生成任务（甚至递归创建子任务）。工作者代理然后接管这些任务并实现它们，而不必担心更广泛的图景。

在每次迭代结束时，一个 法官代理 评估目标是否实现（例如，完成项目）。这种方法防止了漫无目的的游荡，并且大大增加了吞吐量 - Cursor 的团队成功地让 数百个代理 在构建 Web 浏览器时一起工作，仅在一周内就产生了超过 100 万行代码，跨越 1,000 多个文件。

虽然您可能不需要这种规模，但 可以并行运行多个循环以实现不同的目的 。例如，您可能会专门为前端任务分配一个代理循环，为后端任务分配另一个循环（分别操作代码库的不同部分或不同分支）。

如果您这样做，请确保清晰地划分工作以最小化冲突。

另一种场景是为不同的功能分支运行单独的夜间循环 - 例如，10 个功能排队，并且您为 10 个分支触发 10 个代理进程。Ryan Carson 预测，最终，创始人将运行 10 多个这样的循环 每晚，以加速开发。每个循环仍然遵循相同的原则，但您需要良好的 CI 实践来集成所有输出（就像您有多个人类工程师同时工作一样）。

协调工具： 如果多个代理必须处理同一个项目，请考虑使用协调文件或简单的 API 进行通信。具有锁定方案的共享 tasks.json 是一种方法（尽管如前所述，文件锁可能很棘手）。另一种轻量级方法是拥有一个“交通警官”脚本，分配任务给代理并使用队列。

还有一些新兴的代理编排平台来处理多代理工作流，但目前这些平台大多是定制构建或研究项目，而不是现成的解决方案。

对于今天的大多数高级用户来说， 扩展意味着更深入地迭代，而不仅仅是纯粹地更广泛地扩展 。通常让一个有能力的代理循环运行更长时间（过夜或多天）以处理一个复杂的项目比启动一个难以管理的代理群更有价值。长时间运行的单个代理也在模型能力增长时不断改进。

监控、调试和反馈仪表

当您将编码委托给自主代理时，您需要对其操作有可见性。将您的代理视为一名真正的工程师，您正在审查他们的工作。以下是一些监控和调试代理循环的最佳实践：

• 实时日志： 保持一个终端打开，实时跟踪代理的输出或 progress.txt 日志。循环应该打印出它正在处理的任务，您应该看到测试或任何错误的结果。如果您注意到代理在同一个错误上循环，请干预（停止它或给出提示）。许多框架允许您看到 AI 的消息；例如，Claude Code 桌面应用程序显示代理工作时的对话线程，Amp 的 CLI 按步骤打印模型输出。

• 检查点提交： 由于每次迭代都会提交到 Git，因此您有一个优秀的审计跟踪。频繁使用 git log 和 git diff。如果您看到 diff 中有什么不对劲，可以在为时已晚之前捕获它。您甚至可以自动化 diff 审查 - 例如，在循环中停止，如果 diff 远大于预期或触及任务范围之外的关键文件（表明代理可能已经“失控”）。

• 检查命令： 将一些调试命令纳入循环中，或使其易于运行。例如，一个显示所有任务状态的脚本（jq ‘.tasks[] | {id, story, passes}’ prd.json）可以快速总结进度。检查 progress.txt 中的“ERROR”一词或读取最后 N 行可以告诉您任务失败的原因。

• 代理自省： 您可以要求代理解释自己，如果需要。例如，如果它卡在一个任务上，您可以修改提示以说“如果测试在 3 次尝试后仍然失败，请输出您的推理和计划。”这可以表明代理的内部思维过程（所谓的“自我反思”），这可能会提供线索。请谨慎使用 - 过多的自省也可能混淆循环 - 但这是调试工具包中的一个工具。

• 性能指标： 有用的是记录每次迭代的时间和使用的成本（API 令牌）。您可能会记录每个任务和总体的计时。如果您看到一个任务比其他任务花费 10 倍的时间，那是一个它复杂或卡住的迹象。经过多个夜晚，您可以收集诸如“每小时功能”之类的统计数据，这可以告知您是否升级（模型更改、提示调整）有所改善。

• 自动停止条件： 有时事情会出错 - 例如，代理进入了一个无望的循环（可能是由于一个棘手的 bug，它无法解决），或者外部依赖项已关闭，使测试始终失败。在正常完成条件之外，请设置停止条件。一个简单的条件是 最大迭代次数限制 - 例如，在 50 次循环后停止，即使尚未完成。这防止了无限制的成本和无限循环。您还可以在时间限制（“如果此运行超过 3 小时，请终止它”）或空闲条件（“如果在最后 5 次迭代中没有新提交，请退出”）上停止。这些确保您回到卡住的代理，而不是让它运行一整夜而没有做任何有用的事情。

• 手动覆盖： 即使有所有的自动化，也要在循环中保持人类覆盖，以便在关键时刻进行干预。一个好的模式是让代理在结束时打开一个 拉取请求 ，而不是自动合并。这意味着您每天早上都可以进行最终的代码审查。您可能会捕获到测试中未被发现的任何内容（逻辑问题，或满足接受标准的字母但不是精神）。这种“人类 QA”步骤至关重要 - 它允许您信任代理执行繁重的工作，但不放弃最终的控制权。

如果代理一致地失败某种类型的任务，请将其视为反馈。也许您的接受标准模糊或过于严格。或者也许代理需要 AGENTS.md 中关于特定框架的更好提示。将失败视为 对您和代理的学习信号 。

例如，如果代理难以使用第三方 API，因为它缺乏上下文来了解如何使用它，请考虑在 AGENTS.md 中添加一个简短的使用示例，或者将其作为代码中的注释，以便下次使用。随着时间的推移，这种反思式改进（不像配对编程回顾一样）将使系统更加强大。

风险管理和保障

运行具有提交访问权限和 shell 执行权限的代码生成代理是强大的 - 并且存在风险。您必须有意地管理这些风险。以下是关键领域以及如何解决它们：

防止破坏性操作

自主代理如果配置不当，可能会删除文件、损坏您的存储库或推送不安全的代码。为了减轻这种风险：

• 有限范围： 在功能分支或 fork 上运行代理，而不是直接在主分支上运行。这确保即使它做了什么疯狂的事情，您的生产代码也保持不变，直到您审查。

• 只读与写入权限： 大多数代理平台都有对危险操作的确认门槛。Amp 和 Claude Code 有标志，如 --dangerously-allow-all，以绕过自动化的确认。

使用这些标志时要谨慎。更安全的方法是 仅自动批准只读命令 并要求手动批准写入。例如，允许代理在不询问的情况下运行 grep、git log 或 npm test，但不要允许 git push 或 rm -rf 而不经过您的明确确认。通过白名单安全操作，您可以让代理自由地收集信息，同时限制副作用。

• 沙盒： 理想情况下，在隔离环境中运行代理 - 例如 Docker 容器或 VM - 尤其是当它有执行代码的能力（它经常用于测试）时。

这限制了意外命令造成的损害。此外，使用具有最小范围的 API 密钥：如果代理需要 API 密钥来执行某些操作（例如，发布 GitHub 评论），请给它一个只能执行该操作而不能执行其他任何操作的令牌。

• 紧急停止： 始终知道如何在代理运行中终止它。这可以简单到终端中的 Ctrl+C 或代理 UI 中的特定命令（Claude Code 使用 Escape 键停止生成）。

如果您看到它执行有害操作，请先终止，然后再询问。另外，请考虑监控资源使用情况 - 如果代理进程消耗异常高的 CPU 或内存（可能是由于代码中触发了疯狂的无限循环），则自动监控器可能会终止它。

处理幻觉和偏离

AI 模型有时会产生在语法上合理但在语义上错误的输出（幻觉）。在编码中，这可能意味着调用不存在的函数、使用错误的算法或编写无意义的注释。还有 任务偏离 的风险：代理可能会错误地解释要求并实现错误的东西。

缓解措施：

• 强大的规范和提示： 清晰的验收标准和明确定义的任务是您的第一道防线。如果任务指出“向 /api/login 发送 POST 请求并获得 200 OK”，则代理没有太多机会产生不同的端点。模糊性是敌人。花时间在开始时使任务不模糊，并使提示模板对要执行的内容和不执行的内容保持明确。系统提示/前言可以列出“不要引入任何新依赖项，除非指定”或“遵循此存储库中使用的编码样式”等内容。

• 验证以捕获幻觉： 前面提到的测试和类型检查将捕获许多产生幻觉的代码段（例如，调用未定义的函数）。类型错误、引用错误、失败的测试 - 这些