这两年，很多程序员都已经开始用 AI 写代码了。

不会写的实现可以问，卡住的报错可以贴，接口、SQL、测试、重构建议，AI 都能很快给出一版答案。尤其是对初中级程序员来说，这种帮助非常
直接。

但真正的问题也在这里。

很多人虽然已经在用 AI，但并没有真正建立起自己的工作流。
更多时候只是“哪里卡住了就问一句，哪里懒得写了就让它补一段”。

短期看，这种方式确实能提效。
长期看，它很容易让人形成一种错觉：自己好像一直在进步，但很多时候只是把开发过程外包给了 AI。

我越来越觉得，AI 编程真正拉开差距的，不是“会不会用”，而是“有没有工作流”。

这篇文章我不想再讲趋势，也不想讲抽象方法。
我想直接用一个比较真实的开发场景，把这件事讲清楚：

初中级程序员到底该怎么建立自己的 AI 编程工作流？

1. 很多人会用 AI，但没有工作流

先说一个很常见的现象。

很多人现在用 AI 的方式，大概是这样的：

• 看到需求，先让 AI 直接写
• 报错了，把异常堆栈贴过去
• 代码能跑就先合上
• 出问题了再回头补
• 写完之后也没有沉淀

这种方式的问题，不是完全没用，而是太随机。

它会让你在开发过程中始终处于“哪里缺了补哪里”的状态。
你可能写得更快了，但并没有建立起稳定的方法，也没有真正提升自己对需求、结构、边界和验证的把控能力。

而工作流的价值就在这里。

它不是让你把每一步都流程化，而是让你知道：

• 哪一步该自己先想
• 哪一步可以让 AI 参与
• 哪一步必须自己判断
• 哪一步绝对不能省掉验证

对初中级程序员来说，这一点尤其重要。

因为你最需要建立的，不是“更依赖 AI”，而是“更稳定地借助 AI 完成完整开发过程”。

2. 先用一个真实开发场景来讲

我用一个比较贴近日常开发的场景来说明。

假设你接到一个需求：

在设备操作页面里，给失败的操作记录增加一个“重试”按钮，前端点击后，调用后端重试接口，操作执行时间比较长，按钮要防止重复点击，并
给用户明确反馈。

这个需求其实不算复杂，但很适合拿来讲 AI 工作流。

因为它里面同时包含了几个典型环节：

• 需求理解
• 前后端调用链梳理
• 后端接口补齐
• 前端交互处理
• 防重复提交
• 测试与验证

如果这个需求交给很多初中级程序员，第一反应可能是：

“我直接把需求丢给 AI，让它帮我写。”

但真正更合理的做法，不是直接让 AI 接管，而是让 AI 参与到不同阶段。

3. 第一步：先自己理解需求，不急着让 AI 写代码

这是我觉得最重要的一步。

很多人现在最大的问题，不是不会用 AI，而是太早用 AI。

需求刚看到，脑子里还没形成清晰结构，就直接把一句模糊描述丢给 AI，让它给最终实现。
这种用法很容易得到一段“看起来能用”的代码，但你自己其实还没真正想清楚问题。

更好的做法是，先自己把下面几件事想清楚：

• 这个按钮出现在哪个页面
• 只有失败记录才能重试，还是别的状态也可以
• 前端点了之后，后端应该调哪个服务
• 重试是不是要记录来源
• 操作执行时间比较长时，用户界面应该怎么反馈
• 需要防止哪些重复操作
• 最后应该验证哪些场景

这一步不一定要想得很完整，但至少要先形成一个“问题骨架”。

只有这样，你后面让 AI 参与时，它才是在帮你推进，而不是替你碰运气。

所以我现在更推荐一种顺序：

先自己理解问题，再让 AI 帮你加速。

4. 第二步：让 AI 帮你拆问题，而不是直接生成最终实现

当你对需求已经有基本理解后，这时候让 AI 参与，就会更有效。

但这个阶段我不建议直接问：

“帮我把这个功能写完。”

更好的问法是：

• 这个需求应该拆成哪几个开发步骤？
• 前端和后端分别要改哪些地方？
• 哪些地方最容易漏边界？
• 如果要防止重复点击，前端提交态应该怎么处理？
• 如果要补后端接口，调用链可能会经过哪些层？

