最近在大量使用 AI Coding 的时候，我越来越明显地遇到一个问题：
AI 能把功能写出来，但它写出来的代码，往往不是“团队真正想要的代码”。
而且项目一旦复杂起来，这个问题会被迅速放大。
最开始可能只是一些小问题：
- Controller、Service 分层不符合项目约定；
- 明明项目用了 Lombok，AI 还是手写 Getter、Setter；
- 关键逻辑没有注释；
- 日志随手写，内容不统一；
- 异常和日志默认都是英文；
- 长业务链路没有 TraceId；
- 已有公共能力不用，又重新实现一套。
单看一段代码，好像都不算大问题。
但当 AI 一次改几十个文件、项目里又有很多表、很多接口、很多业务流程以后，情况就完全不一样了。
一个很简单的例子
假设做一个订单系统。
正常情况下，我们可能约定：
Controller
↓
Service
↓
Repository
日志统一使用中文，入口有 TraceId，DTO 使用 Lombok，异常走统一处理。
但如果只告诉 AI：
“增加一个订单退款功能。”
它很可能会：
- 在 Controller 里直接写业务逻辑；
- 新建一个和现有能力重复的工具类；
- 打几条
Process success之类的日志； - 自己重新定义异常；
- 顺手再增加几个类。
功能可能真的能跑。
但连续做十几个需求以后，项目会慢慢变成：
代码很多，但没人真正知道它为什么这样设计。
我现在觉得真正的问题有两层
第一层：AI 不知道团队的工程规范
AI 默认追求的是：
“把这个需求实现出来。”
但团队真正关心的是：
“用我们项目自己的方式实现出来。”
这些规范很多都藏在老代码和工程师经验里。
所以仅仅靠一句：
“请按照项目规范开发。”
其实远远不够。
第二层：项目复杂以后，人开始失去控制
这个问题我现在觉得更加严重。
项目小的时候，AI 改几个文件，我还能逐行 Review。
但项目越来越大以后：
- 几百个类；
- 大量数据库表；
- 很多接口；
- 多个业务流程；
- AI 一次修改几十个文件。
这时候再问：
“这次到底改了什么？”
很多时候连人自己都讲不清楚。
代码开始变成一个黑盒。
最危险的不是 AI 写错一行代码，而是：
人已经不知道 AI 到底在系统里做了什么。
如果这种状态持续下去，项目虽然一直有新代码产生，但工程师实际上已经逐渐失去了系统的 Ownership。
那应该怎么办？
这个问题我现在也没有一个百分之百确定的答案。
但我目前比较倾向于从四个方向尝试。
1. 把团队规则显式化
例如用项目级规则告诉 AI：
- 分层怎么做；
- 日志怎么写；
- 异常怎么处理；
- 是否使用 Lombok；
- 哪些模块不能互相调用。
至少先解决“AI 根本不知道规则”的问题。
2. 给 AI 一个标准实现作为 Reference
相比写很多文字规则，我越来越觉得：
一份好的示例代码，可能比十条 Prompt 更有效。
让 AI 新增功能时优先参考项目里已经写得比较好的模块。
3. 能自动约束的，不依赖 AI 自觉
比如：
- TraceId 用 MDC 和日志格式统一注入；
- 异常用全局异常处理；
- 分层依赖用 ArchUnit 检查；
- 代码规范用 Checkstyle / PMD / SpotBugs 检查。
目标是：
AI 写错了，也能够被自动发现。
4. 解决“代码黑盒”问题
这个我觉得可能是接下来最值得研究的。
AI 每次修改代码以后，不只是告诉我：
“任务完成。”
而是应该同时给出一份可审计的变更说明：
这次改了哪些模块？
为什么改？
影响哪些接口？
影响哪些表？
新增了哪些状态？
有没有改变原有流程？
哪些地方存在风险？
甚至进一步自动生成：
模块关系图、调用链、数据库影响、关键 Diff、风险清单。
这样人审核的就不再是几千行代码，而是：
先审核 AI 对系统产生了什么影响，再去看关键代码。
我现在越来越觉得，这可能是大型项目使用 AI Coding 时必须补上的一层。
写在最后
AI Coding 现在已经很擅长“产生代码”。
但项目真正复杂以后，我越来越关心另外两个问题：
怎么让 AI 写出来的代码符合团队的工程规范？
以及：
怎么保证代码越来越多以后，人依然知道系统里面发生了什么？
前一个问题是规范。
后一个问题是控制。
如果这两个问题解决不了，AI 写代码越快，项目反而可能越容易失控。
所以我现在越来越觉得：
AI Coding 下一阶段真正需要解决的，不只是代码生成效率，而是工程治理和可审计性。
