# AI VOC 下一阶段可执行方案

**版本**：2026-08-06
**范围**：`E:\workspace\Saas-voc` 前端、`E:\workspace\server\saas-voc-server` 后端
**目标**：把当前可运行的“反馈证据 -> AI 洞察 -> 行动项创建”提升为可审计、可执行、可验证、可持续学习的 VOC 业务闭环。

## 1. 执行结论

当前系统已经具备一条可用的生成链路：反馈收件箱提供可筛选的原始评价，AI VOC 页面准备证据并生成结构化洞察，洞察可以回跳到原始评价并预填行动项，后端 `AnalysisRun` 和 `ActionItem` 也已经有状态、权限、审计和来源字段。

但目前的链路仍停在“生成结果并创建行动项”，还没有完整表达以下业务事实：

1. **洞察是否被人确认**：`AnalysisRun.completed/partial` 是计算运行状态，不是业务确认状态；当前没有独立的确认、驳回或“补证据”记录。
2. **行动中心是否消费同一批行动项**：AI 页面写入 SaaS `ActionItem`，但现有行动中心仍通过本地 `DomesticAnalyticsAdapterService.actions(dataset)` 生成规则行动，来源和状态没有统一。
3. **行动是否有效**：行动项有执行状态和 `completedAt`，但没有基线、目标、观察窗口、观测值、验证结论或未测量原因。
4. **原始反馈是否越过了洞察层**：反馈收件箱的快捷创建使用 `sourceAnalysisId=null`、`sourceInsightId=null`、空 `evidenceIds`，会产生一条没有证据链的行动项。
5. **AI 结果是否被服务端重新验证**：服务端会校验行动项引用的分析、洞察和证据，但 `PATCH analysis` 目前允许写入任意 JSON 结果，尚未在服务端强制校验 `insight.evidenceIds` 属于本次 `input.evidenceIds`。

因此下一阶段不以增加更多“AI 摘要卡片”为主，而以三个可度量结果为主：

```text
可追溯：每个可执行行动都能回到洞察、分析运行和原始证据
可决策：每个洞察都有显式的人审结论，AI 生成完成不等于业务确认
可验证：每个完成行动都有结果或明确的未测量原因，并能进入下一轮 VOC 分析
```

## 2. 当前实现盘点

### 2.1 已经形成的主链路

| 环节 | 当前实现 | 已具备能力 | 当前限制 |
| --- | --- | --- | --- |
| 反馈证据 | `src/modules/feedback-inbox/feedback-inbox.component.ts:157-245`、`feedback-inbox.models.ts:13-27` | 来源、情感、主题、样本量、置信级别、详情回看 | 主要由前端数据集即时计算，没有统一的反馈事件/证据登记表 |
| AI 输入 | `src/modules/ai-voc-insight/ai-voc-insight.service.ts:63-94` | 过滤范围、样本上限、证据 ID、主题和情感/来源统计 | 输入快照缺少模型、提示词、规则和分类版本；服务端不认识输入证据集合 |
| AI/规则生成 | `ai-voc-insight.service.ts:96-152`、`:154-186` | 结构化 JSON、超时降级、deterministic fallback、`needs_validation` | 结果解析和证据白名单主要在前端；fallback 仍可直接打开行动创建面板 |
| 运行记录 | `ai-voc-insight.component.ts:265-345`、`:507-642` | `pending -> processing -> completed/partial/failed`、历史恢复、终态锁定、审计 | 运行状态没有拆成洞察业务状态；生成执行在前端，`analysisExecution: false` |
| 洞察展示 | `ai-voc-insight.component.html:311-394` | finding、user need、severity、confidence、opportunity status、recommendation、validation metric、证据回跳 | 没有“已阅证据/确认/驳回/补证据”的持久化交互 |
| 洞察转行动 | `ai-voc-insight.component.html:427-440`、`action-create-panel.component.ts:81-115` | 自动带入 `sourceAnalysisId`、`sourceInsightId`、`evidenceIds`、`validationMetric` | `createdActionIds` 只在页面内存中；没有幂等键；没有按机会状态阻断 |
| 单条反馈转行动 | `feedback-inbox.component.ts:255-325`、`:281-304` | 可从反馈详情预填行动项 | 当前未携带分析/洞察来源，绕过证据->洞察关系；前端本地集合无法跨刷新判断已创建 |
| Action API | `server/src/modules/saas-platform/routes.ts:221-266` | 分页、权限、成员校验、来源审计、状态更新 | 当前缺少行动详情、决策和验证 API；尚未表达效果回流 |
| 来源完整性 | `server/src/modules/saas-platform/domain.ts:142-200`、`migrations/003...`、`004...` | 同 workspace、已完成/部分完成的 `voc_insight`、洞察 ID、证据子集校验 | 仅校验行动创建时的来源；不校验生成结果本身，也不校验人审决策 |
| 行动中心 | `src/modules/domestic-voc/framework/domestic-action-workbench.component.ts:88-106` | 有看板、体验优化、产品迭代、策略四个视图 | 读取 `analytics.actions(dataset)` 本地规则结果，没有消费 `SaasPlatformService.actions()` 或更新 ActionItem |
| 持久化 | `server/src/modules/saas-platform/local-platform.repository.ts:208-287`、Parse/Postgres repository | 三种 repository 接口已对齐 | local repository 为进程内数组，重启丢失；Postgres 迁移 `003/004` 必须在部署验收时确认已执行 |

