企业官网建设流程全解析

最近和几个泡在AI编程里的朋友聊天，发现一个很有意思的分水岭：多数人还在琢磨怎么调Prompt，而已经开始跑通流程的人在聊Skill。不是说Prompt没用了，而是只要你在同一个代码仓库里反复做代码审查、生成单测、补注释、做迁移，就会发现每次重新组织提示词既低效又容易飘。Prompt是一次性的，Skill是可以沉淀的。我自己的体会是，AI编程时代的可复用技能，核心就是把人从“反复描述需求”里解放出来，把经验变成机制。这篇文章我会从踩过的坑出发，聊聊怎么从Prompt升级成Skill，以及如何设计一套真正能用的可复用技能框架。

如果你只是偶尔让AI写一段代码片段，那你用Prompt就够了；但如果你打算在真实项目里稳定使用AI辅助开发，想让新同事接手后也能用同一套标准干活，或者想把自己摸索出的工作流固化下来，那Skill一定是你绕不开的一环。不管是Claude、Codex这类代码工具，还是Spring AI这类开发框架，现在都在往“技能包”方向靠。下面这套设计框架，是我在项目里反复打磨后沉淀下来的，希望对你有用。

1. 为什么Prompt不够用了

1.1 Prompt的“一次性陷阱”

先说说我最早是怎么用Prompt的。那时候我写代码遇到问题，就把整段上下文、报错信息、相关文件往对话框里一贴，再附上一句“帮我看看哪里有问题，顺便给出修复方案”。一开始效果还行，可时间一长问题就出来了：第一，每次都要从头重新描述需求，上下文稍一变化结果就跟着变；第二，同一个任务换一个窗口、换一个模型，出来的代码风格和质量都不一样；第三，Prompt本身没有任何结构，AI只能把它当成一段自然语言来“猜”，而不是当成需求来“执行”。

最让我崩溃的一次，是我把同一个审查Prompt复制到三个会话里，让它们分别审查同一段代码，结果一个说“逻辑没问题”，一个说“有潜在死循环”，还有一个直接建议重构。这哪是AI编程，简直是在抽盲盒。后来我才想明白，Prompt本质上是一次性对话的背景说明，它不是系统，不是规则，也不是工具。它没有输入参数的校验，没有执行步骤的编排，没有输出格式的约束，一切全靠模型“临场发挥”。

很多人以为Prompt写得越长越细就越稳定，其实不然。模型对长文本的注意力是有限的，你的核心要求一旦淹没在几百行描述里，反而容易被忽略。而且Prompt升级换代之后，旧提示词很可能失效，你要重新调优，等于每次模型更新都要做一次“提示词回归测试”。我见过团队里有同事维护着一份20多条Prompt的Excel表，每次模型一升级就哀嚎一片。这种玩法，本质上是用人力对抗不确定性，注定不可持续。

1.2 Skill把“提示”变成了“程序”

既然Prompt不稳定，那怎么才能让AI稳定地执行一类任务？我的答案是把它变成Skill。Skill是什么？你可以把它理解成一个封装好的“程序”：它有名字、有参数、有执行步骤、有输出格式、有校验规则。你的角色从“每次重新描述需求”变成“调用一个函数”，传几个参数进去，拿到一份结构化的结果。

还是用代码审查举例子。Prompt版的写法是：“请帮我审查这个文件，重点看XX，建议用YY风格。”Skill版则会在内部定义一套完整流程：先读取指定文件，再提取变更行，接着按安全检查、逻辑错误、性能隐患、风格问题四个维度逐项扫描，最后输出一份带严重级别、行号定位和修改建议的JSON报告。这个流程是固定的，AI只是在执行它。就算换一个模型，只要它读得懂Skill的指令，输出的结构依然一致。

Skill的另外一层价值，是可以访问工具和环境。很多AI编程工具里的Skill并不是纯粹的文字提示，它还包含了调用文件读取、命令行执行、代码搜索、测试运行等外部动作。这样一来，Skill不再“闭着眼答”，而是“先看再答”，准确率自然高得多。实测下来，我把代码审查从Prompt改成Skill之后，误报率起码降了三成，输出格式也稳定了，后续接自动格式化、生成变更记录都顺了很多。

