别让 Cursor 的丝滑体验偷走你作为开发者的心智模型
很多新人进入 AI 编程时代最爽的一点就是：不再需要面对那些令人抓狂的报错。但从认知科学的角度来看，真正的能力增长往往发生在那些让你痛苦的时刻。比如，当你对着一个诡异的 TypeError: Cannot read properties of undefined 死磕两小时，或者在无数次尝试后才意识到某个异步逻辑的竞态条件（Race Condition）导致了数据不一致。这种“认知摩擦”才是知识在大脑中扎根的唯一方式。
现在的 LLM 本质上是一个极力迎合用户的“Yes-Man”。当你质疑它的实现方案时，它会迅速给出一个极其完美的解释；当你指出 Bug 时，它会立刻道歉并给出修正方案。这种顺滑的体验让我们习惯了被“喂食”，而失去了通过痛苦调试来建立心智模型的能力。如果你习惯了直接 Copy-Paste 那些能跑通的代码，你其实是在用长期的认知退化换取短期的交付速度。
为了在 AI 时代保持竞争力，我尝试在自己的工作流中人为制造一些“摩擦”，防止自己变成一个只会写 Prompt 的代码搬运工。
首先，我强迫自己禁用直接生成代码，改为先写伪代码。在让 AI 填充函数之前，我会先在注释里写清楚逻辑步骤，尤其是必须强迫自己思考边界情况（Edge Cases）。比如在处理一个数据过滤接口时，我会先写明：1. 校验输入参数是否为空；2. 处理分页偏移量越界；3. 定义默认排序逻辑。只有逻辑闭环后，才允许 AI 填充代码。这样能确保大脑在编码前已经完成了架构思考，而不是被 AI 牵着鼻子走。
其次，我执行一套严格的“追问三遍”机制。每当 AI 给出一段能跑通的代码，我绝不直接提交，而是强制进行三轮深度质询。我会问它：“这段代码在并发量极高时会有什么潜在问题？”、“如果不使用这个第三方库，用原生 API 怎么实现？”以及“这种写法的时间复杂度是多少，有没有更优解？”通过这种方式，我把 AI 从一个“代码生成器”变成了我的“技术评审员”，强迫自己去审视代码的底层性能和潜在风险。
最后，也是最痛苦的一点：刻意保留报错时间。现在很多 IDE 插件在报错的一瞬间就会弹出“Fix with AI”的按钮，这太危险了。我现在的做法是，遇到 Bug 时先禁掉 AI 插件，强迫自己用 console.log 或断点调试手动定位 15 分钟。只有当我真正感受到挫败、尝试了多种路径依然无果时，才把报错信息贴给 AI。实践证明，在这种状态下看到答案，我的吸收率比直接生成高出数倍，因为此时我的大脑已经为这个答案预留了“认知坑位”。
一个优秀的工程师，其价值不在于能让测试用例快速变绿，而在于面对未知崩溃时，依然拥有强大的心理韧性和调试能力。不要让 AI 成为你的拐杖，而要把它当成一个能陪你深度探讨、甚至敢于挑战你的对手。
