企业官网建设流程全解析

这个月我一直在跟一个叫 autoResearch 的“元技能”较劲。它做的事情听起来有点绕：写一个 Skill 来优化其他所有 Skill。起初我以为这只是个锦上添花的工具，真正把几十个技能目录翻出来批量跑过一轮之后，我才意识到它把平时靠感觉进行的 Prompt 工程变成了可复现、可回归的流水线。这不是一套泛泛而谈的优化心得，而是我在 Agent 工作流里维护技能包的真实实践记录。如果你也在维护一堆 Prompt、技能或工作流文件，这篇文章能帮你少走我踩过的那些弯路。

我日常的 Agent 环境里攒了二十多个技能：有处理会议纪要的，有做代码审查的，有辅助写技术方案的，还有生成周报的。它们形态各异，本质都是“输入一段指令或上下文，输出结构化的产物”。问题在于，技能越多，维护成本越离谱。你改了一个技能，另一个技能用同样的表述却保留着旧逻辑；你给这个技能加了示例，另一个技能因为没有示例而行为飘忽。于是我很自然地想：与其一个个手工修，不如让模型自己开一个“技能评审岗位”——给它一份技能源码，让它像资深工程师一样拆解、诊断、重写，然后跑回归。这个岗位，就是 autoResearch。

这篇文章适合三类人看：一是把 AI 当生产力工具、日常维护大量提示词的“提示词管理员”；二是做 Agent 工作流、想把提示词工程化而非靠手感打磨的开发者；三是对“用 AI 优化 AI 的输出”这个 Meta 概念好奇、想了解边界在哪儿的爱好者。我会把 autoResearch 的由来、结构化拆解方法、核心循环、一个完整的改造案例，以及使用它的三个大坑全部展开。最核心的一句话先放在这儿：优化 Prompt 的第一步，永远不是动手改文字，而是建立可诊断的结构。

1. autoResearch 的由来：为什么优化全部 Skill 之前，先写一个“元技能”

1.1 手动维护二三十个技能的真实痛点

技能这东西，写第一个的时候很简单：一段指令，两三个例子，跑一次满意就收工。写到第十个、第二十个时，问题就变了。我最常遇到的是三种情况。

第一种是风格漂移。同一个 Agent 环境里，不同时期写的技能风格完全不一致。早期技能喜欢用长段落描述流程，后期技能则习惯列 bullet 点和输出模板。风格本身没有绝对对错，但它们一旦混在一个工作流里，模型对“什么样的响应才算合格”就丧失了稳定标准。

第二种是触发边界模糊。有些技能写着“当用户需要帮忙总结内容时使用”，结果给模型带来的歧义非常多：它可能在处理代码问题的时候错误地触发总结技能，也可能在真正需要总结时不肯触发。边界描述不清晰，技能等于半残。

第三种是没有回归保障。我改一个技能，通常不会系统地给它设计测试用例。改完之后，可能仅仅靠一两个新输入验证一下，结果老场景被改坏了，新场景倒是满足了。这种“按下葫芦浮起瓢”的修改，几天后又反馈到我头上。

逼到一定份上，我开始接受一个反常识：维护大量技能，靠逐篇人工优化注定是不可持续的；真正划算的投入，是把“优化者”本身沉淀为一个技能。这就是 autoResearch 的雏形。

1.2 从“优化单个技能”到“优化全部技能”：关键的思路转变

普通 Prompt 优化，是分析师在看单份文档：改措辞、调结构、补例子。而 autoResearch 做的事情更像是建了条“技能质检流水线”：把每个技能当作一个待检产品，自动完成拆解、评估、改稿、回归，再输出诊断报告和新的技能包。

我用一个类比说服自己：手写汇编的时候，你顶多能优化一个函数；而当你写出编译器之后，才能批量优化整个工程。autoResearch 就是那个“编译器”——它能持续工作、遵循统一标准，而且不觉得重复劳动枯燥。

这个思路转变带来了三个直接收益。

• 评估标准统一了。以前我评价一个技能好坏全凭直觉，现在 autoResearch 每次都用同一份诊断清单，从意图清晰度、输出规范、示例一致性、失败回退等维度打分。标准一致，才有横向对比的可能。
• 把修复过程变成了可记录的任务。每次改造，autoResearch 都会输出“诊断→建议→修改→回归”的完整日志。我回头翻日志，就能看到这个技能演进的理由，而不是面对一团被反复魔改的文本。
• 人的精力被放在决策上。我不再逐字逐句抠措辞，而是看诊断报告、批准修改方案、抽查回归结果。自动化和人的判断各归其位。