1.3 什么样的场景真正需要Skill

不是所有任务都值得做成Skill。我自己判断的标准有三条：一是任务是否高频重复，二是结果是否必须保持一致，三是流程是否可以拆成明确步骤。比如代码审查、单元测试生成、接口文档生成、依赖升级检查、日志分析、SQL优化，这些都很适合。它们每天都会遇到，而且不同人做出来的结果差别很大，正好可以让Skill来统一质量。

反过来，那些探索性的、需要大量人工判断的任务，比如“帮我设计一个系统架构”“给我一个产品创意方向”，就不太适合做成Skill。这类任务本身没有标准答案，过于结构化的流程反而会限制模型发挥。你说你是为了复用，其实是在复制偏见。一开始我总想把所有需求都塞进Skill，后来发现一个铁律：Skill是给“怎么做”建模的，不是给“做什么”建模的。需求你还是要人来定，技能负责把需求变成可靠的结果。

如果你现在还在犹豫要不要上Skill，我建议先从单个高频任务试起。挑一个你每周至少会重复三次的工作，比如代码审查或者写单测，花一上午把它做成Skill，跑一周看看效果。你会发现，真正难的其实不是写那个文件，而是想清楚这个任务到底有哪些隐式步骤、哪些质量标准是团队默认的、哪些异常情况需要兜底。把这些显式化，本身就值回票价。

2. 可复用Skill的设计框架

2.1 五要素模型：让Skill不再“裸奔”

我在项目里试过很多种Skill写法，后来总结出一个稳定的五要素模型：意图声明、输入定义、执行流程、输出定义、质量校验。这五个要素缺一不可，少了任何一个，Skill都会在各种边界情况下翻车。

意图声明是告诉模型“这个Skill解决什么问题、在什么时候用”。它的作用不只是为了让模型理解，更是为了让调度器判断要不要触发这个Skill。你写的意图越清晰，AI编程工具里的路由就越准确。比如“审查代码”这个意图就太模糊，我会写成“当用户要求对指定路径或PR变更进行代码质量审查，并希望获得结构化风险报告时使用”。这样既不会和“代码解释”“代码补全”冲突，也能避免被别的Skill抢走。

输入定义则是明确这个Skill接受哪些参数。比如代码审查Skill需要接收目标文件路径、变更范围（可选）、审查重点（可选）、输出语言（默认中文）。你要规定每个参数的类型、是否必填、默认值是什么。我见过有人把输入定义写得像一篇文章，反而把模型绕晕了。其实只要用类似JSON Schema的简洁结构描述就够了，让模型一眼知道该填什么。

执行流程是五要素里最核心的部分。你要把任务拆解成若干个有序步骤，并且每个步骤之间要有明确的产物和检查点。比如审查代码，我会拆成：读取文件结构、筛选本次变更涉及的代码块、逐块进行多维审查、生成评分和问题列表、给出修改建议。每走完一步，Skill都会要求模型先汇报中间结果，再决定是否继续。这样做的好处是，当某个环节出错时，你能知道是卡在哪一步，而不是等最终结果出来后一脸懵。

输出定义要解决的是“交付长什么样”的问题。强烈建议用结构化格式，比如JSON、Markdown表格、固定模板。模型对结构的遵从度比对自然语言高得多，你给一个输出样例，它就能照葫芦画瓢。质量校验则是最后一道闸门，定义什么算合格、什么算不合格，不合格时怎么处理。比如代码审查报告里如果出现“这段代码有问题”这种无定位的模糊语句，我会要求模型重新输出，必须包含文件路径和行号。没有校验的Skill，等于没有闭环。

2.2 写Skill要像写API：元信息与声明式结构

Skill和Prompt最大的区别之一，在于Skill是“可被程序解析”的。所以你不能只写一段漂亮的自然语言，还得给它配上元信息和声明式结构，让工具能自动发现、加载、组合它。

