汉字魔法师
118.67M · 2026-02-04
用了AI写代码18个月，我发现一个真相，聊聊我的所思所想。
以前我觉得AI就是个工具，用它就是让它帮我干活。
但有个观点挺对的：AI更像是一个初级工程师，你需要引导它、培养它，甚至还要驯化它。
因为AI有默认的一些思维模型：它想尽快完成任务，然后获得你的表扬。
这会导致什么问题？
它会做一些看似正确但实际上很蠢的决策。
举个例子，比如你让写测试，他很多时候会各种mock数据，让你的测试完美通过，实际上你的业务代码是一个没测到，又比如你让他解决死锁问题，他竟然想出让进程休眠2秒这种离谱的方案。
为什么？
因为这样能快速解决问题啊！但这是不是基于当前业务规范的解决方案？它不在乎。
所以你需要的不是简单地使用AI，而是要引导它用正确的方式做事。
比如在提示词里强调要用规范的方式。
不要说：解决这个问题
要说：用一个规范的方式解决这个问题
还有，不要让它直接写代码，要它先解释清楚这个函数的意图。
这些细节挺重要的。
这点太关键了，很多人要么过度吹AI，要么过度黑AI。
用了一年半AI编程助手后，我有几个挺实在的总结。
写业务逻辑代码
这点我也有体会。
普通的增删改查、API接口、数据转换这些业务逻辑，AI写得比我快，有时候质量还真不错。
听着扎心，但确实是事实。
找bug
这个真的强。
我用到现在，还没遇到AI找不到的bug。
你只要描述症状，它能读代码、分析、找到根因。然后你让它解释为什么会这样，你会发现它的分析是对的。
有时候遇到复杂的bug，我会让AI先建立自己的心智模型，然后再找bug。
这样能找到一些很隐蔽的问题。
理解烂代码和栈追踪
AI真的很擅长读那些让人头大的烂代码，还有那些超长的报错堆栈信息。
这对接手别人项目、排查线上问题太有用了。
前端界面的持续迭代
我用AI写网页界面和终端界面，效果都不太好。可能刚开始还行，迭代迭代着就容易
崩，只有崩了一次，就很容易原地打转。
复杂的性能优化
前面说的死锁那个例子就很典型。
AI会想一些看似能解决但实际很蠢的方案，比如让进程休眠2秒。
要让它找到好的解决方案，你需要非常具体地引导它。
需要深层理解的架构决策
AI能生成代码，但它不真正理解你的系统。
它不知道你的业务场景、性能要求、团队情况、技术栈历史。
所以架构层面的决策，还是得靠人。
总结了几个很实用的技巧，可以借鉴一下。
在提示词里强调要用规范的方式。
不要说：解决问题
要说：用规范的方式解决问题
不要说：写个测试
要说：写个测试，关注被测函数的意图
这些小细节会让AI生成的代码质量提升很多。
在找复杂bug时，我会先让AI建立自己的心智模型。
让AI先理解系统的整体架构、数据流、关键组件，然后再让它分析问题。
这个架构说明，更需要在工作中进行实时更新，维护好整体的项目说明
结对编程大家都知道，两个人一起写代码，互相评审、互相讨论。
我觉得：AI就是你的结对编程伙伴。
但它不是一个经验丰富的高级工程师，更像是一个需要你指导的初级工程师。
你要做的是：
你现在就是AI的编辑，不是写代码的人。
用了一年多的AI编程助手，我有几个很真实的感受。
以前我觉得程序员的价值在于写代码的速度。
但现在看来，这个价值正在快速下降。
因为AI写得比你快、比你准（在某些场景）。
那程序员的核心价值变成什么了？
我觉得是：
有句话让我印象深刻：手写代码仍然有乐趣和价值，但不要指望这是你的工作。
这话听着有点扎心，但确实是现实。
就像现在还有人手写汇编、手写C语言，但这不是主流开发者的日常工作。
也许以后手写代码也一样，变成了一种情怀，一种爱好，而不是谋生手段。
ai编程了一段时间后，我的最大启发是：不要把AI当工具，要把它当伙伴来培养。
它不是一个完美的助手，它有缺陷、有盲区。
但你如果你去引导它、驯化它，它真的能成为你最好的配对编程伙伴（也许未来都不需要太多的引导）。
编程在进化，程序员也在进化。
这不是坏事。
就像从汇编到C，从C到Java，每一次进化都让程序员从繁琐的细节中解放出来，专注于更重要的事情。
AI编程也是一样。
我们只能拥抱变化，而不是恐惧它。
