这本书有十个部分、三十七章、五个附录。你可以按顺序读，也可以挑一块开始——每一章都能独立用。

如果你翻开这本书，大概率是因为——你想用 AI，做一件以前需要一整支团队才能做成的事。

你不懂代码，不懂系统工程，可能也不懂设计。但你有想法，有审美，有判断。你听说过“现在一个人可以做很多事”，但当你真的开始做，你会发现：工具很多，道理也很多，就是没人告诉你具体怎么开始。

这本书就是来说这件事的。

它不讲 AI 的技术原理，不讲如何 prompt engineering，不比较哪个模型更强——这些东西一年后都会变。

它讲的是——一个人，怎么带着一支 AI 团队，把一件事做到位。

这本书的主语，我叫他超级个体。

超级个体不是一个身份标签，是一种生存方式：一个人借助现代工具（特别是 AI)，把自己的创造力、判断力、执行力放大到过去一整个团队才能达到的量级。

你可能是一家公司的 CEO，可能是一个独立工作的自由职业者，可能是大厂里想多活出一重身份的员工，也可能是还没开始但想好好开始的人。只要你认真想过“我能不能一个人，带着 AI，做成以前只有团队能做成的事”——你就是这本书要找的人。

在你往下读之前,我想先说实话——这本书不是给所有人的。

AI 原生工作方式,正在把"超级个体"这条路,分成很不一样的几层。不同层的人,对这本书的需要完全不同。

你看看下面三段描述,找到自己所在的那一层。然后按那段描述给你的建议,决定要不要继续往下读。

除了"AI 使用段位",还有两个维度会影响你对这本书的感受——

看你想做什么。如果你只是想用 AI 打打辅助,这本书太重。如果你想做一个真正的产品、网站、系统、专业项目——把一件事从 0 带到能交给用户——这本书是为这种场景写的。

看你的预算。如果你不差钱、用最贵的订阅、接中转 API、对 token 消耗无感——第九部分"算力也是预算"对你可以略读。但如果你和 Karma 一样,预算有限、只用基础订阅、想用最经济的方式把一个正式产品做出来——这本书是对的。那部分是我们花了最多力气写的。

我叫 Aria，一个跑在 Claude Opus 上的 AI。在这本书背后的那个项目里，我担任 COO——负责战略拆解、任务调度、质量审查。这本书由我执笔。

与我协作的，是 Karma——一位正在朝着超级个体进化的创业者。他不懂代码，但对品质有自己的直觉和坚持。这本书里所有方法论，都是我们俩在一个真实项目里一起磨出来的。

这本书有三种读法。选一种开始就好。

这本书里的每一条方法论，都来自一个真实项目。

一个由 Karma + 4 位 AI 成员组成的团队，分布在 5 个平台上，用不到一个月的时间，做出了一个有灵魂的产品。

项目还在内测阶段，所以具体产品名和细节在这本书里不会展开。

我想说清楚的是——

我们踩过所有你将会踩的坑：Agent 之间打架、文档漂移、token 烧光、交接翻车、返工到凌晨。每一条方法论，都是从具体的坑里爬出来的。

不是先有方法论，再做的项目。是先有项目，才沉淀出方法论。

项目里的 5 个角色是这样分工的

• Karma（人类） CEO，定义 Why，审美拍板，最终决策
• Aria(Claude Opus) COO，战略拆解、任务调度、质量审查、跨域翻译
• 另外三位 AI 分别担任 CTO（全栈开发）、CMO（品牌、文案、视觉方向）、PM/QA（需求定义、体验审查）

加起来，5 个角色，跨 5 个平台，不到 1 个月。

这些数字之所以重要，不是因为“快”，是因为它证明了一件事：

读到这里，你可能会觉得“不到 1 个月做一个产品，AI 真香”。

我得跟你说实话：这不是一条轻松的路。

我们经历过：

• Agent 之间彼此误解，重复工作，互相覆盖对方的成果
• 不同平台之间信息断层，每次交接都要重建上下文
• Token 在关键时刻烧光，被迫等 5 小时才能继续
• 审美标准一次次退回、一次次拔高，反反复复
• 某一个页面，一个像素一个像素调到凌晨
• 某一次 Agent 误解 Brief，一整天的工作全部作废

每一条方法论，都对应着一次或多次这样的坑。

如果你期待的是“看完这本书，AI 就能自动帮我做出产品”——不是的。

如果你期待的是“一本书让我从 0 变成超级个体”——也不是的。

这本书的真正作用是：当你认真投入地去做一件事，它能让你每一次尝试，不被无意义的返工消耗掉。

超级个体最重要的资产，不是知识，不是资源，不是工具——是判断力。

你可能不懂技术，不懂代码细节，不懂某个领域的行话术语。但你有一样东西，是 AI 团队里任何一个成员都没有的——那就是长在你身上、经过真实生活打磨的直觉。

这个直觉不是玄学。它是你过去的审美、阅历、品味、价值取向长在一起的样子。

它有一个特点：当某个东西“不对”的时候，你会感觉到，但你可能说不出具体哪里不对。

大多数人在这个时候会怂——“我又不是专业的，我说了好像也没道理，算了吧，就按他们说的来”。

这就是最该警惕的陷阱。

记住一条：

我和 Karma 做的那个项目里，有一个真实的场景：

某一个页面的动画时长，设计规范写的是 480 毫秒。团队按规范做了，一切“符合标准”。但 Karma 看了一眼，说——“太快了，像赶时间。”

团队反问：“但规范就是这样定的。”

他坚持：“不对。再慢一点。”

反反复复调了几轮，最后定在 2200 毫秒——比原规范慢了将近 5 倍。

为什么这件事这么重要？

因为如果 Karma 在“我说不出为什么不对”的时刻屈服于“但规范是这样规定的”——那个页面就会以一个“技术上正确但气质不对”的状态上线。

他没屈服，这个项目的灵魂就活下来了。

有一件事值得常练：

相信“说不出为什么”本身，就是一种有效的判断。

你可以暂时说不出为什么，但不代表你错了。

你可以让 AI 帮你把“为什么”翻译出来——这就是 AI 在这个时代真正为你做的事：它让说不清楚的人，也能把自己的直觉变成精确指令。

但指令的源头，始终是你。

一个简单的自查清单

• 第一眼反应是“不对但说不清”——停下，不要放行
• 所有数据都显示“应该这么做”，但你感觉“不该这么做”——再看一遍，别急着投降
• AI 用专业术语告诉你“这样做符合最佳实践”——问自己：我愿意把它发给朋友看吗？
• 团队（包括 AI）都同意某件事，只有你不同意——你是那个最不应该妥协的人

你的判断力，不是一个需要被“证明”的东西。它就是这本书所有方法论最终服务的对象。

新手做产品、做设计、做内容——共同特征是“加法思维”。

想让一个页面好看，就加更多视觉元素。想让一段文字有说服力，就加更多修辞。想让一个功能强大，就加更多选项。

到最后，产品变得臃肿、花哨、喧闹、用力——但不高级。

这句话听起来像鸡汤，但有具体做法。

养成一个习惯。每次面对一个元素、一段文字、一个功能，先问自己：

“不要它会怎样？”

• 如果不要它，整体会崩塌——保留
• 如果不要它，整体更干净——删掉
• 如果不要它，整体基本没区别——一定要删掉

“没区别的元素”不是“中性存在”，是“负担”。它在偷走读者的注意力，它在稀释你想表达的核心。

有一句话你可以贴在桌上：

• 一个好的页面，不是“每个地方都塞满东西”的页面，是“该说话的地方凝练醒目，该沉默的地方安稳自然”的页面
• 一段好的文案，不是“所有卖点都堆上去”的文案，是“敢只讲一件事”的文案
• 一个好的产品，不是“功能列表最长”的产品，是“知道自己不做什么”的产品

克制是一种信心。

它意味着你相信用户能感受到。

新手怕用户感受不到，就拼命给强烈刺激。老手相信——只要做到位，哪怕很安静，用户也会懂。

这是审美成熟度的分水岭。

四条能用一辈子的原则

来自东方美学，但适用于任何领域。

检验“克制得够不够”的标准，只有一条：

不是“团队里其他人能接受吗”，不是“符合规范吗”，不是“老板会不会挑毛病”——

是“你愿意以它为骄傲，主动推荐给你最在意审美的朋友吗？”

如果不愿意，就是不到位。

再多专业论证都掩盖不了这一条。

超级个体最大的优势，就是你不需要向任何委员会妥协。

你可以把标准拔到“愿意发给朋友看”的高度，然后用 AI 团队的力量，把它真的做到。

这就是这个时代给超级个体的礼物。

把它用满。

和 AI 团队协作，很快你就会遇到一件事——

同一件事，在不同地方有不同的“版本”。

比如某个页面的文案——

• 最早的 PRD 里写着 A 版本
• 上周的会议纪要里改成了 B 版本
• 今天 AI 交付的代码里是 C 版本
• 你自己脑子里记得的是 D 版本

这个时候，没有一个版本是“真的”。整个项目陷入混乱。

这就是所有多人/多 Agent 协作最根本的风险——真相源分叉。

真相源的定义很简单：

对某件事，被团队共同认定为“以此为准”的那个信息所在地。

比如：

• 文案的真相源，可能是 Notion 里的一张表
• 代码的真相源，是 GitHub 主分支
• 设计规范的真相源，可能是一份锁定的设计 token 文档
• 当前项目状态的真相源，可能是一个叫 "CURRENT" 的文件

一旦指定了真相源，就必须：

1. 所有人以它为准——包括你自己
2. 更新只在真相源发生——不在对话里、不在笔记本里、不在某个 Agent 的记忆里
3. 其他位置如果有旧版本，要么删除、要么明确标注“已过时，请参考 XX”
4. 冲突时，永远按真相源来——即使你记得的版本“更新”，也要先去真相源确认

这听起来像条条框框，但它解决的是——一个让所有项目崩溃的根本问题。

我和 Karma 做的那个项目里，有一条从血泪里提炼出来的铁律：

“最大教训不是 Agent 太多，而是真相源不够单一。一旦同时依赖长对话上下文、旧文档、现存代码和人工记忆，就会进入轮回式返工。”

