BPOS-TMP-REPO/docs/SS02-ACT-WORK-05-html/ACT-WORK-05-活动流程与工单说明.md

# ACT-WORK-05 差异评估 — 活动流程与工单说明

> 素材来源：`activity/SS02-需求分析与方案匹配/SS02_ACT-WORK-05_差异评估_E04-I01架构版_V1.2.html`（v1.2 Demo 架构版）
> 工单目录：`SS02-ACT-WORK-05-html/`（1 数据（条件触发）+ 1 执行 + 2 验收，共 4 份）
> 本套工单已按《SS02-SS03-SS04_Demo台账字段细化与统一方案》（2026-08）完成字段级对齐。

---

## 一、活动定位

- **活动**：ACT-WORK-05 差异评估，P0，所属 SS02 需求分析与方案匹配子系统 / BT-02 跨品牌替代选型场景，负责人 FAE/RI。
- **是什么**：将「候选 PN 是否可替代」拆解为参数、封装、工艺、生命周期、应用边界和验证条件的逐项比较，形成逐项可复核的差异结论（MATCH / MISMATCH / UNKNOWN / CONDITIONAL），并保留证据、风险和下一步动作。输出 AI 分析草稿和 FAE 审核结论，**不自动批准替代关系**。
- **产出物**：差异评估结论 + 推荐等级 recommendation_level（推荐 / 条件推荐 / 备选 / 不推荐），审核通过后落账 **P-11 替代关系主记录**（含 P-11 差异明细子表，一条参数差异一条记录 difference_item_id），并回写 **P-01**（风险等级、验证要求、输出链接、下一步动作、当前阶段）。
- **触发**：双通道——①上游触发：ACT-WORK-03 检索调用 / ACT-GATE-02 路径判定后；②一键手动启动：运营端按钮表单直接启动（绕过 ACT-GATE-02 路径判定，故启动理由必填、source_type=手动启动 留痕，详见《ACT-WORK-05-一键启动入参说明.md》）。**触发渠道仅是活动外部关注点，活动内部与工单不承载触发渠道信息——两种通道传入同一字段集，工单无差别呈现。**
- **门禁**：ACT-GATE-03 评审放行（本活动终点）。
- **下游**：ACT-WORK-08 证据归集消费本活动结论。
- **冷启动能力**：依赖库为空（PN 按 internal_pn 查无记录）时，系统派**数据工单**创建主数据，确认即入库后活动自动从「等待数据」唤醒继续——活动不因空库终止。
- **台账读写**：P-01（R+W）、P-06（R/C，条件写）、P-08（R；无记录时经数据工单 W 创建）、P-09（R）、P-10（R；无记录时经数据工单 W 创建）、P-11（R+W；其中客户批准状态 customer_approval_status **只读边界**，由审批流程维护，本活动不产生）、GOV 规则（R，带版本锁定 rule_version）。
- **进入条件（极简口径）**：启动入参仅 **4 项**——客户 customer_id、客户需求 request_description（新建 P-01·V1）、原 PN、候选 PN（数组 ≥1）；应用场景、BOM 位、替代类型、规则版本、负责人/期限等**启动后在工单内补齐，不回表单**；datasheet 在数据工单里上传（选填），只影响 AI 预填程度。
- **退出条件**：每个候选 PN 都有差异状态、证据/缺口、风险和验证建议，并完成 FAE/RI 审核。

## 二、整体流程（5 步工作链条）

**步骤 1 · 建立评估上下文（PW/AI）**
- AI 做什么：绑定评估对象，生成输入快照。
- AI 怎么做：读 → 经读数工具读 P-01（启动新建的 demand 主记录：客户、需求描述、版本 V1）、P-09（BOM 位 bom_position）、EXT-02（外部来源清单）；加工 → 绑定启动 4 项（客户/需求/原 PN/候选数组），核对资料齐备度，标出缺口项（应用场景、BOM 位等待补）；输出 → 输入快照 input_snapshot_ref（活动自持中间产物）。
- 人做什么：**PW 介入**——补启动时未收的信息（应用场景、BOM 位），确认或调整系统默认值（替代类型、规则版本、负责人/期限），补 AI 拿不到的资料（实测记录等）（执行工单 01）。
- 触发纪律：触发传入参数即活动进入条件，系统据此生成 input_snapshot_ref 并完成绑定后派执行工单 01，PW 仅补缺口，绑定参数不可改（双通道与渠道无感知原则详见第七节）。

**步骤 2 · 读取并标准化资料（AI）**
- AI 做什么：把多来源资料整理成可比对的标准参数表。
- AI 怎么做：读 → P-08（原 PN 物料基准）、P-10（候选原厂 Datasheet、补证、承诺函，资料类型由 document_type 区分）、P-06（历史验证事实）、GOV 规则（评估口径）；**每次读台账均做存在性检查：查无记录→主数据/资料类派数据工单（一单一类可多条），事实/证据类（如 P-06）挂验证任务**；加工 → 统一参数名称、单位、版本和证据引用，缺失项标记 UNKNOWN；输出 → 标准化参数对照表（活动自持）。
- 人做什么：无需介入（纯 AI 加工态）。

