当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提出的"认知债务"概念，通俗点说就是：系统结构演进的速度，超过了团队对其理解的速度。
举几个例子：
- 一个配置改了三轮：一开始是ConfigMap，后来改成 Helm Chart，最后又套了一层 ArgoCD Application。每个开发阶段都有人改过，但没有人把整个演进过程记录下来。
- AI生成的代码没人review：Claude Code自动生成了几十个YAML文件，团队可能就扫一眼能不能跑，根本没人细看每个字段的含义。
- 依赖关系成谜：某个微服务莫名其妙引了一堆过期版本的库，没人知道为什么——因为那是AI几个月前根据某个旧文档生成的。
📝Notes: 认知债务和"技术债务"不一样。技术债务是你明知该重构但没时间做，认知债务是你连"还有这笔债"都不知道。
AI在这里扮演了什么角色？它让系统的"黑盒化"加速了。
以前写代码需要手动查文档、理解函数、调试错误。这个过程很痛苦，但也是在加深你对系统的理解。现在AI帮你跳过了这个过程——你只知道它能跑，但不知道为什么能跑。
开发技能退化：你正在失去的不只是编码能力
Lars Faye的警告更直接——代理编码（Agentic Coding）正在让开发者的技能退化。
我不是在危言耸听。看看你最近的工作流：
- 调试能力下降：以前报错了第一反应是看日志、查堆栈、分析原因。现在第一反应是把错误信息复制粘贴给AI，让它告诉我怎么办。
- 问题分解能力退化：以前遇到复杂问题会自己拆解成子任务。现在直接告诉AI"帮我写个功能"，AI帮你分解了，但你失去了分解的练习机会。
- 供应商锁定抬头：常用的是哪个AI？ChatGPT？Claude？Gemini？如果某天服务被禁用(诶? Claude 是不是已经这么干了?)，你的工作流能正常运转吗？
说个我自己的亲身经历。上个月排查一个Grafana面板渲染慢的问题，搁以前我会：
- 看Grafana的慢查询日志
- 分析Prometheus的查询耗时
- 检查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服务商上。不只是工具本身，还包括：
- 你的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辅助编码不是末日，但我们需要清醒地认识到：
- 认知债务：系统越来越复杂，团队理解跟不上，AI加速了这个过程
- 技能退化：过度依赖编码代理，会让调试、问题分解、代码理解能力钝化
- 供应商锁定：依赖特定AI平台，会失去技术自主性
- 知行分离：只求结果不求理解，最终沦为工具的奴仆
我自己的建议很简单：
把AI当成"高级代码审查员"和"快速原型工具"，而不是"主开发引擎"。
先用脑子想清楚要做什么，再让AI帮忙写骨架，最后自己填血肉、理逻辑。
毕竟，这个行业最大的护城河从来不是你会用多先进的工具，而是你对系统、对代码、对业务的深度理解。
不要像那句老话说的：好AI, 不求甚解。
我们得知道自己应该在哪个方向前行。