从Prompt到Skills：AI辅助编程的工程化进阶之路

“连Skills都没玩过，还敢说自己熟练掌握AI辅助编程？”

面试官这句反问砸过来的时候，我确实愣了两秒。我应聘的是AI辅助编程方向的岗位，前面聊到工作流，我把Prompt模板、上下文管理那套东西讲得头头是道。结果对面轻飘飘一句话，就把话题从“你会不会问问题”拉到了“你有没有真正玩透你的工具”。

这场对话暴露了一个很典型的能力断层：多数人把“用AI写代码”理解成“会写Prompt”，但市面上的AI编程助手早就不停在“文字问答”这件事上了。它们已经进化到“代理式执行”的形态——你给一个任务，它能连续调用多个文件、多个命令、多轮自检，而驱动这种执行的单元，就是类似Skills的技能包机制。这篇文章围绕这次面试展开，把Skills和Prompt的差别、为什么Skills成了面试分水岭、从零配置技能包到底要动手做什么，以及我踩过的坑和后续复盘出的回答思路，一次讲清楚。

1. 为什么“只会Prompt”挡不住这一问

1.1 面试官那一问的潜台词

面试官问Skills，表面上是“你这个工具用过没有”，实际考察的是三个递进的东西：一，你有没有用过工程化的AI编程配置，而不只是零散提问；二，你有没有把重复劳动抽象成可复用资产；三，你有没有理解当前AI编程工具的运行模式已经变了。

第一点最容易理解。会写Prompt就像“会用搜索引擎”——能搜到答案，但搜得快、搜得准、搜完还能整理成自己的知识库，这是两种能力。面试官想看的是后者。第二点则是“经验沉淀”问题：一个团队里经验丰富的人如果只靠口头传授，效率非常低；但如果把流程写进一个技能包，新人也能立刻按同样的标准执行。第三点最关键，现在主流AI编程助手的执行逻辑已经从“我问一句，你答一句”变成“我下一个任务，你通过工具连续完成多步操作”。在这种模式下，Prompt只是触发入口，真正承载能力的是技能包。

所以“呃……Prompt不行吗？”这个反问，其实恰好暴露了对当前工具形态的理解还停留在上一代。这就是面试官皱眉的原因。不是Prompt没用，而是只停留在Prompt维度，说明没有经历过从“自发使用”到“自觉构建”这一步。

1.2 Prompt和Skills到底差在哪

为了把这个区别讲透，我用下面这张表整理过两者的核心差异，面试复盘时觉得特别直观：

这张表里最扎心的是第一行。一直用Prompt，就像每次接待新客户都现场背一遍公司介绍；用Skills，相当于提前做好一套标准手册，客户来了直接递出去，内容规范、口径统一。而且Skill里可以夹带私货——比如放一个预处理脚本、一份输出模板——这是Prompt文字交互做不到的。Prompt是“说教”，Skills是“带装备”，一个靠嘴，一个靠工具链。

1.3 一句话说清Skills是什么

Skills本质上是一份“给AI的职业素养包”。它通常由一个SKILL.md文件组成，里面用结构化格式写明：这个技能什么时候触发、按什么步骤执行、输出成什么样。同时它可以附带脚本目录、模板目录、参考资料目录。当对话中出现了匹配的任务，AI编程工具会像“查字典”一样把这个技能的内容加载进上下文，然后照着里面的指令一步一步执行。

我后来用一个比喻让自己彻底理解：Prompt像给临时工的口头交代——“帮我把这个代码看看有没有问题”，怎么检查、检查哪些项、报告写多详细，全看临时工心情。Skills像给正式员工的岗位手册，写清楚“第一轮检查安全，第二轮检查性能，第三轮检查可维护性，最后输出一张包含风险等级和处理建议的报告表”。AI拿到手册后，输出的东西哪怕不是百分百完美，至少每次都在同一套标准轨道上。一句话总结：Prompt是“对话能力”，Skills是“执行体系”。

2. 从“会提问”到“会构建”：Skills背后的三层能力

2.1 第一层：把经验固化成可复用资产

我自己真正决定认真研究Skills，是因为一个重复劳动场景。那时我每周都要给项目里的代码做一次安全与规范审查，每次都要在对话里反复输入大段审查要求：检查硬编码密钥、检查SQL注入风险、检查异常吞掉问题、检查日志格式……每次输入都有微调，模型的理解也跟着微调，有时想起这条忘了那条，审查质量忽高忽低。

