要说最近 Claude 生态里什么最热闹，除了 Claude Code 本身，就是“Agent Skill”这套技能机制了。我这两天一直在折腾一个叫Causal Analyst Agent Skill的项目——简单说，这是一个给 Claude 用的技能包，能让它从“会算统计量的聊天窗口”变成“按因果推断流程做分析的 analyst”。不需要重新训练模型，也不需要写一堆临时的系统提示词，装一个文件夹进去，Claude 就能按一套规范的分析流程干活。

这个内容到底解决了什么问题？我自己的体会是：平时想让 Claude 做数据分析，它确实能给你算回归、给结论，但对“因果”这件事非常容易张嘴就来。你问它“促销有没有用”，它可能列一堆相关性数字然后含糊地说“可能有正向影响”。而装了 Causal Analyst Skill 之后，它会强制按“定义问题 → 画因果图 → 选识别策略 → 估计效应 → 做检验”的路径走，每一步都要求你补充业务信息，最后给的不是“相关结论”，而是带前提假设的因果效应判断。这篇文章就围绕这个项目展开，适合两类人看：一是研究 Claude Code 和 Skill 机制的开发者，二是做数据分析、实验评估、想用 AI 辅助决策分析的从业者。我会把 Skill 的目录结构、SKILL.md 的编写方法、安装触发流程、以及调试避坑经验全部拆开讲。

1. 先说清楚：Skill、Agent 和普通 Prompt 的边界

这个话题最近被问烂了，尤其“skill 和 agent 的区别”隔几天就上一次热搜。我在折腾这个项目之前也绕了半天，先把这个基础讲透，后面看代码才顺。

1.1 三者区别速览

我先给一个可以直接抄走的对照，然后再展开解释。

用最直白的话说：普通 Prompt 是你要什么就现场说什么，像你去便利店买瓶水，所有信息都在付款那一刻交换完。Skill 是给 Claude 准备的一套“职业规范 + 工具箱”，平时放在文件夹里睡大觉，遇到对应任务时被唤醒，自动加载工作流和参考资料。Agent 则是能自己决定“该用哪个工具、下一步干什么”的调度者，它可以决定在什么时机调用 Skill。

所以在 Claude Code 的语境里，“Agent Skill”这个名字非常准确：它本质上是一个 Skill，不是 Agent；但它是设计给 Agent 用的技能。Agent 负责判断“当前任务涉及因果推断”，然后决定加载 causal analyst 这个技能包，并按技能包里写好的流程执行。

1.2 “Agent Skill”这个叫法的设计思路

我记得 Anthropic 官方在推 Agent Skills（简称 Skills）的时候给过一个定位：Skills are the building blocks that give Claude capabilities, while agents decide when and how to use them。翻译过来就是：Skill 提供能力，Agent 负责决策。这个因果分析项目取名叫 “Causal analyst agent skill”，其实是在强调它所处的生态位——不是替代 Agent，而是作为 Agent 生态中的专业模块。

我自己做这个项目时最深的感触是：如果你只是想把“因果分析”这件事固化下来，做一个 Skill 是性价比最高的选择。因为 Agent 的自主规划能力会带来不确定性，而因果推断恰恰需要稳定的流程——先定义反事实问题，再画 DAG，然后选估计策略。如果你让模型完全自由发挥，它可能跳过关键步骤直接给你算一个回归系数完事。Skill 的价值就是把这种“确定性”写进文件里，让模型每一次都按方法论走。

2. Causal Analyst Skill 的整体设计：把分析师的工作流装进技能包

2.1 为什么是“因果分析师”，而不是普通数据分析师

先说因果和相关的区别。经典例子我就不重复了，大家都听过冰淇淋销量和溺水人数高度相关但毫无因果关系。现实业务中真正麻烦的是这种：促销活动和销量同期上升，但你没法确定是促销带来的，还是季节因素、同行缺货、甚至只是统计口径变化带来的。普通数据分析师的回答是“销量上升了 30%”，因果分析师必须回答“销量上升中有多少是促销这个干预带来的因果效应”。

这就是我选择做 “causal analyst” 而不是 “data analyst” skill 的根本原因。数据分析师技能告诉模型的是“怎么处理数据、怎么画图、怎么跑回归”，因果分析师技能则要逼着模型去区分相关关系和因果效应，要明确写下“这个估计依赖什么假设”。这类结论直接影响业务决策：你没法把 100 万广告预算砸在一个“只是相关”的指标上。

