企业官网建设流程全解析

从 Prompt 到 Skill：AI 编程时代的可复用技能设计框架

这两年我花在 AI 编程助手上的时间，比花在搜索引擎上的还多。代码生成、重构、写测试、查报错，几乎每个环节都在和 Prompt 打交道。但用着用着我发现一个问题：每次遇到同一类任务，我都在重复输入几乎一样的话。改个报错要重新描述一遍项目结构，写个单元测试要重新交代一遍框架版本，做个代码审查又要重新列一遍关注点。

这感觉就像你每天都在用手工锯木头，明明可以做个夹具，却懒得动手。直到我开始系统性地把常用 Prompt 沉淀成 Skill，才意识到这一步的差距有多大。这篇文章想聊的，就是我从“临时写 Prompt”切换到“设计可复用 Skill”这套方法论的全过程——包括我踩过的坑、总结出的框架，以及一套可以直接照抄的设计模板。

先说清楚这篇文章适合谁：如果你每天都在用 AI 编程助手，但总觉得输出质量不稳定；如果你手上攒了几十条 Prompt，却不知道该怎么整理；如果你想让团队里的新人也能用上你的最佳实践——这篇文章应该能给你一些启发。内容不涉及具体某个厂商的工具，而是讲通用的设计思路和落地方法，你用哪家都能套得上。

1. 从一次性 Prompt 到可复用 Skill，到底发生了什么变化

1.1 一次性 Prompt 的固有缺陷

先说个很具体的场景。假设你想让 AI 帮你写一个 Python 装饰器，用来统计函数执行耗时。你随手敲了一段话：“帮我写一个装饰器，统计函数运行时间。”AI 确实能给你写出来，而且看起来还挺像那么回事。然后你复制到项目里，发现有个地方有问题：你的项目里用了异步函数，装饰器没处理 async 的情况。于是你又补一句：“改成支持异步的。”它改了。过几天你又发现需要传参数给装饰器，又补一条。来回折腾几轮之后，你手里这段对话已经变成了一个十几轮的长上下文，每次重新开个会话都要从头再来。

这就是一次性 Prompt 的核心问题：它是无状态的。每一次都是“从零开始”，AI 不知道你项目里用什么 Python 版本，不知道你的代码风格是类型标注全开还是能省就省，不知道你公司内部的 logging 规范。它只能依靠你当前这句 Prompt 和上下文里的碎片信息来猜。猜对了是运气，猜错了才是常态。

还有一个更隐蔽的问题：你没办法积累经验。假设你终于把那个装饰器的需求聊明白了，AI 给了一版能用的代码。你有没有把这个过程固化下来？大多数人的答案是：没有。下次遇到类似需求，你大概率又是从零开始描述。你的时间没有复利，你的 Prompt 技巧没有复利，你和 AI 的协作效率也没有复利。

1.2 Skill 的本质：把经验封装成可调用的单元

Skill 这个概念，简单说就是把“一段结构化的指令 + 必要的上下文模板 + 明确的使用触发条件”打包成一个可以反复调用的单元。它做的不是替你写某一行代码，而是把“怎么做一件事”的方法论固化下来。

举个例子。同样是“生成单元测试”这个任务，一次性 Prompt 是：“帮我给这个函数写点测试。”而一个 Skill 会包含：

• 触发条件：当用户请求生成测试时被激活
• 输入参数：函数签名、依赖的 mock 对象、需要覆盖的分支
• 执行流程：先分析函数依赖，再设计测试用例，然后按项目模板生成代码，最后自查断言覆盖率
• 输出规范：遵循当前项目的测试风格（比如 pytest 还是 unittest），注释要不要写中文，断言要不要带 msg

这个区别就像请一个实习生做事。你说“把这个表格整理一下”，他大概率会给你一个包含了原始数据的表格，因为他不知道你要什么维度、什么格式、给谁看。但如果你给他一份详细的操作手册——先清洗空值，再按日期排序，最后生成透视表，他就能稳定输出你想要的东西。Skill 就是这份操作手册，它把“怎么做”这件事从 AI 的临场发挥变成了流程化执行。

我自己感受到的最大变化是：从“每次重新沟通”变成了“一次配置，多次调用”。刚开始搭第一个 Skill 时，花了我大概一小时来调参和优化模板。但之后每次用到它，我的输入时间从五分钟缩短到了半分钟，输出质量还更稳定了。这才是真正的效率杠杆。

1.3 为什么是现在：AI 编程工具的能力边界正在变化

