企业官网建设流程全解析

1. 为什么 WorkBuddy 的 Skill 体系值得认真对待

WorkBuddy 这类工具刚上手的时候，绝大多数人只会把它当成一个"能聊天的命令行助手"——问一句答一句，用完就关。但真正把它用出效率差的人，关注点根本不在对话本身，而在Skill这个机制上。Skill 可以理解为给 WorkBuddy 预置的一套"行为剧本"：它规定了在什么场景下、按什么顺序、调用哪些工具、产出什么格式的结果。没有 Skill，你每次都要重新描述需求；有了 Skill，你只需要触发一个关键词，剩下的流程它自己走完。

我最初也是抱着试试看的心态，随手写了两个 Skill，结果一周之后发现自己已经离不开它了。原因很简单：重复性的脑力劳动被固化成了可复用的流程。比如每次新建一个 Spring Boot 项目，从目录结构、依赖版本、日志配置到第一个接口的写法，这些内容我脑子里都有，但每次手敲一遍仍然要花十几分钟。把它写成一个 Skill 之后，一句话就能生成骨架，我只需要在骨架上改业务逻辑。这就是效率翻倍的真正来源——不是让 AI 替你思考，而是让 AI 替你执行那些你已经想清楚的事情。

这篇文章要聊的是我认为最值得落地的 10 个 Skill。所谓"值得落地"，标准有三条：第一，使用频率高，几乎每天都会碰到；第二，收益明确，能实打实省下时间或减少出错；第三，实现门槛低，不需要你懂复杂的 MCP 协议细节也能写出来。至于那些花哨但一年用不上一次的 Skill，我不会浪费篇幅。

在展开之前，先统一几个概念，避免后面读起来卡壳。Skill 和 Agent 的区别经常被混淆：Agent 是一个能自主决策、多轮循环执行的主体，它自己决定下一步做什么；Skill 更像是一个被 Agent 调用的"技能包"，输入输出相对确定，流程是预设好的。你可以把 Agent 想成一个员工，Skill 想成这个员工掌握的某项具体手艺。MCP（Model Context Protocol）则是让 WorkBuddy 这类工具能够连接外部系统（数据库、设计稿、浏览器等）的协议层，很多高级 Skill 会依赖 MCP Server 来获取外部数据。理解了这三层关系，后面的内容就顺了。

2. 写 Skill 之前必须想清楚的三个问题

2.1 这个 Skill 是"流程固化"还是"知识注入"

动手写之前，先判断你要做的这件事属于哪一类。流程固化型的 Skill，核心价值在于把一串固定步骤串起来，比如"新建项目 → 初始化 Git → 配置日志 → 生成第一个接口"。这类 Skill 的重点是步骤顺序和参数默认值。知识注入型的 Skill，核心价值在于把某个领域的规则、模板、约束喂给模型，比如"我们团队的代码规范是……""这个项目的目录约定是……"。这类 Skill 的重点是内容的准确性和完整性。

分清楚这一点很关键，因为两者的写法完全不同。流程固化型要写清楚每一步的触发条件和预期输出；知识注入型则要把规则写成模型能直接套用的形式，最好是带正反例。我见过不少人把两类混在一起写，结果 Skill 又长又乱，触发之后模型抓不住重点。

2.2 触发词设计：别让 Skill "抢戏"

Skill 的触发词设计是个容易被忽视的坑。触发词太宽泛，比如你设成"帮我写代码"，那几乎每次对话都会命中，模型会强行套用你的模板，反而干扰正常交流。触发词太窄，比如设成"用我们团队 2024 年 Q3 修订版的规范生成 Spring Boot 控制器"，你自己都记不住。

我的经验是：触发词用 2 到 4 个字的动宾短语，且带有明确的场景指向。比如"起项目""写接口""查日志""过测试"。这些词在日常对话里不会自然出现，但你想用的时候一敲就能命中。另外可以给每个 Skill 配一个"别名"，比如"起项目"和"new project"都指向同一个 Skill，中英文混用的人会舒服很多。

2.3 输出格式：结构化比"好看"重要

很多人写 Skill 时喜欢让输出"排版漂亮"，加一堆分隔线和图标。但从实际使用角度看，结构化、可解析比好看重要得多。如果你的 Skill 输出会被后续步骤消费（比如生成的代码要直接写进文件），那输出格式必须是机器可读的，比如固定的 Markdown 代码块、固定的 JSON 结构。如果只是给人看，那简洁清晰即可，别堆砌装饰。

