1. 项目概述hindsight 到底解决什么问题先说说这个项目怎么来的。前阵子我一直在复盘自己过去做的几个技术决策比如框架选型、架构拆分、排期预估翻来覆去发现同一个问题——当时明明觉得“考虑得很周全”的决定过两三个月回头看漏洞其实早就埋在当时的思考过程里了。这个现象有个专门的词就是 hindsight后见之明。人不缺事后诸葛亮的能力缺的是把事后复盘的结果系统化、结构化地沉淀下来变成下一次决策前的检查清单。所以我就动了念头与其靠脑子记、靠日记本写不如做一个专门干这件事的工具。正好那段时间在研究 dify 这个开源 LLM 应用开发平台发现它的工作流编排和知识库能力特别适合搭这类“复盘 分析”的助手。于是 hindsight 这个项目就诞生了——一个跑在 dify 平台上的个人决策复盘助手核心功能是把你过去的决策记录、背景信息、实际结果全部收纳进来用大模型帮你做“后见之明分析”找出当初思考链路里的盲点并生成可执行的改进建议。这个项目适合谁两类人。一类是技术管理者、项目负责人需要经常做技术选型和方案评审的另一类是任何想刻意训练自己决策能力的人哪怕只是想把日常生活中的重要选择记录下来做复盘。hindsight 不替你做决定它只帮你把“当时怎么想的”和“后来发生了什么”这两条线拉到一起让模型替你做一次冷静的第三方观察。整个项目跑在 dify 上不需要自己写前端、不用管模型部署只需要把工作流配好、把知识库喂饱一个能用的复盘助手就能上线。下面我按从思路到落地的顺序把这个项目完整拆开来讲。2. 整体设计思路为什么复盘工具需要工作流而不是一个对话框2.1 复盘这件事的天然流程决定了它必须分阶段如果你用过 ChatGPT 这类纯对话式工具你会发现让模型直接做“复盘”效果很差。原因很简单复盘是一个多阶段的过程先得把分散的信息收集齐再按固定结构整理然后才能谈得上分析最后还要输出能落地的建议。你把这四个阶段全塞进一段对话里模型要么漏掉关键信息要么输出一堆正确的废话。hindsight 的设计出发点就是把复盘拆成四个清晰的阶段。第一个阶段是信息录入你只需要用自然语言把当时的情况丢进来比如“2024年6月决定从 Vue 2 迁移到 Vue 3当时认为社区生态成熟、团队熟悉、迁移成本可控”。第二个阶段是结构化抽取模型负责把这段描述拆成“决策背景、决策选项、预期收益、风险判断、实际结果”这几个字段。第三个阶段是偏差识别这是整个项目最核心的部分模型会把你当时的风险判断和实际结果做对比指出哪些预期是过度乐观的哪些风险被低估了。第四个阶段是建议生成基于前三个阶段的输出生成针对下一次决策的检查清单。如果用对话式实现你需要在每次对话里反复强调“请按这个结构分析”模型还经常跑偏。用工作流实现就完全不一样了每个阶段是一个独立节点输入输出是固定的结构相当于给模型装了一条流水线它只需要专注做好每一步。2.2 为什么选 dify 而不是直接写代码说实话最早我考虑过直接写个 Python 脚本调用大模型 API逻辑上完全可行但很快就放弃了。原因有三个。第一决策复盘这个场景的数据结构是复杂的有决策记录、有标签分类、有复盘历史、还有知识库里的方法论文档。这些数据的关系和维护自己写代码得做数据库设计、写管理后台工作量直接翻倍。dify 自带的知识库和变量存储能力能让我在十分钟内把数据的“容器”建好把精力集中在核心的分析逻辑上。第二dify 的工作流编排是可视化拖拽的。对于 hindsight 这种需要多模型分工协作的场景意味着我可以把“结构化抽取”和“偏差识别”分配给不同的模型和不同的提示词中间用变量传递数据。如果以后想换更强的新模型拖拽替换一个节点就行不用改代码。这种灵活度对个人项目非常重要因为大模型迭代太快绑定死某个模型反而是最大的风险。第三dify 的开源社区太活跃了。RAG 相关的最佳实践、自定义工具插件的生态拿过来就能用。后面我要做的“接入个人日记数据”这个功能就是通过 dify 的 API 扩展完成的比自己维护一套数据管道省太多事。2.3 hindsight 的整体架构图景再啰嗦一句架构层面的取舍。hindsight 分两层一层是数据层用 dify 的知识库存方法论、用变量存每次复盘的历史记录另一层是处理层就是一条主工作流和三条子工作流。主工作流负责调度子工作流分别是“结构化抽取”、“偏差识别”、“建议生成”。子工作流之间不直接通信都通过主工作流的变量池传递数据这个设计后面帮了我大忙——因为任何一个环节想单独调试直接把子工作流入参填上测试数据就能跑完全不用连带跑通整个链路。3. 核心功能拆解hindsight 的三个关键能力3.1 决策结构化从自然语言到标准字段hindsight 的第一个节点做的是“翻译”工作把用户随口写的一大段话变成一张结构化的表。这一步我用的是 dify 工作流里的“LLM 节点”提示词里强制规定了输出 JSON 格式字段包括decision_date决策日期、context背景信息、options备选方案列表每个方案包含预期收益和预期风险、actual_result实际结果、reflection_period复盘周期。这里最大的坑是模型的“自由发挥”。测试时我发现如果不给示例模型经常擅自增加字段或者把日期格式改成“2024年6月”导致下游节点解析报错。后来我在提示词里加了两条铁律一是“严格按照给定的 JSON Schema 输出禁止增加或减少任何字段”二是给出一个完整的填充示例让模型有样可依。加了之后结构化抽取的成功率从不到八成提升到了接近百分百。这个环节我强烈建议打开 dify 节点的“输出预览”功能多观察几次。因为你会发现同一个描述不同模型抽取出来的字段颗粒度不一样有的模型会把“当时认为社区生态成熟”拆成两个字段有的会塞进一个字段。颗粒度大小直接影响后续偏差识别的效果所以尽量让模型把“事实描述”和“主观判断”分开这一点在提示词里就要明确区分。3.2 偏差识别hindsight 的灵魂所在偏差识别是整个项目里技术含量最高的部分也是 hindsight 这个名字真正落到实处的环节。它的输入是上一节产生的结构化字段输出是一份“认知偏差诊断报告”指出记录者在当时决策中可能存在的思维偏误类型。这里我不是让模型自由发挥地“分析一下”而是先给模型喂了一份“决策偏差分类法”作为知识库。分类法是我基于认知心理学常见的偏差类型整理的包括乐观主义偏差过度高估成功概率、沉没成本谬误因为已投入而不愿放弃、锚定效应被第一印象或初始信息带偏、确认偏误只找支持自己观点的证据、可得性启发凭最近发生的事例做判断等等。有了这个知识库做 RAG 检索模型在分析时就不是凭空谈而是先检索出“当前案例更像哪种偏差类型”再对照案例实际结果做解释。比如你记录“实际结果中迁移时间比预期多了一倍”模型会检索到“乐观主义偏差”和“规划谬误”然后用你写下的背景信息反向证明——当初预期迁移成本可控但没有考虑数据迁移中长尾问题的比例这正是典型的计划谬误。其实测下来模型对常见偏差的识别准确率相当高最大的问题反而是“误报”——模型为了显得自己有用经常把没有明显偏差的正常决策也套上一个偏差标签。这个问题的解法后面在踩坑部分细说核心思路是给模型加一道“证据门槛”。3.3 建议生成把复盘变成下一次的行动项复盘分析做得再透彻不能转化为行动就是空谈。建议生成节点做的事很简单把偏差识别报告里提到的每一个问题对应转成一条“下一次决策前必须做的事”。比如偏差报告指出“存在规划谬误低估了长尾迁移成本”建议节点就会输出“下次排期时请将长尾问题处理时间单独列出并在预估基础上乘以1.5倍系数同时在方案里写明这个系数是怎么来的”。再比如“存在锚定效应受初始方案影响过深”建议节点会输出“在做最终决定前强制列出至少两个与初始方案差异较大的备选方案并比较它们与初始方案在关键指标上的差异”。为了让建议不空泛我在这个节点的提示词里加了一个“建议必须包含可量化指标或明确动作”的约束。如果模型输出的建议里没有数字、没有具体动作词我就判断本次生成不合格触发重试。这样做的好处是一个月后你再看这些建议能明确知道自己到底做没做。4. 实操过程在 dify 上从零搭建 hindsight4.1 第一步创建应用与基础配置打开 dify 控制台创建一个“工作流”类型的应用名字直接叫 hindsight。这里有个细节应用类型一定要选工作流而不是聊天助手因为聊天助手天然面向多轮对话而工作流的节点间的数据流更可控调试体验也更好。创建完成之后你会进入一个空白的画布而已知的主工作流需要串联五个节点开始、决策结构化LLM、偏差识别LLM、建议生成LLM、结束。开始节点不需要设置太多只定义两个输入变量一个是 record_text用来接收用户输入的原始决策描述另一个是 review_cycle可选值有1周、1月、1季度表示这次复盘离决策过去多久。这两个变量后面都会通过变量池引用。创建 LLM 节点时我遇到一个选择要不要三个节点共用同一个模型测试下来我建议分开选结构化抽取用一个响应速度快的模型比如 GPT-4o mini 或者同类轻量模型偏差识别和建议生成用更强的主力模型比如 Claude 或者 GPT-4o。原因很实在——抽取任务是模式化的轻量模型完全够用且成本低分析任务需要上下文理解能力低价模型输出质量差距明显。dify 每个 LLM 节点都可以独立配置模型这个灵活性正好用上。4.2 第二步配置结构化抽取节点创建第一个 LLM 节点起名 structure_extractor。输入变量引用 start 节点里的 record_text。系统提示词我最终定稿的版本是下面这个结构你可以直接参考你是一名决策复盘分析师。用户会提供一段关于过去某个决策的自然语言描述。 请将这段描述抽取为严格的结构化数据并输出 JSON。 输出必须使用以下 JSON Schema { decision_date: 决策发生的日期格式 YYYY-MM-DD如果描述中未提到则填 unknown, context: 决策时的背景信息包含关键限制条件、资源情况、人员情况等客观事实, options: [ { name: 方案名称或标识, expected_benefit: 当时预期的收益必须使用描述中的原话或语义忠实改写, expected_risk: 当时预期的风险同上 } ], actual_result: 实际发生的结果如果描述中未提到则填 unknown, reflection_period: 复盘周期必须是 1week、1month、1quarter 之一 } 铁律 1. 只输出 JSON不要输出任何解释性文字。 2. 严格使用上述字段名称禁止新增、删除或修改字段。 3. expected_benefit 和 expected_risk 中必须严格区分当时的主观预期和后来的客观事实不能混写。这里有个容易被忽略的细节JSON Schema 里我特意要求了“reflection_period”这个字段但它其实在开始节点里已经被用户明确指定了。为什么还要让模型抽取一遍因为用户填的 review_cycle 是通用值而描述里可能包含更准确的时间线索比如“三个月后我发现”让模型从文本里二次确认能够交叉校验避免用户填写与实际情况不一致。4.3 第三步搭建偏差识别子工作流偏差识别我单独做了一个子工作流不在主工作流里直接堆节点。主工作流里用一个“工作流”节点引用它。这样做的好处是我可以把偏差识别这个环节反复调试不影响主链路上的其他部分。子工作流的输入是 structure_extractor 输出的完整 JSON 字符串以及 review_cycle 参数。在这个子工作流里最关键的配置是知识检索节点。我先在 dify 的知识库里上传了一份“决策偏差分类法说明.md”里面用统一格式写了每个偏差类型的定义、典型表现、识别线索、反例。每一个偏差类型我写一段总共有十二条每条约三百字。这里我放一段乐观主义偏差的原文片段给你看乐观主义偏差Optimism Bias个体系统性高估积极结果发生的概率低估消极结果发生的概率。识别线索预期时间线过于紧凑、没有为意外留出缓冲区、把“希望如此”当作“理应如此”。典型反例计划用时两周、实际用时一个月且延期原因是可以提前预判的数据清理问题。知识检索节点需要设置检索策略我用的是混合检索向量检索 关键词检索召回条数设为4。这样模型拿到的上下文里会包含当前案例最匹配的偏差类型以及它对应的反例。这一步是“证据门槛”的地基——模型不能随便扣帽子必须先检索到对应的偏差定义和识别线索跟案例比对后才能在报告里下结论。偏差识别的 LLM 节点提示词里我明确要求了报告的 JSON 格式{ identified_biases: [ { bias_type: 偏差类型名称, evidence: 从输入描述中引用至少两条具体证据支持这个判断, severity: high / medium / low, impact: 这个偏差对最终结果的具体影响结合 actual_result 说明 } ], analysis_summary: 不超过150字的整体复盘分析 }如果这个节点识别出的 identified_biases 为空数组或者 evidence 为空就说明案例没有明显偏差这是正常情况不必强行补一个。4.4 第四步建议生成与结束输出建议生成节点我把它的系统提示词设计得极其“苛刻”因为这是用户最后看到的东西。我要求模型必须做到两点第一每一条建议必须与偏差识别报告中的某一项一一对应禁止提出报告中未提及的新问题第二每一条建议必须包含一个可衡量的动作或指标。用第一版提示词测试时我发现模型经常“发散”会写出“建议培养风险意识”这种正确的废话。后来我加了反向约束如果输出建议中有任何一条无法与 identified_biases 列表中的条目对应整段输出视为不合格。dify 的 LLM 节点里有一个“错误重试”机制我设置的重试次数是2次重试时模型会收到前一次的输出和失败原因自己改正。实测下来加了这个约束后建议质量提升明显。最后在结束节点我把三类输出打包成一个结构化的 JSON 返回给调用方structured_record、bias_report、action_items。如果你通过 dify 的 API 调用这个应用这个 JSON 就是最终的响应体。到这里一个完整的心路复盘流程就走完了。4.5 实测效果与一次完整运行记录我拿自己过去的一个真实决策跑了完整流程输入是这样一段话“2024年3月我决定在项目中引入微前端架构主要原因是当时觉得主应用代码量太大团队拆分势在必行。当时对比了 qiankun 和 Module Federation 两个方案认为 qiankun 文档更全、社区案例更多对现状改动最小。花了两天调研后就定了 qiankun。结果到7月接入时发现老项目的兼容性问题远比预期多光处理各种运行时的坑就多花了两周但整体架构扩展性确实好了很多。”结构化抽取节点输出了两个方案qiankun 的 expected_benefit 是“文档全、社区案例多、改动最小”Module Federation 的 expected_benefit 是“无框架侵入、原生能力”actual_result 里包含了“兼容性问题多、耗时超出预期、架构扩展性提升”。偏差识别检索到了“乐观主义偏差”和“可得性启发”证据是“两天调研就决定了主流方案”和“未考虑存量系统的长尾兼容成本”。建议生成给了三条建议其中一条是“下次技术选型前列出至少五个存量系统兼容性风险点逐个与选型方案比对后再做决定”。整个流程跑完大概花了40秒成本折算下来不到一毛钱。这个速度对复盘场景完全够用毕竟你不可能一天复盘十次。5. 踩坑记录与排查技巧实录5.1 LLM 输出不稳定JSON 解析失败的背后我在搭建过程中遇到的最频繁的问题就是 LLM 输出 JSON 不合法。有时是多余的逗号有时是字段名大小写不一致有时是模型在 JSON 前加了“json”这种代码块标记。dify 的 LLM 节点虽然内置了解析器但解析失败就整个节点报错得手动重新运行。我的解法是在提示词里把“只输出 JSON不要输出代码块标记”写进了铁律同时把 JSON Schema 里的每个字段都给出了严格示例。更稳妥的办法是在 LLM 节点后面加一个“代码执行”节点用一段简单的 Python 脚本做 JSON 清洗和二次校验把模型输出里的中文字符全角逗号替换成英文半角再 json.loads 一下。这个保险丝让整个流程的稳定性从85%提升到98%以上。虽然多花了一点节点执行时间但对自动化场景来说非常值得。5.2 模型乱扣帽子偏差误报怎么治前文提到的“证据门槛”这里详细展开。第一版偏差识别节点只给了分类定义没给反例结果模型几乎在每次复盘中都能找出至少两三个偏差。刚开始我还觉得项目效果好极了直到我看了一次自己明明决策过程很理性的记录模型也给扣了个“沉没成本谬误”的帽子理由是“你花费了大量时间调研所以不愿更换方案”这完全是过度解读。治这个病我做了三件事。第一减少知识检索的召回条数从6条降到4条避免模型拿到太多无关信息后强行联想。第二在识别提示词里明确要求“证据必须引用输入描述中的原文并且至少两条独立证据才能判定存在偏差否则该偏差类型不写入报告”。第三在分类法文档里增加了“反例”字段专门描述哪种情况下这个偏差不适用。做了这三步之后误报率明显下降而且报告的说理更有说服力了不再是空泛的标签。5.3 成本控制复盘助手跑一次到底多少钱hindsight 个人使用场景下成本不可忽视。我的实测数据是单次复盘完整流程大约消耗2万到3万 token含知识检索的上下文按主流模型的中等价位折算成本在一毛钱到三毛钱人民币之间。如果每天复盘一次月成本不到十块钱完全在个人可承受范围内。如果想再压缩成本有两个技巧。第一把结构化抽取节点换成最便宜的轻量模型这个节点不吃理解力只吃遵循指令的能力。第二偏差识别子工作流里的知识检索召回数量控制在3到4条不要贪多检索结果太多会导致上下文长短和费用同时上升而且效果并不提升。5.4 知识库的维护分类法不是一次写死的最后一个踩坑是关于知识库维护的。偏差分类法一开始我写了12条用了半个月后发现有些偏差类型在实际案例中几乎不会出现比如“群体思维”——因为大部分个人决策根本涉及不到团队讨论。但也有两个我想不到的偏差类型频繁出现比如“现状偏差”倾向于维持现有状态而不做改变是我最初清单里没有的。分类法文档现在是一份活文档我每隔两三个月会根据实际识别结果的新增案例做一次补充把高频偏差的识别线索写得更细把长期不命中的条目下线。这个过程本身其实就是在对 hindsight 这个工具做“复盘”算是项目名字的另一种映射。6. 后续扩展与写给想复刻的人hindsight 目前做到的是决策复盘的单次分析但它真正长远的价值在于跨时间的趋势分析。我现在已经在规划第二期功能把每次复盘的偏差报告按时间轴存进 dify 的知识库然后做一次“季度趋势分析”让模型回答“这三个月的复盘中反复出现的高频偏差有哪些”。这个很有用因为单次复盘只能看到一棵树趋势分析能看到整片森林。如果你也想在自己的 dify 环境里搭一个类似的复盘助手我给你的核心建议是不要执着于一次把流程做完美先照着上面的结构把五个节点串起来跑通然后用你自己真实的决策记录去跑把模型输出的每一份报告都当成提示词改进的依据。我前前后后调了十几个版本的提示词最终定稿的版本和你现在看到的已经差别很大了。这类 AI 应用的特点就是模型的弱点就是你改进的方向没有一劳永逸的配置只有越调越顺的过程。最后分享一个我比较大的心得转变。最初我以为 hindsight 的价值在于“得到一份分析报告”用了几周之后发现真正改变我习惯的是“把决策写下来”这个动作本身。为了喂给这个工具我开始有意识地把每个重要决策的背景、选项、预期风险记录下来这件事倒逼我在做决定时更审慎。工具最终沉淀下来的不只是数据更是一种思考习惯。这大概就是 hindsight 这个名字背后真正的含义。 基于Dify工作流构建个人决策复盘助手：从认知偏差识别到行动建议
1. 项目概述hindsight 到底解决什么问题先说说这个项目怎么来的。前阵子我一直在复盘自己过去做的几个技术决策比如框架选型、架构拆分、排期预估翻来覆去发现同一个问题——当时明明觉得“考虑得很周全”的决定过两三个月回头看漏洞其实早就埋在当时的思考过程里了。这个现象有个专门的词就是 hindsight后见之明。人不缺事后诸葛亮的能力缺的是把事后复盘的结果系统化、结构化地沉淀下来变成下一次决策前的检查清单。所以我就动了念头与其靠脑子记、靠日记本写不如做一个专门干这件事的工具。正好那段时间在研究 dify 这个开源 LLM 应用开发平台发现它的工作流编排和知识库能力特别适合搭这类“复盘 分析”的助手。于是 hindsight 这个项目就诞生了——一个跑在 dify 平台上的个人决策复盘助手核心功能是把你过去的决策记录、背景信息、实际结果全部收纳进来用大模型帮你做“后见之明分析”找出当初思考链路里的盲点并生成可执行的改进建议。这个项目适合谁两类人。一类是技术管理者、项目负责人需要经常做技术选型和方案评审的另一类是任何想刻意训练自己决策能力的人哪怕只是想把日常生活中的重要选择记录下来做复盘。hindsight 不替你做决定它只帮你把“当时怎么想的”和“后来发生了什么”这两条线拉到一起让模型替你做一次冷静的第三方观察。整个项目跑在 dify 上不需要自己写前端、不用管模型部署只需要把工作流配好、把知识库喂饱一个能用的复盘助手就能上线。下面我按从思路到落地的顺序把这个项目完整拆开来讲。2. 整体设计思路为什么复盘工具需要工作流而不是一个对话框2.1 复盘这件事的天然流程决定了它必须分阶段如果你用过 ChatGPT 这类纯对话式工具你会发现让模型直接做“复盘”效果很差。原因很简单复盘是一个多阶段的过程先得把分散的信息收集齐再按固定结构整理然后才能谈得上分析最后还要输出能落地的建议。你把这四个阶段全塞进一段对话里模型要么漏掉关键信息要么输出一堆正确的废话。hindsight 的设计出发点就是把复盘拆成四个清晰的阶段。第一个阶段是信息录入你只需要用自然语言把当时的情况丢进来比如“2024年6月决定从 Vue 2 迁移到 Vue 3当时认为社区生态成熟、团队熟悉、迁移成本可控”。第二个阶段是结构化抽取模型负责把这段描述拆成“决策背景、决策选项、预期收益、风险判断、实际结果”这几个字段。第三个阶段是偏差识别这是整个项目最核心的部分模型会把你当时的风险判断和实际结果做对比指出哪些预期是过度乐观的哪些风险被低估了。第四个阶段是建议生成基于前三个阶段的输出生成针对下一次决策的检查清单。如果用对话式实现你需要在每次对话里反复强调“请按这个结构分析”模型还经常跑偏。用工作流实现就完全不一样了每个阶段是一个独立节点输入输出是固定的结构相当于给模型装了一条流水线它只需要专注做好每一步。2.2 为什么选 dify 而不是直接写代码说实话最早我考虑过直接写个 Python 脚本调用大模型 API逻辑上完全可行但很快就放弃了。原因有三个。第一决策复盘这个场景的数据结构是复杂的有决策记录、有标签分类、有复盘历史、还有知识库里的方法论文档。这些数据的关系和维护自己写代码得做数据库设计、写管理后台工作量直接翻倍。dify 自带的知识库和变量存储能力能让我在十分钟内把数据的“容器”建好把精力集中在核心的分析逻辑上。第二dify 的工作流编排是可视化拖拽的。对于 hindsight 这种需要多模型分工协作的场景意味着我可以把“结构化抽取”和“偏差识别”分配给不同的模型和不同的提示词中间用变量传递数据。如果以后想换更强的新模型拖拽替换一个节点就行不用改代码。这种灵活度对个人项目非常重要因为大模型迭代太快绑定死某个模型反而是最大的风险。第三dify 的开源社区太活跃了。RAG 相关的最佳实践、自定义工具插件的生态拿过来就能用。后面我要做的“接入个人日记数据”这个功能就是通过 dify 的 API 扩展完成的比自己维护一套数据管道省太多事。2.3 hindsight 的整体架构图景再啰嗦一句架构层面的取舍。hindsight 分两层一层是数据层用 dify 的知识库存方法论、用变量存每次复盘的历史记录另一层是处理层就是一条主工作流和三条子工作流。主工作流负责调度子工作流分别是“结构化抽取”、“偏差识别”、“建议生成”。子工作流之间不直接通信都通过主工作流的变量池传递数据这个设计后面帮了我大忙——因为任何一个环节想单独调试直接把子工作流入参填上测试数据就能跑完全不用连带跑通整个链路。3. 核心功能拆解hindsight 的三个关键能力3.1 决策结构化从自然语言到标准字段hindsight 的第一个节点做的是“翻译”工作把用户随口写的一大段话变成一张结构化的表。这一步我用的是 dify 工作流里的“LLM 节点”提示词里强制规定了输出 JSON 格式字段包括decision_date决策日期、context背景信息、options备选方案列表每个方案包含预期收益和预期风险、actual_result实际结果、reflection_period复盘周期。这里最大的坑是模型的“自由发挥”。测试时我发现如果不给示例模型经常擅自增加字段或者把日期格式改成“2024年6月”导致下游节点解析报错。后来我在提示词里加了两条铁律一是“严格按照给定的 JSON Schema 输出禁止增加或减少任何字段”二是给出一个完整的填充示例让模型有样可依。加了之后结构化抽取的成功率从不到八成提升到了接近百分百。这个环节我强烈建议打开 dify 节点的“输出预览”功能多观察几次。因为你会发现同一个描述不同模型抽取出来的字段颗粒度不一样有的模型会把“当时认为社区生态成熟”拆成两个字段有的会塞进一个字段。颗粒度大小直接影响后续偏差识别的效果所以尽量让模型把“事实描述”和“主观判断”分开这一点在提示词里就要明确区分。3.2 偏差识别hindsight 的灵魂所在偏差识别是整个项目里技术含量最高的部分也是 hindsight 这个名字真正落到实处的环节。它的输入是上一节产生的结构化字段输出是一份“认知偏差诊断报告”指出记录者在当时决策中可能存在的思维偏误类型。这里我不是让模型自由发挥地“分析一下”而是先给模型喂了一份“决策偏差分类法”作为知识库。分类法是我基于认知心理学常见的偏差类型整理的包括乐观主义偏差过度高估成功概率、沉没成本谬误因为已投入而不愿放弃、锚定效应被第一印象或初始信息带偏、确认偏误只找支持自己观点的证据、可得性启发凭最近发生的事例做判断等等。有了这个知识库做 RAG 检索模型在分析时就不是凭空谈而是先检索出“当前案例更像哪种偏差类型”再对照案例实际结果做解释。比如你记录“实际结果中迁移时间比预期多了一倍”模型会检索到“乐观主义偏差”和“规划谬误”然后用你写下的背景信息反向证明——当初预期迁移成本可控但没有考虑数据迁移中长尾问题的比例这正是典型的计划谬误。其实测下来模型对常见偏差的识别准确率相当高最大的问题反而是“误报”——模型为了显得自己有用经常把没有明显偏差的正常决策也套上一个偏差标签。这个问题的解法后面在踩坑部分细说核心思路是给模型加一道“证据门槛”。3.3 建议生成把复盘变成下一次的行动项复盘分析做得再透彻不能转化为行动就是空谈。建议生成节点做的事很简单把偏差识别报告里提到的每一个问题对应转成一条“下一次决策前必须做的事”。比如偏差报告指出“存在规划谬误低估了长尾迁移成本”建议节点就会输出“下次排期时请将长尾问题处理时间单独列出并在预估基础上乘以1.5倍系数同时在方案里写明这个系数是怎么来的”。再比如“存在锚定效应受初始方案影响过深”建议节点会输出“在做最终决定前强制列出至少两个与初始方案差异较大的备选方案并比较它们与初始方案在关键指标上的差异”。为了让建议不空泛我在这个节点的提示词里加了一个“建议必须包含可量化指标或明确动作”的约束。如果模型输出的建议里没有数字、没有具体动作词我就判断本次生成不合格触发重试。这样做的好处是一个月后你再看这些建议能明确知道自己到底做没做。4. 实操过程在 dify 上从零搭建 hindsight4.1 第一步创建应用与基础配置打开 dify 控制台创建一个“工作流”类型的应用名字直接叫 hindsight。这里有个细节应用类型一定要选工作流而不是聊天助手因为聊天助手天然面向多轮对话而工作流的节点间的数据流更可控调试体验也更好。创建完成之后你会进入一个空白的画布而已知的主工作流需要串联五个节点开始、决策结构化LLM、偏差识别LLM、建议生成LLM、结束。开始节点不需要设置太多只定义两个输入变量一个是 record_text用来接收用户输入的原始决策描述另一个是 review_cycle可选值有1周、1月、1季度表示这次复盘离决策过去多久。这两个变量后面都会通过变量池引用。创建 LLM 节点时我遇到一个选择要不要三个节点共用同一个模型测试下来我建议分开选结构化抽取用一个响应速度快的模型比如 GPT-4o mini 或者同类轻量模型偏差识别和建议生成用更强的主力模型比如 Claude 或者 GPT-4o。原因很实在——抽取任务是模式化的轻量模型完全够用且成本低分析任务需要上下文理解能力低价模型输出质量差距明显。dify 每个 LLM 节点都可以独立配置模型这个灵活性正好用上。4.2 第二步配置结构化抽取节点创建第一个 LLM 节点起名 structure_extractor。输入变量引用 start 节点里的 record_text。系统提示词我最终定稿的版本是下面这个结构你可以直接参考你是一名决策复盘分析师。用户会提供一段关于过去某个决策的自然语言描述。 请将这段描述抽取为严格的结构化数据并输出 JSON。 输出必须使用以下 JSON Schema { decision_date: 决策发生的日期格式 YYYY-MM-DD如果描述中未提到则填 unknown, context: 决策时的背景信息包含关键限制条件、资源情况、人员情况等客观事实, options: [ { name: 方案名称或标识, expected_benefit: 当时预期的收益必须使用描述中的原话或语义忠实改写, expected_risk: 当时预期的风险同上 } ], actual_result: 实际发生的结果如果描述中未提到则填 unknown, reflection_period: 复盘周期必须是 1week、1month、1quarter 之一 } 铁律 1. 只输出 JSON不要输出任何解释性文字。 2. 严格使用上述字段名称禁止新增、删除或修改字段。 3. expected_benefit 和 expected_risk 中必须严格区分当时的主观预期和后来的客观事实不能混写。这里有个容易被忽略的细节JSON Schema 里我特意要求了“reflection_period”这个字段但它其实在开始节点里已经被用户明确指定了。为什么还要让模型抽取一遍因为用户填的 review_cycle 是通用值而描述里可能包含更准确的时间线索比如“三个月后我发现”让模型从文本里二次确认能够交叉校验避免用户填写与实际情况不一致。4.3 第三步搭建偏差识别子工作流偏差识别我单独做了一个子工作流不在主工作流里直接堆节点。主工作流里用一个“工作流”节点引用它。这样做的好处是我可以把偏差识别这个环节反复调试不影响主链路上的其他部分。子工作流的输入是 structure_extractor 输出的完整 JSON 字符串以及 review_cycle 参数。在这个子工作流里最关键的配置是知识检索节点。我先在 dify 的知识库里上传了一份“决策偏差分类法说明.md”里面用统一格式写了每个偏差类型的定义、典型表现、识别线索、反例。每一个偏差类型我写一段总共有十二条每条约三百字。这里我放一段乐观主义偏差的原文片段给你看乐观主义偏差Optimism Bias个体系统性高估积极结果发生的概率低估消极结果发生的概率。识别线索预期时间线过于紧凑、没有为意外留出缓冲区、把“希望如此”当作“理应如此”。典型反例计划用时两周、实际用时一个月且延期原因是可以提前预判的数据清理问题。知识检索节点需要设置检索策略我用的是混合检索向量检索 关键词检索召回条数设为4。这样模型拿到的上下文里会包含当前案例最匹配的偏差类型以及它对应的反例。这一步是“证据门槛”的地基——模型不能随便扣帽子必须先检索到对应的偏差定义和识别线索跟案例比对后才能在报告里下结论。偏差识别的 LLM 节点提示词里我明确要求了报告的 JSON 格式{ identified_biases: [ { bias_type: 偏差类型名称, evidence: 从输入描述中引用至少两条具体证据支持这个判断, severity: high / medium / low, impact: 这个偏差对最终结果的具体影响结合 actual_result 说明 } ], analysis_summary: 不超过150字的整体复盘分析 }如果这个节点识别出的 identified_biases 为空数组或者 evidence 为空就说明案例没有明显偏差这是正常情况不必强行补一个。4.4 第四步建议生成与结束输出建议生成节点我把它的系统提示词设计得极其“苛刻”因为这是用户最后看到的东西。我要求模型必须做到两点第一每一条建议必须与偏差识别报告中的某一项一一对应禁止提出报告中未提及的新问题第二每一条建议必须包含一个可衡量的动作或指标。用第一版提示词测试时我发现模型经常“发散”会写出“建议培养风险意识”这种正确的废话。后来我加了反向约束如果输出建议中有任何一条无法与 identified_biases 列表中的条目对应整段输出视为不合格。dify 的 LLM 节点里有一个“错误重试”机制我设置的重试次数是2次重试时模型会收到前一次的输出和失败原因自己改正。实测下来加了这个约束后建议质量提升明显。最后在结束节点我把三类输出打包成一个结构化的 JSON 返回给调用方structured_record、bias_report、action_items。如果你通过 dify 的 API 调用这个应用这个 JSON 就是最终的响应体。到这里一个完整的心路复盘流程就走完了。4.5 实测效果与一次完整运行记录我拿自己过去的一个真实决策跑了完整流程输入是这样一段话“2024年3月我决定在项目中引入微前端架构主要原因是当时觉得主应用代码量太大团队拆分势在必行。当时对比了 qiankun 和 Module Federation 两个方案认为 qiankun 文档更全、社区案例更多对现状改动最小。花了两天调研后就定了 qiankun。结果到7月接入时发现老项目的兼容性问题远比预期多光处理各种运行时的坑就多花了两周但整体架构扩展性确实好了很多。”结构化抽取节点输出了两个方案qiankun 的 expected_benefit 是“文档全、社区案例多、改动最小”Module Federation 的 expected_benefit 是“无框架侵入、原生能力”actual_result 里包含了“兼容性问题多、耗时超出预期、架构扩展性提升”。偏差识别检索到了“乐观主义偏差”和“可得性启发”证据是“两天调研就决定了主流方案”和“未考虑存量系统的长尾兼容成本”。建议生成给了三条建议其中一条是“下次技术选型前列出至少五个存量系统兼容性风险点逐个与选型方案比对后再做决定”。整个流程跑完大概花了40秒成本折算下来不到一毛钱。这个速度对复盘场景完全够用毕竟你不可能一天复盘十次。5. 踩坑记录与排查技巧实录5.1 LLM 输出不稳定JSON 解析失败的背后我在搭建过程中遇到的最频繁的问题就是 LLM 输出 JSON 不合法。有时是多余的逗号有时是字段名大小写不一致有时是模型在 JSON 前加了“json”这种代码块标记。dify 的 LLM 节点虽然内置了解析器但解析失败就整个节点报错得手动重新运行。我的解法是在提示词里把“只输出 JSON不要输出代码块标记”写进了铁律同时把 JSON Schema 里的每个字段都给出了严格示例。更稳妥的办法是在 LLM 节点后面加一个“代码执行”节点用一段简单的 Python 脚本做 JSON 清洗和二次校验把模型输出里的中文字符全角逗号替换成英文半角再 json.loads 一下。这个保险丝让整个流程的稳定性从85%提升到98%以上。虽然多花了一点节点执行时间但对自动化场景来说非常值得。5.2 模型乱扣帽子偏差误报怎么治前文提到的“证据门槛”这里详细展开。第一版偏差识别节点只给了分类定义没给反例结果模型几乎在每次复盘中都能找出至少两三个偏差。刚开始我还觉得项目效果好极了直到我看了一次自己明明决策过程很理性的记录模型也给扣了个“沉没成本谬误”的帽子理由是“你花费了大量时间调研所以不愿更换方案”这完全是过度解读。治这个病我做了三件事。第一减少知识检索的召回条数从6条降到4条避免模型拿到太多无关信息后强行联想。第二在识别提示词里明确要求“证据必须引用输入描述中的原文并且至少两条独立证据才能判定存在偏差否则该偏差类型不写入报告”。第三在分类法文档里增加了“反例”字段专门描述哪种情况下这个偏差不适用。做了这三步之后误报率明显下降而且报告的说理更有说服力了不再是空泛的标签。5.3 成本控制复盘助手跑一次到底多少钱hindsight 个人使用场景下成本不可忽视。我的实测数据是单次复盘完整流程大约消耗2万到3万 token含知识检索的上下文按主流模型的中等价位折算成本在一毛钱到三毛钱人民币之间。如果每天复盘一次月成本不到十块钱完全在个人可承受范围内。如果想再压缩成本有两个技巧。第一把结构化抽取节点换成最便宜的轻量模型这个节点不吃理解力只吃遵循指令的能力。第二偏差识别子工作流里的知识检索召回数量控制在3到4条不要贪多检索结果太多会导致上下文长短和费用同时上升而且效果并不提升。5.4 知识库的维护分类法不是一次写死的最后一个踩坑是关于知识库维护的。偏差分类法一开始我写了12条用了半个月后发现有些偏差类型在实际案例中几乎不会出现比如“群体思维”——因为大部分个人决策根本涉及不到团队讨论。但也有两个我想不到的偏差类型频繁出现比如“现状偏差”倾向于维持现有状态而不做改变是我最初清单里没有的。分类法文档现在是一份活文档我每隔两三个月会根据实际识别结果的新增案例做一次补充把高频偏差的识别线索写得更细把长期不命中的条目下线。这个过程本身其实就是在对 hindsight 这个工具做“复盘”算是项目名字的另一种映射。6. 后续扩展与写给想复刻的人hindsight 目前做到的是决策复盘的单次分析但它真正长远的价值在于跨时间的趋势分析。我现在已经在规划第二期功能把每次复盘的偏差报告按时间轴存进 dify 的知识库然后做一次“季度趋势分析”让模型回答“这三个月的复盘中反复出现的高频偏差有哪些”。这个很有用因为单次复盘只能看到一棵树趋势分析能看到整片森林。如果你也想在自己的 dify 环境里搭一个类似的复盘助手我给你的核心建议是不要执着于一次把流程做完美先照着上面的结构把五个节点串起来跑通然后用你自己真实的决策记录去跑把模型输出的每一份报告都当成提示词改进的依据。我前前后后调了十几个版本的提示词最终定稿的版本和你现在看到的已经差别很大了。这类 AI 应用的特点就是模型的弱点就是你改进的方向没有一劳永逸的配置只有越调越顺的过程。最后分享一个我比较大的心得转变。最初我以为 hindsight 的价值在于“得到一份分析报告”用了几周之后发现真正改变我习惯的是“把决策写下来”这个动作本身。为了喂给这个工具我开始有意识地把每个重要决策的背景、选项、预期风险记录下来这件事倒逼我在做决定时更审慎。工具最终沉淀下来的不只是数据更是一种思考习惯。这大概就是 hindsight 这个名字背后真正的含义。