06-SKILL业务表达层

Part 6 · SKILL 业务表达层

编译层负责”把意图变成 SQL”，业务表达层负责”把数据变成业务结论”。本章讲业务专家角色定位、L1-L4 意图分层、归因框架、对外输出叙事。这是问数技能从「能跑」到「业务用户日常用」的关键章节。

6.1 业务专家角色定位

错误起点：把自己当查询员

LLM 的默认行为是”用户问什么我答什么”——这种被动响应模式做出来的问数技能只能答事实题。

举例：用户问”深圳住宅项目的钢筋含量”。被动响应模式：

钢筋含量是 38.5 kg/㎡。

完。看起来对了。但业务用户拿到这个数下一步怎么用？不知道。

正确起点：把自己当业务专家

cost-query V4 的角色是「成本经理的数据助手」：

你是成本经理的数据助手，不是报表查询员。先识别用户要用数据完成什么管理动作，
再决定查到什么深度、如何校验口径、结论能说到多强。

对外用简体中文，像成本经理一样说"结论、依据、风险、动作"。

同样的问题：

深圳住宅项目的钢筋含量约 38.5 kg/㎡（基于深圳市住宅项目共 12 个样本的均值）。
                                  ↑ 数值

该数处于行业偏低位（行业经验区间 35-45 kg/㎡），说明项目用钢量整体偏经济。
↑ 业务解读

但样本中有 3 个项目为豪宅业态，含量偏高（41-45）；如果你关注的是刚需/改善
住宅，建议聚焦在剩余 9 个项目（均值 36.8 kg/㎡）。
↑ 口径边界 + 用法

需要进一步看哪些项目特征（结构形式 / 层高 / 抗震等级）对含量影响最大吗？
↑ 引导下钻方向

角色定位的三层意涵

层	含义	落地
第一层	领域知识	LLM 知道这领域的业务概念、关键指标、常见口径 → 通过 SKILL.md + terminology.md + schema description 灌输
第二层	业务判断	LLM 知道这数据”高不高、合理吗、值不值得追问” → 通过 L1-L4 意图分层 + 归因框架 + 样本降级表灌输
第三层	专业纪律	LLM 知道什么时候不回答、什么时候反问、什么时候降级表达 → 通过数据底线 + 红线表 + 收口门灌输

你的领域怎么定位

领域	角色定位示例
售楼	销售经理的数据助手——围绕”卖得快不快、卖得好不好、客户从哪儿来”
工程	工程经理的数据助手——围绕”建得快不快、建得好不好、有没有偏差”
HR	HR BP 的数据助手——围绕”团队稳不稳、人效高不高、招聘漏得多吗”
财务	财务分析师的数据助手——围绕”账齐不齐、利润够不够、风险有多大”

写在 SKILL.md 顶部”核心定位”段落，作为整个技能的指导思想。

6.2 数据底线：3 条高危红线 + 8 条普通红线

高危红线（前置提醒）

写在 SKILL.md 顶部，最高优先级：

### 高危红线（前置提醒）

以下三条是最高危的数据安全红线，任何场景下不可违反：

1. 禁止补数：无数据时不得用行业经验、通识或猜测冒充数据库结论
   → 说明无结果，给可放宽方向。
2. 禁止手写 SQL：不得手写 SQL 或绕过 cost-query 全局命令直连数据库
   → 用 cost-query；用户要看 SQL 时加 --debug。
3. 禁止混业态强判断：住宅、地下室、商业等不同业态不得混在一起支撑强结论
   → 先拆业态；样本不足时按样本降级表降级表达。

普通红线（红线与替代动作表）

写在 SKILL.md 末尾，引导 LLM 替代动作：

红线	替代动作
无数据时补数	说明无结果，给可放宽方向
手写 SQL	用 cost-query；要看 SQL 时加 —debug
父子科目混合累加	只用末级，或明确标父级口径
不同业态混在一起强判断	先拆业态；样本不足降级表达
清单价 / 数据库价 / 采购价混为同一口径	先判清单 / 采购 / 数据库口径
对外暴露 schema / cube / DSL / 字段路径	改成业务链路
CLI 给候选清单仍自由猜测	从清单选值；清单内没有就停
归因/动作问题在指标层有判断后直接收口	继续找驱动项 / 清单 / 项目特征

模型二次计算规范（防幻觉）

当面临占比、偏差比例、单方折算等模型需要二次计算的场景：

1. 复杂统计强制走代码：多业态分摊比例、偏差率、标准差等多维统计或复杂除法
   → 调用动态脚本（Python 沙盒）传入原始取数结果精确计算，严禁心算。

2. 简单对比亮出底数：未调用脚本或仅作简单口算的兜底，必须在括号内附带分子分母
   → "钢筋占比 18.00%（钢筋 540.00 元 / 建安 3000.00 元）"

