This repository has been archived on 2026-09-13. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
BPOS-TMP-REPO/docs/SS02-ACT-WORK-05-html/ACT-WORK-05-活动流程与工单说明.md
T
xcsandClaude Fable 5 bd86dd6088 docs(w05): 差异评估的目标件五份 HTML + 三份说明 + 实施计划;三张图
活动包 views/target-style.ts / report.ts 与两份 W05 文档都指着 docs/SS02-ACT-WORK-05-html ——
模版「逐字节搬自目标件」的那份目标件此前没入库。docs/img/cy 三张 png 现无引用,随批入库。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0167qWjeyBwvfdGovd7FWbCu
2026-08-27 11:44:35 +08:00

37 KiB
Raw Blame History

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)

  • 对应步骤:步骤 34/5 · 逐项差异评估 + FAE/RI 审核(步骤 23 为纯 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 < 客户 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),不在本活动
  1. 结果矩阵(示例):
候选 推荐等级 关键依据 下一步
A · XL2596S-5.0(XLSEMI) 条件推荐 温度范围更优(-40~+125℃ vs +85℃);使能阈值 UNKNOWN,挂 VAL-2026-0188 实测 验证闭环后转正
B · LM2596S-ADJ(TI 同族可调版) 备选 反馈网络不同(可调版 vs 固定 5V),需改 BOM 外围 客户接受改设计则启用
C · 国产某 DCDC 不推荐 硬约束失败:输入上限 32V < 客户 40V(分支 3a) 归档,不再评估
  1. 多候选并行原则:N 个候选 = N 条独立 P-11 记录,并行评估、独立落账,不存在「选一个再评下一个」。
  2. 可视化版本见同目录《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 不在库(完全没有,系统硬查询)时派发,人创建整条主数据记录,确认即入库(无草稿态、无审核环节),确认人=数据责任人并留痕;与执行工单「有而不全」严格区分、互不嵌套。