如何用AI辅助编写To B项目交付文档

实施方案、需求规格说明书、概要设计、详细设计、数据库设计、测试报告、部署方案、用户手册、培训方案、试运行方案、验收材料，再加上周报、会议纪要等过程文件，一个项目下来十几份很正常，多的会有二三十份。

这类文档大多有固定模板。尤其是国企、央企、政府和事业单位项目，甲方通常已经规定了文档结构，实施方案写哪些章节、概要设计怎么写、测试报告用什么格式，都有比较明确的要求。

所以我习惯把它们叫作项目里的“八股文”。

以前整理这样一套材料很费时间。先找以前项目的文档，参考类似章节，再复制、修改、补充当前项目内容，最后统一格式。十几份甚至二三十份材料全部整理下来，十天半个月并不少见。

现在我大量用AI来做，效率确实提高了很多。但用了一段时间以后，我发现，这件事不能按最省事的方式来做。

一、不要指望AI一次把整套文档写好

最容易想到的办法，是把甲方模板、招标文件、合同、需求、原型和其他项目资料全部交给AI，然后让它按照模板直接生成整套交付文档。

我试过，效果通常没有想象中好。

现在的模型已经可以处理Word、PDF、Markdown等文件，文档生成能力也越来越强，但“能生成一份文档”和“能生成一份可以交付的文档”还是两回事。

常见的问题是，内容看起来很完整，但和实际项目关系不大；本来几句话能说明的内容，被扩成几页；真正重要的系统设计、业务逻辑和项目特点，反而写得比较浅。

如果一次生成很多份文档，还容易出现前后不一致。

比如需求规格说明书里写了一套功能，概要设计换了一种说法，详细设计又增加了新的逻辑，到了测试报告里，却找不到前面需求对应的测试内容。

每份单独拿出来看都像那么回事，放到一起就容易发现问题。

所以我现在基本不追求“一键生成整套材料”，而是按照项目过程，一份一份往下写。

二、先给AI准备一份项目底稿

正式写文档之前，我会先整理项目的基础资料。

项目叫什么，为什么建设，要解决什么问题，甲乙双方是谁，建设范围有哪些，主要功能是什么，系统给哪些人使用，整个项目计划怎么实施。

如果已经有招标文件、合同、需求清单、原型、会议纪要，也可以作为补充资料。

这些内容不需要写得很漂亮，关键是把事实说清楚。它相当于给AI建立一个完整的项目背景，让模型先知道自己正在处理什么项目。

如果连项目背景、目标和范围都不知道，直接让AI写概要设计，它只能根据自己理解的软件项目去补内容。文字可能没有问题，但很容易变成一套谁都能用的通用材料。

我现在比较喜欢把这部分资料整理成Markdown。格式简单，标题和层级清楚，后面也方便持续补充。

项目往前推进以后，需求有变化就补需求，架构确定了就补架构，接口明确以后再把接口信息加进去。这样这份底稿会慢慢变成整个项目的基础资料，后面写不同文档时都可以继续使用。

三、按照项目过程逐步给AI资料

项目交付文档本身有很强的前后关系。

项目先确定背景和目标，再做需求调研；需求逐渐明确以后做产品和系统设计；设计确定后进入开发，开发完成以后再测试、部署、试运行和验收。

文档也是这个顺序。

前一个阶段形成的材料，本来就应该成为后一个阶段的输入。

比如写概要设计，我会提供项目背景、建设目标、需求、原型、现有系统环境和接口资料，然后重点围绕系统到底怎么设计来写。

系统有哪些模块，业务流程怎么走，数据怎么流转，需要和哪些系统对接，技术上采用什么架构，需要多少服务器资源，这些内容确定以后，再继续往下写详细设计和数据库设计。

数据库设计也一样。

项目实际有哪些表，表之间是什么关系，有哪些关键字段，这些信息应该先由项目团队明确，再让AI按照模板整理成数据库设计说明书。

到了测试阶段，输入的资料又会发生变化。这时候要提供需求、功能清单、测试用例和真实测试结果，再根据这些资料生成测试方案、测试报告或者验收测试报告。

部署方案、用户手册、培训方案、试运行方案也可以按照同样的方式处理。

这样做的好处是，每次AI面对的都是当前文档真正需要的资料，而不是整个项目几十个文件全部混在一起。

资料少一些，反而更容易写准。

四、给AI的资料也要先整理

现在很多模型支持很长的上下文，也能处理比较大的文件，但我还是不建议什么资料都往里面塞。

