AI 生成文档? 代码有用，领域知识为王

今天想分享一下最近在团队讨论中关于生成式 AI 能否帮助生成技术/业务文档，提高工作效率的思考。纯属个人观点，希望对你有所启发。

背景

起因是我们在处理一个遗留系统项目时，遇到文档不完整、格式混乱的情况。这个项目已经转手多个外包团队，很多文档是在项目交付后匆忙编写的，导致了各种问题：文档过时、不规范，甚至丢失。而我们的团队接手后，通常只有 1 到 3 个月的时间熟悉项目并独立维护。而外包团队在交接后往往解散，一旦交接不充分，就很难再找到相关人员。

更复杂的是，不同项目的技术栈各异，导致团队成员需要快速掌握多种技术和业务知识，这大大增加了学习成本。

期待

团队希望通过生成式 AI，结合源代码和现有的技术/业务文档（无论是否最新），构建一个知识库。这不仅能帮助团队迅速生成项目的整体概况，了解项目的“前世今生”，还能像一个虚拟专家，解答团队在项目中的各种问题——无论是业务逻辑、技术架构还是数据库设计等方面。即便老团队撤出，AI 也能成为对项目了如指掌的“人”。

挑战

最初我们设想使用 GPT-4o 或 Llama3.1 等生成式 AI，通过 RAG（检索增强生成）技术构建一个本地知识库，满足上述需求。然而，冷静分析后，我们意识到一些不可忽视的问题：

1. 生成式 AI 虽然有强大的通用知识储备，但对于特定项目的领域知识，依赖的是输入数据。而这些数据往往是过往外包团队留下的质量参差不齐的文档。

2. 如果这些文档中包含过时或错误的信息，AI 基于此生成的内容也会不准确。

所以，如果 AI 的基础数据不可靠，我们又怎能期望它生成出正确的文档呢？

代码与文档

基于以上挑战，我们意识到：源代码是项目的核心数据资产，虽然其他文档可能过时或不准确，但代码始终能反映项目的现状。因此，AI 可以通过解析代码来生成代码逻辑的解释，这在技术层面是可行且较为准确的。

但要注意，代码只能描述实现逻辑，无法直接推导出原始的业务需求。原因如下：

• 代码是开发人员对业务需求的抽象，而这个过程往往伴随信息丢失或理解偏差，这也是 Bug 产生的主要原因之一。

• 因为代码是一种多对一的抽象，同一个业务需求可能有多种实现方式，无法从代码反向推导出原始需求。

尽管这些问题可以通过技术手段逐步解决，但我的核心思考是：人和领域知识的重要性。经历过产品或者项目的人，头脑中的知识比文字形式的文档更有生动，更有意义。AI 只能作为辅助工具，而业务创新仍然依赖于人类的思考与理解。AI 目前还不具备这种创新能力。

反向思考：代码即业务文档？

如果代码能更好地反映业务领域知识，而不是仅仅是技术抽象，那么代码本身或许也可以成为一种业务文档——活文档。这种情况下，AI 生成业务文档的可能性将大大提升。如果代码能够一对一地映射业务需求，业务文档的生成将变得更加可行。 如何能够实现上面的这一点呢? 一个 20 年前的建模方法或许能够帮上忙，那就是领域驱动设计（DDD）。这里就不再赘述，感兴趣的小伙伴可以自行查找。不过有一点可以高度概括 DDD 希望实现的目标：业务需求、模型、代码三者 1 比 1 的反应彼此。那么代码就可以 1:1 的反应业务需求，本身就是一个业务文档了。

最后

无论你是谁，我希望你可以思考：

• 作为开发人员，你的代码能否真实反映业务领域？而不是你自己的抽象。

• 作为 AI 开发者，你的数据是否准确，足够支持你的应用需求？

• 作为业务人员，AI 是你的伙伴，而你的竞争力在于脑中的领域知识，这是 AI 无法替代的。你的竞争力是什么？

践行敏捷实践，让工作变得更美好。欢迎在留言区留言，交流落地经验。

【欢迎关注我的个人博客】