别让 AI 编程成了你的“认知拐杖”：聊聊技能习得中的摩擦力

习惯了用 Claude Code 或 Cursor 这种工具后，最可怕的不是效率提升，而是那种“不用思考就能出代码”的快感在悄悄偷走我们的深度思考能力。很多新手直接把需求丢给 AI，代码跑通了就直接 Merge，这种缺乏“摩擦力”的开发模式，长期来看会导致开发者在面对复杂架构或深层 Bug 时完全丧失分析能力。

真正的专家级能力，往往产生于那些由于“不方便”而被迫思考的时刻。当你为了解决一个内存泄漏问题在调试器里死磕 4 小时，或者为了优化一个查询语句去翻阅数据库底层文档时，你的知识体系才是在真正构建。而 AI 抹平了这些痛苦的路径，虽然交付速度快了，但知识的内化程度却极低。

为了防止自己在这个过程中逐渐“平庸化”，我给自己设定了一套 AI Coding 实战的工作流，核心就是人为地制造一些“必要的摩擦”：

一、 强制性的“逻辑前置”习惯

在输入任何 Prompt 之前，我禁止自己直接写“帮我实现一个 XX 功能”。相反，我会先在本地的 .md 文档或白板上写出逻辑伪代码。

比如，在处理一个复杂的异步状态同步逻辑时，我会先定义好状态机：

graph TD
    Idle --> Loading
    Loading --> Success
    Loading --> Error
    Success --> Updating
    Updating --> Success

只有当我把逻辑链路理清楚，并且能用自然语言描述出 if-else 的边界条件后，我才会把这个逻辑大纲喂给 AI，让它负责具体的语法实现。这样 AI 成了我的“打字员”，而不是我的“架构师”。

二、 拒绝“一键采纳”，建立 Review 审计机制

很多人的习惯是 Cmd+K 生成代码 → Tab 采纳 → 运行通过 → 下一步。这太危险了。我现在的做法是，对于 AI 生成的任何非琐碎代码（超过 10 行的逻辑），必须强制进行一次自审。

我会重点检查以下三个维度：

• 复杂度分析： 这段代码的时间复杂度是多少？AI 是否为了快速实现而使用了低效的嵌套循环？
• 边界覆盖： 如果输入是 null、空数组或极大值，这段代码会崩吗？
• 依赖污染： 它是否为了解决一个小问题引入了一个巨大的第三方库？

三、 刻意练习：脱离 AI 的“离线时段”

我每周会强迫自己花 2 小时关闭所有 AI 插件，纯手工写一个核心模块。在没有补全提示的情况下，你会猛然发现自己其实不记得某个 API 的具体参数顺序，或者对某个框架的生命周期理解有偏差。这种“不适感”就是最好的学习信号。

如果你想尝试这种从入门到进阶的深度学习法，可以试着在配置 .cursorrules 时加入一些限制性指令，比如：

{
  "instruction": "When suggesting a solution, do not provide the full code immediately. First, explain the logic and the trade-offs of the chosen approach, then ask me if I agree before generating the implementation."
}

这样强迫 AI 先出方案而非直接出代码，能有效增加你与代码之间的交互摩擦，防止大脑进入“自动驾驶”模式。

总结来说，AI Agent 应该被当作一个极其高效的初级程序员，而你必须始终扮演那个审慎的资深 Reviewer。失去摩擦力的学习是极其脆弱的，只有在解决问题的痛苦中，才能真正形成所谓的“专家经验”。