1.3 autoResearch 不是什么：限定期望

有一点必须先说清楚。autoResearch 不是“把 Prompt 丢给模型，让它全面重写一遍”。我见过不少人把希望寄托在“让 AI 自动优化所有 Prompt”，结果模型把原本还能用的技能重写成了一堆华丽的空话。autoResearch 要做的是带约束的优化：保留原意、保持最小必要修改、给出证据支撑。它更像是一个严格负责的审稿人，而不是一个放飞自我的畅销书作家。

2. 先给技能建立“可解剖的分层结构”

为什么 autoResearch 能批量理解不同技能？前提是我把每个技能都拆成了统一的分层结构。没有这一步，模型每次看到的都是一段混沌文本，“诊断”无从谈起。

2.1 一个技能包本质上由哪些部分组成

我常说，一个技能包就像一个岗位说明书。它不需要全世界的细节，但该说清的决策点必须说清。我在实践中总结出五个部分：

• 元信息：技能名称、适用场景、一句话描述、触发条件。这是给调度器和模型看的“门牌号”。
• 主指令：这是技能的核心 Prompt，告诉模型按照什么流程思考与输出。常见问题是写得过长或过短，两种极端都会损害效果。
• 示例与 few-shot：两到五个输入输出示例，用来锚定期望格式和风格。示例不比多，但要有代表性。
• 边界与回退：什么情况下不触发、输入数据不足时怎么办、遇到用户意图偏离时如何提示。这是最容易被忽略却最关键的部分。
• 副作用声明：技能是否调用工具、是否写文件、是否访问外部资源。Agent 化以后，这部分的优先级变得格外高。

我的实操技巧是，把每个技能放进一个独立目录，里面除了技能主体文件，还放一个README.md和若干测试样例。autoResearch 每次读取整个目录，而不是只读一份 Prompt 文件。

2.2 把“感觉不对劲”翻译成可定位的检查维度

很多人在优化 Prompt 时卡住，不是因为改不动，而是因为说不清问题在哪。“感觉输出不够专业”这种评价没法指导修改。我把常见的“感觉”翻译成了七个可检查的维度，这也是 autoResearch 诊断清单的基础：

这七个维度，就像一个体检套餐。之前我靠体感，现在 autoResearch 把每个技能在这七项上的表现写进报告，哪里发炎、哪里虚胖一目了然。

2.3 为什么“先重建摘要、再评估”这个前置操作如此重要

最初我偷懒，直接丢给模型：“请优化以下技能：……” 结果很糟糕。模型容易在重写时悄悄改掉原始意图，甚至把技能原本偏保守的处理风格改成激进风格。原因也很简单：模型读了一段长文本以后，并没有被强制要求先复述“这个技能到底要干什么”，所以它脑补的意图与实际意图发生偏差，后面的改写自然跑偏。

于是我在 autoResearch 里加了一个强制前置步骤：评估任何技能之前，先基于现有内容重建一份结构化摘要。这份摘要包括：目标用户、输入信号、输出产物、关键约束、失败回退。只有摘要通过人工确认，才进入后面的诊断阶段。

这个操作的价值是防守性的。它逼着诊断先站在“忠实理解原意”的立场上，而不是站在“改进建议”的立场上。我宁可让摘要啰嗦一点，也不让后面的重写跑偏。颇有“先确认病历，再开药方”的意思。

3. autoResearch 的核心循环：观察、假设、评估、改写、回归

有了分层结构，autoResearch 就可以按固定流程跑了。我把它设计成一个五阶段循环，你可以理解成一条小型“CI/CD 流水线”。下面把每个阶段拆开讲。

3.1 五阶段循环：每一步都在解决一个具体问题

阶段一：观察。读取技能目录里的全部文件，重建结构化摘要，不急着评价。这一步的目标是“看懂”。如果不看懂就评价，后面全是空中楼阁。

