把会议变成文档、把执行交给 AI、把人的时间还给真正重要的决策
传统团队协作的问题，不是人不够努力，而是大量时间消耗在了沟通本身。
口头说的内容每个人理解不一样，等做完了才发现跑偏了，再返工。
两小时的会议，散会后五个人有五个版本的「结论」，执行方向各不相同。
核心设计都在某人脑子里，没有文档，新来的人要花几个月才能摸清楚。
传统团队把 AI 当工具用，
这套方法是把 AI 当执行者用。
所有决定、需求、设计都必须写下来。文档不是会议的补充——文档就是唯一的沟通介质。没写进文档的决定，视为不存在。
写代码、写文档、搭架构、部署上线——这些都可以交给 AI。人的时间应该花在：想清楚要做什么、判断做出来对不对。
AI 随时在线，文档随时可读。不需要约好时间一起开会，不需要等某人回复消息，任何时间都可以继续工作。
不是减少人，而是每个人把时间花在更值钱的事情上。
| 传统做法（做了大量低价值工作） | 角色 | AI-native 做法（把时间花在判断上） |
|---|---|---|
| 写充满黑话的 PRD 文档，开需求评审会逐行解释 | 产品 / PM | 写「零黑话」意图文档——说清楚解决什么问题、谁来用、边界是什么。AI 来提方案，你来判断对不对。 |
| 写代码、改 bug、等测试、写部署文档……花大量时间在执行上 | 开发 | 把任务描述清楚，让 AI 写代码。你负责验收：AI 的输出符不符合预期，哪里有问题。 |
| 写测试用例、手动点点点、记录 bug、沟通复现步骤 | 测试 | 把测试场景写清楚，AI 生成测试用例、执行验证。你来定义「什么叫做对了」。 |
| 负责「技术知识传递」，花大量时间给别人讲解 | 架构师 | 把架构设计决定写进文档，AI 帮维护。团队成员有问题，先问 AI，AI 会读文档回答。 |
| 发文档、写操作指引、整理会议纪要、出周报 | 团队负责人 | 维护「功能状态表」——一张表看所有功能的进度，不需要每周开会同步。 |
每一步谁来做，做什么——不再有模糊地带。
不需要写技术方案，只需要写清楚：要解决什么问题、谁来用、什么是做对了、边界是什么。这份文档是后续所有工作的起点。
AI 读你的意图文档，给出数据模型、业务流程图、接口设计。你只需要判断：这个方向对不对。有不对的地方，用自然语言告诉 AI「这里不对，因为……」，AI 来修正。
方案确认后，AI 来写代码、写接口文档、建测试。你不需要自己动手写——但你需要验收：跑一遍真实流程，确认结果符合预期。
功能做完后，把设计决定、数据模型、流程图、可配参数写进设计文档。状态表里更新进度。文档是工作的产出物，不是额外负担。
文档更新后，把链接发给团队。不需要开会讲解，不需要等所有人在线。有问题让大家在文档里留言，或者直接问 AI。
4 种文档，职责单一，互相指向。每篇是独立的单文件，AI 随时可读。
overview.html
一页读懂整个项目。解释这个产品是做什么的、给谁用、钱从哪来、用户的完整路径。第一篇写，永远置顶。非技术背景的人看完也要能明白。
scenario-N.html
把用户旅程切成几段，每段一篇。用流程图描述：这个场景下用户做什么、系统做什么、可能出什么问题、运营可以调哪些参数。
*-design.html
需要深入设计的模块——数据模型、业务规则、现状和待做的差距、实现分期。是代码的「说明书」，和代码同步更新。
feature-status.html
一张表看所有功能做到哪了——三色状态（✅已完成 / 🔵进行中 / 🟡待做）。这张表代替周报、代替站会，是团队唯一的进度真值来源。
不需要买任何工具，不需要培训，按这个清单走就行。
提前知道，就可以提前绕开。
做完了就不会回来补文档了。→ 文档和代码同步：做完一步，记录一步。
AI 根据你说的做，如果输出跑偏，通常是输入不够清晰。→ 在意图文档里明确写「完成标准是什么」。
AI 不会犯人会犯的错，但 AI 有自己的误区。每个产出物都需要人来验收。→ 建立「验收清单」，逐项对照。
代码改了，文档没更新；下次 AI 读文档给出的方案就是错的。→ 代码 commit 里必须引用对应文档，改代码时检查文档是否需要同步更新。
习惯很难改变，有些人天然喜欢开会。→ 不强迫，但设一条规则：口头决定必须在 24 小时内写进文档，否则无效。
AI 负责执行，人负责判断。业务方向、架构边界、关键设计取舍——这些必须由人来决定。→ 明确哪些事 AI 做，哪些事人决定，不能模糊。
这不是一套复杂的方法论，就是一个习惯的转变：
把脑子里的东西写出来，然后让 AI 去执行。