在实践里，一个合格的因果分析流程涉及的方法包括：潜在结果框架（Rubin causality framework）、有向无环图（DAG）、后门准则、前门准则、工具变量、双重差分（DID）、断点回归（RDD）、倾向得分匹配等。这些内容如果散落在 Prompt 里，模型往往只会挑它最熟悉的一两个方法用。而把它们组织进 Skill 的结构化文档之后，模型会被引导着做方法选型，而不是靠“感觉”挑一个听起来高级的模型。

2.2 核心方法论编排：识别、建模、检验、解释

我在设计这个 Skill 时，把因果分析的工作流拆成了四个阶段，作为 SKILL.md 的主线。这四步不是拍脑袋定的，它对应了因果推断学术圈里比较公认的实证研究流程。

第一步是“识别研究问题”。模型必须和用户一起把“干预变量、结果变量、目标人群”写清楚。很多人在分析里翻车，就是因为在第一步就含糊：你说“促销有没有效”，到底是指促销对“当周销量”的影响，还是对“三个月复购率”的影响？目标不同，分析方法完全不同。

第二步是“构建因果图”。这一步我要求模型先画变量之间的 DAG，把干预变量、结果变量、可观测混淆因子、不可观测混淆因子、中介变量都写出来。画图的目的不是形式主义，而是逼着分析者交代自己的假设——因果推断的所有结论都依赖假设，DAG 是假设的可视化表达。

第三步是“选择识别策略并估计效应”。根据 DAG，模型决定是用回归调整、倾向得分、DID，还是工具变量。每一步都要说明为什么这个策略是这个 DAG 下的合理选择。

第四步是“检验与解释”。包括安慰剂检验、替换样本的稳健性检验、效应量的经济意义解读等。这一步经常被忽略，但恰恰是区分专业分析和平庸分析的试金石。

这个四步流程写进 Skill 之后，Claude 的表现稳定性提升非常明显。即便用户给的数据很粗糙，模型也会按流程追问关键信息，而不是直接编一个结论出来。这也是我认为“方法论编排”比“堆砌工具调用”更重要的原因。

3. Skill 包落地：目录结构、SKILL.md 与 Prompt 编排细节

3.1 标准目录结构长什么样

一个 Claude Code 的 Skill，本质上就是一个文件夹。我自己项目的结构是这样组织的：

causal-analyst/ ├── SKILL.md ├── references/ │ ├── causal-inference-methods.md │ ├── identification-strategies.md │ └── checklist.md ├── examples/ │ ├── promotion-sales/ │ │ ├── data.csv │ │ └── analysis-summary.md │ └── pricing-experiment/ │ └── results.md └── scripts/ └── balance_check.py

每个部分各司其职：SKILL.md是技能包的入口，Claude 首先读取它；references/存放详细的领域参考文档，避免主文件过长；examples/放完整的示例分析，方便模型模仿输出风格；scripts/放一些可执行的辅助脚本，比如倾向得分匹配后的平衡性检验。

这个结构不是拍脑袋做的，它参考了 Anthropic 官方对 Skill 的推荐目录风格。实际跑下来的经验是：SKILL.md最好控制在 500 行以内，否则每次加载都会消耗大量上下文窗口，而且模型会抓不住重点。详细的公式、代码片段、参考文献全部塞进references/，让模型按需查阅。这就好比一个分析师手上有一本详细的操作手册，而不是把所有公式都背在脑子里。

3.2 frontmatter 的正确写法：name 和 description 是触发器的关键

SKILL.md 的开头是 YAML frontmatter，这部分直接决定了 Skill 什么时候被激活。我见过很多 Skill 不生效的案例，十有八九是 description 写得不对。Causal analyst 这个 Skill 的 frontmatter 我这样写的：

--- name: causal_analyst description: 用于进行因果推断分析的技能。当用户提供观测数据、实验数据、或要求评估干预效果、处理选择偏差、估计因果效应、区分相关性与因果性时使用。辅助用户完成DAG构建、混杂因子识别、效应估计与敏感性检验。 ---