我自己的习惯是：凡是会产出代码或配置的 Skill，输出一律用带语言标注的代码块，且代码块前后不加多余文字，方便我直接复制或让 WorkBuddy 直接落盘。凡是产出分析结论的 Skill，输出用固定的小标题分段，方便我扫读。

3. 十个真正能落地的 Skill 逐个拆解

3.1 起项目：Spring Boot 骨架一键生成

这是我最常用的一个 Skill，没有之一。触发词就是"起项目"。它的作用是：根据我给的模块名和包名，生成一个可直接运行的 Spring Boot 项目骨架，包括pom.xml、启动类、application.yml、日志配置、以及一个健康检查接口。

为什么这个 Skill 值得做？因为 Spring Boot 项目的初始化虽然可以用官方脚手架，但脚手架生成的东西往往还需要手动调整——比如日志格式、统一返回体、全局异常处理这些团队约定，脚手架不会帮你配。把这些约定固化进 Skill，每次起项目就省掉了"配环境"的半小时。

写这个 Skill 的关键在于参数化。我会让它先问我三个问题：项目名、基础包名、是否需要数据库依赖。根据回答生成不同的pom.xml。下面是我用的核心模板片段：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent>

日志配置我固定用 Logback，输出格式统一成"时间 级别 线程 类名 消息"，方便后续接日志采集。健康检查接口固定路径/health，返回{"status":"UP"}。这些默认值都是踩过坑之后定下来的——比如日志格式不统一，排查线上问题时要在不同格式之间来回切换，非常痛苦。

注意：Skill 里写死的版本号要定期更新。我一般每季度检查一次 Spring Boot 的稳定版本，避免生成的项目一上来就带着已知问题。

3.2 写接口：从需求描述到 Controller 全套

"写接口"这个 Skill 解决的是最高频的日常任务：给一个业务需求，生成 Controller、Service、DTO、以及对应的单元测试骨架。触发之后我会描述需求，比如"用户积分查询，按用户 ID 查，返回当前积分和等级"，Skill 就会按我们团队的规范生成一整套代码。

这里有个细节值得展开：分层规范必须写进 Skill。我们团队的约定是 Controller 只做参数校验和转发，业务逻辑全在 Service，DTO 和实体分离，不允许 Controller 直接返回实体。这些规则如果只靠口头约定，新人很容易违反；写进 Skill 之后，生成的代码天然合规。

生成的 Controller 大致长这样：

@RestController @RequestMapping("/api/points") public class PointsController { private final PointsService pointsService; public PointsController(PointsService pointsService) { this.pointsService = pointsService; } @GetMapping("/{userId}") public Result<PointsVO> query(@PathVariable Long userId) { return Result.ok(pointsService.queryByUserId(userId)); } }

注意构造器注入而不是字段注入，这是团队规范里明确要求的，理由是便于测试。Result是统一返回体，PointsVO是视图对象。这些约定全部固化在 Skill 里，我不用每次重复交代。

3.3 过测试：TDD 循环的自动化辅助

TDD（测试驱动开发）这个概念大家都听过，但真正坚持下来的人不多，原因是"先写测试"这件事在手动操作时太反直觉、太费劲。WorkBuddy 的 Skill 可以把这个循环变得顺滑很多。

我的"过测试"Skill 是这样工作的：我先描述一个待实现的功能点，Skill 先生成测试用例（红），然后我确认测试逻辑没问题，Skill 再生成实现代码（绿），最后 Skill 自动跑一遍测试并报告结果（重构）。整个过程我只需要在关键节点做判断，机械性的代码生成和测试执行全部交给它。

这里要提醒一点：TDD 的 Skill 不能全自动。如果让模型自己写测试自己写实现，很容易出现"测试和实现互相迁就"的情况——测试写得刚好能通过实现，失去了测试的意义。所以我在 Skill 里强制加了一个"人工确认"节点，测试用例生成后必须等我点头才继续。这个设计看起来降低了自动化程度，但保证了 TDD 的实际效果。

3.4 查日志：把日志分析变成对话

线上出问题的时候，最耗时的往往不是修复，而是定位。日志文件动辄几百兆，用grep一条条筛效率很低。"查日志"这个 Skill 配合 MCP 连接日志系统之后，可以直接用自然语言查询，比如"查一下昨天下午三点到四点之间，订单服务里所有 ERROR 级别的日志，按出现次数排序"。

