面试复盘这个事，我一直觉得它是一个被严重低估的"高频低效"场景。大部分人面完一场试，能记住的只有"当时有点紧张"和"那个题好像答偏了"，再细的就说不清了。英文里有个词叫hindsight，说的是回看时对当时的处境突然有了清晰的认知——面试官问"你最大的缺点是什么"，你脑子里明明有个真实案例，嘴上却开始背模板；走出大楼五分钟，你才反应过来"其实当时应该那样讲"。这种一拍大腿的瞬间，就是复盘的价值所在，也是我把这个工具命名为hindsight的原因。

这个项目的起点其实很简单：我想做一个面向求职者的AI面试复盘工具，输入面试录音或笔录，输出一份结构化的复盘报告，告诉你在哪些问题上答得好，哪些问题答得偏离面试官的期待，以及下一次可以怎么调整。而技术选型上，我直接选了Dify做应用底座——看中的是它的可视化工作流、RAG知识库和模型管理能力，让我不用从零写一遍LLM应用的后端管线。这篇文章就把整个项目的搭建思路、关键设计、实测数据和踩过的坑都摊开讲一遍，给想用Dify做这类"过程分析型工具"的人一个参考。

1. 面试复盘这件事，到底难在哪里

1.1 记忆衰减是复盘最大的敌人

先做个简单的实验：你现在回忆上周的一次半小时通话，能还原出多少内容？大多数人只能记住三到五个关键片段，而且是那种情绪波动最大的时刻——比如被追问到卡壳、某个问题答得特别顺。面试也一样，而且因为身处高压环境，记忆衰减得更厉害。

这种衰减带来的直接后果是，候选人复盘时只能基于"感觉"来判断，而不是基于"事实"。你以为自己答得很差的一道题，可能只是在那个瞬间没抓住重点，后面挽救的部分其实不错；你以为发挥得很好的一段，也许在面试官耳朵里恰恰暴露了逻辑漏洞。没有完整的事实记录，复盘就成了猜谜。

所以hindsight的第一步，是先解决"事实记录"的问题。我在设计里要求用户上传完整的面试录音，通过转写得到逐字稿，后续所有分析都基于这份逐字稿展开。底层的逻辑是：先有完整信息，再做结构化拆解，最后才谈得上评估和建议。

1.2 面试官视角与候选人视角的信息差

面试复盘难的另一个原因，是信息差。候选人只能看到自己的回答，看不到面试官为什么追问这个问题、追问的哪一点、哪个回答触发了面试官的进一步深挖。

举个例子。面试官问"你做过最有挑战的项目是什么"，候选人A回答时提到了技术选型、时间压力和最终交付结果，面试官追问了"当时备选方案为什么没有选"，候选人答了两个原因，面试官点头进入下一个问题。候选人B同样回答了项目经历，但面试官一直在追问数据细节，追了三轮之后候选人开始语无伦次。

同样的问题，一个被追问一次就过了，一个被追问三轮还在打转。单看回答内容，A和B的答案差距不算悬殊，但面试官的追问行为已经说明了很多。只是候选人当时根本意识不到这层含义。hindsight要做的，就是把这类"行为痕迹"转化为"可解释的反馈"，告诉用户：追问次数本身就暗示了回答在某个维度上存在缺口。

1.3 复盘工具应该解决的核心问题

想清楚这些之后，我给hindsight定了几条产品原则：

• 不预测面试结果，只分析表现特征。能不能拿到offer受太多外部因素影响（岗位竞争度、面试官偏好、企业临时调整），工具只能帮你在能力呈现这个维度上做到更好。
• 结论必须有据可查。每一句评价都要能链回逐字稿的原文，否则就只是AI在"感觉"。
• 建议要可执行。"注意逻辑"这种话毫无价值，必须落到具体的重构思路上。
• 面向过程，不面向结果打分。给的是"这道题你从哪个维度开始答会更完整"，而不是"你这场面试能过"。

2. 为什么是Dify做底座，而不是从零写一套LLM管线

2.1 一句话定位：Dify是LLM应用的可视化装配车间

如果你没接触过Dify，我用一句话说明它是什么：一个开源的LLM应用开发平台，可以在界面上把模型调用、知识库检索、代码处理、条件分支这些模块用工作流节点串起来，最终对外发布成API或Web应用。它解决的是LLM应用从"idea"到"product"之间的工程化问题。