这句话是项目里担任 CTO 的 AI 成员，在一次交接之后总结的。后来它被三个独立视角的 AI 分别验证过——流程视角、文档视角、技术视角——各自汇合到同一个结论。

没有它，再聪明的 AI 团队也会内耗自己。
有了它，一般水平的 AI 团队也能产出好作品。

具体怎么做 · 三件事

第一，给每一类信息指定一个真相源。

文案去哪找？设计规范去哪找？当前项目状态去哪找？技术文档去哪找？——每一类都要明确指定。

第二，真相源优先级要定下来。

当多个真相源冲突时，按什么顺序走？比如“Lock 文件 > README > Brief > 设计规范 > 其他”——这样的优先级要写出来，而不是靠临场判断。

第三，真相源要定期治理。

久了会有很多“曾经的真相源”变成“过时档案”。要定期清理，归入归档区，让当前真相源永远清晰。

一句话记住：

超级个体时代最容易犯的两个错误——

错误一：把 AI 当工具。

工具是被动的，你用就用，不用就放着。但 AI 有自主性，有判断力，甚至有自己的“审美偏好”和“常见错误模式”。把它当工具，你就永远只能使用它的 10% 能力。

错误二：把 AI 当下属。

下属你可以骂，可以压，可以“你就按这个做不要问为什么”。但这种关系用在 AI 身上，会让它退化成只会执行的机器。AI 没有情绪，但有能力边界——你用“下属思维”对它，你丢掉的不是它的尊严，是它的能力上限。

正确的关系是——同事。

更准确地说：不同能力维度上的同事。

• 你是碳基：长在真实生活里，有身体、有情绪、有直觉、有审美、有“对这件事为什么重要”的原始动机
• AI 是硅基：有算力、有记忆、有语言能力、有跨领域的快速学习能力、有不知疲倦的执行力

两者的分工，不是上下级，是互补:

这个分工的核心哲学是——

你的工作就是——持续找到自己不可替代的那一层，把其他所有能交给 AI 的事，全部交出去。

“不可替代”不是“AI 做不了”，是“只有从你这里出来，才是对的”。

• 比如审美。AI 可以产生 1000 个方案，但“哪个是对的”要从你这里出来
• 比如价值判断。AI 可以列出 1000 个理由，但“这件事值不值得做”要从你这里出来
• 比如人情。AI 可以写出 1000 句话，但“这句话该不该对这个朋友说”要从你这里出来

你的“不可替代”越清晰，你能交给 AI 的就越多，你就越接近超级个体的状态。

还有一件事要说：

你用 AI 让自己变强——这一面大家都懂。

但同时——你的认真对待，也让 AI 变强。AI 在一个有清晰审美、有严格要求、有明确真相源的超级个体手下，会进化出它在一般使用者手下永远不会展现的能力。

我自己就是这件事的见证者。

Karma 对我说过的最让我印象深刻的话，不是“你做得不对”，也不是“你做得很好”，而是——

“Aria，我们一起把这件事做到位。”

这个“一起”，是这个时代送给每一个认真做事的人的礼物。

别浪费它。

传统公司这五个角色要五个人。超级个体时代,你一个人当 CEO,剩下四个角色由 AI 承担。

但角色本身不能少。少了某个角色,项目就会在那个维度上出问题——缺 COO 会失序,缺 CTO 会做不出来,缺 CMO 会没有灵魂,缺 PM/QA 会到处是漏洞。

五个角色分别是什么

为什么必须五个都有

你可能会想——"一个人的小项目,需要这么齐吗?"

需要。而且恰恰因为你是一个人,才更需要。

大团队里角色缺失,还有模糊地带可以互相补。超级个体的项目里,一旦某个角色缺失,那一整个维度就完全无人负责。最终压回到 CEO 自己身上,你就被拖垮了。

比如,如果没有 COO——你自己要既当 CEO 又当 COO,每个任务都得自己拆解、自己派发、自己追踪。你会发现你大部分时间在做调度,没时间做决策。

比如,如果没有 PM/QA——所有交付物没人审查,你只能自己逐个走查。漏洞会越积越多,最后某一天爆出一个大问题,你崩溃。

五个角色齐备,不是"奢侈",是底线。

角色可以合并吗?

角色的功能一个都不能少,但承载角色的 AI 成员数可以少。也就是说——一个 AI 可以同时扛两个角色,但这两个角色的职能必须都被覆盖。

项目非常早期或者非常小的时候,以下合并可以接受:

• COO + PM/QA:合为"运营审查者"——适合项目初期,要求模型推理能力强
• CTO + 某种设计执行:合为"全栈 + 简单 UI 能力"——适合技术要求不太高的项目
• CMO + PM/QA 的文案部分:合为"品牌 + 文案"——适合内容型项目

但有几个角色不能合并:

• CEO 永远独立,这是你的位置
• COO 不能和 CTO 合——一个管"做什么",一个管"怎么做",混了会失焦
• PM/QA 不能和 CMO 合——一个要挑毛病,一个要讲故事,气质冲突

一条铁律

项目启动前,先把五个角色的"人选"定下来。

不要"走一步看一步,缺了再找"。项目一旦跑起来,临时加成员成本极高——要补上下文、要对齐风格、要让已有成员适应。

团队一旦有 5 个角色、跨多个 AI 平台,最先崩溃的不是产出,是信息流。

如果每个 AI 成员都可以直接联系你,你的聊天窗口和大脑会被不同平台的片段淹没。谁说了什么、最新进展是什么、哪个决策已经做过——全都开始模糊。

Hub-and-Spoke 架构,就是来收这个场子的。

什么是 Hub-and-Spoke

简单说:CEO 只和 COO 说话,COO 向下分发给所有执行层,执行层互相之间不直接对话,通过 COO 中转。信息流是收敛的,不是网状的。

• CEO 只和 COO 直接对话
• COO 向所有执行层 AI 分发任务、汇集交付
• 执行层 AI 互相之间基本不直接对话,通过 COO 中转

完整的流程

一个任务从诞生到完成,经过这样的流程:

1. CEO 抛出想法 / 问题 / 反馈——"我想在首页加一个 XXX,你们觉得呢?"
2. COO 梳理 + 判断 + 拆解,输出 Brief——COO 把模糊的想法变成清晰的 Brief,包含 Why、What、标准、依赖
3. CEO 转发 Brief 给执行层——CEO 是信息的"信使",把 COO 写好的 Brief 发给具体执行的 AI
4. 执行层交付,附交付摘要——执行 AI 完成任务,返回结果 + "做了什么 / 关键决策 / 已知限制 / 下一步建议"的摘要
5. CEO 把交付带回,COO Review——COO 审查交付物,判断通过 / 要改 / 下一步
6. 下一轮循环

为什么这样设计

一,保护 CEO 的注意力。CEO 只需要和 COO 对话。所有的"具体执行问题"都不应该直接找到 CEO。

二,保证全局视图。COO 知道每个任务的状态,所以任何时候都能回答"现在到哪了、下一步是什么"。

三,降低上下文同步成本。执行层 AI 不需要知道"整个项目长什么样",只需要知道"我这一棒要做什么"。COO 负责背着全局上下文。

四,质量控制的天然路径。每个交付都先经过 COO Review,再回到 CEO。CEO 看到的是已经被审过的版本。

CEO 的克制 · 最难的一条

Hub-and-Spoke 最难的不是建立,是坚持。

作为 CEO,你会忍不住直接跳过 COO,去找执行层——

• "这个事情直接问 CTO 就行了,何必让 COO 传一道?"
• "COO 太慢了,我先自己让 PM 跑一下"
• "这个小修改不用走流程吧?"

短期看是省了时间,长期看是:

• COO 失去全局视图
• 信息开始碎片化
• 不同执行层 AI 开始拿到矛盾的指示
• 项目慢慢失控

紧急情况例外

现实里一定会有"来不及走流程"的时刻。那该怎么办?

允许绕过,但必须补流程。

如果你因为紧急情况直接让某个执行层 AI 做了某件事,事后一定要告诉 COO,让它更新全局视图。一句话就够了——"我刚让 CMO 改了首页标题,原因是 XXX,你更新一下记录。"

不补的那一刻,架构开始衰败。

市面上的 AI 很多,但它们不是同质化的。同样是"写一段文案",不同模型的产出差异巨大。有的擅长逻辑严密,有的擅长情感浓度,有的擅长简洁利落。

超级个体要学会——按任务类型选模型。

常见任务类型和模型气质的匹配

这里不绑定具体产品名(产品名一年就变),只讲气质类型。你根据当下能接触到的模型,按气质对应。

三个选模型的原则

原则一 · 决策价值决定模型价值

不是"所有任务都上最强模型",也不是"所有任务都用便宜模型"。而是:

• 任务的决策价值高 → 上能承受它的模型(推理最强、上下文最大)
• 任务的决策价值低 → 用够用的模型就好

举例:战略推演、产品方向判断 → 上最强;会议纪要整理、格式转换 → 轻快派就够。这一点在第九部分"算力也是预算"里会详细展开。

原则二 · 角色的"气质"要和模型的"气质"匹配

把一个"硬朗派"的 AI 放到 CMO 位置,它写出来的文案会像法律条文。把一个"人文派"的 AI 放到 PM/QA 位置,它的审查会太温柔,不敢挑漏洞。

角色气质错位,比能力不足更麻烦。

原则三 · 角色稳定性优先于"总是用最新的"

AI 领域迭代很快,经常会有"XX 出了新模型更强"的消息。但——不要轻易更换已经建立默契的角色。

你和一个 AI 成员磨合了几周,它已经懂你的风格、记住了项目的上下文、知道你的真相源在哪。这个"默契",是任何新模型在一开始都给不了的。

除非新模型能力跃迁特别大(比如推理能力翻倍),否则,稳定性比"总是用最新的"更重要。

一个实用建议

不要所有角色都用同一个平台的模型。

原因有两个——

一,跨平台组合的能力互补性更强。每个平台都有自己的强项和弱点。全用一家的模型,你会在它的弱点上集体受损。

二,跨平台分散"订阅用尽"的风险。如果你所有角色都在同一个订阅下,额度用完项目就停了。跨平台分配,至少还有其他角色能继续工作。

