深度研究最容易制造一种错觉：报告很长、链接很多，所以结论一定可靠。实际上，引用数量只说明系统找到了页面，不能证明来源有资格回答问题，也不能证明推理成立。
这篇文章适合做竞品分析、行业扫描、选题研究或技术调研的人。示例以 ChatGPT Deep Research 为主，但证据方法同样适用于其他研究型 Agent。
真正的研究从问题边界开始
“研究 AI 编程工具”只是一个主题。可执行的研究问题还要包含对象、决策、时间和排除项。例如：为一个五人 Web 团队判断未来八周应该先试点 IDE 助手、终端 Agent 还是云端异步 Agent，并明确不根据单次 benchmark 直接做采购结论。
问题越具体，检索才越有停止条件。没有决策对象的研究往往会无限收集资料，最后只得到一份信息摘要。
查看图示源码
flowchart LR
subgraph S1["01 设定"]
direction TB
A["研究问题"] --> B["来源计划"]
end
subgraph S2["02 取证"]
direction TB
C["检索与阅读"] --> D["证据矩阵"] --> E{"证据平衡"}
end
subgraph S3["03 交付"]
direction TB
F["形成判断"] --> G["抽查引用"] --> H["决策材料"]
end
B --> C
E -- "否" --> B
E -- "是" --> F来源策略比搜索数量更重要
把来源分级，能防止十篇转载覆盖一份官方说明。
| 级别 | 典型来源 | 在报告中的作用 |
|---|---|---|
| 一级 | 产品文档、论文、规范、监管文本 | 支撑功能和事实 |
| 二级 | 有方法说明的独立测评、采访 | 补充实践与限制 |
| 趋势 | 公众号、X、社区讨论 | 发现问题和用户体验 |
| 线索 | 搜索摘要、聚合页 | 继续寻找原文 |
关键产品能力至少需要一份官方来源；关键判断最好由两类独立来源共同支持。来源冲突时，不要让 AI 替你挑一个顺耳答案，而应保留冲突及其可能原因。
- 官方资料55%
- 专业分析25%
- 社区线索20%
教学示例，不是行业统计数据；比例用于解释来源组合方法。
查看数据
| 来源 | 占比 |
|---|---|
| 官方资料 | 55% |
| 专业分析 | 25% |
| 社区线索 | 20% |
证据矩阵让结论可以复核
在写报告之前，先建立“主张—证据—限制”的对应关系。
| 主张 | 证据摘要 | 来源类型 | 支持强度 | 限制 |
|---|---|---|---|---|
| 终端 Agent 可以执行测试 | 官方工作流说明 | 一级 | 强 | 不代表测试一定充分 |
| 某工具更受开发者欢迎 | 社区讨论样本 | 趋势 | 弱 | 样本偏差明显 |
每个核心主张至少回答三个问题：来源真正说了什么、来源有没有资格知道、同一证据还有没有其他解释。这样，读者看到的不只是结论，还有判断路径。
研究过程中必须允许纠偏
研究计划不是一次性指令。运行过程中如果大量结果来自同一厂商、旧版本与新版本混在一起，或“功能存在”被推导为“效果更好”，就应暂停综合并补充来源。
OpenAI 官方说明允许用户检查研究计划、观察进度并中途调整。有效的纠偏不是简单地“再搜一些”，而是指出当前证据结构哪里失衡，例如要求补充独立实践资料和失败案例。
报告要服务决策而不是展示搜索
一份可用的研究报告通常包含执行摘要、范围与方法、按问题组织的发现、证据矩阵、冲突与空白，以及一个小规模验证实验。它应明确区分事实、推断和选择。
不要删除“不确定”。诚实的报告会告诉读者哪里证据最弱、哪些问题公开资料无法回答，以及哪些结论只得到厂商材料支持。
最后的工作是抽查而不是润色
至少核验全部数字、全部直接影响决策的引文、全部一级结论，以及一部分普通引用。检查链接是否指向原文、原文是否支持紧邻主张、日期和版本是否适用，以及是否把相关性写成了因果关系。
如果抽查发现系统性错引，就应回到证据矩阵，而不是只修改出错句子。研究可信度来自过程可复核，不来自成稿的自信语气。
下一步可以把研究材料沉淀到AI 第二大脑，或继续学习Codex 智能体仓库交付。