企业官网建设流程全解析

1. 别急着写代码：先搞懂 Agent Skill 到底是个什么东西

我最早接触 Agent Skill 这个概念的时候，也跟很多人一样，以为它就是给 AI 写一段提示词（Prompt），或者封装一个 API 调用。一直到我自己在做一个公众号审稿自动化流程时，被各种“看似能用、一跑就废”的方案折磨了几轮，才真正想明白 Skill 的定位。

先说一个最容易混淆的点：Skill 不是 Agent，也不是 Memory，更不是 MCP（Model Context Protocol）。这几个词在 AI Agent 圈子里天天被挂在嘴边，但它们是完全不同的层次。

• Agent是一个“执行者”，它负责理解目标、拆解任务、调用工具、做决策。它像一个项目经理，知道整体流程怎么走。
• Skill是 Agent 可以调用的“单项能力包”，比如“总结这篇公众号文章”“检查错别字”“生成摘要”。它解决的是“怎么做某一件具体的事”。
• Memory是“记忆”，保存的是上下文、历史对话、用户偏好、长期知识。它解决的是“记得住”的问题。
• MCP是“连接标准”，相当于给 Agent 提供了一套统一插头，让它能方便地接上各种外部工具和数据源。

打个比方：Agent 是一家餐厅的店长，Skill 是后厨里的一套套标准化菜谱，Memory 是店长脑子里记住的老顾客口味，MCP 是餐厅和供应商之间的标准化订货接口。四者各司其职，互相配合，但千万不要混为一谈。

那 Skill 和普通 Prompt 到底有什么区别？这是很多人最困惑的地方。我的理解是：Prompt 是一段话，让 AI 临时按你说的做；Skill 是一套结构化的、可复用的、带输入输出的“行为单元”。一个合格的 Skill 通常包含：

• 明确的名称和描述，告诉 Agent 这个 Skill 是干什么用的、什么时候该调用它。
• 结构化的输入参数定义，比如“需要审稿的文章标题”“正文内容”“目标读者群体”。
• 分步骤的执行逻辑，可能是一段精心设计的指令，也可能是多个步骤的编排，甚至调用外部工具。
• 输出格式定义，比如指定输出 JSON、Markdown，还是纯文本。
• 使用示例（Few-shot examples），帮助 Agent 理解什么情况下用、怎么用。

也就是说，Prompt 是“一次性筷子”，Skill 是“一套标准餐具”。一次性的东西用完就扔，而 Skill 的价值在于：它可以被复用、被组合、被版本化，同一个 Skill 可以在不同 Agent 里共享。

回到我的场景：我需要一个公众号审稿 Agent，它要能帮我干几件事——检查文章有没有敏感词和错别字、评价标题是否抓人、判断内容结构是否清晰、输出修改建议、最后生成一段适合公众号发布的摘要。如果这些逻辑全部堆在一个 Prompt 里，Agent 每次都要重新理解一整段复杂指令，容易遗漏、容易走偏，而且换一个场景就完全不能用了。但如果把它们拆成独立的 Skill，每个 Skill 专心做好一件事，Agent 可以根据实际情况灵活调用，组合出完整的审稿流程。这就是“Skill 化”的核心价值。

所以，如果你也想自己写 Agent Skill，第一步不是打开代码编辑器，而是先想清楚：我的 Agent 要反复执行哪些“单项能力”？每个能力包的边界在哪里？只有把这一步想透，后面写出来的 Skill 才是真正好用、能落地的。

2. 公众号审稿流程拆解：从“一个复杂任务”到“多个 Skill 的组合”

我把公众号审稿这个需求拆开之后，发现它天然适合用多个 Skill 协同工作。这其实也反映了 Agent 工作方式的一个关键原则：别让一个 Skill 干太多事，不然它就退化成一个大 Prompt 了。

先看审稿这件事到底涉及哪些能力。在我实际整理的过程中，拆出了这么几块：

