你有没有发现，用AI写代码越来越快，但修bug的时间越来越长？
一位开发者做了件极端的事：三个月不用任何AI工具，纯手写代码。他的发现可能会让你重新考虑现在的开发流程——不是让你当技术保守派，而是找到一种更可持续的工作方式。
「理解债」：比技术债更隐蔽的坑
我们聊技术债聊太多了。但有一种更隐蔽、更危险的东西正在积累，我称之为「理解债」（comprehension debt）——就是你仓库里的代码和你对代码实际行为的理解之间的那个缺口。
每次你不读完就接受AI建议，缺口扩大一点。每次你让AI「让它跑起来就行」然后直接粘贴结果，你都是在透支自己的理解力。
这不是假设。看看这位开发者在真实代码里抓到的模式：
AI生成的版本乍一看很合理：try-catch包裹fetch，出错就console.error，返回null。但fetch不会在HTTP错误时抛出异常。404或500照样resolve，response.json()在非JSON错误页上可能抛出异常，但那时你已经丢了真实的状态码。
这种问题，手写时能抓住——因为你在逐行思考，而不是快速扫描。
修正后的版本更短、更清晰、更正确：没有默默吞掉错误的try-catch，没有强迫每个调用者做空检查的null返回。直接检查response.ok，保留状态码让调用者自己决定怎么处理。
凌晨两点的调试地狱
理解债真正咬人的时候，是调试场景。
凌晨两点，东西崩了，你盯着自己没写的代码——代码你不理解——本质上是在调试别人的工作。但这里没有「别人」可以问。
这位开发者跟踪了自己使用AI工具前后各一个月的调试会话。虽然数字不科学，个人差异很大，但方向性信号强到足以让他改变工作方式。
AI工具不会消失，也确实有用。但问题是：我们怎么在享受效率的同时，不把自己埋进理解债里？
一个可行的折中方案
三个月手写实验后，这位开发者没变成AI抵制者，而是打磨出了一套流程。核心原则很简单：先写，后问，再验证。
具体怎么操作？
第一，总是先自己写第一版。哪怕只是骨架、伪代码、粗糙的实现。关键是让你的大脑先和 problem 搏斗一遍，建立mental model。这时候再让AI帮忙，你能判断它给的东西对不对、合不合适。
第二，把AI当配对程序员，不是代笔。不要问「给我写个用户认证系统」，而是「我这里的密码哈希逻辑有没有timing attack漏洞」。具体、聚焦、有上下文的问题，得到的质量完全不同。
第三，强制解释。AI给的建议，用自己的话复述一遍为什么要这么写。如果说不出来，说明你没理解，别合并。
第四，建立个人代码审查清单。针对AI常犯的错误：错误处理是否完整？边界条件覆盖了吗？有没有引入不必要的依赖？类型定义准确吗？
工具厂商没告诉你的事
Copilot、ChatGPT这些工具的设计逻辑是「减少按键次数」。但代码质量的关键从来不是打字速度，是思考深度。
厂商的metrics很诱人：接受率、代码生成速度、每周节省小时数。但这些数字掩盖了一个事实——省下来的时间可能以指数形式花在调试上。
更麻烦的是，AI生成代码的「合理性幻觉」特别强。语法正确、结构熟悉、命名规范，看起来就像人写的。但正是这种像，让你放松警惕，跳过本该做的审查。
那位开发者的三个月实验有个意外发现：手写代码时，他会自然写出更简洁的实现。因为每多一行都是成本，大脑会自动优化。而AI建议往往「慷慨」——多写几行保险，反正不花它的力气。
给你的具体建议
如果你现在重度依赖AI编码，不用断崖式戒断。试试这个渐进方案：
下周开始，每天留一小时「手写时间」。选最核心、最容易出问题的模块，关掉AI补全，纯手撸。目的是保持手感，不让理解债无限累积。
代码审查时，对AI生成部分强制加标签。很多团队已经在用// AI-generated这种标记，但更重要的是——标记后要额外审查，不是免责金牌。
建立团队层面的「理解债」意识。技术债会进backlog，理解债往往隐形。可以在retro时专门问：这周有没有合并了但不理解的代码？比例是多少？
最后，重新评估你的「效率」定义。如果写代码快了30%，但调试慢了50%，这是净亏损。真正的效率是端到端的交付速度，不是IDE里的字符输出率。
那位开发者现在怎么用AI？他写第一版，AI帮忙找edge case和优化，他审阅、测试、合并。生成-审查的循环还在，但顺序变了，控制权也在自己手里。
AI coding工具不会退潮，但怎么用，决定了你是冲浪还是被卷走。检查一下你最近的commit，有多少行是你能逐行解释为什么这样写的——这个数字，可能比你想的低。
热门跟贴