最近我一直在折腾Claude Code的skill能力起因是一个特别具体的烦恼每次遇到技术选型我习惯性打开AI助手问一圈得到的答案永远都是“综合考虑团队情况后决定”。这话听着没错但等于没说。真正决策的时候我需要的不是一份利弊清单而是一个敢拍板、能兜底、甚至会泼我冷水的顾问。于是我用Claude Code的自定义skill做了一件事把历史案例和心学智慧塞进它的提示词体系让它从“信息整理器”变成“智能决策顾问”。这个项目做完之后效果比我预想的好很多——它不是帮你消除不确定性而是帮你把不确定性变成可执行的行动。这篇文章就给你完整拆一下这个skill的思路、数据设计、提示词写法和踩过的坑。1. 项目准备这个Skill到底要解决什么问题1.1 为什么AI给了一堆方案你却还是不敢拍板我遇到的情况大概长这样项目要做跨平台系统的技术选型原生开发质量稳但周期长跨端框架出活快但后续风险不可控。我把这个问题丢给Claude Code它很快就列出了五六种方案还附带了各自优缺点和适用场景。问题在于当我追问“那到底选哪个”的时候它永远会回到那句安全话术“请根据团队实际情况权衡”。这句话就是典型的决策回避。AI不是没有分析能力而是它的训练目标倾向于“稳妥、全面、不得罪人”所以它天生害怕替你下结论。但对一个被deadline追着跑的开发者来说最值钱的恰恰是有人替你承担那句“就选这个出问题我负责”的压力感。哪怕这个“人”是AI只要能给出明确的倾向和可验证的假设也能把我从纠结状态里拽出来。这个痛点可以拆成三个具体问题第一AI只会罗列选项不会做判断第二AI给出的建议没有参照系你不知道历史上类似场景是怎么处理的第三AI的建议停在“分析”没有落到“下一步动作”。我想做的这个skill就是同时解决这三个问题。1.2 为什么选择Claude Code作为载体我做这个项目之前也考虑过去写一个独立的Web工具甚至搭一个决策树系统。但后来发现真正高频的决策场景根本不在浏览器里而在终端里——我写代码、跑测试、看日志的时候才是决策最密集的时候。Claude Code天然适合干这件事因为它是一个在命令行环境里工作的AI编程助手而且支持自定义skill。所谓skill本质就是一组结构化的提示词文件加知识库文件放在指定的目录里Claude Code在遇到匹配场景时就会自动加载。它相当于给AI装上一个“专项能力包”平时不干扰常规对话但一旦你抛出决策类问题它就会切换到专家的身份和流程来回答。这对我这种喜欢长期复用工作流的人来说太重要了。方案、规则、案例库一旦落成文件就可以像代码一样提交到仓库里做版本管理让团队其他人一起使用和迭代。它不像临时写一段prompt那样用完就丢而是能沉淀成组织资产。所以选Claude Code当载体不是因为它是功能最全的AI工具而是因为它让我可以用工程化的方式管理“决策咨询”这件大事。1.3 历史案例与心学组合的底层逻辑这个skill的核心组合是“历史案例”加“心学智慧”这两者看上去一个偏实证、一个偏哲学其实互补性非常好。历史案例解决的是参照系问题。面对一个新决策我们最大的恐慌是“这事没人干过”。但其实大多数决策都能在历史中找到相似原型哪怕时代变了、技术变了决策的结构还是那几个基本类型资源有限时保哪个目标、新老技术如何交替、短期收益和长期维护如何取舍。把这些案例结构化地喂给AI它就能像经验丰富的老前辈一样说“你这个困境历史上至少三次出现过当时的处理方式是……结果是好是坏……”这种基于样本的推理远比空泛的原则有说服力。心学智慧解决的则是行动力问题。心学传统里反复强调“知行合一”和“事上磨练”翻译成现代语言就是认知必须能转化为行动判断只有在实践中才能被修正。我把这些命题转译成决策前的检查项逼着AI在给出建议之后必须落到“第一步动作”同时用“反证思维”让AI主动挑战用户的倾向。这样整个决策闭环就从“分析-建议”变成了“分析-建议-行动-复盘”远离了纸上谈兵。2. Skill核心设计历史案例库与心学决策模型2.1 历史案例库的字段怎么设计才能不被AI用歪案例库是这个skill的食物来源。一开始我犯过一个典型错误只把案例写成一段段自然语言比如“某团队在技术选型中选择了渐进式混合开发结果不错”。这种写法最大的问题是AI在引用的时候会自由发挥经常把案例细节记错甚至自己脑补出当时并不存在的约束条件。后来我把案例全部改成结构化JSON字段固定语义清晰。一个完整的案例记录包含以下内容{ id: case-001, domain: 技术选型, tags: [跨平台, 周期压力, 渐进式], scene: 某跨平台系统需要在原生开发和跨端框架之间做选择, dilemma: 原生开发质量高但周期长跨端框架出活快但风险未知, options: [原生开发, 跨端框架, 渐进式混合], choice: 渐进式混合, rationale: 先用跨端框架快速验证核心链路再对瓶颈模块做原生化改造, outcome: 验证时间缩短40%核心模块在第二期完成原生替换, principle: 不要在小范围验证阶段就投入全局最优方案 }字段设计的核心思路是让AI能“按图索骥”。domain是领域告诉AI这个案例属于哪个决策场景dilemma是当时的两难困境这是匹配用户问题时最关键的一段options列出的是候选方案choice和rationale组合告诉AI最终选了什么、为什么outcome则用来供AI引用后果。最后加一个principle字段这是从案例里提炼出来的、可以迁移到其他场景的决策原则。这个结构最重要的地方是“纯客观记录、原则单独提炼”。案例文本里不夹杂价值判断所有“应该怎么做”的结论都放进principle字段。这样AI在引用的时候逻辑更清爽它有义务先陈述案例本身然后明确提出这个案例对应的原则而不是含糊地把案例和经验揉在一起瞎说。2.2 心学智慧的字面概念怎么落地成检查指令我知道“心学”这两个字出现在技术文章里很容易显得玄乎。但换个角度看它其实就是一套极其精炼的决策与反思方法论。我心学的东西了解得比较浅不敢说多专业但其中几个核心命题和现代决策理论完全是相通的可以转译成AI能执行的指令。这个skill把心学破成五个检查项我称之为“心学决策五问”第一问叫“处境勘察”。原文表述是“事有本末物有终始知所先后则近道矣”我直接把它翻译成提示词“在给建议前先定位用户最底层的困境剥离所有表面诉求。”这一步要求AI区分用户说的是“想要”还是“真正的约束”。比如用户说他纠结选哪个框架深层问题可能是人力不足、上线期限压得太狠框架反而是次要的。这一步逼AI穿透表面话题。第二问叫“诚于己心”。对应的是“致良知”的思想——人人内心本有判断是非的能力关键在于你诚不诚实地面对那个判断。转成提示词就是“请让用户诚实地写出自己心里已有的倾向不管它显得多不‘专业’。”现在很多决策模型喜欢让AI保持中立但现实里决策者心里往往已经有倾向了。与其掩饰不如让这个倾向暴露出来后续的判断才有靶子。第三问叫“反证审敌”。这来自“事上磨练”的警觉气质原义是在事务中磨炼心性我把它转成“针对用户倾向列出至少三个充分的反对理由并设身处地说明失败情景。”这一步其实就是结构化地唱反调防止AI为了迎合用户而给出偏颇的建议。第四问叫“行动落地”。心学最核心命题是“知行合一”在决策模型里我把它落地为“给出建议后必须提供接下来24小时内可执行的第一步。”这条我最看重因为它强制让AI从分析模式切换到执行模式。第五问叫“复盘回环”。这个来自“省察克治”的思路转成提示词就是“这个决策执行三天后应该观察哪些指标来验证判断正确与否”它让决策不止于决定那一刻而是形成持续修正的循环。2.3 决策顾问的标准输出模板先形后神为了让输出足够稳定我给这个skill设计了一套固定的输出格式。不是写在代码里的校验器而是写在SKILL.md里的指令模板。AI在触发skill后必须遵循这个结构我给它取了个名字叫“顾问意见书”。一个完整的输出包含七个部分决策类型判断先给问题定性是技术选型、资源取舍、还是战略方向让用户和AI站在同一坐标系。关键约束提炼把用户话语里的真实约束和虚假顾虑分开只保留影响决策的三到五个关键条件。历史参照引用案例库里匹配度最高的一个或两个案例陈述当时的选择、理由和结果提醒用户“你不是第一个遇到这个问题的人”。心学检查经过按“五问”逐一列出检查得出的结论。这一部分的价值在于过程透明让用户看到AI是怎么思考的。明确建议必须给一个确定倾向不能骑墙。哪怕AI判断证据不足也要说“现有信息下我更倾向A但需要追加一条信息来确认”。风险提示针对决策失败可能带来的代价做明示让用户对风险的感知前置。第一步行动给出24小时内可执行的具体动作精确到“在什么时间用什么方式做什么”。这个模板看着简单但真正落地时效果非常显著。一个刚用这个skill的人会明显感觉到AI不再像客服像一位带过兵的前辈在给你复盘作战计划。3. 从零搭建Skill完整实操过程3.1 创建目录结构与基础文件Claude Code的skill本质上就是一个约定好的目录结构。我这个项目是这样组织的~/.claude/skills/decision-advisor/ ├── SKILL.md ├── rules/ │ └── decision-check.md ├── data/ │ ├── cases/ │ │ ├── tech-selection.json │ │ ├── product-tradeoff.json │ │ └── refactor-decision.json │ └── principles.md └── prompts/ └── advisor-prompt.mdSKILL.md是技能清单文件描述这个skill什么时候被使用、怎么使用。rules目录放决策时必须遵守的检查规则。data/cases是历史案例库可以按domain拆成多个文件。prompts目录放主提示词模板。创建完目录之后最重要的是分清“哪些内容适合放在SKILL.md里哪些内容适合作为单独文件”。我的习惯是SKILL.md里只写“触发条件工作流程总览”把具体的检查规则和案例数据拆到独立文件里。这样后期维护时改一个案例不会干扰规则逻辑改规则也不会影响案例数据避免牵一发动全身。3.2 编写SKILL.md触发条件决定了它何时接管对话SKILL.md是整个技能的门面。Claude Code会根据description里的描述判断当前对话是否应当激活这个skill。我一开始souhaite写成“帮助用户做决策”这个描述太模糊导致很多不相干的话题也来触发烦不胜烦。后来我学乖了把描述写得非常具体加上大量决策场景关键词。我的SKILL.md开头是这样写的--- name: saga-decision-advisor description: 基于历史案例与心学智慧的智能决策顾问。当用户遇到技术选型、跨平台方案取舍、是否重构、优先级排序、资源分配等决策类问题或在多个方案间犹豫不定需要明确倾向时使用本skill。功能包括结构化困境定位、历史案例参照、心学五问检查、给出明确建议和行动闭环。 --- # 决策顾问技能 ## 使用流程 1. 复述用户困境确定决策类型。 2. 检索data/cases下最匹配的历史案例。 3. 按rules/decision-check.md执行决策检查。 4. 按prompts/advisor-prompt.md输出最终结论。这里有个实操细节普通用户不用记那么多字段语法SKILL.md的核心就是“描述清楚、举例到位”。描述里词写得越具体Claude判断触发的准确性越高。我在description里专门加了“技术选型、是否重构、优先级排序”这类关键词都是实际工作中高频出现的决策场景。效果是聊代码实现时skill完全闭嘴一旦抛出一个“到底选哪个”的问题它就自动切换角色。3.3 编写心学决策五问的具体提示词这是整个skill的魂。我用一个单独的文件rules/decision-check.md存放这套检查规则因为它的篇幅最长、最容易迭代独立成文件最方便单独修改。实际的内容结构是每个检查项都包含三块——心学依据、转译后的具体要求、输出示例。比如第一问这样写## 检查一处境勘察 心学依据所恶于上毋以使下所恶于下毋以事上。凡事要回到本原处看。 执行要求不要直接回答用户抛出的表面问题。先用一段话复述你认为用户真正面临的困境是什么。判断用户口中的“需求”是真问题还是伪问题。 示例输出 表面问题是“该选哪种跨平台方案”但按现有团队人力和上线时间看真正的约束是人手不足加验证周期短与其纠结框架不如先确定哪些功能必须首期上。我不想把这个文件里五问全文都贴出来占篇幅但强调一点每一条检查规则都必须配一个输出示例。没有示例的提示词AI执行起来非常飘有示例之后它才知道你要的“勘察”长什么样。这个经验是从多次试错里换来的——纯讲原则的提示词输出永远是抽象大道理配上示例才落得了地。3.4 构建第一个案例库从真实项目里提炼案例库刚开始不用多五到十个高质量案例就够用。最省力的做法是从自己过去一两年里遇到的实际决策里挖但要把项目和团队匿名掉只保留决策结构。举个例子。我处理过一个某知识管理工具的模块重构需求当时团队对“是否推倒重写”争论了很久。我把它整理成一个案例{ id: refactor-001, domain: 代码重构, tags: [存量系统, 维护成本, 重写vs修补], scene: 某知识管理工具核心模块有大量历史债务新功能难以在原有架构上叠加, dilemma: 重写可以解决架构问题但会停摆数月修补能维持业务但每做一个新功能都加倍痛苦, options: [完全重写, 长期修补, 抽取核心子域重写], choice: 抽取核心子域重写, rationale: 完全重写战线太长且风险不可控长期修补会继续积累坏味道选择将数据层改造为独立服务业务层逐步迁移, outcome: 新功能开发效率在第四个月开始改善首期迁移只覆盖数据层没有造成业务中断, principle: 重构不要追求一步到位把风险锁进最小范围再逐步扩张 }这个案例输入案例库之后遇到同类“重写还是修补”的问题时AI会主动引用它并提炼出“最小可迁移范围”这个原则。比任何泛泛而谈的重构理论都有说服力。我建议每个案例至少包含“价值判断、失败可能、迁移原则”三个维度这样AI才能从中学到真正的决策智慧而不是单纯复制答案。3.5 在Claude Code里加载并做第一次实测文件都放好之后要重启Claude Code让skill生效。这个步骤很容易被忽略我一开始也是纠结了半天发现为什么没触发结果就是没重启。挂载完成后我做了三个场景的测试。第一个是技术选型“我们准备做一套跨平台系统当前团队只有三个人三个月内要上线一个MVP原生和跨端方案怎么选。”这个skill立刻切换角色输出了“决策类型判断技术选型核心约束人力和时间”然后从案例库里调用了tech-selection相关记录最终给出了“渐进式混合”的建议并且落地到第一步动作“今天先列出MVP必须包含的三个核心功能第二天用跨端框架搭一个最小原型”。第二个测试是产品取舍“我们同时有两个新功能要做销售希望上A运营希望上B但团队只能做一个。”这个skill输出没有骑墙它直接指出“真实约束不是用户需求没价值而是验证成本。建议选A做小范围灰度因为它的成功指标更容易量化B放到下一迭代作为对照组。”说实话这个判断比我自己当时的思路还清晰。第三个测试是故意刁难型的“我想辞职创业你觉得行不行”这种脱离上下文宏大的问题skill输出得很警惕它没有直接说行或不行而是复述了处境不确定性给出了“用业余时间先做最小验证”的行动建议。虽然不是意料之外的惊艳但至少说明它没有在决策场景里继续当滥好人。4. 调参避坑与实战心得4.1 常见问题排查为什么它老不听话在实际折腾这个skill的过程中我遇到了一堆问题。有些是配置层面的有些是提示词层面的整理一个排查表方便你对号入座现象原因解决办法skill一直不触发SKILL.md里description写得太泛缺少决策场景关键词把“技术选型、是否重构、优先级排序、资源分配”等词加到description输出依然是罗列优缺点不给倾向提示词里没有“必须给出明确倾向”的硬性要求在advisor-prompt.md开头加一条“禁止骑墙必须给倾向”的强制指令输出像心灵鸡汤不接地气心学检查项只有原则没有示例每个检查项下补一个“示例输出”引用的案例库内容明显不匹配案例库没有domain和tags字段检索模糊在案例里增加domain、tags字段并在SKILL.md里约束AI按标签检索上下文太长经常超限case文件太大一次全塞进去按domain拆文件让SKILL.md指引AI按需加载建议了“第一步行动”但还是空泛输出模板里第一步动作没有时间约束强制规定必须包含“在什么时间、用什么方式、执行什么动作”这六条里最值得花精力调的是第一条触发问题。很多技能失效不是AI不行而是你把触发词写得太窄或太宽。太窄它就找不到入口太宽它就天天误触发。我最后调整的策略是描述里列出一组明确的“决策类动词”比如“选择”“取舍”“权衡”“要不要”等这些词一出现基本就是它该出场的信号。还有一个隐蔽的坑是示例文件的引用方式。我最开始把案例库数据直接粘贴进SKILL.md里结果每次对话加载都要吃掉一大截上下文还没开始分析就快爆了。后来我改成让SKILL.md只写“读取data/cases/xxx.json”Claude Code在实际需要时才读文件上下文压力一下小了很多。4.2 实测效果对比直问与用Skill咨询的差距为了验证这个skill确实有效我做了一次对照测试。同一个问题一份是直接打开Claude Code问另一份是让skill上线后问。这里展示一个简化版的输出对比。问题“我负责的某模块现在代码特别乱要不要重写”直接问Claude Code它的回答是先分析重写的好处是架构清晰、维护方便坏处是开发周期长、风险高建议先做代码评审如果测试覆盖率高可考虑重写否则逐步重构。最后来一句“建议结合团队实际情况决定”。用skill去问输出明显不同。它先复述困境“你表面在问重写实际在问如何在不中断业务的前提下降低维护成本。”然后引用案例库中refactor-001案例讲当时某团队选择了“抽取核心子域重写”在第四个月才见到效率改善。心学检查第二问它直接问“你心里是不是已经倾向重写了如果是请告诉我。”然后列出重写的三个反对理由。最终建议“选择抽取核心子域逐步迁移而不是全量重写。”第一步行动精确到“这周五之前梳理出该模块中变更频率最高的三个子域标记为迁移候选。”这个对照让我意识到直问AI得到的是一份资料skill得到的是一个咨询过程。它不是替你拍板但它会把拍板所需的所有信息组织成一条可执行路径并且不允许你继续在“要不要”里打转。4.3 三条血泪教训为什么你的Skill会越用越鸡肋我做过很多个Claude Code skill这个决策顾问是迭代次数最多的因为它在“灵活”和“稳定”之间特别难平衡。下面是三条最痛的教训每一颗都是踩完坑才长的记性。第一条心学内容只做“框架提取”不要做“话术包装”。我在最早版本里试图引经据典让AI在回答里大量引用心学原文。结果出来的东西玄之又玄用户看不懂实际业务也落不了地。后来我把所有哲学命题全部改成“检查动作”比如“致良知”变成“请用户诚实说出自己已有的倾向”。决策顾问不是传道者是帮人把问题想透的陪练。第二条输出模板越早固定越好最好一次定型。我前前后后改了很多版输出结构每改一次之前对话里的有效上下文就作废一次。后来我痛下决心把“顾问意见书”模板固定成七节后续只优化细节不再动骨架。这样做的好处是团队其他人用的时候看到的输出结构永远一致慢慢会形成阅读习惯和使用信任。第三条别让案例库变成大杂烩。我一度往里塞了一堆从书上看来的商业案例像什么“某公司渠道政策”这种结果领域差异太大AI引用的时候上下文跳跃严重反而把自己搞懵了。后来我把案例库收敛到“技术决策、产品取舍、重构方案”三个领域每个领域精编三五个案例质量立刻上去。案例库的黄金标准不是多而是每个案例都能提炼出可迁移的决策原则。5. 扩展方向与使用边界5.1 从个人决策到团队决策用顺了这个skill之后我开始把它推给身边的团队伙伴用。最初有个阻力——大家觉得在终端里问AI“选什么”不如开会讨论靠谱。但实际用了之后大家发现一个意外的好处它强迫每个人把决策理由结构化。以前讨论技术选型各说各话谁也听不见谁。现在每个人都被skill输出里的“关键约束提炼”“反对理由”“第一步行动”逼着往同一套语言体系里走讨论效率高了很多。我把这个skill的配置和案例库放进了团队的git仓库每个成员clone下来就能用。后续更新案例库时也不再只是我一个人的事大家都可以提交“决策记录”格式统一沉淀下来就是团队的决策史。5.2 案例库的运营循环让决策质量越来越高做这个项目时我最大的体会是案例库不是一次性建设它需要运营。每一次重要决策结束都应该回头把这个决策的原始困境、当时选项、最终选择和实际结果追加进案例库形成一个持续扩展的“决策样本池”。我会按季度做一次回顾把上一个季度实际产生的决策记录提炼成标准格式的案例然后删除那些泛泛而谈的旧案例。这个动作让这个skill越用越熟悉“我们团队”的决策习惯。它不是通用AI它越来越像一个熟悉你业务的内部顾问。5.3 这个Skill不适合解决什么问题虽然这个skill很香但它不是万能的。我给它划了几条边界写在了SKILL.md的末尾第一不适用于时间极短、信息极少的应急决策那种时候效率优先不需要深度推演第二不适用于情感色彩极强的个人生活决策它没有足够的人情感受力去共情第三不适用于合规性、专业性要求极高的判断比如法律意见或者医疗建议专业资质不是AI能替代的。很关键的一点是这个skill输出的是“决策参考”不是“决定者”。它最大的价值是让你想得更清楚、行动得更快但它不能替你承担选择的后果。我每次跟人推荐这个skill时都会加一句AI帮你降低了试错成本但背锅的还是你。从个人经历来讲这个项目的附带收获远大于预期。它让我第一次意识到Claude Code不只是一个能写代码的助手还可以被塑造成一个带有“性格”和“方法论”的工作伙伴。只要你把知识、案例、检查规则以工程化的方式喂给它它就能从一个被动应答的问答机变成一个主动替你排兵布阵的参谋。最后分享一个调参时的小技巧如果你不确定某个检查项该不该写进规则先把它放进去再准备一个一定会踩中的测试问题去试如果输出没有明显改善立刻删掉不要舍不得。少即是多这个道理在提示词设计里比在任何地方都成立。