夜雨聆风今天下午没啥事，比较闲，去书架上那扫了一圈，发现一本好多年前买的《摩托车维修艺术与禅》，都落了不少灰在上面了，随手就拿下来翻了翻。
偶然翻到里面一段话，觉得还挺有意思的，说的和时下AI编程中遇到的问题居然能对上。
他说，优秀的维修师傅与摩托车融为一体，扳手不是工具，是手指的延长线。
他管这叫"关怀"，对比到软件开发领域，意思大概是：你在乎这段代码写得怎么样，不只是能不能跑。你还在乎命名是否准确、结构是否清晰、接手的人会不会骂你。
现在不正是AI工具越来越强，而我们和代码之间的关系却在慢慢变得疏远，那还会有书中所说的这个"关怀"吗？
AI编程带来的效率提升是真真实实的，没人能否认。
但有没有想过这效率背后付出了多少代价？
过去写代码，要从第一行开始建立起对系统的认知。具体到变量命名、条件、异常处理，每一处细节都是在脑子里跑过一遍之后做出的决定。
这个过程确实会很慢，但就是它，在大脑神经回路里刻下了对系统的直觉。
现在的AI Coding典型的开发方式：我负责描述需求，AI生成代码，跑通个测试，合并。快的很，分分钟完成一个需求。
但要说对这段代码的理解，那就只是停留在"它通过了测试"这个层面。
万一要是出了问题，第一反应也不再是看调用链，而是再把错误信息复制给AI，让他来解决。
调试直觉的弱化是一件非常难察觉的事情。
以前调试过程：看日志、设断点、然后一步一步排查，这个调试过程本质上就是在训练对系统的感知能力，对代码逻辑的直觉。
我们心里知道哪些模块容易出bug，看到异常信息就能大致定位。
这种直觉不是天赋，是大量手动调试过程中积累出来经验、第六感。
AI Coding则跳过了这个过程，直接给你答案，让你没法积累出直觉。
还有那虚假的效率感，感觉产出翻了几倍，其实吧，基本上也就干了"代码审核员"的活，有时候这都没好好干。
审核和创作需要的能力完全不同。如果长期只做审核，创作能力肯定是会退化的。
书中提到了一个概念："人机合一"。如何做到识别"人机合一"，核心区别就在于控制权在哪。
如果AI的角色是编程伙伴、助手的时候，这叫做人机协作，你仍然是思考的主体。
你负责设计架构，然后让AI来对这个架构方案进行验证。
调试问题时，让就AI提供一些人可能忽略的角度来作为参考。
这样AI既能提供强大的支撑，又不会打断你的思维心流。
反过来，如果AI成了决策主体，由它来选算法、定接口、决定设计模式，你实际上退出了创作过程。
你的工作变成了把需求翻译成prompt。
虽然确实产出了很多代码。但有成长了吗？
我觉得：项目的核心逻辑代码还是要手写，外围那些重复性的工作可以交给AI，写完了再让AI补测试、补注释。
针对像CRUD、模板代码、文档生成、正则表达式这些场景，逻辑简单，工作繁琐，就大胆让AI做。
如果涉及到架构选型、接口设计、复杂算法还是最好自己上，让AI打辅助。
我觉得应该有这么一个判断标准：如果这段代码出了bug，你能不能在没有AI的情况下解释清楚？
如何才能在当前AI编程的大趋势下保证自己对代码的直觉？
不妨试试：每周半天不用AI。关掉Copilot，Cursor,trae，CodeX,关掉聊天窗口，就自己和IDE。我试过，要不了多久，半小时后那种"自己在思考"的感觉回来了。
这个方法的价值不在于产出，在于确认你的独立开发能力还在？
让AI多做解释类工作，少做决定。
技术方案务必自己选，让AI只负责提供决策相关的信息：每个方案的利弊、适用场景、已知问题，决定权必须在自己手上。
检验标准也很简单：如果你无法向别人解释清楚为什么选这个方案，说明这个决定不是你做的。
AI会犯错，而且犯得很自信，幻觉不是偶尔出现的bug，是它的固有特性。
所以，AI输出都必须通过测试，核心逻辑需要人工review。
就像你不会不review就合并同事的PR是一个道理的，何况现在大部分人对AI的定位是一个很努力的实习生。
在AI时代，开发者的核心竞争力不是写代码的速度，而是这种控制力，对代码的判断力和直觉。
知道什么该认真、什么可以将就、什么绝对不能妥协。
这种判断力来自经验，来自踩过的坑。