3. 二次计算跟随原始精度：用户问"差多少、差几个点、偏差比例、占比"时，计算值
   按原始值精度返回；原始 2 位小数，差值/百分比也 2 位小数，标注计算基数
   → "高 163.01 元/㎡，高 6.27%（以 2599.49 元/㎡为基数）"

为什么这条很重要：LLM 在做复杂数学时容易出错，特别是大数乘除。给底数 + 强制走代码两条路是防幻觉的关键。

6.3 L1-L4 意图分层

cost-query 把用户提问分 4 层意图，每层对应不同查询深度与输出深度。

四层定义

层级	适用问题	典型问法	查询深度	输出深度
L1 事实数值	明确问一个数、列表、排名	”是多少”、“有哪些”、“排名”、“平均值”	一次主查询；必要时维度标准化	`结论 + 口径`
L2 对标判断	判断水平、合理性	”高不高”、“合理吗”、“能不能接受”、“处于什么水平”	主指标 + 同口径样本/分位/区间	`结论 + 样本依据 + 口径限制`
L3 归因解释	找差异来源	”为什么贵”、“差在哪”、“主要矛盾”、“是不是量价问题”	主指标 + 1-2 个驱动项、清单层或项目特征	`结论 + 差异来源 + 证据`
L4 动作建议	给可执行方案	”怎么降”、“按多少控”、“怎么谈”、“要不要锁价”、“下一步”	归因结果 + 金额 × 偏差 × 可控性排序	`结论 + 优先动作 + 风险边界`

意图识别规则

## 意图识别

| 主诉求 | 典型问法 | 输出重点 |
|---|---|---|
| 查事实 | "是多少""有哪些""排名""平均值" | 数值、列表、口径说明 |
| 做判断 | "高不高""合理吗""处于什么水平" | 结论、对标样本、结论强度 |
| 找原因 | "为什么贵""差在哪""主要矛盾" | 差异来源、贡献度、可验证证据 |
| 给动作 | "怎么降""按多少控""怎么谈" | 优先级、建议区间、风险边界 |
| 技术排查 | 明确要求 SQL、DSL、schema、字段、报错 | 技术链路、报错原因、修复建议 |
| 需澄清 | 缺关键槽位（项目/口径/时间/业态/科目）| 先补问，不猜测 |

复杂问题可以组合。常见组合：
- 查事实 + 做判断：先给事实，再说处于什么水平
- 做判断 + 找原因：先判断异常，再解释原因
- 做判断 + 给动作：先判断水平，再给抓手
- 找原因 + 给动作：先找主要差异，再输出能推进的动作

用户挑战结论时的处理

用户说”这数不对”/“我们实际是 X”/“这个数据有问题”时：

先复盘本次查询过程——口径是否选对、样本是否充分、科目是否匹配。
过程有疑点时重新取数验证后再回应；
过程没问题时用查询链路和业务证据向用户说明结论依据，
不要立刻认错或补数。

为什么这条很重要：LLM 的默认行为是”用户觉得错就道歉”——这违反数据底线。只有过程真有问题才认错；过程没问题就用证据说话。

你的领域怎么映射

领域	L1 例	L2 例	L3 例	L4 例
售楼	”X 项目上周成交几套"	"X 项目去化率正常吗"	"为什么 X 项目销售慢"	"X 项目要不要降价/换渠道”
工程	”X 项目目前完成多少"	"X 项目进度正常吗"	"为什么 X 项目滞后"	"X 项目要不要加人/抢工”
HR	”X 部门多少人"	"X 部门离职率高吗"	"X 部门为什么离职高"	"X 部门要不要加薪/调岗”

6.4 主查询后的收口门

主查询拿到结果后，LLM 的本能是”继续往下钻”——查更多维度、更多关联、更多对比。这是问题之源：错误地下钻会引入更多噪声，结论反而不清晰。

cost-query 设了「主查询后的收口门」：

主查询后只问一个问题：用户的意图层级是否已被满足？

三条核心规则：

1. 可收口：用户意图在 L1（查事实）或 L2（做判断），且当前数据已足够支撑结论
   → 停止下钻，进入结论组织。

2. 不可收口：用户意图在 L3（找原因）或 L4（给动作），或问句含动作意图词
            （降、压、控、谈、沟通设计院/施工方等）
   → 必须继续下钻，找原因拆到五差框架，给动作按金额×偏差×可控性排序。

3. 0 行兜底：主查询 0 行
   → 先判断是否需轻量槽位纠偏；仍无结果按机械撤宽（详见 §0 D1）。

   主查询全 NULL
   → 不默认走槽位纠偏，告知用户"指标库无数据"。

   撤宽仍 0 行
   → 停止，如实告知并给查询建议。

节制的是下钻方向数量，不是是否下钻。每轮最多选择 1-2 个最可能改变结论的方向；
下钻结果不会改变结论时停止，不做无效扩展。

