最近和几个泡在AI编程里的朋友聊天发现一个很有意思的分水岭多数人还在琢磨怎么调Prompt而已经开始跑通流程的人在聊Skill。不是说Prompt没用了而是只要你在同一个代码仓库里反复做代码审查、生成单测、补注释、做迁移就会发现每次重新组织提示词既低效又容易飘。Prompt是一次性的Skill是可以沉淀的。我自己的体会是AI编程时代的可复用技能核心就是把人从“反复描述需求”里解放出来把经验变成机制。这篇文章我会从踩过的坑出发聊聊怎么从Prompt升级成Skill以及如何设计一套真正能用的可复用技能框架。如果你只是偶尔让AI写一段代码片段那你用Prompt就够了但如果你打算在真实项目里稳定使用AI辅助开发想让新同事接手后也能用同一套标准干活或者想把自己摸索出的工作流固化下来那Skill一定是你绕不开的一环。不管是Claude、Codex这类代码工具还是Spring AI这类开发框架现在都在往“技能包”方向靠。下面这套设计框架是我在项目里反复打磨后沉淀下来的希望对你有用。1. 为什么Prompt不够用了1.1 Prompt的“一次性陷阱”先说说我最早是怎么用Prompt的。那时候我写代码遇到问题就把整段上下文、报错信息、相关文件往对话框里一贴再附上一句“帮我看看哪里有问题顺便给出修复方案”。一开始效果还行可时间一长问题就出来了第一每次都要从头重新描述需求上下文稍一变化结果就跟着变第二同一个任务换一个窗口、换一个模型出来的代码风格和质量都不一样第三Prompt本身没有任何结构AI只能把它当成一段自然语言来“猜”而不是当成需求来“执行”。最让我崩溃的一次是我把同一个审查Prompt复制到三个会话里让它们分别审查同一段代码结果一个说“逻辑没问题”一个说“有潜在死循环”还有一个直接建议重构。这哪是AI编程简直是在抽盲盒。后来我才想明白Prompt本质上是一次性对话的背景说明它不是系统不是规则也不是工具。它没有输入参数的校验没有执行步骤的编排没有输出格式的约束一切全靠模型“临场发挥”。很多人以为Prompt写得越长越细就越稳定其实不然。模型对长文本的注意力是有限的你的核心要求一旦淹没在几百行描述里反而容易被忽略。而且Prompt升级换代之后旧提示词很可能失效你要重新调优等于每次模型更新都要做一次“提示词回归测试”。我见过团队里有同事维护着一份20多条Prompt的Excel表每次模型一升级就哀嚎一片。这种玩法本质上是用人力对抗不确定性注定不可持续。1.2 Skill把“提示”变成了“程序”既然Prompt不稳定那怎么才能让AI稳定地执行一类任务我的答案是把它变成Skill。Skill是什么你可以把它理解成一个封装好的“程序”它有名字、有参数、有执行步骤、有输出格式、有校验规则。你的角色从“每次重新描述需求”变成“调用一个函数”传几个参数进去拿到一份结构化的结果。还是用代码审查举例子。Prompt版的写法是“请帮我审查这个文件重点看XX建议用YY风格。”Skill版则会在内部定义一套完整流程先读取指定文件再提取变更行接着按安全检查、逻辑错误、性能隐患、风格问题四个维度逐项扫描最后输出一份带严重级别、行号定位和修改建议的JSON报告。这个流程是固定的AI只是在执行它。就算换一个模型只要它读得懂Skill的指令输出的结构依然一致。Skill的另外一层价值是可以访问工具和环境。很多AI编程工具里的Skill并不是纯粹的文字提示它还包含了调用文件读取、命令行执行、代码搜索、测试运行等外部动作。这样一来Skill不再“闭着眼答”而是“先看再答”准确率自然高得多。实测下来我把代码审查从Prompt改成Skill之后误报率起码降了三成输出格式也稳定了后续接自动格式化、生成变更记录都顺了很多。1.3 什么样的场景真正需要Skill不是所有任务都值得做成Skill。我自己判断的标准有三条一是任务是否高频重复二是结果是否必须保持一致三是流程是否可以拆成明确步骤。比如代码审查、单元测试生成、接口文档生成、依赖升级检查、日志分析、SQL优化这些都很适合。它们每天都会遇到而且不同人做出来的结果差别很大正好可以让Skill来统一质量。反过来那些探索性的、需要大量人工判断的任务比如“帮我设计一个系统架构”“给我一个产品创意方向”就不太适合做成Skill。这类任务本身没有标准答案过于结构化的流程反而会限制模型发挥。你说你是为了复用其实是在复制偏见。一开始我总想把所有需求都塞进Skill后来发现一个铁律Skill是给“怎么做”建模的不是给“做什么”建模的。需求你还是要人来定技能负责把需求变成可靠的结果。如果你现在还在犹豫要不要上Skill我建议先从单个高频任务试起。挑一个你每周至少会重复三次的工作比如代码审查或者写单测花一上午把它做成Skill跑一周看看效果。你会发现真正难的其实不是写那个文件而是想清楚这个任务到底有哪些隐式步骤、哪些质量标准是团队默认的、哪些异常情况需要兜底。把这些显式化本身就值回票价。2. 可复用Skill的设计框架2.1 五要素模型让Skill不再“裸奔”我在项目里试过很多种Skill写法后来总结出一个稳定的五要素模型意图声明、输入定义、执行流程、输出定义、质量校验。这五个要素缺一不可少了任何一个Skill都会在各种边界情况下翻车。意图声明是告诉模型“这个Skill解决什么问题、在什么时候用”。它的作用不只是为了让模型理解更是为了让调度器判断要不要触发这个Skill。你写的意图越清晰AI编程工具里的路由就越准确。比如“审查代码”这个意图就太模糊我会写成“当用户要求对指定路径或PR变更进行代码质量审查并希望获得结构化风险报告时使用”。这样既不会和“代码解释”“代码补全”冲突也能避免被别的Skill抢走。输入定义则是明确这个Skill接受哪些参数。比如代码审查Skill需要接收目标文件路径、变更范围可选、审查重点可选、输出语言默认中文。你要规定每个参数的类型、是否必填、默认值是什么。我见过有人把输入定义写得像一篇文章反而把模型绕晕了。其实只要用类似JSON Schema的简洁结构描述就够了让模型一眼知道该填什么。执行流程是五要素里最核心的部分。你要把任务拆解成若干个有序步骤并且每个步骤之间要有明确的产物和检查点。比如审查代码我会拆成读取文件结构、筛选本次变更涉及的代码块、逐块进行多维审查、生成评分和问题列表、给出修改建议。每走完一步Skill都会要求模型先汇报中间结果再决定是否继续。这样做的好处是当某个环节出错时你能知道是卡在哪一步而不是等最终结果出来后一脸懵。输出定义要解决的是“交付长什么样”的问题。强烈建议用结构化格式比如JSON、Markdown表格、固定模板。模型对结构的遵从度比对自然语言高得多你给一个输出样例它就能照葫芦画瓢。质量校验则是最后一道闸门定义什么算合格、什么算不合格不合格时怎么处理。比如代码审查报告里如果出现“这段代码有问题”这种无定位的模糊语句我会要求模型重新输出必须包含文件路径和行号。没有校验的Skill等于没有闭环。2.2 写Skill要像写API元信息与声明式结构Skill和Prompt最大的区别之一在于Skill是“可被程序解析”的。所以你不能只写一段漂亮的自然语言还得给它配上元信息和声明式结构让工具能自动发现、加载、组合它。元信息至少应该包含名称、描述、版本、作者、兼容模型、依赖工具。其中名称和描述是给调度器看的版本和作者是给团队协作看的兼容模型提醒你跨模型时可能需要调整。我习惯把Skill描述控制在三句话以内第一句说干什么第二句说适合什么场景第三句说有什么限制。这样在工具列表里扫一眼就能知道用途。声明式结构指的是用统一的格式比如YAML、JSON或MarkdownFrontmatter来描述Skill而不是一段自由文本。我现在用的一种结构是这样的最外层是元信息接着是参数定义然后是步骤列表最后是输出样例和错误处理规则。这样写出来既是给人看的文档也是给机器读的配置。你甚至可以写一个简单的校验脚本在提交Skill之前先检查格式是否合法这比自己肉眼检查靠谱得多。我见过很多团队把Skill当成提示词来写洋洋洒洒上千字结果第一步就崩了。原因就是没有结构模型和调度器都识别不了。反过来如果你把Skill当成一个API接口来设计每个字段都有明确含义整个系统就能像微服务一样工作一个Skill的输出可以成为另一个Skill的输入大家按契约协作。2.3 四个设计原则别让Skill变成“巨无霸”光有框架还不够实际写Skill时有四条原则我几乎是死守着的它们帮我避开了不少坑。第一是单一职责。一个Skill只做一件事。很多人喜欢把“代码分析、生成单测、更新文档”全塞进同一个Skill表面上看很省事实际上模型在长流程里很容易跑偏而且出问题后很难定位。我宁可拆成三个Skill让用户自己决定调用链也不追求一个Skill包打天下。单一职责的Skill调试起来非常舒服因为每个环节你都知道预期结果是什么。第二是显式上下文。Skill内部要明确声明它需要哪些外部信息不能依赖对话里“隐式”的历史消息。举个反例如果我在审查Skill里写“请根据之前的讨论进行审查”那只要上下文一换Skill就废了。正确做法是在输入参数里显式声明需要“代码变更范围”或“相关Issue链接”。Skill的鲁棒性全靠显式。第三是可回退。每个步骤都要考虑“如果这一步失败怎么办”。比如读取文件失败是跳过还是报错模型返回的JSON格式不对是重试一次还是用容错解析Skill里最好给出一两个兜底分支让模型知道在异常情况下该怎么做。没有回退方案的Skill就像没有保险丝的电路小问题能烧掉整个任务。第四是可组合。Skill的输出尽量标准化这样才能被其他Skill复用。比如审查Skill输出JSON测试生成Skill就能读取这个JSON里的“文件路径”字段来决定给哪个文件生成单测。可组合性要求你设计时想清楚“下游是谁”而不是闭门造车。3. 手把手设计一个“代码审查Skill”3.1 从Prompt到Skill的完整升级路径这一节我们直接动手把之前只存在于脑子里的思路落到一个具体的“代码审查Skill”上。我的做法是先写Prompt再抽象成Skill因为Prompt是最快的原型工具能帮我们验证“这个任务应该怎么拆”是否靠谱。第一步先在对话框里用Prompt写一版完整审查流程明确要读哪个文件重点看哪几类问题输出格式是什么。跑几个样本后你会发现有些描述是反复出现的那些就是候选的“固定步骤”有些描述会因为输入不同而变那就是“参数”。比如“重点看安全和性能”会变“先确认代码能编译”不会变后者就可以固化成前置条件。第二步把Prompt里的固定部分提取出来写成一版带占位符的Skill描述。比如将“请审查 {{file_path}} 的代码重点关注 {{focus_areas}}”作为主模板再补上步骤、输出格式和校验规则。这一步很关键因为你开始用变量的角度去重新审视需求了。一旦你发现某个信息在所有场景里都相同就该考虑在Skill内部写死而不是让用户每次都填。第三步将Skill放到实际的AI编程工具里运行收集失败样本调整步骤。这一步往往耗时最长因为模型不是你肚子里的蛔虫你得一遍遍告诉它“这里太模糊”“那里没给行号”。好在我发现只要你把校验规则写得够硬模型就会努力去满足硬约束而不是自由发挥。最终你会形成一版真正稳定可用的Skill这时再把它提交到团队共享目录。3.2 一个可以直接抄的Skill结构示例下面是我现在用的代码审查Skill的简化版结构你可以直接参考。我用YAML格式写因为可读性比JSON好而且能被大多数AI编程工具解析。name: review_code description: 当用户要求审查指定路径或PR变更的代码质量并希望获得结构化风险报告时使用。 version: 1.4.0 author: your_name compatible_models: - claude - codex - deepseek parameters: file_path: type: string required: true description: 要审查的代码文件路径或目录路径。 focus_areas: type: string required: false default: 安全,逻辑错误,性能,可读性 description: 审查重点用逗号分隔。 output_lang: type: string required: false default: 中文 steps: - step: 读取文件结构 action: 使用工具读取 file_path 对应的文件内容如果路径是目录则列出所有代码文件。 check: 必须确认文件存在否则返回错误提示。 - step: 提取变更块 action: 如果提供变更范围则只提取变更涉及的行段否则提取文件中的核心函数和主要逻辑。 check: 提取范围不得超出文件实际行数。 - step: 逐块审查 action: 按 focus_areas 对每个代码块进行扫描记录问题描述、行号、严重级别、改进建议。 check: 每个问题必须包含定位禁止“代码有问题”这类无定位表述。 - step: 生成报告 action: 输出JSON格式报告包含文件路径、风险计数、问题列表、总体评价。 check: JSON必须能被标准解析器解析。 validation: - 如果问题列表为空需要说明“未发现明显问题”而不是直接结束。 - 如果文件无法访问输出错误信息不要编造内容。 - 如果模型发现自己在某个步骤中信息不足必须停止并询问用户补充参数。 output_example: | { file_path: src/main.py, summary: 发现2个高风险问题, issues: [ { severity: high, line: 45, message: 用户输入未做白名单校验存在注入风险, suggestion: 使用参数化查询或严格校验输入格式 } ] }这个结构看着不复杂但每一个字段我都踩过坑。比如compatible_models在决定用哪个模型跑Skill时特别有用有些模型对工具调用的理解不行就得在描述里额外补一句“如果无法读取文件就根据用户粘贴的代码文本审查”。再比如validation里的“信息不足必须停止询问”这能防止模型在缺少文件内容时瞎编。这些都是纯Prompt时代不会去想的事。3.3 计算Skill参数上下文窗口与代码裁剪很多人在设计Skill时候忽略了一个硬约束上下文窗口是有限的。你以为给了模型一个完整文件路径它就能优雅地读完整个项目其实不行。很多AI编程工具的上下文窗口也就几十万token如果Skill一次性把所有文件全塞进去还没开始审查就爆了。我自己会做一个简单估算。假设团队里一个普通的Python文件是3000行平均每行80个字符大约就是24万个字符。中文字符在tokenizer里大概每个字符消耗0.6到1个token英文则可能每4个字符一个token。按最保守算3000行代码加上注释可能直接吃掉8万到12万token这还不算Prompt本身和其他上下文。结论就是代码审查Skill不能“全文读取”必须裁剪。怎么裁剪我的方案是在Skill里加一个预处理步骤先通过工具获取文件的函数级结构比如函数名、行号区间、参数列表然后只把目标函数或变更行段塞给模型。如果文件实在太大让模型输出“文件结构摘要重点函数全文”再结合静态扫描结果出报告。很多情况下尤其是审查PR变更时你根本不需要全文只需要看diff。所以你会在上面的Skill结构里看到我在“提取变更块”步骤里加了如果提供变更范围则只提取变更涉及的行段。这不是可有可无的优化而是保证Skill在真实项目里不“超额消费”上下文的关键。设计任何一个Skill之前先花两分钟估算一下它的典型输入会有多大再决定要不要加裁剪步骤。很多人第一次写Skill效果很好第二次换个大型仓库就完全失灵多半就是栽在这一步。3.4 用真实代码反复测试攒一份回归集Skill写出来只是开始真正让它变稳的是测试和迭代。我的习惯是为每个Skill准备一个小型的回归测试集里面有5到10个典型输入覆盖正常情况、边界情况和异常情况。比如代码审查Skill我会准备一个安全漏洞明显的文件、一个性能问题集中的文件、一个文件不存在的路径、一个超过上下文窗口的大文件、一个只含几行代码的最小文件。每次调整Skill结构或步骤描述之后我都会把这组回归测试全部跑一遍对比输出报告的质量。你会发现有时候你为了修一个“报错不清晰”的问题会把另一个场景搞得“该说的不说了”。回归测试集就是让你及时发现这种副作用。我建议把测试集放在Skill同目录下的examples文件夹里并且每个测试都写一个README说明这个用例覆盖的是什么场景、期望看到什么结果。这个过程中你会发现模型对Skill描述的遵从度不是一次到位的。第一次跑它可能完全忘了输出JSON第二次跑它输出了JSON但缺少行号第三次跑它终于符合校验了但报告内容空洞。每修一次你就离“可复用”近一步。等到你在多个模型上跑完还依然稳定这个Skill才算真正成熟。4. 存储、分发与团队复用4.1 目录与命名规范让Skill能被人找到Skill有了接下来是怎么管理。如果只放在自己电脑的某个文件夹里那不叫可复用叫自我安慰。团队协作场景下我强烈建议把Skill当作代码一样管理起来要有目录规范、命名规范、版本规范和维护文档。目录结构方面我习惯这样组织skills/ review_code/ SKILL.md examples/ case1_python_injection/ case2_large_repo/ tests/ run_tests.pySKILL.md是Skill的主体描述examples放回归测试输入和期望输出tests放自动化校验脚本。这样无论是人还是AI编程工具只要扫描skills目录就能发现可用的Skill不用到处翻文档。命名上我强调两个原则一是动词开头比如review_code、generate_test、migrate_schema一看就知道是干嘛的二是避免太宽泛的词比如code_analyze就太模糊我建议用review_code因为“分析”太笼统而“审查”隐含了质量评估的意图。名称最好和元信息里的name对齐避免文件名和Skill名不一致导致调度混乱。还有一个容易忽视的细节Skill描述里不要用“最好”“尽量”这类模糊词。你是在写配置不是在写作文。把“尽量输出JSON”改成“必须输出JSON并且用标准解析器可解析”模型执行起来才会不打折扣。团队里如果有人写Skill时描述模糊AI工具调度成功率会肉眼可见地下降。4.2 版本更新与变更记录Skill作为可复用资产版本管理比普通文档更讲究。我的做法是给每个Skill维护一个版本号同时保存一份CHANGELOG记录每次版本迭代的动机和结果。版本号用语义化版本大版本升级代表整体流程变了中版本代表新增步骤或输出结构变化小版本代表措辞修正和参数调整。为什么要这么严格因为很多AI编程工具在加载Skill时是有缓存的。你改了Skill文件但没有更新版本号工具可能还在用旧的。就算工具没有缓存团队里其他人也会困惑这份Skill到底是不是最新的我见过最典型的事故是一个人把Skill改了后忘了更新版本号另一个人在不知情的情况下用旧版本跑了一整天最后产出的报告格式全对不上。用Git管理Skill文件每次变更都走Pull RequestReview的时候重点看版本号和描述有没有同步更新。还有一个好习惯每个Skill在CHANGELOG里写明“兼容模型”的变化。比如上次在Claude上表现很好但换成某个新模型后输出结构变了你在CHANGELOG里记下来下次切换模型时就能提前知道风险。我自己还会在CHANGELOG里记录每个版本的“已知问题”这样别人接手时不用重新踩坑。4.3 跨项目迁移与团队共享Skill要真正发挥价值就得能在多个项目之间迁移复用。我团队现在的做法是搭了一个内部的skills仓库里面按领域分了几个目录代码质量、文档生成、数据分析、运维诊断。每个项目只需要在自己的配置里声明要使用哪些SkillCI流程会自动把对应Skill加载到AI编程工具里。跨项目迁移时要注意两个问题一是项目语言和框架的差异比如Python项目的代码审查Skill未必适合Java项目。我的解法是在Skill参数里增加language和framework两个可选参数默认按通用规则审查用户传入具体语言时则增加对应规则。二是外部工具依赖差异比如Skill里用到了Python的静态分析工具那在Node.js项目里可能就得换一种实现。这些都是设计Skill时要考虑到的可移植性。如果你不想搞一整套基础设施也有轻量方案把Skill文件直接放进项目仓库的.skills/目录里让AI编程工具自动发现。这样每个项目都自带一份“团队默认技能包”新成员clone完代码工具初始化时就能加载这些Skill不需要额外安装。这个方式我实测很稳尤其适合没有专职运维团队的几个人小组。4.4 在主流AI编程工具里的集成经验不同工具对Skill的支持程度不一样我踩了一圈的结论是不要为了用Skill而用Skill先看你的工具支持哪种格式。Claude系的Skill通常强调自然语言的工作流描述你可以在里面定义清晰步骤和校验规则它更倾向于“读”你的Skill文档。而Codex这类工具会更依赖文件读取和命令行执行它的Skill更像一个可以运行的脚本组合你需要明确告诉模型可以调用哪些工具。Spring AI从某个版本开始也引入了Skill或者叫Tool的概念它会加载一个带注解或者Schema的类然后把方法注册给模型。这让我更加确定一个趋势将来Skill就是AI应用里的“插件”。你在Java或Python里定义好函数模型在对话中自主决定调用哪个。这种模式对格式和元信息的规范性要求更高你必须把参数类型、业务含义、返回结构都写清楚否则模型根本不会调用。还有一个特别实用的经验你的Skill最好在文档里同时提供“人类可读版”和“机器可读版”。人类可读版给团队成员看解释这个Skill的适用场景和局限机器可读版就是上面的YAML/JSON给工具调度用。两者含义必须保持一致。我见过很多人只写了一个机器可读版结果团队里其他人根本看不懂也不会用Skill的复用率自然上不去。5. 常见问题与排查技巧实录5.1 Skill不生效没被调度怎么办这是新手最常见的问题明明把Skill文件放对了位置描述也写了但对话时怎么都不触发。我开始也被这个坑过后来排查出了一个套路。先看Skill的元信息尤其是name和description很多工具是根据用户问题里的关键词来匹配Skill的。如果你的描述写得太学术比如“针对代码质量问题进行多维度的结构化分析”用户说一句“帮我看看这个文件”工具根本识别不到。解决方法是把描述写得“口语化”一点因为用户的输入通常是自然语言不是工程术语。我会在描述里故意加入几个容易触发的同义词比如“审查、检查、看看、有没有问题”这样匹配成功率立刻高了不少。第二个排查点是确认工具是否默认加载了你的Skill。有些AI编程工具需要你在设置里手动启用技能商店或某目录没有启用的话文件放得再对也没用。第三个排查点是看有没有其他Skill的description跟你的冲突。如果两个Skill都说“负责代码质量问题”调度器就会随机选一个你会觉得自己的Skill“时灵时不灵”。这时候要么调整描述让职责更专一要么在自己的Skill描述里补充“当用户提到PR变更、代码行号、风险报告时优先使用我”。这一步其实就是把路由优化做到位了。5.2 输出结果不稳定格式来回变Skill执行时输出不稳定是另一种高频事故。明明校验规则里写了“输出JSON”结果模型有时候正常有时候却给你Markdown表格。我后来发现问题往往出在“你给的例子不够明显”。模型很擅长模仿所以输出样例必须放在离步骤描述最近的位置而且尽量给正面和反面两个例子。只给一个正面样例模型可能不知道别的写法是错的。另外我会在validation里增加一个明确的“格式失败后的行为”如果输出不是标准JSON模型应当自我纠正一次。很多模型其实具备自我纠错能力你只要显式告诉它可以回头修改它就会真的再试一次。没有这个指令它往往就直接提交一个半成品给你。还有一个容易被忽略的点模型对“引号”和“八股文”特别敏感。如果你的Skill描述里写着“请用专业的语气”模型可能会生成一堆“总体来看”“综上所述”的废话把真正的结论淹没。所以我现在的Skill描述里都会有这么一条“输出时不允许出现总结性空话每个问题必须落到具体位置和修复建议。”这一条能明显提升报告的信息密度团队里所有人看着都舒服。5.3 上下文爆炸还没跑就报错大型代码仓库是最容易让Skill“翻车”的地方。前面已经算过一个3000行文件就可能吃掉十万token如果Skill还同时读取了多个文件上下文直接爆掉。这个问题最好的解法是从设计上优化而不是等报错后再删。我已经在代码审查Skill里内置了“变更块提取”和“函数级摘要”两步。更极端的场景比如审查整个PR的几百个文件我的办法是让Skill先根据文件修改统计生成一个“疑似重点文件清单”接着只对清单里的文件做深入审查最后把其他文件的结果合并成一句话“检查了其它N个文件未发现高风险问题”。这样既保证重点不遗漏又不会耗尽上下文。如果你使用的工具支持外部工具调用也可以让Skill自己调用“文件摘要工具”把长文件压成一两百字摘要后再进入审查流程。实测下来这种方式能把上下文占用减少六成以上而且在审查大仓库时准确率并没有明显下降。关键是你要在Skill里明确写清楚“对于超过500行的文件必须先调用摘要工具”否则模型还是会选择简单粗暴地全量读取。5.4 去AI味让Skill生成的文本更自然最后聊一个很多人关心但Skill里比较少提的话题怎么让AI生成的内容不那么“AI”。我刚开始给团队做技术方案文档的Skill时产出老是有“首先、其次、最后”这种骨架感看多了就腻。后来我在Skill的规范里加了一条“在输出段落之间建立自然的逻辑连接尽量避免使用官方报告式的过渡词”。结果虽然不能完全消灭八股味但至少比之前自然多了。具体操作上我会在Skill的output_example里直接给一段“有呼吸感”的范文。模型对样例的模仿能力很强你给一个风格具体的样例它就能输出类似的风格。另外我会在validation里增加“软校验”条目比如“检查是否存在‘总而言之’‘综上所述’“不断提升”这类高概率模板短语如果出现先用同义词改写一遍”。注意这属于软校验不是硬性失败因为有些场景确实需要总结句。去AI味这件事本质还是你在Skill设计里投入了多少心思。一个只有干巴巴指令的Skill产出自然干巴巴一个连样例、禁区、风格提示都设计好的Skill产出才能像人写的。我个人的经验是把你想让AI输出的语气直接写进样例比写一百句“请自然一点”都管用。我自己在把一堆Prompt沉淀成Skill的过程中最大的感触是设计Skill本质上是在做工程化而不是在写提示词。你不再追问“这句话怎么说AI才能懂”而是要问“这个任务到底需要什么输入、经过哪些步骤、输出成什么样才算合格”。这些想清楚了Skill自然就有了灵魂。如果你正卡在“提示词总是不稳定”的困境里不妨挑一个最重复的任务按上面的框架做出你的第一个Skill。跑通一次之后你会发现自己再也回不到靠Prompt裸奔的日子了。