ASPICE过程文档的编写起点是过程活动，模板只承担承载作用。先确定要覆盖的过程域和过程目的，把每个过程目的拆成可执行的活动，再为每项活动定义输入、输出、负责人和完成标志，文档才能与研发实际对得上。本文按“定范围—拆活动—分角色—写范例—做检查”的顺序展开，覆盖过程活动说明、工作产品模板和证据记录三层内容，不涉及控制算法、硬件设计细节与评估评级结论。
要点总览（TL;DR）
- 编写起点是过程活动：先确定覆盖的过程域与过程目的，再拆活动、定输入输出，模板只承担承载作用。
- 过程文档分三层：过程活动说明、工作产品模板、证据记录，三层逐层落地，缺一层都会让评审失去判断依据。
- 按四步编写：梳理过程目的与预期结果、拆解活动并标注角色、定义输入输出与完成标志、映射到工作产品和证据。
- 角色分工落到谁写、谁审、谁用、谁维护，评审分内容评审与执行评审两级，版本与变更按文档层次划分责任。
- 发布前用逐项清单、双向追溯和抽样评审检查，活动缺失、关键活动无证据、完成标志不可判断、裁剪无记录属于阻断项。
先定过程域与文档骨架：ASPICE过程文档写什么
编写前先回答两个问题：这次要覆盖哪些过程域，每个过程域要证明什么。范围界定清楚了，文档才不会写成一套与项目无关的通用制度。常见的做法是以项目实际执行的过程域为起点，对照过程目的逐条确认，再决定文档写到什么颗粒度。
范围清单建议按过程域逐行列出四项信息：过程域名称与过程目的、本项目涉及的过程活动、对应的主要工作产品、可提供的证据类型。清单确认后再动笔，能避免写到一半发现某个过程域没有实际活动支撑。
过程文档通常分三层，每层解决不同问题：
| 层次 | 承载内容 | 最小内容要求 | 主要用途 |
|---|---|---|---|
| 过程活动说明 | 谁在什么时点做什么、依据什么规则、做到什么程度算完成 | 触发条件、步骤、角色、输入、输出、完成标志 | 指导执行，作为评审依据 |
| 工作产品模板 | 活动产出物的字段、格式与记录要求 | 必填字段、填写规则、示例、存放位置 | 保证产出物格式统一、信息完整 |
| 证据记录 | 实际执行留下的可检查记录 | 记录对象、时间、责任人、关联活动、评审结论 | 证明活动已按定义执行 |
三层之间是逐层落地的关系：活动说明定义要求，模板规定产出物形态，证据记录证明要求被满足。只写活动说明而缺少模板，产出物格式会因人而异；只收集证据而没有活动说明，评审时无法判断记录是否完整。
过程域与项目实际之间需要裁剪。裁剪的依据是项目类型、交付范围和已识别的过程风险，裁剪结论要写进文档，说明哪些活动适用、哪些活动以简化方式执行、理由是什么。裁剪记录本身也是文档的一部分，评审时能够解释“为什么这里这样写”。
从过程目的拆到活动：编写步骤与输入输出
拆解的目标是让每个过程目的都能落到具体活动上，并且每项活动都有可检查的产出。下面四步按顺序执行，每一步都给出输入、动作、输出和完成标志。
第一步：梳理过程目的与预期结果
输入是选定的过程域及其过程目的说明。动作是把每个过程目的转写为一句可判断的预期结果，例如“需求变更被评估、批准并传递到受影响的工作产品”。输出是一张过程目的与预期结果对照表。完成标志是每个过程目的都有对应的预期结果表述，且表述可以被验证。
第二步：拆解活动并标注角色
输入是上一步的预期结果。动作是把每个预期结果拆成若干活动，活动粒度以“一个角色在一段时间内能完成并留下记录”为准，同时为每项活动标注负责角色和参与角色。输出是活动清单，含活动编号、活动名称、所属过程目的、负责角色。完成标志是每项预期结果至少对应一项活动，每项活动都有明确负责人。
第三步：为每项活动定义输入、输出与完成标志
输入是活动清单。动作是逐项填写活动的触发条件、前置输入、执行步骤、输出物和完成标志。完成标志要写成可观察的状态，例如“评审记录已签署”“变更请求已关联到受影响需求”。输出是活动定义表。完成标志是每项活动的输入输出都能对应到具体工作产品，完成标志不含“基本完成”“大致符合”这类模糊表述。
第四步：把活动映射到工作产品和证据
输入是活动定义表。动作是为每项活动的输出指定工作产品模板，并说明该活动执行后留下什么证据、由谁在何时记录。输出是“活动—输入—输出—证据”对应表，也就是本节的核心交付物。完成标志是每项活动至少对应一份工作产品和一类证据，且证据能够被独立查阅。
| 活动编号 | 活动名称 | 输入 | 输出 | 证据 | 完成标志 |
|---|---|---|---|---|---|
| A-01 | 需求变更评估 | 变更请求、受影响需求清单 | 变更评估记录 | 评估会议记录与审批意见 | 变更请求已关联受影响需求并完成审批 |
| A-02 | 变更影响分析 | 变更评估记录、设计与测试关联信息 | 影响分析说明 | 分析记录及关联工作产品清单 | 受影响的设计、测试项已全部列出 |
| A-03 | 变更实施与验证 | 影响分析说明、更新后的工作产品 | 更新后的需求与验证记录 | 验证结果与关闭记录 | 变更关闭且验证结论可查 |
表中三行是演示情景，用于说明对应表的填写方式，实际活动应按项目选定的过程域展开。填写时保持编号稳定，后续评审和追溯都以编号为索引。
角色分工与文档交付物清单
文档编写职责不清，常见结果是过程负责人写完就归档，项目组照旧执行。分工要落到“谁写、谁审、谁用、谁维护”四个动作上，并与交付物绑定。
| 角色 | 编写职责 | 主要交付物 | 评审与批准 |
|---|---|---|---|
| 过程负责人 | 确定过程域范围、组织活动拆解、维护过程活动说明 | 过程文档范围清单、活动定义表、裁剪说明 | 组织评审，对文档整体一致性负责 |
| 项目负责人 | 确认项目适用活动、提供项目实际执行信息 | 项目裁剪记录、活动执行计划 | 参与评审，确认文档可执行 |
| 开发角色 | 按模板产出工作产品、记录执行证据 | 工作产品实例、活动执行记录 | 接受抽查，对记录真实性负责 |
| 质量角色 | 检查文档与执行的一致性、组织抽样评审 | 检查清单、评审记录、偏差与返工跟踪 | 出具评审结论，跟踪关闭情况 |
评审环节建议分两级：过程负责人组织内容评审，确认活动、输入输出和证据的完整性；质量角色组织执行评审，抽取实际项目记录核对文档是否被遵循。两级评审的记录都要留存，作为文档有效性的证据。
版本与变更责任按文档层次划分：过程活动说明由过程负责人维护，变更需经评审后发布；工作产品模板由过程负责人与质量角色共同确认；证据记录由产生该记录的角色负责，按项目归档，不随模板变更而改写。文档每次变更保留版本说明，注明变更原因、影响范围和生效时间，便于追溯历史执行依据。
文档进入研发管理工具承载时，可以把活动说明、模板和证据放在同一协作空间中，按项目组织页面并配置读写权限，让开发角色只维护自己负责的记录、质量角色保留检查入口。ONES Wiki 支持为不同角色配置读写权限，页面组可关联项目，需求与文档互相对应，文档中可嵌入任务进度与报表；页面版本可查看与回滚，适合过程文档多次修订的场景。工具承载的是编写、评审与版本管理动作，文档内容本身仍需按前述方法组织。
示例：一个过程活动的文档写法
以下示例演示“需求变更评估”这一活动的完整写法，背景设定为某项目在开发阶段收到客户需求变更，需要评估后决定是否纳入当前版本。示例为演示情景，用于说明写法，不代表特定项目实际记录。
活动说明的写法
活动描述先写触发条件：收到变更请求并完成登记后启动。再写步骤：确认变更内容与提出方、识别受影响需求、组织相关角色评估工作量与风险、形成评估结论并提交审批。角色写明负责角色为需求负责人，参与角色包括设计、测试与项目负责人。完成标志写为“评估结论已记录并经审批，变更请求状态更新为已评估”。
工作产品的字段与记录要求
对应工作产品为变更评估记录，必填字段包括变更编号、提出方与提出时间、变更描述、受影响需求清单、影响分析摘要、评估结论、参与评估人员、审批人与审批时间。记录要求是每个字段填写具体内容，受影响需求以编号关联，评估结论明确为纳入、推迟或拒绝，并附理由。
证据的评审与追溯
证据包括评估记录本身、审批意见和关联的需求变更状态。评审时从评估记录追到受影响需求，再从需求追回变更请求，确认双向关联完整；同时抽查审批时间是否早于变更实施时间，判断流程顺序是否符合定义。追溯断点即为偏差，需要补齐关联或说明原因。
可迁移的规律
这个写法可以迁移到其他活动：先写触发条件和完成标志，让活动有明确起止；再把角色写成负责与参与两类，避免责任模糊；工作产品字段围绕“谁、何时、依据什么、结论是什么”设置；证据设计成能被独立查阅和双向追溯的记录。按这个结构替换活动内容，即可形成其他过程域的活动文档。
完成检查：文档可用性与一致性核对
文档写完不等于可用。完成检查要回答两个问题：文档自身是否完整，文档与实际执行是否一致。建议在发布前和执行一段时间后各做一次。
逐项检查清单如下，每项给出通过标准：
- 活动覆盖：选定的每个过程目的都有对应活动，无遗漏、无孤立活动。
- 输入输出完整：每项活动都有明确输入和输出，输出对应到具体工作产品模板。
- 角色明确：每项活动标注负责角色，参与角色可识别。
- 完成标志可判断：完成标志写成可观察状态，不含模糊表述。
- 证据可查：每项活动至少有一类证据，证据能被独立查阅并关联到活动编号。
- 裁剪有记录：项目裁剪结论及理由已写入文档。
- 版本可追溯：文档有版本说明，变更原因与生效时间可查。
双向追溯检查分两个方向执行：从文档出发，任选若干活动，沿活动编号追到工作产品和证据记录，确认链路不断；从实际执行出发，抽取已完成的工作产品和记录，反查其对应的活动说明和模板，确认执行有依据。两个方向都通过，说明文档与执行基本对齐。
抽样评审用于发现文档与实际的偏差。抽样覆盖不同角色和不同过程域，重点看记录时间是否合理、审批顺序是否符合定义、证据是否与活动描述一致。发现偏差时先判断性质：记录缺失或关联断开的，要求补齐并复查；活动描述与实际做法长期不一致的，启动文档修订而不是简单补记录。
阻断项指不修复就不能发布或不能通过评审的问题，包括活动缺失导致过程目的无支撑、关键活动无证据、完成标志无法判断、裁剪无记录。出现阻断项时返工对应章节，返工后重新执行双向追溯检查。非阻断项可列入改进清单，在下一版本修订中处理，但需明确责任人和计划完成时间。
常见问题
项目只执行部分过程域，过程文档要不要把所有过程域都写全？
按项目实际执行的过程域来写，范围清单逐行列出过程域名称与过程目的、本项目涉及的活动、主要工作产品和证据类型。未涉及的过程域在裁剪说明中写明不适用及理由，评审时能解释清楚即可。把全部过程域都写一遍，容易产生没有活动支撑的文档，反而增加维护负担。
过程文档写完发布后，实际执行和文档对不上，应该改文档还是补记录？
先判断偏差性质。记录缺失或关联断开的，属于执行遗漏，要求补齐记录并复查；活动描述与实际做法长期不一致的，说明文档定义本身需要调整，应启动文档修订，按版本变更流程发布，而不是简单补记录掩盖差异。修订时保留变更原因、影响范围和生效时间，便于追溯历史执行依据。
工作产品模板和证据记录有什么区别，能不能合并成一份文档？
两者用途不同。工作产品模板规定产出物的字段、格式与填写规则，回答“应该记什么”；证据记录是实际执行留下的内容，回答“实际记了什么、由谁在何时记的”。合并后模板的规范作用会被实际记录冲淡，评审时也难以区分要求与执行。建议模板单独维护，证据按项目归档，模板变更不影响已归档的证据记录。
用协作工具承载过程文档，需要注意哪些配置？
重点是把活动说明、模板和证据放在同一协作空间中，按项目组织页面，并按角色配置读写权限，让开发角色只维护自己负责的记录、质量角色保留检查入口。文档版本要可查看与回滚，变更留说明。ONES Wiki 支持为不同角色配置读写权限，页面组可关联项目，页面版本可查看与回滚，适合过程文档多次修订的场景；文档内容本身仍需按活动拆解方法组织。
抽样评审抽多少、抽哪些，才能判断文档与执行一致？
抽样覆盖不同角色和不同过程域，优先抽取近期完成、涉及跨角色协作的活动记录。检查重点是记录时间是否合理、审批顺序是否符合定义、证据能否沿活动编号追到工作产品。抽样发现的问题按阻断项和非阻断项分类处理，非阻断项列入改进清单并明确责任人和计划完成时间。