1. 通读与整体评价：审稿人第一步肯定要把文章读完，对文章的主题、定位、目标读者有个整体判断。然后才是“这篇文章到底写得怎么样”的总评。
2. 敏感信息与合规检查：公众号发布有一个绕不开的坎——内容安全。错别字、病句、敏感词、不当表述，这些如果上线之后出了问题，处理起来很麻烦。这一块需要专门的检查逻辑。
3. 标题与开头的吸引力评估：公众号文章能不能被点开，标题和开头的权重极高。这个环节需要从内容运营的角度去做判断，而不是简单地纠错。
4. 结构与逻辑分析：一篇长文如果结构松散、逻辑跳跃，读者很难看完。这里需要分析段落划分、论证思路、信息密度。
5. 修改建议与具体的润色优化：发现问题之后，还要能给出可操作的修改建议，甚至直接给出润色后的句子。
6. 摘要生成与发布文案：公众号文章发布时通常需要一段推荐语或摘要，这个 Skill 负责从正文里提炼核心卖点，生成适合发在朋友圈或公众号平台的文案。

把这六块拆出来之后，你可能会发现：有些 Skill 之间存在依赖关系。比如“修改建议”肯定要建立在“通读评价”的基础上，而“摘要生成”又需要先了解全文的核心内容。这就涉及到 Skill 编排的问题——在 Agent 层面，我们可以通过工作流（Workflow）把多个 Skill 串起来，也可以让 Agent 根据情况自动决定调用顺序。

我建议在初版设计中，先用“顺序执行 + 必要分支”的方式把流程定下来，而不是一上来就搞复杂的动态路由。顺序执行的优点是稳定、可调试；等跑顺了再逐步放开，让 Agent 有更多自主决策空间。

在拆解 Skill 时，还有几个细节特别值得注意：

• 每个 Skill 的输入输出要尽量标准化。比如“文本检查类” Skill 的输入统一是“文章内容（字符串）”，输出统一是“检查结果（结构化数据）”。这样上一个 Skill 的输出可以直接作为下一个 Skill 的输入，编排起来非常顺。
• 职责边界要清晰，但也不能过细。比如“错别字检查”和“敏感词检查”可以拆成两个 Skill，但在前期资源有限时，合并成一个“文本合规检查” Skill 也完全可行。我的建议是：先合并、后拆分，不要一上来就追求极致的原子化。
• 每个 Skill 都要设计好“失败模式”。比如输入为空、输入超长、内容类型不对，这些情况该怎么处理。很多 Skill 写出来不好用，问题就出在只考虑了正常路径，没考虑异常路径。

有人可能会问：我用一个大 Prompt 把这些逻辑全部写进去，效果不也差不多吗？说实话，在小规模场景下，大 Prompt 确实能跑，而且开发速度更快。但一旦你要面对多篇文章、不同作者、不同领域的审稿需求，大 Prompt 的劣势就暴露出来了：改一个细节要动全局，调试时不知道是哪段逻辑出了问题，不同需求之间还会互相干扰。而拆成 Skill 之后，每个模块都可以独立测试、独立优化，换需求时只需要替换对应模块。这才是 Skill 真正值钱的地方。

3. 核心开发实战：手写一个“公众号文章质量分析” Skill

前面讲了那么多概念和思路，这一节直接上干货。我以“公众号文章质量分析”这个 Skill 为例，完整走一遍开发过程。这个 Skill 是整个审稿流程里最核心的一环——它负责对文章做整体评价，输出结构化质量报告，供后续的修改建议 Skill 和摘要 Skill 使用。

3.1 设计 Skill 的元信息（Meta）

每个 Skill 在定义时，第一件事是写清楚元信息。这里我用一个类 JSON 的结构来描述它，这也是目前各大 Agent 开发框架里比较通用的方式。元信息的作用是让 Agent 在决策时“知道有这个 Skill 存在、什么时候该调用它、传什么参数”，所以描述一定要写得精确，参数定义要严谨。

{ "name": "article_quality_analysis", "description": "对一篇公众号文章进行整体质量分析，输出结构化的质量评估报告。适用于文章初稿完成后的第一次整体审阅，或改稿后的复评。评估维度包括主题清晰度、结构逻辑、信息密度、语言表达、可读性等。", "inputs": { "title": { "type": "string", "description": "文章标题", "required": true }, "content": { "type": "string", "description": "文章正文内容，为纯文本格式", "required": true }, "target_audience": { "type": "string", "description": "目标读者群体描述，如‘互联网从业者’‘新手妈妈’", "required": false } }, "output": { "type": "json", "description": "结构化质量分析报告" }, "tags": ["审稿", "质量分析", "公众号"] }

