一次真实项目的模型评测 - 许愿式开发，离现实有多远？

一个下午，从零到可部署：刚发布的 DeepSeek-V4.1-Flash-1017 × DeepSeek Harness Desktop 实测

模型：V4.1-Flash-1017 · 项目：FrpcDeck · 构建：1 个下午 · 平台消费：¥23.27 · 2026.10

2026 年 10 月 17 日，DeepSeek 发布 V4.1-Flash-1017。这不是 9 月那个 V4.1-Flash，而是一个新的 1017 检查点：官方称它在基准测试中更强、任务运行时间更短、输出更短，并针对 DeepSeek Harness Desktop 做了专项优化。

我没有跑分，也没有写一个 TodoList。我从一个空目录开始，用一个下午做出了 FrpcDeck，从头到尾“许愿”了一遍。

RELEASE · 2026.10.17

DeepSeek-V4.1-Flash-1017

官方给这次发布的标题是**“许愿式编程一键成真”**：通过基于自反馈的强化学习，提升从零开始构建完整项目的能力。本文评测的正是这个版本，而不是笼统的 V4.1-Flash。

发布时间 2026/10/17版本 V4.1-Flash-1017官方关键词 许愿式编程 / 完整项目推荐 DeepSeek Harness Desktop 0.2.1-rc.1 及以上官方改进 性能–费用帕累托改进同步开放 Search / Fetch API

来源：DeepSeek 官方发布说明 · 模型权重已在 Hugging Face / ModelScope 开源

关于这篇文章

你正在读的这篇评测，从资料整理、正文写作到封面和 HTML 排版，也来自 DeepSeek-V4.1-Flash-1017；它在 DeepSeek Harness Desktop 中完成。选题、真实数据、判断和最终发布由我负责——包括文中那些“AI 差点写错”的部分。

先说结论

如果“许愿式”指的是从一句愿望到一个可运行的原型，DeepSeek-V4.1-Flash-1017 + DeepSeek Harness Desktop 已经非常接近。如果指的是从愿望到一个可上线、可维护的产品，它仍然需要一位工程师站在旁边——负责定义、判断、验收和兜底。

本文看点

• • 01 · 为什么拿 FrpcDeck 做评测
• • 02 · 1017 的第一印象与账单
• • 03 · 最像“许愿”的三次体验
• • 04 · 翻车现场与能力边界
• • 05 · 一张不跑分的评分卡
• • 06 · DeepSeek Harness Desktop 的加分项
• • 07 · 怎么“许愿”才有效

01. 为什么拿 FrpcDeck 做评测

FrpcDeck 是我用 Vibe Coding 做的一个 frpc 可视化管理面板。

这次不是“改一个功能”，而是从空目录开始。一个下午，从第一行代码到 v3.2.1、38 项测试、Docker 镜像和文档页面，全部走完。

它不是一个玩具：后端是 Node/Fastify，前端是 Vue 3，要管理 frpc 子进程、生成 TOML、提供 SSE 日志、处理认证和 CSRF、支持多实例、批量端口、移动端、Docker 部署，还要把文档、截图和发布流程一起收尾。

它足够复杂，能暴露“许愿式开发”最真实的问题：

• • 模型能不能理解一个持续演进的产品，而不是一次性脚本？
• • 它能不能在真实 API、真实进程、真实浏览器里完成闭环？
• • 遇到性能、安全、部署这些“不酷但重要”的问题，它会不会偷懒？
• • 当人类推翻它的方案时，它能不能重新组织代码？

图 1：最终的概览页。连接状态、代理、流量、运行时长和配置健康度都在同一屏。

02. 1017 的第一印象

我对 V4.1-Flash-1017 的第一个感受不是“聪明”，而是快而不飘。

先对齐一个容易混淆的点：9 月 10 日发布的是 V4.1-Flash，10 月 17 日发布的是 V4.1-Flash-1017。两者同名不同版本，后者是一个新的检查点。官方对 1017 的描述很具体：

• • 在多项基准测试中相比上一版有明显提升
• • 缩短任务运行时间与输出长度，达到性能–费用的帕累托改进
• • 针对 DeepSeek Harness Desktop、腾讯 CodeBuddy、WorkBuddy 等框架做了专项优化
• • 通过自反馈强化学习，提升从零构建完整项目的能力
• • 同步开放 Search / Fetch API，模型权重开源

官方演示里甚至包括故宫 3D 建模、网页赛车、Godot 版《传送门 2》和 3D 历史场景。这些是官方案例，我没有逐一复现；但它们说明了 1017 想证明的方向：不只是写函数，而是把一整个项目从零做出来。

账单：一个下午，668M tokens，¥23.27

“一个下午”不是修辞。下面是这次 DeepSeek Harness Desktop 会话与 DeepSeek 平台当天的真实统计：

ONE AFTERNOON · 许愿账单

