Archived
docs: ADR-014 确定性步骤 + W05 重写设计 spec + 实施计划(第一份:平台机制)
spec 定死八条:配方驱动零工具 · 六张台账 + P-06 按结论入账 · 四态 AI 定等级规则算 · 保存即铺格 · 类型不一致硬拦 · 审核卡只有确认 · 只做真用得到的那几式。 计划十三个任务,机制先在纯函数与假端口上钉死,再去接真活动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
This commit is contained in:
xcs
@@ -0,0 +1,340 @@
|
||||
# ADR-014 确定性步骤:确定的活由引擎按声明做,不问模型
|
||||
|
||||
状态:**提案**(2026-08-28,待用户定)
|
||||
背景出处:ACT-WORK-05 差异评估九步流程盘点(§2)、`docs/ACT-WORK-05-端到端测试记录.md` 发现表 A–AE。
|
||||
关联:ADR-004(活动包 ABI:**系统不执行代码即知包为何物**)、`docs/活动开发规范.md` §4.4(自动收步)、
|
||||
`PlanStep.humanWrites`(2026-08-28 立的墙)、ADR-005(工具契约与落地预检)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题
|
||||
|
||||
用户 2026-08-28 的原话:
|
||||
|
||||
> 「这个不是一个确定的流程吗?根本不需要交给 ai,你直接查库不就知道有没有了吗?」
|
||||
|
||||
指的是 W05 的「逐个料号查库 → 不在库就铺骨架、发数据工单」。这一段没有任何判断余地,却写成了模型的 guide。
|
||||
不是活动作者偷懒 —— **平台里没有别的落点**:
|
||||
|
||||
| 现有机制 | 能做 | 不能做 |
|
||||
|---|---|---|
|
||||
| 纯工具(`pure`) | 算、读台账(1.2.0 起) | 写台账、发卡 |
|
||||
| 判定表(DMN) | 出结论 | 写台账、发卡 |
|
||||
| `doneWhen` | 判「办完没有」,引擎自己收步 | **做事** |
|
||||
| 哨兵(`entryCriteria`) | 判「能不能进这一步」 | **做事** |
|
||||
| 视图绑定语言 | 把台账取出来**摆到屏上** | 写回去 |
|
||||
|
||||
「读台账 + 写草稿 + 发人卡」跨了三样,没有一个机制能整段承接。而引擎这三样能力**全有**
|
||||
(`data.view` / `data.draftWrite` / `humanTool.issueExecution`)—— 缺的只是**声明面**。
|
||||
|
||||
`packages/activity-sdk/src/define.ts` 里 `run?` 的注释早就写着:
|
||||
|
||||
> 留着它是为**确定性子序列(结晶片段)**将来有个落点;不写就是不写,不是缺件。
|
||||
|
||||
这份 ADR 就是给那个落点定形。
|
||||
|
||||
**代价已经付过。** W05 的事故里,至少八条落在「本来就该是确定的」那几步上(§7 逐条验算)。
|
||||
|
||||
---
|
||||
|
||||
## 2. 盘点:W05 九步里哪些是确定的
|
||||
|
||||
| 步 | 确定的部分 | 需判断的部分 |
|
||||
|---|---|---|
|
||||
| **S0_bind** 建上下文 | 铸案号 · 查客户在不在库 · 写需求单(入参搬运+常量)· 逐料号查库写核对表 · 写结论行 | **零** |
|
||||
| **S0d_p08** 派主数据单 | 定名单 · 铺三张表骨架 · 发卡 · 人交回后改旗 | 有 datasheet 附件时从原文抽参数值 |
|
||||
| **S0d_p10** 派资料单 | 定名单 · 发卡 · 人交回后改旗 | **零** |
|
||||
| **S1** 评估输入清单 | 清单九行(四行绑定投影 + 两行固定缺口 + 三行常量默认)· 发执行单 · 把 supplement 抄进需求单 | 人补的自由文本**归纳**成技术约束 |
|
||||
| **S2** 标准化对照表 | 关系骨架 · 逐参数对照行(原 PN 参数集 × 候选同名行的 join)· 补封装/生命周期两行 | 单位换算;`constraint_type` 未标时归类(**应进 DMN,不进配方**) |
|
||||
| **S3** 逐项差异评估 | 工具串接 · 四态照抄 · 计数 · `difference_summary` · 置信取最小 | **客户原话 → 约束式** · 影响陈述 · UNKNOWN 去向与验证条件 · 推荐理由扩写 |
|
||||
| **S4** 结论审核 | 发决策卡(内容是计数投影)· approve 收步 | **读人的自由文本意见 → 定位到具体行 → 改实** |
|
||||
| **S5** 拟落账 | 分析状态推 FAE 确认 · 回写需求单五项(风险取最高档、VAL 号拼接、编号、常量三项) | 只有 summary 一句人话(可模板化) |
|
||||
| **T_release** 放行 | submit · 无分支去向 | 两条裁量判据 · 打回后修订 |
|
||||
|
||||
**agent 真正不可替代的只有四类**:①自然语言 → 结构化;②读人的意见并落到具体行;③写给人看的话;
|
||||
④非结构化来源抽取(datasheet 抽值、单位换算)。第四类在实跑中一次都没发生过(没传附件)。
|
||||
|
||||
**结论:九步里三步整个确定(S0_bind / S0d_p10 / S5),四步八成确定,只有 S3 是 agent 的主场。**
|
||||
按拍数算,一单十来拍里有七八拍在做确定性的活 —— 而每一拍都是一次采样,都有编错号、抄错行、漏一列的机会。
|
||||
|
||||
---
|
||||
|
||||
## 3. 决策
|
||||
|
||||
### 3.1 声明式配方,**不执行活动包代码**
|
||||
|
||||
`sys.activity_package.artifact`(包的 `index.js`)存了库,但**至今一次都没被执行过**。这份设计**不开这条路**:
|
||||
|
||||
- ADR-004 的立场是「系统不执行代码即知包为何物」;配方是**数据**,装进来仍然只是数据,
|
||||
可静态审、可回放、可在治理台上摆出「这一步系统会做什么」。执行代码则相反。
|
||||
- 执行第三方包要配沙箱、超时、内存墙,而 `scanArtifact` 只是文本扫描,拦不住混淆。
|
||||
- 配方要表达的形状**很窄**(§3.2 三个动词),不值得为它开一个能跑任意代码的面。
|
||||
|
||||
**代价**:表达力有上限。上限之外的**不要硬塞** —— 退回模型,或者把那一段切成独立的 agent 步(§3.4)。
|
||||
|
||||
### 3.2 三个动词,复用已有的两套求值
|
||||
|
||||
配方只有三个动词:
|
||||
|
||||
| 动词 | 做什么 |
|
||||
|---|---|
|
||||
| `project` | 从「某个来源的每一行」投影出台账行,`draftWrite` 落草稿层 |
|
||||
| `card` | 发一张人类工具的卡(执行工单 / 数据工单 / 数据录入卡),**至多一张** |
|
||||
| `say` | 一句给人看的交代(模板串,不是模型生成) |
|
||||
|
||||
条件与聚合**不发明第二套求值**:
|
||||
- 条件用 **S-FEEL**(`when`,对任务视图求值)—— 与哨兵、`doneWhen` 同一个求值器;
|
||||
- 计数/聚合用**基座读数**(`_rows` / `_missing` / `_distinct_x` / tally 计数)—— 本来就在作用域里。
|
||||
|
||||
### 3.3 `auto` 是「问模型之前先把确定的事做了」,不是「整步替代」
|
||||
|
||||
`PlanStep.auto` 是一个属性。引擎在这一步的**每一拍拍首**先跑配方,然后:
|
||||
|
||||
- 配方发了卡 → 这一拍到此为止(**零 token**,不问模型);
|
||||
- 没发卡且这一步**没有 `guide`** → 求 `doneWhen`,真了收步、进下一步(下一步若也是 auto 就接着跑);
|
||||
- 没发卡且这一步**有 `guide`** → 照常问模型(半 auto:确定的已经做完,模型只面对剩下的判断)。
|
||||
|
||||
这样老步骤一个字不改,可以一步一步搬。
|
||||
|
||||
### 3.4 作用域:**一个计划项内,到交出控制权为止**
|
||||
|
||||
配方跑到「发卡」就结束 —— 与现有 `handsOff` 语义(ask/human/decide/listen/submit 是交出控制权)对齐。
|
||||
人答回来之后,那一步若还有活,归 `guide`。
|
||||
|
||||
**推论(重要)**:一步要么确定,要么不是。**不做「一半 auto」的复杂机制** —— 判断点要先从那一步里切出去。
|
||||
例:S0d_p08 的「datasheet 抽值」应当移出这一步(归到起单读来件),这一步才变成纯 auto。
|
||||
**这条逼着活动作者把判断点想清楚,是特性不是限制。**
|
||||
|
||||
### 3.5 幂等
|
||||
|
||||
配方会被反复进入(人答卡后再 tick),必须幂等:
|
||||
|
||||
- **写**:`draftWrite` 本来就是同 PK 覆盖。值没变 → **静默跳过,不留痕、不算空转被拒**
|
||||
(「写了等于没写」那条判据是拦模型空转的,配方不是模型);
|
||||
- **发卡**:先看 `worldTouched` —— 发过就不再发。人工激活的 auto 步,**配方发卡就是启动**。
|
||||
|
||||
### 3.6 出错 = 交人,不重试、不退回模型
|
||||
|
||||
配方抛错(地址不存在、S-FEEL 算不出、卡骨架不合契约)是**活动包的 bug**:如实留痕 + 交人。
|
||||
**不重试五遍,也不退回模型** —— 退回模型就是让它去凑,那正是这份 ADR 要消灭的东西。
|
||||
|
||||
### 3.7 静态审在装的时候把住
|
||||
|
||||
`staticAudit` 扩到配方(与 `refersTo` 目标检查同款,写错地址 = 每一单都错):
|
||||
|
||||
- `into` / `each` / `lookup` / `joinRows` 的台账地址必须在 `declarations.ledger` 里(与写的授权面同一份名单);
|
||||
- `fields` 的列名必须在该对象的列声明里;
|
||||
- `when` 的 S-FEEL 必须能解析,引用的名字要绑得上(`boundNames`,已有);
|
||||
- 卡骨架的 `view` 必须在 `viewTemplates` 里;
|
||||
- 同一张表既在 `auto.project` 里又在 `humanWrites` 里 → **警告**(铺骨架合法,但要作者确认列不重叠)。
|
||||
|
||||
### 3.8 观测与度量
|
||||
|
||||
- 配方的每一笔照常进 `sys.task_memory`,`detail.auto = '<步名>#<第几笔>'`;
|
||||
工作日志三色里归**系统灰**(已有档,不必新增);
|
||||
- 治理台的活动详情能摆出「这一步系统会做什么」(配方是数据,渲染得出来)—— 这是相对提示词的一大好处;
|
||||
- **自主率的分法要认第三档**:现在两档(AI / 人),配方做的事既不是 AI 判的也不是人办的,是系统做的。
|
||||
|
||||
---
|
||||
|
||||
## 4. 声明形状
|
||||
|
||||
```ts
|
||||
// PlanStep 新增(可选,老活动一个字不改)
|
||||
auto?: AutoRecipe;
|
||||
|
||||
type AutoRecipe = {
|
||||
/** 配方级局部值:先算一遍,后面所有表达式都能引用({in:'evalRef'})—— 整单只有一个案号,靠它 */
|
||||
readonly let?: Record<string, AutoExpr>;
|
||||
/** 按序执行;每一笔可带 when(S-FEEL),假就跳过这一笔 */
|
||||
readonly do: ReadonlyArray<AutoAction>;
|
||||
};
|
||||
|
||||
type AutoAction =
|
||||
| { kind: 'project'; when?: string; into: string; from: AutoSource; fields: Record<string, AutoExpr> }
|
||||
| { kind: 'card'; when?: string; workOrder: 'execution' | 'entry'; variant?: 'data';
|
||||
title: AutoExpr; gateLedgers?: string[]; view?: string; /* 指导书等静态文本直接写 */ }
|
||||
| { kind: 'say'; when?: string; text: AutoExpr };
|
||||
|
||||
type AutoSource =
|
||||
| { once: true } // 一行
|
||||
| { rows: ReadonlyArray<Record<string, AutoExpr>> } // 固定几行(S1 的默认三项)
|
||||
| { each: string; where?: Record<string, AutoExpr>; // 'in:candidateInternalPns' | 'mine:域.对象' | 'ledger:域.对象'
|
||||
then?: { each: string; where?: Record<string, AutoExpr> } }; // 第二层,**最多两层**
|
||||
|
||||
type AutoExpr =
|
||||
| string | number | boolean // 常量
|
||||
| { in: string } // 入参 / case:* / 基座读数 / let
|
||||
| { self: true } // each 是数组时的本项
|
||||
| { col: string } | { outer: string } // 本行的列 / 外层那一行的列
|
||||
| { cat: AutoExpr[] } // 拼接
|
||||
| { fmt: AutoExpr; as: 'digits' } // 只留数字(铸号)
|
||||
| { lookup: string; by: Record<string, AutoExpr>; take: string; else?: AutoExpr } // 查另一张表的一列
|
||||
| { joinRows: string; where?: Record<string, AutoExpr>; take: string; sep?: string } // 多行一列拼成串
|
||||
| { when: string; then: AutoExpr; else: AutoExpr }; // S-FEEL 条件(可嵌套)
|
||||
```
|
||||
|
||||
**字段按声明顺序求值,已算出的字段进同一行的 S-FEEL 作用域** —— 「先 lookup 出依据,再按依据判 found/absent」
|
||||
这种写法靠它成立。
|
||||
|
||||
### 4.1 例:S0d_p10_document(整步确定,最小的那个)
|
||||
|
||||
```ts
|
||||
auto: {
|
||||
do: [
|
||||
{ kind: 'card',
|
||||
when: 'sub_eval_pn_check_exists_status_absent > 0',
|
||||
workOrder: 'execution', variant: 'data', view: 'p10-document-create',
|
||||
gateLedgers: ['parts.document'],
|
||||
title: { cat: ['数据工单 · 原厂技术资料创建(P-10):',
|
||||
{ joinRows: 'mine:sub_eval.pn_check', where: { exists_status: 'absent' },
|
||||
take: 'internal_pn', sep: '、' }] } },
|
||||
{ kind: 'say', text: '这几颗料的原厂技术资料库里查无记录,已派数据工单请你登记。' },
|
||||
],
|
||||
}
|
||||
// guide 不写。doneWhen 照旧:parts_document_rows >= parts_profile_rows and parts_document_missing = 0
|
||||
// 人在件上填完确认 → 数据即入库 → 下一拍 doneWhen 成立 → 引擎收步。**模型在这一步一次都不出现。**
|
||||
```
|
||||
|
||||
### 4.2 例:S0_bind 的铸号与存在性核对
|
||||
|
||||
```ts
|
||||
auto: {
|
||||
let: {
|
||||
digits: { fmt: { in: 'case:openedAt' }, as: 'digits' },
|
||||
evalRef: { cat: ['W05-', { in: 'digits' }] },
|
||||
requestId:{ cat: ['REQ-', { in: 'digits' }] },
|
||||
},
|
||||
do: [
|
||||
// 客户不在库 → 发数据录入卡,这一拍到此为止
|
||||
{ kind: 'card', when: 'customer_profile_rows = 0', workOrder: 'entry', /* … */ },
|
||||
{ kind: 'project', into: 'demand.request', from: { once: true },
|
||||
fields: { request_id: { in: 'requestId' }, customer_code: { in: 'customerCode' },
|
||||
requirement_version: 'V1', request_type: '技术需求',
|
||||
request_description: { in: 'requestDescription' },
|
||||
input_snapshot_ref: { cat: ['SNAP-', { in: 'evalRef' }] },
|
||||
original_internal_pn: { in: 'originalInternalPn' },
|
||||
request_status: 'pending', current_activity: 'ACT-WORK-05', current_stage: 'assessing' } },
|
||||
{ kind: 'project', into: 'sub_eval.pn_check', from: { each: 'in:candidateInternalPns' },
|
||||
fields: { eval_ref: { in: 'evalRef' }, internal_pn: { self: true }, role: 'candidate',
|
||||
found_pn_ref: { lookup: 'ledger:parts.profile', by: { internal_pn: { self: true } },
|
||||
take: 'internal_pn', else: '' },
|
||||
exists_status: { when: 'found_pn_ref != ""', then: 'found', else: 'absent' } } },
|
||||
// 原 PN 那一行同理(from: { once: true },role: 'original')
|
||||
{ kind: 'project', into: 'sub_eval.verdict', from: { once: true }, fields: { /* … */ } },
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
「在不在库」从此是一次 `lookup`,不是模型的一句断言 —— 08-27 那条「原 PN 不在库却判在库」结构性消失。
|
||||
|
||||
---
|
||||
|
||||
## 5. 引擎行为(拍内次序)
|
||||
|
||||
```
|
||||
tick 开始
|
||||
├─ ① 拍首自动收步(现有:doneWhen 为真的项,人工激活项需 worldTouched)
|
||||
├─ ② 算 current(当下在办的那一步)
|
||||
├─ ③ current.auto 存在 → 跑配方
|
||||
│ ├─ 求 let
|
||||
│ ├─ 按序执行每一笔(when 假则跳过)
|
||||
│ │ · project → 逐行 draftWrite(同 PK 覆盖;值没变静默跳过)
|
||||
│ │ · card → 先看 worldTouched,发过就跳过;发了标 worldTouched、烧 humanCalls
|
||||
│ │ · say → 进对话区
|
||||
│ ├─ 每一笔留痕(by=系统,detail.auto)
|
||||
│ └─ 抛错 → 留痕 + 交人(不重试、不退回模型)
|
||||
├─ ④ 发了卡 → status awaiting,收拍(零 token)
|
||||
├─ ⑤ 没发卡 → 重求 doneWhen;真了收步,回 ② (封顶 8 轮,与现有自动收步同款)
|
||||
├─ ⑥ 这一步有 guide → 照常问模型(半 auto)
|
||||
└─ ⑦ 无 guide、doneWhen 不成立、也没有卡在等 → **交人**(配方没做到位,是包的 bug)
|
||||
```
|
||||
|
||||
**预算**:配方不烧 token;发卡烧 `humanCalls`;配方段在同一 tick 内,不额外计 step。
|
||||
|
||||
---
|
||||
|
||||
## 6. 与现有机制的衔接
|
||||
|
||||
| 机制 | 处置 |
|
||||
|---|---|
|
||||
| `doneWhen` | 不变。auto 步几乎都该有 —— 它做的事是可验的 |
|
||||
| 哨兵 `entryCriteria` | 不变。auto 步照样要满足入场前提才在场 |
|
||||
| `worldTouched` | 配方发的卡同样标 —— 它是真发了 |
|
||||
| `humanWrites`(2026-08-28) | **配方豁免**:那道墙防的是模型即兴,配方是审过的声明。铺骨架合法,人填内容不冲突(静态审提示列不要重叠) |
|
||||
| 写三分 | 不变:配方只写**草稿层**,落正式表仍靠放行 / 数据工单确认入库 |
|
||||
| 「一单一卡」 | 不变:配方至多一张卡 |
|
||||
| 熔断 | 配方不会「被拒」,不进 `stalledTurns` |
|
||||
| 试跑 / 回放 | 配方是纯数据求值,同输入同结果 —— 可回放。**配方里没有时钟与随机**(时刻取 `case:openedAt`) |
|
||||
| 记账旗 | **该删的删,不是该 auto** —— `input_confirmed_total` 这类基座本就数得出来 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 回溯验算:历史事故有几条会结构性消失
|
||||
|
||||
| # | 事故 | 落在哪 | auto 后 |
|
||||
|---|---|---|---|
|
||||
| 1 | 编号从正式表里**别单的案号**里挑 | S0_bind 铸号 | 消失(模板铸号) |
|
||||
| 2 | 原 PN 不在库却判「在库」(发现 I) | S0_bind 查库 | 消失(lookup 现查) |
|
||||
| 3 | 数据工单派给了**在库**的那颗(发现 J) | S0d_p08 名单 | 消失(where absent) |
|
||||
| 4 | 压拍没写骨架就发卡,人打开是空表(发现 Q) | S0d_p08/p10 | 消失(配方按序) |
|
||||
| 5 | S1 清单 11 行全漏 `input_item`,人无处可填 | S1 前半 | 消失(字段声明齐全) |
|
||||
| 6 | 库里有值的参数被 S1 当缺口再问一遍(发现 AB,三次复现) | S1 前半 | 消失(清单是投影) |
|
||||
| 7 | P-10 抄**原 PN 的规格书**安在候选头上(发现 AE) | S0d_p10 | 消失(模型不出现) |
|
||||
| 8 | `finish` 撞 worldTouched 墙五拍熔断(发现 AE 同单) | S0d_p10 | 消失(那一步不问模型) |
|
||||
|
||||
**八条落在会被 auto 掉的三步半上。** 剩下的事故(工具没调、比对入参抄错、验收卡面孔、重做循环)
|
||||
不在这个范围内 —— 它们该由别的机制治,这份 ADR 不承诺。
|
||||
|
||||
---
|
||||
|
||||
## 8. 不做什么
|
||||
|
||||
- **不调工具**:工具有副作用面与预算面,先不给(S3 的 `compare → recommend` 串接留作待定)
|
||||
- **不 `finish`、不 `submit`、不发决策卡**:收步归 `doneWhen`,终局归 submit,岔路口本就是判断
|
||||
- **不写正式表**:仍走草稿层
|
||||
- **不做三层以上的嵌套**:两层(关系 × 参数)是 W05 的上限;超出就别 auto
|
||||
- **不在治理台上编辑配方**:那就成了低代码平台;配方随包走,改配方 = 升版本重装
|
||||
- **不承诺消灭 agent**:§2 的四类判断照旧归它
|
||||
|
||||
---
|
||||
|
||||
## 9. 代价与风险
|
||||
|
||||
1. **活动作者要写结构化声明,不能再靠散文。** 但那些散文本来就在(而且更长、还不能测);
|
||||
配方**能单测**(纯数据求值,包内自测钉死)。
|
||||
2. **代码错是必然的错,模型错是概率的错。** 配方写错 = 每一单都错。
|
||||
对策:静态审(§3.7)+ 包内自测 + 安装两审的回放审拿样例入参跑一遍配方。
|
||||
**但必然的错比概率的错好查** —— 这正是把它从模型手里拿走的理由。
|
||||
3. **立场要改口。** 「组织的工作定义为可编排的工作流……活动是完成一项任务的 Agent 机制」——
|
||||
加一句:**agent 只在真需要判断的地方出现,与「人只在责任点与放行点出现」是同一条原则。**
|
||||
确定的事交系统,判断交 AI,责任交人。
|
||||
4. **把有判断的地方硬写成规则的风险。** `constraint_type` 的 hard/soft 归类按品类会变 ——
|
||||
这类**进 DMN 判定表,不进配方**;配方里只许出现「取值、拼装、投影、发卡」。
|
||||
5. **现在的「确定」有一半是靠强制命名一致换来的。** S2 能纯 join,前提是「候选与原 PN 参数名一模一样」
|
||||
(P-08 建骨架时用中文名硬压 + 门上的行数对账)。**一旦料号来自外部导入**,同义归一就回来了 ——
|
||||
那是判断,是 agent 的活。**auto 化不等于永远不需要 agent。**
|
||||
|
||||
---
|
||||
|
||||
## 10. 迁移次序(每搬一步都要五案例 e2e:released + 被拒 0 才算数)
|
||||
|
||||
1. **`S0d_p10_document`** —— 最小、纯粹、刚出过事;拿它验证机制(配方 + 静态审 + 留痕 + 观测)
|
||||
2. **`S5_prepare_landing`** —— 整步确定、不发卡;验证「不发卡时接着走 doneWhen 收步」那条路
|
||||
3. **`S0_bind`** —— 整步确定、含一张录入卡的分岔;验证 `let` 铸号与 `lookup` 存在性
|
||||
4. **`S1_input_confirm` 前半** —— 清单投影 + 发卡;半 auto(收口仍归 guide)
|
||||
5. **`S0d_p08_master`** —— **先把 datasheet 抽值切出去**,再 auto
|
||||
6. **`S2_normalize`** —— 两层嵌套,最难;搬之前先确认它与比对工具的 join 是否重复(§11)
|
||||
|
||||
---
|
||||
|
||||
## 11. 待定(要用户定的)
|
||||
|
||||
1. **决策卡要不要给配方**:S4 第一张卡的 ask 内容是计数投影,确定;但决策卡是岔路口,给了会不会滑坡?
|
||||
2. **工具串接要不要做第四个动词**:S3 的 `compare → recommend` 之间模型只是转手 counts,却占掉整整一拍。
|
||||
3. **`humanWrites` 该不该细到列**:现在是表级。auto 铺骨架 + 人填内容之后,列级更准。
|
||||
4. **S2 与比对工具的 join 是否重复**:`compare-parameters` 1.2.0 起自己从台账取参数对,
|
||||
而 S2 让模型抄的 `difference_item` 对照表是**同一份 join**。一份事实做了两遍,一遍还是手抄的 ——
|
||||
要么 S2 auto 化,要么让工具的出参直接落 `difference_item`(那是另一个机制:工具出参绑台账)。
|
||||
5. **`T_release` 第三条裁量判据**「推荐等级与差异明细一致」就是工具的定级规则本身,
|
||||
让模型再裁一次是给自己盖章 —— 该删(与 08-01 在 A1 上拆掉 L4 同款)。
|
||||
@@ -1318,3 +1318,5 @@ pnpm 硬链到全局 store,真实占盘远小于这个数,但 `du` 看着吓人
|
||||
「说不在库」那一侧至今没有校验);08-28 模型把原 PN 的规格书抄到候选头上(已用 `humanWrites` 立墙)。
|
||||
真治法:剧本加 `auto` 步(声明「这一步引擎按规则做,不问模型」)。**代价**:活动模型往「配置化流程」挪一格,
|
||||
与「活动是 Agent 机制」的立场有张力 —— 但这一段本来就没有判断余地。真需要模型的只剩「有 datasheet 附件时从原文抽值预填」。
|
||||
**2026-08-28 已出设计:`docs/adr/ADR-014-deterministic-steps.md`**(声明式配方、三动词、迁移次序、回溯验算八条、
|
||||
五条待定)—— 待用户定后实现。
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,632 @@
|
||||
# SS02—SS03—SS04 Demo台账字段细化与统一方案
|
||||
|
||||
## 一、结论摘要
|
||||
|
||||
本成果以《SS01-02-03-04-台账体系全景-18Activity关联矩阵》的台账编号为唯一编号标准，对六组Demo Activity进行字段级反推和补齐：[1] [2] [3] [4] [5] [6]。结论是：**当前全景体系的台账编号总体可承载Demo，但核心内容描述仍不足以直接支撑执行，必须补充字段级定义、条件必填规则和主记录/子表结构。**
|
||||
|
||||
本方案将Demo中的细分编号按全景标准归并，例如P-01-01→P-01、P-08-01→P-08、P-11-01/P-11-02→P-11的不同关系状态或子对象；不新增与全景体系冲突的台账编号。[1] [2] [3] 对于逐参数差异、逐报价阶梯和逐份单证等重复明细，采用子表承载，避免在单一文本字段中堆叠数据。
|
||||
|
||||
## 二、编号归并与建模原则
|
||||
|
||||
> **编号原则：**全景矩阵的44个台账编号是主键标准；Demo中的-01/-02属于局部架构或对象层标识，除非全景矩阵明确存在对应台账，否则不作为新的全景台账编号。
|
||||
|
||||
|Demo原编号/写法|统一全景编号|统一后的对象/说明|
|
||||
|---|---|---|
|
||||
|P-01-01|P-01|客户具体需求与项目任务主台账；任务、需求版本、报价上下文和Activity回链统一归入。|
|
||||
|P-06-01|P-06|样品交付与芯片验证记录台账；验证事实与样品追溯统一归入。|
|
||||
|P-08-01|P-08|芯片主数据台账；全链路只认internal_pn。|
|
||||
|P-09-02|P-09|客户技术与机会档案；技术档案字段统一挂客户ID。|
|
||||
|P-10-01/02/03|P-10|原厂技术资料库；资料类型由document_type区分。|
|
||||
|P-11-01/P-11-02|P-11|替代选型与批准关系库；analysis_status与customer_approval_status分离，差异明细设子表。|
|
||||
|P-04-01/P-04-02|P-04|交易框架与承诺台账；框架主记录与承诺子记录分层。|
|
||||
|D-01物流F组/交接E组|D-01|交易与执行台账；交接事实与物流节点作为不同对象层，但共享order_id。|
|
||||
|
||||
## 三、Activity覆盖校验
|
||||
|
||||
下表说明每个Demo的关键读写台账、字段补足点和覆盖结论。[1] [2] [3] [4] [5] [6]
|
||||
|
||||
|Activity|原矩阵台账编号|统一台账编号|主写入台账|关键新增/细化字段|覆盖结论|
|
||||
|---|---|---|---|---|---|
|
||||
|ACT-WORK-05 差异评估|P-01-01、P-06-01、P-08-01、P-09-02、P-10-01/02/03、P-11-01、P-11-02、GOV|P-01、P-06、P-08、P-09、P-10、P-11、GOV|P-01、P-11；条件写P-06|requirement_version、input_snapshot_ref、bom_position、normalized_parameter_set、difference_item_id、difference_status、impact_statement、constraint_type、rule_version、confidence_score|已覆盖；差异明细由P-11差异明细子表承载，客户批准状态与差异分析状态分离。|
|
||||
|ACT-WORK-24 报价方案制定|P-01-01、P-02-01、P-03-01、P-04-01/02、P-06-01、P-08-01、P-11-02、GOV|P-01、P-02、P-03、P-04、P-06、P-08、P-11、GOV|P-02；回写P-01|quote_version、quote_type、quote_valid_until、delivery_commitment、payment_terms、tax_terms、incoterms、exchange_rate、gross_margin_status、rule_version、QuoteLine、blocking_reason、substitution_approval_status|已覆盖；P-02采用主记录+QuoteLine明细结构，正式发布与AI草稿以状态和版本区分。|
|
||||
|SS03 Activity 1 发起询价|P-01、D-15、P-08、S-03、S-05、S-04|P-01、D-15、P-08、S-03、S-05、S-04|S-04 RFQ层；条件写S-03|source_type/source_id、rfq_batch_id、rfq_line_id、quote_due_at、outbound_content_ref、sent_evidence_ref、reminder_count、last_reminded_at、overdue_flag、temporary_supplier_flag|已覆盖；最小粒度固定为询价批次×供应商×内部料号。|
|
||||
|SS03 Activity 2 回填报价/比价/定点|P-01、D-15、P-08、S-03、S-05、S-04|P-01、D-15、P-08、S-03、S-05、S-04|S-04 Quote/Decision层|supplier_quote_id、quote_revision_no、comparability_status、comparison_basis_snapshot_ref、baseline_match_status、baseline_unit_price、comparison_currency_code、conversion_rate、price_variance_pct、selected_supplier_id、selected_quote_id、unselected_reason、notification_recipient_ref、score_rule_version|已覆盖；跨币种、无基准、不可比、涨幅>10%、代理证及临时供应商门禁均有字段承载。|
|
||||
|ACT-11-A2 提货交接与风险转移|D-01、D-03、D-10、D-11、L-02、P-08、D-04|D-01、D-03、D-10、D-11、L-02、P-08、D-04|D-01、D-03；触发D-04相关门禁|allocation_ref、handover_no、receiver_name、sign_time、risk_transfer_time、handover_diff、handover_file_ref、handover_doc_status、handover_notes、document_set_complete、consistency_check_status、allocation_status、last_ship_date|已覆盖；交接事实、风险转移派生、文件状态、单证门禁和库存同步均已落台账。|
|
||||
|ACT-11-A3 物流执行信息跟踪|D-01、D-10|D-01、D-10|D-01物流节点事实层|logi_pickup/logi_clearance/logi_release/logi_departure（统一节点结构）、track_note、track_visible、logistics_confirmation_channel、logistics_confirmation_interval_days、logistics_max_reminder_count、alert_thresholds|已覆盖；每个节点包含预计时间、实际时间、来源、采集方式、确认状态、异常标记和证据引用。|
|
||||
|
||||
## 四、字段统一总表
|
||||
|
||||
### 4.1 通用治理字段
|
||||
|
||||
以下字段建议作为所有涉及Demo台账的通用治理字段继承，但不要求在每张业务台账中重复手工维护。`record_status`只管理记录生命周期；`*_status`管理具体业务过程；`evidence_ref`用于AI和人工结果的可审计回链。
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|维护/来源|Demo使用|定义/取值/校验规则|
|
||||
|---|---|---|---|---|---|---|
|
||||
|record_id|记录ID|Text/AutoNumber|是|系统|所有Demo|每条台账记录的唯一主键；业务编号不能替代数据库主键。|
|
||||
|record_status|记录状态|Enum|是|台账Owner|所有Demo|有效/草稿/归档/作废；不得用业务过程状态替代记录生命周期状态。|
|
||||
|record_version|记录版本|Text/Integer|是|系统/Owner|W05/W24/SS03/11-A2/11-A3|每次影响业务判断的修改递增；报价、价格、规则、客户映射必须可回溯。|
|
||||
|source_type|来源类型|Enum|条件必填|系统/上游Owner|W05/W24/SS03/11-A2|来源对象的类型，如客户需求、采购计划、价格维护、异常补货、订单、外部回复。|
|
||||
|source_id|来源对象ID|Text/Link|条件必填|系统/上游Owner|W05/W24/SS03/11-A2|与source_type成对出现；不得把说明文字写入ID字段。|
|
||||
|data_owner|数据Owner|Link|是|台账Owner|所有Demo|负责定义、质量和变更审批的角色或人员。|
|
||||
|evidence_ref|证据引用|URL/Attachment/Structure|条件必填|AI/PW/Owner|W05/W24/SS03/11-A2/11-A3|指向原始邮件、聊天记录、签署件、数据表、资料页码或其他证据；可多值。|
|
||||
|created_at|创建时间|DateTime|系统|系统|所有Demo|系统生成。|
|
||||
|updated_at|更新时间|DateTime|系统|系统|所有Demo|系统生成。|
|
||||
|last_verified_at|最后核验时间|DateTime|条件必填|Owner/PW/FAE/采购|所有Demo|对影响下游决策的事实标记最近一次人工或规则核验时间。|
|
||||
|
||||
### 4.2 按全景台账编号展开的字段
|
||||
|
||||
#### P-01 客户具体需求与项目任务主台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|request_id|需求编号|Text/AutoNumber|是|主记录|SS02|W05/W24/SS03-1/SS03-2/D-01|客户需求与项目任务主记录的统一业务键；SS03写入S-04.source_id。|重命名/统一|任务ID、request_id、需求编号|
|
||||
|customer_id|客户ID|Link|是|主记录|L-02/SS02|W05/W24/SS03-1/SS03-2|统一关联L-02；需求没有客户时需明确内部需求标识。|保留/细化|customer_id、客户|
|
||||
|project_id|项目ID|Link|条件必填|主记录|P-05/SS02|W05/W24/SS03-1/SS03-2|有项目场景必填；与客户ID共同确定需求归属和结果通知对象。|新增/细化|project_id、客户/项目|
|
||||
|requirement_version|需求版本|Text|是|主记录|SS02/系统|W05/W24|需求基线版本；差异评估与报价均按版本回溯。|新增/统一|任务描述/需求版本、版本|
|
||||
|request_type|需求类型|Enum|是|主记录|SS02/系统|W05/W24/SS03|客户需求/RFQ/询价/技术需求/价格维护/其他；采购来源可由source_type补充。|新增/统一|需求类型、RFQ类型|
|
||||
|request_description|需求描述|LongText|是|主记录|SS02/需求Owner|W05/W24|保留原始需求语义，不能只保留结构化字段。|新增/细化|任务描述|
|
||||
|input_snapshot_ref|输入快照|URL/Attachment/Structure|W05必填；W24条件|主记录|系统/AI|W05/W24|记录本次评估或报价运行时的输入快照，支持版本回溯。|新增|输入快照|
|
||||
|bom_id|BOM ID|Link|条件必填|主记录|SS02|W05/W24|有BOM场景必填；与bom_position一并确定物料位置。|新增|BOM范围|
|
||||
|bom_position|BOM位|Text|条件必填|主记录|SS02/FAE|W05/W24|按BOM位记录原物料、替代物料和报价明细；不同BOM位批准边界不得混用。|新增|BOM位、PN/BOM范围|
|
||||
|original_internal_pn|原内部料号|Link(P-08)|W05必填；其他条件|主记录|P-08/FAE|W05/W24|差异评估基准；引用P-08.internal_pn。|重命名/统一|原型号/原PN、原PN|
|
||||
|candidate_internal_pn|候选内部料号|Link(P-08)|W05条件；W24条件|主记录|P-08/FAE|W05/W24|候选替代物料；多个候选应进入P-11子记录而非逗号拼接。|重命名/统一|候选PN、Candidate_PN|
|
||||
|customer_pn|客户料号|Text|条件必填|主记录|L-02/D-10映射|W24/SS03/D-01|若客户使用客户料号，保留并与internal_pn分开。|新增/统一|customer_mpn、客户料号|
|
||||
|application_scenario|应用场景|LongText/Enum|W05必填；W24条件|主记录|FAE/客户|W05/W24|解释需求约束、验证条件与报价适用场景。|保留/细化|应用场景、适配场景|
|
||||
|target_qty|目标数量|Number/Structure|W24/SS03必填|主记录|需求Owner/采购|W24/SS03-1/SS03-2|正式报价、询价与比价的数量基准；阶梯放入数量阶梯子表。|重命名/统一|数量、target_qty、报价类型/数量|
|
||||
|target_delivery_date|目标交期|Date|W24/SS03必填|主记录|需求Owner/采购|W24/SS03-1/SS03-2|正式报价、询价与比价的日期基准。|重命名/统一|target_delivery_date、目标交期|
|
||||
|target_price_internal|内部目标价|Currency|否|主记录|SS02|W24/SS03|仅内部判断；默认不对外发送；币种必须同时记录。|保留/细化|target_price_internal、目标价|
|
||||
|target_price_currency_code|内部目标价币种|ISO 4217 Enum|target_price有值时必填|主记录|SS02|W24/SS03|与target_price_internal成对出现。|新增/统一|currency|
|
||||
|requested_price_types|所需价格类型|MultiEnum|SS03必填；W24条件|主记录|需求Owner/采购|W24/SS03-1/SS03-2|参考价/量产价/现货价/样品价；上游默认值可补充，删除或替换需留痕。|重命名/统一|price_types_default、price_types_requested、报价类型|
|
||||
|quote_due_at|期望报价返回时间|DateTime|SS03必填；W24条件|主记录|需求Owner/采购|W24/SS03-1/SS03-2|客户需求来源从P-01读取；内部或维护型询价由采购填写。|重命名/统一|quote_return_due_at、quote_due_at、截止时间|
|
||||
|technical_constraints|技术约束|Structure|W05/W24条件|主记录|FAE/AI|W05/W24|包含参数、单位、版本、硬约束/软约束，供差异评估和报价前提检查。|新增|参数边界、硬/软约束|
|
||||
|risk_level|风险等级|Enum|W05/W24条件|主记录|FAE/BDPM|W05/W24|低/中/高/关键；必须记录确认人和时间。|统一|FAE人工判断/风险等级、风险等级|
|
||||
|verification_requirement|验证/复测/确认要求|LongText/Structure|W05条件；W24条件|主记录|FAE|W05/W24|用于关闭UNKNOWN或CONDITIONAL，并可回链P-06验证记录。|重命名/统一|验证/复测/确认要求、验证要求|
|
||||
|latest_quote_id|最新报价ID|Link(P-02)|W24/SS03条件|主记录|系统|W24/SS03-2|聚合P-02最新有效报价，不直接复制价格。|新增|关联报价、最新报价状态|
|
||||
|latest_quote_status|最新报价状态|Lookup/Enum|W24/SS03条件|主记录|系统|W24/SS03-2|由P-02.quote_status/publish_status聚合。|重命名/统一|最新报价状态、报价状态|
|
||||
|request_status|需求状态|Enum|是|主记录|SS02|W05/W24/SS03|待处理/已响应/已成交/已放弃/关闭；不得与Activity运行状态混用。|重命名/统一|状态机、需求状态|
|
||||
|current_activity|当前Activity|Link/Enum|W05/W24条件|主记录|系统|W05/W24|如ACT-WORK-05、ACT-WORK-24；用于流程位置显示。|重命名/统一|当前Activity|
|
||||
|current_stage|当前阶段|Enum/Text|W05/W24条件|主记录|系统/Owner|W05/W24|评估、报价、审批、发布等阶段。|新增/统一|当前阶段|
|
||||
|next_action|下一步动作|LongText|W05/W24条件|主记录|FAE/BDPM/系统|W05/W24|明确责任人、动作和截止时间。|统一|下一步动作|
|
||||
|output_ref|标准输出链接|URL/Attachment|W05/W24条件|主记录|系统/FAE/BDPM|W05/W24|差异报告或报价文件的正式输出链接。|重命名/统一|标准输出类型/输出文件链接、输出链接|
|
||||
|
||||
#### P-02 报价与商务记录台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|quote_id|报价ID|Text/AutoNumber|是|报价主记录|系统|W24/SS03-2|报价主记录唯一标识。|保留/细化|报价ID|
|
||||
|request_id|关联需求编号|Link(P-01)|是|报价主记录|系统|W24/SS03-2|回链P-01.request_id。|重命名/统一|关联任务、关联需求号|
|
||||
|quote_version|报价版本|Text|是|报价主记录|系统/BDPM|W24|同一需求条件变化创建新版本；旧版本保留不可覆盖。|新增/统一|报价版本、版本|
|
||||
|quote_type|报价类型|Enum|是|报价主记录|BDPM|W24|正式报价/参考价/项目报价/其他；与price_type（明细价格类型）区分。|新增/统一|报价类型|
|
||||
|quote_status|报价状态|Enum|是|报价主记录|系统/BDPM|W24/SS03-2|草稿/待审核/已批准/已发布/已过期/已撤回。|重命名/统一|报价发布状态、报价状态|
|
||||
|quote_currency_code|报价币种|ISO 4217 Enum|是|报价主记录|系统/BDPM|W24|报价金额的统一币种；明细价格若币种不同必须换算并留痕。|重命名/统一|报价价格/币种、currency|
|
||||
|valid_from|报价生效时间|Date/DateTime|条件必填|报价主记录|BDPM|W24|正式发布报价必须有生效时间。|新增/统一|生效期|
|
||||
|quote_valid_until|报价有效期至|Date|条件必填|报价主记录|BDPM|W24|不得与P-03价格来源有效期混用。|重命名/统一|报价有效期、valid_until|
|
||||
|delivery_commitment|报价交期承诺|Date/Text/Structure|是|报价主记录|PW/BDPM|W24|记录交期数值、计算口径、来源和是否为承诺。|重命名/统一|报价交期、交期|
|
||||
|payment_terms|付款条件|Text/Structure|条件必填|报价主记录|BDPM/P-04|W24|来源于P-04或本次商务确认。|新增/统一|付款|
|
||||
|tax_terms|税费条件|Text/Structure|条件必填|报价主记录|BDPM|W24|税率、含税/未税口径必须明确。|新增|税费|
|
||||
|incoterms|贸易术语|Enum|条件必填|报价主记录|BDPM/P-04|W24|使用标准Incoterms枚举并记录版本/地点。|新增/统一|Incoterms、交货条款|
|
||||
|quote_assumptions|报价前提条件|LongText/Structure|是|报价主记录|BDPM|W24|含付款、税费、Incoterms、MOQ/SPQ、供货边界等。|重命名/细化|报价前提条件|
|
||||
|technical_boundary|技术边界|LongText/Structure|条件必填|报价主记录|FAE/BDPM|W24|记录替代、验证、规格限制与客户批准状态。|新增|技术边界|
|
||||
|cost_basis|成本基准|Currency/Structure|条件必填|报价主记录|BDPM/采购|W24|记录成本来源、币种、数量口径和时点。|新增|成本|
|
||||
|exchange_rate|报价汇率|Number|跨币种时必填|报价主记录|系统/BDPM|W24|统一比较币种时使用；必须关联exchange_rate_source与as_of。|新增|汇率|
|
||||
|exchange_rate_source|汇率来源|Text/URL|exchange_rate有值时必填|报价主记录|系统/BDPM|W24|记录汇率来源。|新增|汇率|
|
||||
|exchange_rate_as_of|汇率时点|Date|exchange_rate有值时必填|报价主记录|系统|W24|统一币种计算基准日。|新增|汇率|
|
||||
|gross_margin_status|毛利状态|Enum/Structure|条件必填|报价主记录|系统/BDPM|W24|未计算/通过/低于阈值/缺成本；口径由GOV规则维护。|新增|毛利状态|
|
||||
|rule_version|报价规则版本|Text/Link|是|报价主记录|GOV/系统|W24|记录计算、毛利、价格优先级使用的规则版本。|新增/统一|规则版本|
|
||||
|approval_status|商务审批状态|Enum|是|报价主记录|Gate/审批人|W24|未提交/待审批/已通过/已驳回；通过前不得发布。|重命名/统一|商务联审结论/审批记录|
|
||||
|approval_comment|商务审批意见|LongText|条件必填|报价主记录|审批人|W24|驳回或有条件通过时必须填写。|新增/统一|审批记录、审批意见|
|
||||
|publish_status|报价发布状态|Enum|是|报价主记录|系统/Gate|W24|草稿/待审批/已批准/已发布/过期/撤回。|重命名/统一|报价发布状态|
|
||||
|quote_document_ref|正式报价文件链接|URL/Attachment|已发布时必填|报价主记录|系统/BDPM|W24|只指向正式发布版本。|重命名/统一|报价文件、台账链接|
|
||||
|blocking_reason|阻断原因|LongText/Structure|条件必填|报价主记录|AI/BDPM|W24|价格过期、冲突、阶梯缺失、技术批准缺失等逐项记录。|新增|阻断原因|
|
||||
|quote_line_id|报价明细ID|Text/AutoNumber|是|报价明细QuoteLine|系统|W24|最小粒度为报价版本×PN×BOM位×数量阶梯。|新增|QuoteLine|
|
||||
|internal_pn|内部料号|Link(P-08)|是|报价明细QuoteLine|P-08/FAE|W24|报价物料统一引用P-08。|统一|PN|
|
||||
|bom_position|BOM位|Text|条件必填|报价明细QuoteLine|FAE|W24|同一报价中不同BOM位不能混淆。|统一|BOM位|
|
||||
|quantity_tier|数量阶梯|Structure|是|报价明细QuoteLine|AI/BDPM|W24|含min_qty、max_qty或阶梯描述。|拆分/结构化|数量阶梯|
|
||||
|price_type|价格类型|Enum|是|报价明细QuoteLine|BDPM|W24|参考价/量产价/现货价/样品价等。|新增/统一|price_type|
|
||||
|unit_price|报价单价|Currency|是|报价明细QuoteLine|系统/BDPM|W24|与currency_code成对存在。|重命名/统一|报价价格、单价|
|
||||
|currency_code|明细币种|ISO 4217 Enum|是|报价明细QuoteLine|系统/BDPM|W24|明细币种；若与主报价币种不同必须记录换算。|重命名/统一|币种|
|
||||
|lead_time_days|供货交期天数|Number|条件必填|报价明细QuoteLine|供应商/采购/BDPM|W24|统一为自然日或工作日一种口径，口径写入字段说明。|重命名/统一|LT、报价交期|
|
||||
|moq_qty|最小起订量|Number|条件必填|报价明细QuoteLine|P-08/S-05/采购|W24|数量比较与前提条件校验。|拆分/统一|MOQ|
|
||||
|spq_qty|标准包装量|Number|条件必填|报价明细QuoteLine|P-08/S-05/采购|W24|数量比较与包装约束校验。|拆分/统一|SPQ|
|
||||
|price_source_ref|价格来源引用|Link(P-03/S-05/S-04)|是|报价明细QuoteLine|系统|W24|指向Price List、采购基准或专项询价记录。|新增/统一|来源报价、价格来源|
|
||||
|substitution_approval_status|替代批准状态|Enum|条件必填|报价明细QuoteLine|P-11|W24|未检查/待验证/已批准/不批准；未满足时阻断发布。|新增|技术替代批准状态|
|
||||
|
||||
#### P-03 Price List台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|price_list_id|PriceList ID|Text/AutoNumber|是|价格记录|系统/BDPM|W24|价格来源唯一标识。|重命名/统一|PriceListID|
|
||||
|internal_pn|内部料号|Link(P-08)|是|价格记录|P-08/价格Owner|W24|统一引用P-08。|重命名/统一|PN/料号|
|
||||
|customer_id|适用客户ID|Link(L-02)|条件必填|价格记录|价格Owner|W24|客户专属价必填；公共渠道价可用scope_type标识。|新增|客户或渠道|
|
||||
|price_scope_type|价格适用范围|Enum|是|价格记录|BDPM|W24|客户专属/渠道/公共/项目。|新增|客户或渠道|
|
||||
|price_type|价格类型|Enum|是|价格记录|BDPM|W24|与报价所需价格类型对齐。|新增/统一|价格类型|
|
||||
|list_unit_price|Price List单价|Currency|是|价格记录|价格Owner|W24|与currency_code成对。|重命名/统一|客户专属价/单价|
|
||||
|currency_code|价格币种|ISO 4217 Enum|是|价格记录|价格Owner|W24|统一币种编码。|重命名/统一|币种|
|
||||
|release_version|Release版本|Text|是|价格记录|价格Owner|W24|报价时按as_of选取有效版本。|重命名/统一|Release版本、版本|
|
||||
|valid_from|生效时间|Date|是|价格记录|价格Owner|W24|与valid_to组成有效区间。|保留/细化|生效期|
|
||||
|valid_to|失效时间|Date|是|价格记录|价格Owner|W24|报价时点必须落在有效区间内。|重命名/统一|失效期、有效期|
|
||||
|quantity_tier|数量阶梯|Structure|条件必填|价格记录|价格Owner|W24|含适用数量和折扣条件。|拆分/结构化|数量阶梯/折扣条款|
|
||||
|discount_terms|折扣条款|LongText/Structure|条件必填|价格记录|价格Owner|W24|结构化记录折扣条件和例外。|细化|折扣条款|
|
||||
|source_quote_id|来源报价ID|Link(P-02/S-04)|条件必填|价格记录|系统/BDPM|W24|能追溯价格来源。|重命名/统一|来源报价|
|
||||
|price_status|价格状态|Enum|是|价格记录|价格Owner|W24|草稿/有效/暂停/过期/替代。|新增/统一|状态|
|
||||
|
||||
#### P-04 交易框架与承诺台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|framework_id|交易框架ID|Text/AutoNumber|是|框架主记录|商务Owner|W24|统一框架合同主键。|重命名/统一|框架ID|
|
||||
|customer_id|客户ID|Link(L-02)|是|框架主记录|商务Owner|W24|交易框架归属客户。|保留/统一|客户名称|
|
||||
|contract_version|合同版本|Text|是|框架主记录|商务Owner|W24|报价采用的合同/框架版本。|重命名/统一|合同版本|
|
||||
|contract_status|合同状态|Enum|是|框架主记录|商务Owner|W24|草稿/有效/到期/终止。|保留/细化|合同状态|
|
||||
|account_status|交易账户状态|Enum|是|框架主记录|商务Owner|W24|正常/冻结/待准入/关闭。|重命名/统一|交易账户状态|
|
||||
|payment_terms|账期与付款条款|Text/Structure|条件必填|框架主记录|商务Owner|W24|供报价继承；与D-04信用台账区分。|重命名/统一|账期条款、付款条件|
|
||||
|credit_limit|信用额度|Currency|条件必填|框架主记录|商务Owner|W24/11-A2条件|可供信用门禁使用。|保留/细化|信用额度|
|
||||
|cooperation_scope|合作范围|LongText/Structure|条件必填|框架主记录|商务Owner|W24|定义品牌、产品线、区域等边界。|保留/细化|合作范围|
|
||||
|incoterms|默认贸易术语|Enum|条件必填|框架主记录|商务Owner|W24|报价若覆盖本条件，回链本字段。|新增/统一|交易条款、Incoterms|
|
||||
|effective_from|框架生效时间|Date|是|框架主记录|商务Owner|W24|有效区间。|新增/统一|生效期|
|
||||
|effective_to|框架失效时间|Date|条件必填|框架主记录|商务Owner|W24|有效区间。|新增/统一|生效期|
|
||||
|commitment_id|承诺ID|Text/AutoNumber|条件必填|承诺子记录|系统/商务Owner|W24|每条价格、交期、数量或条件承诺一个ID。|重命名/统一|承诺ID|
|
||||
|commitment_party|承诺方|Enum/Link|是|承诺子记录|商务Owner|W24|我方/客户/供应商/其他。|统一|承诺方|
|
||||
|commitment_type|承诺类型|Enum|是|承诺子记录|商务Owner|W24|价格/交期/数量/质量/付款/其他。|新增/统一|承诺内容|
|
||||
|commitment_content|承诺内容|LongText/Structure|是|承诺子记录|商务Owner|W24|结构化值+说明，避免只写自由文本。|细化|承诺内容|
|
||||
|commitment_due_date|承诺期限|Date|条件必填|承诺子记录|商务Owner|W24|到期前可触发提醒。|重命名/统一|期限|
|
||||
|commitment_status|承诺状态|Enum|是|承诺子记录|商务Owner/系统|W24|未生效/生效/已兑现/逾期/取消。|重命名/统一|状态|
|
||||
|fulfillment_record_ref|兑现记录引用|Link/URL|条件必填|承诺子记录|系统/履约|W24|回链D-01/D-09等执行事实。|重命名/统一|兑现记录|
|
||||
|unresolved_risk_list|未决商务风险清单|LongText/Structure|条件必填|主记录|商务Owner|W24|报价前置风险；未关闭时可阻断审批。|重命名/细化|未决风险清单、商务风险|
|
||||
|
||||
#### P-06 样品交付与芯片验证记录台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|validation_id|验证ID|Text/AutoNumber|是|验证主记录|系统|W05/W24|验证记录唯一标识。|保留/统一|Validation_ID、验证编号|
|
||||
|request_id|关联需求编号|Link(P-01)|条件必填|验证主记录|系统/FAE|W05/W24|回链需求与验证目的。|新增/统一|需求号|
|
||||
|project_id|关联项目ID|Link(P-05)|条件必填|验证主记录|系统/FAE|W05/W24|项目场景验证必填。|新增/统一|项目|
|
||||
|customer_id|客户ID|Link(L-02)|条件必填|验证主记录|系统/FAE|W05/W24|客户验证必填。|新增/统一|客户ID|
|
||||
|validation_internal_pn|验证内部料号|Link(P-08)|是|验证主记录|FAE|W05/W24|统一引用P-08.internal_pn。|重命名/统一|Validation_PN、验证PN|
|
||||
|validation_type|验证类型|Enum|是|验证主记录|FAE|W05/W24|Pin-to-Pin/功能/可靠性/认证/复测。|新增/统一|验证类型|
|
||||
|test_condition|测试条件|LongText/Structure|是|验证主记录|FAE/验证Owner|W05|环境、输入、负载、样品状态等。|重命名/统一|测试条件|
|
||||
|test_parameters|测试参数|Structure|是|验证主记录|FAE/验证Owner|W05|参数名、值、单位、版本必须结构化。|重命名/统一|测试参数|
|
||||
|test_result|测试结果|LongText/Structure|是|验证主记录|验证Owner|W05|实测数据与结论，必要时附原始数据。|重命名/统一|测试结果|
|
||||
|validation_status|验证状态|Enum|是|验证主记录|FAE/验证Owner|W05/W24|未开始/进行中/通过/不通过/条件通过/待补证。|新增/统一|通过状态、验证状态|
|
||||
|issue_risk|问题与风险|LongText/Structure|条件必填|验证主记录|AI/FAE|W05/W24|记录未关闭问题、风险等级、责任人和关闭条件。|重命名/统一|问题与风险|
|
||||
|sample_version|样品版本|Text|条件必填|验证主记录|验证Owner|W05|样品追溯。|重命名/统一|样品版本|
|
||||
|sample_lot|样品批次|Text|条件必填|验证主记录|验证Owner|W05|与D-07或样品出库记录回链。|重命名/统一|样品批次、批次|
|
||||
|evidence_ref|验证证据引用|URL/Attachment/Structure|是|验证主记录|验证Owner/FAE|W05/W24|原始数据、照片、报告、资料页码等。|统一|证据引用|
|
||||
|next_validation_action|后续验证动作|LongText/Structure|条件必填|验证主记录|FAE|W05/W24|UNKNOWN/CONDITIONAL时必须有关闭动作。|新增|验证建议/缺口|
|
||||
|
||||
#### P-08 芯片主数据台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|internal_pn|内部料号|Text|是|物料主记录|SS02/FAE|W05/W24/SS03/11-A2|全链路料号统一基准；不可使用自由文本替代。|重命名/统一|标准型号PN、pn、mpn|
|
||||
|customer_pn|客户料号|Text|条件必填|物料主记录|SS02/D-10映射|W24/SS03/11-A2|客户料号映射优先维护在D-10，P-08可作为别名索引。|新增/统一|customer_mpn|
|
||||
|brand_name|品牌名称|Text/Link|是|物料主记录|FAE/数据Owner|W05/W24/SS03/11-A2|品牌统一引用；外部供应商品牌与原厂制造商分开。|重命名/统一|brand、manufacturer_brand、原厂或品牌|
|
||||
|manufacturer_name|制造商名称|Text/Link|条件必填|物料主记录|数据Owner|W05/W24|品牌与制造商不一致时分开记录。|新增/统一|原厂|
|
||||
|specification_description|规格描述|LongText|是|物料主记录|数据Owner/原厂资料|W05/W24|标准规格文本。|重命名/统一|Specification Description、产品描述|
|
||||
|normalized_parameter_set|标准化参数集|Structure|W05必填；W24条件|物料主记录|FAE/数据Owner|W05/W24|参数名、值、单位、精度、版本，用于硬/软约束比较。|新增|参数名称、单位、版本|
|
||||
|package|封装|Enum/Text|条件必填|物料主记录|数据Owner|W05/W24/SS03|影响硬约束和报价识别。|保留/细化|封装|
|
||||
|process_technology|工艺|Text/Enum|条件必填|物料主记录|数据Owner|W05|硬约束比较项。|重命名/统一|工艺|
|
||||
|lifecycle_status|生命周期状态|Enum|是|物料主记录|数据Owner|W05/W24/SS03|Active/NRND/EOL/停产/风险。|重命名/统一|生命周期状态、lifecycle_status、产品状态|
|
||||
|eol_pcn_status|EOL/PCN状态|Enum/Structure|条件必填|物料主记录|数据Owner/原厂|W05/W24|记录通知状态、影响和生效时间。|新增/统一|EoL/PCN状态|
|
||||
|datasheet_ref|Datasheet引用|URL/Link(P-10)|条件必填|物料主记录|P-10/原厂|W05/W24|官方资料链接。|重命名/统一|Datasheet链接|
|
||||
|datasheet_version|Datasheet版本|Text|datasheet_ref有值时必填|物料主记录|P-10/原厂|W05/W24|用于证据版本回链。|重命名/统一|Datasheet版本/版本|
|
||||
|application_scenarios|适配应用场景|MultiEnum/Structure|条件必填|物料主记录|FAE/数据Owner|W05/W24|判断物料实际适用性。|重命名/统一|应用场景、适配场景|
|
||||
|pin_to_pin_relation_ref|Pin-to-Pin关系引用|Link(P-11)|条件必填|物料主记录|FAE|W05/W24|引用P-11关系记录，避免在P-08复制批准结论。|新增/统一|Pin-to-Pin替代关系|
|
||||
|
||||
#### P-09 客户技术与机会档案
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|customer_id|客户ID|Link(L-02)|是|客户技术档案|SS02/FAE|W05/W24|区别于L-02的商务画像，技术档案以客户ID为主键。|保留/统一|客户 ID|
|
||||
|technical_stack|客户技术栈|Structure|条件必填|客户技术档案|FAE|W05/W24|记录平台、架构、关键技术约束。|重命名/统一|技术栈|
|
||||
|product_line_direction|产品线技术方向|Text/Structure|条件必填|客户技术档案|FAE/BDPM|W24|报价上下文与应用场景。|重命名/统一|产品线方向|
|
||||
|bom_brand_usage|BOM品牌使用情况|Structure|条件必填|客户技术档案|FAE|W05/W24|记录客户当前BOM品牌、料号及替代空间。|重命名/统一|BOM品牌|
|
||||
|validation_process|客户验证流程|LongText/Structure|条件必填|客户技术档案|FAE/客户|W05/W24|支持验证要求和报价前提判断。|重命名/统一|验证流程|
|
||||
|technical_decision_maker_ref|技术决策人引用|Link(L-08)|条件必填|客户技术档案|FAE|W05/W24|引用联系人，不复制姓名。|重命名/统一|技术决策人|
|
||||
|rd_capability_assessment|研发能力评估|Enum/LongText|条件必填|客户技术档案|FAE|W05/W24|用于技术支持与验证路径判断。|重命名/统一|研发能力|
|
||||
|technical_preference_tags|技术偏好标签|MultiEnum|条件必填|客户技术档案|FAE|W05/W24|用于推荐和方案匹配。|重命名/统一|技术偏好标签|
|
||||
|opportunity_id|机会ID|Text/AutoNumber|条件必填|机会子记录|系统/BDPM|W05/W24|需求或报价对应的机会对象。|新增/统一|机会记录|
|
||||
|
||||
#### P-10 原厂技术资料库
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|document_id|资料ID|Text/AutoNumber|是|资料主记录|系统|W05/W24|资料唯一标识。|新增/统一|资料记录|
|
||||
|document_type|资料类型|Enum|是|资料主记录|FAE|W05/W24|Datasheet/应用笔记/参考设计/白皮书/样片资料/其他。|新增/统一|资料类型|
|
||||
|internal_pn|关联内部料号|Link(P-08)|条件必填|资料主记录|P-08/FAE|W05/W24|料号相关资料必须回链P-08。|新增/统一|PN|
|
||||
|brand_name|品牌名称|Text/Link|是|资料主记录|数据Owner|W05/W24|统一引用P-08.brand_name。|重命名/统一|原厂|
|
||||
|document_title|资料标题|Text|是|资料主记录|资料Owner|W05/W24|资料可识别名称。|新增|资料|
|
||||
|document_version|资料版本|Text|是|资料主记录|资料Owner|W05/W24|评估必须回链版本。|重命名/统一|版本|
|
||||
|document_date|资料发布日期|Date|条件必填|资料主记录|资料Owner|W05/W24|用于时效判断。|新增|更新记录|
|
||||
|document_ref|资料文件链接|URL/Attachment|是|资料主记录|资料Owner|W05/W24|官方资料文件。|重命名/统一|Datasheet链接、资料|
|
||||
|citation_locator|证据定位|Text/Structure|W05必填；W24条件|资料主记录|AI/FAE|W05/W24|页码、章节、表格或段落，支持参数证据引用。|新增|证据引用、页码或证据段落|
|
||||
|source_contact_ref|原厂支持联系人|Link(L-08)/Text|条件必填|资料主记录|FAE|W05/W24|需要补证时的联系人。|重命名/统一|原厂支持联系人|
|
||||
|document_status|资料状态|Enum|是|资料主记录|资料Owner|W05/W24|有效/过期/待核实/作废。|新增/统一|状态|
|
||||
|
||||
#### P-11 替代选型与批准关系库
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|substitution_relation_id|替代关系ID|Text/AutoNumber|是|替代关系主记录|系统|W05/W24|原P-11-01与P-11-02统一后的关系主键。|新增/统一|P-11-01/P-11-02记录ID|
|
||||
|original_internal_pn|原内部料号|Link(P-08)|是|替代关系主记录|P-08/FAE|W05/W24|评估基准物料。|重命名/统一|Original_PN、原PN、目标替代料号|
|
||||
|candidate_internal_pn|候选内部料号|Link(P-08)|是|替代关系主记录|P-08/FAE|W05/W24|被评估物料。|重命名/统一|Candidate_PN、候选PN|
|
||||
|substitution_type|替代类型|Enum|是|替代关系主记录|FAE|W05/W24|Pin-to-Pin/功能替代/参数替代/其他。|重命名/统一|替代类型、关系类型|
|
||||
|recommendation_level|推荐等级|Enum|是|替代关系主记录|AI/FAE|W05/W24|推荐/条件推荐/备选/不推荐。|重命名/统一|替代等级、推荐|
|
||||
|recommendation_reason|推荐理由|LongText|是|替代关系主记录|AI/FAE|W05/W24|说明技术和商务依据。|新增/统一|推荐理由|
|
||||
|difference_summary|差异摘要|LongText|是|替代关系主记录|AI/FAE|W05|供P-01和后续流程消费。|新增/统一|评论、差异摘要|
|
||||
|difference_item_id|差异明细ID|Text/AutoNumber|是|差异明细子表|系统|W05|一条参数差异一条记录。|新增|逐参数差异明细|
|
||||
|parameter_name|标准参数名|Text/Link(GOV)|是|差异明细子表|AI/FAE|W05|参数名称标准化。|新增/统一|参数名称|
|
||||
|original_value|原物料参数值|Text/Number/Structure|是|差异明细子表|AI|W05|引用P-08或资料证据。|新增|参数A|
|
||||
|candidate_value|候选物料参数值|Text/Number/Structure|是|差异明细子表|AI|W05|引用P-08或资料证据。|新增|参数B|
|
||||
|parameter_unit|参数单位|Text/Link(GOV)|条件必填|差异明细子表|AI/FAE|W05|统一单位后比较。|新增/统一|单位|
|
||||
|constraint_type|约束类型|Enum|是|差异明细子表|GOV/AI|W05|硬约束/软约束。|新增/统一|硬/软约束标识|
|
||||
|difference_status|差异状态|Enum|是|差异明细子表|AI/FAE|W05|MATCH/MISMATCH/UNKNOWN/CONDITIONAL。|新增/统一|Status、差异状态|
|
||||
|impact_statement|影响说明|LongText|MISMATCH/CONDITIONAL必填|差异明细子表|AI/FAE|W05|说明对应用、验证、报价的影响。|新增|Impact、影响说明|
|
||||
|evidence_ref|差异证据引用|URL/Attachment/Structure|是|差异明细子表|AI/FAE|W05|具体资料、页码、测试记录。|统一|证据引用|
|
||||
|rule_version|差异规则版本|Text/Link(GOV)|是|差异明细子表|GOV/系统|W05|记录评估时采用的硬/软约束规则版本。|新增/统一|GOV规则版本|
|
||||
|risk_level|替代风险等级|Enum|是|替代关系主记录|FAE/RI|W05/W24|低/中/高/关键。|统一|风险等级|
|
||||
|verification_requirement|验证要求|LongText/Structure|CONDITIONAL/UNKNOWN必填|替代关系主记录|FAE|W05/W24|与P-06.validation_id或待验证任务回链。|统一|验证要求|
|
||||
|validation_id|关联验证ID|Link(P-06)|条件必填|替代关系主记录|系统/FAE|W05/W24|验证完成后回链事实。|新增/统一|验证编号、验证结果|
|
||||
|analysis_status|分析状态|Enum|是|替代关系主记录|系统/FAE|W05/W24|AI草稿/FAE确认/待客户验证/客户已批准/不批准/作废。|新增/统一|写入权限与时机、批准状态|
|
||||
|customer_approval_status|客户批准状态|Enum|是|替代关系主记录|审批流程|W05/W24|未提交/待批准/已批准/不批准/有条件批准；不由差异评估自动产生。|重命名/统一|批准状态、客户批准|
|
||||
|customer_approval_at|客户批准时间|DateTime|客户已批准时必填|替代关系主记录|审批流程|W05/W24|客户批准事实时间。|新增/统一|批准时间|
|
||||
|customer_approval_ref|客户批准凭证|URL/Attachment|客户已批准时必填|替代关系主记录|审批流程|W05/W24|签核邮件、系统审批单或客户文件。|新增/统一|批准凭证|
|
||||
|customer_feedback|客户反馈|LongText|条件必填|替代关系主记录|FAE/BDPM|W05/W24|记录客户对候选物料的反馈。|保留/细化|客户反馈|
|
||||
|request_id|关联需求编号|Link(P-01)|条件必填|替代关系主记录|系统|W05/W24|明确候选关系适用的需求。|新增/统一|关联需求|
|
||||
|project_id|关联项目ID|Link(P-05)|条件必填|替代关系主记录|系统|W05/W24|不同项目批准边界可不同。|新增/统一|关联项目|
|
||||
|bom_position|关联BOM位|Text|条件必填|替代关系主记录|FAE|W05/W24|批准边界定位。|新增/统一|BOM位|
|
||||
|analysis_report_ref|替代分析报告|URL/Attachment|条件必填|替代关系主记录|系统/FAE|W05|正式结构化结果或附件回链。|重命名/统一|替代分析报告、报告链接|
|
||||
|confidence_score|证据可信度|Percent/Enum|条件必填|替代关系主记录|AI/FAE|W05|AI输出可信度，需与人工确认区分。|新增/统一|证据可信度|
|
||||
|
||||
#### S-03 供应商主台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|supplier_id|供应商ID|Text/AutoNumber|是|供应商主记录|SS03|SS03-1/SS03-2|统一供应商主体键；临时供应商定点前必须转正式ID。|保留/统一|supplier_id、Supplier ID|
|
||||
|supplier_name|供应商名称|Text|是|供应商主记录|采购/SS03|SS03-1/SS03-2|临时供应商可先占位，定点前补齐正式名称。|保留/统一|supplier_name、供应商名称|
|
||||
|supplier_type|供应商分类|Enum|是|供应商主记录|SS03|SS03-1/SS03-2|原厂/授权代理/贸易/分销/其他。|保留/细化|supplier_type、供应商分类|
|
||||
|supplier_status|供应商状态|Enum|是|供应商主记录|SS03|SS03-1/SS03-2|临时/正式/停用；临时状态不可定点。|新增/统一|supplier_status|
|
||||
|temporary_supplier_flag|临时供应商标记|Boolean|是|供应商主记录|采购|SS03-1/SS03-2|临时新增立即可询价，但必须受定点门禁约束。|新增|临时供应商|
|
||||
|sales_contact_ref|业务联系人引用|Link/Text|SS03-1必填|供应商主记录|采购/供应商Owner|SS03-1|至少一名联系人，用于邮件或即时通讯外发。|重命名/统一|sales_contact、联系人|
|
||||
|contact_channel|首选联系渠道|Enum|条件必填|供应商主记录|供应商Owner|SS03-1|邮件/即时通讯/电话；需与外发记录一致。|新增/统一|send_channel、确认通道|
|
||||
|rfq_product_scope|当前询价品牌/料号范围|Structure|临时供应商定点前必填|供应商主记录|采购|SS03-1/SS03-2|允许不预建完整品牌覆盖，但必须覆盖当前询价。|新增/统一|rfq_product_scope|
|
||||
|authorized_brand_scope|授权品牌范围|Structure|代理/原厂条件必填|供应商主记录|SS03|SS03-1/SS03-2|判断品牌授权和可供范围。|新增/统一|品牌授权|
|
||||
|agency_certificate_ref|代理证凭证|URL/Attachment|supplier_type=授权代理时必填|供应商主记录|供应商Owner/采购|SS03-2|无有效代理证不得提交定点审批。|保留/细化|agency_certificate_ref、代理证|
|
||||
|agency_certificate_valid_to|代理证有效期至|Date|代理证有值时必填|供应商主记录|供应商Owner|SS03-2|定点前检查有效期。|新增|代理证|
|
||||
|qualification_status|准入资质状态|Enum|定点前必填|供应商主记录|SS03|SS03-2|待准入/合格/限制/不合格。|新增/统一|资质/准入|
|
||||
|compliance_status|合规状态|Enum|定点前必填|供应商主记录|SS03|SS03-2|通过/待核查/不通过。|新增/统一|合规|
|
||||
|commercial_terms_ref|长期商务规则引用|Link/Structure|条件必填|供应商主记录|SS03|SS03-2|长期条款不在本次询价Activity维护，但应有引用。|新增/统一|商务规则、长期条款|
|
||||
|supplier_health_score|供应商健康度|Percent/Enum|条件必填|供应商主记录|SS03/SS04|SS03-2|由履约数据计算，不作为单次询价事实覆盖。|新增/统一|供应商绩效/健康度|
|
||||
|
||||
#### S-04 询价、报价、比价与采购决策记录台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|rfq_batch_id|询价批次号|Text/AutoNumber|是|RFQ层|系统/采购|SS03-1/SS03-2|同一批次可含多料号、多供应商；品牌或料号变化必须新开批次。|保留/统一|rfq_batch_id、询价批次号|
|
||||
|rfq_line_id|询价行ID|Text/AutoNumber|是|RFQ层|系统|SS03-1/SS03-2|最小粒度为询价批次×供应商×内部料号。|保留/统一|rfq_line_id、询价行ID|
|
||||
|source_type|需求来源类型|Enum|是|RFQ层|采购/上游台账|SS03-1/SS03-2|P-01客户需求/D-15采购计划/价格维护/异常补货。|统一|source_type|
|
||||
|source_id|来源对象ID|Text/Link|条件必填|RFQ层|系统/上游台账|SS03-1/SS03-2|与source_type成对；P-01写request_id，D-15写purchase_plan_id。|统一|source_id|
|
||||
|customer_id|客户ID|Link(L-02)|条件必填|RFQ层|P-01/D-15|SS03-1/SS03-2|用于需求归属与通知。|新增/统一|customer_id|
|
||||
|project_id|项目ID|Link(P-05)|条件必填|RFQ层|P-01/D-15|SS03-1/SS03-2|用于需求归属与通知。|新增/统一|project_id|
|
||||
|brand_name|询价品牌|Text/Link(P-08)|是|RFQ层|P-08/采购|SS03-1/SS03-2|与internal_pn精确匹配；品牌变化新开批次。|重命名/统一|brand、manufacturer_brand|
|
||||
|internal_pn|询价内部料号|Link(P-08)|是|RFQ层|P-08/采购|SS03-1/SS03-2|统一引用P-08.internal_pn。|重命名/统一|pn、料号|
|
||||
|target_qty|目标数量|Number|是|RFQ层|P-01/D-15/采购|SS03-1/SS03-2|比价基准；来自P-01.target_qty或D-15.trigger_qty。|统一|target_qty、purchase_trigger_qty|
|
||||
|target_delivery_date|目标交期|Date|是|RFQ层|P-01/D-15/采购|SS03-1/SS03-2|比价基准；来自P-01或D-15.requirement_date。|统一|target_delivery_date、requirement_date|
|
||||
|requested_price_types|所需价格类型|MultiEnum|是|RFQ层|P-01/采购|SS03-1|参考价/量产价/现货价/样品价。|重命名/统一|price_types_requested|
|
||||
|quote_due_at|报价回复截止时间|DateTime|是|RFQ层|P-01/采购|SS03-1|供应商回复时效基准。|重命名/统一|quote_due_at、期望报价返回时间|
|
||||
|target_price_internal|内部目标价|Currency|否|RFQ层|P-01|SS03-1/SS03-2|仅内部判断；如实际披露需留痕。|统一|target_price_internal|
|
||||
|supplier_id|供应商ID|Link(S-03)|是|RFQ层|S-03/采购|SS03-1/SS03-2|临时供应商定点前转正式ID。|统一|supplier_id|
|
||||
|send_channel|询价发送渠道|Enum|是|RFQ层|采购/系统|SS03-1|邮件/即时通讯/电话。|统一|send_channel|
|
||||
|sent_at|询价发送时间|DateTime|是|RFQ层|系统|SS03-1|系统生成；未发送不得标记已发送。|保留/细化|sent_at|
|
||||
|outbound_content_ref|外发内容引用|URL/Attachment|是|RFQ层|系统/采购|SS03-1|记录对外披露内容和附件。|新增/统一|对外披露内容、附件|
|
||||
|sent_evidence_ref|外发凭证|URL/Attachment|是|RFQ层|系统|SS03-1|原始邮件、聊天发送记录等。|新增/统一|发送凭证、evidence|
|
||||
|rfq_status|询价状态|Enum|是|RFQ层|系统/采购|SS03-1|草稿/已发送/部分回复/全部回复/已到期未回复/催询中/关闭。|保留/细化|rfq_status|
|
||||
|reminder_count|催询次数|Integer|是|RFQ层|系统|SS03-1|自动提醒与人工催询均计数。|新增|跟进回复时效|
|
||||
|last_reminded_at|最后催询时间|DateTime|条件必填|RFQ层|系统/采购|SS03-1|有催询时必填。|新增|催询|
|
||||
|overdue_flag|询价超期标记|Boolean|是|RFQ层|系统|SS03-1|quote_due_at已过且未完成回复或未发出时触发。|新增|已到期未回复、发起超期|
|
||||
|supplier_quote_id|供应商报价ID|Text/AutoNumber|是|Quote层|系统|SS03-2|同一询价行可有报价修订历史。|新增/统一|报价记录ID|
|
||||
|quote_status|供应商报价状态|Enum|是|Quote层|采购|SS03-2|已报价/拒绝报价/未回复/待确认。|保留/细化|quote_status|
|
||||
|price_type|报价价格类型|Enum|条件必填|Quote层|采购|SS03-2|必须与requested_price_types匹配。|保留/统一|price_type|
|
||||
|unit_price|报价单价|Currency|已报价时必填|Quote层|采购|SS03-2|与currency_code成对。|重命名/统一|unit_price、价格|
|
||||
|currency_code|报价币种|ISO 4217 Enum|已报价时必填|Quote层|采购|SS03-2|统一币种比较前保留原币种。|重命名/统一|currency|
|
||||
|actual_qty|报价适用数量|Number|已报价时条件必填|Quote层|采购|SS03-2|判断与target_qty可比性。|重命名/统一|actual_qty|
|
||||
|lead_time_days|报价交期天数|Number|已报价时条件必填|Quote层|采购|SS03-2|统一工作日/自然日口径；原始文字可放lead_time_note。|重命名/统一|lead_time、LT|
|
||||
|lead_time_note|交期说明|LongText|条件必填|Quote层|采购|SS03-2|无法标准化时保留供应商原文。|新增|lead_time|
|
||||
|moq_qty|MOQ|Number|条件必填|Quote层|采购|SS03-2|最小起订量。|拆分/统一|MOQ-SPQ、MOQ|
|
||||
|spq_qty|SPQ|Number|条件必填|Quote层|采购|SS03-2|标准包装量。|拆分/统一|MOQ-SPQ、SPQ|
|
||||
|quote_valid_until|报价有效期至|Date|条件必填|Quote层|采购|SS03-2|报价是否仍可用。|重命名/统一|valid_until、报价有效期|
|
||||
|special_terms|本次特殊商务条款|LongText/Structure|否|Quote层|采购|SS03-2|一次性条款；长期供应商条款回链S-03。|重命名/细化|special_terms、特殊条款|
|
||||
|response_at|实际回复时间|DateTime|已回复时必填|Quote层|系统/采购|SS03-2|回复时间事实。|保留/细化|response_at|
|
||||
|no_quote_reason|未报价原因|LongText|拒绝/未回复时必填|Quote层|采购|SS03-2|拒绝报价或未回复必须填写。|保留/细化|no_quote_reason|
|
||||
|quote_evidence_ref|原始报价凭证|URL/Attachment|报价/拒绝均必填|Quote层|系统/采购|SS03-2|邮件、聊天截图、供应商报价单。|重命名/统一|evidence、原始沟通凭证|
|
||||
|quote_revision_no|同轮报价修订号|Integer|是|Quote层|系统/采购|SS03-2|同轮修改保留修订历史，当前报价可聚合展示。|新增|报价与版本|
|
||||
|comparison_group_id|比价组ID|Text/AutoNumber|是|Decision层|系统|SS03-2|由rfq_batch_id+internal_pn+target_qty+target_delivery_date组成。|重命名/统一|comparison_group|
|
||||
|comparability_status|可比性状态|Enum|是|Decision层|AI/采购|SS03-2|可直接比较/条件可比/不可比；不可比必须说明原因。|新增|正式比价组、不可直接比较|
|
||||
|comparison_basis_snapshot_ref|比价基准快照|Structure/URL|是|Decision层|系统|SS03-2|固化目标数量、目标交期、价格类型、汇率和基准版本。|新增|比价组|
|
||||
|system_score|系统评分|Number|是|Decision层|系统|SS03-2|按询价类型权重计算，0-100。|重命名/统一|score|
|
||||
|system_recommendation|系统推荐|Enum|是|Decision层|系统|SS03-2|推荐/备选/不推荐。|重命名/统一|recommendation|
|
||||
|procurement_confirm|采购确认意见|Enum|意见确认时必填|Decision层|采购|SS03-2|认可/调整/否决。|保留/细化|procurement_confirm|
|
||||
|confirm_reason|确认或调整理由|LongText|与系统推荐不一致时必填|Decision层|采购|SS03-2|采购调整或否决系统建议时必填。|重命名/统一|confirm_reason|
|
||||
|baseline_id|采购基准ID|Link(S-05)|有基准时必填|Decision层|系统|SS03-2|与品牌、料号、价格类型、数量和有效期匹配。|新增/统一|baseline_id|
|
||||
|baseline_match_status|基准匹配状态|Enum|是|Decision层|系统|SS03-2|已匹配/无基准/条件匹配/不匹配。|新增|无基准可比、基准比较|
|
||||
|baseline_unit_price|比较基准单价|Currency|有基准时必填|Decision层|系统|SS03-2|复制当次采用的S-05基准快照，避免历史重算漂移。|新增/统一|benchmark_unit_price|
|
||||
|comparison_currency_code|比价统一币种|ISO 4217 Enum|跨币种时必填|Decision层|系统|SS03-2|统一币种并回链汇率。|新增|汇率/统一币种|
|
||||
|conversion_rate|币种换算汇率|Number|跨币种时必填|Decision层|系统|SS03-2|记录换算基准和来源。|新增|汇率|
|
||||
|price_variance_pct|相对基准涨幅|Percent|有基准时派生|Decision层|系统|SS03-2|(报价-基准)/基准；涨幅>10%标红。|重命名/统一|price_variance_pct、涨幅|
|
||||
|variance_reason|涨价原因|LongText|涨幅>10%时必填|Decision层|采购|SS03-2|说明供应商涨价、市场、交期或其他原因。|保留/细化|variance_reason、涨价原因|
|
||||
|selected_supplier_id|中选供应商ID|Link(S-03)|定点通过时必填|Decision层|系统/采购|SS03-2|审批通过的定点对象。|新增/统一|推荐供应商、中选供应商|
|
||||
|selected_quote_id|中选报价ID|Link(S-04 Quote)|定点通过时必填|Decision层|系统|SS03-2|关联被选中的供应商报价。|新增/统一|定点结论|
|
||||
|approval_status|定点审批状态|Enum|是|Decision层|审批流|SS03-2|待审批/已通过/已驳回。|重命名/统一|approval_status|
|
||||
|approval_comment|定点审批意见|LongText|驳回/条件通过时必填|Decision层|审批人|SS03-2|审批意见。|重命名/统一|approval_comment|
|
||||
|decision_status|定点结论状态|Enum|是|Decision层|系统/采购|SS03-2|待定点/已定点/无法定点/建议关闭/已变更。|重命名/统一|decision_status、定点结论|
|
||||
|unselected_reason|未选/无法定点原因|LongText|无法定点或未选时必填|Decision层|采购|SS03-2|完整说明比较、准入或供应条件原因。|新增/统一|未选原因、无法定点原因|
|
||||
|notification_status|结果通知状态|Enum|是|Decision层|系统|SS03-2|待通知/已通知/通知失败。|重命名/统一|notification_status|
|
||||
|notification_recipient_ref|结果通知对象|Link/Text|定点结论产生时必填|Decision层|系统|SS03-2|按source_type通知P-01负责人、D-15负责人或其他发起人。|新增/统一|通知需求发起人|
|
||||
|score_rule_version|评分规则版本|Text/Link(GOV)|是|Decision层|GOV/系统|SS03-2|记录不同询价类型的权重版本。|新增/统一|规则版本|
|
||||
|
||||
#### S-05 采购基准与供应能力台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|baseline_id|采购基准ID|Text/AutoNumber|是|基准主记录|系统|SS03-1/SS03-2|基准唯一标识。|保留/统一|baseline_id|
|
||||
|brand_name|基准品牌|Text/Link(P-08)|是|基准主记录|采购/SS03|SS03-1/SS03-2|与internal_pn精确匹配。|重命名/统一|brand|
|
||||
|internal_pn|基准内部料号|Link(P-08)|是|基准主记录|P-08/采购|SS03-1/SS03-2|统一引用P-08。|重命名/统一|pn|
|
||||
|supplier_id|基准供应商ID|Link(S-03)|是|基准主记录|S-03/采购|SS03-1/SS03-2|当前采购基准的供应商。|统一|supplier_id|
|
||||
|price_type|基准价格类型|Enum|是|基准主记录|采购|SS03-2|必须与本次报价价格类型一致后比较。|统一|price_type|
|
||||
|baseline_unit_price|采购基准单价|Currency|是|基准主记录|采购|SS03-2|历史/当前有效采购基准，不被单次询价直接覆盖。|重命名/统一|benchmark_unit_price|
|
||||
|currency_code|基准币种|ISO 4217 Enum|是|基准主记录|采购|SS03-2|与单价成对。|重命名/统一|currency|
|
||||
|quantity_tier|适用数量阶梯|Structure|是|基准主记录|采购|SS03-2|匹配目标数量。|拆分/结构化|applicable_qty、数量阶梯|
|
||||
|valid_from|基准生效时间|Date|是|基准主记录|采购|SS03-2|有效期判断。|重命名/统一|effective_from|
|
||||
|valid_to|基准失效时间|Date|是|基准主记录|采购|SS03-2|有效期判断。|重命名/统一|effective_to|
|
||||
|lead_time_days|基准交期天数|Number|条件必填|基准主记录|采购|SS03-1/SS03-2|供应能力比较。|重命名/统一|lead_time、LT|
|
||||
|moq_qty|基准MOQ|Number|条件必填|基准主记录|采购|SS03-2|供应能力比较。|拆分/统一|MOQ|
|
||||
|spq_qty|基准SPQ|Number|条件必填|基准主记录|采购|SS03-2|供应能力比较。|拆分/统一|SPQ|
|
||||
|availability_status|可供状态|Enum|是|基准主记录|采购|SS03-1/SS03-2|可供/部分可供/不可供/待确认。|重命名/统一|availability_status、可供状态|
|
||||
|supply_risk_level|供应风险等级|Enum|条件必填|基准主记录|采购|SS03-2|低/中/高/关键。|新增/统一|供应风险|
|
||||
|baseline_status|基准状态|Enum|是|基准主记录|采购|SS03-2|Active/暂停/过期/替代。|保留/细化|baseline_status|
|
||||
|source_quote_ref|基准来源报价引用|Link(S-04/P-02)|条件必填|基准主记录|系统/采购|SS03-2|记录基准形成依据。|重命名/统一|来源报价|
|
||||
|locked_at|基准锁定时间|DateTime|条件必填|基准主记录|采购|SS03-2|锁定后单次询价不得直接覆盖。|新增|报价锁定基准|
|
||||
|
||||
#### D-15 采购计划与执行需求台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|purchase_plan_id|采购计划ID|Text/AutoNumber|是|采购计划主记录|SS04|SS03-1/SS03-2|内部采购需求唯一引用；写入S-04.source_id。|保留/统一|purchase_plan_id|
|
||||
|customer_id|客户ID|Link(L-02)|条件必填|采购计划主记录|SS04|SS03-1/SS03-2|客户需求型采购必填。|统一|customer_id|
|
||||
|project_id|项目ID|Link(P-05)|条件必填|采购计划主记录|SS04|SS03-1/SS03-2|项目型采购必填。|统一|project_id|
|
||||
|internal_pn|内部料号|Link(P-08)|是|采购计划主记录|P-08/SS04|SS03-1/SS03-2|统一引用P-08。|重命名/统一|pn|
|
||||
|forecast_version|Forecast版本|Text/Link(D-02)|条件必填|采购计划主记录|D-02/SS04|SS03-1/SS03-2|Forecast来源时必填。|统一|Forecast版本、版本号|
|
||||
|customer_pickup_demand|客户提货需求|Number/Date/Structure|条件必填|采购计划主记录|SS04|SS03-1/SS03-2|客户提货需求的数量和时间。|重命名/统一|提货需求|
|
||||
|requirement_date|内部需求日期|Date|是|采购计划主记录|SS04|SS03-1/SS03-2|作为询价目标交期或内部需求时点。|重命名/统一|requirement_date、需求日期|
|
||||
|inventory_ref|库存引用|Link(D-03)|条件必填|采购计划主记录|系统|SS03-1/SS03-2|用于采购建议量判断。|新增/统一|库存引用|
|
||||
|in_transit_ref|在途引用|Link(D-03/D-16)|条件必填|采购计划主记录|系统|SS03-1/SS03-2|用于采购建议量判断。|新增/统一|在途引用|
|
||||
|recommended_purchase_qty|建议采购量|Number|是|采购计划主记录|系统/采购|SS03-1/SS03-2|形成询价目标数量的依据。|新增/统一|建议采购量|
|
||||
|trigger_qty|采购触发数量|Number|是|采购计划主记录|SS04|SS03-1/SS03-2|进入询价的正式数量输入。|重命名/统一|purchase_trigger_qty、触发数量|
|
||||
|purchase_type|采购类型|Enum|是|采购计划主记录|SS04|SS03-1/SS03-2|量产/样品/现货/异常补货。|保留/细化|purchase_type|
|
||||
|urgency_flag|紧急程度|Enum/Boolean|是|采购计划主记录|SS04|SS03-1/SS03-2|普通/紧急/特急；影响评分权重。|保留/细化|urgency_flag|
|
||||
|plan_status|采购计划状态|Enum|是|采购计划主记录|SS04|SS03-1/SS03-2|有效/待执行/询价中/已满足/关闭。|保留/细化|plan_status|
|
||||
|triggered_at|触发询价时间|DateTime|条件必填|采购计划主记录|系统|SS03-1|记录进入询价流程的时间。|新增/统一|触发时间|
|
||||
|po_ref|关联采购订单引用|Link(D-16)|条件必填|采购计划主记录|系统|SS03-2|定点/执行后回链D-16。|重命名/统一|关联后续PO|
|
||||
|
||||
#### L-02 客户主台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|customer_id|客户ID|Text/AutoNumber|是|客户主记录|SS01|W24/SS03/11-A2|所有客户侧台账统一锚点。|保留/统一|唯一ID、customer_id|
|
||||
|customer_name|客户名称|Text|是|客户主记录|SS01|W05/W24/11-A2|展示名称；法律主体与展示名称如不同需分开。|新增/统一|客户名称、客户|
|
||||
|legal_entity_name|客户法律主体|Text|条件必填|客户主记录|SS01|11-A2条件|单证、合同或制裁筛查需要时必填。|新增|主体信息|
|
||||
|customer_status|客户状态|Enum|是|客户主记录|SS01|W24/11-A2|有效/暂停/终止。|新增/统一|状态机|
|
||||
|default_contact_ref|默认联系人引用|Link(L-08)|条件必填|客户主记录|SS01|11-A2|与D-10提货联系人区分；D-10可覆盖为履约联系人。|新增/统一|联系人|
|
||||
|
||||
#### D-01 交易与执行台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|order_id|订单号|Text/AutoNumber|是|订单主记录|SS04|11-A2/11-A3|订单执行主键。|保留/统一|order_id、订单号|
|
||||
|request_id|需求编号|Link(P-01)|条件必填|订单主记录|系统|11-A2|回链P-01需求。|统一|需求编号|
|
||||
|customer_id|客户ID|Link(L-02)|是|订单主记录|系统|11-A2/11-A3|客户名称通过L-02展示。|统一|customer_id|
|
||||
|project_id|项目ID|Link(P-05)|条件必填|订单主记录|系统|11-A2|项目追溯。|统一|项目|
|
||||
|internal_pn|内部料号|Link(P-08)|是|订单主记录|P-08/SS04|11-A2|内部料号统一引用P-08。|重命名/统一|mpn、料号|
|
||||
|customer_pn|客户料号|Text/Link(D-10)|条件必填|订单主记录|D-10/SS04|11-A2|通过D-10映射获得。|重命名/统一|customer_mpn|
|
||||
|order_qty|订单数量|Number|是|订单主记录|订单/系统|11-A2|交接实发数量核对基准。|保留/统一|order_qty|
|
||||
|allocation_ref|分配批次引用|Link(D-03)|条件必填|订单主记录|D-03/SS04|11-A2|指向D-03批次分配记录。|新增/统一|inventory_lot|
|
||||
|promised_delivery_date|承诺交期|Date|条件必填|订单主记录|P-04/SS04|11-A2|订单承诺交期。|重命名/统一|承诺交期|
|
||||
|trade_term|贸易术语|Enum|条件必填|订单主记录|D-10/P-04|11-A2|EXW等；风险转移逻辑依赖。|新增/统一|BT类型、贸易术语|
|
||||
|milestones|履约里程碑|Structure|是|订单主记录|系统/SS04|11-A2/11-A3|至少含交接；每个节点有状态、时间、来源、证据。|细化|milestones、里程碑|
|
||||
|pickup_status|提货状态|Enum|是|提货交接事实层|PW/系统|11-A2|待提货/已预约/已提货/待重新预约/取消。|保留/细化|pickup_status|
|
||||
|ship_date|发货日期|Date|现场交接时必填|提货交接事实层|PW|11-A2|现场事实；由PW唯一录入。|保留/细化|ship_date|
|
||||
|shipped_qty|实发数量|Number|现场交接时必填|提货交接事实层|PW|11-A2|现场事实；与order_qty及D-03同步校验。|保留/细化|shipped_qty|
|
||||
|handover_no|交接单号|Text|交接完成时必填|提货交接事实层|系统|11-A2|格式HD-YYYYMMDD-NNN。|保留/细化|handover_no|
|
||||
|receiver_name|签收人姓名|Text|交接完成时必填|提货交接事实层|PW|11-A2|双方签署事实。|重命名/统一|receiver、签收人姓名|
|
||||
|sign_time|交接签署时间|DateTime|交接完成时必填|提货交接事实层|PW|11-A2|EXW风险转移时点的事实基础。|保留/细化|sign_time、签署时间|
|
||||
|risk_transfer_time|风险转移时点|DateTime|签署后派生|提货交接事实层|系统/AI/PW确认|11-A2/11-A3|EXW场景默认等于sign_time；作为开票和后续追踪锚点。|保留/细化|risk_transfer_time|
|
||||
|handover_diff|交接差异|Enum/Structure|条件必填|提货交接事实层|PW/RI|11-A2|无差异/数量差异/型号差异/批次差异/包装差异/其他；关联差异单。|保留/细化|handover_diff|
|
||||
|handover_file_ref|交接单影像/文件|URL/Attachment|交接完成时必填|提货交接事实层|PW|11-A2|必须区分草稿、已签署、已归档。|重命名/统一|handover_file|
|
||||
|handover_doc_status|交接单文件状态|Enum|有handover_file_ref时必填|提货交接事实层|PW/系统|11-A2|草稿/已签署/已归档/作废；下游只消费已签署或已归档。|新增/统一|文档状态|
|
||||
|handover_notes|交接注意事项|LongText|条件必填|提货交接事实层|D-10/PW|11-A2|模板或现场特殊注意事项。|新增|交接注意事项|
|
||||
|logi_pickup|提货节点事实|Structure|11-A3必填|物流节点事实层|AI/PW|11-A3|含estimated_time、actual_time、source、collection_method、confirmation_status、anomaly_flag、evidence_ref。|保留/结构化|logi_pickup|
|
||||
|logi_clearance|报关节点事实|Structure|11-A3必填|物流节点事实层|AI/PW|11-A3|同上；异常如报关受阻、查验。|保留/结构化|logi_clearance|
|
||||
|logi_release|放行节点事实|Structure|11-A3必填|物流节点事实层|AI/PW|11-A3|同上。|保留/结构化|logi_release|
|
||||
|logi_departure|离港节点事实|Structure|11-A3必填|物流节点事实层|AI/PW|11-A3|同上；异常如离港延误。|保留/结构化|logi_departure|
|
||||
|track_note|物流跟踪/决策备注|LongText|条件必填|物流节点事实层|PW/RI|11-A3|货代不配合时记录降级为到货确认或销售协调等决策。|重命名/统一|track_note、决策记录|
|
||||
|track_visible|物流信息可查状态|Boolean|四节点完成后必填|物流节点事实层|系统|11-A3|四节点实际事实齐备后为True；不是人工主观勾选。|保留/细化|track_visible|
|
||||
|invoice_status|开票状态|Enum|是|订单状态层|系统/财务|11-A2|待开票/已触发/已开票/异常；risk_transfer_time为触发锚点。|新增/统一|开票状态|
|
||||
|acceptance_status|验收状态|Enum|是|订单状态层|履约Owner|11-A2|待验收/已确认/争议/不适用。|新增/统一|验收状态|
|
||||
|order_status|订单状态|Enum|是|订单状态层|系统/SS04|11-A2/11-A3|已放行/已交接/物流跟踪中/已完成/异常/关闭。|重命名/统一|订单状态机|
|
||||
|closed_flag|关闭标记|Boolean|是|订单状态层|系统/SS04|11-A2/11-A3|所有必需节点或异常处置完结后关闭。|新增/统一|关闭状态|
|
||||
|close_reason|关闭原因|LongText|关闭时必填|订单状态层|SS04|11-A2/11-A3|正常完成/取消/转异常流程等。|新增|关闭状态|
|
||||
|pickup_appointment_time|预约提货时间|DateTime|分支2场景必填|提货交接事实层|D-10/PW|11-A2|用于预约提醒、未按预约提货判断及重新预约。|新增/统一|提货预约时间|
|
||||
|physical_check_status|实物核对状态|Enum|交接前必填|提货交接事实层|PW|11-A2|未核对/已核对/不一致；核对数量、型号、批次标签和包装。|新增|实物一致性核对|
|
||||
|diff_handling_result|差异处理结果|Enum/Structure|有差异时必填|提货交接事实层|RI/PW|11-A2|补齐后交接/按实发量交接并标注/暂停并转后续Activity。|新增/统一|差异处理结果|
|
||||
|ri_gate_decision|RI门禁判断|Enum/LongText|差异或超时升级时必填|提货交接事实层|RI|11-A2/11-A3|放行/补齐后放行/暂停/转异常/降级追踪/联系客户核实。|新增/统一|RI门禁判断、决策记录|
|
||||
|ri_escalated_at|RI升级时间|DateTime|发生升级时必填|提货交接事实层|系统|11-A2/11-A3|差异、预约超时或节点反馈超时的升级事实。|新增|升级时限|
|
||||
|node_type|物流节点类型|Enum|是|物流节点子表（适用于logi_*）|系统|11-A3|提货/报关/放行/离港；对应logi_*字段。|新增/统一|四个关键节点|
|
||||
|estimated_time|节点预计时间|DateTime|是|物流节点子表（适用于logi_*）|系统/AI|11-A3|到达预计时间后触发确认请求。|新增/统一|节点预计时间|
|
||||
|actual_time|节点实际时间|DateTime|收到事实时必填|物流节点子表（适用于logi_*）|AI/PW|11-A3|收到反馈或人工电话确认的实际时间。|新增/统一|时间|
|
||||
|source|节点事实来源|Text/Link|是|物流节点子表（适用于logi_*）|AI/PW|11-A3|回复单位、系统或具体联系人；不得只写“外部”。|重命名/统一|来源、Source|
|
||||
|collection_method|节点采集方式|Enum|是|物流节点子表（适用于logi_*）|AI/PW|11-A3|邮件/微信/即时通讯/电话/人工录入。|重命名/统一|采集方式、Method|
|
||||
|confirmation_status|节点确认状态|Enum|是|物流节点子表（适用于logi_*）|系统/PW|11-A3|待确认/已确认/超时/异常/已升级。|新增/统一|确认状态|
|
||||
|anomaly_flag|节点异常标记|Boolean|是|物流节点子表（适用于logi_*）|AI/PW|11-A3|报关受阻、查验、离港延误等为True。|新增/统一|Anomaly Flag、异常节点标记|
|
||||
|anomaly_type|节点异常类型|Enum/Text|anomaly_flag=True时必填|物流节点子表（适用于logi_*）|AI/PW|11-A3|报关受阻/查验/离港延误/其他。|新增/统一|异常节点|
|
||||
|node_evidence_ref|节点事实证据|URL/Attachment|已确认或异常时必填|物流节点子表（适用于logi_*）|AI/PW|11-A3|回复原文、电话记录或其他节点证据。|新增/统一|证据引用|
|
||||
|reminder_count|节点提醒次数|Integer|是|物流节点子表（适用于logi_*）|系统|11-A3|按D-10最大提醒次数控制。|新增/统一|最大提醒次数|
|
||||
|last_request_at|最后请求时间|DateTime|有请求时必填|物流节点子表（适用于logi_*）|系统|11-A3|支持间隔天数和超时判断。|新增|确认请求|
|
||||
|node_ri_escalation_status|节点RI升级状态|Enum|超时/异常时必填|物流节点子表（适用于logi_*）|系统/RI|11-A3|未升级/已升级/已核实/已降级。|新增/统一|升级RI门禁|
|
||||
|
||||
#### D-04 回款与信用台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|credit_record_id|信用记录ID|Text/AutoNumber|是|信用门禁主记录|系统|11-A2|回款信用门禁记录主键。|新增/统一|信用记录|
|
||||
|customer_id|客户ID|Link(L-02)|是|信用门禁主记录|SS04|11-A2|关联客户信用主体。|统一|客户ID|
|
||||
|payment_terms|账期条款|Text/Structure|是|信用门禁主记录|P-04/SS04|11-A2|从交易框架读取，作为信用判断依据。|重命名/统一|账期条款|
|
||||
|credit_limit|信用额度|Currency|条件必填|信用门禁主记录|商务/财务|11-A2|与currency_code成对。|统一|信用额度|
|
||||
|outstanding_amount|应收金额|Currency|是|信用门禁主记录|财务|11-A2|当前应收，需记录币种。|新增/统一|应收|
|
||||
|paid_amount|已回款金额|Currency|是|信用门禁主记录|财务|11-A2|当前已回款，需记录币种。|新增/统一|已回款|
|
||||
|overdue_days|逾期天数|Integer|是|信用门禁主记录|系统/财务|11-A2|信用预警触发依据。|保留/细化|逾期天数|
|
||||
|credit_rating|信用评级|Enum|是|信用门禁主记录|财务/商务|11-A2|正常/关注/高风险/冻结。|保留/细化|信用评级|
|
||||
|warning_status|信用预警状态|Enum|是|信用门禁主记录|系统/财务|11-A2|无预警/预警/拦截/已解除。|保留/细化|预警状态|
|
||||
|
||||
#### D-03 库存与在途台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|inventory_record_id|库存记录ID|Text/AutoNumber|是|库存批次记录|系统|11-A2|库存事实主键。|新增/统一|库存记录|
|
||||
|internal_pn|内部料号|Link(P-08)|是|库存批次记录|P-08/SS04|11-A2|统一引用P-08。|重命名/统一|料号|
|
||||
|manufacturer_lot|原厂批次|Text|条件必填|库存批次记录|供应商/仓库|11-A2|交接单/COC披露。|重命名/统一|mfr_lot、lot|
|
||||
|date_code|日期码DC|Text|条件必填|库存批次记录|供应商/仓库|11-A2|交接单/COC披露。|重命名/统一|dc、Date Code|
|
||||
|available_qty|可用数量|Number|是|库存批次记录|仓库|11-A2|可出库库存。|新增/统一|可用|
|
||||
|inspection_qty|待检数量|Number|是|库存批次记录|仓库|11-A2|状态数量。|新增/统一|待检|
|
||||
|frozen_qty|冻结数量|Number|是|库存批次记录|仓库|11-A2|状态数量。|新增/统一|冻结|
|
||||
|in_transit_qty|在途数量|Number|是|库存批次记录|系统|11-A2|与D-16履约关联。|新增/统一|在途|
|
||||
|allocation_id|分配记录ID|Text/AutoNumber|是|库存批次记录|系统|11-A2|批次占用与订单绑定。|新增/统一|子表2|
|
||||
|allocated_qty|已分配数量|Number|是|库存批次记录|系统|11-A2|与allocation_status配套。|新增/统一|分配数量|
|
||||
|allocation_status|分配状态|Enum|是|库存批次记录|系统/PW确认|11-A2|已分配/部分出库/已出库/释放。|重命名/统一|alloc_status|
|
||||
|shipped_qty|已出库数量|Number|是|库存批次记录|系统/PW确认|11-A2|与D-01.shipped_qty同步。|保留/细化|shipped_qty|
|
||||
|last_ship_date|最后出库日期|Date|条件必填|库存批次记录|系统/PW确认|11-A2|该批次最后一次出库事实。|保留/细化|last_ship_date|
|
||||
|moq_qty|库存批次MOQ|Number|条件必填|库存批次记录|S-05/供应商|11-A2|备货决策参考。|新增/统一|MOQ|
|
||||
|lead_time_days|库存批次交期天数|Number|条件必填|库存批次记录|S-05/供应商|11-A2|备货与在途判断。|新增/统一|交期|
|
||||
|stocking_decision|备货决策|Enum/Structure|条件必填|库存批次记录|履约Owner|11-A2|维持/补货/冻结/退出。|新增/统一|备货决策|
|
||||
|exit_plan|退出方案|LongText/Structure|stocking_decision=退出时必填|库存批次记录|履约Owner|11-A2|异常PN或库存退出动作。|新增/统一|退出方案|
|
||||
|
||||
#### D-10 客户履约主数据台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|execution_profile_id|履约参数档案ID|Text/AutoNumber|是|执行参数主记录|SS04|11-A2/11-A3|客户履约参数的版本化主键。|新增/统一|执行参数|
|
||||
|customer_id|客户ID|Link(L-02)|是|执行参数主记录|SS04|11-A2/11-A3|履约参数按客户维护。|统一|客户|
|
||||
|incoterms|贸易术语|Enum|是|执行参数主记录|履约Owner|11-A2|EXW等；影响风险转移规则。|新增/统一|贸易术语|
|
||||
|packaging_requirements|包装要求|LongText/Structure|条件必填|执行参数主记录|履约Owner|11-A2|生成交接单和实物核对依据。|重命名/统一|包装|
|
||||
|label_requirements|标签要求|LongText/Structure|条件必填|执行参数主记录|履约Owner|11-A2|实物核对依据。|重命名/统一|标签|
|
||||
|document_requirements|单证要求|Structure|条件必填|执行参数主记录|履约Owner|11-A2|客户格式与单证清单要求。|重命名/统一|单证要求|
|
||||
|logistics_preference|物流偏好|Structure|条件必填|执行参数主记录|履约Owner|11-A3|节点采集偏好。|重命名/统一|物流偏好|
|
||||
|service_level|服务等级|Enum/Structure|条件必填|执行参数主记录|履约Owner|11-A3|节点可见性和响应要求。|新增/统一|服务等级|
|
||||
|alert_thresholds|预警阈值|Structure|条件必填|执行参数主记录|履约Owner|11-A3|节点超时、异常延误等阈值。|新增/统一|预警阈值|
|
||||
|pickup_contact_ref|提货联系人引用|Link(L-08)/Text|是|执行参数主记录|履约Owner|11-A2/11-A3|用于交接单和未按预约提货提醒。|重命名/统一|pickup_contact|
|
||||
|pickup_appointment_mode|预约提货方式|Enum|是|执行参数主记录|履约Owner|11-A2|预约/临时/固定窗口等。|重命名/统一|pickup_appt_mode|
|
||||
|logistics_confirmation_channel|物流节点确认渠道|Enum|是|执行参数主记录|履约Owner|11-A3|邮件/微信/即时通讯/电话。|重命名/统一|logi_channel、确认通道|
|
||||
|logistics_confirmation_interval_days|节点确认间隔天数|Integer|是|执行参数主记录|履约Owner|11-A3|默认3天；可按客户配置。|重命名/统一|logi_interval|
|
||||
|logistics_max_reminder_count|最大提醒次数|Integer|是|执行参数主记录|履约Owner|11-A3|默认3次；达到后升级RI。|重命名/统一|logi_max_retry|
|
||||
|handover_template_ref|交接单模板引用|URL/Attachment|是|执行参数主记录|履约Owner|11-A2|生成交接单草稿。|重命名/统一|handover_tpl|
|
||||
|handover_notes|交接注意事项|LongText|条件必填|执行参数主记录|履约Owner|11-A2|客户特殊注意事项；生成交接单。|新增/统一|交接注意事项|
|
||||
|mapping_id|料号映射ID|Text/AutoNumber|是|料号映射子表|系统|11-A2|客户料号与内部料号一对一版本记录。|新增|料号映射|
|
||||
|customer_pn|客户料号|Text|是|料号映射子表|履约Owner|11-A2|客户侧料号。|重命名/统一|客户料号、customer_mpn|
|
||||
|internal_pn|内部料号|Link(P-08)|是|料号映射子表|履约Owner|11-A2|内部统一料号。|重命名/统一|internal_pn|
|
||||
|mapping_version|映射版本|Text|是|料号映射子表|履约Owner|11-A2|料号映射版本受控。|新增/统一|版本|
|
||||
|mapping_status|映射状态|Enum|是|料号映射子表|履约Owner|11-A2|有效/待确认/过期/作废。|新增/统一|状态|
|
||||
|difference_flag|映射差异标记|Boolean/Structure|是|料号映射子表|系统/履约Owner|11-A2|客户料号与内部料号无法一一对应时标记并说明。|新增/统一|差异标注|
|
||||
|
||||
#### D-11 出口单证台账
|
||||
|
||||
|统一字段名|中文字段名|数据类型|必填性|对象层|维护/来源|Demo使用|定义/取值/校验规则|处理建议|原字段/来源名称|
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
|document_set_id|单证包ID|Text/AutoNumber|是|单证包主记录|系统|11-A2|订单级单证包唯一标识。|新增/统一|证据包|
|
||||
|order_id|订单号|Link(D-01)|是|单证包主记录|系统|11-A2|回链D-01订单。|新增/统一|订单号|
|
||||
|invoice_ref|发票文件引用|URL/Attachment|条件必填|单证包主记录|履约/财务|11-A2|随货单证之一。|重命名/统一|发票|
|
||||
|packing_list_ref|箱单文件引用|URL/Attachment|条件必填|单证包主记录|履约|11-A2|随货单证之一。|重命名/统一|箱单|
|
||||
|coc_ref|COC文件引用|URL/Attachment|条件必填|单证包主记录|履约/质量|11-A2|随货单证之一。|重命名/统一|COC|
|
||||
|certificate_of_origin_ref|产地证文件引用|URL/Attachment|条件必填|单证包主记录|履约|11-A2|按客户或贸易场景要求。|重命名/统一|产地证|
|
||||
|warranty_certificate_ref|质保书文件引用|URL/Attachment|条件必填|单证包主记录|履约|11-A2|随货单证之一。|重命名/统一|质保书|
|
||||
|required_document_types|应提供单证类型|MultiEnum|是|单证包主记录|D-10/履约|11-A2|根据D-10.document_requirements生成。|新增/统一|单证清单、客户格式要求|
|
||||
|document_set_complete|单证包齐套状态|Enum|是|单证包主记录|系统/PW|11-A2|未齐套/已齐套；已齐套至少满足本订单required_document_types。|保留/细化|doc_set_complete|
|
||||
|consistency_check_status|单证一致性审核状态|Enum|是|单证包主记录|系统/PW|11-A2|未审核/通过/不通过/待补正；核对订单、料号、数量、批次、客户信息。|新增/统一|一致性审核|
|
||||
|consistency_check_result|单证一致性审核结果|LongText/Structure|审核后必填|单证包主记录|系统/PW|11-A2|记录差异项、责任人和补正动作。|新增/统一|一致性审核记录|
|
||||
|document_archive_ref|单证包归档引用|URL/Attachment|归档时必填|单证包主记录|系统/履约|11-A2|正式证据包统一归档。|新增/统一|证据包|
|
||||
|archive_due_date|归档期限|Date|条件必填|单证包主记录|履约Owner|11-A2|依据客户或合规要求。|新增/统一|归档期限|
|
||||
|document_type|单证类型|Enum|是|单证明细子表|系统|11-A2|发票/箱单/COC/产地证/质保书/其他。|新增/统一|doc_list|
|
||||
|document_ref|单证文件引用|URL/Attachment|是|单证明细子表|履约|11-A2|单证文件。|重命名/统一|doc_list|
|
||||
|document_status|单证文件状态|Enum|是|单证明细子表|系统/履约|11-A2|草稿/已核验/已归档/作废。|新增/统一|文档状态|
|
||||
|document_version|单证版本|Text|是|单证明细子表|系统/履约|11-A2|单证修改必须递增。|新增/统一|版本|
|
||||
|
||||
|
||||
## 五、重叠字段与统一命名清单
|
||||
|
||||
下表列出不同Activity或台账中“含义相同但写法不同”“层级不同却使用同名”“同一字段承载多个语义”的主要问题，以及本次建议的统一口径。
|
||||
|
||||
|冲突主题|涉及台账/Activity|原有写法|统一字段名|统一口径|
|
||||
|---|---|---|---|---|
|
||||
|客户ID|P-01/P-02/P-04/P-06/P-09/S-04/D-01/D-10/L-02；W05/W24/SS03/11-A2|customer_id、客户ID、客户/项目、客户名称|customer_id；展示字段customer_name|ID只存L-02.customer_id；名称通过关联展示，不在业务台账重复维护。|
|
||||
|项目关联|P-01/P-02/P-04/P-06/P-09/S-04/D-15/D-01；W05/W24/SS03/11-A2|project_id、客户/项目、项目|project_id|项目对象只保留ID关联；项目名称由P-05展示。|
|
||||
|内部料号|P-01/P-02/P-03/P-06/P-08/P-11/S-04/S-05/D-15/D-01/D-03/D-10；W05/W24/SS03/11-A2|pn、mpn、标准型号PN、Validation_PN、Original_PN、Candidate_PN|internal_pn；原物料用original_internal_pn，候选物料用candidate_internal_pn|全链路只认P-08.internal_pn；不得将mpn、pn、型号混作同一字段。|
|
||||
|客户料号|P-01/P-08/D-01/D-10；W05/W24/11-A2|customer_mpn、客户料号|customer_pn|客户料号与internal_pn分开；正式映射落D-10料号映射子表。|
|
||||
|品牌/原厂|P-08/P-10/S-04/S-05/SS03|brand、manufacturer_brand、原厂或品牌|brand_name；制造商另用manufacturer_name|品牌、制造商、供应商不是同一对象；S-04/S-05引用brand_name与supplier_id。|
|
||||
|数量|P-01/S-04/D-15/D-01/D-03/W24/SS03/11-A2|数量、target_qty、purchase_trigger_qty、order_qty、shipped_qty、actual_qty|target_qty、trigger_qty、order_qty、actual_qty、shipped_qty、allocated_qty|按业务语义分开；数量阶梯统一用quantity_tier子表，不用文本拼接。|
|
||||
|交期/时间窗|P-01/S-04/D-15/P-02/S-05/W24/SS03|target_delivery_date、requirement_date、quote_return_due_at、quote_due_at、lead_time/LT|target_delivery_date、requirement_date、quote_due_at、lead_time_days|目标日期、需求日期、报价截止时间、供货时长四类概念分开；原始说明写lead_time_note。|
|
||||
|价格类型|P-01/P-02/P-03/S-04/S-05/W24/SS03|price_types_default、price_types_requested、price_type、报价类型|requested_price_types（需求层）；price_type（价格明细层）；quote_type（报价主记录层）|需求要什么价格、这一行是什么价格、这份报价属于什么业务类型分别建字段。|
|
||||
|价格/币种|P-01/P-02/P-03/S-04/S-05/W24/SS03|报价价格/币种、unit_price、benchmark_unit_price、currency|金额字段按对象命名，币种统一currency_code；跨币种另记comparison_currency_code/conversion_rate|金额与币种成对出现；currency不再作为模糊字段名。|
|
||||
|有效期|P-02/P-03/S-04/S-05/W24/SS03|生效期、失效期、报价有效期、valid_until、effective_from/to|valid_from、valid_to；报价主记录用quote_valid_until|Price List/采购基准的有效区间用valid_from/valid_to；报价对外有效期用quote_valid_until。|
|
||||
|状态|P-01/P-02/P-03/P-06/P-11/S-04/S-05/D-01/D-03/D-10/D-11/W05/W24/SS03/11-A2/11-A3|状态机、状态、approval_status、publish_status、doc_set_complete|对象业务状态与record_status分离；各对象保留*_status命名|record_status只管记录生命周期；quote_status、approval_status等只管业务流程。|
|
||||
|版本|P-01/P-02/P-03/P-06/P-08/P-10/P-11/D-10/S-04/W05/W24/SS03/11-A2|版本、需求版本、Release版本、报价版本、Datasheet版本、规则版本|对象字段用requirement_version/quote_version/release_version/document_version/mapping_version；通用用record_version；规则用rule_version|版本必须绑定对象和用途，不再使用裸字段version。|
|
||||
|证据/附件/链接|P-01/P-02/P-06/P-10/P-11/S-04/D-01/D-11/W05/W24/SS03/11-A2/11-A3|evidence、证据引用、输出文件链接、handover_file、doc_list|evidence_ref；对象文件用*_ref；输出用output_ref；交接单用handover_file_ref|证据引用可多值且必须可定位；业务对象文件链接按对象命名。|
|
||||
|供应商主体/联系人|S-03/S-04/S-05/SS03|supplier_id、供应商ID、sales_contact、联系人|supplier_id；sales_contact_ref；contact_channel|供应商主体与联系人分离；联系渠道记录在供应商主数据，实际发送渠道记录在S-04.send_channel。|
|
||||
|询价批次/比价组|S-04/SS03|rfq_batch_id、comparison_group|rfq_batch_id；comparison_group_id|批次是询价过程容器；比价组是同条件可比集合，两者不可互代。|
|
||||
|MOQ/SPQ|P-02/S-04/S-05/D-03/W24/SS03/11-A2|MOQ-SPQ、MOQ、SPQ|moq_qty、spq_qty|拆分为两个数值字段，适用对象前缀由台账区分。|
|
||||
|交期LT|S-04/S-05/P-02/SS03/W24|LT、lead_time、交期|lead_time_days；lead_time_note|标准化时长与原始说明分开；统一日历口径由GOV定义。|
|
||||
|替代关系与批准|P-01/P-02/P-06/P-08/P-11/W05/W24|替代等级、推荐、批准状态、验证结果、P-11-01/P-11-02|recommendation_level、analysis_status、customer_approval_status、validation_status|推荐、分析、验证、客户批准四个阶段分开，P-11作为统一关系主对象。|
|
||||
|风险等级|P-01/P-02/P-06/P-11/S-05/D-18/W05/W24/SS03|风险等级、供应风险、问题与风险|risk_level（通用决策风险）；supply_risk_level（供应能力风险）；issue_risk（问题明细）|不同风险对象不共用一个自由文本字段。|
|
||||
|交接/物流节点|D-01/D-03/D-10/D-11/11-A2/11-A3|milestones、ship_date、logi_pickup、track_note、交接|milestones；交接事实字段；logi_*节点结构；track_note|交接是法律/责任事实；物流节点是后续过程事实，统一回链同一order_id但不混成一个字段。|
|
||||
|
||||
## 六、必须落地的结构化规则
|
||||
|
||||
|标准项|标准定义|示例|
|
||||
|---|---|---|
|
||||
|ID命名|业务对象主键使用<对象>_id；跨台账引用保留同名ID并采用Link。|request_id、supplier_id、order_id|
|
||||
|料号命名|internal_pn表示内部标准料号；customer_pn表示客户料号；original_internal_pn/candidate_internal_pn只用于替代关系上下文。|P-08.internal_pn、D-10.customer_pn|
|
||||
|金额与币种|所有金额字段必须与currency_code成对；跨币种比较在决策记录中另记comparison_currency_code与conversion_rate。|unit_price + currency_code|
|
||||
|数量阶梯|数量阶梯使用结构化子表，至少包含min_qty、max_qty、price或discount；禁止把多个阶梯拼接为自由文本。|P-02 QuoteLine.quantity_tier|
|
||||
|时间字段|发生时点用*_at（DateTime），业务日期用*_date（Date），持续时长用*_days（Number）。|quote_due_at、target_delivery_date、lead_time_days|
|
||||
|版本字段|不使用裸version；必须指明对象：requirement_version、quote_version、release_version、document_version、record_version、rule_version。|P-02.quote_version|
|
||||
|状态字段|record_status管记录生命周期；对象业务流程用*_status；派生可见性用*_flag或*_visible。|record_status、approval_status、track_visible|
|
||||
|证据字段|evidence_ref表示证据集合；对象文件按对象命名为*_ref；证据必须支持URL/附件/定位信息。|quote_evidence_ref、handover_file_ref、citation_locator|
|
||||
|节点结构|物流节点统一包含estimated_time、actual_time、source、collection_method、confirmation_status、anomaly_flag、evidence_ref。|D-01.logi_pickup|
|
||||
|主记录与子表|主记录保存上下文、状态和汇总；逐PN/BOM位/阶梯/参数/单证的重复明细使用子表。|P-02 QuoteLine、P-11差异明细、D-11单证明细|
|
||||
|
||||
## 七、实施优先级与待确认事项
|
||||
|
||||
**P0：**先落实P-01、P-02、P-11、S-04、D-01的主记录与子表结构，并建立统一ID、料号、版本、状态和证据字段。P-02如果不建立QuoteLine，PN×BOM位×数量阶梯无法稳定支撑报价和版本管理；P-11如果不建立差异明细，差异评估只能保留摘要，无法被AI复核或下游消费；S-04如果不拆RFQ/Quote/Decision三层，询价事实、供应商回复和定点结论会互相覆盖。
|
||||
|
||||
**P1：**落实条件必填与校验规则，包括代理证、涨价原因、跨币种换算、报价/基准有效期、风险转移时点、交接文件状态、物流节点异常及提醒次数。
|
||||
|
||||
**P1：**明确以下业务口径后固化到GOV规则：lead_time_days按自然日还是工作日；毛利计算公式和阈值；价格来源优先级；汇率来源与as_of；Incoterms及地点字段；客户批准与FAE分析结论的权限边界；D-10履约参数的客户级/物流公司级配置粒度。
|
||||
|
||||
**P2：**将S-05基准、D-03库存与D-16采购履约的数据同步关系做成系统接口；将D-01物流节点结构接入客户可查询视图，并将异常节点回链D-18或既有异常归集Activity。
|
||||
|
||||
|
||||
## 八、交付物说明
|
||||
|
||||
本Markdown用于评审和阅读；配套Excel提供可直接继续维护的“字段总表”“Activity覆盖矩阵”“重叠字段统一”“字段标准”四张工作表，并保留“说明”页作为使用口径。
|
||||
|
||||
|
||||
## 参考附件
|
||||
|
||||
[1]: /home/ubuntu/upload/SS01-02-03-04-台账体系全景-18Activity关联矩阵(2).html "SS01-02-03-04-台账体系全景：18 Activity关联矩阵"
|
||||
|
||||
[2]: /home/ubuntu/upload/SS02_ACT-WORK-05_差异评估_E04-I01架构版_V1.2(1).html "SS02 ACT-WORK-05 差异评估"
|
||||
|
||||
[3]: /home/ubuntu/upload/SS02_ACT-WORK-24_报价方案制定_E04-I01架构版_V1.2(1).html "SS02 ACT-WORK-24 报价方案制定"
|
||||
|
||||
[4]: /home/ubuntu/upload/SS03询价ActivityDemo(1).html "SS03 询价 Activity Demo"
|
||||
|
||||
[5]: /home/ubuntu/upload/20260826-11-A2架构版（E04-I01v1.2）.html "SS04 ACT-11-A2 提货交接与风险转移"
|
||||
|
||||
[6]: /home/ubuntu/upload/20260826-SS04-SOP-11活动描述样板（11-A3）.html "SS04 11-A3 物流执行信息跟踪活动描述样板"
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,572 @@
|
||||
# ACT-WORK-05 差异评估 · 整体重写设计
|
||||
|
||||
状态:**已评审通过**(2026-08-29,用户逐节点头)
|
||||
落点:`activities/part-substitution-assessment@2.0.0` + 平台侧「确定性步骤」机制
|
||||
关联:ADR-014(确定性步骤,本设计是它的第一个落地者与两处改口)、ADR-004(不执行包代码)、
|
||||
`docs/活动开发规范.md`、`docs/HTML报告生成规范.md`、`docs/ss02-act-05-new/`(业务素材)
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么推倒重来
|
||||
|
||||
现版 `@1.7.3` 是**九步、两枚工具、全程 agent 驱动**:每一拍问模型「下一步干什么」,
|
||||
它自己 `write` 台账、自己 `finish`、自己发卡。`docs/ACT-WORK-05-端到端测试记录.md` 的
|
||||
A–AE 发现表里,八条事故落在「本来就该是确定的」那几步上 —— 编号抄别单、判在库判错、
|
||||
数据工单派给在库的料、没写骨架就发卡、库里有值当缺口、抄别的料的规格书。
|
||||
|
||||
用户 2026-08-29 定的新立场:
|
||||
|
||||
> 「不是把所有东西都丢给 ai 来处理,不要给 ai 暴露任何的工具,全部由系统确定性的来控制,
|
||||
> 一定是系统先确定性的从数据库中取出数据后交给 ai 分析。」
|
||||
|
||||
**agent 只在真需要判断的地方出现,与「人只在责任点与放行点出现」是同一条原则。**
|
||||
这个活动里,真需要判断的只有一件事:**这一条参数,候选跟原厂比算不算事**。别的全是确定的。
|
||||
|
||||
新版:**四步、零工具、零 `guide`、AI 出场恰好一次**。
|
||||
|
||||
---
|
||||
|
||||
## 2. 已定的八条(评审逐条通过)
|
||||
|
||||
| # | 决定 |
|
||||
|---|---|
|
||||
| 1 | **驱动**:落地 ADR-014 声明式配方 + 第四动词「一次结构化 AI 调用」。活动内部不再引第二套引擎(Mastra 仍在流程包编排与模型网关的原位) |
|
||||
| 2 | **台账**:两张新字典表 + P-08 主记录 + 参数子表 + P-11 主/明细 + P-06 + 一张活动自持案卷。**P-01 需求主记录 / P-10 原厂资料 / 客户档案本活动不碰** |
|
||||
| 3 | **P-06 芯片验证记录**:每条替代关系**固定落一条**,全推荐的写「本轮无待验项」 |
|
||||
| 4 | **结论谁定**:逐条四态由 AI 判;**推荐等级、风险、摘要、推荐理由由规则与模板算** |
|
||||
| 5 | **补数据的执行工单**:保存即铺格 —— 人选定/新建类型后按一次保存,系统按该类型的字段清单把参数值的行铺出来,人只填值,不加行不删行 |
|
||||
| 6 | **两颗料类型不一致**:硬拦,与「PN 不在库」同一条路(派工单让人改),保住「两边字段清单一定是同一套」这个前提 |
|
||||
| 7 | **结论审核卡**:只有「确认通过」一个钮,改全在件上;**人改完不重跑 AI**,只重算等级与摘要 |
|
||||
| 8 | **机制规模**:只实现本活动真用得到的那几式;没实现的形状装包时静态审当场拒 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 数据模型
|
||||
|
||||
### 3.1 两张新字典表(`parts` 域,与 P-08 同域)
|
||||
|
||||
**`parts.chip_type` · 芯片类型**
|
||||
|
||||
| 列 | 型 | 档 | 说明 |
|
||||
|---|---|---|---|
|
||||
| `type_id` | integer | 主键 · `auto` | 人不填,基座续号(现有最大 +1) |
|
||||
| `type_name` | text | 必填 | 「DC-DC 降压稳压器」;件上下拉显示它 |
|
||||
| `description` | text | 建议 | 这个类型是干什么的 |
|
||||
|
||||
**`parts.type_param` · 芯片类型核心参数字段**
|
||||
|
||||
| 列 | 型 | 档 | 说明 |
|
||||
|---|---|---|---|
|
||||
| `type_id` | integer | 主键 · `refersTo parts.chip_type.type_id` | 属于哪个类型 |
|
||||
| `param_name` | text | 主键 | 「输入电压范围」 |
|
||||
| `param_desc` | text | 必填 | 这个参数是什么意思 —— **AI 分析时读它** |
|
||||
| `constraint_type` | text | 必填 · tally `hard`/`soft` | 硬约束 / 软约束 |
|
||||
| `param_unit` | text | 建议 | 参考单位 |
|
||||
|
||||
关联:一行 P-08 关联一个类型;多行 `type_param` 关联一个类型。
|
||||
|
||||
### 3.2 P-08 及其子表的改动
|
||||
|
||||
**`parts.profile`**(声明后为八列,物理表其余列不声明 = 本活动不碰):
|
||||
|
||||
`internal_pn`(主键)· **`chip_type_id` integer 必填 refersTo `parts.chip_type.type_id`** ·
|
||||
`brand_name` 必填 · `lifecycle_status` 必填 tally · `specification_description` 建议 ·
|
||||
`manufacturer_name` 建议 · `datasheet_ref` 建议 · `datasheet_version` 建议
|
||||
|
||||
**`createOnly` 撤掉**(现版标着它,只许建新料、不许改已有行)。它当初是为了拦模型凭空建料;
|
||||
模型现在不在场,**行由配方按本单两颗料铺出来,凭空建在结构上不可能**。而撤掉它换来一件必需的事:
|
||||
**给在库的老料补上「芯片类型」这一格** —— 迁移前建的行没有类型,不许改就永远补不了,单子卡死。
|
||||
|
||||
**不声明**:`package` 封装 · `process_technology` 工艺 · `eol_pcn_status` · `application_scenarios`。
|
||||
**封装和工艺本来就是「核心参数」** —— 它们该以类型字段的身份出现在字典里,不在主记录上另开一列。
|
||||
|
||||
**`parts.parameter`**:`internal_pn`(主键,refersTo profile)· `param_name`(主键)·
|
||||
`param_value` 必填 · `param_unit` 建议 · `param_note` 建议(**值说明,AI 也读它**)
|
||||
|
||||
`parts.parameter` 的 **`createOnly` 同样撤掉**(理由同上:④那一笔要把在库那颗料的现值回填进草稿层,
|
||||
只许建新就写不进去)。
|
||||
|
||||
两处退休:
|
||||
- **`constraint_type` 退休** —— 搬去 `type_param`。同一个参数在两颗料上标法不一致这件事从结构上消失。
|
||||
- **`param_name` 的自指引用墙退休**(`refersTo: 'parts.parameter.param_name'`)。它当初是为了硬逼两颗料
|
||||
用同一套参数名,措辞拦了三次没拦住才砌的;现在字段清单由类型字典给、**行由系统按字典铺**,
|
||||
名字对不上根本不可能发生。`distinct` 一并退休。
|
||||
|
||||
### 3.3 活动自持两张(顶掉现在的 `pn_check` / `input_gap` / `verdict` 三张)
|
||||
|
||||
**`sub_eval.part` · 本单两颗料**,`kind: record`,`caseKey: eval_ref` —— 一单**恰两行**
|
||||
|
||||
`eval_ref`(主键)· `internal_pn`(主键)· `role` 必填 tally `original`/`candidate` ·
|
||||
`exists_status` 必填 tally `found`/`absent` · `chip_type_id` integer **必填** · **`distinct: true`**
|
||||
(「两颗料是不是同一个类型」于是成了基座数得出来的数:不同取值恰好 1 种)
|
||||
|
||||
**`sub_eval.case` · 本单案卷**,同上 —— 一单**一行**
|
||||
|
||||
`eval_ref`(主键)· `chip_type_id`(本单锁定的类型)· `gate_reason`(入参未就绪的原因,件上摆的就是它)·
|
||||
`summary`(结论一句话)
|
||||
|
||||
`exists_status` 与两处 `chip_type_id` **每一拍由 `lookup` 重算** —— 人把料建好之后自己变 `found`,
|
||||
不设 `created` 档、不靠谁记账。
|
||||
|
||||
**为什么非拆成两张不可**:`part` 是**配方唯一能拿来遍历「哪几颗料要建」的数据源** ——
|
||||
`each: 'mine:sub_eval.part' where exists_status = absent`。挤进一行案卷里就没法 `where` 过滤,
|
||||
而不能过滤就会给已经在库的那颗料也铺一遍空参数行,`_missing` 当场报缺、单子死在那儿。
|
||||
|
||||
### 3.4 结论三张
|
||||
|
||||
**`substitution.relation`**(P-11 主记录,一单一行)
|
||||
|
||||
`substitution_relation_id`(主键)· `eval_ref` 必填 · `original_internal_pn` / `candidate_internal_pn`
|
||||
必填 refersTo profile · `chip_type_id` 必填 · `recommendation_level` 必填 tally
|
||||
`recommended`/`conditional`/`not_recommended` · `recommendation_reason` 必填 ·
|
||||
`difference_summary` 必填 · `risk_level` 必填 tally `low`/`medium`/`high` ·
|
||||
`verification_requirement`(`requiredWhen recommendation_level = conditional`)· `validation_id` ·
|
||||
`analysis_status` 必填(固定 `fae_confirmed`)· `rule_version` 必填
|
||||
|
||||
退休:`substitution_type`(新流程里没有它的定夺人)· `confidence_score` · `analysis_report_ref` ·
|
||||
`recommendation_level` 的 `alternate` 档(原 D02 的 `configurable` 来路已不存在)。
|
||||
|
||||
**`substitution.difference_item`**(P-11 明细,一参数一行)
|
||||
|
||||
`substitution_relation_id`(主键 · `distinct` · refersTo relation)· `difference_item_id`(主键)·
|
||||
`parameter_name` 必填 · `parameter_desc` 建议(字段说明快照,归档件不必 join)· `constraint_type` 必填 tally ·
|
||||
`original_value` / `candidate_value` 必填 · `parameter_unit` 建议 ·
|
||||
**`difference_status` 必填 tally `match`/`mismatch`/`unknown`/`conditional`(AI 判)** ·
|
||||
**`judgement_class` 必填 tally `match`/`soft_mismatch`/`hard_mismatch`/`unknown`/`conditional`(系统合成)** ·
|
||||
`impact_statement` 必填(AI)· `evidence_note` 必填(AI)·
|
||||
`unknown_disposition`(`requiredWhen difference_status = unknown`,AI)· `risk_level` 必填 tally · `rule_version` 必填
|
||||
|
||||
**`judgement_class` 是这套设计的关键一列**:推荐等级要数的是「硬约束不符有几条」,
|
||||
而基座读数只会数单列 —— 把「约束类型 × 四态」先合成一列,规则才算得出来。
|
||||
`evidence_ref` 改名 `evidence_note`「判断依据」:不写 P-10 了,AI 能给的就是依据不是文件引用,名字得说实话。
|
||||
|
||||
**`validation.record`**(P-06,一单一行)
|
||||
|
||||
`validation_id`(主键)· **`eval_ref` 必填**(顶掉 `request_id` —— P-01 不在本活动里)·
|
||||
`validation_internal_pn` 必填 refersTo profile · `validation_type` 必填 tally(**追加一档 `parametric`**)·
|
||||
`validation_status` 必填(固定 `not_started`)· `test_condition` 建议 · `next_validation_action` 必填
|
||||
|
||||
### 3.5 规则(唯一真源在配方里,不再另留 DMN)
|
||||
|
||||
**`judgement_class`**:`match` → match;`unknown` → unknown;`conditional` → conditional;
|
||||
`mismatch` 且硬 → `hard_mismatch`;`mismatch` 且软 → `soft_mismatch`。
|
||||
|
||||
**明细 `risk_level`**:`hard_mismatch` → high;`unknown`/`conditional`/`soft_mismatch` → medium;`match` → low。
|
||||
|
||||
**`recommendation_level`**(读 `judgement_class` 的 tally 计数,自上而下第一条命中):
|
||||
|
||||
| 条件 | 等级 |
|
||||
|---|---|
|
||||
| `hard_mismatch > 0` | `not_recommended` |
|
||||
| `unknown > 0` | `conditional` |
|
||||
| `conditional > 0` | `conditional` |
|
||||
| `soft_mismatch > 0` | `conditional` |
|
||||
| 其余 | `recommended` |
|
||||
|
||||
**关系 `risk_level`**:`not_recommended` → high;`conditional` → medium;`recommended` → low。
|
||||
|
||||
**模板串**:
|
||||
- `difference_summary` = 「共 N 项核心参数:x 一致 / y 不一致(硬 z)/ u 待确认 / c 有条件」
|
||||
- `recommendation_reason` = 按等级三形:点名硬约束不符的参数 / 点名待确认与有条件的项 / 「N 项全部一致,无待确认项」
|
||||
- `verification_requirement` = 「实测并回填:<UNKNOWN 与 CONDITIONAL 的参数名,顿号连>」
|
||||
- P-06 `test_condition` = 同上参数名列表(没有就写「无」);`next_validation_action` =
|
||||
「实测上述参数并回填 P-08 标准化参数集」/「本轮无待验项」
|
||||
|
||||
---
|
||||
|
||||
## 4. 四步案例模型
|
||||
|
||||
进度条四格:**校验入参 → 差异分析 → 结论审核 → 落账放行**。
|
||||
全程 `guide: ''`、`tools: []`、`declarations.tools: []`。
|
||||
|
||||
### 4.1 启动参数(运营中心活动详情一键启动)
|
||||
|
||||
两格,**都选填**:
|
||||
|
||||
- `originalInternalPn`「原内部料号」—— `x-control: combo`,`x-options` 从 `parts.profile.internal_pn` 现读;可选库里的,也可自己写一个新的
|
||||
- `candidateInternalPn`「候选内部料号」—— 同款
|
||||
|
||||
### 4.2 S1 校验入参与补数据 —— 纯系统 +(条件)一张数据工单
|
||||
|
||||
```
|
||||
let evalRef = cat('W05-', fmt(case:openedAt, digits))
|
||||
|
||||
① project sub_eval.part from rows[{pn:入参原PN, role:'original'}, {pn:入参候选PN, role:'candidate'}]
|
||||
eval_ref = {in:'evalRef'};internal_pn = {col:'pn'};role = {col:'role'}
|
||||
exists_status = when lookup('parts.profile' by internal_pn={col:'pn'} take internal_pn) != ''
|
||||
then 'found' else 'absent'
|
||||
chip_type_id = lookup('parts.profile' by internal_pn={col:'pn'} take chip_type_id, else '')
|
||||
|
||||
② project sub_eval.case from once
|
||||
eval_ref = {in:'evalRef'}
|
||||
chip_type_id = lookup('mine:sub_eval.part' by role='original' take chip_type_id, else '')
|
||||
gate_reason = when 链(**全读基座数**):
|
||||
两颗 PN 有一格为空 → 「原 / 候选料号还没填」
|
||||
sub_eval_part_exists_status_absent > 0 → 「<PN> 库里没有,请在下面建」
|
||||
sub_eval_part_distinct_chip_type_id > 1 → 「两颗料类型不一致,换一颗或把类型改对」
|
||||
parts_profile_missing + parts_parameter_missing > 0 → 「还差 n 格没填」
|
||||
其余 → ''
|
||||
|
||||
③ project parts.profile prune from each('mine:sub_eval.part') ← **两颗料都铺**
|
||||
internal_pn = {col:'internal_pn'}
|
||||
chip_type_id / brand_name / lifecycle_status / specification_description /
|
||||
manufacturer_name / datasheet_ref / datasheet_version
|
||||
= lookup('parts.profile' by internal_pn={col:'internal_pn'} take 同名列, else '') ← 回填现值
|
||||
↑ 与④同构。在库那颗回填出它此刻的样子;要建那颗全空等人填。
|
||||
**「在库的老料还没归类型」于是也被拦住** —— 那一格回填出来是空的,而 chip_type_id 必填。
|
||||
人不必在件上「加一行」:要建哪颗料是启动参数就定死的事,行由系统摆好,他只填格子。
|
||||
|
||||
④ project parts.parameter prune
|
||||
from each('mine:sub_eval.part') ← **两颗料都铺,不只是缺库那颗**
|
||||
then each('parts.type_param' where type_id={outer:'chip_type_id'})
|
||||
internal_pn = {outer:'internal_pn'};param_name / param_unit ← {col:…}
|
||||
param_value = lookup('parts.parameter' by internal_pn={outer:'internal_pn'},
|
||||
param_name={col:'param_name'} take param_value, else '') ← **回填现值**
|
||||
param_note = 同上 take param_note
|
||||
↑ 三件事一笔办完:
|
||||
· 人还没挑类型 → {outer:'chip_type_id'} 是空串,where 一行不命中,什么也不铺;
|
||||
他挑了、按了保存,行就出来 —— **「保存即铺格」不是特判,是这一笔的自然结果**;
|
||||
· 在库那颗料**也**铺,值回填现值 → 屏上是它此刻的样子,`_missing` 不会误报;
|
||||
· **「在库但参数没录全」于是自动被拦住** —— 那一格回填出来是空的,红带点名、闸按不下。
|
||||
|
||||
⑤ card 执行工单 · variant data · view 'input-supplement' when gate_reason != ''
|
||||
gateLedgers = [parts.chip_type, parts.type_param, parts.profile, parts.parameter]
|
||||
|
||||
⑥ say
|
||||
|
||||
doneWhen sub_eval_part_exists_status_found = 2
|
||||
and sub_eval_part_missing = 0 ← 两行的 chip_type_id 都有值
|
||||
and sub_eval_part_distinct_chip_type_id = 1 ← 且是同一个类型
|
||||
and parts_profile_missing = 0
|
||||
and parts_parameter_missing = 0
|
||||
```
|
||||
|
||||
**`doneWhen` 里没有「行数 = 字段数×2」这条对账,是故意的**:参数行由 `prune` + `each 字典`
|
||||
铺出来,**人不加行不删行**,少一行在结构上不可能发生(真发生就是配方 bug,归静态审与包内自测)。
|
||||
而「本类型有几个字段」根本不是基座数得出来的数 —— `parts_type_param_rows` 数的是**本单写下的**
|
||||
那几行(人新建的字段),不是整本字典。**给判据编一个数不出来的数,是这个仓踩过六次的同一个坑。**
|
||||
|
||||
- **两颗都在库、类型一致、参数齐 → 一张卡都不发**,首拍 `doneWhen` 即真,直接进 S2。
|
||||
- 人在件上按「保存」→ 系统 tick → 配方**原样重跑**:类型这会儿知道了,④把参数行铺出来;
|
||||
⑤因为卡发过(`worldTouched`)不再发;件就地刷新。
|
||||
**幂等靠同 PK 覆盖 + 发过不再发 + `prune`**,不靠谁记得住。
|
||||
- 人点「提交」= 数据工单确认 → **`chip_type` / `type_param` / `profile` / `parameter` 当场进正式表**
|
||||
(平台 2026-08-27 的范围放行)。它们是主数据,该立刻可用,不等整单放行。
|
||||
|
||||
### 4.3 S2 差异分析 —— 纯系统 + AI 唯一一次出场
|
||||
|
||||
```
|
||||
① analyze model: deepseek-v4-flash into 'result:items'
|
||||
input from each('parts.type_param' where type_id=本单类型):
|
||||
{ 字段名, 字段说明, 约束(硬/软), 单位,
|
||||
原PN值 = lookup('parts.parameter' by internal_pn=原PN, param_name=col),
|
||||
原PN值说明 = 同上 take param_note,
|
||||
候选值 = lookup('parts.parameter' by internal_pn=候选PN, param_name=col),
|
||||
候选值说明 = 同上 take param_note }
|
||||
output schema { items: [{ param_name, difference_status, impact_statement,
|
||||
evidence_note, unknown_disposition? }] }
|
||||
|
||||
② project substitution.difference_item prune
|
||||
from each('parts.type_param' where type_id=本单类型) ← **行由字典决定,不由 AI 决定**
|
||||
parameter_name / parameter_desc / constraint_type / parameter_unit ← {col:…}
|
||||
original_value / candidate_value ← lookup('parts.parameter' …)
|
||||
difference_status / impact_statement / evidence_note / unknown_disposition
|
||||
← lookup('result:items' by param_name={col:'param_name'}, else '')
|
||||
judgement_class = when 链(见 §3.5);risk_level 由它映射
|
||||
|
||||
③ project substitution.relation from once
|
||||
recommendation_level / risk_level / difference_summary /
|
||||
recommendation_reason / verification_requirement ← §3.5 规则与模板
|
||||
|
||||
④ project validation.record from once
|
||||
|
||||
⑤ say
|
||||
|
||||
doneWhen difference_item_rows = 本类型字段数
|
||||
and substitution_relation_rows = 1
|
||||
and validation_record_rows = 1
|
||||
```
|
||||
|
||||
**这一步一张卡都不发,人不出现。** 三处刻意的克制:
|
||||
|
||||
- **AI 决定不了「有几行」。** 明细的行由类型字典 `each` 出来,AI 的出参只是拿 `param_name` 去
|
||||
`lookup` 的一张查表;它漏了哪一条,那一行的四态就是空 —— `required` 立刻把它变成
|
||||
`_missing > 0`,提交闸与放行门当场拦住。**从前是 `from each(AI 出参)`,AI 少给两条就少两行,
|
||||
而每一行看着都合规。**
|
||||
- AI 只答「这一条算什么、为什么」,**值是多少一个字都不重述** —— 基座读得到的事实不让模型转述。
|
||||
- 推荐等级、风险、摘要、推荐理由**全由规则与模板拼**。永远不会出现「有硬约束不符却写着推荐」。
|
||||
- 出参不合 schema → **就地重问一次**;第二次仍不成 → 留痕交人,不退回模型自由发挥。
|
||||
|
||||
### 4.4 S3 结论审核 —— 一张验收工单,人就地改
|
||||
|
||||
配方只有一笔:`card` 审核卡(`variant: 'review'`,件 `difference-review`,**单一选项「确认通过」**,
|
||||
带人工验收清单四条)。
|
||||
|
||||
人在件上改四态 / 影响 / 依据 → 保存 → tick → 配方重跑 → S2 的第③笔把推荐等级、摘要、风险
|
||||
**重算一遍**(同 PK 覆盖)→ 件刷新。改几次都行,**不重跑 AI**。
|
||||
|
||||
> 重算发生在 S2 那一步的配方里,而 S2 已收步 —— 所以 S3 的配方里**复制一份 ③④ 两笔**
|
||||
> (纯投影、幂等),不去回退步骤。这是刻意的:一步一份配方,不做跨步回跳。
|
||||
|
||||
这一步**不给 `doneWhen`**(它触达世界),人点了「确认通过」即收步。
|
||||
|
||||
### 4.5 S4 落账放行 —— 纯系统派单
|
||||
|
||||
```
|
||||
① project sub_eval.case.summary from once ← 模板串
|
||||
② submit view 'landing-confirm' + 人工验收清单五条
|
||||
```
|
||||
|
||||
人签 → 合并 `substitution.relation` / `difference_item` / `validation.record` / `sub_eval.case`
|
||||
进正式表 → 发口 `assessment-released`。
|
||||
|
||||
**出口载荷**:`evalRef` · `relationId` · `originalPn` · `candidatePn` · `recommendationLevel` ·
|
||||
`matchTotal` / `mismatchTotal` / `unknownTotal` / `conditionalTotal` · `validationId`。
|
||||
|
||||
### 4.6 预算
|
||||
|
||||
调人 3 次(补数据 / 审核 / 放行),cap **8**;模型调用 **1** 次,tokens **30 万**;
|
||||
步数 **40**(保存一次 = 一拍,给人反复保存留余量);`activeMinutes` 60。
|
||||
对照现版:90 步 / 200 万 token / 16 次调人。
|
||||
|
||||
---
|
||||
|
||||
## 5. 平台要补的能力
|
||||
|
||||
全是**加法**。E04 / I01 一个字不用改 —— 有 `guide` 的步照常问模型。
|
||||
|
||||
### 5.1 `PlanStep.auto` 配方 + 求值器
|
||||
|
||||
契约照 ADR-014 §4 的形状,**只实现这几式**:
|
||||
|
||||
- **动词**:`project` · `card` · `analyze` · `submit` · `say`
|
||||
- **表达式**:常量 · `{in:入参|基座读数|let}` · `{col:本行列}` / `{outer:外层行列}` ·
|
||||
`{lookup:地址, by, take, else}` · `{when:S-FEEL, then, else}` · `{cat:[…]}` · `{fmt:…, as:'digits'}`
|
||||
—— `lookup` 的地址除了 `域.对象`(任务视图)/ `mine:域.对象`,还能是**拍内作用域的数组** `result:xxx`
|
||||
(`analyze` 的出参当查表用,S2 的明细就靠这一条)
|
||||
- **数据源**:`{once}` · `{rows:[…]}` · `{each:…, where?, then?{each:…}}`(**两层封顶**)
|
||||
- **地址只有四种**,配方里出现的每一处都得是其中之一:
|
||||
- **`域.对象`** —— **任务视图 = 正式表 + 本单草稿叠加**。这是配方默认该用的那一种。
|
||||
(它不是新东西:`engines.ts` 的 `taskData.view` 早就把 `ledger.taskView` 的结果铺在这个键上。
|
||||
**这一点是这套设计的命门** —— 人在件上新建的料与字段,按保存那一刻只在草稿层;
|
||||
拿纯正式表去看永远看不见它们,参数格就永远铺不出来。)
|
||||
- `mine:域.对象` —— 只有本单草稿写下的行。**「哪几颗料是这一单要办的」只有它答得出**
|
||||
- `in:入参数组` —— 起单入参里的数组
|
||||
- `result:xxx` —— 本拍 `analyze` 的出参
|
||||
**没有「纯正式表」这一种**,配方不需要它:要区分「本单写的」与「别人放行的」,用 `mine:` 就够了。
|
||||
- **`project` 加 `prune: true`**:这一笔投影出来的行**就是这张表在本单草稿里的全部**,多出来的撤掉。
|
||||
只动本单草稿层,正式表一个字不碰。(换类型时上一个类型铺的参数行必须消失。)
|
||||
|
||||
求值器是纯函数(域层、零 IO);执行器在 usecase,拿 ledger / humanTool / llm 端口。
|
||||
|
||||
**必须写死的一条**:每一笔 `do` 执行**之前**刷新基座读数。S2 的第③笔要数第②笔刚写下的行 ——
|
||||
不刷新就恒为 0,等级永远算成「推荐」。
|
||||
|
||||
### 5.2 `analyze` 动词 —— 声明式 AI 调用
|
||||
|
||||
入参由声明组装、出参给 JSON schema、结果落进拍内作用域 `result:*` 供后面的 `project` 消费。
|
||||
走现有模型网关(四元绑定、凭证隔离、录制回放、用量计入预算),**不给工具、不给记忆、不多轮**:
|
||||
一次 generate,结构化出参。出参不合 schema → 就地重问一次 → 仍不成 → 留痕交人。
|
||||
|
||||
### 5.3 视图绑定加一件:`data-options`
|
||||
|
||||
`data-options="parts.chip_type"` + `data-option-value="type_id"` + `data-option-label="type_name"`
|
||||
→ 渲染时把 `<option>` 铺进那个 `<select>`,与 `data-rows` 同一层机制:**只取值,不判断**。
|
||||
地址写法与 `data-rows` 一致(`域.对象` = 任务视图,`mine:域.对象` = 本单草稿)。
|
||||
|
||||
只读那一份**不用新东西** —— 走已有的 `data-by` 查表
|
||||
(`<span data-rows="parts.chip_type" data-by="type_id=chip_type_id">` 摆 `type_name`)。
|
||||
「枚举列上下两态得说同一个字」那条账因此不会重演:上面是 label,下面也是 label。
|
||||
|
||||
### 5.4 件上「保存」之后 tick 一次
|
||||
|
||||
保存路由落草稿后调 `TaskService.wake`(现在只有两条回传路由调它)。
|
||||
|
||||
**护栏:有未答的卡在场时,配方只跑 `project` / `say`,不发新卡、不 submit、不 analyze。**
|
||||
—— 只算、只写。
|
||||
|
||||
### 5.5 审核卡放宽到单选项 + 卡答复即收步
|
||||
|
||||
- 决策卡「少于两个选项拒发」对 `variant: 'review'` 放宽到 1。
|
||||
- auto 步发过的卡被答复、且这一步没有 `doneWhen` → **收步**。
|
||||
人已经签了,收步是照实记录,不是替人签字 ——「人工激活项不给 `doneWhen`」那条纪律
|
||||
防的是引擎抢在人前面,这里人在前面。
|
||||
|
||||
### 5.6 `submit` 动词
|
||||
|
||||
ADR-014 §8 原写「不 submit、不发决策卡」。**那是假设还有 agent 在场时的保守话**;
|
||||
这个活动全程无 agent,没有别人来干这两件事,不开口最后两步就没人做。
|
||||
|
||||
护栏:`submit` 只许出现在声明了 `acceptanceChecklist` 的那一步;提交门(判据全绿)照旧把关 ——
|
||||
**系统提交不比模型提交宽松**。
|
||||
|
||||
### 5.7 静态审在装包时把住
|
||||
|
||||
与 `refersTo` 目标检查同款:
|
||||
|
||||
- `into` / `each` / `lookup` 的台账地址必须在 `declarations.ledger` 里(与写的授权面同一份名单)
|
||||
- `fields` 的列名必须在该对象的列声明里
|
||||
- `when` 的 S-FEEL 必须能解析、引用的名字绑得上(`boundNames`,已有)
|
||||
- `card` / `submit` 的 `view` 必须在 `viewTemplates` 里
|
||||
- `analyze` 的出参 schema 必须是对象,`into` 指向的键必须被后面某一笔消费
|
||||
- **没实现的表达式形式当场拒** —— 说好「只做真用得到的那几式」,静态审就是这句话的执行人
|
||||
|
||||
### 5.8 引擎拍内次序
|
||||
|
||||
```
|
||||
tick
|
||||
├─ ① 拍首自动收步(doneWhen 为真的项;人工激活项需 worldTouched)
|
||||
├─ ② 算 current
|
||||
├─ ③ current.auto → 跑配方(每一笔之前刷新基座读数)
|
||||
│ · 有未答卡在场 → 只跑 project / say
|
||||
│ · 抛错 → 留痕 + 交人(不重试、不退回模型)
|
||||
├─ ④ 发了卡 / submit → 收拍(零 token)
|
||||
├─ ⑤ 没发卡 → 重求 doneWhen;真了收步,回 ②(封顶 8 轮)
|
||||
├─ ⑥ 这一步有 guide → 照常问模型(老活动走这条)
|
||||
└─ ⑦ 无 guide、doneWhen 不成立、也没有卡在等 → 交人(配方没做到位,是包的 bug)
|
||||
```
|
||||
|
||||
### 5.9 观测
|
||||
|
||||
配方每一笔进 `sys.task_memory`,`detail.auto = '<步名>#<第几笔>'`,工作日志归**系统灰**;
|
||||
`analyze` 那一笔归 AI 蓝。治理台的活动详情能把「这一步系统会做什么」直接摆出来 ——
|
||||
配方是数据,渲染得出来。
|
||||
|
||||
---
|
||||
|
||||
## 6. 三张件 + 一张看板
|
||||
|
||||
### 6.1 `input-supplement` · 评估输入补全(数据工单)
|
||||
|
||||
三块竖排,一张贯穿(在办可编辑 ↔ 办结 `finalHtml` 静态归档)。
|
||||
|
||||
1. **要评估什么** —— 原 PN / 候选 PN 两行(行由系统铺,人不加行)。在库的挂品牌与类型徽;
|
||||
不在库的那一行摊开成可填的主数据格(类型下拉 / 品牌 / 生命周期 / 规格描述…)。
|
||||
顶上一条红带说清 `gate_reason`。
|
||||
2. **芯片类型** —— 一个下拉(`data-options` 从 `parts.chip_type` 现读)+ 下面
|
||||
「这个类型的核心参数字段」表。选已有类型 → 表只读回显;**＋新建类型** →
|
||||
类型表加一行(`type_id` 空着由基座续号),字段表加行(字段名 / 说明 / 硬软 / 单位)。
|
||||
3. **参数值** —— 左右两栏(原 PN / 候选 PN),一字段一行,**两栏都可填**:在库那颗回填现值
|
||||
(它的参数当年没录全的话,那一格就是空的,照样点名要填),要建那颗全是空格。
|
||||
行由系统铺,**人不加行不删行**。
|
||||
|
||||
底下编辑闸 + 缺项红带,与提交闸、S1 的 `doneWhen` **同一份数**。
|
||||
|
||||
### 6.2 `difference-review` · 差异评估结论审核(验收工单)
|
||||
|
||||
- **顶**:对决头(原 PN → 候选 PN、类型徽)+ 四态分布带 + **推荐等级大徽章**
|
||||
(规则算的,人改四态它当场跟着变)。
|
||||
- **中**:逐条差异明细表,一行一参数 —— 字段名 · 说明 · 硬/软徽 · 原值 · 候选值 · 单位 ·
|
||||
**四态(下拉,可改)** · **影响说明(可改)** · **判断依据(可改)** ·
|
||||
UNKNOWN 去向(判 UNKNOWN 才必填)。
|
||||
- **下**:推荐理由 / 差异摘要 / 风险 / 验证要求 —— **只读**。
|
||||
它们是系统算出来的,**要改就去改上面那一条四态** —— 让人直接改摘要,
|
||||
等于让他给自己没做的判断盖章。
|
||||
|
||||
### 6.3 `landing-confirm` · 落账确认(终局验收工单)
|
||||
|
||||
全只读,答「这一签下去发生什么」:进哪几张表各几行(摆人读名)· 结论卡(等级 + 一句话)·
|
||||
四态分布,硬约束不符的**逐条点名** · 待验项清单(P-06 的测试条件与后续动作)· 发哪一口。
|
||||
|
||||
### 6.4 运营中心看板 `activity-ledger`
|
||||
|
||||
重绑到新表(最近一次已放行实例:案卷 → 两颗料 → 类型与字段 → 参数对照 → 明细 → 关系 → P-06)。
|
||||
|
||||
---
|
||||
|
||||
## 7. 判据与人工验收清单
|
||||
|
||||
**机检(全部基座数)**
|
||||
|
||||
| key | level | 谓词大意 |
|
||||
|---|---|---|
|
||||
| `input-ready` | L1 | 两颗都在库 · 类型一致 · 参数行数 = 字段数×2 · 参数值不缺 |
|
||||
| `every-param-judged` | L2 | `substitution_difference_item_missing = 0` 且四态四档计数之和 = `_rows`(AI 漏一条 → 那行四态为空 → 两边都不成立) |
|
||||
| `level-by-rule` | L2 | 推荐等级与 `judgement_class` 计数一致(硬不符>0 必须是「不推荐」…) |
|
||||
| `unknown-has-disposition` | L2 | `substitution_difference_item_missing = 0` |
|
||||
| `validation-landed` | L2 | P-06 一行且 `_missing = 0` |
|
||||
| `evidence-credible` | L4 | 影响说明与判断依据站得住(裁量) |
|
||||
| `values-traceable` | L4 | 参数值与原厂资料对得上(裁量) |
|
||||
| `gate03-release` | L5 | 责任关,不上卡 |
|
||||
|
||||
**人工验收清单**
|
||||
|
||||
- S3 审核卡四条:逐条对过原值与候选值 / 硬约束项逐条看过 / UNKNOWN 都写了去向 / 影响说明能站住
|
||||
- S4 放行卡五条:等级与四态一致 / 待验项清单认可 / 落账内容核对过 / 参数值来源可追 / 签了就发给下游
|
||||
|
||||
---
|
||||
|
||||
## 8. 包与退役
|
||||
|
||||
**原地重写 `part-substitution-assessment@2.0.0`**。跟着退役的:
|
||||
|
||||
- 两枚工具 `compare-parameters` / `recommend`(全仓只有 W05 用)—— 注册表停用,留墓志铭;
|
||||
- **判定表 D01 退役**(四态改 AI 判);**D02 的规则搬进配方的 `when` 链后 DMN 也退役** ——
|
||||
规则只许有一处真源,再留一份 DMN 就是同一件事两处各存一份;
|
||||
- 说明书 `NARRATIVE` 瘦成「这个活动是干什么的」(全程无 `guide`,它不再进提示词;
|
||||
`analyze` 的提示词是那个动词自己的字段);
|
||||
- 现有五张视图模版全部作废,重做三张 + 看板重绑;
|
||||
- `sub_eval.pn_check` / `input_gap` / `verdict` 三张单据退役,由 `sub_eval.case` 一张顶掉。
|
||||
|
||||
**样例集五条**(名 ≤14 字,与 e2e 案例一一对应):
|
||||
「都在库·零卡直分析」「候选缺库·类型已有」「候选缺库·新建类型」「类型不一致·硬拦」「两颗都缺库」
|
||||
|
||||
---
|
||||
|
||||
## 9. 测试与验收线
|
||||
|
||||
- **包内自测**:配方每一笔的口径钉死(字段齐全 / `when` 链 / 模板串 / 静态审能过 /
|
||||
说明书不出现具体料号与参数名)。
|
||||
- **平台侧**:求值器纯函数测(七式表达式 × 三种数据源 × 两层嵌套 × `prune`)·
|
||||
`analyze` 出参不合 schema 就地重问 · 卡答复即收步 · 保存后 tick ·
|
||||
`data-options` 渲染 · 未答卡在场时不发第二张卡 · `submit` 只许在有验收清单的步 ·
|
||||
静态审逐条拒。
|
||||
- **e2e `w05` 五案例**,验收线:**5/5 released · 配方零出错 · 提交闸每单真拦 · 模型调用恰 1 次**。
|
||||
(「行动被拒 0」这条对无 agent 的活动自动成立,改数**模型调用次数**。)
|
||||
- **浏览器走查**:「候选缺库·新建类型」那条最长的路走完(新建类型 → 加字段 → 保存铺格 →
|
||||
填值 → 提交 → 结论审核就地改 → 确认 → 落账放行 → released)。
|
||||
- **五道门禁**以退出码验:`pnpm gates`。契约变更走四步(depcruise 反查 → CONTRACT.md →
|
||||
`pnpm api:check --update && git add api-report`)。
|
||||
|
||||
---
|
||||
|
||||
## 10. 迁移次序
|
||||
|
||||
1. **契约与求值器**:`PlanStep.auto`、五动词、七式表达式、`prune` —— 纯函数先行,单测钉死。
|
||||
2. **引擎接线**:拍内次序 §5.8、留痕、观测;拿一个**最小假活动**(两步:project + card)验证机制。
|
||||
3. **`analyze` 动词**:走模型网关,schema 重问,用量计预算。
|
||||
4. **平台三件小的**:`data-options` 渲染、保存后 tick、审核卡单选项 + 卡答复即收步、`submit` 动词。
|
||||
5. **静态审**:扩到配方,把没实现的形状拒死。
|
||||
6. **数据模型**:两张新表 + `chip_type_id` 由声明合并物化;种子给库里两颗料建
|
||||
「DC-DC 降压稳压器」+ 核心参数字段,并把 `parts.parameter` 现有行的 `constraint_type`
|
||||
迁进字段表;**再加一颗 LDO 料**(如 `AMS1117-3.3`)+「LDO 线性稳压器」类型,
|
||||
供「类型不一致·硬拦」那条 e2e 用。
|
||||
7. **活动包 2.0.0**:四步配方 + 三张件 + 判据 + 样例。
|
||||
8. **e2e 五案例 + 浏览器走查**;旧 W05 跑出来的运行数据 `reset-runs` 清掉。
|
||||
|
||||
---
|
||||
|
||||
## 11. 风险与代价
|
||||
|
||||
1. **代码错是必然的错,模型错是概率的错。** 配方写错 = 每一单都错。
|
||||
对策:静态审 + 包内自测 + 五案例 e2e。**但必然的错比概率的错好查** —— 这正是把它从模型手里拿走的理由。
|
||||
2. **AI 那一步是唯一的自由面。** 提示词与 schema 是它的全部约束;出参不合 schema 就地重问一次,
|
||||
仍不成交人。值一律 lookup 台账,所以它就算胡说也污染不了数据,只会污染判断 ——
|
||||
而判断正是人在 S3 要核的东西。
|
||||
3. **类型字典会被建脏**(同一类型建两遍、字段名不一致)。件上下拉优先选已有、新建是次选;
|
||||
MVP **不做去重合并**,记 debt。
|
||||
4. **`prune` 会撤本单草稿层的行** —— 只在 S1 参数骨架这一笔用,别处不许用。静态审可以只放行这一处。
|
||||
5. **保存一次 = 一拍**。人反复保存十几次会吃步数,预算给到 40。
|
||||
6. **表达力有上限**。上限之外的不要硬塞 —— 退回模型,或者把那一段切成独立的 agent 步。
|
||||
|
||||
---
|
||||
|
||||
## 12. 不做什么
|
||||
|
||||
- **不给 AI 任何工具、不多轮、不给它写台账的口** —— 它只出一份结构化判断
|
||||
- **不做类型的去重与合并**(记 debt)
|
||||
- **不迁 E04 / I01** —— 机制先在一个活动上跑通
|
||||
- **不碰 P-01 需求主记录 / P-10 原厂技术资料 / 客户档案**
|
||||
- **不在治理台上编辑配方** —— 那就成了低代码平台;配方随包走,改配方 = 升版本重装
|
||||
- **不做三层以上的嵌套** —— 两层(类型字段 × 料)是本活动的上限
|
||||
- **不在活动内部再引一套 Mastra** —— 它在流程包编排与模型网关的原位不动
|
||||
Reference in New Issue
Block a user