上一篇谈了 AI 与论文阅读，今天讲第三个部分——论文写作。

论文写作可能是 AI 最难真正替代人的一个环节。

AI 很容易给你一篇"及格"的论文，但想把它从 60 分改到 80 分，花的功夫往往不比​自己重写少。越往上改，边际收益越低。

当然，这件事首先要区分工程类论文和人文社科论文。

---

一、工程类 vs 人文社科

对于工程类论文来说，AI 的介入相对容易。

它们研究 gap 往往更加明确，methodology 很多已经体现在 code、实验记录、系统架构和算法流程里，而且这些东西都是可以被显性提取的

所以只要研究本身已经做得比较完整，AI 往往能比较容易地总结出主要卖点，再组织成一条基本合理的叙述线。

但到了人文社科，事情就完全不一样了。

人文社科论文的写作并不是把"已有信息整理成句子"这么简单，它更像一条河。

文章始终有一条中心叙述，但过程中要不断汇入新的理论、文献和证据。

有的地方应该快速推进，有的地方需要停下来铺垫；有些理论值得展开，有些理论虽然相关，却只能轻轻带过。

河还是那条河，但什么时候加速、什么时候转弯、什么时候让一条支流汇进来，严重依赖研究者自己的判断。

---

二、AI 最容易出问题的地方

而这恰恰是 AI 最容易出问题的地方。AI 最大的问题并不是不会写句子，而是抓不住为什么要这样写。

它经常会抓住一个点，然后展开成四五个并列的小概念，每个都没错，但就是不肯点破背后的核心。看起来写了很多，实际上一直在门口徘徊，就是不进去。

你问它一个问题，它很容易给你三个维度、四个方面、五个特点。但哪个才是核心？为什么是这四个？它们之间是什么关系？这些问题 AI 往往回答不好。

---

三、好的文章是一个圆

所以我越来越觉得，好的论文其实是一个整体。Research question、literature review、theoretical framework、method、results、discussion 不是几个独立章节，而是在不断互相回应。

前面提出的问题，会在后面的 method 中被操作化；literature review 里提出的 tension，会在 findings 中重新出现；理论框架中的概念，会决定你如何解释结果；discussion 最终又应该回到文章一开始提出的问题。

一篇真正好的论文，很多东西是跨章节发生联系的。

而 AI 最大的弱点之一，就是特别容易局部正确、整体失焦。

---

四、那么，人的价值到底在哪里？

我现在觉得，核心在于研究者拥有整篇文章的作者性。你要知道：

• 这篇文章到底想证明什么，哪些东西是真正重要的；
• 什么时候应该展开，什么时候应该收住；
• 不同章节之间应该如何互相回应。

AI 可以帮你表达，但它不能替你拥有一个必须被表达出来的中心判断。换句话说，研究者真正握住的不是键盘，而是整篇文章的叙述权。

---

五、如何合理利用AI写作？

我并不反对用 AI 写论文。相反，我自己也大量在用。

但如果想让 AI 真正参与论文写作，比较稳妥的办法是把论文当成一个系统工程。我比较推荐参考 Paper Spine、Academic Paper Research 这类 skill 的思路。

1. 文献综述最好先结构化成表格。明确每篇文章研究了什么、用了什么方法、得出了什么结论、彼此之间有什么差异。
2. 把你脑子里的东西显性记录下来。比如自己的学术背景、论文目标、research question、理论框架、章节结构等等。
3. 每个章节提前写清楚三件事。这一节要解决什么问题？承接前文什么内容？最后要把读者带到哪里？
4. 给 AI 几篇真正好的参考论文。如果你的领域有比较特殊的写作传统，还可以给 AI 几篇真正好的参考论文，让它理解这个领域的论证方式和叙述节奏。
5. 最后处理语言层面。最后用用 Humanizer、Stop Slop 之类的 skill 去处理语言层面的机械感和 AI 味。

整个过程其实很像 coding。你需要把原本存在于脑子里的文章结构、约束和依赖关系显性化，再让 AI 去完成局部任务。

这一整套流程确实很重，但它能真正解决怎么让 AI 尽量不要破坏研究者原本的文章意图。最后你可能会得到一份 70 分甚至更好的 AI 初稿。

