去年有个数据在开发者圈子里悄悄传开：GitHub Copilot的用户平均代码产出速度提升了55%。但另一组数据几乎没人提——同一批人里，43%在半年后承认"看不懂自己写的代码了"。
这两个数字把我架住了。作为产品经理出身的人，我对"效率提升"天然敏感，但对"失控"更敏感。所以当"氛围编程（vibe coding）"这个词开始泛滥时，我的第一反应是绕道走。
直到去年圣诞节前，我老婆问我能不能做个小工具：让全家人在群里共享"想要但不好意思开口要"的礼物清单。不是购物车那种，是能标注"已经买了别重复"的协作列表。我算了算，按传统方式写，得搭后端、做实时同步、处理权限逻辑——周末两天肯定不够。
于是我决定做个实验：用AI辅助写代码，但保留"我知道发生了什么"的底线。作者Andre Terron把这个叫"增强编程（augmented coding）"，我觉得比"vibe coding"准确得多。前者是工具，后者像玄学。
选技术栈，其实是在选AI的"母语"
Andre在文章里埋了个关键判断：技术栈的选择会极大影响LLM的输出质量。这不是玄学，是训练数据的统计学。
他选了Elixir——一门函数式编程语言，小众到国内程序员可能都没听说过。理由很有意思：不是因为它热门，恰恰是因为他"喜欢这门语言的设计哲学"，而且"学过一点，但没在生产环境用过"。
这个选择逻辑值得拆解。很多人误以为AI编程就该选最热门的框架，让模型"见多识广"。但Andre的观察更细：LLM对流行语言的掌握确实更深，但深度不等于适配你的需求。如果你选了一个自己完全不懂的技术栈，模型生成的代码再漂亮，你也分不清是优雅实现还是屎山堆砌。
他打了个比方：理论上LLM可以为你发明一门全新的编程语言，但人类程序员不会这么干——因为复用成熟的生态能借到别人的力。AI编程也一样，选技术栈的本质是选"你能验证正确性"的那个。
我最后选了Next.js + Prisma + PostgreSQL。 boring到不能再boring的组合，但每一层我都能独立调试。三周后App上线时，我发现这个保守选择救了我至少三次——当AI生成的SQL查询明显慢于预期时，我能自己写EXPLAIN ANALYZE定位问题，而不是对着黑箱祈祷。
"氛围编程"的幻觉：你以为在对话，其实在抽奖
现在回到那个被滥用的词：vibe coding。
Andre在文章里划了一条很多人忽略的线：这个词已经被严重超载了。它同时描述两种完全不同的开发模式——一种是100词的提示词直接生成完整App，另一种是几百词的详细描述只求一个10行的精准修复。
社交媒体上的演示视频几乎全是前者。一个提示词，咖啡还没凉，一个能跑的应用就诞生了。这种画面极具传播性，但隐藏了关键信息：你不知道这个提示词是第几次迭代的结果，也不知道镜头外有多少人工修补。
Andre的"增强编程"刻意选择了后者。他的workflow是：把问题拆成足够小的块，用精确的描述换取可预测的结果，然后人工验证每一步。这不是浪漫，是工程。
我在做礼物清单App时深有体会。第一次尝试让AI"直接写一个支持实时协作的wishlist应用"，得到的是个能跑但数据模型完全错误的demo——它把"礼物"和"购买记录"存在同一张表里，并发修改时直接丢数据。如果我是纯"vibe"状态，可能要到用户投诉时才发现这个坑。
切换到"增强"模式后，我的提示词变成了："用Elixir的Ecto ORM设计一个schema，要求：1) Gift和Purchase是独立表 2) 通过外键关联 3) 支持乐观锁处理并发更新"。结果一次通过，而且我能逐行解释为什么这样设计。
速度幻觉与质量债务
Andre提到一个现象：行业里充斥着"LLM让开发速度提升X倍"的宣称，以及"软件工程师即将失业"的恐慌。但他在文章里没直接反驳，而是选择用实践检验。
三周后，他的App上线了。数据点有了，但结论很复杂。
纯编码时间确实缩短了。那些他本来要查文档、试错的 boilerplate，AI几秒就生成了。但总时间并没有等比例下降——省下来的时间被重新分配到了"验证"和"重构"上。每当AI生成一段代码，他需要额外做三件事：测试边界情况、检查是否引入隐式依赖、确保风格一致。
更隐蔽的是"决策疲劳"。传统编程里，你做一个技术选择，脑子里有完整的推理链条。AI辅助时，模型经常替你做选择——用哪个库、怎么处理错误、要不要缓存——而这些选择被埋在生成的代码里，不仔细看根本发现不了。
Andre在文中引用了自己的反思：「我享受软件工程中的问题解决过程，而不仅仅是得到解决方案」。这句话听起来像老程序员的矫情，但背后有个硬核事实——当AI替你"解决"了问题，你失去的是对问题空间的建模能力。
我那个礼物清单App上线后，老婆用了两周，提了个需求：能不能让"已购买"状态对送礼人可见，但对收礼人隐藏？这个需求涉及权限系统的重新设计。我发现自己能快速定位到需要修改的模块，因为整个数据流是我和AI一起、一步步搭建的，不是凭空出现的。
如果当初完全"vibe"过去，我可能得先花半天理解AI生成的权限代码是怎么工作的——如果它甚至生成了权限系统的话。
那些"绝不碰AI"的人，和"All in AI"的人
Andre在文章里提到了另一极：他尊重的一些开发者明确表示"永远不会碰LLM，拒绝任何闻起来像生成式AI的代码"。
这个立场在2024年的技术圈需要勇气。但Andre没有嘲讽，而是承认"重要的伦理考量被提了出来"。他的态度是：与其争论谁对谁错，不如先做一个完整的实验，用结果说话。
我的观察更功利一些。完全拒绝AI的开发者，和完全依赖AI的开发者，其实在犯同一个错误：他们都把AI当成了需要站队的意识形态，而不是工具。
前者担心代码"不纯粹"，但软件工程从来就不是纯粹的手工艺术——我们依赖编译器、依赖开源库、依赖Stack Overflow。后者追求极致效率，却忽略了代码是写给人看的，附带能在机器上运行这个古老真理。
Andre的"增强编程"试图走中间道路：用AI处理机械劳动，保留人类在架构设计和质量把关上的主权。这不是妥协，是分工。
他在技术选型上的另一个细节印证了这一点：虽然用AI生成代码，但部署和运维完全手动。Dockerfile是自己写的，CI/CD管道是自己搭的，监控告警是自己配置的。这些"基础设施"没有交给AI，因为一旦出问题，他需要知道从哪里开始排查。
3周后，我的残酷真相
礼物清单App最终有47个用户，全是家人和朋友。数据很小，但足够回答我最初的问题：AI编程到底改变了什么？
我的结论是：它改变了"写代码"的边际成本，但没有改变"做好软件"的总成本。
那些省下来的打字时间，被转移到了更隐蔽的地方——设计更精确的提示词、验证AI的假设、重构它生成的过度工程化方案。有个周末我花了4小时，只为让AI理解"不要为这么简单的东西用Redis"，最后干脆自己动手写了内存缓存。
Andre在文章结尾没有给宏大判断，只提供了一个数据点：他用这种方式做了一个能解决真实问题的应用，现在他"开始在AI/LLM评估的广阔光谱中找到自己的位置"。
我的位置大概是这样的：AI是极好的副驾驶，但前提是你要知道目的地在哪，而且能随时接管方向盘。如果你连地图都不会看，副驾驶开多快都救不了你。
那个礼物清单App现在还在跑。上周我老婆说，她妹妹也想给男朋友做一个类似的，问能不能直接用我的代码。我打开仓库，花了20分钟给她讲清楚数据模型和部署流程——这20分钟的存在，证明了三周前我做的那些"非效率最优"的选择是对的。
如果完全交给"vibe coding"，我现在可能只能转发一个链接，然后说"我也不知道怎么工作的，但能用"。
你现在的项目里，有多少代码是你能向同事逐行解释的？又有多少是"AI写的，应该没问题"？这个比例，可能比任何效率指标都更能预测你六个月后的技术债务。
热门跟贴