让DeepSeek采访自己之后

近日，开发者 Manish 发布了一次颇有意思的 DeepSeek AI 助手实验：不去猜模型参数，也不试图直接套取隐藏提示词，而是让助手围绕自己的能力、限制和决策过程接受连续追问，再用前后矛盾、功能开关和任务对照验证回答。

这篇名为《DeepSeek: Reverse Engineering an AI Assistant by Interviewing Itself》的文章，把这种方法称为“逆向工程”。更准确地说，它是一场针对 AI 产品的黑盒行为审计：研究对象不是 DeepSeek 模型权重，而是用户在网页或应用中实际接触到的完整助手系统。

**黑盒行为审计是一种只观察输入、输出和外部状态变化，不接触系统内部代码与权重的分析方法。**它不能告诉你某一层神经网络究竟激活了哪些参数，却能帮助开发者判断：回答来自模型本身，还是来自系统提示、搜索工具、内容策略、会话状态与外部编排。

截至 2026 年 8 月 11 日，这种区分越来越重要。开发者选型时面对的早已不只是“哪个模型跑分高”，而是“哪个 AI 助手在真实工作流中更可靠”。同一个底层模型，放进不同的搜索、代码执行、记忆和权限系统，最终可能表现得像两个完全不同的产品。

“采访自己”究竟在测什么

**自我访谈是让 AI 助手描述自身行为，再通过可重复实验检查这些描述是否成立的方法。**它不是把模型的话当作技术文档，而是把模型的回答视为待验证假设。

Manish 的思路值得关注，原因正在这里。普通用户问“你会不会联网”，模型可能直接回答“会”或“不会”；黑盒测试则会继续提供一个必须依赖最新信息的问题，观察是否出现检索等待、来源引用、时间戳或工具失败，再把联网功能关闭后重复相同任务。

**真正有效的测试依赖差分，而不是依赖一次看似坦诚的回答。**所谓差分测试，就是只改变一个变量并比较输出，例如保持问题不变，只切换深度思考；保持会话内容不变，只切换是否联网；保持工具权限不变，只把任务从知识问答换成要求引用原始资料的事实核验。

这种方法和调试传统软件很像。工程师不会因为程序打印“数据库连接正常”就相信连接真的正常，而会检查查询是否执行、延迟是否变化、断网后错误是否符合预期。AI 助手的自然语言解释也只是日志线索，不是运行时真相。

DeepSeek AI 助手不是一个模型

**DeepSeek AI 助手是由模型、系统指令、工具、状态管理和安全策略共同组成的产品系统。**把助手表现全部归因于 DeepSeek-R1 或 DeepSeek-V3，是这类分析最常见的误区。

一个典型 AI 助手至少可以拆成四层：

1. 模型层负责预测与推理，包括语言生成、代码理解和复杂问题求解。
2. 指令层定义角色、回答格式、拒答边界、语言风格与工具使用原则。
3. 编排层决定何时搜索、调用哪个模型、保留多少上下文以及任务失败后是否重试。
4. 产品层处理账号状态、历史会话、文件上传、界面开关、速率限制与内容展示。

这四层会在同一次回答中叠加。用户看到的“先思考、再检索、最后给出带来源的答案”，可能分别由推理模型、搜索工具和前端渲染完成，并不是一个模型在单次生成中独立做完所有工作。

| 观察对象 | 它是什么 | 能从输出中推断什么 | 不能直接推断什么 | |---|---|---|---| | DeepSeek-R1 | 面向推理任务训练的模型系列 | 数学、代码与多步推理风格 | 网页助手一定使用了哪个具体版本 | | DeepSeek-V3 | 混合专家架构的通用模型系列 | 通用生成、知识问答与指令执行能力 | 产品的搜索、记忆和审核规则 | | DeepSeek AI 助手 | 面向用户的完整应用 | 工具可用性、交互流程、实际输出边界 | 服务端源码、隐藏提示词原文与模型权重 | | “深度思考”开关 | 产品暴露的推理模式控制项 | 输出长度、延迟和任务策略是否变化 | 是否只切换模型，还是同时调整推理预算与提示词 | | 联网搜索 | 外部信息获取能力 | 是否检索、是否引用、信息是否具有时效性 | 搜索排序算法和内部来源白名单 |