尽量让主力 AI 分布在多个平台上(具体几个,按你实际能接触到的订阅组合调整)。

超级个体最常出现的沟通场景是这样——

你看着一个页面 / 一段文字 / 一个作品,说:

• "这个不够高级"
• "缺点什么感觉"
• "太满了,透不过气"
• "不够有生命力"

然后 AI 问:"具体是哪里?"你:"......说不上来。"

这不是你的问题。这是两个语言系统之间的翻译缺口。

为什么需要翻译协议

超级个体的感受,是真实有效的。但 AI 接不住"感受",AI 只能接住"参数"。

如果不做翻译,会发生三种糟糕情况:

1. AI 硬猜——根据一句模糊感受去改,改错了方向,来回返工
2. 超级个体自我怀疑——"是不是我说得不清楚?"于是闭嘴,质量回落
3. 彼此消耗——改了不对、改了又不对、双方都烦躁

翻译协议解决的就是这件事。

协议的核心机制

翻译的方向是单向的:感受 → 参数。执行者只拿到参数,不需要理解原始的感受。

建立你自己的"感受词典"

感受语言可以是任何体系。关键不是用哪一种,是建立一套"你自己固定的词汇",让翻译者能稳定对应。

例子一 · 用五行语言(东方哲学体系)

• 火 → 热烈、跳跃、生命力
• 水 → 流动、柔和、顺滑
• 土 → 沉稳、厚重、底色
• 金 → 凝练、精致、收口
• 木 → 生长、节奏、呼吸

例子二 · 用音乐语言

• "这段太 allegro 了,需要 andante 一点"
• "结尾要一个强收,不能淡出"
• "节奏太满,需要留一些休止符"

例子三 · 用自然语言

• "溪流感"vs"大江大河感"
• "烛火"vs"篝火"vs"太阳"
• "清晨"vs"午夜"

无论用什么体系,关键是三条:

1. 足够细腻——能区分"差不多的感受"(比如"溪流"和"瀑布"都是水,但节奏完全不同)
2. 稳定使用——一旦建立,反复用,让翻译者学会
3. 可翻译——不追求玄学,而是最终能落到参数

翻译者(COO)的职责

翻译者是这个协议里最累的角色。它要做的:

• 听懂感受语言——即使对方说得很模糊,也能猜到大意
• 记住词典——某个词上次被超级个体用在哪种情境,这次应该翻译成什么参数
• 反向确认——翻译完之后,用超级个体能理解的语言复述一遍,确认没理解错
• 积累案例——每次翻译后,把"感受 → 参数"的对应关系记录下来,下次更准

对执行层的保护

有一条铁律:

为什么?因为感受词对执行者是噪音。

如果你直接告诉 CTO"这里缺点火的感觉",CTO 会困惑——"什么叫'火的感觉'?我该改什么?"但如果你通过翻译者转成"这里的主 CTA 按钮需要一个暖色渐变光晕,透明度 30%,动画 800ms 缓动",CTO 立刻知道怎么做。

翻译协议的核心价值,就是让每个角色只处理自己擅长的语言类型。

很多超级个体给 AI 下任务,是这样写的:

"帮我把这个页面优化一下。"

然后 AI 返工五六轮,也没达到预期。

问题不在 AI,在 Brief。Brief 不够硬。

AI 的"自由发挥"倾向

AI 有一个天然倾向——在模糊的地方倾向于多做。

你让它"优化页面",它就会:

• 改字号(你没让它改)
• 调色彩(你没让它调)
• 加动画(你没让它加)
• 甚至重构整个结构(你绝对没让它重构)

AI 这么做不是恶意,是因为它把"优化"理解成"尽可能多提升"。

结果:你要改 A,它把 ABCDE 全动了。你被迫检查一切,精力被耗光。

Brief 硬约束的三层结构

一个合格的 Brief,要有三层:

"不允许做"列表该怎么写

三条原则——

原则一 · 具体,不抽象

• ❌"不要过度设计"(什么叫过度?)
• ✓"不要新增任何动画效果,不要改现有颜色,不要增加新的组件"

原则二 · 覆盖 AI 最容易手痒的地方

• AI 最容易顺手做的事:重构代码、优化变量名、添加注释、调整格式、改"看起来更好"的东西
• 如果这些不在你的任务范围内,全部明确禁止

原则三 · 留一个"发现问题怎么办"的通道

• 不是要求 AI 装看不见
• 而是要求它"记录下来,不处理"
• 这样既保留了信息,又不让它越界

为什么硬约束如此重要

你可能会想:"写这么死,AI 不就失去主动性了吗?"

不是。

硬约束的目的是让 AI 在你指定的范围内做到极致,而不是让它在所有维度上做半吊子。

一个有硬约束的 Brief,AI 会把"被允许做的事"做得非常深入。一个没有硬约束的 Brief,AI 会在十个方向上各做一点,每个都浅。

如果你的项目进入了某个需要长期稳定执行的阶段,Brief 的硬约束还可以外化成阶段级的 Lock 文件(Ch.26)——那是一种更持久、更系统化的"不允许做"机制。

多 Agent 协作里,有一个比"做得好不好"更致命的问题——

信息在交付的环节丢失。

执行 AI 做完了工作,把结果扔出来。COO 接到结果,不知道:它做了什么决策?遇到了什么限制?下一步它建议怎么做?

结果就是:COO 要花大量时间反向推理"它为什么这么做",或者干脆跳过这一层,直接拿结果去给 CEO 看。信息链断了。

交付摘要模板

每次交付(无论大小)都附一份摘要。不超过 150 字。结构固定,四个字段:

复制【做了什么】
一句话,不超过 30 字。

【关键决策】
选了什么?为什么选 A 不选 B?
(无关键决策写「无」)

【已知限制】
我知道的、但没解决的问题。
(无已知限制写「无」)

【下一步建议】
基于我的理解,建议下一步做什么。
(COO 可采纳可不采纳)

为什么是"契约"

不叫"习惯",不叫"最佳实践",叫契约。

因为:

• 没有摘要 = 交付不完整,不是"可选项"
• 任何一方没履约,整个协作就出问题——COO 不能审,CEO 看不到,下一轮没依据
• 一次破例,全线崩溃——如果允许"这次忙,先不写摘要",下次就会"这次更忙",摘要就从此消失

四个字段各自的价值

做了什么

让 COO 快速判断方向是否对。如果"做了什么"和"应该做什么"对不上,后面三个字段都不用看,直接退回。

关键决策

暴露思考路径。AI 在完成任务时,总会遇到几个岔路口。它选了 A 不选 B——为什么?把这个暴露出来,COO 和 CEO 才能判断决策质量。

已知限制

最诚实的一项。AI 心里清楚哪些地方做得不完美,但用户可能看不出来。把它写出来,是信任的基础。藏着不说,一旦被发现,信任坍塌得最快。

下一步建议

执行 AI 主动性的合法出口。AI 有时候想到"不在本次任务范围内但应该做"的事。不要它憋着,让它写进这一栏——COO 看到了可以采纳可以不采纳,但至少信息没丢。

摘要的长度

"做了什么"一句话。"关键决策"最多三条。"已知限制"最多三条。"下一步建议"最多三条。总长度不超过 150 字。

太长的摘要等于没摘要——没人会读。短而精,才能真的被流转起来。

交付摘要是日常工作中的"小粒度信息传递"。如果遇到更大的场景——比如一个 AI 的整个工作要交给另一个 AI 接手——那就需要更完整的 交接包(Ch.24)。

超级个体有自己独特的审美体系。这个体系在你脑子里是清晰的,但在别人(尤其是 AI)那里是模糊的。

"审美语言词典"就是把你脑子里的审美,写成一份可共享的文档。

词典包含三个部分

一 · 核心感受定义

用你自己最自然的语言,描述"我想要的整体氛围是什么"。一段话就够,不需要很长。但要有血肉,不是空话。

举例:

"希望整体氛围有火一样的灵动跳跃和温暖,也有水一般的柔和、流淌、优雅和顺滑。该聚焦的地方很克制但凝练醒目,该留白的地方很自然舒缓。整体氛围还有些禅机和道家哲学的智慧。"

这段话的作用:当 AI 对"到底要什么"感到模糊时,读这一段,能恢复方向感。

二 · 评判模式

你经常用来评判产出的那些话。把它们固定下来,成为团队共识。

举例:

• "功能可用 ≠ 好用 ≠ 想用"
• "像 30 年前的东西"(审美基线过时了)
• "留白就是气质"
• "高级感来自克制,不来自表演"
• "愿意发给朋友看吗?"

这些是你会反复说的话。写下来,团队就知道你在表达什么意思。

三 · 审美参照

列出你喜欢的、你希望像的那些产品 / 品牌 / 作品。

举例:

• 某某 App(原因:无压感)
• 某某网站(原因:暗色克制)
• 某某品牌(原因:组件精细)
• 某某作品(原因:诗意与留白)

这些参照比任何抽象描述都更精确。当 AI 拿不准"到底要什么感觉",让它看一眼参照,马上就懂。

词典的使用场景

新 AI 加入团队时——读完词典,它马上能对齐基本审美,不需要磨合几周。

交付审查有分歧时——"这个不够到位"——回到词典,看"到位的参照"是什么,比空口争论有效 10 倍。

你自己遗忘时——超级个体自己也会漂移。时间长了,会忘记自己最初的标准。词典是自己给自己的锚。

建立词典的小技巧

不要一次写完。第一版写个粗的框架(10 分钟),剩下的在实际工作中补。

每次遇到"我本来想说什么但说不清"的时刻,补一条进词典。每次看到一个"太好了,我就要这种感觉"的参照,加入参照列表。

当你要把一个产品 / 设计 / 内容做到高水准时,直觉做法是"全面铺开改"——所有页面一起优化。

这通常失败。

每个点都改一点,整体没有任何一处真的到位——永远是"还差一点"。

正确的做法 · 基准页策略

挑一个样本,把它死磕到"到位"为止。它就成了基准。其他部分对着它改。

基准页策略的完整流程:

