企业官网建设流程全解析

Hacker News 上每隔一段时间就会出现一个类似的问题：“你是怎么在 research 里使用 LLM 的？”问法不同，困惑却一致：明明每天都在和 ChatGPT、Claude、Gemini 这类工具对话，可真到正经研究场景里，总觉得它们给的东西不够扎实。要么答得太泛，要么引用的文献根本不存在，要么看起来逻辑通顺，却跟自己的方向完全对不上。我自己的体感是，问题不全在模型能力，而在于大多数人把 LLM 用错了场景。我用了一年多才真正意识到：LLM 用于研究，不是搜索引擎的升级，而是把阅读、总结、追问、试错和验证这整条低效流程，改造成一条可以持续交互的流水线。真正决定成败的不是哪个模型更强，而是你怎么组织问题、怎么供给资料、怎么验证输出。

我把这个思路展开成下面几个部分，每个部分都来自实际踩坑后的操作经验。如果现在想开始把 LLM 纳入研究工作流，可以直接照着后面的路径先跑一个最小版本。

1. 研究里真正值得交给 LLM 的，不是“找答案”而是“拆问题”

很多研究者第一次用 LLM 的方式，是把它当搜索引擎：输入一个主题，等它给出一段“综述”。结果往往很失望，因为 LLM 生成的综述非常平滑，却缺少真正的文献基础，引用也经常编造。于是这些人很快得出结论：LLM 不靠谱，不适合做研究。

我理解这种挫败，但这个结论下得太早。它真正不能被替代的地方，不是替你给最终判断，而是帮你把一个大而模糊的问题拆成许多可处理的小问题。

1.1 表层功能：确实能帮你找资料、梳理概念

直接把论文 PDF、书籍章节、GitHub README 丢给对话模型，它能快速生成摘要；让它在几篇方法之间做对比，它也能给出大致差异；让一段陌生代码解释每一步在做什么，它通常讲得比文档还细。这些都是表层功能，它们解决的是“省时间”的问题：过去可能要一个下午才能读完的十篇摘要，现在一小时就能完成初筛。

但省时间不是核心价值。核心价值是，它在这些低层操作上几乎不消耗意志力，这让你可以把人类特有的精力，留给更关键的判断和决策。

1.2 研究流程里真正被改变的三个环节

回顾我自己的研究流程，LLM 真正改变的不是“找资料”那个环节，而是三个过去容易被忽略的地方：

• 文献阅读的“第一遍扫描”。过去拿到一批论文，需要从摘要、图表、结论里快速判断哪些值得精读。现在我会让 LLM 先按“问题—方法—实验—不足—可复现性”五个维度做摘要，然后在摘要基础上决定要不要深读原文。这一步能过滤掉大量不值得投入时间的论文。
• 概念之间的连接解释。研究中最容易卡住的不是单个术语，而是术语之间的关系。比如“RAG 和 Agent 到底能不能同时用？它们之间是怎么传递数据的？”这类问题，LLM 可以快速给出多种角度的解释，虽然不一定完全准确，但足够帮你建立初步认知地图。
• 实验思路的快速试错。写代码之前，先让 LLM 给出一个伪代码流程、可能的参数范围、数据格式和边界条件。它不是替代实验设计，而是在正式动手之前，帮你把“没有想到的边界”尽可能暴露出来。

所以我倾向于把 LLM 在研究中的角色定义为：一个低成本的思考陪练。它的输出不是结论，而是供你反复推敲和反驳的草案。真正的结论必须由你的专业判断、实验数据和一手文献来确认。这个定位是所有后续方法设计的前提。

2. 从灵光一现到可持续：一套四步研究用法

如果你只把 LLM 当作临时聊天工具，那每次的结果都不可控。想让它稳定地进入研究流程，我建议把它当成一套四步流程来用：拆问题、喂资料、问追问、做验证。四步缺一不可。

2.1 第一步：把研究问题拆成可追问的原子问题

不要直接问“帮我写一篇关于知识蒸馏的综述”，这个任务太大，输出必然泛泛。更合理的做法是把“知识蒸馏”拆成一批原子问题：

• 知识蒸馏的关键损失函数有哪些形式？
• soft label 和 hard label 在蒸馏里分别起到什么作用？
• 温度参数对输出分布的影响，直觉上应该怎么理解？
• 哪些论文给出了不同蒸馏方法之间的系统对比？
• 蒸馏后模型的容量上限有没有实验证据？

