到底怎么和 AI 一起写一个好项目？
这段时间一直在做简历上的项目，我算是尚硅谷和黑马的骨灰粉了，全栈开发的核心教学视频我基本都有学习。
最近在B站上看视频来跟进点评和外卖的过程中我不断定期去反思自己的成效 ，发现单纯盯着视频上老师的节奏，敲下暂停键然后一比一的照抄下屏幕上标准代码并没有让我的工程能力和后端素养得到真正的提升。在瞌睡，回放，看弹幕来修bug的返回折腾下我开始感到厌倦与疲惫。
经过长期的听课的被动学习，我深深的认识到此举的效率十分低下并且我相信最终和曾经的各位一样：除了完美运行的代码文件和简历上的项目外一无所获。
扪心自问学这一个月到底学到了什么？是真的完全熟悉前后端联调的标准流程？是真的理解了数据与对象在消息流转过程中的状态转换？还是彻底在潜意识里熟悉了后端分层架构的设计逻辑？我认为很难，至少我做不到完成整个项目时能自信地向朋友描述我项目的架构设计，遇到的“最大危机”，最有感触的细节打磨。
诚然，多少学哥学姐们都是打着瞌睡，看着点评和外卖一路杀进大厂，但当今早已时过境迁，如今 AI 已然为计算机软件行业注入了无比强大的力量，先进的生产力和生产工具对我们而言触手可得。我曾经是多么无知 竟把 AI 当作“升级版”的度娘，殊不知在未来 ，AI 的定位绝不是行走的“拐杖”，而应当充当不舍昼夜的“黑奴”！
在和 AI 日复一日的交流与思考中：很幸运！我找到了属于自己与 AI 协作开发简历级项目的新范式，文章很长，因为的确是我在开发项目过程中即兴抒怀让 GPT 生成的文章，但所有的协作范式，思考洞见都是我从实践和思考中沉淀和内化的。有幸与各位一同分享！
(代码不分贵贱，此范式你可以应用于任何项目：最近很火的多 Agent 协作项目， 底层的 mini-RPC 框架项目，亦或是人人喊烂大街的点评和外卖项目，因为真正决定简历能否过筛/面试能否口吐珠玑地展示自己的工程能力和代码功底的在于你是否真的通透的理解过自己的（抑或是别人的）项目 ）
1. 这篇文章是干什么的？
这不是一份鸡汤，也不是一份空泛的“如何学编程”建议。
它是一套可以直接拿来执行的协作范式，用来解决很多学习者在软件开发中最常见的几个问题：
- 功能做出来了，但代码没真正读懂
- 一直跟着教程或 AI 走，自己大脑却很空
- 会调接口、会跑项目，但讲不清逻辑链路
- 学习过程缺少节奏，今天做了，明天就散了
- 和 AI 协作时，经常变成“AI 一顿输出，自己被动接收”
这套范式的目标不是“最快做完项目”，而是：
- 在真实开发中同步建立工程能力
- 在实现功能的同时完成理解、复盘和内化
- 把 AI 从“代做工具”变成“陪跑教练、代码搭子和复盘老师”
一句话概括：
- 不是“边做项目边顺便学习”
- 而是“把项目本身设计成最好的学习现场”
2. 这套范式的核心理念
2.1 功能推进不是唯一目标
很多人以为软件学习的主线是：
- 今天做登录
- 明天做 CRUD
- 后天做支付
问题在于，这样很容易只留下“完成感”，却没有留下“能力”。
真正有效的学习开发应该同时包含三条线：
- 功能线：把业务做出来
- 理解线：把代码和逻辑讲清楚
- 复盘线：把经验、错误和关键知识点沉淀下来
如果只跑功能线，最后往往会出现一种常见状态：
- 项目推进了
- 但打开 IDEA 还是心里发空
2.2 AI 不只是写代码，更要参与教学
新时代的软件学习，不应该把 AI 只当成“高级代码生成器”。
更好的用法是让 AI 同时承担这些角色：
- 架构陪跑者：帮你规划阶段目标
- 代码搭子：和你一起实现功能
- 联调助手：一起排查接口、数据库、前端、配置问题
- 复盘老师：把当天关键逻辑和知识点讲明白
- 提问教练：在你以为懂了的时候继续追问
如果 AI 只负责“生成代码”，那它只提高了速度； 如果 AI 同时负责“引导理解”，它才真正提高了成长质量。
2.3 学习不是“看懂”，而是“能复述”
对新手来说，一个最容易自欺的瞬间是：
- 这段代码我好像看懂了
但真正的标准应该是：
- 我能不能用自己的话讲出来
- 我能不能说清请求是怎么流转的
- 我能不能指出关键代码在哪几个文件里
- 我能不能改一个小地方而不慌
所以这套范式特别强调：
- 口述
- 反问
- 复述
- 小步验证
不是为了增加负担，而是为了把“似懂非懂”变成“真正内化”。
3. 这套范式适合什么项目
这套方式不要求必须照搬某个课程项目。
完全可以让 AI 直接为你设计一个：
- 架构合理
- 技术栈成体系
- 难度分阶段递进
- 能真实落地实现
的新项目。
适合的项目有两类：
3.1 跟经典项目做二次构建
比如：
- 外卖平台
- 电商后台
- 博客系统
- 商城管理平台
- 预约系统
优点是：
- 业务成熟
- 资料多
- 容易对照
3.2 由 AI 直接设计新项目
比如：
- 面向校园的二手交易平台
- 小型 SaaS 任务协作系统
- 个人知识管理后台
- AI 内容运营管理平台
- 社区活动报名与签到系统
更好的要求不是“项目名多酷”，而是：
- 场景完整
- 模块清晰
- 能覆盖核心后端能力
- 可以逐步扩展
一个值得做的项目，至少应该让你练到这些东西：
- 接口设计
- 数据库设计
- 分层开发
- 登录鉴权
- CRUD
- 事务
- 异常处理
- 前后端联调
- 文件上传
- 文档沉淀
4. 标准协作节奏
这是这套范式最核心的部分。
每一天、每一个模块，都按下面 6 个阶段推进。
阶段 1：先定目标，不急着写代码
一开始不要直接问 AI：
- “帮我把这个功能写了”
更好的方式是先明确：
- 今天做什么
- 这个功能在整个项目中的位置是什么
- 依赖哪些旧代码
- 做完以后应该能验证什么
这一步的目标是：
- 先立地图
- 再走路
阶段 2：小步实现，不做大跃进
不要一口气做完整个模块。
应该切成一个个最小闭环，比如：
- 先新增
- 再分页
- 再详情
- 再修改
- 再删除
- 再处理前端联调问题
每次只做一小步，有两个好处：
- 出错时容易定位
- 大脑更容易跟住链路
阶段 3：每做一步就立即验证
每一个功能做完后，都要立刻验证，不要攒到最后一起测。
验证方式可以包括：
- APIFox 调接口
- 前端页面点击
- 查数据库
- 看控制台日志
- 看 Swagger 文档
要养成一个习惯：
- 功能不是“代码写完”才算完成
- 而是“代码写完并验证通过”才算完成
阶段 4：每完成一段，就讲清主链
这是这套范式和传统“跟着敲”最大的不同。
每完成一段功能后，都必须讲清：
- 前端请求打到哪里
- Controller 做了什么
- Service 做了什么
- Mapper 执行了什么 SQL
- 数据库哪张表发生了变化
- 最终为什么页面会更新
如果一条链路讲不出来，就先别急着进下一步。
阶段 5：精读关键代码，而不是泛泛总结
复盘不是“今天完成了新增、修改、删除”这种流水账。
真正有价值的复盘，要盯关键代码读，比如：
- 哪个切面在拦截
- 哪个 Service 在做业务编排
- 哪个 XML 在动态拼 SQL
- 哪个配置类在控制资源映射
精读时只抓最关键的 3 到 6 个文件，不贪多，但要讲透。
阶段 6：沉淀文档和问题清单
每一天结束后，都要留下至少一份过程文档。
这份文档应该包含：
- 今天做了哪些功能
- 关键代码逻辑链路
- 重要概念的人话解释
- 联调中踩过的坑
- 值得记住的经验
- 还不熟、下次还要追问的问题
这样做的意义不是“好看”，而是为了：
- 防遗忘
- 便于二次复习
- 为未来的新项目复用方法
5. 每天继续下一天之前，至少达到什么标准
不是要求把当天代码背下来，而是至少满足下面 5 条：
- 能说清今天做了什么
- 能讲出 1 到 2 条核心请求链路
- 能认出关键文件分别负责什么
- 能用自己的话解释当天最重要的 5 个关键词
- 能独立做一个小改动而不完全失去方向
如果还做不到，就不要急着开下一天。
真正稳的学习节奏不是：
- 今天必须做完 Day4
而是：
- 今天的 Day3，我已经真的吃进去了吗
6. AI 协作的推荐方式
和 AI 协作时，建议明确告诉它遵守下面的规则。
6.1 AI 不要只给结果，要带着走
比起：
- “你去测一下这个接口”
更好的方式是：
- 只测一个接口
- 我告诉你去哪点
- 我告诉你看什么结果
- 做完后把结果发回来
这样用户不会被任务丢在原地。
6.2 AI 不要一口气讲太多抽象词
更适合新手的解释顺序应该是：
- 先说这一步在做什么
- 再说为什么要这么做
- 最后再补原理词汇
也就是说：
- 先讲人话
- 再讲术语
6.3 AI 要主动做“讲解 + 追问”
当一个模块完成后，AI 不应该立刻跳到下一模块。
它应该主动做三件事：
- 挑关键代码精读
- 提炼当天关键词
- 提几个小问题让学习者自己回答
因为“回答问题”的过程，本身就是最好的内化过程。
6.4 AI 要保护学习者的思考痕迹
在改代码、重构、修报错时，AI 不应随意删除用户自己写的：
- 注释
- 理解笔记
- 过程标记
这些内容对于学习者来说不是噪音，而是认知支架。
6.5 AI 要区分“推进功能”和“建立能力”
AI 需要时刻提醒自己：
- 项目推进速度不是唯一指标
- 学习者是否真正形成理解，才是更高优先级
7. 一套推荐的日常开发学习流程
下面是一套非常适合和 AI 配合使用的日常流程。
每次开始前
- 先说今天的目标
- 明确只推进一小段
- 确认已有代码基础和缺口
开发时
- 一次只做一个闭环
- 每完成一步就测试
- 遇到问题先分层定位：
- 前端问题
- 后端问题
- 数据库问题
- 配置问题
开发后
- 做代码精读
- 做关键词复盘
- 做问题回答
- 做文档沉淀
第二天开始前
- 先快速回看昨天文档
- 先口头复述昨天主链
- 再进入新模块
8. 一个真正有效的提问方式
很多人和 AI 协作低效，不是因为 AI 不够强，而是因为提问方式太粗。
低效提问：
- 帮我写这个功能
- 我报错了怎么办
- 这段代码讲讲
更好的提问：
- 先帮我梳理这个功能的最小实现闭环，再带我一步一步完成
- 先别直接改，先告诉我这个报错更像是前端、后端还是数据库问题
- 不要只解释结果，请按 Controller、Service、Mapper、数据库的链路带我讲这段代码
一个高质量问题，应该尽量包含：
- 我现在做到了哪一步
- 我看到了什么现象
- 我最困惑的点是什么
- 我希望 AI 以什么方式帮助我
9. 一个推荐的新项目启动模板
如果下一次做新项目，可以直接把下面这段话发给 AI：
我们这次要一起做一个新的软件开发项目。请不要只把自己当成代码生成器，而是作为“项目陪跑老师 + 代码搭子 + 联调助手 + 复盘教练”。我希望我们遵循下面的协作范式：1. 先由你帮我设计一个架构合理、技术栈完整、可落地实现的项目，也可以结合我的方向偏好来定题。2. 项目推进时，一次只做一个最小闭环，不做大跃进。3. 每实现一步都要立即验证，包括接口、前端、数据库、日志。4. 不要只告诉我结果，要带着我一步一步测，告诉我点哪里、看什么、结果意味着什么。5. 每完成一段功能后，必须带我做代码精读，讲清 Controller、Service、Mapper、SQL、数据库变化的完整链路。6. 每天结束后，必须帮助我提炼关键代码、知识点、关键词、常见错误和排错思路。7. 在我没有真正讲清主链和关键代码职责前，不要急着推进下一天。8. 你在修改代码时，不要删除我自己写的注释和理解笔记，除非我明确要求。9. 沟通语言要通俗具体，先讲人话，再补术语。10. 目标不是最快做完项目，而是借项目真正建立软件开发能力。如果你理解了，请先帮我：1. 设计一个合适的项目2. 拆出前 7 到 12 天的阶段目标3. 给出 Day1 的最小闭环4. 告诉我今天先做什么
这段话的价值在于：
- 它不是在问一个单点问题
- 而是在一开始就把协作方法定下来
10. 这套范式为什么有效
因为它同时解决了软件学习中的 4 个根问题：
问题 1：只会跟着做，不会自己讲
解决方式：
- 每段功能后强制做主链复述和追问
问题 2：做了很多功能，但脑子里没有地图
解决方式：
- 每次先定范围、再做最小闭环、再画链路
问题 3：功能跑通了，但代码没读进去
解决方式：
- 每天固定精读关键文件，不再只看表面现象
问题 4：和 AI 协作时，自己越来越被动
解决方式：
- 把 AI 从“代做者”改造成“陪跑者”和“提问者”
11. 潜在的进一步升级做法
如果想把这套范式再升级，可以继续加上这些做法：
11.1 建立自己的“问题错题本”
每次遇到有代表性的问题，都记录：
- 现象
- 根因
- 排查过程
- 最终修法
久而久之，这会成为你自己的开发经验库。
11.2 建立“关键词卡片”
比如把下面这些词分别做成自己的解释卡：
- DTO
- VO
- AOP
- 事务
- 动态 SQL
- ThreadLocal
- 拦截器
- 反射
要求不是背定义，而是：
- 用自己的话解释
- 配一个项目中的真实例子
11.3 给自己留“微型独立题”
在 AI 带完一个模块后，不要马上继续下一个模块。
先给自己布置一个 10 到 20 分钟的小题：
- 改一个字段
- 补一个简单接口
- 改一条查询条件
- 调整一个校验规则
这是把“看懂”推向“会动手”的关键一步。
11.4 周期性做“无提示复盘”
每隔几天，关闭 AI 输出，只看项目代码和文档，自己尝试讲：
- 这个模块怎么跑
- 哪几个文件最关键
- 哪一步最容易出错
然后再让 AI 补漏。
这会非常有效。
12. 最后的结论
新时代学习软件开发，最好的方式已经不是：
- 只看视频
- 只抄代码
- 只拼命做题
- 只让 AI 帮你写完
更好的方式是：
- 用一个真实项目做主线
- 用 AI 带着你小步开发
- 每一步都验证
- 每一段都讲清楚
- 每一天都沉淀下来
- 用反复提问、复述和精读，把项目真正变成自己的能力
这套范式的本质不是“让学习更快”，而是：
- 让学习真正发生
如果要把它压缩成一句最值得记住的话，那就是：
- 不是让 AI 替你完成项目
- 而是让 AI 陪你把项目一层一层嚼碎，最后变成你自己的软件开发能力