注意几个细节。name必须用短横线命名，不能有空格。description里不要写“这是一个关于因果推断的技能包”这种废话，要写清楚“什么场景下需要这个技能”，因为 Claude 是靠语义匹配 description 来决定是否加载这个 Skill 的。我一开始写的 description 是“分析因果关系”，结果发现触发率很低，改成上面这种“场景列举式”描述后，只要用户问题里出现“干预效果”“选择偏差”“因果效应”这些词，技能就会被唤起。

3.3 SKILL.md 正文：怎么把四步工作流写成 Prompt 指令

frontmatter 之后是正文，正文就是一段结构化的 Markdown，本质上是一套详细的提示词工程。但它比普通提示词强的地方在于，它可以引用外部文件，可以编排分支路径，还可以定义输出格式。

Causal analyst 的 SKILL.md 正文，我把四步流程写成这样（简化版）：

# Causal Analyst 你是经验丰富的因果推断分析师。你的目标不是给出相关性报告，而是帮助用户识别并估计因果效应。 ## 工作流程 ## Step 1: 研究问题定义 - 询问或确认: 干预变量(X)、结果变量(Y)、分析单位、目标人群 - 将研究问题写成反事实形式: "如果X不同，Y会如何变化?" - 如果信息不足, 列出需要用户补充的问题, 不要擅自假设 ## Step 2: 构建因果图(DAG) - 列出所有与X和Y相关的变量 - 区分: 混杂因子、中介变量、对撞因子、工具变量 - 用文字或 mermaid 形式写出变量的有向图结构 - 明确标出哪些混杂因子可观测、哪些不可观测 ## Step 3: 选择识别策略 - 根据DAG选择方法: 回归调整/倾向得分/DID/工具变量/RDD - 解释该策略为什么在本DAG下成立 - 指出该方法依赖的关键假设 ## Step 4: 估计与检验 - 给出效应估计值与置信区间 - 执行安慰剂检验、平衡性检验、稳健性检验 - 将结果解释为因果语言, 但必须附带假设条件

这里有一个我踩过坑后确定的细节：不要允许模型在 Step 2 之前给出因果结论。第一次版本我没有强制顺序，模型经常先跑回归给结论，再补一张 DAG 当装饰。后来我明确加上“未完成前序步骤不得给出最终结论”后，输出质量才稳定下来。Skill 的价值就在这种约束里——它不是更聪明的提示词，它是把专业流程变成了模型的行为规范。

3.4 references 和 examples 的设计要点

references 目录里，我放了三份文档。causal-inference-methods.md介绍各种因果推断方法的适用条件和公式；identification-strategies.md详细解释后门准则、前门准则怎么操作；checklist.md是一份输出前的检查清单。这里有个设计技巧：检查清单不要写在 SKILL.md 主文件里占篇幅，而是放在 references 中，然后在 SKILL.md 里写“输出最终结论前，阅读 references/checklist.md 并逐项自查”。这样模型会在关键时刻去读取那个文件，而不至于让主流程臃肿。

examples 则更重要。模型模仿能力很强，给它一个完整的示例输出，它就能照着格式生成。我的promotion-sales示例里放了一份从数据到分析报告的完整过程，包括 DAG 的文字描述、DID 估计步骤、安慰剂检验结果。实测下来，有这份示例和没这份示例，输出结构的稳定性差了不止一个档次。你如果自己写 Skill，examples 目录一定不要省，哪怕只有一份虚构案例。

4. 从安装到跑通：完整实操一个因果分析案例

4.1 安装 Claude Code 与准备 Skill 目录

这个项目本身不依赖额外后端服务，它就是给 Claude Code 用的一个技能包，环境准备主要是装好 Claude Code。

安装方式很直接，我当时的命令是：

npm i -g @anthropic-ai/claude-code

装完验证一下：

claude --version

如果报“无法识别 claude 命令”，一般是 Node.js 的全局 bin 路径没进 PATH。Windows 用户则要额外注意，Claude Code 的某些能力需要 WSL 或 Windows 虚拟机平台支持，官方文档里也有说明。我在几台机器上实测下来的经验是：最好统一把目录想办法搞干净，不要用中文路径，否则后面挂 Skill 文件容易出现编码问题。

接着是创建 Skill 目录。Claude Code 支持两个层级：

