产出方式：可判定决策驱动

上一节推出的结论是：卷二的载体规模比卷一大一个数量级。承载几千个决策，每个决策带推理、边界、边缘情况，块之间保持冗余，块间的一致性还要能维护。这样一份载体，产出方法是什么。

答案是人和大模型共同产出。人做不了这件事。大模型也做不了这件事。只有两者合作能做。合作要跑通，需要一条元原则定义接口。

先说为什么单人做不了。再说共同产出的分工。再说定义接口的元原则。再说这条元原则的三层约束。

单人产出的物理边界

单人做不了的原因有两条。第一条是体量。第二条是一致性维护。

体量的问题直白。卷一的一份 spec 里，你可能需要做出几十个决策。主要功能选什么，UX 怎么走，字段怎么定，错误怎么处理。你花一下午能想清楚。卷二的载体里，决策点是几千个甚至上万个。主功能之外有几十个衍生场景，每个场景带边界处理，每个边界处理带默认策略，多个子空间之间有交互契约，每个契约带失败模式，每个失败模式带兜底策略。数量级从几十上升到几千。

几千个决策一个人做，做多久做完不算问题，问题是做的过程里怎么保持状态。人的工作记忆容量有限。你做到第五百个决策的时候，回头调整第二百个决策，你已经不完整记得第二百个决策当时是基于什么理由做的。你可以查笔记，但查笔记本身是消耗时间的动作。做到第两千个决策的时候，你需要参考的历史决策已经不是"回想"能覆盖的了。

一致性维护的问题更麻烦。卷一的几十个决策彼此相对独立，改一个不太影响其他。卷二的几千个决策彼此耦合。改一个多主编协作模式的决策，会连带影响冲突处理、通知机制、审核历史结构、UI 状态显示等十几个决策。改动引发的连锁效应，需要一致性维护。

一个人做一致性维护，改到第三处的时候会忘了第一处改成什么样。等改完第十处一回头，发现前几处已经跟当前假设矛盾了。这不是能力问题。这是人的工作记忆和一致性维护能力的物理上限。团队里最资深的架构师面对几千个耦合决策也是同样的物理上限。

胥克谦在他的开发过程里印证了这一点。他自己形容："我一个人开发的时候，写着写着就发现前面的假设跟当前的实现打架了。"他后来的做法是把一致性检查工程化，交给大模型每一轮循环都做一次覆盖。人不做这件事，因为做不了。

共同产出的分工

共同产出的分工是明确的。大模型承担细节生成、覆盖检查、扩展推理。人承担意图判断。

大模型的能力对应卷二载体的具体需求。它可以从一句需求扩展出所有相关的决策点，因为它没有工作记忆瓶颈，可以对整个已有内容做覆盖式扫描。它可以拿一个新增决策去检查其他所有决策是否兼容，因为它可以逐条对比不需要"记住"。它可以推理边界情况和默认行为，因为它见过大量类似模式。这些是它擅长的部分。人做起来会漏，会忘，会疲劳。大模型不会。

人的能力对应意图判断这一点，是因为意图这个东西只在人的头脑里。大模型无法凭空知道用户想要什么。同样一个决策空间，比如审核队列的主编协作模式，选抢占式还是分派式，两个答案都能自洽地做出一个可用产品，但产品行为完全不同。哪个是你要的，这个信息只在你的意图里。大模型只能猜。它可以猜得很像，但那还是猜。要让载体真的忠实于你的意图，人的判断必须进循环。

两边分工清楚。剩下的问题是接口。人怎么把判断给大模型，大模型怎么问人要判断。

元原则：只抛回可判定的决策

接口由一条元原则定义。大模型只向人抛回人能判定的决策。

抛回不能判定的决策等于形式主义。想象大模型抛回一个问题："系统应该用最终一致性还是强一致性？"这个问题抛给一个纯前端开发者的时候，他没有能力判定。他可能凭直觉选一个，也可能查一下文档凑合选一个。选出来的东西反映的是他对术语的浅层理解。他的真实意图并没有进来。大模型拿到这个回答，回去继续扩展载体，扩展的基础是一个凑合出来的决策。这样多轮下来，载体里的很多决策依据是凑合出来的。载体看起来完整，实际的意图对齐已经丢失。

这不是理论顾虑。这是共同产出如果没有可判定原则的话必然出现的失效模式。为什么？因为大模型识别决策的时候，会识别出很多决策。这些决策里，有些人能判定，有些人不能判定。如果全都抛回给人，人会陷入两种糟糕状态。一种是耐心不够，选一个方向敷衍了事。另一种是耐心够但知识不够，认真选但选得跟凑合差不多。两种状态下，人的判断都没有真正进入循环。

要让循环真的跑通，抛回必须是有效的。有效的抛回意味着人在这个决策上确实能做出一个反映自己意图的选择。大模型识别决策的时候，就要过滤。挑出人能判定的部分抛回。剩下的部分，大模型自己承担，或者转成人能判定的形式再抛。

