让AI生成的文档可审阅、可追溯，关键在于把模板拆成结构、字段、提示约束三层并对齐：结构层固定章节顺序，字段层为每条结论配置来源与责任人，提示约束层限定生成行为。三层对齐后，AI产出先进入待审阅状态，由指定角色逐项核对，确认来源与结论一致再定稿。本文适用于需求文档与会议纪要两类模板的设计。
要点总览（TL;DR）
- 把AI文档模板拆成结构、字段、提示约束三层：结构层固定章节顺序与每节回答的问题，字段层为每条结论挂来源与责任人，提示约束层限定AI的输入范围、输出格式与禁止项。
- 可追溯字段不必多，但来源位置、引用片段、生成方式、确认人、审阅状态应设为必填；依据强度等辅助字段可设为选填，用于提示审阅人关注证据薄弱处。
- 提示约束按角色边界、输入范围、输出格式、引用要求、禁止项五类分段编写，每条写成可核对的判断句，缺信息时要求标注待补充，无法定位来源时明确标注。
- 审阅流程区分起草者、领域审阅人、文档 owner 三类角色，初稿必填字段齐全才进入待审阅，关键结论逐条确认后才能定稿，驳回与返工保留记录。
- 上线前按结构覆盖、字段完整性、提示约束覆盖、流程明确到人、随机抽查可回溯五个维度逐项检查，未通过项视为阻断项，修正后再试用。
先定模板骨架：章节顺序与每节回答的问题
结构层解决的是“审阅人按什么顺序看、每节该看到什么”。做法是先按文档类型确定固定章节顺序，再为每节写明它要回答的问题、允许出现的内容类型，以及该节是否允许AI推断。章节顺序固定后，审阅人可以逐节对照，不必每次重新理解文档组织方式。
需求文档与会议纪要的骨架差异明显。需求文档围绕“要解决什么问题、做成什么样、如何验收”展开；会议纪要围绕“谁在什么会上决定了什么、后续谁做什么”展开。两类文档都应把事实陈述、AI推断、待确认项放在可区分的位置，避免推断内容混入事实段落。
| 章节名 | 该节回答的问题 | 内容类型 | 是否允许AI推断 |
|---|---|---|---|
| 背景与目标 | 这个需求来自什么业务问题，期望达成什么结果 | 事实陈述、引用材料 | 不允许，只能摘录与归纳原文 |
| 需求描述 | 系统需要提供哪些能力，边界在哪里 | 事实陈述、待确认项 | 允许提出拆解建议，须标注为建议 |
| 验收标准 | 用什么可观察的结果判断需求完成 | 事实陈述、待确认项 | 允许起草，须由领域审阅人确认 |
| 待确认问题 | 哪些信息缺失或存在分歧 | 待确认项 | 允许列出，不允许自行给出结论 |
会议纪要可采用“会议信息—议题与讨论要点—决议项—待办项—待确认项”的顺序。决议项与待办项必须能对应到具体发言或材料，讨论要点只做归纳。结构层确定后，字段层负责给每节中的结论挂上来源与责任人，提示约束层负责要求AI按这套骨架输出，三层由此形成对应关系。
字段设计：让每条结论都带来源与责任人
可追溯的核心是每条关键结论都能回答三个问题：来自哪里、谁提出、谁确认。字段设计围绕这三点展开，再补充状态与变更记录。字段不必多，但要保证关键结论的追溯链完整。
| 字段名 | 所属章节 | 必填/选填 | 取值规则 | 填写责任人 |
|---|---|---|---|---|
| 来源位置 | 全部含结论的章节 | 必填 | 原始材料的位置，如文档章节、会议时间点、工单编号 | 起草者 |
| 引用片段 | 全部含结论的章节 | 必填 | 支撑该结论的原文摘录，保持原意 | 起草者 |
| 生成方式 | 全部含结论的章节 | 必填 | 摘录、归纳、AI起草、人工补充之一 | 起草者 |
| 提出人 | 需求描述、决议项、待办项 | 必填 | 原始提出该内容的人或角色 | 起草者 |
| 确认人 | 全部含结论的章节 | 必填 | 对该结论负责确认的领域审阅人 | 领域审阅人 |
| 审阅状态 | 全部含结论的章节 | 必填 | 待确认、已确认、已废弃 | 领域审阅人 |
| 依据强度 | 需求描述、验收标准 | 选填 | 直接引用、多方一致、单一来源、AI推断 | 起草者初填，审阅人复核 |
| 变更记录 | 全部含结论的章节 | 必填 | 记录修改时间、修改人、修改原因 | 修改发起人 |
必填与选填的划分原则是：缺少该字段会导致结论无法回溯或无法追责的，设为必填；只影响阅读便利的，设为选填。来源位置、引用片段、确认人、审阅状态属于前者，依据强度属于后者。依据强度字段用于提示审阅人关注证据薄弱处，取值应限定在预设选项内，避免写成自由描述而失去比较意义。
状态字段需要配合变更记录使用。一条结论从待确认转为已确认，应记录确认人与确认时间；转为已废弃时，保留原结论与废弃原因，便于后续追溯为什么改。变更记录不覆盖历史，只追加条目。
提示约束怎么写：角色、输入、格式与禁止项
提示约束的作用是把模板规则转成AI可执行的指令，让输出天然带有可审阅的结构。建议按五类要素分段编写，每类给出明确句式，便于团队复用和修改。
- 角色与任务边界：明确AI只做整理与起草，不做需求判断或风险定级。示例句式：“你是文档起草助手，负责按给定模板整理材料并起草内容；对需求合理性、优先级和风险等级不作判断，遇到此类内容列入待确认问题。”
- 输入范围约束：只允许引用给定材料，缺信息时标注待补充。示例句式：“仅使用本次提供的材料作答；材料未覆盖的信息标注‘待补充’，并说明缺少哪类信息。”
- 输出格式约束：按模板章节与字段逐项输出，不合并、不省略字段。示例句式：“按以下章节顺序输出，每节包含指定字段；字段无内容时写‘无’并说明原因，不得省略字段。”
- 引用要求：每条结论附来源位置，无法定位时明确标注。示例句式：“每条结论后附来源位置与引用片段；无法在材料中定位来源的，标注‘来源待核实’，不得省略标注。”
- 禁止项：不编造数据、版本、人名与结论。示例句式：“不得生成材料中未出现的数据、版本号、人名和结论；不得将推断表述为事实。”
约束条目应写成可核对的判断句，避免“尽量准确”“注意质量”这类无法验证的表述。团队可以把上述五类要素做成固定段落，每次使用时只替换输入材料与文档类型，减少提示词随意变动带来的输出波动。
审阅流程：角色分工、状态流转与交付物
模板能否落地，取决于每个角色在什么时点审什么、交付什么。建议至少区分三类角色：起草者负责整理材料、运行模板、补齐来源字段；领域审阅人负责核对结论与来源是否一致、确认业务准确性；文档 owner 负责整体质量、状态推进与最终定稿。
| 角色 | 主要动作 | 负责的状态 | 交付物 |
|---|---|---|---|
| 起草者 | 整理输入材料，按模板生成初稿，填写来源与提出人字段 | 将文档置为待审阅 | 带字段的初稿、待确认问题清单 |
| 领域审阅人 | 逐条核对结论与来源，确认或驳回，填写确认人与审阅状态 | 待确认转为已确认或退回 | 审阅意见、确认记录 |
| 文档 owner | 检查字段完整性，处理驳回项，推进定稿 | 已确认转为定稿 | 定稿文档、变更记录 |
状态流转的触发条件要写清楚：初稿完成且必填字段齐全，才进入待审阅；领域审阅人逐条确认后，该条结论转为已确认；全部关键结论确认完毕，文档 owner 才能定稿。驳回时记录驳回原因与退回章节，返工后重新进入待审阅，历史记录保留。
会议纪要与需求文档的审阅角色可以不同。会议纪要通常由会议主持人或记录人确认决议项与待办项，责任人确认与自己相关的待办；需求文档则需要领域审阅人确认需求描述与验收标准，文档 owner 统筹定稿。角色划分按文档影响范围确定，影响越大的文档，确认环节越应明确到人。
当模板在团队中稳定运行后，文档状态流转、审阅交接与变更记录需要有承载的地方。ONES 的 Wiki 与工作项管理可用于承载文档页面与需求条目，ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，其知识问答与任务执行基于 ONES 权限体系，输出过程可追踪、结果可审计。将模板字段与这些能力配合使用时，建议先核验模板结构、字段和提示约束在具体环境中的配置方式，以及审阅状态与变更记录的实际呈现，再决定落地范围。
两个示例：需求文档与会议纪要模板落地
以下片段为演示情景，用于说明结构、字段与提示约束如何配合，不代表真实项目数据。
需求文档示例：一条需求的字段填写
| 项目 | 内容 |
|---|---|
| 需求描述 | 支持按项目导出测试用例清单 |
| 来源位置 | 用户访谈记录 2024-05-10，第 3 节 |
| 引用片段 | “希望能把用例导出来，方便和外部团队对齐” |
| 生成方式 | AI起草，人工归纳 |
| 提出人 | 测试负责人 |
| 确认人 | 产品经理（待确认） |
| 审阅状态 | 待确认 |
| 依据强度 | 单一来源 |
| 待确认问题 | 导出格式与字段范围未明确，标注“待补充” |
这条需求中，“支持导出”是材料中可定位的事实，“导出格式待定”是待确认项，AI 提出的“建议支持 CSV 与 Excel 两种格式”应单独标注为建议，不能写入需求描述正文。审阅人核对时先看来源位置能否打开、引用片段是否支持结论，再判断是否确认。
会议纪要示例：决议项与待办项
| 类型 | 内容 | 责任人 | 来源位置 | 状态 |
|---|---|---|---|---|
| 决议项 | 本期先支持用例清单导出，格式范围下期再定 | 产品经理 | 会议录音 12:30 | 已确认 |
| 待办项 | 整理导出字段清单初稿 | 测试负责人 | 会议录音 15:10 | 待确认 |
| 待确认项 | 外部团队对格式的具体要求尚未收集 | 产品经理 | 会议录音 18:05 | 待确认 |
两个示例的共同规律是：结论与来源成对出现，AI 推断单独标注，待确认项有明确归属人。迁移到其他文档类型时，只需替换章节骨架与字段取值，三层配合的方式保持一致。
完成检查：模板上线前的核对清单
模板上线前，建议按以下清单逐项判断，每项给出通过标准，未通过即视为阻断项，修正后再上线。
| 检查维度 | 检查项 | 通过标准 | 是否阻断 |
|---|---|---|---|
| 结构 | 章节是否覆盖该类文档的必要问题 | 每节都有明确要回答的问题和内容类型 | 是 |
| 结构 | 事实、推断、待确认项是否有区分位置 | 三类内容在骨架中可区分 | 是 |
| 字段 | 关键结论是否都有来源与责任人字段 | 来源位置、引用片段、确认人为必填 | 是 |
| 字段 | 状态与变更记录是否可追加 | 状态取值固定，变更记录保留历史 | 是 |
| 提示 | 约束是否覆盖输入范围、格式与禁止项 | 五类约束均有可核对句式 | 是 |
| 流程 | 审阅角色与状态流转是否明确到人 | 每个状态有触发条件与负责人 | 是 |
| 抽查 | 随机抽取生成内容能否回溯到原始材料 | 抽查样本的来源位置均可定位 | 是 |
抽查验证是最后一道关口：从近期生成内容中随机抽取若干条结论，按来源位置回到原始材料，确认引用片段支持该结论、确认人真实存在、状态与实际一致。抽查中发现无法回溯的条目，应回到字段设计和提示约束中找原因，而不是只修改单条内容。完成以上检查后，模板即可进入试用，并在试用期持续记录驳回原因，作为下一轮优化的输入。
常见问题
模板里的字段是不是越多越好？哪些字段可以省？
字段数量以追溯链完整为准，不必求多。判断标准是：缺少该字段会导致结论无法回溯或无法追责的，设为必填；只影响阅读便利的，设为选填。来源位置、引用片段、确认人、审阅状态属于前者，依据强度这类用于提示证据强弱的字段属于后者。字段过多会增加填写负担，反而让起草者用“无”“待补充”敷衍填写，削弱可追溯性。
AI 在生成时提出了模板里没有的内容，应该怎么处理？
先判断内容性质。属于材料中可定位的事实，补充来源位置与引用片段后保留；属于推断或建议，单独标注为建议，不写入事实段落；属于材料未覆盖的信息，列入待确认问题并写明缺少哪类信息。提示约束中应提前写明“不得将推断表述为事实”，审阅时把这类内容作为重点核对项。若某类额外内容反复出现，说明模板章节或字段设计有缺口，应回到结构层补充，而不是每次人工删除。
会议纪要和需求文档能否共用一套模板？
可以共用同一套设计方法，章节骨架与审阅角色需要分别设定。会议纪要围绕会议信息、议题与讨论要点、决议项、待办项、待确认项展开，通常由会议主持人或记录人确认决议项，责任人确认与自己相关的待办；需求文档围绕背景与目标、需求描述、验收标准、待确认问题展开，需要领域审阅人确认需求描述与验收标准。字段层可以复用来源位置、引用片段、确认人、审阅状态等通用字段，按文档类型调整必填范围。
审阅时如何快速判断一条结论是否可信？
按字段顺序核对：先看来源位置能否打开并定位到原始材料，再看引用片段是否真的支持该结论，然后看生成方式标注的是摘录、归纳还是AI起草，最后看确认人是否具备相应职责、审阅状态是否与实际一致。依据强度字段可以帮助排序，单一来源或AI推断的条目优先复核。抽查阶段发现无法回溯的条目，应回到字段设计和提示约束中找原因，避免只修改单条内容。
模板上线后，如何持续发现提示约束的漏洞？
把试用期的驳回原因记录下来，按类型归类：来源缺失、引用不匹配、推断混入事实、字段遗漏、格式偏离。某一类反复出现，说明对应的约束条目表述不够可核对，应改成明确的判断句并补充示例。同时定期抽查生成内容能否回溯到原始材料，抽查结果作为下一轮修改模板结构和字段的依据。约束条目修改后保留版本记录，便于对比调整前后的输出差异。
