最近我花了两周时间基于 Dify 搭了一个叫“hindsight”的 AI 复盘助手目的很简单让大模型帮我把“已经发生过的事”重新掰开揉碎总结出到底哪里做对了、哪里做错了、下一步该怎么改。这个念头来源于我自己的一个真实痛点——每周写周报的时候翻聊天记录、会议纪要、项目日志经常一翻就是一个多小时最后写出来的东西还是流水账根本看不出什么值得固化的经验。hindsight 想解决的就是这种“信息到处都是但洞察几乎没有”的状态。它把散落在会议纪要、工作日志、项目文档里的素材集中收进来再由 Dify 编排好的工作流去生成一份带着结论、带着动作的复盘结果。这篇文章适合正在用 Dify 搭 AI 应用的人也适合那些被周报、复盘、总结折磨的职场人。如果你完全没接触过 Dify也没关系我会从最基础的概念讲起最后让你能照着步骤自己动手搭一个出来。下面就直接进入正文。1. 项目背景与核心思路1.1 为什么我们需要一个 AI 复盘工具复盘这件事本质上是一个高频率、低门槛但高认知消耗的动作。高频率在于项目节点、周报、季度总结、年度述职都在逼你做低门槛在于素材就摆在那里会议记录、聊天记录、你写的阶段性文档不需要额外生产什么高认知消耗则体现在要从一堆流水账里提炼出“规律”和“结论”需要人真正动脑子去对比、归纳、抽象。问题就出在最后这一步大部分人的复盘之所以流于形式不是不愿意总结而是大脑在长时间处理琐碎信息后根本没有多余的认知带宽去做深度归纳。我自己试过好几种方法用模板照着填填几周就烦了用表格管理经验教训维护成本太高最后还是荒废。后来我意识到整理素材这种事完全可以交给机器而归纳总结这种需要“见过足够多案例”才能做好的事恰恰是大模型最擅长的地方。hindsight 的设计初衷就是把“记录”和“洞察”这两件事彻底分开。记录靠人因为只有你知道哪些事情值得记洞察靠 AI因为它能在几秒钟内把过去一个月的记录全部过一遍找出那些你根本没意识到的问题和机会。工具不替代人思考它把你从繁琐的整理工作中解放出来让你把精力放在判断 AI 给出的结论是否靠谱上。1.2 核心思路输入-分析-输出三段式架构整个 hindsight 的逻辑非常朴素就是一条“输入-分析-输出”的流水线。输入环节收集原始素材分析环节由大模型完成模式识别、问题定位、经验提炼输出环节把结论组织成结构化报告。这个三段式的架构是我在对比了不少现成的复盘工具之后确定的。市面上的复盘工具大多把自己定位成“笔记模板”给出一堆框架让你自己填AI 顶多帮你润色一下文字。而 hindsight 从一开始就明确AI 要做的不是润色是提炼。同样是给 AI 一段项目总结普通工具做的是把句子改得更通顺hindsight 做的是从这段文字里找出“真正影响结果的因素”。举一个具体的例子。我输入“Q3 版本上线时间延期了三天原因是测试环境不稳定期间产品经理临时加了一个需求”hindsight 的输出不会停留在复述这件事而是会给出三个层次的判断直接原因是环境稳定性不足管理原因是变更流程没有把关预防措施是上线前增设环境验收环节。这种多层归因的分析靠模板是做不到的必须依赖大模型对自然语言的理解能力。这也是我把项目命名为 hindsight 的原因——它给的不是预测而是后见之明。1.3 与普通聊天机器人的核心区别很多人在刚看到 hindsight 时都会问这不就是一个套了提示词的 ChatGPT 吗我当初也是这么想的但实际做完之后发现两者之间的差距比想象中大得多。普通聊天机器人的交互模式是“问一句、答一句”用户需要自己把问题描述清楚还要在对话中不断补充上下文。而 hindsight 做的是“给一堆素材、返回一整份报告”它背后有一套固定工作流在约束输出结构。比如做项目复盘时它必须包含背景回顾、结果对比、原因分析、经验教训、后续行动五个模块每个模块都有独立的提示词约束。这种结构化的产出直接决定了它能不能被落地使用零散对话生成的答案永远不可能替代一份完整的复盘报告。还有一点很关键聊天机器人没有记忆每次对话都是独立的。hindsight 借助 Dify 的知识库和数据集能力把历史复盘结果、公司项目文档、个人 OKR 记录都存成了可检索的向量AI 在分析时会主动调取这些背景资料。这相当于给 AI 装了一个“组织记忆”它知道你上一季度总结过什么这次的复盘就不会和过去打架。这个能力是纯聊天式交互很难做好的也是我坚定选择 Dify 而不是零散调用 API 的原因之一。2. 技术选型为什么把底座放在 Dify 上2.1 Dify 是什么它能做什么先给没接触过 Dify 的朋友一个简单的定义Dify 是一个开源的 LLM 应用开发平台核心价值是让开发者通过可视化方式编排大模型工作流而不需要自己从零搭建框架。你可以在里面配置模型、写提示词、上传知识库、设置变量、串联多个节点最终生成一个可以分享出去的 AI 应用。我在做 hindsight 之前其实先用过几种其他方案。最早我试着直接调大模型 API自己写代码来管理上下文和输出解析做了一版原型发现大部分时间都耗在工程问题上而不是业务逻辑上。后来我又试了 LangChain 那套编排框架灵活是灵活但对一个“只想快速把复盘流程跑起来”的场景来说学习成本确实高了一点。换到 Dify 之后最直观的感受是主要精力终于可以用在“设计复盘逻辑”上而不是“写胶水代码”。比如我要让 AI 先总结材料、再提取问题、最后生成行动建议其实就是在工作台里拖三个节点串起来。知识库接入也是一样上传文档、选择分段方式、配置检索权重界面操作就完成了。当然 Dify 并不是没有缺点后面第五节我会专门讲讲我在调试中踩到的一些坑。2.2 横向对比直连 API、LangChain 与 Dify 的取舍我在选型阶段整理过一个简单的对比今天直接放出来方便大家根据自己情况判断。这里的对比基准是“一个人或小团队想在两周内做出一个可落地的 AI 复盘工具”不是大公司做复杂业务系统的那种选型逻辑。对比维度直连大模型 APILangChain 编排Dify 平台上手门槛需要懂编程还要自己处理链路需要懂编程且要理解框架概念基本没有编程要求界面操作即可知识库能力需要自己开发向量检索和存储需整合向量库、切片、召回等组件内置知识库上传文档即可工作流可视化完全靠代码表达部分靠代码部分靠抽象概念可视化拖拽实时预览可控性最高任何环节都能改高但复杂逻辑学习成本大中等特殊需求可能受平台限制部署运维自己全部承担自己全部承担开源版可自托管社区成熟对我来说直连 API 的问题不是能力不够而是时间成本太高。我把模型接好、上下文管理好、输出格式化这个链路自己写一遍差不多要三四天而且写出来的代码基本不会复用第二次。LangChain 相比直连 API 已经好了很多但我发现它的抽象层次太丰富为了让一个简单的“先查询知识库再生成答案”的逻辑跑通我得先搞明白一堆组件的概念。最终选择 Dify主要看重三条第一知识库功能开箱即用我只需要把团队沉淀的文档传上去做切片不用自己搭向量数据库第二工作流编排所见即所得调整复盘逻辑不用改代码重新部署第三Dify 社区生态比较活跃遇到问题能找到现成方案。这个选择本质上是在“控制力”和“交付速度”之间做了一个平衡对 hindsight 这个项目来说快比全更重要。2.3 hindsight 的整体架构搭建完成之后hindsight 的整体架构可以用一个简单的流程描述。用户把复盘素材以文本、文档、或者数据集记录的形式传入Dify 工作流首先做输入校验和格式归一化然后从知识库中检索相关的历史背景资料接着拼接出一段完整的提示词交给大模型执行分析任务最后对模型返回的结果做格式校验把不合格的输出打回重跑。在模型配置上我同时接入了两种模型分析总结用中长文本能力强的旗舰模型保证归纳深度润色和格式化辅助任务用性价比更高的轻量模型控制成本。Dify 支持一个应用内配置多个模型我通过一个前置的判断节点来分流任务。比如长篇项目复盘走完整分析链路而碎片化的每日回顾只做轻量总结这样单次调用的 token 消耗可以明显下降。数据存储这块我用了 Dify 原生的数据集和会话记录能力。历史复盘报告会被保存为下次复盘时的参考上下文形成一种“越复盘越准确”的累积效应。当然这种设计也带来一个问题就是所谓“上下文污染”AI 可能会把过去复盘中的陈旧结论带入新场景这个坑我会在第五节详细说。3. 核心功能拆解与场景设计3.1 场景一会议复盘从纪要中提取真问题和真行动hindsight 最常用也最见效的场景是会议复盘。我每周会开三四个项目会每场会议都有 AI 转录生成的纪要素材但纪要不会告诉你“这个会到底解决了什么还有哪些事情被遗漏了”。利用 hindsight我只需要把原始纪要复制进来工作流就会完成三件事识别会议中的关键决策、找出遗留分歧、生成责任人明确的行动清单。在这个场景中我特别让 AI 区分“决策”和“讨论”。很多会议的通病是聊了很多但没形成决策或者误把讨论当决策。我在提示词中要求所有决策必须对应具体责任人、时间节点和验收标准如果纪要里没有明确信息必须标记为待确认不能猜。这个约束大大提高了复盘结果的可用性因为 AI 生成的报告不再是一堆模糊的正确废话而是能真正拿到下一次会上逐条核对的东西。还有一个细节值得分享在处理会议复盘时我会要求 AI 先输出“一句话会议结论”再展开详细分析。这么做是为了逼模型抓住重点。如果模型连一句话结论都给不出说明它对材料的理解还不够那我就得考虑把原始纪要拆成更小的片段再喂进去。3.2 场景二项目阶段复盘自动生成结构化报告第二个核心场景是项目阶段复盘这也是我最初决定做 hindsight 的直接原因。每到项目里程碑节点我需要提交一份阶段总结内容包括目标达成情况、偏差原因、经验和下一步计划。以前这份文档我要写两个小时现在用 hindsight把过程文档、数据截图说明、团队成员的核心总结扔进去大概五分钟就能拿到一份结构完整的初稿。项目复盘场景对输出格式有硬性要求因此我在 Dify 中单独做了一个“项目复盘”工作流和会议复盘分开。它的输出模板是固定的五个模块目标回顾、结果对比计划 vs 实际、根因分析、经验教训、后续行动计划。为了稳定输出我在提示词中直接给出了 JSON 结构的示例并要求模型严格按照 JSON 格式返回然后由 Dify 前端的应用逻辑把 JSON 渲染成带标题的文本报告渲染这块我用了一个简单的代码节点。在实际使用中我体会到项目复盘的质量高度依赖于输入材料的丰富程度。如果只丢一个项目周报进去AI 能给出的归纳非常有限但如果能把过程中的关键邮件、Bug 列表、需求变更记录都带上AI 的分析深度会有质的提升。所以我现在会在项目群里养一个习惯每两周把该阶段的代表性文档归档到一个固定文件夹复盘时直接把这个文件夹里的内容交付给 hindsight。3.3 场景三个人每日回顾与知识沉淀第三个场景偏个人使用主要服务于我自己的持续复盘需求。每天晚上我会把一天的感受、遇到的问题、想法碎片丢给 hindsight让它帮我生成一份“每日三问”式回顾今天我最重要的成就是什么、今天我最遗憾的决定是什么、明天我应该在哪个环节做出改变。这个场景的输入往往比较零散可能是几句话、一张手写笔记的照片转成的文字、或者是通勤路上用语音记录的几个要点。为了让 AI 在信息不完整时依然能给出有价值的输出我设计了一个“推测 标注”的机制AI 可以根据零散信息做合理推测但必须在输出中明确标注“这一点是基于推测”。这样既保留了分析深度又避免了幻觉信息被当成事实记录。日回顾的数据积累起来之后还有一个用法很值得推荐——把它变成知识库索引。每周末让 hindsight 把过去七天的日回顾再汇总一次提炼出当周的主题和长期规律然后自动归档到周报知识库中。时间长了这份沉淀下来的数据其实就是你自己的“生活实验记录”比任何时间管理软件都更真实。3.4 Prompt 设计中的三个关键原则在多个场景来回调整的过程中我总结出三条 prompt 设计原则可以说直接决定了 hindsight 的可用性。第一条原则是“给角色更给边界”。不要只说“你是一个复盘专家”还要明确“你只能基于用户提供的材料进行分析不能引用外部未经验证的信息”这个边界能大幅降低模型胡编乱造的概率。第二条原则是“要求结构化并给出样例”。模型对于“请分点回答”这种模糊要求的执行效果远不如“请按以下 JSON 格式返回”给出具体格式样例之后输出稳定性会高很多。我在 Dify 的每个场景工作流里都内置了输出样例效果立竿见影。第三条原则是“设置反思节点”。这不是让模型空泛地“再想想”而是告诉它在第一轮分析完成后主动检查是否有与结论矛盾的材料如果有必须重新评估并说明理由。增加这一步之后AI 给出的复盘结论明显更全面因为它不再只挑支持自己论点的证据而是被迫处理反例。4. 从零到一在 Dify 中搭建 hindsight 的完整流程4.1 环境准备与 Dify 部署我是在自己的云服务器上部署了 Dify 社区版建议配置至少 2 核 4G 内存因为 Dify 本身会启动好几个容器再加上模型 API 调用资源太紧张容易卡顿。部署方式很简单官方推荐用 Docker Compose下面是我当时的操作流程。# 拉取 Dify 源码仓库 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量示例文件 cp .env.example .env # 启动全部服务 docker compose up -d如果网络状况不太理想镜像拉取可能会失败可以配置 Docker 的镜像加速源。启动完成后浏览器访问服务器的 IP 加端口就能进入 Dify 的初始化界面。首次进入需要设置管理员账号同时可以选择默认模型供应商这一步也可以在之后的后台设置里更改。我特别提醒一句部署之后第一件事是去后台检查一下日志确认 API 服务和 worker 服务都正常起来。我第一次部署时worker 容器因为内存不足反复重启表面上看页面能打开但知识库的文档处理任务全部卡住排查了很久才发现是资源限制的问题。4.2 创建应用与核心参数配置部署好 Dify 之后进入应用管理界面创建一个“聊天助手”类型的应用这就是 hindsight 的雏形。在应用设置里有几个参数我需要强调一下它们是决定复盘质量的关键。第一个参数是模型供应商配置。我在 Dify 的后台同时添加了多家模型供应商的 API Key并把默认模型设为最适合长文本分析的版本。这里建议优先选择上下文窗口大、指令遵循能力强的模型比如 128K 上下文起步因为复盘输入常常是大量文档拼接窗口小了根本没戏。第二个参数是温度Temperature。我在不同场景里设置了不同的值做事实性总结和项目复盘温度设置为 0.2 到 0.3让输出更保守做创造性洞察分析温度可以调到 0.5 左右给模型一点自由发挥的空间。温度太高会导致复盘结论过度演绎太低又会变成机械复述这个度需要根据你自己的场景去试。第三个参数是“用户输入表单”。我在应用里配置了几个可选的表单字段比如“复盘类型会议/项目/每日”“补充背景信息”“期望输出风格”这样每次调用时用户可以在界面里明确告诉 AI 这次复盘的侧重点大大减少歧义。还有一个很重要的配置是“对话开场白”。Dify 允许自定义开场白我把 hindsight 的开场白写成了引导用户提供素材的提示比如“请粘贴需要复盘的原始记录并选择复盘类型”这样即使用户是第一次使用也知道该干什么。4.3 编写系统提示词一份可复用的复盘 Prompt系统提示词是整个 hindsight 的灵魂它不是简单几句话而是一套完整的“操作手册”。我把最终版系统提示词精简后贴在这里你可以直接复制去改成自己的版本。注意提示词中的“待复盘材料”这个变量对应 Dify 里的用户输入变量。你是 hindsight 复盘助手擅长从混沌信息中提炼结构化结论。 你的工作流程 1. 阅读并理解用户提供的待复盘材料 2. 基于知识库中的历史背景补充必要的上下文 3. 识别材料中的关键事件、决策、问题和结果 4. 进行多层归因分析区分直接原因、管理原因和系统原因 5. 输出结构化复盘报告必须包含“事实摘要”、“核心结论”、“经验教训”、“后续行动”四个部分。 严格要求 - 只基于提供材料进行判断禁止编造外部信息 - 所有结论必须能在材料中找到对应依据 - 信息不足时明确输出“信息缺失无法判断” - 行动建议必须具体到“谁在什么时间完成什么事” - 如对材料的理解存在多种可能必须列出所有可能并标注最可能的一种。这段提示词的核心在于“严格要求”部分它其实是在给模型的生成过程戴上了多道枷锁。比如“所有结论必须能在材料中找到对应依据”这一条就能有效抑制模型输出空洞内容。在实际测试中加了这句之后AI 的输出明显变得更克制但也因此更可信。如果你需要处理更复杂的情况可以在上面基础上增加“领域限定”子提示词。比如做技术项目复盘时加入“请重点关注架构设计、代码质量、交付流程、团队协作四个维度”这一段能有效把分析重心引导到技术场景。4.4 接入知识库让 AI 学会说“人话”只靠提示词hindsight 做的复盘还是有点“通而不专”因为它不了解你所在团队和项目的具体背景。为了解决这个问题我给应用接入了知识库这是 Dify 非常核心的能力相当于给 AI 一个可以随时查资料的数据库。我在 Dify 的知识库模块里创建了三个数据集一是“历史复盘库”归档了过往所有复盘文档让 AI 知道哪些问题以前踩过坑二是“项目背景库”存放团队的项目说明和技术架构文档AI 在分析项目复盘时可以随时查阅三是“行业资料库”放入与业务相关的外部参考资料用于扩展模型的判断视野。建立知识库的过程中有一个细节非常影响最终效果就是文档切片策略。Dify 支持自动分段和自定义分段我认为对复盘文档来说自定义分段更合适。我通常按章节和语义块来切每个块保持在 500 到 800 字之间这样既能保证上下文信息完整又不会因为块太大导致检索不精准。如果你的文档有明确的标题结构建议打开“标题分段”选项Dify 会自动按标题层级切块。知识库的检索配置也很关键。Dify 允许设置检索召回数量、检索模式等参数我经过反复调优后把检索召回数量设为 4 到 6 个片段相似度阈值设为 0.2这个组合在“保证相关度”和“避免遗漏背景信息”之间比较平衡。你可以在“提示词编排”里给模型明确指示“参考知识库内容时应优先采用与当前复盘场景时间最近的历史记录”这样能减少旧信息干扰。4.5 联调测试与参数调优实录应用搭好之后真正花时间的是联调和优化阶段。我用的测试方法不是随便丢几段文字看结果而是构造了一组“标准复盘测试集”里面包含了几个我特别设计的用例专门用来检验 AI 的分析能力。第一个测试用例是“信息缺失测试”我故意给一段没有结论的会议纪要并隐含提了一句“原定结论待下一篇纪要进一步确认”。好的复盘助手应该识别出信息不完整并明确告知这一点而不是强行生成结论。第二个用例是“矛盾信息测试”我在材料中故意放入两个冲突的数据检验 AI 是否会发现矛盾并追问。第三个用例是“长期依赖测试”我将一条只有结合知识库里历史文档才能理解的简称放进材料检查模型会不会去检索知识库。第一轮测试下来问题非常多。最大的问题是模型容易忽略材料中的矛盾信息直接把两个冲突数据都当作事实引用输出了一份自相矛盾的报告。为了解决这个问题我在系统提示词中加入了一条强制规则“分析前必须检查材料之间是否存在矛盾如存在必须单独列出矛盾点并优先尝试从知识库中寻找解释。”第二轮测试调整后情况好了很多但又暴露出另一个问题输出内容过于冗长一份会议复盘能写出三千字很多内容说出来等于没说。我把最初的输出格式改为表格结构要求“每个结论必须对应材料原文摘录”限制每个模块最多 200 字。经过这一轮“由繁到简”的调优hindsight 的输出才真正达到了“可以直接在工作中使用”的标准。5. 落地过程中的坑与排查实录5.1 模型幻觉复盘结论不可信怎么办使用大模型做复盘最难解决的就是幻觉问题模型可能生成一段看似合理、实则无中生有的结论。我有一次做项目复盘AI 居然“回忆”出团队在某个时间点做过一次用户调研但我非常确定那周大家都在赶工期根本没有调研安排。排查之后我发现幻觉产生的根源往往在提示词给模型施加了太大压力。当我要求“必须输出完整结论”时模型在信息不足时会倾向于编造一个逻辑上通顺、但实际不存在的细节来“填补空白”。解决办法就是我在上一节提到的“信息缺失”标记机制允许模型在无法判断时直接承认。这一点需要在公司里向使用者反复强调看到 AI 标注了推测或者信息缺失的内容就不能当事实用。另一个有效手段是强制引用溯源每一项关键结论后面必须附带材料中的原文摘录或片段编号。我最初觉得这样会让报告看起来很啰嗦但实际上大大提升了实用性。当结论可以追溯到原始材料时对错一查便知模型自己也会在生成时更谨慎因为它知道每个论断都会被审查。5.2 上下文窗口不足长文档记不住开头项目复盘经常需要输入很多文档即使选用了大上下文模型仍然会遇到长度超限的问题。Dify 提供给模型的上下文由用户输入、知识库检索结果、历史会话三部分拼接而成一次调用超过模型上限时会直接报错或者对较早的内容“失忆”。这个问题的排查并不难Dify 后台会显示每轮对话的 token 消耗如果发现输入 token 经常稳定在最大值的 90% 以上就要警惕了。我的解决办法是在进入正式分析流程之前增加一个“文档预处理”节点。这个节点由 Dify 代码模块实现会自动执行三步操作删除重复段落、压缩空白和冗余修饰语、提取每个文档的前 500 字作为摘要。这样可以在保留核心信息的前提下把输入缩短一半左右。如果材料实在太多我还会用“分块-合并”策略先把材料按主题拆成几个文件夹分别生成子复盘最后再把子复盘结果合并成一份总报告。这个策略等于把一个超长文本任务拆成了多个短任务效果比硬塞进一个上下文窗口好得多而且每一轮分析可以更专注。代价是增加了调用次数所以成本上要提前做好预算。5.3 成本失控每次复盘要烧掉多少 tokenAI 复盘看起来只是丢一段文字进去但实际 token 消耗比想象中大得多。第一次全项目复盘时我导入了所有历史周报和过程文档共约十几万字一次带知识库检索的完整调用算下来光输入 token 就消耗了差不多 6 万。如果每天做一次这样的复盘按当时的 API 价格一个月下来是一笔不小的开销。控制成本的核心思路是“让每一轮调用都只做一件事”。我在 Dify 中把复盘链路拆成了多个串行节点而不是让一次大调用完成所有任务。第一阶段先做文档摘要和预处理第二阶段再由模型基于摘要做分析与归纳。摘要阶段用的模型相对便宜分析阶段用的模型相对贵但后者输入量已经大幅缩小总体成本反而更低。另外还可以善用 Dify 的“数据集”缓存机制。对于反复使用的历史文档不需要每次复盘都重新传入可以把它们放到知识库中用检索方式按需调用。这样既避免了重复计费也提高了响应速度。如果个人使用频率很高我更推荐选用有包年套餐或者按量计费阶梯优惠的模型供应商。5.4 数据隐私与敏感信息处置复盘材料往往涉及项目内部信息、个人工作细节甚至未公开的商业决策。在使用云上大模型 API 时这些数据会经过模型服务商的服务器很多人对此有顾虑这个顾虑我认为是完全合理的。我在 hindsight 中采取了几条措施来降低风险。第一所有复盘输入材料在进入模型之前都会先经过一个本地敏感信息过滤节点把明显的内部代号、账号信息、手机号等替换成匿名占位符。Dify 支持自定义代码节点可以挂接第三方脱敏库我直接用正则表达式做了一套规则不复杂但管用。第二如果处理的是高敏感材料我会选择私有化部署的开源模型而不是调用云端 API虽然效果差一些但数据不出内网。第三Dify 本身支持自托管部署部署在自己的服务器上数据至少不会经过 Dify 的官方云服务这是一层基本的心理保障。我要提醒的是很多人在搭 AI 应用时只关注效果忽略了数据合规但复盘数据恰恰是最容易踩线的。如果你的团队或者公司有明确的数据安全规范建议在项目启动前先确认清楚哪些内容可以进外部大模型哪些必须留在内部系统。这一点做在前面能省掉后面无数麻烦。5.5 常见问题与排查方法速查表最后我把实际使用中遇到频率最高的问题整理成一个速查表方便你直接对照排查。现象可能原因排查与解决AI 输出空洞无物提示词没有限定结论必须基于材料在系统提示词里强制加入“引文溯源”规则报告前后矛盾输入材料本身包含冲突数据增加矛盾检测步骤要求 AI 单独列出矛盾点上下文超限报错输入太长或知识库检索召回过多预处理压缩输入调低知识库召回数量幻觉补充不存在的事实提示词对输出完成度要求过高允许 AI 输出“信息缺失”标注推测内容知识库检索不到相关内容切片策略不合理或阈值设置过高调整切片大小降低相似度阈值检查文档解析成本远超预期一次调用承担了过多任务拆分流程廉价模型做预处理贵模型做分析应用响应很慢服务器资源不足或模型负载高升级配置换用响应更快的模型设置合理的超时时间这张速查表里的每一项都是我踩过坑后总结出来的。解决思路不一定适用于所有情况但大概率能帮你节省几个小时甚至一天的排查时间。6. 写在最后的几点个人体会整个 hindsight 项目从想法到落地前后用了两个星期其中有收获也有遗憾。我最大的体会是AI 复盘工具不是简单“把材料丢给大模型”就完事它更像是在设计一个分析流程的自动化系统。提示词、知识库、工作流编排、成本控制每一个环节都需要结合你的真实使用场景反复迭代这远比写一个一次性提示词复杂但也远比它有价值。如果你也准备搭一个类似的复盘助手我最后给三点具体建议。第一先从一个最小的场景跑通全流程比如就做“会议复盘”不要一上来就贪多求全。第二保存一份标准测试集每次改动提示词或工作流之后用同样的测试集回归验证避免改 A 坏 B。第三从第一天开始记录 token 消耗数据不要等到月底收到账单才知道成本失控。hindsight 这个名字本身就带着一种“回过头去看清楚”的意味。对我来说这个项目最大的意义不是省下了多少写周报的时间而是它让我养成了一个更自觉地观察自己工作的习惯。每次让 AI 生成复盘结果时我会重新审视那些被我忽略的细节这种审视本身可能比任何自动化工具都更重要。