从提问到协作 —— 聊聊 AI 编程的三个阶段

最近接到博哥邀请，组织了个面向低年级的技术分享，让我来聊聊对 Vibe Coding的体会。说实话 AI确实是一个很屌很好玩的东西，自己玩了很久 也实践出了一套很Awesome的Workflow，对agent也有很深刻的理解和认知吧，但是真要我来说一说还得好好总结记录一下...

但真要我掏心窝子讲，我又确实有话想说。因为这一年我agent从零搓了个全栈电商项目 springMall ，从最开始的claude code暴力调用，一路用到后来的 Subagent, Agent Team，Skills，MCP的 工作流。中间踩的坑、转过的弯，值得唠一唠。所以干脆把分享的稿子整理成这篇 BLOG，记录一下我对 Vibe Coding 这件事到现在为止的理解。

提前来个免责声明：这篇不是教程，是经验分享。存主观臆断，如你的XP与我不符，你说的都对hhh

image

何为 Vibe Coding？

一切都要得从 2025 年初说起。那个搞 nanoGPT 的 Andrej Karpathy 发了条推文：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Vibe Coding待生了！！！简而言之，vibe coding就是：你描述意图，AI 写代码，你自己沉浸在「Vibe」里，甚至不用去关心代码长啥样。听起来是不是很美好？

但现实呢？现实是同样一句话，有的人效率真的翻了十倍，有的人却越用越乱——生成的代码跑不起来、风格东一榔头西一棒槌、跟自己的项目完全格格不入，最后还得自己一行行回去擦屁股。

那么问题来了：凭什么差距这么大？

是啊，一样的工具，一样的模型，怎么到手里就一个天上一个地下。这事跟你「会不会用」AI 关系不大，跟你走到了哪个阶段关系很大。

在我看来，用 AI 编程这件事，是有三个层层递进的阶段的：

1. Prompt Engineering —— 你会提问
2. Context Engineering —— 你会喂料
3. Agentic Engineering —— 你会协作

下面我就结合 springMall 这个项目，挨个唠唠这三个阶段到底是个啥。

第一阶段：Prompt Engineering —— 你会提问就会编程

第一阶段，也是最早、最入门的玩法——Prompt Engineering（提示词工程）。

image

它的本质一句话就能说清：你怎么说话，AI 就怎么干活。你问得含含糊糊，它就还你一坨含含糊糊的东西；你把角色、要干啥、要啥格式、有啥限制讲明白，它就给你一份能直接用的代码。说白了就是「把话说清楚」这点事，没啥玄学。

不过我得先泼盆冷水：这一招放到今天，其实已经有点过时了。 它最活跃的年代，是你对着 ChatGPT、Claude 这种「网页聊天框」一段一段地敲——你和一个光秃秃的对话框打交道，全靠那一段话的功夫。

为啥说过时？因为网页聊天框有个治不好的毛病：它每开一轮新对话都是「失忆」的。它不知道你这个项目用的是 MyBatis 不是 JPA，不知道你的响应统一包了一层 Result<T>，不知道你所有路径都得加 /api/v1/ 前缀。你总不能每次提问都把这一长串规矩重新抄一遍吧？抄到第三回我自己都嫌烦。

所以 Prompt 这关，会，但别恋战——它是地基，不是高楼。真正让 AI 从「网页玩具」变成「生产力」的，是下一步：你得想办法，给 AI 喂对、而且让它能「记住」上下文。

第二阶段：Context Engineering —— AI 不读心，你得喂对料

何为 Context Engineering？

Context Engineering（上下文工程）的核心就一句话：AI 压根不了解你的项目，你得系统性地、一次性地告诉它。

Claude code、Open code、Cursor

注意，重点不是把代码一股脑全甩给它——那叫信息过载，上下文窗口分分钟给你撑爆。重点是精心地组织信息，让 AI 摸清你项目的全貌：架构长啥样、规范是啥、有哪些约束、现成的写法是怎样的。

image

一份好的「项目上下文」，我觉得至少得讲清这几件事：

要素	作用	举个栗子
项目架构	项目的骨架	前后端分离，Spring Boot + Vue 3
目录结构	代码该放哪	controller/ 放接口，service/ 放业务
命名规范	东西怎么命名	DTO 用 XxxRequest，VO 用 XxxVO
技术栈约束	用啥不用啥	MyBatis（不是 JPA），JWT（不是 Session）
已有模式	照着现成的抄	统一 Result<T> 包装响应

用 .claude 规范，给 AI 装一份「记忆」

还记得上一节那个「失忆」的毛病吗？这一步就是来治它的。

/init 可以叫ai创建.claude规范

我的做法是：在项目根目录建了个 .claude/CLAUDE.md 文件，把它当成 AI 的「项目说明书」。妙就妙在——这玩意儿你只用写一次，AI 每开一轮新对话都会自动读一遍。换句话说，那些「项目用 MyBatis、响应包 Result<T>、路径加 /api/v1/」的规矩，从此长在了 AI 脑子里，再也不用你一遍遍复读。这，就是「记忆」。