**步骤 3 · 逐项差异评估（AI）**
- AI 做什么：逐项给出差异结论。
- AI 怎么做：读 → 步骤 2 的标准化对照表 + GOV 规则版本 rule_version（取参数时同样做存在性检查：查无记录→派数据工单或挂验证任务）；加工 → 按硬约束（封装/工艺等）与软约束（constraint_type）逐项判定，输出 MATCH / MISMATCH / UNKNOWN / CONDITIONAL（difference_status），并说明影响、风险等级、证据引用与置信度；输出 → P-11 差异明细子表草稿（一条参数差异一条记录 difference_item_id，**审核前不落账**），不改变客户批准关系。
- 人做什么：无需介入（AI 计算态），结论交步骤 4 审核。

**步骤 4 · FAE/RI 审核与补证（FAE/RI）**
- AI 做什么：把步骤 3 草稿整理成可审核视图（四态 pill + 证据链）。
- AI 怎么做：读 → P-11 差异明细子表草稿；加工 → 按验收判据组织展示（漏项检查、UNKNOWN 去向、证据回链、硬约束检查）；输出 → 审核工单视图。
- 人做什么：**FAE/RI 介入**——确认参数解释、风险等级、证据可信度和验证要求，必要时退回补证；审核意见与补充条件条件写 P-06（验收工单 01）。

**步骤 5 · 提交评审放行（FAE/RI + Gate）**
- AI 做什么：汇总拟落账内容供确认。
- AI 怎么做：读 → 审后结论；加工 → 生成拟写 P-11 替代关系主记录字段值（替代类型/原内部料号/候选内部料号/推荐等级/推荐理由/差异摘要/替代分析报告/分析状态/风险等级/验证要求/证据可信度/差异规则版本）与拟回写 P-01 字段值（风险等级/验证要求/输出链接/下一步动作/当前阶段）；输出 → 落账确认视图。
- 人做什么：**FAE/RI 介入**——确认拟落账内容无误后，在对话区卡提交 ACT-GATE-03（验收工单 02）。放行后更新 P-01 状态，结论供 ACT-WORK-08 证据归集消费；客户批准状态 customer_approval_status 仍由审批流程维护，本活动不写。

## 三、工单划分逻辑

本活动为**纯数据/内容生产型**（同 I01），无物理执行环节（没有拜访、递送、线下执行），因此**没有执行回执类工单**。本活动使用**三类工单**，触发条件与分工严格区分：

| 类型 | 触发条件 | 判断方 | 人做什么 | 入库方式 |
|---|---|---|---|---|
| **数据工单** | **完全没有**：按 internal_pn 查台账（P-08 等主数据/资料类）无此记录 | 系统（硬查询） | 从零创建整条记录 | **确认即正式入库**（无草稿态、无审核环节），确认人=数据责任人并留痕 |
| **执行工单** | **有而不全**：PN 在库、个别字段/资料缺失 | AI（字段级判断） | 补缺字段、补资料链接 | 对话区【执行卡】提交，缺口可留 UNKNOWN |
| **验收工单** | AI 已产出结论，需人拍板 | AI 产出 + 人判断 | 通过 / 驳回 | 对话区【验收卡】通过后落账 |

- 数据工单与执行工单**严格区分、互不嵌套**：一个是「整条记录不存在」（系统判断），一个是「记录存在但字段不全」（AI 判断）。
- 数据工单**铁律一**：只能建主数据/资料类记录（P-08 / P-10 / S-03 / L-02），不能建事实/证据记录（P-06 验证记录须实测产生，只能挂任务）。

对生产流程逐步判定：

- **步骤 0.5（存在性检查，条件触发）**：启动校验发现 PN 不在库 → 派 **数据工单 01**（芯片主数据创建，本活动唯一数据单），确认入库前活动停在「等待数据」状态，确认后自动唤醒。
- **步骤 1（建立评估上下文）**：AI 能读台账建快照，但「参数原厂未披露、资料版本过旧」这类 **AI 拿不到的可信来源资料只有人能补** → 派 **执行工单 01**（评估输入与资料补齐确认，本活动唯一执行单）。
- **步骤 2（读取并标准化）、步骤 3（逐项差异评估）**：均为**纯 AI 加工态**——读台账、标准化、按规则计算，不需要人补内容、也没有产出要人拍板的中间结论 → **不派工单**，其结论并入步骤 4 的验收单呈现。
- **步骤 4（FAE/RI 审核）**：AI 已产出差异结论（四态 + 风险 + 证据），需要人判断「结论可信不可信、UNKNOWN 有没有去向」→ 派 **验收工单 01**（差异评估结论审核）。
- **步骤 5（提交 ACT-GATE-03）**：AI 拟好了落账内容，需要人确认「无误后入库 / 放行」→ 派 **验收工单 02**（评审放行与落账确认）。

