正在加载文章内容，请稍候。
《开发者吐槽“AI 让大脑变钝”：效率叙事与现实返工之间的落差》
一线开发者体验指出重度依赖 AI 编码工具可能带来更多错误与返工，并削弱基本功与新人培养。
精准输入
我的笔记
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可记笔记
登录后可保存笔记、高亮、划线和批注。
正在加载文章内容，请稍候。
一线开发者体验指出重度依赖 AI 编码工具可能带来更多错误与返工，并削弱基本功与新人培养。
精准输入
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可保存笔记、高亮、划线和批注。
科技公司高管喜欢用“代码中有多少比例由 AI 生成”来证明生产力革命已经到来，但一线开发者的体验更复杂：AI 生成的代码往往需要反复检查、修补和返工；更深的焦虑是，长期依赖 AI 可能削弱开发者对代码库、调试和基本工程判断的掌控。效率叙事背后，正在堆积看不见的技术债和技能退化风险。
大型科技公司正在把 AI 编码塑造成经济转型的证据。Meta、Google、Microsoft 等公司高层不断强调，AI 正生成越来越多公司内部代码，因此软件生产会更快、更便宜。这个叙事的潜台词是：如果顶级科技公司已经用 AI 提升效率、降低人力需求，那么其他行业也迟早会被同样改造。
他们最爱举的指标，是 AI 生成代码占比。Google 曾表示公司 3/4 新代码由 AI 生成；Microsoft CEO Satya Nadella 说公司最多 30% 代码由 AI 生成，CTO Kevin Scott 预计到 2030 年这一比例会达到 95%；Mark Zuckerberg 也说 AI 将在 12–18 个月内写出大部分用于改进 AI 的代码；Anthropic 则称团队多数代码有 90% 由 AI 生成。
这些数字让 AI 看起来像软件工程的自动化胜利，但它们没有回答一个更关键的问题：这些代码是否真的高质量、安全、可维护。代码生成比例越高，不等于系统质量越高；如果审查能力没有同步增长，高比例反而意味着更大面积的未知风险。
被要求使用 AI 的开发者讲的是另一个故事。在 Reddit、Hacker News 和其他开发者讨论区，越来越多人对大语言模型生成代码的承诺感到幻灭。问题不只是 AI 输出有缺陷，而是为了完成工作，开发者常常需要逐行检查、修复和解释它的错误，这会让任务变得更费时、更困难、更沮丧。
一名中型科技公司的 UX 设计师说，公司要求他们用 AI agent 在代码库中做大范围修改，但“没有办法评估那么多代码是否写得好、是否安全——尤其当公司里几百个程序员都在做同样的事”。这不是单个 pull request 的质量问题，而是大规模组织实践：每个人都在把不完全理解的生成代码推进系统。
AI 编码的真实成本常常不在生成那一刻，而在后续验证、修补和承担责任的过程中。模型能快速产出文本，不能自动保证架构一致性、边界条件、安全属性和长期可维护性。
文章里最尖锐的一句话是：“The actual quality of output doesn't matter as much as our willingness to participate.” 真正被管理层奖励的，可能不是代码质量，而是团队愿意加入 AI 化流程。
这会制造一种“AI 参与率”崇拜：只要工具使用率、生成比例、token 消耗和自动化故事足够漂亮，就能被包装成组织转型。那名 UX 设计师担心，团队正在建造一个“rat's nest of tech debt”——一团以后难以解开的技术债。更讽刺的是，如果模型成本变得高昂或工具不可用，公司可能会留下大量没人真正理解、也没人愿意维护的 AI 生成代码。
高管们还把 AI 实施和裁员联系起来。AI 生产力提升并没有明显带来更好的产品、更短工时或更好的用户体验，更多时候被用来解释为什么可以减少人手。Meta、Microsoft、Snap 等公司都出现过将裁员与 AI 使用联系起来的表述或背景。
开发者最担心的不是“AI 会不会抢工作”这个抽象问题，而是自己正在失去做工作的能力。长期让 AI 生成、补全和解释代码，可能让人忘记 API、丧失对代码库的心智模型、遇到生产故障时更难从底层推理。
这种退化尤其会影响新人培养。初级开发者过去通过读代码、写 bug、调试、重构来建立工程直觉；如果他们一开始就把问题转化为 prompt，再接受模型输出，就可能更擅长驱动工具，却更不擅长理解系统。AI 编码最危险的副作用，可能不是替代开发者，而是让开发者失去判断 AI 何时错了的能力。
这不是反技术情绪。AI 在生成样板代码、探索 API、解释陌生模块、加速小范围修改上确实有价值。但一旦它被用来做“跨代码库的大范围变更”，而人类又没有足够时间审查，效率就会变成风险放大器。
AI 编码工具的价值不在于让人少思考，而在于把人的注意力从机械输入移到更高层判断：需求是否清楚、架构是否合适、边界条件是否覆盖、测试是否能捕捉错误、变更是否能被团队长期维护。
如果组织只追求“用了多少 AI”“生成了多少代码”，而不投入评审、测试、可观测性和新人训练，AI 会把软件工程中最稀缺的能力——判断力——进一步耗空。相反，如果 AI 被限制在可验证、小范围、强测试覆盖的场景中，它才可能成为真正的杠杆。
AI 编码的关键矛盾不是“会不会写代码”，而是“谁来理解、验证并维护这些代码”。高管看到的是生成比例和降本空间；开发者感受到的是返工、审查压力、技能退化和技术债。真正成熟的 AI 编码文化，不应把参与 AI 流程当成目标，而应把人类工程判断保留下来：模型负责加速，人负责理解；模型可以建议，人必须能否定。
文章先对比高管的 AI 生产力叙事和开发者的一线体验，指出“AI 代码比例”无法代表真实质量。随后通过匿名开发者的担忧，把问题推进到技术债、审查成本和组织激励。最后落到技能退化：AI 的最大风险不是生成错误，而是让人逐渐失去识别错误和维护系统的能力。
费曼输出