核心内容大概长这样：

image

有了这份东西之后，AI 生成的代码就从「能跑」悄悄进化成了「能融进项目」：

• 自动用 MyBatis，再也不冒 JPA 了
• 自动拿 Result<T> 把响应包好
• 自动给路径加上 /api/v1/ 前缀
• 自动把文件丢到正确的包目录里

那种感觉很奇妙——你不再是反复纠正它，而是它本来就懂规矩。

还有一招：让agent「先想清楚再动手」—— Plan Mode

「Context」解决的是「AI 知道项目长啥样」，但上下文工程还有另一半同样要紧的：在它真正动手改代码之前，先逼它把任务想清楚。

image

这就是 plan mode（计划模式）的用处。开了它，AI 不会上来就闷头一通乱改，而是先把「我打算动哪些文件、分几步走、为啥这么改」摆出来给你过目；你点头了，它才真正下手。

说到底，这是门信息架构的学问

很多人一听上下文就以为是多贴点代码，其实差远了——它还包括文档、代码规范、Git 约定、错误处理方式、安全红线这些软东西。这些单拎出来看好像都不那么重要，但恰恰是它们，决定了 AI 写出来的代码能不能真正长进你的项目里。

我有个特别顺手的类比：这跟给新员工写 onboarding 文档一模一样。你不会傻乎乎地把整个代码库甩他脸上让他自己悟，而是告诉他「项目是怎么转的、代码搁哪、规矩是啥」。把 AI 当成那个聪明但啥都不知道的新人，你就知道该喂它什么了。

第三阶段：Agentic Engineering —— AI 不是工具，是队友

何为 Agentic Engineering？

Agentic Engineering（代理工程）是我目前体会到的最高阶玩法。在这个阶段，AI 不再是那个「你问一句、它答一句」的对话框了，而是一个能自己规划、自己执行、自己验证的 Agent。

image

你扔给它一个需求，它会自顾自地把这一整套都走完：

1. 分析需求范围
2. 制定实施计划
3. 吭哧吭哧写代码
4. 跑测试
5. 自己审查代码质量
6. 顺手把文档也生成了
7. 最后回过头来跟你汇报结果

发现没有——这已经不是「用工具」了，这是派活儿。

范式变了

我喜欢用这张表来概括三个阶段里「你」和「AI」的角色变化，看完基本就懂了：

阶段	怎么交互	你是	AI 是
Prompt Engineering	你写一句，它写一句	代码作者	代码生成器
Context Engineering	你给背景，它写代码	架构师	高级开发
Agentic Engineering	你给需求，它自己干	项目经理	一整个开发团队

是的，到第三阶段，你的身份从「写代码的人」变成了「带团队的人」。

springMall 的六人 Agent 团队

在 springMall 里，我在 CLAUDE.md 里给自己配了一支 6 人 Agent 团队，每个 Agent 各管一摊：

Agent	管啥	相当于
backend-dev	Controller、Service、Mapper、Entity 这些后端代码	后端工程师
frontend-dev	Vue 页面、组件、Pinia Store、Router	前端工程师
code-reviewer	安全审查、OWASP 检查、代码规范一致性	技术 Lead
test-validator	跑 mvnw test 和 pnpm run build	QA 工程师
devops-deploy	Dockerfile、docker-compose、nginx 配置	DevOps
doc-writer	写文档、更新文档	技术文档工程师

image

听起来有点中二是吧——一个人的项目，硬是搞出个「公司编制」😂。但你别说，真用起来是有用的：每个 Agent 职责单一、互不打架，质量反而比一个 Agent 大包大揽要稳。

一个功能，是怎么被流水线做出来的

举个具体的。当我丢出一句「加一个商品收藏功能」的时候，这套团队会自动跑起来这么一条流水线：

用户提需求
    │
    ▼
主 Agent 分析需求范围
    │
    ├── 要改后端？ ──► backend-dev 实现
    │                      │
    │                      └──► doc-writer 补技术文档
    │
    ├── 要改前端？ ──► frontend-dev 实现
    │
    ▼
code-reviewer 审查所有改动（只读不写）
    │
    ▼
test-validator 跑测试 + 构建
    │
    ▼
主 Agent 把结果汇报给我

而整个过程里，我真正要动手的只有三件事：

1. 把需求说清楚
2. 确认一下方案
3. 验收最终结果

剩下的脏活累活，全程它们自己消化掉了。那一刻我是真切地从「写代码的人」变成了「项目经理」。 第一次跑通这套流程的时候，我盯着终端里一个个 Agent 自动接力，说实话还挺爽的 hhh。

但是，千万别飘——几个心智模型

爽归爽，这里有几条我踩出来的经验，必须泼点冷水。

一、Agent 不是万能的，边界得你来划

Agent 再能干，它也不知道哪些事「绝对不能碰」。这些红线，只能人来定。比如 springMall 的 CLAUDE.md 里，我写死了一串安全策略：