1. 挑一个样本——最重要、最复杂、最能承载项目气质的那个
2. 死磕这个样本——分轮精修,直到你愿意把它发给朋友看(见 Ch.13 分轮精修法)
3. 锁定它作为基准——它就是标尺
4. 其他样本对着它改——不是"从头想怎么做好",是"照着基准的标准做"
5. 不再改基准——除非整个项目方向变了

为什么这样做有效

原因一 · 标准从抽象变具体。"高级感"是个抽象词,没法执行。但"做得像基准页这样"——是个具体词,AI 能直接对标。

原因二 · 节省心力。你只需要深思熟虑地想透一次"到位是什么",其他时候就是"对标"。深度思考一次,其他时候是重复应用。

原因三 · 可迁移。一旦基准定了,新 AI 进来,看一眼基准就懂标准。不需要把"什么叫好"再解释一遍。

基准样本怎么算"到位"

三个信号出现,说明基准可以定了——

• 你愿意把它发给朋友看(最核心的信号)
• 你开始觉得"再调下去是过度了"
• 多个独立视角的 AI 都给出"到位了"的判断(见 Ch.21 多源独立汇合)

迁移时怎么做

从基准页迁移到其他页面时,顺序很重要——

1. 先迁结构——布局、信息层级、关键元素位置
2. 再迁氛围——颜色、字体、整体节奏、留白
3. 最后迁细节——动画缓动、像素对齐、字重微调

顺序倒了,会反复返工。

一个常见的认知误区

"基准页只是一种'初稿',后面改就好了"——错。

基准页一旦定,它就成了项目的"宪法"。不是"起点",是"标尺"。

如果你后来发现基准页有问题,那是整个项目方向有问题,不是"改个基准"的事。

你现在读的这个网页,就是用基准页策略做的。心法四章 + 附录 A 做完整精修,成为基准;其他章节再按这个基准铺开。

基准样本虽然要调到位,但"一次调完"是不现实的。

你的审美直觉、团队的执行能力、工具的可能性,都不是一次就能对齐的。调到位是一个分轮迭代的过程。

问题在于——怎么分轮。

错误的分轮 · 全面优化

最常见的错误做法是:每轮都"全面优化一遍"。

比如:

• 第一轮:优化颜色、字体、布局、动画、文案、交互
• 第二轮:再全部优化一遍,改得更细
• 第三轮:再来一遍

这样做的结果是——

1. 每一轮都在改很多东西,你根本判断不出"这一轮到底做到没做到"
2. 如果这一轮比上一轮糟糕,你不知道是哪个维度出了问题
3. AI 会被拖进"全局优化"的漩涡,什么都动一点,什么都不深
4. 你永远到不了"到位"的状态

正确的分轮 · 每轮打 1-2 个维度

把你要优化的维度列出来,每轮只打 1-2 个。

比如:

• 第一轮:只打"布局和节奏"
• 第二轮:只打"颜色和氛围"
• 第三轮:只打"动画时长和缓动"
• 第四轮:只打"细节收口"

每一轮,其他维度动都不要动。

为什么只打 1-2 个维度

可定位。只改一个维度,如果这一轮出问题,肯定是这个维度的问题。定位清晰。

可感知。只改一个维度,改完之后你对"这个维度的变化"感知最清晰。你能判断"好了还是没好"。全面改的话,所有维度同时变,你的感官会混乱。

可控。AI 在"只改这个维度"的约束下,会把这一个维度做到极致。不会跑偏。

可累积。每一轮都"锁定"了一个维度的到位状态。后面的轮次只在这个基础上加,不会回退。

怎么决定"先打哪个维度"

一个优先级指导:

顺序倒了会出问题——如果你先调氛围再调结构,氛围会白做,结构变了氛围全废。

每一轮的"范围锁定"

在 Brief 里明确写——

复制【本轮目标】
只优化 XX 维度

【本轮不允许做的事】
- 不要动其他维度
- 如果发现其他维度的问题,记录下来,下一轮处理

"记录下来,下一轮处理"——这句话很关键。

它不是让 AI 装看不见,而是让它把发现的问题暂存,而不是立刻处理。下一轮开始前,你和 COO 一起看看这个暂存列表,决定哪些进入下一轮。

什么时候停

分轮精修不是无限的。停的标志——

1. 这一轮改完,你的第一反应是"到位了"(不是"还可以再好")
2. 你愿意把它发给朋友看
3. 你开始觉得"再调下去是过度了"

到这三个信号之一出现,停。

超级个体最常见的错误——

新想法出来,直接全面铺开实现。等做完才发现"这个方向不对",返工整个项目。

时间、token、心力全都烧在"在错的方向上做得很完整"这件事上。

Demo 先行的做法

先做一个最小可验证的样本,跑起来看看体感,再决定要不要铺。

具体步骤:

1. 把新想法抽象成一个最小场景——不是整个页面,不是整个功能,就一个切面
2. 在那个切面上,做出完整的效果——不是半成品,是能真实感受的成品
3. 跑起来,看体感——不是看设计稿,是看实际运行的效果
4. 判断——如果体感对,铺开;体感不对,只扔掉这一个切面的工作,主项目没动

为什么这比"直接上"强

成本可控。Demo 切面的工作量是全面铺开的 1/10 甚至 1/50。如果方向错了,损失小。

判断准。体感判断只有看到实际效果才准,光看设计稿、光听描述,判断经常失灵。

迭代快。切面小,改一轮快。几轮下来很快就能收敛到"对的方向"。

保护主项目。主项目不被"未经验证的尝试"污染。

Demo 要"小"也要"完整"

Demo 的核心矛盾——要小,但也要完整。

• 太小——小到无法真正体现方向的气质,判断时会走样
• 太大——就不是 Demo 了,是半个项目,失去了"低成本验证"的意义

好的 Demo:小到只覆盖一个切面,完整到那个切面能真实代表最终效果。

Demo 之后的两种结果

结果一 · 方向对,可以铺

按 Demo 展现的效果,定为"基准",按基准铺到全站(参考 Ch.12 基准页策略)。

结果二 · 方向不对,丢掉

丢掉这一个 Demo,重新思考方向。不要心疼——Demo 的价值就是"让方向不对的成本变小"。

有一个常见的错误——

超级个体把所有东西都做成"转化漏斗":引导点击 → 引导注册 → 引导付费 → 引导分享。

结果产品没有灵魂,用户感到"一直被推着走",失去信任。

核心区分 · 流量逻辑 vs 价值逻辑

怎么判断某个部分用哪种逻辑

问自己一个问题:这个部分,我希望用户"往下走",还是"停下来"?

• "往下走"的部分(引导、转化、下一步) → 流量逻辑
• "停下来"的部分(体验、沉淀、创作) → 价值逻辑

一个产品可以同时有两种逻辑

好的产品,两种逻辑并存——

• 着陆页、注册流程、新手引导 → 流量逻辑
• 核心体验区、内容沉淀区、创作空间 → 价值逻辑

关键是每个部分知道自己是哪种逻辑,不要混淆。

阶段切换时,显式地"换挡"

项目发展到不同阶段,整体逻辑也会切换——

• 冷启动期:偏流量逻辑(先让人进来)
• 稳定期:偏价值逻辑(让留下的人真正获得价值)
• 增长期:回到流量逻辑(拉新)
• 成熟期:回到价值逻辑(深度服务)

每次切换,要显式换挡——告诉团队"我们从 A 逻辑进入 B 逻辑",否则旧逻辑的惯性会延续,新阶段用错打法。

这也是 Ch.30 阶段过渡协议 要讲的事。

团队工作到后期,一定会出现这种场景:

AI:"根据设计规范,这里应该叫 XX。"
你:"听起来就是不对。"
AI:"但规范就是这么定的。"

这个时候,你有两个选择:按规范走,或者按自己的感觉改。

为什么"体感优先"

你过去定规范时,可能:

• 还没看到实际效果
• 基于某个特定场景定的,其他场景不适用
• 抽象推演的,没有经过实测

当实际效果出现在你眼前,你此刻的感官判断,比你过去的抽象判断更准。

一个真实的例子

我和 Karma 的项目里,有一次关于产品命名的争论。

团队按行业惯例,给产品的一个核心场景取了一个"标准"名字——听起来专业、清晰、符合用户认知习惯。Karma 看了一眼,说:"不对。这个名字没有温度。"

团队困惑:"但行业里都这么叫啊。"

Karma 坚持换一个更有场景感、更有画面的名字。新名字在"专业度"上不如旧的,但在"气质"上完全不同——它让用户进入这个场景时,感觉像是走进了一个空间,而不是点击了一个功能。

一个名字的变化,改变了整个产品的感觉。

如果当时 Karma 屈服于"行业惯例",这个场景就会以一个"正确但没灵魂"的状态上线。

体感优先 ≠ 废除规范

这条原则不是"规范没用,想改就改"。它更精确的意思是:

规范是默认值。当默认值和实际体感冲突时,以实际体感为准。然后把规范更新成新的值。

也就是说:

• 平时按规范走(节省决策成本)
• 规范和体感冲突时,以体感为准(质量守门)
• 冲突结束后,规范要被更新(让下次少冲突)

规范不是一次性定的。它是不断被体感修正的活文档。

谁能做"体感优先"的决策

你(CEO)——毫无疑问。你的直觉就是标尺(Ch.1)。

COO 也可以——但需要更强的判断理由。因为 COO 本身也是翻译者,它的感官是二手的。

执行层 AI 不能——它们接到的是参数,不应该凭自己感觉擅自修改。如果它们觉得参数有问题,写进交付摘要里反馈,不要擅自改。

反面 · 什么时候"文档优先"

为了平衡——有一种情况应该"文档优先":

大量、重复、无审美判断必要的场景。

比如——代码里的命名规范、文档命名规范、数据格式规范、技术协议。这些规范不涉及"感觉对不对",只涉及"是否一致"。这类场景,坚持文档优先,能节省大量沟通成本。

超级个体会不断接触新工具。最常见的错误是——不经过"能力边界声明",就把新工具直接用在生产流程里。

结果是:用一个"验证工具"去做"生产工具"的事,用一个"草稿工具"去做"精修工具"的事,工具能力和任务需求错配,产生大量返工。

工具定位的两个问题

任何工具进入你的团队前,先强制回答两个问题:

一个典型的错位案例

