AI写代码虽爽，但代价是什么？

字数 2337，阅读大约需 12 分钟

近期读了两篇关于AI开发误区的文章，觉得有必要分享一些看法。作为每天与DeepSeek、Claude Code打交道的运维工程师，我觉得不说点什么实在过意不去。

先声明：这篇文章并非全盘否定AI编码工具，而是想探讨一个关键问题——我们在追求"一键搞定"的快感之后，到底失去了什么。

先聊聊我的日常工作。作为PaaS架构师，我的工作流程中AI辅助无处不在：

不可否认，效率提升是实实在在的。以前编写Kubernetes Helm Chart需要翻阅大量文档，现在只需输入几个关键词，AI就能帮你搞定。

但最近我注意到一个现象：我对自己编写的代码的理解程度越来越低。

举个例子：上周编写Prometheus Operator的告警规则时，Claude Code生成了一堆看似正确的YAML配置，部署后也确实正常运行。但当生产环境出现告警需要调整阈值时，我却对着那堆规则不知所措——这是谁写的？为何这样设计？这个值为什么是这个数字？

绕了这么大一圈，其实核心问题只有一个。

Margaret Storey提出的"认知债务"概念，简单来说就是：系统架构演进的速度，超过了团队对其理解的速度。

举几个具体例子：

📝Notes: 认知债务与"技术债务"有本质区别。技术债务是你清楚应该重构但没时间做，认知债务是你根本不知道"还有这笔债"存在。

AI在这里扮演了什么角色？它加速了系统的"黑盒化"进程。

过去写代码需要手动查阅文档、理解函数、调试错误。这个过程虽然痛苦，但也是加深对系统理解的关键环节。现在AI帮你跳过了这些步骤——你只知道它能运行，却不明白为什么能运行。

Lars Faye的警告更为直白——代理编码（Agentic Coding）正在导致开发者的技能退化。

我并非在危言耸听。审视一下你最近的工作流程：

说说我自己的真实经历。上个月排查一个Grafana面板渲染缓慢的问题，以前我会：

但那天因为时间紧迫，我直接问AI："Grafana面板渲染慢，怎么解决？"

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，不求甚解。

我们得知道自己应该在哪个方向前行。

[1]What I’m Hearing About Cognitive Debt (So Far) - Margaret Storey:https://margaretstorey.com/blog/2026/02/18/cognitive-debt-revisited/ [2]Agentic Coding is a Trap - Lars Faye:https://larsfaye.com/articles/agentic-coding-is-a-trap