先教会 AI，再让 AI 上班：我的 Skill 与自动化实践
约 2266 字大约 8 分钟
AIVibe Coding
2026-06-27
上一篇留了个口子：怎么让 AI 写出来的代码更像自己的？这篇就把它补上。
思路说穿了很简单：AI 再聪明，对你来说也只是个聪明的小白。它不知道你的注释写在哪儿、不知道项目里有加密中心这种东西，你不要去抱有期望一个刚入职的小白自己猜中这些规矩，这个时候你就要给他一份开发手册，让他学会了再动手。当前我要讲的就是干的这件事，去把经验、风格、规范整理成手册教给 AI，等于培养一个自己。
具体拆开是四块： 开发习惯、项目规矩、安全网、自动化，一步步来。
AI 是个聪明的小白
先回答一个问题：为什么是 Skill，而不是每次对话的时候口头交代一遍？
口头交代不是不行，是累。每次开工都要重复一遍「注释怎么写、SQL 怎么写、工具类用哪家」，说漏一条，AI 当场就给你表演什么叫自由发挥。
Skill 的本质
把这些每次都要交代的话，持久化成一份文件，每次对话自动注入上下文——一次写好，回回生效。你带新人的那份手册，就是 skill 该有的样子。
第一篇说过一句话：它见过全世界的代码，唯独没见过你的。Skill 补的正是这一块。
第一个 Skill：把我的开发习惯写成手册
先说注释。什么时候注、注什么、什么格式，都有讲究，我的一贯风格：Controller 上注释接口标题，用 <p></p> 标签声明接口的执行流程，如果有总结内容或者类的引用，再放到 p 标签下面。别小看这几个标签——javadoc 的悬浮提示里，p 标签管着换行排版，读代码的人在 IDEA 里鼠标一悬，整个流程清清楚楚：
/**
* 订单超时取消
*
* <p>执行流程：定时任务触发 -> 扫描超时订单 -> 校验订单状态 ->
* 调用取消服务 -> 记录操作流水 -> 通知下游系统</p>
*
* <p>相关实现：{@link OrderTimeoutCancelService}</p>
*/再比如项目依赖了 MyBatis-Plus，日常查询我一律用 Lambda 风格，skill 里直接放个示例让它照着来：
LambdaQueryWrapper<Order> wrapper = Wrappers.<Order>lambdaQuery()
.eq(Order::getStatus, OrderStatus.PAID)
.between(Order::getCreateTime, startTime, endTime)
.orderByDesc(Order::getId);
List<Order> orders = orderMapper.selectList(wrapper);字段名跟着实体走，重构改一处全生效，比手拼字符串的查询稳得多。
类似的还有分支的开发规范、写 SQL 的规范、索引创建的规范，一条条攒进去，最后汇总成我的第一个 Skill。AI 拿到它，写出来的代码才有我的味儿。
第二个 Skill：项目级的规矩
个人习惯解决「写得像不像」，项目级 Skill 解决「对不对」——每个项目都有自己的一亩三分地。
第一件事，给项目生成索引文件：项目的版本、使用的框架、功能模块的内容，整理成一份索引。接到需求先按索引定位功能在哪个模块、周边架构长什么样，AI 顺着索引直接找过去，省得每次都来一遍全项目扫描——又慢又费 token，扫多了上下文窗口还被无关代码挤占。
第二件事，依赖治理：把项目的依赖包分析一遍，哪些是工具包、各自负责什么，排好优先级——hutool 的、spring 的、guava 的、项目内已有的工具目录，按序取用。没有这条，AI 的天性就是自己造轮子，一个 StringUtils 能给你手写八百遍。
第三件事最要命：项目铁律。我们项目里所有手机号、卡号、身份证号、密钥，都必须走加密中心处理，这条不写进 skill，AI 就会自己撸一套 SHA256、RSA 加密签名，代码看着还挺专业——
「专业」恰恰是坑
AI 自己写的加密实现，算法层面大概率没毛病，但它绕过了加密中心，密钥管理、合规审计全部脱轨。这种代码 review 的时候一眼看过去还挺唬人，真上了生产，等审计来找你的时候，哭都来不及。所以类似的项目铁律，不仅要写进 skill，还要写清楚怎么调、怎么开发。
安全网：敢放手的前提
手册教好了，安全网没配齐之前，谈不上放手。
我的做法：AI 开工前先拉分支，开发过程小步提交，写砸了秒回滚，git revert 一下的事。但有条死规矩：不能推送到远端。远端是团队的地盘，AI 的半成品一律留在本地分支上，污染了别人的拉取，那就不是效率问题，是事故。
数据库这边，我会把测试库的账号给 AI，让它自己连接、自己查数据验证逻辑——数据对不对，查一眼比猜半天管用。但权限收敛到最小：可以查询、可以新增，不能更新、不能删除。
权限红线
测试库账号按最小权限原则给：查询、新增可以，更新、删除不行。后面自动化要用的部署权限、Jira 权限同理，能给只读就不给读写，能限定单项目就不给全局。最后一条，加粗喊三遍：不能连生产！不能连生产！不能连生产！自动化链路上的任何凭证，都不要留生产环境的入口。
还有个容易忽略的点：skill 本身别写敏感信息。skill 会随着上下文流向模型服务端，密钥、内网地址这类东西放进去，等于把家里的钥匙复印一份寄出去。测试库密码走环境变量，skill 里只写「从哪取、怎么用」。
让 AI 值夜班：Bug 自动修复工作流
安全网配齐，才轮到这篇最爽的部分：自动化。
场景很日常，测试同学在 Jira 上提了个 bug，我的工作流是这样的：
- 脚本定时检测我名下的 Jira 任务，发现新 bug 就拉详情
- AI 分析根因，在隔离分支上完成修复并提交
- 飞书通知我：有修复待评审
- 我评审代码，通过后 AI 自动部署到测试环境
- 部署完成，Jira 单状态自动流转
整条链路里脏活累活都是 AI 的，但有个环节它碰不了：第 4 步那个「通过」。
灵魂是人工闸门
这套工作流的价值不在全自动，而在关键动作前面有一道人工闸门。AI 可以修代码、可以跑部署脚本、可以流转单据，但评审通过这个按钮必须人来按——它修的 bug 可能治标不治本，可能顺手改坏别的地方，这些只有人看得出来。自动化提的是效率，闸门保的是底线，两个都要。
Skill 不是一次写成的
手册怎么越写越厚？我的经验：每次 AI 犯错、每次 review 打回，都是 skill 的迭代素材。它在加密中心摔过一跤，回头就补一条规范；它把两张不该联表的大表联了，回头就补一条 SQL 约束。坑变成规则，同一个地方不让它摔第二次，这就是 skill 的迭代观。
还有个小习惯：复杂需求开工前，让 AI 把项目铁律复述一遍再动手。它复述的过程，既是确认它真记住了，也是你自己查漏的过程——哪条它说不出来，往往就是 skill 里写得不够显眼的那条。
手册越厚，你越值钱
三篇连起来看：第一篇骂自己差点写废，第二篇把流程的拍板权拿回来，这一篇把自己复制给 AI。
Skill 越攒越厚，AI 出手就越像你，你就能腾出手去干更要紧的事——定规范、做设计、盯风险。角色悄悄变了：从一个写代码的人，变成了带 AI 的人。
但有句话得放在最后：教得再像，签字的永远是你的名字。AI 可以替你写代码、替你值夜班，唯独替不了你担责任——责任链的末端，永远是人的名字。
核心就一句话
先教会 AI，再让 AI 上班。手册越厚，你越像带队的人；闸门按得越稳，你越敢放手。培养出一个「自己」，是为了把自己解放到更值钱的地方去。
这套个人的实践跑顺之后，我最近在琢磨怎么往团队层面推——规范这个东西，一个人写是习惯，一群人用才是资产。等有了体感再整理出来。先到这。