
给 AI 套上质量缰绳:追问协议的七个条件
TL;DR: 追问协议用七个条件给 AI 的 5-Why 过程设规矩:T1–T3 是地板(不满足不许停),HC1–HC4 是护栏(防止过程失控)。其中 T2 的预防性反事实检验是最关键的设计——预防性 framing 迫使追问走深,同时反事实提问专门构造否定情境来对冲确认偏差。 ...

TL;DR: 追问协议用七个条件给 AI 的 5-Why 过程设规矩:T1–T3 是地板(不满足不许停),HC1–HC4 是护栏(防止过程失控)。其中 T2 的预防性反事实检验是最关键的设计——预防性 framing 迫使追问走深,同时反事实提问专门构造否定情境来对冲确认偏差。 ...

TL;DR: AI 用 5-Why 有三个问题:浅尝辄止(深度不够)、单线追踪(广度不够)、确认偏差(推理偏误)。三个问题独立但往往一起出现——浅层结论形成锚定后,会同时压缩探索空间和引导证据偏好。本文用一个四轮归因全部失败的真实案例,拆解每个问题的具体表现。 ...

一、引子:永远修不完的 bug 前几天,以完全实现 GEAR 协议为目标的 Aristotle 项目[1],终于成功验证了所有核心技术线路,代码也完成了第三次重构,实现了基本功能,并完善了测试。在准备把开发分支合并到 main 上线前,我做了一轮手工测试,发现 SKILL.md 的指令没有被模型正确执行——拿到了 action 却不调用 task() 启动后台 subagent,反而去加载了 LEARN.md。从排查这个问题开始,更多的 bug 被陆续发现: ...

这是"用 TDD 驯服 AI 编码代理"系列的第 6 篇。前四篇分别讲了需求层、设计层、测试层和审核层,第 5 篇把审核层升级为程序正义。本篇把它们串成一条可落地的完整管线。 ...

我之前做的 Ralph Loop 审核机制,有个隐藏问题。 v0.2 的流程只有「发现问题→修复→确认收敛」。第 4 篇提过,创造者如果认为审查者误判,可以在下一轮提供证据,由审查者重新评估——但那只是一句规则,不是正式协议。没人检验审核本身的质量。审查者可能标错问题严重等级。主代理可能盲目接受不合理建议。 ...

这是"用 TDD 驯服 AI 编码代理"系列的第四篇。第一篇讲了测试驱动的需求锚定,第二篇介绍了消除歧义的 GEAR 协议,第三篇讲了技术方案必须锁死什么。本篇讲最后一道防线——审核机制。 第三篇留下的问题 第三篇结尾提了一个问题:PRD 写了,技术方案写了,测试方案写了,流程是对的。但这些文档里的事实性声明——平台 API 的行为、框架的限制、依赖库的接口——都是 AI 生成的。一个人逐条核实,时间上不现实。但不核实,又可能踩进 coroutine-O——Aristotle 的异步编排原型——同样的坑。 ...

这是"用 TDD 驯服 AI 编码代理"系列的第三篇。前两篇分别讲了测试层的需求锚定和需求层的 GEAR 消歧协议。本篇补中间一环——PRD 做完之后,技术方案该做什么。 ...

这是"用 TDD 驯服 AI 编码代理"系列的第二篇。上一篇讲了测试层的需求锚定方法[1]。测试的前提是需求清晰。本篇回头补上游——需求层的消歧实践。 ...

这是"用 TDD 驯服 AI 编码代理"系列的第一篇。整个系列讲一件事:为什么 AI 辅助开发需要比传统开发更严格的流程纪律,以及每一步具体怎么做。 ...

昨天某技术群里有朋友说 GPT-5.4 的表现还不如豆包,问问题常常不读题就瞎回复。追问了一下,得知对方喂了很多文档,对话轮次也很长了。这大概率不是模型的问题——是上下文腐烂(context rot)了。 ...