FDE 怎么治理文档和代码：怎么让 AI 真的能帮上忙
上一篇讲了项目推进的三个纪律：每天的计划、模块的拆解、Git 的分支纪律。
这一篇讲一个更底层的问题：文档和代码的治理。
为什么这两样东西需要「治理」？因为在 FDE 项目里，AI 是主要的代码生产者——而 AI 写代码的时候，会大量参考你的文档、大量阅读你的代码。你给它的原料是什么质量，它产出的代码就是什么质量。
以前文档是写给人看的。人有个本事：从混乱里找信息。文档乱一点、命名差一点、版本旧一点，人能忍，能猜，能问。AI 不行。你给它一堆混乱的文档，它就一本正经地给你写出混乱的代码。
所以治理的目标很明确：让 AI 拿到的每一份文档、每一段代码，都是干净的、孤立的、最新的。
一、文档精细化：只留下有用的，每一份都要命好名
第一个原则可能和直觉相反：文档不是越多越好，是越精越好。
我们的做法是：只留下有用的那几个文档。 过期的方案、废弃的会议纪要、试错的中间稿，一律清出去。为什么？因为 AI 不会分辨「这份文档是不是已经作废了」——它读到什么就信什么。一份过期的需求文档留在目录里，就是一颗定时炸弹。
留下来的文档，要做到三件事：
- 分门别类。需求文档、业务规则、接口说明、数据结构，各归各的目录，不混在一起。
- 好好命名。命名就是 AI 的导航。「采购计划表-字段说明-v3.md」和「新建文档-final-最终版.md」，AI 对前者的理解成本远低于后者——人也一样。
- 版本号必须写清楚。业务方案改了，文档就要升版本。AI 参考到旧版文档，写出来的就是旧版逻辑，而这种 bug 极难排查——代码看起来「明明是对的」，只是对的是三个月前的需求。
文档的版本混乱，最后都会变成代码里的隐性 bug。
二、先吃透业务和数据，再写代码
第二个原则是关于动手之前的：写代码之前，全员要理解业务。
注意是「全员」，不只是 FDE 自己。第 1 篇讲过 FDE 要白天泡客户现场、晚上带团队过业务——那一套做到位之后，动手前还要再过一遍：每一个业务细节，尽量问清楚。
肯定要承认：不可能全部问清楚，总会有模糊的角落。但「尽量问清楚」和「差不多就开写」之间，差的是整个项目的返工率。
业务问清楚之后，还有一步很多人会漏：看数据来源，决定要不要做数据治理。
- 数据从哪来？几个来源？
- 格式统一吗？字段对得上吗？
- 有没有脏数据、缺失、口径不一致？
有些数据来源很复杂，不做数据治理根本没法办。 客户的财务系统和库存系统对不上，你不先把数据洗一遍，后面所有建立在这些数据上的功能都是空中楼阁——代码写得再好，算出来的数也是错的。
数据治理不性感，但它是地基。地基不打，楼盖得越快，塌得越响。
三、文档和代码都要「面向 AI」
第三个原则最反直觉：文档体系和代码结构，都要面向 AI 来设计。
文档要分开：上下文不能混
前后端的文档要分开，不同业务的文档要分开。 不然 AI 写代码的时候，上下文里什么都有，相当混乱——写前端组件的时候掺着后端接口的细节，写采购模块的时候掺着库存模块的规则，产出质量直接掉一档。
分开之后，每个任务只喂相关的文档，AI 的注意力才能聚焦。
代码要隔离：不要搞复用
这条更反直觉。传统软件工程追求 DRY（Don't Repeat Yourself），能复用就复用。但在 AI 协作的项目里，我们的原则是：代码尽量隔离，不要搞复用。
为什么？因为复用对人友好，对 AI 是耦合：
- 人改一个共用模块，知道要检查所有调用方
- AI 改一个共用模块，它只盯着你给它的那段上下文，改完波及所有用到它的地方，它还觉得自己干得挺好
隔离的代码，每个模块独立、可替换、可单独验证。AI 改 A 模块，物理上就不可能碰坏 B 模块。重复一点代码，换来的是故障半径的大幅缩小——这笔账怎么算都值。
面向人设计代码，追求的是「少写」；面向 AI 设计代码，追求的是「改不坏」。
写在最后
三个原则其实是同一件事：降低 AI 的理解成本。
- 文档精细化，让 AI 读到的是对的
- 先吃透业务和数据，让 AI 做的是对的
- 文档和代码面向 AI，让 AI 改的时候不会碰坏别的
文档和代码的治理，看起来是「内务」，实际上是 AI 时代 FDE 的核心竞争力。你的原料有多干净，AI 的产出就有多可靠。