结论：**1 数据（条件触发）+ 1 执行 + 2 验收**。本活动无独立复盘流程（结论复用由下游 ACT-WORK-08 与后续替代/方案流程承担），无需拆时间轴。三条硬约束全程成立：工单不承载审批/确认动作（动作在对话区卡）；要素完整（期限/判据/必填/去向）；交回内容可校验（执行单必填＊、验收单判据清单、数据单必填全齐才允许确认）。

## 四、每个工单详细说明

### 工单 0：数据工单 01 · 芯片主数据创建（WO-ACT-WORK-05-D01，条件触发）
- **对应步骤**：步骤 0.5 · 等待数据（惰性触发点之一；启动校验期的存在性检查只是第一次）。
- **三条定稿规则**：
  - **一单一类（可多条）**：每张数据工单只针对**一种台账**；**字段即表头、每行一条新记录，可一次创建多条**（如 P-08 一次建多个料号）；主记录与结构子表（如参数集）分表承载，子表行以主键（所属料号）归属记录；其它台账的缺失另行派发新实例。
  - **惰性触发（不限于启动）**：活动执行到任何一步，**每次读台账**发现「完全没有」（按主键查无记录）即派一张；同一活动可派发多张，按派发顺序编号 WO-<活动>-D01/D02/…；活动进入「等待数据」状态，全部确认入库后从断点续跑。启动校验只是惰性触发的第一次，不是唯一一次。并发去重不考虑（一活动一负责人）。
  - **模板统一**：数据工单只有**一个统一模板**（类型级），职责只有「数据创建」；实例化时按目标台账的字段 schema（《统一方案》字段表）渲染表头 + AI 预填/人全填。实例之间只有两处不同：**目标台账（决定表头 schema）、预填内容（决定行集）**（本单：目标台账=P-08 `meta.data.target_ledger`、本批记录=XL2596S-5.0 `meta.data.target_key`）。
- **触发**：系统按主键查台账**无此记录**（完全没有，系统硬查询）——原 PN 无数据=硬阻塞必须创建；候选 PN 无数据：候选数 ≥2 时人可二选一（放弃该候选【记录放弃原因】或创建），候选数 =1 时不能放弃、必须创建。事实/证据类查无（如 P-06 无验证记录）**不可创建**，只能挂验证任务。
- **创建什么**：①表 1 主数据记录（**字段即表头、每行一条新记录、可加行批量创建**：internal_pn★ / brand_name★ / manufacturer_name / specification_description★ / package★ / process_technology / lifecycle_status★ / eol_pcn_status（条件）/ datasheet_ref+datasheet_version（成对条件）/ application_scenarios，字段说明放表头第二行小字，tbody `in.create_p08_fields`）；②表 2 标准化参数集 normalized_parameter_set★（**每行一个参数、以「所属料号 internal_pn」列归属表 1 记录**：所属料号★/参数名/值/单位/约束类型/说明只读注释列，可加行，tbody `in.create_p08_params`，示例预填 7 行）。启动时传了 datasheet → AI 预填（计数槽 `sd.prefill_count`，示例 1 条记录 · 8 项字段 + 7 行参数）；没传 → 人全填，同为合法路径。
- **为什么两张表（粒度不同，一张表摆不平）**：表 1 的粒度是「一个料一行」——每个字段对每条记录只有一个值，字段集合由台账 schema 定死（主记录）；表 2 的粒度是「一个参数一行」——每个料挂一串行数不固定的参数，每行内部还有 参数名/值/单位/硬软约束 四件套（结构子表）。两者行数没有固定比例，合成一张表只有两条死路：①参数塞进料号行的某格——一坨文本，机器没法逐项消费（差异评估要逐项比对）、人没法校验必填，违反《统一方案》「重复明细用子表承载，不在单一文本字段堆叠」；②参数也变成列——不同料的参数清单完全不同（DCDC 和 MCU 没有共同列），列数不固定，表头无法按 schema 统一渲染，通用模板破产。所以必须两张表，靠表 2 的「所属料号」列做连接键（映射主表+子表的外键关系）：建 3 个料 → 表 1 三行、表 2 按料号分 3 组；入库时系统按该键把参数集挂到各自主记录下。
- **确认即入库与责任人**：人在对话区【数据卡】点确认 → **直接入正式库（record_status=有效），无草稿态、无审核环节**；确认人=该数据责任人，系统留痕（确认人 / 数据工单号 / 所属活动）；必填字段全齐才允许确认（表单级校验，不算审核）。入库后活动自动唤醒进步骤 1；入库后发现错误走主数据治理修正，工单不复用。
- **铁律一**：只能建主数据/资料类记录（P-08 / P-10 / S-03 / L-02），不能建事实/证据记录（P-06 验证记录须实测产生，只能挂任务）。
- **为什么是独立类型**：条件触发（只在「完全没有」时派发，非常驻）；产出是**共享资产**（进正式库、跨活动复用，不是本活动的中间产物）；模板直接来自台账字段定义（P-08 字段表），不是活动自定义表单；与执行工单「有而不全」严格区分、互不嵌套。