这里有个细节：description一定要包含“什么时候该调用”的信息。比如我写了“适用于文章初稿完成后的第一次整体审阅，或改稿后的复评”，这样 Agent 在编排任务时就能更准确地判断调用时机。很多新手写 Skill 时容易忽略这一点，导致 Agent 不敢用或者误用这个 Skill。

3.2 编写核心指令（System Prompt）

元信息之外，最重要的就是 Skill 的执行指令。这一段指令的质量，直接决定了输出结果的上限。我不会写那种长长的、无所不包的大段落，而是把指令拆成几个清晰的部分。

第一部分是角色与目标设定：

你是一位资深的公众号内容编辑，拥有8年新媒体行业从业经验，擅长从读者视角审视文章质量。 你的任务是对给定文章进行全面的质量分析，输出一份结构化的分析报告。 分析时要保持客观、专业，既不要一味吹捧，也不要刻意挑刺。

第二部分是分析维度与评分标准。我总结了六个维度，每个维度都有自己的权重和评分说明：

第三部分是输出格式要求。我强制要求输出 JSON，这样下游 Skill 解析起来非常方便：

{ "overall_score": 8.5, "dimension_scores": { "topic_focus": 9, "structure_logic": 8, "information_density": 7, "language_expression": 9, "readability": 8, "reader_value": 8 }, "summary": "一句话概括这篇文章的核心内容和质量印象", "strengths": ["优点1", "优点2", "优点3"], "weaknesses": ["不足1", "不足2", "不足3"], "critical_issue": "如果文章存在严重问题，在此说明；没有则写null" }

3.3 让 Skill 更聪明的 Few-shot 示例

光有指令还不够，我建议再加上 1-2 个示例（Few-shot examples），尤其是第一次写 Skill 的时候。为什么？因为大模型对“质量分析”这个抽象任务的理解，可能跟你的预期有偏差。给一个具体示例，相当于把“我心里想要什么”变成“AI 看得懂的样本”。

我举一个简化的例子：

输入文章主题：如何用 Notion 搭建个人知识库 示例输出片段：

{ "overall_score": 7, "dimension_scores": { "topic_focus": 8, "structure_logic": 6, ... }, "summary": "文章提供了Notion知识库的搭建入门指南，步骤清晰但深度不足，部分章节存在工具操作与知识管理理念的脱节。", "strengths": ["实操步骤清晰", "图文结合较好", "适合新手入门"], "weaknesses": ["缺少进阶技巧", "结构有些松散", "理论支撑不足"] }

注意，示例的质量很重要。如果示例本身评分标准不一致，模型学到的规矩就会乱。我建议花点时间打磨示例，让它能覆盖“中等质量文章”的典型情况。

3.4 合成为一个完整的 Skill 文件

完整的 Skill 文件会被模型直接使用。实际项目中，更多是放在一个特定目录里，由框架自动加载。如果是在 Claude（或类似支持 Skill 能力的 Agent 平台）里，可以通过 Skill 编辑器创建，填入 Name、Description、Instruction 即可；核心还是要把 Instruction 写好。

我这里给出一个适合 copy 走的完整版：

# 公众号文章质量分析 Skill 你是一位资深的公众号内容编辑，拥有8年新媒体行业从业经验，擅长从读者视角审视文章质量。你的任务是对给定文章进行全面的质量分析，输出一份结构化的分析报告。 【分析流程】 1. 先通读全文，理解文章的核心主题、写作目的和目标读者。 2. 逐维度评估：主题聚焦度、结构逻辑性、信息密度、语言表达、可读性、读者价值。 3. 综合各维度得分，给出整体评分（1-10分，可保留一位小数）。 【评分标准】 - 9-10分：优秀，几乎无可挑剔。 - 7-8分：良好，有明确亮点，但存在可改进之处。 - 5-6分：及格，核心内容完整，但明显不够出色。 - 3-4分：较差，存在明显缺陷。 - 1-2分：极差，需要推翻重写。 【输出格式】 使用JSON格式输出，必须包含以下字段： - overall_score: 整体评分 - dimension_scores: 各维度评分 - summary: 100字以内的整体评价 - strengths: 至少2个优点 - weaknesses: 至少2个不足 - critical_issue: 严重问题说明（无则填null） 【注意事项】 - 不要过度挑剔语气词和标点等细枝末节，除非严重影响阅读。 - 对优点和不足的描述要具体，避免‘语言流畅’‘结构清晰’这类空泛表达，要说明好在哪、差在哪。 - 如果文章主题明显属于自己不了解的领域，请基于通用表达逻辑和行文结构做判断，不要不懂装懂。