两年前的 AI 编程助手，基本只能做“短距离上下文”的代码补全，你写的下一个 token 它能猜中，但让它理解整个项目结构、按照团队规范输出完整模块，基本上做不到。那时候谈 Skill 设计，有点超前。

现在不一样了。主流 AI 编程工具基本都支持长上下文理解、仓库级代码索引、自定义规则注入。这意味着 AI 已经可以从你的项目里读取真实的代码风格、接口定义、历史提交记录来做判断。但与此同时，它也给使用者的 Prompt 提出了更高要求——你描述得越含糊，它发挥得越飘忽。

这正好是 Skill 发挥价值的时候。长上下文能力让 Skill 可以携带大量项目级上下文，仓库级索引让它能自己找到相关代码，自定义规则又让 Skill 的输出能直接对齐团队规范。这些能力在 2023 年那会儿根本不存在，所以那时候你只能准备一堆 Prompt 备忘。今天你把它们固化成 Skill，工具的算力才能真正变成你的生产力。

2. Skill 设计框架的核心要素

2.1 目标定义：明确这个 Skill 为谁解决什么问题

设计 Skill 的第一步，不是写模板，而是回答三个问题：

• 这个 Skill 服务什么场景？（代码生成、重构、审查、调试、文档、测试？）
• 这个场景里的用户是什么样的？（新手、中级、高级开发者？）
• 什么样的输出算“合格”？（代码通过 Lint、测试全绿、满足某个规范？）

这三个答案会直接影响你后面写 Prompt 时的详细程度。比如你是给团队里的初级开发者用的代码审查 Skill，那输出里的解释就要详细一点，最好带上“为什么这里要注意”的说明；如果你是给自己用的重构 Skill，那解释就可以精简，直接给结论就行。

我刚开始做 Skill 时犯过一个错：想把所有场景塞进一个 Skill 里。“这个 Skill 既能生成代码又能写测试还能做审查”，听起来很全能，实际用起来一团糟。因为指令越长，AI 越容易在长指令中迷失优先级。你把五件事混在一起说，它大概率会做到每件事都只做了七成。

这个阶段的产出物是一句话：这个 Skill 的一句话定义。比如：“代码审查 Skill——对指定文件进行逐行审查，输出问题列表和修复建议，遵循团队编码规范。”写清楚这一句，后面所有设计都知道往哪个方向使劲了。

2.2 上下文收集：Skill 能用到的信息从哪里来

Skill 和普通 Prompt 最大的区别，就在于它能在执行时自动收集上下文。但很遗憾，目前大部分工具还不能做到让 Skill 自己满仓库乱翻代码。所以你要设计的是：这个 Skill 需要用户提供哪些信息？哪些信息可以通过代码库索引自动获取？哪些信息需要从交互中明确表达？

拿“生成 API 接口文档”这个 Skill 来说。它需要知道：接口的路由路径、HTTP 方法、请求参数、返回结构、鉴权方式。其中路由和方法通常可以从代码里直接看到，请求参数和返回结构也可以从类型定义里推断，但鉴权方式这种偏隐性的信息，可能就要靠开发者补充一句“这个接口需要 Admin 角色”。

设计上下文收集的时候，有一个平衡要把握：不是信息越多越好。你把一个 Skill 的输入参数设计成 20 个字段，看起来面面俱到，实际用的时候用户填都懒得填。我建议控制在 5 个以内，把最关键的、AI 自己不好获取的信息留出来让用户填，其余的全靠自动收集。

还有一类常见信息是“约束条件”。比如：Python 版本必须 3.10+、不允许用全局变量、日志必须走标准库。这类信息适合放在 Skill 的固定规则段，而不是每次调用时让用户重复说。这也体现了 Skill 的另一个价值——把散落在各个项目里的“规矩”集中固化下来。

2.3 输出规范：对“合格”的定义越细越好

这是最容易被忽略但影响最大的一步。很多人在写 Skill 时，把输入侧设计得很完整——要什么、不要什么、从哪拿信息——但到输出侧就只写一句“生成结果”。结果就是 AI 确实按照你的要求做了，但做出来的东西总差口气。

举个具体例子。我的一个“代码审查 Skill”，最初版本对输出的定义是：“列出发现的问题并给出修改建议。”听起来没毛病，对吧？实际用下来的问题可大了。AI 有时候给的是一个长篇散文式的分析，有时候给的是零散的几句话，有时候会在每个问题前面加一段客套话。虽然内容勉强可用，但你要从这一堆废话里提取真正的行动项，效率反而比不用 Skill 还低。

