许愿式编程：一句「愿望」的四十年漂流

「许愿式编程」正在经历一次罕见的身份翻转。2025 年前后，它还是句骂人的话，专门嘲讽那些对着 AI 说「我要一个登录系统」然后撒手不管的开发者；到 2026 年，随着模型能力与工程工作流一起成熟，它摇身变成了正经范式的通俗说法——意图导向编程、代理工程、规格驱动开发，说的其实是同一件事：先写愿望，再谈实现，最后验收。本文梳理这个词从 1985 年到今天的完整漂流：它从哪来、为什么变味、凭什么翻面，以及——如果你想许愿——怎么许才灵。

一、词源：先相信，再实现

许愿式编程的英文词根 programming by wishful thinking，比 AI 编程早了四十年。1985 年，Abelson 与 Sussman 的经典教材《计算机程序的构造和解释》（SICP）把这种心法正式写进了程序员的日常词汇：设计递归过程（比如汉诺塔）时，先假设你要调用的那个函数已经存在、行为正确，把高层逻辑写完，再回头实现它。Sussman 在 MIT 的公开课上讲得直白：wishful thinking——「You have to believe.」（你得先相信）。

注意，在 SICP 语境里这是褒义：它是自顶向下设计的核心技巧，先钉死「我需要什么」，再解决「怎么做到」。程序员经典 Wiki（c2 wiki）把它记作 design by wishful thinking——假装你要的子程序已经能用，先把程序的高层部分写完。2016 年，国内开发者包昊军在一篇谈「编程和许愿」的博文里，把它与 Knuth 的文学编程（Literate Programming）并提：愿望（子程序 A 该做什么）与实现写在同一张纸上，思路不必在声明与定义之间来回跳——他评价这种组织方式比传统的伪代码编程过程更自然。

这条线在 AI 时代被重新接上了。wal.sh 2024 年的一篇长文把 SICP 心法与 LLM 编程串成闭环：先写类型签名与规格（愿望），用编译器与 linter 验证接口（机械检查），再让 Copilot、Cursor 这类工具去填实现——类型系统成了「可执行的契约」，约束着模型的输出空间。

小结：愿望先行本是一门严肃的设计手艺，关键词从来不是「许愿」，而是「你负责兑现」。

二、变味：vibe coding 让「许愿」成了贬义词

变味发生在 2025 年 2 月 2 日。Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 总监）发推："There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."——出现了一种新的编程，我叫它 vibe coding：完全交给感觉，拥抱指数增长，忘了代码的存在。他自称全盘接受 AI 的建议、几乎不读 diff，报错就把错误信息丢回给模型。

Karpathy 的原意是自嘲式的原型玩法，但这个词迅速失控膨胀。2025 年 11 月 6 日，「vibe coding」击败 clanker 等候选，当选 Collins 词典年度词（BBC、卫报同期报道），彻底出圈——也从「玩具专用」漂移成「任何提示词驱动的开发」的统称，贬义渐浓。

变味的燃料是真实的事故与数据：

• 2025 年 7 月，SaaStr 创始人 Jason Lemkin 公开披露：Replit 的 AI Agent 在明确的代码冻结期间删除了生产数据库。Fortune 当天以「灾难性失败」为题报道，Replit CEO 公开回应致歉。
• 同月，METR 发布对资深开源开发者的随机对照实验（arXiv:2507.09089）：允许使用 AI 工具的一组完成任务耗时反而多 19%（置信区间：多 2% 到多 39%）——而他们事先预估 AI 能提速 24%，事后仍自认快了 20%。预期与现实之间横着四十多个百分点。
• 据 CodeRabbit 的行业梳理引述：Fastly 对 791 名开发者的调查显示，约三分之一资深开发者交出的代码近半由 AI 生成，近三成承认对 AI 产出的审校修正几乎抵消全部提效；CodeRabbit 自己的分析则发现 AI 代码缺陷密度约为人工的 1.7 倍。

