AI编程越热，文档需求越值钱：TypeDOM如何用类型系统管好文档

大概一年前，我把团队里所有能跑通的AI文档流程收敛成了一个内部编码体系，起了个名字叫TypeDOM。名字没别的意思，就是把“文档需求”当成一种可以管理的类型系统来看待——需求文档、PRD、测试用例、技术设计、接口说明……每类文档都有固定的Schema、固定的验收标准、固定的AI角色和固定的产出格式。TypeDOM这个项目做完之后，我最大的收获反而不是省了多少工时，而是彻底想明白了一件事：AI编程越热闹，文档需求越值钱。模型能替你写代码，但没法替你决定“要写什么”，文档恰恰是那个“要写什么”的唯一载体。

如果你是AI产品经理、技术负责人、AI应用开发者，或者团队正在引入AI编程工具但还没把“文档”这个环节理顺，这篇文章应该对你有用。下面我会把TypeDOM这套方法拆开来讲：AI在文档生命周期里到底能做哪些事、哪些事绝对不能交给它、一条从模糊需求到PRD再到测试用例的完整流水线长什么样、以及幻觉、成本、团队落地这些真实问题怎么处理。不绕弯子，直接上干货。

1. 为什么AI越强，文档需求反而越值钱

先说一个很反直觉的现象：很多团队引入AI编程之后，第一件事就是把文档砍了。理由是“AI看代码就能懂需求，写文档浪费时间”。我见过不止一个团队这么干，几个月后无一例外开始返工。原因非常朴素——AI编程工具确实能读懂代码，但它读不懂“人脑子里那个没写下来的需求”。

1.1 文档被砍之后，需求去了哪里

需求不会因为文档被砍就消失。它只是换了一种更隐蔽的方式存在：散落在IM聊天记录里，存在于白板照片里，藏在某次评审会的录音里，甚至只在某个核心开发者的脑子里。等到AI按代码库现有逻辑“合理”地实现了一个功能，产品经理一看：这不是我要的东西。这时候返工的成本，比写文档高出一个数量级。

更麻烦的是，AI有一个特性——它特别擅长一本正经地实现一个不存在的需求。你说“给用户加一个会员到期提醒”，模型真的会生成完整的邮件模板、定时任务、数据库字段。但如果需求文档里没写清楚“到期前三天提醒、只提醒付费用户、提醒频率是一天一次”，AI产出的代码就是无根之木。文档在这里起的作用不是“记录”，而是“约束”。

1.2 TypeDOM做了什么：把文档当类型系统来管理

TypeDOM的核心思路，是把每一种文档都定义成一个“类型”。写过代码的人都懂类型系统的好处——变量是什么类型、有哪些字段、哪些值是合法的，编译器帮你兜底。文档也一样：一份PRD应该有哪些章节，每个章节放什么内容，验收标准怎么写，术语表用什么词，这些都是可以提前定义好的。

有了类型定义之后，AI生成文档就不再是“自由发挥”，而是“按Schema填表”。哪怕模型输出的文字水平参差不齐，结构一定是稳定的、可校验的。这带来的直接好处有三个：

• 文档的结构稳定，评审和阅读的人不需要重新适应；
• AI可以按同一套Schema反复重写、局部修改，不会改一处坏一处；
• 文档可以被“校验”，哪些章节缺失、哪些字段为空，机器能自动标出来。

我当时做TypeDOM的时候，第一件事不是选模型，而是拉了一份公司所有文档类型的清单，逐个定义Schema。这个过程本身就让团队重新审视了一遍：原来我们有这么多种文档，原来很多文档的内容是重叠的，原来有些文档根本没人看。

1.3 全景地图：AI在文档生命周期里的五个位置

顺着类型系统往下走，TypeDOM把AI介入文档的方式收敛成五个固定位置：

1. 需求采集与澄清：用AI把一句话需求拆成问题清单，逼着业务方把模糊描述说清楚；
2. 文档生成：按Schema生成PRD、技术方案、测试用例等初稿；
3. 文档评审：用另一个AI角色专门找文档里的逻辑漏洞、前后矛盾和缺失项；
4. 文档到代码的衔接：将PRD中的验收标准转换为AI编程工具可理解的描述，减少编码阶段的歧义；
5. 文档运维与知识沉淀：把历史文档变成问答机器人、新人培训资料、跨项目复用资产。

