Chrysalid上个季度经营分析会，销售负责人说“本季度业绩增长23%”，供应链说“库存周转恶化、爆仓预警”，财务说“经营性现金流已经连续两个月为负”。三个人面对同一套业务系统，讲出了三个完全不同的企业状态。老板最后憋出一句话：“我就想知道，我们公司现在到底怎么样？”
这句话我记了很久。作为数字化负责人，那一刻我意识到：问题不是数据不够，而是数据被割裂在各部门的语言体系里。销售看的是合同金额口径，供应链看的是SKU和库龄，财务看的是权责发生制，三套口径之间没有人给老板翻译成统一的企业叙事。传统BI项目我也做过，报表、大屏、数据中台都上过，但老板的问题是无穷尽的——他每次追问，背后都是一条新的取数逻辑。
后来我转向AI Agent应用，接触到了Skill这个形态。Skill本质上是一份“可复用能力包”，把意图理解、工具调用、业务规则打包在一起，让大模型在特定场景里干专业活。我最终做的这个Skill叫THS，全称Total Holistic Sight，直译就是“全维视野”，目标很朴素：让管理层用一句自然语言，就能拿到企业各维度真实、可交叉验证的数据答案，而不用再等IT排期、翻Excel、开无数个系统权限。
这篇不是讲理论，而是把THS从立项、设计、开发、踩坑到落地的完整过程复盘一遍。如果你正在做企业数据分析、Agent场景落地，或者自己在折腾Skill开发，这篇文章应该能帮你省掉不少弯路，尤其是我在上线期踩过的那几个坑，网上很少有人说清楚。
1. 老板在会议上的那句话，让我决定做THS
先交代一个背景。我们公司规模算中型，有ERP、CRM、MES、HR SaaS、费控系统，五套核心业务系统，每套都来自不同厂商，数据库类型不同，业务含义也不同。过去两年我带着不到十个人的数据团队，陆续做了数据仓库、AutoBI报表平台、移动端管理看板，该上的基础也都上了。
可问题依然存在。表面看是“数据孤岛”，本质上其实是“口径孤岛”。CRM里存的“成交金额”是含税合同额，ERP里出库确认的“销售收入”是不含税净额，两者在月度对账时永远对不上；供应链算的“库存周转天数”和财务算的这同一个指标，算法完全不一样，结论能差出两倍多。
老板不关心底层口径，他想要的是“同一家企业，在不同视角下到底表现如何，差距在哪，机会在哪”。这不是一张固定报表能回答的，更不是大屏上几个跳动的数字能回答的，而是一个能随问题逐层下钻、随时换视角的对话式分析能力。
1.1 数据孤岛的真相：不是技术问题，是口径问题
很多人一谈数据孤岛就想到数据库不通、API没接好、网络隔离，这些确实是障碍，但真正让数据“没法用”的，是业务语义没有被统一。ERP说“客户A本月回款500万”，销售系统说“客户A本月开票700万”，财务说“客户A本月确认收入800万”，三个数都对，但问你“客户A这个月贡献了多少”，没有一个人敢拍板说哪个是标准答案。
所以在设计THS的时候，我给自己定了第一条硬规矩：先统一口径，再谈技术连接。技术手段再强，比如能打通所有数据库，但如果口径不统一，Agent给出再流畅的回答也是错的。
1.2 为什么是Skill而不是中台或BI
在THS立项前，团队内部有过争论，是否应该继续采购一套数据中台或者升级高级BI工具。我的判断是：不能走老路。
传统数据中台的思路是“先把数据都搬到一个湖里再说”，这个项目动不动就是半年周期，投入大、见效慢，更麻烦的是业务部门的需求根本等不起。传统BI的思路是“把常见问题固化成看板”，但管理层的提问天然是发散式的，看板永远跟不上问题。
Skill的思路完全不一样。它不要求把数据搬在一起，而是把“理解数据语义、调用数据接口、组织分析叙事”这套能力，做成一个可以被大模型加载的知识包。Skill可以插在对话式Agent后面，也可以接入内部助手，甚至放到Claude Code、Codex这类编码Agent的工作流里，让数据能力跟着场景走。
说白了，之前的方案是“把数据推到人面前”，THS是“让数据围绕问题主动组合”。这个理念上的差异，决定了后面的整个架构设计。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. THS的逻辑结构：把“全维度”变成Agent可执行的上下文
很多刚接触Skill的人有个误区，以为Skill就是给大模型写一段提示词，让它“用自然语言回答问题”。真做起来你会发现，提示词只是最表层的东西，Skill要真正在企业数据场景里可用，必须解决三个问题：怎么识别用户要什么、怎么取到正确的数据、怎么把数据讲成人话。
THS因此设计成三层结构，每一层的职责都尽量单一，这也是我在多次试验后固定的框架。
2.1 三层结构：意图识别、数据映射、交付表达
第一层意图识别层。用户的提问通常很口语化，老板问“本月情况怎么样”，如果不做拆解，模型根本不知道该返回什么。THS的做法是维护一个“问题模板库”，将常见管理问题归类为“经营概览”“专项分析”“趋势判断”“异常排查”四类。模型先判断用户的问题属于哪一类，再决定下一步执行路径。
第二层数据映射层。这是THS的核心，也是让Agent不至于乱取数的关键。它维护一张“指标-数据源-取数逻辑”对照表，指标是中性的，比如“营业收入”“存货周转天数”“销售人员人均产出”，每个指标背后都绑定唯一的取数接口和计算口径。模型在意图识别后，把所有涉及到的指标翻译成结构化的查询参数，交给数据桥接层去执行。
第三层交付表达层。同样是“这个月销售额下降了”，给CFO和给销售总监的答案侧重点完全不同。THS会根据提问者的角色、问题的上下文，选择不同的输出模板，可能是“一句话结论+指标卡”，可能是“经营周报式分段叙述”，也可能是“趋势图表+异常归因”，避免所有回答都长成同一个样子。
2.2 指标注册中心：全维度的前提是口径唯一
“全维度”这个词说出来很轻松，做起来必须落到具体指标上。THS目前的指标注册中心一共收录了187个指标，分布在财务、销售、供应链、生产、人力、客服六个域。每个指标都有一段结构化描述，不是写给人看的，是写给模型看的。
我拿一个真实例子来解释这个设计的重要性。“库存周转天数”这个指标，供应链部门算的是“月均库存 / 当月销售成本 × 30”，财务部算的是“期末库存 / 当期营业成本 × 360”，分母和期间都不同，算出来的结果能相差一倍多。如果不把这些算法差异写死在指标库里，模型每次调用接口时都靠“临场发挥”，结果一定是不稳定的。
THS把每个指标的定义、公式、取数字段、数据来源、更新时间、权限级别、适用场景全部固化下来。模型不负责“自己算数”，它只负责把用户的自然语言翻译成“指标+维度+时间范围”，再交给经过验证的计算逻辑去处理。这样一来，准确率就摆脱了对模型推理能力的依赖，变成了对“规则执行质量”的依赖，稳定性高很多。
2.3 输出模板：管理层能直接看，而不是能跑
技术型的人做数据产品，经常犯一个毛病：把系统做得很“能跑”，但业务方看完一头雾水。THS在交付表达层上做了很多打磨，核心原则只有一条——答案的第一屏必须是结论。
比如老板问“华南区这个月为什么销售额下滑”，THS的输出不是先扔出一大堆表格，而是先给出一句话：“华南区本月销售额环比下降18%，主要原因是两个大客户订单延期交付，影响金额约3200万元，占总缺口的61%。”然后才是表格细节。这个“先结论后明细”的格式，是我让团队把过去半年的经营分析报告拆开学习后总结出来的，效果比之前任何一种输出方式都好。
3. 开发实录：SKILL.md和数据桥接是Skill的两个地基
有了架构，真正动手开发时，我发现最花时间的不是模型提示词，而是两个容易被忽略的文件：SKILL.md和数据桥接层。前者决定了Agent能不能稳定理解任务边界，后者决定了它能不能拿到真实数据。这两个阶段踩的坑最多，也最值得分享。
3.1 SKILL.md：给Agent写的岗位说明书
现在主流的Skill规范里，SKILL.md都承担着“岗位说明书”的角色，它告诉Agent：这个Skill是干什么的、在什么场景下触发、有哪些边界、可以调用哪些工具、有哪些红线。我在这一版THS的SKILL.md里，写了将近四十条规则，这里展示最核心的骨架部分：
yaml复制name: ths
description: 面向企业管理层的企业全维度数据查询与解读。
当用户询问经营数据、财务指标、销售情况、库存周转、人力效能等
跨部门数据时使用。不得用于非数据类问答。
version: 0.4.2
triggers:
- 经营情况
- 销售/营收/利润
- 库存/供应链
- 人力/编制/人效
- 财务/现金流/成本
variables:
- company_id: "当前用户所属企业ID，必须从会话上下文中获取"
- user_role: "决定数据可见范围，如executive/finance/sales/ops"
tools:
- ths_metric_query
- ths_dimension_drill
- ths_report_pull
- ths_anomaly_explain
rules:
- "用户询问利润时，必须区分归母净利润、营业利润和毛利，不允许模糊回答"
- "任何对比必须明确基期，同比、环比、预算比要显式说明"
- "涉及人员、薪酬类数据，必须先校验user_role的权限级别"
- "如果指标库存中没有对应口径，必须明确告知用户'暂不支持该口径'，禁止自行编造"
写SKILL.md的心得是：规则宁多勿少，边界宁窄勿宽。与其让模型在模糊指令下自由发挥，不如把它限制在能保证质量的范围内。THS上线前反复调整的就是这些规则条目的顺序和权重，因为模型在长上下文里往往更关注靠前的指令，所以我把“口径必须唯一”这条排到了最前面。
3.2 数据桥接层：一套规范接住二十个系统
Skill里的工具定义可以很优雅，但落到真正的企业环境，就要面对现实：ERP只支持WebService接口，CRM用的是REST API，MES的数据放在Oracle里，HR系统只能导出CSV。如果让Agent直接连这些原始接口，光是鉴权方式不同就能折磨死人。
THS的做法是在中间做了一层“数据桥接服务”，对外暴露统一的接口规范，对内去适配各系统的差异。核心接口实际设计得并不复杂，比如指标查询就一个方法：
python复制def ths_metric_query(
company_id: str,
metric_code: str,
start_date: str,
end_date: str,
period: str = "day",
compare_base: str | None = None,
dimension: list[str] | None = None,
filters: dict | None = None,
) -> dict:
"""
指标查询统一入口。
metric_code 来自指标注册中心，禁止接收模型自创的指标名。
compare_base 可选值：mom（环比）、yoy（同比）、budget（预算比）。
"""
# 1. 从指标注册中心读取口径定义
metric_def = metric_registry.get(metric_code)
if not metric_def:
return {"success": False, "message": "指标不存在，请检查metric_code"}
# 2. 根据指标定义选择对应的数据适配器
adapter = adapter_factory.get(metric_def["source"])
# 3. 执行适配器专属的取数逻辑
raw_data = adapter.query(
company_id=company_id,
fields=metric_def["fields"],
period=period,
date_range=(start_date, end_date),
)
# 4. 按metric_def中的公式计算指标值
result = metric_def["formula"].calculate(raw_data)
# 5. 如果需要对比，再取一次对比基期数据
if compare_base:
base_result = ...
return format_response(result)
这套桥接层最大的价值是：把“取数”的复杂度屏蔽在模型之外。模型的智商不应该浪费在思考“数据从哪个系统来”上，它只需要知道指标代码、时间范围、对比方式，其余交给桥接层。另外，所有对底层系统的调用都有超时限制和熔断机制，防止某个系统慢查询拖垮整个Agent响应。
3.3 测试问题集：用十个业务问题完成定型
Skill开发到一定阶段，最容易出现的问题就是“演示环境一切正常，真实场景一用就翻车”。我让团队整理了一份包含十个典型问题的验收测试集，每次改动都跑一遍。这份测试集不是简单看回答流畅度，而是逐项打分，包括数据正确性、口径一致性、输出可读性、响应时间四个维度。
测试集里光“销售情况”这一个问题就写了六个变体：“本月销售怎么样”“本月销售收入是多少”“和上月比销售变化”“为什么这个月销售差了”“哪个区域拖了后腿”“下个月按趋势能完成目标吗”。同一指标，不同问法，模型必须能识别出背后的不同意图，有的需要横向对比，有的需要归因分析，有的需要预测。这个测试集成了THS的守门员，后面每次修改SKILL.md、调整提示词、增加新接口，都在它跑完后才算合格。
4. 上线期排障实录：权限、缓存、上下文预算三座山
如果说开发和内部测试阶段还能靠“小团队默契”掩盖问题，那么上线给几十个管理层用户用，问题就藏不住了。THS上线第一周，我先后撞上了三个坑，每一个都值得单独说。
4.1 权限越权：Skill能取到的数据不等于用户该看到的
第一次内部灰度，就有业务线负责人反馈：他问“全公司各事业部利润排行”，系统居然返回了其他事业部的明细数据。技术上，接口明明带了user_role参数，但问题出在“模型不可靠”上——它偶尔会在组装查询参数时漏传权限字段，或者干脆把role写成默认的executive。
我的解决思路是双保险：第一，桥接层里强制校验用户身份，不依赖模型传参，而是从会话上下文中的服务端令牌解析出当前用户和角色；第二，在返回结果层面做数据脱敏，凡是超出角色权限的字段直接替换为空或脱敏值。这样才能保证即使模型在意图理解上出了偏差，数据也出不了权限边界。
这里面还有个容易被忽略的点：权限校验的位置必须在桥接服务端做，不能在Skill提示词里做。因为提示词只是“建议”，模型可能忽略，服务端代码才是强制约束。
4.2 接口雪崩：连问四十次之后，Oracle侧先扛不住了
某天下班前，一位高管用THS连续追问了四十多个问题，而且每个问题都触发了底层ERP数据库的实时查询，结果ERP系统出现大量慢SQL，影响了业务部门正常操作。这个事故让我意识到：尽管THS口头上“不给底层系统增压”，但如果没有有效的缓存策略，它在真实使用中照样能压垮系统。
现在的方案是三级缓存：最常用的指标缓存到Redis，TTL设五分钟，key包含公司ID、指标代码、时间范围、维度组合；周期性报表结果落到ClickHouse里的物化视图，每天早上定时刷新；只有真正的异常排查类查询才会穿透到业务系统实时取数。三层缓存上线后，ERP侧的压力下降了90%，THS响应时间反而更快了。
4.3 上下文失控：一份周报吃掉20万token的教训
第三个坑来自很多人会忽视的上下文预算。最开始THS回答经营概览类问题时，习惯把所有指标明细都输出，动辄几千行的Markdown表格，直接把一次对话的上下文撑爆，用户接着问第二个问题时，模型已经开始丢三落四。
我后来定了一条输出规范：任何回答里的明细行数不得超过三十行，超过部分按“核心结论+前五明细+聚合汇总”的结构输出。每周经营分析这类本来就偏长的报告，单独走ths_report_pull工具，生成结构化文档后以附件方式提供，不占对话窗口。这个调整以后，一次多轮问答的平均token消耗从约11万降到了2万出头，模型理解和回答的连贯性也明显回升。
这三座山翻过去之后，THS才算真正有了“敢给管理层用”的底气。
5. 运行两个月的复盘与下一步演进
THS从上线到现在运行了两个多月，我这边有一些真实数字可以分享。月活用户覆盖了约70%的部门负责人及以上层级，累计调用3600多次，平均每个工作日六十多次。最容易触发的高频问题是“本月经营情况概览”，其次是销售波动归因和库存健康度检查，这说明管理层最需要的不是单点指标，而是“先看全貌，再追细节”的能力。
从回答质量看，这里我给自己打一个比较客观的分：口径完全正确、可以直接采纳的回答占了约82%；需要人工更正少量数据的占13%；完全错误的占5%，主要集中在三个月以上的长周期归因问题上。这个水平离“完全替代分析师”还有距离，但已经足够让管理层在提问后的三分钟内形成初步判断，整个决策讨论的速度明显变快了。
除了数据准确率，我更在意的是用户行为的变化。过去管理层拿到月度报告后很少主动追问，因为知道要等IT排期；现在他们在日常周会上就会打开THS现场查数，甚至在一个问题上反复下钻，从“全公司营收”一路钻到“某区域的A类客户回款”。这种追问习惯的形成，是我认为THS真正撬动的东西——它把数据分析从“项目交付物”变成了“管理者的思考习惯”。
下一步我计划的演进方向有三个：一是把THS接进经营分析会的自动会前准备流程，会前自动生成绩效预警简报，把“人找数据”变成“数据找人”；二是支持更多非结构化数据源，比如把销售会议纪要和客服录音转写文本也纳入分析范围，做业务归因时能结合一线信息，而不只是看财务数字；三是把THS的能力开放给行业内的数据分析团队，让大家能基于自己的指标体系快速生成专属Skill，而不是每家都从零开发一遍。
如果你也在做类似的Skill，我唯一的建议是：先把企业的指标体系梳理清楚，再谈技术。Skill的代码和规范都可以快速迭代，但口径错了，所有建立在它上面的回答都会跟着错，那时再回头改成本就高了。这也是THS给到我个人最大的一个教训。