DeepSeek V4.1 Flash-1017 深度拆解：基准成绩怎么读、成本账怎么算、接入与合规怎么落地

本文由 莫潇羽@复源AI社区（bbs.fuyuan7.com）撰写，转载请注明出处。

快速摘要

DeepSeek 在 2026 年 10 月 17 日把 V4.1 Flash 更新为 V4.1-Flash-1017：网页端、App、API 同步切到新模型，API 仍然用 deepseek-flash 这个名字，价格不变，权重以 MIT 许可开放下载。官方基准里，Terminal-Bench 4.0 从 31.2 提到 42.3，DeepSWE v1.1 从 74.2 提到 77.0，ProgramBench 从 20.3 提到 29.1，同时任务运行时间和输出长度都缩短了。这是一次小版本更新，亮点在"同样的活更快、更省地做完"，不是换代。同时开放的 Search/Fetch 接口按 5 元每千次成功请求计费，经 Harness 等工具发起的服务端调用从北京时间 2026 年 11 月 1 日 0 点起开始收费。读榜单要先看口径，算成本要看"每个通过验收的结果花多少钱"，而不是单价。

这篇文章我会按"先把消息读准、再把数字读懂、再把账算清、再动手接入、最后落到合规"的顺序往下走，里面有公式、代码、对照表和流程图，新手也能照着做。

想看完整拆解，往下翻。

一、先把消息读准：这次更新到底动了什么

1.1 时间线：它在 V4 家族里处在什么位置

很多人看到"1017"这个后缀会懵，以为是个全新的模型。我先把官方更新日志里这一年的关键节点捋成一张表，你就知道它的坐标了。

这张表能说明一个事实：DeepSeek 今年的节奏是"一个季度里连发好几次"，每次都在原有模型上叠加后训练和工程适配。1017 的模型卡里自己就写明，这是对 V4.1 Flash 的一次 minor update，也就是小版本更新。

理解这一点很重要。你如果拿"换代"的预期去看它，会觉得提升不够炸裂；如果拿"同一个底座上又打磨了一轮"的预期去看，就会发现几个数字其实挺扎实。

1.2 官方自己强调的三件事

我把官方公告和模型卡里反复出现的内容归纳一下，其实就三条。

第一条，能力上，从零构建完整项目的本事变强了。 官方的说法是，这次用了基于自反馈的强化学习训练。通俗讲，强化学习就是"做对了给奖励、做错了给惩罚"的训练方式，自反馈则是让模型利用自己运行结果产生的反馈去修正行为。官方展示的案例覆盖游戏开发和 3D 建模，并且特别说明是在较少的提示词与素材参考、较短的交互轮次下实现的。官方把这类"一句话需求直接出原型"的任务叫作"许愿式编程"，这是官方宣传口径，我们后面会用比较克制的方式去验证它。

第二条，成本上，同样的任务跑得更快、输出更短。 官方称之为"性能与费用的帕累托改进"。帕累托改进这个词来自经济学，意思是"在没有任何一方变差的前提下，至少一方变好了"。落到这里就是：分数涨了，同时耗时和输出量没有变多，反而变少了，所以综合成本下降。

第三条，生态上，针对几个具体平台做了适配。 官方点名了 DeepSeek Harness、腾讯的 CodeBuddy 和 WorkBuddy，并建议把 DeepSeek Harness 升级到 0.2.1-rc.1 或更高版本。这里的 Harness 可以理解成"给模型套上的一层工作台"，它负责决定模型能调用哪些工具、出错了怎么重试、上下文怎么管理。同一个模型放进不同工作台，表现可能差得不少，所以官方才会专门强调适配。

1.3 API、网页端和权重：三个入口怎么对应

对普通用户来说，最关心的是"我现在用的到底是不是新版"。我把三个入口列清楚：

网页端 / App    →  官方已切换为 V4.1-Flash-1017，打开即用
API            →  model 填 deepseek-flash 即可，调用方式和价格都没变
自部署          →  到 Hugging Face 或魔搭社区下载权重，MIT 许可

这里有个细节值得提醒。官方定价页里写明，旧的模型名 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 仍然可以调用，但对应的模型已经下线，请求会被转给 1017 来处理，并按 Flash 的价格计费。这意味着一件事：你代码里什么都没改，背后的模型却换了。 如果你的业务对输出风格或格式很敏感，就要主动安排一次回归测试，而不是等出了问题再排查。