### 工单 1：执行工单 01 · 评估输入与资料补齐确认（WO-ACT-WORK-05-01）
- **对应步骤**：步骤 1/5 · 建立评估上下文。
- **做什么**：确认触发传入参数已绑定（只读回显），补齐「有而不全」的缺口资料。
- **AI 产出**：一张「评估输入清单」（`in.evaluation_inputs`）——按状态列区分：**已绑定**（灰底只读行，启动时冻结，仅 4 项：客户 customer_id、客户需求 request_description（新建 P-01 · V1）、原内部料号 original_internal_pn、候选内部料号 candidate_internal_pn[] 数组逐行）、**待补**（应用场景 application_scenario、BOM 位 bom_position——启动时未收）、**默认·可改**（替代类型 substitution_type 默认 Pin-to-Pin、规则版本 rule_version 默认 R-2026.07、负责人/期限按客户线默认）、**待确认·需补**（候选 PN 使能阈值原厂未披露，P-08）、**齐备**（原 PN 资料版本 P-10 Rev H 已核验、外部来源清单 EXT-02）；编辑闸读数 `sd.input_gap_count` 显示缺口项数。
- **人填什么**：缺口行「补充内容」列（必填＊）——资料链接 / 任务编号；可加行补充 AI 未列出的资料项（新行自动标「新增·待补」），可删行声明不适用；已绑定行在编辑态下仍只读、不可删。未补齐项按 UNKNOWN 进入评估。启动参数如有误，退回触发方修订后重新触发，本单不可改。
- **为什么是执行**：本单只覆盖「**有而不全**」——PN 已在库、个别字段缺失（AI 判断）；「**完全没有**」（PN 不在库）由系统派数据工单创建，不在本单，两类互不嵌套。可信来源资料的获取在 AI 识别规则之外（原厂未公开、实测未做），只有 PW 能补。

### 工单 2：验收工单 01 · 差异评估结论审核（WO-ACT-WORK-05-02）
- **对应步骤**：步骤 3~4/5 · 逐项差异评估 + FAE/RI 审核（步骤 2~3 为纯 AI 加工，不单独派单，结论并入本单）。
- **AI 产出**：P-11 差异明细子表草稿（7 行示例：输出电压/输出电流/开关频率/封装 MATCH，工作温度 MISMATCH 高风险，使能阈值 UNKNOWN 挂 VAL-2026-0188，生命周期 CONDITIONAL 凭 P-10 供货承诺函），每项带约束类型 constraint_type（硬/软约束）、四态 pill difference_status、风险等级、证据引用 evidence_ref、AI 置信度。
- **人审什么**（4 条判据）：关键参数差异均有明确状态（无漏项）；UNKNOWN 项均有去向（挂验证任务或补来源）；证据链完整（可追溯 P-08/P-10/P-06 或 EXT-02）；硬约束项未被自动判 MATCH。
- **为什么是验收**：结论是 AI 按规则算出的，FAE/RI 只拍板通过/驳回，不改内容；审核意见与补充条件写 P-06。

### 工单 3：验收工单 02 · 评审放行与落账确认（WO-ACT-WORK-05-03）
- **对应步骤**：步骤 5/5 · 提交 ACT-GATE-03。
- **AI 产出**：两张只读表——拟写 P-11 替代关系主记录（替代类型 substitution_type / 原内部料号 original_internal_pn / 候选内部料号 candidate_internal_pn / 推荐等级 recommendation_level「条件推荐」pill / 推荐理由 / 差异摘要 / 替代分析报告 analysis_report_ref RPT-2026-0188 / 分析状态 analysis_status「FAE确认」/ 客户批准状态 customer_approval_status「未提交」/ 风险等级 / 验证要求 / 证据可信度 / 差异规则版本 rule_version）；拟回写 P-01（风险等级 / 验证要求 VAL-2026-0188 / 输出链接 / 下一步动作 / 当前阶段）。
- **人审什么**（4 条判据）：推荐等级与差异明细一致（存在 UNKNOWN/CONDITIONAL 不得给「推荐」）；分析状态与客户批准状态分离（本单只写分析层 analysis_status=FAE确认，customer_approval_status 保持未提交，不由差异评估产生）；GOV 规则版本已锁定（R-2026.07）；回写 P-01 字段完整。
- **为什么是验收**：落账内容已由 AI 拟好，人只确认「无误后入库 + 放行」；客户批准不在本单范围（customer_approval_status 只读边界，由审批流程维护）。

## 五、文件对应关系与闭环流程图

