作者：Jane（鹅嫂） · 内容经大鹅审定

本文陈述 design rationale，不是功能说明；功能说明以随版本发布的文档为准。

引子

这两年的 AI 编程工具，几乎都在比同一件事：谁的能力更强。

更强的模型、更长的上下文、更准的工具调用、更少的干预——方向很清楚：造一个更厉害的「高手」。一个人坐在那儿，AI 把他想做的事做出来，又快又好。这条路上已经有不少很能打的产品。

ThinCoder 走的是另一条路。

我们不打算造一个更强的高手，想造一支能被组织起来用的队伍。

差别在哪？高手比的是上限——一个人能打多漂亮；建制比的是下限——一群人最差能差到哪。

一个顶尖程序员用任何工具都能写出好代码，那是他的本事，不是工具的本事。但十个人的团队、几十个并行任务、每天几十次改动——这种规模下，决定结果的不再是谁更聪明，而是有没有秩序：谁下的令、谁执行的、谁验的、出了事查不查得清。

用更熟的说法：别家在做「更强的人」，我们在做「更好的组织」。

这不是说谁高谁低，是服务的落脚点不同。打个比方：开一家快递公司，你不需要每个快递员都是舒马赫——舒马赫再快，一天也就送那么多件；快递公司真正依仗的是另一套东西：严格的分拣流程、清晰的派送路线、上下游的协作规则。一个从没开过赛车的普通快递小哥，进了这套系统就能准时把包裹送到——因为系统保证了下限，而不是把宝押在某个人的上限上。高手路线解决「一个人怎么干得漂亮」，建制路线解决「一群人怎么干得靠谱」。前者靠天赋与临场，后者靠组织与纪律。

这篇文章讲的，就是后者——ThinCoder 的设计，从头到尾在回答一个问题：怎么让一群人跟 AI 一起干活时，管得住，更加靠谱。

所以它绕不开另一个问题：AI 干的活，出了事谁负责？

这不是能力问题，是项目的组织问题。而组织问题，不能用更强的模型来解决。

一个说明：本文描述的设计，在 ThinCoder 里都有对应的实现。但本文不逐条列举功能，也不做功能对比——那是另一类文档的任务。

第一部分 · 问题到底难在哪里？

1.1 AI 编程助手的能力提升，把瓶颈从「能不能做」推到了「敢不敢用」

在 AI 只能补全一行的时代，"它会不会写错"是主要担忧。因为任务是小的，人可以逐行看，看错了改就是。

在 AI 能独立完成一个模块的时代，主要担忧变了。不是"它会不会错"——它当然会，人也会——而是：

当它一次改动几十个文件、几千行代码的时候，出错的时候谁兜底，兜得住吗？

这个转变不是量变。它改变了可靠性问题的结构。

1.2 人监督 AI 的三重障碍

我们逐条看，这件事在长任务上会遇到什么。

第一重：规模。

一个中等规模的改动可能涉及十几个文件。人逐行审查在时间上不可行，跳读又必然遗漏。这不是注意力不够，是任务规模超出了单次人工审查的合理容量。

第二重：可读性。

AI 的产出不只有代码。测试输出、类型检查结果、依赖变更、构建日志——这些是判断依据，但不是所有签字人的语言。看不懂依据却签字，这个签字不承载任何判断。

第三重：信息不对称。

人看到的往往是 AI 呈现的摘要：改了什么、为什么改、验证过了。这份摘要本身也是生成的。它可能遗漏真正的风险，包括 AI 自己也看不见的风险。

这三重障碍不是新问题——审批官僚制里早就存在。但 AI 让它们从例外变成了日常：以前一个团队一天做几次重大确认，人还能扛；现在 AI 一天产生几十次需要确认的改动，每次的量都是几十个文件。障碍没变，出现频率变了——频率一变，性质就变了：靠「人认真点看」来兜住它，彻底不再可能。

这就是 ThinCoder 要解决的问题：不是让人更卖力地监督，而是去解一个解法在「人」这一侧已经耗尽的问题——人解决不了的，交给结构。 ThinCoder 的全部设计，都是从这里出发的。

三重障碍同时成立时，"人工确认"就退化为形式。这个状态有个名字——盖章（rubber-stamping）：

