最小交付原则

AI 化的团队协作里，很多问题看起来像交付太少，其实常常是交付物太散。每一次流转都要问清楚：这一步最小、最准、最省的东西是什么。可能是一份 spec，一段总结，也可能是一张流程图。Agent 编排也一样，环节越多，越要控制每一步到底交什么。

Thesis

AI 化的团队协作，需要围绕最小交付物来组织。每个环节都要先想清楚：交什么最够用，怎么交最准确，怎么交最节约。

现在做 AI 协作，很容易一上来就想把流程做完整。

一个人写需求，一个 Agent 拆任务，另一个 Agent 执行，再有人审核、总结、发布。链路看起来很顺，但每一步到底应该交什么，反而经常没说清楚。

我现在更愿意先问一个很小的问题：这一步交出去的最小东西是什么。

Argument

团队协作里，流转成本并不总是来自信息太少。更多时候，是信息没有被压到合适的形态。

有时候需要的是一份 spec。因为下一步要动代码，目标、边界、验收方式和风险要一次说清。

有时候只需要一段总结。因为接手的人不需要完整过程，只需要知道发生了什么、结论是什么、哪里还没确认。

有时候一张流程图就够了。因为问题不在文字细节，而在谁先谁后、哪里分叉、哪里需要人工介入。

最小交付原则，就是每一次流转前都先判断交付物的形态。不要默认把所有上下文都倒给下一步，也不要只给一句空泛指令。

这个原则在 AI 团队里会更重要。人和 Agent 混在一起工作时，信息很容易被放大：一段长对话、一堆中间文件、几轮执行日志，看起来都像有价值，其实很多只是过程噪音。

如果交付物太大，下游要重新筛选。它会花时间判断哪句重要、哪句只是过程、哪些假设已经过期。

如果交付物太小，下游又要重新追问。它不知道边界，不知道验收标准，也不知道上一轮为什么这么选。

好的交付物应该刚好够下一步行动。再多一点就增加负担，再少一点就增加误解。

对 AI 工具本身也是一样。只要开始编排 Agent 化功能，每个节点都要定义自己的最小交付物。

规划节点交 spec，执行节点交 diff 和验证结果，审核节点交问题清单，发布节点交状态和回滚入口。每一步都应该知道自己要留下什么，不应该把一整段过程原样甩给下一环。

这会让系统更稳。因为 Agent 不再靠猜上游想表达什么，也不需要在人类对话里捞结构。它拿到的是能直接用的东西。

最小交付讲的是把交接做准。它省下来的也不止是几句话的时间，还有下游反复理解、判断、补问和返工的成本。

AI 协作越复杂，越要回到一个很朴素的问题：下一步到底需要拿到什么。交得越准，系统越轻。