判定能力由三层约束定义。领域、杠杆、呈现形式。三层都通过，才是有效的抛回。

领域可判定性

第一层是领域。人在这个领域内是否有识别能力。

判定能力和领域绑定，和职位无关。同一个人在不同领域里判定能力差别巨大。做过十年编辑器产品的人，看博客审核队列的产品决策，六七成能识别。同一个人去做一个数据库存储引擎，看架构决策，可能九成以上是盲区。资深工程师头衔不代表跨所有领域都能判定。判定的基础是知识和经验的重合区域。

胥克谦的经历是一个直接例子。他做了十几年教育行业的产品，教育项目里他有六七成的可判定率。他后来转型做编程工具。同一个人换了行业，判定率骤降。技术栈没变，工程能力没变，判定不了是因为盲区。他的原话："在开发手头这个项目的时候，里边百分之九十九都是盲区。"这个观察不是他一个人的特例，是任何一个人跨领域时都会遇到的物理现实。

大模型识别决策的时候，判定这条决策是不是在人的领域内，需要知道人的领域是什么。这个信息在共同产出的初始设定里就要给出：抛回对象是谁，他的领域是什么。抛回的时候用这个信息过滤。产品决策抛给产品经理，技术决策抛给工程师，架构决策抛给架构师。抛给谁不是身份问题，是这个人在这个领域里判定率是不是高。

一个特例是没有对应领域的人在场。有些决策没有一个明确的人可以抛。这种情况下大模型要么用有依据的默认（比如行业最佳实践、类似项目里的常见选择），要么把决策提升到更高层（可能是"这个功能整体的方向"这一层），交给能判定更高层的人。

杠杆判定

第二层是杠杆。这个决策是否值得人投入注意力。

杠杆低的决策抛给人，浪费的是人对更重要决策的注意力。想想函数命名这类决策，比如 processQueue 还是 handleQueue。两个都对，选错也不会影响系统行为。抛给人做，人的时间就消耗在这里。同一时间人可以判定的高杠杆决策就少了。

反过来，审核队列用推送模型还是拉取模型，这是高杠杆决策。选错会影响系统的可扩展性、故障恢复、监控方式。抛给人才是正确的分配。

杠杆的判断可以用一个简单的检验。这个决策错了，后面产出的东西需要大范围推翻吗。是的话，杠杆高，值得抛回。不是的话，杠杆低，大模型自己决定。

胥克谦的一个观察："PRD 决定的东西占产品价值的百分之八十到九十。"这不是文学夸张，是杠杆分布的经验描述。前期决策的杠杆比后期决策高一个数量级。一个 PRD 决策错了，后面几周几个月的代码全要改。一个函数命名错了，改一次就完。抛回给人的时候，前期决策要优先抛，因为杠杆分布本身就集中在前期。

领域够但杠杆低，抛给人是浪费。杠杆够但领域不足，抛给人是形式主义。两条同时成立，才构成有效的抛回。

呈现形式与领域词汇

第三层是呈现形式。大模型抛回决策的形式必须匹配抛回对象的领域表达。

大模型内部对一个决策的表达往往是技术性的、精确的、上下文完整的。这种表达对大模型自己有用，对人不一定有用。给产品经理抛回一个悲观锁还是乐观锁的问题，就算他领域够、杠杆够，他也没法判定。因为决策的呈现形式不在他的判定语言里。

同一个决策换个说法就能判定。"两个主编同时审同一稿的时候怎么办？选项 A：后提交的会被通知刚才有别人也在审，让他确认要不要覆盖。选项 B：谁先提交谁生效，后提交的收到已被处理的错误。"这样问，产品经理的判定就有依据了。他知道选 A 意味着用户看到什么，选 B 意味着用户看到什么。判定就变成了一个产品行为选择。

给产品经理抛回的决策要用产品行为的语言。给工程师抛回的决策要用技术权衡的语言。给架构师抛回的决策要用系统属性的语言。呈现形式错了，客观上可判定的决策也会变得实际上不可判定。

这一条推出大模型在共同产出中的额外工作。除了识别决策、判定杠杆、匹配领域，还要做一个翻译动作。把决策的内部表达翻译成抛回对象领域内可判定的表达。这个翻译能力是共同产出跑通的关键之一。

翻译不总是能成功。有些决策本身就必须用专业术语才能精确表达。这种情况下翻译动作会失败，抛回就失败。这种时候大模型要么找一个能判定专业术语的人（比如工程师），要么把决策做低一个抽象层——从"用什么锁"降到"是否允许两个人同时改"，后者是产品经理能判定的。

三层约束合起来，就是共同产出的接口。领域、杠杆、呈现形式，三层都通过，才算有效抛回。三层里任何一层不成立，抛回就是空转。

原则和方法都已经在手上。下一节用一个真实项目走一遍完整流程。

Harness Engineering Playbook · AgentsZone Community