这段指令的关键在于：流程明确、标准量化、输出可解析、避免空洞表达。这四个要素缺一不可。

3.5 踩过的坑：输出格式不稳定怎么办

我在实际使用中遇到最大的问题，就是大模型输出的 JSON 格式不够稳定。有时候字段名变了，有时候飘出一段解释文字，下游解析直接报错。

针对这个坑，我的解决办法有三个：

1. 在指令里反复强调“只输出JSON，不要输出其他任何内容”。必要时可以加一句“不要使用Markdown代码块包裹”。
2. 在调用侧增加JSON提取与修复逻辑：如果解析失败，用正则把第一个{到最后一个}之间的内容提取出来，再尝试解析。这个方法能解决 80% 的格式漂移问题。
3. 强制约束枚举值：比如评分只能用数字，避免模型输出“8分”或者“良好”这类模糊值。

这三个手段组合使用之后，我这边 JSON 解析的成功率能从 70% 左右提升到 95% 以上。这个提升幅度非常明显，强烈推荐你在开发时提前考虑。

4. 组合出完整的审稿 Agent：从文章输入到审稿报告的全流程编排

单个 Skill 写完之后，接下来要解决的问题是：怎么把它和另外几个 Skill 组合成一个完整的审稿 Agent？

我在这一节把完整的设计思路和流程细节展开讲，你可以直接照着搭。

4.1 审稿 Agent 的工作流程设计

我的初版采用了一个**“主流程固定 + 分支判断”**的结构：

1. 接收输入：用户提供一个公众号文章链接或者直接粘贴正文。如果是链接，先调用“网页内容提取”工具把正文抓取下来。
2. 文本合规检查：跑一遍“合规检查” Skill，检查错别字、敏感词、禁用词。
3. 文章质量分析：调用上面写的“文章质量分析” Skill，输出整体评分和维度分析。
4. 标题与开头吸引力评估：专门分析标题和开头段落，输出“是否吸引点击”的判断和建议。
5. 生成修改建议：结合第2步和第3步的结果，生成一份“重点修改建议”清单，区分必须改和优化项。
6. 摘要生成：最后调用“摘要生成” Skill，输出适合发布的推荐语和摘要。

这个流程的好处是：每个环节都有明确的输入输出，Agent 不需要在大段记忆里“临场发挥”，而是像流水线一样逐站完成。

4.2 如何定义 Agent 的编排逻辑

在大多数 Agent 开发框架里，编排逻辑要么写在工作流配置里，要么写在 Agent 的系统提示词里。我偏向把“流程”和“自由度”做一个平衡：前三步走固定顺序，后三步给 Agent 一定的自主权。

为什么这样设计？因为前面三步是强依赖关系——文章没提取出来，就无法做合规检查；合规检查不过，质量分析也没意义。但后面三步相对独立：修改建议和摘要可以并行，或者根据用户需求只执行其中一项。给 Agent 自主权，可以让流程更灵活，不至于“非要走完所有步骤才能给用户一个答复”。

如果你用的框架支持“工作流 + 子Agent”模式，我强烈建议用这种混合方式。纯工作流太死板，纯 Agent 自由发挥又容易偏离预期，混合是实战中最实用的状态。

4.3 上下游数据如何传递

Skill 与 Skill 之间的数据传递，是编排环节里最容易出隐性 Bug 的地方。

我的经验是：每个 Skill 的输出只要是需要给别的环节用的，都强制用结构化 JSON，并且在设计时明确“给下一个环节的关键字段”。比如质量分析 Skill 输出的critical_issue字段，如果为 null，修改建议环节就知道“这篇文章没有致命问题，重点放在优化项上”；如果非 null，修改建议环节就要把这条作为最优先级处理。

这里有一个非常典型的坑：如果两个 Skill 是不同团队或不同时间开发的，字段命名习惯不一致，比如一个用overall_score，另一个用total_score，传递时就容易断裂。处理办法是在编排层做一个轻量级的字段映射，或者在定义 Skill 时统一约定好公共数据模型。不要小看这个动作，它能帮你省下大量排错时间。

4.4 完整示例：一次真实的审稿过程

为了让流程更直观，我模拟一次真实的审稿调用过程。

用户输入：

