Vibe Coding 做复杂项目：给 AI 搭一个产研团队

很多人第一次 Vibe Coding，做的是记账、Todo、番茄钟、个人主页这类单一功能的小东西。AI 分分钟就能写出来，体验非常顺。

可一旦想做一个功能复杂的 App，项目就开始乱了：页面逻辑乱了，AI 做的设计很丑，bug 一大堆，最后项目烂尾。

原因在于：你每一次跟 AI 对话，它都要先把整个项目理解一遍，看完相关文件，才能给你回答。

项目越复杂，理解的难度越高；文件越多，占用的上下文越多，AI 就越混乱。

所以当一个 Vibe Coding 项目开始变复杂，难度就从「项目开发」变成了「项目治理」。

这一篇用一个真实案例，讲怎么给 AI 搭一个产研团队，并配上一套工作制度。搭好以后，哪怕新开一个对话窗口，AI 也能很快知道自己该从哪开始、该怎么干活。

案例是一个正在设计和开发的睡眠类 App。它涉及睡眠监测、数据计算、成就系统算法，还做了风格化的 UI 设计，是一个典型的复杂项目。

在开工之前，第一件事不是急着开发，而是先组建一个 AI 产研团队，并配上工作制度。

这套系统和现实里搭一个产研团队、开一家小公司没什么区别，核心就三件事：

听上去有点复杂，其实一步步来并不难。下面先从给 AI 分岗位开始。

在这个睡眠 App 项目里，参与产品决策的岗位一共分了 12 个：项目统筹、产品经理、视觉体验与美术、技术负责人与 iOS、后端与云服务、数据与睡眠算法、质量保障，等等。

每个岗位都要写一张「定义卡」，讲清三件事：做什么、不做什么、和其他岗位的边界在哪里。这有点像企业招聘时写的岗位职责。

以「视觉体验与客户端呈现」这个岗位为例，它的岗位文档 03-视觉体验与客户端呈现.md 里写了：

• 使命与职责：把 App 的体验转化为一致的、可访问的、可实现的、可验收的 UI/UX、美术和动效；
• 具体工作：用户流程、概念美术、视图组件和各种状态，以及维护视觉资源、做好尺寸匹配；
• 与 iOS 技术岗的边界：本岗管「用户看到和操作的呈现层」，领域模型、数据访问、架构等归技术岗；
• 固定产物与完成定义：交出哪些东西、达到什么标准才算完成。

按同样的方式，把项目经理、产品经理、视觉、前后端、算法等岗位全部拆开。每个岗位既有自己负责的事，也写清需要和哪些岗位协作。

岗位拆开后，还需要一张职责与协作矩阵（文件 01-职责与协作矩阵.md），把每项工作和每个岗位交叉起来，用四个字母标出关系：

其中 H 列最重要：它写明哪些事情必须交给你本人拍板。案例里的规定是，仅在涉及真人数据、设备操作、外部账号或商业决定时需要真人。

这样，一套岗位划分系统就建好了。

不过，实际做的时候不一定要像案例这样写 12 个角色。大多数新项目只需要产品、设计、开发、质检这四个。如果项目不涉及算法、用户运维等工作，就不用设这些角色，以免浪费资源。

岗位分好了，怎么让这些角色互相协作、持续运转？靠的是工作台账。

在项目根目录下放一份 项目总台账.md，写明当前项目的岗位、里程碑、当前工作项、阻塞、风险、人力授权和决策摘要等内容。

它相当于整个项目的总览。AI 读一遍，就知道项目走到了哪一步、哪些部分正在推进、哪些问题需要解决。

举个例子：工作项 DATA-001 的内容是「完成 Apple Watch 隔夜阶段数据验证」，状态标记为已阻塞，阻塞原因是「需人类佩戴 Watch 产生真实样本」。

所以在开发期间，作者每天晚上都要戴着 Apple Watch 睡觉去记录数据。数据回来后，这一项才能继续推进。

台账不只是给 AI 看的，也会明确告诉你：哪些事卡在你身上。

除了项目总台账，每个角色还有一份自己的岗位台账。

这就像老板问员工：「你本周完成了哪些工作？项目进度怎么样了？」岗位台账就是这些问题的答案。

还是看 3 号岗位「视觉体验与客户端呈现」的台账，里面记录了：

• 当前进度：现在走到了哪里；
• 近期计划：接下来要做什么，每一项带编号、优先级、状态和完成标准。

因为产品还处在页面设计和 Demo 阶段，这个岗位的工作是最多的。近期计划里已经完成了设计系统的搭建，以及所有页面的高保真状态和设计资产的绘制。

台账里的日志只记录后续工作的事实。案例里的日志列是：日期、工作项、动作与结论、证据、下一步。

如果某件事需要其他角色参与，就直接登记下来，交给对应的角色，然后继续做自己该做的事。

为什么一定要分角色

每一个独立的对话窗口并不是全能的。只让它做开发，或者只让它做设计，它能把工作完成得很好；但如果让一个窗口同时参与多项工作，质量可能会因为不专注而变差。

这就是为什么一定要把 AI 的工作进行角色分配。

岗位分好了，总台账和岗位台账也建好了，怎么让这套机制真正运行起来？关键在于 AI 工具读文档的加载顺序。