每个原子问题都可以单独追问，得到比较具体的回答，再把这些回答组合成你对这个方向的理解。当问题足够具体时，模型的表现会稳定很多，因为它的训练数据里覆盖了大量类似 Q&A 模式。

2.2 第二步：资料先行，让 LLM 在明确上下文里工作

研究用的对话不能是白手起家。你应该尽可能地把你的笔记、论文片段、数据字典、实验结果、代码文件等作为上下文喂给模型。这就是 RAG 和本地知识库真正介入的地方。

我自己的做法是，把长期研究资料整理到 Obsidian 这样的本地笔记库里，每篇笔记有明确的标题、标签和链接关系。然后再把笔记库导出成可供 LLM 检索的目录形式。Andrej Karpathy 提过的 LLM Wiki 范式，本质上也类似：不是把所有原文都塞进上下文，而是让 LLM 基于一个高密度的、有结构的目录或 Wiki 页面进行回答。它更像“先给目录，再按需展开章节”，而不是“一次把所有章节都背下来”。

这种做法的好处有两个：

1. 模型不会因为上下文过长而丢失重点；
2. 回答能引用你提供的资料，而不是凭概率生成一个可能的答案。

在具体配置上，如果使用 RAG，需要先给文本做切片（chunking）。切得太短，模型看不到完整段落语义；切得太长，检索精度下降，还容易超出上下文窗口。常见做法是每个切片 300 到 800 个 token，保留段落边界和标题信息，再对有层级结构的内容做父文档召回。

2.3 第三步：连续追问和反向追问

研究不是一次性问答。真正有价值的洞察通常藏在第二轮、第三轮，甚至第六轮追问里。

我会在每轮回答后问自己三个问题：

• 它给出的前提是什么？这个前提成立吗？
• 如果反过来做，结果会怎样？
• 它还遗漏了哪个关键变量？

然后把这些问题原样抛给 LLM。比如让它给出一段模型训练建议后，我会追问“如果数据只有 500 条，这个建议哪些不适用？”或者“如果训练目标不是准确率而是鲁棒性，哪些步骤要调整？”这些反向追问的作用，是让模型把隐含的适用条件显式化。很多时候，模型并不是在“正确”或“错误”之间摇摆，而是在“有边界条件的正确”和“无边界条件的正确”之间切换。

这一步也最能体现你是否真的理解自己的研究问题。如果你无法对模型输出提出高质量追问，那么模型给你的也只能是平均水平的答案。

2.4 第四步：输出必须经过人工验证

研究级的使用，绝对不能直接采信模型的输出。每一轮对话产生的结果，都要落到一个可复核的动作上：找到原文引用、跑一次最小实验、检查日志里的数值、看代码里对应实现的逻辑。

我习惯在对话结束后，把 LLM 给出的关键信息分成两类：

• 一类是“可以快速验证的”，比如一个 API 参数、一个文件路径、一段代码语法，直接通过文档或运行确认；
• 另一类是“需要长期验证的”，比如某种方法在该领域的适用性、对比实验的结论，必须通过一手文献和实验数据判断。

如果发现模型引用了一篇标题很具体的论文，先不要直接相信，先去 Semantic Scholar、Google Scholar 或 arXiv 搜一下，看看论文是否真实存在。研究场景中最消耗信任的，不是模型没有能力，而是它一本正经地给出一个根本不存在的引用。这一点永远不能跳过。

3. 不同研究场景的配置与常见坑

研究场景差异很大，有的是纯文本阅读，有的涉及代码复现，有的涉及本地数据和隐私保护。下面按场景拆开说，每个场景的配置侧重点都不太一样。

3.1 文献阅读与多篇比较：RAG 和上下文窗口怎么选

如果只是单篇论文，直接把 PDF 转成文本喂给上下文窗口就够了。LLM 通常能够抓住论文的主题、方法和结论，尤其当你有明确的问题时。

但如果你要做多篇论文的横向对比，不建议一次性把所有原文都塞进去。更好的做法是：先让模型分别为每篇生成结构化摘要，然后把摘要汇总成一个对比矩阵。矩阵通常包括：研究问题、方法类型、数据集、主要结果、局限、和本研究的关联。这时候再用一次追问，让模型补齐不同论文之间的冲突点，比如“为什么在同样数据集上结果差异很大？可能是哪些变量不同？”