后来我把这套审查要求固化成了一个代码审查技能包。整个过程中我最大的感触是：当你把经验写进SKILL.md，你就被迫把脑子里那些“模糊的正确”变成“精确的规则”。比如以前说“注意密码处理”，写在技能里就变成“若配置文件中出现明文密码字段，标记为高风险并给出调用链”这样具体的判定标准。这个“被迫精确”的过程，本身就是一次能力提升。经验一旦被写成规则，就不只存在于某个人的大脑里，而成了项目资产。

这种资产的价值，在团队里体现得更加明显。带过新人的人都懂，最怕的不是对方不会写代码，而是他缺少“老手的判断力”。判断力很难直接传授，但技能包可以承载一部分判断标准。新人拿到技能包，至少能把“安全底线”和“风格基线”先兜住，再慢慢理解为什么这样判。这就是为什么现在的AI编程实践里，技能包正在成为团队知识沉淀的重要载体。

2.2 第二层：让AI按流程办事而不是按感觉办事

写Prompt的时候，最常遇到的问题是“同一句话，早上能用，下午就跑偏”。原因在于模型本身有随机性，同样的输入可能给出不同侧重点的输出。而技能包通过两步压制这种随机性：第一步，强制加载固定指令，比如“必须按以下1-7步骤顺序执行，不可跳过”；第二步，提供输出模板，比如“报告必须包含风险等级、影响范围、修复建议”三个字段。

这两步的效果非常明显。以前我让AI做代码审查，它输出的报告一会儿是表格、一会儿是列表、一会儿是长篇分析。固化成技能包之后，每次拿到手都是同一套结构化报告：风险等级在前，影响范围有文件级定位，修复建议可直接抄进PR描述。整个输出从“散文”变成了“公文”，可读性和可用性完全不是一个量级。

这背后其实是“减少模型自由发挥空间”的设计思路。模型自由发挥的空间越大，结果方差越大。技能包把“发挥空间”压缩到你允许的范围内——你允许它补充判断细节，但不允许它改变报告结构。做AI辅助编程的工程化，本质上就是在找“哪里该放权给模型，哪里该用规则锁定”。技能包就是这个锁的载体。

2.3 第三层：把技能包纳入团队协同

当技能包从一个文件夹变成一个团队仓库时，意义就完全不同了。我参与过一个模拟项目，团队里五个人用AI辅助编程，各写各的Prompt，模型给出的代码风格五花八门。后来我们做了一次统一：把代码审查、测试生成、提交信息生成这三类高频场景做成三个技能包，放到团队共用的代码库里统一版本管理。从那以后，AI生成的代码风格、PR描述格式、测试覆盖范围终于有了统一基线。

这一步的重点在于“技能包成为接口”。以前“要求AI按团队规范写代码”是一句口号，现在是一个可执行的文件。新同事入职，不需要听半小时规范宣讲，把技能包仓库拉下来就可以了。团队里有人发现更好的审查技巧，直接更新技能包文件，所有人同步受益。这种“个人经验通过技能包转化为团队能力”的路径，是我认为面试官真正希望听到的回答方向。

当然，团队协同也有坑，比如技能包版本冲突、描述被改坏导致该触发时不触发。这些我在后面踩坑实录里会详细说。但总体方向是明确的：AI辅助编程从“个人技艺”走向“组织能力”的转折点，几乎必然是通过技能包这类机制实现的。

3. 实战演练：从零构建一个可用的Skills

3.1 先看一个Skill的基本结构

动手配置之前，得先理解一个技能包的文件组织方式。大多数AI编程助手支持的技能包目录结构大同小异，核心是一个名为SKILL.md的入口文件，周围可以挂脚本、模板和参考资料。一个典型的目录长这样：

skills/ code-review/ SKILL.md scripts/ scan_credentials.py templates/ review_report.md references/ security_checklist.md

SKILL.md是灵魂。它通常分为两部分：YAML开头的元信息区和Markdown正文的指令区。元信息区里最关键的就是name和description，尤其description，它决定了模型能不能在合适的时机找到这个技能。正文区则写“触发之后该干什么、按什么顺序干、有什么输出要求”。理解这一点后，再看那些写得很好的技能包，会发现它们都遵循同一个原则：元信息区负责“被找到”，正文区负责“干得对”。

我第一次自己写技能包，把精力全花在正文区，结果发现根本触发不了。后来才意识到，description写得够不够精确，直接影响模型能不能在任务到来时“想到”这个技能。这就像给工具贴标签——标签写“扳手”，别人拧螺丝时才会找你；标签写“金属物体”，基本就没人能找到了。

