> 版本：1.0  
> 适用范围：大模型生成的文章、说明文档，以及 UI 页面与交互流程。  
> 验收方式：以目标受众的疑问发现问题，以可验证的证据确认修复。

大模型生成的结果，即使语言流畅、界面整齐，也可能让读者无法理解关键概念，让访问者找不到入口，或让用户在需要作出决定时缺少必要信息。

本规范将“从受众角度提出问题，再根据问题修改结果”转化为一套可执行、可复核的验收流程：

**生成初稿 → 模拟受众提问 → 判断问题是否成立 → 针对性修订 → 验证修复 → 给出验收结论。**

本文是一套实践工作规范，不是行业认证标准。其中的等级与通过条件可根据项目调整，但应在评审前确定，不能为了让结果通过而临时降低要求。

## 一、验收目标

验收应围绕成品对目标受众的实际作用展开：

| 目标 | 验收要求 |
| --- | --- |
| 能理解 | 受众能够理解核心信息，不依赖作者在场解释 |
| 能判断 | 受众拥有判断可信度、适用性和选项差异所需的信息 |
| 能行动 | 对于有操作目标的内容，受众知道下一步怎么做 |
| 少障碍 | 不存在明显的误解、信息缺失或操作阻碍 |

不同成品可以采用不同目标。观点文章重点检查理解与论证；操作教程还应检查可执行性；产品页面应检查信息判断和行动入口。

**验收对象必须是最终交付形态。** 文章应检查完整正文及其实际呈现；UI 应检查渲染后的页面，并根据验收范围操作相关流程。只阅读生成提示词或源代码，不足以完成受众视角验收。

## 二、验收前确定范围

每次验收至少记录以下信息：

| 项目 | 需要明确的内容 |
| --- | --- |
| 目标受众 | 谁会阅读或使用？具备哪些知识，缺少哪些知识？ |
| 使用情境 | 为什么来到这里？是在快速浏览、深入学习，还是执行操作？ |
| 核心目标 | 最终应该理解什么、判断什么或完成什么？ |
| 内容边界 | 本次负责解决哪些问题，哪些问题不在范围内？ |
| 验收材料 | 正文、截图、可操作页面、必要的资料与业务规则 |
| 必须满足的约束 | 篇幅、语气、品牌、设备范围、无障碍要求等 |
| 通过条件 | 哪些要求必须验证，哪些非关键问题可以保留？ |

例如：

> 面向第一次接触产品的个人用户。用户应在两分钟内理解产品用途，判断是否值得试用，并找到试用入口。本页面不负责解释企业采购流程。

“两分钟”在这里是待测试的项目目标。未经计时观察，不能仅凭 AI 判断就认定已经达成。

影响核心目标的信息缺失时，应标记为“待确认”；非关键缺失可以采用明确记录的假设。范围外问题可以作为后续建议，但不应直接导致本次验收失败。

## 三、角色与信息边界

验收分为三个职责，可以由同一个模型分步骤承担，也可以由不同评审者承担：

| 角色 | 职责 |
| --- | --- |
| 创作者 | 根据需求生成初稿 |
| 受众评审者 | 按阅读顺序或操作路径，提出疑问并指出障碍 |
| 修订与复核者 | 判断问题、执行修复、检查证据并给出结论 |

受众评审者必须遵守以下规则：

1. 只使用受众实际可见的信息和已定义的背景知识。
2. 不利用作者的创作过程、隐藏说明或实现意图补全缺失信息。
3. 不把自己理解作者意图，等同于目标用户能够理解成品。
4. 不为凑数量制造问题，不将个人审美偏好直接判定为缺陷。
5. 明确区分观察事实、推测的用户影响，以及尚未验证的事项。

独立会话可以减少创作上下文的影响，但更换会话或模型不代表评审天然可靠。**AI 提出的用户疑问，应视为需要检查的假设。**

## 四、有效问题的记录要求

每个验收问题必须具有可定位、可解释、可复核的依据：

| 字段 | 记录要求 |
| --- | --- |
| 编号与位置 | 指出具体段落、原句、界面区域或操作步骤 |
| 用户疑问 | 用目标受众的语言描述困惑 |
| 观察依据 | 引用原文、可见状态或实际操作结果 |
| 用户影响 | 说明如何妨碍理解、判断或行动；推测需注明 |
| 严重程度 | 按本规范分级 |
| 处理与复核 | 记录处理方式、验证依据及最终状态 |

例如：

> **编号：** A-03  
> **位置：** 第三段第二句  
> **用户疑问：** “效率提升 40%，是和什么相比？”  
> **观察依据：** 原文提供了比例，没有提供比较对象或来源。  
> **用户影响：** 读者可能高估收益，无法判断是否适用于自己。  
> **等级：** 重要  
> **处理：** 核验并补充比较对象与来源；无法核验时删除具体比例。  
> **复核标准：** 比较关系清楚，结论与来源一致，或不再使用无依据的数字。

以下反馈不能直接作为修订要求：“逻辑不好”“不够高级”“页面不够直观”。它们必须进一步转化为具体疑问和实际影响。