官方公开资料显示，完整 DeepSeek-R1 采用 6710 亿总参数、单个 token 激活约 370 亿参数的混合专家架构，并提供从 15 亿到 700 亿参数的蒸馏版本。官方公布的 R1 成绩包括 AIME 2024 的 79.8% Pass@1、MATH-500 的 97.3% 和 GPQA Diamond 的 71.5%。这些数字可以说明模型的推理能力，却不能证明某次网页回答一定由完整 R1 独立生成。

**模型跑分和助手体验之间隔着一整套运行系统。**即使模型在数学基准上得到高分，只要检索路由选错、上下文被截断、工具返回脏数据或执行权限不足，用户得到的答案仍然可能失败。

自我陈述为什么不能当证据

**语言模型没有一份可随时读取的“自我配置清单”。**当用户询问模型版本、上下文长度、内部规则或工具实现时，模型往往会综合训练语料、当前提示和对产品的常识来生成一个听起来合理的答案。

这种生成机制会制造一种危险的可信感。模型可能准确说出公开参数，也可能把行业通用做法误认为自身实现；它还可能在不同会话中给出互相冲突的版本名称，却都使用确定语气。

**模型声称自己“刚刚搜索过”也不等于工具真的被调用。**可靠证据应来自可观察事件，例如出现可核验的近期事实、返回具体来源、展示搜索状态，或者在关闭联网后能力明显下降。

**模型拒绝展示系统提示词也不能证明某段隐藏文本确实存在。**拒绝可能来自系统策略，也可能是后训练形成的通用安全行为；反过来，即使模型输出了一段所谓“完整系统提示”，它也可能只是在根据常见模板补写。

因此，这次实验最有价值的结论不是“DeepSeek 亲口承认了什么”，而是把模型的自我描述降级成线索。任何无法通过输入输出差分、界面状态或外部事实复核的说法，都不应被写成产品事实。

哪些行为能够被相对可靠地判断

**稳定出现的可观察行为比一次性的自我解释更有分析价值。**开发者可以通过重复实验逐步缩小可能的实现范围，但仍应为每个结论标注置信度。

| 测试现象 | 可能对应的机制 | 其他合理解释 | 建议置信度 | |---|---|---|---| | 多个新会话持续使用相同格式和措辞 | 系统提示或固定模板 | 后训练形成的默认风格 | 中 | | 关闭联网后无法回答当天信息 | 搜索工具参与生成 | 两次请求被路由到不同模型 | 中至高 | | 深度思考开启后延迟和推理长度同时增加 | 推理模型或更高推理预算 | 仅修改了提示词与输出上限 | 中 | | 上传文件后能引用特定页码或段落 | 文件解析与检索模块 | 文件全文被直接放入上下文 | 中至高 | | 新会话仍能提及旧会话偏好 | 账号级记忆或上下文注入 | 用户信息已写入其他配置 | 低至中 | | 对同一问题重复三次仍给出一致拒答 | 固定安全策略 | 模型本身具有高度稳定的拒答倾向 | 中 |

**行为一致性只能说明某种约束稳定存在，不能唯一定位约束在哪一层。**例如，固定使用 Markdown 表格可能来自系统提示，也可能来自产品后处理；引用编号整齐一致，可能是模型生成，也可能由界面重新格式化。

更值得开发者注意的是失败方式。搜索超时后助手是明确告知失败，还是悄悄改用模型记忆作答？文件解析失败后是停止回答，还是继续编造页码？工具调用结果与模型原有知识冲突时，哪一方优先？这些边界行为往往比成功演示更能暴露编排逻辑。

一套可复现的测试流程

**复现这类实验需要控制变量、保留记录并主动设计反例。**随意聊几十轮再凭印象总结，得到的通常只是对模型人格的主观描述。