在hindsight项目之前，我试过用纯代码直接调模型API做整套链路。功能上当然可以做，但有一个很现实的问题：迭代太慢了。你改一个Prompt的评估维度，要改代码、跑测试、重新部署；调一下知识库的分段策略，又得重新维护向量索引的构建流程。这些开销在项目早期会吞掉大量时间，让你根本没精力去关注真正核心的问题——分析逻辑本身是否可靠。

2.2 三个关键支撑点：工作流、知识库、模型管理

Dify对hindsight有价值的功能，我列了这三个：

• 可视化工作流（Workflow）：hindsight的处理链路有多个阶段——文本清洗、问题抽取、回答切分、逐题评估、报告生成。用工作流节点串联之后，每一步的输入输出都可以在界面上直接检查，对于调优分析质量非常重要。
• 知识库（RAG）：评估面试回答质量的时候，需要参考"好的回答长什么样"以及岗位JD里面的要求。Dify的知识库支持多种分段策略和检索模式，可以用来存储这些参考材料，让评估不依赖模型自身的隐含知识。
• 模型管理：Dify可以统一配置不同模型供应商的Key，工作流里的不同节点可以用不同的模型。我在hindsight里的做法是，信息抽取类的任务用速度更快的模型，评估和报告生成用能力更强的模型，这样成本和质量之间有灵活调配的空间。

2.3 和直接调API相比，省了什么麻烦

具体对比一下"纯代码方案"和"Dify方案"在开发体验上的差异：

这不是说Dify完美无缺，而是说在hindsight这种原型快速验证期，选Dify能把开发精力放到算法和分析逻辑上。至于平台能力的边界问题，我会在第六节踩坑部分详细展开——它确实有一些让人头疼的限制，但不影响它在这个项目里成为正确的选择。

3. hindsight的核心链路：从录音文件到结构化复盘报告

3.1 链路总览：四个阶段一条流水线

hindsight的完整处理链路是：上传录音 → ASR转写 → 结构化抽取 → 逐题评估 → 报告生成。在Dify的Workflow里，我把后三步做成了四个核心节点，每个节点独立可测：

1. 文本预处理节点：处理转写文本，去除语气词、重复词，标记说话人。
2. 问题抽取节点：把面试官的所有提问按顺序提取出来，形成一个"问题清单"。
3. 回答切分节点：把候选人的回答按对应问题切分，建立"问题-回答"配对。
4. 逐题评估节点：对每一对"问题-回答"进行多维度评估，输出结构化结论。

最终，报告生成节点会把所有结论汇总，输出成Markdown格式的复盘文档。

3.2 输入层：录音转写与质量校验

这个环节是整个链路的地基。转写质量如果打不过关，后面所有分析都不可靠。

我第一次测试时用的是现场录音，环境噪音和说话重叠让转写结果惨不忍睹。后来在项目里明确要求：尽量使用在线面试的录屏/录音导出文件，或者环境相对安静的手机录音。同时我在输入层加了一个质量校验逻辑——检测转写文本中"嗯""啊""那个"等填充词的比例，如果比例异常高，就提示用户录音质量可能不佳，建议换一份再分析。

这里插一个实际经验：麦克风距离和采样率，比录音软件的"降噪"功能重要得多。用手机采访时，手机平放在桌上和拿在手里，转写准确率会差不少。我测试时不少翻车案例都来自环境混响，尤其是那种中等大小的空房间，远比马路边的噪音更影响ASR效果。

3.3 信息抽取层：如何把一场对话拆成干净的结构化数据

转写文本是一大段连续的对话流，要分析它，得先把它拆开。这里有两个关键节点，每一个都有设计细节。

问题抽取的关键：如何识别"这是个问题"

面试官说的话并不全是问句。比如，"说说你之前做过的项目"是问题；"嗯，然后呢"是追问引导；"好的，这个问题我们聊到这"是结束语。如果简单按问号来判断，会把"你还有什么想问的吗"这类社交性问句也当成核心问题，干扰后续评估。

我在Prompt里给了模型明确的抽取规则：只有涉及候选人经历、能力、观点、动机的提问才属于"评估性问题"；纯过渡性、社交性的问句归入"非评估性话语"，不进入评估流程。同时要求模型标注该问题是属于"行为面试类"（比如描述一个曾经面对的冲突）、"技术考核类"（比如解释某个方案的实现）还是"动机类"（比如为什么选择这个公司），给后面的评估节点提供分类依据。

