企业官网建设流程全解析

1. 从“skills”这个热词说起：它到底是什么，为什么突然火了

最近几个月，不管是在技术社区、开发者群聊，还是在做AI应用的朋友圈子里，“skills”这个词出现的频率高得离谱。有人叫它 Agent Skills，有人叫它 Claude Agent Skills，还有人直接简称为 skills。热搜词里甚至出现了“今天学会了skills，打开新世界”这种非常情绪化的表达。作为一个在AI应用开发一线摸爬滚打多年的人，我一开始也以为这不过是又一个包装概念，直到我自己动手把一套 skills 体系跑通、接到实际项目里，才意识到这东西确实值得认真聊一聊。

先把话说清楚：skills 本质上是一种把“能力”模块化、可复用、可组合的封装机制。你可以把它理解成给 AI Agent 准备的“技能包”——每个技能包里面包含了完成某类任务所需的指令、工具调用逻辑、上下文约束和输出规范。Agent 在运行时，根据当前任务动态加载对应的 skills，而不是把所有能力一股脑塞进一个巨大的提示词里。这个思路听起来简单，但它解决的是当前 AI 应用开发中最让人头疼的几个问题：提示词膨胀、能力耦合、复用困难、维护成本高。

为什么现在火？因为大家发现，单纯靠堆提示词、堆上下文窗口，已经很难让 Agent 稳定完成复杂任务了。你写一个能写论文的 Agent，再想让它同时会做分镜、会挖漏洞、会做前端代码审查，提示词会膨胀到无法维护，而且不同能力之间会互相干扰。skills 的出现，本质上是把软件工程里“模块化”和“关注点分离”的思想，搬到了 Agent 能力构建上。这个类比很重要，后面我会反复用到。

这篇文章适合谁看？如果你正在做 AI Agent 相关的开发，或者你是一个重度 AI 工具使用者，想搞清楚怎么让 AI 更稳定地完成特定任务，那这篇内容会对你有直接帮助。如果你只是听说过 skills 这个词，想知道它到底是不是又一个炒作概念，我也会用实际操作的视角给你一个判断依据。全文我会围绕 skills 的设计思路、核心机制、实操落地、常见坑和排查方法展开，尽量做到你看完就能动手试。

2. skills 的核心设计思路：为什么不是“又一个提示词模板”

2.1 从“万能提示词”到“技能模块化”的必然转变

早期做 Agent 的人，包括我自己，都经历过一个阶段：试图用一个超级提示词解决所有问题。你会在系统提示里写“你是一个资深工程师，你会写代码、会审查、会写文档、会做架构设计、会排查问题……”然后下面跟几千字的规则。刚开始效果还行，但随着任务复杂度上升，你会发现几个致命问题。

第一，能力之间会互相污染。当你让 Agent 同时具备“写论文”和“挖漏洞”两种能力时，写论文时它可能会突然用上安全测试的思维，输出一堆风险评估；做安全测试时它又可能开始讲究学术引用格式。这不是模型笨，而是提示词里的指令在互相竞争注意力。

第二，维护成本指数级上升。每加一个能力，你都要回头检查它会不会影响已有能力。改一处，可能崩三处。这种维护体验，做过大型提示词工程的人都懂，非常痛苦。

第三，无法复用和共享。你写了一个很好的“代码审查”提示词，想分享给同事，只能整段复制。同事想把它和自己的“文档生成”能力结合，又得手动拼接，拼完还得调。整个过程没有任何工程化的痕迹。

skills 的设计思路，就是针对这三个问题来的。它把每个能力封装成一个独立的 skill 单元，每个单元有自己的触发条件、执行逻辑、依赖工具和输出格式。Agent 在运行时，根据任务类型动态加载对应的 skill，而不是一次性加载所有能力。这就像你电脑上不会同时打开所有软件，而是用什么开什么。这个类比虽然简单，但非常准确。

2.2 skills 的组成结构：一个 skill 里到底有什么

一个完整的 skill，通常包含以下几个部分。不同平台和框架的实现细节会有差异，但核心结构是相通的。

