如何给 Codex 设定验收标准？

用Codex久了，连许愿都开始像写提示词一样详细设定目标和验收标准，生怕AI“误解”需求，这恰恰揭示了在日常使用Codex时，设定明确的验收标准是确保AI输出“精准到位”的关键方法。

一、为什么需要给Codex设定验收标准

许多用户发现，用久Codex后会养成一种习惯：表达需求时必须非常精确，否则容易得到“黑色幽默式”的结果。就像用户为了规避AI的“幻觉”风险，会在需求中列出明确的条件、边界和验证标准一样，在工作中给Codex设定验收标准，可以从源头避免需求模糊和错误理解。

设定验收标准的核心价值在于三点：- 将主观的“感觉不对”转化为客观的“可判定”- 减少反复沟通和修改的轮次- 让Codex能够自我验证和迭代，直到结果达标

二、如何设定有效的验收标准

1. 把“完成”定义清楚

设定验收标准的第一步，是明确告诉Codex什么状态才算任务“完成”。参考Anthropic的提示词原则，你可以使用“可量化目标”来描述验收条件。

性能类任务：明确阈值，例如“包体积控制在200KB以内”

功能类任务：要求执行验证动作，例如“对公开API添加限流，并确认已有测试仍然通过”

输出类任务：指定格式，例如“以HTML形式输出，包含可交互图表”

2. 让AI自己证明完成

优秀的验收标准不只是给出目标，还要让Codex有能力“自证”它完成了任务。在提示词中嵌入验证方法，能让AI主动测试与修复。

要求Codex写测试并运行验证，例如“编写测试并执行

npx jest --no-coverage

确认通过”

让Codex检查实际结果，而不是只看命令是否执行成功

对于UI类任务，让Codex截图并对比设计稿差异

三、验收标准的两种实践路径

1. 基于需求文档的验证方法

在任务开始前，先在需求文档中专门设置“验证方法”这一栏，要求该验证方法必须能够被AI自行判定。

可判定形式：脚本退出码、文件diff比对、输出包含特定字符串、子Agent按评分标准打分过线

不可判定的形式：纯主观的“看起来对”不适合作为验证方法，因为AI无法自动评估主观感觉

2. 基于“不知情子Agent”的独立验收

如果你想让技能或流程更加健壮，可以借鉴“创建不知情子Agent”的验证机制。

主Agent完成工作并凝练出技能文档（如SKILL.md）

启动若干独立子Agent，它们只读技能文档，不接触实现过程

子Agent能独立跑通才表示文档写清楚了

连续多次都通过才算交付，任何一次失败则重新计数

这种做法的价值在于：防止主Agent通过上下文补齐技能文档中遗漏的细节，避免产生“只有作者本人能看懂”的操作说明。

四、常见误区与应对策略

• 误区
• 正确做法
• 只描述步骤，不描述结果直接说明预期产出，让Codex自主定位所需文件和方法
• 给出模糊目标给出具体阈值和量化标准，让“完成”可度量
• 验证方法主观或不可执行要求验证方法必须能被AI自动判定，例如执行一个脚本或比对文件
• 修改后不追根溯源在修改前先输出“根因假设”，避免补丁式修复堆叠问题
• 让AI自己测自己使用隔离的、不知情的子Agent进行独立验证

五、高效协作的通用原则

1. 先计划后执行

在任务执行前，先让Codex输出一个简短计划，包含每一步的验证方式。如果存在多种合理理解，让AI先说明差异和影响，再继续执行。

2. 明确完成标准再开始

在任务启动前，花30秒把验收标准写在提示词里（如“完成标准是：所有测试通过、错误日志清零、输出符合指定格式”），能显著提高成功率。

3. 验证失败时引导自我修正

当Codex反复处理同一个但bug得不到解决时，不要只强调问题还存在，而是引导它“先分析原因，再尝试找到可行的解决办法，如果解决不了则告诉我需要什么资源”。这种结构化的引导能让AI突破死循环。