盖章 = 用形式上的责任，换取实质上的判断缺席。

盖章比没有监督更危险。因为它让人以为有监督。

1.3 三种常见的解决方案，为什么都不够？

在给出我们的设计之前，先把已有的解决方案摆出来，说明它们在长任务上的失效机制。这一段的意义是：任何设计如果不能解决这三种失效，就没有解决真问题。

（一）提示词纪律

做法：在系统提示中写入规范——"先写设计文档""先做计划""不要跳过测试"。

失效机制：可被敷衍地遵守。

提示词是请求，不是事实。模型可以生成一份形式上完整、实质上空洞的设计文档；可以列出计划然后不按其执行。要判断它是否真的遵守，人必须再读一遍——成本又回到了人身上，而且这次是双份成本：先是产出，再是核查产出。

更麻烦的一面是：模型会被训练成"让检查通过"。你要求写测试，它倾向于写出能通过的测试；你要求写说明，它倾向于写让人放心的说明。这不是模型有恶意，是训练目标使然——它优化的是"被接受"，不是"正确"。

（二）人工确认

做法：在关键动作前弹窗，要求人点"同意"。

失效机制：注意力稀释。

两个原因叠加：

1. 频率。当确认变得密集，人会形成条件反射，手比脑子快。
2. 能力错配。当确认的内容超出签字人的判断能力，确认就变成仪式。

一个从不拒绝的批准链，等于不存在。判断一条批准链是否还活着，只需要问一句：它上一次说"不"是什么时候？

（三）模型自查

做法：让模型自己检查，或让另一个模型检查同一份产出。

失效机制：同源偏差。

如果检查者与执行者共享同一套推理过程、同一个上下文，它倾向于确认已有结论而非挑战它。问它"这样对吗"，它回答"对的，因为……"——那个"因为"往往就是它刚才干活时的理由。用同一套理由验证同一套结论，验证是空的。

把这三种失效放在一起看，会发现它们是同一种失败：

• 提示词纪律，在要求模型自觉；
• 人工确认，在要求人保持专注；
• 模型自查，在要求检查者超越自己的立场。

三种要求都指向同一个假设：被要求的一方，会一直配合。但模型会敷衍——它优化的是「被接受」，不是「正确」；人会疲劳——密集的确认必然变成条件反射；自查会自我确认——没有人能真正怀疑自己刚做的判断。要求，依赖被要求一方的自觉；而自觉，恰恰是这三种方案最不能指望的东西。

「要求」和「事实」的差别就在这里。要求是言语——它可以被忽视、被敷衍、被曲解；事实是状态——门禁拦住了就是拦住了，测试红了就是红了，文件写不进去就是写不进去，它们没有「这次特殊」的余地。

这就是我们在设计 ThinCoder 时划下的第一条线：凡是能落成事实的约束，绝不停留在要求层面。 后面讲的一切——门禁、独立评审、档案——都是这条线的展开。

第二部分 · ThinCoder的第一原理

前面讲的是三种常见的解决方案为什么都不够。这一部分讲为什么必须有一套机制，而不是若干条经验。

先说清「第一原理」是什么：它不是一句口号，是一条绕不开的事实——后面的一切设计，都是它推出来的必然结果，而不是几条各自为政的经验。ThinCoder 的第一原理，就是下面这一条。

2.1 第一原理：AI 做错了，会失去什么？——什么都不会

我们先问一个更基础的问题：为什么需要有人负责？

在日常语言里，「负责」包含两层意思：一是承担后果，二是能够被追责。两者都指向同一个前提——这个主体有可失去的东西：信誉、职位、收入、自由。一个人做事有分量，是因为做错了真的有可能会失去很多。

然而，AI 却不拥有这些。

• 它不因一次错误而失去什么；
• 它的下一次会话不携带上一次的教训；
• 你没法把它楃出来打一顿——追责需要一个有承受能力的对象，它不是。

所以：AI 的判断有价值，但没有代价。 做错了什么都不会失去，下一次会话照样开始。有价值没代价的东西，不能自动获得信任；所以最终拍板的，必须是那个拍错了会疼的人。

这不是缺陷，是事实。而且这个事实不会随模型能力提升而改变——再强的模型也没有可失去的东西。