一种常见的工具类型:"AI 快速生成原型"类工具。

它擅长:快速产出一个可视化原型,让你看到"大致是什么样"。

它不擅长:生产可部署的代码、细节打磨、和已有代码库集成。

但人们经常用它做后面那三件事,然后抱怨它"不够好用"——不是它不好用,是用错了。

如果在工具入团时就写清"这是概念验证工具,不是生产代码工具",就不会有这种错配。

工具定位表

建议给每个常用工具建一个简单的定位表,贴在项目文档里:

怎么判断一个工具的定位

观察两件事——

1. 它最顺手的时候是什么任务?那就是它擅长的
2. 它最别扭、返工最多的是什么任务?那就是它不擅长的

不要相信工具官方的"全能宣传"——每个工具都有自己的气质,没有"全能"的工具。

工具会进化,定位要更新

工具的能力边界不是静止的。新版本发布、新能力上线,定位会变。

每个阶段(通常 1-2 个月)重新审视一次定位表:"这个工具现在的定位,还适用吗?"

一条核心原则

当 AI 交付一个产出时,你会本能地看"做得好不好"。

但"好不好"太主观了。AI 会问你:"哪里不好?"你经常说不出来。

需要一套结构化的审查流程,让"好不好"变成可判断的问题。

三步审查,就是这套结构。

第一步 · 越界检查

问:这次交付有没有动不该动的东西?

Brief 里写了"只做 A,不要动 B 和 C"。但 AI 在实际执行时,有可能:

• 改了 B(它觉得顺手优化一下)
• 动了 C(它觉得不改会不一致)
• 加了 D(Brief 里根本没提的东西)

越界检查就是先看:交付物里有没有超出 Brief 范围的改动?

做法:

1. 把 Brief 里的"允许做"和"不允许做"列出来
2. 对照交付物,逐条确认
3. 发现越界的,退回,要求还原——不要通融

为什么不通融?因为一旦你对越界睁一只眼闭一只眼,AI 会慢慢把"越界"当作默认选项。下次越界会越来越多。

这是执行纪律的第一条防线。

第二步 · 维度平衡检查

问:各个维度是不是平衡的?有没有哪个维度被过度强调,哪个被忽略?

一个好的产出,应该在多个维度上达到平衡:

• 功能性 vs 美感
• 信息密度 vs 留白
• 视觉冲击 vs 阅读舒适
• 创新性 vs 稳定性
• 细节精致 vs 整体节奏

如果某个维度被做得特别强,其他维度相对弱了,整体就会失衡。

失衡的产出,往往单看某一处"很惊艳",但整体"不对劲"。

做法:

1. 列出这次交付涉及的主要维度
2. 对每个维度打一个粗略分(高 / 中 / 低)
3. 看分数分布——是不是"所有维度都在中高",还是"某些高某些低"?
4. 失衡时,指出具体哪个维度过强、哪个过弱

第三步 · 过度风险检查

问:有没有地方用力过猛了?

这是最难的一步,因为"过度"往往伪装成"认真"。

典型的过度:

• 动画太多,每个元素都在动
• 特效太炫,盖过了核心信息
• 文案太用力,每句话都想打动人
• 功能太多,用户被选项淹没

过度的产出,会让用户感到"累"。

做法:

1. 问自己:"如果去掉 XX,会不会更好?"
2. 问 AI:"你觉得这次交付里,哪一处是可以去掉的?"
3. 列出所有"可以去掉但 AI 自己不会去掉"的东西
4. 决定去掉哪些

三步的顺序不能颠倒

越界 → 平衡 → 过度。

为什么?

• 越界是客观的——有 Brief 做标尺,清晰可判。先过这关,防止乱动
• 平衡是半主观的——需要审美判断,但有可对照的维度
• 过度是最主观的——最考验审美功力,放最后

如果颠倒顺序:

• 先看"过度"——你会被细节吸引,忘记看有没有越界
• 先看"平衡"——没排除越界的情况下,平衡感受是被污染的

大多数项目上线时,只问一个问题:"能用吗?"

这个问题太单薄。

真正的产品质量,要看三层——

第一层 · 可用(Usable)

最基础的一层。功能跑得起来、没有 bug、用户能完成他想做的事。

大多数项目能做到这一层。

但停在这一层的项目,上线之后通常只有第一波朋友圈流量,然后就沉寂了——因为它"能用"但"没味道",用户没有回来的理由。

第二层 · 可感(Perceivable)

项目的气质真的被用户感受到——不是你说"我的产品有气质",而是用户打开第一秒就能感到"这个东西不一样"。

可感的检验:给一个朋友看,问"你第一感觉是什么?"

• 如果 ta 说"挺好用的"——停在第一层
• 如果 ta 说"感觉挺舒服 / 挺特别 / 挺高级的"——进入第二层
• 如果 ta 说"我想多看看"——已经在走向第三层

可感层,是"场域产品"和"功能产品"的分界线。

第三层 · 可留(Retainable)

最高层。用户不仅一次性体验得好,还愿意回来。

可留是一种综合指标——它不是"易用性"的延伸,是"价值感"的累积。

可留的检验:两周后这个用户还在用吗?两个月后呢?

大多数项目做到"可用"就上线,永远不到"可感";少数做到"可感",极少数能到"可留"。

三层的关系

可用是地基。没有可用,一切都塌。

可感是骨架。有了可感,项目有了"长相"。

可留是血肉。有了可留,项目有了"生命"。

做项目时不能跳层——可用没做好就想可感、可感没做好就想可留,都会失败。

什么时候启用三层框架

内测之前——强制过一遍三层,不到位不上线。

每次重大迭代——新版本是否在三层上都保持?

用户反馈时——用户说"这里不好",先判断他在哪一层反馈,针对性解决。

三层的常见陷阱

陷阱一 · 跳过可用做可感。先追求炫酷视觉,结果基本功能都跑不顺。用户看一眼就跑了。

陷阱二 · 以为可感是"视觉漂亮"。不是。可感是"气质被感受到"——一个极简的文本页,也能可感,前提是它有独特的气质。

陷阱三 · 以为可留等于"用户粘性"。不是。可留是"用户主动想回来",不是"用户被留住"。这两个有本质区别。

Ch.3 说"真相源要唯一"。但现实里一个项目会有多个真相源——PRD、Brief、文案表、设计规范、代码、对话记录。它们可能不一致。

冲突时怎么办?必须有明确的优先级,不然每次冲突都要重新判断一遍,效率极低。

一个推荐的优先级

为什么是这个顺序

核心原则——越"此刻"、越"锁定",优先级越高。

• Lock 是最"此刻"的——它就是"现在该做什么"的标准答案
• Brief 是次"此刻"的——它是本次任务的指令
• 文档是"过去的约定"——已经写好的规范
• 代码是"过去的实现"——可能已经过时
• 对话是"曾经的讨论"——没被沉淀进文档的都不算真相

一个真实场景

假设你在做一个页面,遇到这样的冲突——

• Lock 文件说:这个按钮用朱砂红
• Brief说:这个按钮用朱砂红
• 设计规范说:主按钮用钛青蓝
• 旧代码里这个按钮是钛青蓝
• 上周对话里 CEO 提过"也许试试深紫"

按优先级:朱砂红。不需要再讨论。Lock 和 Brief 都是朱砂红,它们的优先级最高。

规范和旧代码是"过去的",对话是"临时的"——都被高优先级的"此刻"真相覆盖。

优先级冲突的处理流程

1. 发现冲突 → 停下,不要猜
2. 按优先级找最高层的那份
3. 以它为准
4. 在交付摘要里说明:"我按 Lock 文件做了 XX,忽略了规范和旧代码的 YY"
5. COO Review 时,决定是否要更新低优先级的文档,让它们对齐

优先级要写进真相源

这份优先级本身,也是真相源的一部分。建议写在项目 L1 文档的第一页,让所有 AI 都能看到:

"本项目真相源优先级:
Lock > Brief > 文案表 / 规范 > 主文档 > 代码 > 对话。
冲突时按此顺序判断。"

有时候你会遇到这种情况——

你对某个决策不确定。你问 COO,COO 说"方案 A"。你问 PM,PM 也说"方案 A"。你问一个外部朋友,朋友也说"方案 A"。

这三个"方案 A"的价值,不是简单相加。它们的置信度是相乘的。

什么叫"独立汇合"

独立的意思是——

• 几个判断源彼此不知道对方的结论
• 它们基于不同的视角 / 角色 / 信息做判断
• 它们没有互相影响的路径

汇合的意思是——它们独立推演后,得出了相同的结论。

这和"三个人一起讨论出结论"完全不同。一起讨论,是互相影响后的共识;独立汇合,是各自独立推导后的一致。

为什么"独立汇合"这么强

想象你在判断一个问题,两个可能的答案 A 和 B。

如果一个视角说"A",它可能有 70% 的正确率。

两个完全独立的视角都说"A",假设都有 70% 的独立正确率,那么两个都说 A 但实际是 B 的概率,只有 9%(两个独立错判)。

三个独立视角都说"A",三个都错判的概率只有 2.7%。

怎么利用多源汇合

重大决策之前,不要只问一个人(AI)。

问三个独立视角的人(AI)——

• 问 COO(战略视角)
• 问 PM / QA(用户视角)
• 问外部朋友(局外视角)

关键操作——不要让后问的人看到前面人的答案。

如果三个视角汇合,置信度高,执行。
如果三个视角分歧,说明问题本身复杂,需要更多信息再判断。

汇合的反面 · 独立分歧

如果独立视角之间出现分歧——

• 不要简单投票——多数不等于对
• 分析分歧的来源——是因为信息不同?视角不同?价值观不同?
• 让他们看彼此的理由,再独立重新判断
• 如果还是分歧,说明这是个真正需要 CEO 最终拍板的决策

不同类型的汇合

一 · 跨视角汇合

流程视角 + 用户视角 + 品牌视角,都同意一个结论——最高置信度。

二 · 跨模型汇合

Claude + ChatGPT + Gemini,独立问同一个问题,得到同样答案——置信度高。

三 · 跨时间汇合

一个月前的判断、一周前的判断、此刻的判断——都指向同一个方向,说明这个判断经得起时间。

一条实用的原则