于是我重写了输出的定义，改成结构化格式：

• 每个问题必须单独编号
• 每个问题必须包含：严重级别（P0/P1/P2）+ 文件位置 + 问题描述 + 修复建议
• P0 代表会导致 bug 或安全风险，P1 代表影响可维护性，P2 代表风格类问题
• 最终输出一个修复优先级列表

改完之后的效果立竿见影。AI 不再输出散文了，给出来的就是一张一眼能看完的表格，按 P0 顺序处理就行。这个经验让我意识到：输出规范是 Skill 设计里最值得花时间的地方。你把“合格”的定义细化到什么程度，AI 的稳定输出就能到什么程度。

3. Skill 内容设计：从指令骨架到细节打磨

3.1 角色设定与规则段：让 AI 知道该用什么身份干活

设计 Skill 时，一开始要定义好角色。这个角色不是为了好玩，而是为了让 AI 在生成回答时自带一套先验的偏好。你让它扮演“一个资深的 Python 后端工程师”，它在写代码时会更倾向于遵循 PEP8、会主动考虑异常处理和边界条件、会在设计接口时考虑扩展性。你让它扮演“一个刚入行三个月的初级开发者”，它会写得相对简单直白，注释也更详细。

这个区别在实际输出中是非常明显的。我自己试过同一个重构 Skill，角色设定为“资深工程师”时，AI 生成的重构方案会主动考虑性能影响和不兼容风险；角色设定为“初级开发者”时，生成结果就相对稚嫩，很多细节不会主动想。所以，我给自己的建议是：除非你有意为之，否则 Skill 的角色一律用“资深”起步。

规则段是角色之外的硬性约束。这里放的是“违反就会出问题”的事项。比如：

• 生成代码时必须包含类型标注
• 禁止使用第三方库重写标准库能实现的功能
• 所有错误处理必须显式返回错误信息，而不是吞掉异常
• 文件名和函数名遵循当前项目的命名规范

规则段的写法要极简，每条一句话，不解释原因。原因写多了反而会稀释指令的权重。AI 处理长文本时，对“必须”“禁止”这种强约束词更敏感，对长篇大论的解释反而容易忽略。

3.2 执行步骤设计：把任务拆成 AI 可以逐步消化的小环节

我见过很多写得不错的 Skill，开头定义出色，规则部分清晰，输出格式也明确，但就是执行效果不稳定。后来发现问题出在“只定义了做什么，没定义怎么做”上。AI 是单步推理的，你给它一个复合任务，它可以自己拆解，但拆解出来的路径不一定是你想要的。

举个例子。一个“将旧代码迁移到新框架”的 Skill，如果你只说“把这个模块迁移到新版框架”，AI 可能直接从文件头开始改，边改边遇到问题边停下来猜。结果就是改到一半，旧的依赖关系没理清，新代码又引入了兼容性问题，输出极其不稳定。

我后来把这个 Skill 的执行步骤拆成了四步：

1. 分析当前模块的依赖关系图，梳理出要迁移的接口和数据结构
2. 对照新框架的迁移指南，列出所有可能需要调整的调用点
3. 按依赖顺序逐层改造，先改底层数据模型，再改上层业务逻辑
4. 全局搜索旧的 API 调用，确认没有遗漏，编译并运行测试

每一步都让 AI 先输出中间分析，确认无误后再进入下一步。这样做的好处有两个。一是你可以在中途纠偏，如果 AI 在第一步理解错了依赖关系，你不用等它改完全部代码才发现。二是 AI 分步执行时，每一步的注意力更集中，生成的代码质量明显比一口气干完要高。

3.3 上下文注入：把项目信息“喂”到合适的位置

Skill 里有一个很微妙的环节：哪些上下文是固定不变的，哪些是需要动态注入的？固定不变的信息，比如公司编码规范、常用库版本、禁止使用的依赖，可以直接写死在 Skill 的规则段里。动态信息，比如当前要处理的文件路径、相关的业务模块、特殊的需求上下文，需要设计成变量，在调用时由用户传入。

我常用的做法是：在 Skill 模板里保留一个【上下文区域】，专门放本次调用时的项目特定信息。比如代码审查 Skill 的模板大概是：

【审查目标】 文件路径：{{file_path}} 相关需求上下文：{{context}} 【审查焦点】 - 并发安全 - 数据一致性 - 错误处理完整性