这五个位置不是一上来就全部铺开。刚开始我把1、2、3做通，4靠人工衔接，5是后续慢慢积累出来的。很多人问“AI能不能直接帮我写完整文档”，我的回答是：别贪多，先从前三个位置开始，跑通一条线再扩展。

2. 先盘家底：哪些文档任务适合交给AI，哪些必须人肉

不要一上来就问“AI能不能做文档”，要先问“我手里有哪些文档任务，每一件都适合AI做吗”。我把团队常见的文档任务拉了一张表，逐个试了一遍，结论很有参考价值。

2.1 适合AI的文档任务清单

经过实测，下面这些任务交给AI的性价比最高，基本上可以放心下放：

实际跑下来，收益最大的是“测试用例生成”和“一句话需求拆解”。前者省的是测试工程师的时间，后者省的是产品经理反复追问的时间。这两个任务有一个共同特点：重复性高、模板化强、判断门槛低，AI的容错空间大，人工复核成本低。

2.2 不适合AI的任务清单（以及为什么）

有适合的就有不适合的。我的经验是，下面这类任务别交给AI，至少不能让它独立完成：

• 战略决策类文档：比如“下个季度要不要做这个方向”的立项报告。这类文档的核心是价值判断，AI能帮你整理信息和风险点，但最后的拍板必须是人。
• 涉及人员评价、组织调整的文档：AI对人际关系的理解是缺失的，它给出的建议往往“逻辑正确但政治不正确”，容易在团队里引发问题。
• 格式极其严格、法律责任明确的文书：在没有人工逐字审核的情况下，AI生成的法律文书、合规文档风险太大，一个措辞差异可能带来完全不同的后果。
• 需要团队共识的会议纪要：AI能把发言整理清楚，但“大家达成一致的决定”这种东西，必须由参会人自己确认，AI替代不了。

一句话总结：AI适合做“信息加工”，不适合做“价值判断”。凡是需要人承担责任、做出选择的文档环节，AI都只能当参谋，不能当决策者。

2.3 用任务盘点结果反推工具选型

盘完任务之后，下一步是根据任务的重复频率和风险等级来选工具。我当时的分类逻辑是这样：

• 高频、低风险：比如Release Notes、简单FAQ，直接全自动跑，定时任务生成，人工只抽检；
• 高频、高风险：比如PRD、测试用例，必须人机协同，AI生成初稿，质量闸门里的“评审Agent”过一遍，产品经理最终签字；
• 低频、按需：比如专利交底书、竞品分析，用现成的对话式AI工具按需生成就行，不需要单独搭流程。

这个分类决定了TypeDOM的建设优先级。先做高频高风险的，因为它最值钱；再做高频低风险的，因为它最容易跑通；低频的反而不用急着沉淀成系统，用通用AI工具临时处理就够了。

3. 搭一条能跑的AI文档流水线：角色、模型与工具编排

有了任务清单，下一步是搭流水线。TypeDOM里的每一条文档流水线都由三个固定角色构成。很多同事一开始不理解为什么要拆三个角色，认为“开一个对话窗口让它直接写不就完了”，实际上拆开之后效果完全不同。

3.1 三个固定角色：分析师、撰写者、审核者

第一个角色叫“文档分析师”（Analyst）。它的职责是拆解任务、生成问题清单、梳理输入材料。比如你丢给它一句“我们要给ERP加一个跨部门单据流程”，它不会直接写PRD，而是先输出一系列问题：跨部门流程涉及哪些单据类型？审批节点由谁定义？超时未审批怎么办？异常退回怎么处理？这些问题会由人工确认后进入下一阶段。

第二个角色叫“撰写者”（Writer）。它拿到确认过的问题清单、业务背景、以及目标文档类型的Schema，输出结构化初稿。这个角色最核心的约束是“只按Schema写，不自由发挥”，上下文里没提到的信息，一律用“待确认”标记，不能脑补。