1.4 几种容易被误读的说法

新模型发布的那几天，网上的标题总是比官方文档激进。我挑几类最常见的误读，逐条说明为什么要打折扣。

误读一："全面超过国外旗舰"。 官方发布表里的对照对象是 GPT-5.6 Sol、Claude Opus 5 以及国内的 GLM-5.3、Kimi K3。在十一行成绩里，它对 Opus 5 是四行领先、七行落后。所以更准确的说法是"在软件工程类和智能体类任务上很能打，在高难度知识问答和部分视觉任务上还有差距"。

误读二："和某某更新的旗舰比，分数更高"。 有些二手稿件会把它和发布表里根本没出现的更新型号做比较。官方表里没有这一项，不同厂商各自公布的分数，测试框架、预算、模型快照往往并不一致，直接并排放在一起没有意义。你看到这类说法，应该回到官方表格核对对照对象是谁。

误读三："某个具体的单任务成本数字"。 成本图上的数字，取决于所用的测试框架和任务集合。官方只给了"同一个测试框架下新旧版本的相对位置"，没有给一个可以直接套到你业务上的价格。我的做法是，看到别人转述的"每任务多少钱"，一律当作示意，等自己跑完一批真实任务再下结论。

误读四："演示视频等于稳定能力"。 官方展示的案例是精选的。一次精选演示证明"这件事可以做成"，但不证明"每次都能做成"。第五章我会给一套自己验证稳定性的方法。

小结一下这一章：它是个小版本，亮点是效率和从零建项目的能力，生态上更贴近 Harness 和国内的几款编程助手，读消息的时候要盯住"对照对象"和"测试口径"两个词。

二、成绩单怎么读：基准分背后的含义与盲区

2.1 先搞清楚每个榜单在考什么

基准测试，英文叫 benchmark，就是一套固定的题目加评分规则，用来给不同模型打分。同样叫"分数"，不同榜单考的东西天差地别。我把官方发布表里的十一个榜单按能力方向做了归类。需要先说明：个别榜单我没有逐一回到原始榜单页核对细则，下表中的归类是按名称和公开描述做的大致划分，真要引用请以各榜单自己的说明为准。

你会发现，这次升级的重点集中在前面几行，也就是"让模型像工程师一样动手做事"的那一类。这和官方强调的"从零构建完整项目"是自洽的。

2.2 新旧对照：涨了多少，涨得有没有分量

下面是 1017 与上一版 V4.1 Flash 的对照。涨幅是我自己算的，公式很简单，放在表前面：

绝对提升 = 新分数 − 旧分数
相对提升 = （新分数 − 旧分数）÷ 旧分数 × 100%

拿两个例子说明相对提升怎么算。Terminal-Bench 4.0 是 11.1 ÷ 31.2 ≈ 35.6%，ProgramBench 是 8.8 ÷ 20.3 ≈ 43.3%。听起来很吓人，但一定要记住：这是"榜单分数"的相对变化，不是"你能多完成 43% 的工作"。分数涨 43%，在你自己的任务里可能表现为多通过两三个用例，也可能几乎感觉不到，取决于你的任务和榜单有多像。

再看 DeepSWE 这一行。它只涨了 2.8 分，但基数已经很高，在 77 这个位置上每多涨一分都比在 20 这个位置上难得多。所以不能简单地比较绝对提升大小，要结合基数看"剩下的难题还有多少"。 这是读任何榜单时都应该养成的习惯。

2.3 放进同一张桌子：与其他模型的相对位置

官方发布表还给出了几个对照模型。我挑几个关键行整理出来，并且提醒一句：这是官方自己选定的对照组，不等于全行业排名。

按我自己的统计：对 Opus 5，四行领先、七行落后；对 GPT-5.6 Sol，十一行里九行领先、两行落后；对国内的 GLM-5.3，在七个可以直接比较的非 HLE 行上全部领先。

从这个格局里，我读出三条判断：

• 在"智能体做事"这一类任务上，它的性价比位置非常好，这正是开发者最在意的地方；
• 在"需要极强知识储备和最高难度推理"的任务上，最强的闭源旗舰仍然有明显优势；
• 如果你的任务偏"整仓库从零生成"，Opus 5 在 ProgramBench 和 NL2Repo 上依然领先不少，不要因为 DeepSWE 一行亮眼就一概而论。