元信息至少应该包含：名称、描述、版本、作者、兼容模型、依赖工具。其中名称和描述是给调度器看的，版本和作者是给团队协作看的，兼容模型提醒你跨模型时可能需要调整。我习惯把Skill描述控制在三句话以内，第一句说干什么，第二句说适合什么场景，第三句说有什么限制。这样在工具列表里扫一眼就能知道用途。

声明式结构指的是用统一的格式（比如YAML、JSON或Markdown+Frontmatter）来描述Skill，而不是一段自由文本。我现在用的一种结构是这样的：最外层是元信息，接着是参数定义，然后是步骤列表，最后是输出样例和错误处理规则。这样写出来，既是给人看的文档，也是给机器读的配置。你甚至可以写一个简单的校验脚本，在提交Skill之前先检查格式是否合法，这比自己肉眼检查靠谱得多。

我见过很多团队把Skill当成提示词来写，洋洋洒洒上千字，结果第一步就崩了。原因就是没有结构，模型和调度器都识别不了。反过来，如果你把Skill当成一个API接口来设计，每个字段都有明确含义，整个系统就能像微服务一样工作：一个Skill的输出可以成为另一个Skill的输入，大家按契约协作。

2.3 四个设计原则：别让Skill变成“巨无霸”

光有框架还不够，实际写Skill时有四条原则我几乎是死守着的，它们帮我避开了不少坑。

第一是单一职责。一个Skill只做一件事。很多人喜欢把“代码分析、生成单测、更新文档”全塞进同一个Skill，表面上看很省事，实际上模型在长流程里很容易跑偏，而且出问题后很难定位。我宁可拆成三个Skill，让用户自己决定调用链，也不追求一个Skill包打天下。单一职责的Skill调试起来非常舒服，因为每个环节你都知道预期结果是什么。

第二是显式上下文。Skill内部要明确声明它需要哪些外部信息，不能依赖对话里“隐式”的历史消息。举个反例：如果我在审查Skill里写“请根据之前的讨论进行审查”，那只要上下文一换，Skill就废了。正确做法是在输入参数里显式声明需要“代码变更范围”或“相关Issue链接”。Skill的鲁棒性，全靠显式。

第三是可回退。每个步骤都要考虑“如果这一步失败怎么办”。比如读取文件失败，是跳过还是报错？模型返回的JSON格式不对，是重试一次还是用容错解析？Skill里最好给出一两个兜底分支，让模型知道在异常情况下该怎么做。没有回退方案的Skill，就像没有保险丝的电路，小问题能烧掉整个任务。

第四是可组合。Skill的输出尽量标准化，这样才能被其他Skill复用。比如审查Skill输出JSON，测试生成Skill就能读取这个JSON里的“文件路径”字段来决定给哪个文件生成单测。可组合性要求你设计时想清楚“下游是谁”，而不是闭门造车。

3. 手把手设计一个“代码审查Skill”

3.1 从Prompt到Skill的完整升级路径

这一节我们直接动手，把之前只存在于脑子里的思路落到一个具体的“代码审查Skill”上。我的做法是先写Prompt，再抽象成Skill，因为Prompt是最快的原型工具，能帮我们验证“这个任务应该怎么拆”是否靠谱。

第一步，先在对话框里用Prompt写一版完整审查流程：明确要读哪个文件，重点看哪几类问题，输出格式是什么。跑几个样本后，你会发现有些描述是反复出现的，那些就是候选的“固定步骤”；有些描述会因为输入不同而变，那就是“参数”。比如“重点看安全和性能”会变，“先确认代码能编译”不会变，后者就可以固化成前置条件。

第二步，把Prompt里的固定部分提取出来，写成一版带占位符的Skill描述。比如将“请审查 {{file_path}} 的代码，重点关注 {{focus_areas}}”作为主模板，再补上步骤、输出格式和校验规则。这一步很关键，因为你开始用变量的角度去重新审视需求了。一旦你发现某个信息在所有场景里都相同，就该考虑在Skill内部写死，而不是让用户每次都填。

