从给“小龙虾”这个项目加了几个 Skill 开始，它彻底变了：以前只会把数据原样堆出来，像个自动合订本，现在居然能分层拆问题、交叉验证逻辑、主动写反方意见。从“数据搬运工”到能扛事儿的“高阶分析师”，中间隔的不是更贵的模型，而是几个不到几十KB的Skill文件。这篇我就把完整的实战过程写下来，包括Skill的目录怎么设计、触发逻辑怎么定、坑都踩在哪里，尽量做到你拿去就能跟着配。
1. 事情是怎么开始的：一个只会“复读”的Agent，把我看急了
我手头有个内部代号叫“小龙虾”的Agent项目，初衷很简单：给它丢一堆行业资料、财务数据、访谈纪要，让它自动输出一份能直接用的分析报告。最开始的效果怎么说呢——不能说错，但就是没法用。它会把所有拿到的数据按照原始顺序罗列出来，然后在我没有明确指令的情况下，自作主张地加一句“总体来看，该行业具备一定发展潜力”这种正确但毫无营养的废话。数据之间没有因果逻辑，报告里没有核心结论，读者看完只记得它最后那句万能结论。
我试过换更强的模型、在系统提示词里写“你要像资深分析师一样思考”，结果大概率是：报告变得更长、更像那么回事，但里面的论证链条依然松散。比如它会在没有任何收入预测数据的前提下，直接写“预计未来三年将保持高速增长”；或者把两个口径完全不同的财务指标并列在一起，假装它们可以比较。这说明问题根本不在模型的“智力”，而在于它缺少一套行为规范——就像把一位名校毕业的实习生扔进会议室，他确实聪明，但不知道分析师应该按什么流程来工作、每一步要交付什么格式的产出物。
后来我注意到社区里有人聊“Skill”的玩法，核心思路是：不要试图通过长篇提示词让模型“变成”某类专家，而是给它一组可调用的工作流文件，每个文件定义清楚一个子任务的目标、输入格式、处理步骤和输出标准。模型不再靠临场发挥来“装专业”，而是按文件里的流程一步步执行。我抱着试试看的心态，给小龙虾加了几个Skill文件，结果两天之内，它的输出质量出现了肉眼可见的跳变。
这篇记录我不想写成泛泛的经验分享，会更像一份带注释的改造日志：我到底加了哪几个Skill、每个Skill内部写了什么、为什么这样写有效、中间踩了哪些坑。如果你也在折腾Agent，希望能帮你少走几趟弯路。
2. Skill到底改了小龙虾的哪根筋：行为协议，不是知识包
很多人第一次接触Skill会有一个误解：以为它是给Agent塞知识库，类似于往模型里灌行业数据。实际上Skill的核心作用不是“提供答案”，而是“约束行为”。它能改变的是Agent在接到任务之后，按什么顺序思考、以什么格式产出、在什么情况下需要调用工具或停止输出。这才是它能让“小龙虾”脱胎换骨的根本原因。
2.1 对比一下就明白：Prompt、知识库、Skill分别解决什么问题
我习惯用一个不太精确但很直观的类比：如果把模型比作一个刚入行的新人分析师：
- 提示词相当于你临场交代的一句口头任务：“今天把这份数据看一下，写个报告。”新人聪明的话能听懂个大概，但细节全靠自己脑补。
- 知识库相当于把一柜子的行业报告、财务底稿借给他翻阅。参考资料变多了，但他如果不知道“分析报告的标准结构是什么”，依然可能抄一页扔一页，最后拼出一份杂交文档。
- Skill相当于给这位新人发了一套《分析作业标准操作规程》，里面白纸黑字写清楚了：接到任务先拆解成哪几个子问题、每个子问题需要什么数据支撑、一个观点成立需要满足哪几条检验条件、报告最终必须包含哪几个章节。
小龙虾最初的状态就是“高智商但无流程”：知识它都读得懂，数据它也抓得到，但输出完全取决于它当下那一刻怎么理解我的指令。同一个问题问两次，两版的框架经常不一样。这就像同一个实习生每次交上来的报告格式都不同，有的从行业规模讲起，有的从竞品动向讲起，有的直接从财务预测讲起——你看得懂，但你没法把它当标准化产能来用。
2.2 Skill的两层结构：路由层和执行层
我实际用下来的感受是，一套完整的Skill体系应该分两层。第一层是路由层，负责判断“当前这个任务适合走哪一套流程”；第二层是执行层，负责把具体流程跑完并输出最终结果。
路由层解决的是“龙虾弹跳”问题：同一个Agent，收到“帮我算一下这个项目的投资回报率”和“帮我梳理一下这个行业的竞争格局”，这两件事的工作方法完全不同。前者需要财务数据和现金流假设，后者需要市场规模、玩家策略、护城河逻辑。如果你把这些要求全都塞进同一个提示词里，模型很容易在切换任务时“精神分裂”：一会儿想用财务模型，一会儿想画行业图谱，最后出来的报告两边都不够深。
执行层解决的则是“怎么做才算做完”。以行业分析为例，一个Skill里面会定义至少四步：定义问题边界、收集并校验信息、构建逻辑框架、输出结论并标注不确定性。模型在推理时不是一口气直接生成2000字报告，而是先按Skill的步骤拆解，再逐步填充内容。这和我之前用的“一次性长Prompt”有一个本质区别：长Prompt描述的是“优秀报告长什么样”，Skill描述的是“怎么一步步做出这样一份报告”。
2.3 为什么几个Skill就能“变高阶”：流程把智力释放了出来
写到这里我不由得想到一个点：大语言模型的推理能力其实一直都在，缺的往往不是“能不能想明白”，而是“有没有沿着正确的路径想”。就像一个人数学功底再好，如果不检查题目条件、不写推导过程，照样会错。Skill做的事情，就是把“正确的路径”外置成文件，让模型每一步都有参照物，不需要在推理的每一步都靠自己的力量去“回忆”数据分析领域应该怎么做。
有几个关键的观察，我在改造小龙虾之后才真正体会到：
一是模型不需要“记住”所有规则，只需要“读取”当前阶段的规则。以前我把几十条要求写在系统提示词里，模型到后面其实已经忘了前半部分，或者开始自己总结“大概要求就是这样”。但Skill文件是分阶段加载的，当前阶段只需要关注当前阶段的规则，上下文压力小很多。
二是输出规范比内容要求更容易稳定复现。Skill里如果写“请对数据进行分析”，模型不知道什么叫“分析”；但如果写“每个结论必须附带支持数据及其来源，如数据缺失则明确标注”，模型就非常清楚该输出什么。这就是把模糊要求变成可校验格式的价值。
三是触发机制让“专业动作”变成条件反射。小龙虾现在收到“帮我写一份公司深度报告”这样的任务，会自动走一遍经营分析Skill的路径，而不是漫无目的地堆砌文字。就像外科医生看到手术指征，自然知道该走哪套手术流程，而不是现场即兴发挥。
3. 我实际加了哪三个Skill：目录结构、触发逻辑与输出格式
初次改造的时候我并没有堆很多Skill，只加了三个。数量少有一个好处：调试方便，出了问题能很快定位是哪个文件管得太多或管得太少。后面稳定了，再在骨架之上添加细分方向才比较安心。
3.1 第一个Skill：开题拆解与逻辑预设（scope_breakdown）
这个Skill的作用是强制Agent在真正开始收集信息、写报告之前，先把任务“拆开来看”。我当时的触发词设计得很简单，只要用户请求里包含“分析”、“研究”、“报告”、“评估”这些词，并且任务对象是企业、行业或投资项目，就会先走这个流程。
它在执行时要求Agent输出四段内容：研究目标、核心问题清单、信息缺口、分析框架预设。举一个实际跑过的例子，我让它“分析一下某新能源配件供应商的成长性”，小龙虾没有直接去写“该行业未来空间广阔”，而是先输出：
- 研究目标：评估该供应商未来三年的收入与利润成长空间，并识别关键驱动因素。
- 核心问题清单：收入增长来自哪些产品线？产能约束在哪个环节？客户集中度是否构成风险？
- 信息缺口：当前缺少分产品的产能利用率数据、缺少主要客户续约条款信息。
- 分析框架预设：按“市场空间→份额提升→产能落地→盈利质量”的链条展开。
这段输出看起来简单，但它有个巨大的价值：把模糊任务变成一套可以逐项打勾的清单。后续所有信息检索都围绕这份清单展开，模型不会再东一榔头西一棒子。我对比过加这个Skill之前的小龙虾，它经常在报告前两段就开始讲结论，然后花很多篇幅罗列无关数据。现在它会先“立框架”，哪怕数据还没收集，读者也知道你要往下写什么、为什么这样写。
3.2 第二个Skill：财务与数据校验规则（data_validation）
分析师的报告里最怕一件事：数据和结论脱节。情绪上觉得“这个公司挺好”，然后找几个看起来不错的数字来撑腰。这不是模型独有的问题，人类分析师也会这样。所以我给小龙虾写的第二个Skill，是对所有涉及数据的关键结论做强制校验。
这个Skill的触发不是靠用户请求里的关键词，而是靠路由层判断：只要后续输出中出现财务指标、市场规模、增长率、市占率这类数值型关键字段，就会调用这部分规则。它的核心要求有三点：
第一，任何结论必须标注数据来源和统计口径。比如写“市占率达到15%”，就必须注明是“按出货量计算”还是“按收入计算”，数据来自哪一年、哪一个统计区间。很多AI报告看起来漏洞百出，问题常常就出在口径混用：A公司说自己收入端市占率排第一，B公司说自己的出货量排第一，两个说法可能都对，但放在一起就被模型写成“该企业具备全方位优势”，事实失真。
第二，任何预测必须给出计算逻辑。小龙虾过去写的预测经常属于“直觉式增长”，比如给出一个未来三年增速，却不知道这个数怎么来的。现在我会在规则里要求：预测增速必须和行业历史增长、公司产能扩张计划或已经披露的订单成长性建立关系。如果没有依据，那就必须如实标注“此项为缺乏直接数据支撑的推断”。
第三，关键指标如果要跨期对比，必须拉出同比/环比框。有些数据单看绝对值没感觉，但把连续几年的趋势线画出来，能立即看出毛利率往下走、净利率往上走等结构性变化。Skill会要求Agent至少列出近三个报告期的数值，再把变化原因写透。
这个Skill的规则文件我写成了类似问卷的形式，模型在输出数据类段落时会按照条条框框来填空，而不是自由畅谈。效果立竿见影：小龙虾编数字的频率大幅下降，因为它不能再说“规模庞大，前景广阔”这种空话，每次想讲一个判断，都得交代为什么。
3.3 第三个Skill：反方观点与风险发现（contrarian_view）
给分析报告加“反方视角”，是我后来特意补上的一个设计。因为只要求Agent顺着自己的观点找证据，它一定会去做“结论先行”的表扬稿。但如果规定它必须回答“看空这个标的人会怎么说”，整个思维质量会立刻上一个台阶。
这个Skill的触发条件简单粗暴：只要报告输出的是“买入/推荐/有吸引力/建议关注”这类方向性结论，就必须再写一节“反方意见与主要风险”。而且不能是那种“行业竞争加剧、政策变化可能带来不确定性”这种万金油式风险提示，必须具体到可以检验的程度。最好是针对报告中的某个核心假设，反方向提出质疑。
举个例子，如果之前的核心假设是“这家公司的海外产能能如期投产”，反方意见就会要求Agent评估：如果投产延迟六个月，收入和利润会受影响多少？有没有已经出现的预警信号可以观察？这一招让小龙虾的报告从“自说自话的营销号风格”变成了“带攻防的分析意见”，读者看完之后会在脑子里形成两种情景，而不是被单边观点牵着走。
3.4 一个Skill文件的内部长什么样
这里放一个我精简过的示例结构，不是完整的源文件，但能让你直观理解规则是怎么写进文件里的：
skills/equity_research/ ├── SKILL.md ├── rules/ │ ├── scope_breakdown.md │ ├── data_validation.md │ └── contrarian_view.md └── templates/ ├── report_framework.md └── checklists/ ├── financial_checklist.md └── risk_checklist.md其中SKILL.md是整个Skill的入口，里面会写明这个Skill叫什么、在什么条件下被调用、读取哪些规则文件、最终产出什么。规则文件之间不是互相独立的，scope_breakdown生成的“核心问题清单”会作为后续data_validation和contrarian_view的输入。也就是说，模型在report_framework模板的约束下，把三份规则文件串联成了一条完整流水线。
我还专门设计了一个触发小技巧：在SKILL.md的第一行就写明“该Skill的触发条件是什么”，这句话在大模型读取时权重很高，等于告诉它“什么时候该主动进入这套流程”。如果触发条件写得太模糊，模型很容易要么每个任务都触发Skill（导致简单问题被过度加工），要么完全不触发（Skill文件形同虚设）。我最终把触发条件写成了“对组织、行业、业务单元进行深度分析，输出结构超过三段的评估报告时，必须调用本Skill”。普通问答、快速摘要、翻译类任务则明确不触发。
4. 加Skill前后的实际产出对比：旧版与新版差在哪
光说理论不直观，这里放一组我真实跑过的对照，任务完全一样：“分析某充电桩运营商的商业前景”。
4.1 加Skill之前的小龙虾输出（节选）
“近年来，随着新能源汽车保有量持续快速增长，充电桩行业迎来了重要的发展机遇。该运营商作为行业内的重要参与者，在多地布局了充电网络，具备一定的先发优势。从市场空间来看，充电桩市场规模庞大，未来发展潜力可观。总体来看，我们看好公司在行业增长中的受益前景，预计公司业务将保持较快发展。”
这段话你品品，是不是什么问题都没说错，但什么问题都没说透？市场空间庞大——多大？先发优势——先发在哪里？较快发展——快在哪一年、快在哪条业务线？整段文字随便换个标的也成立，这就是典型的“没有分析的分析”。
4.2 加Skill之后的小龙虾输出（节选）
“该运营商的核心收入来自充电服务费，同时通过电费差价与广告增值服务获取额外收入。当前公用充电桩的行业平均利用率约为8%-12%，而该运营商披露的场站平均利用率为14.5%，明显高于行业均值。需要说明的是，该数据来源于其2024年官方业务公告，未获得第三方审计认证，考虑到场站分布差异，估算存在约2个百分点的偏差。”
“主要增长逻辑为两条：一是2025年计划重点拓展对物流车队的专用充电场站，该类场站单桩日均充电时长预计可达6.5小时，远高于乘用车公共场站的3小时；二是联合商圈物业开通‘目的地充电’服务，以固定分成代替自营建设，资本开支需求较低。但上述扩张计划依赖2025年底前至少三处新建变电站的按时投运，供应链与审批进度存在不确定因素。若任一关键节点延期6个月以上，今年新增收入预测将下调15%-20%。”
看到差别了吗？新版报告里每一个观点都带了一个锚点：行业均值是8%-12%，它是14.5%；增长逻辑指向具体业务动作（物流车队专用场站）；风险依赖具体物理条件（变电站投运）并给出了量化后果（下调15%-20%）。这份材料如果给一个基金经理看，他可以立刻决定要不要深入调研；而旧版材料看完，他只能回复一句“谢谢，我们内部看一下”。
4.3 用一张表格感受质量差异
| 对比维度 | 加Skill前 | 加Skill后 |
|---|---|---|
| 结论依据 | 模糊、形容词支撑 | 数据、口径、来源明确 |
| 逻辑链条 | 堆砌多个“利好”因素 | 从业务动作推导财务结果 |
| 预测方法 | 拍脑袋给增速 | 基于产能/订单/行业均值推算 |
| 风险提示 | 泛泛而谈“竞争加剧” | 具体到项目延期、量化影响 |
| 阅读门槛 | 看完不知道下一步该问什么 | 每个段落都自然引出可调研方向 |
| 可复核性 | 几乎不可复核 | 数据来源与假设都有标注 |
另外一个不容易被注意的差异：加Skill之后，同一类任务的多份报告之间，框架越来越一致。以前小龙虾今天写的框架、明天写的框架可能对不上，拼在一起好像两个分析师的作品。现在它会在开头严格按照“目标→问题清单→框架预设”来走，中间每一点结论都有数据支撑，结尾反方意见固定到位。这套稳定性对团队协作特别重要，因为别人可以预判报告的结构，拿过来就知道去哪里找什么内容。
5. 两个月实战踩坑：不生效、一套到底、一本正经的胡说八道
把理论讲完、亮完成果之后，再说说难听的部分。改造小龙虾的前两周，我几乎每天都在SIKLL不生效和处理副作用之间反复横跳。下面这几个坑是我认为最有代表性的，你大概率也会遇到。
5.1 坑一：Skill文件加了，但Agent根本不“理”你
第一个坑是最让人崩溃的：规则写得清清楚楚，模型却视而不见，还是照旧用自己的方式输出。我当时的排查思路是从简到繁，最后发现问题的关键既不在文件内容，也不在模型大小，而在“触发条件不明确”。
前面提到SKILL.md里要写明触发条件，但如果触发条件设定得太苛刻，模型在判断时就会犹豫，宁可不触发。举例来说，如果触发条件写“当用户请求涉及财务分析、估值模型、投资评价等专业分析场景时”，模型可能对“估值模型”理解得很抽象，看不到“搭建DCF模型”或“PE倍数对比”就不认为这是估值场景，于是直接跳过。
这里我学到的做法是把触发条件从“场景描述”改成“产出描述”：不写“财务分析”，而是写“当任务要求输出一份包含财务指标、预测、评估结论的报告时，必须调用”。模型对输出物的判断比对抽象场景的判断可靠得多。说白了，你的规则要能回答“什么样的请求会让你进入这个流程”，而不是“什么领域的请求需要帮助”。
5.2 坑二：Skill文件里写的步骤，被AI“象征性执行”了一遍
还有一种情况更隐蔽：模型确实触发了Skill，也按文件里的顺序输出了几个章节，但每一个部分都是泛泛而谈，等同于把Skill规定的步骤走了一个过场，内核依然是空壳。比如scope_breakdown要求它列三条核心问题，它列了，但问题完全不经大脑：“这个行业是否有竞争力？”“此公司是否存在风险？”——这种问题没有任何信息量。
我最后解决这个问题的方法是：不依赖习惯，而是强制校验。我在规则文件里加了一条明确要求：
每一步骤的输出必须包含可直接用于下一步操作的信息。若缺失关键字段（如具体数值、明确数据来源、可验证时间节点），视为执行失败，必须返回步骤一重新执行。
然后把scope_breakdown这个环节的输出格式从“自由段落”改成了结构化字段。模型没法再对着空气提问，每一行都要填具体主体、具体指标、具体时间。试想一下，让模型填“目标公司的应收账款周转天数下降的解释变量有哪些”，它就不能写“分析其应收账款质量”这种空话了，因为字段本身就是具体化的。
5.3 坑三：三个Skill互相抢戏，输出“四不像”
一开始我把三个Skill都塞在同一个提示词里反复强调，结果模型经常搞混：明明在研究开题阶段，就已经开始写反方观点；或者数据校验还没做，风险评估先跑出来了。整份报告结构混乱，看起来哪段的影子都有一点，但又没有一条章节是完整的。
后来我借鉴了微服务的思想，把三个Skill拆成了可编排的流程，而不是一股脑塞给模型。路由层先判断任务类型，然后决定先调用哪个Skill、哪个Skill的输出传给下一个。级联方式让每个环节职责单一，模型当前只需要聚焦一个任务，上下文压力和互相污染都显著降低。用大白话说，以前是让一个人同时干三份工作，现在是让同一个人按顺序干三份工作，虽然总工时没变，但每份工作的质量都上来了。
5.4 坑四：包装变好了，幻觉反而更难发现
这可能是最危险的一个问题：加了Skill之后，报告每一段都写得像模像样，有数据、有来源、有逻辑链条，于是你更容易放松警惕，把整份报告当作真实可靠的结论用。但实际上，如果底层数据是模型编的，包装得越专业，误导性越强。
我的应对方式是给小龙虾加了一个“证据留痕”的要求：每一处关键数据都必须在段落末尾用方括号标注数字来源编号，来源编号对应文末的“数据源与假设清单”。清单里每条数据注明出处（财报页码、公告名称、行业协会统计等）以及置信等级。模型如果找不到出处，就必须写“假设数据，待验证”。这个规则极大地提升了数据的可信度，因为模型知道如果所有数据都写着“待验证”，报告质量会崩盘，所以它会更努力地在上下文里检索真实存在的材料，而不是自由发挥。
这在产品上其实就是“诚实惩罚机制”：你编一个数据很简单，但你要为每一个编出来的数据提供一个看起来合理的来源和口径，难度就会指数级上升。模型在权衡之后，会倾向于选择已有的可信材料，而不是凭空捏造。
5.5 坑五：流程变长了，消耗和时间都涨了
最后是个现实问题：加Skill之后，小龙虾的推理链路从“直接写报告”变成了“拆题→检索→验证→写初稿→补反方意见→标注来源”，每一步都要反复消耗token。实测同一份报告，改造前大约用6万token，改造后涨到12万-15万token，延迟也从30秒左右拉长到两分钟以上。
如果只是偶尔用用，这个成本其实可以接受。但如果产品要对外开放，每次请求都跑全量流水线就太贵了。我的优化思路是给规则加“提前终止”条件，比如开题拆解中如果发现信息严重不足，就先返回用户确认信息，而不是硬撑着往下写；如果任务只是简报类分析，则跳过反方意见环节；如果数据源比较少，则允许适度简写数据校验部分。动态裁剪之后，短任务的成本降回原来的1.3倍，长报告的稳定高质量式分析仍然走全量流水线。
6. 从“能跑”到“能用”：我下一步打算怎么折腾
现在的“小龙虾”基本达到了我认为“能用”的水准，但我依然不打算停下。因为在实际运营中我已经看到了几个值得继续深挖的方向，这里也顺便记录下来，给有类似情况的朋友做个参考。
一个方向是给结论加可信度分级。目前的报告虽然会标注来源和假设，但读者还是很难一眼判断“这段是猜测，那段是事实”。我的想法是让Skill最后输出的时候给每个核心结论打一个置信度标签：高置信（直接数据支撑）、中置信（间接推断）、低置信（主观判断），并在分析要点里把“如果低置信结论被推翻，会如何影响整体判断”写出来。
另一个方向是让Skill具备自我循环能力。现在的流程是线性的：拆解→收集→验证→输出→反方意见→结束。但复杂任务往往需要多轮迭代，比如第一轮分析发现一个关键假设是错的，那后面的结论其实都要重新评估。理想情况是Agent在写完初稿后，自己扮演“挑毛病的评审员”，把反方意见反馈回初稿，修订后再出一版。这等于在流程里增加一个“内部回环”，让质量进一步提升。
不过我也意识到，Skill不是越多越好。文件过多会带来路由选择困难和相互污染，规则过细又会把模型的灵活性耗死，让它变成一本只会背流程的“死手册”。好的Skill应该像给分析师一叠检查清单，确保他不会漏掉关键步骤，而不是告诉他每一句话该怎么写。在可预见的未来，我最想打磨的不是加更多的新Skill，而是把现有的三个Skill之间的衔接做顺、把触发逻辑做精、把校验规则做得对用户更友好。
如果说这次折腾小龙虾给了我什么实质性的教训，那就是：想让Agent变得“高阶”，你要抓的不是它的智商，而是它的操作系统。智商是模型给的，操作系统才是你能改的部分。Skill就是这套操作系统里，你亲手写进去的那些制度和规矩，它们决定了一个聪明的家伙是被当成路人甲放走，还是被当成资深分析师重用。
