极米投影仪
149.20M · 2026-03-22
好久不见，各位朋友。
最近这段时间，我一直在折腾 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% 的问题。
新员工类比：公司规章制度，什么能做、什么不能做。
它是什么：一个叫 CLAUDE.md 的文件。你在里面写规则，AI 每次启动时会自动读取并遵守。
举个例子：
# CLAUDE.md
- 使用 2 空格缩进
- 禁止删除任何文件
- 禁止读取 node_modules 目录
- 注释统一使用中文
- 默认使用 pnpm 作为包管理器
就这么简单。
它分三级：
~/.claude/CLAUDE.md）—— 所有项目通用的规则CLAUDE.md 或 .claude/CLAUDE.md）—— 跟代码一起提交，团队共享CLAUDE.md）—— 进入这个目录时自动加载什么时候该用：现在。只要你在用 AI 编程工具，第一件事就是写 Rule。成本最低，效果最明显。
新员工类比：SOP 手册，标准操作流程。
它是什么：用 Markdown 文件定义的自定义命令。写好之后，输入 /命令名 就能触发。
举个例子：
你每次让 AI 写 commit message 都要说一大堆要求。累不累？
写一个 .claude/commands/commit.md：
根据当前代码变更，生成符合约定式提交规范的 commit message。
要求：
- 类型：feat / fix / refactor / docs / chore / style / build
- 描述使用中文
- 不超过 50 个字
以后只要输 /commit，AI 就知道该怎么做了。
两个层级：
~/.claude/commands/ —— 用户全局，个人常用.claude/commands/ —— 项目级，跟团队共享什么时候该用：当你发现自己在重复输入类似的 Prompt 时。
新员工类比：专业培训课程，学完就具备对应能力。
它是什么：能反复用的 Prompt 工作流，打包成一个“技能”。和 Command 有点像，但 Skill 更强——它能被社区分发和安装，还带有更丰富的触发机制。
区别说清楚：
典型场景：
/review-pr —— 自动审查 Pull Request/unit-test-generator —— 自动生成单元测试/vue-best-practices —— Vue 最佳实践检查怎么找：先去社区和相关资源库里搜索现成的 Skill，找到适合自己的，安装到 Claude Code。
什么时候该用：当你发现某个工作流不只你自己需要，别人也需要的时候。
新员工类比：安全检查站。每次出入公司大门都要刷卡、过安检。
它是什么：在 AI 调用工具前后自动执行的 Shell 脚本。比如“写文件之前”、“执行命令之后”，你都可以插一段自定义逻辑。
它有哪些时机：
PreToolUse —— 工具调用之前（可以拦截危险操作）PostToolUse —— 工具调用之后（可以自动跑格式化）Notification —— 通知事件Stop —— Agent 停下来的时候举个例子：
每次 AI 写完代码后自动跑 ESLint：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"command": "npx eslint --fix $FILE_PATH"
}
]
}
}
AI 改了代码 → 自动格式化 → 你拿到的永远是规范的代码。
什么时候该用：当你想让某些检查“永远不会忘”的时候。人会忘，Hook 不会。
新员工类比：团队协作机制。遇到大项目，别一个人死扛，拆给团队一起干。
它是什么：主 AI 可以启动多个“子代理”，并行处理不同任务。每个 Subagent 有独立的上下文，互不干扰。
为什么需要它：
AI 的上下文窗口有限。一个复杂任务塞太多东西，它会“忘事”。
Subagent 的解决思路是：拆。
常见的分工方式：：
Explore —— 快速探索代码库、梳理相关上下文Plan —— 整理思路、设计方案、拆解任务general-purpose —— 通用型子代理，啥都能干什么时候该用：当任务复杂到“一口气说不清楚”的时候。
新员工类比：办公工具。你总不能让新人空手上班吧？电脑、邮箱、Jira 权限，都得给配齐。
它是什么：MCP（Model Context Protocol），模型上下文协议。一个开放标准，让 AI 能连接外部工具和数据源。
说白了，AI 本身只能读代码、写代码。但通过 MCP，它能：
怎么用：在配置文件里加一个 MCP Server 就行。
去哪找：目前社区已经有不少 MCP Server 市场：
主流 AI 工具基本都有现成的 MCP Server。装上就能用，不用自己写。
什么时候该用：当你希望 AI 能访问代码之外的信息或工具时。
这里要澄清一个误解。
Claude Code 没有传统意义上的“插件系统”。它不像 VS Code 那样有一个插件市场，点安装就完事。
它的扩展方式是组合式的：
这四种机制灵活组合，就是 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 编程工程化体系的全景导读。
每个概念背后都有一堆细节——是什么、怎么用、哪些场景适合、有哪些坑需要避开，以及有哪些现成的市场资源可以直接用。
后续我会逐一展开，每篇聚焦一个概念：
感兴趣的朋友可以保持关注~
工程化不是限制创造力，是保护创造力。
先把体系搭好，再让 AI 起飞。
当 AI 能写代码、能改架构、甚至能自己完成任务的时候，程序员真正的差距，已经不再是“会不会用 AI”。
而是——有没有能力把 AI 用进工程体系里。
这也是我越来越强烈的一个感受：
AI 编程工程化，正在成为 AI 时代程序员的一项基本功。