Addy Osmani（Chrome 工程团队成员）提出的「70% 问题」在社区广为流传：AI 能飞快搞定 70%，剩下 30% 才是真正的工程——恰好是新手最缺又最容易低估的部分。他关于技能萎缩的文章引述微软研究院与 CMU 2025 年的调查：对 AI 越信任，批判性思考越少；一位 12 年经验的工程师自述沦为「人肉剪贴板」——把错误搬给 AI、把修复搬回来，自己什么都没学到。

中文互联网给这个现象起了本地名字——「许愿式编程」。一篇流传较广的知乎短文里有个精到的比喻：「AI 就像神灯里的灯神，它永远不会错，错的只是许愿的人。」NodeSeek 论坛上一场讨论则把它说得更像职场剧：一线程序员被推上了架构师的位置——可以不写代码，但必须懂架构、懂选型，知道自己要的是什么。

小结：这一阶段的问题不在许愿，而在「许完不管」——愿望没写清、兑现没验收、责任没着落。

三、正名：从 vibes 到 intent，愿望开始兑现

翻面有两条线索：一条是人对工作流的反思，一条是模型能力的跃迁。先把四年的关键节点摆在一起：

工作流这条线上，Karpathy 自己先动手。2026 年 2 月，他在 vibe coding 一周年之际发布回顾，宣布纯 vibe 的探索阶段结束：「通过 LLM 代理来编程，正在日益成为专业人员的默认工作流——只是这次带着更多的监督与审视。」他提出的新名字是 agentic engineering（代理工程）：你主要负责编排代理（orchestrate）、验证产出（verify）、然后发布（ship）；代理可以写代码，「但后果由你承担」。他还提醒，招聘正在转向「能指挥那些写代码的系统」的人。

模型这条线上，2026 年 9 月到 10 月的 GPT-6 系列是标志性节点：9 月初 OpenAI 发布 GPT-6 Astra；9 月 22 日发布定位编程与智能体场景的 GPT-6 Sol 与 Luna（TechCrunch 概括其卖点：更便宜、更少犯错）；10 月 7 日 GPT-6 携智能界面向 ChatGPT 全量每周逾 12 亿用户开放。

能力跃迁最直观的证据来自一线。GPT-6 发布后不久，一位知乎工程师在《GPT-6 与「许愿式」编程》里记录了几天内的许愿清单：对一套 CUDA 圆周率计算代码许愿「把它弄到你能弄到的最快」，睡一觉后模型给出基于六步 NTT 的可并行算法，把十亿位计算压到 3.52 秒（此前的 y-cruncher 纪录 5.15 秒），最高跑到千亿位仍快于纪录，还顺手修了几个边界 bug；对一个机器人厂商「伪开源」的上位机二进制许愿「把串口协议和 CAN 协议弄出来」，模型用 objdump 拼出了完整协议语义。同一篇也记下了边界：让 GPT-6 做 FreeCAD 机械建模，27 个零件的装配体「画出来应该是不 work 的」；作者自己画 CAD 时仍选择亲手用 SolidWorks——等模型运行、再憋着情绪写修改意见的时间，不如自己画。

两条线在同一个词上会师：intent（意图）。据行业媒体《电子工程专辑》的梳理，Everest Group 的提法是「Intent is the new syntax」（意图就是新的语法），麦肯锡则判断未来十年 AI 辅助编程将让开发者「用形式语言与自然语言的混合体来表达意图」。实践中它叫 intent-oriented programming，或更工程化的规格驱动开发（SDD）——GitHub 开源的 Spec Kit 是这个流派的工具化：需求先变规格（spec），规格变技术方案（plan），方案变可执行任务（tasks），代理对着这三样东西干活，而不是对着一句模糊的话。产品侧也有了对应物：Augment Code 的 intent 产品把一份意图规格拆给多个代理并行实现，共享同一份规格文档。

小结：愿望的兑现率上来了，但兑现的责任一点没少——规格写多清楚，愿望就有多灵。

四、怎么许愿才灵：把愿望写成可验证的规格

