AI Agent自迭代改造指南：先写验证再跑循环

想让AI Agent持续自我改进，先要回答一个前置问题：怎么判断Agent真的做对了？这是近期围绕Agent自迭代能力讨论的核心起点。

相关实践来自三个方向：@poteto提出的Verification Skill、@addyosmani分享的Claude Code团队代码审查实践，以及@yetone的Agent Loop。核心共识是把标准写清楚，把可重复操作做成工具，把确定要求变成自动检查，让每次反馈都能留存。

这份指南的使用方式很直接：把完整指南复制给能访问、编辑Skill文件的Agent（比如Claude Code、Codex），告诉它需要改造的Skill路径。Agent先读现有文件给出简要诊断，和用户确认标准后再动手改造。

改造目标是把现有Skill从依赖AI理解和执行的操作说明，变成结构清晰、工具可靠、结果可验证、能根据反馈持续改进的工作系统。整个流程分四步走。

第一步是理解现有Skill。Agent先读Skill及关联文件、脚本、参考样例，梳理四件事：任务目标、执行步骤、输入输出、依赖关系、关键分支组成的工作地图；哪些操作已有工具支持、哪些重复确定性步骤值得封装成工具的工具能力；目前如何判断任务完成、哪些要求只有文字说明没有实际检查的验证机制；用户指出错误后如何修正、能否避免同类问题再发的反馈机制。已有有效设计尽量保留，不为重构而重构。

第二步是和用户确认验收标准。Agent先根据现有Skill提出自己理解的标准，再向用户确认三个重点：好结果是什么样、哪些要求必须满足哪些只是偏好；最不能接受什么错误、过去有哪些反复出现的问题；哪些环节必须人工确认、哪些可以放心交给Agent自动执行。交互上优先从现有文档、历史反馈、样例里找答案，只问缺失或模糊的关键问题，每轮最多3个，不让用户重复解释已有信息。

第三步是实施改造，按需做四件事：结构化，建立简洁工作地图让Agent理解任务、步骤、依赖和验收条件；工具化，把重复确定性操作封装成可复用工具，需要时提供统一CLI入口，不强制所有Skill都开发CLI；可验证，把明确要求转化成自动检查，记录检查对象、结果和证据，内容变化后相关验证重新执行，语义、审美等主观判断保留人工复核；可改进，建立反馈记录，优先把错误转化为认可样例、程序检查或工具修复，必要时再更新Skill说明，区分单次要求与长期规则，避免规则无限膨胀。

第四步是测试与交付。用已有样例做回归测试，条件允许再增加真实任务测试；对比改造前后结果，确保原有重要功能没有退化；未经用户确认不覆盖重要原始文件或正式交付结果。最后明确区分四类状态：自动验证通过、AI评估通过、人工确认通过、尚未验证。

交付时还要简要说明四件事：改造了什么、为什么；哪些问题现在可以自动检查；哪些问题仍然需要人工判断；以后用户提出反馈时如何进入下一轮改进。

核心原则有三条：优先解决真实问题，不追求复杂架构；优先修改工具、检查和好样例，而不是不断增加提示词；没有证据，不宣称验证通过。执行起点是先读现有Skill给出简要诊断，不要立即大规模重构。