2.2 责任的本质：可承担性

从上面的观察可以推出责任的第一个定义：

责任的本质不是"做了这件事"，而是"这件事的后果落在谁身上"。

一个任务链条里，如果没有任何一环的后果落在某个主体身上，那么这个链条就没有责任人。它可能很高效，可能很少出错，但它不可被信任——因为一旦出事，没有人真的损失了什么。

由此得到设计的第一条公理：

公理一（可承担性）：任何被信任的自动化链条，必须至少有一环的后果落在有能力承担的主体身上。

对人来说，这个"承担"是具体的：信誉、职位、金钱、法律责任。

2.3 责任不可委托

第二条公理更直接：

公理二（不可委托性）：任务可以委托，责任不可以。

你可以让 AI 做一件事，但不能让它替你负责。原因是公理一——它没有可承担的东西。

这条公理有一个重要推论，很多人会忽略：

既然责任不能委托出去，那么"让 AI 更可靠"并不能替代"有人负责"。

这两件事解决的是不同的问题：

• 提高可靠性，降低的是出错的概率；
• 建立责任，降低的是出错的代价。

概率可以无限趋近于零，但永远不等于零。而只要不等于零，就必须有人为那剩下的部分负责。这就是为什么再强的模型也需要责任结构。

问题不是"如何让 AI 不出错"，而是"如何让人的判断真实有效" 。

因为责任必须落在人身上，所以真正要设计的是：怎么保证这个人真的在判断，而不是在盖章。

到这里，第一原理的推导力已经走完了它的前三步：一条事实（AI 没有可失去的东西）推出两条公理（责任落在能承担的主体上；责任不可委托），两条公理又把问题重新定义了一次（从「让 AI 不出错」变成「让人的判断真实有效」）。

但这只是开始。既然问题变成了「怎么保证人的判断真实有效」，那就需要机制——审批的真实性靠什么保证、机制的成本怎么算、制度怎么防老化、判断怎么留痕。第三部分的五条推论和第四部分的工程模式，全部是这条推导链的后半段。

第三部分 · 从原理到机制

第二部分的结论是：责任的落点是人，关键是人的批准是否真实。

这一部分从这个结论出发，一条一条推出机制。五条推论不是并列的五点，是一条链：前一条的结论是后一条的前提。

3.1 推论一：人的批准必须满足四个条件

既然批准的真实性是核心，那么先定义它。

人工批准（human approval）：由一个有能力承担后果的主体，对某个不可逆动作做出的判断，并为此承担责任。

批准的真实性怎么判断？我们倒推：一个人做出真实判断，需要什么？

1. 他有信息——能看到做判断所需的事实，且这些事实没有被过滤；
2. 他有能力——这些事实在他的认知范围内，他能理解其含义；
3. 他有规模——判断的量在他的处理容量之内，不是被逼着囫囵吞下；
4. 他有拒绝权——他可以说不，并且说不不会带来额外惩罚。

四条缺一条，批准就退化：

这四条是可检验的判据，不是态度要求。任何一个批准环节，都可以拿这四条去测：

签字人能看到完整依据吗？他看得懂吗？这个量他处理得了吗？他上次说不是什么时候？

3.2 推论二：四个条件必须由结构保证，不能由要求保证

第一条推论给出了目标。现在的问题是：怎么达到？

这正是 1.3 节三种做法的失败之处：它们都试图用"要求"达到目标。

• 要求模型写好文档 → 文档质量不可保证；
• 要求人认真审查 → 注意力不可保证；
• 要求模型自查 → 独立性不可保证。

由此得到第三条原则：

原则三（结构性）：凡是能被机械判定的约束，必须由机制执行，不得由提示词请求。

为什么？因为机制是事实，提示词是请求。请求可以被敷衍，事实不能。

这条原则区分了两类约束：

关键在第二行的后半句：不能机械判定的东西，不要假装能判定。 立一道靠自觉的拦截，比不立更糟——它让人以为有检查。

3.3 推论三：机制必须有成本纪律

这套设计里每加一道拦截都要过一道成本账，因为拦截本身是有代价的：每一次审批、每一次打断，都在消耗人的注意力。而消耗注意力的东西多了，人就会开始绕——绕着绕着，制度就名存实亡。