这一步 AI 最适合做的是：

帮你拆问题。

因为很多初中级程序员不是不会写代码，而是面对需求时，很难快速把问题拆成一组可执行的小任务。
AI 在这个阶段能明显提效。

比如一个本来看起来有点散的需求，经过 AI 帮你拆解之后，会更容易变成：

1. 后端补一个重试接口
2. 前端增加重试按钮
3. 提交时增加 loading 和禁用态
4. 失败和成功给提示
5. 补测试或至少做关键验证

一旦问题被拆开，后面的开发就会顺很多。

5. 第三步：带着上下文让 AI 起草实现，而不是让它盲写

这一步才轮到“让 AI 生成代码”。

但我还是建议，不要一句话让它盲写，而是带着足够的上下文去问。

比如你可以给它这些信息：

• 这是一个 Spring Boot 多模块项目 / 或一个 Vue 3 前端项目
• 当前已有的设备操作列表页面在哪里
• 后端已有 retryDeviceCommand 这样的服务能力
• 前端使用的是确认弹窗还是 modal
• 这次最重要的是防止重复点击，并给用户明确提交反馈

上下文越明确，AI 产出的质量通常越高。

而且这个阶段也不要只让它写实现，你还可以顺手让它给你：

• 需要改哪些文件
• 哪些测试可能要补
• 哪些边界要关注
• 哪些地方可能和现有设计冲突

这样一来，AI 就不只是“代码生成器”，而更像一个开发协作者。

这里有一个很关键的区别：

低质量用法是让 AI 替你开发，高质量用法是让 AI 帮你形成更完整的开发方案。

6. 第四步：自己评审 AI 的结果，重点看 3 件事

AI 把代码写出来以后，真正重要的事情才开始。

因为这时候最危险的，不是“完全写错”，而是“看起来对，但其实有隐患”。

我自己现在评审 AI 结果时，最先看 3 件事。

6.1 这段代码是不是解决了正确的问题

很多 AI 代码的第一层风险，不是实现差，而是方向偏。

比如你本来要解决的是“防止用户重复点击”，结果 AI 只是在按钮上加了个样式，没有真正做提交态控制。
或者你本来要的是“失败记录支持重试”，结果它把所有记录都加上了重试按钮。

所以第一步永远不是看写法，而是看：

它有没有解决对问题。

6.2 它有没有破坏原有分层和边界

这也是初中级程序员特别容易忽略的地方。

AI 很容易为了“快速写出来”，把逻辑放到不合适的位置。比如：

• 本该在后端业务层做的判断，写进了 controller
• 本该在组合逻辑里统一处理的 loading，散落在多个组件里
• 本该复用已有服务能力，却重新绕了一层

这些代码短期也许能跑，但长期会让系统越来越难维护。

所以我会特别看：

• 逻辑放得对不对
• 有没有重复已有能力
• 有没有把问题写“散”了

6.3 它有没有遗漏边界和副作用

这是 AI 最容易出问题的地方。

比如：

• 重复点击时是否真的不会重复提交
• 弹窗关闭后状态会不会残留
• 请求失败后按钮状态是否恢复
• 成功后是否需要刷新列表
• 某些异常场景下会不会卡死在 loading

这些问题往往不是代码主流程能不能跑出来，而是边界是否完整。

所以对初中级程序员来说，一个非常重要的习惯就是：

不要只看 AI 帮你生成了什么，也要看它漏掉了什么。

7. 第五步：自己验证，编译、测试、联调一个都不能省

这是很多人最容易偷懒的阶段。

AI 写完代码之后，最容易出现的心态是：

“看起来差不多了，应该可以。”

但工程里最危险的，往往就是“应该可以”。

我建议最少做这几层验证：

• 编译是否通过
• 页面交互是否符合预期
• 重复点击时是否真的只发一次请求
• 请求失败时 loading 是否恢复
• 成功后页面状态是否更新
• 有没有影响原有流程

如果项目里有测试体系，就尽量补上最关键的测试。
如果没有，也至少把关键链路手动走一遍。

因为对 AI 来说，写代码不是难点。
真正能决定质量的，还是你最后有没有把验证做完整。

