别再把 Claude Code 当聊天机器人：从 Vibe Coding 到 Agentic Engineering

前言

先说一个你大概率经历过的场景。

你听说 AI 会写代码，兴冲冲打开对话框敲下一句：帮我做个待办事项的小网站。十秒后代码就出来了，一跑，还真能用。你惊叹一句”厉害”，接着提需求：加个深色模式，加个数据导出，再适配一下手机端。

半小时后，事情开始不对劲。改一个按钮的颜色，另一个页面崩了。让 AI 修，它修出三个新 bug；再修，再崩。你把报错贴回去，它答”抱歉，这次一定改好”——结果还是没有。最后你只能重开一个对话，从头再来，祈祷这回运气好点。

如果这个故事让你觉得眼熟，这篇文章就是写给你的。问题其实不在模型不够聪明——过去两年模型换了一代又一代，这个故事却一直在重演。真正的症结在别处，这也正是整个系列要讲的事。

这种玩法有个名字：Vibe Coding

“Vibe Coding”这个词是 Andrej Karpathy 带火的，指一种全凭感觉的写码方式：对着 AI 描述需求，生成的代码看都不看，能跑就行，跑不起来就再换个说法描述一遍。

得先替它说句公道话——Vibe Coding 本身不是罪。周末想捣鼓个小工具，或者验证一个点子到底成不成立，这种玩法快得惊人。Claude Code 的作者 Boris Cherny 就说过，与其花几天写 PRD，不如直接让 AI 做上二三十个原型试试看——反正如今做原型的成本已经低到可以忽略不计。

问题在于，很多人把”原型玩法”一路照搬到了正经项目上。原型可以随手扔掉，你的正式项目却扔不了。于是一切开始反噬：没有测试，改哪儿都提心吊胆；没有文档，AI 每次面对你的项目都一无所知；对话越聊越长，AI 越来越”钝”，你却说不清它到底忘了什么。

换个工作方式，比换个模型有用

把 Vibe Coding 和正经工程放在一起看，差别就很直观了：

右边这种工作方式，如今有了一个正式的名字，叫 **Agentic Engineering ** —— 把 AI 当成一支工程团队来带，而不是当成一口许愿池来许愿。团队里有分工，有规矩，有验收，也有交接文档。你要做的，从”求它一次做对”，变成”设计一套让它很难做错的流程”。

听起来像管理学的空话？我起初也是这么想的。直到看到一组数据，我才明白这个转变有多实在。

你打的 6 个字，和模型看到的 15000 个词

你有没有想过一个问题：当你按下回车，AI 到底「看到」了什么？

你觉得自己输入的是一句话，比如"帮我写个函数"，6 个词。但模型实际接收到的，远不止这些。

如果你的项目配了 CLAUDE.md（一份写给 AI 看的项目说明书），模型会先读到它；如果配了规则文件，相关规则会被自动加载进来；再叠上系统提示、工具定义、环境信息、你们之前的对话历史……你敲进去的那 6 个词，只是这一大摞内容最底下的一条。

这组数字出自一份针对 Claude Code 内部机制的分析报告：用户输入大约只有 6 到 60 个 token，而模型一次推理实际”看到”的，通常在 5000 到 50000 个 token 之间——差了整整三个数量级。

那么，谁负责把这一大摞东西组装起来？不是你，是 Claude Code 这套工具本身。业内管它叫 Harness（不妨理解成”驾驭系统”）——它是包在模型外面的一整层工程设施：什么时候加载什么上下文、哪些操作该拦截、活干完要不要跑测试、跨会话还记不记得你。

一个不算严谨但很好用的类比：模型是厨艺，Harness 是厨房。

菜谱（提示词）写得再漂亮，没有厨房——没有灶台、没有流水线、没有品控——你照样开不了餐厅。Vibe Coding 的困境，本质上就是一个人拿着菜谱，在没有厨房的地方炒菜：前面几道小菜靠手快还能撑住，菜单一多，必然翻车。

那Claude Code到底给了你什么

说了半天 Harness，落到具体产品上，Claude Code 给你的其实就是几件「工程原语」。单看每一件都不复杂，合起来就是一整套厨房：