提出问题后，还要检查成品是否已在合理位置提供答案。如果答案存在，应判断是入口、顺序或显著性有问题，还是评审者遗漏阅读，避免重复补充信息。

## 五、文章验收要求

文章应按实际阅读顺序检查：

| 维度 | 典型读者疑问 |
| --- | --- |
| 主题与价值 | 这篇文章回答什么问题？为什么与我有关？ |
| 概念与前提 | 这个术语是什么意思？作者是否假定我已经知道某些背景？ |
| 逻辑衔接 | 为什么能从上一段得出这个结论？中间缺少什么解释？ |
| 证据与边界 | 依据是什么？哪些条件下成立？是否把个别例子扩大为普遍结论？ |
| 信息顺序 | 为什么读到后面才能理解前面？关键答案是否出现得太晚？ |
| 实际应用 | 我要照着做，第一步是什么？需要什么条件？如何知道做对了？ |
| 阅读负担 | 哪些重复、旁支或抽象表达妨碍了我抓住重点？ |

修订应采用能解决问题的适当方式，包括补充说明、增加例子、调整顺序、删除重复内容、收窄结论或替换模糊表达。

**增加篇幅不自动代表质量提高。** 每项新增内容都应服务于目标读者的实际问题，不能为了回答所有可能的疑问，把文章扩展到原定范围之外。

涉及数据、引用、因果关系等事实性问题时，应使用可靠资料核验。修订过程中不得为使内容完整而编造出处、数字或案例。

## 六、UI 验收要求

UI 验收必须绑定具体任务，例如“选择套餐并开始试用”。评审沿任务路径进行：

| 阶段 | 典型访问者疑问 |
| --- | --- |
| 初次进入 | 这是什么？能帮我解决什么问题？ |
| 寻找入口 | 从哪里开始？主要操作是否容易发现？ |
| 理解选择 | 选项有什么区别？我需要哪些信息才能决定？ |
| 执行操作 | 点击之后会发生什么？是否会产生费用或不可撤销的结果？ |
| 接收反馈 | 系统正在处理、成功了，还是失败了？ |
| 纠错恢复 | 输入错误或操作失败后，如何修正并继续？ |
| 完成任务 | 我是否已经完成？接下来需要做什么？ |

视觉模型应查看实际渲染结果，并指出对应区域。评审时应说明所检查的页面状态与视口；项目要求覆盖移动端时，不能仅凭桌面截图通过。

验证材料决定结论范围：

| 材料 | 可以支持的结论 | 仍需补充的验证 |
| --- | --- | --- |
| 静态截图 | 可见文字、布局、信息层级及部分可见问题 | 点击结果、输入校验、完整任务流程等 |
| 可操作界面 | 实际测试过的流程、状态变化和错误恢复 | 未测试路径、设备与辅助技术表现 |
| 真实用户测试 | 参与者在具体测试情境下的理解与行为 | 其他人群与情境仍需谨慎推广 |

如只提供截图，结论应标注为“视觉与信息层面验收”，并列出交互未验证项。截图中的按钮存在，不代表按钮功能正常。

若无障碍属于项目的必达要求，应按相应要求检查键盘操作、焦点、语义等内容；视觉评审只能覆盖其中一部分。

## 七、问题分级

| 级别 | 定义 | 处理要求 |
| --- | --- | --- |
| 阻断 | 核心内容被严重误解，或核心任务无法完成 | 必须解决，不允许以其他项目高分抵消 |
| 重要 | 明显增加误判、反复寻找或求助的可能，影响核心体验 | 默认修复；确需保留时由交付负责人明确接受影响 |
| 一般 | 存在局部阅读或操作负担，但核心目标仍能实现 | 根据成本与收益安排处理 |
| 偏好 | 缺少明确用户影响，主要属于风格选择 | 可作为建议，不单独构成不通过理由 |

严重程度必须结合受众、任务和后果判断。同一个术语对专业读者可能无需解释，对新手教程则可能构成重要障碍。

AI 可以建议等级，但不能代替交付负责人接受已知的重要问题。

## 八、修订与复核流程

### 第一步：记录初稿与验收基线

保留本轮待验收版本，记录目标受众、核心任务、范围和必达要求，以便比较修订前后的变化。

### 第二步：模拟受众提问

沿阅读顺序或操作路径记录问题。优先发现影响理解与任务完成的障碍，不预设必须发现多少个问题。

### 第三步：筛选与分级

逐项检查问题是否有依据、是否在范围内、是否与其他问题重复，并确定严重程度。对不成立或不采纳的问题说明理由。

### 第四步：针对性修订

先修复阻断和重要问题。每项修改应对应一个明确问题或原始要求，避免在修复过程中加入无关改动。

### 第五步：逐项复核

用原问题重新检查修改后的成品：

- 原疑问是否已得到解决？
- 答案或入口是否出现在用户需要的位置？
- 修改是否符合原始要求？
- 是否有足够证据支持“已解决”？

“已经改过”不能作为关闭问题的依据。

### 第六步：整体复核

重新通读文章或执行核心流程，检查修改是否引入矛盾、冗余、布局退化或新的操作障碍。必要时检查与改动直接相关的其他位置和路径。