所以一套合格的 AI 编程工作流，一定不能停在“AI 生成代码”这一步，而必须走到“自己确认结果可靠”为止。

8. 第六步：把高频任务沉淀成自己的 skill、规则和模板

我觉得这一步特别容易被忽略，但其实价值很高。

很多人用 AI 是一次一忘。
每次都重新问，每次都临时发挥，每次都从头来过。

这样虽然也能做事，但很难真正建立自己的工作流。

更好的方式是，每做完一个需求，就顺手沉淀一点东西，把高频任务逐步固化下来。
这些固化后的内容，可以是：

• 一套需求拆解规则
• 一套代码评审清单
• 一套测试补齐模板
• 一套 Bug 排查步骤
• 一个可以反复复用的 skill

这里我觉得要区分两个层次：

8.1 prompt 解决的是一次提问

你今天碰到一个需求，临时组织一段描述，让 AI 帮你输出一版结果。
这当然有用，但它更像一次性沟通。

8.2 skill 解决的是一类重复任务

如果你发现自己经常在做同一类事，比如：

• 接到需求后要先拆解任务
• AI 写完代码后要做固定评审
• 遇到 bug 时总要按某个顺序排查
• 写完改动后总要补关键验证

那就不应该每次都从零开始问。
更好的做法是，把这类高频动作沉淀成自己的 skill、规则或模板。

这样做的价值很直接：

• 减少随机性
• 让输出更稳定
• 让自己形成固定方法
• 把经验积累下来，而不是反复遗忘

8.3 skill 可以自己沉淀，也可以安装别人提供的

这点也很重要。

不是所有东西都要自己从零写一遍。

你完全可以：

• 自己把常见任务沉淀成一套 skill
• 也可以安装别人已经提供好的 skill，再结合自己的项目和习惯调整

比如有些 skill 已经把“代码评审”“Bug 排查”“测试补齐”“需求拆解”的流程整理得比较成熟，这种时候直接拿来用，往往比自己从零摸索更快。

但关键不是“装了多少 skill”，而是：

• 这个 skill 适不适合你的项目
• 会不会太重
• 有没有和你的工作流冲突
• 你能不能把它真正变成自己方法的一部分

也就是说，skill 不是主角，它只是工作流成熟之后的一个固化结果。

真正重要的，还是你有没有形成自己的方法。

9. 对初中级程序员来说，好的 AI 工作流到底是什么

如果把前面这些压缩成一句话，我会这样理解：

好的 AI 编程工作流，不是把开发过程交给 AI，而是把 AI 放到正确的位置，并把高频任务逐步沉淀成可复用的 skill。

对初中级程序员来说，我更推荐这样的顺序：

1. 自己先理解需求
2. 让 AI 帮你拆问题
3. 带着明确上下文让 AI 起草实现
4. 自己评审结果
5. 自己验证和联调
6. 最后沉淀方法，把高频任务固化下来

这个顺序听起来不炫，也不神奇。
但它很稳，而且真的能帮助一个人把 AI 用进日常开发，而不是只停留在“偶尔问几句”。

我一直觉得，AI 时代最重要的不是“谁更会写提示词”，而是“谁更早建立起自己的工作方法”。

因为工具会越来越强，真正拉开差距的，还是人对问题、结构、边界和验证的掌控能力。

10. 最后

AI 编程当然值得用，而且越早用越好。
但对初中级程序员来说，越是早期，越不能把 AI 用成“思考替代品”。

你真正需要建立的，不是“让 AI 帮我写更多代码”的习惯，而是“让我和 AI 一起把开发流程走完整”的能力。

如果你能形成这套工作流，AI 会成为你的放大器。
如果你只是哪里不会就丢给 AI，短期看是在提效，长期看很可能是在透支自己的成长。

如果你想找一个真实项目练习“怎么理解需求、怎么拆问题、怎么评审 AI 结果、怎么在真实系统里验证实现”，也可以看看我的开源项目
ems4j。

• Gitee：https://gitee.com/jerryxiaosa/ems4j
• GitHub：https://github.com/jerryxiaosa/ems4j

它覆盖后台管理、计费结算、IoT 接入和远程控表，比较适合拿来练习业务理解、架构判断和工程评审能力。欢迎 Star 和交流。