从“不好使“到“真香“：4步搞定项目级skill

最近在搞AI编程提效，方向集中在skill工作流的设计和编排上。刚开始尝试写一个skill，从需求分析到任务拆解，每个环节都设计得很精细。结果丢到项目代码里一跑，生成的代码风格和项目里已有的完全不一样——用的技术栈也对不上，结构划分的习惯也对不上。改了一轮又一轮，最后改的时间比手写还长。

后来我意识到，问题不在skill本身，而在我是从一个"通用能力"的视角在设计它。通用能力意味着要适配所有场景，但skill的威力恰恰来自于对特定场景的深度适配。想通这一点之后，我把整个创建流程推倒重来，总结出了一套4步方法论。

把skill当岗位JD来写，先画角色表

一套好用的skill就像一个分工明确的团队，每个skill承担一个清晰的角色。所以写skill之前，你应该做的事情和搭建团队一样——先搞清楚需要什么角色，每个角色负责什么、接收什么输入、产出什么。

不需要很复杂的文档，一张表格就够了。以"项目需求开发"为例：

注意"主导思维"这一列——它不是装饰，是告诉你每个角色为什么这样分工。需求分析师用产品思维去挖掘模糊点，技术架构师用工程思维去做选型和建模，两者不能混在一起。如果混了，后面生成的skill就会既做需求分析又做架构设计，上下文变得又长又乱，输出质量大打折扣。

每个角色的交付物恰好是下一个角色的输入，形成一条完整的工作链。画完之后检查一件事：每个角色能不能独立消化自己的输入，而不需要去问别人。如果做不到，说明角色划分有问题，回去重划边界。

一个好的skill不是通用工具，而是一个特定角色的精确描述。写skill最忌讳的就是"一个人干了四个人的活"。

角色表不是想出来的，是跑出来的

画完角色表，别急着让skill-creator帮你生成。先找个真实需求，自己扮演这些角色，把流程从头走到尾。

比如手头刚好有个"给现有项目加用户反馈功能"的需求，你按角色表来：

• 先扮演需求分析师，把模糊的"加个反馈功能"澄清成具体的需求文档；

• 再扮演技术架构师，基于需求文档做技术方案；

• 然后扮演任务规划师，把技术方案拆成开发任务；

• 最后扮演规范执行者，按任务列表写代码。

我第一次跑的时候，走了一半就发现"需求分析师"给出的需求文档里缺了信息——没有写清楚反馈功能的触发场景和边界条件。结果"技术架构师"拿到需求文档后没法独立做方案，还得回头去问需求。这就是角色边界没划好的信号。

这种问题在设计阶段你是看不出来的，只有真的走一遍才能暴露。把发现的问题修回角色表里，这一步看起来费时间，实际上省时间——你总不希望生成完skill之后才发现角色设计有漏洞，那时候回头改的成本大得多。

角色的职责边界，不是在设计时想清楚的，是在跑通流程时磨清楚的。经历这一步之后，你的角色表会从一个"看起来合理"的设计变成一个"跑得通"的设计。

让skill-creator帮你"招人"，不是帮你"干活"

角色表验证通过之后，才是让AI介入的时机。把角色表保存成markdown文档，然后在Claude Code里说一句：

基于多角色skill设计文档.md，通过/skill-creator创建一套完整的项目需求开发skill

skill-creator会根据你定义的角色、职责、输入输出，为每个角色生成对应的skill文件。你前两步做得越扎实，生成的skill就越贴合需求。

但说实话，到这一步为止，你拿到的还是一套"应届生"——有知识，没经验。它能按流程走，但它不了解你项目里的规矩：使用Spring Cloud而不是其他RPC框架、数据校验封装了工具类而不是重新造轮子、路由文件都放在src/routes/下面……这些它统统不知道。

skill-creator只能帮你把设计落地，不能帮你把设计做好。你在前两步投入的思考深度，直接决定了skill的质量上限。

项目适配：让"应届生"变成"熟手"的关键一步

这就是为什么我说第4步最关键。前面3步产出的skill是通用的，它可以在任何项目里跑，但跑出来的结果不会让你满意。只有经过项目适配，skill才会变成你真正想用的东西。

操作不复杂：把生成的skill复制到项目目录的.claude/skills/下面，再用一次skill-creator：

基于当前项目代码情况，使用/skill-creator将当前skills目录下的skill调整适配当前的代码

这次skill-creator会扫描你的项目代码——目录结构、技术栈、命名习惯、文件组织方式——然后把这些信息写进skill里。适配前后的差别非常直观：适配前的"技术架构师skill"可能会建议"选择一个合适的后端框架"；适配后的版本会直接说"使用Spring Cloud，参考现有中间件的结构组织新模块"。

通用skill产出的代码你还得花时间改；项目适配后的skill产出的代码直接能用。这就是为什么第4步不能省。

最大的收获不是skill本身

这4步走下来，你得到的不只是几个skill文件，而是一张可复用的角色表。换个项目，不需要重新梳理角色——角色定义是可以复用的。只需要在新项目里重复第3步和第4步：生成、适配。第一次花了半天做的事，第二次可能只要十分钟。

如果只想记住一件事：先当架构师设计角色，再当项目经理验证流程，最后才让AI帮你把设计变成skill。顺序反了，就会一直在"改了测、测了改"的循环里打转。