AI 编程工程化:AI 时代程序员的基本功

0 阅读10分钟

好久不见,各位朋友。

最近这段时间,我一直在折腾 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-engineering-system

内层管的是“AI 应该怎么做”——先把规矩立好。

中层管的是“AI 能做什么”——让它更强、更稳、更专业。

外层管的是“AI 能接触什么”——把它和外部工具打通。

从内到外,一层一层来。别急着全部配好,先把内层搞定就能解决 80% 的问题。


7 个概念,逐个拆解

① Rule — 给 AI 定规矩

新员工类比:公司规章制度,什么能做、什么不能做。

它是什么:一个叫 CLAUDE.md 的文件。你在里面写规则,AI 每次启动时会自动读取并遵守。

举个例子

# 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

根据当前代码变更,生成符合约定式提交规范的 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:

{
  "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 时代程序员的一项基本功。