### 2.2 当前状态机边界

```text
AnalysisRun: pending -> processing -> completed | partial | failed | cancelled
ActionItem:  open -> planned -> in_progress -> completed | blocked | cancelled
```

`AnalysisRun` 的终态约束在 `server/src/modules/saas-platform/domain.ts:95-140` 已有实现；`ActionItem` 的状态更新在各 repository 已有实现。但缺少业务层状态机：

```text
Insight: draft -> confirmed | rejected | needs_more_evidence -> published -> archived
ActionValidation: pending -> effective | partially_effective | ineffective | not_measured
```

第一条用于判断“洞察能否进入正式行动”，第二条用于判断“行动是否解决了问题”。它们需独立于 `AnalysisRun.status` 和 `ActionItem.status`。

## 3. 闭环断点与优先级

| 优先级 | 断点 | 业务风险 | 处理原则 |
| --- | --- | --- | --- |
| P0 | 没有独立的人审决策；`needs_validation` 仍可创建行动 | AI/规则摘要可能被误当作正式结论 | 先保存决策，再允许可执行行动；“补证据”只能生成数据收集任务 |
| P0 | 生成结果的证据白名单只在前端完成 | 任何可写入 API 的客户端都可能提交无关证据 | 服务端对结果做 schema、证据子集、coverage 一致性校验 |
| P0 | 反馈收件箱快捷行动绕过洞察 | 行动缺少洞察与分析批次归因 | 改为“加入分析/创建待验证项”；确需快捷行动时必须用独立的原始反馈来源模型 |
| P0 | AI ActionItem 与行动中心断开 | 用户看不到刚创建的行动，也缺少状态推进入口 | 行动中心改读 SaaS Action API，并保留本地规则行动为独立来源 |
| P1 | 没有洞察版本、发布和归档 | 重新生成会覆盖上下文，难以比较口径变化 | 引入 `InsightRecord` 版本化，AnalysisRun 只代表一次计算 |
| P1 | 完成行动没有结果回流 | 缺少“哪类 VOC 被解决”的事实依据 | 引入 `ActionValidation`，完成行动必须记录验证结果或未测量原因 |
| P1 | 反馈缺少统一事件与快照 | 增量同步、去重、跨周期主题追踪不稳定 | 引入稳定 evidence registry 和 ingestion quality |
| P2 | 没有相似反馈/跨周期记忆 | 重复主题反复生成，分析师需要手工合并 | 规则过滤后再做向量相似检索，保留人工合并/拆分 |
| P2 | AI 质量和成本不可运营 | 缺少判断模型升级收益的事实依据 | 建立 golden set、schema/evidence 评估、延迟/成本看板和版本回归 |
| P2 | 没有受控的周报和问答 | 信息只能停留在页面内，组织传播成本高 | 只输出带引用的摘要，确认和行动仍回到平台完成 |

## 4. P0：先闭合可审计决策链