3.2 手把手写一个“代码审查”技能包

我把自己实际用过的代码审查技能包简化出一个示例框架，可以直接参考。首先是SKILL.md的内容：

--- name: code-review description: 用于对代码变更进行系统性审查，当用户要求检查代码质量、安全性、性能问题时触发。也适用于处理PR、MR评审场景以及提交前的自检。 --- # Code Review Skill ## 触发时机 在用户要求审查代码变更、检查安全隐患、评估代码质量时使用本技能。同时适用于提交前自检、CI流水线失败后的修复建议。 ## 执行步骤 1. 获取变更代码或代码文件范围 2. 按以下顺序逐项检查，不可跳步： - 安全检查：硬编码密钥、注入风险、敏感信息泄露 - 逻辑检查：空指针、边界条件、并发安全 - 性能检查：循环嵌套、无效查询、资源未释放 - 可维护性检查：命名规范、函数长度、注释完整性 3. 汇总问题清单，输出结构化报告 ## 报告输出模板 - 风险等级（高/中/低） - 问题描述（50字以内） - 文件与位置（文件路径+行号） - 修复建议（可直接执行的方案）

这个例子麻雀虽小，五脏俱全。那段“执行步骤”里特意写了“不可跳步”，这四个字是我用出来的经验——如果不强调，模型有时候会跳掉安全检查直接查风格，那报告质量就大打折扣了。description里同时放了“代码质量、安全性、性能问题、PR、MR、提交前自检”这些词，目的就是提高语义匹配命中率，让各种相关的说法都能触发这个技能。

配置好之后，测试方法很简单：直接打开AI编程助手，让它“审查一下当前文件的代码质量”，看看它有没有自动加载这个技能；再换一种说法，“帮我在提交前做一遍变更检查”，看能不能触发。如果两种说法都能触发，说明description覆盖得不错。再用一个有已知问题的代码片段测试，核对它输出的报告是否包含全部四类检查项目，以及格式是否符合模板。

3.3 把旧Prompt改造成Skill时要注意什么

很多人问我：我已经有一堆写好的Prompt，直接塞进SKILL.md就行了吧？其实不行。我改造过几个旧Prompt之后发现，至少有四类问题需要处理。

第一，把“规则”和“变量”分开。好的Prompt里经常有“请结合当前项目的技术栈生成代码”这类话，技术栈就是变量。放在技能包里，应该写成“先获取项目技术栈信息，再决定代码实现方式”，而不是把某个具体技术栈写死。第二，把“步骤”显式化。对话式Prompt可以靠上下文自然区分先后，技能包不行，必须明确写“先A后B再C”，并且加上不可跳步声明。第三，把模糊的期望改成明确的模板。比如不说“输出一份好看的报告”，而是直接给模板字段。第四，控制单文件体量。技能包文件超过五六百行时，模型加载质量会下降，不如拆成多个技能，或把细节放进references目录按需加载。

这个过程有个额外收获：改造旧Prompt，迫使你把隐含的决策逻辑显式化。比如一个Prompt让AI“生成测试用例”，看起来很简洁，但技能包版本就必须回答很多问题：测试框架是什么？覆盖率要求？哪些边界条件优先？一个技能包写下来，等于做了一次“需求澄清”，这对个人思考能力本身就是训练。

4. 踩坑实录：Skills用不起来的主要问题

4.1 技能不触发

技能包配置完却不生效，是最常见也最挫败的问题。我碰到的原因大概这么几类：技能包没放在工具指定的目录下，路径不对；description写得过于笼统或过于狭窄；项目里多个技能包的description互相冲突，导致模型不知道该选哪个；工具缓存没有刷新，新技能没有被索引到。

排查路径也有顺序。第一步直接点名测试，用“按code-review技能执行”这种说法，如果能触发，说明技能本体没问题，问题出在description的语义覆盖范围上。第二步检查description里是否包含常见场景词和同义词，比如“代码审查”也应该覆盖“code review”“检查代码”“PR评审”。第三步检查目录路径和命名，有些工具要求技能目录名和技能名完全一致。把这些顺序走一遍，大部分“不触发”都能解决。后来我把一套引擎策略总结成一句话：描述是给模型看的SEO网页，要覆盖用户平时会用的说法。

4.2 描述模糊导致执行跑偏