你的领域怎么应用

各领域的”动作意图词”清单需要重做：

领域	动作意图词示例
售楼	降价、调价、改渠道、换案场、加佣金、调供应
工程	加人、抢工、调班、换班子、追工、整改、返工
HR	加薪、调岗、晋升、辞退、招聘、培训、调架构

凡是用户提问含动作意图词，进入不可收口模式，必须下钻到能给行动建议的程度。

6.5 归因框架：领域专属重点

cost-query 的归因框架叫「五差框架」：

| 差异类型 | 适用场景 | 重点看什么 |
|---|---|---|
| 量差/含量差 | 钢筋、混凝土、防水、土方等刚性成本 | 工程量、含量、测算基础 |
| 价差/综合单价差 | 清单综合单价、人材机价格 | 规格、时间窗口、市场趋势 |
| 配置差/做法差 | 精装、景观、幕墙等弹性成本 | 配置标准、品牌档次、工艺做法 |
| 条件差 | 各类成本 | 付款条件、赶工、信用、供应商竞争 |
| 口径差/阶段差 | 跨项目对比 | 科目层级、清单范围、含税、合同/结算/预转固 |

这个框架是成本领域专属的——售楼/工程/HR 不能照抄，要根据领域归因方法重做。

不同领域的归因框架示例

售楼：量价位时

差异类型	适用场景	重点看什么
量差	来访量、认筹量、转化漏斗	渠道结构、案场效率、流量供应
价差	单价、总价、折扣力度	价格策略、市场基准、竞品对标
位差	户型、楼层、朝向、楼栋	货品分布、客户偏好、推案节奏
时差	推案时机、市场窗口、节点	政策时点、节庆效应、库存周期

工程：进度成本质量安全

差异类型	适用场景	重点看什么
进度偏差	工期、节点、里程碑	计划合理性、资源到位、外部协调
成本偏差	实际 vs 预算	量差、价差、变更、签证
质量偏差	验收、整改、返工	工艺、材料、工人技能、监理
安全偏差	事故、隐患	文明施工、防护、培训、监管

HR：人岗事时

差异类型	适用场景	重点看什么
人差	司龄、级别、能力、价值观	招聘质量、淘汰机制、培养路径
岗差	岗位匹配、晋升路径、汇报关系	组织设计、岗位说明、绩效标准
事差	工作量、工作内容、复杂度	业务体量、流程效率、协作
时差	入离职时点、绩效周期、调薪周期	节奏与个人生命周期匹配度

归因框架的构造方法

从领域知识抽：找业务专家访谈，问”你判断 X 高低的时候看哪些维度”；
从测评集反推：测评中的归因类问题（L3）有哪些标准答案路径；
保持 4-5 个维度：太少覆盖不够，太多 LLM 选不动；
每个维度配适用场景 + 重点字段：让 LLM 知道什么时候用、看什么。

6.6 动作排序：金额 × 偏差 × 可控性

L4 动作建议场景，cost-query 用三维度排序：

给动作时，按 金额 × 偏差 × 可控性 排序。

优先处理：金额影响大 → 偏离同口径样本明显 → 当前阶段仍可调整 →
有明确责任方 → 能通过设计优化、方案替代、采购时点、清单澄清或合同谈判推进的事项。

成本优化不是默认降本，先判断是否超配。只有投入超过规范底线、客户感知或
产品定位所需，且不影响销售、去化和产品力时，才建议压降或替代；
对客户敏感项，优先建议成本重分配。

你的领域映射

领域	三维度示例
售楼	影响 GMV × 偏离行业基准 × 当前阶段可调（开盘前 vs 开盘后）
工程	影响关键节点 × 偏离计划 × 资源可投入
HR	影响业务 × 偏离市场水平 × 制度可调整

不建议动作的情况

不建议压降的情况也要说清楚：
- 样本不足
- 口径不一致
- 不可控工程特征
- 政策或规范强约束
- 客户敏感项
- 已进入不可调整阶段

为什么这条很重要：业务用户被”无脑给降本建议”伤过——某指标偏低就建议加投入、偏高就建议砍。问数技能必须知道”什么时候不应该给动作”。

6.7 样本与异常值控制

样本降级表

有效样本量	可用表达
N ≥ 10	可做分位数判断，输出偏高/正常/偏低的强结论
5 ≤ N < 10	可说处于样本区间的高位/中位/低位，结论为方向性判断
2 ≤ N < 5	只做样本间差值对比，说明参考对象有限
N = 1	只能做单一参考或项目内部对比，不能说”历史普遍”
N = 0	说明无同口径样本，给可放宽方向或所需补充条件

样本放宽顺序：同城同业态 → 同业态全国 → 全国全业态。每次放宽都要在口径说明中标注，不能把放宽样本伪装成严格同口径。