文章标题：30岁以后，我靠这3个习惯摆脱了无效加班 文章正文：（这里省略正文，假定是一篇约2000字的职场感悟文章） 目标读者：30-40岁的职场人士

Agent 依次执行的调用：

第一步，调用text_compliance_check：

{ "input": "（文章正文）", "check_type": ["typo", "sensitive_word"], "output": { "typo_count": 2, "sensitive_word_count": 0, "typo_list": ["‘的’与‘地’混用1处", "‘在’与‘再’混用1处"], "sensitive_word_list": [] } }

第二步，调用article_quality_analysis。假设输出的核心结果是：

{ "overall_score": 7.8, "dimension_scores": { "topic_focus": 8, "structure_logic": 7, "information_density": 7, "language_expression": 8, "readability": 9, "reader_value": 8 }, "summary": "文章以个人经历切入，主题聚焦，可读性强，但在信息密度和结构深度上仍有提升空间。", "strengths": ["开篇有代入感", "三个习惯的结构清晰", "每部分都有具体做法"], "weaknesses": ["第二部分论证较单薄", "缺少反例或风险提示"], "critical_issue": null }

第三步，调用headline_attractiveness_analysis，专门评估标题：

{ "headline_score": 8, "hook_score": 9, "clarity_score": 8, "suggestions": "标题精确命中目标人群痛点，可考虑增加数字来增强确定性。" }

第四步，生成修改建议：

{ "must_fix": [ "修正2处错别字：……", "补充第二部分中‘习惯二’的具体执行案例" ], "optimize_suggestions": [ "增加一段关于‘习惯一’的常见误区说明", "结尾可加入一句行动号召，提升转化感" ], "priority_order": [ "先修正错别字", "补充案例", "优化结尾" ] }

第五步，生成摘要：

{ "push_title": "30岁后告别无效加班，我坚持了3个习惯", "summary": "加班不等于努力。这篇文章从个人真实经历出发，分享三个帮助作者摆脱无效加班的具体习惯，适合被工作困住却不知如何突破的职场人阅读。", "tags": ["职场", "效率", "个人成长"] }

这套流程走下来，一篇审稿报告就完整了。作为用户，你拿到的不是一句“写得挺好的”，而是从合规、质量、标题吸引力、修改建议到发布摘要的一整套内容包。这就是多个 Skill 组合起来的真正威力：每个 Skill 负责一个专业切面，组合起来就是一位逼近资深编辑水平的审稿助手。

5. 输出结构不稳定的自救方案：JSON 提取与兜底策略

在上一节的调用示例里，所有输出都是干干净净的 JSON，看起来非常理想。但说实话，真实世界里几乎不可能这么顺利。这一节专门展开讲输出稳定性的问题，因为这是任何一个写 Agent Skill 的人都会撞上的墙。

大模型输出的不稳定，主要表现有这么几类：

• 在 JSON 前后添加了“好的，以下是分析结果：”之类的废话。
• 用了 Markdown 代码块包裹 JSON，有的加了```json，有的没加。
• 字段值里混入了多余内容，比如评分写成了“8分（主题明确）”而不是8。
• 缺少某些必填字段。
• 字段名轻微变化，比如overall_score变成了overallScore。

在我维护审稿流程的这段时间里，前两类问题出现最频繁。下面是我实际采用的兜底策略，按优先级排列：

5.1 正则提取 JSON 片段

如果解析 JSON 直接失败，第一步尝试用正则从原始输出中提取最外层的大括号内容：

import json import re def extract_json(text: str) -> dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取从第一个 { 到最后一个 } 之间的内容 pattern = r'\{.*\}' match = re.search(pattern, text, re.DOTALL) if not match: raise ValueError("无法在输出中找到JSON内容") json_str = match.group(0) try: return json.loads(json_str) except json.JSONDecodeError: raise ValueError("提取到的JSON仍然无法解析")

这个做法能解决的问题：模型在 JSON 前后加了说明文字、用了代码块（只要代码块的语言标记没有干扰大括号匹配）等常见情况。

5.2 去掉 Markdown 代码块标记

如果用了json 包裹，上面的正则其实已经能处理（因为不是大括号）。但如果代码块内部还有反引号字符，可能干扰。再补一个更暴力的清洗：

def clean_extracted_json(text: str) -> str: # 去掉Markdown代码块标记 text = re.sub(r'```(?:json)?', '', text) # 去掉首尾空白 text = text.strip() return text