如果论文数量超过二十篇，我会建议用本地 RAG 方案，而不是对话式的手动贴入。原因是，对话上下文窗口再大也有上限，而检索可以高效定位最相关的几篇论文片段。实际使用中要注意，检索回来的片段本身可能不完整，所以回答时最好要求模型标明依据来自哪个文件、哪个章节，方便你复查。

3.2 代码理解与复现实验：LLM 是解释器，不是调试器

研究过程中，代码理解是最常见的高频场景。你可以把一个新仓库的目录结构和关键文件发给 LLM，让它解释模块职责、数据流动、运行入口。这一步能把陌生项目的上手时间从几天压缩到几小时。

但必须记住一个边界：LLM 理解代码的方式是统计性的，不是执行性的。它能告诉你某段代码的意图，却没法替你验证某个操作在特定版本里是否有效。所以涉及调试时，最好的做法是让 LLM 给你一个排查步骤和候选原因，而不是直接相信它的“修复方案”。

我自己的经验是，把报错信息原样贴给 LLM 通常有效，但前提是你要提供环境信息：Python 版本、PyTorch 或 CUDA 版本、操作系统、完整 traceback。缺少这些信息，模型只能泛泛而谈。反过来，如果它给出的修复涉及安装新依赖，不要直接照做，先看依赖版本冲突。

3.3 本地部署与隐私场景：从量化选型到推理引擎配置

有些研究数据不能上传到云端 API，比如医疗数据、未公开的企业内部数据或实验室数据。这种场景下，本地部署一个开源模型就成了刚需。常见的选择包括各类开源模型配合 LLM Studio 这样的图形化工具，或者 Ollama、llama.cpp 这类命令行方案。

如果你的主力设备是 Mac，要重点关注推理引擎对 MPS 和 Metal 的支持。很多人在 Mac 上跑模型遇到速度慢或内存爆掉，往往不是模型问题，而是推理引擎没有针对 Apple Silicon 做优化。常见的做法是选择支持 Metal 的推理后端，并合理设置内存映射。与此同时，也可以考虑通过 Maid LLM 这类安卓端工具，把私有模型的入口放到移动端，方便在通勤或访谈时快速检索和记录。

本地部署还有一个容易被忽视的问题：ComfyUI 这类工具在配置 LLM 相关节点时，需要修改extra_model_paths.yaml来指定外部模型路径。新手经常在这个环节踩坑，原因是路径写错后没有及时看日志，程序不报错却一直找不到模型。配置完成后，第一步应该是查看启动日志里是否加载出了目标模型名。

3.4 精度参数怎么选：fp16 / fp32 / bf16 的实践理解

本地部署模型时，经常看到 fp16、fp32、bf16 这几个精度选项。很多人以为是越高越好，实际上是取舍问题。

• fp32：精度最高，但显存占用和计算开销也最大，通常只在小模型或 CPU 调试场景里使用。
• fp16：训练和推理的常用精度，速度比 fp32 快很多，显存占用减半，但数值范围有限。极小的学习率或极端梯度更新时，可能出现溢出问题。
• bf16：动态范围和 fp32 一样大，但尾数精度低。对大多数深度学习任务来说，尾数精度损失影响不大，而且能在大规模训练和推理里获得更好的稳定性。

在“研究怎么做实验”这个层面，我建议把精度问题放在最后考虑。如果你只是跑通一个推理流程，先用默认设置即可。要长期稳定运行，再去观察模型的输出是否因为精度切换产生明显变化。这里很容易陷入“调参自嗨”，实际上对研究结论影响更大的，往往是数据质量和评估方式。

4. AI 输出为什么总是“像模像样却不能用”

这是研究者对 LLM 最核心的不满。模型生成的文字一段比一段漂亮，逻辑似乎无懈可击，可拿到具体场景里根本站不住脚。要理解这个问题，需要拆开 LLM 输出“能用”与“不能用”的间隙。

4.1 幻觉不是 bug，是当前模型交互方式的固有风险

