AI 写代码, 脑子却空了

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

当AI成为依赖：认知债务与技能退化的隐忧

最近看到两篇关于AI开发陷阱的文章，觉得不写点啥对不起自己也是天天跟 DeepSeek、Claude Code 打交道的运维老狗。

先声明一下：这玩意儿不是要全盘否定AI编码，而是想探讨一下——我们在"一把梭"爽完之后，到底付出了什么代价。

背景

先说说我的日常。作为PaaS架构师，我每天的工作流里充满了AI辅助：

• • 用 Claude Code写Helm Chart
• • 让Claude Code 根据 KRR 生成资源优化后的 YAML
• • 甚至排查Pod CrashLoopBackOff时也会让 Grafana AI Assistant, HolmesGPT 分析 Metrics/Logs/Events/Tracings

说实话，效率提升是肉眼可见的。以前写个Kubernetes Helm Chart可能要翻半天文档，现在敲几个字AI就帮你搞定了。

不, 谢谢, 我用AI

不, 谢谢, 我用AI

但最近我发现一个问题：我越来越看不懂自己写的代码了。

比如上周写一个Prometheus Operator的告警规则， Claude Code 帮我生成了一堆看起来很对的YAML，部署上去也确实work了。但当生产环境出告警需要调整阈值时，我却对着那堆规则发懵——这是谁写的？为什么要这么写？为什么设成这个值？

好了，绕这么大圈子，其实就想说一件事。

认知债务：系统变复杂了，你的理解还停留在原地

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

举几个例子：

1. 1. 一个配置改了三轮：一开始是ConfigMap，后来改成 Helm Chart，最后又套了一层 ArgoCD Application。每个开发阶段都有人改过，但没有人把整个演进过程记录下来。
2. 2. AI生成的代码没人review：Claude Code自动生成了几十个YAML文件，团队可能就扫一眼能不能跑，根本没人细看每个字段的含义。
3. 3. 依赖关系成谜：某个微服务莫名其妙引了一堆过期版本的库，没人知道为什么——因为那是AI几个月前根据某个旧文档生成的。

📝Notes: 认知债务和"技术债务"不一样。技术债务是你明知该重构但没时间做，认知债务是你连"还有这笔债"都不知道。

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

以前写代码需要手动查文档、理解函数、调试错误。这个过程很痛苦，但也是在加深你对系统的理解。现在AI帮你跳过了这个过程——你只知道它能跑，但不知道为什么能跑。

开发技能退化：你正在失去的不只是编码能力

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

我不是在危言耸听。看看你最近的工作流：

• • 调试能力下降：以前报错了第一反应是看日志、查堆栈、分析原因。现在第一反应是把错误信息复制粘贴给AI，让它告诉我怎么办。
• • 问题分解能力退化：以前遇到复杂问题会自己拆解成子任务。现在直接告诉AI"帮我写个功能"，AI帮你分解了，但你失去了分解的练习机会。
• • 供应商锁定抬头：常用的是哪个AI？ChatGPT？Claude？Gemini？如果某天服务被禁用(诶? Claude 是不是已经这么干了?)，你的工作流能正常运转吗？

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

1. 1. 看Grafana的慢查询日志
2. 2. 分析Prometheus的查询耗时
3. 3. 检查Grafana的缓存策略
4. 4. 逐步优化

但那天因为赶时间，我直接问AI："Grafana面板渲染慢，咋整？"

AI给了我七八条建议，我挨个试了一遍，最后确实好了。但搞完之后我完全不知道真正的问题出在哪里。下一次再遇到类似问题，我还是得复制粘贴。

🤔 细思极恐。如果再这样依赖下去，五年后我还能独立排查一个复杂问题吗？

技能退化的具体表现

代理编码的陷阱：从工具到依赖

这里要特别说说Agentic Coding —— 也就是Claude Code这类能自动规划、执行、调试的编码代理。