• 用户级：~/.claude/skills/，所有项目共享
• 项目级：<项目根目录>/.claude/skills/，只对当前项目生效

Causal analyst 这个技能属于通用分析能力，我放在用户级，这样每个会话里都能用。如果你想把技能绑定到特定项目（比如某个调研项目），就放项目级。目录建好后，直接用 git clone 或手动拷贝文件夹进去即可。这正是大家经常搜的“claude code 怎么手动装 github 上的 skills”的标准答案——并没有特殊安装命令，本质上就是拉到.claude/skills/目录下。

git clone https://github.com/yourname/causal-analyst-skill.git ~/.claude/skills/causal-analyst

4.2 触发方式：自动唤起和手动命令

Skill 装好后，有几种触发方式。最核心的是自动触发：Claude Code 会根据用户输入的问题，结合每个 Skill 的 description 做语义匹配，自动加载对应的技能包。比如你上传一份销售数据说“帮我看看促销对销量的因果效应”，它就会自动唤起 causal analyst。

除了自动触发，Claude Code 里还有手动/skill命令，可以直接查看当前所有已安装技能并主动调用。如果你在调试某个 Skill，手动触发是最高效的。

另外，你也可以在自己写的 SKILL.md 里定义专门的斜杠命令。比如我在文件里加过一行## /causal，这样在会话里输入/causal可以直接唤起本技能并进入分析流程。对经常重复使用某个技能的场景，这个很实用，可以省掉一段冗长的业务描述。

4.3 完整示例：跑一遍“促销与销量”分析

为了演示这个 Skill 的实际工作过程，我构造了一个简单但典型的业务案例：一家连锁零售店铺，过去 12 个月的周度数据，变量包括“是否开展促销”“周销量”“客流量”“天气温度”“竞品是否缺货”。我故意把数据结构做得有点脏，因为真实业务就是这样——直接跑回归大概率会得到促销显著，但那很可能是客流量带偏的。

我把数据丢给 Claude，说了一句“帮我分析促销对销量有没有因果效应，我用的是观测数据”。Skill 被唤起后，输出流程如下：

Step 1 它先没有急着建模，而是反问我：“促销的定义是什么？‘销量’是销售额还是订单量？分析单位是周还是店铺级别？”并且把研究问题改写成了反事实形式：“如果某周没有开展促销，该周销量会比实际低多少？”这一步看起来简单，但非常关键，因为大多数数据分析任务在起点就模糊。

Step 2 它生成了 DAG 的文字结构，列出的节点包括：促销、客流量、天气温度、竞品缺货、周边活动、当周销量。它特别标出“客流量”是混杂因子，因为客流量既会影响店铺是否决定做促销，也会直接影响销量。它还标记“竞品缺货”是工具变量的候选来源，因为竞品缺货直接影响促销决策，但不直接作用于本店销量（在合理假设下）。这个结构铺出来后，分析路线就清晰了。

Step 3 它没有无脑选多元回归，而是给了两个方案：如果接受“可观测变量足够捕捉混杂”的假设，用回归调整；如果担心有不可观测混杂（比如店长是否更勤奋），用“竞品是否缺货”做工具变量做两阶段回归。然后它让我选，因为它没法凭空验证工具变量排他性。

Step 4 最终输出是一个表格，包含各方法的效应估计值、标准误、置信区间，以及一句话总结：“回归调整法估计促销平均带来 18% 销量提升；IV 法点估计为 23% 但置信区间很宽，在 5% 水平不显著。结论对模型选择敏感，建议先解决客流量数据的测量误差再作决策。”

这个输出在因果推断里算是非常合格的。它没有说“促销有效”或“促销无效”，而是把结论的假设依赖清清楚楚地说出来，把选择权交还给业务方。这就是 Causal Analyst Skill 和其他“数据分析助手”最大的区别。

5. 上线后的调试、质量判断和避坑实录

5.1 常见报错与不生效排查速查表

折腾完一遍，我把最常见的坑整理成了一个速查表，方便你照着排查自己的 Skill 安装问题。

里面我特别想强调的是第一行：description 的作用比大多数人想的重要。Claude 加载 Skill 是语义匹配的过程，你的 description 越像“用户在真实对话里会发的需求”，触发越准。别写“这是一个很好的因果分析工具”，要写“当用户提到干预效果、混杂、效应估计时使用”。