5.3 设置宽松的字段校验

如果提取到了 JSON，但字段缺失，不要直接报错让整个流程中断。更好的做法是设置默认值，并记录告警：

def sanitize_report(data: dict) -> dict: defaults = { "overall_score": 0, "dimension_scores": {}, "summary": "", "strengths": [], "weaknesses": [], "critical_issue": None } # 对每个字段，确保键存在且类型正确 data["overall_score"] = float(data.get("overall_score", 0)) data["dimension_scores"] = data.get("dimension_scores", {}) data["summary"] = str(data.get("summary", "")) data["strengths"] = list(data.get("strengths", [])) data["weaknesses"] = list(data.get("weaknesses", [])) data["critical_issue"] = data.get("critical_issue", None) return data

这样即使模型输出不完整，流程也能继续走，只是对应字段为空。对用户来说，拿到一份“部分字段为空”的报告，比直接报错要友好得多。

5.4 终极手段：解析失败后让模型自修复

如果一个 Skill 的输出反复解析失败，我会再加一个“自修复”步骤：把原始输出和解析错误信息一起回传给模型，让它重新输出一遍 JSON：

你上一次输出的JSON格式无法解析，解析器报错如下：{error_message} 请只输出一个格式合法的JSON对象，不要输出任何其他内容。原始内容如下：{original_output}

实测下来，自修复对大多数情况都有效。但它会额外消耗一次模型调用，所以不是最优解，只作为最后一层保险。

我在实战中建议的顺序是：先靠指令约束 → 再做正则提取 → 再做字段清洗 → 最后自修复。四层保险下来，整套流程的稳定性已经非常可用了。如果你在看这篇文章时已经遇到过解析崩溃的坑，可以把这套方案直接抄走用。

6. Skill 的调试方法论：怎么判断是你的 Skill 写得不好，还是模型能力不够

开发完 Skill，接下来就是没完没了的调试。很多人在这一步特别容易陷入焦虑：明明指令写得很清楚了，模型还是输出怪东西。到底该改 Skill，还是该换模型？我总结了一套自己的判断流程。

6.1 先做“最小复现测试”

不要一上来就拿着几百篇文章去批量验证。先拿着 1-2 篇有代表性的文章，手动触发单个 Skill 跑一跑。比如单独跑“文章质量分析” Skill，看它的输出是否落在预期范围内。

如果最小复现测试已经跑偏，说明问题是 Skill 本身的问题，而不是流程编排的问题。这时候先去检查 Skill 指令、示例、参数定义。

6.2 判断问题出在“理解”还是“执行”

同样是输出不合格，原因可能完全不同。

• 理解问题：模型没能理解你要的格式，或者对“质量分析”的理解太宽泛，导致输出泛泛而谈。这种情况通常需要加强 Few-shot 示例、把评分标准写得更具体。
• 执行问题：模型理解了要求，但输出时格式漂移、字段缺失。这种情况通常需要加强输出格式约束，或者做更多的后处理兜底。

怎么区分？一个很简单的办法：在输出里找关键词。如果输出内容在逻辑上是合理的，只是格式不对，那大概率是执行问题；如果输出内容本身就驴唇不对马嘴，那大概率是理解问题。

6.3 不同的失败，用不同手段修

根据我的经验，整理了下面这个对照表：

6.4 建立回归测试集

调试一段时间后，你一定会发现一个规律：改好了 A 案例，B 案例可能又坏了。为了避免“按下葫芦浮起瓢”，我强烈建议建立一个轻量级的回归测试集。

不用特别复杂，就是把 10-20 篇不同风格、不同长度的文章存起来，每次改完 Skill 后批量跑一遍，对比输出结果是否出现新的退化。注意不要只看是否解析成功，还要人工抽查 2-3 篇的输出质量。解析成功不等于内容合格，这一点要特别警惕。

有了这套回归测试集，你才能放心地去迭代优化 Skill。否则每改一次都像在玩随机骰子，心里完全没底。

7. 进阶优化：让 Skill 更懂你的公众号运营策略

基础版的审稿 Skill 能帮你检查错别字、分析质量、生成摘要，但如果你希望它更贴合自己的公众号定位，还有几个值得投入的优化方向。

7.1 把“读者画像”内嵌到 Skill 里