第三步，将Skill放到实际的AI编程工具里运行，收集失败样本，调整步骤。这一步往往耗时最长，因为模型不是你肚子里的蛔虫，你得一遍遍告诉它“这里太模糊”“那里没给行号”。好在我发现，只要你把校验规则写得够硬，模型就会努力去满足硬约束，而不是自由发挥。最终你会形成一版真正稳定可用的Skill，这时再把它提交到团队共享目录。

3.2 一个可以直接抄的Skill结构示例

下面是我现在用的代码审查Skill的简化版结构，你可以直接参考。我用YAML格式写，因为可读性比JSON好，而且能被大多数AI编程工具解析。

name: review_code description: 当用户要求审查指定路径或PR变更的代码质量，并希望获得结构化风险报告时使用。 version: 1.4.0 author: your_name compatible_models: - claude - codex - deepseek parameters: file_path: type: string required: true description: 要审查的代码文件路径或目录路径。 focus_areas: type: string required: false default: 安全,逻辑错误,性能,可读性 description: 审查重点，用逗号分隔。 output_lang: type: string required: false default: 中文 steps: - step: 读取文件结构 action: 使用工具读取 file_path 对应的文件内容，如果路径是目录则列出所有代码文件。 check: 必须确认文件存在，否则返回错误提示。 - step: 提取变更块 action: 如果提供变更范围，则只提取变更涉及的行段；否则提取文件中的核心函数和主要逻辑。 check: 提取范围不得超出文件实际行数。 - step: 逐块审查 action: 按 focus_areas 对每个代码块进行扫描，记录问题描述、行号、严重级别、改进建议。 check: 每个问题必须包含定位，禁止“代码有问题”这类无定位表述。 - step: 生成报告 action: 输出JSON格式报告，包含文件路径、风险计数、问题列表、总体评价。 check: JSON必须能被标准解析器解析。 validation: - 如果问题列表为空，需要说明“未发现明显问题”而不是直接结束。 - 如果文件无法访问，输出错误信息，不要编造内容。 - 如果模型发现自己在某个步骤中信息不足，必须停止并询问用户补充参数。 output_example: | { "file_path": "src/main.py", "summary": "发现2个高风险问题", "issues": [ { "severity": "high", "line": 45, "message": "用户输入未做白名单校验，存在注入风险", "suggestion": "使用参数化查询或严格校验输入格式" } ] }

这个结构看着不复杂，但每一个字段我都踩过坑。比如compatible_models在决定用哪个模型跑Skill时特别有用，有些模型对工具调用的理解不行，就得在描述里额外补一句“如果无法读取文件，就根据用户粘贴的代码文本审查”。再比如validation里的“信息不足必须停止询问”，这能防止模型在缺少文件内容时瞎编。这些都是纯Prompt时代不会去想的事。

3.3 计算Skill参数：上下文窗口与代码裁剪

很多人在设计Skill时候忽略了一个硬约束：上下文窗口是有限的。你以为给了模型一个完整文件路径，它就能优雅地读完整个项目，其实不行。很多AI编程工具的上下文窗口也就几十万token，如果Skill一次性把所有文件全塞进去，还没开始审查就爆了。

我自己会做一个简单估算。假设团队里一个普通的Python文件是3000行，平均每行80个字符，大约就是24万个字符。中文字符在tokenizer里大概每个字符消耗0.6到1个token，英文则可能每4个字符一个token。按最保守算，3000行代码加上注释，可能直接吃掉8万到12万token，这还不算Prompt本身和其他上下文。结论就是：代码审查Skill不能“全文读取”，必须裁剪。

怎么裁剪？我的方案是在Skill里加一个预处理步骤：先通过工具获取文件的函数级结构，比如函数名、行号区间、参数列表，然后只把目标函数或变更行段塞给模型。如果文件实在太大，让模型输出“文件结构摘要+重点函数全文”，再结合静态扫描结果出报告。很多情况下，尤其是审查PR变更时，你根本不需要全文，只需要看diff。