涉及的国外模型，这里只是引用官方发布表里的公开对照数据做科普说明。境外模型的使用需遵守国内网络与内容管理相关规定，本文不提供也不引导任何访问境外服务的方式，国内读者请优先选择境内合规可用的模型与工具。

2.4 读榜单的四个盲区

我把官方脚注和模型卡里的备注，加上自己读榜时的习惯，整理成四个盲区。

盲区一：测试框架不同，分数不可直接互比。 官方明确写了，Terminal-Bench 4.0 使用的是 Claude Code 框架，DeepSWE 使用的是 Mini-SWE-V2 框架。换一个工作台，同一个模型的得分可能就不一样。你自己的环境和官方测试环境越不同，越要打折扣。

盲区二：带星号或带剑号的数字，口径不同。 HLE 这一行有两个数字，括号里的 44.0 是只测文本子集的结果，和其他模型的全集成绩不能放一起比。官方还注明 ZeroBench-main 用的是 Pass@5。Pass@5 的意思是"允许尝试五次，只要有一次对就算对"，它衡量的是上限能力，不是一次成功率。

盲区三：自家发布表通常没有置信区间。 一个榜单上差两三分，到底是真实差距还是随机波动，发布表里看不出来。我的做法是：差距小于三分的行，一律视为"基本持平"，不据此下结论。

盲区四：榜单测不到你最关心的东西。 比如模型能不能听懂你含糊的需求，生成的代码好不好维护，改了新功能会不会破坏旧功能，这些都不是固定榜单能覆盖的。所以最终决策一定要回到你自己的任务上，这个做法我会在最后一章给出具体方案。

下面这张流程图，是我读任何一份发布表时的固定顺序，推荐你收藏：

flowchart TD
    A[拿到一张发布表] --> B{对照对象是谁?}
    B -->|只挑了对自己有利的| C[标记为官方口径 不当作行业排名]
    B -->|范围合理| D{测试框架一致吗?}
    D -->|不一致| E[分数只做方向参考]
    D -->|一致| F{有无脚注 子集 多次尝试?}
    F -->|有| G[按脚注口径单独比较]
    F -->|没有| H[读取差距]
    H --> I{差距小于三分?}
    I -->|是| J[视为基本持平]
    I -->|否| K[进入自己的任务验证]
    G --> K
    E --> K

三、成本账怎么算：从一次任务的账单到每天的预算

3.1 先把价格表摆出来

官方定价页是用"百万 tokens"为单位计价的。Token 是模型处理文本的最小计量单位，可以是一个词、一个汉字片段或一个标点。你可以粗略地把它理解成"模型眼里的字数"，中文里一个常用汉字往往折算成一到两个 token，具体以官方的用量计算说明为准。

下面是写稿时官方页面上 deepseek-flash 与 deepseek-v4-pro 的对照，单位是元每百万 tokens：

高峰与空闲的划分，官方写得很明确：北京时间周一到周五（不含中国法定节假日）的 9:00 到 12:00、14:00 到 18:00 属于高峰时段，其余时间，包括周末和法定节假日全天，都按空闲时段计价，空闲价是高峰价的一半。

这里有三个"倍数关系"，我建议你记在脑子里，后面做预算全靠它：

同一时段内：缓存命中价 ÷ 缓存未命中价 = 0.02 ÷ 1 = 1/50（Flash）
高峰价 ÷ 空闲价 = 2 倍
Flash 与 Pro 的输出单价之比 = 27.0 ÷ 8 ≈ 3.4（高峰时段）

AI 模型的价格变动非常快，上面是写稿时的官方公开价格，请务必以官方定价页面的实时数据为准。

3.2 一条通用的费用公式

很多人算成本只看"输入多少钱"，忘了输出才是大头，也忘了缓存。我给自己用的是下面这条公式（单位全部换算成百万 tokens）：

单次任务费用
  = 未命中输入量 × 未命中单价
  + 命中输入量   × 命中单价
  + 输出量       × 输出单价

这里的输入量，指的是这一次任务中所有请求累计发给模型的 token 数，而不只是你最初那一句话。智能体类任务每走一步都会把前面的上下文再发一遍，所以累计输入往往是你直觉的好几倍，这正是缓存价格影响巨大的原因。

3.3 一个虚构的演算示例

为了让公式落地，我虚构一次"中等规模的代码修改任务"，数字完全是示意，用来演示算法，不代表真实任务的实际消耗：

• 累计缓存未命中输入：0.8 百万 tokens
• 累计缓存命中输入：4 百万 tokens
• 输出：0.15 百万 tokens

