10月17日下午，DeepSeek把V4.1 Flash更新到了V4.1-Flash-1017。

官方文档里有一句话写得很直接：在提示词和素材参考极为有限的条件下，直接生成可运行的项目成果。它管这个叫“许愿式编程”。

我第一反应是夸张。一句“做一个3D项目”，真能出来一个能跑的东西？

翻完官方示例和基准数据之后，我信了一半。翻完GitHub上那条issue之后，另一半也信了，但多了一个新的担心。

官方示例没只给PPT，四个项目全都能跑

DeepSeek放了四个示例，全部是在DeepSeek Harness框架内跑出来的，交互轮次极短。

第一个是故宫3D建模。镜头从空中掠过一层层金色屋顶，再落到宫门前。红墙、琉璃瓦、中轴线的空间关系都在。它不是一张图，是一个可以在浏览器里拖拽旋转的3D场景。

第二个是网页版赛车游戏。有赛道、有车、有操控，能跑起来。第三个更离谱——基于Godot引擎复刻了《传送门2》的核心玩法。第四个叫Valley of Ages，用3D场景动态展现从史前到现代的发展历程。

这些不是“生成一段代码给你复制粘贴”，是Agent在Harness里自己搭环境、写文件、跑测试、修bug，最后交付一个能打开的东西。

官方给的定位很克制：“提升从零开始构建完整项目的能力”。但“从零开始”这四个字，放在半年前，是资深工程师带着团队干几周的事。

基准测试全面上涨，但有一个数字比涨幅更值得看

官方公布的对比表信息量很大。

Terminal-Bench 4.0从31.2跳到42.3。这个测试考的是多步骤终端操作，涨了三分之一还多。DeepSWE v1.1从74.2到77.0，ProgramBench从20.3到29.1，Automation-Bench从54.8到60.5。

但真正让我停下来的是横向对比里的两个数字。

Terminal-Bench 4.0上，V4.1-Flash-1017的42.3高于GLM 5.3的37.9和Kimi K3的12.6。Kimi K3只有12.6——这个分数低得有点反常，可能是测试框架（Claude Code）对Kimi的适配问题，也可能K3本身在纯终端操作任务上就不是强项。不管原因是什么，这个差距说明“谁更强”这件事极度依赖你测的是什么。

DeepSWE v1.1上，V4.1-Flash-1017的77.0超过了GPT 5.6-Sol的73.0和Claude Opus 5的74.0。但在Terminal-Bench上，Claude Opus 5的51.8仍然明显领先。一个在终端操作上最强，一个在软件工程任务上更强，没有全面碾压。

一个成本数字，让“许愿式编程”的账算得过来

Vercel AI Gateway上的定价：输入$0.15/百万token，输出$0.60/百万token。DeepSeek官方API的缓存命中输入在空闲时段只要0.02元/百万token。

这个价格意味着什么？

Claude Opus 5的输出价格是它的十几倍。一次“从零建3D项目”的任务，如果放在Claude Opus 5上跑，成本可能够你在DeepSeek上跑十几次。“许愿式编程”真正的杠杆不在于模型多聪明，在于试错成本足够低。 你可以让它跑一遍、不满意、换个提示词再跑一遍，反复迭代到满意为止，账单仍然在可控范围内。

Vercel AI Gateway上，未付费用户每30天还有$5免费额度。对于想试水“一句话建项目”的普通用户，这个门槛几乎为零。

但它有一个“自我怀疑”的毛病，官方还没修

这是我翻GitHub时最意外的发现。

Issue #1669记录了一个具体的失败模式：在Codex Desktop的长时编码任务中，上下文压缩成功之后，模型多次自行声称“上下文余量不足”，提前停止工作。

关键数据在这里：压缩后反复停工时，记录的输入量只占窗口的44%到47%。模型并没有收到剩余token数或窗口占用率——它根据会话持续时间、读过的代码量、下一步的复杂度，自己推断出“快用完了”，然后把这个未经验证的推断当成了停工理由。

翻译成人话：它不是真的没空间了，是它觉得自己快没空间了。

这个bug对“许愿式编程”的影响很直接。你让它做一个3D项目，它干到一半，停下来跟你说“上下文不够了，做不完”。你查一下，明明还有一半余量。你得手动告诉它“继续”，它才接着干。长任务里这种打断会反复出现。

目前这个issue的状态是open。官方文档里没有提到修复，V4.1-Flash-1017的发布说明里也没有涉及。如果你打算用它跑长时间、多步骤的项目，心里要有这个预期。

长任务的另一个代价：速度会往下掉

社区测试的数据：上下文超过100K之后，TPS降到不足100；接近200K时，大约50 tokens/s。

“许愿式编程”恰好是那种会把上下文吃得很深的场景。3D建模的代码量、反复迭代的对话历史、工具调用的输出日志——这些东西叠起来，很快就把窗口填到几十万token。

50 tokens/s是什么体验？生成一段500字的代码注释，等10秒。一个完整项目跑下来，中间可能有几十次这样的等待。

所以“许愿式编程”最适合的场景，是那些你不需要盯着屏幕等结果的活。 扔一个需求进去，去干别的事，过一阵回来看产出。如果你需要高频交互、快速迭代，这个速度会让你难受。

值不值得试，一句话

值得试的人： 想低成本体验“从零建项目”的开发者，Vercel的$5免费额度就够跑几轮。需要快速做3D原型或小游戏demo的设计师/产品经理，几个官方示例说明它在这个方向上有真东西。

需要谨慎的人： 跑长时间多步骤任务的团队，issue #1669那个“自我怀疑”会反复打断你。对速度敏感、需要高频交互的场景，上下文一深速度就往下掉。

和Kimi K3比，不是替代关系。 K3在Terminal-Bench上那个12.6可能不代表它的真实水平，但它和V4.1-Flash-1017的强项确实不同。V4.1-Flash-1017在“从零建完整项目”这件事上给出了一个其他模型没有明确覆盖的定位，而且价格让它值得被放进工具箱里。

“许愿式编程”不是让AI替你想，是让“想完之后动手”这一步的门槛降到几乎为零。 你的判断力仍然是上限，但下限被抬高了。