13.5 三轮迭代接口与常见误区
面向经管学生、研究者与从业者的 AI 智能体设计教材
评估发现了问题，也找到了对应层级，但如果改动没有落到具体文件和机制里，评估就只是报告，还没有形成闭环。
这一节讲两件事：怎样把评估结果转成下一轮真正生效的改动，以及哪些误区最常见。
三轮迭代接口
评估结果要回灌到系统中，必须有明确的写入位点。按照三层评估的结构，迭代也分三轮，每轮对应不同的写入目标。
第一轮：任务校准
目标：确保每个任务的说明、约束和验收条件是完整的。
| 评估发现 | 写入位点 | 写入内容 |
|---|---|---|
| 输出缺少必需章节 | 任务说明 | 补充输出格式要求 |
| 验收条件太模糊 | 验收清单 | 改为可判定的二元条件 |
| 缺少 few-shot 示例 | 任务说明 | 增加 1-2 个输出示例 |
第一轮迭代改动范围最小，通常只涉及一个任务的提示词或说明文档。改完后重新跑一次该任务的最小评测集，确认输出满足验收条件。
第二轮：Skill 校准
目标：确保 Skill 在不同输入上的执行结果稳定一致。
| 评估发现 | 写入位点 | 写入内容 |
|---|---|---|
| 误触发或欠触发 | Skill description | 调整触发关键词 |
| 输出骨架不稳定 | 参考文件 | 增加输出模板 |
| 工具调用缺失 | YAML frontmatter | 补充 allowed-tools |
| 执行步骤被跳过 | Skill 执行步骤 | 增加强制检查点 |
第二轮迭代涉及 Skill 文件及其依赖的参考资料。改完后，用 5-10 个不同输入重复测试该 Skill，确认输出结构一致。
第三轮：系统回归
目标：确保多组件协作时没有引入新的问题。
| 评估发现 | 写入位点 | 写入内容 |
|---|---|---|
| 跨组件术语不一致 | CLAUDE.md | 更新术语对照表 |
| 错误输出未被拦截 | Hook 配置 | 增加检查规则 |
| 修改后旧功能回归 | 回归测试集 | 把新的检查项加入集合 |
| 同类错误反复出现 | lessons 文件 | 记录问题模式和解决方案 |
第三轮迭代涉及全局配置文件和跨组件机制。改完后运行完整的回归测试集，确认之前通过的检查项没有被破坏。
三轮迭代不是严格串行的流水线，不必等第一轮全部完成才开始第二轮，但层级顺序不能乱：先确认单次任务能做对，再确认封装能稳定复用，最后确认多组件协作没有回归。前两层没有查清就直接调整系统，通常只会增加排查成本。
经验写回
三轮迭代中有一个容易被忽略的环节：把解决问题的经验写回到系统中，使同类问题在下一轮不再出现。
经验写回的目标位点：
| 经验类型 | 写入位点 | 效果 |
|---|---|---|
| 术语规范 | CLAUDE.md | 后续所有代理自动遵守 |
| 输出格式要求 | Skill 参考文件 | 后续执行自动包含 |
| 检查规则 | Hook 脚本 | 后续提交自动拦截 |
| 失败模式 | 回归测试集 | 后续修改自动检测 |
| 问题-解决方案 | lessons 文件 | 后续排查时可查阅 |
没有进入规则文件、Skill、Hook 或回归集的经验，只停留在个人记忆里，不算完成迭代。
常见误区
误区一：把所有问题都归结为提示词。 输出不满意时，很多人第一反应都是改提示词。改上几轮后，提示词越来越长，问题定位越来越模糊。提示词只能解决任务级问题。同一问题在不同输入上反复出现，通常说明问题在 Skill 层面；单组件正常但组合出错，问题在系统层面。
误区二：只有主观评价，没有评测样本。 团队讨论时常说”输出质量还行”，但没有固定评测样本做对比，就无法追踪变化趋势。最小可行的做法，是维护一个 10-20 条的评测集，每次修改后跑一遍，记录通过率变化。
误区三：记录了 lessons，但没有写回机制。 很多团队会维护 lessons learned 文档，但如果 lessons 没有写进 CLAUDE.md、Skill 或 Hook，同类问题还是会反复出现。lessons 的价值在于有多少条被转成了自动执行的规则或检查。
误区四：只看最终输出，不看中间过程。 最终输出不合格时，有些团队直接修改最后一步。但如果问题出在上游环节，修改最后一步并不能解决根本问题。对于多步骤工作流，应该检查每个环节的中间输出，从源头修复。
Anthropic 的最佳实践文档建议：给模型提供验证方法（如运行测试、检查输出格式的脚本），让模型自己判断输出是否合格。这把评估从”人看结果”变成了”系统自检”，是三轮迭代中成本最低的自动化入口。
本节一句话总结： 评估结果必须落到任务说明、Skill 文件、Hook 规则或回归集中，否则不算完成迭代。