阶段二：假设。基于七个检查维度，列出这个技能候选的问题点。每个问题点必须附上从原文里摘出的证据。例如不是写“触发边界模糊”，而是写“第 12 行写‘当用户需要内容时’，但没有定义什么算需要，这与代码审查技能的触发范围重合”。

阶段三：评估。针对这些假设，生成一组小测试：正常输入、异常输入、边界输入。然后让当前技能在这些测试上跑一遍，记录实际输出。这一步把“假设的问题”变成“看得见的失败”。很多假设在这一步会被推翻，这也是 autoResearch 不直接照搬模型意见的原因之一。

阶段四：改写。根据评估结果，生成改进后的技能全文。但必须写出“改动点说明”：哪里改了、为什么改、动了哪一行或哪一段。没有改动说明的优化，我不接受。

阶段五：回归。用同一组测试继续跑新技能，对比前后输出。同时跑一遍相邻技能的相关测试，确认没有引入新的冲突。如果回归不过，回到阶段四继续迭代。

完整跑一个技能，通常需要两三轮循环。首次跑二三十个技能花了我整整一个晚上，不过回报是，之后每次改技能我都有据可依，工作量减少了一半以上。

3.2 一个可复用的诊断 Prompt 骨架

autoResearch 本身不是魔法，它的灵魂是一套设计良好的诊断 Prompt。这里我直接把核心骨架分享出来，你可以复制到自己的 Agent 环境里改造。

# 角色 你是一名资深 Prompt 工程师，参与技能代码评审。你的职责是判断一个技能包的质量，并给出改进方案。 # 输入内容 技能目录路径：{skill_dir} 原始技能全文：{skill_content} 相关测试样例：{test_samples} # 工作步骤 1. 重建技能摘要。包括：目标用户、触发条件、输出产物、关键约束、失败回退。 2. 按以下七个维度逐项检查，并为每个问题点给出原文证据： a. 触发清晰度 b. 意图一致性 c. 输出规范性 d. 示例有效性 e. 失败回退 f. 依赖副作用 g. 协同冲突 3. 基于有证据的问题点，设计最少 3 个测试输入，覆盖正常、异常、边界场景。 4. 模拟当前技能运行这些测试，记录实际输出，定位失败现象。 5. 给出改进后的技能全文，并在末尾列出“改动点说明”清单。 # 强制约束 - 禁止修改技能的原始核心目标。 - 禁止增加原文中没有依据的附加功能。 - 每一项建议必须引用原文位置或测试输出作为证据。 - 最终的技能改动决策权归人类，你只提供选项与后果分析。

这份 Prompt 的关键，在于强制证据链。它不是让模型说“这里不好”，而是让模型说“这里因为什么证据不好、副作用是什么”。当你对 Prompt 工程还拿不准时，这个方法能极大降低空气感。

3.3 为什么必须把“诊断”和“治疗”分开

一次成熟的代码评审，不会上来就写补丁。它会先描述问题边界，分析根因，然后才是方案。可大多数 AI 优化提示词的尝试，都是把诊断和改写混在一个请求里，结果模型给出的改进往往建立在模糊洞察之上，甚至会主动迎合“必须改点什么”的偏见。

我在 autoResearch 里强制执行“诊断结果必须单独输出、人工可审阅”后再进入改写阶段。这样做还有一个额外好处：有时候诊断完发现技能根本不用改，只是触发条件没写清楚。过度修改反而是伤害。

很多 Auto Prompt 优化工具一上来就产出“重写后的完整版本”，这只适合菜鸟阶段。真正负责的做法是，让诊断报告自己说话。报告说改 30%，你就别让它换掉 80% 的内容。

4. 改造演练：从“一句话纪要”到可验证的“决策提取工作流”

理论讲多了容易飘，我拿一个真实改造案例来演示 autoResearch 的完整用法。为了不牵扯到具体业务，这里用“会议纪要技能”来抽象举例，但诊断思路完全一致。

4.1 原始技能存在的问题

我一开始的会议纪要技能长这样：

# 会议纪要技能 从会议记录中提取关键内容。输出包含标题、议题、决定、行动项、截止日期的简明摘要。必要时可提及参与者姓名。

这段 Prompt 如果给一个人看，能懂个大概，但给模型看，处处是坑。触发条件没有定义：是一段聊天记录、一份速记、还是一段转写文本？输出格式没有固定：“标题、议题、决定、行动项”具体用 Markdown 还是纯文本？遇到未讨论截止日期的情况，编还是不编？示例缺失，风格就一定会漂移。