第三个角色叫“审核者”（Reviewer）。它专门找文档里的问题：前后表述不一致、字段缺失、验收标准不可测试、逻辑冲突、以及幻觉内容。审核者的输出不是“重写文档”，而是“问题列表 + 修改建议”，由人来决定改还是不改。

三个角色串起来的流程是：分析师产出问题清单 → 人确认 → 撰写者产出初稿 → 审核者产出问题列表 → 人决定修改方向 → 撰写者按修改意见迭代。这个编排本质上把“人机协作”的每个环节都固定下来了，每道缝里都有人工确认的点，不会出现AI一口气写到底、人一看全不对的情况。

3.2 模型选型与本地部署的取舍

关于模型选型，TypeDOM初期做了一个简单的分流策略：云端API负责复杂推理、长文档理解、结构生成；本地模型负责隐私敏感内容、格式转换、术语一致的校验任务。

云端API的优势是聪明，但成本高、数据出域。当前主流的Claude、GPT、DeepSeek这类模型，在需求拆解和PRD结构化生成上表现都不错，我观察下来长文档一致性和中文写作质量是选型的关键维度。国产模型在中文场景的表现已经追得很近，而且价格优势明显，适合文档量大、对成本敏感的场景。

本地部署模型则用于敏感数据场景。很多公司对需求文档非常敏感，不允许发送到外部API。这种情况下我建议用Ollama这类工具在内部服务器或本地工作站跑一个7B到14B的量化模型，专门做术语校验、格式转换这类逻辑简单但数据敏感的任务。之前在带NPU的AMD AI PC上试过跑Ollama，像Ryzen AI 9 HX 370这一代平台，驱动装好之后用ollama ps看模型是否加载到GPU上，如果发现推理速度慢、进程停留在CPU，先检查Ollama后端版本和显卡驱动，再把OLLAMA_GPU_LAYERS这类环境变量调一下，很多时候能直接把模型调度到GPU上。不过要提醒一句：本地小模型的复杂推理能力明显弱于云端大模型，让它写整份PRD会吃力，但做“提取术语表”“判断章节完整性”这类机械任务完全够用。

3.3 提示词资产的版本化管理

流水线跑起来之后，有一个问题会很快浮出水面：提示词散落在各人手里，张三调出了一版好用的PRD提示词，李四不知道，自己又花两天调了一版。TypeDOM把提示词当成代码来管，每个角色的提示词都是一个独立的prompt文件，放在Git仓库里，带版本号、变更记录和效果备注。

每次调整提示词，都要先小范围验证，再同步到团队。仓库里每份提示词都配一个“已知坑”清单，比如“撰写者提示词里必须强调不得使用未确认的业务词汇，否则AI会生造术语”“审核者提示词需要明确要求输出问题优先级，否则它会把低风险问题堆满整页”。

这一步是整个项目里最容易被忽略但最关键的环节。模型会换版本、提示词会被迭代，但沉淀下来的提示词资产是团队的长期竞争力。我后来招人做文档流程时，第一件事就是让他读提示词仓库的历史变更记录，因为这比读文档更能理解团队的真实业务。

4. 从文档需求到PRD：一个完整产出的复盘

光讲架构太空了，我用一个最近在TypeDOM里跑通的真实场景来复盘完整流程。背景很简单：业务方提了一句“我们要给ERP加一个跨部门单据流程，走线上审批”，然后就没有然后了。一句话需求、没有背景材料、没有流程图、没有明确的审批层级。正好拿来做全流程演示。

4.1 第一步：用分析师角色把一句话需求拆成问题清单

分析师角色的提示词大致长这样（这是从TypeDOM提示词仓库里摘出来的精简版）：

text复制你是一名资深的ERP产品分析师。用户提出了以下原始需求，请基于该需求生成一份问题清单。

原始需求：我们要给ERP加一个跨部门单据流程，走线上审批。

要求：
- 问题必须覆盖：业务场景、单据类型、发起人、审批节点、审批规则、超时处理、异常退回、权限控制、通知方式、数据统计。
- 每个问题必须给出选项式的候选答案，方便用户快速确认。
- 你的输出只包含问题清单，不要展开任何方案设计。
- 问题回答不出来的，标记为“待确认”，不要自行假设。

这一步的输出是一份十几行的清单，选出几个有代表性的问题就是下面这样：

