今天想分享一下最近在团队讨论中关于生成式AI能否帮助生成技术/业务文档，提高工作效率的思考。纯属个人观点，希望对你有所启发。
背景
起因是我们在处理一个遗留系统项目时，遇到文档不完整、格式混乱的情况。这个项目已经转手多个外包团队，很多文档是在项目交付后匆忙编写的，导致了各种问题：文档过时、不规范，甚至丢失。而我们的团队接手后，通常只有1到3个月的时间熟悉项目并独立维护。而外包团队在交接后往往解散，一旦交接不充分，就很难再找到相关人员。
更复杂的是，不同项目的技术栈各异，导致团队成员需要快速掌握多种技术和业务知识，这大大增加了学习成本。
期待
团队希望通过生成式AI，结合源代码和现有的技术/业务文档（无论是否最新），构建一个知识库。这不仅能帮助团队迅速生成项目的整体概况，了解项目的“前世今生”，还能像一个虚拟专家，解答团队在项目中的各种问题——无论是业务逻辑、技术架构还是数据库设计等方面。即便老团队撤出，AI也能成为对项目了如指掌的“人”。
挑战
最初我们设想使用GPT-4o或Llama3.1等生成式AI，通过RAG（检索增强生成）技术构建一个本地知识库，满足上述需求。然而，冷静分析后，我们意识到一些不可忽视的问题：
- 生成式AI虽然有强大的通用知识储备，但对于特定项目的领域知识，依赖的是输入数据。而这些数据往往是过往外包团队留下的质量参差不齐的文档。
- 如果这些文档中包含过时或错误的信息，AI基于此生成的内容也会不准确。
所以，如果AI的基础数据不可靠，我们又怎能期望它生成出正确的文档呢？
代码与文档
基于以上挑战，我们意识到：源代码是项目的核心数据资产，虽然其他文档可能过时或不准确，但代码始终能反映项目的现状。因此，AI可以通过解析代码来生成代码逻辑的解释，这在技术层面是可行且较为准确的。
但要注意，代码只能描述实现逻辑，无法直接推导出原始的业务需求。原因如下：
- 代码是开发人员对业务需求的抽象，而这个过程往往伴随信息丢失或理解偏差，这也是Bug产生的主要原因之一。
- 因为代码是一种多对一的抽象，同一个业务需求可能有多种实现方式，无法从代码反向推导出原始需求。
尽管这些问题可以通过技术手段逐步解决，但我的核心思考是：人和领域知识的重要性。经历过产品或者项目的人，头脑中的知识比文字形式的文档更有生动，更有意义。AI只能作为辅助工具，而业务创新仍然依赖于人类的思考与理解。AI目前还不具备这种创新能力。
反向思考：代码即业务文档？
如果代码能更好地反映业务领域知识，而不是仅仅是技术抽象，那么代码本身或许也可以成为一种业务文档——活文档。这种情况下，AI生成业务文档的可能性将大大提升。如果代码能够一对一地映射业务需求，业务文档的生成将变得更加可行。
如何能够实现上面的这一点呢? 一个20年前的建模方法或许能够帮上忙，那就是领域驱动设计（DDD）。这里就不再赘述，感兴趣的小伙伴可以自行查找。不过有一点可以高度概括DDD希望实现的目标：业务需求、模型、代码三者1比1的反应彼此。那么代码就可以1:1的反应业务需求，本身就是一个业务文档了。
最后
无论你是谁，我希望你可以思考：
- 作为开发人员，你的代码能否真实反映业务领域？而不是你自己的抽象。
- 作为AI开发者，你的数据是否准确，足够支持你的应用需求？
- 作为业务人员，AI是你的伙伴，而你的竞争力在于脑中的领域知识，这是AI无法替代的。你的竞争力是什么？
践行敏捷实践，让工作变得更美好。欢迎在留言区留言，交流落地经验。
欢迎关注我的个人博客