**目标**：任何进入正式行动中心的事项，都能证明“谁审阅了哪些证据、确认了什么、基于哪次分析、准备如何验证”。

### P0-1 数据模型与 API

#### A. 新增 `InsightDecision`

建议新增 `voc.insight_decision`（Parse 对应 `VocInsightDecision`）：

| 字段 | 类型 | 约束/含义 |
| --- | --- | --- |
| `publicId` | text/UUID | 对外 ID |
| `workspaceId` | FK/text | 与 source analysis 一致 |
| `sourceAnalysisId` | FK/text | 必须是 `voc_insight` 且状态为 `completed/partial` |
| `sourceInsightId` | text | 必须存在于 `analysis.result.insights[].id` |
| `decision` | enum | `confirmed`、`rejected`、`needs_more_evidence` |
| `reviewedEvidenceIds` | jsonb/array | 非空，且是该 insight 的 `evidenceIds` 子集 |
| `comment` | text | 决策理由；`rejected` 和 `needs_more_evidence` 必填 |
| `decidedBy` | user ID | 当前 workspace active 成员 |
| `decidedAt` | timestamp | 服务端写入，不信任客户端时间 |
| `createdAt/updatedAt` | timestamp | 审计与幂等 |

约束：同一 `(workspaceId, sourceAnalysisId, sourceInsightId)` 只允许一个当前决策；重新判断产生新版本或显式 supersede 记录，不静默覆盖旧决策。

建议 API：

```text
POST /api/saas/workspaces/:workspaceId/insight-decisions
GET  /api/saas/workspaces/:workspaceId/insight-decisions?analysisId=:id
GET  /api/saas/workspaces/:workspaceId/insight-decisions/:id
```

`POST /actions` 增加 `sourceDecisionId`。服务端必须检查决策与分析、洞察、workspace 三者一致：

- `confirmed`：允许创建 `experience/product/strategy/general` 行动。
- `needs_more_evidence`：只允许创建 `data_quality` 的补证据任务，标题和验证指标必填。
- `rejected`：正式行动创建入口关闭。
- deterministic fallback 的洞察默认只能走 `needs_more_evidence`，除非已有明确人工 `confirmed`。

#### B. 强化 `AnalysisRun` grounding contract

保留当前 `AnalysisRun`，但要求 `input` 和 `result` 使用固定版本结构：

```ts
input: {
  schemaVersion: 1;
  evidenceIds: string[];
  filters: { scope: 'all' | 'own' | 'competitor'; sentiment: string; sampleLimit: number };
  datasetSnapshotId: string;
  promptVersion?: string;
  model?: string;
  ruleVersion?: string;
  taxonomyVersion?: string;
  redaction: { applied: boolean; fieldCounts: Record<string, number> };
}

result: {
  schemaVersion: 1;
  mode: 'ai' | 'deterministic';
  evidenceCoverage: number;
  insights: Array<{ id: string; evidenceIds: string[]; opportunityStatus: string; validationMetric: string }>;
  risks: string[];
  followUpQuestions: string[];
}
```

服务端在 `PATCH /analyses/:id` 的终态写入前执行：

1. 所有 `insight.evidenceIds` 为非空且属于 `input.evidenceIds`。
2. `evidenceCoverage` 等于实际被引用的去重证据数除以输入证据数，由服务端重算。
3. `mode=deterministic` 必须写成 `partial`，且所有 insight 至少有 `needs_validation` 或显式风险说明。
4. `mode=ai`、`partial`、`completed` 的结构均通过同一 schema validator。
5. 记录 `model/promptVersion/ruleVersion/taxonomyVersion`，用于回归和审计；日志仅保存脱敏统计，不保存原始反馈正文。

#### C. ActionItem 幂等和来源补全

在现有 `sourceAnalysisId/sourceInsightId/evidenceIds/validationMetric` 之上增加：

```text
sourceDecisionId: string | null
creationKey: string           // workspace + analysis + insight + decision，唯一
sourceKind: 'insight' | 'raw_feedback' | 'rule_action'
```

`creationKey` 用于双击、刷新重试和多标签页幂等。现有 `domain.ts:149-193` 的来源完整性检查继续保留，并扩展为校验 `sourceDecisionId`。

