你好，我是方可乐。
一个从Java开发成功转型，聚焦 AI 编程、AI 应用和智能体开发的 AI 应用开发工程师。
今年挺多Java开发的同学转型 AI 应用开发。
不少代码都是AI写的，甚至100% AI。
毕竟2026年8月了，谁还没习惯用AI写代码呢？
不少人有这样的疑问：公司能接受吗？
前两天AI 成长圈一个从 Java 转行的圈友，学 RAG，他当前的代码全是 AI 写的。
他的想法是，优先把功能做出来，跑通demo，跑通场景。
代码都是AI写的，基本上没看过。而且AI写的代码和原本自己的编码风格不太一样，也有点难读。
我的观点是，功能可以AI设计，代码可以AI写，但大方向和原理得自己把握。源码至少看一遍，因为demo 代码和生产代码差异很大。
demo的坑没踩透，到了真实生产场景，需要用更大的代价补回来。
刚好我最近面了不少 AI 应用开发的候选人，正好聊聊公司视角怎么看这件事。
有个候选人，三年经验，简历上写着熟练使用 Claude Code 做 AI Coding。
我问他：团队有没有沉淀什么 AI 编码规范？
他想了有二十来秒，最后说"没整太多，具体细节不记得了"。
三年了，团队用 AI 写代码，但没有成型的 Spec、没有稳定的 Rule、没有专门针对AI的测试、没有失败复盘。最终稳定性靠人工测试和代码 Review 兜底。
这就是问题所在。
AI 编程看起来让团队无所不能，但如果没有人把"AI 写出来的代码怎么验收"沉淀成方法，AI 只是在放大团队的混乱。
公司不怕你用 AI 写代码。
公司怕的是你用了，但说不清怎么验收。
另一个候选人就完全不一样。
他也是 AI 写代码，但有一套自己的约束流程。
先确定技术栈和项目规则，再让 Agent 把模糊想法展开成需求文档。
生成完以后自己 Review，删掉过度设计，让 Agent 针对不清楚的地方继续提问，逐步收敛成执行计划。
每个 Agent 只负责明确范围，按分支推进，阶段性 Git Commit 保留可回滚的开发过程。
他不是不让 AI 写，是给 AI 划了边界。
这两个人放在一起，使用AI的水平差别就很明显。
用 AI 的写代码，如何做好工程约束？这是一个绕不开的课题。
回到开头那个问题：AI写的功能，源码值不值得看一遍？
写demo的时候，更应该看。
不是因为你比 AI 写得好，是因为 demo 代码和生产代码的差异很大。
AI 能帮你快速跑通一个 demo，检索能出结果，对话能接上，看起来就差上线了。
但生产环境要处理的是：脏数据怎么办，边界条件漏了怎么办，并发的时候向量库顶不顶得住，召回质量怎么评估，出了问题能不能定位到哪一段。
这些东西，你不看源码、不懂原理，根本不知道风险在哪。
面试的时候，不是在考你会不会用工具。
而是在判断：你如何对AI交出去的代码负责。
工具名单不是能力证明。
你怎么用它，怎么约束它，它翻车以后你留下了什么，才是。
所以如果你正在从 Java 或者其他传统开发转 AI。
我的建议是：
工作上可以用 AI 写代码，是要建立"AI 写、人审、沉淀"的闭环。
至少做到三件事：
源码看过一遍，知道 AI 在哪翻过车，翻车以后留下了什么
——是 Rule、是测试、还是一条规范。
公司能接受的不是"AI 写的代码"。
是你负责过的 AI 写的代码。