| 文件 | 类型 | 对应步骤 | 一句话 |
|---|---|---|---|
| `ACT-WORK-05-数据工单-01-芯片主数据创建.html` | 数据 1/1（条件触发） | 步骤 0.5 | PN 不在库时系统派发，人创建整条 P-08 记录，确认即入库（责任人留痕）后活动唤醒 |
| `ACT-WORK-05-执行工单-01-评估输入与资料补齐确认.html` | 执行 1/1 | 步骤 1 | 评估输入清单：已绑定项只读核对 + 「有而不全」缺口项 PW 补齐，缺口项按 UNKNOWN 进入评估 |
| `ACT-WORK-05-验收工单-01-差异评估结论审核.html` | 验收 1/2 | 步骤 3~4 | FAE/RI 审核 AI 逐项差异结论（四态 + 证据链），意见写 P-06 |
| `ACT-WORK-05-验收工单-02-评审放行与落账确认.html` | 验收 2/2 | 步骤 5 | 确认拟写 P-11 / 回写 P-01 内容，提交 ACT-GATE-03 |
| `ACT-WORK-05-一键启动入参说明.md` | 说明文档 | 触发 | 运营端一键启动的入参总表、系统行为与工单衔接说明 |
| `ACT-WORK-05-全流程分支图.html` | 可视化 | 全流程 | 面向业务负责人的流程与全部分支一览（自包含零依赖） |

```
触发（双通道：ACT-WORK-03 检索调用 / ACT-GATE-02 路径判定 ｜ 一键手动启动，绕过 GATE-02，启动理由留痕）
  │
  ▼
步骤0.5 存在性检查（系统，条件触发）── PN 不在库？（全链路惰性检查的第一次；之后每次读台账仍可能再派 D02/D03…）
  │──►【数据工单 01】芯片主数据创建 ── 一单一类可多条（字段即表头、每行一条），对话区【数据卡】确认即入库
  │      确认前活动停「等待数据」；全部确认入库后从断点续跑
  ▼
步骤1 建立评估上下文（PW/AI）
  │──►【执行工单 01】评估输入与资料补齐确认 ── PW 补资料，对话区【执行卡】提交
  ▼
步骤2 读取并标准化资料（AI，不派单）── 缺失项标 UNKNOWN
  ▼
步骤3 逐项差异评估（AI，不派单）── P-11 差异明细子表草稿（不落账）
  ▼
步骤4 FAE/RI 审核与补证
  │──►【验收工单 01】差异评估结论审核 ── 对话区【验收卡】通过/驳回
  │      通过：意见与验证要求条件写 P-06
  │      驳回：退回补证 / 验证（回步骤 1 或挂 VAL 任务）
  ▼
步骤5 提交评审放行
  │──►【验收工单 02】评审放行与落账确认 ── 对话区【验收卡】通过/驳回
  │      通过：P-11 替代关系主记录落账 ＋ P-01 回写 ＋ 提交 ACT-GATE-03
  ▼
ACT-GATE-03 评审放行（门禁，本活动终点）
  ▼
下游 ACT-WORK-08 证据归集消费
（P-11.customer_approval_status 客户批准：全程只读边界，由审批流程另行维护）
```

## 六、动态数据标注

命名空间速查：`meta.*` 任务元数据 ｜ `card.*` 工单身份 ｜ `in.*` 执行/数据工单输入行集 ｜ `out.*` 验收单输出行集 ｜ `sd.*` 状态读数。

### 工单 0（数据 01）动态位置

| 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 卡头 sub | 收件人 | `meta.task.owner` | data-slot |
| 卡头 sub | 关联任务 | `meta.task.id` | data-slot |
| 卡头 side | 当前步骤（等待数据 · 步骤 0.5/5） | `meta.phase` | data-slot |
| 卡头 side | 最迟交回 | `card.deadline` | data-slot |
| note 读数 | AI 预填项数 | `sd.prefill_count` | data-slot |
| 表 1 tbody | 主数据记录行集（每行一条记录，可加行批量创建） | `in.create_p08_fields` | data-rows |
| 表 1 表头 th / 单元格 td | 内部料号★/品牌★/制造商/规格描述★/封装★/工艺/生命周期★/EOL-PCN（条件）/Datasheet 引用+版本（成对）/适配场景 ｜ internal_pn / brand_name / manufacturer_name / specification_description / package / process_technology / lifecycle_status / eol_pcn_status / datasheet_ref / application_scenarios | data-h / data-field | 列标签 / 列绑定 |
| 表 2 tbody | 标准化参数集行集（每行一个参数，按所属料号归属，可加行） | `in.create_p08_params` | data-rows |
| 表 2 表头 th / 单元格 td | 所属料号★ / 参数名 / 值 / 单位 / 约束类型 / 说明（只读注释 ro） ｜ internal_pn / param / value / unit / constraint / desc | data-h / data-field | 列标签 / 列绑定 |
| 页脚 | 工单编号 | `card.id` | data-slot |

### 工单 1（执行 01）动态位置

| 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 卡头 sub | 收件人 | `meta.task.owner` | data-slot |
| 卡头 sub | 关联任务 | `meta.task.id` | data-slot |
| 卡头 side | 当前步骤 | `meta.phase` | data-slot |
| 卡头 side | 最迟交回 | `card.deadline` | data-slot |
| 编辑闸读数 | 缺口项数 | `sd.input_gap_count` | data-slot |
| 表格 tbody | 评估输入清单行集（已绑定行只读 + 缺口行可编辑） | `in.evaluation_inputs` | data-rows |
| 表头 th | 输入项 / 来源 / 状态 / 绑定值·缺口说明 / 补充内容（req＊） | data-h | 列标签 |
| 单元格 td | input_item / source_ledger / status / detail / supplement | data-field | 列绑定 |
| 页脚 | 工单编号 | `card.id` | data-slot |

