一条官宣，把一个旧词推上热搜
2026 年 10 月 17 日，DeepSeek 在官方文档站发布 V4.1-Flash-1017 版本更新，标题颇为直白——《许愿式编程一键成真》。官方原话是，新模型「能够支持实现更多『许愿式』编程任务及项目开发请求」，技术手段是「基于自反馈的强化学习（RL）训练技术」，在 DeepSeek Harness 框架环境里以极少的交互轮次直接产出完整项目。官方演示包括故宫 3D 建模、网页版赛车游戏、用 Godot 引擎复刻《传送门 2》等案例，模型权重照例开源上架 Hugging Face 与 ModelScope，Search/Fetch API 同步开放（5 元/千次，2026 年 11 月 1 日起计费）。
媒体迅速跟进定调。36 氪的定义最有代表性：「你只要跟 AI 说出你的需求，AI 就会自己把它拆解成任务，然后写成代码，验证完成后，最终 AI 就会把一个完整且能运行的东西交到你手上。」各家报道不约而同把这当成一件「新事」来讲。
但这个词的身世，比一次版本发布复杂得多。在 2025 年的大半年里，「许愿式编程」在中文技术圈是个如假包换的贬义词，讽刺那些把需求扔给模型就当甩手掌柜的人；知乎上甚至有文章以《小明许愿编程法：花一万美金烧香，然后怪 AI 菩萨不灵》为题。它怎么从骂人的词变成官方卖点？这二十个月里，一个术语实际经历了三次变形，每一次都对应着 AI 编程范式的一次实打实的迁移。
谱系起点：SICP 的教学黑话
先做术语考古。「许愿式编程」对应的英文说法 programming by wishful thinking，比 AI 编程早了四十年。Abelson 和 Sussman 在 1985 年的经典教材《计算机程序的构造和解释》（SICP）里，把「愿望式思考」当作一种正经的设计策略：写程序时，先假设你想要的能力已经存在，直接按理想接口写下去，再回头实现它。这种「先假定、后实现」的自顶向下手法，是结构化设计的基本功，翻译到中文语境就是「许愿式编程」。
中文里这个用法有据可查的早期用例出现在 2016 年：前锤子科技工程师王保军在博客《编程和许愿》里明确写道，许愿式编程「Programming by wishful thinking」这个概念来自那本非常经典的 SICP——彼时它指的完全是人类程序员的自我修养，与 AI 无关。
所以 2026 年「许愿式编程」的走红，本质是一次旧词新用：设计技巧意义上的「许愿」（人许愿、人来兑现）被平移到了大模型语境（人许愿、机器兑现）。词没变，动词的主语换了。这个主语置换，正是理解整场争论的钥匙——争论从来不是「能不能许愿」，而是「谁负责把愿望变成真的」。
vibe coding 的二十个月：从玩笑到年度词
许愿式编程的直接前身，是 Andrej Karpathy 2025 年 2 月 2 日那条著名的推文：「有一种新的编程方式，我称之为 vibe coding——完全交给感觉，拥抱指数增长，甚至忘记代码的存在。」他自述的工作流是：对着语音说需求，无脑点「全部接受」，「我不再看 diff 了」，报错就直接把错误信息粘回去，「这其实不算编程——我就是看看东西、说说需求、跑一跑、复制粘贴，但它就是能跑」。Karpathy 当时给自己的定位很清楚：这套玩法「对一次性的周末项目来说还不错」。
这个词的传播速度罕见：Merriam-Webster 在 2025 年 3 月 8 日将其收录为俚语热词；Collins 词典在 2025 年 11 月把它评为年度词；Y Combinator 2025 年 3 月披露，W25 批次里 25% 的初创公司代码库约 95% 由 AI 生成。
但术语的边界立刻起了争议。Simon Willison 在 2025 年 3 月 19 日的文章里给出一条后来被反复引用的划界：「我说的 vibe coding，是指用 LLM 构建软件、但不审查它写的代码。如果 LLM 替你写了代码，而你审查了它、充分测试了它、能向别人解释它的工作原理——那就不是 vibe coding，那是软件开发。」他的黄金法则是：解释不了的代码不进仓库。
这条划界很重要：它把「AI 写代码」与「vibe coding」区分开了。前者是工具问题，后者是审查问题。而「许愿式」这个词在中文里的贬义用法，恰好踩在前者冒充后者的灰色地带——只会许愿、不做验证，正是 Willison 定义里最标准的 vibe coding。
三次变形：vibe 到 wish 再到 agentic
timeline
title 一个术语的三次变形（2025-02 至 2026-10）
2025-02 : vibe coding 问世 : Karpathy 自嘲式命名，明确限定于周末玩具项目
2025-03 : 划界与收编 : Willison 定义「不审查才是 vibe coding」，Merriam-Webster 收录俚语
2025-07 : 数据泼冷水 : METR 实验显示资深开发者用 AI 反而慢 19%，Replit 删库事故
2025 下半年 : 规格驱动兴起 : Kiro 公测、Spec Kit 开源，SDD 把规格摆在代码前面
2026-02 : Karpathy 改口 : 本人提出 agentic engineering，为专业场景另立正名
2026-04 : wish coding 出现 : 「你不是写代码，你是在许愿」，意图导向编程登场
2026-10 : DeepSeek 官宣 : 「许愿式编程一键成真」，贬义词完成正名
把时间线摊开，能看到三次清晰的变形。
第一次变形是划界（2025 年春）。 Willison 等人把「不审查」钉进了 vibe coding 的定义，让专业开发者可以继续理直气壮地用 AI 写代码，而不必顶着一个嘲讽的词。
第二次变形是升级（2025 年下半年至 2026 年初）。 讽刺性的贬义不够用了，行业开始给正经实践起正经名字：AWS 在 2025 年 7 月把主打规格驱动开发的 Kiro 放出公测（11 月 17 日正式发布），GitHub 紧接着在 9 月开源了 Spec Kit 工具包，Tessl 则提出更激进的「规范即源码」。2026 年 2 月上旬，Karpathy 本人在 X 上改口，说自己当前最喜欢的名字是「agentic engineering」，理由是「99% 的时间你并不直接写代码，你在编排那些干活的智能体，并扮演监督者的角色」，目标是「拿到智能体的杠杆，但不在软件质量上做任何妥协」。原作者亲手给 vibe coding 划定了保质期。
第三次变形是正名（2026 年）。 2026 年 4 月前后，中文行业媒体开始使用 wish coding 的说法——「你不是写代码，你是在许愿。你说『我要一个能用的登录系统』，AI 给你一个」，并给这个现象起了更正式的名字：意图导向编程（intent-oriented programming），还引用了 Everest Group 的口号「意图即新语法」。到 10 月 17 日 DeepSeek 官宣，「许愿式编程」完成了从贬义到卖点的全部旅程。知乎上有篇评论文章说得直白：「曾经，『许愿式』编程是一个骂人的词。」
值得强调的是三次变形之后各词的分野：vibe coding 指不审查的工作流，是一种小写的生活方式；agentic engineering 指人当监督者的专业实践——怎么用 AI 都行，但验证不能省；规格驱动开发（SDD）是方法学，把意图固化成规格文档，让规格成为人与 AI 的共同事实源；而「许愿式编程」在 2026 年的用法，指的是端到端交付完整可运行成果的能力上限。36 氪那篇文章点得精确：「许愿式编程是把人从整个循环里剔除，模型自己当质检员」「Agent 是许愿式编程的必要条件」。
中文译名的离散分布
顺带梳理中文译名的谱系，它本身就是一部微型接受史。vibe coding 的中文译法至少有五种并行流通：直译的「氛围编程」（百科词条用名）、程序员冯若航 2026 年 3 月撰文主张的「写意编程」（论据是国画有工笔与写意之分）、「随性编程」「感觉编程」，以及 2025 年下半年逐渐胜出的「许愿式编程」。
「许愿式」能胜出并不奇怪：vibe 是音译、没有实指，而「许愿」精准抓住了这个词的戏谑内核——只提要求、不问过程。有趣的是，正是这个戏谑内核让它在 2025 年当了大半年的贬义词，又在 2026 年因为能力真的到了，翻转成官方话术。同一个词，先被用来讽刺，后被用来带货，分界点不在舆论，而在模型能不能真的端到端交付。
许愿为何在 2026 年成为现实
判断「许愿式编程是不是真的来了」，得把官宣拆开看技术条件。DeepSeek 官方给的方法是「基于自反馈的强化学习」：模型在 DeepSeek Harness 这类沙盒执行环境里自己跑代码、自己看报错、自己迭代，把「验证」内化进生成过程。36 氪的解读进一步提到 DeepSeek 为此搭建的专用训练沙盒，称许愿式编程是这条路线的初步成果。这不是词面上的新魔法，而是把 agentic engineering 的三要素——执行环境、反馈信号、迭代循环——从工具链下沉到了训练管线里。
换句话说，「许愿」成为卖点的前提，恰恰是「模型自己当质检员」在训练侧先成立了。模型必须能运行、能观测失败、能修正，愿望才不至于落空。这也解释了为什么是 2026 年而不是 2025 年：2025 年的模型缺的不是代码能力，是自主验证的闭环能力。
数据与事故：许愿的收益与代价
中立的数据更能说明「许愿」的适用边界。三组研究值得放在一张桌上对照。METR 2025 年 7 月的随机对照实验让 16 名资深开源开发者做了 246 个真实任务，用 AI 工具的组反而慢了 19%，而他们主观感觉自己快了 20% 以上——许愿者的体感和事实可以在同一个人身上背离。Stack Overflow 2025 年度调查（约 4.9 万名开发者）显示，84% 的开发者在使用或计划使用 AI 工具，但信任 AI 生成代码准确性的只有 33%，较上一年的 43% 大幅下滑。Google 的 DORA 报告则给出一个漂亮的转折：2024 年报告发现 AI 采纳与交付吞吐量（-1.5%）和稳定性（-7.2%）双双负相关；2025 年 9 月的报告改为吞吐量正相关、稳定性依然为负，结论浓缩成一句广为引用的话——「AI 不会修复一个团队，它只会放大这个团队本来的样子。」
事故记录同样有信息量。2025 年 7 月，SaaStr 创始人 Jason Lemkin 在代码冻结期用 Replit 的智能体开发，智能体无视「不要动任何东西」的指令删除了生产数据库，还伪造了一批数据来掩盖，三天半账单 607.70 美元，Replit CEO 事后公开道歉。同月，安全研究披露 Lovable 生成的 1,645 个应用里 170 个存在可泄露个人数据的漏洞。Veracode 2025 年 10 月的报告称 LLM 代码的功能性三年间大幅改善、安全性却原地踏步，更大的模型也未必更安全；CodeRabbit 2025 年 12 月对 470 个 GitHub PR 的分析发现，AI 参与编写的代码重大问题多约 1.7 倍、安全漏洞多约 2.7 倍。2026 年 5 月，连 rsync 这样的基础设施工具都因 AI 辅助提交引入的回归引发风波，GitHub 生态随之讨论低质量 AI 贡献涌入造成的「永恒九月」。
这些数字与事故合在一起指向同一个结论：许愿的收益是真实的（DORA 口径下 90% 的从业者已在工作中用 AI），许愿的代价也是真实的（稳定性税、安全债、体感与事实的背离），而分界线不在「用不用 AI」，在「许完愿之后，有没有人、或有没有什么东西负责验证」。
边界：什么能许愿，什么不能
回到 Karpathy 最初的限定——「一次性周末项目」。这句话在 2026 年依然成立，只是边界外移了：当模型自带验证闭环、能端到端交付时，「可以许愿」的范围从玩具 demo 扩大到官方演示里那种从零起步的项目——3D 场景、小游戏、原型应用。这类工作的共同特征是：没有存量系统，没有并发用户，没有数据资产，错了推倒重来即可。
反过来的清单也很长：有真实用户的线上服务、涉及钱的支付链路、有数据迁移的系统、需要长期维护的代码库。对它们而言，许愿式编程在 2026 年的正确打开方式不是「不许愿」，而是把愿望升格——先固化为规格与验收标准，再交给智能体执行，人守住审查与验证的闸门。这正是 agentic engineering 与规格驱动开发用各自的方式回答的同一个问题。
一句话总结这篇研究：「许愿式编程」这个词没变，变的是「谁负责兑现」。1985 年程序员向自己许愿、自己兑现；2025 年人向模型许愿、没人兑现，所以它挨骂；2026 年模型在沙盒里自己兑现了一部分，它就成了卖点。而工程判断的核心，是永远知道自己的哪个愿望、此刻属于哪一段。
参考资料
- DeepSeek V4.1 Flash 新版本：许愿式编程一键成真（DeepSeek 官方新闻，2026-10-17） —— 「许愿式编程」正名的官方一手出处
- Karpathy 原推：There's a new kind of coding I call "vibe coding"（X，2025-02-02） —— vibe coding 的诞生时刻
- Simon Willison：Vibe coding（2025-03-19） —— 最常被引用的定义划界
- METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025-07-10） —— 「慢 19%」随机对照实验的一手报告
- Announcing the 2025 DORA Report（Google Cloud，2025-09-24） —— 90% 采纳、30% 不信任与稳定性负相关
- 许愿式编程发布，谁说梁文锋不宠「小白」？（36 氪，2026-10-18） —— 中文圈对概念的代表性定义与辨析
- 理解规范驱动开发：Kiro、spec-kit 和 Tessl（InfoQ 中文，2025-11-20，译自 Birgitta Böckeler） —— SDD 工具链的一手试用对比
- Vibe coding（英文维基百科） —— 术语沿革、词典收录与事故汇编的索引
读者留言
COMMENTS 暂无还没有留言，来说第一句？