“许愿式编程”这词，我第一次听到时也觉得像句玩笑——动动嘴，代码全让 AI 写，能出什么真东西？有人说得更直接：那不叫编程，叫赛博求签。
我一开始也这么想。但后来 DeepSeek 在 2026 年 10 月 17 日推 V4.1-Flash-1017 的时候，官方文档里白纸黑字写着“许愿式编程一键成真”。一个段子被写进 API 文档，这事就值得重新看一眼了。
不过光看官方说法还不够。真正让这个说法落到地上的，是个容易被忽略的名字：dsh。我想先把这个词说清楚，再回头聊许愿式编程到底比之前的说法多了什么。
许愿式编程，比 vibecoding 多了什么
先说关系。许愿式编程不是从石头里蹦出来的，它是从 vibe coding 的讨论里长出来的，但两者对人的要求不一样。
Vibe coding 的核心是“凭感觉一起写”。你多少得有点技术直觉，知道代码大概在干嘛，方向偏了能拽回来。许愿式编程把这步也省了——它说，你不需要知道代码长什么样，你只要说出你的愿望。
DeepSeek 官方的定义更具体：用自然语言描述需求，AI 自主开发，减少人工干预，不需要太多轮来回。还有一句我觉得更关键——在“较少的提示词和素材参考条件下”，从零搭一个完整项目。
撑住这个承诺的是“基于自反馈的强化学习”。模型自己生成、自己判断、自己修正，把人从“生成—检查—调整”这个循环里尽量往外挪。官方放的案例有故宫 3D 建模、网页版赛车游戏、用 Godot 复刻的《传送门 2》场景。这些不是“写个函数”，是“交一个能跑的东西”。
所以粗略概括一下：vibecoding 是“一起写”，许愿式编程是“说完等收货” 。后者更激进，也更靠模型自己兜底。
但这里我得停一下。上面说的是官方定义和演示案例，不等于随便谁随便说一句都能拿到同样的结果。这个边界我后面还会回到。
dsh 是什么，为什么它比概念本身更值得看
如果许愿式编程只停在“对着对话框说一句话”，它大概率还是段子。让它从一个说法变成一套能操作的流程的，是 dsh——DeepSeek Harness。
DeepSeek 在 V4.1-Flash-1017 的发布说明里写得很明确：新模型针对 DeepSeek Harness 做了专门优化，建议升到 dsh 0.2.1-rc.1 及以上版本，才有“最优体验”。官方演示里那些从零搭的项目，也是在 DeepSeek Harness 环境里跑完的。
我理解 dsh 是许愿式编程的运行容器。愿望要落地，得有工程约束接着：任务怎么拆、第一轮想什么、工具链怎么调、什么时候该打断、什么时候让模型自己往下走。模型负责“想”和“写”，dsh 负责让这个过程能重复、能控制、能交付。
社区的反应比我想的快。GitHub 上有个叫 dsh-minimal-turbo 的项目，直接在 dsh 里做了个“许愿模式”（wish mode），跟“极简模式”并列。它的思路挺有意思：不靠模型硬想，而是用提示词约束第一轮思考，打断“雷霆思考”那种闭门造车的状态，让模型更快进入能用的产出节奏。
官方定范式，社区把它做成模式开关。到这一步，许愿式编程就不再是悬在半空的概念了——它有了自己的操作界面。
谁在真的许愿，许愿的边界又在哪
这里我想说个容易被忽略的事：许愿式编程最先改变的不是程序员，是那些一直有做工具的冲动、但被“写代码”挡在门外的人。
我看到一位非程序员的实践者，用许愿式编程在半年里做了 12345 数据分析看板、政府采购监督工具、医保基金筛查系统，还有一个自用的刷题 App。他的刷题软件第一版 10 分钟就出来了，两天迭代了几十个版本。他总结的一句话我觉得比很多技术讨论都准：软件难的从来不是写代码，是想清楚要什么。天天泡在业务里的人，恰好最知道哪里疼。
但这套模式的边界也很清楚。开发者的实测反馈相当一致：单人小项目、独立 demo，它确实能打；一到企业级、系统级的题目，就普遍做不完。
我觉得原因不在模型“不够聪明”。写软件从来不是一轮对话的事。需求拆解、联调、边界情况、回归测试，大量隐性成本发生在对话之外。许愿式编程压缩的是“从愿望到第一版能跑的东西”的距离，但“能跑”和“能用”之间，还隔着安全、健壮、可维护这一长串东西。
社区里也不是没人踩坑：数据被误删、接口裸奔、密码硬写进文件、逻辑只覆盖了最常见那一档。这些不是许愿式编程独有的问题，但门槛降下来之后，没有工程直觉的人更容易把“生成”误读成“可靠” 。
那我到底怎么看它
我自己的判断，介于“封神”和“翻车”之间，而且偏保守。
它真正做到的，是把软件开发的起点拉低了。过去一个会计、一个老师、一个开小店的人，脑子里有个小工具的想法，面前只有两条路：学几个月编程，或者花钱找人。现在多了第三条：把愿望说清楚，当天拿到一个能跑的东西。这部分被放出来的创造力，是我觉得门槛下降最值得看的地方。
但“许愿”不等于“放手”。那位做刷题 App 的实践者说得很直白：许愿人得在场，AI 想偏了要拉回来。愿望的质量，就是软件的质量。
而 dsh 的意义，我理解是它想把“在场”这件事工程化——不靠人一直盯着，而靠框架、模式、约束，让许愿式编程从一次性的“赛博求签”，变成一套有底座、能重复的开发方式。
不过这话我也只说一半。dsh 能不能真的把“在场”接住，还要看它在更多真实项目里的表现，现在下结论偏早。
赛博求签求出来的是签文，许愿式编程做出来的是工具。区别不在 AI，在许愿的人，也在许愿的人手里拿的是不是一把能收住力的工具。