一、程序员最烦的不是写代码，是写文档
写代码是跟机器打交道——它不挑你的措辞，只认逻辑对不对。
写文档是跟人打交道——甲方、验收专家、操作员，每个人都有自己的脾气。写薄了说"不够详细"，写厚了说"太啰嗦"，技术术语多了说"看不懂"，写得太通俗又说"不够专业"。
做过定制项目的都懂，项目里最让人头秃的两份文档：
- 售前标书：还没写一行代码，先把系统架构、功能设计、数据库设计、技术路线全写出来。以前我憋一个标书技术方案，从整理需求到画架构图到写技术路线，至少一两周。
- 验收文档：用户手册、验收报告、运维手册。项目越大文档越厚，写代码可能三个月，写文档可能还要一个月。
但这两个月做项目的时候，我发现了件事：文档不应该是"写"出来的，是"长"出来的。
二、文档的原材料，其实一直都在
我以前写文档是这么干的：项目做完了，坐下来，从零开始回忆"我做了个什么系统"，然后一个字一个字往外挤。
现在我是这么干的：把项目过程中已经产出的东西直接变成文档。
关键在这句话：测试产出本身就是文档的原材料。
- 测试用例 = 用户操作手册的目录。每个用例就是一步操作：进哪个页面、点什么按钮、预期出现什么。
- 测试截图 = 手册里的配图。用例对应的截图放进去，图注都不用重写。
- 测试报告 = 验收文档的底稿。测了什么、通过率多少、发现过哪些问题、怎么修的，全在里面。
以前这些材料是"过程产物"，交付完就躺在 SVN 里吃灰。现在我让它们变成最终交付物的一部分——不是额外花时间写文档，是测试跑完，文档自然就有了。
三、真实案例：291 条用例是怎么变成一份测试总报告的
这个项目的测试做了 17 个子阶段、291 条用例、60 张截图。每个模块产出一套东西：执行计划、测试用例、测试脚本、测试报告、测试截图。
如果你觉得这只是"测试"，那我换个说法——这套东西本身就是一份 60 页的验收材料，只是还没组装。
阶段跑完后，我让 AI 把 17 份模块测试报告汇总成一份《测试总报告》：
综合能源管理系统 — 测试总报告 v2
一、总体结果
| 测试阶段 | 17个 |
| 测试用例总数 | 291 |
| 通过 | 291 |
| 通过率 | 100% |
| 截图总数 | 60张 |
二、各阶段详情 # 17 个子阶段，每阶段的用例数/截图数/边界覆盖
三、缺陷清单 # 2 个 BUG：编号、严重程度、问题、状态
四、阶段5测试要点 # 数据采集引擎（Modbus TCP + MQTT）的测试重点
五、结论 # 291条全部通过，2个缺陷已修复并复验
这份报告不是我逐字写的。是 AI 从 17 份模块报告里汇总的——我负责检查数字对不对、结论准不准。
同理，给操作员看的用户手册，就是把测试用例按"操作步骤"改写，把测试截图插进去。给验收专家看的验收文档，就是把测试报告按"验收条款"重新组织。
你写文档花的时间，从"从零憋内容"变成了"审 AI 汇总的内容"。 省下来的是体力，没省掉的是判断。
四、另一种文档：标书，从需求直接生成
测试类文档是"从过程产物长出来"的。标书是另一种——它是从需求直接生成的，一个字节代码都还没写。
这个项目签下来之前，我干的事是：把客户发来的原始需求文档扔给 AI，让它生成标书的技术部分。
结果 AI 输出的是：
# 投标文件（技术部分）
# 项目概述 # 客户是谁、面临什么问题（数据孤岛、人工抄表…）
# 建设目标 # 消除数据孤岛、实时监控、指标管理、智能报表…
# 总体设计 # 系统架构、功能架构、部署架构
# 数据库设计 # 15 张表的结构说明
# 原型页面说明 # 每个页面长什么样、有什么功能
从需求到"项目概述 + 建设目标 + 总体设计 + 数据库设计"，AI 直接给出成型的结构。我做的不是从头写，是核对：技术路线对不对？数据库选型是不是客户要的国产化？功能范围有没有漏？
以前写标书技术方案，"憋两周"不是夸张——是整理需求、画架构图、定技术路线，全是重复劳动。现在原始需求进，标书草稿出，半天微调就完事。
五、AI 写文档的坑：数字会编，风格会歪
写文档让 AI 干，最爽的是它快，最怕的是它编。这半年踩过的坑，条条要人把关：
5.1 AI 会编数字
让 AI 汇总测试报告，它可能把 291 条用例写成 290，或者给某个模块填一个"通过率 98%"——因为上一个模块是 100%，它觉得这个模块也该有点"真实感"。
文档里的每一个数字都必须人工核对。 尤其是汇总类文档——AI 不会撒谎，但会"推断"，而文档里的数字一旦错了，验收时是要出问题的。
5.2 文档是有读者的
- 标书是给甲方看的——要正式、要讲清楚你解决了什么问题
- 用户手册是给操作员看的——要口语、要一步步教
- 测试报告是给验收专家看的——要严谨、要可追溯
AI 默认输出一种"四平八稳的技术文档"腔。你让它生成用户手册，它写得跟标书一样正式；你让它写标书，它可能太口语。读者不同，腔调必须不同，这个 AI 判断不了，只有你知道谁在看。
5.3 敏感信息过滤
给 AI 的原始材料里，经常混着不该出现在对外文档里的东西——内部模块的临时名字、业务细节、还没定稿的数据。
AI 会原封不动抄进去。"什么能写、什么不能写"这个边界，只有你划。
六、写文档的最高境界，是不写文档
把文档交给 AI 这几个月，我的体会是：
文档不是写出来的，是长出来的。 项目的过程产物——需求、用例、截图、报告——本身就是文档的半成品。你需要的不是"再写一遍"，是"组装一遍"。
但组装这件事，AI 也只能做一半：
- AI 负责"生成"——汇总报告、改写手册、起草标书，又快又全
- 你负责"把关"——数字对不对、腔调对不对、敏感信息有没有漏
跟第五篇里说的一样：质量靠验收，不靠生成。 写代码是这样，写文档也是这样。
以前我写文档，最怕的是"没东西可写"。现在最怕的是"AI 把它写得太满"——满到我看不出哪里是它编的。
所以别再问"能不能让 AI 写文档"了。能，但你要坐在它旁边，盯着数字，划着红线。
下一篇预告：AI 在一个真实项目里翻过的坑，我记了 265 行