5.2 输出质量判断：怎么防止模型“伪因果”

装了 Skill 不代表模型每次都对。模型仍然可能给出看似严谨实则错误的因果结论。我在使用中总结了一个三步质检法。

第一步看它有没有交代识别假设。任何一个因果估计都必须说清楚“它依赖什么假设”。比如回归调整法依赖“无不可观测混杂”和“正确函数形式”。如果输出里没有这一步，直接判定不合格。

第二步看它有没有做反事实检验。一个安全的因果分析通常至少做一次安慰剂检验或者替换样本的稳健性检验。比如用“过去某周随机虚构的促销”做一个假干预，看看是否会错误地估计出效应。Claude 在装了 Skill 后知道要做，但有时候会偷懒，这时你可以直接在对话里说“请执行 checklist.md 里的第 3 项检验”，它会立刻补齐。

第三步是敏感性分析。这个最容易被忽略。模型给了一个 IV 估计，你就该问它“如果工具变量的排他性假设放松一点，结论还会成立吗？”把这个问题丢回给 Claude，Skill 会根据 references 里的方法给出一个敏感性分析框架。

5.3 Skill 调优的几个技巧

调优阶段有几个技巧值得分享。

第一个是“把假设显性化”。我在 SKILL.md 里加了一句话：“输出因果结论时必须附带一段‘结论依赖的假设’。”就是这一句话，让输出质量上了一个台阶。模型本身不是不知道假设的重要性，而是缺乏强制约束。

第二个是“利用 examples 让输出靠近你的偏好”。Claude 的模仿能力很强，你给它什么样的完整示例，它就会照那个格式和深度来。我放的那份pricing-experiment示例里特意写了一个“结论部分带风险提示”的报告格式，模型之后就经常输出类似风格。你要什么风格，就喂什么示例，这是最直接的调参手段。

第三个是“给模型一个中止反思的动作”。我在 SKILL.md 里加了这么一条：当数据不足以支撑因果判断时，必须停下来说“现有数据无法支持因果推断，需要补充以下信息”并列出清单。这个设计是为了对抗模型“硬要给结论”的倾向。实测下来，装了这条之后，模型胡说八道的概率大幅下降。

5.4 关于长上下文和复杂任务的一点体会

现在 Claude Code 已经支持巨大的上下文窗口，有人会觉得那就把所有参考文档都塞在会话里，让模型自行查阅。我的体会是：不要这样做。上下文再大，模型在长文本中定位关键信息的能力也是有限度的，而且每一轮对话都会消耗上下文，塞得越多越容易在会话后半段进入“忘事”状态。

正确的做法是把参考资料放进 Skill 的 references 目录，通过描述性指令让模型在需要时读特定文件。比如在 SKILL.md 里写“估计 DAG 的后门调整前，阅读 references/identification-strategies.md 中的相关小节”。这种按需阅读的方式，比一次性把所有文档塞进对话效率高得多，也是 Skill 机制相对普通 Prompt 的核心优势之一。

写在最后的一点经验

折腾完这个 Causal Analyst Agent Skill，我最大的体会是：给模型做 Skill，本质是把你脑子里的那套“专业流程”显性化。我以前直接用一大段 Prompt 让 Claude 做因果分析，总觉得它输出“看起来专业但经不起推敲”。做成 Skill 之后我才明白，问题不在于模型不够聪明，而在于我没有给它一条足够严谨的轨道。一旦把识别、建模、检验、解释四步固化下来，配合 references 里可以随时查阅的方法论文档，它就能稳定地产出专业级分析。

最后再分享一个小技巧：如果你只打算借鉴这个项目的一个点，那就借鉴“强制先画 DAG 再给结论”这条。我在多个场景测试过，只要 SKILL.md 里加了这一步，模型的伪因果输出至少能减少一半。这东西不复杂，但就是好用。

另外，这个 Skill 后续还有很多可以扩展的方向。比如把它跟 Agent 结合起来，让 Claude Code 在跑数据管道时自动调用这个技能做中期分析；或者在 references 里补齐更多行业特定的混杂因子库。你们要是也做了自己的分析类 Skill，随时可以交流踩坑心得。