高峰时段用 Flash 来跑：

0.8 × 2 + 4 × 0.04 + 0.15 × 8
= 1.6 + 0.16 + 1.2
= 2.96 元

空闲时段用 Flash 来跑：

0.8 × 1 + 4 × 0.02 + 0.15 × 4
= 0.8 + 0.08 + 0.6
= 1.48 元

同样的 token 量，用 V4-Pro 在高峰时段跑：

0.8 × 9 + 4 × 0.30 + 0.15 × 27
= 7.2 + 1.2 + 4.05
= 12.45 元

把三个结果放在一起：

你会发现一个有意思的现象：在这个示例里，输出只占了 0.15 百万 tokens，但在 Flash 高峰的总账里它贡献了 1.2 元，占比超过四成。这就是为什么官方强调"缩短输出长度"对成本的意义：输出单价比缓存命中的输入单价高出两百倍（8 ÷ 0.04），输出每少一点，账单就明显轻一点。

3.4 比单价更重要的指标：每个合格结果的成本

单次费用低，不等于总体便宜。设想一个很常见的情形：便宜的模型一次做对的概率低一些，你需要重试，还要花时间人工检查。所以我更看重的指标是：

单个合格结果的成本 = 总花费 ÷ 通过验收的任务数

继续用上面的虚构数字，再虚构两个通过率，仅作演示：假设 Flash 的验收通过率是 70%，Pro 的通过率是 85%。

Flash：2.96 ÷ 0.70 ≈ 4.23 元 / 个合格结果
Pro：  12.45 ÷ 0.85 ≈ 14.65 元 / 个合格结果

即使 Pro 通过率更高，在这个虚构设定下 Flash 的单个合格成本依然低得多。但要提醒你，如果换成"失败一次要三个人排查半天"的场景，人工成本会把天平拉回去。所以这个公式里的"总花费"，我建议你把人工检查和返工的时间也折算进去。

我自己做选型时，会把任务分成"可以自动验收的"和"必须人工判断的"两类：前一类尽量用便宜模型反复跑，后一类才请更强的模型出手。

3.5 五个压低账单的杠杆

我把能操作的省钱办法按"效果大小"粗略排了个序。

杠杆一：让缓存命中率尽量高。 缓存命中价是未命中价的五十分之一，这是整张价格表里差距最大的一项。要提高命中率，核心原则是"保持请求前缀稳定"：把不变的系统提示、项目说明、工具定义放在最前面，把每次变化的内容放在后面，不要在前缀里塞时间戳之类每次都变的字段。

flowchart LR
    A[请求开头: 系统提示 + 工具定义 + 项目说明] --> B[内容固定不变]
    B --> C[更容易命中缓存 按命中价计费]
    D[请求后部: 当前任务 + 最新对话] --> E[每次变化]
    E --> F[按未命中价计费]
    C --> G[整体账单下降]
    F --> G

杠杆二：错峰。 同样的任务放到空闲时段，价格直接减半。夜间批量跑测试、周末跑回归评估，都是现成的错峰场景。当然，要留意法定节假日全天是空闲价，这个规则可以拿来安排长任务。

杠杆三：控制思考强度。 官方提供 low、high、max 三档思考强度，默认是 high。官方的建议是：简单任务用 low，日常智能体任务用 high，更复杂的场景才用 max。思考越深，输出的 token 越多，成本也就越高。

杠杆四：给智能体设置"刹车"。 无限循环的重试是最可怕的账单黑洞。无论你在哪个工作台里用，都应当设置最大步数、最大 token 预算和超时时间。

杠杆五：留意搜索与抓取的单独计费。 这部分我会在第六章专门展开，这里先记住：它们不走 token 计费，按成功请求次数收费。

3.6 做月度预算的简易方法

如果你要给团队做一个粗略预算，我推荐用"抽样外推"，不要拍脑袋：

步骤 1：从真实任务里随机抽 20 个，放到同一个工作台里跑完
步骤 2：记录每个任务的三项数据：未命中输入、命中输入、输出（工作台或接口返回的用量字段里都有）
步骤 3：套用上面的费用公式，算出每个任务的费用，取平均值
步骤 4：月度预算 = 平均单任务费用 × 预计月任务量 × 1.3（留 30% 余量应对重试和波动）