### 工单 2（验收 01）动态位置

| 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 卡头 sub | 收件人 | `meta.task.owner` | data-slot |
| 卡头 sub | 关联任务 | `meta.task.id` | data-slot |
| 卡头 side | 当前步骤 | `meta.phase` | data-slot |
| 卡头 side | 最迟交回 | `card.deadline` | data-slot |
| 表格 tbody | 差异明细行集（P-11 差异明细子表草稿，difference_item_id） | `out.difference_items` | data-rows |
| 表头 th | 参数项 parameter_name / 原PN值 original_value / 候选PN值 candidate_value / 单位 parameter_unit / 约束类型 constraint_type / 结论 difference_status / 风险等级 / 证据引用 evidence_ref / AI置信度 | data-h | 列标签 |
| 单元格 td | parameter_name / original_value / candidate_value / parameter_unit / constraint_type / difference_status / risk_level / evidence_ref / confidence | data-field | 列绑定 |
| 页脚 | 工单编号 | `card.id` | data-slot |

### 工单 3（验收 02）动态位置

| 位置 | 动态数据 | 绑定地址 | 类型 |
|---|---|---|---|
| 卡头 sub | 收件人 | `meta.task.owner` | data-slot |
| 卡头 sub | 关联任务 | `meta.task.id` | data-slot |
| 卡头 side | 当前步骤 | `meta.phase` | data-slot |
| 卡头 side | 最迟交回 | `card.deadline` | data-slot |
| 表 1 tbody | 拟写 P-11 替代关系主记录行集 | `out.ledger_p11` | data-rows |
| 表 2 tbody | 拟回写 P-01 行集 | `out.writeback_p01` | data-rows |
| 表头 th | 字段 / 拟写入值 | data-h | 列标签 |
| 单元格 td | field / value | data-field | 列绑定 |
| 页脚 | 工单编号 | `card.id` | data-slot |

---

## 七、启动与触发（实现规格）

1. **双通道与渠道无感知原则**：触发方式 = ①上游触发（ACT-WORK-03 检索调用 / ACT-GATE-02 路径判定）②运营端一键手动启动。两通道传入**同一字段集**；活动内部与工单不承载、不区分触发渠道。source_type / 启动理由属运营端留痕字段，不传入活动。
2. **进入条件（启动校验，agent 必须在创建活动实例前校验，极简口径）**：启动入参仅 **4 项**——客户 customer_id、客户需求 request_description（无 P-01 记录则新建·版本 V1）、原 PN、候选 PN（数组 ≥1）。**应用场景、BOM 位、替代类型、规则版本、负责人/期限不是启动入参**——替代类型默认 Pin-to-Pin、规则版本默认当前发布版、负责人/期限按客户线默认，均在执行工单 01 列为「默认·可改」行由 PW 确认或调整；应用场景、BOM 位为「待补」行由 PW 补录。**datasheet 在数据工单里上传（选填）**——传了则 AI 在数据工单里预填，没传则人全填，不影响能否启动。
3. **存在性检查 = 全链路惰性触发（系统硬查询）**：启动校验期的存在性检查只是**第一次**；活动执行中**每次读台账**（步骤 2 读 P-08/P-10/P-06、步骤 3 取参数等）发现「完全没有」均再派新数据工单（一单一类可多条，按派发顺序 D01/D02/…）。活动可并行等待多张数据工单，全部确认入库后从断点续跑。启动期的两档语义：
   - 原 PN 无数据 → **硬阻塞**：必须派数据工单创建，确认入库前活动停在「等待数据」状态；
   - 候选 PN 无数据 → 候选数 **≥2** 时人可二选一（放弃该候选【记录放弃原因】或派数据工单创建）；候选数 **=1** 时不能放弃、必须创建；
   - 数据工单确认入库后，活动自动唤醒进入步骤 1。
   - datasheet 的有无不参与拦截，只决定数据工单是「AI 预填」还是「人全填」。
4. **任务锚点二选一（重点：request_id 与 requirement_version 是系统产出，不是入参）**：
   - **关联已有需求**：选 request_id，版本自动带出；
   - **快速创建**（客户口述需求未建档场景）：入参 = customer_id（老客户下拉选；新客户先建 L-02，属分支 0a）+ 需求描述（口述整理成文字）；系统行为 = **自动创建 P-01 记录、生成 request_id、requirement_version 默认 V1**，并把原 PN 与候选 PN 数组作为独立启动参数挂载绑定。