这个 Skill 的核心是查询意图到查询语句的转换。我在 Skill 里预置了常见的日志查询模式：按时间范围、按级别、按关键字、按异常类型、按调用链 ID。模型根据我的描述选择对应的模式并生成查询。实测下来，比手写查询语句快很多，尤其是复杂的多条件组合查询。

提示：日志查询 Skill 一定要设权限边界。我给它限定了只能查最近 7 天的日志，且不能导出原始日志内容，避免误操作或数据泄露风险。

3.5 过规范：代码审查的自动化预检

代码提交之前跑一遍规范检查，能省掉大量 review 时的来回。"过规范"这个 Skill 做的事情是：读取我指定的代码文件，按团队规范逐条检查，输出问题清单和修改建议。

检查项包括：命名规范（类名大驼峰、方法名小驼峰、常量全大写下划线）、注释规范（公共方法必须有 Javadoc）、异常处理规范（不允许吞异常、不允许 catch 后不处理）、日志规范（不允许用System.out、日志必须带上下文）。这些规则写进 Skill 之后，每次提交前跑一遍，能拦下八成以上的低级问题。

这个 Skill 的价值在团队协作场景下尤其明显。新人提交的代码经常在命名和注释上不合规，review 时反复提同样的问题很消耗精力。有了这个 Skill，新人自己就能先过一遍，review 时只需要关注业务逻辑。

3.6 读设计稿：从 Figma 到代码的桥接

前端或者全栈开发经常要对着设计稿写页面。"读设计稿"这个 Skill 通过 MCP 连接设计工具，读取指定画板的图层信息，然后生成对应的页面结构代码。

这里的关键是图层命名规范。如果设计稿里图层名字是"矩形 1""组 2"这种，模型根本不知道哪个是按钮哪个是输入框。我在 Skill 里加了一步：先让模型输出它对图层的理解（"这个图层我理解为搜索框，那个理解为提交按钮"），我确认或纠正之后再生成代码。这一步看起来多余，但能大幅提升生成代码的准确率。

生成的代码我一般只用作骨架，样式细节还是手动调。因为设计稿里的间距、圆角、阴影这些，模型读出来的数值经常有偏差，直接用会导致还原度不够。把它当成"帮你把结构搭好"的工具，而不是"一键还原设计稿"的魔法，心态会平和很多。

3.7 写文档：接口文档与 README 自动生成

写文档是大家都讨厌但又不得不做的事。"写文档"这个 Skill 读取项目里的 Controller 和 DTO，自动生成接口文档，包括路径、方法、请求参数、响应结构、示例。同时还能根据项目结构生成 README，包含项目简介、环境要求、启动步骤、目录说明。

这个 Skill 的收益非常直接：以前写一份接口文档要一两个小时，现在几分钟搞定，而且不会漏接口。我一般会在项目里程碑节点跑一次，保证文档和代码同步。

有个细节要注意：生成的文档必须人工过一遍。模型对参数含义的理解有时会偏差，比如把"用户 ID"理解成"订单 ID"。所以我在 Skill 里让它在每个参数后面标注"（请确认含义）"，提醒我逐条核对。这个设计有点笨，但确实避免过几次尴尬的错误。

3.8 建数据：从需求到建表语句与实体类

新功能开发经常要先建表。"建数据"这个 Skill 接收业务描述，输出建表 SQL、实体类、以及对应的 Mapper 接口。比如我说"建一个用户反馈表，包含反馈内容、联系方式、提交时间、处理状态"，它就会生成完整的表结构和配套代码。

建表语句里我会固定几个约定：主键统一用bigint自增、时间字段统一用datetime且默认CURRENT_TIMESTAMP、状态字段用tinyint并在注释里说明取值含义、所有字段加注释。这些约定写进 Skill 之后，生成的表结构天然符合规范，不用每次手动补。

CREATE TABLE user_feedback ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键', content TEXT NOT NULL COMMENT '反馈内容', contact VARCHAR(128) COMMENT '联系方式', status TINYINT NOT NULL DEFAULT 0 COMMENT '处理状态：0待处理 1处理中 2已处理', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '提交时间' ) COMMENT '用户反馈表';

3.9 排故障：异常堆栈的快速定位

线上抛异常的时候，堆栈信息往往很长，夹杂着框架内部的调用。"排故障"这个 Skill 接收异常堆栈，输出三样东西：异常的根本原因（剥掉框架包装）、最可能的触发场景、以及排查建议。

这个 Skill 的价值在于经验固化。我把常见的异常类型和对应的排查思路写进了 Skill，比如NullPointerException优先看入参和数据库查询结果、TimeoutException优先看下游服务响应时间和连接池配置、DeadlockLoserDataAccessException优先看事务边界和加锁顺序。模型拿到堆栈后先匹配异常类型，再套用对应的排查思路，输出比我凭记忆想更全面。

