Appearance
用 Codex 完成带来源的研究报告
哈喽，我是小枫。做研究工作这些年，我踩过不少坑——比如兴冲冲写完一篇"行业分析"，事后才发现引用的数据来自三年前的统计，结论完全站不住脚。后来慢慢摸索出一套方法，核心就一句话：让每一句话都能追溯回去。这个页面整理的流程，就是我现在自己做研究时真正在用的东西，分享给你。
研究任务最危险的事情，我自己的经验是：把没核实过的摘要当成事实写到报告里。AI 搜索摘要看着挺像回事，点进去原文往往完全不是那回事。所以我整理了一条可审计的流程：问题拆解、来源分级、主张台账、交叉验证、写作和引用检查。每一步都留记录，写完以后自己能复査，别人也能看懂你的证据链。
不会写代码怎样完成本章
说句实在话，我第一次做系统研究的时候也以为要写一堆脚本。后来发现完全不用。普通用户用 ChatGPT Work、网页搜索和文档/表格能力就能走完整条流程：先确认研究问题，让任务建立来源清单和主张台账，最后生成可预览报告。你不需要写爬虫、数据库或者分析脚本。
research-plan.md、claim-ledger.csv 这些名字只是方便说明的文件格式，你用 Word 写计划书、Excel 做来源表完全没问题。批量抓取、API、自动引用检查和程序化去重属于技术增强选项，有余力再搞，不用一开始就追求自动化。
如果你对判断来源质量和检查成品还不熟，推荐先看 文件验收教程，那篇讲得更基础一些。
第一步：把主题改成可回答的问题
我刚开始做调研的时候经常犯一个错——问题太宽了，比如"研究一下 AI 电商"。这种问题搜出来的东西乱七八糟，根本没法收尾。
差问题：“研究 AI 电商”。
可执行问题：
text
截至 2026-07-11，一个 5 人跨境电商团队把 AI 用于选品、Listing、素材和客服时，哪些环节已经有可落地工具，哪些环节仍必须人工控制？重点比较成本、数据权限、质量风险和上线门槛。这个问题的核心是定义了五样东西：时间范围、地区、对象、比较维度和决策目的。少了任何一样，你就很难知道什么时候算"研究完了"。我现在的习惯是，动笔之前先把这五个维度写清楚，否则后面肯定跑偏。
第二步：建立来源层级
搜索到的东西不是平等的，这是我踩了无数次坑才意识到的。现在我的优先顺序是：
- 官方文档、法规、原始数据和正式发布；
- 官方仓库、技术论文和可复现实验；
- 可靠媒体、行业报告和专家访谈；
- 社区文章、视频和社交内容，用于发现线索；
- 搜索摘要，只用于导航，不直接作证据。
产品能力、命令、版本和价格必须优先回到当前官方来源。为什么要强调"当前"？因为我吃过亏：某 SaaS 产品的定价页面半年改了三次，我用旧的截图做推荐，结果给朋友指了条弯路。教训就是版本敏感信息一定要亲自打开官网确认。
第三步：先写研究计划
这一招是我从一个做咨询的朋友那学来的：按住自己，别上来就搜。先拆问题。
text
先不要写报告。把研究问题拆成 6-10 个子问题，给每个子问题定义需要的证据、首选来源类型、时间范围和停止条件。
输出 research-plan.md。不要开始大范围搜索，先让我审查。停止条件特别好用。比如"找到一份官方说明和一份独立实测交叉验证"就比"多搜搜看"强一百倍——有 stop 条件你才能知道自己什么时候可以收工。我最早做研究的时候就是因为没有停止条件，搜了两天还在搜，最后写得筋疲力尽。
第四步：建立检索日志
source-log.csv 字段：
text
source_id,title,url,publisher,date,accessed_at,source_type,question,relevance,notes提示：
text
按 research-plan.md 搜索。每打开一个来源就记录 source-log.csv。不要把搜索结果摘要当正文证据；必须打开原页面。遇到登录、验证码、付费墙或访问限制时停止并标记，不绕过。必须打开原页面这件事，我再说一遍：必须打开。AI 的搜索结果摘要经常断章取义，我自己遇到过好几次，摘要看起来完美支持我的论点，点进去发现说的是另一件事。另外，遇到付费墙就标记，别想着"绕过看看"，合规问题比多一条引用重要得多。
第五步：建立主张台账
claim-ledger.csv：
text
claim_id,claim,source_ids,evidence_type,status,confidence,caveat,report_section每个准备写入报告的事实必须有来源。状态可以是：confirmed、conflicting、unverified、analysis。
text
把来源中的候选结论写入 claim ledger。每条用自己的话表达，不复制长段原文。区分来源明确说了什么、可以合理推导什么、还不知道什么。这个台账是我整个流程里最核心的一步。写 claim 的时候强迫自己"用自己的话说"，你会发现有些你以为是事实的东西，其实只是你的推断。能推导的就标 analysis，别混在 confirmed 里——读者会误以为有来源背书。
第六步：处理冲突和时效
遇到两个来源结论不同，我现在的处理方式是：
- 比较发布日期和适用版本；
- 比较样本、地区和定义；
- 回到原始数据或官方说明；
- 在报告中保留分歧，不强行选一个；
- 写清当前判断和不确定性。
价格、套餐、模型、法规和市场数据必须标注核验日期。
我自己的一个经验：读者其实不介意看到"这里存在分歧"，他们介意的是你明明看到了冲突却假装只有一个答案。把分歧亮出来反而显得你做过功课。
第七步：先写结论骨架
写完整报告之前，先搭骨架。这一步的目的是确认你的证据真的能撑起结论。
text
只使用 claim-ledger.csv 中 confirmed 和 analysis 项，生成报告骨架。
结构：
1. 结论摘要；
2. 决策建议；
3. 证据与比较；
4. 风险和限制；
5. 仍需回答的问题；
6. 方法与来源。
每段标注将使用的 claim_id，不写完整正文。先审查证据能否支持结论，再进入润色。我踩过的一个坑是：写完全文才发现某个关键论点对应不上任何一条 claim。先搭骨架就能提前暴露这个问题，省得后面大改。
第八步：完成正文与引用
text
按已确认骨架写 3000-4000 字中文报告。每个版本敏感或可争议事实紧跟引用链接；短引文保持必要长度，其余用原创归纳。把作者分析明确写成分析，不伪装成来源结论。对每条引用检查：
- 链接能打开；
- 页面确实支持前面的句子；
- 日期和版本匹配；
- 没有把二手转述伪装成原始来源；
- 引用范围没有覆盖过大的综合结论。
逐条验证引用很枯燥，但这个步骤省不掉。我一般会在周末早上花一两个小时专门做这件事，打开咖啡、打开每个链接、一条一条对照。偷懒的结果往往是报告发出去以后被人揪出一个坏链或者牛头不对马嘴的引用，那个尴尬程度我不想再体验第二次。
第九步：做反方审查
text
以怀疑者角度审查报告：找出证据不足、相关性被写成因果、样本偏差、过期事实、定义偷换和遗漏反例。每条回到 claim ledger 和来源验证，不只给泛泛意见。这一步如果能找一个不了解这个主题的朋友来做最理想——他们天然就是"怀疑者"。我有时候会让队友帮忙看一眼，往往能发现我因为太熟悉主题而忽略的逻辑跳跃。
第十步：交付可复核材料
最终目录：
text
research/
├── report.md
├── report.pdf
├── research-plan.md
├── source-log.csv
├── claim-ledger.csv
└── figures/公开交付时不要附带受限原文、个人数据、登录内容或无权再分发的附件。这个提醒看起来理所当然，但我确实见过有人在报告附件里贴了付费数据库导出的全文 PDF，这在法律上很危险，记得留意。
常见失败
搜索很多，证据很少
把注意力从"网页数量"转到"主张是否有第一方证据"。搜了 50 个网页但没一个能跟到原始数据，你需要的是更聚焦而不是更多网页。
引用链接和句子无关
逐条打开验证，不依赖搜索摘要和模型记忆。用 AI 生成的引用尤其要小心——它会一本正经地编造看起来很合理的链接。
内容像目标文章
我早期的一个毛病是：看完几篇参考文章后写出来的东西，结构、语气甚至比喻都跟原文一样。解决方法是先建立自己的问题、claim ledger 和结构，再关掉参考页面用自己语言写。不要沿用来源的标题顺序、比喻和句式。
把没有结果写成负面结论
"没有找到证据"等价于"目前没搜到"，它和"事实不存在"是两码事。标为未验证并说明检索范围，这样读者知道你的搜索边界在哪里。
完成门槛
- [ ] 研究问题有时间、范围和决策目的。
- [ ] 每条关键事实进入 claim ledger。
- [ ] 搜索摘要没有直接充当证据。
- [ ] 冲突、分析和未知项清楚区分。
- [ ] 引用逐条打开验证。
- [ ] 报告结构和语言为原创归纳。