# 方案设计、AI PRD 与原型

对生成内容增加展示、复制、下载/导出的标识契约；对 Agent 增加主体、资源、动作、确认、预算、撤销与终态凭据；对受影响人补充纠错、申诉和退出。字段在原型与真实环境中验证，参考 [动作契约](../14_行业基线/02_Agent安全_身份与协议.md)及 [标识适用性](../14_行业基线/08_法规_标准与适用性.md)。

## 从服务蓝图开始

AI 功能处在完整服务中。先画：

- 用户步骤与情绪。
- 前台界面、AI 行为、人工协作。
- 后台流程、数据、模型、工具和策略。
- 支撑系统、权限、日志与责任人。
- 正常、失败、取消、超时、升级和申诉路径。

如果只画“输入框 → 神奇答案”，所有风险都会在开发后出现。

## 选择自动化程度

用五个问题决定“建议、草拟、执行”：

1. 错误损害多大？
2. 动作是否可逆？
3. 错误是否容易被及时发现？
4. 任务频率是否高到值得自动化？
5. 责任与监督者是否明确？

默认从最低足以产生价值的自主性开始。高影响动作采用“预览 → 明确确认 → 执行 → 回执 → 可撤销/补偿”。

## Human-in-the-loop 的真实设计

“有人复核”必须具体：

- 谁复核，是否有专业能力？
- 何时触发，全部还是风险抽样？
- 一次需要多久，是否形成瓶颈？
- 界面是否突出不确定点和证据？
- 复核错误如何发现与问责？
- 自动化偏见和疲劳如何避免？

人不是无限可靠的兜底组件。系统需让人有时间、有证据、有权限改变结果。

## AI UX 原则

Microsoft 的 [18 条 Human-AI Interaction Guidelines](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/) 可归为四个时刻：初次使用、正常交互、AI 出错、长期使用。

### 初次使用

- 清楚说明能做什么、不能做什么、可能多常出错。
- 用具体示例和适用范围代替“智能、高效、万能”。
- 说明数据使用、是否联网、是否执行动作。

### 交互中

- 显示当前上下文、来源、状态和将要执行的动作。
- 信息不足时澄清，不自信地补全关键事实。
- 提供建议入口，避免打断和过度拟人化。

### 出错时

- 用户能编辑、重试、比较、否定、报告和转人工。
- 解释失败类型和下一步，不只显示“Something went wrong”。
- 高影响动作支持撤销、补偿和申诉。

### 长期

- 用户能查看、纠正和删除记忆/偏好。
- 模型能力变化有适当提示，不静默改变关键行为。
- 从纠错学习前取得适当同意，避免反馈回路放大偏差。

## 信任校准

目标不是“让用户更信任 AI”，而是让信任与实际能力匹配：该信时信、该核实时核实、该拒绝时拒绝。

设计手段：

- 引用精确到支持该主张的片段；允许展开原文。
- 区分事实、推断、建议和未知。
- 对关键字段提供独立验证状态。
- 暴露适用范围和更新时间。
- 不用拟人化道歉掩盖系统性问题。

## AI PRD 必备章节

普通 PRD 的背景、用户、流程、功能、指标仍需要；额外加入：

1. **问题与基线**：用户任务、现状性能和不做的代价。
2. **为何 AI**：与规则、搜索、人工、传统 ML 的比较。
3. **范围与自主性**：做/不做、用户、区域、动作权限。
4. **输入/输出契约**：数据来源、Schema、长度、语言、格式。
5. **能力与限制**：已知边界、失败模式和告知方式。
6. **数据需求**：来源、授权、质量、标注、保留、删除。
7. **AI 方案**：模型、Prompt、RAG、工具、规则、降级。
8. **评测设计**：数据集、切片、Rubric、阈值、基线和人评。
9. **安全合规**：威胁、敏感数据、内容、版权、审计。
10. **运营**：版本、监控、漂移、反馈、事故、回滚。
11. **成本与容量**：流量、Token、工具、人工、峰值。
12. **开放问题与决策日志**：假设、责任人、截止日。

完整骨架见 [模板 05](../06_模板工具箱/README.md#05-ai-prd)。

## 写好验收标准

弱：系统应准确回答用户问题。

强：

> 在 `golden_v3` 的政策问答切片（n=300）上，事实正确率 ≥ 92%，引用支持率 ≥ 97%，高风险错误为 0；无法由授权知识库支持的问题，正确拒答率 ≥ 95%；P95 完成延迟 ≤ 8 秒；每成功任务全链路成本 ≤ ¥0.35。评审规则和置信区间见评测计划。

每项标准说明样本、版本、评分者、阈值、严重级别和失败处置。

## 原型分层

1. **故事板**：验证任务与时机。
2. **静态线框**：验证信息结构和控制。
3. **Wizard-of-Oz**：验证行为与价值，不依赖模型就绪。
4. **真实模型原型**：暴露延迟、随机性、失败和成本。
5. **影子原型**：接真实输入但不影响用户决策。

真实模型原型必须保存输入、版本和结果，避免只挑成功截图。

## 失败模式设计

为每个关键流程写一张失败表：

| 失败 | 用户看到什么 | 系统做什么 | 谁知道 | 如何恢复 |
|---|---|---|---|---|
| 信息不足 | 请求补充关键字段 | 不生成高风险结论 | 用户/日志 | 补充后继续 |
| 无可靠来源 | 明确无法确认 | 拒答/转搜索或人工 | 用户/运营 | 新增知识后重试 |
| 工具超时 | 显示未执行 | 不宣称成功、幂等重试 | SRE | 恢复或人工执行 |
| 策略拦截 | 解释可提供的安全帮助 | 记录政策类型 | 安全抽检 | 申诉/人工复核 |
| 低置信高风险 | 标记待专家确认 | 阻断提交 | 专家 | 审核后提交 |

## 设计评审问题

- 用户能否区分 AI 建议和已执行事实？
- 引用是否真的支持答案，而非只相关？
- 用户纠错是否改变当前任务，是否被不当用于训练？
- 超时、断网、模型拒答、工具部分成功时状态是否一致？
- 攻击者能否通过文档/网页改变系统指令？
- 多租户、共享设备和截图/导出是否泄露敏感信息？
- 新手与专家是否需要不同控制和解释？
- 无障碍、语言和文化差异是否被测试？