这是"用 TDD 驯服 AI 编码代理"系列的第四篇。第一篇讲了测试驱动的需求锚定，第二篇介绍了消除歧义的 GEAR 协议，第三篇讲了技术方案必须锁死什么。本篇讲最后一道防线——审核机制。 第三篇留下的问题 第三篇结尾提了一个问题：PRD 写了，技术方案写了，测试方案写了，流程是对的。但这些文档里的事实性声明——平台 API 的行为、框架的限制、依赖库的接口——都是 AI 生成的。一个人逐条核实，时间上不现实。但不核实，又可能踩进 coroutine-O——Aristotle 的异步编排原型——同样的坑。 ...
这是"用 TDD 驯服 AI 编码代理"系列的第三篇。前两篇分别讲了测试层的需求锚定和需求层的 GEAR 消歧协议。本篇补中间一环——PRD 做完之后，技术方案该做什么。 ...
这是"用 TDD 驯服 AI 编码代理"系列的第二篇。上一篇讲了测试层的需求锚定方法[1]。测试的前提是需求清晰。本篇回头补上游——需求层的消歧实践。 ...
这是"用 TDD 驯服 AI 编码代理"系列的第一篇。整个系列讲一件事：为什么 AI 辅助开发需要比传统开发更严格的流程纪律，以及每一步具体怎么做。 ...
昨天某技术群里有朋友说 GPT-5.4 的表现还不如豆包，问问题常常不读题就瞎回复。追问了一下，得知对方喂了很多文档，对话轮次也很长了。这大概率不是模型的问题——是上下文腐烂（context rot）了。 ...
五篇文章之后，我想退一步，看看脚下的路。 Aristotle：让 AI 学会从错误中反思 讲了设计理念和初版实现。claude-code-reflect：同样的元认知，落在不同的土壤 讲了跨平台移植的坎坷。信任边界：同一个想法在开放系统和受限系统上的实现实验 提出了信任分层模型。从四道伤疤到一套铠甲：Aristotle 改造中的驾驭工程实践 用改造过程验证了理论。一份 Markdown 的三次生命：从静态规则到 Git 版本管理的 MCP Server 把反思规则从 append-only 推进到了 GEAR 协议。 ...
上一篇文章 从四道伤疤到一套铠甲：Aristotle 改造中的驾驭工程实践 的结尾处，Aristotle 有了一份精简的路由器（SKILL.md 从 371 行压缩到 84 行），一个按需加载的 Progressive Disclosure 架构，和一个还算能用的反思→审核→确认流程。 ...
三篇文章之后，再次回到代码，今天要做一个深刻的反思。 第一篇 Aristotle：让 AI 学会从错误中反思 讲了设计理念和顺利的实现过程——3 个 commit 一气呵成。第二篇 claude-code-reflect：同样的元认知，落在不同的土壤 讲了同样理念搬到 Claude Code 上的适配代价——从 V1 到 V3 的持续迭代。第三篇 信任边界：同一个想法在开放系统和受限系统上的实现实验 提出了信任分层模型和驾驭工程的思考框架。 ...
Fundamentum autem est iustitiae fides, id est dictorum conventorumque constantia et veritas. — Cicero, De Officiis 正义的基石是信——言辞与约定的始终如一与真实。 前两篇讲了两个项目的故事。Aristotle：让 AI 学会从错误中反思 跑在 OpenCode 上，3 个 commit 一气呵成。claude-code-reflect：同样的元认知，落在不同的土壤 跑在 Claude Code 上，从 V1 迭代到 V3，踩了一路坑。 ...
同样的元认知能力，落在不同的土壤上，发芽的姿态和路径会截然不同。 上一篇 Aristotle：让 AI 学会从错误中反思 的核心设计是三个原则：即时触发、会话隔离、人在回路。这些原则听起来平台无关，但当把同一套理念搬到 Claude Code 上时，才发现平台差异比想象中大得多。 ...