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
11 KiB
11 KiB
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 · 覆盖范围确认（步骤 ①）
- 做什么：确认本轮覆盖范围。
- 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 做不到的派出去让人干。数据由服务注水，工单只是模板。