• 元信息（Metadata）：包括 skill 的名称、描述、版本、适用场景、触发关键词等。这部分决定了 Agent 在什么情况下会加载这个 skill。元信息写得好不好，直接决定了 skill 能不能被正确触发。
• 指令集（Instructions）：这是 skill 的核心，告诉 Agent 在执行这类任务时应该遵循什么步骤、注意什么约束、输出什么格式。它类似于一个专门针对某类任务的系统提示，但比系统提示更聚焦、更短。
• 工具依赖（Tool Dependencies）：这个 skill 需要调用哪些外部工具或 API。比如一个“代码审查”skill 可能需要读取文件、运行静态分析工具、查询代码规范文档。把这些依赖显式声明出来，Agent 在加载 skill 时就能知道需要准备什么。
• 输入输出规范（I/O Schema）：定义这个 skill 接受什么输入、输出什么结果。这是实现 skill 之间组合的关键。如果每个 skill 的输入输出都是自由文本，那组合起来就会很混乱；有了明确的 schema，skill 之间就可以像函数调用一样串联。
• 示例（Examples）：一些典型的输入输出示例，帮助 Agent 更准确地理解这个 skill 的预期行为。示例的质量往往比指令本身还重要，因为模型对示例的敏感度很高。

我自己的经验是，元信息和示例是最容易被忽视但最影响效果的两部分。很多人写 skill 时把大量精力花在指令集上，写了几千字规则，但元信息就写了一句“用于代码审查”，示例一个没有。结果就是 Agent 要么不触发这个 skill，要么触发了但输出格式完全不对。后来我调整了策略，先把元信息和示例写好，指令集反而可以精简很多，整体效果提升非常明显。

2.3 为什么 skills 比传统插件机制更适合 Agent

有人可能会问，这不就是插件机制吗？以前也有插件，为什么现在 skills 又火了？这个问题问得好，我一开始也有同样的疑惑。仔细对比之后，我发现 skills 和传统插件有几个本质区别。

传统插件通常是功能导向的，它封装的是一个具体功能，比如“查天气”“发邮件”“搜索网页”。插件本身不包含太多“怎么用”的智慧，它只是把能力暴露出来，具体怎么调用、什么时候调用、调用后怎么处理结果，全靠 Agent 自己判断。这就导致 Agent 在面对复杂任务时，经常不知道该用哪个插件、该怎么组合。

skills 是任务导向的，它封装的是“完成某类任务的完整方法论”。一个 skill 不仅告诉 Agent 有哪些工具可用，还告诉它这类任务的典型流程是什么、有哪些坑、输出应该长什么样。这相当于把人类专家的经验也封装进去了，而不仅仅是工具本身。

另一个区别是组合方式。传统插件的组合往往需要开发者手动编排，或者依赖 Agent 的临场判断。skills 通过明确的输入输出 schema，让 skill 之间可以像乐高积木一样拼接。一个“数据清洗”skill 的输出可以直接作为“数据分析”skill 的输入，中间不需要人工干预。这种可组合性，是 skills 真正强大的地方。

还有一个容易被忽略的点：skills 是可版本化和可测试的。你可以给每个 skill 写单元测试，验证它在给定输入下是否产生预期输出。这在传统提示词工程里几乎做不到，因为提示词是一个整体，你没法单独测试其中某一部分。skills 把能力拆开之后，测试和迭代就变得可行了。这一点对于要把 Agent 用到生产环境的团队来说，价值巨大。

3. 核心细节解析：一个高质量 skill 应该怎么写

3.1 元信息设计：让 Agent 在正确的时候想起你

元信息看起来简单，但它是 skill 能否被正确触发的第一道关卡。我见过太多 skill 因为元信息写得太模糊，导致 Agent 要么不加载，要么在不该加载的时候加载。

写元信息时，我通常遵循几个原则。第一，描述要具体到场景，而不是泛泛而谈。比如“用于代码审查”就不如“用于审查 Python 代码中的安全漏洞和性能问题，输入为代码文件路径，输出为问题列表和修复建议”。后者明确说了语言、审查维度、输入输出形式，Agent 匹配起来准确率高很多。

第二，触发关键词要覆盖同义表达。用户不会总是用同一个词来描述需求。有人会说“审查代码”，有人会说“检查代码问题”，有人会说“code review”。如果你的触发关键词只写了“代码审查”，那其他表达就可能匹配不上。我的做法是列出至少五到八个同义或近义表达，覆盖不同用户的语言习惯。

第三，版本和依赖要写清楚。如果你的 skill 依赖某个特定版本的模型能力或外部工具，一定要在元信息里标注。否则换了个环境，skill 可能就跑不起来了。我踩过这个坑：一个依赖特定文件解析库的 skill，换到另一台机器上因为库版本不对，直接报错，排查了半天才发现是依赖没声明清楚。

