AI Native 项目组:B 端交付,人该做什么,AI 该做什么

不管你做什么行业，大概率都遇到过这种时刻：项目快交付了，客户临时加个需求，还希望时间不变。你要做的不是"能不能加"，而是"加了之后谁担责、怎么安排、怎么回写记录"。

我们项目组最近就遇到这么一件事：一个候选版本刚通过验收，客户那边突然发来一句话——能不能再加个功能？时间不变。

会议室里一下子安静了。技术负责人在算影响范围，对客沟通的人在琢磨客户真正要的是什么，项目负责人在权衡：是硬塞进去，还是另开变更？

这不是什么新故事。几乎每个需要跨角色协作的项目都会遇到类似的时刻——范围要加，时间不变，人要做决定。

但这次不一样的地方是：团队开始讨论，以后能不能让 AI 先把这些差异整理出来。

1. 先说说，我们之前是怎么干活的

项目刚开始的时候，文件都是"飞来飞去"的：会议纪要发在邮件里，周报贴在群里，需求文档存在某个人的电脑里，版本改了好几轮，谁手里是最新版谁也说不准。新人进来第一件事："能不能把最新版的 XX 发我一下？"

这不是什么小问题。版本混乱意味着：

• 谁改了哪一行、为什么改，没人说得清

• 出了问题，要翻好几个聊天记录才找得到源头

• AI 想帮忙，得先从各个地方收集一遍资料，还不一定收得全

根据我的了解和判断，一套成熟的做法是这样的：把业务知识逐层拆开——从模块到功能，再到具体功能点；把疑问单独留下，通过客户沟通、资料和必要验证逐步澄清。每次反馈都要能回到相应条目，而不是重新整理出一套互不相认的事实。

这套方法背后有几个关键设计：

• 对客沟通的人，需要便于讨论的视图——问题清单、待确认事项、影响范围

• 维护知识的人，需要能持续修订的底表——功能点、验收标准、版本记录

• 两者可以采用不同展示形式，但事实依据应当对应，修改也要留下版本和原因

这些不是什么新发明。传统交付管理里早就有这些原则：范围逐步澄清，责任可以指认，变更留痕，不同角色围绕同一件事沟通。

但问题是：这些原则，你团队真的做到了吗？

一次索取附件，不能证明团队没有维护文档；一套方法被记录下来，也不代表每个环节都已稳定执行。很多时候，方法在纸面上，执行在迷雾里。

我见过一个很实用的边界判据："我做的这个东西，是给谁交差的？" 答不出对自己人的交付对象，大概率就是越界了。对客催办有专门的出口，技术侧只输出"卡在哪、需要什么"；别人认领的工作，不主动抢着做，备好资料放那儿，谁用谁取。这条判据听起来简单，但在小团队里特别容易被"都是为了项目好"模糊掉。

2. 后来我们用 Git 文档仓，把所有东西管起来了

文件飞来飞去解决不了根本问题。后来我们干脆用一个 Git 文档仓，把所有东西管起来。

代码在各自的开发仓，文档、会议纪要、周报、任务跟踪、新人上手全放在这个文档仓里。读者可能不懂技术——写文档时假定读者是 PM 或业务同事，能用一句话说清的，不写一段。

为什么非要用 Git？因为文件飞来飞去的时候，你根本不知道哪个是最新版，也不知道谁改了什么、为什么改。用 Git 之后，每次修改都有记录，谁在什么时候改了哪一行、为什么改，翻历史就知道。新人进来 clone 下来，就是最新版，不用到处问"谁有最新的发我一下"。

这个仓里有几样东西是协作的骨架：

• 术语表：项目里的统一语言只有一份真相源，不在别处各写一份。新人进来先看术语表，不用到处猜

• RACI 职责矩阵：一行一事项，四个角色点名——谁干活、谁最终负责、咨询谁、通知谁。判据是"这条卡住时，谁负责把它推通？"答不出，就是缺最终负责人

• 变更日志：这个仓每次改了什么，都记在 CHANGELOG 里。要追溯"这个决定是什么时候做的、为什么"，翻日志就行

• 机器可读索引：除了给人看的目录，还有一份给 AI 读的索引——单元、入口、问题、关键词、关键文件。AI 代人做事时，先查索引再读正文

仓里还跑了 CI：坏链检查、孤儿文档检查、文档站自动发布。写了文档不合规，CI 直接拦住，合不进去。

还有一个容易忽略的点：文档目录怎么组织。很多团队按 PMP 的五大过程组分——启动、规划、执行、监控、收尾。但实际跑起来会发现：同一份文档会在过程组之间搬家，一搬所有引用全废。

客户找的是"你答应交的那几件事在哪"，不是"你们怎么管"。所以按交付物来组织目录——交付件、工作底稿、参考资料、状态追踪、会议纪要——比按过程组分更实用。追溯链落在一页状态表里，不新增目录。

3. 文档管好了，接下来是：为什么还需要人作决定

文档仓解决了"东西在哪"的问题，但解决不了"出了事谁拍板"的问题。

回到开头那个场景：候选版本刚通过验收，客户提出加新功能，希望沿用原来的上线时间。

周报即使把每个状态写得准确，也不能替团队回答这项新要求怎样处理。

负责对客沟通的人，先确认客户真正需要的是什么——是要那个功能本身，还是用它来解决另一个业务问题。

技术与测试角色说明：新增要求影响哪些权限、实现和检查范围，原版本的确认还能覆盖哪些部分——这些都不是"顺手加一下"的事。

项目负责人组织大家比较保留原范围、调整时间或另开变更等选项。最终由项目约定的授权角色作决定，发布安排也按相应权限确认。