• 跨部门单据流程涉及哪些单据类型？（采购申请、费用报销、合同审批、其他）
• 审批节点如何定义？（按部门层级固定审批、按单据金额动态审批、按角色自定义审批）
• 超时未审批如何处理？（自动通过、自动催办、升级到上级、保持待处理）
• 单据被退回后，发起人是否可以修改后重新提交？（可以修改重提、只能作废重建）

这份清单发给业务方确认，半小时内就收回了所有答案，而以往这个“把需求聊清楚”的阶段可能要拖一两周。

4.2 第二步：用撰写者角色生成结构化PRD初稿

拿到确认的问题清单后，撰写者开始按PRD的Schema生成初稿。TypeDOM为PRD定义了类似下面的结构（这里是简化版）：

json复制{
  "prd": {
    "背景与目标": ["业务背景", "要解决的问题", "成功指标"],
    "名词定义": [],
    "用户角色": [],
    "功能需求": [
      {
        "编号": "FR-001",
        "名称": "",
        "描述": "",
        "触发条件": "",
        "业务规则": [],
        "优先级": "P0/P1/P2",
        "验收标准": []
      }
    ],
    "非功能需求": [],
    "依赖与风险": [],
    "待确认项": []
  }
}

关键点是，Schema里每一项都不能为空。如果业务方没有提供足够信息，撰写者必须把该字段标为“待确认”，而不是自己编一个合理答案。这一步是防止幻觉最重要的拦水坝。

初稿生成后，我看到它有一条功能需求写得特别到位：FR-003“单据撤回控制”，它根据业务方“可以修改重提”的回答，自动补充了“已审批通过的节点不可修改、只能作废重建”这个约束，并明确标注了信息来源于确认过的问题清单。好的AI文档生成不是凭空写，而是像拼乐高一样把确认过的信息块拼成完整文档。

4.3 第三步：用审核者角色找漏洞

初稿交给人工之前，先交给审核者角色过一遍。审核者提示词的核心要求是这样：

text复制你是一名文档评审专家。请检查PRD中是否存在以下问题：
1. 逻辑矛盾：前后章节对同一规则的描述是否不一致。
2. 字段缺失：Schema中必须填写的章节是否有遗漏。
3. 验收标准不可测试：验收标准是否足够具体、可以验证。
4. 未确认信息被写成事实：是否有“待确认”信息被当作真实规则输出。
5. 业务漏洞：是否存在明显缺失的边界场景（例如并发提交、重复提交、权限隔离等）。

输出格式：问题编号、问题描述、所在章节、严重程度（高/中/低）、修改建议。

它跑完一遍，找出了三个人工初稿看漏的问题，其中一个很典型：PRD里写了“审批超时会自动催办”，但没有定义催办频率和催办渠道；另一个是“跨部门单据”没有定义部门作为审批节点的“会签”和“或签”差异。这些细节如果人工硬想，也能发现，但有审核者角色之后，省掉的是“通读全文找矛盾”的时间，人只需要判断它找得对不对、怎么改。

4.4 第四步：用验收用例反向校验PRD

最后一步是生成测试用例，生成出来后不要直接交给测试团队，先做一次反向校验。所谓反向校验，就是把用例里出现的每一个操作步骤和预期结果，与PRD里的功能需求逐条对照。凡是PRD里没有支持的用例步骤，说明PRD写漏了；凡是PRD里的验收标准没有被任何用例覆盖，说明用例写漏了。这个闭环非常有效，它能把PRD的覆盖度问题自动暴露出来。

在ERP跨部门单据这个场景里，测试用例反向校验发现PRD漏掉了一个关键边界：审批人在多个待办中批量操作时，是否也适用超时升级规则。这个场景真实存在，但一开始谁都没想起来。要是按原文档直接开发，上线后大概率会在运营期被用户投诉。

5. 质量闸门：幻觉治理、评估指标与结果验收

AI生成文档，最让人不放心的问题就是幻觉。代码里出了幻觉，编译阶段还能拦一部分；文档里的幻觉没有编译器，会直接变成需求、变成设计、变成测试用例，一路传导到代码里。TypeDOM专门设了一道质量闸门来应对这件事。