所以你会在上面的Skill结构里看到，我在“提取变更块”步骤里加了如果提供变更范围，则只提取变更涉及的行段。这不是可有可无的优化，而是保证Skill在真实项目里不“超额消费”上下文的关键。设计任何一个Skill之前，先花两分钟估算一下它的典型输入会有多大，再决定要不要加裁剪步骤。很多人第一次写Skill效果很好，第二次换个大型仓库就完全失灵，多半就是栽在这一步。

3.4 用真实代码反复测试，攒一份回归集

Skill写出来只是开始，真正让它变稳的是测试和迭代。我的习惯是为每个Skill准备一个小型的回归测试集，里面有5到10个典型输入，覆盖正常情况、边界情况和异常情况。比如代码审查Skill，我会准备一个安全漏洞明显的文件、一个性能问题集中的文件、一个文件不存在的路径、一个超过上下文窗口的大文件、一个只含几行代码的最小文件。

每次调整Skill结构或步骤描述之后，我都会把这组回归测试全部跑一遍，对比输出报告的质量。你会发现，有时候你为了修一个“报错不清晰”的问题，会把另一个场景搞得“该说的不说了”。回归测试集就是让你及时发现这种副作用。我建议把测试集放在Skill同目录下的examples文件夹里，并且每个测试都写一个README，说明这个用例覆盖的是什么场景、期望看到什么结果。

这个过程中你会发现，模型对Skill描述的遵从度不是一次到位的。第一次跑，它可能完全忘了输出JSON；第二次跑，它输出了JSON但缺少行号；第三次跑，它终于符合校验了，但报告内容空洞。每修一次，你就离“可复用”近一步。等到你在多个模型上跑完还依然稳定，这个Skill才算真正成熟。

4. 存储、分发与团队复用

4.1 目录与命名规范：让Skill能被人找到

Skill有了，接下来是怎么管理。如果只放在自己电脑的某个文件夹里，那不叫可复用，叫自我安慰。团队协作场景下，我强烈建议把Skill当作代码一样管理起来，要有目录规范、命名规范、版本规范和维护文档。

目录结构方面，我习惯这样组织：

skills/ review_code/ SKILL.md examples/ case1_python_injection/ case2_large_repo/ tests/ run_tests.py

SKILL.md是Skill的主体描述，examples放回归测试输入和期望输出，tests放自动化校验脚本。这样无论是人还是AI编程工具，只要扫描skills目录就能发现可用的Skill，不用到处翻文档。

命名上我强调两个原则：一是动词开头，比如review_code、generate_test、migrate_schema，一看就知道是干嘛的；二是避免太宽泛的词，比如code_analyze就太模糊，我建议用review_code，因为“分析”太笼统，而“审查”隐含了质量评估的意图。名称最好和元信息里的name对齐，避免文件名和Skill名不一致导致调度混乱。

还有一个容易忽视的细节：Skill描述里不要用“最好”“尽量”这类模糊词。你是在写配置，不是在写作文。把“尽量输出JSON”改成“必须输出JSON，并且用标准解析器可解析”，模型执行起来才会不打折扣。团队里如果有人写Skill时描述模糊，AI工具调度成功率会肉眼可见地下降。

4.2 版本更新与变更记录

Skill作为可复用资产，版本管理比普通文档更讲究。我的做法是给每个Skill维护一个版本号，同时保存一份CHANGELOG，记录每次版本迭代的动机和结果。版本号用语义化版本：大版本升级代表整体流程变了，中版本代表新增步骤或输出结构变化，小版本代表措辞修正和参数调整。

为什么要这么严格？因为很多AI编程工具在加载Skill时是有缓存的。你改了Skill文件，但没有更新版本号，工具可能还在用旧的。就算工具没有缓存，团队里其他人也会困惑：这份Skill到底是不是最新的？我见过最典型的事故是，一个人把Skill改了后忘了更新版本号，另一个人在不知情的情况下用旧版本跑了一整天，最后产出的报告格式全对不上。用Git管理Skill文件，每次变更都走Pull Request，Review的时候重点看版本号和描述有没有同步更新。

还有一个好习惯：每个Skill在CHANGELOG里写明“兼容模型”的变化。比如上次在Claude上表现很好，但换成某个新模型后输出结构变了，你在CHANGELOG里记下来，下次切换模型时就能提前知道风险。我自己还会在CHANGELOG里记录每个版本的“已知问题”，这样别人接手时不用重新踩坑。

