写一个 Skill 来优化所有 Skill —— autoresearch 的 Prompt 工程实践我最近一直在折腾 AI Agent 的自定义 Skill前后写了十几个用来处理不同场景的文本、做资料梳理、调格式。写多了以后发现一个问题每次新写一个 Skill都被同样几个毛病反复折腾——要么指令太笼统模型发挥不稳定要么约束太死换个输入就罢工要么输出结构跟实际需求对不上改来改去浪费大量时间。后来我换了个思路既然我已经踩了这么多坑为什么不把“怎么写好一个 Skill”这件事本身也做成一个 Skill让模型拿着这个元技能去审视和优化我所有的其他技能。于是就有了这套 autoresearch 的 Prompt 工程实践。它的核心逻辑很简单不再为每个任务单独调教提示词而是先把“调教方法论”定义清楚再让模型充当评审和重构者。这篇文章就是把完整做法拆开揉碎讲清楚适合那些已经在用 AI 工具、写过几个 Prompt 或 Skill但总觉得效果不稳定、想建立一套可复用流程的人。1. 为什么要造一个“元技能”思路源头1.1 写 Skill 的真正难点不在格式在视角市面上的教程大多在教“怎么写一个好 Prompt”比如给角色、给背景、给示例、分步骤。这些东西当然有用但当你批量去写 Skill 的时候会发现真正的瓶颈是“找不到自己的毛病”。就像写代码编译器能报语法错误但报不了逻辑漏洞写 Prompt 也一样语法全都对模型也理解了但生成结果就是不够准你自己根本看不出来是哪里带偏了它。我原先写过一个小工具类 Skill用来给技术文章提取摘要。起初的指令写得挺完整有角色定位、有输出格式、有长度限制。但实际用下来摘要里总是混入原文的长句而且经常漏掉结论部分。我调试了很久反复改措辞、加强调效果还是不稳。后来我把这段 Prompt 丢给自己的 autoresearch 技能去诊断它很快就指出了问题我虽然规定了“提炼核心观点”却没有规定“不要直接摘抄原句”也没有告诉模型“结论和实验数据优先保留”。这个视角是我站在“作者”位置上很难跳出来看到的。这就是元技能最核心的价值你不需要时刻保持“上帝视角”去审视自己的每一个 Prompt而是把审视的标准,提前写进一套规则里让模型替你执行。它比任何人肉 review 都稳定因为它每次都按同一套六维标准去检查不会受情绪和疲劳影响。1.2 “优化所有 Skill”的可行路径既然决定要让模型来做这件事接下来要回答的问题是怎么让“优化”这件事有章法而不是让模型漫无目的地“提建议”我的答案是分层抽象。把优化工作拆成四个层次第一层是意图匹配。你这个 Skill 到底要解决什么问题目标用户是谁输入是什么、输出要给谁用很多写失败了的 Skill问题根源在意图没想清楚写出来的指令自然东拉西扯。第二层是结构健康度。Prompt 内部有没有清晰的逻辑块角色设定是不是和任务匹配输出格式是否足够明确约束条件是分散各处还是集中管理第三层是边界意识。这个 Skill 哪些事情坚决不做输入超出范围时该怎么处理模型的自作主张空间应该有多大第四层是可评测性。你拿什么标准判断这个 Skill 改得好不好是可量化的格式合规率还是可感知的语义准确度autoresearch 的做法是把这四层抽象转换成一份固定的检查清单再配合“诊断—推测—重构—校验”四步流程来执行。这样每一次优化都不是凭感觉而是有据可循的结构化操作。2. autoresearch 的核心设计与分工2.1 模块划分先诊断再重构这套元技能在结构上模仿了一个资深编辑的工作方式先通读全文找问题不急着下笔改等诊断列表足够清晰了再动手重写。所以它包含四个阶段阶段一诊断。读取输入的旧 Skill 全文按固定维度打分并列出问题点。这里的关键是诊断必须输出“现象 原因 证据”不能只说“你的 Prompt 不够具体”这种空话。比如要指出“角色设定与任务目标错位你设定了一位资深编辑但后续指令全是数据清洗规则角色完全没有被调用”这才是有价值的诊断。阶段二推测。针对每个诊断出的问题推测它可能导致的实际行为偏差。这一步是为了让修改方向有依据——你改这一处到底是解决什么问题我曾经优化过一个数据整理类的 Skill原版本规定“去除重复项”但没说“基于哪一列去重”。推测阶段指出这会导致模型随机选择保留哪一行数据量大时甚至可能出现前后两次运行结果不一致。有了这个推测修改方向就非常明确了。阶段三重构。把诊断和推测转化为具体的改写动作。不是零散地修修补补而是直接生成一份新的 Skill 全文。重构时坚持三条原则保持原有功能不变只消除问题所有新增的约束必须写清理由输出格式如果不能精简到位宁可不用表格也不用代码块。阶段四校验。把新生成的 Skill 按同一套六维标准重新打分确认没有为了修一个问题而引入新问题。这一步很多人会跳过但实际上它恰恰是确保优化质量的关键闭环。我自己实测下来加了校验环节之后生成的 Skill 后续需要人工二次修改的次数大概减少了六成。2.2 请求字段设计为什么必须让“需求意图”独立成项在设计 autoresearch 的输入结构时我一开始只是简单地把旧 Skill 原文丢进去然后让模型“看看哪里能优化”。结果很不理想——模型要么只改格式不动实质要么过度发挥把原本好用的部分也改掉了而且不同运行之间给出的优化方向差异很大。后来我梳理了一下发现问题的根源在于模型缺少足够的上下文来理解“这个 Skill 到底服务于什么场景”。同一个 Skill如果用途是给内部团队快速出草稿和给面向客户的内容做初筛优化的重点完全不同。没有这个背景信息优化方向必然发散。所以我重新设计字段结构核心是让“需求意图”独立成项和 Skill 原文分开传入。完整字段包括context这个 Skill 的使用场景、目标用户、交付物是什么。legacy_skill旧的 Skill 全文通常是直接从文件里复制出来的原始 Prompt。known_pain_points作者已经注意到的问题列表不需要修全漏了也没关系。opt_targets本次优化的优先级比如“优先让输出更稳定”“优先保证不歪楼”“优先压缩长度”。为什么必须让需求意图独立出来因为模型在不同场景下对“好 Prompt”的定义不同。新闻摘要和代码注释生成判断标准显然不一样。如果不把这个背景讲清楚模型只能依据一套通用标准来改改完之后的 Skill 也许结构更漂亮但用起来还是别别扭扭。这个字段独立出来之后相当于给优化过程定了基调所有后续判断都围绕它展开不再跑偏。2.3 评估维度设计六维评分背后的取舍优化效果不能只靠感觉衡量所以我给 autoresearch 内置了一套六维评估体系。每个维度 1-10 分既有量化指标也有语义判断。角色契合度角色设定是否被真正服务于任务还是仅仅作为装饰。指令清晰度模型是否明确知道每一步要做什么、产出物是什么。边界明确性它是否知道自己的职责范围什么不该做、超出范围怎么办。输入鲁棒性面对不同格式、不同长度的输入是否都能稳定处理。可评测性生成结果能否被客观检验不是靠“感觉对不对”。可维护性后续如果要调整参数或扩展功能改动成本高不高。设计这六个维度时我特意剔除了“语言优美程度”这类主观指标。因为 Skill 不是拿来朗读的它的存在意义是稳定地产出符合要求的结果。语言再漂亮如果行为不稳定这个 Skill 就是失败的。这六项里我自己最看重的是可评测性。一个 Skill 哪怕角色设定和指令措辞都好如果评判它好坏只能凭主观感受那后续优化就无从下手。3. 手把手实现一个最小可用版本3.1 准备工作与设计思路导图在动笔写指令模板之前我把整个 autoresearch 的处理逻辑画成了一张流程草图。整个流程分四条并行通道输入解析、诊断分析、重构生成、自检校验。其中诊断和重构是两个核心节点后续写指令模板时所有内容都要围绕这两个节点展开。实际落地时我建议把它做成一个独立的文本文件放在你自己的 Skill 管理目录下命名清晰一点就行。整个模板包含四个区块初始定义、诊断指令、重构规则、校验清单。下面我会把关键部分的写法拿出来逐段讲完整模板可以直接复制去用。3.2 指令骨架与各分区写法先看初始定义区。这一段的作用是让模型进入“评审者”角色同时明确任务边界。我的写法是# Role: Skill Prompt 评审与重构专家 你负责对一个给定的旧版 Skill 进行诊断、评估并重构目标是产出更稳定、边界更清晰、更易于维护的新版 Skill。 ## 工作原则 1. 面对旧版 Skill 中的任何内容你只做结构化诊断和重构不评判其历史优劣。 2. 你的所有修改建议必须基于“预设使用场景 六维评分标准”展开禁止空谈通用技巧。 3. 在重构结果中你需要保留旧版的所有正向能力只消除问题点。 4. 如果旧版信息不足以支撑某项判断在诊断结果中明确标注“信息不足”禁止臆测。写这一段时有个小技巧不要只写“你是专家”还要说明专家在这个任务里具体怎么表现。比如第 4 条“信息不足就标注、禁止臆测”这条能让模型在信息缺失时不被逼着瞎编实测能显著降低生成内容中无依据的“建议”。接下来是诊断指令区。我用了一段结构化输出格式来约束模型只允许它按以下模板输出诊断结果## 诊断输出模板 ### 一、总览 - 六维评分按 1-10 分制附带一句话理由 - 一句话总结该 Skill 当前最需要解决的问题 ### 二、问题清单 逐条列出发现的问题每条格式为 - 问题描述[一句话说清问题] - 证据位置[引用原文关键句或描述出现的场景] - 可能后果[这一问题在实际使用时会导致什么偏差] - 修改建议[针对该问题给出具体策略]这段的关键在于“证据位置”。我发现如果不强制给证据模型写出来的诊断会非常泛化说辞一套一套但根本对不上原文的毛病。有了“证据位置”这个字段模型就必须回到原文去定位具体语句诊断质量立刻上一个台阶。然后是重构指令区。这是整套模板里最需要细心调教的部分。重构有三条铁律## 重构规则 1. 每次对旧版所作的任何修改都要在“变更说明”中注明动机即这一改动针对的是诊断清单中的哪个问题。 2. 如果旧版中的某段内容在诊断阶段被判定为“信息不足”在该段旁边以 [待补充] 标记不擅自代写具体内容。 3. 重构后的结构应该让一个从未读过旧版的新用户也能直接使用不依赖旧版作为上下文。第 3 条特别重要。很多模型在重写时喜欢做“修补式修改”读者必须对照旧版才能理解新版在说什么。这在单个 Prompt 调优时问题不大但如果你把 Skill 打包分发新用户根本不会去看旧版重构出来的东西必须能独立成立。最后是校验清单也就是模型在输出重构结果时需要同步给出的自检报告## 输出校验清单 - [ ] 新 Skill 是否在使用意图上与旧版一致 - [ ] 六维评分中是否存在优化后反而下降的维度 - [ ] 所有修改是否都有诊断依据 - [ ] 重构后的结构是否完全脱离旧版也能理解和使用这四条分别对应意图保真、整体提升、逻辑闭环、独立可维护四个优化目标。四项全过才允许作为最终输出。3.3 一条旧 Skill 优化前后的直观对照为了让你更直观地感受差别我拿自己旧版的一个 Skill 做了简单示例。这个旧版原本是一个“文章要点提取”工具优化前长这样你是资深编辑请阅读下面的文章然后提取出文章的要点和结论最后输出摘要。 文章是{input}问题很明显角色没被调用指令过于泛化没有输出结构约束没有边界说明。模型可以自由发挥结果是十个字和五百字都可能算“摘要”。用 autoresearch 的重构指令跑一轮之后新版变成了这样# Role: 技术文章要点提取器 你负责从给定的技术文章中提取结构化摘要服务于需要快速获取核心信息的研发人员。 ## 输入与输出 - 输入技术文章全文可能包含代码片段、图表描述、实验数据。 - 输出Markdown 格式的结构化摘要包含核心结论、关键数据、适用边界。 ## 提取规则 1. 核心结论必须显式单列优先保留原文出现次数最多的明确判断。 2. 关键数据包括评测指标、运行耗时、性能提升幅度保留精确数值和单位。 3. 如果文章包含代码级实现细节提取时只保留接口特征不展开算法推导。 4. 不摘抄原文长句所有要点必须用自己的语言重新组织。 5. 如果原文缺少足够信息支撑要点提取在对应条目处标注 [信息不足:原文未提及]。 ## 输出示例 ### 核心结论 不超过三句话 ### 关键数据 - 指标A数值区间 - 指标B提升幅度 ### 适用边界 该结论成立的前提条件或已知限制 ## 边界声明 本 Skill 只处理技术类文章不处理小说、新闻评论或非技术类文本若输入内容为空直接输出提示并停止生成。这个对照可以很直白地看出“结构化”和“泛泛而谈”的差别。新版每一段指令都对应一个明确的判断依据模型执行起来稳定得多而且后续如果要微调改动点也非常聚焦。这里要说明的是上面这个旧版是比较极端的“新手画风”现实中很多人的旧版 Skill 没这么简陋但带病结构是类似的——角色悬空、边界缺失、约束分散。4. 用起来之后踩过的坑与排查实录4.1 常见问题速查表这套方法用了小半年我攒了一批真实踩过的坑整理成表格方便照单排查现象可能原因排查思路优化后新版 Skill 风格和旧版差异过大重构指令中缺少“保留旧版表达偏好”的约束在重构规则里追加一条除非影响功能表达否则保留原 Skill 的句式习惯诊断出的问题很泛化像通用建议没有启用“证据位置”字段确认输出模板是否包含证据位置字段且此字段为强制项优化后的 Skill 偏离了原本用途需求意图字段为空或描述太模糊检查 context 字段是否写清场景、目标用户、交付物评分在优化后反而下降只改格式不实质改善或反向引入了更严格的边界查看校验清单状态如果产生回退可让模型在诊断中额外标注所有会产生副作用的修改点同一个旧 Skill 跑了两次修改方向完全不一致缺乏决策锚点模型每次都在“自由创作”给模型提供旧版实际运行一次后的错误输出作为“参考反例”锚定判断方向输出的诊断太长核心信息反而不突出没有约束输出长度或优先级在诊断模板中加入“按严重程度排序最严重的不超过三条”这里我想重点展开“同一个旧 Skill 跑了两次方向不一致”这个坑。一开始我非常困惑因为同样的 Skill、同样的输入两次运行给出的重构方案大相径庭一个偏保守一个偏激进。后来才想透模型本质是在做生成式判断如果没有一个“硬锚点”让它对标它当然会每次给出不同的“合理答案”。后来我给 autoresearch 增加了一个输入上限字段——把旧 Skill 实测中一次失败的具体输出原文作为“参考反例”传进去。这样一来模型不再是凭空判断而是对标“这个错误样本”来修改方向立刻稳定了。4.2 三条提高一次成功率的小技巧技巧一给“不改什么”单独建一个清单。我们习惯告诉模型“你要改什么”但常常忘了告诉它“什么不许改”。很多模型在重构时会把旧版里原本好用的细小设定也顺手改了比如某个特定的术语定义、某种偏好的措辞风格。给 autoresearch 增加一个preserve_list字段专门列出不可触碰的内容一次成功率能提升不少。技巧二明确让模型做“保守重构”还是“激进重构”。这听起来像废话但真的有很多人没在 Prompt 里区分这两件事。如果你的 Skill 已经基本好用只是局部不稳就指定“保守重构”让模型最小范围改动如果你是在搭新 Skill 找思路就允许它“激进重写”。我实测下来两个模式生成的产出质量都明显好于不指定模式的默认情况因为模型不必自己猜测你的意图。技巧三把旧版跑一次的真实错误输出作为反例放进去。这个在上面提到过但值得单独强调。模型看完错误输出之后它会非常精准地围绕“避免出现同一类错误”来组织新版指令这比任何抽象描述都高效。比如旧版摘要里漏了结论你把漏掉结论的原文和摘要一起丢进去新版里几乎必然会出现“核心结论必须显式单列”这类针对性约束。原因很简单具体的反例比一堆泛泛的建议更能锚定模型的判断。4.3 让元技能自己迭代自己既然这套方法的逻辑是“用方法论优化所有 Skill”那它自然也适用于优化它自己。我每迭代一个版本的 autoresearch都会把旧版和新版同时喂给它自己诊断观察哪些判断维度互相矛盾、哪些规则在实际输出中根本没被遵守。举个例子我在早期版本里写了一条“重构时必须保留旧版所有正向能力”这条规则方向是对的但它没有定义“什么叫正向能力”。后面做了一次自我迭代把这条规则细化成了“如果旧版包含领域术语表、特殊约定、特定输出结构这些内容必须在新版中原样保留”。同一个原则加上了“是什么”的具象说明模型执行起来就完全不是一回事了。我的习惯是每跑完一轮批量优化就把 generates 出来的新版 Skill 的特征回填进 autoresearch 的规则里。比如我观察到凡是被模型加了“输入为空时直接提示并停止生成”这个边界句的 Skill在实际使用中的误跑率都低了很多。于是这个句式就成了后续所有重构的默认加分项。这其实就是一种人工反馈——在模型的输出规律里提炼自己的方法论。时间长了这套元技能会越来越贴合你自己的使用偏好而不是一套放之四海而皆准的通用模板。5. 延展思考元技能思路能用到哪里去这套“优化所有 Skill 的 Skill”写完之后我最大的感受是它的意义不止于省时间而是改变了我和 AI 协作的方式。过去我总是在一个个具体的 Skill 里做微调思维是被动响应的现在我用一套方法论去审视所有 Skill思维变成了主动设计。这种从“做事”到“定义怎么做事的规则”的转变才是元技能真正的价值所在。我目前正在把这套思路扩展到一个更复杂的场景不是优化单个 Skill而是优化一整个 Skill 系统。比如一个文档处理系统里有采集 Skill、清洗 Skill、结构化 Skill、输出 Skill它们之间互相调用这时候单个优化就没用了需要把“衔接处”也纳入检查范围。autoresearch 正好可以扩展成一套系统级评审工具专门检测模块之间的接口是否顺畅。换一个角度说自动研究这件事本身也在变化。我最近在尝试给 autoresearch 加上外部查询能力——让它不光基于内部规则做诊断还能去检索当前社区里关于 Prompt 工程的公开讨论把新的方法论同步吸收进它的规则库里。这样一来它就不再是一个固定死板的方法论复读机而是一个可以持续生长、持续学习的技能优化系统。对于刚接触这套思路的人我的建议是先别急着追求一步到位。第一次写元技能能做到“每次按照同一套标准评估旧版 Skill 并按固定流程重构”就已经成功了。随着你的 Skill 越写越多、越用越熟再逐步往里面加维度、加反例、加模式切换。它最大的魅力就在于——写它的过程本身就是你在梳理自己的工作方式。