Archived
活动侧(E04 2.1.0 → 2.1.9,I01 1.2.2): - 覆盖闭合成为机检:基座新增 distinct 读数,「计划盖住的客户数 = 候选行数」钉进 S3 收步 / S4 哨兵 / 放行 L2;人加的候选客户不再被整单无视 - 「关键人待识别」占位句式全链退役:查无联系人先发数据录入卡收人;契约新增 refersTo, 计划/回执的 contact_code 只许引用真实存在的联系人(安装期核引用目标) - 台账更新确认摆全落库面:客户档案/联系人档案两张落库预览(touched: 数据源, 正式现值 + 草稿叠加),可补改、可加行(自增主键由基座续号);姓名升必填 - 更新明细:update_key 位置键 + 「同一处只留一条」L2;依据写人话不带机器键; 标题旁不摆单号;判据与文案不夹字段名;行标识去掉单标识那一段 - 回执骨架 = 计划行数钉进 S3 收步与 S4 哨兵;重做分支不许删计划凑数 - 阶段刻度对齐文档 7 步;起单样例预填满 基座侧: - 两个后端连同一个库:task-claim 跨进程租约(迁移 0030)+ Postgres LISTEN/NOTIFY 广播桥;对话区按任务内记忆序号排,不按墙上时钟;并卡「刚说过话」按记忆序列判紧邻 - 多行 write 整批先验后写(dryRun),被拒 = 一行都没落 - 决策卡意见与本单草稿字面比对,归属以观察进轨迹(note-anchors) - 括号栈补「补闭括号」两形(少一个 } / 行对象没关直接跟下一行) - 件上加行:空着的自增主键直进续号,不从别的行借号;未落下的行点名回给前端 - 人答复落库那一刻就把 runtime 翻 running(task.wake),两块同帧变脸 - 试跑单可落真库(land_master,迁移 0031,默认开);数据域按活动分组; JSON 列不再是 [object Object];按钮键感 + 在办进度条 + 防抖 - 报价链 A1–A7 从系统卸载(只卸不删源码),种子只装 E04/I01 契约变更(api-report 已刷新):FieldDeclaration.distinct / refersTo, objectDeclaration.file,landMaster,unkeyed,assetFiles,ledgerByActivityRoute。 1700 测 / typecheck / lint / depcruise / api:check 绿。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EEJX8Z7CHejvwmDQyPQuBX
81 lines
4.7 KiB
TypeScript
81 lines
4.7 KiB
TypeScript
/**
|
|
* E04 技能 —— 关系覆盖经营的方法经验。载方法,不载权力。
|
|
*
|
|
* 与剧本的分工:剧本写「这一步做什么、写哪几列」,技能写「为什么这么判、
|
|
* 拿不准时按哪条走」。剧本改了口径,技能里同一句要跟着改(规范 §5.9)。
|
|
*/
|
|
import { skillIdSchema } from '@contracts';
|
|
import type { Skill } from '@contracts';
|
|
|
|
export const COVERAGE_SKILLS: Skill[] = [
|
|
{
|
|
id: skillIdSchema.parse('crm-coverage.gap-analysis'),
|
|
label: '读覆盖现状、找决策链空白节点',
|
|
applicability: '识别候选客户之后、拟经营计划之前,要判断这一轮该覆盖谁。',
|
|
method: [
|
|
'决策链地图(`customer.profile.decision_chain`)按 BT 层级列节点:',
|
|
'· BT-01 采购/供应链层、BT-02 技术层(研发/质量)、BT-03 高层(产品总监/VP)。',
|
|
'一个节点算「已覆盖」,要同时满足三条:该节点上有联系人对应、那个人标了',
|
|
'`key_person=true`、亲密度 `relationship >= 3`。三条少一条都算空白 ——',
|
|
'认得这个人不等于覆盖了这个人,亲密度不够的关键人一样是缺口。',
|
|
'',
|
|
'调 `crm-relationship-coverage.recompute-score` 拿 `gapNodes`,别自己数:',
|
|
'节点覆盖是逐条核对的活,人算容易漏,数得出来的事一律让工具数。',
|
|
'**批量调**(入参 `customers` 数组,一次多家客户):工具调用后同拍其余动作作废,',
|
|
'一家客户调一次就要多截断一拍,而结果是同一份数据算出来的,批量传入不影响精度。',
|
|
'',
|
|
'`gapNodes` 全员缺口(一个节点都没覆盖到)是正常结果,不是异常 —— 不要回头重调工具',
|
|
'确认;缺口本身就是下一步经营计划要处理的东西。',
|
|
'',
|
|
'缺口分析只认台账现状,不猜将来:客户明说要覆盖某个人,先看 `customer.contact`',
|
|
'里有没有这个人的记录,没有的话缺口分析给不出他,只能在计划里写「需先建档」。',
|
|
].join('\n'),
|
|
crystallized: [],
|
|
knowledgeRefs: ['决策链地图', 'BT 层级'],
|
|
version: '1.0.0',
|
|
},
|
|
{
|
|
id: skillIdSchema.parse('crm-coverage.plan-drafting'),
|
|
label: '按影响力 × 亲密度缺口排经营计划',
|
|
applicability: '缺口找齐之后,要给每个关键人排优先级、定动作时。',
|
|
method: [
|
|
'排序不是拍脑袋,是尺:调 `crm-relationship-coverage.rank-key-persons` 批量算',
|
|
'(一次多条,不要一条关键人调一次 —— 拿回来的排序结果本就是同一份数据算出来的)。',
|
|
'`influence` 权重高的、`relationship` 缺口大的排前面 —— 一个天天见面的低影响力的人,',
|
|
'排序上必然让位给一个见不到面的高影响力的人,这是尺给的结论,不是你临场判断的。',
|
|
'',
|
|
'建议动作要**具体到能执行**:「拜访」不够,「下月中拜访技术总监,带 XX 认证报告」',
|
|
'才算数;每条动作配一个 `target_date`,没有时间点的建议是空话,验收判据③会核这个。',
|
|
'',
|
|
'理由(`rationale`)要说清「为什么是这个人、这个动作」——',
|
|
'引影响力评级与亲密度差值,不要只写「重要客户,建议拜访」这类空话,',
|
|
'人审计划时判的就是这句话站不站得住。',
|
|
].join('\n'),
|
|
crystallized: [],
|
|
knowledgeRefs: ['影响力 × 亲密度缺口排序'],
|
|
version: '1.0.0',
|
|
},
|
|
{
|
|
id: skillIdSchema.parse('crm-coverage.ledger-update'),
|
|
label: '收口写台账、每条更新配依据',
|
|
applicability: '执行回执收齐之后,要把结果写回 L-02/L-08 主数据时。',
|
|
method: [
|
|
'每一条更新都要能在回执里找到对应的事实 —— `evidence_ref` 不是可选的装饰,',
|
|
'是验收判据①的唯一抓手:写「Itelma·Ekaterina 的回执:已完成拜访,亲密度由3提升至4」',
|
|
'这种能溯源的**人话**(客户名·人名,不写编码、不带机器键前缀),',
|
|
'不写「综合判断」这类查无实据的话。',
|
|
'',
|
|
'覆盖度 `coverage_score` 收口时按执行后的最新数据重算一次(调',
|
|
'`crm-relationship-coverage.recompute-score`),不要凭回执的完成条数估一个大概值 ——',
|
|
'分数要能重算出同一个数,重算不出来的分数没人信得过。',
|
|
'',
|
|
'「无变动」也要写清楚:回执里 `key_person_change` 是 `unchanged`(人在卡上选的',
|
|
'「无变动」)的联系人,台账更新明细里不必为它单开一行,但不许因为没变动就漏掉',
|
|
'这条覆盖度的重算依据。',
|
|
].join('\n'),
|
|
crystallized: [],
|
|
knowledgeRefs: ['台账更新依据'],
|
|
version: '1.0.0',
|
|
},
|
|
];
|