这里要说一个反向坑：技能确实触发了，但它跑偏了。比如“代码审查”技能被用到“帮我解释这段代码”的场景——因为description里写了“适用于代码相关问答”，范围划得太宽。模型只看了description和技能内容，没法判断用户这次具体是想审查还是想解释，于是拿着审查的指令去做解释，输出自然四不像。

解决方法是把description写成“条件触发式”，明确说清楚“仅在……时使用”，同时给出“不适用”的场景。比如代码审查技能的description最后补一句“本技能不用于解释代码逻辑，用户仅要求解释代码时请忽略此技能”。这个反向排除法非常有效，能大幅减少误触发。另外，正文区也要写“如果用户请求仅包含非审查任务，说明本技能不适用”——给模型一个“可以主动忽略”的出口，比逼它在任何情况下都硬执行要好很多。

4.3 工具调用和权限边界

技能包挂载了脚本之后，容易掉进另一个坑：权限和路径问题。AI编程助手在跑技能里附带的Python脚本时，可能没有正确的虚拟环境，或者跨平台路径不兼容。我在一个技能包里放了log分析脚本，在Windows上能跑，换到macOS就因为路径分隔符问题报错。这提醒我：技能包里的脚本要做跨平台处理，路径拼接用标准库，文件读取指定编码，而且尽量声明依赖环境。

更需要注意的是权限边界。技能包如果涉及写文件、删除文件、调用外部API，必须在SKILL.md里明确写出确认步骤。比如“在删除任何缓存目录之前，必须先列出待删除文件清单并等待用户确认”。这不是多余的谨慎，而是必要的容错。模型执行多步任务时一旦出错，错误会被放大——它可能基于错误的路径删掉不该删的文件。给技能包加“安全确认阀”，本质上是在给自动化流程装刹车片。

4.4 版本化和团队同步的坑

技能包在团队里共享后，版本管理就变得重要了。一开始我们直接把SKILL.md放在共享文件夹里，有人改了别人同步不到，还有人把整个目录覆盖了，造成前一天的优化丢失。后来改成纳入代码仓库统一管理，目录地址固定，改完必须更新Changelog。变更记录里写清楚“这次改了什么、改的原因是什么”，比代码注释还重要——因为技能包的质量取决于团队对它的信任，而信任建立在“改坏了能回滚、改好了能追溯”的基础上。

还有一个容易被忽视的同步陷阱：技能包更新后，已经在运行的AI会话不会自动加载新内容，要新开会话才能生效。有次我正在审查一个大型PR，技能包被同事优化了，我却用了半天旧版本，产出格式跟前几次不一致。后来我们约定：技能包更新后发一条通知，提醒大家新开会话时再使用。这个细节虽然小，但团队协作时影响体验很大。

5. 面试复盘：AI辅助编程的“熟练”到底怎么说

这次面试之后，我认真做了复盘：如果再有人问“你熟练掌握AI辅助编程吗”，我不会再回答说“我会写Prompt”。我会按三个层次来组织回答。

第一层，会用。熟练使用AI编程助手进行日常编码，包括代码生成、补全、重构、解释、单测生成，熟悉对话上下文管理。第二层，会配。针对高频场景配置技能包，把个人工作流固化为可复用资产，能够根据项目实际调整技能包的触发逻辑和输出模板。第三层，会建。能够在团队维度设计技能包体系，统一AI产出标准，把个人经验转化为团队能力。

面试是道证明题，需要例子支撑。我会给一个我的真实实践：我配置过一个“技术方案设计”技能包，它会先收集需求背景，再按“现状分析、方案对比、风险评估、实施步骤”四个模块输出方案，并且强制要求对比至少三种候选方案。有了这个技能包，AI产出的设计方案质量稳定了很多，后来这个技能包分享给同事，团队的技术方案输出标准也统一了。这种带细节的回答，比空泛地说“我用得很熟练”有说服力得多。

回到那次面试的“呃”字。如果我当时能接住那句话，换个角度回答：“Skills我用得不多，但Prompt之外的工作流我试过很多，最近正在把代码审查流程沉淀成技能包，现在的效果是……”，整场对话的走向就会完全不一样。面试官真正想看到的，不是一个名词的背诵者，而是一个对AI辅助编程有工程化思维、愿意把工具吃透的人。技能包只是这套思维的载体之一。

最后分享一个小建议：无论你当前用的是哪款AI编程工具，都值得花一个晚上，把每周重复次数最多的一件事写成技能包。哪怕只有几十行指令、一个输出模板，它也会让你从“会提问的人”变成“会构建工具的人”。这一步跨过去，AI辅助编程的能力边界会明显不同。