下面是一个元信息示例，用 YAML 格式展示，这种格式在多数 skills 框架里都通用：

name: python-security-review description: 审查 Python 代码中的安全漏洞，包括注入风险、敏感信息泄露、不安全的反序列化等 version: 1.2.0 triggers: - 代码安全审查 - Python 安全检查 - 漏洞扫描 - security review - 检查代码安全问题 inputs: - name: code_path type: string description: 待审查的 Python 文件或目录路径 outputs: - name: issues type: array description: 发现的安全问题列表，每项包含位置、严重程度、描述和修复建议 dependencies: - python>=3.9 - bandit>=1.7

这个元信息里，触发词覆盖了中英文常见表达，输入输出有明确类型，依赖也列清楚了。Agent 在匹配时，只要用户表达落在这些触发词附近，就能准确加载。

3.2 指令集编写：把专家经验翻译成可执行步骤

指令集是 skill 的灵魂。写得好，Agent 执行起来像专家；写得差，Agent 就像刚入行的新手，步骤混乱、遗漏关键点。

我的经验是，指令集要写成“操作手册”而不是“知识百科”。很多人写指令时喜欢堆知识，比如“Python 中常见的注入风险包括 SQL 注入、命令注入、模板注入……”这些知识模型本身就有，写进去反而占用上下文。真正有价值的是操作步骤：先做什么、再做什么、遇到什么情况怎么处理、输出格式是什么。

一个实用的指令集结构通常是这样的：

1. 任务目标：一句话说清楚这个 skill 要达成什么。
2. 前置检查：执行前需要确认什么，比如文件是否存在、依赖是否安装。
3. 执行步骤：按顺序列出每一步做什么，每步的预期结果是什么。
4. 分支处理：遇到不同情况时分别怎么处理，比如发现高危漏洞时优先输出，发现低危问题时批量汇总。
5. 输出规范：最终输出什么格式，包含哪些字段，字段的含义是什么。
6. 边界说明：什么情况下这个 skill 不适用，应该转给哪个 skill 处理。

这里有个细节值得展开：分支处理是区分普通 skill 和优秀 skill 的关键。普通 skill 只告诉 Agent“做什么”，优秀 skill 还告诉它“遇到 A 情况怎么做，遇到 B 情况怎么做”。这就像给新员工的培训手册，好的手册会把各种异常情况都考虑到，新员工遇到问题不会慌。Agent 也是一样，有了分支处理，它在面对复杂输入时表现会稳定很多。

我自己的一个“代码审查”skill，指令集里专门有一段处理“如果代码文件超过 500 行”的情况：先按函数拆分，逐个审查，最后汇总。这个分支处理让 skill 在处理大文件时不会因为上下文超限而崩溃。这种细节，只有实际跑过、踩过坑的人才会想到写进去。

3.3 工具依赖与权限控制：别让 skill 变成安全隐患

skills 通常会调用外部工具，这就带来了权限和安全问题。一个设计不当的 skill，可能会让 Agent 执行危险操作，比如删除文件、发送网络请求、修改系统配置。

我的做法是最小权限原则：每个 skill 只声明它真正需要的工具权限，不多给。比如一个“代码审查”skill 只需要读文件和运行静态分析工具的权限，就不应该给它写文件或执行任意命令的权限。这在元信息里就要声明清楚，框架层面也要做校验。

另外，对外部工具的调用要做输入校验。Agent 生成的工具调用参数不一定总是合法的，如果直接传给外部工具，可能会出问题。比如一个执行命令的工具，如果 Agent 生成的命令里包含了用户输入的未转义内容，就可能有注入风险。虽然这是框架层面的事，但写 skill 的人也要有这个意识，在指令集里明确告诉 Agent 哪些参数需要转义、哪些操作需要二次确认。

还有一个实践中的经验：给危险操作加确认环节。如果一个 skill 需要执行删除、覆盖、发送这类不可逆操作，我会在指令集里要求 Agent 先输出操作计划，等确认后再执行。这个确认可以是人工确认，也可以是另一个 skill 的校验。多这一步，能避免很多误操作。我见过因为 skill 直接执行了覆盖操作，把重要文件清空的情况，事后排查发现是 Agent 误解了用户意图。加个确认环节，这种问题基本就能杜绝。