• CLAUDE.md（项目记忆）——相当于新员工入职手册。用什么框架、测试命令是什么、代码风格有哪些规矩，都写在这里，AI 每次开工先读一遍，省得你每轮对话都重复一句 ”我们用的是 pnpm，不是 npm”。
• Commands（自定义命令）——把每天要重复很多遍的话做成快捷指令。比如 /deploy、/fix-lint，一次定义，随时调用，还能提交进 git 供全组共享。
• Skills（技能）——给 AI 配的专业岗位操作手册。平时它”装作不知道”，遇到对得上的任务才自动加载，不占用平时的脑容量。
• Subagents（子代理）——外包团队。派独立的分身去干搜索、调研、跑测试这类脏活累活，主对话里只回收一句结论，上下文干干净净。
• Hooks（钩子）——质检流程。在 AI 干活的各个环节插上你自己的检查点，比如”每次改完代码自动跑一遍格式化”。关键在于：它由程序强制执行，不靠 AI 自觉。

这五件东西，后面每个都会用一整篇文章细讲。这里你只需要建立一个直觉：它们都不是"更花哨的提示词"，而是提示词根本做不到的事。

"会写提示词"为什么不够

现在网上教提示词的课一大堆，你可能会问：把提示词写好点，不就完了？

提示词当然重要，但它有三个天花板，是再好的文笔也顶不破的。

第一，提示词不能并行。 你在一句话里让 AI 同时调研十个文件，它也只能一个一个来，中间的过程和走过的死胡同，全都堆在你们的对话里。而 Claude Code 可以一次派出五个子代理，各开各的上下文分头去查，最后只把五份结论交回来。仓库里那句总结很精辟：动手前先问自己——“我要的是这个工具的输出本身，还是只要一个结论？”

第二，提示词不能强制。 你在提示词里写"每次改完代码必须跑测试"，AI 心情好就跑，上下文一长就忘——因为提示词本质上是"建议"。Hooks 不一样，它是代码，是程序层面的强制拦截，模型想绕都绕不开。"建议"和"强制"的区别，就是"拜托你靠谱点"和"CI 流水线"的区别。

第三，提示词活不过一次会话。 对话一关，你说过的所有规矩、踩过的所有坑，全部清零，第二天又是个陌生人。而 CLAUDE.md 和规则文件写在磁盘上，每个新会话自动生效——你调教 AI 一次，它就永久在线。

这就是那份数据背后真正想说的话：对于真正的工程任务，输出质量 ≈ 有效上下文 × 模型能力 × 迭代循环。你手写的那点提示词，只是有效上下文里的一小片。其余的部分，谁搭好了 Harness，谁就拿得到。

这个系列要讲什么

接下来我会用一个完整的系列，把上面这五件原语和更多进阶玩法一篇篇讲透。整个系列的素材，主要来自一个叫 claude-code-best-practice 的 GitHub 仓库——它登上了 2026 年 3 月 GitHub 趋势榜月榜第一，内容全部溯源到 Claude Code 团队成员（作者 Boris Cherny、工程师 Thariq 等）的一手分享，每周还有人追踪官方更新。我的工作，是把这些英文世界里散落的精华，翻译成普通人能上手的中文实践。

系列规划是 12 篇，每周更新：

篇	主题	解决什么问题
1	本篇：认知开篇	为什么不能把 Claude Code 当聊天机器人
2	CLAUDE.md 与记忆系统	怎么写 AI 一读就懂的项目手册
3	Subagents / Commands / Skills 怎么选	三大原语的使用决策
4	Subagents 深度实战	怎么派活、怎么回收结论
5	Skills 深度实战	怎么给 AI 写"操作手册"
6	Hooks 系统	怎么给 AI 装上强制质检
7	Settings 与权限	配置文件从入门到放心的放权
8	上下文管理	什么时候该 /clear，40% 法则
9	编排实战	手把手搭一个 Command → Agent → Skill 工作流
10	Hot 新特性	Agent Teams、定时任务、并行开发
11	主流工作流框架评测	12 个热门框架怎么挑
12	官方团队 83 条技巧精编	大师工作流合集收官

不需要从头读到尾，哪篇对应你眼下的困惑，就从哪篇进。但如果你刚装好 Claude Code 不久，建议按顺序来——这个系列的前后是有依赖的。

给完全没装过的新手留一句：这个系列默认你已经在终端里跑起来 Claude Code 了。如果还没有，别急，先去 claude.com/claude-code 装一个，回来正好从第 2 篇开始。

下一篇，我们从最简单、见效最快的一件事讲起：给你的项目写一份 AI 真的会读的说明书。

系列导航