最近看到两篇关于AI开发陷阱的文章，觉得不写点啥对不起自己也是天天跟 DeepSeek、Claude Code 打交道的运维老狗。
先声明一下：这玩意儿不是要全盘否定AI编码，而是想探讨一下——我们在"一把梭"爽完之后，到底付出了什么代价。
先说说我的日常。作为PaaS架构师，我每天的工作流里充满了AI辅助：
说实话，效率提升是肉眼可见的。以前写个Kubernetes Helm Chart可能要翻半天文档，现在敲几个字AI就帮你搞定了。
但最近我发现一个问题：我越来越看不懂自己写的代码了。
比如上周写一个Prometheus Operator的告警规则， Claude Code 帮我生成了一堆看起来很对的YAML，部署上去也确实work了。但当生产环境出告警需要调整阈值时，我却对着那堆规则发懵——这是谁写的？为什么要这么写？为什么设成这个值？
好了，绕这么大圈子，其实就想说一件事。
Margaret Storey提出的"认知债务"概念，通俗点说就是：系统结构演进的速度，超过了团队对其理解的速度。
举几个例子：
📝Notes: 认知债务和"技术债务"不一样。技术债务是你明知该重构但没时间做，认知债务是你连"还有这笔债"都不知道。
AI在这里扮演了什么角色？它让系统的"黑盒化"加速了。
以前写代码需要手动查文档、理解函数、调试错误。这个过程很痛苦，但也是在加深你对系统的理解。现在AI帮你跳过了这个过程——你只知道它能跑，但不知道为什么能跑。
Lars Faye的警告更直接——代理编码（Agentic Coding）正在让开发者的技能退化。
我不是在危言耸听。看看你最近的工作流：
说个我自己的亲身经历。上个月排查一个Grafana面板渲染慢的问题，搁以前我会：
但那天因为赶时间，我直接问AI："Grafana面板渲染慢，咋整？"
AI给了我七八条建议，我挨个试了一遍，最后确实好了。但搞完之后我完全不知道真正的问题出在哪里。下一次再遇到类似问题，我还是得复制粘贴。
🤔 细思极恐。如果再这样依赖下去，五年后我还能独立排查一个复杂问题吗？
| 能力 | 退化表现 | AI加剧的因素 |
|---|---|---|
| 代码理解 | 看别人代码像天书 | AI生成代码，你从没通读过 |
| 调试能力 | 报错只会问AI | 失去了自己推理的机会 |
| 架构思维 | 只会调用接口不会设计 | AI替你做了设计决策 |
| 代码审查 | 扫一眼就过 | 觉得AI写的肯定没问题 |
| 阅读文档 | 懒得看，直接问AI | AI总结了核心内容 |
这里要特别说说Agentic Coding —— 也就是Claude Code这类能自动规划、执行、调试的编码代理。
这玩意儿确实很强。比如我要部署一套Kubernetes集群，以前得手动配各种参数，现在跟Claude Code说"帮我部署一个K3s集群，网络用Cilium，存储用rook-ceph, 监控用prometheus-stack"，它就能全程帮我搞定。
但是问题来了：
你所有的"能力"都绑定在了某个AI服务商上。不只是工具本身，还包括：
AI看起来很香, 比人力便宜，但代价是什么？
这才是最要命的。
借用王阳明心学的视角——AI替你做了"行"（生成代码），但你失去了"知"（对代码的理解）。知行分离意味着你永远无法真正掌握技术。
打个比喻：就像你请了个私人教练帮你完成每一次卧推，你就负责在旁边看着, 看过就是练过. 你自己从来没感受过胸肌发力。表面上看你"完成了训练"，但实际上肌肉从来没增长过。
我不是说回到石器时代。AI用得好是神兵利器，用得不好就是精神成瘾。
这里分享几个我自己的实践，供参考：
这个原则适用所有AI生成的代码：
不是所有任务都适合交给AI：
我自己每隔几天几周会强制自己：
认知债务不是一个人的问题。团队层面：
王阳明说"知行合一"，放到技术语境就是：
AI辅助编码不是末日，但我们需要清醒地认识到：
我自己的建议很简单：
把AI当成"高级代码审查员"和"快速原型工具"，而不是"主开发引擎"。
先用脑子想清楚要做什么，再让AI帮忙写骨架，最后自己填血肉、理逻辑。
毕竟，这个行业最大的护城河从来不是你会用多先进的工具，而是你对系统、对代码、对业务的深度理解。
不要像那句老话说的：好AI, 不求甚解。
我们得知道自己应该在哪个方向前行。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。