一、AI 带来的变化
这一年用 AI 写代码，说实话并不是一开始就这么顺的，最早接触的时候对它的期待也不高；
更多只是把它当成一个比搜索引擎反应快一点的工具
做一个接口
最开始的应用基本是在网页或者桌面对话框里进行工作，做的事情基本围绕：
- 给定字段生成 model
- 生成一个方法逻辑
- 完成官方库一些 API 检索
因为是通过外部工具完成生成然后粘贴到工程，因此这种改动范围很小，就算生成存在问题也能人工识别进行修正；
所以当前阶段本质上还是人为主导，AI 只是完成一些琐碎工作
但问题也很明显， 整体很考究提词并且有时上下文沟通没有关联性输出信息很零碎
大部分时间需要反复提醒上下文，才能把一件小事做完
结构设计
真正让我感觉不一样，是后来把 Trae 和 ChatGPT agent 结合使用；
AI 不再只是补代码，而是开始直接给我一整套结构：
目录怎么分、模块怎么拆、代码应该放在哪一层。
这时候，我问的问题也变了。不再是“这段代码怎么写”， 而是“这个功能如果以后要维护，现在这样合不合理”。
虽然输出还谈不上多成熟，但我能明显感觉到：
AI 已经不只是执行者了，而是在参与决策。
再往后：新技术和重复劳动，被我直接交给了它
再后来，有两个场景我用 AI 用得特别多。
学新技术
遇到不熟的技术栈，我已经很少从头啃文档了，而是先让 AI 给我跑一个最小可用的例子出来；
我不指望它一步到位，但这个例子至少能让我快速知道：
这个东西大概是怎么组织的，有没有明显坑点。
日常那些特别消耗耐心的重复工作
比如对象声明、序列化反序列化、各种样板代码，这些活不难，但写多了真的很烦； 在这一类事情上，我已经基本不自己动手了，不是因为我不会写，而是没必要；
慢慢地，我对 AI 的感觉也变了，它不再只是一个工具，更像是
随时可以调度的 “超级工厂”
慢慢的不再是逐行完成代码，而是完成方案，审视结构，运行逻辑
二、Agent 的使用
说实话，真正让我开始“敬畏” Agent 编程的，并不是效率提升，而是它开始变得像一套工程流程；这也是首次意识到，Agent 的价值不在于“生成代码”，而是通过上下文的约束将代码关进“笼子”；
提词到工具流
一开始用 AI 写代码，基本靠 prompt 硬提：
描述得好不好，直接决定输出能不能用
但后来明显能感觉到，AI 自己也在“工程化” 不管是 skill、工具流，还是对上下文的约束方式，本质上都在做一件事—— 减少即兴发挥，增加可控性
现在的 Agent 编程看起来突然靠谱了不少,不是它突然聪明了,而是交互方式更像工程，而不是聊天
幻觉问题
组里就出过一次因 AI 幻觉导致的P0事故。
同事在用 AI 改一个 A 文件的逻辑时，把 B 文件里相关的实现也一起“优化”了。从代码本身看，改动是合理的，逻辑也能自洽。但问题在于，B 文件的那部分逻辑不该被这个需求触碰的；
结果很直接：
一个 P0 缺陷被带到了线上。
事后复盘时大家的共识也很清楚,如果是人工改代码，大概率不会这么干。
真正危险的地方在于————不是代码写错了，而是约束失控
老项目里，AI 很容易把坑一次性放大
还有一次经历，也让我对 AI 在工程里的边界有了更清醒的认识;
当时想在一个迭代了多年的老项目里快速加功能,我对整体框架理解得并不算透，就想着先让 AI 出一版方案;
功能确实很快就跑起来了,但越往后维护，问题越多：
- 结构过重，没有以原有结构逻辑新增
- 设计过度，几乎没扩展性
- 完全无维护性，一碰就碎
最后的结果——新增功能没保住，还被迫连带着做了一次重构。
那次之后我基本形成了一个认知：
在复杂工程里，AI 会把你当前的认知水平，成倍放大
回头看，这次问题不在于 AI，而是个人未理解系统之前将权利交了出去
三、行业的变化
这两年IT行业的环境变化，其实大家都有体感——岗位变少、要求变高，带教制几乎消失，很多时候一上来就要求“能干活”。有一部分行业自身衰落的原因，也有 AI 出现对新人的影响；
AI 并没有改变工程复杂度，只是改变了谁来为复杂买单，在真实的工程环境里，AI 带来的最大变化，其实不是“写得更快”，而是 风险的承担方式发生了变化；
工程与人
对已经有工程经验的人来说，AI 更像是加速器。你大概知道什么是对的、什么是不能碰的，能节约开发周期；
但对新人来说，情况往往相反。在还没建立完整认知体系、也没真正做过设计取舍的前提下，AI 给出的“看起来很完整的方案”，反而会让人误以为问题已经被解决了；一旦业务复杂度上来，隐藏的问题会集中爆发。也是为什么在老项目里， AI 很容易把问题一次性放大————不是因为它乱写，而是它不知道什么不该写；
实践的认知
任何工具的使用，都应该建立在实践之上
很认同张文宏医生的观点——反对年轻医生过度依赖 AI 诊断不是因为 AI 不准，而是诊断能力本身需要通过大量实践建立；
软件工程也是一样，如果一个人从一开始就习惯把“理解”和“设计”外包给 AI，那么他缺失的不是代码能力，而是判断能力；在还未建立工程直觉，没踩坑之前，很难判定一些基础事实：
- 是否过度设计，可用性如何
- 当前改动对于整个系统的影响
- 后续的可维护性以及随业务迭代的可扩展性
这些判断能力，都需要亲身经历才能逐渐形成
非特定行业问题
其实不只是 IT 行业，在很多领域，培训正在被“效率”和“交付压力”挤掉；团队难以投入成本培养新人，AI 看起来给了一个看似合理的补位方案，能帮助新人短期“看起来能干活”
但从结果看，在提高效率的同时，也将很多经验化的风险责任直接暴露给新人；很多经验型风险从团队层兜底演变成个人面对，这是一个巨大的隐患；
有些认知理念需要日积月累的工程学认知积累
工程认知这块，需要在真实工程反复碰壁、反复复盘靠实践逐步积累；
工程认知这件事从来不是效率工具可以压缩的成本
四、在信息洪流找到属于自己的 Vibe Coding
回溯与 AI、Agent 打交道的一路，真正改变我的不是再只是将他作为一个“工具”，而是重新审视自己在工程领域中的 角色；
很多时候，我离不开使用他进行工作、生活，但本质上这是在不断建立并提升认知前提下才能更好使用；
构思需求，完善约束，沟通方案，执行生成；用得好他就是救命稻草，用不好就是洪水猛兽，不神话，不拒绝是最好的使用观念；所谓的 Vibe Codeing，绝不该是无脑使用 AI 输出代码，而是在理解系统，敬畏工程的前提下，拥有清晰判断力的情况下完成劳动成果；
也许 AI 带来的真的是下一次工业革命，至少对个人而言它是日常的一部分
