AI 生成的代码，已经超出了我的认知边界。
大家好，我是十三！欢迎来到十三Tech。
AI 帮我完成了大部分编码工作，但前段时间发生的一件事让我警觉。AI 给我的前端工程能完美运行，可我看不懂里面的代码。我想加一个小功能——用户滚动到底部时自动加载下一页——却在它生成的代码里找不到该改哪儿。useEffect、useState、useCallback、memo 这些 Hooks 摆在面前：我不理解组件的渲染周期，不清楚状态怎么通过 props 流动，也不知道列表渲染背后 key 的作用和虚拟 DOM 的 diff 逻辑。
对着这个「完美」的工程，我感觉像个文盲。AI 给了我结果，却没给我理解过程的机会。
最危险的信号就在这里：AI 生成的代码，超出了我的认知边界。
认知惰性：只求结果，不问过程
AI 带来的效率提升，有个隐藏代价。我们只要描述问题，就能马上拿到一个「能用」的方案，于是很容易滑进一个陷阱：只求结果，不问过程。
时间一长，它会养成工程师最致命的习惯——认知惰性：
- 懒得想有没有更优解法，因为「AI 给的也还行」。
- 懒得究背后的原理，因为「反正能跑」。
- 懒得系统学一个新领域，因为 AI 让人产生「我好像什么都会」的错觉。
烂代码可以重构，但思维上的惰性一旦形成，很难逆转。
当 AI 的输出超出你的认知
和 AI 协作，最该警惕的信号是：你开始看不懂它生成的代码。
这不是「技术不好」的问题，而是你正在失去对这段代码的控制权。后果很直接：
1. 无法维护。 代码在你仓库里，但你不是它的主人。一个简单的需求变更——比如给列表加个「加载中」动画——都可能变成灾难，因为你不知道该在哪个组件的哪个 Hook 里改状态。
2. 无法调试。 这段黑盒代码在线上偶发崩溃时，你会束手无策。你没法用 debugger 跟踪一条自己都不理解的数据流，也看不懂 React 抛出的错误栈。
3. 无法负责。 工程师要为自己写的每一行代码负责，但你没法对一个自己都不理解的东西负责。用户问「这个页面为什么这么卡」，你总不能回答「这是 AI 写的，我也不知道」。
到这一步，你就只是代码的搬运工，而不是这个系统的工程师了。
怎么守住认知主权
吃了一次亏，我重新想了想和 AI 协作的姿势。核心只有一条：你得永远是那个能为结果兜底的人。
具体三个做法：
1. 把 AI 当陪审员，而不是法官。 AI 可以提供证据、分析案情、给出建议，但敲下法槌的人必须是你——你对方案有最终的理解权和采纳权。下次遇到不熟悉的东西，我会反过来考它：
你用 React Hooks 实现了这个功能。现在跟我解释一下，
useEffect和useCallback在这里的区别，以及为什么这里要用useCallback做性能优化。
把 AI 当成 24 小时随叫随到的老师，而不是一个你盲从的权威。
2. 看不懂就问到底。 遇到不懂的代码，别放过，那是拓展认知边界的最好时机。一句很好用的咒语是「给我解释一下」：
- 给我解释一下 React 的
key在 diff 算法里到底起什么作用。 - 给我解释一下这段代码为什么需要用
memo包起来。 - 给我解释一下 Zustand 和 Redux 的设计哲学有什么不同。
问得越深，AI 的回答越有价值，你的认知边界也扩得越快。
3. 刻意练习，别让「核心肌群」萎缩。 AI 能帮你处理大部分日常工作，但省下来的时间，得投到那 10% 最核心、最吃功夫的练习上。每周留一两个小时，关掉所有 AI 助手：用原生 API 从零实现一个功能，啃一个一直想学没时间学的硬骨头，或者挑一个常用库去读它的源码。就像健身练核心——真到了要你出手解决复杂问题时，你才不会发现自己的肌肉早就萎缩了。
写在最后
AI 时代最危险的陷阱，不是工具替代人，而是人主动放弃了思考：
- 认知惰性：只求结果、不问过程，是最致命的习惯。
- 失控信号：看不懂 AI 生成的代码，就是控制权流失的警报。
- 守住主权：把 AI 当陪审员而非法官，保持手写核心代码的习惯，定期做「无 AI」训练。
真正淘汰程序员的从来不是 AI，而是我们在技术面前那颗不再敬畏、不再好奇、也停止了思考的心。AI 是程序员的杠杆，但杠杆的支点，永远是你的认知深度。
关于十三 Tech
资深服务端研发工程师，AI 编程实践者。专注分享真实的技术实践经验，相信 AI 是程序员的最佳搭档。
