DeepSeek-V3 隐藏功能揭秘：你可能不知道的用法

我是怎么发现这些的

事情要从上个月说起。我在写一个爬虫脚本，逻辑上有个死循环问题，我随手把代码贴给了 DeepSeek-V3，没指望它能怎样——毕竟之前用别的模型，长代码基本是“看起来对了，跑起来全崩”。

结果它不光指出了死循环，还提示我可以在同一个对话里直接让它拆解任务、用 JSON 输出结构化结果，方便我写测试用例。我当时愣了一下：这些用法我根本没用过。后来我花了一周时间，专门把 DeepSeek-V3 的各种边角功能翻了个遍，踩了不少坑，这篇文章就是把那些真正好用的“隐藏用法”整理出来。

我最早的用法很土：提示词末尾加一句“请以 JSON 格式输出”。结果十次里有两三次它会先来一句“好的，以下是您需要的 JSON：”，直接把我的解析脚本干崩了。

后来我学到了正确姿势——在提示词里给出精确的 JSON Schema，并且用“只输出”来约束：

只输出合法 JSON，不要任何解释文字、markdown 代码块标记。
格式如下：
{
  "bugs": [{"line": int, "severity": "high|medium|low", "description": string}],
  "summary": string
}

实际效果对比：用“请输出 JSON”，我测了 20 次，5 次带额外文字；用“只输出合法 JSON，不要任何解释文字”，20 次全部干净。就这么一句话的差别。

一个小坑：如果你需要它输出包含换行的字符串，记得在 schema 示例里说明“字符串内换行用 \n 转义”，否则它真的会输出原始换行符，json.loads 直接报错。我在这上面浪费了半小时。

DeepSeek-V3 支持很长的上下文窗口，但我一开始用错了——把所有资料一次性丢进去说“帮我总结”。

正确用法是分阶段喂料：

这样做的效果远好于一次性提问，因为它会真正“记住”上下文细节。我试过让它对比一份技术方案的前后两个版本找差异，分阶段喂入后，它抓出了 3 处我人工都没注意到的参数默认值变更。

注意坑点：对话拉得太长后，早期细节会被稀释。如果任务超过十几轮，把关键结论让它在中间阶段显式总结一遍（“请用 5 行总结目前确认的结论”），能明显提升后期回答的稳定性。

这是我个人体感最明显的用法差异。直接问“这段代码为什么报错”，它经常给出一个能跑但不优雅的补丁。

换成两段式提示：

第一步：只分析这段代码的问题，列出至少 3 个潜在缺陷，不要给出修改代码。
第二步：等我确认后，再给出修复方案。

为什么有效？第一步强制它做全面审查，而不是盯着最显眼的那个报错。我有一段 Go 代码，报错是空指针，它第一步列出的缺陷里除了空指针，还发现了 goroutine 泄漏和一处未加锁的 map 写入——后两个在直接提问模式下从没出现过。

给模型设角色很常见，但多数人只设“你是资深程序员”。实测更有效的做法是角色 + 明确的输出立场：

你是一个挑剔的技术评审，任务是否决我方案中的漏洞。对每个方案，
先给出"驳回理由"，只有当我回答了你所有质疑后才允许认可。

我用这个模式评审过自己的微服务拆分方案，它连续提了 4 轮质疑（数据库跨服务事务、重试风暴、幂等性、灰度切换），每一轮都逼我补细节。最后方案比初版扎实得多。这种对抗式用法比“你是专家请点评”强太多了——后者它只会礼貌地说“整体不错，但可以考虑……”。

DeepSeek 系列的推理能力不错，但 V3 在复杂多步计算上偶尔会跳步。加一句咒语：

每一步计算完成后，用代入法反向验证该步结果，验证失败则回退重算。

我拿一道库存+折扣+税率的多步计算题测试，不加指令时正确率大概 7/10；加上反向验证后 10/10，代价是回答变长。值不值看场景——日常问答别加，财务、报价这类算错会出事的场景必须加。

最后说点实话，免得你期望过高：

JSON 输出不是 100% 可靠。极端复杂的嵌套 schema 下仍偶有字段遗漏，生产环境务必加解析容错和重试逻辑。
超长上下文也有衰减。别指望它记住 10 万字文档里的每一个数字，关键数据让它在回答中引用原文段落，方便你核对。
实时信息不行。它不知道最新的库版本和 API 变更，涉及新版本的问题它可能会自信地给你过时答案——这是我踩过最疼的坑，它曾给我一个在新版中已废弃的函数用法，语气还非常笃定。
对抗式评审偶尔会“为反对而反对”，第四、五轮的质疑质量会下降，见好就收。

总体来说，DeepSeek-V3 的潜力大头不在模型本身，而在你怎么喂、怎么约束、怎么分阶段。同样的模型，换一套提示策略，产出质量能差出一个档次。把上面这几个用法融进你的日常流程，至少能省掉一半的返工。