继续关于我如何在Waza中设计技能的系列文章，这篇文章是关于我如何构建/检查代码审查技能的。 起点很简单。一个说“完成了”的模型并不意味着它真的完成了。它仍然可能留下破碎的逻辑、不存在的碎片、隐藏的回归或未解决的风险。根据我在建筑代理方面的经验，给模型一个具体的清单来验证完工情况，比简单地要求它“双重检查”要好得多 所以/check从来没有被设计成一个巨大的一体化审阅者。这是一个责任明确的审查编排系统。主要的SKILL.md担任首席评审员，处理评审级别和过程控制。在代理/下，有独立的专家，如安全审查员和架构审查员，每个人都专注于自己的领域。哪位专家参与是由激活规则集决定的，而不是许多人使用的关键字匹配方法。 审查级别也是有意的。对于100行以下的更改，它会进行快速审查。对于100到500行之间的更改，它会在需要时引入专家。对于超过500行的更改，它将激活完整的审查路径并添加对抗性测试回合。这一轮从四个角度寻找故障模式：破碎的假设、仅在组合故障下出现的问题、跨层集成中的错误以及滥用或误用场景。 然后，在四个层面处理调查结果。安全和明显的修复可以直接应用。大多数清楚但仍值得确认的问题都打包好供您查看。需要判断的案件会上报给你。较低优先级的观察结果仍然会浮出水面，但/check不会因为每一个小问题而打断你，也不会自行改变行为逻辑。 还有一条硬规则：如果验证没有运行，则任务没有完成。/check包含一个探测脚本，用于检测Cargo、TypeScript和Python等项目类型，然后运行相应的验证流。如果它无法检测到项目类型，它将显式失败，而不是假装所有内容都已通过。 其结果更接近于经验丰富的技术审查人员：针对不同变更规模的不同策略，明确的专家参与，以及对“完成”实际含义的更强定义。我只是试图将这些工程习惯提炼成Waza中一种简单且可重复使用的技能。 如果你对代码审查工作流程有更好的想法，我很乐意为Waza做出贡献。欢迎PR。 https://（github）/tw93/waza