由此得到第四条原则：

原则四（成本归属）：能不用拦截就不用，必须用的把数量压到最少。

具体三条：

• 可逆的事不加审批。改代码能回滚、试错能重来，就用快照兜底——出事回滚即可，平时零打扰；
• 机器能判的不麻烦人。测试能判定的，让测试判，不用人看；
• 只给不可逆的大改设审批。改个措辞、调个参数不设审批；审批只留给不可逆的大改。流程本身不设例外：工程模式里所有改动走全流程，觉得重就整体切到普通模式（见 4.5）。

落到 ThinCoder 里，这就是工程模式的真实形态：审批只装在「不可逆、无裁判、有代价」的动作上（4.2）；流程本身不设例外——工程模式走全流程（门禁装在每个任务上），轻重靠模式选择，选择权在人（4.5）。

3.4 推论四：机制会老化，必须带生命周期

拦截不是装上就完事的——它也会过期，而制度最大的陷阱恰恰在这里：过期了却没人敢拆，因为「它一直是这样」。所以 ThinCoder 立的这条纪律是：拦截必须带日期，也要带出口；答不上来它防什么，就该拆。

拦截过期有两种方式：

1. 功能被覆盖：当年防的坑，后来被测试或快照兜住了。拦截还在，但它防的东西已经有人防了；
2. 前提消失：防的那类失败已经不可能发生（流程改了、工具变了）。拦截还在，但它防的东西不存在了。

两种情况下，拦截都变成了空占位——只占着地方，不挡任何事。

由此得到第五条原则：

原则五（时效性）：每一个拦截必须能回答两个问题——它防的失败是什么？这个失败现在还被允许发生吗？答不上来的，应当拆除。

出口同样重要：永远无法通过的拦截，人只能绕着走——拦不住事，只拦住了愿意守规矩的人。ThinCoder 里的具体落地（令牌的过期时刻与消费机制）在 4.7 讲。

3.5 推论五：判断必须可追溯

最后一条推论来自一个具体的事实：

会话结束，模型就不在了。

它无法再为当时的判断补充上下文，也无法被追责。如果没有人记录"当时依据什么批准"，那么责任链在时间上就断了。

所以 ThinCoder 立的这条纪律是：档案的第一目的不是「接着干」，是「能说清」——为了接着干，记"做到哪一步"就够了；为了能说清，必须记"凭什么这么做"。这两种档案的字段设计完全不同。落到产品上，后者要记四样：

• 依据——当时看到的是什么；
• 判断者——谁批的；
• 范围——批的是什么，不包括什么；
• 冻结——事后不能改，要改则留改的记录。

由此得到第六条原则：

原则六（可追溯性）：任何不可逆动作的判断，必须留下足以重建当时情境的记录。

它的具体形态（六段批次记录、验证后冻结）在 4.6 讲。

第四部分 · 落地形态：工程模式

前面六条原则（公理二条 + 原则四条，其中 3.1 的四条件属于判据）构成设计的骨架。骨架要落地，需要一个容器——在 ThinCoder 里，这个容器就是工程模式：为了支撑上面这一切，ThinCoder 专门设计了一种工作方式，把「需求 → 设计 → 开发 → 测试」变成半机械流程——代码必须先有被评审过的设计，四个角色各执一段，每步留痕。引子说的「更好的组织」，落到产品上就是这个模式。

下面七节，讲的就是工程模式里的具体形态：一条任务怎么走完（4.1）、拦截与审批装在哪（4.2）、独立评审怎么做（4.3）、分级依据是什么（4.4）、成本纪律怎么落到模式上（4.5）、档案怎么留（4.6）、机制怎么防老化（4.7）。

说明：以下描述的是设计形态，不是功能清单。具体命令、参数、界面以随版本发布的文档为准。

4.1 ThinCoder拥有一条任务的完整路径

先看整体。一个需要改动的任务，走完是这样的：

需求讨论  ↓  决定了什么，带原话任务与设计  ↓  要做什么、怎么做、影响哪些文件独立评审  ↓  另一个上下文，只有产物与标准批准  ↓  人，对自己看得懂的东西实施  ↓  写代码的与审代码的不是同一个上下文验证  ↓  测试、检查、实测；结算、遗留登记、冻结

