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

如果你翻开这本书，大概率是因为——你想用 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 更强了”再尝试。

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

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