把模型接到数仓，不会自动得到稳定的分析师。它还需要知道团队怎样检查数据、如何建模、什么图适合表达结论，以及交付前必须做哪些复核。
Anthropic 将 Skill 定义为包含指令、脚本和资源的文件夹，相关时才加载所需内容。这个设计把“每次重新解释工作方法”变成可版本化的工作协议，也允许在需要确定性的环节执行代码。
Skill 封装的是方法，不是知识幻觉
指令可以规定步骤和边界；脚本可以承担清洗、计算或格式转换；模板与参考材料可以约束最终制品。三者组合后，同一套方法可用于表格、文档、演示和 PDF 等不同交付面。
但 Skill 不会凭空补齐企业指标定义和权限。分析类 Skill 仍需显式接入数据语义、来源优先级、允许调用的工具，以及谁负责最终批准。
为什么比一次性提示词更容易治理
Skill 可以进入版本控制，变更能审阅，测试任务能回归，组织也能分发经过批准的版本。它把模型行为的一部分从隐藏对话移到可检查文件中。
代价是新的供应链风险：Skill 可能包含可执行代码，也可能引导模型访问文件和连接器。Anthropic 官方同样建议只使用可信来源。企业至少需要来源审查、最小权限、隔离执行、依赖固定和制品扫描。
分析 Skill 的合理分层
一个成熟工作流通常分成六段：理解用户任务、加载方法指令、取得必要文件与工具、执行可重复计算、生成制品、进行内容与视觉验收。封面图中的每个区块都对应一个可测试的责任，而不是一句抽象的“做分析”。
适合怎么落地
先挑一个高频、边界清楚的交付，例如周度经营复盘。把输入契约、指标口径、异常处理、图表规范和验收清单写进 Skill；将真实历史任务做成回归集；让分析师审阅失败类型，而不是只看平均满意度。
Skills 最有价值的地方，不是给模型增加更多身份，而是把专家经验变成可以维护、组合和验证的工作流。
验收应覆盖过程与制品
分析 Skill 的测试不能只问“有没有生成文件”。过程层要检查输入数据是否完整、公式是否可追溯、异常是否被记录；制品层要检查表格公式、图表尺度、标题结论和移动端可读性。对同一批历史任务做版本回归，才能知道新指令是改进了方法，还是只让输出更像模板。
企业还需要明确失败策略：缺少关键字段时停止并说明，还是用替代口径继续；脚本报错后允许重试几次；生成的文件在发送前由谁批准。把这些边界写进 Skill，才算把经验工程化，而不是把一段更长的提示词放进文件夹。
维护时还应把方法更新与模型更新分开评估。模型升级可能改善推理，却也可能改变工具选择和制品风格；Skill 版本变化则会直接改变步骤与验收。分别固定变量做回归，才能知道质量变化来自哪里。