---

结语

但这套复杂流程本身也说明了一件事：

真正决定论文质量的，从来不是句子是谁写出来的。

真正有价值的是谁决定文章想证明什么，谁在选择论证路径，谁在不断删除不重要的内容，谁在维持不同章节之间的联系，又是谁最终对这套论证负责。

AI 可以替代一部分写作劳动。但研究者不能把自己的作者性一起外包出去。

我是Erwin，PolyU在读PhD，前Alibaba & Shopee开发，专注AI Agent行业。我会分享硬核的前沿AI知识和开发干货。如果你也是AI Builder，欢迎关注我。

最近大家都在聊，随着大模型自身能力的爆发，外层的工程框架（Harness）正在变得越来越薄。甚至很多人觉得，以后不需要什么复杂的 Agent 架构了，模型自己就能搞定一切。

但如果你真的动手搭过生产级的多智能体系统，就会发现一个非常反直觉的现场：

当你让单个 AI 去写代码时，它干净利落。可一旦你把三四个 Agent 拉进同一个群聊让他们协同办公，不出三轮，就会退化成灾难级的互相吹捧、重复回答以及上下文失控。

为什么会这样？很多人的第一反应是Prompt 没写好或者模型智商不够。

其实根本原因在于：

从一开始，大家选用的系统拓扑结构就错了。

在现实的软件工程和多智能体世界里，想要让 AI 之间能稳定干活，目前已经自然分化出了两套截然不同的底层协作模型。

---

一、 主从派发模式（Master-Worker）：面向单点执行的总管与分包

当你看到像 Claude Code、Codex，或者各类针对复杂单点任务的 Sub-agent 框架时，它们底层几乎清一色跑的是这套逻辑。

想象一个非常高效的团队，大老板手下有一个极其精明的总管，总管手下有若干个专员。

老板走过来说：“帮我准备一下明天的技术发布会。”

总管绝对不会把所有小弟拉进一个大微信群里头脑风暴，因为那样大家很快就会在群里水群打架。总管的做法非常冷酷：

• 把小弟 A 叫进办公室：“你，去查一下明天会场的网络和投影规格，查完写成一行字给我，其他不用管。”
• 把小弟 B 叫进办公室：“你，去把发布会 PPT 的第三页字体改了。”
• 小弟们彼此完全不知道对方在干嘛，他们只对总管负责，交完差就回去待命。总管把两份结果一拼，回给老板。

在系统架构里，这叫Hub-and-Spoke（星型）或 Master-Worker 树状拓扑。

主控 Agent 派发子任务，就像程序调用一个远程子函数（RPC）一样干净，有严格的输入和输出契约。

每个 Sub-agent 都在自己独立的沙箱上下文里运行，小弟翻阅海量网页产生的中间垃圾信息阅后即焚，完全不会污染主线程和其他人。

这套模式天生适合那些因果链极强、且拥有“客观裁判”的硬任务。

最典型的就是写代码和日常私人助理（查日程、定外卖、改文件）。因为代码改得对不对，有编译器、单元测试和 Git Diff 当绝对的裁判。跑腿任务是否完成，有接口返回值当裁判。这种场景追求的是极速收敛，压根不需要小弟们坐在一起谈人生。

---

二、 黑板模式（Blackboard Architecture）：面向多角色的公告栏

但如果你的任务不是修一个 Bug，而是把一家公司的日常业务搬到线上呢？主从模式就会显得捉襟见肘，这时候就轮到第二种模型登场了。

三年前 MetaGPT 刚出来的时候，之所以让很多人眼前一亮，就是因为它把现实中软件公司的标准作业程序（SOP）搬到了代码世界。

在真正的公司里，跨部门合作从来都不是点对点单线汇报的，而是依赖于一块公共的大黑板（共享消息池）：

• 产品经理写完了需求，他不会单发给某一个人，而是把一份PRD贴在黑板上；
• 架构师每天在看黑板，发现上面多了份新 PRD，确认是自己的事，撕下任务，出了一份架构设计图，重新贴回黑板；
• 程序员和测试工程师同样盯住黑板，看到设计图合格了，才各自领走自己的任务。