很多研究者把幻觉归咎于“模型不诚实”。从技术角度看，这更像是一个不可避免的副产品：LLM 的目标是预测下一个 token，而不是确保每个句子都符合外部事实。它生成的内容像一份“从数据分布中采样得来的高质量文本”，所以在概念关系熟悉时，它往往说得像真事；在概念关系稀疏时，它就会靠语言模型对“合理的下一步”的理解填补空缺。

这不意味着我们不能用。它意味着我们必须把“模型输出”当作一个待验证的假设，而不是事实。研究工作中的任何决策，都不能只以 LLM 输出为依据。

4.2 交叉验证：搜索、原文、日志、实验四位一体

我在反复踩坑之后，总结出一个适用于研究场景的验证策略，简称“四位一体”：

1. 搜索验证：把模型引用的关键论文标题、作者、年份拿到搜索引擎或论文数据库里查一遍，确认存在性。
2. 原文验证：找到论文原文，直接看摘要、图表和结论，确认模型转述是否准确。
3. 日志验证：如果涉及代码或配置，通过运行日志和报错信息来确认行为是否符合预期。
4. 实验验证：如果可能，跑一个最小实验，用数值结果判断方向是否值得继续投入。

这四个验证动作不需要每次全部执行。但至少前两个应该成为默认动作，尤其是当模型给出一个“看起来非常有用”的结论时，不要被表面说服。

4.3 一套研究级验证清单

为了让验证动作更标准化，我把它做成了一个清单，每次重要对话后过一遍：

• [ ] 模型输出的关键引用是否真实存在？
• [ ] 模型的核心假设是否符合我所在子领域的默认条件？
• [ ] 模型提到的实验设置，是否有能支撑它的原始数据或来源？
• [ ] 如果我把这个结论放进论文/实验报告，评审会质疑哪里？
• [ ] 这个结论能不能被一个具体的、可重复的实验证明？
• [ ] 哪些段落是模型直接从分布中“平滑生成”，而不是基于证据的？

这个清单看起来简单，但一旦养成习惯，能让模型的可用性提升非常大。研究者的价值，恰恰体现在这些验证和判断动作上。

5. 当单个对话不够用：RAG、MCP、Agent 与编排框架

用过一段时间后，你会发现单靠一个对话框做研究会遇到瓶颈：上下文窗口有限、模型记不住项目背景、不能实时查找资料，也不能主动执行多步骤任务。于是出现了更复杂的组合方案：RAG、MCP、Agent，以及把它们串起来的各种编排框架。很多人被这些概念绕晕，我这里用一个更朴素的方式拆开。

5.1 为什么需要编排框架

单个 LLM 对话就像只有一个聪明但健忘的临时助手。你每次重建对话，它都忘了上年发生了什么。编排框架的本质，是给这个临时助手配上持久记忆、工具、任务清单和工作日志，让它能够在一个项目里连续工作。

“LLM 应用为什么需要编排框架”这个问题的答案就在这里：不是框架本身有魔力，而是研究工作需要状态持久化。你不可能每次研究对话都从头解释项目背景、方法和已有结论，你需要一个可以长期维护的项目上下文。

5.2 RAG 和 MCP 分别解决不同的问题

RAG 解决的是“信息供给”。当模型需要回答一个问题时，先从本地或外部知识库检索出最相关的片段，再把这些片段拼进提示词。它解决的是模型不知道或不记得的“领域资料”问题。注意，RAG 本身不会把知识注入模型参数，它只是把证据放到模型眼前，帮助输出更贴近相关内容。

MCP 则更像“工具插口”。它让 LLM 能够调用外部工具，比如读取文件、执行代码、查数据库、访问网络接口。过去每个工具都要单独对接，MCP 把工具访问方式统一了。你可以把 MCP 理解为给 LLM 配了一套“通用工具箱”，而 RAG 是工具箱中的一个资料抽屉。

实际使用时，两者经常配合：先由 RAG 查出相关章节，再由 MCP 调用解析器打开文档、执行检索脚本或写入日志。

5.3 Agent 编排：多步任务的串联

Agent 是让 LLM 不止于“回答”，而是能够自主规划并执行多步任务。例如，让它完成“从十篇论文里找出使用对比学习的方法，提取它们的损失函数，并把结果写入 Markdown 表格”这样的任务，就需要它拆解步骤、决定每步用什么工具、检查结果，然后进入下一步。

