Archived
xcsandClaude Opus 5
0aa2fc11b0
**资料文件全链**(用户:审核资料这一步要真产出 word/excel/md/html,前端能渲、点资料名能开)
接手时这一步一个文件都产不出来 —— S3 剧本白纸黑字写着「file_ref 本 MVP 阶段可留空」。
文件是台账那一行的投影,不另存一份:
· 声明 `file:{titleColumn,bodyColumn,formatColumn}`,它同时是授权面(没声明就点不开)
· 现造真字节 —— docx/xlsx 是自己打的 OOXML 包(zip-write:store+CRC32,零依赖)
· 读回来渲 —— 解的就是造出来那份字节,渲得出来才证明文件是真的
· 件上 `data-file-of` → 工作区二级界面(Word 纸面/Excel 网格/渲好的 md/沙箱 html)+ 下载原件
放行落地前把每一份冻进 `sys.task_asset_file`(迁移 0029):归档件点开的必须是签字那一刻
那一份,而资料落在主数据上、试跑单不落正式表 —— 不存这一份,收工后一个都点不开。
工作成果里「产出的资料」自成一摞。Markdown 富文本渲染顺带销账(仍零依赖)。
**Harness**
· 画面按「这一拍办完之后」在办的那一步挑 —— 从前拿拍首的局面决定拍尾的事:
收掉 S4、发出 S5 的卡,而屏上还摆着 S4 的只读件,人无处可填(墙要配路第四次现形)
· 验收「重做」真能退回重做,且打回后台账没动就不许再提交(软硬两段,不锁死单子)
· 立监听的授权面是清单声明;发卡的授权面是调人预算,不是计划项
· 读工具同参重调有兜底;空转写身后还有行动就不废串;finish 的 doneWhen 按写完后的草稿算
**界面**
· 翻件与翻页各归各位(从前二选一,多卡多页时页翻不动);没得翻写「—」不写 0/0
· 工作成果详情能翻份;表宽超出能横滑(E04/I01 抄版式时把 overflow-x 抄丢了)
· 查看面灰底滚过一屏变白 —— 两条独立的路都治了(沙箱内不同色 / 弹性子项不长个)
· 测试台「取不到」不再当成「还活着」
**活动**
E04 关系覆盖、I01 品牌内容各自补到验收线:判据全读基座数、判据指向的东西摆上卡面、
样例满载且名字 ≤14 字;提交前要裁的判据搬进说明书(模型会压拍,压过之后只有说明书还在)。
验收:e2e i01 4/4、e04 3/3 全部 released,资料在办中渲得出、放行后存了档点得开;
门禁 typecheck/lint/depcruise/1628 测全绿。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EEJX8Z7CHejvwmDQyPQuBX
178 lines
11 KiB
Markdown
178 lines
11 KiB
Markdown
# E04 关系覆盖与关键人经营 · 活动流程与工单说明
|
||
|
||
> 所属子系统：SS01 客户与市场 ｜ 优先级：P0 ｜ 类型：关系经营型活动
|
||
> 本说明总结 E04 活动的整体流程、工单产出的设计逻辑，以及每一步做了什么。配套工单 HTML 见本目录。
|
||
|
||
---
|
||
|
||
## 一、活动定位
|
||
|
||
**E04 关系覆盖与关键人经营**是围绕客户关系网络的持续经营活动：关键人识别与覆盖、关系亲密度维护、决策链更新、影响力经营。核心理念是「你还没开口，你想要的我已经给你了」——关系覆盖是预判需求的前提。
|
||
|
||
**消费的台账**（读）：L-02 客户主台账（画像/决策链/覆盖度）、L-08 联系人台账（角色/影响力/亲密度）。
|
||
**产出的台账**（写）：L-02 的 coverage_score / decision_chain / interaction_timeline、L-08 的角色标注 / 影响力 / 亲密度 / 关键人标记。
|
||
|
||
**触发方式**：① 月度例行（每月对重点客户做一轮覆盖维护）；② 事件驱动（新客户建档 / 关键人变动 / 重大商机启动 / 攻坚项目 T04 立项）。
|
||
|
||
---
|
||
|
||
## 二、整体流程（7 步）
|
||
|
||
E04 的完整工作链条共 7 步，AI 与人的分工原则是：**AI 承担信息汇总、记录与初稿生成，人负责判断与决策**。
|
||
|
||
| 步骤 | 名称 | 谁在做 | 干什么 |
|
||
|---|---|---|---|
|
||
| ① | 启动与覆盖范围确认 | AM Lead（审） | 确认本轮覆盖哪些客户、场景类型、覆盖深度 |
|
||
| ② | 读取覆盖现状 | AI 汇总 | 调出客户画像、决策链地图、覆盖度、联系人清单，形成覆盖全景 |
|
||
| ③ | 覆盖缺口分析 | AM Lead（审） | 对照决策链识别空白节点，按 BT 层级确定需覆盖的角色 |
|
||
| ④ | 制定关系经营计划 | AM Lead（审） | 按「影响力 × 亲密度缺口」排序，草拟每个关键人的经营动作 |
|
||
| ⑤ | 执行经营动作 | AM（执行） | 拜访 / 技术交流 / 价值传递等线下动作（AI 做不到） |
|
||
| ⑥ | 更新关系台账 | AM（办理） | 重算 coverage_score、更新决策链、更新联系人档案 |
|
||
| ⑦ | 复盘与完结（门禁） | AM Lead（审） | 覆盖度达标检查，输出更新后的关系覆盖地图 |
|
||
|
||
---
|
||
|
||
## 三、为什么这样产出工单（核心设计逻辑）
|
||
|
||
7 步不是 7 个工单。按「AI 能不能独立完成」把 7 步收敛成 **2 张执行工单 + 2 张验收工单**：
|
||
|
||
| 工单 | 覆盖步骤 | 类型 | 依据 |
|
||
|---|---|---|---|
|
||
| 执行工单 1 | ① | 执行 | AI 识别出了覆盖范围，但「规则之外」的信息需要人来补 |
|
||
| 验收工单 1 | ②③④ | 验收 | AI 算出了经营计划，需要人判断计划是否合理 |
|
||
| 执行工单 2 | ⑤⑥ | 执行 | 计划要人去线下执行（AI 做不到），执行完要回执 |
|
||
| 验收工单 2 | ⑥⑦ | 验收 | AI 收到回执后更新台账，需要人确认无误后入库 |
|
||
|
||
### 两条工单的本质区别
|
||
|
||
**执行工单 = AI 产出 + 人填内容**
|
||
- AI 先列出它产出的结论（候选基线），人在这基础上**查漏补缺 / 填写内容**（可以不填）。
|
||
- 用于「AI 做不到、需要人去做」的事——如物理拜访、线下交流、补充 AI 识别规则之外的信息。
|
||
|
||
**验收工单 = AI 结论展示 + 人只做审批**
|
||
- AI 展示它计算出的结论（只读），人**只做「通过 / 驳回」**，不能修改结论；驳回带意见，AI 重做。
|
||
- 用于「AI 算出了结论、需要人拍板」的事——如经营计划是否合理、台账更新是否无误。
|
||
|
||
### 三条硬约束
|
||
|
||
1. **工单不承载审批动作**：工单里不放「提交回执 / 通过 / 驳回」按钮，审批动作统一放在对话区的卡（执行卡 / 验收卡）里。
|
||
2. **工单要完整**：每个工单必须包含「做什么 / 交回什么 / 期限 / 判据（验收工单）/ 提交后去向」。
|
||
3. **交回内容可校验**：执行工单的回执字段标注必填（＊）/ 选填，验收工单给明确的判据清单，让人知道凭什么通过或驳回。
|
||
|
||
---
|
||
|
||
## 四、每个工单详细说明
|
||
|
||
### 执行工单 1 · 覆盖范围确认（步骤 ①）
|
||
|
||
- **做什么**：确认本轮覆盖范围。
|
||
- **AI 产出**：按台账规则识别出的候选客户清单（如 AvtoKom、Boreas）＋ 场景类型、覆盖深度。
|
||
- **人填什么（查漏补缺）**：在 AI 清单上直接增删改——加一行 = 额外纳入（AI 没识别但人了解有价值）、删一行 = 排除（AI 纳入了但实际应排除）、改单元格 = 修正 AI 识别内容。
|
||
- **为什么是执行工单**：AI 只能按台账规则判断，有些「数据里没有、但人线下知道」的信息（如某贸易商掌握关键渠道）需要人补充录入。
|
||
- **交回**：核对后的覆盖范围客户清单（客户编号、客户名称必填）。
|
||
|
||
### 验收工单 1 · 关系经营计划审批（步骤 ②③④）
|
||
|
||
- **做什么**：审批 AI 制定的关系经营计划。
|
||
- **AI 产出**：经过「读覆盖现状 → 缺口分析 → 制定计划」三步计算，得出经营计划（经营哪些关键人、建议动作、建议优先级、理由），按「影响力 × 亲密度缺口」排序。
|
||
- **人怎么审**：只读展示，不可修改。按判据核对后「通过」或「驳回＋意见」（驳回 AI 重做）。
|
||
- **验收判据**：① 关键人覆盖是否完整；② 优先级排序是否合理；③ 动作是否可执行、有时间点。
|
||
- **为什么是验收工单**：计划是 AI 算出来的结论，人对结论只做肯定或否定，不自己改。
|
||
|
||
### 执行工单 2 · 经营计划执行回执（步骤 ⑤⑥）
|
||
|
||
- **做什么**：执行已验收通过的计划动作。
|
||
- **AI 产出**：验收通过后的计划动作清单（拜访谁、做什么）。
|
||
- **人填什么（回执）**：逐项填完成状态（必填）、结果摘要（必填）、客户反馈（选填）、关键人变动（必填）。
|
||
- **为什么是执行工单**：拜访、技术交流、递送实物都是 AI 做不到、需要人到场执行的事；人执行后把回执填回来。
|
||
- **交回**：每项计划动作的执行回执。
|
||
|
||
### 验收工单 2 · 关系台账更新确认（步骤 ⑥⑦）
|
||
|
||
- **做什么**：确认 AI 拟更新的台账，无误后入库。
|
||
- **AI 产出**：收到执行回执后，重算 coverage_score、更新决策链、更新 L-08 联系人档案、追加互动时间线，产出「更新前 → 更新后」明细。
|
||
- **人怎么审**：只读展示，不可修改。按判据核对后「通过入库」或「驳回＋意见」。
|
||
- **验收判据**：① 更新是否有依据（每条更新能否在回执里找到对应事实）；② 数值是否合理；③ 有无漏更或误更。
|
||
- **为什么是验收工单**：台账更新是 AI 的落账动作，人确认无误后入库，是「终局唯放行」的最后一道确认。
|
||
|
||
---
|
||
|
||
## 五、文件对应关系
|
||
|
||
| 工单文件 | 类型 | 覆盖步骤 | 一句话 |
|
||
|---|---|---|---|
|
||
| `E04-执行工单-01-覆盖范围确认.html` | 执行 | ① | 人补充 AI 覆盖范围结论之外的信息 |
|
||
| `E04-验收工单-01-关系经营计划.html` | 验收 | ②③④ | 人审批 AI 的经营计划（通过/驳回） |
|
||
| `E04-执行工单-02-执行回执.html` | 执行 | ⑤⑥ | 人执行计划并填回执 |
|
||
| `E04-验收工单-02-台账更新确认.html` | 验收 | ⑥⑦ | 人确认 AI 的台账更新后入库 |
|
||
|
||
**完整闭环**：
|
||
|
||
```
|
||
① 覆盖范围确认 ──执行工单1(人补信息)──▶ ②③④ AI 制定计划 ──验收工单1(通过/驳回)──▶
|
||
⑤⑥ 人去执行计划 ──执行工单2(人填回执)──▶ AI 更新台账 ──验收工单2(确认入库)──▶ 完结
|
||
```
|
||
|
||
---
|
||
|
||
## 六、动态数据标注（模板绑定位置）
|
||
|
||
> 这 4 个工单 HTML 是**模板**——里面的数据会根据实例（不同任务 / 客户 / 轮次）加载不同内容。本表标注每个工单里「动态数据」的位置及其绑定地址（命名空间）。设计态示例数据在运行时会被注水器替换。
|
||
|
||
### 6.1 绑定命名空间速查
|
||
|
||
| 命名空间 | 含义 | 本活动用到 |
|
||
|---|---|---|
|
||
| `meta.*` | 任务与活动元数据 | 收件人、任务编号、步骤、活动名 |
|
||
| `card.*` | 工单身份专属 | 期限、工单编号、验收判据、回执字段 |
|
||
| `out.*` | 输出表单 / 台账映射行集 | 客户清单、经营计划、台账更新明细 |
|
||
| `sd.*` | 状态数据读数 | 客户计数、触发口径、覆盖度 |
|
||
|
||
### 6.2 四个工单共用的动态位置（每个工单头部都有）
|
||
|
||
| HTML 位置 | 动态数据 | 绑定地址 |
|
||
|---|---|---|
|
||
| 卡头「收件人」 | 负责人 | `meta.task.owner` |
|
||
| 卡头「关联任务」 | 任务编号 | `meta.task.id` |
|
||
| 卡头「步骤」 | 当前节点 | `meta.phase` |
|
||
| 卡头「最迟交回」 | 期限 | `card.deadline` |
|
||
| 页脚「工单编号」 | 工单 ID | `card.id` |
|
||
|
||
### 6.3 执行工单 1 · 覆盖范围确认
|
||
|
||
| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|
||
|---|---|---|---|
|
||
| 【做什么】里「触发口径与覆盖范围」结论 | 本轮触发场景 | `sd.trigger_scene` | 单值 |
|
||
| 编辑闸「AI 已识别 2 个客户」 | 识别客户数 | `sd.customer_count` | 单值 |
|
||
| 【交回什么】客户清单表 | 候选客户清单 | `out.customer_list` | 行集 |
|
||
| └ 客户编号 / 名称 / 类型 / BT层级 / 状态 / 依据 / 覆盖深度 | 各列字段 | `out.customer_list.*` | 字段 |
|
||
|
||
### 6.4 验收工单 1 · 关系经营计划
|
||
|
||
| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|
||
|---|---|---|---|
|
||
| 【验收判据】清单 | 判据项 | `card.criteria[]` | 列表 |
|
||
| 【AI 产出的经营计划】表 | 计划行 | `out.plan` | 行集 |
|
||
| └ 客户 / 关键人 / 建议动作 / 优先级 / 理由 | 各列字段 | `out.plan.*` | 字段 |
|
||
| └ 优先级「高/中」颜色 | 状态着色 | `data-class-of` | 状态类 |
|
||
|
||
### 6.5 执行工单 2 · 执行回执
|
||
|
||
| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|
||
|---|---|---|---|
|
||
| 【交回什么】计划动作回执表 | 计划动作（AI 产出） | `out.plan` | 行集 |
|
||
| └ 计划动作 / 对象 | AI 产出的计划 | `out.plan.action / target` | 字段（只读） |
|
||
| └ 完成状态 / 结果摘要 / 客户反馈 / 关键人变动 | 人填回执 | `card.fields.*` | 字段（可填） |
|
||
|
||
### 6.6 验收工单 2 · 台账更新确认
|
||
|
||
| HTML 位置 | 动态数据 | 绑定地址 | 类型 |
|
||
|---|---|---|---|
|
||
| 【验收判据】清单 | 判据项 | `card.criteria[]` | 列表 |
|
||
| 【拟更新的台账】表 | 更新明细行 | `out.ledger_update` | 行集 |
|
||
| └ 台账 / 字段 / 更新前 / 更新后 | 各列字段 | `out.ledger_update.*` | 字段 |
|
||
|
||
---
|
||
|
||
（完）E04 一个活动，七个步骤，四张工单：**执行工单让人补内容、验收工单让人拍结论**——AI 做得出的算出来给人审，AI 做不到的派出去让人干。数据由服务注水，工单只是模板。
|