这在经典软件工程里叫黑板模式（Blackboard），本质是基于发布-订阅（Pub/Sub）机制的事件驱动系统。

系统里存在一个中心化的共享消息池，每个 Agent 都有自己的职责过滤规则。发消息的人只管把带有标签的事件往池子里抛，而收消息的人只监听跟自己相关的状态变化。

这带来了极高的解耦性，架构师花几个小时做设计时，程序员完全可以去干别的事，异步等待黑板更新即可。

更关键的是，它提供了无可替代的全局可观测性——所有的流转记录、产出物全在池子里，管理员或者监控系统只要站在黑板前，一眼就能看清整个复杂业务当前到底卡在哪个节点上。

这种黑板模式最适合的，是那些长链路、多角色参与、且缺乏单一客观裁判的开放式日常协同。比如跨部门的行业竞品监控、公关应急方案推进，或者像 Grok Bot 探索的虚拟团队。

这类任务没有编译器能一行代码判定对错，必须依赖不同视角的角色顺着SOP梯次推进。

---

三、 两套模式的现实暗坑与工程解法

在纸面上看，这两种模式都很优美，但在真实开发中，如果你没踩过坑，系统一上线就会被教做人：

主从派发模式最致命的死穴，在于总管的上下文雪崩。

当你派出去五个跑腿小弟，每个小弟都极其尽职地抓回了几千字的详细执行日志。

等汇总到总管那里时，总管瞬间要面对一两万字的庞大原始数据。主控的上下文窗口瞬间被打爆，紧随其后的就是逻辑混乱、关键指令遗忘和严重的幻觉。

黑板模式则更容易掉进“惊群效应”与“责任真空”的泥潭。

如果黑板上掉下来一条意图稍微模糊的任务，池子里监听的几个 Agent 可能会同时被唤醒，各自消耗几千个 Token 跑了一通推理，最后却得出“这事好像不归我管”的荒谬结论，白白造成巨大的计算浪费。

更糟糕的是，如果任务没有明确分工，各个 Agent 很容易在消息池里互相客套，甚至大家都以为别人会去接单，导致关键任务永久挂起。

---

四、 终局蓝图：“宏观黑板、微观树”的混合体

分析完这两种模式，你会发现单纯依赖其中任何一种，都没法支撑真正复杂的未来世界。

全都做成主从树？层级一旦深了，总管管不过来，跨业务通信的代价大到无法承受

全都挂在黑板上？Agent 数量超过几十个，池子里信息熵爆炸，整个系统陷入无休止的噪声干扰。

未来的多智能体终极形态，一定会演化成现代企业的微服务架构——“宏观黑板，微观树”。

在宏观层面，整套系统必须由一条干净的企业级共享事件总线来支撑，用来打通跨领域的业务孤岛。

但在这条总线上，流通的绝不能是琐碎的对话碎片，而只能是粗粒度的核心里程碑事件，比如“市场调研已完成”、“方案已通过合规审批”。

宏观黑板负责全局的进度推进、状态持久化、合规审计以及Human-in-the-loop的介入。

而在微观层面，接入这条总线的每一个具体业务部门，内部其实都是一棵紧凑严密的 Sub-agent 树。

比如挂在总线上的市场分析节点，它的负责人会带着自己的跑腿小弟在独立的沙箱里把搜集数据、清洗文档这些琐碎的脏活彻底消化掉。

他们内部快速流转、严格收敛，绝不把半成品的草稿和运行报错倒进宏观的公共池子里。最终交付时，只把最干净、经过验证的确定性成果推上总线。

---

写在最后

很多人聊到 AI 代替人类工作，总觉得只要大模型参数再翻两倍、上下文再长十倍就行了。

但回到真实的系统工程里，单体模型的提升解决的只是单点智商。而真正能让几十上百个 AI 有条不紊地替人类处理日常事务的，一定是这套在数字空间里重新发明组织学、把混乱的信息熵收敛起来的通信与协同协议。

理清了主从派发和黑板模式的边界，你的多智能体系统，才算真正迈出了走出玩具 Demo 的第一步。