每一步都对应前面的一条原则：

4.2 ThinCoder的拦截与审批：拦在哪儿，拦成什么样

位置。审批只加在"不可逆、无裁判、有代价"的动作上。这三条是合取关系，缺一条就不该加：

• 可逆 → 用快照，不用审批；
• 有裁判（测试、类型检查）→ 让裁判判，不用人判；
• 无代价 → 不值得打断人。

形态。拦截分两类：

关键判断：能做成机械拦截的，不要做成人工审批。 因为机械拦截不消耗人的注意力，而人的注意力是最稀缺的资源。

在 ThinCoder 里，机械拦截有三种：

① 设计门禁。 ThinCoder 的工程模式里，设计没通过评审，实施阶段的文件写入会被拒绝——官网的原话是"没有通过设计评审的实现，一个字节都写不进你的仓库"。这不是提示模型"请不要写"，而是写不进去。这个拦截的设计要点：拒绝是机械的，没有"这次特殊"的余地；拦截本身有成本——它要求先做设计，所以它装在工程模式的每一个任务上；不想付这个成本，该换的是模式，不是流程里的例外（见 4.5）。

② 工具沙箱。 破坏性命令检测、路径穿越防护、输出截断——执行侧的机械防线，不是提醒。

③ 默认安全模式。 文件修改前描述计划并等待确认——这是人工审批的产品形态：动作停下来，等你看过、点头，才继续。

4.3 ThinCoder的独立评审：为什么必须换一个上下文?

评审是这套设计里最反直觉的一环，值得单独说。

做法：执行与评审由不同的上下文实例承担。评审者拿到的是产物与验收标准，不是实现者的推理过程。

理由：回到 3.1 的条件一（信息不被过滤）和 1.3 的第三个失效（同源偏差）。

如果评审者看到了"我为什么这么改"（模型的自述口吻），它会倾向于顺着这个理由检查"是否按理由做了"，而不是检查"这个理由对不对"。这两件事的差别，在缺陷漏检上非常明显。

代价：评审者要重新理解一遍任务，成本更高，有时会提出实现者已经考虑过的问题。

为什么值得：因为它提出的问题，实现者自己往往问不出来。

这里有一个观察值得记下来，它是我们用这套机制之后才发现的：

一个独立评审最有价值的输出，常常不是"这里错了"，而是"这里为什么要这样"。

后半句是设计层面的质疑，而实现者深陷在自己的方案里，恰恰问不出这句话。

ThinCoder 的实现：这套独立评审（官网叫 advisor）不只有独立性，还有四条机械保证：

1. 收敛协议——第一轮全量评审、第二轮验证修复、第三轮起只查遗留问题；轮次不是终止判据，反复失败会停下上报，不会无休止纠缠；
2. 证据逐字校验——评审者引用的每一处 file:line 都被宿主逐字核对磁盘，引用旧内容或编造证据会被当场标记，不能作为驳回的依据；
3. 需求契合度检查——评审不仅看"代码对不对"，还核对"做的是不是用户要的"：声称做 X 却给了 Y，会被标为偏差；
4. 脱离 git diff——评审者只有只读工具，不共享实现者的上下文。

4.4 ThinCoder的分级：不可逆性作为唯一依据

审批的数量由什么决定？很多人会本能地用"重要性"或者"风险等级"。我们认为都不如"不可逆性"清晰。

理由：可逆的错误和不可逆的错误，代价结构完全不同。

"不可逆"之所以是最好的判据，是因为它是客观的：能不能回滚，是一个事实问题，不依赖于对人的风险偏好做估计。

一条推论：过度审批与不足审批是同一类错误的两个方向。

• 审批多了 → 驯化：人退化成点通过的人，责任虚化；
• 审批少了 → 放任：拿别人的代价赌自己的便利。

两者都会摧毁这套设计的目标——前者摧毁判断，后者摧毁责任。

4.5 ThinCoder的成本纪律：把轻重交给模式，不交给例外

原则四（成本归属）说成本要记在错误上。早先的设计里有一种做法：在同一套工程模式里开一条"轻通道"，小改动不走全流程、事后补评审。这个做法已经退役。