4.3 跨项目迁移与团队共享

Skill要真正发挥价值，就得能在多个项目之间迁移复用。我团队现在的做法是搭了一个内部的skills仓库，里面按领域分了几个目录：代码质量、文档生成、数据分析、运维诊断。每个项目只需要在自己的配置里声明要使用哪些Skill，CI流程会自动把对应Skill加载到AI编程工具里。

跨项目迁移时要注意两个问题：一是项目语言和框架的差异，比如Python项目的代码审查Skill未必适合Java项目。我的解法是在Skill参数里增加language和framework两个可选参数，默认按通用规则审查，用户传入具体语言时则增加对应规则。二是外部工具依赖差异，比如Skill里用到了Python的静态分析工具，那在Node.js项目里可能就得换一种实现。这些都是设计Skill时要考虑到的可移植性。

如果你不想搞一整套基础设施，也有轻量方案：把Skill文件直接放进项目仓库的.skills/目录里，让AI编程工具自动发现。这样每个项目都自带一份“团队默认技能包”，新成员clone完代码，工具初始化时就能加载这些Skill，不需要额外安装。这个方式我实测很稳，尤其适合没有专职运维团队的几个人小组。

4.4 在主流AI编程工具里的集成经验

不同工具对Skill的支持程度不一样，我踩了一圈的结论是：不要为了用Skill而用Skill，先看你的工具支持哪种格式。Claude系的Skill通常强调自然语言的工作流描述，你可以在里面定义清晰步骤和校验规则，它更倾向于“读”你的Skill文档。而Codex这类工具会更依赖文件读取和命令行执行，它的Skill更像一个可以运行的脚本组合，你需要明确告诉模型可以调用哪些工具。

Spring AI从某个版本开始也引入了Skill（或者叫Tool）的概念，它会加载一个带注解或者Schema的类，然后把方法注册给模型。这让我更加确定一个趋势：将来Skill就是AI应用里的“插件”。你在Java或Python里定义好函数，模型在对话中自主决定调用哪个。这种模式对格式和元信息的规范性要求更高，你必须把参数类型、业务含义、返回结构都写清楚，否则模型根本不会调用。

还有一个特别实用的经验：你的Skill最好在文档里同时提供“人类可读版”和“机器可读版”。人类可读版给团队成员看，解释这个Skill的适用场景和局限；机器可读版就是上面的YAML/JSON，给工具调度用。两者含义必须保持一致。我见过很多人只写了一个机器可读版，结果团队里其他人根本看不懂，也不会用，Skill的复用率自然上不去。

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

5.1 Skill不生效，没被调度怎么办

这是新手最常见的问题：明明把Skill文件放对了位置，描述也写了，但对话时怎么都不触发。我开始也被这个坑过，后来排查出了一个套路。先看Skill的元信息，尤其是name和description，很多工具是根据用户问题里的关键词来匹配Skill的。如果你的描述写得太学术，比如“针对代码质量问题进行多维度的结构化分析”，用户说一句“帮我看看这个文件”，工具根本识别不到。

解决方法是把描述写得“口语化”一点，因为用户的输入通常是自然语言，不是工程术语。我会在描述里故意加入几个容易触发的同义词，比如“审查、检查、看看、有没有问题”，这样匹配成功率立刻高了不少。第二个排查点是确认工具是否默认加载了你的Skill。有些AI编程工具需要你在设置里手动启用技能商店或某目录，没有启用的话文件放得再对也没用。

第三个排查点是看有没有其他Skill的description跟你的冲突。如果两个Skill都说“负责代码质量问题”，调度器就会随机选一个，你会觉得自己的Skill“时灵时不灵”。这时候要么调整描述，让职责更专一，要么在自己的Skill描述里补充“当用户提到PR变更、代码行号、风险报告时优先使用我”。这一步其实就是把路由优化做到位了。

5.2 输出结果不稳定，格式来回变