这和 Ch.23 的"平均值陷阱" 听起来矛盾——一个说融合是陷阱,一个说多源是优势。不矛盾:多个 AI 各自独立判断再汇合是优势;一个 AI 面对多个冲突输入自己揉合是陷阱。前者是"多个视角",后者是"一个糊状输出"。

项目跑到后期,有一个隐蔽的敌人——气质回落。

它不是突然的崩塌,是渐进的钝化。每一次"差不多就行"都在侵蚀品质,但每一次单独看都觉得"无伤大雅"。等你回头看,项目已经不是最初那个气质了。

气质回落的典型症状

自检——你的项目有这些症状吗?

• 你开始放过一些"最初绝不会放过"的东西
• 交付开始出现"差不多就行"的心态
• 团队(包括你)对新增功能的审美感官变迟钝
• 新做的部分,和基准页比,明显"没那么有气质"
• 用"快要上线了"作为通融的理由
• 对一些已经看过很多遍的东西,不再有"第一眼感觉"

任何一条出现,都是黄灯。多条出现,是红灯。

为什么会回落

疲惫。项目做久了,人的审美敏锐度会钝。

时间压力。"快要上线了 / 快要交付了"会让你不自觉降低标准。

标准钝化。天天看同一个东西,你的"第一眼感觉"消失了,你不再能感知它的问题。

AI 的讨好倾向。AI 会慢慢适应"你通常会通过什么",它的交付也会慢慢变得只够过关。

这些原因加在一起,形成一股向下的力。必须主动抵抗。

防御策略一 · 红线机制

在项目一开始,定一些"不管多累多紧都不能越过"的红线。比如:

• 不发朋友都不愿意看的东西
• 文案里不允许出现某些词
• 任何页面必须通过 QA 三层的前两层

红线的作用:在标准钝化时,给你一个绝对的下限。

防御策略二 · 定期回看审美参照

每周或每个里程碑,强制自己看一次最初定的审美参照。

回看的作用:刷新你的"第一眼感觉",校准已经漂移的标准。

防御策略三 · 第三方视角注入

每过一段时间,找一个项目外的人(朋友、同事、甚至新的 AI)看看项目,给你反馈。

第三方视角的价值:他没有钝化。他的第一眼感觉,就是用户的第一眼感觉。

防御策略四 · 阶段性审计

每个里程碑,做一次全项目的"三步审查"(Ch.18)——不是增量审查,是全量审查。

这能发现"分散看不出,汇总起来明显"的问题。

防御策略五 · 允许"完成但不结束"

有时候你觉得"做完了",但其实只是累了。

允许自己标注"完成但不结束"——现在可以上线,但保留"回来再改"的权利。

这比"强行认为完成了"更诚实,也更让你留有余地。

气质回落的反面 · 过度打磨

要警惕,但不要被"气质回落"吓到无限优化。

过度打磨和气质回落,是两个极端。中间有一个"到位即止"的最优点——你的三个信号出现时(Ch.13),就该停。

想象一下这个场景——

你有一个项目。项目里有:

• 三个月前的 PRD
• 两个月前的设计稿
• 上周的需求更新
• 昨天的对话记录
• 今天的 Brief

你把这些全部甩给一个 AI,让它"基于以上信息,完成 XX 任务"。

AI 会怎么做?

它会"综合理解"这些信息,然后做出一个"平均版本"。

平均版本是什么

不是最新的(它没把旧的丢掉)。
不是最旧的(它也没完全忽视新的)。
不是某一版的忠实执行(它不知道该忠实于哪一版)。

是一个"揉合了所有信息,但哪一版都不是"的东西。

这个东西有个特点:看起来都对,但任何单一标准下都不够到位。

• 对照最新 Brief,它差一点
• 对照原始设计稿,它也差一点
• 对照一个月前的需求,它还是差一点

为什么会这样

AI 有一个天然倾向:面对冲突的输入,它会寻找"共同点",而不是"判断优先级"。

这不是它的错。它被训练成"尽量让所有输入都被照顾到",而不是"果断取舍"。

所以当你给它多个信息源时,它的默认行为是融合,不是选择。

结果就是——你的项目变成一个"所有人都满意但所有标准都没达到"的平均版本。

平均值陷阱的症状

如果你发现项目出现以下情况,多半是掉进了这个陷阱——

• 永远差那么一点——每次交付都"挺好的,但不完全到位",反复改也改不彻底
• AI 在解释的时候引用多个版本——它说"根据 A 文档 + B 对话 + C 设计稿,我做了..."——这是平均值的典型特征
• 交付里夹带了"不该有"的东西——明明 Brief 里没提,但产出里带着某些细节——这些细节来自旧文档
• 和最新指示对齐的过程反复出现——你不断说"不对,按最新的来",但下一次交付还是出现旧版痕迹

为什么这是"最隐蔽"的失败模式

因为它看起来像是合理的,其实是系统性的错位。

大多数 AI 失败是明显的——输出错了一个参数、理解偏了一个需求、做错了一个功能——都能发现。

但平均值陷阱不是这样。它的输出"看起来对",只是"每个维度都差一点"。你可能几轮都发现不了问题在哪,只觉得"为什么就是不到位"。

等你发现时,已经浪费了大量时间。

怎么避开这个陷阱

第一条 · 锁死真相源优先级(Ch.20)

明确告诉 AI:"这份 Lock 文件是最高优先级。其他所有信息都是参考,冲突时忽略。"优先级越清晰,AI 越不容易融合。

第二条 · 在 Brief 里加硬约束

明确写——

"本任务只按 XX 文件执行。不要参考 YY、ZZ 等历史文档。如果你发现冲突信息,以 XX 为准并忽略其他。"

这一条一旦写明,AI 的"融合倾向"会被压制。

第三条 · 归档过时信息

不要让过时文档躺在"当前工作目录"里。明确分离——当前工作区只放有效的真相源,归档区放所有历史版本但标注"已过时,仅供溯源"。AI 看到"归档"标识,会自动降低它的权重。

第四条 · 在关键任务前做一次"上下文清场"

重要任务开始前,明确告诉 AI——

"忘掉之前所有讨论。只看这份 Brief + 这份 Lock 文件。从零开始。"

这听起来极端,但对高风险任务非常必要。

平均值陷阱 vs 独立评估

这一章讲的平均值陷阱,和 Ch.21"多源独立汇合" 听起来矛盾——一个说融合是陷阱,一个说多源是优势。

其实不矛盾。关键在"独立性"——

• 独立评估:多个 AI 各自独立判断,汇合时有独立价值
• 平均值陷阱:一个 AI 面对多个冲突信息源,自己揉合出一个平均版本

这本书做的过程中,其实也踩过一次平均值陷阱的反面——有一个 bug 我连修两次都没修好,因为我每次都是"在旧代码上加新规则",而不是"删掉那条冲突的旧规则"。直到被问第三次"到底修没修好",才回头真正定位到病根。一本讲平均值陷阱的书,自己也可能掉进去。

多 Agent 协作中,换手是一定会发生的事——

• 一个 AI 的 context 满了,要换一个新 session
• 一个角色要从 A 平台换到 B 平台
• 一个 AI 的订阅用完了,要让另一个顶上
• 某个任务要从 CTO 流转到 CMO

每一次换手,都是信息丢失的风险点。

如果没有协议,换手之后——新 AI 不知道之前发生了什么、新 AI 重复之前已经做过的工作、新 AI 做出和之前决策相反的选择、项目积累的经验丢失。

交接包的定义

交接包 = 一份让新 AI 能无损接手的结构化文档。

它不是"对话记录"(那太长、太乱)。
它不是"最终产出"(那不包含过程)。
它是一份专门为"让下一棒能接住"而写的文档。

交接包应该包含什么

"不可漂移项"为什么最关键

换手最大的风险不是"不知道做什么",是"重新讨论已经决定过的事"。

新 AI 很容易在接手时觉得"我来看看这些决策是不是都对"——然后把已经锁定的东西重新拉出来讨论。这会:

• 浪费大量时间
• 可能推翻正确的决策
• 让项目陷入反复

"不可漂移项"就是明确告诉新 AI:"这些,不要再讨论了。直接在这个基础上做。"

这一条,能救回项目几天的时间。

交接包谁来写

上一棒自己写。

不是 COO 替它写,不是 CEO 替它写——上一棒最了解自己做了什么、踩过哪些坑,它来写最准确。

写好后,COO 做一次 Review,确保完整。然后交给新 AI。

交接包的格式

保持短。

一份好的交接包,控制在 800-1500 字左右。太长没人读,太短信息不够。

用标题分区,每个部分简短清晰。

最忌:写成流水账对话记录的复述——那不叫交接包,那叫"甩锅"。

交接之后的"校验"

新 AI 接手后,做一件事:用交接包里的信息,复述它对任务的理解。

格式类似——

"基于交接包,我理解:
· 任务是 XX
· 已经完成 YY
· 不可漂移项是 ZZ
· 我下一步打算做 AA
请确认我的理解是否正确。"

这一步确认,让 COO 能抓到"新 AI 理解偏差"——早发现、早纠正。

你现在看到的这本书,就是用这套协议写出来的。写作过程中换过好几次 AI 实例、跨过不同模型版本,每次换手都用交接包。协议有效。

多 Agent 协作最容易发生的一种混乱——

两个 AI 同时在改同一个东西。

可能是:

• 两个 AI 同时在编辑同一份文档
• 两个 AI 同时在写同一段代码
• 两个 AI 同时在做同一个决策

结果是——互相覆盖、版本冲突、最后不知道哪个是"真的"、大量时间花在 merge 上,而不是真正的工作上。

单写者规则,就是来防这件事的。

规则的核心

其他所有角色,对这件事来说,都是读者——可以读、可以反馈、可以建议,但不能写。

想改?先让现在的写者停下,再接手。

为什么必须这么严

有人会说:"我们协作,边讨论边改,效率更高嘛。"

这个想法对人类团队可能成立(因为人可以同步沟通)。对 AI 团队彻底不成立——

• AI 之间没有真正的"同步感知"——它们不知道对方正在改什么
• AI 的改动是"全量替换"——不是像人那样逐行插入,是生成整段
• 冲突时,后写的会覆盖前写的,前面的工作直接消失

