用AI写代码到底靠不靠谱？一位写了40年代码的老程序员最近分享了他的真实体验。他在开发一个叫include-tidy的工具时，第一次把AI用在"正经项目"上，结果发现这东西既省大事，也埋大坑。
他的核心结论是：AI确实能帮你少读很多文档、少翻很多教程、少在Stack Overflow上等答案。但代价是——你得学会跟它"斗智斗勇"。
这位开发者用的是Google的Gemini，原因很实在：Claude要花钱，而这是个纯个人项目，不打算赚钱。在此之前，他只用AI写过小函数或者问问边角情况。这次用AI搭建完整的Libclang项目，是他第一次"大规模"使用AI。
关于提示词，他的态度很鲜明："提示工程"这个词被吹得太过了，"提示工程师"这个头衔跟"卫生工程师"差不多一个级别。但说实话，你确实得写得详细具体——就像在Stack Overflow上提问一样。
不过AI和论坛有个关键区别：你不会因为问题重复被骂，不会因为没看FAQ被嘲讽，不会被反问"你为什么要这么做"，也不会等好几天没人理。几秒钟就有答案。
听起来很美？问题是答案可能是错的。他遇到过两次，Gemini让他调用一个不存在的API函数。他指出之后，AI倒是认错了，改了答案。
更大的隐患是"猴子爪效应"——AI给你的答案技术上满足你的要求，但后果你想不到。比如他第一次给Gemini的提示词是：用clang的API写个程序，输入C或C++源文件，输出每个符号（宏、常量、函数、类型、变量等）及其声明位置，找不到就标"unknown"。
AI哗哗输出好几屏代码：该include哪个Libclang头文件、怎么初始化和清理、怎么解析源文件、怎么遍历抽象语法树。看起来完美运行。
但老程序员心里清楚：这段代码能跑，不代表没问题。AI不会告诉你哪些边界情况没处理、哪些内存没释放、哪些错误码没检查。它只回答你问的那句话，不多不少。
这大概就是AI编程的常态：省掉的是查文档的时间，省不掉的是审代码的精力。对于有经验的开发者，它是加速器；对于新手，可能是陷阱制造机。那位40年老程序员的态度很务实——用，但得带着脑子用。
热门跟贴