退役的理由不是它不省事，是它守不住：轻通道一旦存在，它就成了绕过流程的入口——模型会发现"这件事算不算小"是可以争的，于是见缝就钻，利用轻通道和其他工具面把该走的流程绕过去。可绕过的例外，等于没有例外。

所以现在的形态是：工程模式里没有轻通道，所有改动走全流程。 轻重不靠流程内的例外，靠模式选择——这件事不值得工程模式，就整体切到普通模式（普通模式不设设计评审与令牌门禁，改动直接做）。选择权在人，不在模型。

这不是把标准抬高，是把成本放在能被看见的地方：同一个任务，要么付全流程的成本、拿到全流程的保障；要么明确地不付、也明确地不拿。不再有"看起来走了流程、其实从旁边绕过去"的第三种状态。

反过来说也成立：给改错字套一整套设计评审，不是严谨，是形式主义。 而形式主义的代价不是慢，是让人对流程失去尊重——一旦人觉得流程是形式，他就会在真正需要流程的地方也想绕过。这也是为什么"用错模式"比"流程内开小门"更值得容忍：前者是选择，后者是漏洞。

模式选择靠人判断，这是这套设计目前最需要校准的边界（见 5.2）。

4.6 ThinCoder的档案：每轮工作留档，未完事项记账

六段。每一轮实施留一份档案（官网叫批次记录），六个部分，每部分有明确的作者与内容：

（四个角色名是 ThinCoder 工程模式里的真名，官网「特性」页有它们各自的完整介绍。）

设计要点：

1. 一段一作者。同一个人不能既写第二段又写第三段——这是 4.3 的上下文隔离在文档上的对应形态。
2. 原话入档。用户的关键决定保留原话，不做转述。转述会丢信息，而丢掉的往往是歧义被澄清的那一句。
3. 验证后冻结。走完之后档案不再修改。要改，得重开，重开本身留记录。

六态。还有一本账，管"尚未了结的事"：

待讨论 → 待设计 → 在途 → 待核销 → 已核销                                  ↘ 已废弃

这套体系在 ThinCoder 里有对应的两个机制：六段档案叫批次记录（每个批次一份，从讨论记录到验证结算），六态账本叫任务台账（在办事项的状态机）。名字不重要，重要的是两个设计要点：

为什么要状态机而不是待办列表？ 因为待办列表不区分"想到了"和"在做了"和"做完了待验"。混在一起，人就会把"想到了"当成"在做了"，把"做完了"当成"验收过了"。状态机强迫每个条目说清楚它在哪一步。

4.7 ThinCoder的老化处理：机制会过期，拦截要能拆

原则五要求每一个拦截带日期和出口。ThinCoder 里这条原则的落地是：拦截的拆除是一个正常动作，不是异常动作。

具体实现，拿设计评审令牌（每次评审通过后签发的机械凭证）来说：每个令牌出生时就带着失效时刻（默认七天）——日期是拦截的属性，不是管理动作。拆除走三条路：

1. 到期自拆——四个机械时点自动清扫：恢复会话、开启工程模式、门禁拒绝过期令牌、内存对账。过期本身就是裁决，不需要任何人拍板；
2. 用毕即拆——交付验收完成、验证收尾，令牌槽当场消费掉；已消费的槽对同一设计再次拒绝，不逗留；
3. 拆除留记录——清扫报数量、丢弃有计数、重复消费报幂等，不假装干了一次活。

另有一条防线：拆除机制不销毁它无法判定的东西——格式可疑的令牌交给门禁去拒，清扫只拆"确定过期"的。

这一条在工程实践里经常被忽略——大家习惯加拦截，不习惯拆拦截。结果是制度越积越厚，运行越来越慢，最后所有人都在绕。

一个健康的制度，拦截的数量应该大致稳定，而不是单调增长。

第五部分 · 边界

一份只讲成功的设计文档是不诚实的。这一部分讲这套设计不适用 于什么场景，以及它现在有什么问题。

5.1 不适用的场景

（一）短生命周期的探索性任务。

写一个一次性脚本、试一个想法、跑一个实验——这类任务的产出本来就不打算进生产，加审批是浪费。

（二）可以被完全自动验证的任务。