1. 绝不修改、创建或 commit .env 文件
2. 绝不 commit 密钥：JWT Secret、数据库密码、API Key
3. 绝不在未写明回滚方案的情况下改数据库迁移脚本
4. 绝不执行 rm -rf、git reset --hard 等危险命令

这些规矩是人设计的，Agent 只负责老老实实执行。你不写，它真有可能哪天兴致一来就把你 .env 给 commit 上去了——到时候哭都来不及。

二、CLAUDE.md 就是你的「团队手册」

我越用越觉得，CLAUDE.md（有些工具叫 AGENTS.md）的质量，几乎直接等于 Agent 的靠谱程度。手册写得越清楚、越完整，Agent 就越听话；手册含含糊糊，Agent 就给你自由发挥，发挥到你血压升高。

它里面该有的东西：项目架构和目录结构、技术栈和约束、编码规范、安全红线、Agent 的角色分工、工作流程……基本就是把一个真团队的「入职大全」搬过来。

三、有些活，永远是人的

这条我想专门强调，尤其是说给新生听——别一看 AI 这么猛就慌，觉得「那我还学个啥」。恰恰相反，下面这些事，AI 一样都替不了你：

• 定义需求：Agent 不知道你的业务到底要什么
• 设计架构：它能照着架构干活，但「该用哪种架构」这个决策得你拍板
• 把控质量：最终的代码审查、业务验收，还得人点头
• 划定红线：什么能做什么不能做，永远是人说了算

那么，这三个阶段是什么关系？

讲到这你可能会问：那是不是学会了第三阶段，前面两个就可以扔了？

恰恰相反。 这三个阶段不是「新的替代旧的」，而是层层叠加、地基越垒越高的关系：

• Prompt 是地基：你得先会跟 AI 把话说清楚
• Context 是进阶：你得会管理项目级别的信息
• Agentic 是高阶：你得会设计一整套协作流程

哪怕你已经用上了 Agent 团队，写好每一个 prompt 依然是你最核心的基本功。因为说到底，你给 Agent 下的那个需求，本身就是一个 prompt——地基塌了，上面盖多高都是空中楼阁。

再给你串个类比，可能更好记：

阶段	好比	练的是
Prompt Engineering	学会跟同事沟通	把话说清楚
Context Engineering	学会给新人写 onboarding	组织信息、传递知识
Agentic Engineering	学会带一个团队	设计流程、把控质量

至于什么时候用哪个，其实也不用纠结，按事情大小来就行：

• 小脚本 / 一次性的活 → Prompt 就够了，别整那些花活
• 正经项目 / 要协作 → 老老实实上 Context
• 复杂系统 / 长期维护 → 该请你的 Agent 团队出场了

给学弟学妹的一点建议

铺垫了这么多，落到实处。别整那些虚的——作为一个国内新生，想真正上手玩 agent，其实就这么几步：

第一步：先把梯子问题解决掉

说句实在话，计算机专业的 翻墙都不会 那就洗洗睡吧。它是绕不开的第一道坎，大多数技术都不会出现在中文环境当中，这关搞不定，后面全是空谈。给几个关键词吧，V2rayn Clash vless vmess （具体怎么搞……请自行 google 吧，懂的都懂🤫）

第二步：把环境装好

梯子通了，接着把工具链铺起来：装好 Node 环境，然后 npm i -g 上 Claude Code 或者 OpenCode ，登录、配好 key。别小看这一步，环境是劝退过不少人的地方——但好在它是一次性的事，装好了就一劳永逸。

第三步：开始玩 agent —— 在试错里把它调教出来

环境就绪，剩下的就俩字：玩。

但玩不是丢个需求进去就翘脚等结果。真正的功夫全在那个循环里——让 agent 干 → 看它砸在哪 → 回去调你的 CLAUDE.md / subagent / 流程 → 再让它干。它一开始大概率不听话，改出一堆四不像，这时候别急着自己上手抢方向盘，而是先想想「我是不是哪条规矩没给它讲清楚」，然后回去补。

这套「试错 → 调整 agent」的循环转个几轮，你会发现它越来越懂你——而你，也越来越像个会带团队的人了。

写在最后

唠了这么多，其实我最想跟新生掏的一句心里话是——

AI 编程的本质，从来不是让 AI 替你写代码，而是让你能驾驭得了更复杂的项目。

以前你可能只敢写个百来行的脚本，现在你能去构建上万行的系统；以前你得把一堆 API 死记硬背在脑子里，现在你要学的是怎么去指挥一个 AI 团队。

编程这件事的核心能力，正在悄悄地从「写代码」，挪到「定义问题、设计架构、把控质量」上去。这不是什么遥远的未来，这就是当下正在发生的事。

所以别怕，也别躺。从今天起，就去练习怎么跟 AI 协作吧——慢慢来，你会发现自己能做的事，比想象中大得多。

就bb到这，散会，拜拜！PEACE!!👋