这其实是大多数“初级技能”的共性：精确到人感觉够用，但精确到模型就远远不够。autoResearch 给的第一个诊断建议就是“将概要输出升级为固定模板，并补充失败回退”。

4.2 autoResearch 输出的诊断摘录

以下是那次运行里诊断报告的关键片段（非生成原样，效果一致）：

诊断维度：意图一致性 证据：主指令未声明“哪些类型的会议不需要纪”，例如头脑风暴、纯闲聊，导致技能可能在无关输入上误触发。 诊断维度：输出规范性 证据：格式描述为“简明摘要”，未给最终模板结构。模型可能第一轮输出表格、第二轮输出列表，行为不可复现。 诊断维度：失败回退 证据：未定义“开始时间/发言者/决议缺失”时将如何处理。极端情况未覆盖，模型有编造风险。 诊断维度：示例有效性 证据：零示例。缺少 few-shot 可能导致输出层级混乱。

看到这份诊断，我第一反应是：这些“病”几乎在每个早期技能里都有。但以前你很少能发现，因为你不会特意去问“缺失了什么”，而只会说“再改好一点”。这恰恰是 autoResearch 的核心价值：把隐性问题显性化。

4.3 重写后的技能包长什么样

基于诊断报告，autoResearch 分析后给出了一个改进版本，我几乎原样采纳，只改了一处关于“失败回退时是否返回空模板”的措辞。改进后的技能包：

# 会议纪要技能（决策提取模式） ## 触发条件 仅当用户提供一段会议记录、聊天记录或要点列表时触发。 未提供原始材料时，不主动生成纪要。 ## 输入约定 接受：带时间戳的转写、聊天导出、结构化速记。 不接受：用户口头描述的二手信息。 ## 输出模板 - 会议摘要（4-6 行，不超过 150 字） - 决策记录（每条含“决定内容 / 支持证据 / 反对意见”） - 行动项表格（列：责任人 / 任务 / 截止日期 / 阻塞项） - 待议事项（明确记录未讨论完的话题） ## 处理规则 1. 只基于输入文本提取，所有信息不得编造。 2. 若信息缺失，标记为“未提及”，不得自行补全。 3. 行动项至少包含一个负责人，若无负责人则标记为“待定”。 4. 当仅有碎片信息时，降级输出“要点列表”而非完整模板，并说明局限。 5. 如果输入内容少于 3 行，直接返回“信息不足，请补充材料”，不强行生产纪要。 ## 示例 ### 示例 1 输入：一段关于产品发布会的聊天记录…… 输出：（这里放一个完整输出样例） ### 示例 2 输入：一段只有两条短语的“随意聊聊”…… 输出：信息不足，请补充材料。

这次改写的收益是肉眼可见的。结构固定下来后，它的每次输出都稳定在同一套模板里，模型不再自由发挥。行动项、负责人、阻塞项这些字段有了明确语义，给后续自动化处理铺好了路。

4.4 回归测试带来的意外发现

我最想强调的是回归测试那一步。重写完之后，autoResearch 用同一组测试输入跑新旧两个版本，发现一个有意思的差异：旧版在面对“只有一句口语化总结”时，会自作主张生成一大段纪要；新版本则按规则降级输出“请补充材料”。这个变化看似“变笨了”，实际上避免了我下游流程接收到大量低质数据。回归测试让“变笨”和“变可靠”的界限变得清晰，而不是靠感觉瞎猜。

那次改造之后，我建立了一个小习惯：每次给某个技能做任何修改，都把它对应的测试样例放进一个回归集里跑一遍。回归集可以从 autoResearch 的测试输入里继承，也可以我在日常使用中补录，成本不高但价值极大。

5. 边界、反模式与推进的注意事项

讲了这么多方法论，我也必须说清楚 autoResearch 的边界。它不是什么灵丹妙药，用错了姿势反而会引入新的问题。这一节全是我踩过坑以后总结出来的反模式。

5.1 三个最容易翻车的使用姿势