这玩意儿确实很强。比如我要部署一套Kubernetes集群，以前得手动配各种参数，现在跟Claude Code说"帮我部署一个K3s集群，网络用Cilium，存储用rook-ceph, 监控用prometheus-stack"，它就能全程帮我搞定。

但是问题来了：

陷阱一：供应商依赖

你所有的"能力"都绑定在了某个AI服务商上。不只是工具本身，还包括：

• • 你的prompt习惯
• • 对特定AI输出格式的依赖
• • 有时候AI改了一个小行为，你的整个工作流就崩了

陷阱二：隐性成本

AI看起来很香, 比人力便宜，但代价是什么？

• • 时间成本：AI给出的东西不对，你得花更多时间debug
• • 认知成本：为了适应AI的非确定性输出，你得增加额外的检查逻辑和上下文
• • 学习成本：当AI的某个特性过时了，你得重新适应

陷阱三：知行分离

这才是最要命的。

借用王阳明心学的视角——AI替你做了"行"（生成代码），但你失去了"知"（对代码的理解）。知行分离意味着你永远无法真正掌握技术。

打个比喻：就像你请了个私人教练帮你完成每一次卧推，你就负责在旁边看着, 看过就是练过. 你自己从来没感受过胸肌发力。表面上看你"完成了训练"，但实际上肌肉从来没增长过。

如何避免被AI架空？

我不是说回到石器时代。AI用得好是神兵利器，用得不好就是精神成瘾。

这里分享几个我自己的实践，供参考：

1. 先理解，再使用

这个原则适用所有AI生成的代码：

• • 让AI生成代码后，通读一遍，确认每个字段的含义
• • 加注释不是只为了给别人看，更是为了逼自己去理解
• • 复杂的YAML（比如Prometheus Operator的CRD），分段理解后再组装

2. 给AI设边界

不是所有任务都适合交给AI：

• • ✅ 适合：样板代码、文档生成、简单查询、快速原型
• • ❌️ 不适合：核心逻辑的架构设计、安全敏感的配置、复杂调试

3. 主动做"无工具"练习

我自己每隔几天几周会强制自己：

• • 不用Copilot写超过50行代码
• • 遇到bug先自己推理15分钟，再问AI验证思路
• • 定期review AI生成代码的历史提交，搞清楚它的"意图"

4. 建立团队的知识机制

认知债务不是一个人的问题。团队层面：

• • ✅ 所有AI生成的代码都要被review
• • ✅ 关键决策要写ADR（架构决策记录）
• • ❌ 不要让AI做的改动变成"who改的"的悬案

5. 识别"真的懂了"和"假装懂了"

王阳明说"知行合一"，放到技术语境就是：

• • "懂了"意味着能独立写出和解释代码
• • "假装懂了"意味着只有AI能生成，你自己改了反而跑不通

最后唠叨几句

AI辅助编码不是末日，但我们需要清醒地认识到：

1. 1. 认知债务：系统越来越复杂，团队理解跟不上，AI加速了这个过程
2. 2. 技能退化：过度依赖编码代理，会让调试、问题分解、代码理解能力钝化
3. 3. 供应商锁定：依赖特定AI平台，会失去技术自主性
4. 4. 知行分离：只求结果不求理解，最终沦为工具的奴仆

我自己的建议很简单：

把AI当成"高级代码审查员"和"快速原型工具"，而不是"主开发引擎"。 先用脑子想清楚要做什么，再让AI帮忙写骨架，最后自己填血肉、理逻辑。

毕竟，这个行业最大的护城河从来不是你会用多先进的工具，而是你对系统、对代码、对业务的深度理解。

不要像那句老话说的：好AI, 不求甚解。

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

📚️参考文档

• • What I’m Hearing About Cognitive Debt (So Far) - Margaret Storey[1]
• • Agentic Coding is a Trap - Lars Faye[2]

引用链接

[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