2026/9/7 19:34:03
FEATURED · 精选文章 
1. 这件事不是危言耸听而是正在发生的技能风化最近关于 Anthropic AI Coding 的讨论突然多了起来尤其是 Claude Code 这类能自己读仓库、跑测试、改文件的编程智能体出现之后团队里的效率曲线确实变得很夸张。有人告诉我“数小时内完成过去需要数周的开发工作”我看了一眼 demo确实是真的。但恰恰因为是真的我才想写一些不合群的话如果你靠 AI Coding 把活干完却没有同步升级自己的判断力那你很可能正处于职业生涯里最舒服的衰退期。先把话说清楚我不反对 AI Coding我自己也在重度使用 Claude Code。我说的是“被蒙蔽”。AI Coding 会以非常隐蔽的方式夺走你验证自己判断的机会让你以为产出变多等于能力变强结果一年后打开 IDE你发现自己已经看不懂一段 200 行的核心逻辑了。这个现象不是极少数人的问题很多有五年、十年经验的老开发同样中招只是他们不会公开承认。1.1 我先说个让我后背发凉的下午前两天我在帮一个遗留系统补自动化测试。系统很老模块之间有大量隐式依赖我先花了两小时梳理调用链然后打开 Claude Code让它按我的思路补一批关键用例。它执行得飞快收集了路由、方法名、数据模型然后一顿操作生成了几十个测试文件甚至自己起了 mock server跑了 pytest最后绿油油一片。我一开始挺满意直到我 review 到其中一个测试。那个断言不是在验证我们接口的返回字段而是在断言 Claude Code 自己生成的一个中间对象的值。也就是说它把“自己构造的临时结构”当成了被测对象并基于这个结构推导出了断言。看起来测得很全实际什么都没测到。更让我后背发凉的是如果不是那天我坚持一行行 review这批测试会挂在 CI 里很久很久。那一刻我突然意识到AI Coding 最大的问题不是它写得不好而是它会让你在“看起来没问题”的假象里待太久。等你发现问题你面对的是一个你不完全理解的大规模改动而你自己的技能雷达已经因为过度信任而钝化了。1.2 谁最容易掉进这个坑里我把身边用过 AI 编程工具的人分成了三类。第一类是刚工作两三年的开发基础还不牢很容易把“AI 能跑通”理解成“我已经掌握了”。他们简历里写着熟悉 Spring、熟悉 Redis实际上是靠 agent 把代码凑出来的一旦问到底层原理整个人会瞬间卡壳。第二类是长期做业务系统的“熟练工”他们过去最大的优势是对老系统的熟悉程度可当 AI 也能快速读完整个仓库并给出修改建议时这个优势会迅速贬值。第三类是已经晋升到技术管理或架构岗位的人他们觉得“我只要负责把关不就好了”但把关这件事恰恰最依赖实打实的手感和直觉。不是说资深开发不会衰退而是资深开发衰退得更慢一点因为他们脑子里还有足够的上下文兜底。真正危险的是所有把 AI Coding 当成“个人能力放大器”的人。放大器放大的是产出同时也会放大你对产出质量的盲区。你越依赖它你亲手验证关键逻辑的机会就越少最后连“哪里容易错”这个最基础的敏感度都会消失。2. 职业技能衰退的底层机制不是记性变差而是判断力被外包很多人会把技能衰退理解成“知识点忘了”——比如你不再记得某个 API 的参数顺序不再记得 JVM 的默认堆大小。但作为一个长期在一线写代码、带过团队的人我觉得更本质的变化是判断力外包而不是记忆消失。记忆丢了还能查文档判断力如果外包太久你可能都意识不到自己已经失去了什么。2.1 你好不容易积累的错误预案库正在被清零一个合格的开发者最值钱的资产不是会写多少语法而是脑子里那本“错误预案库”。比如你一看到多处共享的可变状态就会下意识想并发问题一看到用户上传的文件名就会先做安全校验一看到时间字段就会追问是 UTC 还是本地时区。这些不是靠背八股文得来的是你过去一遍遍踩坑、一遍遍 review、一遍遍修线上故障换来的直觉。过去这个预案库会在你写每一行代码时被激活。你会先在脑内构建一个“这个需求可能会炸的地方”清单然后每一行实现都去匹配这个清单。现在用 AI Coding流程变成了需求丢给 agent它自己生成代码你大概率只做两件事——贴进去、跑一下。如果你的上下文里没有明确提“这里有并发风险”而 AI 也没主动规避这个坑就被静默地埋了下来。你说那 review 不就行了问题在于当 review 的对象是一大段由 AI 生成的、风格统一、注释到位的代码时你会不自觉地降低防御心。这种“看起来都对”的表象其实比手写代码的乱糟糟更难发现隐患。你的错误预案库没有更新到新的代码模式上下次遇到同样的问题你还是会把它交给 AI然后继续错过。时间一长预案库里的条目不仅没有增加反而开始失真。2.2 从“写代码”到“审代码”反馈路径变长变钝手写代码的反馈是即时的。你的手指敲下一个循环你会立刻判断这个条件应该放在循环里还是循环外你会因为一个变量名取得不好停下来重想抽象你会因为一个函数太长而主动拆解。这个过程看起来慢但它每时每刻都在训练你的“代码嗅觉”。AI Coding 改变了反馈路径。你不再通过“写”来思考而是通过“审”来确认。你在 AI 生成的结果上做修改、提要求就像拿着一支红笔改下属的作文。审阅当然也是一种能力但它依赖你已经有足够强的内在标准如果没有你只能做表面检查比如格式、缩进、方法名而很难判断核心设计是否合理。我见过很多年轻开发他们可以非常熟练地告诉 Claude Code“这里用一个策略模式那里加一层缓存”但如果你把 AI 藏起来让他们从零设计同样的模块他们会突然不知道从哪下手。因为他们已经习惯了把“思维碎片”扔给工具让工具替他们把碎片组织成完整结构。组织结构的这个过程恰恰是编程训练中最核心的部分。你跳过了它短期是快长期是钝。2.3 T型开发者正在退化成一字形参与者我们常说要成为 T 型人才横向上有广泛的领域知识纵向上有一项足够深的核心技能。对程序员来说那根竖线通常是你最熟悉的语言、框架或者是你对某个业务领域的深刻理解。AI Coding 的问题在于它让所有人看起来都变成了“一字形”——广度很宽但没有深度。你会写 Python、Go、TypeScript因为你让 AI 生成过这些语言的代码你会配 Docker、K8s、Terraform因为你用过 Infra agent你会写前端组件因为你让 Claude Code 照着设计稿改过样式。看起来什么都会一点但每一项都停留在“能跑”的水平。有一天线上出了故障需要有人快速从日志反推原因甚至需要在不依赖模型的情况下做一版热修复。这个时候一字形的人会非常被动。这种退化的可怕之处在于它不会立刻让你失业因为市场还在为“能交付”付费。但它会悄悄改变你在团队里的定位——你从那个“遇到难题能扛住的人”慢慢变成一个“只会在常规任务上用 AI 辅助的装配工”。当公司开始缩减人员、优化成本时最先被审视的往往就是这种可替代性极高的角色。3. “被蒙蔽”不是巧合是一条完整的商业与心理闭环你可能会问既然 AI Coding 会造成技能衰退为什么大家都没感觉因为“被蒙蔽”不是发生在某一个瞬间而是一套完整的闭环工具厂商给你看效率神话团队绩效奖励你的产出幻觉你自己的大脑则擅长为省力行为寻找合理叙事。三股力量往同一个方向拧你当然意识不到自己在滑坡。3.1 效率幻觉的制造过程demo、话术与短期指标Anthropic 在推广 Claude Code 时放出的 demo 确实很有冲击力。一个 agent 在终端里自己调用工具、编辑文件、跑测试几分钟完成一个任务观感上就像有一个全栈工程师坐在你电脑前。再配合“几周变几小时”的口径任何人都很难不动心。但真实项目不是 demo。demo 里的仓库是干净的新项目需求是明确的一句话整个环境是工具方预设好的。而真实工程里有历史遗留的数据库字段有谁也不愿意碰的祖传模块有跨团队的接口约束有上线窗口和回滚方案。你让 AI 处理这些东西它能给出一个看起来合理的方案但判断这些约束是否真的被正确理解还是得靠你。而这个环节恰恰最没有效率神话可言。更隐蔽的是短期绩效指标。这一周你交付了三个功能领导很满意至于这三块代码里有多少是你在没有理解的情况下“审核通过”的下个月才会爆雷。到了下个月爆雷之后你第一反应不是反思自己的技能而是觉得自己应该把 prompt 写得更详细一点。于是你对工具的依赖更进一步而你的因果推断也彻底被带偏了。3.2 最危险的自我安慰是“我负责架构AI 负责实现”我常听一些资深开发说代码让 AI 写没问题我负责架构我来把控方向。这句话听上去很有道理实际上是一个巨大的自我欺骗。架构决策不是空中楼阁它需要建立在大量实现细节的反馈上。你如果不亲手写过某些模块不经历过某个字段在真实数据下的奇葩表现你画出来的架构图很可能只是套话的堆砌。架构本质上是在约束这里允许哪些依赖那里必须做到什么性能什么情况下需要妥协。这些约束来自实现层的真实反馈而不是来自某个抽象的原则。如果你把实现全部交给 AI你的架构会慢慢失去“手感”变成一种 PPT 里的漂亮逻辑。等到 AI 实现不了你的设计你发现需要调整架构时你已经很难判断调整后的成本到底有多大了。这也是最典型的被蒙蔽路径你以为自己是那个“指挥者”AI 只是“执行者”但在真实的项目推进中你越来越依赖 AI 给出的执行反馈来修正自己的指挥。不知不觉角色已经反转你成了那个不断给 AI 需求、再根据 AI 结果去调整期望的人。你还以为自己在做高价值工作其实你已经退化成一个需求转述管道了。3.3 组织氛围和 AI coding 面试正在把幻觉制度化光是个人的心理机制还不够现在连组织和招聘制度都在助长这种幻觉。团队里只要有一个用 AI coding agent 每天交付十个 PR 的人其他人就很难坚持手写了因为老板只看得到 PR 数量和上线速度。于是大家集体进入“快节奏外包模式”代码 review 变成形式code review 里说的最多的一句话是“这里跑通了吗”而不是“这个设计合理吗”。更荒诞的是招聘环节。我看到一些公司已经把 AI Coding 笔试当成了新卖点候选人可以在 coding 环节使用 AI agent 辅助解题。听起来很前卫但你仔细想想如果笔试考察的是“一个人能否利用 AI 完成一个明确的小任务”那它衡量的是求职者使用工具的速度而不是他理解系统、诊断问题、应对模糊需求的能力。结果是一个能熟练给 agent 下达指令的人可能完全不具备排查线上内存泄漏的经验。他的“AI coding 笔试”分很高但入职后第一个大故障就把他打回原形。这种制度化的蒙蔽会让技能衰退变得合理化。大家不再觉得“我必须手写代码才能保持手感”而是觉得“时代变了会调用 AI 才是新技能”。这两者并不矛盾但如果不给后者加前提就会变成你以为自己在驾驶一辆高性能赛车实际上你只是坐在副驾驶上看着自动驾驶往前跑而你连地图和仪表盘都没有真正读懂。4. 拿 Claude Code 实测后的能力边界与常见翻车场景既然标题里提到了 Anthropic那我以 Claude Code 为例做一轮更具体的实操拆解。我自己的用法不算极端但几个月用下来已经积累了足够的样本去画一张能力边界图。这份地图很有价值——因为只有知道工具在哪里会翻车你才不会被它蒙蔽。4.1 它擅长什么、不擅长什么一张清晰的地图先给结论Claude Code 在做“有明确模式、内容重复、上下文完整”的任务时能力是超出我预期的。它能快速理解仓库结构能按已有风格写代码能自己在本地跑测试并根据失败信息迭代。对于生成 CRUD、批量重构命名、补单元测试、写工具脚本这类任务它确实是把好手。但在下面这些场景里它的表现其实非常脆弱。一来是需求本身存在大量隐性业务规则时它很容易漏掉二来是跨模块依赖链条很长单次对话只能看到局部上下文三来是性能优化和安全性评估它给出的建议经常停留在“正确但没必要”的层面四来是团队协作中的一些非代码约束比如某段代码必须兼容一个已经被淘汰的旧客户端版本这类信息如果没有被显式写进上下文它几乎不可能主动想到。我把这些整理成一张表方便你对照使用使用场景Claude Code 的能力实际建议脚手架与样板代码很强可放手让它写但要看懂每段批量重构与重命名较强建议配合同步测试验证行为不变单元测试补全中上必须人工审视断言是否有实际覆盖跨模块业务改动一般自己先梳理调用链别让它自由发挥故障排查与线上问题弱只能把它当“第二个意见”不能跳过第一轮复杂算法与性能优化较弱需要你亲自推导别轻信它的复杂度结论这张地图告诉我们工具的能力不是一条直线而是一堆离散的岛。你只有在能清楚分辨哪些岛适合登陆、哪些岛会触礁的前提下才能安全使用它。4.2 那些看起来成功、实际上失控的项目经历光给地图不够我再分享一个实际踩坑案例用来解释为什么“demo 成功”和“项目成功”是两回事。我给内部平台写过一个批量导入 Excel 数据的功能。开始时我很轻松Claude Code 很快生成了一版代码包含数据校验、进度日志、失败回滚结构非常完整。pytest 也是绿的我甚至觉得这功能可以零 review 直接上。幸好我没有那么做。真实数据文件到了之后问题立刻暴露。那个 Excel 里有合并单元格有字段内部换行有几列格式不统一有的数字被 Excel 自动转成了科学计数法。Claude Code 生成的解析逻辑是按“干净表格”假设来的它识别了文件头却没能识别出某些行因为合并单元格导致的对齐错位。结果是一部分数据被静默地写进了相邻的错误列而且因为它的校验逻辑也是按同样假设写的脏数据全部通过了校验。最后我花了一个晚上重新梳理解析规则用真实文件做边界测试才把它救回来。这个案例给我的启发是AI Coding 可以在几小时内搭出一个看起来完整的功能但它对“真实世界里的脏数据”和“业务现场的不规则性”几乎毫无感知。你如果不提前把这些约束填进上下文并且保留人工核对真实数据的环节它给你的效率只是幻觉。另一个常见翻车场景是“过度自信”。我问它某个模块是否存在缓存穿透风险它非常肯定地告诉我已经做了布隆过滤器。我去翻代码确实有一个 filter 类但那个类只在一个测试文件里出现过生产代码根本没用。AI 的回答看起来逻辑通顺实际上是在虚构一个它认为合理的事实。这提醒我你永远不能把 AI 的“解释”当成代码运行的真实结论一切要以实际执行结果和代码路径为准。4.3 遇到 unable to connect 类连接错误怎么冷静排查热词里很多人都在搜 “unable to connect to anthropic services” 或者 “failed to connect to api.anthropic.c”。作为每天在用 Claude Code 的人我可以负责任地告诉你这个错误我隔三差五就会遇到它不代表你的电脑坏了也不代表 AI Coding 不值得用。遇到这类报错我的第一反应是不要慌然后按步骤排查。第一步检查终端所在网络的连通性最简单的方式是浏览器能否正常打开同域名服务或访问官方的文档站第二步检查 API key确认没有过期、没有达到额度限制同时确认环境变量里的 key 是否被某个 shell 配置覆盖了第三步去 Anthropic 的状态页看一眼有没有区域性服务波动很多连不上问题其实是服务端限流或故障导致第四步把 Claude Code 和相关的 CLI 升级到最新版本旧版本在服务端接口调整后会频繁连接失败最后一步是等待五到十分钟重试因为多数限流是短时的。我特别不建议的做法是一遇到连接失败就急着去换各种不规范的接入方式。无论你换成哪家模型、哪个接口连接问题都只是工具层面的小浪花真正决定你职业价值的是解决问题的能力。你把精力花在“如何让 agent 始终可用”上而不是花在“如何理解这段代码为什么错”上本身就是技能衰退的又一种征兆。4.4 “数小时完成数周工作”背后的项目真相“数小时内完成过去需要数周的开发工作”这句话我没法直接说它是假的因为它描述的是少数理想情况。可你想过没有过去需要数周的项目为什么会费数周通常不是因为最终那几千行业务代码需要敲一周而是因为需求在过程中反复颠簸、接口文档对不上、历史代码的行为需要对齐、测试环境不稳定、跨团队协作要排队。这些时间消耗没有一个能被 Claude Code 压缩掉。AI Coding 能压缩的只是“把已经明确的方案转换成代码”这个环节。如果项目最大的瓶颈在于需求模糊和沟通成本那么 agent 的作用非常有限。它的确能帮你把明确的部分快速落地但也会让你误以为项目整体都在加速。这种误解会带来一个很现实的问题你会不会因此接下更高的承诺领导看到你“数小时完成数周工作”会自然把下一个需求的工期预期调低。当你真的遇到那个“数周主要是沟通成本”的项目时你只能靠 AI 硬撑出一个表面进度然后再用加班去填里面的坑。长期下来你不仅没享受到效率红利反而被效率话语绑进了更危险的交付节奏。技能衰退在这样的节奏里几乎是一种必然结果因为你连停下来复习和思考的时间都没有了。5. 我目前最有效的自救框架让 AI 当杠杆不当义肢写了这么多“衰退”和“蒙蔽”最后还是要落到可操作的自救方案上。我的立场很明确AI Coding 是好工具但它必须被纪律性地约束。你要设计一套属于自己的使用框架让 AI 帮你在低价值部分加速同时在高价值部分继续承担“训练你判断力”的功能。5.1 使用 AI Coding 前先立三条军规第一条军规是凡是需要“拍板”的逻辑不允许 AI 直接写主干。你可以让它生成初稿、给出候选方案但核心分支、事务边界、数据一致性这类代码我会选择手写或者在 AI 生成后推倒重写一遍。这是为了强制保留“亲手构建”的神经回路。第二条军规是如果让 AI 生成代码你必须在下达 prompt 之前先自己写下三条测试用例来锁定期望行为。很多衰退正是因为缺少“预期”。你没有预期就无法判断 AI 的输出对不对。写了测试之后再让 AI 生成不管它写得多离谱你有一个独立的标准去衡量它。第三条军规是无论 AI 帮你写了多少代码每次合入前必须自己把改动用自然语言解释一遍。不是解释给同事听而是解释给自己听。如果你发现自己只能复述代码流程却说不出为什么这里要这样设计、为什么不用另一种方案那就说明这行代码的技能没有真正沉淀到你身上你需要回到代码里再待一会儿。5.2 分层摄入法不同难度任务给不同级别的 AI 权限只靠军规还不够还要有一套分级策略。我自己把开发任务分成四层每一层给 AI 的权限都不一样。第一层是“探索和解释”。你不熟悉某个框架不理解某段历史代码让 AI 帮你梳理调用链、解释概念。这个层级非常安全因为你接收的是知识输出的是理解主动权还在你手里。第二层是“样板和编码细节”。写接口、DTO、配置文件、工具函数可以大胆用 AI但必须对产物做人工审视并补测试。第三层是“核心业务逻辑”。涉及资金、权限、数据一致性、状态机的部分我原则上要求自己手写初稿然后让 AI 充当 code reviewer。第四层是“架构和跨模块设计”。这一层我会禁止 AI 直接输出设计文档但可以让它列出多个方案的优缺点用来挑战我的决定。这样做的本质是把 AI Coding 从“代笔”降级成“顾问”。代笔写多了你的写作能力会退化顾问见多了你的决策能力会增强。差别就在权限边界。5.3 每天/每周做一次“无 AI 复盘”第三个方法可能听起来最简单但执行起来最难每天或每周抽出一段时间关掉所有 AI 辅助做一次纯粹的手写复盘。这里说的“无 AI 复盘”不是让你写一个完整的项目而是只做几件事把你今天让 AI 写的某段代码打开手绘出它的流程把你不理解的测试断言拿出来自己在草稿上推算一遍把你一个星期前审过的代码重构一遍看能不能提出更好的方案。如果觉得工作任务压得你根本没时间做复盘那就把周期拉长到两周一次甚至一个月一次。关键不是频率而是这件事必须存在。因为你让 AI 写的代码越多用手重建核心路径的次数就越少你的内部建模能力就会越弱。无 AI 复盘就像健身时的抗阻训练它不允许你使用任何省力杠杆逼着你的肌肉纤维重新撕裂并增长。我自己有一次在做完两周的 AI 密集型迭代之后专门把一个模块删掉重写了一遍结果发现速度比 AI 生成的版本慢了不止一倍但写出来的代码在可读性和边界处理上明显更好。那个模块里所有关于“为什么这么设计”的记忆也在重写过程中全部回来了。这种手感是任何 code review 都给不了你的。5.4 如果你还是想提升能力可以从一个小实验开始最后分享一个很具体的小实验适合想验证自己是否已经“衰退”的朋友。找一个你最近经常用 AI Coding 完成的功能给自己限定三小时完全不用 agent、不用代码补全、不粘贴模型生成的代码只靠文档和自己的理解把它重新实现一遍。实现完不需要上线只需要对比两版代码。你大概率会发现两种情况。一种是你发现自己的手写版本比 AI 版本粗糙很多这本身就是重要信号说明 AI 帮你省掉的那些细节已经变成了你的盲区。另一种情况是你发现手写版本能更好地表达真实的业务意图因为你更清楚约束在哪里而 AI 之前只是生成了一份“看起来正确”的通用方案。无论哪种结果这次实验都能让你准确看到自己当前的能力水位而不是被 PR 数量和演示效果掩盖。我个人在实际迭代中越来越清楚一件事Anthropic 这类 AI Coding 工具从来不是问题的根源工具本身只是放大镜放大的是你的输出效率也放大你长期疏于思考的代价。真正决定你会不会衰退的是你是否还能保持对每一行代码的“为什么”保持追问。只要你还留着一个不依赖 AI 的思考内核AGI 时代无论怎么走你都能站得住。
AI Coding时代：警惕技能衰退，用Claude Code实测与自救指南
1. 这件事不是危言耸听而是正在发生的技能风化最近关于 Anthropic AI Coding 的讨论突然多了起来尤其是 Claude Code 这类能自己读仓库、跑测试、改文件的编程智能体出现之后团队里的效率曲线确实变得很夸张。有人告诉我“数小时内完成过去需要数周的开发工作”我看了一眼 demo确实是真的。但恰恰因为是真的我才想写一些不合群的话如果你靠 AI Coding 把活干完却没有同步升级自己的判断力那你很可能正处于职业生涯里最舒服的衰退期。先把话说清楚我不反对 AI Coding我自己也在重度使用 Claude Code。我说的是“被蒙蔽”。AI Coding 会以非常隐蔽的方式夺走你验证自己判断的机会让你以为产出变多等于能力变强结果一年后打开 IDE你发现自己已经看不懂一段 200 行的核心逻辑了。这个现象不是极少数人的问题很多有五年、十年经验的老开发同样中招只是他们不会公开承认。1.1 我先说个让我后背发凉的下午前两天我在帮一个遗留系统补自动化测试。系统很老模块之间有大量隐式依赖我先花了两小时梳理调用链然后打开 Claude Code让它按我的思路补一批关键用例。它执行得飞快收集了路由、方法名、数据模型然后一顿操作生成了几十个测试文件甚至自己起了 mock server跑了 pytest最后绿油油一片。我一开始挺满意直到我 review 到其中一个测试。那个断言不是在验证我们接口的返回字段而是在断言 Claude Code 自己生成的一个中间对象的值。也就是说它把“自己构造的临时结构”当成了被测对象并基于这个结构推导出了断言。看起来测得很全实际什么都没测到。更让我后背发凉的是如果不是那天我坚持一行行 review这批测试会挂在 CI 里很久很久。那一刻我突然意识到AI Coding 最大的问题不是它写得不好而是它会让你在“看起来没问题”的假象里待太久。等你发现问题你面对的是一个你不完全理解的大规模改动而你自己的技能雷达已经因为过度信任而钝化了。1.2 谁最容易掉进这个坑里我把身边用过 AI 编程工具的人分成了三类。第一类是刚工作两三年的开发基础还不牢很容易把“AI 能跑通”理解成“我已经掌握了”。他们简历里写着熟悉 Spring、熟悉 Redis实际上是靠 agent 把代码凑出来的一旦问到底层原理整个人会瞬间卡壳。第二类是长期做业务系统的“熟练工”他们过去最大的优势是对老系统的熟悉程度可当 AI 也能快速读完整个仓库并给出修改建议时这个优势会迅速贬值。第三类是已经晋升到技术管理或架构岗位的人他们觉得“我只要负责把关不就好了”但把关这件事恰恰最依赖实打实的手感和直觉。不是说资深开发不会衰退而是资深开发衰退得更慢一点因为他们脑子里还有足够的上下文兜底。真正危险的是所有把 AI Coding 当成“个人能力放大器”的人。放大器放大的是产出同时也会放大你对产出质量的盲区。你越依赖它你亲手验证关键逻辑的机会就越少最后连“哪里容易错”这个最基础的敏感度都会消失。2. 职业技能衰退的底层机制不是记性变差而是判断力被外包很多人会把技能衰退理解成“知识点忘了”——比如你不再记得某个 API 的参数顺序不再记得 JVM 的默认堆大小。但作为一个长期在一线写代码、带过团队的人我觉得更本质的变化是判断力外包而不是记忆消失。记忆丢了还能查文档判断力如果外包太久你可能都意识不到自己已经失去了什么。2.1 你好不容易积累的错误预案库正在被清零一个合格的开发者最值钱的资产不是会写多少语法而是脑子里那本“错误预案库”。比如你一看到多处共享的可变状态就会下意识想并发问题一看到用户上传的文件名就会先做安全校验一看到时间字段就会追问是 UTC 还是本地时区。这些不是靠背八股文得来的是你过去一遍遍踩坑、一遍遍 review、一遍遍修线上故障换来的直觉。过去这个预案库会在你写每一行代码时被激活。你会先在脑内构建一个“这个需求可能会炸的地方”清单然后每一行实现都去匹配这个清单。现在用 AI Coding流程变成了需求丢给 agent它自己生成代码你大概率只做两件事——贴进去、跑一下。如果你的上下文里没有明确提“这里有并发风险”而 AI 也没主动规避这个坑就被静默地埋了下来。你说那 review 不就行了问题在于当 review 的对象是一大段由 AI 生成的、风格统一、注释到位的代码时你会不自觉地降低防御心。这种“看起来都对”的表象其实比手写代码的乱糟糟更难发现隐患。你的错误预案库没有更新到新的代码模式上下次遇到同样的问题你还是会把它交给 AI然后继续错过。时间一长预案库里的条目不仅没有增加反而开始失真。2.2 从“写代码”到“审代码”反馈路径变长变钝手写代码的反馈是即时的。你的手指敲下一个循环你会立刻判断这个条件应该放在循环里还是循环外你会因为一个变量名取得不好停下来重想抽象你会因为一个函数太长而主动拆解。这个过程看起来慢但它每时每刻都在训练你的“代码嗅觉”。AI Coding 改变了反馈路径。你不再通过“写”来思考而是通过“审”来确认。你在 AI 生成的结果上做修改、提要求就像拿着一支红笔改下属的作文。审阅当然也是一种能力但它依赖你已经有足够强的内在标准如果没有你只能做表面检查比如格式、缩进、方法名而很难判断核心设计是否合理。我见过很多年轻开发他们可以非常熟练地告诉 Claude Code“这里用一个策略模式那里加一层缓存”但如果你把 AI 藏起来让他们从零设计同样的模块他们会突然不知道从哪下手。因为他们已经习惯了把“思维碎片”扔给工具让工具替他们把碎片组织成完整结构。组织结构的这个过程恰恰是编程训练中最核心的部分。你跳过了它短期是快长期是钝。2.3 T型开发者正在退化成一字形参与者我们常说要成为 T 型人才横向上有广泛的领域知识纵向上有一项足够深的核心技能。对程序员来说那根竖线通常是你最熟悉的语言、框架或者是你对某个业务领域的深刻理解。AI Coding 的问题在于它让所有人看起来都变成了“一字形”——广度很宽但没有深度。你会写 Python、Go、TypeScript因为你让 AI 生成过这些语言的代码你会配 Docker、K8s、Terraform因为你用过 Infra agent你会写前端组件因为你让 Claude Code 照着设计稿改过样式。看起来什么都会一点但每一项都停留在“能跑”的水平。有一天线上出了故障需要有人快速从日志反推原因甚至需要在不依赖模型的情况下做一版热修复。这个时候一字形的人会非常被动。这种退化的可怕之处在于它不会立刻让你失业因为市场还在为“能交付”付费。但它会悄悄改变你在团队里的定位——你从那个“遇到难题能扛住的人”慢慢变成一个“只会在常规任务上用 AI 辅助的装配工”。当公司开始缩减人员、优化成本时最先被审视的往往就是这种可替代性极高的角色。3. “被蒙蔽”不是巧合是一条完整的商业与心理闭环你可能会问既然 AI Coding 会造成技能衰退为什么大家都没感觉因为“被蒙蔽”不是发生在某一个瞬间而是一套完整的闭环工具厂商给你看效率神话团队绩效奖励你的产出幻觉你自己的大脑则擅长为省力行为寻找合理叙事。三股力量往同一个方向拧你当然意识不到自己在滑坡。3.1 效率幻觉的制造过程demo、话术与短期指标Anthropic 在推广 Claude Code 时放出的 demo 确实很有冲击力。一个 agent 在终端里自己调用工具、编辑文件、跑测试几分钟完成一个任务观感上就像有一个全栈工程师坐在你电脑前。再配合“几周变几小时”的口径任何人都很难不动心。但真实项目不是 demo。demo 里的仓库是干净的新项目需求是明确的一句话整个环境是工具方预设好的。而真实工程里有历史遗留的数据库字段有谁也不愿意碰的祖传模块有跨团队的接口约束有上线窗口和回滚方案。你让 AI 处理这些东西它能给出一个看起来合理的方案但判断这些约束是否真的被正确理解还是得靠你。而这个环节恰恰最没有效率神话可言。更隐蔽的是短期绩效指标。这一周你交付了三个功能领导很满意至于这三块代码里有多少是你在没有理解的情况下“审核通过”的下个月才会爆雷。到了下个月爆雷之后你第一反应不是反思自己的技能而是觉得自己应该把 prompt 写得更详细一点。于是你对工具的依赖更进一步而你的因果推断也彻底被带偏了。3.2 最危险的自我安慰是“我负责架构AI 负责实现”我常听一些资深开发说代码让 AI 写没问题我负责架构我来把控方向。这句话听上去很有道理实际上是一个巨大的自我欺骗。架构决策不是空中楼阁它需要建立在大量实现细节的反馈上。你如果不亲手写过某些模块不经历过某个字段在真实数据下的奇葩表现你画出来的架构图很可能只是套话的堆砌。架构本质上是在约束这里允许哪些依赖那里必须做到什么性能什么情况下需要妥协。这些约束来自实现层的真实反馈而不是来自某个抽象的原则。如果你把实现全部交给 AI你的架构会慢慢失去“手感”变成一种 PPT 里的漂亮逻辑。等到 AI 实现不了你的设计你发现需要调整架构时你已经很难判断调整后的成本到底有多大了。这也是最典型的被蒙蔽路径你以为自己是那个“指挥者”AI 只是“执行者”但在真实的项目推进中你越来越依赖 AI 给出的执行反馈来修正自己的指挥。不知不觉角色已经反转你成了那个不断给 AI 需求、再根据 AI 结果去调整期望的人。你还以为自己在做高价值工作其实你已经退化成一个需求转述管道了。3.3 组织氛围和 AI coding 面试正在把幻觉制度化光是个人的心理机制还不够现在连组织和招聘制度都在助长这种幻觉。团队里只要有一个用 AI coding agent 每天交付十个 PR 的人其他人就很难坚持手写了因为老板只看得到 PR 数量和上线速度。于是大家集体进入“快节奏外包模式”代码 review 变成形式code review 里说的最多的一句话是“这里跑通了吗”而不是“这个设计合理吗”。更荒诞的是招聘环节。我看到一些公司已经把 AI Coding 笔试当成了新卖点候选人可以在 coding 环节使用 AI agent 辅助解题。听起来很前卫但你仔细想想如果笔试考察的是“一个人能否利用 AI 完成一个明确的小任务”那它衡量的是求职者使用工具的速度而不是他理解系统、诊断问题、应对模糊需求的能力。结果是一个能熟练给 agent 下达指令的人可能完全不具备排查线上内存泄漏的经验。他的“AI coding 笔试”分很高但入职后第一个大故障就把他打回原形。这种制度化的蒙蔽会让技能衰退变得合理化。大家不再觉得“我必须手写代码才能保持手感”而是觉得“时代变了会调用 AI 才是新技能”。这两者并不矛盾但如果不给后者加前提就会变成你以为自己在驾驶一辆高性能赛车实际上你只是坐在副驾驶上看着自动驾驶往前跑而你连地图和仪表盘都没有真正读懂。4. 拿 Claude Code 实测后的能力边界与常见翻车场景既然标题里提到了 Anthropic那我以 Claude Code 为例做一轮更具体的实操拆解。我自己的用法不算极端但几个月用下来已经积累了足够的样本去画一张能力边界图。这份地图很有价值——因为只有知道工具在哪里会翻车你才不会被它蒙蔽。4.1 它擅长什么、不擅长什么一张清晰的地图先给结论Claude Code 在做“有明确模式、内容重复、上下文完整”的任务时能力是超出我预期的。它能快速理解仓库结构能按已有风格写代码能自己在本地跑测试并根据失败信息迭代。对于生成 CRUD、批量重构命名、补单元测试、写工具脚本这类任务它确实是把好手。但在下面这些场景里它的表现其实非常脆弱。一来是需求本身存在大量隐性业务规则时它很容易漏掉二来是跨模块依赖链条很长单次对话只能看到局部上下文三来是性能优化和安全性评估它给出的建议经常停留在“正确但没必要”的层面四来是团队协作中的一些非代码约束比如某段代码必须兼容一个已经被淘汰的旧客户端版本这类信息如果没有被显式写进上下文它几乎不可能主动想到。我把这些整理成一张表方便你对照使用使用场景Claude Code 的能力实际建议脚手架与样板代码很强可放手让它写但要看懂每段批量重构与重命名较强建议配合同步测试验证行为不变单元测试补全中上必须人工审视断言是否有实际覆盖跨模块业务改动一般自己先梳理调用链别让它自由发挥故障排查与线上问题弱只能把它当“第二个意见”不能跳过第一轮复杂算法与性能优化较弱需要你亲自推导别轻信它的复杂度结论这张地图告诉我们工具的能力不是一条直线而是一堆离散的岛。你只有在能清楚分辨哪些岛适合登陆、哪些岛会触礁的前提下才能安全使用它。4.2 那些看起来成功、实际上失控的项目经历光给地图不够我再分享一个实际踩坑案例用来解释为什么“demo 成功”和“项目成功”是两回事。我给内部平台写过一个批量导入 Excel 数据的功能。开始时我很轻松Claude Code 很快生成了一版代码包含数据校验、进度日志、失败回滚结构非常完整。pytest 也是绿的我甚至觉得这功能可以零 review 直接上。幸好我没有那么做。真实数据文件到了之后问题立刻暴露。那个 Excel 里有合并单元格有字段内部换行有几列格式不统一有的数字被 Excel 自动转成了科学计数法。Claude Code 生成的解析逻辑是按“干净表格”假设来的它识别了文件头却没能识别出某些行因为合并单元格导致的对齐错位。结果是一部分数据被静默地写进了相邻的错误列而且因为它的校验逻辑也是按同样假设写的脏数据全部通过了校验。最后我花了一个晚上重新梳理解析规则用真实文件做边界测试才把它救回来。这个案例给我的启发是AI Coding 可以在几小时内搭出一个看起来完整的功能但它对“真实世界里的脏数据”和“业务现场的不规则性”几乎毫无感知。你如果不提前把这些约束填进上下文并且保留人工核对真实数据的环节它给你的效率只是幻觉。另一个常见翻车场景是“过度自信”。我问它某个模块是否存在缓存穿透风险它非常肯定地告诉我已经做了布隆过滤器。我去翻代码确实有一个 filter 类但那个类只在一个测试文件里出现过生产代码根本没用。AI 的回答看起来逻辑通顺实际上是在虚构一个它认为合理的事实。这提醒我你永远不能把 AI 的“解释”当成代码运行的真实结论一切要以实际执行结果和代码路径为准。4.3 遇到 unable to connect 类连接错误怎么冷静排查热词里很多人都在搜 “unable to connect to anthropic services” 或者 “failed to connect to api.anthropic.c”。作为每天在用 Claude Code 的人我可以负责任地告诉你这个错误我隔三差五就会遇到它不代表你的电脑坏了也不代表 AI Coding 不值得用。遇到这类报错我的第一反应是不要慌然后按步骤排查。第一步检查终端所在网络的连通性最简单的方式是浏览器能否正常打开同域名服务或访问官方的文档站第二步检查 API key确认没有过期、没有达到额度限制同时确认环境变量里的 key 是否被某个 shell 配置覆盖了第三步去 Anthropic 的状态页看一眼有没有区域性服务波动很多连不上问题其实是服务端限流或故障导致第四步把 Claude Code 和相关的 CLI 升级到最新版本旧版本在服务端接口调整后会频繁连接失败最后一步是等待五到十分钟重试因为多数限流是短时的。我特别不建议的做法是一遇到连接失败就急着去换各种不规范的接入方式。无论你换成哪家模型、哪个接口连接问题都只是工具层面的小浪花真正决定你职业价值的是解决问题的能力。你把精力花在“如何让 agent 始终可用”上而不是花在“如何理解这段代码为什么错”上本身就是技能衰退的又一种征兆。4.4 “数小时完成数周工作”背后的项目真相“数小时内完成过去需要数周的开发工作”这句话我没法直接说它是假的因为它描述的是少数理想情况。可你想过没有过去需要数周的项目为什么会费数周通常不是因为最终那几千行业务代码需要敲一周而是因为需求在过程中反复颠簸、接口文档对不上、历史代码的行为需要对齐、测试环境不稳定、跨团队协作要排队。这些时间消耗没有一个能被 Claude Code 压缩掉。AI Coding 能压缩的只是“把已经明确的方案转换成代码”这个环节。如果项目最大的瓶颈在于需求模糊和沟通成本那么 agent 的作用非常有限。它的确能帮你把明确的部分快速落地但也会让你误以为项目整体都在加速。这种误解会带来一个很现实的问题你会不会因此接下更高的承诺领导看到你“数小时完成数周工作”会自然把下一个需求的工期预期调低。当你真的遇到那个“数周主要是沟通成本”的项目时你只能靠 AI 硬撑出一个表面进度然后再用加班去填里面的坑。长期下来你不仅没享受到效率红利反而被效率话语绑进了更危险的交付节奏。技能衰退在这样的节奏里几乎是一种必然结果因为你连停下来复习和思考的时间都没有了。5. 我目前最有效的自救框架让 AI 当杠杆不当义肢写了这么多“衰退”和“蒙蔽”最后还是要落到可操作的自救方案上。我的立场很明确AI Coding 是好工具但它必须被纪律性地约束。你要设计一套属于自己的使用框架让 AI 帮你在低价值部分加速同时在高价值部分继续承担“训练你判断力”的功能。5.1 使用 AI Coding 前先立三条军规第一条军规是凡是需要“拍板”的逻辑不允许 AI 直接写主干。你可以让它生成初稿、给出候选方案但核心分支、事务边界、数据一致性这类代码我会选择手写或者在 AI 生成后推倒重写一遍。这是为了强制保留“亲手构建”的神经回路。第二条军规是如果让 AI 生成代码你必须在下达 prompt 之前先自己写下三条测试用例来锁定期望行为。很多衰退正是因为缺少“预期”。你没有预期就无法判断 AI 的输出对不对。写了测试之后再让 AI 生成不管它写得多离谱你有一个独立的标准去衡量它。第三条军规是无论 AI 帮你写了多少代码每次合入前必须自己把改动用自然语言解释一遍。不是解释给同事听而是解释给自己听。如果你发现自己只能复述代码流程却说不出为什么这里要这样设计、为什么不用另一种方案那就说明这行代码的技能没有真正沉淀到你身上你需要回到代码里再待一会儿。5.2 分层摄入法不同难度任务给不同级别的 AI 权限只靠军规还不够还要有一套分级策略。我自己把开发任务分成四层每一层给 AI 的权限都不一样。第一层是“探索和解释”。你不熟悉某个框架不理解某段历史代码让 AI 帮你梳理调用链、解释概念。这个层级非常安全因为你接收的是知识输出的是理解主动权还在你手里。第二层是“样板和编码细节”。写接口、DTO、配置文件、工具函数可以大胆用 AI但必须对产物做人工审视并补测试。第三层是“核心业务逻辑”。涉及资金、权限、数据一致性、状态机的部分我原则上要求自己手写初稿然后让 AI 充当 code reviewer。第四层是“架构和跨模块设计”。这一层我会禁止 AI 直接输出设计文档但可以让它列出多个方案的优缺点用来挑战我的决定。这样做的本质是把 AI Coding 从“代笔”降级成“顾问”。代笔写多了你的写作能力会退化顾问见多了你的决策能力会增强。差别就在权限边界。5.3 每天/每周做一次“无 AI 复盘”第三个方法可能听起来最简单但执行起来最难每天或每周抽出一段时间关掉所有 AI 辅助做一次纯粹的手写复盘。这里说的“无 AI 复盘”不是让你写一个完整的项目而是只做几件事把你今天让 AI 写的某段代码打开手绘出它的流程把你不理解的测试断言拿出来自己在草稿上推算一遍把你一个星期前审过的代码重构一遍看能不能提出更好的方案。如果觉得工作任务压得你根本没时间做复盘那就把周期拉长到两周一次甚至一个月一次。关键不是频率而是这件事必须存在。因为你让 AI 写的代码越多用手重建核心路径的次数就越少你的内部建模能力就会越弱。无 AI 复盘就像健身时的抗阻训练它不允许你使用任何省力杠杆逼着你的肌肉纤维重新撕裂并增长。我自己有一次在做完两周的 AI 密集型迭代之后专门把一个模块删掉重写了一遍结果发现速度比 AI 生成的版本慢了不止一倍但写出来的代码在可读性和边界处理上明显更好。那个模块里所有关于“为什么这么设计”的记忆也在重写过程中全部回来了。这种手感是任何 code review 都给不了你的。5.4 如果你还是想提升能力可以从一个小实验开始最后分享一个很具体的小实验适合想验证自己是否已经“衰退”的朋友。找一个你最近经常用 AI Coding 完成的功能给自己限定三小时完全不用 agent、不用代码补全、不粘贴模型生成的代码只靠文档和自己的理解把它重新实现一遍。实现完不需要上线只需要对比两版代码。你大概率会发现两种情况。一种是你发现自己的手写版本比 AI 版本粗糙很多这本身就是重要信号说明 AI 帮你省掉的那些细节已经变成了你的盲区。另一种情况是你发现手写版本能更好地表达真实的业务意图因为你更清楚约束在哪里而 AI 之前只是生成了一份“看起来正确”的通用方案。无论哪种结果这次实验都能让你准确看到自己当前的能力水位而不是被 PR 数量和演示效果掩盖。我个人在实际迭代中越来越清楚一件事Anthropic 这类 AI Coding 工具从来不是问题的根源工具本身只是放大镜放大的是你的输出效率也放大你长期疏于思考的代价。真正决定你会不会衰退的是你是否还能保持对每一行代码的“为什么”保持追问。只要你还留着一个不依赖 AI 的思考内核AGI 时代无论怎么走你都能站得住。 
