OMO vs SLIM：一次省钱切换的实测与反思
TL;DR： 从 OMO 切换到 SLIM 跑了 13 天，每消息平均 Token 数降了 3.7%，几乎持平。按任务类型拆开后发现：coding 持平，写作贵 61%，review 省 53%，debug 贵 121%（样本不足不可靠）。Aristotle 省 68%，但主因是架构重写不是插件差异。「省钱」不是全局事实，是局部现象。真正的差异在体验和架构选择上，不在 Token 数。 ...
AI 实践
追问的最后一道防线：独立确认与协议的自反性
TL;DR： 追问协议的最后一道防线是独立确认——用一个没有确认偏差的视角，对整个假说系统做可证伪性检验找反例。本文还讲了追问协议的来路（从 18 个 bug 的实践到写文章时发现的漏洞），以及未来自反性的计划。 ...
给 AI 套上质量缰绳：追问协议的七个条件
TL;DR： 追问协议用七个条件给 AI 的 5-Why 过程设规矩：T1-T3 是地板（不满足不许停），HC1-HC4 是护栏（防止过程失控）。其中 T2 的预防性反事实检验是最关键的设计——预防性 framing 迫使追问走深，同时反事实提问专门构造否定情境来对冲确认偏差。 ...
AI 用不好 5-Why：浅尝辄止、单线追踪与确认偏差
TL;DR： AI 用 5-Why 有三个问题：浅尝辄止（深度不够）、单线追踪（广度不够）、确认偏差（推理偏误）。三个问题独立但往往一起出现——浅层结论形成锚定后，会同时压缩探索空间和引导证据偏好。本文用一个四轮归因全部失败的真实案例，拆解每个问题的具体表现。 ...
修不完的 bug 与逃不出的循环：AI 辅助根因诊断实战
一、引子：永远修不完的 bug 前几天，以完全实现 GEAR 协议为目标的 Aristotle 项目[1]，终于成功验证了所有核心技术线路，代码也完成了第三次重构，实现了基本功能，并完善了测试。在准备把开发分支合并到 main 上线前，我做了一轮手工测试，发现 SKILL.md 的指令没有被模型正确执行——拿到了 action 却不调用 task() 启动后台 subagent，反而去加载了 LEARN.md。从排查这个问题开始，更多的 bug 被陆续发现： ...
AI 辅助 TDD 全流程：从需求到代码的完整防线
这是"用 TDD 驯服 AI 编码代理"系列的第 6 篇。前四篇分别讲了需求层、设计层、测试层和审核层，第 5 篇把审核层升级为程序正义。本篇把它们串成一条可落地的完整管线。 ...
程序正义入协议：让 AI 审核的每一步都经得起检验
我之前做的 Ralph Loop 审核机制，有个隐藏问题。 v0.2 的流程只有「发现问题→修复→确认收敛」。第 4 篇提过，创造者如果认为审查者误判，可以在下一轮提供证据，由审查者重新评估——但那只是一句规则，不是正式协议。没人检验审核本身的质量。审查者可能标错问题严重等级。主代理可能盲目接受不合理建议。 ...
Ralph Loop：AI 的错误不是随机的，是收敛的
这是"用 TDD 驯服 AI 编码代理"系列的第四篇。前三篇按管线顺序讲了需求层、设计层和测试层。本篇讲最后一道防线——审核机制。 第三篇留下的问题 第三篇结尾提了一个问题：PRD 写了，技术方案写了，测试方案写了，流程是对的。但这些文档里的事实性声明——平台 API 的行为、框架的限制、依赖库的接口——都是 AI 生成的。一个人逐条核实，时间上不现实。但不核实，又可能踩进 coroutine-O——Aristotle 的异步编排原型——同样的坑。 ...
PRD → 技术方案：AI 时代文档不是负担，是护栏
这是"用 TDD 驯服 AI 编码代理"系列的第三篇。前两篇分别讲了测试层的需求锚定和需求层的 GEAR 消歧协议。本篇补中间一环——PRD 做完之后，技术方案该做什么。 ...
为什么 AI 辅助 Aristotle 开发必须从 GEAR 协议开始：需求层的消歧实践
这是"用 TDD 驯服 AI 编码代理"系列的第二篇。上一篇讲了测试层的需求锚定方法[1]。测试的前提是需求清晰。本篇回头补上游——需求层的消歧实践。 ...