对于反馈收件箱：

- 默认按钮改为“加入待分析”，把 `reviewId` 加入分析批次，不直接创建正式 ActionItem。
- 如果业务必须保留快捷行动，新增 `sourceKind=raw_feedback` 和 `sourceFeedbackIds`，UI 必须显式标注“原始反馈行动”，并与 AI 洞察行动区分；其验证指标和后续洞察归因单独处理。

### P0-2 页面交互

#### AI 洞察页

在 `ai-voc-insight.component.html` 当前洞察卡片上增加一个明确的“决策区”，不把“生成完成”当作“已确认”：

1. 卡片展示 `证据覆盖率`、输入证据数、已审阅证据数、运行模式和当前决策状态。
2. 点击证据 ID 或“查看证据”打开右侧证据抽屉；抽屉支持逐条标记已阅、查看反馈收件箱详情、查看同主题样本。
3. 只有已阅证据数达到最小门槛且用户填写理由后，`确认洞察`、`驳回`、`需要补证据` 才可提交。
4. `needs_validation`、deterministic 或低覆盖率洞察只显示“需要补证据”；确认后才显示“创建正式行动”。
5. 提交后卡片显示决策人、时间、决策理由和决策 ID；刷新页面、恢复历史或跨页面后保持一致。
6. 创建行动面板从 `sourceDecisionId` 读取来源；二次提交返回既有行动时，UI 显示“已存在行动”，不再创建第二条。

#### 反馈收件箱

1. 保留当前队列、来源/情感筛选和 `reviewId` 回跳。
2. 详情页将“创建行动项”改为“加入分析批次”；用户选择已有分析运行或新建待分析批次。
3. 如保留快捷行动，必须显示来源类型、证据 ID、风险提示，并只能创建 `raw_feedback` 或 `data_quality` 类型。
4. 创建结果来自服务端列表而非 `createdActionIds` 内存集合，避免刷新后重复创建。

#### 行动中心

1. 增加来源筛选：`AI 洞察`、`原始反馈`、`规则行动`。
2. 列表从 `GET /workspaces/:workspaceId/actions` 读取，支持状态、优先级、负责人、到期日、来源分析筛选。
3. 行动详情固定展示：`ActionItem -> InsightDecision -> Insight -> AnalysisRun -> Evidence`。
4. 状态更新使用 `PATCH /actions/:id`，完成时若没有验证记录，状态显示“待验证”而不是“问题已解决”。
5. 本地 `DomesticAnalyticsAdapterService.actions()` 保留为规则建议来源，迁移期用标签区分，不与 SaaS ActionItem 混在同一个完成计数中。

### P0-3 AI 能力

- **Grounded generation**：模型只接收脱敏后的结构化证据和允许的 evidence ID；原始正文仅用于当前分析，prompt 日志仅保存脱敏统计。
- **Schema-first output**：前端解析保留，但终态写入必须经过服务端 schema validator；未知字段可忽略，未知证据 ID 必须拒绝。
- **Confidence calibration**：置信度由证据量、来源覆盖、情感一致性和重复度共同计算；模型负责补充解释，数量和比例由确定性数据层提供。
- **Fallback discipline**：AI 网关不可用时继续提供 deterministic 摘要，结果统一为 `partial + needs_validation`，并沿用人审门槛。
- **可解释追问**：每条洞察生成 1-3 个补证据问题，问题必须能映射到来源、时间窗、产品或主题，避免生成无数据依赖的泛化建议。

### P0-4 成功指标与验收标准

| 指标 | 目标 | 口径 |
| --- | --- | --- |
| Evidence precision | >= 99% | 洞察引用 ID 中属于本次输入的比例；服务端拒绝未知 ID |
| Evidence coverage correctness | 100% | 存储 coverage 与去重引用数/输入数一致 |
| Decision traceability | >= 99% | 正式行动能找到决策、洞察、分析运行和至少 1 条证据 |
| Unconfirmed action leakage | 0 | 未确认洞察不得创建正式行动 |
| Duplicate action rate | < 1% | 相同 creationKey 的重复创建数/创建请求数 |
| UI recoverability | 100% | 刷新、重新登录、历史恢复后决策和来源仍可见 |