我是Erwin，PolyU在读PhD，前Alibaba & Shopee开发，专注AI Agent行业。我会分享硬核的前沿AI知识和开发干货。如果你也是AI Builder，欢迎关注我。

AI 看完了一百篇论文，就等于你也看了？

上一篇谈了 AI 与文献综述。

这一篇继续讨论第二个环节：论文阅读。

先说明我的立场：

我赞成并积极使用 Human-in-the-loop 的科研方式，但反对在计算机科学以外的领域盲目使用 Auto Research。

AI 可以替我们完成越来越多科研工作，但这不代表研究者只需要等待它输出答案。

尤其是在论文阅读中，AI 带来的不仅是效率提升，也可能改变我们理解知识的方式。

---

1. AI最适合做什么？

用 AI 速读论文、提取关键信息，可能是目前最常见的科研使用场景。

过去判断一篇论文是否值得阅读，通常要依次查看：

Abstract → Figures → Introduction → Conclusion

现在，可以先让 AI 快速回答：

• 这篇文章研究了什么？
• 它解决了什么问题？
• 使用了什么方法？
• 得到了什么结果？
• 与我的课题是否相关？

对于大量初筛工作，AI 确实非常高效。

它还可以帮助解释陌生概念、整理公式推导、概括实验流程，让我们更快建立对论文的初步认识。

但需要注意：

AI适合帮助你快速理解论文，不适合直接替你定义论文。

---

2. 论文阅读与文献综述并不相同

文献综述的重点，是整合多篇研究，从多个维度梳理一个领域，并为自己的课题寻找位置。

论文阅读则不同。

阅读一篇论文，是为了理解一条完整的研究思路：

• 为什么要做这个问题？
• 作者如何定义 gap？
• 采用了什么方法？
• 证据如何支持结论？
• 哪些部分是事实，哪些部分是推断？

因此，论文阅读不仅是在提取信息，更是在还原作者的论证过程。

而这恰恰是 AI 容易出错的地方。

---

3. 风险一：概念正确，不代表证据可靠

AI 很擅长输出概念层面的总结。

但当信息粒度变小时，它的可靠性会明显下降。

例如，你进一步追问：

某个观点具体出现在哪一段？ 这句话是作者提出的，还是引用别人的？ 这个结论由哪组数据支持？ 论证中哪些是已验证事实，哪些只是研究假设？

AI 就可能指错位置、混淆信息来源，甚至生成原文中不存在的表述。

对于工程类论文，这种错误有时只是让人找错一个参数或段落。

但在社科、设计、人文等高度依赖论证和语境的研究中，后果可能更严重。

AI 可能把作者引用的观点当成作者自己的立场，把推测描述成事实，或者把文章中分散的内容拼接成一个作者从未明确表达过的结论。

所以，严肃阅读时必须检查 AI 给出的证据链：

观点能否定位到原文？ 信息来源是否清楚？ 结论是否有直接证据支持？ AI的概括是否超出了作者原本的表达？

观点必须可追溯，证据必须可验证。

---

4. 风险二：总结得很完整，但重点可能错了

阅读论文不是把所有内容平均压缩一遍。

真正有效的阅读，应该围绕自己的研究问题，判断什么值得深入、什么可以略读。

但现在许多所谓的“论文阅读 Skill”，实际上都预设了一套固定的提问框架。

而且绝大多数框架是为计算机科学设计的，重点通常是：

任务、数据集、模型、基线、指标和性能提升。

这套逻辑放到其他学科中，可能完全不适用。

例如，设计研究可能更关注研究语境、问题建构、参与者、方法选择和分析框架；社科研究可能更关注理论立场、概念定义、证据链和解释边界；材料研究则可能更关注工艺参数、结构表征、性能机制和实验条件。

如果直接使用通用模板，AI 即使总结得很完整，也可能没有提取真正有价值的信息。

因此，我建议在使用任何论文阅读 Skill 前，先根据自己的研究方向改造它：

你的研究通常如何提出问题？ 一篇论文最值得提取哪些信息？ 你需要比较的是方法、理论、实验条件，还是论证方式？ 什么信息能够真正衔接到你的课题？