Skill执行时输出不稳定，是另一种高频事故。明明校验规则里写了“输出JSON”，结果模型有时候正常，有时候却给你Markdown表格。我后来发现，问题往往出在“你给的例子不够明显”。模型很擅长模仿，所以输出样例必须放在离步骤描述最近的位置，而且尽量给正面和反面两个例子。只给一个正面样例，模型可能不知道别的写法是错的。

另外，我会在validation里增加一个明确的“格式失败后的行为”：如果输出不是标准JSON，模型应当自我纠正一次。很多模型其实具备自我纠错能力，你只要显式告诉它可以回头修改，它就会真的再试一次。没有这个指令，它往往就直接提交一个半成品给你。

还有一个容易被忽略的点：模型对“引号”和“八股文”特别敏感。如果你的Skill描述里写着“请用专业的语气”，模型可能会生成一堆“总体来看”“综上所述”的废话，把真正的结论淹没。所以我现在的Skill描述里都会有这么一条：“输出时不允许出现总结性空话，每个问题必须落到具体位置和修复建议。”这一条能明显提升报告的信息密度，团队里所有人看着都舒服。

5.3 上下文爆炸，还没跑就报错

大型代码仓库是最容易让Skill“翻车”的地方。前面已经算过，一个3000行文件就可能吃掉十万token，如果Skill还同时读取了多个文件，上下文直接爆掉。这个问题最好的解法是从设计上优化，而不是等报错后再删。

我已经在代码审查Skill里内置了“变更块提取”和“函数级摘要”两步。更极端的场景，比如审查整个PR的几百个文件，我的办法是让Skill先根据文件修改统计生成一个“疑似重点文件清单”，接着只对清单里的文件做深入审查，最后把其他文件的结果合并成一句话“检查了其它N个文件，未发现高风险问题”。这样既保证重点不遗漏，又不会耗尽上下文。

如果你使用的工具支持外部工具调用，也可以让Skill自己调用“文件摘要工具”，把长文件压成一两百字摘要后再进入审查流程。实测下来，这种方式能把上下文占用减少六成以上，而且在审查大仓库时准确率并没有明显下降。关键是，你要在Skill里明确写清楚“对于超过500行的文件，必须先调用摘要工具”，否则模型还是会选择简单粗暴地全量读取。

5.4 去AI味：让Skill生成的文本更自然

最后聊一个很多人关心但Skill里比较少提的话题：怎么让AI生成的内容不那么“AI”。我刚开始给团队做技术方案文档的Skill时，产出老是有“首先、其次、最后”这种骨架感，看多了就腻。后来我在Skill的规范里加了一条，“在输出段落之间建立自然的逻辑连接，尽量避免使用官方报告式的过渡词”。结果虽然不能完全消灭八股味，但至少比之前自然多了。

具体操作上，我会在Skill的output_example里直接给一段“有呼吸感”的范文。模型对样例的模仿能力很强，你给一个风格具体的样例，它就能输出类似的风格。另外，我会在validation里增加“软校验”条目，比如“检查是否存在‘总而言之’‘综上所述’“不断提升”这类高概率模板短语，如果出现，先用同义词改写一遍”。注意这属于软校验，不是硬性失败，因为有些场景确实需要总结句。

去AI味这件事，本质还是你在Skill设计里投入了多少心思。一个只有干巴巴指令的Skill，产出自然干巴巴；一个连样例、禁区、风格提示都设计好的Skill，产出才能像人写的。我个人的经验是：把你想让AI输出的语气直接写进样例，比写一百句“请自然一点”都管用。

我自己在把一堆Prompt沉淀成Skill的过程中，最大的感触是：设计Skill本质上是在做工程化，而不是在写提示词。你不再追问“这句话怎么说AI才能懂”，而是要问“这个任务到底需要什么输入、经过哪些步骤、输出成什么样才算合格”。这些想清楚了，Skill自然就有了灵魂。如果你正卡在“提示词总是不稳定”的困境里，不妨挑一个最重复的任务，按上面的框架做出你的第一个Skill。跑通一次之后，你会发现自己再也回不到靠Prompt裸奔的日子了。