为什么要让代理接受外部审查？
这套方法的核心观点很直接：不要让代理自行决定设计方案。当代理开始处理任务时，不应只依靠自己的判断完成设计，而应该主动引入其他代理，对当前工作进行批判性、对抗性的审查。
这里的重点不是让审查者简单地说“看起来不错”，而是要求它们专门寻找问题，质疑当前方案是否合理，检查其中可能存在的缺陷、遗漏和过度设计。
具体应该怎样组织审查？
第一步：整理完整的问题背景
在发起审查之前，先把任务的全部问题背景写入一个文件。这个文件应当承载当前工作的上下文，让参与审查的代理能够先了解问题是什么、已经完成了什么，以及当前设计是围绕哪些条件形成的。
这样做可以避免只截取一小段内容进行判断。审查者如果缺少背景，就可能针对局部细节提出意见，却忽略真正的任务目标。
第二步：启动三个代理进行批判性审查
完成背景文件后，启动三个代理，并要求它们阅读该文件。三个代理都需要对当前工作进行批判性、对抗性的评审，重点不是重复原有设计，而是主动寻找问题。
原始内容特别强调，不能只让一个代理给出意见，而是要固定启动三个审查者。这样可以获得多份反馈，减少单一判断带来的盲区。
第三步：收集并重新审视反馈
拿到三个代理的回复后，不能把它们当作绝对正确的结论，也不能因为反馈来自代理就直接照单全收。原文要求把这些回复视为“缺乏经验、判断幼稚的实习生意见”。
这意味着反馈的作用是帮助发现问题，而不是替代最终决策。设计者需要逐条阅读这些意见，判断哪些确实指出了风险，哪些只是误解背景，哪些建议并不适合当前任务。
为什么要把审查者当作“实习生”？
“实习生”这个比喻提醒人们：审查意见值得参考，但不能盲目信任。即使审查者提出了看似专业的建议，也应当回到问题背景中重新核对。
这种态度包含两层意思：一方面，要认真听取批评，不能只接受赞同自己的反馈；另一方面，也要保持判断力，避免为了回应每一条意见而不断增加复杂结构。
如何避免审查变成过度设计？
原文最后强调：不要过度工程化。审查的目的，是发现设计中的实际问题，而不是让系统不断叠加新的流程、模块和复杂规则。
因此，收到反馈后应当优先处理真正影响方案的问题。例如，如果某条意见只是提出了一个没有必要的额外机制，就不应为了显得“考虑周全”而强行加入。审查应当服务于设计，而不是让设计被审查流程拖得越来越复杂。
这套方法的核心流程是什么？
整个流程可以概括为四个动作：禁止代理独自决定设计、将问题背景写入文件、启动三个代理进行批判性审查、把反馈当作不成熟但有参考价值的意见进行筛选。
它并不是要求代理完全服从其他代理，而是建立一种“先做方案、再找人挑错、最后由自己判断”的工作方式。最终目标仍然是保持设计简单，避免在没有充分理由的情况下不断增加复杂度。
需要注意哪些信息？
来源内容只提供了上述工作原则，并没有给出具体的安装命令、配置文件格式或完整使用示例。因此，不能据此补充具体的安装步骤，也不能擅自推断该工具的技术实现细节。
另外，原始素材末尾以不完整的“j”结束，显然不是一个完整观点。正文应以此前能够确认的内容为准，不对缺失部分进行猜测。
我认为：一个只会点头的助手，往往比一个敢于挑错的助手更危险。让三个并不成熟的“实习生”来审查方案，听起来有些滑稽，却也提醒我们：设计最怕的不是被质疑，而是从头到尾无人质疑。只是，挑错之后仍要有人负责判断，既不能把意见全部当圣旨，也不能借“避免过度设计”之名，拒绝一切改进。好的方案，大概就是在反复被敲打之后，仍然保持必要的简单。
#人工智能工具
© 版权声明
文章版权归作者所有，未经允许请勿转载。