开箱即用，往往只能得到一份格式标准但价值有限的摘要。

---

5. AI可能替你读完论文，却无法替你建立知识体系

还有一件经常被忽略的事情：

人在认真阅读论文时，不只是在接收信息，也在加工信息。

新知识会与已有知识发生联系。你会发现两篇文章之间的相似点、冲突和因果关系，也会逐渐形成对一个领域的整体理解。

这个过程不是简单地把知识存进一个外部数据库。

它是在训练你如何：

获取信息、判断信息、组织信息、建立联系、形成观点，以及表达观点。

这些能力共同构成了一个人的科研素养和 research taste。

尤其是阅读优秀论文时，我们学习的不只是它得出了什么结论，还包括：

它如何提出问题， 如何安排证据， 如何控制叙述重点， 如何把次要内容逐步引入， 以及如何让整篇论文形成一条完整的逻辑链。

AI 可以告诉你一篇论文“讲了什么”，但只有亲自阅读和思考，才能逐渐理解一篇好论文“为什么这样讲”。

---

6. 人的价值在哪里？

在 AI 辅助论文阅读中，人的价值至少包括三点：

第一，核查证据。 确认观点来自哪里，证据是否完整，结论有没有被过度解释。

第二，定义重点。 根据自己的学科和研究问题，决定论文中什么值得关注。

第三，建立联系。 把新知识放入已有知识体系中，逐渐形成自己的理解、判断和 research taste。

AI 可以减少机械阅读的时间，但不应替代深度阅读本身。

不要把所有论文都丢给 AI，再把它生成的摘要存进某个所谓的“LLM Wiki”，就以为知识已经属于自己。

被AI处理过的信息，不等于被你理解的知识。

AI 可以帮助我们读得更快。

但研究者真正的价值，仍然在于判断一条证据是否可信、一个观点是否重要，以及一篇论文最终如何进入自己的知识体系。

1. AI 写得越快，方向错了越危险

普通人Vibe Coding 最大的阻碍可能不是技术水平，而是——

你自己可能都没想清楚，到底要做什么。

你脑子里有一个模糊的 idea，感觉很酷，打开 Cursor / Claude / Grok 就开始狂写。

结果写到一半发现：功能边界模糊、用户场景冲突、取舍完全没想好……

AI 不会因为你的需求含糊就主动停下来。

相反，它可能把错误的方向执行得又快又好。

最后代码写了不少，项目却越来越难改，甚至直接烂尾。

---

2. 项目开始前，先让 AI“拷打”你一次

最近很推荐大家在项目启动阶段试试 Matt Pocock 的 "grill-me"。

它不会急着替你写代码，而是不断追问：

• 这个功能真正解决什么问题？
• 哪些人会使用它？
• 正常路径之外，还有哪些边界情况？
• 什么应该做，什么坚决不做？
• 几个目标冲突时，究竟优先保哪一个？

听上去有点像被 AI“拷打”，但这个过程恰恰补上了 Vibe Coding 最容易缺失的一环：需求挖掘。

---

3. 真正重要的需求，往往是你还没说出来的部分

一个产品的需求，大致可以分成三层：

1. 第一层是显性需求：你知道自己想要什么，也能直接表达。
2. 第二层是未充分表达的需求：你隐约有想法，但还没有形成清晰的规则和方案。
3. 第三层是潜在需求：你甚至没有意识到，只有进入具体场景、遇到冲突和边界情况时才会暴露。

大多数项目都从一个现实中的 gap 开始。

“现有工具哪里不好用？”

“我想做一个更适合自己的版本。”

这类显性需求通常不难说出来。

真正决定产品质量的，往往是后两层：

没有想清楚的边界、没有意识到的用户路径，以及不同需求发生冲突时的取舍。

---

4. Agent 的价值，不是替你决定，而是逼你做决定

这也是 "grill-me" 真正有价值的地方。

它有点像装修时的设计师。设计师不会只问你喜欢什么风格，还会继续追问生活习惯、预算、动线和未来变化，再帮你判断哪些想法能实现、哪些想法彼此矛盾。

Agent 也可以扮演类似的“产品设计顾问”。

