关于 AI Coding 的一些思考
做RobustMQ时，我一直在想：当AI能快速生成代码、Claude和Cursor成日常工具时，我们写代码的人，核心竞争力还剩什么？
这不是杞人忧天。身边不少工程师，包括曾经很强的人，已明显依赖AI。我自己有时也有这种依赖。
一个让人不安的观察
过去一年，明显趋势：身边工程师越来越多依赖AI写代码。需求来，先问Claude怎么实现；AI给代码，复制粘贴；能跑就提交。整个过程十几分钟，效率惊人。
我理解诱惑，谁不想轻松、高效？但更不安的现象：这些高度依赖AI的工程师，技术能力在肉眼可见地退化。
上个月遇一朋友，两年前手撸分布式系统，底层理解深。现在基本不手写，全靠Copilot。问并发问题，半天说不清。他说："细节越来越不敏感，离开AI慌。"
还有次Code Review，一段循环重复分配内存的代码。同学说AI生成，"能跑就行"。指出性能问题，他说："确实，不知道怎么改，让AI优化吧？"
这些小事让我思考：AI提升效率的同时，是不是在悄悄掏空我们的能力？
AI的根本限制
很多人担心AI完全替代工程师，这种担心基于错误假设：AI能达到100%智能。
实际上，AI有根本限制。不理解"为什么"——知道怎么写代码，但不懂为什么要这样设计系统。不创新——只能重组已有模式，无法突破性架构。不理解真实场景——如RobustMQ的缓存一致性问题，AI发现不了这些痛点。不做权衡——面对性能vs可维护性选择，AI给不出基于项目实际的判断。
更重要的是，工程本质不是写代码，而是解决问题。真正工作是：理解需求、定义方案、设计架构、优化性能、排查问题、做关键决策。写代码只是环节，往往不是最重要的。
AI可以辅助写代码，但理解问题、设计方案、做出判断、承担责任，这些核心工作必须人做。
所以不是"工程师没价值"，而是"简单编码价值降，复杂工程价值升"。AI降低初级门槛，提高高级要求。未来属于深入理解技术、解决复杂问题、驾驭AI工具的工程师。
能力退化与技术直觉的丢失
编程能力不是学会了就永远拥有的知识，更像是需要持续锻炼的肌肉。长期不练，就会萎缩。
我自己就有体会。去年项目赶进度，大量用AI生成代码。两个月后，手写算法时才发现：以前信手拈来的实现，现在要想一会儿；以前一眼能看出的优化点，现在要仔细思考。才两个月不手撸，能力就开始下降了。
朋友们也有类似感受："不用AI写代码，感觉特别不适应，就像开惯了自动挡，突然换手动挡。"更可怕的是，这种退化悄无声息。你不会突然发现"我不行了"，而是在某个时刻意识到：复杂问题定位变慢了，看代码没感觉了，性能优化没手感了。
当你习惯了AI，重新手撸代码会觉得痛苦、缓慢、笨拙。大部分人会继续依赖AI，于是退化成为不可逆趋势。
这种退化最致命的，是技术直觉的丢失。写RobustMQ消息引擎时，我盯着代码看了几分钟，总觉得不对劲。分析后发现：数据结构没对齐cache line，导致false sharing。改了之后，性能提升15%。这种"哪里不对劲"的感觉，就是技术直觉。
技术直觉不是天生的，是手撸上万行性能关键代码、踩无数坑后形成的。你处理过各种并发问题、优化过内存布局，慢慢就能看到代码就感觉到哪里可能有问题。
但这种直觉非常脆弱。不再手写核心代码，不再深入底层，不再亲手优化，半年后直觉就开始变弱，一年后可能完全消失。
AI生成的代码能跑，但往往不够优化。它不会考虑cache对齐，不会优化分支预测，不会用SIMD指令。有技术直觉的人能看出这些问题并手动优化。没有直觉，就只能接受次优代码，永远达不到极致性能。
做基础软件，性能就是核心竞争力。RobustMQ要微秒级延迟，每一微秒都要抠出来。这种优化，AI做不了，必须靠人的经验和直觉。
核心代码必须手写
不是所有代码都要手写，但核心代码必须自己写。
性能关键路径必须手写。消息队列核心逻辑，每一次调用都影响延迟，每一次内存分配都要考虑。AI写不好这种代码，需要理解底层的工程师精心打造。CPU缓存对齐、分支预测、SIMD指令，这些细节决定性能天花板。
架构核心抽象必须手写。关键trait定义、模块接口、数据结构选择，决定架构扩展性和优雅性。AI给通用方案，做不出针对性优化设计。需要深刻业务理解、前瞻技术思考、准确权衡判断。
疑难问题修复必须手写。生产诡异bug、性能骤降、偶现崩溃，需要深入系统底层，结合日志监控源码经验排查。AI给建议，但定位根因、设计解决方案，还得靠人经验直觉。
创新功能必须手写。从未有特性、突破性优化、独特方案，没现成参考，AI基于已有知识，给不出真正创新。RobustMQ多协议统一内核，这种架构设计必须人来做。
重复性代码、标准化模式、大量测试，可以用AI生成，人来Review优化。这不是偷懒，而是把时间花在更有价值的地方。关键是能看出AI代码问题并优化，这本身就需要深厚功力。
两条发展道路
五年后、十年后，哪些工程师会被淘汰，哪些会越来越值钱？
第一条路：依赖AI的舒适区
刚开始爽。用AI写代码，效率翻倍，产出很高。第一年可能还被表扬"效率高"。
但第二年、第三年，问题显现。底层知识模糊，不记得系统调用，不确定并发细节。但AI知道，问问就好。
再过两年，手写代码能力下降。现场写代码不适应，就像开惯自动挡换手动挡。但平时工作，AI都搞定。
第五年，遇到AI解决不了的复杂问题，完全卡住。同事们已成高手，自己却离不开AI。想重拾手感，已找不回当年的感觉。
这条路看似轻松，实则透支未来。
第二条路：保持硬功夫
这条路更累。核心代码坚持手写，每行都思考为什么。生产问题亲手解决，熬夜排查root cause。性能优化亲手做，一微秒一微秒抠。
第一年觉得慢，别人十分钟搞定，自己写一小时。但这一小时，积累真功夫。
第二年、第三年，底层理解加深，直觉敏锐。看代码一眼看出问题，定位bug有思路，做优化有手感。同时学会用AI提效，但它是助手，不是依赖。
第五年，手写能力加AI工具，产出是原来的三倍。更重要的是，能解决别人搞不定的问题。复杂并发bug、诡异性能问题、创新技术方案，只有自己能搞定。
这条路当下累，但长期竞争力强。
如何正确对待AI与实践
我不是反对用AI，自己也用。关键是怎么用。原则是：人先思考，人做核心，AI辅助细节。
遇到问题，我不会直接问AI。先想清楚：问题的本质是什么？解决方案有哪些？权衡在哪里？哪个适合我们的场景？想明白后，再用AI辅助实现。
核心逻辑必须手写，比如消息调度算法，这决定系统性能和正确性。每一行代码都要理解为什么这样写，每一个数据结构都要考虑性能影响。
辅助代码可以用AI生成，如配置解析、错误处理、测试框架。但生成后必须仔细Review，理解每一行，优化不够好的地方。如果解释不清楚某段代码为什么这样写，就说明没真正理解，不能用。
Review AI代码的过程，就是保持技术敏感度的过程。要能看出冗余、性能问题、不够优雅的地方。这需要扎实的语言、算法、系统原理基础。
那些用好AI的工程师，往往底子扎实。他们知道AI的边界：什么时候用，什么时候不用；知道AI代码的坑在哪里，如何优化。那些只会用AI的人，要么底子不行，要么被AI拖垮了。
AI是放大器，让强者更强，也暴露弱者的不足。
但用好AI的前提，是保持在一线。有人说高级工程师只做设计决策，不用写代码。这是危险误区。
好的架构设计必须基于实战经验。没有手写高性能代码，怎么知道哪种设计性能更好？没处理过生产故障，怎么知道哪里容易出问题？没优化过内存，怎么判断架构是否有瓶颈？
我见过脱离一线的"架构师"，图画得很漂亮，理论讲得头头是道，但实现起来问题百出。因为失去系统感觉，"小问题"其实是大坑。
真正厉害的人都保持一线。Linus七十多岁还在Review Linux patch，因为知道脱离代码就会失去理解深度。
做RobustMQ时，我一直手写核心代码。存算分离调度、消息路由优化、MQTT协议关键部分，都亲手实现。不是别人写不好，而是只有亲手写过，才能真正理解系统，做出正确决策。
有次讨论新特性，我以为很简单。但手写代码时发现改动巨大，会影响性能。如果没动手，可能就做错决策。
远离一线，能力就会退化。不管你以前多强，不管你title多高。
未来属于谁
AI会让工程师分化更明显。
一部分人因AI变得更强。保持手写核心代码、底层理解、一线实践能力，同时善用AI处理重复劳动。这些人的产出可能是原来的两三倍，解决复杂问题能力更强，技术判断更准。他们将成为行业最稀缺的人才。
另一部分人因AI变得更弱。过度依赖AI，不再手写代码，不再深入底层，能力持续退化。五十年后，当需要真功夫时，发现自己什么都不会。他们的"会用AI"技能不再稀缺，失去的"硬核能力"才稀缺。
市场会投票。十年后回头看，坚持手写代码、保持技术深度、一线实践的工程师，会是最值钱的人才。而过度依赖AI、能力退化的工程师，会越来越难找到机会。
这是时代分水岭，也是每个工程师的选择。
选择艰难路，保持硬功夫，长期走得更远。