5. **口述需求的版本纪律**：版本属于需求记录而非客户口述；客户后续补充 / 澄清 → 更新 P-01 记录，requirement_version 递增（V1→V1.1，旧版保留）；每次评估锁 as_of 版本（input_snapshot_ref 记录当时按哪版评），全程可回溯。
6. **启动后系统行为序列**：校验进入条件（4 项） →（快速创建时建 P-01 · V1）→ **存在性检查**（按 internal_pn 查台账，候选数组逐个查；缺则派数据工单，活动停「等待数据」，确认入库后唤醒）→ 绑定客户 / 需求 / 原 PN / 候选数组 + 落系统默认值（替代类型、规则版本、负责人/期限）→ 生成 input_snapshot_ref → 进入步骤 1 派执行工单 01。
7. **冻结与退回纪律**：触发时绑定的参数在工单内只读不可改；绑错的唯一处理 = 退回触发方修订后重新触发（手动 → 退回运营端启动人；上游 → 退回上游活动）。
8. 参数字段集详见同目录《ACT-WORK-05-一键启动入参说明.md》（运营端规格）。

## 八、完整流程分支总表（含示例）

1. **示例场景**（口径注意：本活动只评技术可替代性，示例不涉及库存数量 / 采购情节）：客户工业电源项目在用 LM2596S-5.0（TI，12V→5V），原厂 PCN 转 NRND，客户要求验证替代；候选 A=XL2596S-5.0、B=LM2596S-ADJ、C=国产某 DCDC；一键快速创建需求单 REQ-20260826-001（V1）；应用场景（12V→5V、工业温域、40V 输入上限）启动后在执行工单 01 补录。
2. **分支总表**（18 条全列）：

| 分支 | 触发条件 | 处理与去向 |
|---|---|---|
| 0a | 启动期：新客户无档案 | 先建 L-02 客户档案（数据工单），再返回启动 |
| 0b | 启动期：候选无 P-08 主数据 | 同分支 1d：派数据工单登记创建 |
| 0c | 启动期：未传 datasheet | **不再拦截**——datasheet 已是选填，仅意味着数据工单由「AI 预填」变为「人全填」 |
| 1a | 步骤 1：绑定参数有误 | 退回触发方修订后重新触发（工单内不可改） |
| 1b | 步骤 1：输入存在缺口（有而不全） | 补缺口四情形：候选 PDF 未入库→补链接+版本；参数原厂未披露→挂验证任务（P-06）；原 PN 资料版本过旧→补最新版；应用约束不清→回头问客户并更新需求单版本 |
| 1c | 步骤 1：缺口补不了 | 留 UNKNOWN 进入评估（合法路径，不阻断） |
| 1d | 任何读数点：查无记录（完全没有） | 惰性触发派数据工单（一单一类可多条，模板统一，可多实例 D01/D02/…）：原 PN=硬阻塞·必须创建；候选 ≥2 可放弃【记录放弃原因】或创建（人判断）；候选 =1 必须创建。确认即入库（责任人留痕）→ 活动从断点续跑。事实/证据类查无（如 P-06）不可创建，挂验证任务 |
| 2a | 步骤 2：单位冲突 | 阻断，回步骤 1 补证 |
| 2b | 步骤 2：证据版本冲突 | 人工复核哪份资料为准 |
| 3a | 步骤 3：硬约束 MISMATCH | 该候选直接「不推荐」（示例：候选 C 输入上限 32V &lt; 客户 40V） |
| 4a | 步骤 4：UNKNOWN 无去向 | 退回步骤 1~2 补证 / 挂验证任务 |
| 4b | 步骤 4：证据链不全 | 退回补齐证据回链 |
| 5a | 步骤 5：ACT-GATE-03 放行 | P-11 落账（analysis_status=FAE确认），衔接下游 |
| 5b | 步骤 5：ACT-GATE-03 驳回 | REWORK：回步骤 4 重审，或回步骤 1 重补输入 |
| 6a | 完结：至少一个推荐 | 交下游衔接（ACT-WORK-08 / SS03 / ACT-WORK-24） |
| 6b | 完结：全是条件推荐 | 等验证闭环——通过→升级推荐；不过→降级不推荐 |
| 6c | 完结：全不推荐 | 重新检索替代料 / 继续用原 PN / 与客户协商放宽约束 |
| 6d | 完结：客户不批准 | 走独立审批流（customer_approval_status），不在本活动 |

3. **结果矩阵（示例）**：

| 候选 | 推荐等级 | 关键依据 | 下一步 |
|---|---|---|---|
| A · XL2596S-5.0（XLSEMI） | 条件推荐 | 温度范围更优（-40~+125℃ vs +85℃）；使能阈值 UNKNOWN，挂 VAL-2026-0188 实测 | 验证闭环后转正 |
| B · LM2596S-ADJ（TI 同族可调版） | 备选 | 反馈网络不同（可调版 vs 固定 5V），需改 BOM 外围 | 客户接受改设计则启用 |
| C · 国产某 DCDC | 不推荐 | 硬约束失败：输入上限 32V &lt; 客户 40V（分支 3a） | 归档，不再评估 |

4. **多候选并行原则**：N 个候选 = N 条独立 P-11 记录，并行评估、独立落账，不存在「选一个再评下一个」。
5. 可视化版本见同目录《ACT-WORK-05-全流程分支图.html》。

## 九、后端实现纪律（agent 必读，逐条不可违反）

