企业官网建设流程全解析

写一个 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、同样的输入，两次运行给出的重构方案大相径庭，一个偏保守，一个偏激进。后来才想透：模型本质是在做生成式判断，如果没有一个“硬锚点”让它对标，它当然会每次给出不同的“合理答案”。后来我给 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 越写越多、越用越熟，再逐步往里面加维度、加反例、加模式切换。它最大的魅力就在于——写它的过程本身就是你在梳理自己的工作方式。