一、那个确定的年代
做过 Java 后端开发的人大概都有这样的记忆：定义好数据库表结构，配好 MyBatis Generator 或 JPA，一键生成 Entity、DAO、Service、Controller，增删改查代码整整齐齐地躺在项目里。这些代码是公式化 的，是确定的------同样的输入，永远产出同样的输出，不会多一行，也不会少一行。
剩下的事情就是写业务逻辑。每一行代码都经过自己的手，每一个 if-else 都在脑子里跑过，改了又改，Review 了又 Review。你对整个系统有一种掌控感------哪个接口做了什么，哪个字段可能为空，哪个边界需要兜底，心里一清二楚。
这种掌控感，就是程序员的安全感。
二、快，但不安
然后 AI 来了。
你描述一段需求，几分钟之后，几百行代码就生成了。功能能跑，逻辑大致正确，甚至还帮你写好了注释。效率提升是肉眼可见的------过去半天的工作量，现在一杯咖啡的时间就完成了。
但伴随这种速度而来的，是一种挥之不去的不安感。
这种不安来自三个地方：
第一，你不再是代码的"经历者"。 以前写代码是一个思考的过程：先想数据怎么流转，再想异常怎么处理，最后落笔成代码。每一行代码都是思考的产物。现在你是"需求描述者"，代码是别人（AI）写的，你和代码之间隔了一层。你读它，但你没有"经历"它。
第二，你不清楚 AI 的决策依据。 为什么用这个数据结构？为什么这样组织代码？当初自己写的时候，每个选择都有理由。AI 的代码虽然能工作，但背后的"为什么"是模糊的。
第三，也是最实际的问题------边界处理的缺失。 AI 擅长生成"主干逻辑"，也就是 Happy Path。但真实的生产环境，90% 的 Bug 藏在那些边界里：空值怎么办？并发怎么办？超时怎么办？数据不一致怎么办？这些 AI 往往不会在第一次生成时就考虑周全，因为你的需求描述里也很少会提到这些。
这就形成了一个悖论：AI 让你写代码更快了，但也让你对代码更不放心了。
三、本质：掌控感的迁移
仔细想想，这种焦虑的本质并不是"AI 写的代码不好"，而是掌控感从"写代码"转移到了"审代码"。
过去，掌控感来自于：我写的，我清楚。 现在，掌控感需要来自于：我审的，我理解，我确认。
这是一次角色转换。你从"代码的作者"变成了"代码的架构师 + 审查者"。这个角色其实对能力的要求不是降低了，而是提高了------你需要能快速阅读代码、判断质量、发现隐患，而不仅仅是能写出来。
接受这个转变，是用好 AI 写代码的第一步。
四、如何更好地利用 AI 写出可靠的代码
以下是我在实践中总结的几条方法，帮助在效率和掌控感之间找到平衡。
1. 先设计，再让 AI 动手
不要一上来就把整个需求甩给 AI。先自己做好设计：
- 数据模型是什么？
- 核心流程是什么？
- 模块怎么拆分？
- 接口契约是什么？
把设计结果作为约束条件喂给 AI。AI 在明确约束下生成的代码，质量远高于"你帮我实现一个 XXX 功能"。
你负责"做什么"和"怎么做的骨架"，AI 负责"具体实现"。
2. 小步生成，逐段审查
不要让 AI 一次性生成整个模块。把任务拆细：
- 先生成数据层
- 再生成业务逻辑
- 最后生成接口层
每生成一段，就读一遍、跑一遍。发现问题立即修正，不要累积。这样你对每一层代码都有清晰的认知，和自己写的区别就只是"手速更快了"。
3. 主动要求边界处理
AI 不主动考虑边界，那你就主动提。在需求描述中显式列出：
- 参数为空时如何处理？
- 数据不存在时返回什么？
- 并发场景下是否需要加锁？
- 接口超时的兜底策略是什么？
- 数据量大时是否需要分页？
把边界条件当作需求的一部分告诉 AI，而不是期待它自己想到。你对业务的理解，才是代码质量的真正护城河。
4. 让 AI 先写测试
一个被低估的用法：让 AI 先根据需求生成测试用例，再去实现代码。
测试用例本身就是对需求的精确描述------输入是什么、输出是什么、异常情况怎么处理。有了测试，你就有了一张"安全网"。后续不管是 AI 重新生成代码还是你手动修改，跑一遍测试就知道有没有问题。
5. 建立自己的 Prompt 模板
好的 Prompt 是可以复用的。针对常见场景，沉淀出自己的模板：
markdown
## 需求
[功能描述]
## 技术约束
- 使用的框架/语言版本
- 需要遵循的项目规范
- 依赖的已有模块和接口
## 边界与异常
- [列出需要处理的边界情况]
## 期望输出
- 代码结构要求
- 命名规范
- 是否需要注释好的模板能让 AI 的输出更稳定、更可预期，减少来回修改的次数。
6. 把 AI 当作"初级开发"来做 Code Review
生成的代码一定要 Review，而且要带着"这是别人写的代码"的心态去审查。重点关注：
- 有没有遗漏的异常处理？
- SQL 有没有注入风险？
- 敏感数据有没有脱敏？
- 有没有硬编码的魔法值？
- 资源（连接、流）有没有正确关闭？
AI 是你的"高效初级开发"，但它不是高级工程师。审查的责任在你身上。
7. 保持"手感"
不要完全放弃手写代码。核心业务逻辑、关键算法、安全相关的代码，建议亲手写或者至少亲手改。保持对代码的"手感"，才能在 Review 时更敏锐地发现问题。
一个完全不写代码的人，很难审好代码。
五、写在最后
AI 不会取代程序员，但会取代不会用 AI 的程序员------这句话说了太多遍，但它隐含了一个容易被忽略的前提：会用 AI，不是指会打字描述需求，而是指能驾驭 AI 产出的代码。
驾驭的前提是理解，理解的前提是能力。
所以在 AI 时代，程序员的核心能力反而回归到了最本质的东西：对业务的深入理解、对系统设计的全局把控、对代码质量的敏锐判断。 这些从来都不是靠工具能替代的。
那种不安感，其实是一个好的信号------它说明你在意代码的质量，在意系统的可靠性，在意自己作为工程师的专业性。
不要消灭这种不安，而是把它转化为更好的工程实践。
用 AI 的速度，配上你的判断力。这才是 AI 时代程序员最好的工作方式。