1. request_id / requirement_version / input_snapshot_ref 一律系统生成，agent 不得要求调用方传入。
2. 活动实例创建前必须做进入条件校验与存在性检查；原 PN 无数据必须硬阻塞并派数据工单，返回缺什么；候选 PN 无数据按规则处理（≥2 可放弃【记录放弃原因】或创建，=1 必须创建）。
3. 已绑定参数任何接口不允许修改；修改请求一律返回「退回触发方重新触发」。
4. UNKNOWN 是一等公民：缺参数不得伪造、不得留空字符串冒充，必须显式标 UNKNOWN 并记录去向（挂验证任务 / 补来源）。
5. 硬约束 MISMATCH 不得被任何人工操作改判 MATCH；人只能补证据后重评。
6. analysis_status 与 customer_approval_status 严格分离：本活动只能推进 analysis_status（AI草稿→FAE确认），customer_approval_status 一律不碰（由独立审批流维护）。
7. 规则版本 as_of 锁定：评估开始即记录 rule_version；评估中途 GOV 规则更新不得影响进行中的评估。
8. 本活动输出只回答「技术可替代性」：不得在活动内做数量、价格、交期、采购判断（那是 SS03 / ACT-WORK-24 的事）。
9. 执行工单缺口的处理闭环：补不了的缺口必须能以 UNKNOWN 合法放行，不得阻塞流程等人填（人可以不填）。
10. 多候选并行：任何「单候选」假设（字段只存一个 candidate）都是错的，必须支持 N 候选独立评估与落账。
11. 数据工单**确认即入库**：无草稿态、无审核环节，确认直接写正式库（record_status=有效）；确认人=数据责任人，系统必须留痕（确认人 / 数据工单号 / 所属活动）。
12. 数据工单必填字段全齐才允许确认（表单级校验，不算审核）；缺必填不得放行确认。
13. 事实/证据类记录禁止工单创建：P-06 验证记录等只能实测产生、挂任务闭环；数据工单只能建主数据/资料类记录（P-08 / P-10 / S-03 / L-02）。
14. datasheet 选填：不得作为启动拦截条件；其有无只决定数据工单 AI 预填程度。无 datasheet 创建的数据，差异明细证据来源必须标「人工录入 · 数据工单 WO-xxx · 确认人 xxx」。
15. 并发去重不考虑：一个活动只绑一个负责人，不实现数据工单的去重 / 合并逻辑。
16. **一单一类（可多条）**：每张数据工单只针对一种台账，禁止混合台账；一张单可批量创建多条记录（字段即表头、每行一条）；不同台账 / 不同读数点的缺失 = 多张单（D01/D02/…，按派发顺序编号）。
17. **惰性触发不限于启动**：每次读台账都必须做存在性检查，查无记录即派单；不得只在启动时检查一次。活动可同时等待多张数据工单，全部确认后从断点续跑。
18. **模板统一**：数据工单只有一个统一模板（类型级，职责只有数据创建）；实例化按目标台账字段 schema（《统一方案》字段表）渲染表头，实例间仅两处可变——目标台账（决定表头 schema）、预填内容（决定行集）。

---

## 附：v1.2 待确认 4 项 — 落地状态

素材第六节列出 4 项待确认问题。按《SS02-SS03-SS04_Demo台账字段细化与统一方案》（2026-08），本套工单的落地状态如下：

| # | 待确认问题 | 落地状态 |
|---|---|---|
| 1 | 差异明细正式归属是什么？（P0） | **已落地**：差异明细 = P-11 差异明细子表（difference_item_id，一条参数一条记录）；验收工单 01 的 `out.difference_items` 行集即其草稿视图，含 parameter_name / original_value / candidate_value / parameter_unit / constraint_type / difference_status / evidence_ref 等字段。 |
| 2 | P-11 何时允许写入？（P0） | **已落地**：以 analysis_status 枚举区分写入时机（AI草稿→FAE确认），客户批准独立为 customer_approval_status 字段，由审批流程维护，不由差异评估产生；验收工单 02 只写分析层（analysis_status=FAE确认），customer_approval_status 保持「未提交」。 |
| 3 | 硬约束规则由哪个 GOV 对象维护？（P0） | rule_version 字段已落在差异明细子表（记录评估时采用的硬/软约束规则版本，本单锁 R-2026.07）；维护方归属仍待 GOV 确认（P0 遗留）。 |
| 4 | 是否按 BOM 位独立评估？（P1） | bom_position 字段已落在 P-01 与 P-11 主记录（执行单评估输入清单以「BOM 位 bom_position」待补可编辑行承载，启动后补录，示例 U3 电源位）；多 BOM 位边界不混用，不做按位独立评估。 |
| 5 | 冷启动与数据工单 | **已落地**：新增第三类工单「数据工单」——PN 不在库（完全没有，系统硬查询）时派发，人创建整条主数据记录，**确认即入库**（无草稿态、无审核环节），确认人=数据责任人并留痕；与执行工单「有而不全」严格区分、互不嵌套。 |