当 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 就帮你搞定了。

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

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

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

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

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

举几个例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

技能退化的具体表现

能力	退化表现	AI 加剧的因素
代码理解	看别人代码像天书	AI 生成代码，你从没通读过
调试能力	报错只会问 AI	失去了自己推理的机会
架构思维	只会调用接口不会设计	AI 替你做了设计决策
代码审查	扫一眼就过	觉得 AI 写的肯定没问题
阅读文档	懒得看，直接问 AI	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. 认知债务：系统越来越复杂，团队理解跟不上，AI 加速了这个过程
2. 技能退化：过度依赖编码代理，会让调试、问题分解、代码理解能力钝化
3. 供应商锁定：依赖特定 AI 平台，会失去技术自主性
4. 知行分离：只求结果不求理解，最终沦为工具的奴仆

我自己的建议很简单：

把 AI 当成 "高级代码审查员" 和 "快速原型工具"，而不是 "主开发引擎"。

先用脑子想清楚要做什么，再让 AI 帮忙写骨架，最后自己填血肉、理逻辑。

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

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

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

---

📚️参考文档

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