回答切分的关键：边界不总是清晰的

候选人回答问题时经常跑题。面试官问A，候选人讲了B，或者回答A的中途绕去补充了之前的项目细节。如果机械地按"面试官提问之后到下一次提问之前"来切回答，切出来的文本会夹着很多无关信息。

我用了一个折中策略：先做粗切分，再让模型判断粗切出来的回答中是否有超过一定比例的文本偏离该问题；如果有，则在评估时单独标注"回答漂移"，而不是强行把偏离内容也算进这个问题的回答质量里。这个设计在用户体验上的好处是，用户能看到"你在这个问题上跑题了多少"，这本身就是重要的复盘信息。

3.4 评估层：从"说的内容"到"回答的特征"

信息抽取完成之后，评估节点拿到的是：一个问题文本、对应的候选人回答文本、问题类型。评估节点会输出一份结构化的评分卡，设计如下：

{ "question_id": 3, "question_type": "behavioral", "question_text": "你遇到过最棘手的技术难题是什么？", "evaluation": { "structure_score": 72, "structure_reason": "回答有背景-行动-结果的框架，但结果部分缺少量化指标", "relevance_score": 65, "relevance_reason": "后半段花了一半篇幅讲与问题无关的项目细节", "depth_score": 78, "depth_reason": "对技术难点的原理分析到位，但未提及备选方案的对比", "clarity_score": 80, "clarity_reason": "表达流畅，逻辑主线清晰", "evidence_score": 58, "evidence_reason": "缺乏可验证的具体数据支撑，多处使用'很多''大幅'等模糊量词" }, "improvement_suggestion": "建议补充三点：问题背景中的约束条件、当时的备选方案与取舍依据、最后效果的量化数字。" }

这个评分卡的维度选择不是一个拍脑袋的决定。我参考了招聘面试中常用的行为面试评分方法，结合候选人复盘场景做了裁剪。结构维度考察的是有没有清晰的叙述框架，相关维度考察的是有没有绕开问题，深度维度考察的是有没有触及问题背后的本质，证据维度考察的是有没有用事实和数字说话。这几个维度覆盖了"回答质量"最核心的几个切面。

3.5 输出层：复盘报告的生成与存储

最后的报告生成节点，会把所有题目的评估结果汇总成一份按时间顺序排列的复盘文档。报告分为六个部分：

• 面试概览：时间、转写字数、问题总数、各类问题占比。
• 总体表现：各维度的平均分和横向对比。
• 逐题解析：每一道问题的评估结果、原文引用、改进建议。
• 追问分析：面试官追问较多的题目，按追问次数排序。
• 高频话题聚类：整个面试中最常出现的关键词和话题。
• 下次准备建议：综合所有题目评估，给出3-5条优先级最高的建议。

报告在Dify里通过一个返回Markdown的节点生成，用户可以在WebApp界面直接查看，也可以复制到自己的笔记工具里存档。

4. 评估Prompt的设计：让AI的评价不流于"你很棒"或"你不行"

4.1 角色设定：让模型站在面试官助理的位置上

Prompt设计是整个hindsight项目中迭代次数最多、对最终质量影响最大的部分。大量的实际效果验证让我认识到，与其写一个"全知全能的评估者"角色，不如明确告诉模型它的工作关系和边界。

hindsight的评估节点Prompt采用的核心设定是：你是一名面试复盘顾问，正在帮助候选人分析一场真实面试。你不是面试官本身，也无法知晓面试官的真实想法，你的任务是基于候选人回答的文本证据，推断其表现的强项与待改进之处。

这个设定的价值在于"边界"两个字。一旦模型以为自己是面试官，它就容易自己编造"面试官觉得你匹配"这类结论；一旦它站到候选人一边，它又会变得宽容，把明显不完整的回答也说成"展现了良好的抗压能力"。设定为中间视角的顾问，模型会更倾向于援引证据、给出中性的结构分析。

4.2 追问行为分析：从"答了什么"到"被追问了什么"

这个模块的出发点很简单：面试官追问次数最多的回答，往往不是答得最差的，而是回答中最值得深挖的。我观察了很多场面试样本后，总结出三个规律：

第一，面试官对缺乏具体细节的回答会连续追问"具体是怎么做的""当时的数据是多少"，这类追问通常是感觉到了回答的"空"。