这个方法的好处是，它基于你自己的任务分布，比任何公开榜单上的"每任务成本"都靠谱。另外别忘了，价格和高峰时段划分随时可能调整，预算表里最好把单价做成可以随时修改的单元格。

四、动手接入：API、思考强度和最容易出问题的细节

4.1 接入之前，先把账号和密钥的事情理顺

要调用 API，你需要在 DeepSeek 开放平台注册账号、充值并创建 API Key。这个 Key 相当于你账户的"提款密码"，谁拿到谁就能花你的钱。我的习惯是三条铁律：

1. 密钥只放在环境变量或密钥管理工具里，永远不写进代码文件
2. 不同项目用不同的 Key，泄露时可以单独作废
3. 一旦怀疑泄露，立刻在平台上删除旧 Key 并新建

下面的示例都默认你已经把密钥放进了名为 DEEPSEEK_API_KEY 的环境变量。

4.2 最小可运行的调用

官方提供的接口兼容 OpenAI 的 Chat Completions 格式，同时也兼容 Anthropic 格式。基础地址是 https://api.deepseek.com，模型名填 deepseek-flash。下面是我整理的最小示例：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "system", "content": "你是一名严谨的代码审查员。"},
        {"role": "user", "content": "请检查下面这段函数有没有边界问题：..."},
    ],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
)

print(response.choices[0].message.content)

有两个细节要说明。第一，thinking 参数要放进 extra_body，这是官方文档特别写明的，直接作为普通参数传会不生效。第二，思考模式默认就是开启的，effort 默认是 high，所以上面这两个参数写出来是为了让意图更清晰，不写也是同样的效果。

4.3 思考模式与强度：怎么选，怎么映射

官方文档给出了几种格式下的控制方式，我把它们并成一张表：

还有一张映射表很有意思，说明你传入的强度词汇会被归并成三档：

也就是说，你写 medium 并不会得到"中等强度"，而是等同于 high。这个细节在从别的平台迁移代码时很容易被忽略。

另外，思考模式下不支持 temperature、presence_penalty、frequency_penalty 这几个参数，为了兼容已有软件，传了不会报错，但也不会生效。top_p 在思考模式下的有效范围是 0.95 到 1.0，低于 0.95 的取值会被按 0.95 处理。如果你以前习惯用 temperature 去调"创造性"，在这里就要换思路了：想让输出更稳，主要靠提示词写得更具体，而不是调温度。

我给自己定的选档规则很朴素：

改个小 bug、写个脚本、做格式转换     →  low
日常的多步骤智能体任务              →  high（默认）
跨多个文件的重构、复杂的排障         →  max，并且设置好输出上限

4.4 带工具调用时，最容易炸的一处坑

这是官方文档用加粗强调的内容，我也想重点说一下。当你的请求里带了 tools 参数（也就是让模型可以调用函数、执行命令），模型每一轮返回的 reasoning_content，也就是思维链内容，必须在后续所有请求里原样回传，哪怕那一轮模型并没有真的调用工具。如果漏传，接口会返回 400 错误。

反过来，如果请求里没有带 tools，那 reasoning_content 不需要回传，传了也会被忽略，不会拼进上下文。

最稳妥的写法，就是把整条返回消息对象直接追加进历史，不要自己挑字段拼：

messages.append(response.choices[0].message)   # 包含 content、reasoning_content、tool_calls

一种很典型的写法是自己手写字典，只放 content 和 tool_calls，结果把 reasoning_content 漏掉，然后对着 400 报错反复排查。养成"整条消息原样追加"的习惯，可以省掉大量麻烦。下面这个流程图，展示了带工具的一轮完整循环：

sequenceDiagram
    participant U as 你的程序
    participant M as 模型接口
    participant T as 本地工具
    U->>M: 请求（含 tools 与历史消息）
    M-->>U: reasoning_content + tool_calls
    U->>T: 执行工具调用
    T-->>U: 工具结果
    U->>M: 再次请求（历史中保留 reasoning_content）
    M-->>U: 最终回答 content

4.5 在国内的编程助手里接入

对多数读者来说，不会直接手写 API 循环，而是在编程助手里选模型。官方文档的"接入 Agent 工具"一栏列出了好几个入口，其中有两类特别适合国内环境：DeepSeek Harness，以及腾讯的 WorkBuddy 与 CodeBuddy。