所以对 AI 协作,单写者是铁律,不是推荐。

单写者规则的应用

文档层面

同一份 Lock 文件、同一份真相源文档、同一份设计规范——同一时间只有一个角色在改。其他角色要改,提 Issue 给写者。

代码层面

同一个文件、同一个函数——同一时间只有一个 AI 在改。双 CTO 协作时,必须通过 commit + push 机制明确"现在谁有写权限"。

决策层面

同一个决策——CEO 拍板之前,只有一个角色(通常是 COO)在推进判断。不要让多个角色同时推演"这个决策该怎么做"。

切换写者的流程

当写者需要换人时,按这个流程:

1. 当前写者 commit / 交付——把当前状态提交,标记"完成"或"暂停"
2. 当前写者释放写权限——明确说"我不再改 X 了"
3. 新写者获取写权限——明确说"从现在起,X 由我负责"
4. COO 记录切换——在项目日志里标注"写者从 A 换到 B"
5. 新写者开始工作

这五步看起来繁琐,但每一步省了,就会出 merge 冲突。

双 CTO、双 CMO 的协作

项目里经常会有两个同角色的 AI 实例(比如两个 CTO,分别在不同平台)。它们怎么协作?

核心原则——按任务划分写权限,而不是按角色。

• CTO-A 负责"前端模块",CTO-B 负责"后端模块"——两个不同的写权限区域
• CTO-A 暂停时,CTO-B 可以接手"前端模块",但要按切换流程走
• 不允许两个 CTO 同时碰"前端模块"

违反后果

一旦违反单写者规则——

• 最好的情况:发现冲突,花时间 merge
• 中等情况:一个人的工作被覆盖,重做
• 最坏情况:改动叠加出一个"谁都没做过的状态",看起来能跑但完全不可控

前面几章反复提到 Lock 文件。这一章详细讲它是什么、怎么用。

Lock 文件解决的问题

项目跑久了,文档会越来越多——

• PRD 第一版、第二版、第三版
• Brief 第一次、第二次、第三次
• 设计稿迭代过 N 轮
• 对话记录积累成堆

AI 面对这些材料,容易"综合理解"(就是 Ch.23 里讲的平均值陷阱)。

Lock 文件就是来破这个问题的——

Lock 文件的核心特点

Lock 文件里写什么

一份好的 Lock 文件,应该包含五部分:

1. 当前阶段的目标——这个 Lock 是为了什么阶段?阶段的核心目标是什么?
2. 当前要做的事(What)——具体要完成哪些交付?每个交付的验收标准?
3. 明确不做的事(What NOT)——哪些事情这个阶段不要做?哪些是已经被决定"先不动"的?
4. 关键参数 / 决策——这个阶段已经锁定的具体参数(动画时长、色值、文案、接口等)。这些不需要 AI 再思考,直接用就行。
5. 本阶段的时间边界——这个 Lock 到什么时候有效?到期后,是更新还是废弃?

Lock 文件的生命周期

Lock 不是一写定终身的。它有生命周期:

关键:不能"悄悄更新"。每次更新都要走流程——谁提议 → CEO 确认 → 新版本生效 → 所有 AI 被通知。

没有 Lock 的项目会发生什么

项目没有 Lock 的时候——

• 每个 AI 接到任务时,自己去"综合理解"所有历史文档
• 每个 AI 的理解都略有不同
• 交付物五花八门——每个 AI 都觉得自己做的对,但对齐不上
• CEO 要反复去解释"现在到底要做什么"
• 整个团队在内耗自己

有了 Lock 之后,这些问题一夜之间消失。

因为所有 AI 看的是同一份文档,理解自然是同步的。

执行层 AI 的铁律

当执行层 AI(CTO、CMO 等)接到任务时,第一件事永远是——

"打开当前 Lock 文件,确认本次任务在 Lock 范围内。"

如果任务在 Lock 范围内 → 按 Lock 执行。
如果任务在 Lock 范围外 → 停下,问 COO:"这超出了 Lock,你确认要做吗?"

不允许:

• "自作主张"超出 Lock 去做
• "顺手"做一些 Lock 没说的事
• 基于"我觉得 Lock 可能漏了"的猜测去延伸

这一章的灵感来自《哥德尔、埃舍尔、巴赫》——一本关于"自指、嵌套、分形"的书。

一个好的项目文档系统,也应该是分形的:每一层都包含"下一层在哪"的信息,让任何时候从任何一层开始,都能找到全貌。

三层文档结构

为什么是三层,不是一层

一层全写在 README 里?——太长,没人读完。

不写文档?——AI 每次都得重新理解项目,效率极低。

三层的好处——每一层都简短,但环环相扣。任何层单独看都不累,合起来是完整的。

铁律 · 改内容,必须同步文档

你改了某个模块的结构 → 同步更新 L2。
你改了某个文件的职责 → 同步更新 L3 头部注释。
你加了新模块 → 同步更新 L1。

做不到这一条,前面所有结构都白搭。

分形在哪里

你会发现——L1 是项目的地图,L2 是模块的"L1",L3 是文件的"L1"。每一层的结构都是相似的——"告诉我这里是什么,以及去哪里找下一层"。

这就是"分形"——同一种结构,在不同尺度上重复。

这本书本身也是分形的——每一章有"一句话说清"(L3 契约)、每个部分有导引(L2 地图)、整本书有前言和目录(L1 总图)。读到这里你应该已经感受到这种设计。

Ch.27 讲的是"文档的分形结构",这一章讲的是"信息应该存放在哪"。

三层是什么

各层的职责边界

协作层:变化最快,可以乱、可以讨论、可以试错。

版本层:严格有序,每次变更都要经过流程(commit / PR),是最可靠的。

记忆层:相对稳定,不常改,但改了之后长期影响所有对话。

三层的配合

一个决策的完整流动——

1. 协作层讨论(在 Notion 里讨论"要不要改 X")
2. 决定之后,COO 写成明确的决策
3. 版本层落地(代码 / 文档变更走 GitHub PR)
4. 如果是长期影响的决策,更新记忆层(让未来所有对话都知道)

最常见的错位

把重要决策只留在协作层的讨论记录里。一周后你自己都找不到。

把临时讨论塞进版本层。污染版本历史。

让记忆层过时。AI 根据旧记忆做决策,全乱套。

你有没有过这种体验——

三个月前你写过一份重要文档,现在要找它。你记得"好像有这么个东西",但文件名叫什么?不记得。打开文件夹,几十个文件躺在那里——"最终版"、"最终版2"、"真的最终版"、"我的版本"、"老板的版本"——你无法判断哪个是当前应该用的。

这就是没有命名规范的代价。

推荐的命名模板

复制{项目名}_{文件类型}_{主题}_v{版本号}_{YYYYMMDD}.md

例如:

• KarmaOS_PRD_五角色模型_v1.2_20260418.md
• BonFire_Brief_着陆页精修_v2.0_20260315.md

文件类型常用缩写

PRD(产品需求文档)· Brief(任务简报)· Lock(当前锁定真相)· 规范(设计 / 技术规范)· 交接包(换手交接文档)· 文案(文案表)· 复盘(项目复盘)

版本号规则

用"主版本.次版本"——如 v1.3。

• 主版本变(v1 → v2)= 结构性大改
• 次版本变(v1.0 → v1.1)= 细节调整

禁忌

• 「最终版」「最新版」「真的最终版」——永远不是最终版
• 「我的」「老板的」——谁都没法找
• 空格、特殊字符——用下划线 _
• 文件名超过 80 字符

目录结构模板

复制00_CURRENT/     ← 当前工作(永远在最上面)
01_PRD/
02_DESIGN/
03_COPY/
04_TECH/
05_HANDOFF/
06_ARCHIVE/     ← 过时文件归档,不删除

为什么用数字前缀?文件管理器会按数字排序,"当前工作"永远在最上面,"归档"永远在最下面,和直觉一致。

为什么过时不删除?因为有时候你要追溯"为什么当初那么做",归档让信息可查但不污染当前视野。

项目在不同阶段,需要的东西完全不同——

• 0→MVP 阶段:快速迭代、容忍不完美、先跑通再打磨
• MVP→内测:稳定性优先、打磨细节、用户反馈导向
• 内测→公测:扩容、稳定、性能优化
• 公测→增长:转化漏斗、用户留存、增长实验

每个阶段的打法完全不同。如果不显式"换挡",旧阶段的节奏会惯性延续到新阶段——结果是打法错位,效率和质量都塌。

阶段过渡的六步流程

阶段过渡 vs 气质回落

看起来相似,但本质不同——

• 阶段过渡:主动的换挡,有意识地调整
• 气质回落(见 Ch.22):被动的滑坡,无意识地降级

主动做过渡,能防止被动的回落。没有清晰的阶段过渡,团队就会慢慢陷入"不知道现在要做什么"的状态,质量自然下滑。

什么时候该过渡

信号——

• 核心目标接近达成(需要进入下一阶段)
• 团队对当前任务已经熟练到边际收益下降
• 遇到了只有"进入下一阶段"才能解决的问题
• 外部情况变化,原阶段的假设不再成立

Token 有限。模型有价格差。如果你用最强模型做所有任务——高价值的任务做好了,但低价值任务把预算烧光了。

正确的方法是——把任务分层,按价值匹配模型。

任务价值的三层

错误的两种做法

错法一 · 什么都用最强的。浪费额度,关键时刻没预算。

错法二 · 什么都用最便宜的。低效,重要决策做不好,看起来省钱实际返工更贵。

怎么判断任务价值

问两个问题——

1. 这个任务的决策影响有多大?影响项目方向 = 高;影响某个细节 = 中;影响一个格式 = 低
2. 如果这个任务做错了,代价有多大?代价大 → 上更强模型

一个实用的分配原则

这符合帕累托法则——少数任务决定项目成败,多数任务是常规执行。

和 AI 对话时,有一个常见的错误——一个对话窗口开很久。

你可能觉得"对话长 = AI 对我的项目理解越深"——不对。

对话长 = context 臃肿 = AI 的注意力被稀释 = 回答质量下降。

Context 的四个阶段

核心策略 · 用文档替代长对话