第二，面试官觉得找到了可以深挖的点时，也会连续追问，目的是测试候选人的真实掌握程度。

第三，面试官对答案已经满意时，追问很少，会直接切换到下一个问题。

所以，仅仅统计追问次数是不够的，还要结合追问的内容来判断。我在评估节点里增加了一个"追问分析"子任务，专门提取面试官的追问序列，并分类为"澄清性追问"（目标是获取具体细节）和"挑战性追问"（目标是测试边界），然后分别统计。这两类追问出现的频次，能告诉候选人"你哪段叙述留下的漏洞最多"。

4.3 知识库：好答案的"对标样本"从哪里来

评估一个回答好不好，不能只靠模型的隐含判断，还需要有可对照的参考标准。hindsight的知识库里放了三类材料：

• 岗位JD及技能栈说明：用于判断回答中提到的技术栈、项目方向与目标岗位的匹配情况。
• 优秀回答示例库：收集了同类高频面试题的高质量回答框架，比如"讲一个失败项目""介绍一个复杂系统设计"这类题目的参考结构。
• 公司/团队背景资料：用于判断候选人回答中体现的价值观、工作方式是否与目标团队文化有冲突点。

知识库的检索逻辑不用太复杂，按问题类型做粗粒度分类，然后用向量相似度取Top K条相关内容注入Prompt。这个设计让评估Prompt在"评估具体题目"时，可以引用一到两条知识库中的参考标准作为"锚点"，输出更有针对性的结论。

这里有一个我在实践中调过多次的参数：知识库召回条数。一开始召回太多，一次注入5条到Prompt里，结果模型在评估时大量引用知识库内容，反而忽略了回答本身的证据，输出显得很"教条"。后来降到了2条，效果明显改善。核心原因是评估任务本身需要模型聚焦在回答文本的证据上，外部参考材料只是辅助，不能喧宾夺主。

4.4 Prompt模板的最终形态（简化版）

下面是评估节点Prompt的核心骨架。实际生产版本比这个长很多，这里保留最关键的逻辑结构：

你是一名面试复盘顾问。用户将给你一个面试中的问题和候选人的回答，请从四个维度评估回答质量。 问题：{{question}} 回答：{{answer}} 问题类型：{{question_type}} 评估要求： 1. 结构维度：回答是否包含清晰的叙述框架（如背景-行动-结果），框架是否完整。 2. 相关维度：回答是否直接回应了问题，是否出现明显跑题。 3. 深度维度：回答是否触及了问题的本质，是否展示了深入思考或专业深度。 4. 证据维度：回答是否用具体数据、事实、案例支撑结论，还是停留在模糊描述。 输出格式（JSON）： - structure_score: 0-100整数 - relevance_score: 0-100整数 - depth_score: 0-100整数 - evidence_score: 0-100整数 - each维度需附一段简短理由（一句话），理由必须引用回答中的原文证据 - improvement_suggestion: 一段不超过150字的改进建议，必须给出具体的重构方向 参考标准（如果检索到知识库内容，则附加在此处）： {{knowledge_retrieval_result}}

这个模板的关键设计有三个：一是每个维度的定义都绑定到回答中可以观察的特征（框架、跑题、深度、数据），而不是抽象的"好"与"不好"；二是维度理由必须引用原文证据，这意味着模型不能输出unfounded的评价；三是改进建议必须给出"重构方向"而不是"努力方向"——"建议补充背景中的约束条件和备选方案的取舍依据"是好的建议，"注意加强逻辑性"是坏的建议。

5. 实测效果：用hindsight复盘了7场真实面试之后

5.1 测试配置与样本说明

hindsight跑完第一版之后，我做了一个为期两周的真实测试，收集了7场模拟面试的录音进行分析。测试对象是在校生和工作一年内的候选人，岗位方向集中在后端开发和产品运营两个类别。每场面试时长30-50分钟，转写文本字数在3000-8000字之间。

测试用的模型配置是：信息抽取节点用快速模型，评估和报告节点用更强推理能力的模型。知识库中已导入2份目标岗位JD、5份优秀回答示例。以下是这次测试中比较有代表性的一些发现。

5.2 哪些评估维度真正有效

先把结论放在前面：结构维度、证据维度、追问分析，是本项目中最有价值的三类输出。