DeepSeek Harness，官方文档写的流程很简洁：按仓库说明启动它的 Web 界面，打开"设置 → 模型"，填入 DeepSeek API 密钥并保存，模型路由立即可用，不需要重启服务；然后点击"选择工作区"，添加你的项目目录并选中；之后就可以发起会话了。智能体可以读取和编辑工作区文件、运行命令、委派工作并维护计划，遇到需要审批的操作，界面会先询问你。官方还特别提示：要升级到 0.2.1-rc.1 或更高版本，才能获得对新模型的完整适配。

WorkBuddy 与 CodeBuddy，官方的接入方式是通过本地的模型配置文件添加自定义模型。示例配置文件的结构大致是这样的（以下仅展示关键字段，密钥用环境变量引用）：

{
  "models": [
    {
      "id": "deepseek-flash",
      "name": "DeepSeek Flash",
      "vendor": "DeepSeek",
      "url": "https://api.deepseek.com/v1/chat/completions",
      "apiKey": "${DEEPSEEK_API_KEY}",
      "supportsToolCall": true,
      "supportsImages": true
    }
  ],
  "availableModels": ["deepseek-flash"]
}

官方还有几条排错提示，非常实用：

• 配置文件要保存为 UTF-8 无 BOM 编码，带 BOM 的文件头可能导致桌面版读取失败；
• 改完配置要完全退出应用再重新打开，才能在模型选择器里看到新模型；
• 出现 401 多半是 Key 填错了，别把接口地址填进 Key 字段；出现 404 要检查模型 id 是否严格等于 deepseek-flash；
• 如果界面里直接显示了 ${DEEPSEEK_API_KEY} 这样的字面量，说明桌面端没有展开环境变量，可以从已设置变量的终端里重新启动，或者直接在本地配置里填写真实 Key。

我想提醒一个容易忽略的地方：官方示例配置里给的上下文和输出上限（输入 12.8 万、输出 8192）远小于模型本身的 1M 上下文和最大 384K 输出能力。示例这样写是为了稳妥起步，如果你要处理大型仓库，需要根据需要调高，同时要注意上限越高，一旦失控账单也越高，所以配合前面说的预算刹车一起用。

官方文档里还提供了对其他一些编程工具的适配说明，其中也包含境外的工具。这里只作为科普提及，境外工具与服务的使用需遵守国内网络与内容管理相关规定，本文不做任何访问方式的引导，国内读者请优先使用境内合规可用的工具。

4.6 接入完成后的三项冒烟检查

装好之后，我建议你不要立刻上真实项目，先用下面三件小事验证一遍：

检查 1：问它"你是哪个模型"，确认返回的信息和预期一致（注意模型自述不完全可靠，仅作参考）
检查 2：让它读一个小文件并改一行，确认读写权限和审批流程正常
检查 3：故意给一个会报错的命令，看它能不能读懂报错并修正（这是智能体最基本的闭环能力）

三项都过了，再去碰真实项目。这样即使环境配置有问题，也不会在复杂任务里才暴露，浪费 token。

4.7 模型别名漂移：一个长期隐患

前面提过，旧别名会被路由到最新模型。这在省心的同时也是个隐患：同一个名字背后的模型在变。 我的建议是在自己的日志里记录每次调用时的日期，并且保留一份"固定的回归任务集"，每次发现官方更新日志里有新版本，就用它跑一遍，对比结果。这个动作只需要十几分钟，但可以让你在"悄悄变化"面前心里有底。

五、从零做项目：把一句话需求变成能跑的原型

5.1 为什么"一句话出原型"有时成、有时不成

官方这次主打的方向，是在较少的提示词和素材参考下，通过很短的交互轮次，直接做出一个完整项目。我自己对这件事的理解是：一个"完整项目"至少包含三层东西。

第一层：场景层   —— 画面里有什么（角色、地形、界面、光影）
第二层：交互层   —— 用户能做什么（按键、鼠标、视角切换、选择）
第三层：反馈层   —— 做了之后发生什么（得分、计时、结算、提示）

以前的模型常常能把第一层搭个大概，第二层和第三层就开始漏洞百出：按键没响应、状态不同步、结算界面进不去。官方说这次引入了自反馈的强化学习，训练目标就是让模型在"跑起来、看结果、再修正"这个循环里表现更好。所以它在"端到端打通"上的能力才是这次升级的看点，而不是单点代码写得多漂亮。

但是，一个官方精选的演示和你手里的真实需求之间，有一条不小的沟。需求越含糊、依赖越多、素材越缺，成功率就掉得越快。所以接下来我讲的，是怎么把"一句话"升级成"一份足够清楚的需求说明"，把成功率拉上来。

