karminski-牙医@karminski3 · X如果你在用 DeepSeek-V4 写代码，这个坑迟早会踩到，作者把问题和解法都讲清楚了，不用等 IDE 修，看完就能自己改。
用户在使用DeepSeek-V4 API或集成该模型的终端编码代理（如Claude Code、Kimi CLI）和AI IDE（如Cursor）时，频繁遇到HTTP 400报错。错误信息指出，在思考模式下必须将`reasoning_content`字段回传给API。核心问题在于，当任务步骤的`tool_call`过于简单直接时，DeepSeek-V4返回的`reasoning_content`可能为空字符串。许多开发工具默认会过滤掉空值字段，导致该字段未被回传，从而触发API报错，致使编码任务或代理中断。经测试，在特定场景下该字段返回空字符串的概率高达59%。解决方案是必须将空字符串值的字段原样回传，不能省略或改为空对象。目前需等待IDE官方修复或自行修改开源工具，使用DeepSeek-V4的代理项目也需注意此问题。
给大家说下目前使用 DeepSeek-V4 （pro/flash） 的最需要注意的问题. 本身其实并不算 bug， 但是却很致命.
问题大概是这样的， 在请求 DeepSeek API 或者 terminal coding agent （claude code， kimi cli 等） / AI IDE （cursor 等） 用 DeepSeek 的时候偶尔会遇到报错：
HTTP 400 {"error"：{"message"："The `reasoning_content` in the thinking mode must be passed back to the API."，"type"："invalid_request_error"，"param"：null，"code"："invalid_request_error"}}
这个报错的意思是， 请求 DeepSeek API 必须在 tool_call 的时候回传 reasoning_content 这个字段. 听上去没问题， 开了思考模式那肯定要把 reasoning_content 作为上下文回传.
但是来了， 如果任务的这一步制定的 tool_call 过于显而易见， deepseek 返回的 reasoning_content 其实是空字符串. 这就导致了有些写代码的 IDE 直接过滤掉了这个字段， 不回传， 导致 DeepSeek API 报错， 编码任务或者 Agent 就直接挂了.
DeepSeek-V4 API会不会真的有的时候 reasoning_content 空字符串？ 答案是会的， 我专门构建了个 POV 场景， 复现概率高达 59%.
那么出现 reasoning_content 为空字符串的时候该怎么办？
经过验证， 答案是必须原样传回去. 即也在 context 中保留这个值为空字符串的字段. 不能是空对象， 也不能丢掉.
那就原样传回去呗？ 废什么话呀？
关键是， 现有的各种 terminal coding agent 或者 AI IDE 这并不是默认行为， 它们大部分的默认行为是直接把字段丢掉了， 导致 DeepSeek-V4 API 报错.
所以现在的解决方法是， 要么等 IDE 的官方修复， 要么你用的 IDE 或者 coding agent 是开源的， 自己 fork 一个版本魔改.
另外， 如果你的 Agent 项目要使用 DeepSeek-V4 也要注意这个坑. 避免运行到一半直接报错退出.
以及， 报错重试不太行的， 因为 DeepSeek-V4 在我 POV 这个场景， 59% 的概率都会为空. 如果重试次数为 3， 那偶尔都不够用. 所以还是老实的把问题解决为好.
#deepseek #deepseekv4