验收用例：

- 提交未知 `evidenceId`、跨 analysis 的 `evidenceId`、空证据数组，API 返回 4xx 且数据库无脏结果。
- 对 deterministic 结果直接点击创建正式行动，UI 禁用，API 直接拒绝；提交 `needs_more_evidence` 后只能创建补证据任务。
- 同一洞察双击或并发提交两次，最终只有一个 `creationKey` 对应的 ActionItem。
- 从 AI 洞察、行动中心、反馈收件箱往返跳转，URL 中的分析/洞察/反馈 ID 能恢复同一上下文。
- 用 local、Parse REST、Postgres 三种 repository 各跑一次来源与决策测试；local 明确标注为演示存储。

## 5. P1：建立洞察资产和行动效果回流

**目标**：让洞察成为可版本化的业务资产，让行动完成后能产生下一轮分析的事实输入。

### P1-1 数据模型

#### `InsightRecord`

新增独立洞察实体，`AnalysisRun` 只保留计算运行：

| 字段 | 含义 |
| --- | --- |
| `publicId/workspaceId` | 洞察资产和权限边界 |
| `insightKey` | 稳定主题键，由 taxonomy + product/category + normalized topic 组成 |
| `version` | 同一 insightKey 的递增版本 |
| `sourceAnalysisId` | 产生该版本的运行 |
| `status` | `draft/confirmed/published/archived` |
| `title/finding/userNeed/recommendation` | 可编辑业务内容 |
| `evidenceIds/evidenceCoverage` | 版本快照，随源数据刷新时保持不变 |
| `ownerUserId/publishedBy/publishedAt` | 运营责任和发布审计 |
| `supersedesId/archiveReason` | 版本链和归档原因 |

#### `ActionValidation`

新增 `voc.action_validation`（Parse 对应 `VocActionValidation`）：

```text
publicId, workspaceId, actionId, metricKey, baselineValue,
targetValue, observationWindowStart, observationWindowEnd,
observedValue, verdict, notMeasuredReason, notes,
verifiedBy, verifiedAt, createdAt, updatedAt
```

`verdict`：`effective | partially_effective | ineffective | not_measured`。当 `not_measured` 时 `notMeasuredReason` 必填；行动只有在验证记录提交后才显示“已验证完成”。

#### `FeedbackEvidence`

统一反馈登记表/registry，至少包含：稳定内部 ID、来源平台/渠道、原始来源 ID、产品/类别、正文哈希、时间戳、情感/主题版本、去重键、快照批次、可见性和数据质量状态。原始正文与脱敏正文分开保存，AI 只拿到最小必要字段。

### P1-2 页面交互

- 洞察页新增 `Evidence / Decision / Actions / Validation / Versions` 五个页签。
- 发布动作只对已确认洞察开放；发布时选择受众范围和版本说明，已发布版本不可原地改写。
- 行动中心增加“待验证”泳道，完成行动后自动打开验证表单：指标、基线、目标、窗口、观测值、结论。
- 验证结果页支持按洞察、主题、产品、负责人和时间窗口过滤，并可回跳原始证据。
- 当验证结果为 `ineffective` 或 `partially_effective` 时，系统生成复盘草稿和下一轮补证据问题，不自动创建新的产品行动。
- 行动中心可同时展示 SaaS ActionItem 与本地规则建议，但分别计数、分别标注数据来源。

### P1-3 AI 能力

- **主题演化**：基于确定性 topic key 计算新增、上升、缓解、复发，不让模型自行决定趋势；模型只解释已计算的变化。
- **相似反馈检索**：先按 workspace、产品、时间、来源和权限过滤，再按 embedding/关键词排序；每条结果带匹配原因和真实 evidence ID。
- **Grounded Explore**：支持对当前分析范围追问，回答必须返回引用、过滤条件、计算来源和数据缺口；对话仅生成草稿，发布洞察和创建行动仍需业务表单提交。
- **验证辅助**：根据 action 的 metric/baseline/target/window 生成观测模板，observed value 和 verdict 只能来自业务人员或确定性数据源。

### P1-4 成功指标与验收标准