平台统计为当天 00:00–24:00 的总量；DeepSeek Harness Desktop 会话统计为 668,303,856 tok。两者相差约 3.95M tok，来自同日其他 API 调用（包括生成这篇文章本身）。668M 不是 668M 全新输入：其中 663,493,760 tok 是缓存读取，未缓存输入只有 3,443,774 tok，输出 1,366,322 tok。高缓存命中是长会话能持续跑下去、成本还能保持在 ¥23.27 的关键。

这组数字比任何“感觉很快”都更有说服力：

• • 首 token 平均 1.6 秒，输出 260 tok/s。交互几乎没有等待感，愿望可以连续地往前推。
• • 模型生成 2 小时 7 分，工具执行 3 小时 15 分。工具时间比模型时间更长，说明“许愿式”不是一句话生成，而是 Agent 在真实终端、浏览器和测试里不断闭环。
• • 99% 缓存命中。668M 的累计量听起来夸张，但真正的新鲜输入只有 3.44M；这也是为什么长会话没有把成本推到不可承受。
• • 当天账单 ¥23.27。1,536 次 API 请求、平台总消耗 672,257,292 tokens，换来一个从空目录到可部署的项目，以及这篇文章本身。
• • 一个下午。从空目录到可部署版本，不是“生成一个 demo”，而是把配置、测试、文档、截图和发布一起收掉。

“Flash”通常意味着更低的延迟和更低的成本，但也容易让人担心：它会不会为了快而牺牲理解力？这次实际用下来，它在三件事上明显超出预期：

1. 1. 中文意图理解。我不需要把需求翻译成英文 prompt，也不需要写很长的技术前缀。像“批量端口不要做成模板模式，一个范围就是一条代理”这种产品判断，它能直接落到数据模型和 UI 上。
2. 2. 长上下文里的连续性。项目跨了几十个文件、多个版本、几十轮修改。它能在后续对话里记住“多实例要隔离”“密码不能进 TOML”“批量是一行”这些约束，而不是每次重新发明。
3. 3. 工具闭环。配合 DeepSeek Harness Desktop，它能在一个会话里读文件、改代码、跑命令、起服务、看截图、再修。许愿式开发真正难的不是“生成”，而是“生成之后还能自己验证”。

评测边界

本文不重新跑官方 benchmark，也不复现官方 3D / 游戏案例。所有判断只来自一个真实项目：FrpcDeck 的完整研发与发布过程。样本只有一个，结论也应该只在这个范围内成立。

一个直观的比喻

它不像一个只会补全代码的编辑器，更像一个非常快、非常有耐心、但需要你带教的工程师。你给出方向和验收，它能把大量实现工作接过去。

03. 最像“许愿”的三次体验

第一次：一句话长出一个全栈骨架

我最初给它的不是一个页面，而是一段产品描述：要覆盖 frpc 的主要配置、同时支持 PC 和手机、要能导入导出、要和 frpc 一起用 Docker 部署。

它没有只给我一个静态页面，而是先拆了数据模型：配置、代理、访问器、备份、运行时状态、SSE 日志，再把这些落到前后端目录和接口里。

第一版当然不完美，但骨架是对的。从 0 到 1 最耗神的“起盘”阶段，被压缩得很明显。

第二次：推翻它的方案，它还能重构

批量端口最初做成了“模板模式”。用起来很别扭：用户要先理解模板，再生成代理，编辑时还要在两个概念之间切换。

我给的反馈很直接：“不要模板模式。一个端口范围，就是一条代理记录，列表里只占一行。”

这是一个会伤筋动骨的要求：数据模型、表单、导入、导出、校验、运行时映射都要动。它没有只改表面文案，而是把批量数据收敛成一条可编辑记录，再把范围解析、命名规则和运行时状态接回去。

