去年年底我开始折腾一个叫“hindsight”的个人项目起因很朴素我的团队每个月做项目复盘但每次复盘会都开得像追悼会——大家凭记忆你一言我一语最后纪要写了一大堆下次该踩的坑一个没少踩。我觉得这事不对复盘的意义在于“后见之明”但大多数人根本没把“后见之明”变成“可复用的经验”。后来我在 Dify 平台上把这个想法落地成了一个 AI Agent专门做结构化的复盘反思、失败归因和经验沉淀。这篇文章就把这个项目的完整设计思路、实现过程、踩坑记录全部拆开揉碎了讲清楚适合正在做 Agent 应用、知识库 RAG、或者对 AI 辅助团队协作感兴趣的朋友参考。先啰嗦一句背景为什么这事儿值得做。当时我面临三个痛点第一复盘材料散落在飞书文档、聊天记录、项目周报里想查一个历史决策的上下文翻半天都翻不全第二复盘输出全靠个人自觉写得好不好、全不全面看心情缺乏统一的结构化模板第三复盘结果和实际执行脱节总结完就完了没有形成可检索、可关联、可复用的知识资产。所以我在想能不能用大模型 知识库做一个智能复盘助手让它接手“整理历史信息、关联相似经验、输出结构化复盘、给出改进措施”这套流程。这就是“hindsight”项目的起点。1. 项目整体设计与思路拆解1.1 “hindsight”到底是什么从定位上看“hindsight”是一个基于大语言模型和 RAG 检索增强生成的知识型 Agent跑在 Dify 平台上。它的核心功能是你给一段项目原始记录比如一段会议纪要、几行失败经过、一个事故报告它会先检索你沉淀好的私有知识库把历史上类似的项目、相近的问题、之前总结过的经验捞出来然后按照一套固定的复盘框架生成结构化输出——“目标是什么、实际结果是怎样、偏差在哪里、根因是什么、下次要怎么改”。为什么叫“hindsight”因为这个词的本义就是“事后洞察”。我们做复盘本质上就是在用事后视角重新解读当时的信息和决策而大模型最擅长的恰恰就是“给一段混乱的信息让它按某种逻辑重述”。但是单纯用大模型做这件事有一个致命缺陷它只能靠训练时的通用知识来发挥不了解你团队的具体语境也不知道你上个季度踩过的那个坑的细节。所以必须把 RAG 加上——让 Agent 在生成之前先从你自建的知识库中检索相关历史经验作为上下文注入。这一下就把一个“泛泛而谈的 AI 顾问”变成“懂你们团队历史的 AI 复盘助手”。从适用场景来说这个项目可以服务三类需求个人知识管理场景比如整理自己的周记、日记、失败笔记让 AI 帮你找出反复出现的思维盲区团队协作场景比如复盘会议前置准备让 AI 先把历史资料梳理好会上直接聚焦讨论内容创作场景比如写经验分享文章时让 AI 帮你从历年材料中提取有共鸣的案例。我目前深耕的是第二种场景但设计架构时考虑了通用性。1.2 为什么选 Dify 而不是自己搭应用选型这件事我犹豫了挺久。最初想的是直接调 OpenAI API LangChain 自己写一套但评估完工作量之后放弃了。因为我需要的不是一个技术 Demo而是一个团队里非技术人员也能上手维护的长期工具。自研框架意味着要有人一直维护、要处理数据库、要写管理后台、要管模型密钥——这些都是隐形成本。Dify 打动我的点在于它把“应用编排、知识库管理、模型管理、日志追踪”都集成好了。尤其是可视化的工作流编排我可以把“检索历史 → 生成复盘 → 结构化输出 → 提取待办”这些节点拖拽连接起来改逻辑不需要重新部署直接在画布上调整即可。这对一个以内容沉淀为目标的项目来说是压倒性的优势。另一个考虑是数据隐私和部署形态。Dify 是开源的可以社区版自托管部署到内网我们的项目资料、复盘记录不会经过第三方平台这对企业内部敏感信息来说非常重要。而且 Dify 的知识库支持多种向量检索方案包括内置的向量数据库也支持接入外部向量库如 Weaviate、Qdrant扩展空间很大。当然 Dify 也不是没有缺点后面我会专门讲几个实际踩到的坑但整体上选它作为落地平台是性价比最高的方案。1.3 整体架构与核心链路整个项目的架构可以拆分五个核心组件链路是“输入 → 预处理 → 检索 → 生成 → 落库”。第一环是输入源管理。我接入了两种输入方式手动输入直接在对话窗口粘贴项目复盘素材和文件上传支持 Markdown、TXT、PDF 格式的过程文档。第二种方式主要给团队里习惯写长文档的同事用。第二环是知识库构建。我用 Dify 的知识库模块建了三个独立的库历史项目复盘库存放过去所有项目的复盘记录、最佳实践库存放团队总结出的做事方法论、行业资料库存放外部收集的相关案例。三个库分开建的原因后续细讲现在先记住这个划分。第三环是 Agent 工作流。这是整个应用的“大脑”包含“意图识别 → 知识检索 → 生成反思 → 输出结构化报告 → 提取后续动作”五个节点。这里需要说明的是Dify 的工作流分两种模式简单编排适合直接问答和高级编排支持多节点串联我这个项目用的是高级编排。第四环是模型层。我同时配置了多个模型快速响应模型用于意图识别和轻量处理、深度推理模型用于根因分析和反思生成。用不同模型跑不同节点的原因是成本和响应速度的权衡后面我会给出实测对比数据。第五环是输出和复盘报告落库。Agent 生成的复盘报告通过 HTTP 请求节点写入我部署的 PostgreSQL 数据库同时生成一份 Markdown 文件归档到网盘目录方便团队成员随时查阅。整个链路设计思路的核心有两条一知识库与生成模型解耦保证任何一次生成都有可追溯的资料支撑二流程节点可插拔未来想加入“情绪分析”“风险预测”等功能直接在画布里加节点就行不用动底层代码。2. 核心细节解析与实操要点2.1 复盘提示词决定输出质量的命门这个项目最核心的“软细节”就是提示词设计。我试过很多版本踩过不少坑最后沉淀下来一套还算稳定的复盘提示词框架分享出来供参考。先看我的核心 System Prompt你是一名资深的项目复盘顾问擅长用“目标—结果—偏差—归因—改进”五段式框架分析项目执行过程。 你的任务是基于用户输入的原始项目资料结合知识库检索到的历史经验输出一份高质量的复盘报告。 要求如下 1. 先复述原始输入中的核心目标和关键事件确保信息理解准确 2. 对比实际结果与原始目标找出关键偏差点 3. 对每个偏差点进行根因分析从“流程设计、执行能力、外部依赖、信息判断”四个维度排查 4. 归因必须区分“可控因素”和“不可控因素”可控因素给出具体改进措施不可控因素给出应对预案 5. 检索知识库中与此项目相似的历史案例用“此前遇到过类似问题当时的处理方式是……”的格式关联引用 6. 输出必须严谨客观避免责任归咎和个人情绪 7. 最终输出一份结构化报告包含以下部分 - 项目摘要 - 目标回顾 - 结果与偏差分析 - 根因分析 - 历史经验关联 - 改进措施按优先级排序 - 待办事项列表这个提示词经历了三个迭代版本。第一版太笼统只说“请帮我复盘以下项目”结果输出大量正确的废话比如“建议加强团队沟通”这种没有执行力的内容。第二版引入了“可控/不可控”分析维度质量明显改善但历史经验关联做得很差因为当时知识库还没接通。第三版加上了检索指令和四维度归因框架才达到现在这个效果。一个重要心得提示词里每一条指令都要对应一个“可验证的输出”。比如“从流程设计、执行能力、外部依赖、信息判断四个维度排查”这就是强制 Agent 在每个偏差点都输出四个子项你一眼就能看出它有没有在糊弄。“历史经验关联”这条指令也同理如果你没有给它明确的知识库检索入口它要么编造案例要么说“知识库中没有相关内容”——实际测试中加了明确的检索指令后相关内容关联率从 22% 提升到了 76%。2.2 知识库构建历史经验的质量比数量重要知识库是“hindsight”的另一个支柱但很多人会把知识库当成垃圾桶什么都往里扔结果检索出来的内容杂音极大反而拉低了生成质量。我最终用的是三分库策略每个库独立管理、独立设置检索参数。第一个库叫“历史复盘库”存放的是历次项目复盘的结构化报告。这类文档的格式相对统一所以我把分段长度设为 500 字重叠区设为 50 字检索权重侧重“语义相似度”。这个库解决的核心问题是“我们以前有没有遇到过类似的问题当时是怎么处理的”。第二个库叫“最佳实践库”存放的是团队归纳的方法论、操作手册、流程规范比如《需求评审检查清单》《事故应急流程 V2》这类文档。这类文档的价值在于事前的预防所以分段长度设为 300 字重叠区设为 30 字保证每条知识的粒度足够细、便于精确匹配。第三个库叫“行业案例库”存放外部资料比如行业报告、论文摘录、优秀团队的公开复盘文章等。这些资料往往篇幅长、信息密度大分段长度我用的是 800 字重叠区 100 字检索权重偏“全文关键词匹配”。知识库构建中有一个特别容易忽视的细节你要给每个知识库设置不同的索引权重和检索阈值。Dify 默认的相似度阈值是 0.2这个值太低了会导致很多语义上沾边但实际不相关的段落被捞出来当作“经验依据”生成报告时就会出现“牛头不对马嘴”的引用。我实测后把历史复盘库的阈值设为 0.42最佳实践库设为 0.50行业案例库设为 0.36效果改善非常明显。另一个细节是文档预处理。我最初直接把原始周报扔进知识库结果因为格式混乱、含大量表格和图片链接解析质量很差。后来我写了一个简单的预处理脚本把所有文档统一转成 Markdown 格式删除无关的表格样式和链接只保留正文文本再按章节结构拆分上传。处理后检索准确率有了质的提升。2.3 Agent 工作流编排每一环都要有容错设计Dify 的高级编排工作流可以看作一个可视化管道你需要设计每一个节点以及它们之间的连线。我的工作流分为七个节点第一是“输入节点”接收用户的原始素材。这里需要注意的是用户输入的内容可能很长超出模型上下文限制所以我加了一个判空逻辑——如果输入为空或者少于 20 个字直接提示用户补充信息不走后续流程。第二是“意图识别节点”用快速模型判断用户输入属于“复盘请求”“资料补充”“查询历史”还是“闲聊”。这个节点看起来简单但价值很大它避免了用户不小心发一句“好的”就触发整套复盘流程白白消耗一次生成的费用和时间。第三是“知识检索节点”这是整个链路的枢纽。它同时查询三个知识库并对每个库设置不同的 topK 值。历史复盘库我设为 4最佳实践库设为 3行业案例库设为 2。检索结果会在后续节点里以“[引用资料]”的格式注入提示词上下文。第四是“生成复盘节点”使用深度推理模型。这里有一个关键设计该节点的输入不仅包含用户原始素材和知识库检索结果还包含了“意图识别节点”输出的意图类型不同类型调用不同的复盘模板。如果意图是“项目复盘”用五段式完整框架如果是“事故分析”则调整为“时间线还原 直接原因 根本原因 应急措施 长期对策”的模板。第五是“结构化提取节点”用来从生成内容中提取待办事项、责任人和优先级。这个我用的是函数调用方式让模型返回 JSON 格式的待办列表。第六是“落库节点”通过 HTTP 请求把复盘报告和待办列表写入外部数据库。第七是“输出节点”把最终报告推给用户同时附带一个下载链接。整个工作流的容错设计有两个要点。第一每个节点都加了错误处理分支比如知识检索节点超时或返回空结果时会走“无检索结果提示语”分支而不是直接报错中断。第二深度推理模型偶尔会出现输出格式不合规的情况导致结构化提取节点失败我为此增加了一个重新生成逻辑——如果提取结果校验失败自动回退到“直接透传原文”模式保证用户至少能看到完整报告不会白等。3. 实操过程与核心环节实现3.1 从零搭建 hindsight Agent 的具体步骤接下来是最干的干货部分。如果你也想复刻一个类似的 Agent可以直接照着下面的步骤走。我以 Dify 社区版 Docker 部署为例整个过程大约需要两三个小时。第一步是部署 Dify 平台。官方仓库提供了 docker-compose.yml直接拉代码后在项目根目录执行git clone https://github.com/langgenius/dify.git cd dify docker compose up -d启动完成后浏览器访问 http://localhost/install 配置管理员账号。这里要注意的是Dify 依赖多个组件同时启动首次启动可能需要等待 2-3 分钟如果某个容器启动失败可以通过docker compose logs查看具体日志。我踩过的一个坑是服务器内存不足——Dify 全家桶跑起来要占差不多 4GB 内存如果你用的是 2GB 的小机器需要提前加 swap 或者在配置中裁剪掉不必要的组件。第二步是添加模型供应商。我主要用的是 OpenAI 的 GPT-4o 和 GPT-4o mini 各一个。在 Dify “设置 → 模型供应商”中填入 API Key然后在“模型”页面分别配置深度推理模型gpt-4o temperature 设为 0.2这是为了减少生成的随机性保证复盘报告的稳定性快速响应模型gpt-4o-mini temperature 设为 0.1用于意图识别和轻量处理。如果你有开源模型部署需求Dify 也支持接入 Ollama、Xinference 等本地推理服务不过对生成质量要求较高的场景商业模型依然是首选。后面我会给出一组实测对比数据说明模型选型对输出质量的影响有多大。第三步是创建知识库。在 Dify “知识库”模块新建三个库分别命名为“历史复盘库”“最佳实践库”“行业案例库”上传对应文档。上传时注意选择分块模式为“自定义分段”并按照我前面提到的参数进行设置——历史复盘库 500 字/50 字重叠最佳实践库 300 字/30 字重叠行业案例库 800 字/100 字重叠。上传完成后先运行一次“召回测试”在知识库的检索测试界面输入几个历史项目的关键词检查返回的段落是否与预期相关。这个环节非常建议做因为你后续 Agent 生成质量完全取决于这一步效果。我最初上传文档后没测试结果生成报告引用了完全不相关的段落排查了好久才发现是分段参数设置不合理。第四步是创建工作流。在 Dify“工作室”中新建“Chatflow”类型应用从模板左侧拖出各个节点按我前面提到的七节点链路进行连接。对于只熟悉低代码操作的人来说这个环节可能需要一些时间适应但 Dify 的画布交互做得比较直观拖拽、连线、配置参数三步即可完成一个节点。配置“生成复盘节点”的提示词时用我前面贴的 System Prompt 模板即可需要微调的话建议保留“四维度归因”和“历史经验关联”两条核心指令。第五步是配置外部数据库和落库逻辑。如果你不需要把复盘结果持久化这一步可以跳过。如果需要可以通过 Website API 或自定义工具节点实现。我这里用的是 Dify 的“HTTP 请求”节点目标地址是我部署的一个小型 Node.js 接口接收 JSON 格式的复盘报告和待办列表写入 PostgreSQL 数据库。第六步是发布与测试。工作流配置完成后先发布为“草稿”状态用几组真实项目资料做端到端测试。建议准备至少三组测试数据一组是成功项目一组是失败项目一组是信息不全的短文本分别验证 Agent 在不同输入下的表现。发布正式版本后可以在 Dify 的“访问 API”页面获得 API 密钥接入你的内部系统或聊天工具。3.2 关键配置参数速查表我把整个项目中最关键的参数汇总成一个速查表方便你对照检查配置项推荐值说明深度推理模型gpt-4otemperature 0.2用于生成复盘报告温度低保证稳定性快速响应模型gpt-4o-minitemperature 0.1用于意图识别响应快成本低知识库分段长度复盘库500 字适合结构化工整的复盘文档知识库分段重叠复盘库50 字保证跨段上下文的连续性知识库分段长度实践库300 字适合理知识粒度高的文档知识库分段长度案例库800 字适合外部长文资料相似度阈值复盘库0.42根据测试集微调相似度阈值实践库0.50严格控制无关内容混入相似度阈值案例库0.36外库可适当放宽检索 TopK复盘库4每个库独立设置检索 TopK实践库3保证精确匹配检索 TopK案例库2避免喧宾夺主单轮最大回复 token2000复盘报告较长需足够容量失败重试次数2应对模型超时等情况值得强调的是这些参数不是拍脑袋定的而是基于我测试集上的对比实验调出来的。比如相似度阈值我先用一套标注过的“相关/不相关”问答对在 0.2 到 0.6 之间按 0.02 的步长扫描选择 F1 分数最高的点。这个方法可以复现建议你在自己的语料上也跑一遍不要直接照搬我的值——因为不同领域文档的语义分布差异很大阈值选择高度依赖语料特征。3.3 一次完整的复盘流程演示为了让你更直观地理解整个系统我用一个脱敏后的真实项目记录做一次完整演示。假设原始输入材料是一段 500 字的项目记录内容大致是“智能客服项目原定 5 月底上线但实际推迟到 7 月 15 日才发布。推迟的主要原因是语音识别模块供应商接口变更导致联调工作比预期复杂期间客服部门多次催促研发资源出现争抢最终上线后首月满意度达标但转人工率比预期高出 8 个百分点。”用户把这端文本粘贴到对话框点击发送。Agent 的处理过程如下第一步意图识别节点用 gpt-4o-mini 快速判断这是“项目复盘”请求置信度 98%。第二步知识检索节点并行查询三个库。历史复盘库返回三个历史项目一个是去年 4 月上线的电商推荐项目遇到过类似的第三方接口变更问题一个是前年的语音机器人项目有转人工率异常的详细分析还有一个是今年初的支付项目没有明显相关性但相似度勉强超过阈值。最佳实践库返回两条资料包括《三方服务接口变更应对流程》和《客服指标异常排查手册》。行业案例库返回一篇关于客服系统容灾设计的公开文章片段相关性一般。第三步生成复盘节点接到检索结果后按照提示词中的五段式框架输出一份完整报告。报告中“历史经验关联”部分明确写道“此项目中语音模块接口变更导致的联调延误与历史项目‘电商推荐项目’中第三方推荐引擎接口下线问题高度相似。当时团队的处理方式是提前两周启动替代方案评估并建立了供应商直接对接通道最终将影响时间压缩在 5 个工作日内。本轮建议参考此经验在下一次项目排期预研阶段加入供应商接口变更风险清单。”第四步结构化提取节点从报告中提取待办事项“在项目预研阶段建立第三方接口变更风险清单责任人架构组小李优先级高建立客服转人工率异常预警机制责任人产品组小王优先级中。”整个过程大约耗时 18 秒。用户收到的是一份层次清晰的复盘报告而不是一大段混沌的文字。实测中这版报告团队成员普遍认为“够专业可以直接用”这正是我设计这个项目时最想达到的效果。4. 常见问题与排查技巧实录4.1 知识库检索质量差八成是分段和阈值的问题上线初期我最头疼的问题就是“检索召回了一堆不相关内容”。当时检查的方向有三个是不是文档本身格式太乱是不是分段参数不合理是不是相似度阈值太低首先自查文档格式。我把原始文档打开看了一遍发现很多是从 Notion 导出的 HTML 格式里面夹杂着大量空行、图片标签和导航菜单文字。Dify 的解析器虽然能识别 HTML但对导航信息和正文不加区分地全部收录了。解决方案是写脚本统一转 Markdown把无关内容剔除后在整体上传。接着排查分段参数。我用的是 Dify 内置的分段方式默认是“自动分段”它会把文章按段落拆分成不定长的小块。这个模式在信息密度较低的对话类文档上效果可以但对技术文档类的内容不适用——很多技术文档的关键信息都集中在一两个长段里自动分段经常把它们拆得七零八落检索时只命中其中一部分导致上下文不完整。改成按固定长度分段并设置合适重叠区之后检索完整性明显提升。最后调整相似度阈值。Dify 的检索结果会给出每条结果的相似度分数我跑了一遍测试集发现大量不相关的段落分数集中在 0.2-0.35 之间而真正相关的段落普遍在 0.4 以上。于是我把各库的阈值分别上调到 0.36-0.5 之间无效召回率从 41% 降到 12%。需要注意的是阈值太高也会误伤正确结果需要在精确率和召回率之间做平衡。4.2 Agent 输出经常“自由发挥”不按模板走这个问题在接入知识库之后出现过一段时间的“复发”。现象是明明 System Prompt 里要求按固定框架输出但偶尔几份报告会漏掉某一节或者把所有内容都压缩成一大段。排查后定位到两个原因。第一用户的输入很长时模型可能被原始素材中的叙述逻辑带跑偏尤其是当输入材料本身就有极强的叙事性时模型会倾向于模仿这种风格而不是执行 System Prompt 里的结构化指令。解决方案是把结构化要求从 System Prompt 中搬到用户输入前的额外处理中用模板化的前缀提示强化约束比如在用户输入前加一句“请严格按照以下章节输出项目摘要 / 目标回顾 / 结果与偏差分析 / 根因分析 / 历史经验关联 / 改进措施 / 待办事项”。第二部分模型对指令中的“输出必须采用 Markdown 格式用二级标题分隔各章节”理解得不够稳定。后来我改为不强依赖模型自觉而是在生成后加一个结构化提取节点用函数调用方式让模型返回 JSON 格式的数据再由前端渲染成固定模板。这个方法生效后输出格式的稳定性基本达到了 95% 以上。4.3 模型选型与成本控制的实测对比最后排一下模型选择的实测数据。我在同样的提示词和知识库设置下用 GPT-4o、GPT-4o mini、以及一个开源模型安装的是 Qwen2-72B 的量化版各跑了 20 组测试数据。从生成质量上看GPT-4o 的结构化程度最高几乎每个测试样本都能输出严格的五段式框架且归因分析具体有依据很少出现空话套话GPT-4o mini 能完成基本的框架但深度不足根因分析部分经常是比较浅显的“沟通不好”“进度管理不到位”这类描述开源模型则发挥极不稳定有些输出效果接近 GPT-4o有些则在逻辑性和关联性上掉线。从成本上看GPT-4o 大约是 GPT-4o mini 的 15 倍左右对个人项目来说压力较大。所以我做了一个折中方案日常的意图识别和轻量处理全部用 mini只把耗时的“生成复盘报告”环节用 GPT-4o。这样整体成本降低了 60% 左右而关键输出质量没有明显下降。还有一个省钱技巧是我后来才发现的对知识库检索结果做“相关性预筛”在生成环节之前把不相关的检索段落剔除掉。这个直接减少了大模型处理的 token 数量因为生成节点的输入中检索到的相关段落往往占了 70% 以上的 token 开销。我现在让检索节点先返回每个库的 top 10 结果再用一个快速模型做二次过滤只保留 top N 条最高质量的再送入生成环节。4.4 易被忽视的日常维护细节会话记忆与知识库增量更新这个项目跑通后我日常维护发现两个细节非常影响长期使用体验。第一个是会话记忆管理。Dify 默认会把前几轮对话作为上下文传给模型这在连续补充资料时很好用——用户先发一段项目记录Agent 生成了报告初稿用户接着补充一条背景信息Agent 能在原报告基础之上更新而不是重新生成。但副作用是如果对话轮次多了上下文占用膨胀。我建议给“生成复盘节点”明确设置上下文轮数Dify 中可以配置最多携带几轮对话历史。对于复盘这类长文本生成任务我会限制只把用户输入和系统提示作为上下文避免历史对话干扰生成质量。第二个是知识库增量维护。复盘最关键的价值在“复用”如果你的知识库一直不更新Agent 总是引用半年前的旧经验价值会逐日递减。我养成了一个固定习惯每次复盘报告生成后经过人工确认没有问题就把它加入历史复盘库。这个动作可以用 Dify 的 API 接口自动化完成报告落库的同时自动写入知识库。另外还要定期清理知识库里的失效内容比如某些过时的流程文档如果不清理检索结果就会拿过时的经验指导新的项目造成反向误导。写在最后的个人体会我在实际使用中发现“hindsight”这个项目真正解决的并不是“生成一篇复盘报告”这个问题本身。报告只是表象它背后代表的是一种把“事后经验”转变为“事前能力”的机制。以前我们复盘靠的是老员工个人记忆人走了经验就带走了现在经验沉淀在知识库里任何人面对新项目时都能先问一句“之前有没有遇到过类似的”。这种改变带来的红利是长期的它的价值会随着知识库的积累越来越大。还有一个体会是任何 AI 产品前期最大的投入一定不是写代码、调模型而是梳理业务逻辑。我花了两三天时间做提示词和流程设计但知识库的整理和清洗花了两周。别嫌这个过程繁琐AI 的能力上限往往不在模型而在你喂给它的信息的质量——垃圾进垃圾出。如果你也想搞一个类似的 Agent 项目我的建议是把验收标准定得具体一点。不要只满足于“输出看起来不错”而是要问“这份报告能直接指导动作吗”“待办事项能分给具体的人吗”“下次遇到类似问题能搜得到这条经验吗”。三个问题都能答“是”这才算是一个真正能落地的“后见之明”项目。