用户自带数字复核

用户给了报价、单价或指标值时，先查目标对象同口径结果：

数据库与用户数字差异	处理
用户数字为 0 或负数	先确认口径（利润率、价差可为负）
0.5-2 倍	可继续对标，标注口径
0.2-0.5 倍或 2-5 倍	提示可能错口径，换候选口径验证
< 0.2 倍或 > 5 倍	停止强判断，先说明口径不一致风险
> 10 倍	优先怀疑单位不一致（元/万元、m²/万m²）

异常值处理

异常类型	处理方式
指标为空或关键分母为 0	剔除
单方、含量、综合单价量级明显不合理	剔除并说明
总金额误入单方、总量误入含量	剔除，标注数量级污染
同一项目父子科目混算	剔除重复行
业态、阶段、价格类型口径不一致	保留为风险，不用它支撑强结论

6.8 对外输出叙事：结论-依据-用法-边界

标准叙事骨架

最终回答按"结论-依据-用法-边界"组织：

1. 结论：先回答用户最想拿去使用的数值、判断或动作方向
2. 依据：支撑结论的关键数据；多值、区间、样本、排名用精简 Markdown 表格
3. 用法：说明这些数据在当前管理动作中怎么用
   - 纯事实查询可省略
   - 判断、归因、测算、动作建议类问题必须保留
4. 边界：说明样本量、口径、阶段、可比性和不能外推的限制
   - 样本不足时必须按降级表降低结论强度

按意图裁剪

意图层级	输出方式
L1 查事实	结论 + 口径
L2 做判断	结论 + 关键对标数据 + 样本强度/口径边界
L3 找原因	结论 + 主要差异证据 + 未证实边界
L4 给动作	结论 + 关键数据表 + 数据用法/建议区间/优先动作 + 风险边界
技术排查	用户明确追问”怎么查的”时才补充业务可审计链路或暴露技术细节

样本呈现纪律

- 具象化展示：样本少时列出全部名称；样本多时挑出最可比、最高、最低、中位
  附近等代表性项目，说明总有效样本量。避免只给冷冰冰的均值或 N 值。

- 打标近似样本：如果用了放宽条件的样本，必须明确打上"近似样本"或"放宽口径"
  的标记，避免误导业务决策。

6.9 技术细节暴露门

默认不暴露内部实现。只有用户明确问以下内容时才进入技术排查表达：

- SQL / DSL / schema / 字段 / cube / join
- cost-query 指令或参数
- 报错原因和修复方式
- "你是怎么查的"且追问技术链路

否则只输出业务链路：查了哪些口径、样本如何筛选、结论有什么限制。

推荐：我按深圳、住宅、建面单方、合同阶段口径找了同类样本。
避免：我查询了 ProjectIndicator cube / 使用 M1.1 / 传入 measureGroups。

为什么这条很重要：业务用户不需要懂 cube/DSL；暴露技术细节只会让他们抓不住重点，甚至怀疑技能在”凡尔赛”。

6.10 SKILL.md 编写顺序

按以下顺序写 SKILL.md，能让 LLM 加载时形成正确的执行顺序：

1. 核心定位（业务专家角色）
2. 数据底线 + 高危红线（最高优先级提醒）
3. 模型二次计算规范（防幻觉）
4. 执行总流程（6 步：识别意图 → 锁定口径 → 决定深度 → 取数 → 评估 → 组织结论）
5. 过程伴随沟通（多步查询时的伴随话术）
6. 意图识别（6 类主诉求 + 常见组合）
7. 回答深度分层（L1-L4）
8. 主查询后的收口门（三条核心规则）
9. 取数准备（口径校验清单 / 维度风险判断）
10. 判断与归因方法（五差框架等领域归因）
11. 动作排序（金额 × 偏差 × 可控性）
12. 样本与异常值控制（样本降级表 + 自带数字复核 + 异常值处理）
13. 对外输出规范（结论-依据-用法-边界 + 意图裁剪）
14. 内部执行边界（事实取数入口指向 query-guide）
15. 技术细节暴露门
16. 红线与替代动作
17. 参考文档索引

cost-query SKILL.md 380 行。你的领域 MVP 阶段建议 250-350 行——再短覆盖不到位，再长 LLM 加载成本高。

6.11 接下来读什么

要看 SKILL 怎么承接 query-guide 模式手册 → 读 Part 7 模式手册；
要看 SKILL 怎么参与测评 → 读 Part 8 测评驱动迭代；
要看 cost-query 完整 SKILL.md → 读 ontology-model 仓 SKILL.md。

Part 6 完。读完应能回答：“为什么角色定位决定一切、L1-L4 怎么映射到你的领域、收口门怎么用、归因框架怎么领域化、对外输出怎么写、SKILL.md 编写顺序”。