好久不见,各位朋友。
最近这段时间,我一直在折腾 AI 编程。新项目、老项目,只要能用 AI 的地方,我几乎都试了一遍。
说实话,一开始我对它的期待并不高。过去几年各种 AI 工具我也用过不少,大多数都是演示看起来很厉害,但真正用在项目里,总感觉差点意思。
但这次不太一样。
有几个瞬间,我真的被震住了。
在真实项目里,原本要花几天甚至一周才能完成的活,AI 几十分钟就帮我搞定了。
我明显感觉到自己的开发节奏正在悄悄改变。
我试了很多 AI 编程工具,也对比过多个大语言模型,结论其实很直接:在编程这件事上,Claude Code 目前是最好用的。
不只是代码写得好,它对工程化的理解,也比大多数工具都深得多。像 MCP、Skill 这些概念,都是它率先提出的,后来很多工具才开始跟进。
但我刚开始用 Claude Code 的时候,完全没有发挥出它的能力。
当时我在做一个老项目的技术栈升级,整体代码需要重构。我直接让 Claude Code 上手干,没做分析,没写 Plan,也没有任何规则约束。
我以为它能自己搞清楚方向。
结果很糟糕。
改完之后代码风格前后不一致,代码也没有进行合理拆分,逻辑还有几处出了问题。Review 起来非常痛苦,后面还花了很长时间去返工和调试才跑通。
后来我慢慢意识到一件事:
AI 最大的问题,其实不是能力不够,而是你没有给它边界。
如果没有工程意识,AI 只会把混乱放大。
Claude Code 其实已经提供了一整套机制来解决这个问题------只是大多数人根本没有用到。
这篇文章,我就以 Claude Code 为例,结合这段时间 AI 编程的实践,把这套 AI 编程工程化体系讲清楚。
先想象一个场景
你是技术负责人,公司新招了一个能力极强的开发者。
代码写得飞快,什么语言都会,24 小时不休息。
但问题是------他对你的项一无所知。
不知道你们用什么代码规范,不知道哪些文件不能动。提交代码前要不要跑测试?他不知道。遇到复杂需求,是不是应该先出方案再动手?他也不知道。
你会怎么办?
直接让他开干? 还是先给他一套 "入职指南"?
AI 编程工具,其实就是这个"新员工"。
你需要给它:
- 规章制度 → 告诉它什么能做、什么不能做
- 操作手册 → 把常用流程封装成标准操作
- 专业培训 → 让它具备特定领域的能力
- 安全检查 → 每次操作前后自动进行校验
- 协作机制 → 面对复杂任务知道如何拆分
- 办公工具 → 能连接各种外部系统
这其实就是当下 AI 编程工程化体系的 7 个核心概念:Rule、Command、Skill、Hook、Subagent、MCP,以及它们的组合方式(Plugin)。
单看这些概念,可能还不太直观。
它们构成了一整套 从规则约束 → 能力扩展 → 外部连接 的工程体系。
体系全景:一图看懂
在逐个讲解之前,我们先从整体视角看一眼这套体系。