这里有几项不同的职责：谁推进澄清，谁提供影响判断，谁批准范围和承诺，出现分歧时何时升级。它们不要求新增一排岗位，但必须能够回答。一个人可以兼任，也应知道自己此刻是在提供建议，还是作出有权作出的决定。

会议结束后，只需在原工作项中补一条决策记录。格式很简单，五个要素：

• 决定：本轮维持原范围，新需求另列变更

• WHY：新需求涉及权限和新增测试用例，硬塞会影响原交付

• 依据：原版本已按约定通过验收；客户提的新需求不在原约定内

• 谁定：范围负责人（授权角色）

• 影响：对客沟通者澄清具体范围；技术与测试评估变更工作量；项目负责人在下次协调会复核

有一条铁律：没有 WHY 的判断不进决策表。那种判断第二天就会被推翻——谁还记得为什么这么选？

这比再增加一张漂亮看板更接近协作的核心：让下一位接手者知道，团队为什么这样做，还有哪些决定没有作出。

4. AI 进来之后，到底能做什么

文档仓管好了，决策也有规范了。接下来的问题是：AI 到底在里面起什么作用？

AI 的一个候选作用，是在授权范围内对照反馈、版本和决定，整理差异与依赖，再按受众生成不同视图。

对客沟通者得到待澄清问题，技术角色得到变更影响，项目负责人得到需要协调和决定的事项。生成摘要还要检查接收者能否看到这些信息，不能把读取权限扩大成任意披露权限。

但要让 AI 真正参与协作，先要把知识分层。有一套很实用的三层加载模型：

• 常驻层：每次会话都加载的——触发条件、禁止项、核心判据。这层要少而精，多了就稀释注意力

• 按需层：人主动读、AI 按需检索的——全文、案例、模板、规范细则。不用每次都加载，用到再查

• 执行层：脚本和钩子跑的——确定性动作，比如坏链检查、索引校验、格式门禁。结果只出 stdout，不占上下文

判据很简单：每次都用到 → 常驻；场景才用 → 按需；能被脚本判定 → 执行。

这里有一条很关键的分水岭：写在文档里是请求，做成 hook 才是保证。 文档里写了"必须带文件头"，但没人检查，实际覆盖率不到一半；做成 CI 门禁，不过就合不进，覆盖率就是 100%。

我们具体是怎么管理这套东西的？ 所有 AI 相关的规则、手册、项目上下文，全部上传到同一个 Git 仓里，不是散落在各个地方。这个仓里放三类东西：

• 常驻层的规则：每次 AI 进来都要读的——禁止什么、触发什么、什么是硬约束。这层要少而精，多了就稀释注意力

• 按需层的手册：具体的技能操作手册、项目上下文、术语表、决策日志。AI 遇到什么任务，再去读对应的手册

• 执行层的脚本：坏链检查、格式门禁、索引校验——这些是确定性的动作，不用 AI 来做，跑脚本就行

每次有新的实践，就往仓里加一份手册；每次发现 AI 犯了什么错，就往常驻层加一条禁止项。所有改动都有 Git 记录，谁改的、为什么改，翻历史就知道。不是靠人记在脑子里，也不是靠微信群里传。

人工的工作也会随之调整。记录维护者要检查 AI 有没有把不同事项错误归并；负责人要审查摘要是否遗漏分歧；授权角色要确认自己的决定没有被模型补写。若事实或判断有异议，应能回到来源修正，并留下更正记录，而不是默认接受最后一份生成结果。

5. 最小验证：用一场协调会试一次

不要一开始就开发庞大的 Agent 平台。挑一个范围明确、资料允许读取的待决问题，继续使用现有会议和记录，试一次。

第一步：先留对照。 由熟悉项目的人回答：正在等什么，谁推进，谁有权决定，什么情况需要升级。把这些答案与依据留下，作为对照。

第二步：让 AI 旁路整理。 只交三样东西：分歧与依赖、可能的选项及其依据、仍缺的确认。它可以提出问题，但不替团队承诺范围、时间或验收结论。

第三步：会上裁决，会后回写。 由有权角色裁决，会后在原记录补一条决定和下一动作。然后比较：AI 是否遗漏了关键分歧，是否把建议当成批准，是否扩大了资料可见范围？团队为了修正它新增了多少维护工作？

什么情况下停止？出现未经批准的状态改动、无法解释的结论或敏感信息扩散时，停止试点，回到人工记录与原有流程。决定是否继续的依据，应是团队能否更好地协调和交付，而不只是摘要生成得更快。

6. 要保留的经验，要验证的变化

这轮资料核对让我更重视已有交付经验中的具体设计：知识怎样分层，反馈怎样进入下一版本，谁负责沟通，谁维护共同依据，以及什么信息只能留在授权环境。这些工作在 AI 参与之后仍然需要有人负责。

还有一个实测出来的洞察：凡是挂了脚本或 CI 的（坏链检查、索引校验、文档体积），可以认为有效；凡是没有自动校验的（文件头格式、版本历史表、命名规范），实际覆盖率约等于"写的人当时记不记得"。我见过一个项目，文件头格式规范写得很详细，但实测覆盖率不到一半——因为没人查，也没人罚。

所以 AI Native 的第一步，不是给 AI 多少权限，而是先把哪些东西是"硬约束"、哪些是"软建议"分清楚。硬约束做成自动校验，软建议写进文档就行。AI 跑在上面，才不会把软建议当成硬约束来执行，也不会把硬约束漏过去。

新的问题是，如何把这些规则表达得足够清楚，让 AI 可以受约束地帮忙，也让人有能力发现和纠正它的错误。

如果对你有启发，欢迎点赞、在看、转发；星标「行途」，第一时间收到下一篇。

谢谢你看我的文章，下篇见。

关键词：AI Native / 项目协作 / 交付管理