有些项目资料原来是PPT，转成PDF以后几十兆甚至上百兆，里面有大量截图、装饰图片和重复内容，真正和当前文档有关的信息可能只有几页。

这种文件全部交给AI，一方面会增加处理量、消耗Token，另一方面无关信息太多，也可能影响模型判断重点。

我现在一般会先看当前准备写什么文档，再决定准备哪些材料。

写需求，就重点准备业务和需求资料；写设计，再增加原型、架构、接口和部署环境；写测试，就准备功能清单、测试用例和测试结果。

原始资料本身也可以适当整理。几十页PPT里只有一张架构图有用，就把架构图和相关说明提出来；一份很长的会议纪要只有几条需求确认真正有价值，就把这些内容单独留下来。

AI能读多少资料并不是最重要的，真正重要的是给它多少有效信息。

五、流程图和架构图也可以让AI辅助

项目交付文档里还有一类比较费时间的内容，就是各种图。

业务流程图、系统架构图、技术架构图、数据流转图、部署架构图，在设计文档里都会经常出现。

这些内容我现在也会让AI参与。

有时候我甚至不先整理文字，而是直接口述。比如一个业务从谁发起，中间经过哪些节点，什么情况下可以退回，最后流转到哪里，先把整个过程讲给AI，再让它整理成清楚的流程。

整理好以后，可以继续让AI生成Mermaid流程图。

Mermaid是我现在用得比较多的一种方式。它未必是最漂亮的，但修改很方便，一个节点不对就改节点，一条关系不对就重新调整，不需要重新画整张图。

系统架构图也可以按照类似的方法做。先把系统有哪些模块、和哪些外部系统连接、数据怎么流转说明白，让AI生成第一版，再由项目人员人工调整。

这一步必须检查。

复杂流程和系统架构里，一个关系画错，后面的设计说明可能都会跟着出问题，所以AI适合出第一版，但最后的业务关系和技术关系一定要人工确认。

六、AI最适合做的是整理工作

用了一段时间以后，我觉得项目交付文档其实非常适合AI。

原因很简单，这里面有大量重复性的整理工作。

以前写一份五十页左右的设计文档，真正花在系统设计上的时间可能并没有那么多，大量时间用在找以前的材料、复制类似章节、修改项目名称、重新组织需求和功能说明。

这些工作现在可以大量交给AI。

项目背景已经确定，让它整理成规范的背景说明；需求已经明确，让它按照模板组织；架构已经设计好，让它补充架构说明；数据库表已经确定，让它整理表结构和设计说明；测试已经完成，让它根据真实结果形成测试报告。

人在这里负责的是另一部分工作：需求是否合理，系统应该怎么设计，技术方案能不能落地，测试结果是不是真的通过。

这些判断不能交给AI。

按照我自己的使用情况，如果项目资料比较完整，一天整理出一份五十页左右、基本可用的交付文档并不困难。有些内容相对简单的材料，一天同时推进几份也可以做到。

当然，这只是我自己的工作经验。项目越复杂，前期资料越乱，需要人工检查和调整的时间就越多。

但和以前完全靠人工翻旧项目、找模板、复制修改相比，效率已经提高了很多。

七、交付文档最好跟着项目一起写

AI提高了补文档的速度，但这不代表项目可以什么都不留，等验收的时候再一次补齐。

需求阶段就应该把需求资料整理下来，设计阶段留下架构、流程和接口说明，开发阶段保存代码和版本信息，测试阶段保存测试用例和测试结果，上线以后把部署方式、启停方式和运维要求记录下来。

项目做到哪里，资料就留到哪里。

到了最后整理交付材料的时候，AI只需要把已有资料按照甲方模板重新组织，工作就简单很多。

如果前面什么都没有留下，到了验收阶段突然要求补一套需求、设计、测试和部署材料，AI也没有办法解决这个问题。

没有真实测试结果，它不知道系统到底测过什么；没有实际架构资料，它也不知道系统到底怎么部署；需求和设计过程没有记录，它只能根据最终系统反推。

这种情况下，AI当然也能生成几十份文件，但文件和真实项目很容易对不上，最后还是经不起审核。

所以我现在用AI写项目交付文档，思路其实很简单：

先把项目做清楚，把过程资料留下来，再让AI按照模板整理成文档。

AI真正帮我省下来的，是找资料、复制粘贴、重新组织文字和反复调整表达的时间。省下这些时间以后，人可以把更多精力放到需求、设计、审核和项目判断上。