![FrpcDeck 批量端口列表

图 2：批量端口最终以“一条代理”呈现，而不是一组模板。这个产品判断由人做出，模型负责把它实现干净。

第三次：多实例，不只是多一个页面

需求变成“一个面板管理多个 frpc，连接不同 frps”时，真正的问题不是 UI，而是隔离：

• • 每个实例有独立的配置、代理、访问器、日志、备份和自动启动设置
• • 请求要识别当前实例
• • SSE 日志要切换实例
• • 切换实例不能串数据
• • 删除实例不能误删别的目录

它提出的方案是根级认证、实例级 Store 和 FrpcManager、请求上下文、实例目录。这个方案最终被采用，但**“实例之间必须隔离”这条边界是人定的**。

图 3：多实例页面。模型能写出实例管理，但数据隔离和迁移策略需要人来把关。

04. 翻车现场与能力边界

许愿式开发最危险的地方，是它会把“看起来合理”当成“真实”。

流量监控：它先编了一个 API

我想加流量统计，第一句愿望是“给 frpc 加一个流量监控”。

它很快开始设计卡片和曲线。但我去读 frpc 的 /api/status，发现返回的只有代理名称、状态、地址这些字段，没有流量，也没有连接数。

如果不去验证，很容易得到一套漂亮但数据是假的面板。

真实数据源在 frps Dashboard。于是方案改成可选接入：在 frps 开启 webServer，在 FrpcDeck 里配置地址和认证，后端每 15 秒采样一次，前端读缓存，未启用时零请求。最后的效果是真实的，但前提是人先去确认数据从哪来。

图 4：流量监控。今日入站/出站、实时速率、连接数和代理流量都来自 frps Dashboard，而不是模型“想象”的接口。

性能：它不会主动替你心疼用户

代理列表变多之后，打开编辑器会卡几秒。模型第一反应是“优化一下”，但真正的瓶颈在渲染：所有折叠面板同时存在，所有行都在重复计算。

最后的处理很具体：折叠面板只在打开时渲染、行做记忆化、编辑器延迟初始化、列表分页。这些不是模型自动送的，是用户被卡到之后，工程师给出的约束。

两个真实的小事故

• • PowerShell 写配置文件时带了 UTF-8 BOM，frps 启动直接报 invalid character at start of key: ï。
• • 重新构建前端后，旧的静态资源索引导致 404，页面一片空白。

这两个问题都不会在“生成代码”时出现，只会在真实运行、真实部署时出现。工具闭环越强，越需要人去看真实输出。

05. 一张不跑分的评分卡

这不是 benchmark，只是这次项目的主观评分。

官方宣传对照

1017 的官方主张里，“更快、更短、性能–费用帕累托改进”在这次项目里和体感一致：长任务等待更短，输出更克制，返工次数更少。“从零构建完整项目”也大体成立：它能把一个真实全栈项目的骨架、功能、测试和发布链路接住。但官方 benchmark 我没有复现，“许愿式”也不等于“无需判断”——愿望要具体，验收要可执行，结果要验证。

06. DeepSeek Harness Desktop 的加分项

这次体验里，DeepSeek Harness Desktop 不是背景板。

官方在发布说明里特别提到：1017 针对 DeepSeek Harness Desktop 做了专项优化，建议升级到 DeepSeek Harness Desktop 0.2.1-rc.1 及以上。如果你还在旧版本，先升级，否则体验到的并不是 1017 被适配后的状态。

它把原来需要在聊天窗口、编辑器、终端、浏览器之间来回搬运的流程，收进了一个会话：

• • 读工程、改多个文件
• • 跑测试、看真实报错
• • 起服务、用浏览器看页面
• • 截图对照桌面端和移动端
• • 继续下一轮修改

这让“许愿”不再是一锤子买卖，而是一个可以不断收敛的闭环。

但工具越强，越要守住三条线：

1. 1. 不要让 Agent 直接操作生产环境。
2. 2. 不要在没有测试和 diff 的情况下接受大改。
3. 3. 不要把“它能跑”当成“它是对的”。

图 5：最终连文档页面也做进了产品。会写代码只是起点，能把交付物一起收好才是完成。

07. 怎么“许愿”才有效

如果你也想用 V4.1-Flash-1017 做项目，我的建议不是“把需求写长”，而是“把验收写清楚”。

一个有效的愿望至少包含五件事：

目标：我要做一个什么，给谁用？现状：已有代码、技术栈、不能动的东西是什么？约束：性能、安全、兼容性、部署方式有什么要求？验收：什么叫做完？用户能完成哪条完整路径？失败时：报错、截图、日志应该怎么反馈给你？

再补三条实践：

• • 先小步验证，再扩大范围。 先让它跑通一条真实路径，再谈“所有配置”。
• • 用真实失败做反馈。 报错、截图、接口返回，比“还是不对”有用一百倍。
• • 把架构和安全留在人这边。 多实例隔离、认证模型、数据目录、生产发布，不应该完全外包。

写在最后

FrpcDeck 现在有完整的配置编辑、批量端口、多实例、认证、日志、文档和流量监控，38 项自动化测试通过，也发布了多架构镜像。

项目地址：https://github.com/Luqijian/FrpcDeck

如果只看结果：一个下午、¥23.27、668,303,856 tokens、38 项测试、一个可部署的开源项目。

回到最初的问题：许愿式开发，离现实有多远？

我的答案是：它已经能接住“愿望”，但还接不住“责任”。

DeepSeek-V4.1-Flash-1017 + DeepSeek Harness Desktop 是我目前用过最接近“许愿式”的工程搭档之一。它快、稳、能干活，能把大量重复实现接过去；但方向、品味、边界和最后的那次验收，仍然需要工程师。

参考资料

• • DeepSeek-V4.1-Flash-1017 官方发布说明（2026/10/17）
• • DeepSeek Harness Desktop 官方介绍
• • DeepSeek-V4.1-Flash-1017 模型权重（Hugging Face）

最好的愿望，不是“帮我写一个”，而是“和我一起把它做完”。

如果你也在用 Vibe Coding 做自己的产品，欢迎来 FrpcDeck 看看，或者把你的“许愿”故事讲给我听。

github.com/Luqijian/FrpcDeck

本文由 DeepSeek-V4.1-Flash-1017 协作撰写 · 数据来自真实 Harness 会话 · 2026.10