### 第七步：给出结论

汇总问题状态、验证依据、遗留问题与适用范围。保留未验证项，不将其当作已通过项目。

## 九、通过条件与停止规则

本规范使用四种结论：

| 结论 | 判定条件 |
| --- | --- |
| 通过 | 核心目标满足；无未解决的阻断或重要问题；所有必达要求已验证 |
| 有条件通过 | 核心目标与必达要求已验证；剩余非阻断问题有明确记录，并由交付负责人接受 |
| 不通过 | 已发现阻断问题，或存在未获接受的重要问题、未满足的必达要求 |
| 待验证 | 缺少关键材料或验证证据，暂时无法确定是否满足必达要求 |

已发现阻断问题时，即使还有未验证项，也应给出“不通过”，同时列明后续需要验证的内容。

非关键的范围限制可以随结论一并说明；缺少关键验证不能用“有条件通过”绕过。若只验收截图，结论仅适用于截图可覆盖的范围。

不建议仅按总分判定通过。多个次要项目的高分，不能抵消核心流程失败或关键事实错误。

可以先安排一轮修订和一轮复核，再根据遗留问题决定是否继续。达到通过条件后停止，不追求“完全提不出问题”。连续修订仍无进展时，应重新检查需求、材料或问题判断，必要时引入真实用户反馈。

## 十、交付记录模板

每次验收至少提供以下记录：

> **验收对象与版本：**  
> **目标受众与核心任务：**  
> **验收范围及材料：**  
> **必达要求：**  
> **评审方式：** AI 模拟受众／人工评审／真实用户测试／组合方式  
> **验收结论：** 通过／有条件通过／不通过／待验证  
> **主要问题与处理结果：**  
> **验证依据：**  
> **遗留问题、接受人及处理安排：**  
> **未验证项与结论限制：**

由 AI 模拟读者或访问者得出的结论，应明确标注为“AI 模拟受众验收”。即使没有发现问题，也只表示在本次范围和方法下未发现问题，不能据此宣称真实用户一定不会遇到困难。

## 十一、可直接复用的验收指令

```text
请按照《大模型生成结果验收规范》检查以下成品。

目标受众：[填写受众及其背景知识]
使用情境：[填写]
核心目标与任务：[填写]
内容边界：[填写]
必须满足的约束与通过条件：[填写]
验收材料及版本：[提供正文、截图或可操作界面]

请按顺序执行：

1. 检查输入是否足够。记录必要假设；缺少关键材料时标记待验证。
2. 作为目标读者或访问者，沿阅读顺序或操作路径提出具体疑问。
   只使用受众可见的信息，不用创作过程或隐藏说明补全成品。
3. 每个问题记录位置、用户疑问、观察依据、影响和严重程度。
   区分事实与推测，不凑问题数量，不把偏好当作缺陷。
4. 检查问题是否成立、是否在范围内，以及成品是否已提供答案。
5. 修复成立的问题，优先处理阻断和重要问题。
   可以补充、删减、重排或调整交互，不默认增加内容。
   不编造事实、数据、来源或验证结果。
6. 逐项验证原问题是否解决，并检查修改是否引入新问题。
   事实结论需核验；交互行为需实际测试。
7. 输出验收结论、修订后成品、主要问题及处理结果、
   验证依据、遗留问题和未验证项。

存在阻断问题时不得通过。
缺少关键验证证据时不得宣称完成验收。
重要问题未经交付负责人接受，不得自行有条件通过。
达到通过条件后停止，不为继续优化而制造新问题。
```

## 十二、方法依据与适用边界

这一流程与已有写作、可用性评估和大模型反馈研究相近：

- **读者导向写作：** Linda Flower 在 1979 年讨论了如何将作者自身的表达转化为适合读者理解的结构与语言。它为本文的受众视角提供了相关思想基础。[原论文](https://atgender.eu/wp-content/uploads/sites/207/2022/03/Linda_1979.pdf)
- **认知走查：** 通过模拟用户完成任务，逐步检查目标、操作发现、理解和反馈，与本文的 UI 任务路径评审相近。[方法说明](https://www.hcibib.org/tcuid/chap-4.html)
- **Self-Refine：** 2023 年研究探索了模型生成结果、提供反馈并据此迭代修订的流程。[论文](https://arxiv.org/abs/2303.17651)
- **UI 自动反馈研究：** 2024 年研究发现，大模型反馈能够帮助发现部分 UI 问题，但反馈实用性可能随迭代下降。[论文](https://arxiv.org/abs/2403.13139)
- **自我修正的限制：** 2023 年针对推理任务的研究发现，缺少外部反馈时，模型自我修正可能无效，甚至降低表现。这提示我们要验证修改结果，不能将迭代次数当作质量证明。[论文](https://arxiv.org/abs/2310.01798)

这些研究支持相关方法的讨论，并不直接验证本规范全部条款的效果。本文规定的问题等级、通过条件和记录格式，是为了让工作流程可执行、可追踪而提出的实践约定。

**验收的最终依据，是原有障碍是否得到解决，以及解决结果是否有证据支持。**