这个设计的关键是，让固定的和可变的分开，避免每次调用时都去改写 Skill 的规则部分。规则部分越稳定，AI 越不容易被带偏。上下文区域越灵活，Skill 越能在不同场景下复用。

还有一个小技巧：如果 Skill 要处理的是一个大型代码库，建议在上下文区域里附上关键入口文件路径，而不是让 AI 全局搜索。给它指一条近路，既能节省它的思考时间，又能减少因为搜索偏差导致的误判。

4. 实操案例：从零搭建一个“代码重构”Skill

4.1 案例需求与设计拆解

这一节我拿一个真实做过的 Skill 来走一遍全流程。需求背景：我手上有一个历史项目，技术栈比较老，用的是 jQuery 时代的写法，代码里到处都是匿名回调、全局变量和字符串拼接的 DOM 操作。我打算逐步把它重构成模块化的现代 JavaScript。因为项目太大，不可能一次改完，所以我需要一个稳定的、可复用的流程来每次重构一个文件或者一个模块。

设计目标其实很清楚：让 AI 在重构每一个文件时，都能遵循一致的流程，不破坏现有的功能，同时逐步引入模块化结构。

这个 Skill 的输入设计为三个参数：

• 重构目标：要处理的文件路径或模块路径
• 重构范围：是只重构这一个文件，还是连带它的依赖一起重构
• 特殊要求：比如哪些逻辑必须保留原样、有没有兼容性要求

输出设计为结构化报告：重构前后代码对比、每一步的改动说明、可能存在的风险点、回归测试建议。

4.2 Skill 指令模板（可直接复制修改）

基于上面的需求，我拆解出来的指令模板大概是这样的（已脱敏，数据结构可以按你的工具做微调）：

# 角色 你是一位资深前端工程师，擅长在不改变外部行为的前提下，对遗留代码进行渐进式重构。 # 规则 - 禁止在一次重构中改变任何对外接口的行为 - 必须保留原有的错误处理和边界条件逻辑 - 新代码必须使用 ES Module 语法 - 每一步重构必须附带简短的说明 # 目标 【重构目标】: {{file_path}} 【重构范围】: {{scope}} 【特殊要求】: {{special_requirements}} # 执行流程 第1步：分析文件依赖 - 列出该文件引用了哪些外部模块 - 列出哪些其他文件引用了该文件 - 分析该文件内部是否存在隐式全局依赖 第2步：拆分功能模块 - 识别独立的逻辑单元（事件绑定、数据请求、DOM渲染等） - 建议拆分方案，但不要立刻动手 第3步：逐步实施重构 - 先抽取纯逻辑到独立函数/模块 - 再替换 DOM 操作方式（如有必要） - 最后整理事件绑定与生命周期 第4步：自查与测试建议 - 确认重构后的代码没有改变原有调用方式 - 列出需要手工回归测试的场景 # 输出格式 - 文件：重构后完整代码 - 说明：每段改动对应的理由与风险 - 回归：需要重点验证的功能点清单

4.3 参数选择的逻辑和使用指引

你看这个模板，我把【特殊要求】设计成了一个自由文本参数，这是因为实际项目中常有各种临时约束，比如“这次顺带把回调改成 Promise 风格”或者“这个文件暂时不要拆分太细，保留单文件结构”。如果把这些都做成固定的规则，Skill 会变得越来越臃肿，最后变成一个几乎没人愿意调用的庞然大物。

而【重构范围】这个参数，我设计成三个取值：单文件、带直接依赖、包模块树。单文件就是只动眼前这个文件，适合小步快跑；带直接依赖会连带调整该文件直接 import 的模块；包模块树则是整个依赖子树全部重构。取值越小越安全，默认建议选单文件。

这里有一个实际的教训。我第一次用这个 Skill 时，给了一个比较大的 Vue 组件文件，里面还引用了好几个公共工具模块。我图省事选了“带直接依赖”，结果 AI 把公共模块也改了，而公共模块在别处用了 20 多回，差点引发大面积回归。后来我把输出规范里明确加了一条：“如果发现目标文件依赖了跨模块共享的工具函数，优先保留其原实现，并在说明中标记出来，不主动修改。”从那以后，重构的回归率明显降下来了。

使用这个 Skill 的正确姿势是：一次只丢给它一个文件，重构完跑一遍该文件的测试，确认没问题再丢下一个。如果你期望 AI 一次解决一个大模块的重构，效果往往不稳定，反而更难排查问题。渐进式重构的意义就在于，每次改动足够小，出问题可以立刻定位。

5. 将 Skill 融入日常开发的落地步骤