结构维度有效是因为它几乎总能给出准确的诊断。测试中，被判定"框架不完整"的回答，回听录音时我（作为模拟面试官）的感受高度一致——候选人确实讲了很多细节但没有收拢结论，或者只给了结论但过程缺失。这个维度的评估置信度很高。

证据维度有效体现在它能指出用户自己意识不到的习惯，比如"全程没有出现一个具体数字"。不少候选人在模拟面试时自评"讲得还挺具体的"，但hindsight的证据维度评分只有40多分，把逐字稿里"很多""挺大""大幅提升"一类的模糊表述列出来之后，候选人才意识到自己的具体性认知存在偏差。

追问分析的有效性来自它的"信号"属性。它统计和分类了面试官的追问后，测试用户可以清楚地看到一个扎心的事实：大部分追问都集中在自己当初觉得讲得不错的段落上。这种"自评和追问行为不一致"的发现，是普通复盘完全无法提供的。

5.3 几个值得警惕的特征：AI评分的偏差模式

测试过程中也发现了评分偏差问题，目前还没有完全解决，先把现象记录下来。

偏差一：语言流畅度对评分的"污染"效应。同一道题，一个表达流利但内容空泛的回答，和一个频繁停顿但内容扎实的回答，前者的结构化得分往往会偏高。这个偏差目前只能通过Prompt里强调"评估内容而非表达流畅度"来缓解，但无法彻底消除。

偏差二：技术深度类题目容易出现"模型自慰"式打分。这个问题很有意思：当模型自身的知识储备不足以判断候选人技术回答的准确性时，它会倾向于用"回答是否完整、是否有结构"来替代"内容是否正确"。也就是说，深度维度在纯技术题目上的可信度要打折扣。我的缓解方式是，在知识库里增加技术类题目的"参考答案"文档，用参考资料来约束模型的判断，但这个方案对特别专业的技术问题仍然力不从心。

偏差三：多轮对话场景下的上下文遗忘。在面试后段，模型偶尔会忘记前面出现过的项目背景，导致同一份技术栈信息在不同题目里的评估不一致。这个问题我放在第六节的踩坑部分详细说。

5.4 用户侧的实际反馈

测试结束后，我收回了一份简短的反馈问卷，几类典型反馈形成了这个项目后续迭代方向的主要证据：

• "报告里说我在项目介绍中缺少量化指标，这个我回去听了录音，确实是这样。"
• "追问分析那段让我很意外，原来面试官追问了我三次的地方，真的是我讲得最模糊的地方。"
• "改进建议如果能更具体一些，最好能给出示例回答的参考话术，会更实用。"

第三类反馈直接推动了后续迭代的一个重要功能方向：在逐题解析中加入"参考回答重构"，也就是针对同一道题，基于候选人已有的回答素材生成一个思路更完整的重构版本。这个功能目前还在开发中，我预期它能进一步提升复盘报告的实用价值。

6. 踩坑记录：半年迭代中处理过的五个典型问题

6.1 转写文本的专业术语识别问题

最开始的测试里，技术面试的转写文本经常把"Kubernetes"转成"酷波奶次"，把"Redis"转成"瑞迪斯"。这类错误对信息抽取节点的影响不大，因为模型通常能从上下文中猜出术语含义，但对"证据引用"环节是致命的——报告里引用原文时会出现让人啼笑皆非的错误术语，拉低整个报告的可信度。

处理方案是在工作流里加了一个术语清洗节点：内置一份常见技术术语的正确写法列表，把转写文本中匹配错误的词替换为正确写法。这个节点用代码写了一个简单的字符串替换逻辑，清洗表持续补充。实测下来，常见的高频术语错误能解决八成以上，冷门的长尾术语仍然要靠用户的反馈来累积。

6.2 上下文过长导致评估漂移

Workflow节点对单次Prompt的长度是有限制的，把整个面试逐字稿一次性塞进一个评估节点会导致两种情况：一是超出上下文长度，直接报错；二是虽然没超限，但模型会"抓大放小"——只注意面试中段的若干片段，前10分钟和后20分钟的内容被平均掉，导致同一场面试里前后回答的评估风格不一致。这就是我在5.3节提到的上下文遗忘问题在架构层面的根源。

最后采取的方案是：把评估节点做成"逐题评估"，每个节点调用只处理一道题的"问题+回答"，不携带全文上下文。这样模型在每一道题上的注意力都是集中的，不再有长文本导致的注意力衰减。代价是上下文关联信息丢失了一部分，但通过方法1中提到的"粗切分+漂移标注"来补偿。