4. 实操过程：从零搭建一个可用的 skill 并接入 Agent

4.1 环境准备与框架选择

动手之前，先要把环境搭好。skills 本身是一个概念，具体实现依赖你用的 Agent 框架。目前比较常见的有几类：一类是云平台提供的 Agent 开发框架，比如 Google Cloud 上的相关服务，它们通常内置了 skills 管理能力；一类是开源框架，比如 Genkit 这类工具链，可以自己搭建 skills 加载机制；还有一类是直接基于模型 API 自己实现 skill 调度逻辑。

选哪个，取决于你的实际需求。如果你是在做企业级应用，需要稳定的托管和运维，云平台方案省心但灵活性受限。如果你需要深度定制，或者想完全掌控 skill 的加载和执行逻辑，自己实现更合适。我自己的项目里，因为需要和已有的 GKE 集群集成，选择了在容器化环境里自己实现 skill 调度，这样能更好地控制资源隔离和权限。

环境准备的核心是确定 skill 的存储和加载方式。skill 本质上是一些配置文件加代码，可以存在本地文件系统，也可以存在数据库或对象存储里。我推荐用文件系统加版本控制的方式，每个 skill 一个目录，目录里放元信息文件、指令文件、示例文件和测试文件。这样便于版本管理，也便于团队协作。目录结构大概长这样：

skills/ python-security-review/ skill.yaml instructions.md examples/ input1.py output1.json tests/ test_review.py >name: csv-data-cleaning description: 清洗 CSV 数据，处理缺失值、重复行、格式不一致和异常值 version: 1.0.0 triggers: - 数据清洗 - 清洗 CSV - 处理缺失值 - 去重 - data cleaning inputs: - name: file_path type: string description: CSV 文件路径 - name: strategy type: string description: 缺失值处理策略，可选 drop、fill_mean、fill_median、fill_mode default: drop outputs: - name: cleaned_file_path type: string description: 清洗后的文件路径 - name: report type: object description: 清洗报告，包含处理的行数、列数、缺失值数量等 dependencies: - python>=3.9 - pandas>=1.5

然后写指令集。指令集我用 Markdown 格式，因为可读性好，模型理解起来也顺畅：

# 任务目标 对指定的 CSV 文件进行数据清洗，输出清洗后的文件和清洗报告。 # 前置检查 1. 确认 file_path 指向的文件存在且为 .csv 格式 2. 确认 strategy 参数在允许范围内 3. 检查 pandas 是否可用 # 执行步骤 1. 读取 CSV 文件，记录原始行数和列数 2. 统计每列的缺失值数量和比例 3. 根据 strategy 处理缺失值： - drop：删除包含缺失值的行 - fill_mean：用列均值填充数值列缺失值 - fill_median：用列中位数填充数值列缺失值 - fill_mode：用列众数填充分类列缺失值 4. 检测并删除完全重复的行，记录删除数量 5. 对字符串列进行去空格和统一大小写处理 6. 对数值列检测异常值（超过 3 倍标准差），在报告中标记但不自动删除 7. 保存清洗后的文件，文件名加 _cleaned 后缀 8. 生成清洗报告 # 分支处理 - 如果文件为空，直接返回错误提示，不执行后续步骤 - 如果某列缺失值比例超过 80%，在报告中特别标记，建议用户考虑删除该列 - 如果 strategy 为 fill_mean 但列不是数值类型，回退到 fill_mode 并记录警告 # 输出规范 清洗报告为 JSON 格式，包含以下字段： - original_rows：原始行数 - original_columns：原始列数 - missing_values：每列缺失值数量 - duplicates_removed：删除的重复行数 - outliers_flagged：标记的异常值数量 - warnings：警告信息列表 # 边界说明 本 skill 仅处理 CSV 格式。如果输入是 Excel、JSON 或其他格式，应转给对应的 skill 处理。

这个指令集里，我特意加了分支处理和边界说明。分支处理让 skill 在面对异常输入时不会直接崩溃，边界说明则明确了 skill 的适用范围，避免 Agent 在不该用的时候硬用。

4.3 测试与调试：怎么知道 skill 写对了

skill 写完不是就完了，必须测试。我通常从三个层面测试：单元测试、集成测试和端到端测试。

