DeepSeek错误复现提示词细节保留：5个关键步骤

使用DeepSeek复现错误时，一个常见痛点在于模型常擅自“修正”关键细节：连字符被替换为下划线、大小写被统一、特殊符号被“优化”，最终复现场景与原始错误完全脱节。

解决这一问题需遵循四个步骤，每步均有特定要点。

第一步：以原始日志片段替代自然语言描述

放弃自行归纳，直接将终端中的完整报错信息复制过来。务必包含HTTP状态码、JSON响应体、堆栈行号，前后各保留两行上下文亦无妨。

例如：{"code":"invalid_param","msg":"field 'User-ID' is not allowed"}。将上述JSON片段原样输入后，模型会锁定User-ID这一包含连字符和大写的字段名，不会擅自将其改为user_id——精确的字符串锚点彻底限制了模型的“修正”倾向。

操作上极为简便，直接将文件拖入即可。但需谨记：【必须保留原始换行、缩进、引号类型（单/双）、空格数量】——即使看似冗余。模型对这些格式敏感，引号和缩进的完整性是模型精确执行指令的前提。

第二步：标记不可更改的“锚点字符”

在原始日志内，使用方括号明确标注你要求模型绝对保留的字符组合，例如："field '[User-ID]' is not allowed" 或 curl -H "Authorization: Bearer [sk-xxx]"。

方括号会触发模型的字面量保护机制，绕过所有标准化与规范化处理。实验表明：未加括号的User-ID常被转为user_id，加括号后则原样保留，连字符亦不受影响。

第三步：界定复现操作的可执行范围

① 打开错误复现场景的代码，定位触发该报错的具体请求行；
② 在提示词中明确：“仅允许修改第12行的headers字典，其余所有行（包括import、URL拼接、response处理）禁止增删任何字符”；
③ 附加硬约束：“headers键名必须与原始日志完全一致，值字符串的长度误差不超过±1个字符”。

完成上述三步后，模型不会擅自补充缺失的Content-Type头，也不会将sk-xxx替换为api_key_123——其修改范围被严格限定在你指定的物理边界内。

第四步：植入仅你环境独有的校验线索

方法一：添加一行仅你的系统才有的响应特征，例如：“返回body中包含"trace_id":"trc-7f3a9b"，且该trace_id在Kafka topic deepseek-debug中存在对应日志”。

方法二：补充仅在本地调试时才能观察到的现象，例如：“在VS Code调试器中，第8行变量payload的__dict__属性显示_raw字段值为b'{"id":1}'”。

此类信息无法伪造，模型无法用通用知识覆盖——它只能严格依照你提供的线索执行复现。核心在于：你提供的并非泛场景描述，而是仅可被你自己验证的精确信号。