customer-proposal-writer/SKILL.md15.7 KB
# 客户方案撰写
## 北极星
让客户读完觉得**"这家销售真的在为我着想、想帮我解决问题"**，而不是被推销。
方案永远站在客户那一侧：先讲客户的处境和痛点，再讲我们怎么帮，最后才轮到介绍我们自己。
## 🔧 维护气口：想改什么，改哪里
> 原则：**会变的内容都在数据和模板里，`scripts/render.py` 只做确定性的渲染和校验，不承担任何判断。**
> 下面这张表是这个 skill 最重要的维护索引——对号入座，不要改错地方、更不要把内容改回代码里。
| 我想改… | 改这里 | 不要碰 |
|---|---|---|
| 换客户 / 换这次的需求 / 换销售落款 | `inputs/` 下对应文件（`crm.json` / `needs.txt` / `sales.json`） | 代码、模板 |
| 更新产品能力 / 案例 / 公司 / 服务（物料本身） | `materials/` 里对应文件夹的文件 | 代码 |
| 改四段式写法、语气、判断方向、挑案例规则 | **本文件（SKILL.md）正文** | 代码 |
| 改章节顺序 / 配色 / 布局 / 落款位置 / 动效 | `assets/template.html` | `.py` |
| 改公司介绍 / 服务话术 / 底部数字 | `assets/company_stats.json` | 代码、模板 |
| 改报价规则 / 字段校验逻辑 | `scripts/render.py`（**唯一**要动代码的地方） | — |
四路"气口"对应四种变更频率：`inputs/`（每次都变）、`materials/` + `assets/company_stats.json`（偶尔更新）、`assets/template.html`（改外观时）、`SKILL.md`（改判断方式时）。代码 `scripts/render.py` 几乎不用动。
## 这个 skill 的核心架构：判断与渲染彻底分开
```
┌─ 输入三路 ──────────────┐ ┌─ 判断（你/模型现场做）─┐ ┌─ 渲染（脚本做）──────┐
│ inputs/crm.json 背景角度│ │ 提炼痛点 │ │ scripts/render.py │
│ inputs/needs.txt 痛点来源│ ───▶ │ 归并 3-5 个目标 │──▶│ + assets/template.html│──▶ output/*.html
│ inputs/sales.json 销售落款│ │ 四段式对应能力 │ │ + company_stats.json │
│ materials/ 我方物料 │ │ 痛点优先挑案例 │ │ （只渲染/校验，不判断）│
└─────────────────────────┘ └──────────┬─────────────┘ └───────────────────────┘
▼
proposal_content.json ← 单一数据源（中间层）
```
**铁律：**
- **判断 = 模型现场做**（提炼需求、归并目标、写四段式、挑案例）。SKILL.md 只给方向，**绝不写死答案**。
- **渲染 = `scripts/render.py` 做**（套模板、配色、布局、报价占位、字段校验），保证每次布局一致、不漂移。
- **`proposal_content.json` 是中间层**：模型只管把它填对，脚本只管把它渲染好。**两边谁都不越界**——模型不碰 HTML，脚本不做判断。
- **销售联系方式零容错**：`inputs/sales.json` 由脚本**原样只读渲染**，模型一个字都不生成、不改动。
## 输入：三路 + 物料，各管一段
| 文件 | 内容 | 它提供什么 | 它**不**提供什么 |
|---|---|---|---|
| `inputs/crm.json` | 客户 CRM 字段：行业、规模、意向产品、在用版本、成交状态/标签等 | **背景与角度**——行业（定背景章+挑案例）、规模、标签决定方案角度（见下） | 痛点。CRM 给不了客户这次的具体困扰 |
| `inputs/needs.txt` | 销售这次沟通了解到的需求简述 / 对话记录（自由文本） | **痛点与需求**——这是四段式"你的处境"的**唯一真实来源** | 行业背景、公司资质这类标准信息 |
| `inputs/sales.json` | 销售落款：`name` / `phone` / `wechat`(可选) / `qrcode`(可选) | **销售联系方式（固定资产·零容错）** | 不参与任何判断，纯展示 |
| `materials/` | 我方真实物料：`01_产品` / `02_案例` / `03_公司` / `04_服务` | **事实素材**——产品能力、案例、公司、服务的真实内容 | 客户的痛点 |
> demo 阶段 `crm.json` / `sales.json` 由销售手动放一份；未来 `crm.json` 对接 yccrm，`sales.json` 从**登录态 / CRM 负责人字段自动带出**。
**销售落款铁律（零容错）：** `sales.json` 里的姓名、电话、微信是零容错信息，**由 render.py 原样读取渲染，模型一个字都不许生成或改动**——避免编错号码。它属于"固定资产渲染"，不进 `proposal_content.json`。字段缺失或为空 → 落款处显示「——」，绝不编。
**CRM 标签决定方案角度（举例，非穷举）：**
- 标签含"流失客户"/"已流失" → 方案走**赢回**角度（"我们注意到贵司曾…，这次想重新…"）。
- 在用"标准版"、意向"专业版/AI教练" → 走**升级**角度（站在已用功能之上讲新增价值）。
- 全新客户 → 走标准的**首次合作**角度。
## 工作流：当销售说"给【客户】做方案，情况是【…】"时
> 销售的口头需求描述，应先落到 `inputs/needs.txt`（直接写入或粘贴对话记录）；客户 CRM 落到 `inputs/crm.json`。然后按下面顺序做。
### 第 1 步：读全部输入
读 `inputs/crm.json`、`inputs/needs.txt`，以及 `./materials/` 下的产品（`01_产品`）、案例（`02_案例`）、公司（`03_公司`）、服务（`04_服务`）物料。
产品/案例/公司/服务的**事实内容必须来自 materials，不许编**。
### 第 2 步：提炼需求/痛点
从 `needs.txt` 里提炼出客户的若干条具体需求/痛点。**尽量保留客户自己的话**。
🚫 **不许编 needs.txt 里没有的痛点**，不要靠行业常识脑补客户没说过的困扰。
### 第 3 步：目标梳理（体现把控性）
把这些需求**归并成 3-5 个核心目标**（不是逐条罗列），像顾问一样帮客户看清全局。
这是体现"我懂你、我有把控"的一步——把零散诉求收敛成几条主线。
### 第 4 步：对每条需求现场生成四段式
结合 `materials/01_产品` 里的**真实能力**，为每条需求写四段：
| 段 | 写什么 | 红线 |
|---|---|---|
| **你的处境** | 用客户原话/原意复述这条痛点，先让他觉得被听懂 | 不许我方腔，不许夸产品 |
| **这对贵司意味着** | 这个痛点的**业务代价**，站客户角度（影响良品率/安全/排产/成单/翻台率…） | 讲客户的损失，不是讲我们多好 |
| **我们怎么帮你解决** | 针对客户**这个具体场景**，授客学堂的某能力**具体怎么用**——讲机制和场景 | 不是报功能名清单；能力必须真实存在于 materials |
| **你会得到** | 客户能拿到的**结果/改变** | 落在结果上，不空喊 |
🚫 某条需求在产品物料里**找不到对应能力 → 如实写"建议进一步沟通确认"**，绝不硬塞不相干功能。
🚫 删掉"完全匹配/匹配度"这类销售徽章，那不是分析。语气全程"你的/贵司的/帮你"。
### 第 5 步：挑案例，焊到痛点上
**核心原则：痛点同构是硬通货，同行业是加分项。** 挑案例的目的是让客户信"你解决过**我这种问题**"，而不是"你服务过我同行"。
**排序逻辑：第一维度永远是「痛点/场景相似度」**（多门店分散、一线高流动、上岗取证、标准化复制、合规留痕…），**不是行业标签**。先按痛点同构度给所有案例排序，同行业只在此基础上**加分**，不作必要条件、不死卡。
每个案例**回扣一条具体需求**，按下面**三优先级**择优，**绝不伪装**：
| 优先级 | 条件 | 为什么 | JSON `match_level` |
|---|---|---|---|
| **1** | 同行业 + 同痛点 | 既懂行又解决过，最强 | `same_industry` |
| **2** | 跨行业 + 痛点高度同构 | 痛点同构是硬通货——能证明"你解决过我这种问题" | `cross_industry` |
| **3** | 同行业 + 痛点一般 | 靠"自己人"建立信任 | `same_industry_weak` |
| 都没有 | 连相近场景都没有 | 绝不硬凑 | `none` |
> 注意优先级 **2 高于 3**：一个跨行业但痛点高度同构的案例，比一个同行业却没解决过相似问题的案例更有说服力。
**句式：**
- **优先级 1**：「贵司最担心的【X】，同行【某公司】原来也这样，我们帮他【做法】做到了【效果】。」
- **优先级 2**：**必须如实标注行业差异**，并填 `similarity`（一句话说清哪里同构）：
「虽属【制造业】，但同样面对【全国门店分散培训】的难题，与贵司多门店场景高度相似——【某公司】我们帮他【做法】做到了【效果】。」
- **优先级 3**：点明是同行、但坦诚痛点不完全一致：
「同为【行业】的【某公司】也在用，虽然场景不完全相同，但同行的实践或可供贵司参考——【做法】【效果】。」
- **都没有**：「暂无高度匹配的案例，但我们可提供完整的客户案例库供贵司参考。」（JSON 放一条 `match_level: "none"`，无需 company/approach）
案例的客户名/做法/效果**必须是 materials 里的真实案例**，不许编。判断痛点是否同构是模型的活——SKILL.md 只给排序逻辑与四档方向。
### 第 6 步：写中间层
把第 2-5 步生成的全部内容写进 `proposal_content.json`（结构见下）。这是**唯一数据源**。
### 第 7 步：渲染
运行 `python3 scripts/render.py`，它读 `proposal_content.json` + 固定资产（`assets/company_stats.json` 公司介绍/服务/数字 + `assets/template.html` 模板 + `inputs/sales.json` 销售落款）→ 输出 HTML 到 `output/`。**报价占位、字段校验也在这一步由脚本完成。**
## 受众语气
从 `crm.json` / `needs.txt` 判断受众，写进 `proposal_content.json` 的 `audience` 字段：
- **管理层**（对接的是老板/总监、关注 ROI 与全局）→ 顶部生成"一屏看懂"摘要、多用结果和数据。
- **对接人**（HR/培训专员等执行层）→ 可讲到操作层面，但仍简洁，别让他花很久读；不出"一屏看懂"。
## proposal_content.json 结构（模型负责填，render.py 负责读）
```jsonc
{
"customer_name": "客户公司名",
"industry": "行业", // 来自 crm.json
"scale": "企业规模", // 来自 crm.json
"audience": "管理层", // 管理层 | 对接人
"angle": "升级", // 首次合作 | 升级 | 赢回（由 CRM 标签判断）
"background": "客户所处行业大环境的一段话（背景章，站客户视角）",
"challenges": ["客户原话/原意的痛点1", "痛点2", "..."], // 现状与挑战，尽量保留客户的话
"goals": ["归并后的核心目标1", "目标2", "目标3"], // 3-5 个，不是逐条罗列
"matches": [
{
"title": "这条需求的小标题",
"situation": "你的处境（客户的话）",
"impact": "这对贵司意味着（业务代价）",
"how": "我们怎么帮你解决（具体机制/场景）", // 找不到能力时设为 null
"gain": "你会得到（结果）", // 找不到能力时设为 null
"todo": false // 找不到对应能力时为 true → 渲染成"建议进一步沟通确认"
}
],
"cases": [
{
"need": "回扣的那条需求（客户担忧）",
"match_level": "same_industry", // same_industry | cross_industry | same_industry_weak | none
"company": "案例客户名（materials 里真实；none 档可省）",
"industry": "案例所属行业",
"scale": "案例规模",
"similarity": "仅 cross_industry 需要：一句话说清哪里场景同构（如'同样是全国上万门店分散培训'）",
"approach": "做法（materials 里真实；none 档可省）",
"effect": "效果（materials 里真实；none 档可省）"
}
]
}
```
> `render.py` 只读 `proposal_content.json` 里的上述字段；公司介绍、服务保障、底部数字、落款等**固定资产**在 `assets/company_stats.json`，销售联系方式在 `inputs/sales.json`，模型都不用在本 JSON 里重复。
## 章节结构（render.py 固定，不漂移）
封面 →（管理层才有）一屏看懂 → ①方案背景 → ②现状与挑战 → ③目标梳理 → ④解决方案·四段式 → ⑤案例（"同样的难题，我们解决过"，痛点优先）→ ⑥服务与安全保障 → ⑦报价（占位）→ ⑧关于我们 → 销售落款。
- 飞书风：主色 `#1456F0`，字体 PingFang SC，轻量克制的滚动动效。
- 报价永远是**占位区**，不含数字。
- "关于我们"放最后、弱化。
## 工程结构
```
proposal-skill/
├── SKILL.md # 本文件：维护气口 + 工作流 + 判断方向（不写死答案）
├── inputs/ # 【气口1：每次用都会变的输入】
│ ├── crm.json # 客户 CRM 字段（demo 手填，未来对接 yccrm）
│ ├── needs.txt # 销售这次沟通的需求描述/对话记录（自由文本）
│ └── sales.json # 销售落款：姓名/电话/微信/二维码（零容错，未来从登录态带出）
├── materials/ # 【气口2：我方物料，会更新但不常变】
│ ├── 01_产品/ 02_案例/ # 产品能力 / 客户案例
│ ├── 03_公司/ 04_服务/ # 公司介绍 / 服务保障
│ └── 05_友商/ # 友商对比（备用）
├── assets/
│ ├── template.html # 【气口3：布局/配色/章节顺序/动效/落款位置】
│ └── company_stats.json # 【气口4：公司介绍/服务话术/底部数字】
├── scripts/
│ └── render.py # 唯一的代码：渲染 + 校验 + 报价占位（不判断）
├── proposal_content.json # 中间层：模型把判断结果填进来（单一数据源）
├── output/
│ └── 方案_<客户>.html # 生成结果
└── README.md # 给人看的使用与维护说明
```
## 换客户怎么用（关键：内容跟着全变）
1. 把这个客户的 CRM 放进 `inputs/crm.json`，把这次沟通了解到的需求/对话放进 `inputs/needs.txt`，销售落款放进 `inputs/sales.json`。
2. 模型按上面工作流**重新做一遍判断**，覆盖写 `proposal_content.json`。
3. 跑 `python3 scripts/render.py`。
> 换行业、换需求 → 背景、挑战、目标、四段式、案例**全部跟着变**。
> 如果换了客户还冒出上一个客户/行业的内容，说明判断没做干净（或没覆盖写 JSON），要重做。