反模式一：全自动重写一切。有的朋友一拿到 autoResearch 就很兴奋，批量把所有技能“过”一遍，自动采用全部重写结果。结果呢？一批技能丢失了原本精细的“手感”，变得圆滑但平庸。因为 autoResearch 属于“工业化优化”，它擅长把事情做得规范，但不擅长保留那些微妙但有效的独门技巧。我的做法是对每个技能设置“改动上限”：允许调整 20%-50% 的内容，超过上限必须人工介入。对大改的，逐段对比，不闭眼合并。

反模式二：没有样本基线就急着回归。回归测什么？如果测试输入本身就想当然，那回归结果一定失真。技能优化前，先花一点时间在真实输出中搜集“当下能接受的基准输出”，把基准输出存成一个baseline/目录。以后每次 autoResearch 跑回归，先对比新输出和 baseline 输出，而不是对比上一版本输出。基准基线比迭代版本更可靠。

反模式三：忽略技能的“对外沟通”属性。技能不仅是给模型看的，也是给人看的。尤其当一个技能会被多个协作者复用，改动太激进会让使用者感到陌生。autoResearch 重写出来的技能，可能逻辑正确但措辞冷硬，丢掉了原有技能里讲人话的舒适感。解决方法是保留“人类导读”的部分——把给模型看的精确实例和给人类看的概览说明分开，少动后者。

5.2 什么时候不该用 autoResearch

每讲一个方法，我都想强调它不适用的时候。autoResearch 不是用来写新技能的。它的输入是“已存在、可用、只是在某些维度有瑕疵”的技能。如果技能尚处于从零探索期，压根没有一份可诊断的基线，autoResearch 跑起来只会输出一堆虚构的规范，反而禁锢了手脚。

另外，当性能瓶颈不在 Prompt 时，也不需要 autoResearch。我遇到过一个技能，改了多少版效果都差，后来发现是底层模型上下文被塞得太满，和 Prompt 设计关系不大。先定位瓶颈，再用工具，顺序不能颠倒。

5.3 落地小技巧：版本管理、变更记录、人工抽查

最后分享三个落地层面的小操作，都是低投入、高杠杆的实践。

第一，给技能目录做版本管理。每个技能是一个独立目录，git 记录就是它的演进史。autoResearch 每轮优化的“改动点说明”作为 commit message 的一部分提交，日后翻记录时可以理解“为什么这样改”。这比技能文件本身更有价值。

第二，强制记录每次修改的变更理由。我在 autoResearch 的输出格式里硬性要求“改动点说明”，原因就是希望驱动模型把决策过程拉出来秀一秀。对于人来说，阅读一份只写着“优化了表达”的 commit，等于什么都没读到。而对模型来说，文本的可解释性本身就是质量的一部分。

第三，人工抽查比例别低于 20%。即使 autoResearch 跑得再顺，我每个星期仍会把所有被优化的技能拎出来，挑 20% 左右重新模拟一遍真实任务。这个比例不高，但足以建立信任感。有一次抽查发现 autoResearch 在某个技能上反复“优化”回旧版本，来回震荡，就是靠人工抽查发现的，原因是一个测试样例本身有问题，逼得模型在两个风格之间反复横跳。修掉坏样例后，一切恢复平静。

最后，我的实操心得

回到标题：写一个 Skill 来优化所有 Skill，这件事最大的价值不是自动化，而是让“优化”这一行为本身具备了可重复、可检验、可辩论的性质。以前我改技能靠个体经验，现在我改技能靠结构、证据和回归测试。autoResearch 并不是什么神奇模型，它只是一套严格约束下的 Prompt 工程循环，但正是这套循环，把我从“逐篇手搓提示词”的泥潭里拉了上来。

如果你打算在自己的环境里复刻这套实践，我的建议是不要一上来就铺开全部技能。先挑一个你每天都会用、且你自己也承认不太稳定的技能，按照第 2 节的七个维度给它做一次结构体检，再跑一遍第 3 节的五阶段循环，看看诊断报告是否符合你的直觉。你会发现，真正难的不是让模型给你一份漂亮的重写稿，而是让模型帮你把“哪里不对劲”说得清清楚楚。等这份报告让你心服口服，你再决定让 autoResearch 接管更多目录也不迟。

“优化所有技能”听起来像一句大话，但拆成结构拆解、证据诊断、回归测试里，它就是每个维护过提示词库的人都能做到的事。工具的边界很清楚，剩下的就是人的判断。