5.1 从使用场景反推 Skill 清单

很多人问：我该设计多少个 Skill 才够？我的回答是：不要为了有 Skill 而做 Skill。你平时怎么用 AI，就照着那个清单去设计就行。先花一周时间记录你现在高频使用 AI 的场景，然后按使用频率从高到低排序，先做前三个。

我自己目前日常在用的 Skill 清单大概是：

• 代码审查 Skill：对新写的代码或改动进行 review，输出结构化问题清单
• 单测生成 Skill：给指定函数生成单元测试，覆盖正常路径、边界、异常路径
• 重构 Skill：上面详细讲过那个
• 报错诊断 Skill：把一条报错信息 + 相关代码片段输入进去，输出根因分析
• 提交信息生成 Skill：基于 git diff 生成符合规范的 commit message

这些 Skill 不是一开始就有的。我先做了代码审查和单测生成，用了两周稳定之后，才逐步补了后面几个。每一步都在实际使用中迭代优化模板，而不是一次性写好一个“完美”的版本。

5.2 建立自己的 Skill 迭代节奏

Skill 不是一次性写好的，它需要随使用反馈不断迭代。我自己的迭代节奏大概是：每用 5 次产出一个改进点，每用 20 次做一次版本更新。改进点来源于你实际使用时的感受——哪个输出不够精确？哪个参数总是不填？哪个规则总是被 AI 忽略？

这里分享一个我曾经走过弯路的改进案例。我的单测生成 Skill 早期版本里，有一条规则是“测试代码需要覆盖所有分支”，但实际执行中发现 AI 对“所有分支”这个表述的理解非常宏观，经常漏掉异常分支。后来我把规则细化成：“必须覆盖以下六类用例：正常路径、空值输入、非法类型、越界值、异常抛出场景、极端大值场景。”细化后的覆盖率高了很多，因为列举具体类别比抽象概念更不容易遗漏。

这一步也给一个建议：给每个 Skill 加上版本号和使用笔记。版本号帮你记录迭代里程碑，使用笔记记录每次改进的原因和效果。等过几个月回头看，你能清晰感受到一个 Skill 从粗糙到成熟的过程，这个记录本身就是你的工程资产。

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

6.1 生成结果飘忽不定，不同时间跑差异巨大

这个大概是用 Skill 时遇到最多的抱怨。同一个 Skill，同一个输入，早上跑和晚上跑结果不一样，换个模型跑又不一样。

排查思路分几步。先检查你的 Skill 里有没有“模糊表述”。比如“请适当地优化代码”，“适当地”这个词就是典型的模糊指令，AI 每次对“适当”的理解都可能不同。把这些模糊词换成可执行的量化标准，比如“优化后函数体不得超过 20 行”或者“提取重复代码为独立工具函数”。

再检查你的输出规范是否足够结构化。如果输出格式是自由文本，那每次不同是必然的。把输出拆成固定字段，AI 在填写字段时受到的约束会强很多。

最后检查参数设计是否覆盖了核心变量。如果 Skill 输入参数太少，AI 只能靠猜来补充缺失信息，猜出来的结果自然不稳定。试着把你总是在对话里补充的话，变成 Skill 的一个可选输入参数。

6.2 明明写清楚了规则，AI 就是不遵守

我见过最多的违反类型就是“规则冲突”。比如你的 Skill 里写着“生成代码必须包含完整注释”，但输出规范又写着“最终给出精简版代码”，这两条其实是在互相打架。AI 面对冲突指令时，往往会优先遵循输出格式的要求，于是你发现注释没了。

排查这类问题的方法很简单：把 Skill 里所有“必须”和“禁止”列出来，逐一检查是否自洽。我常用一个“每条规则下再问一句反例”的方法——如果这条规则不生效，会是什么原因？往往一查就发现问题出在规则之间互相矛盾。

如果规则本身没问题但 AI 就是无视，那大概率是规则的位置太靠后了。AI 对前面两三段的指令注意力最强，后面的规则容易被稀释。把最重要的规则、最容易出错的约束提到指令开头，能显著提升遵守率。

6.3 Skill 太长了，AI 处理不过来导致输出被截断

这个问题在上下文窗口受限的时候尤其明显。一个 Skill 指令动辄一两千字，再把代码内容贴进去，很容易超过单次处理上限。表现就是输出往往到一半就停了，或者后半段的规则被 AI 忽略。

