一、那个确定的年代
做过 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。在明确约束下生成的代码，质量远高于那种“你帮我实现一个 XXX 功能”式的对话。
你负责“做什么”和“怎么做的骨架”，AI 负责“具体实现”。
2. 小步生成，逐段审查
别让 AI 一次性生成整个模块。把任务拆细：
- 先生成数据层
- 再生成业务逻辑
- 最后生成接口层
每生成一段，就读一遍、跑一遍。发现问题立刻修正，不要累积。这样你对自己模块的每一层代码都有清晰的认知，和手写相比，区别仅仅是“手速更快了”。
3. 主动要求边界处理
AI 不主动考虑边界，那就由你来主动提。在需求描述中显式列出：
- 参数为空时如何处理？
- 数据不存在时返回什么？
- 并发场景下是否需要加锁？
- 接口超时的兜底策略是什么？
- 数据量大时是否需要分页？
把边界条件当作需求的一部分告诉 AI，而不是期待它能自己想到。你对业务的理解，才是代码质量的真正护城河。
4. 让 AI 先写测试
这个用法被严重低估了：让 AI 先根据需求生成测试用例，再去实现代码。
测试用例本身就是对需求的精确描述——输入是什么、输出是什么、异常情况怎么处理。有了测试，就等于有了一张“安全网”。后续不管是 AI 重新生成代码，还是你手动修改，跑一遍测试就能快速发现问题。
5. 建立自己的 Prompt 模板
好的 Prompt 是可以复用的。针对常见场景，把模板沉淀下来：
## 需求
[功能描述]
## 技术约束
- 使用的框架/语言版本
- 需要遵循的项目规范
- 依赖的已有模块和接口
## 边界与异常
- [列出需要处理的边界情况]
## 期望输出
- 代码结构要求
- 命名规范
- 是否需要注释
有了好的模板，AI 的输出会更稳定、更可预期，来回修改的次数自然就少了。
6. 把 AI 当作“初级开发”来做 Code Review
生成的代码必须 Review，而且要带着“这是别人写的代码”的心态去审。重点关注：
- 有没有遗漏的异常处理？
- SQL 有没有注入风险？
- 敏感数据有没有脱敏？
- 有没有硬编码的魔法值？
- 资源（连接、流）有没有正确关闭？
AI 是高效的“初级开发”，但它不是高级工程师。审查的责任，始终在你这里。
7. 保持“手感”
不建议完全放弃手写代码。核心业务逻辑、关键算法、安全相关的代码，建议亲手写，或者至少亲手改。保持对代码的“手感”，才能在 Review 时更敏锐地发现问题。
一个完全不写代码的人，很难审好代码。
五、写在最后
“AI 不会取代程序员，但会取代不会用 AI 的程序员”——这句话已经被说烂了，但它隐含了一个容易被忽略的前提：会用 AI，不是指会打字描述需求，而是指能驾驭 AI 产出的代码。
驾驭的前提是理解，理解的前提是自身的能力。
所以在 AI 时代，程序员的核心能力反而回归到了最本质的东西：对业务的深入理解、对系统设计的全局把控、对代码质量的敏锐判断。这些能力，从来不是靠什么工具能替代的。
那种不安感，其实是一个好信号——它说明你在意代码的质量，在意系统的可靠性，在意自己作为工程师的专业性。
不必急于消灭这种不安，而是学会把它转化为更好的工程实践。
用 AI 的速度，配上你自己的判断力。这才是 AI 时代程序员最好的工作方式。