不同公众号的读者群体，对“好文章”的定义完全不一样。同样是 2000 字的深度文，面向投资人的号和面向新手妈妈的号，评价标准差着十万八千里。

我在质量分析 Skill 的指令里增加了一个可选参数reader_profile，用来描述目标读者的特征。传入后，模型在评分时会主动带入这个画像：

如果提供了reader_profile，请在分析时始终站在该读者群体的视角进行评分。例如： - 新手妈妈：重视实操性、易读性，对专业术语容忍度低。 - 投资从业者：重视数据完整性、逻辑严密性，对煽情表达容忍度低。

这样同一个 Skill，在不同的读者画像下会给出不同的评分逻辑。这是让 Skill“脱胎换骨”的极简单做法。

7.2 增加历史审稿偏好记忆

如果平台支持 Memory 功能，可以允许 Agent 记录用户的历史审稿偏好，比如“作者偏好短句、喜欢在开头抛案例”，然后在后续审稿时参考这些偏好生成建议。

这里要注意 Skill 和 Memory 的协作边界：Memory 负责记住偏好，Skill 负责在输出时应用偏好。不要把偏好硬编码在 Skill 里，否则换一个作者就全乱了。

7.3 让 Skill 自我反思和迭代

比较进阶的玩法，是在流程末尾加一个“反思”环节：让 Agent 对比本次审稿报告和作者的实际修改，判断哪些建议被采纳了、哪些没有，并总结原因。然后把这些反馈存入 Memory，反过来优化后续审稿建议的侧重点。

这个闭环是很多成熟 Agent 产品和普通玩具的区别。虽然初期实现起来会多一些工作量，但一旦跑通，它带来的个性化效果是非常惊人的。它会让你觉得，这个审稿 Agent 越来越像一位真正了解你的主编。

8. Skill 开发的几条实用经验总结

文章写到这儿，主体内容已经全部展开。最后这部分，我把自己这段时间开发 Agent Skill 的几条核心经验做一个“不套路”的收尾，也相当于给想动手的同学一份速查清单。

第一条经验：Skill 的颗粒度，宁粗勿细。除非你的场景极其复杂，否则不要一上来就把事情拆到原子级。先做几个大而全的 Skill，跑通流程，再逐步拆分。我一开始把“错别字检查”“敏感词检查”“语气检查”拆成三个独立的 Skill，结果发现它们对模型的能力要求高度重叠，拆开之后反而多了一堆编排开销。后来合并成一个“文本合规检查”，效果反而更好。

第二条经验：Skill 的描述（description）和指令（instruction）要分开写，别混在一起。description 是写给 Agent 的“搜索引擎摘要”，它决定 Agent 会不会调用这个 Skill；instruction 是写给模型的“执行手册”，它决定调用后输出的质量。两件事目的不同，写作方式也应该不同。description 要短而准，突出调用时机；instruction 要长而细，突出执行步骤和输出要求。

第三条经验：一定不要在输出格式上妥协。哪怕初期开发时你觉得“稍微飘一点没关系”，也要尽早把输出结构定成强规范。因为一旦下游依赖这个输出，格式稳定性的问题就会被无限放大。宁可前期多花时间打磨输出约束，也不要后期在解析上打补丁。

第四条经验：建立“小步迭代”的开发节奏。每写完一个 Skill，就立即用一个最小的示例跑一次，确认没问题再写下一个。不要一次性写完五六个 Skill 再统一测试，那样出现问题时你根本不知道是哪一个环节的锅。这个开发节奏听起来很简单，但真的能帮你省掉大量定位问题的时间。

第五条经验：把“不确定”交给 Agent，把“确定”写死在代码里。Skill 的优势是灵活性，但它并不适合承载需要精确计算的逻辑。如果某个环节的目标非常明确（比如“提取正文内容”），用传统代码处理会更稳定；只有像“分析质量”“判断标题吸引力”这类主观判断任务，才适合交给 Skill 去发挥大模型的语义理解能力。用对工具，比什么都重要。

如果你正在被“Agent Skill 到底怎么写”这个问题困扰，我希望这篇文章能帮你理清思路。不要被概念吓到，也不要把所有逻辑一股脑塞进一个 Skill。先把流程拆开、把边界画好、把输出定死，一步一步来，你会发现 Agent 开发和写一份操作手册没有本质区别——都是“分而治之，逐一攻破”。