研究场景里，Agent 的最大价值是处理重复性的检索和提取任务，而不是做学术判断。不要指望 Agent 能独立完成“下一步应该研究什么问题”这种需要专业直觉的任务。我的建议是：Agent 适合执行，不适合决策。

5.4 Spring AI + MCP + RAG + Agent + SKI 这类组合如何理解

现在能看到很多类似“Spring AI + MCP + RAG + Agent + SKI”的技术组合词。它本质上是一套把上述能力集成到 Java 生态的解决方案。Spring AI 提供统一的接口，MCP 负责连接工具，RAG 提供资料检索，Agent 负责多步任务编排，SKI（可能指某个项目中的技能集或自学习模块）作为辅助增强。

如果你已经在一套成熟后端里做研究应用集成，这种组合确实有吸引力：它能让研究助理的能力通过标准接口对外提供服务。但如果你只是个人研究使用，不一定需要一上来就搭这么重的框架。先用简单的脚本或 notebook 组合 RAG 和 API，跑通流程，比追求“全家桶”更重要。

编排框架的适用边界非常清楚：个人轻量探索，经典对话+RAG 就够了；团队协作、系统集成、需要权限和日志审计时，才值得上 Agent 编排框架。千万不要因为概念热门，就把简单问题复杂化。

6. 从今天就能开始的最小可行方案与问题排查

最后给一个不依赖复杂基础设施，今天就能开始用的最小可行方案。它不一定最强大，但足够让你在真实研究中体会 LLM 协作的收益和风险。

6.1 最小研究助理：三件套

我的“最小研究助理”由三部分组成：

1. 对话入口：可以使用你最顺手的对话工具，也可以使用本地部署的开源模型。关键在于保持一致的使用流程，而不是频繁切换模型。
2. 资料库：把常用论文、笔记和代码仓库整理成一个结构清晰的本地文件夹或 Obsidian 笔记库。良好的命名和互链，是后续让 RAG 发挥作用的前提。
3. 验证通道：至少保留一个论文搜索引擎、一个代码运行环境、一个日志输出位置。建议在每次重要对话后，强制使用其中至少一个通道做验证。

一开始不要做通用助手，而是做一个“只回答特定研究方向问题”的助手。比如：这个助手只允许回答关于知识蒸馏、模型压缩、或你所在课题的问题。范围越小，上下文越容易维护，输出质量越高。

6.2 最常出现的五个坑及排查顺序

根据我自己的经验，研究场景下最容易出现的问题集中在五个地方：

1. 上下文不完整：模型不知道你的实验条件，导致答非所问。排查方式：检查提示词里是否给出了关键背景，比如数据规模、模型架构、评估指标。
2. 输入文件格式不被支持：PDF 转文本时出现乱码或缺页，分块时把段落切断了。排查方式：先把文件转成纯文本，肉眼检查首尾和标题区域。
3. 本地模型路径或精度配置错误：例如 ComfyUI 的extra_model_paths.yaml写错，模型一直加载失败。排查方式：看启动日志，确认模型绝对路径和配置里的路径一致。
4. RAG 检索不到相关内容：不是模型不行，而是切片策略和检索阈值不匹配。排查方式：先手动搜索一个已知问题，看返回的文档片段是否包含关键内容；如果不包含，调整切片大小或重写文档标题。
5. 输出幻觉或引用错误：模型给出一个看起来很真实的结论，但实际不支持。排查方式：用上一节的四位一体验证流程，至少执行搜索和原文验证。

当问题出现时，不要直接怀疑“模型不行”。先看输入、再看环境、再看参数、最后看工具边界。和排查代码 bug 一样，研究工具链的失败点往往出现在数据供给和配置层面。

6.3 什么时候该及时抽身

最后一个建议，可能比所有技术都更重要：学会判断什么时候不应该继续用 LLM。

如果你发现自己在和模型反复绕圈子，几分钟内得不到实质进展，或者模型已经开始生成大量看似合理但无法验证的内容，这时候最有效的动作是停止对话，回到原始文献和实验数据里。

LLM 是研究过程中的杠杆，不是研究本身。它能帮你把大量低效环节压缩成快速迭代，但它不能替你做判断、不能替你理解研究背景、不能替你承担责任。一个合格的研究者，应该始终掌握两个核心能力：提出好问题的能力，和对答案进行审计的能力。工具越强，这两项能力越值钱。