6.3 知识库内容与Prompt打架导致评估逻辑不一致

有一次我更新了知识库里的优秀回答示例，结果第二天所有评估报告中的结构维度分数普遍下降了5分左右。排查之后发现，新导入的示例回答框架比旧版详细很多，模型在处理普通回答时，会不自觉地将候选人的回答与知识库里的"理想回答"进行对比，标准被提高了，分就降下来了。

这个问题的根源是：知识库的检索结果会直接注入评估Prompt，作为参考标准。我最终的做法是，在Prompt中对知识库内容的角色做了明确限定：知识库仅用于"补充背景信息"和"提供建议方向"，不允许作为评分尺度的依据。评分只依据维度定义本身。这样知识库依然是有用的——它让建议更具体，但不会绑架评分尺度。

6.4 多轮追问的前文丢失问题

有一段面试出现了这样的情况：面试官问了候选人一个OpenAPI设计问题，候选人回答中提到了"幂等性"，面试官接着追问"你设计这个幂等方案的时候怎么处理重试的？"。按问题抽取节点的逻辑，面试官的追问会被识别为新问题，它的回答会被切分出来单独评估。但单独评估时，评估节点拿到的上下文里只有"你设计这个幂等方案的时候怎么处理重试的？"和候选人的回答，完全丢失了前一问答中关于幂等方案的背景。

这种追问导致"上下文断链"在真实的面试中非常普遍，处理不好会让复盘报告出现"这份回答没头没尾"的错误结论。我的处理方案是在抽取追问时做回溯：如果当前问题被判定为追问类问题，除了当前的提问文本，把上一道题的"问题+回答摘要"也一起作为上下文传给评估节点，让模型知道追问是针对什么内容发的。

6.5 幻觉数据：AI会编造面试官没说过的问题

这是所有LLM应用都会面临的顽疾，在hindsight里它有一个特殊的呈现形式：报告中出现面试官从未提到过的"问题"。有一次测试报告里出现了一道"你对这个岗位的职业规划是什么？"，但回听录音，面试官原话是"你对未来的三到五年有什么打算吗？"——语义相近但表述不同，模型在抽取时进行了语义改写。

一开始我觉得这没什么问题，但后来意识到，这会让报告中的"原文引用"环节失真，用户如果基于转述查找原文，会找不到对应出处。最终的方案是：在抽取问题时强制要求模型必须输出完整原文，禁止改写，即使原文存在语气词或语法瑕疵也照原样输出。这个约束牺牲了一部分整洁度，但保住了"结论可追溯"这条底线。

这是一个很小的改动，但它的影响是深远的。因为它意味着hindsight生成的每一句话都能被勾回录音原文，用户可以在任何时候验证报告的真实性。产品上线到现在，"报告不可信"这个质疑出现的频次接近于零，很大程度上就得益于这个细节。

7. 后续扩展方向与我的个人体会

项目走到现在，hindsight已经从一个原型变成了一个我日常愿意使用的工具。它远不是一个成熟商业产品的形态，但已经证明了"Dify+LLM应用"解决过程分析类需求的可行性。我目前正在做的扩展方向有两个：一个是语音特征分析——把候选人的停顿频率、语速变化、语气词密度和回答内容结合起来，形成更立体的表现画像；另一个是面试官风格分层——根据面试官提问方式和追问习惯，区分"压力型面试官"和"引导型面试官"，帮助用户理解不同的面试互动模式。

我个人在实际操作中最深的体会是：这一类"分析型LLM应用"的成败，不取决于模型选得多强，而取决于你是否能把"评估标准"定义得足够清晰。模型天然会给出平均但模糊的评价，你需要用Prompt设计、知识库约束、结构化的输出格式，把它逼到一个具体的、证据导向的轨道上，产出的内容才有真正的参考价值。

最后分享一个小技巧。如果你也想做分析类工具，先不要急着搭复杂的工作流，拿一个原始Prompt加一段真实数据先跑一遍人工评估，看看输出哪里不对，再决定做什么任务拆解。我在做hindsight早期就吃了这个亏——一开始就把工作流拆了七八个节点，结果瓶颈根本不在架构，而在Prompt本身的评估逻辑没想清楚。先用最笨的方法跑通端到端，再回头优化工程结构，这个顺序能省掉一大半的返工时间。