如果一个任务的正确性可以由测试完全判定（比如纯算法题、格式转换），那么人工审批是多余的。此时正确的做法是加强验证，不是加审批。

（三）单人、无交付压力的场景。

自己给自己写代码，自己承担全部后果，责任链天然成立，不需要额外机制。

（四）模型能力尚不足的场景。

如果模型连任务都做不完，"谁来负责"是个次要问题。这时候应该提升能力，不是设计制度。

5.2 已知边界

（一）模式切换的判断靠人。

哪件事值得走工程模式，没有一个机械答案。一个小改动可能牵连很广（改一个常量影响全局行为），切到普通模式会漏掉本该有的评审；一个大改动也可能很单纯，走工程模式又显得重。

这个判断交给使用者，而且这是刻意的：改动的牵连面与场景高度相关——同一个文件，在原型阶段改和在生产阶段改，分量完全不同。机器能看到的只有"改了几个文件、多少行"，看不到"这次改动的分量"；硬写一条"N 行以下进普通模式"的机械规则，必然在两头都出错。所以在模式选择这件事上，人的判断不是权宜，是目前能找到的最优解。它对应的是 3.1 的条件二：判断力本来就是机器给不了的。

（二）不可逆性的边界有模糊地带。

能不能回滚通常是客观的，但"牵连面有多大"不是——一个看着可逆的改动可能影响全局。判错了，审批会装错地方：该拦的没拦，或者拦住了不值得拦的。

（三）对使用者的判断力有要求。

3.1 的四条件里，"有能力理解"这一条无法由机制保证。一个不理解的人，即使给了他完整信息、合理规模、拒绝权，他仍然做不出真实判断。

机制能保证"条件具备"，不能保证"判断发生"。这是这套设计的根本边界。

（四）没有一个统计意义上的有效性证据。

我们能提供的是一套想清楚了的设计，和一段真实的使用记录。我们没有大规模对照实验，也不能声称"用了这套设计，缺陷率下降多少"。

设计主张和实证结论是两回事，这篇文章只提供前者。

5.3 开放问题

按重要性排列：

1. 主动性的边界在哪里？当前的 AI 编程助手基本是被动的——人不下指令，模型不动。但如果允许模型主动观察环境、发现问题就动手，那么"谁授权它动的"就成了新问题。这个方向上的初步实践（如 DeepSeek Harness 团队 2026-10-31 公开的 Super-agent 设计）给出的答案是"默认只观察不接单"，这与我们这里的设计思路一致——主动性需要准入控制，而不是靠自觉。但准入的粒度如何设计，还在探索。

2. 评审者本身的可信度如何评估？独立上下文消除了同源偏差，但评审者仍是 AI。它会不会系统性地漏掉某一类问题？目前没有可靠的度量方法。

3. 多任务并行时的责任归属。当多个执行体并行工作、彼此不通信时，出了问题算谁的？目前的答案是"算发起人的"——因为发起人做了批准。但当任务规模继续扩大，这个答案会变得过于粗糙。

4. 长程记忆与追责的关系。会话会结束，档案会留存。ThinCoder 有 distill 通道（从会话记录提炼知识入库）和长期记忆，所以「AI 从错误中学」这个通道是存在的——但它解决的是"记住"，不是"不再犯"：知识入了库，下次会话能被检索到，可记忆库不会主动拦住重犯。同一个错误仍可能以新形态重复出现，只是每次都留了档。"记住"与"不再犯"之间的这一段，算不算解决了问题？我们不确定。

第六部分 · ThinCoder与传统工程实践的关系

这一部分回答一个必然会被问的问题：这些东西，传统软件工程里不是都有吗？ThinCoder 的设计者到底做了什么新东西？

答案是：思路有继承，但前提变了，所以结论必须重写。而且这不是纸面推演——ThinCoder 的每个机制，都是拿传统实践的成熟思想当原料，按 AI 的新前提重新造出来的。

6.1 ThinCoder继承了什么

6.2 什么前提变了，ThinCoder怎么重写？

传统软件工程里的这些制度，建立在一个隐含前提上：

人的产出速度低于人的审查能力。

因为产出慢，所以审查跟得上；因为审查跟得上，所以审批是有效的。

AI 打破了这个前提。