| 指标 | 目标 |
| --- | --- |
| Published insight provenance | 100% |
| Version overwrite | 0 |
| Action validation completion | >= 80% of completed actions within due window |
| Verified action rate | >= 70% of completed actions |
| Feedback-to-insight reuse | >= 60% of published insights can list their evidence snapshot |
| Trend explanation grounding | >= 95% of explanations contain valid evidence/metric references |

验收：发布 v1 后编辑产生 v2，v1 仍可恢复；行动完成但没有验证记录时，系统拒绝标记“已解决”或强制进入待验证；提交验证后能在洞察详情显示结果，并能作为下一次 `AnalysisRun.input` 的统计来源。

## 6. P2：规模化智能与质量运营

**目标**：在 P0/P1 数据可信和闭环可回流后，降低重复分析成本并让 AI 升级可量化。

### P2-1 能力与数据模型

- `AiEvaluationRun`：记录 golden set、模型、提示词版本、schema pass rate、evidence precision、decision agreement、latency、token/cost、fallback rate。
- `TopicMergeSplit`：保存主题合并/拆分操作、操作者、旧 key、新 key 和生效时间，维护跨周期主题记忆。
- `ReportDelivery`：记录周报版本、收件范围、引用的 insight/action/validation ID 和发送结果，不保存无来源的自由生成结论。

### P2-2 页面交互

- AI 质量中心只对管理员/分析师开放，展示运行量、成功率、fallback、平均耗时、schema 失败、证据精度、人工一致率和成本趋势。
- 周报页面支持按 P0/P1、主题上升、逾期行动、待确认洞察和验证结果生成摘要；所有摘要可点击回平台详情。
- 相似反馈结果支持人工“合并/拆分/忽略”，系统展示相似原因，不自动合并原始证据。

### P2-3 AI 能力

- 受控模型/提示词 A/B 与 golden set 回归；只有达到门槛的组合才标记 production。
- Schema-aware dashboard：AI 只能从白名单指标、维度和图表类型中选择，数值由确定性查询提供。
- 基于验证结果的检索增强：将“有效/无效/未测量”作为反馈信号，提升建议排序，不直接把人工结论当作自动真相。

### P2-4 成功指标与验收标准

| 指标 | 目标 |
| --- | --- |
| Golden set schema pass rate | >= 99% |
| Evidence precision | >= 99.5% |
| Human decision agreement | >= 85% |
| AI fallback rate | < 10%，异常期可单独告警 |
| Median insight latency | < 15s for configured sample window |
| Duplicate topic review load | 下降 >= 30% |
| Weekly report citation coverage | 100% |

验收：同一 golden set 上比较模型/提示词版本，报告可重现；任一 evidence precision 或 schema pass rate 低于门槛时，版本保持非 production；周报中的每条重要结论至少能跳到一个洞察和一条原始证据。

## 7. 开发拆分与依赖顺序

### Sprint 1：P0 数据契约和门禁

1. 新增 `InsightDecision` 的 domain、repository、Parse/Postgres migration、routes、audit 和测试。
2. 扩展 `ActionItem` 的 `sourceDecisionId/sourceKind/creationKey`，实现服务端决策门禁和幂等。
3. 在 `PATCH analysis` 终态写入前加入 schema + evidence subset + coverage validator。
4. 确认部署环境的 `schema_migration` 已应用 `003_action_item_insight_source.sql`、`004_action_item_source_integrity.sql`；未确认前不把 Postgres 视为已验收。

### Sprint 2：P0 前端闭环和行动中心接通

1. AI 洞察页实现证据审阅、决策状态、决策提交和创建行动门禁。
2. 反馈收件箱将快捷行动改为加入分析，或实现明确的 `raw_feedback` 类型。
3. 行动中心接入 `SaasPlatformService.actions()`，支持列表、详情、状态更新和来源回跳。
4. 用真实数据跑桌面/移动端验收，覆盖刷新、历史恢复、重复提交、权限失败、AI 降级。

### Sprint 3：P1 资产发布和效果验证

1. `InsightRecord` 版本化和发布/归档页面。
2. `ActionValidation` 表单、接口、查询和验证结果回流。
3. 统一 feedback evidence registry 与增量同步质量指标。
4. 建立 50-100 条 golden set，纳入 CI 或发布前回归。