但它的价值并不是替你做决定，而是提高你做决定的密度，迫使你把两个问题想清楚：

行动层面：这个产品应该做什么，又不应该做什么？

设计层面：它究竟解决什么问题，背后的设计原则是什么？

当这些问题逐渐被回答，原本散落的灵感才会被串成系统。你得到的不只是一张功能清单，而是一套可以持续指导取舍的底层逻辑。

---

5. 第一版工程上下文，决定了 AI 会往哪里跑

这对 AI 编程尤其重要。

因为 AI 的执行能力越强，前期方向错误的代价反而越大。一个含糊的初始需求，也许不会让 AI 停下来，但很可能让它高效率地跑向错误方向。

所以，项目的第一版工程上下文非常关键。

它至少应该包括：

• 项目目标
• 功能边界
• 核心术语
• 已确定的设计决策
• 关键取舍
• 验收标准

前期把这些问题说清楚，后面的代码生成、测试和迭代才会更加稳定。

先把问题定义清楚，再让 AI 发挥执行能力。

否则，Agent 越强，返工速度可能越快。

---

6. 从模糊想法到实际开发，我使用这套流程

我的实践流程是：

grill-me → to-spec → to-tickets → implement / TDD

第一步，使用 grill-me。

从一个模糊的想法开始，通过持续追问，挖掘目标、场景、边界和需求冲突。

第二步，使用 to-spec。

把讨论结果整理成一份相对正式的规格文档，明确做什么、不做什么，以及如何判断完成。

第三步，使用 to-tickets。

把规格拆成可以独立实现、独立验证的任务，避免 Agent 一次处理过大的范围。

第四步，进入实现和 TDD。

通过“测试失败—完成实现—重构优化”的反馈循环，让需求、代码和验证标准保持一致。

如果项目已经存在 Codebase，还可以进一步使用 grill-with-docs。

它不仅会追问新需求，还会结合已有项目文档，帮助建立统一术语，并记录关键设计决策，减少后续对话中的概念漂移。

---

7. 并不是所有项目都需要完整流程

当然，"grill-me" 也不是任何项目都必须走的仪式。

如果只是做一个随时可以丢弃的低成本原型，过度追问反而可能拖慢验证速度。

AI 提出的边界情况，也不一定真实存在。

有些问题只是逻辑上可能发生，但实际用户根本不会遇到。最终仍然需要用户反馈、真实数据和领域证据来判断。

因此，是否需要完整需求挖掘，取决于项目的维护成本和风险。

如果只是短期 Demo，可以先快速验证。

但只要项目准备长期维护，或者你计划把大量实现工作交给 Agent，那么启动阶段先被“拷打”一次，通常比直接开写更划算。

说到底，Vibe Coding 真正稀缺的，已经不只是写代码的能力，

而是：

定义问题、做出取舍和设计反馈机制的能力。

你觉得现在 AI 项目更容易失败在“写不好”，还是“根本没想清楚要写什么”？

Matt 的 Skills 仓库：

https://github.com/mattpocock/skills

现在，几乎所有科研工作者都在不同程度上使用 AI。

用 AI 搜索文献、阅读论文、整理综述、修改表达、处理数据，已经逐渐成为日常操作。更进一步，Auto Research、AI Scientist 等自动化研究系统也开始尝试完成从提出问题、设计实验到撰写论文的完整流程。

于是，一个问题变得越来越现实：

当 AI 可以承担越来越多科研工作时，研究者的价值究竟在哪里？

先说明我的观点：

我赞成并积极使用 Human-in-the-loop 的科研方式，但反对在计算机科学以外的领域盲目使用 Auto Research。

接下来，我会用一个系列讨论 AI 辅助科研，将整个过程分成四个环节：

1. 文献综述
2. 论文阅读与选题
3. 论文写作
4. 数据处理

这一篇先讨论第一个环节：文献综述。

---

1. AI确实非常适合做文献综述

在文献综述中，AI 的信息处理能力具有明显优势。

它可以帮助我们：

1. 搜索和筛选文献；
2. 下载并整理论文；
3. 提取研究问题、方法与结论；
4. 横向比较不同研究；
5. 纵向梳理领域的发展脉络；
6. 总结已有研究中的争议与空白。