单元测试针对 skill 的核心逻辑。比如数据清洗 skill，我会准备几个小 CSV 文件，分别测试缺失值处理、去重、格式统一等功能是否按预期工作。单元测试用代码写，可以自动化运行，每次改完 skill 跑一遍，确保没有回归。

集成测试验证 skill 和 Agent 的配合。把 skill 加载到 Agent 里，用自然语言描述任务，看 Agent 是否能正确触发 skill、传入正确参数、处理返回结果。这一步经常能发现元信息或指令集的问题。比如我写过一个 skill，单元测试全过，但集成测试时 Agent 死活不触发，排查发现是触发关键词写得太窄，用户换个说法就匹配不上。

端到端测试模拟真实使用场景。用完整的任务描述，从用户输入到最终输出走一遍，看整体体验是否流畅。这一步能发现一些边界问题，比如多个 skill 同时被触发时会不会冲突、skill 执行失败时 Agent 有没有合理的降级处理。

调试 skill 时，我有个习惯：把 Agent 的决策过程打印出来。很多框架支持输出 Agent 的思考链，能看到它为什么选择某个 skill、为什么传这些参数。这个信息对调试非常有用。有一次我发现 Agent 总是给数据清洗 skill 传错 strategy 参数，看了思考链才发现，是我在指令集里对 strategy 的描述不够清晰，Agent 理解偏了。改清楚描述后，问题就解决了。

4.4 接入实际项目：几个关键配置

skill 测试通过后，接入实际项目还有几个配置要注意。

第一，加载策略。是启动时加载所有 skill，还是按需动态加载？启动时加载简单，但 skill 多了会占用大量内存和上下文。按需加载灵活，但需要实现匹配逻辑。我的建议是，skill 数量少于 20 个时，启动时加载全部元信息，执行时按需加载完整内容；超过 20 个时，考虑用向量检索的方式做元信息匹配，只加载最相关的几个 skill。

第二，超时和重试。skill 执行可能失败，比如外部工具不可用、网络超时。要给每个 skill 设置合理的超时时间，并定义重试策略。我的经验是，读操作可以重试，写操作要谨慎重试，避免重复写入。重试次数一般不超过 3 次，超过就报错让上层处理。

第三，日志和监控。skill 的执行情况要记录日志，包括触发时间、输入参数、执行结果、耗时、错误信息。这些日志对排查问题和优化 skill 都很有价值。我一般会把日志按 skill 名称分类，方便快速定位是哪个 skill 出了问题。

第四，版本管理。skill 会迭代，不同版本可能行为不同。要在元信息里标注版本，并在加载时记录使用的版本。如果发现某个版本有问题，可以快速回滚。我吃过这个亏：一个 skill 更新后没做好版本管理，线上出问题想回滚，发现旧版本已经被覆盖了，只能紧急修复，非常被动。

5. 常见问题与排查技巧实录

5.1 skill 不触发或触发错误怎么办

这是最常见的问题。Agent 该用某个 skill 时没用，或者不该用时用了。排查思路如下。

先检查元信息的触发关键词。把用户的实际输入和触发关键词对比，看是否有匹配。如果没有，补充同义表达。如果有匹配但没触发，可能是匹配逻辑的问题，比如大小写敏感、分词方式不对。这时候要看框架的匹配实现，必要时调整。

再检查是否有其他 skill 竞争。如果多个 skill 的触发条件重叠，Agent 可能选了另一个。这时候要调整元信息，让每个 skill 的适用范围更清晰。我的做法是给每个 skill 加一个“优先级”字段，冲突时按优先级选择。

最后检查指令集里是否有排除条件。有时候 skill 被触发了，但指令集里的前置检查没通过，Agent 就放弃了。这时候要看前置检查是否过于严格，适当放宽。

5.2 skill 执行结果不稳定怎么排查

同一个 skill，同样的输入，有时候结果好，有时候结果差。这种不稳定通常来自几个方面。

输入格式不一致。用户输入可能是自由文本，Agent 提取参数时可能提取出不同的结果。解决办法是在指令集里明确参数提取规则，或者加一个参数校验步骤。

上下文干扰。如果对话历史很长，或者同时加载了多个 skill，上下文里的信息可能干扰当前 skill 的执行。解决办法是执行 skill 时清理无关上下文，只保留必要信息。