应对方案是把大而全的 Skill 拆成小组合。不用把整个流程设计在一个 Skill 里，拆成几个小型 Skill 串着用。比如“代码重构”这个工作，拆成“依赖分析 Skill + 逐步重构 Skill + 回归测试建议 Skill”，每一步都只用一个小而精准的指令集，执行效果反而比一个大而全的 Skill 好得多。

6.4 怎么验证一个 Skill 真的改好了

经常有人问我：如何判断一个 Skill 是否已经调优到位？我的标准很简单：同一个输入，连跑五次，每次输出的结构一致、结论一致、关键建议一致。细微的表达差异不影响使用，但核心内容如果五次都不一样，说明 Skill 还不够稳，需要继续打磨。

也可以做“极端输入测试”。给 Skill 输入一个完全超出预期的内容，看它是合理拒绝还是强行处理。比如代码审查 Skill，你丢给它一个只有三行的空壳函数，它不应该像模像样地分析出一堆问题来，而应当明确指出“目标文件过小，缺少足够的审查面”。这个表现能透露出 Skill 对边界条件的理解程度。

7. 从个人技能到团队资产：Skill 的分享与移植

7.1 为什么 Skill 需要版本化和文档化

当 Skill 从个人工具变成团队共享资产时，它就不再只是一段 Prompt 了。它本质上是你团队工程经验的封装：你们的代码规范、踩过的坑、沉淀出的流程，全在一个 Skill 里。如果这些经验只存在于某位资深开发者的私人配置里，对团队来说等于没有资产沉淀。

我建议给每个 Skill 配一个简短的 README，写清楚三件事：这个 Skill 解决什么问题、最佳实践是什么、已知的边界和注意点。版本记录里写清楚每次改了什么、在什么场景下验证过。这样团队成员拿到一个 Skill 时，能快速理解它的定位和限制，而不是打开模板看半天仍然一头雾水。

版本化还有一个额外好处：你可以放心迭代。改坏了回退到上一版，改好了记录这个版本的效果。不用怕“把这个 Skill 改坏了”而不敢动它。有了版本树，每一次改动都是可追踪的。

7.2 团队共享 Skill 时的小技巧

刚把 Skill 分享给团队时，我发现新人经常遇到一个困惑：“模板我理解了，但不知道具体调用时应该填什么。”后来我在每个 Skill 的参数说明后面加了一个示例输入，效果立竿见影。比如重构 Skill 的示例填的是：“重构目标：src/components/UserProfile.js，重构范围：单文件，特殊要求：保持 API 返回结构不变。”新手一看就知道该怎么填了。

另外，Skill 里的规则最好不要用团队内部的黑话。外人可能不知道你们说的“XX 规范”是什么具体内容，所以要么把它展开成可理解的明文规则，要么在 README 里附一个“适用规范链接”。这一点在我们团队踩过坑——新人拿到一个写满了缩写的内部 Skill 模板，完全不知道该如何执行，最后还是要找原作者对口述一遍，效率不升反降。

8. 未来方向：Skill 如何与 AI 开发流程深度整合

这一部分没有严谨的数据和事实来支撑，主要是从我自己体验中延伸的思考和预测。AI 编程工具已经足够强大，但使用者的水平差距正在变成一条越来越宽的鸿沟。有人拿它当加强版自动补全，有人拿它当可靠的结对编程搭档，这个差距的根源不在模型能力，而在你愿不愿意花时间去沉淀方法论。

Skill 恰好是沉淀方法论的有效载体。往后看，我判断 Skill 的价值会越来越大，而不是越来越小。模型能力越强，通用 Prompt 的输出质量越高，但通用的东西很容易遇到天花板。你需要的是符合你项目特点、你团队规范、你个人偏好的定制流程，这些东西只有自己搭 Skill 才做得到。

再往后，Skill 的形式可能会超越“指令文本”这单一的形态。它可能会包含更多示例数据、更复杂的条件分支、不同阶段调用的模型配置。但它沉淀经验和约束流程的本质，会在相当长时间内保持稳定。现在花时间把这套设计框架搭起来，后面无论工具怎么变，你的方法论都能平滑迁移。

回到我自己，用 Skill 这大半年最大的变化其实不在效率上，而在心态上。以前每做一个新任务，我都要重新想一遍，这次的程度要怎么把握，这个上下文要怎么组织。现在这些已经被固化在 Skill 里了。我需要做的是提供那 5 个参数，然后看它跑出来的结果，仅此而已。这种“设计好系统，然后让系统自动运转”的感觉，才是 AI 编程时代真正让人觉得舒服的地方。