5.2 需求说明的五段式模板

我推荐的需求模板分五段，每段只写必要的内容。下面是一个可以直接复制改写的骨架：

【目标】
用一句话说清楚要做什么，以及给谁用。

【技术约束】
- 单个 HTML 文件，不依赖任何外部链接和在线资源
- 不使用需要联网加载的字体、图片、脚本
- 兼容最新版常见浏览器，鼠标与键盘都能操作

【功能清单】
1. ……（每条写成可以"通过或不通过"的判断句）
2. ……

【验收标准】
- 打开页面控制台没有报错
- 按下指定按键，指定元素必须发生可观察的变化
- 从开始到结束，完整流程能走通一遍

【迭代规则】
- 每次只改我指出的部分，其他部分保持不变
- 修改后用一句话说明改了哪些地方

这里面最关键的是【验收标准】。如果你不告诉模型"怎样算做完了"，它就只能凭感觉停下来。把验收写成可观察、可判断的语句，既能指导生成，也方便你后面快速检查。

5.3 一套可以反复使用的迭代流程

光有模板还不够，工作流同样重要。我习惯把整个过程画成一个循环，让模型的"自反馈"在使用侧也有用武之地。需要说明：官方说的自反馈是模型训练阶段的技术，我这里把它类比到使用阶段，是一个个人的工作方法，不是官方的操作规范。

flowchart TD
    A[写需求说明 含验收标准] --> B[模型生成首版]
    B --> C[在本地真实运行]
    C --> D{控制台有报错? 验收项全过?}
    D -->|有问题| E[把报错原文和现象截图回传给模型]
    E --> F[模型定位并修正]
    F --> C
    D -->|全部通过| G[人工体验一遍 检查观感]
    G --> H{满意?}
    H -->|否| I[提出具体修改点 回到迭代]
    H -->|是| J[保存版本 记录提示词]
    I --> B

这套流程里有三个细节，是我个人比较推崇的好习惯：

细节一：报错信息要原文回传。 不要自己概括成"页面打不开了"，把控制台的错误行完整复制给模型。原文里的行号、变量名、堆栈信息是它定位问题的线索，你一概括，线索就丢了。

细节二：每轮只提一个修改点。 你一次提五个要求，模型改了三个、漏了两个、还顺手动了一个你没提的，最后很难追查。小步迭代虽然看起来慢，实际总耗时往往更短，成本也更可控。

细节三：每次通过验收就存档。 把当时的代码和对应的提示词一起保存。后续修改搞砸了，可以随时退回，也方便你复盘"哪种写法的需求说明成功率更高"。

5.4 一个虚构的完整例子：桌面专注计时器

为了让你看到整个过程，我虚构一个小项目，名字叫"桌面专注计时器"，只做原型验证，不涉及任何真实业务数据。

第一轮：先出最小可运行版本

【目标】做一个网页版专注计时器，给学生和上班族用，界面简洁。
【技术约束】单个 HTML 文件，不引用任何外部资源。
【功能清单】
1. 可选择 15、25、45 分钟三档倒计时
2. 开始、暂停、重置三个按钮
3. 倒计时结束时页面显示"本轮完成"并有视觉提示
【验收标准】
- 控制台无报错
- 点开始后每秒数字递减
- 暂停后数字保持不变，再点开始能继续

拿到首版后，我会按验收标准一条一条手动点一遍，很快就能知道哪一项没过。

第二轮：补充一个交互层的需求

在现有基础上增加：按空格键可以开始或暂停。
不要改动其他功能，改完告诉我改了哪些函数。

第三轮：加上反馈层

增加一个"今日完成轮数"的计数，页面刷新后不要求保留。
每完成一轮，计数加一，并在页面角落轻微闪动一次。

如果你想试一下"带场景的 3D 项目"，比如一个只有桌子、书架和台灯的小书房，可以在技术约束里额外写明"使用浏览器原生能力或体积较小的三维库，并把库文件内嵌或随项目一起放置，不要引用境外在线地址"。这样做有两个现实好处：一是国内网络环境下页面能稳定打开，二是避免因为外链失效导致整个页面空白。

5.5 让模型帮你"自查"：三个有用的追加要求

在每一轮生成后，我会追加一句让它自己检查的话。这几句我觉得很值：

1. 请逐条对照验收标准，