这些能力非常适合快速了解一个领域，也能显著提高论文综述部分的写作效率。

对于理论门槛不高、边界相对明确的主题，AI 甚至可以生成一篇结构完整、表面上逻辑通顺的综述。

但问题也恰恰出现在这里：

文献综述看起来像是信息整理，实际上却是一项判断工作。

---

2. 文献综述有两种完全不同的目的

第一种情况是：你已经完成了研究，现在需要为它寻找理论依据和研究空白。

说得直接一点，就是“先开枪，再画靶”。

在这种情况下，AI 很好用。你可以告诉它自己的研究内容，让它寻找相关文献、组织论证，并将已有研究中的不足逐步引向你的研究方向。

如果使用者缺少警惕，整个过程甚至可以非常轻松：

你只需要看着 AI 不断为你的研究辩护，最后再被它说服——自己做的事情确实很有意义。

问题在于，这样得到的 gap 很可能只是一个被论证出来的 gap，而不是真正值得研究的问题。

从0到1寻找gap，更依赖人的判断

第二种情况是：你还没有明确选题，希望先通过文献综述寻找研究空白，再决定具体研究方向。

一个相对可靠的过程通常是：

先对大量文章进行比较和总结，形成几个初步的 gap；再带着这些概念回到文献中反复验证；最后判断哪个问题真正重要、可行，并且值得投入时间。

在这个过程中，AI 可以承担大量机械性的工作：

整理信息、建立表格、归纳观点、寻找相似研究、追踪引用关系，以及反复检查某个判断是否有文献支持。

但它很难替代最关键的一步：

判断哪个 gap 值得做。

这通常被称为研究者的 taste。

---

3. AI容易陷入两种局限

第一种是信息自我强化。

AI 很容易延续最初的假设。只要开头形成了某个判断，后续的文献搜索、归纳和分析就可能不断向这个判断靠拢。

如果你先告诉它“这个方向可能存在 gap”，它往往会优先寻找支持这一判断的证据，并把后续分析不断往这个方向收拢。最后形成的，可能不是对假设的验证，而是一套越来越完整的自我证明。

所以不能只让 AI 寻找支持材料，还要主动要求它找反例、替代解释，以及可能推翻当前判断的证据。

第二种是在局部细节上钻牛角尖。

AI 很擅长发现文献中的差异、缺失和未覆盖之处。AI 提出的某个问题可能客观上没有错，甚至确实没有被充分研究，但“没有被研究”并不等于“值得研究”。

有些 gap 客观存在，却只是文献中的细小缺口，范围过窄、意义有限，或者只是因为没有必要研究。把它单独拿出来看似乎成立，但放回整个领域中，就会显得缺乏分量。

AI 擅长发现差异，却未必擅长判断差异的重要性。

因此，人不仅要判断 AI 说得对不对，还要判断这件事值不值得做。好的 research taste，就是忽略正确但不重要的信息，抓住真正关键的问题。

---

4. 人的价值是判断与指引

因此，在 AI 辅助文献综述的过程中，人最重要的作用不是比 AI 读更多论文，而是提供判断标准。

这种判断必须建立在一定的先验知识上。

先验知识可以来自：

• 领域内公认的权威综述；
• 导师和资深研究者的判断；
• 经典理论与研究框架；
• 自己长期阅读论文后形成的理解。

研究者需要用这些知识判断 AI 提出的观点：

• 这个问题是否真的重要？
• 它是一个研究空白，还是一个没有研究价值的细节？
• 这个方向应该继续深入，还是及时停止？
• 现有证据是在验证判断，还是在迎合判断？

Human-in-the-loop 的核心并不是“人在流程中点击确认”。

而是：

人负责确定方向、判断重要性，并在必要时纠正 AI。

好的 research taste，也不是比 AI 掌握更多信息。

它意味着能够面对 AI 提供的大量材料，忽略那些正确但不重要的内容，识别真正关键的问题，并知道什么值得继续追问。

AI 可以帮助我们更快地看到更多信息。

但科研的价值，仍然取决于人决定看什么、相信什么，以及最终选择做什么。