第22章 案例：技术能力产品化
第21章讲了怎么从接单里发现真需求，但发现需求只是起点——你手里攥着一堆「我会 RAG」「我会代码审查」的技术能力，这些能力本身不值钱，客户不会为「会」付费。本章解决一个更硬的问题：怎么把一项技术能力，翻译成客户能下单、能验收、能复购的产品。 第23章会接着讲怎么从一个工具扩成一类产品。
22.1 结论先行：技术能力产品化 = 交付物 + 评估指标 + 报价梯度
先把结论摊开。
技术服务产品化 = 明确交付物 + 可验证评估指标 + 可购买报价梯度三者缺一，就不是产品。「我会代码审查」是能力；「一份按 CVSS 分级、附修复优先级矩阵、48 小时交付的安全审查报告」是产品。客户买的从来不是你的能力，而是能力变成的确定结果。
这正好对应第01章公式二的「交付闭环」——大多数技术人卡在「实现」环，做得出东西，但说不清「交付什么（范围）」「怎么算好（验证）」「多少钱（验收）」。产品化就是把这三环一次性钉死，让一个模糊能力变成可复用的 SKU。
它同时呼应公式三「复利资产」：一份报告模板、一套评测集、一份报价单，做一次用 N 次。没有产品化，你永远是计件工——接一单干一单；产品化之后，第 N 单的边际成本趋近于零。
理解这一点后，本章其余都在回答一个问题：怎么把一项你已有的技术能力，拆成这三件套，做成可售卖的产品？
22.2 技术能力产品化是什么：定位、能力与边界
与「卖工时 / 卖技术」的差异
| 维度 | 卖工时（计件） | 卖技术（炫技） | 能力产品化（本书主张） |
|---|---|---|---|
| 客户买到 | 你的时间 | 你的牛逼 | 一个确定的结果 |
| 定价单位 | 小时 / 人天 | 不可比 | 套餐 / 交付物件数 |
| 验收方式 | 「差不多了」 | 「真厉害」 | 对评估指标逐条核对 |
| 复用性 | 每次从零 | 每次从零 | 模板 + 评测集复用 N 次 |
| 客户决策成本 | 高（要懂技术） | 极高（要懂技术 + 信任你） | 低（看套餐下单） |
| 边际成本 | 恒定 | 恒定 | 趋近于零 |
「卖工时」和「卖技术」的本质都是把定价权和验收权交给客户的直觉。 产品化是把这两把钥匙拿回来——你定义交付物、你定义指标、你定义套餐，客户只需在 A/B/C 里选一个。
能做什么
- 把模糊能力变成可下单的 SKU——「代码审查」变成「单仓库快审 / 多仓库订阅 / 年度巡检」三档套餐。
- 把主观感受变成可核对指标——「查得挺全」变成「CRITICAL × N、HIGH × N，附 CVSS 与修复优先级」。
- 把一次性劳动变成可复用资产——报告模板、评测集、报价单做一次，复用 N 次（呼应公式三）。
不能做什么（边界）
- 不能把烂能力变好：产品化是放大器，不是变好的魔法。能力本身 60 分，产品化后只是「60 分的可售卖版」，不会变成 90 分。
- 不能替代需求验证：本章假设你已经验证过有人要（见第06章）。没人要的能力，包装得再精致也卖不动。
- 不能违背领域常识：评估指标必须业内公认。自造一套没人认的指标，等于自说自话。
22.3 产品化流水线：从能力到套餐的三步翻译
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 一项技术能力 │ ─→ │ 明确交付物 │ ─→ │ 可验证指标 │ ─→ │ 报价梯度套餐 │
│ 「我会 RAG」 │ │ 问答系统 demo │ │ 28题评测集 │ │ 试读/标准/定制│
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
(实现) (范围) (验证) (验收)
← 第01章公式二闭环这三步，正好是公式二「范围 → 实现 → 验证 → 验收」的后三环被显式做出来。能力本身是「实现」，剩下三环是产品化的全部工作。
22.3.1 第一步：定义交付物（把能力翻译成客户能拿到手的东西）
交付物必须满足三条：可交付、可演示、可归档。
- 可交付：是一个文件 / 一个可访问的 URL / 一个可运行的产物，不是「我帮你看看」。
- 可演示：客户能在 5 分钟内看到结果，不需要你口头解释半天。
- 可归档：客户能存档复用，下次还能翻出来看。
反例：「我做了一次代码审查」——不可交付（没产物）、不可演示（全在你脑子里）、不可归档（明天就忘）。 正例：「一份分级漏洞报告，含漏洞清单、CVSS 分级、修复优先级矩阵、复测清单」——三可齐全。
22.3.2 第二步：定义评估指标（把「好不好」翻译成可核对的数字）
评估指标必须满足三条：可量化、可复现、业内认。
- 可量化：是数字或分级，不是「比较全面」「挺准的」。
- 可复现：同样的输入，跑两次结果一致（评测集固定）。
- 业内认：用行业通用口径（CVSS、Recall@K、F1），不是自造词。
铁律：没有评估指标的交付，等于没有验收标准——呼应第01章「没有验收标准的交付不叫交付，叫白干」。
22.3.3 第三步：定义报价梯度（把「多少钱」翻译成客户能选的套餐）
报价梯度必须满足三条：有锚点、有梯度、有边界。
- 有锚点：最便宜那档让客户有个心理价位入口（哪怕免费试用）。
- 有梯度：3 档左右，覆盖「试一下 / 认真用 / 深度定制」三种心态。
- 有边界：每档明确写清「包含什么 / 不包含什么 / 加项怎么算」，防止范围蔓延。
22.3.4 把「￥X」填成真数字：定价三法
报价单里的「￥X 千」不是随便填的。三种定价逻辑，按可信度递增：
| 方法 | 逻辑 | 适用场景 | 风险 |
|---|---|---|---|
| 成本法 | 你的工时 + token 成本 × 倍率 | 起步期，先保不亏 | 上限低，忽略价值 |
| 锚点法 | 找业内同类服务对标 | 有竞品的市场 | 没竞品时失效 |
| 价值法 | 按客户省下 / 赚到的钱分润 | 高价值、可量化场景 | 客户要会算账 |
- 成本法打底：先算清「跑这一单花多少 token / 多少工时」，乘 2-3 倍，这是地板价。低于它就是亏本赚吆喝，复购越多亏越多。
- 锚点法定档：看市面上同类服务收多少（哪怕粗略对标），标准档定在对标价的 60-80%——新人入场要有价格优势，但别低到显得不值。
- 价值法封顶：问客户「这个问题不解决你损失多少」。一份安全审查拦下一个 CRITICAL 漏洞，省下的可能是几十万应急成本。按省下金额的 10-20% 定价，客户觉得划算，你拿到高客单。
铁律：永远先报价值法价，被拒退锚点法，再不行退成本法。从高往低报，不是从低往高加——先报低价，客户的心理锚就钉死在低价了。
三种方法不是单选，而是**地板（成本）→ 中位（锚点）→ 天花板（价值）**的三层定价区间。报价时心里要有这三层，给客户报的是中间偏上的位置。
22.4 三个心法
心法一：客户买的是结果，不是你的过程
客户不为你的技术深度付费，只为你的结果确定性付费。
- 把过程藏起来：RAG 用了哪种 embedding、代码审查编排了几个 agent，客户不关心。关心的是「问 28 题答对几题」「查出几个 CRITICAL」。
- 把结果摆出来：报告首页就是结论数字和分级矩阵，不是技术架构图。
心法二：评估指标是产品化的护城河
- 谁定义指标，谁掌握定价权：你能说清「准确率 92% 怎么算的」，客户就没法用「感觉不太准」压价。
- 评测集是核心资产：一套 28 题的评测集，做一次用 N 次（呼应公式三）。它既是验收工具，也是销售物料——「换 embedding 前后准确率从 44% 到 100%，这是硬数据」。
心法三：报价梯度是范围管理的工具
- 套餐就是边界：客户选了「标准版」，你就只做标准版的事。加需求 = 加档 = 加钱。
- 最便宜那档是流量入口：免费试用 / 试读版，目的是让客户低成本尝到甜头，不是赚钱。
心法四：每一份交付物都要顺产一份资产
产品化不是「多做一份报告」，而是「多攒一份能复用的资产」。
- 报告 → 模板：第一次写安全审查报告要 3 天，抽成模板后第二次只要半天。模板是资产，报告是一次性产物。
- 评测集 → 数据资产：28 题评测集做完一次，每个新客户都能用它跑基线，越用越值钱（呼应公式三：一次生产 × N 次复用）。
- 报价单 → 销售资产：一份清晰的报价单，下个客户直接套，省去重新谈价的心理摩擦。
判断一个产品化动作有没有做到位，看它顺产了几份资产：只有交付物、没有顺产模板/评测集/报价单的产品化，本质上还是计件工——只是把计件包装得好看一点。真正的产品化，是让这一次的产出，成为下一次的起点。
22.5 实战：两项技术能力的产品化全流程
下面用两个脱敏案例，完整演示从能力到套餐的翻译。案例已剥离真实平台、凭据、客户信息，只保留可迁移的工程范式。
案例一：从「我会 RAG」到「知识库问答系统」
起点：你做了一个 RAG（检索增强生成）demo，用某中文大模型 + 中文 embedding + 向量数据库，能对自己整理的文档集提问。能力是真的，但「我做了一个 demo」卖不出去。
步骤一：定义交付物
交付物清单（知识库问答系统 · 标准版）：
[ ] 一个可访问的问答 demo URL（客户可自助提问）
[ ] 一份部署文档（客户能自行重装到自己的机器）
[ ] 一份 28 题评测集 + 评测脚本（客户能自己跑准确率）
[ ] 一份 30 分钟的使用演示录屏四件东西，件件可交付、可演示、可归档。
步骤二：定义评估指标
评估指标（28 题评测集，业内口径）：
- Recall@1（Top-1 命中率）：目标 ≥ 90%
- Recall@3 / Recall@5：分档报告
- 关键词命中率（KW）：目标 ≥ 90%
- 无答案题幻觉率（该拒答时硬答）：目标 ≤ 10%
- 端到端延迟 P95：目标 ≤ 5 秒
复现方式：
python eval.py --dataset eval_28.json --endpoint <your_endpoint>
输出 report.json，数字固定可复现。这一步顺手产出一个销售物料：两版 embedding 的控制变量对比——英文通用 embedding 只有 44% Recall@1，换中文专用 embedding 后到 100%，证明中文场景必须选对 embedding。技术深度由此变现成客户信任，是「卖技术」变「卖结果」的典型路径。
步骤三：定义报价梯度
报价单（知识库问答系统）：
┌─────────┬────────────────────┬────────────────────┬────────────────────┐
│ │ 试读版（免费） │ 标准版（￥X 千） │ 定制版（￥X 万起） │
├─────────┼────────────────────┼────────────────────┼────────────────────┤
│ demo │ 公开 demo（限量） │ 独立部署 + 私有库 │ 私有化 + 定制模型 │
│ 评测集 │ 公开 28 题 │ + 客户专属 50 题 │ + 持续优化评测集 │
│ 文档 │ 使用说明 │ 部署 + 运维手册 │ 专属技术支持 │
│ 数据隔离 │ 公开 │ 客户独占 │ 私有化 │
│ 交付周期 │ 即时 │ 5 个工作日 │ 按项目周期 │
└─────────┴────────────────────┴────────────────────┴────────────────────┘三档清晰：试读版引流、标准版走量、定制版走利润。每档的「不包含什么」写进合同，防止「免费版用户要求定制版服务」。
案例二：从「我会代码审查」到「安全审查报告」
起点：你用 Claude Code 编排了一套代码审查 workflow，能对任意代码仓库输出分级漏洞清单。能力是真的，但「我帮你审一下」卖不上价。
步骤一：定义交付物
交付物清单（安全审查报告 · 标准版）：
[ ] 一份分级漏洞报告（PDF + Markdown 双格式）
- 漏洞清单（编号 / 位置 / 类型 / CVSS / 修复建议）
- 修复优先级矩阵（按 严重度 × 可利用性 四象限）
- 复测清单（修复后如何验证）
[ ] 一份可复现的审查配置（规则集 / agent 编排 / 扫描范围）
[ ] 一份 30 分钟的修复 walkthrough 录屏（针对 TOP 3 漏洞）报告首页就是结论：「本次共发现 CRITICAL × N、HIGH × N、MEDIUM × N、LOW × N，附 P0 崩溃 × N」。客户第一眼看到数字，不用翻完才知道结果。
步骤二：定义评估指标
评估指标（安全审查报告）：
- 覆盖率：扫描文件数 / 总文件数 ≥ 95%
- 分级准确率：抽样复核，分级误判率 ≤ 5%
- 误报率：人工复核，非真实漏洞占比 ≤ 10%
- 修复可执行性：每条漏洞附可粘贴的修复代码片段
行业口径：
- CVSS v3.1 评分（业内通用）
- CRITICAL / HIGH / MEDIUM / LOW 四级（业内通用）
- P0 = 触发即崩溃（自加维度，对客户决策关键）注意 P0 是这套服务自加的维度——业内通用的是 CVSS 四级，但「崩溃类问题」对客户决策特别重要，单独拎出来。这就是「业内认 + 领域增强」的指标设计法：基础用通用口径保证可比，增强维度贴合客户决策。
步骤三：定义报价梯度
报价单（安全审查服务）：
┌─────────┬────────────────────┬────────────────────┬────────────────────┐
│ │ 单仓库快审（￥X 千）│ 多仓库订阅（￥X 万/年）│ 年度巡检（￥XX 万/年）│
├─────────┼────────────────────┼────────────────────┼────────────────────┤
│ 范围 │ 1 仓库，单次 │ ≤5 仓库，每月 1 次 │ 不限仓库，季度巡检 │
│ 报告 │ 标准分级报告 │ + 趋势对比 + 修复跟踪│ + 架构级威胁建模 │
│ 交付 │ 48 小时 │ 每月定期 │ 季度 + 应急响应 │
│ 复测 │ 1 次免费复测 │ 不限次复测 │ 不限次 + 上门 walk │
└─────────┴────────────────────┴────────────────────┴────────────────────┘三档同样清晰：单次走量、订阅走稳定现金流、年度走深度服务。
模板：技术服务产品化清单
把上面两案例抽象成一个可套用的模板（呼应公式三——模板本身是资产，做一次用 N 次）：
技术服务产品化清单（套用到你的任意能力）：
【交付物】（满足 可交付 / 可演示 / 可归档）
□ 主交付物（文件 / URL / 产物）：________________
□ 辅交付物 1（文档 / 手册）：________________
□ 辅交付物 2（录屏 / 演示）：________________
□ 可复现配置（脚本 / 规则集）：________________
【评估指标】（满足 可量化 / 可复现 / 业内认）
□ 指标 1 = 数字目标（业内口径）：________________
□ 指标 2 = 数字目标（业内口径）：________________
□ 领域增强指标（自加维度）：________________
□ 复现命令 / 脚本：________________
【报价梯度】（满足 有锚点 / 有梯度 / 有边界）
□ 入门档（免费或低价，引流）：包含 ____ / 不包含 ____
□ 标准档（走量）：包含 ____ / 不包含 ____
□ 定制档（利润）：包含 ____ / 不包含 ____
□ 加项单价表：________________验证（产品化是否完成的自检）：
- [ ] 交付物能不能在 5 分钟内演示给一个不懂技术的客户？
- [ ] 评估指标能不能用一条命令跑出固定数字？
- [ ] 报价梯度能不能让客户在 3 档里 1 分钟选完？
- 三条都过，才算产品化完成。
失败边界（逐项排查）：
| 症状 | 根因 | 处理 |
|---|---|---|
| 客户看了交付物还问「你到底给我什么」 | 交付物不可演示，全在口头 | 改成实物（URL / 文件 / 录屏），删掉口头解释 |
| 客户质疑「你怎么证明查得全 / 答得对」 | 没有评估指标或不可复现 | 补评测集 + 固定脚本，跑出固定数字 |
| 客户砍价说「这个不值这么多」 | 报价没梯度，无法锚定 | 加免费 / 低价入门档做锚点，拉开档差 |
| 客户无限加需求 | 套餐边界没写清 | 每档明确「不包含什么」，加项单独计价 |
22.6 能力产品化 vs 工作流产品化 vs 工具产品化：分工与选型
技术人手里有三种「半成品」，产品化路径不同：
| 维度 | 能力产品化（本章） | 工作流产品化（第18章） | 工具产品化（第23章） |
|---|---|---|---|
| 起点 | 一项技术能力（我会 X） | 一套编排流程（workflow） | 一个可运行的程序 |
| 产物 | 服务 / 报告 / 套餐 | 可复用的 SOP / agent | 可分发的软件 |
| 客户买到 | 你跑一次的结果 | 你跑 N 次的流程 | 程序本身 |
| 边际成本 | 中（每次要跑） | 低（流程复用） | 极低（复制分发） |
| 适合阶段 | 起步期（验证有人要） | 稳定期（标准化重复） | 规模期（放大分发） |
决策树：
- 你手里是「一项技能」且还没验证有人要 → 能力产品化（本章），先把能力变成可下单的服务
- 你手里是「一套重复跑的流程」且客户要反复用 → 工作流产品化（第18章），把流程封装成 SOP / agent
- 你手里是「一个能跑的程序」且客户要自己用 → 工具产品化（第23章），把程序做成可分发软件
三者不互斥，而是能力 → 工作流 → 工具的递进。本章是这条链的起点。
22.7 失败边界：四种最常见的死法
死法一：技术炫技（客户看不懂，所以不买）
症状：交付物是「我用了 12 个 agent 协同 + tree-sitter + 知识图谱」，客户一脸懵，转头走了。
根因：把过程当结果卖。客户买的是「28 题答对几道」「查出几个 CRITICAL」，不是你的技术栈。
对抗：交付物首页只放结论数字和分级矩阵，技术细节压到附录或干脆删掉。把过程藏起来，把结果摆出来。
死法二：指标不可验证（客户感觉你在吹牛）
症状：你说「查得很全面」「准确率很高」，客户反问「怎么证明」，你答不上来。
根因：没有评估指标，或指标不可复现。主观形容词（全面、高、准）都不算指标。
对抗：强制规则——任何能力产品化前，必须先有一套固定评测集 + 固定脚本，跑出固定数字。没有数字，不上线。
死法三：交付物难理解（客户不知道拿到的是什么）
症状：你交付了一堆 JSON / 一坨代码 / 一份 50 页无结构的文档，客户不知道哪个是重点，丢一边。
根因：交付物的信息架构没有以客户视角设计。你以为「信息都给了」，客户看到的是「噪音」。
对抗：交付物必须结论先行——首页一句话结论 + 关键数字，后面才是明细。这条原则和本书每一章的写法一致（见第01章「结论先行」），交付物也一样。
死法四：客户不知道为什么买（没有触发场景）
症状：套餐设计得很好，但客户问「我为什么需要这个」「我现在不是好好的吗」。
根因：产品化做了，但需求触发场景没说清。客户不为「好东西」付费，只为「解决我现在的痛」付费。
对抗：报价单里必须有一栏**「适用场景」**——「你的系统刚上线要过安全合规」「你要给投资人演示 AI 能力」。把产品锚定到客户的触发事件上（呼应第21章「从接单中发现需求」）。
红线边界：不可让渡的决策
- 交付物定义：即便用 AI 生成报告，交付物「包含什么 / 不包含什么」必须人定。
- 评估指标口径：用哪套指标、目标值多少，必须人定，不能让 AI 自评分（AI 自评必然虚高）。
- 报价与边界：定价、套餐边界、加项单价，必须人定。这三件事交给 AI，等于把方向盘交出去。
22.8 小结 / 核心心法
技术能力不值钱，能力变成的确定结果才值钱。产品化就是把「我会」翻译成「你能买到、能验收、能复购」。
- 产品化 = 交付物 + 评估指标 + 报价梯度，三者缺一即不是产品。
- 交付物要可交付、可演示、可归档；评估指标要可量化、可复现、业内认；报价梯度要有锚点、有梯度、有边界。
- 产品化是公式二「交付闭环」的「范围 / 验证 / 验收」三环一次性钉死，也是公式三「复利资产」——报告模板、评测集、报价单做一次用 N 次。
- 客户买结果，不买过程：把技术深度藏进附录，把结论数字摆上首页。
- 能力产品化是「能力 → 工作流 → 工具」递进链的起点，第23章讲怎么从工具扩成一类产品。
执行清单（每次产品化前自检）：
- [ ] 交付物是否满足「可交付 / 可演示 / 可归档」三可？
- [ ] 评估指标是否有「固定评测集 + 固定脚本」跑出固定数字？
- [ ] 评估指标用的是业内口径，还是自造词？（自造词一律打回）
- [ ] 报价梯度是否有 3 档，且每档写清「包含 / 不包含」？
- [ ] 是否有最便宜那档做流量入口？
- [ ] 交付物首页是否「结论先行」，5 分钟能看懂？
- [ ] 报价单是否标明「适用场景」，让客户知道何时该买？
- [ ] 产品化产出（模板 / 评测集 / 报价单）是否沉淀为可复用资产？
上一章：第21章 案例：从接单中发现需求 下一章：第23章 案例：从一个工具到一类产品