### Sprint 4+：P2 规模化智能

1. AI 质量中心、成本/延迟/失败观测。
2. 相似反馈、主题合并拆分和跨周期趋势。
3. 受控问答、schema-aware 报告和带引用周报。

依赖规则：P0 的决策门禁、服务端 grounding 和 Action API 接通完成前，不做自动发布、自动创建行动、自动发送周报或无引用的对话式推荐。

## 8. 最终验收清单

- [ ] 反馈证据有稳定 ID、来源、时间、产品和权限边界。
- [ ] AnalysisRun 的输入、结果、模型/提示词/规则版本可复现。
- [ ] 任何洞察证据 ID 都属于本次输入，coverage 可由服务端重算。
- [ ] 洞察有 `confirmed/rejected/needs_more_evidence` 决策，含人员、时间、理由和已阅证据。
- [ ] 未确认洞察的正式行动入口关闭；补证据只创建数据质量任务。
- [ ] ActionItem 可通过来源链回到 InsightDecision、Insight、AnalysisRun 和原始 Evidence。
- [ ] 行动中心读取 SaaS ActionItem，规则建议与正式行动分开统计。
- [ ] ActionItem 完成后有验证指标、基线、目标、观察窗口、观测值、结论或未测量原因。
- [ ] 刷新、历史恢复、权限变化和跨页面跳转不丢失上下文。
- [ ] local/Parse/Postgres 的持久化差异有验收说明，Postgres migration 状态可查询。
- [ ] AI schema、证据精度、人工一致率、fallback、延迟和成本有可重复评估。

## 9. 核心决策

1. **先做可审计门禁，再做更多 AI 功能**：`completed` 只代表计算结束，不代表洞察成立；`confirmed` 才是正式行动入口。
2. **服务端是最终事实源**：前端负责体验和预填，服务端负责 schema、证据子集、workspace、权限、决策和幂等校验。
3. **原始反馈快捷行动不再伪装成洞察行动**：默认加入分析；保留快捷入口时必须显式标注 `raw_feedback`，并独立归因。
4. **行动中心统一消费 SaaS ActionItem**：本地规则建议保留，但作为独立来源，不与正式行动混合计数。
5. **洞察和运行分离**：AnalysisRun 记录一次计算，InsightRecord 记录可发布版本，避免刷新或重新生成覆盖业务资产。
6. **完成不等于有效**：ActionValidation 是闭环的最后一跳，验证结论必须能回写下一轮分析输入。
7. **AI 只能解释已计算和已引用的事实**：趋势、KPI、成本和结果由确定性数据层提供，模型输出必须带引用并经过版本化评估。

## 10. 代码依据

- 前端 AI 洞察：`src/modules/ai-voc-insight/ai-voc-insight.component.ts`、`ai-voc-insight.component.html`、`ai-voc-insight.service.ts`、`ai-voc-insight.models.ts`
- 前端反馈收件箱：`src/modules/feedback-inbox/feedback-inbox.component.ts`、`feedback-inbox.component.html`、`feedback-inbox.models.ts`
- 前端行动创建：`src/modules/shared/components/action-create-panel/action-create-panel.component.ts`、`action-create-panel.component.html`
- 前端 SaaS 契约：`src/app/core/services/saas-platform.service.ts`
- 前端行动中心：`src/modules/domestic-voc/framework/domestic-action-workbench.component.ts`、`domestic-action-workbench.component.html`、`src/app/core/services/domestic-analytics-adapter.service.ts`
- 后端契约与状态机：`src/modules/saas-platform/domain.ts`、`src/modules/saas-platform/routes.ts`
- 后端 repository：`src/modules/saas-platform/local-platform.repository.ts`、`parse-rest-voc.repository.ts`、`postgres-platform.repository.ts`
- 数据库迁移：`migrations/002_saas_platform.sql`、`migrations/003_action_item_insight_source.sql`、`migrations/004_action_item_source_integrity.sql`
- 迁移执行器：`src/db/migrations.ts`
- 既有审计说明：`docs/AI-VOC-INSIGHT-LIFECYCLE.md`