模型随机性。模型输出本身有随机性，同样的输入可能产生不同输出。如果对稳定性要求高，可以降低温度参数，或者让 Agent 多次执行取一致结果。我在做关键任务时，会让 Agent 跑三次，取多数一致的结果，稳定性提升明显。

5.3 skill 之间冲突或循环调用怎么处理

多个 skill 组合使用时，可能出现冲突或循环调用。比如 skill A 的输出触发了 skill B，skill B 的输出又触发了 skill A，形成死循环。

解决办法是设置调用深度限制。每个 skill 执行时记录调用链，如果发现循环，就中断并报错。另外，skill 的输入输出 schema 要设计得足够明确，避免模糊匹配导致意外触发。

还有一个经验：给 skill 分组。把功能相关的 skill 放在一组，组内 skill 可以互相调用，组间调用需要显式声明。这样能减少意外冲突。我在一个项目里把 skill 分成“数据处理组”“分析组”“输出组”，组内调用自由，组间调用需要经过一个调度 skill，冲突问题少了很多。

5.4 常见问题速查表

这张表是我在实际项目中总结的，基本覆盖了八成以上的常见问题。遇到问题时先查表，能快速定位方向，再深入排查。

5.5 几个容易踩的坑和独家技巧

坑一：元信息写得太泛。我见过一个 skill 的描述是“用于处理数据”，这种描述等于没描述。Agent 根本不知道什么时候该用它。后来改成“用于清洗 CSV 文件中的缺失值和重复行”，触发准确率立刻上去了。

坑二：指令集里堆知识。前面提过，模型本身有知识，你堆进去反而占用上下文。把知识换成操作步骤，效果更好。

坑三：忽略示例的作用。示例比指令更能约束模型行为。我现在的习惯是，每个 skill 至少配三个示例，覆盖正常情况、边界情况和异常情况。示例写好了，指令集可以精简一半。

技巧一：用测试驱动 skill 开发。先写测试用例，明确输入输出，再写 skill。这样写出来的 skill 目标清晰，不容易跑偏。

技巧二：给 skill 加“自检”步骤。在指令集最后加一步，让 Agent 检查自己的输出是否符合规范。这一步能拦截不少格式错误。

技巧三：定期回顾 skill 使用日志。看看哪些 skill 经常失败、哪些很少被触发。失败的优化，不用的清理。保持 skill 库精简高效。

技巧四：skill 命名要有规律。我用“领域-功能-版本”的命名方式，比如“data-cleaning-v1”“code-review-security-v2”。这样一眼就能看出 skill 的用途和版本，管理起来方便。

6. 关于 skills 生态的一些个人观察

skills 这个概念火起来之后，各种 skills 市场、skills 推荐、skills 大全也跟着出现了。有人在做 skills 的分享平台，有人在做 skills 的自动生成工具，还有人把 skills 和特定领域结合，比如写论文的 skills、做分镜的 skills、安全测试的 skills。这个生态正在快速形成。

我的判断是，skills 的价值最终取决于质量而不是数量。一个精心设计的 skill，比一百个粗制滥造的 skill 有用得多。现在很多 skills 市场里，大量 skill 只是把提示词换了个包装，没有真正的模块化设计，也没有测试和版本管理。这种 skill 用起来问题很多，反而会增加维护负担。

如果你打算认真做 skills，我的建议是：少而精。先把一两个核心场景的 skill 做扎实，跑通测试，接入实际项目，验证效果。有了成功经验再扩展。不要一上来就追求大而全，那样很容易做成一个没人用的 skill 库。

另外，skills 的可组合性是它最大的潜力所在。单个 skill 的能力有限，但多个 skill 组合起来，能完成非常复杂的任务。我最近在尝试把数据清洗、数据分析、报告生成三个 skill 串起来，用户只需要提供一个原始数据文件，Agent 就能自动完成从清洗到报告的全流程。这种组合带来的效率提升，是单个 skill 无法比拟的。后续我还会继续探索更多 skill 组合的可能性，比如把代码审查和自动修复结合，把文档生成和翻译结合。这个方向值得投入时间。

最后分享一个我在实际使用中的小体会：skill 的迭代不要追求一步到位。先写一个能用的版本，跑起来，收集问题，再迭代。我最早的一个 skill 只有十几行指令，经过十几次迭代，现在有几百行，但每一行都是根据实际问题加进去的。这种从实践中长出来的 skill，比一开始就设计得很复杂的 skill 更实用、更稳定。