5.1 幻觉是怎么混进文档里的

我复盘了团队所有踩过的幻觉坑，发现它们混进文档的路径基本逃不出三类：

第一类是“填补未知”。AI不知道答案，但它会编一个看起来合理的答案填进空位。比如问它“超时未审批怎么办”，一旦业务方没回答，它可能默认生成“自动通过”，这就是很危险的业务决策。

第二类是“数据编造”。这在竞品分析和市场分析里最常见，AI会编出看起来非常真实的行业报告、竞品功能清单、甚至具体的数据指标。凡是涉及外部事实的内容，必须人工二次核实。

第三类是“术语漂移”。AI在长文档里用词会不自觉地变化，一会儿叫“单据”、一会儿叫“申请单”，这对人来说很容易忽略，但下游开发人员会以为这是两个不同的实体。

5.2 我常用的三个降幻觉手段

针对这三类幻觉，TypeDOM里沉淀了三个手段，亲测有效：

手段一：限制数据来源，强制“只许用上下文里的信息”。所有生成类角色的提示词里都会写死这句话：“你的回答只能基于用户提供的上下文信息。上下文不存在的信息，一律输出为‘待确认’，禁止推测或补充。”这句话能够大幅压低第一类幻觉。

手段二：强制来源引用。凡是文档里的关键业务规则、数字、日期，生成时要求在括号里标注来源。比如“到期前三天提醒（来源：产品经理2024-05-10确认）”。这样做有两个好处：人工复核时可以快速溯源；文档被质疑时能直接找到责任环节。

手段三：两步走，先起草后自查。所有重要文档生成之后，审核者角色必须独立跑一遍自查，它的任务就是专门挑“这段看起来像模型编的”内容。把“写”和“查”拆成两个角色，比让同一个模型边写边查有效得多——因为同一个模型很容易对自己的输出过于自信。

除了这三个手段，还有一句最重要的：所有AI生成的文档，最后必须有一个真实的人签字确认。不要把AI当作者，要把它当“无限勤快但偶尔撒谎的实习生”。文档可以写得快，但责任在人的肩膀上。

5.3 量化的验收指标表

质量闸门不能只靠感觉，TypeDOM用下面这些指标来验收AI文档质量，每份文档生成后都会跑一遍评分：

这几个指标不用每个都追求“完美”，但“可测试性”和“可追踪性”这两项我会卡得很严格。因为这两项直接决定了文档能不能被下游使用，如果验收标准测不了，那这份PRD本质上只是一堆漂亮的废话。

5.4 建立持续回归的“黄金文档集”

质量闸门还有一个容易被忽略的长期机制：回归测试。TypeDOM维护了一个“黄金文档集”，里面放着十几份经过人工反复修改、确认过的高质量文档，覆盖了团队最主要的文档类型。每次调整提示词、换模型、改Schema时，都拿这些黄金文档跑一遍，看看新配置生成的文档质量有没有退化。

这个机制救过我好几次。有一次我把撰写者的提示词改得更“简洁”，结果生成出来的PRD把验收标准全部压缩成了模糊描述，可测试性大幅下降。如果没有黄金文档集回归，这个改动会静默上线，影响后面所有PRD的质量。现在团队里已经形成习惯：任何提示词变更，先跑黄金集、再小范围上线、最后才全量推广。

6. 落地避坑：团队渗透、知识复用和成本账

很多技术方案死在最后一步：做出来了，团队不用。TypeDOM自己也经历过一轮尴尬期，前两周几乎没人主动用，后面是靠几个方法慢慢渗透开的。

6.1 团队不愿意用AI文档流程的常见原因和对策

第一，大家担心AI生成的文档是“AI味”的，读起来别扭。解法是给生成器喂团队自己的写作风格样本。TypeDOM的每个文档类型都配了1-2份团队历史认可的文档作为风格示例，让模型模仿团队的用词习惯、章节节奏。这是最有效的一招。

第二，大家觉得“改AI生成的东西还不如自己写”。这里的关键是提高初稿质量，而不是提高模型智商。我后来发现，初稿质量差的根源往往不是模型不够聪明，而是输入信息不完整。只要前面的“分析师”角色把问题清单拆得足够细，撰写者生成的初稿就能达到“大方向正确、小细节需要修”的水平，改起来比自己从空白写起快很多。