3.10 收尾活：提交信息与变更说明生成

最后这个 Skill 看起来不起眼，但每天都会用到。"收尾活"读取当前的代码变更（git diff），生成规范的提交信息和变更说明。提交信息按约定式提交格式（feat:、fix:、refactor:等），变更说明按"改了什么、为什么改、影响范围"三段式输出。

这个 Skill 省下的是"想提交信息"的那几分钟，但更重要的是它让提交历史变得可读。团队里如果每个人都用这个 Skill，提交历史会非常规整，回溯问题时能快速定位到相关提交。

4. 让 Skill 真正跑起来的几个实操细节

4.1 Skill 的存放与版本管理

Skill 写多了之后，管理就成了问题。我的做法是：所有 Skill 文件放在一个独立的 Git 仓库里，按类别分目录（project/、code/、ops/、docs/），每个 Skill 一个文件，文件名就是触发词。这样既能版本管理，又方便在多台机器之间同步。

每次修改 Skill 都提交一次，提交信息写清楚改了什么、为什么改。这个习惯让我在某个 Skill 改出问题之后能快速回滚。我踩过一次坑：把一个"写接口"Skill 的分层规范改错了，导致生成的代码全部把业务逻辑写进了 Controller，发现时已经生成了十几个文件。有版本管理的话，回滚一下就好。

4.2 Skill 之间的组合调用

单个 Skill 的能力有限，真正强大的是组合。比如"起项目"生成骨架之后，紧接着"建数据"建表、"写接口"生成业务代码、"过测试"补测试、"写文档"出文档，一条流水线下来，一个新模块的骨架就搭好了。

要实现组合，关键是统一接口约定。我让所有 Skill 的输出都遵循同一套命名和结构约定，比如包名统一、返回体统一、日志格式统一。这样上一个 Skill 的输出能直接被下一个 Skill 消费，不用做转换。这个约定是组合调用的前提，值得花时间设计。

4.3 什么时候该放弃一个 Skill

不是所有 Skill 都值得长期维护。我给自己定了个标准：如果一个 Skill 连续一个月没被触发，就删掉。因为要么是场景不常见，要么是触发词设计得不好导致我想不起来用。留着只会增加维护负担。

另外，如果一个 Skill 的维护成本超过了它省下的时间，也该放弃。比如某个 Skill 因为依赖的外部接口经常变，我每个月都要改一次，那还不如手动做。Skill 是工具，不是负担。

5. 我踩过的坑和总结出的经验

5.1 别追求"大而全"的 Skill

我一开始写过一个"全能开发助手"Skill，想把起项目、写代码、测试、文档全塞进去。结果触发之后模型不知道该走哪条分支，输出一堆无关内容。后来拆成十个独立的小 Skill，每个只做一件事，反而好用得多。Skill 的粒度应该小到"一句话能说清它做什么"，这是我从那次失败里学到的最重要的一课。

5.2 触发词要"反直觉"一点

前面提过触发词要带场景指向，这里补充一点：触发词最好是你日常不会自然说出的词。比如我用"起项目"而不是"新建项目"，因为后者在正常对话里太常见，容易误触发。用稍微别扭一点的词，反而能保证精准命中。这个技巧听起来奇怪，但实测有效。

5.3 给 Skill 留"逃生口"

再好的 Skill 也有不适用的时候。我在每个 Skill 里都加了一句"如果本次需求不适用本 Skill 的默认流程，请直接说明并给出替代方案"。这样当场景超出 Skill 预设范围时，模型不会硬套模板，而是会提醒我。这个设计避免了好几次"生成的代码完全不对但模型还在硬编"的尴尬。

5.4 定期回顾 Skill 的使用数据

WorkBuddy 一般会记录 Skill 的触发次数。我每个月看一次，把高频 Skill 优化一下（比如补充更多默认值、细化输出格式），把低频 Skill 清理掉。这个习惯让我的 Skill 库始终保持精简高效，不会越积越多变成垃圾场。

说到底，Skill 这个东西的价值不在于数量，而在于你是否真的把它嵌进了日常工作流。十个精心设计、天天在用的 Skill，远胜过一百个写完就忘的。上面这十个是我自己反复打磨、验证过确实能提效的，你可以直接拿去用，也可以根据自己的场景改。关键是先动手写第一个，用起来，再迭代。