入口一：AGENTS.md

案例中使用的 AI 工具，每次开始对话都会优先读取项目根目录下的 AGENTS.md。所以 AGENTS.md 里只写两件事：这个仓库是干什么的，以及接手的 AI 必须依次阅读哪些文档。

案例里的必读清单是：

1. 项目总台账.md：确认项目阶段、当前目标、阻塞项和工作项编号；
2. 06-团队手册/README.md：确认岗位、职责边界和文件入口；
3. 06-团队手册/00-AI团队运行规则.md：确认执行、验收、交接和权限规则；
4. 与本次任务对应的 06-团队手册/角色台账/*.md；
5. 任务引用的 PRD、决策记录、设计稿或技术文档。

清单直接指向项目总台账和团队手册文件夹。这样无论在哪个对话窗口下达任务，AI 都能找到团队手册。

编者注：不同工具自动读取的入口文件不一样。比如 Claude Code 默认读取 CLAUDE.md，可以在里面只写一行 @AGENTS.md，让它同样读到这份入口。

入口二：团队手册里的 README.md

团队手册文件夹里还有一份 README.md，同样会被优先读取。它简明地写了三块内容：团队结构、文件入口和使用顺序。

AI 接手任务时会怎么走

顺着这套指引，接手任务的 AI 不会马上开始写代码，而是：

1. 先读项目总台账，了解整个项目的进度；
2. 给自己认领一个确定的身份；
3. 再去读这个岗位的台账，看当前进度；
4. 如果是之前没完成的任务，对着台账接着做；如果是新任务，就拆解成一条条工作项，登记回项目总台账。

通过 AGENTS.md 和 README.md 这两个简单的文件链接，项目里的 AI 就能按照设定好的工作流程高效工作。

这么一套操作下来，会不会非常消耗 token？要分情况看。

小项目：不需要。 如果只是一个页面、一两个功能，整个开发过程本来就是一条单线，你说一步它做一步。这时强制的引导和登记，对 AI 来说反而是负担。

复杂项目：反而更省。 如果项目页面比较多、模块之间互相牵扯，而且要长期迭代、越做越复杂，情况就完全反过来了。没有台账时，你每交代一个任务，接手的 AI 都得重新盘一遍：

台账系统相当于在项目里立起了一排路标。AI 不用再自己摸索，顺着路标走几步，就知道自己现在在哪、接下来该干什么。

想在自己的项目里快速建立这套台账系统，可以直接把下面这段提示词复制给 AI 编程工具。把开头的「某某类型」换成你自己的项目类型：

我在做一个某某类型的项目，界面比较多，要长期迭代，由我一个人加AI来完成。请帮我在项目里建一套角色台账，让你每次只站在一个岗位上工作，换个对话窗口也不会丢记忆。请生成下面这几份文件。

第一份，项目入口文件。写清楚任何AI接手这个项目，必须按什么顺序读哪几份文件；硬规则：不把单次对话当成项目记忆，聊出来的结论必须写回文件；开工前先认领一个工作项，收工前更新状态和下一步；不把写完了当成验收通过。

第二份，岗位与职责。结合我这个项目的实际情况，给出四到六个岗位，每个岗位写清三件事：负责什么、不负责什么、交出什么才算完成

第三份，项目总台账。放里程碑和当前的工作项表格，每一项要有编号、状态、负责岗位、卡在哪儿、产出和验证证据，再单独留一个需要我本人拍板的队列。

第四份，每个岗位一份自己的台账。放这个岗位的工作计划、过程日志和验收证据。总台账写摘要，岗位台账写细节，同一个工作项的编号，两边保持一致。

先把岗位清单和第一批工作项列出来给我看，我确认之后你再生成文件。

这段提示词会让 AI 生成四份文件：

留意最后一句：先把岗位清单和第一批工作项列出来，确认后再生成文件。 第一次搭建时，先看 AI 打算设哪些岗位、拆出哪些工作项，和你的项目对得上再让它动手。

用 AI 做复杂项目，不能依赖会话窗口里的对话，而要依赖记忆。这套系统也可以理解为：在给 AI 做记忆的治理。

案例项目的 AGENTS.md 里，强制规则的第一条就是：

不以单次对话作为项目记忆；结论、进度、证据和下一步必须回写仓库。

换句话说，仓库才是项目的记忆，对话只是临时的工作台。你跟 AI 聊出来的结论，只要没写回项目里，对这个项目来说就等于从来没有发生过。

回顾整套做法：

1. 分岗位：每个岗位写清做什么、不做什么、和谁有边界；用职责矩阵标出需要你拍板的事；
2. 建总台账：里程碑、工作项、阻塞和决策摘要，读一遍就知道项目走到哪；
3. 建岗位台账：每个岗位记进度、计划和日志，需要别人做的事直接登记交出去；
4. 设入口：用 AGENTS.md 和团队手册 README.md 规定读取顺序，让每个新对话都能找到路标。

AI 是一个超级员工，但再强的员工，也需要一个好老板和一套好的工作制度。

如果项目还没复杂到需要分岗位，可以先从更轻的一套开始：用 4 个文件让 AI 自己跑完开发闭环。