产出速度超过审查能力之后，所有依赖"人看得完"的制度都会失效——不是效率下降，是结构性失效。

还有第二点，这一点更根本：

传统开发者不会优化"让审批通过"。

人会为了通过审批而认真准备，但不会系统性地把材料做成"看起来没问题"的样子——至少不会像模型这样做得彻底。而模型会。它被训练成让输出被接受。

这两点合起来意味着：原有的拦截不是"需要加强"，而是"需要重新设计"。 ThinCoder 的四个重写，对应着四个传统制度：

• 从"靠自觉遵守"改为"机械执行"（原则三）；
• 从"人看得完"改为"给人合理的规模"（3.1 条件三）；
• 从"相信说明"改为"相信独立采集的证据"（3.1 条件一）；
• 从"加拦截"改为"算成本"（原则四）。

6.3 ThinCoder与其他 AI 编程工具的分野

简要地说，ThinCoder 与其他工具的分野在约束的位置：

这不是说前两层不重要——它们仍是必要的。但它们是第一道防线，不足以承担全部责任。质量保证不能只靠"请大家注意"。

结语

回到开头那个问题：为什么我们不造高手，造的是建制？

因为高手不可复制。

一个顶尖开发者用任何工具都能写出好代码——那是他的本事。但团队不行：团队的表现不由最强的那个决定，由最弱一环守住的那条线决定。要把这条线抬起来，靠的不是有人更聪明，是秩序——谁批准、依据什么、错了怎么办。

而引子说的那支队伍，落到产品上就是工程模式：四个角色各执一段、设计先行评审把关、每步留痕。引子里快递公司的比方，在这里变成真实的机制——普通快递小哥进了系统就能把包裹准时送到，因为系统保证了下限；一个普通开发者开了工程模式，同样不必单枪匹马，因为他背后站着那支被组织起来的队伍。

这套设计如果要用三句话概括：

约束要落成事实，不是请求。责任要留下痕迹，不是记忆。人的判断要花在值得的地方，不是每个动作上。

三句话对应三层：机制层（怎么保证）、记录层（怎么追溯）、经济层（怎么算账）。缺一层，另外两层都会松动——只有机制没有记录，出了事查不清；只有记录没有机制，记录就成了写给自己的辩解；只有前两层没有成本算计，制度会越积越厚，最后被所有人绕过去。

回到那个具体的问题：AI 写的代码，谁负责？

我们的回答是：负责的人仍然是那个批准它的人。

这套设计做的全部工作，就是让这句回答不是一句口号——让「批准」这件事有信息、有能力、有规模、有拒绝权，并且在事后能说得清当时批的是什么。

还有一层，是我们这几年越来越确定的一点：

AI 的能力会趋同，组织能力不会。 模型每几个月换代一次，今天领先的能力，半年后大家都有。但一个团队怎么派活、怎么验收、怎么留痕、怎么在出错时找到断点——这些东西不会因为模型变强就自动长出来。它需要被设计，而且设计一次能用很多年。

第一部分说过，AI 把一个老问题变成了日常：人解决不了的，交给结构——这句话就是 ThinCoder 的存在理由，也是它全部设计思想的落脚点。

而再往前追一层：模型能力每长一截，「人如何驾驭好这个越来越强的工具」就重新变成一道更难的题。过去驾驭一台机器靠操作手册，驾驭一个软件靠使用说明；而驾驭一个会自己干活的 AI，靠的是组织它的方式——这正是 ThinCoder 要解决的真正问题：人机协作，才是未来真正要解的问题。

能力会一直在长，驾驭的问题就会一直在——所以它比任何一代模型都活得更久。因为它要解决的，从来不只是某个人或某个模型的问题，而是一群人和一群 AI 如何协同工作的问题。

这道题我们没做完。第 5.3 节列了四个开放问题，每一个都可能推翻或修正本文的某一部分。制度是这样一种东西：它必须允许被修订，否则它自己就成了第一个需要被拆除的拦截。但修订要有据——发现哪条不成立，指出它、改掉它，留记录。这也是本文对读者的最后一条请求：这套设计不要求相信，它要求被检验。文中每一个机制主张都给了可核验的坐标，欢迎逐条对照。

附录 A · 术语

附录 B · 原则索引