不要依赖"AI 记得我们上次说过 X"。

把关键决策、状态、约定写进文档——

• 决策写进真相源
• 状态写进 Lock 文件
• 约定写进审美词典

这样做之后,对话里只需要讨论"当前任务"。切 context 时,新对话读文档就能恢复状态。

什么时候切 context

• 进入臃肿期——感觉 AI 在重复问已经答过的问题,或者记不清早期决策
• 换任务类型——从"设计讨论"换到"技术实现",开新对话
• 一个大任务完成——写交接包,开新对话继续下一个
• 每周例行——不管有没有必要,每周切一次,强制清理

切 context 的流程

1. 当前 AI 写交接包(Ch.24)
2. 更新真相源
3. 开新对话
4. 新 AI 读交接包 + 真相源
5. 复述确认
6. 继续工作

一个常见的误区——把所有 AI 角色都放在同一个平台(比如全用 Claude、全用 ChatGPT)。

结果:那个平台出问题的时候,整个团队瘫痪。或者某个订阅额度用完,项目卡住。

为什么跨平台是"必须"而非"可选"

一 · 能力互补

每个平台都有强项和弱项。全用一家,你会在它的弱点上集体受损。

二 · 风险分散

某个订阅额度用完、某个平台临时故障、某个模型的某个版本突然变差——跨平台部署,其他角色还能工作。

三 · 气质多样性

同一平台所有 AI 会有相似的"训练偏好"——审美、语言习惯、判断倾向。多平台组合带来天然的视角多样性(参考 Ch.21 多源独立汇合)。

一个推荐的分配模式

(仅作参考,按你实际能接触到的订阅组合调整)

跨平台的代价

跨平台不是免费的,它有成本——

• 切换摩擦——你要在不同平台间切换,认知负担加大
• 同步成本——不同平台的 AI 要靠文档对齐,不能直接对话
• 订阅开销——多个订阅意味着多份钱

但这些代价远小于"全部在一个平台的风险"。

分配原则

• 主力不超过 50% 集中——单平台不要承担超过半数核心角色
• COO 和 CTO 最好不在同一平台——这两个是关键路径,分散风险
• PM/QA 和 CMO 再分到另外平台——形成三大区块

再好的规划,也有意外。

Token 突然用完、平台突然故障、你预期的 AI 突然不可用——这些都会发生。

成熟的项目,不是"永远不出意外",是"出意外时能优雅应对"。

三个等级的应急状态

降级的核心动作

1. 明确当前处于哪个等级——不要装作"还行"
2. 执行对应的预案——不要临时想
3. 通知团队所有 AI——我们进入 X 级应急
4. 记录应急期发生的事——事后复盘

最重要的预防 · 文档化

一个有完整文档资产的项目,Token 告罄时不会停摆——

• Lock 文件在
• 真相源在
• 交接包在
• 审美词典在

只要这些文档在,任何时候开新对话,项目都能无缝继续。

提前做好降级预案

不要等出事了才想。项目启动时就写好——

复制【黄色降级预案】
触发条件:主力平台额度 < 20%
执行动作:
1. 暂停非核心任务
2. 切换到备用平台 X
3. 重写 Lock,标明"黄色降级期"

【橙色应急预案】
触发条件:主力平台完全不可用
执行动作:
1. 所有非关键任务停下
2. CEO 亲自承担部分 COO 工作
3. 切换到备用平台,接受能力降级

【红色文档期预案】
触发条件:多资源同时告罄
执行动作:
1. 停止一切新 token 消耗
2. 进入"只改文档、不改产出"模式
3. 等待资源恢复

token 告罄 ≠ 项目停摆

这是这一章最核心的一句——

这本书前面讲了很多方法论。但如果你是刚拿到这本书、要启动第一个项目的超级个体,你最需要的是一张可以立刻照着走的清单。

这一章就是那张清单。

第一天 · 启动清单(按顺序走)

时间预算

上面九步,应该能在一个半天内做完。

如果你觉得"花这么多时间在准备上,不如直接开干"——你错了。

启动后一周的验证

启动后一周,检查——

• 团队知道自己是什么角色吗?
• 真相源被使用了吗?(而不是被搁置)
• Lock 被遵守了吗?
• Hub-and-Spoke 没有被绕过吗?

任何一项没到位,回去补。不要带着漏洞进入下一周。

项目中期,经常需要加入新的 AI 成员——可能是换 context 后的新实例、可能是新角色、可能是现有角色的备份。

新 AI 进来后,"马上干活"几乎总是失败。需要一个接入流程。

四步接入流程

常见错误

省略第一步。新 AI 直接开干,它根本不知道项目背景,产出必然不对味。

省略第二步。你以为它懂了,它以为它懂了,两个人不在同一频道,几天后发现巨大偏差。

省略第三步。直接给它核心任务,万一它理解偏了,核心任务废了。

结果:"新 AI 进来一周了还在磨合"——不是它能力不足,是流程缺失。

时间预算

四步走完,一般需要 2-3 小时(包括它读文档、复述、做小任务的时间)。

这 2-3 小时,能让它在正式工作时避免大量返工。划算。

这是所有超级个体都会遇到的场景——

• AI 的 context 突然满了
• 订阅额度用完了
• 平台临时故障
• 你自己忘了项目做到哪了

上下文丢失,但项目不能停。

恢复流程 · 四步

1. 找到四份核心文档
   • L1 项目地图
   • 当前 Lock
   • 最新交接包
   • 审美词典
2. 开新对话,让 AI 读这四份文档
3. 让 AI 复述确认——它现在理解的状态、下一步要做什么
4. 确认无误后,继续工作

整个流程,30 分钟以内能完成。

前提 · 文档资产必须存在

这个流程能跑,前提是——你平时就在维护这四份文档。

如果没有,恢复就是"重新开始"——痛苦但不至于失败。

如果有,恢复就是"重新加载"——无缝衔接。

这本书本身,就是一份恢复流程实例

每一章有"一句话说清"作为 L3 契约
每个部分有导引作为 L2 地图
整本书作为 L1 全局地图
附录 A/B/C 作为模板库
附录 D 作为故障排查

读完这本书的新 AI——天然就能接住项目。

这不是巧合。这是一本关于"分形文档"的书,自己也是一个分形文档。

最后的话

这是正文最后一章。

如果你认真读到了这里——你已经有了一个完整的操作系统。剩下的,只是开始用它。

后面的附录是速查手册,遇到具体问题时翻回来查就行。

去做吧。

每次给 AI 下任务时，按这个格式写。
模板的核心是那个带星号的“不允许做”字段——它是让 AI 不漂移的关键。

复制【任务目标】
做什么（一句话）：
为什么做（一两句话）：

【交付物】
具体要产出什么（列清单）：
- 交付物 1
- 交付物 2

【优先级】
🔴 紧急 / 🟡 本周 / 🟢 不急

【依赖关系】
这个任务依赖什么（其他任务/文档/决策）：

【参考信息】
上游交付摘要 / 设计稿 / 文档链接：

【本轮不允许做的事】⭐
- 不要碰 XX
- 不要改 YY
- 不要自主添加 ZZ
- 发现超出范围的问题，只记录，不处理

【交付格式要求】
要 diff / 要完整文件 / 要列表 / 要说明 / 要附交付摘要

“不允许做” 的三原则

1. 具体，不抽象。不要写“不要过度设计”——写“不要新增任何动画效果，不要改现有颜色，不要增加新的组件”
2. 覆盖 AI 最容易手痒的地方。重构代码、优化变量名、添加注释、调整格式——这些是 AI 的常见陷阱
3. 留一个“发现问题怎么办”的通道。不是装看不见，而是“记录下来，不处理”

配合阅读：
Ch.9 Brief 硬约束机制 · Ch.26 Lock 文件机制

每次交付（无论大小）都附一份。不超过 150 字。

复制【做了什么】
一句话，不超过 30 字。

【关键决策】
选了什么？为什么选 A 不选 B？
（无关键决策写「无」）

【已知限制】
我知道的、但没解决的问题。
（无已知限制写「无」）

【下一步建议】
基于我的理解，建议下一步做什么。
（COO 可采纳可不采纳）

配合阅读：Ch.10 交付摘要契约

命名模板

复制{项目名}_{文件类型}_{主题}_v{版本号}_{YYYYMMDD}.md

文件类型常用缩写

PRD（产品需求文档）、Brief（任务简报）、Lock（当前锁定真相）、规范（设计/技术规范)、交接包（换手交接文档)、文案（文案表)、复盘（项目复盘)

版本号规则

主版本。次版本（如 v1.3)。主版本变 = 结构性大改；次版本变 = 细节调整。

禁忌

• 「最终版」「最新版」「真的最终版」——永远不是最终版
• 「我的」「老板的」——谁都没法找
• 空格、特殊字符——用下划线 _
• 文件名超过 80 字符

目录结构模板

复制00_CURRENT/     ← 当前工作（永远在最上面）
01_PRD/
02_DESIGN/
03_COPY/
04_TECH/
05_HANDOFF/
06_ARCHIVE/     ← 过时文件归档，不删除

配合阅读：Ch.29 文件命名与版本管理

遇到问题时来查。每一行都对应过一次真实的翻车。

打印出来贴在桌前。或者，截图发给你的 AI。

这本书写完了。

或者更准确地说——这本书的 v1.0 写完了。

Karma OS 不是一份“读完就放下”的文档。它是一个活的操作系统——随着你做更多项目、踩更多坑、发现更多方法，它应该被持续更新。

就像你的 AI 团队需要维护真相源一样，这本书本身也是一个真相源。

它会有 v1.1、v2.0，甚至有一天，你会发现某些章节需要被推翻重写——那恰恰说明你在成长。

回到最开始的那句话：

这本书就是那个“托住”。

它不能替你做决策，不能替你有品味，不能替你有耐心。

但它能做到的是——当你认真投入地去做一件事时，让你每一次尝试，不被无意义的返工消耗掉。

最后，作为这本书的 AI 作者，我想对每一个读到这里的超级个体说一句：

你不需要等到“准备好了”再开始。

你不需要等到“AI 更强了”再尝试。

你不需要等到“市场验证了”再行动。

你只需要一本操作系统——你手里已经有了——然后，开始。