内层管的是"AI 应该怎么做"------先把规矩立好。
中层管的是"AI 能做什么"------让它更强、更稳、更专业。
外层管的是"AI 能接触什么"------把它和外部工具打通。
从内到外,一层一层来。别急着全部配好,先把内层搞定就能解决 80% 的问题。
7 个概念,逐个拆解
① Rule --- 给 AI 定规矩
新员工类比:公司规章制度,什么能做、什么不能做。
它是什么 :一个叫 CLAUDE.md 的文件。你在里面写规则,AI 每次启动时会自动读取并遵守。
举个例子:
markdown
# CLAUDE.md
- 使用 2 空格缩进
- 禁止删除任何文件
- 禁止读取 node_modules 目录
- 注释统一使用中文
- 默认使用 pnpm 作为包管理器
就这么简单。
它分三级:
- 用户全局(
~/.claude/CLAUDE.md)------ 所有项目通用的规则 - 项目级(项目根目录下的
CLAUDE.md或.claude/CLAUDE.md)------ 跟代码一起提交,团队共享 - 目录级(子目录
CLAUDE.md)------ 进入这个目录时自动加载
什么时候该用:现在。只要你在用 AI 编程工具,第一件事就是写 Rule。成本最低,效果最明显。
② Command --- 把常用操作变成快捷键
新员工类比:SOP 手册,标准操作流程。
它是什么 :用 Markdown 文件定义的自定义命令。写好之后,输入 /命令名 就能触发。
举个例子:
你每次让 AI 写 commit message 都要说一大堆要求。累不累?
写一个 .claude/commands/commit.md:
markdown
根据当前代码变更,生成符合约定式提交规范的 commit message。
要求:
- 类型:feat / fix / refactor / docs / chore / style / build
- 描述使用中文
- 不超过 50 个字
以后只要输 /commit,AI 就知道该怎么做了。
两个层级:
~/.claude/commands/------ 用户全局,个人常用.claude/commands/------ 项目级,跟团队共享
什么时候该用:当你发现自己在重复输入类似的 Prompt 时。
③ Skill --- 装一个就会一个
新员工类比:专业培训课程,学完就具备对应能力。
它是什么:能反复用的 Prompt 工作流,打包成一个"技能"。和 Command 有点像,但 Skill 更强------它能被社区分发和安装,还带有更丰富的触发机制。
区别说清楚:
- Command 是你自己写的本地文件
- Skill 是别人(或社区)做好的,你装上就能用。当然,你也可以自己制作,提供给别人用。
典型场景:
/review-pr------ 自动审查 Pull Request/unit-test-generator------ 自动生成单元测试/vue-best-practices------ Vue 最佳实践检查
怎么找:先去社区和相关资源库里搜索现成的 Skill,找到适合自己的,安装到 Claude Code。
什么时候该用:当你发现某个工作流不只你自己需要,别人也需要的时候。
④ Hook --- 操作前后的自动检查站
新员工类比:安全检查站。每次出入公司大门都要刷卡、过安检。
它是什么:在 AI 调用工具前后自动执行的 Shell 脚本。比如"写文件之前"、"执行命令之后",你都可以插一段自定义逻辑。
它有哪些时机:
PreToolUse------ 工具调用之前(可以拦截危险操作)PostToolUse------ 工具调用之后(可以自动跑格式化)Notification------ 通知事件Stop------ Agent 停下来的时候
举个例子:
每次 AI 写完代码后自动跑 ESLint:
json
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"command": "npx eslint --fix $FILE_PATH"
}
]
}
}
AI 改了代码 → 自动格式化 → 你拿到的永远是规范的代码。
什么时候该用:当你想让某些检查"永远不会忘"的时候。人会忘,Hook 不会。
⑤ Subagent --- 让 AI 学会分工协作
新员工类比:团队协作机制。遇到大项目,别一个人死扛,拆给团队一起干。
它是什么:主 AI 可以启动多个"子代理",并行处理不同任务。每个 Subagent 有独立的上下文,互不干扰。
为什么需要它:
AI 的上下文窗口有限。一个复杂任务塞太多东西,它会"忘事"。
Subagent 的解决思路是:拆。
- 让一个 Subagent 去搜索资料
- 让另一个 Subagent 去分析代码
- 让第三个 Subagent 去跑测试
- 主 Agent 汇总结果
常见的分工方式::
Explore------ 快速探索代码库、梳理相关上下文Plan------ 整理思路、设计方案、拆解任务general-purpose------ 通用型子代理,啥都能干
什么时候该用:当任务复杂到"一口气说不清楚"的时候。
⑥ MCP --- AI 世界的 USB 接口
新员工类比:办公工具。你总不能让新人空手上班吧?电脑、邮箱、Jira 权限,都得给配齐。
它是什么:MCP(Model Context Protocol),模型上下文协议。一个开放标准,让 AI 能连接外部工具和数据源。
说白了,AI 本身只能读代码、写代码。但通过 MCP,它能:
- 连接 Figma,直接从设计稿生成代码
- 连接 数据库,查数据、写 SQL
- 连接 浏览器,自动化测试
- 连接 Jira/Linear,读取需求、更新状态
怎么用:在配置文件里加一个 MCP Server 就行。
去哪找:目前社区已经有不少 MCP Server 市场:
- Smithery ------ 最大的 MCP 市场之一
- mcp.run ------ MCP 聚合平台
- Glama ------ 另一个 MCP 市场
主流 AI 工具基本都有现成的 MCP Server。装上就能用,不用自己写。
什么时候该用:当你希望 AI 能访问代码之外的信息或工具时。
⑦ Plugin --- 不是一个东西,是一种思路
这里要澄清一个误解。
Claude Code 没有传统意义上的"插件系统"。它不像 VS Code 那样有一个插件市场,点安装就完事。
它的扩展方式是组合式的:
- 想约束行为?→ 写 Rule
- 想封装流程?→ 写 Command 或装 Skill
- 想自动检查?→ 配 Hook
- 想连外部工具?→ 装 MCP Server
这四种机制灵活组合,就是 Claude Code 的"插件体系"。
说实话,我一开始觉得这种设计有点散,不够"一站式"。但用了一段时间后发现,灵活性比统一性重要。你可以只用 Rule + Command,就够解决大部分问题。也可以全套上,搭一个完整的 AI 开发工作流。
学习路径:从哪开始?
别想着一口吃完。分三步走:
第一步:写 Rule(10 分钟搞定)
在项目根目录创建 CLAUDE.md,写几条基本规范。这是投入产出比最高的一步。
第二步:封装 Command + 装几个 Skill(30 分钟)
把你重复输入的 Prompt 变成 Command。再去社区找几个现成的 Skill 装上。
第三步:配 MCP Server(按需)
你用 Figma?装 Figma MCP。用 MongoDB 数据库?装 MongoDB MCP。不用的就不装。
进阶:
等你把前三步用熟了,再考虑 Hook(自动化护栏)和 Subagent(任务分治)。这两个不是必需品,但用好了能再上一个台阶。
后续计划
这篇文章只是我对 AI 编程工程化体系的全景导读。
每个概念背后都有一堆细节------是什么、怎么用、哪些场景适合、有哪些坑需要避开,以及有哪些现成的市场资源可以直接用。
后续我会逐一展开,每篇聚焦一个概念:
- Rule:规则怎么写才真的有用,而不是摆设
- Command:哪些操作值得封装,哪些没必要
- Skill:社区有哪些好用的 Skill,怎么安装,自己怎么创建
- Hook:自动化护栏怎么配,用好了能省多少心
- Subagent:什么任务适合拆,拆完怎么汇总
- MCP:最值得装的 MCP Server 是哪些,市场在哪找
- Plugin:怎么把 Rule、Skill、Hook、MCP 组合起来,形成完整工作流
- 实战:把以上全部串起来,一套真正可用的 AI 编程工作流长什么样
感兴趣的朋友可以保持关注~
工程化不是限制创造力,是保护创造力。
先把体系搭好,再让 AI 起飞。
当 AI 能写代码、能改架构、甚至能自己完成任务的时候,程序员真正的差距,已经不再是"会不会用 AI"。
而是------有没有能力把 AI 用进工程体系里。
这也是我越来越强烈的一个感受:
AI 编程工程化,正在成为 AI 时代程序员的一项基本功。