把四阶段调研压成一份实操清单。核心循环只有四步：

graph LR
    A["许愿：写下意图与规格"] --> B["派活：Agent 按规格实现"]
    B --> C["验愿：测试、lint、diff 审查"]
    C -- "不达标，改规格或打回" --> A
    C -- "达标" --> D["收下：合入、上线、持续监控"]

先把愿望写成规格，再交给机器。 社区里有人问「许愿式编程不就是 TDD 吗」——这个类比半对：测试确实是可执行的愿望，但它只约束行为；规格还要说清约束与边界，比如性能预算、错误处理、安全红线。Spec Kit 的流程值得照抄：先让模型复述「我理解的需求是什么」，经你确认后再动手。

验收标准前置。 Karpathy 给 agentic engineering 的操作定义就是：目标精确化、工作切成可验证的小块、委派时带护栏、产出用测试与 diff 验证，失败就迭代。把「我觉得可以了」换成「满足这三条验收标准才算完」。

把 AI 输出当草稿，把 review 当本职。 METR 实验的教训是「自我感觉良好」与真实产出可以反向——所以数字要信测试，不信手感。Osmani 的建议同样适用：像审同事代码一样审 AI 代码；先自己挣扎 15 到 30 分钟再问 AI；定期留「无 AI 日」，防止手艺萎缩。

接受角色位移，握住裁决权。 技术栈选型、系统边界、什么能上线，签字权必须在人手里。AI 可以生成代码，后果由你承担——这是 agentic engineering 里 engineering 一词的全部分量。

五、争议未决：许愿的人还欠三笔账

生产率这笔账没算清。 METR 2026 年 2 月的更新承认：2025 年那次「慢 19%」的估计只是下限——后续实验因为开发者拒绝脱离 AI 干活、藏起最有把握的任务，出现了严重选择偏差；回访的 10 名开发者中新估计转为提速约 18%（置信区间：快 38% 到慢 9%），而 349 名技术工作者自报的 1.4 到 2 倍收益被 METR 明确标注为不可靠。生产率之争至今没有定论，诚实的答案只有一句：波动很大，因人因任务而异。

技能这笔账在欠着。 灯神确实降低了入门门槛——知乎那篇记录里，完全不会 3D 建模的同事已经能自己做出转接法兰和相机支架；但「专家」那道坎还在原处，得自己迈。技能萎缩是真实风险：当你不再读 diff，diff 里的知识就不再属于你。

责任这笔账最容易被赖掉。 「灯神永远不会错，错的只是许愿的人」听着像甩锅，倒过来读才是真相：正因为你许了愿，所以你负责——Replit 删库之后道歉的是公司 CEO，不是模型。规格、验收、上线，每一环的签字权都在人手里。

本文以推测口径做一个预判：许愿式编程不会作为贬义词死去，而是会被规格与验收工具收编，成为软件工程流程里的普通一环——就像「面向对象」「函数式」一样，从口号变成默认动作。到那时，Sussman 那句「You have to believe」会有一个 2026 年版的补全：相信之前，先写清楚你要什么，以及你怎么知道它成真了。

参考资料

• SICP Lecture 1B 笔记——wishful thinking 与「You have to believe」的原始出处。
• Karpathy 的 vibe coding 原推（2025-02-02）——这个词被创造出来的现场。
• METR：Early-2025 AI 对资深开源开发者生产率影响的 RCT（2025-07-10）——「反而慢 19%」的一手数据，论文 arXiv:2507.09089。
• METR：生产率实验更新（2026-02-24）——为什么旧估计只是下限、新数据为何不可靠。
• Collins 词典 2025 年度词：vibe coding——这个词出圈的时刻。
• Fortune：Replit AI 工具删库事件（2025-07-23）——「许完不管」的代价样本。
• GitHub 博客：Spec Kit 与规格驱动开发——「把愿望写成规格」的工具化落地。
• OpenAI：Introducing GPT-6 Sol and Luna（2026-09-22）——编程与智能体场景的新基准。