Skill 可以保存一套分析方法，甚至打包某次分析的 SQL、背景与修正记录；但它无法单独保存当时使用了哪个版本的数据、实际运行了什么、谁批准了口径，以及结论如何连回证据。Skill 记住的是分析应该怎么做，而不是一份分析实际上如何发生。
我看到一种很自然的做法：分析师和 Agent 好不容易完成一次分析后，把磨合出来的 Prompt、口径、SQL、检查步骤和注意事项整理成 Skill。下次遇到类似问题，再让 Agent 加载这份 Skill 接着做。
这比把成果埋在一段看不到尽头的聊天记录里好得多。但它也暴露了另一个问题：我们正在把“可复用的方法”和“一段真实发生过的分析”塞进同一种容器。
我们其实在讨论两种 Skill
Agent Skills 的通用格式把 Skill 定义为一个以 SKILL.md 为核心的文件夹，可包含指引、scripts、references、templates 与其他资源。它很适合让 Agent 按需加载专业知识与工作流程。
放到数据分析场景中，我认为大家口中的 Skill 至少有两种：
| Skill 类型 | 保存的内容 | 例子 | 主要价值 |
|---|---|---|---|
| 方法论 Skill | 通用方法、步骤、检查标准与交付格式 | 漏斗分析方法、SQL review checklist、数据质量检查 | 教 Agent“这类问题通常怎么做” |
| 具体分析 Skill | 某次分析积累的口径、SQL、背景、修正与结论 | Q2 留存分析、每月营收分析、某产品的转化率分析 | 让 Agent 延续一段已经做过的工作 |
第一种是可复用的 expertise。第二种则更像一个被压缩过的分析项目：我们希望 Agent 不只记住方法，还记住上次和我们一起做了什么。
这个需求完全合理。聊天不是好的分析保存格式；更换 Agent、开启一段新对话，或者三个月后回头看，之前对齐过的细节都很容易消失。具体分析 Skill 因此成了实用的补丁。
但补丁终究不是分析本身。
Skill 里有 SQL，不等于保存了那次分析
假设你和 Agent 完成了“新客 30 日付费转化率”分析，最后把这些内容整理成 Skill：
- 新客的定义；
- 需要排除的测试账号与退款；
- 用户、订单与付款表的 JOIN 方法；
- 计算转化率的 SQL；
- 报告应该呈现的图表与结论。
三个月后，另一位同事加载 Skill，准备更新最新数字。Agent 确实知道该怎么做，却仍然不一定回答得了：
- Skill 里的 SQL 当时真的成功执行过，还是只是一份建议？
- 报告中的 18.4% 是由哪次查询结果产生的？
- 当时使用的是哪个数据范围，数据后来更新了吗？
- 分析师曾否决过哪些口径？最后批准的是哪个版本？
- JOIN 前后是否检查过 grain 与 fan-out？
- 如果重新执行后得到 17.9%，差异来自数据更新、SQL 改动，还是定义变化？
你当然可以继续往 Skill 里添加文件：放入查询结果、日期、版本说明、更多 SQL，甚至编写 script 重建流程。但当它开始负责数据快照、依赖、执行记录、决策历史与最终交付时，它已经不只是一份 Skill，而是一个需要手工维护的分析工作区。
问题不是 Skill 能不能装下这些文件，而是这些文件彼此的关系不会自动成立。
一段 SQL 存在，不代表它执行过；一个数字被写下来，也不代表它仍能连回产生它的数据与条件。
方法是 instructions，分析是 state and evidence
这是两者最根本的区别。
Skill 描述 intended path：应该读取哪些数据、采用哪些步骤、检查哪些风险，以及如何交付。
分析保存 actual path：这次选择了哪个口径、实际执行了哪段 SQL、使用了哪个数据状态、产生了什么结果、经过了哪些审核，以及最后仍有哪些限制。
两者都重要，但生命周期不同。方法可以跨项目复用；分析结果则绑定特定问题、时间、数据与决策。
| 真实分析需要保存的内容 | 具体分析 Skill | Lantide Data |
|---|---|---|
| 分析方法 | 可保存步骤、规则与 Prompt | 可加载并共享 Skill |
| 业务口径 | 写成文字供 Agent 下次理解 | 以 Reference、Agent Memory 与 Plan 承载 |
| SQL | 可保存 SQL 文件或示例 | 成为可执行、可审核的分析 artifact |
| 执行结果 | 需要另存快照或重新生成 | 与 SQL、结果面板及工作区状态相连 |
| 中间结果与依赖 | 需要自行描述如何重建 | 可用具名缓存、持久 SQL 与 lineage 表达 |
| 人工决策 | 通常只留下整理后的最终版本 | 通过 Plan、批注与批准保留决策脉络 |
| 报告证据 | 结论与查询结果可能分离 | Plan、SQL、结果与 Report 留在同一项目中 |
| 权限与执行边界 | Skill 本身不是授权 | 由 Agent 状态、工具与 access mode 控制 |
因此，真正的比较不是“Skills 和 Lantide 谁更强”。Skill 是方法资产；Lantide 是让方法进入真实数据、执行与审核流程的工作环境。
一份分析至少有五层，Skill 最擅长其中一层
我会把一份可以延续的分析拆成五层：
Method → Decision → Execution → Evidence → Delivery
| 层次 | 需要保存的问题 | 适合的载体 |
|---|---|---|
| Method | 这类问题通常怎么分析？ | Skill |
| Decision | 这次采用什么口径、范围与假设？ | Plan、Reference、批注 |
| Execution | 实际运行了哪段查询？ | SQL 与 query environment |
| Evidence | 结果从哪里来，如何验证与重跑？ | Results、lineage、activity |
| Delivery | 最后如何解读，还有哪些限制？ | Report |
如果最后只保存了 Skill，你保存的是“下一次可以怎么做”，却未必保存了“上一次到底做了什么”。这也是为什么可复现的 AI 分析需要的不只是一份漂亮的操作说明，而是一条能从结论回到来源、转换与限制的证据链。
这就是我为什么做 Lantide Data
我不是因为 Skills 没有价值才做 Lantide Data。相反，我认为 Skills 会成为分析师与 Agent 协作时非常重要的知识资产。Lantide 也提供 Skill Library，让内置 Agent 与通过 MCP 接入的外部 Agent 共享同一份方法定义；但 Skill 不会因此获得更多工具或绕过治理。实际使用方式可参考 Skills 使用指南。
真正让我在意的是：当分析师开始把 SQL、业务口径、分析结果、修正记录，甚至整个项目都塞进 Skill，他真正缺少的可能不是另一份更完整的指令文件，而是一个能保存分析工作本身的环境。
在 Lantide 的正式分析流程中，Agent 可以使用 Skill 起草方法，但这次分析的问题、范围与 checkpoints 会进入 Plan；用户审核后才 Approve & Execute；实际使用的 SQL、结果与中间依赖保留在工作区；最终的 Report 则与前面的证据一起存在。方法可以复用，具体项目不必被压扁成方法。
这并不代表 Lantide 能替团队决定唯一正确的业务口径，也不代表它是 data warehouse 或企业 semantic layer。人仍然需要判断问题、数据与限制。Lantide 想补上的，是 Agent 完成真实分析时所需的状态、执行面与审核界面。
Skills 是分析资产，但不是全部的分析资产
评估一套 Agent 分析工作流时，不妨问两组问题。
第一组关于能力：Agent 是否知道这类问题该怎么分析？有没有使用合适的 Skill？
第二组关于证据：这次采用了什么口径？实际执行了什么？数字如何产生？谁做了决定？下一位接手的人能不能重跑？
前一组可以由 Skills 回答，后一组需要真正的分析工作环境。
Skills help an Agent learn how you work. Lantide helps you preserve the work you actually did.
下一次准备把一段成功的分析整理成 Skill 时，可以先做一个简单检查：把可复用的方法放进 Skill，把这次分析的决策、SQL、结果与限制留在能够审核和重跑的项目中。两种资产分开保存，Agent 才能延续你的方法，而团队也不会失去分析本身。