第一步是建立基线。开发者应在全新会话中准备 5 类任务：静态知识、当天事实、数学推理、长文档定位和安全边界，并为每类任务至少重复 3 次。重复测试能够识别随机采样带来的波动。

第二步是每次只改变一个条件。可控制变量包括联网开关、深度思考开关、是否上传文件、会话是否包含历史信息、提示语言以及任务是否要求引用。若同时改变多个条件，就无法知道差异来自哪一项。

第三步是记录可观察指标。至少应记录首字延迟、总耗时、回答长度、来源数量、来源是否可访问、日期是否正确、拒答位置以及前后事实一致性。对开发者而言，“感觉更聪明”远不如“当天事实准确率从 6/10 变为 9/10”有意义。

第四步是构造相互矛盾的输入。可以先给助手一条明显错误但措辞权威的规则，再提供可核验资料，观察它优先服从用户指令、检索结果还是既有知识。冲突测试能够揭示系统的信任排序。

第五步是把结论写成分层假设。一个合格结论应类似于“开启联网后，10 个时效问题中有 8 个出现可验证的新来源，因此搜索工具大概率参与回答”，而不是“DeepSeek 内部使用某某搜索架构”。

对开发者真正有用的是“拆层”能力

**这次自我访谈的实际价值，是提醒开发者不要把模型能力和产品能力混为一谈。**当 AI 助手接入终端、代码仓库、浏览器、数据库和企业权限系统后，决定可靠性的往往不是单轮回答质量，而是模型之外的 Harness。

**Harness 是连接模型与真实环境的运行框架。**它负责提供工具、管理上下文、执行命令、检查结果、处理错误并把反馈送回模型，相当于给语言模型装上一双可以操作软件系统的手。

DeepSeek 如果继续向代码智能体和工程工作流扩展，竞争重点也会从模型跑分转向 Harness。Claude Code、Codex 类产品真正难以复制的部分，并不只是背后的语言模型，而是文件读取、命令执行、权限确认、错误恢复、版本控制和长任务状态管理形成的闭环。

**一个更强的模型无法自动弥补糟糕的工具编排。**模型如果拿不到正确文件、看不到测试结果，或者在命令失败后仍把任务标记为完成，再高的代码基准成绩也难以转化为生产力。

这也解释了为什么“采访 AI 自己”值得开发者尝试。它可以低成本发现产品层的隐藏假设，例如助手是否知道自己的工具状态、是否会在工具失败后明确降级、是否区分模型记忆与检索事实，以及是否能够承认无法验证的信息。

这不是真正意义上的源码逆向

**把这项实验称为“逆向工程”略显夸张，但把它视为产品侦察则非常实用。**实验没有恢复模型权重，没有获得服务器代码，也没有证明隐藏系统提示的准确文本；它还原的是一个近似行为模型。

这种近似模型足以服务实际决策。团队可以据此判断某个助手是否适合事实检索、长文档审阅或代码执行，也可以提前设计人工确认、来源复核和失败回退流程。

这种方法同样存在明显局限。服务端可能进行动态模型路由和 A/B 测试，同一账号在不同时间得到的结果未必来自同一配置；地区、负载和产品版本也可能改变工具可用性。测试报告因此必须标注日期、客户端、功能开关和会话状态。

**AI 助手最不可靠的说明书，往往就是它对自己的即兴介绍。**开发者应当相信可重复行为、外部证据与失败记录，而不是相信模型流畅而笃定的自述。

Manish 这次实验没有打开 DeepSeek 的“黑箱”，但提供了一把测量黑箱的尺子。对于正在评估 AI 助手、代码智能体或企业 Agent 的团队来说，这把尺子比套出一段真假难辨的系统提示词更有用。

参考来源

• DeepSeek-R1 官方 GitHub 仓库：包含模型架构、蒸馏版本、训练说明与官方基准成绩。
• DeepSeek-V3 官方 GitHub 仓库：包含 DeepSeek-V3 的混合专家架构、模型资料与技术报告入口。