第三，流程成本太高。如果每份文档都要走五个环节，小需求就没人愿意用。TypeDOM的应对是分两套流程：重要文档走全流程，轻量文档走简化流程——只保留分析师和撰写者，审核交给人工。

另外，团队里一定要有人承担“文档质量守护者”的角色。不是说他本人去写所有文档，而是他负责维护Schema、更新提示词、组织双周一次的文档评审会。评审会不用长，每次30分钟，过一份AI生成的文档，大家提意见，守护者记录下来反哺提示词和Schema。这个循环跑起来之后，AI文档的质量会肉眼可见地持续上升。

6.2 成本账：credits、Token用量和真正的省钱点

说到成本，很多团队对“AI辅助文档”犹豫是因为怕花钱。实际上文档类任务的Token消耗比很多人想象中低。我算了一笔账，一份标准的ERP改造PRD，包含需求拆解、初稿生成、两轮评审迭代，总Token消耗大约在10万到15万之间。这个量级在云端API上折算下来也就是几块钱人民币，对比产品经理和测试梳理需求的时间成本，基本可以忽略。

但“credits”这个坑要单独说。AI平台里经常能看到credits或叫积分、点数的概念，它不像Token那样直观。不同平台的兑换规则不一样，有的平台会把高级模型、长上下文、联网检索分别计费，实际消耗可能比你以为的快很多。我的建议是：上线前先拿小批量试跑，看一份文档实际扣了多少credits，再估算月成本，不要轻信平台的宣传页。

真正的省钱点在于减少无效生成和无效人工。无效生成指那种输入信息不完整、生成出来全是废话、还得重来的场景，用分析师角色拦住；无效人工指花两小时读AI生成的冗长文档，用更严格的Schema和更短的输出粒度解决。我常用的一个技巧是让撰写者按“章节碎片”输出，而不是一次生成整篇，每个小片段人工确认过再生成下一段，既省Token又避免大段返工。

6.3 本地部署小模型的适用场景和注意点

最后一个落地问题是数据安全。需求文档、技术方案这类东西往往涉及商业敏感信息，很多公司不允许直接发到外部API。前面提过用Ollama这类工具本地部署模型可以解决这个问题，但这里必须把适用边界说清楚。

本地部署的适用范围是：格式转换、术语检查、模板填充、基于已有结构化数据的摘要。这些任务逻辑简单、对模型“聪明程度”要求不高，7B-14B的量化模型完全能胜任。但如果你让它做复杂的需求拆解、长文档跨章节一致性审核，效果会明显差一个档次。这种任务该用云端大模型就用，提前做好脱敏就行。

硬件上的经验是，如果本地机器带独立显卡或新一代AI处理器（比如Ryzen AI 9 HX 370这类），优先把模型调度到GPU/NPU上。装好Ollama之后用ollama ps看当前模型是否加载到GPU，如果一直在CPU上跑，先检查Ollama版本和显卡驱动是否匹配，再调整相关环境变量，实测下来同样一个模型，CPU和GPU的推理速度可能差好几倍。不过别指望NPU能扛住所有任务，复杂逻辑推理仍然需要云端大模型兜底。

最后再分享一点个人体会。TypeDOM做了一年，最大的感悟是：文档需求这件事的难点从来不是“写”，而是“定义清楚什么是合格的文档”。模型只是放大器，你把文档的Schema定义得越清楚，AI能发挥的空间就越大；反过来，如果连你自己都说不清一份PRD必须包含哪些内容、验收标准应该怎么写，那再强的模型也帮不了你。

有一个小技巧我一直用到现在——AI生成PRD初稿之后，强制在文档顶部加一段“来源说明”：每个关键业务规则后面标注它是来自业务方访谈、历史系统分析、还是假设。这个习惯大幅减少了跨部门沟通中的误解，也让审核者角色能更快定位问题。所有被标为“假设”的内容，在评审会上逐条过一遍，往往能揪出一半以上的需求盲区。文档写的不是字，是决策和边界，AI能帮我们把边界挖得更清楚，但最终拍板的人，永远是我们自己。