# FDE Fieldnotes · 企业 AI 落地案例库 123条完整结构化案例及研究，版本2026-09-23。 公开披露不等于独立核验，实施建议不等于客户实录。 --- # 匿名德国零部件企业｜老师傅经验传承 / 新人培训 - ID：datawhale-001 - 行业：制造与工业 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：已落地/持续迭代 - 独立核验：未记录 ## 业务问题 关键工艺与故障处理经验主要存在于资深员工脑中，新人遇到问题高度依赖找老师傅。 ## 解决方案 FDE先跟岗观察培训与现场处理流程，再把隐性经验、SOP和历史案例组织成可检索知识，并嵌入新人实际工作场景。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 AI负责检索与建议；资深员工提供经验、审核高风险建议。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 公开材料强调新人培养与经验沉淀得到改善；未披露统一财务指标。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把“沉淀经验”重新定义为新人高频问题与学习验收；纯访谈不足，改为跟岗观察。 ### 阻力与证据边界 复用原培训平台，陪跑接近两个月。约95%解析、80%以上召回是协商的小范围门槛，不是通用行业标准。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按产品、工艺与异常类型建立留出问题集；追踪新人独立操作时间及师傅介入时长。 研究依据： - [Datawhale FDE案例100｜NO.01 从师徒带教到AI辅助培训：FDE用AI破解制造业经验传承难题](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=7) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Datawhale FDE案例100｜NO.01 从师徒带教到AI辅助培训：FDE用AI破解制造业经验传承难题](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=7) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.01](https://fde100.datawhale.cn/cases/cases-009) - [旧版使用的二次整理或汇总来源](https://finance.sina.com.cn/roll/2026-09-06/doc-iniqxiqt0968091.shtml) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-001", "source": "Datawhale", "company": "匿名德国零部件企业", "industry": "制造业", "scenario": "老师傅经验传承 / 新人培训", "fde": "明确FDE", "problem": "关键工艺与故障处理经验主要存在于资深员工脑中，新人遇到问题高度依赖找老师傅。", "solution": "FDE先跟岗观察培训与现场处理流程，再把隐性经验、SOP和历史案例组织成可检索知识，并嵌入新人实际工作场景。", "human": "AI负责检索与建议；资深员工提供经验、审核高风险建议。", "result": "公开材料强调新人培养与经验沉淀得到改善；未披露统一财务指标。", "maturity": "已落地/持续迭代", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=7", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“老师傅经验传承 / 新人培训”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.01 从师徒带教到AI辅助培训：FDE用AI破解制造业经验传承难题", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=7", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 1, "printed_page": 6, "pdf_page": 7 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.01", "url": "https://fde100.datawhale.cn/cases/cases-009" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://finance.sina.com.cn/roll/2026-09-06/doc-iniqxiqt0968091.shtml" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名工业企业｜工业采购 / 物料定位 - ID：datawhale-002 - 行业：制造与工业 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 SKU与物料体系复杂，采购人员依赖老员工经验定位替代料与正确物料。 ## 解决方案 整合产品资料、历史采购与业务规则，用语义检索和AI辅助物料匹配。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 采购人员确认关键物料与异常替代建议。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 案例聚焦缩短定位时间与减少经验依赖；公开资料未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把找不到物料的问题追到主数据质量与重复采购损失，而不只改进搜索界面。 ### 阻力与证据边界 先选易证明价值的窄场景；业务方必须确认损失计算方式，不能用搜索命中率替代采购收益。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 对同义名称、旧物料号、替代件建立标注集；核对重复采购金额与误匹配造成的成本。 研究依据： - [Datawhale FDE案例100｜NO.08 从物料难找到精准定位：FDE用AI减少工业企业采购浪费](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=77) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Datawhale FDE案例100｜NO.08 从物料难找到精准定位：FDE用AI减少工业企业采购浪费](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=77) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.08](https://fde100.datawhale.cn/cases/cases-024) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-002", "source": "Datawhale", "company": "匿名工业企业", "industry": "制造业", "scenario": "工业采购 / 物料定位", "fde": "明确FDE", "problem": "SKU与物料体系复杂，采购人员依赖老员工经验定位替代料与正确物料。", "solution": "整合产品资料、历史采购与业务规则，用语义检索和AI辅助物料匹配。", "human": "采购人员确认关键物料与异常替代建议。", "result": "案例聚焦缩短定位时间与减少经验依赖；公开资料未披露统一ROI。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=77", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“工业采购 / 物料定位”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.08 从物料难找到精准定位：FDE用AI减少工业企业采购浪费", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=77", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 8, "printed_page": 76, "pdf_page": 77 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.08", "url": "https://fde100.datawhale.cn/cases/cases-024" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名非标制造企业｜售前方案与报价 - ID：datawhale-003 - 行业：制造与工业 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：POC/落地 - 独立核验：未记录 ## 业务问题 售前报价高度依赖工程师理解非标需求并从历史方案中找相似项目。 ## 解决方案 AI读取客户需求，检索历史方案、配置与报价依据，生成方案/报价初稿。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 销售与工程师负责最终技术边界、价格和承诺。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 提升方案初稿产出效率；公开资料未披露精确数值。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 围绕实际可用于报价的结果，串联图纸解析、历史订单、成本及审批。 ### 阻力与证据边界 扫描件、手写符号和非标准图框导致错误；低把握字段先人工校准，小组用真实订单试运行1至2个月。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 比较报价周期、关键尺寸误差与毛利偏差；先由报价负责人签发，保留版本和修订。 研究依据： - [Datawhale FDE案例100｜NO.17 从老师傅报价到AI深度协同：FDE用AI重构非标制造售前链路](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=166) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.17 从老师傅报价到AI深度协同：FDE用AI重构非标制造售前链路](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=166) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.17](https://fde100.datawhale.cn/cases/cases-019) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-003", "source": "Datawhale", "company": "匿名非标制造企业", "industry": "制造业", "scenario": "售前方案与报价", "fde": "明确FDE", "problem": "售前报价高度依赖工程师理解非标需求并从历史方案中找相似项目。", "solution": "AI读取客户需求，检索历史方案、配置与报价依据，生成方案/报价初稿。", "human": "销售与工程师负责最终技术边界、价格和承诺。", "result": "提升方案初稿产出效率；公开资料未披露精确数值。", "maturity": "POC/落地", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=166", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“售前方案与报价”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.17 从老师傅报价到AI深度协同：FDE用AI重构非标制造售前链路", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=166", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 17, "printed_page": 165, "pdf_page": 166 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.17", "url": "https://fde100.datawhale.cn/cases/cases-019" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名工程租赁企业｜长尾需求承接 / 产品匹配 - ID：datawhale-004 - 行业：制造与工业 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：验证中 - 独立核验：未记录 ## 业务问题 大量长尾工程需求依赖人工判断设备与方案，销售承接成本高。 ## 解决方案 用AI理解需求、匹配产品和历史服务方案，降低一线查找与沟通成本。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 业务人员确认高价值订单和非标准方案。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 重点是扩大长尾需求可承接范围；公开材料未给统一指标。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把高价值大客户与标准化长尾询价分开，老板继续处理前者。 ### 阻力与证据边界 价格区间依赖车型、距离、作业和人工成本；复杂或议价不匹配的需求需转人工，不能宣称全自动成交。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 以被承接且可履约的小订单毛利衡量价值，同时统计无效询价和错误报价。 研究依据： - [Datawhale FDE案例100｜NO.23 从老板报价到长尾承接：FDE用AI打通工程租赁获客与报价](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=226) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Datawhale FDE案例100｜NO.23 从老板报价到长尾承接：FDE用AI打通工程租赁获客与报价](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=226) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.23](https://fde100.datawhale.cn/cases/cases-006) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-004", "source": "Datawhale", "company": "匿名工程租赁企业", "industry": "制造业", "scenario": "长尾需求承接 / 产品匹配", "fde": "明确FDE", "problem": "大量长尾工程需求依赖人工判断设备与方案，销售承接成本高。", "solution": "用AI理解需求、匹配产品和历史服务方案，降低一线查找与沟通成本。", "human": "业务人员确认高价值订单和非标准方案。", "result": "重点是扩大长尾需求可承接范围；公开材料未给统一指标。", "maturity": "验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=226", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“长尾需求承接 / 产品匹配”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.23 从老板报价到长尾承接：FDE用AI打通工程租赁获客与报价", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=226", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 23, "printed_page": 225, "pdf_page": 226 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.23", "url": "https://fde100.datawhale.cn/cases/cases-006" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名车管所｜网上业务材料预审 - ID：datawhale-005 - 行业：政务与公共服务 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：已见成效 - 独立核验：未记录 ## 业务问题 网上业务材料需要人工逐项检查，审核慢且重复劳动多。 ## 解决方案 OCR/多模态识别材料，结合业务规则与大模型做预审，并把异常件交给人工。 ## 技术工作流 > 公开信息与编辑推演混合 1. 用户上传证件/申请材料 2. OCR/多模态解析图片与文档 3. 字段标准化并关联业务类型 4. 规则引擎检查硬性条件；LLM辅助理解非标准文本/材料 5. 置信度与异常检测 6. 标准件自动形成预审结果；异常件进入人工队列 7. 人工结论回写异常类型和规则库 组件：OCR/多模态、LLM、规则引擎、置信度路由、审核工作台 ## 人机责任 人工处理低置信度、规则冲突和最终责任事项。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 统计人工审核真正耗时的材料类型和错误类型 - 把“看材料”拆成字段识别、规则判断、语义理解三层 - 优先用规则覆盖确定性要求，用模型处理非结构化理解 - 定义不能自动过的异常和低置信度阈值 - 用单件审核时间、人工介入率和错误率验证PoC ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开二次整理称单次审核从约15分钟降到3–5分钟。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 政务/合规类流程应把硬规则和LLM分开 - 自动化目标不是100%无人，而是让人只看异常件 - 可审计的判断路径比“模型回答得像人”重要 ## 现场决策与研究 ### 为什么这样做 驻场运维暴露了后台看、读、填、搬的重复劳动，AI机会来自现场而非先有需求书。 ### 阻力与证据边界 正常件自动流转，异常人工复核；识别更严格后暴露历史审核尺度差异，尺度必须由业务主管决策。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 分开记录识别准确率、错误放行、人工复核率和端到端办件时间；保留政策版本。 研究依据： - [Datawhale FDE案例100｜NO.02 从人工审材料到自动化办件：FDE用AI提升车管所网办效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=15) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.02 从人工审材料到自动化办件：FDE用AI提升车管所网办效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=15) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.02](https://fde100.datawhale.cn/cases/cases-007) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 中：公开材料披露业务链路与约15分钟→3–5分钟的二次整理指标；具体模型与阈值未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-005", "source": "Datawhale", "company": "匿名车管所", "industry": "政务/公共服务", "scenario": "网上业务材料预审", "fde": "明确FDE", "problem": "网上业务材料需要人工逐项检查，审核慢且重复劳动多。", "solution": "OCR/多模态识别材料，结合业务规则与大模型做预审，并把异常件交给人工。", "human": "人工处理低置信度、规则冲突和最终责任事项。", "result": "公开二次整理称单次审核从约15分钟降到3–5分钟。", "maturity": "已见成效", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=15", "architecture": [ "用户上传证件/申请材料", "OCR/多模态解析图片与文档", "字段标准化并关联业务类型", "规则引擎检查硬性条件；LLM辅助理解非标准文本/材料", "置信度与异常检测", "标准件自动形成预审结果；异常件进入人工队列", "人工结论回写异常类型和规则库" ], "components": [ "OCR/多模态", "LLM", "规则引擎", "置信度路由", "审核工作台" ], "fde_actions": [ "统计人工审核真正耗时的材料类型和错误类型", "把“看材料”拆成字段识别、规则判断、语义理解三层", "优先用规则覆盖确定性要求，用模型处理非结构化理解", "定义不能自动过的异常和低置信度阈值", "用单件审核时间、人工介入率和错误率验证PoC" ], "reusable": [ "政务/合规类流程应把硬规则和LLM分开", "自动化目标不是100%无人，而是让人只看异常件", "可审计的判断路径比“模型回答得像人”重要" ], "evidence": "中：公开材料披露业务链路与约15分钟→3–5分钟的二次整理指标；具体模型与阈值未公开。", "case_summary": "这个案例的关键不是单点使用AI，而是把“网上业务材料预审”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.02 从人工审材料到自动化办件：FDE用AI提升车管所网办效率", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=15", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 2, "printed_page": 14, "pdf_page": 15 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "中：公开材料披露业务链路与约15分钟→3–5分钟的二次整理指标；具体模型与阈值未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.02", "url": "https://fde100.datawhale.cn/cases/cases-007" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # 匿名城市规划机构｜城市规划研判 - ID：datawhale-006 - 行业：政务与公共服务 - 来源：Datawhale - 详细度：概览案例｜作为线索使用（5/12） - 证据：A级｜案例级直接来源 - 部署：验证中 - 独立核验：未记录 ## 业务问题 规划数据、政策、报告分散，人工汇总与研判周期长。 ## 解决方案 汇集多源数据与文档，用AI辅助检索、归纳、研判和报告生成。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 规划专家负责判断、政策解释与正式结论。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 缩短案头分析周期；具体指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 从全市缩到一个具体规划单元的两条流程，保证一文、一图、一表能交付。 ### 阻力与证据边界 精确空间计算交给专业工具；部分节点无法接通时需仍可完成核心交付，避免全链路强依赖。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 用固定地块和规则版本回放；核对坐标、保护线、数据时点与人工签审，而非仅检查报告流畅度。 研究依据： - [Datawhale FDE案例100｜NO.04 从人工研判到智能调度：FDE用AI重构城市规划研判流程](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=34) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Datawhale FDE案例100｜NO.04 从人工研判到智能调度：FDE用AI重构城市规划研判流程](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=34) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.04](https://fde100.datawhale.cn/cases/cases-008) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-006", "source": "Datawhale", "company": "匿名城市规划机构", "industry": "政务/公共服务", "scenario": "城市规划研判", "fde": "明确FDE", "problem": "规划数据、政策、报告分散，人工汇总与研判周期长。", "solution": "汇集多源数据与文档，用AI辅助检索、归纳、研判和报告生成。", "human": "规划专家负责判断、政策解释与正式结论。", "result": "缩短案头分析周期；具体指标未公开。", "maturity": "验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=34", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“城市规划研判”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.04 从人工研判到智能调度：FDE用AI重构城市规划研判流程", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=34", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 4, "printed_page": 33, "pdf_page": 34 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.04", "url": "https://fde100.datawhale.cn/cases/cases-008" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 5, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名消防维保企业｜纸质记录数字化 / 维保报告 - ID：datawhale-007 - 行业：政务与公共服务 - 来源：Datawhale - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 巡检、维保记录大量存在于纸质单据与非结构化材料中。 ## 解决方案 文档识别后结构化入库，再自动生成记录、检索历史问题与辅助报告。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 现场人员确认真实设备状态与异常。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 减少手工录入与文书工作；指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 现场发现政府监管系统无开放接口后，调整原先另建完整平台的方案。 ### 阻力与证据边界 新增系统会造成双重录入；先减少月检表的重复描述，历史异常不能未经核验直接当成本期结果。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 选择一个巡检小组验证净录入时间和重复操作次数，确认监管提交路径仍然可用。 研究依据： - [Datawhale FDE案例100｜NO.13 从纸质流程到数据驱动：FDE用AI推动传统消防维保企业数字化转型](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=129) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Datawhale FDE案例100｜NO.13 从纸质流程到数据驱动：FDE用AI推动传统消防维保企业数字化转型](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=129) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.13](https://fde100.datawhale.cn/cases/cases-011) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-007", "source": "Datawhale", "company": "匿名消防维保企业", "industry": "政务/公共服务", "scenario": "纸质记录数字化 / 维保报告", "fde": "明确FDE", "problem": "巡检、维保记录大量存在于纸质单据与非结构化材料中。", "solution": "文档识别后结构化入库，再自动生成记录、检索历史问题与辅助报告。", "human": "现场人员确认真实设备状态与异常。", "result": "减少手工录入与文书工作；指标未公开。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=129", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“纸质记录数字化 / 维保报告”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.13 从纸质流程到数据驱动：FDE用AI推动传统消防维保企业数字化转型", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=129", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 13, "printed_page": 128, "pdf_page": 129 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.13", "url": "https://fde100.datawhale.cn/cases/cases-011" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名律师团队｜诉讼检索 / 证据梳理 / 文书初稿 - ID：datawhale-008 - 行业：专业服务 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：落地/迭代 - 独立核验：未记录 ## 业务问题 律师大量时间用于检索、整理案卷与重复性初稿工作。 ## 解决方案 搭建面向案件材料与法律资料的检索、证据梳理和文书辅助工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 律师保留事实认定、法律判断和最终签发。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 降低案头工作时间；公开材料未给统一量化效果。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把律师的瓶颈定位到材料处理与案件脉络，而非替代其法律判断。 ### 阻力与证据边界 专家思考框架是系统输入；单个百万字材料的提效实例不能外推到全部案种。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 以证据出处完整性、事实遗漏和律师修改时间验收，设置案件隔离与最终签审。 研究依据： - [Datawhale FDE案例100｜NO.03 从案头工作到智能协作：FDE用AI优化诉讼律师的案件处理能力](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=25) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.03 从案头工作到智能协作：FDE用AI优化诉讼律师的案件处理能力](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=25) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.03](https://fde100.datawhale.cn/cases/cases-001) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-008", "source": "Datawhale", "company": "匿名律师团队", "industry": "法律/专业服务", "scenario": "诉讼检索 / 证据梳理 / 文书初稿", "fde": "明确FDE", "problem": "律师大量时间用于检索、整理案卷与重复性初稿工作。", "solution": "搭建面向案件材料与法律资料的检索、证据梳理和文书辅助工作流。", "human": "律师保留事实认定、法律判断和最终签发。", "result": "降低案头工作时间；公开材料未给统一量化效果。", "maturity": "落地/迭代", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=25", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“诉讼检索 / 证据梳理 / 文书初稿”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "专业服务", "maturity_stage": "未明确", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.03 从案头工作到智能协作：FDE用AI优化诉讼律师的案件处理能力", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=25", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 3, "printed_page": 24, "pdf_page": 25 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.03", "url": "https://fde100.datawhale.cn/cases/cases-001" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 0, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名央国企｜财务流程自动化 - ID：datawhale-009 - 行业：企业运营与其他 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：已落地/规模化 - 独立核验：未记录 ## 业务问题 报销、建单、审核等流程既有语义判断，也有大量重复系统操作，且责任要求高。 ## 解决方案 AI负责信息组织、分类判断与风险识别；RPA/API负责建单、填表和提交；高风险事项升级人工。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务材料/发票/单据/申请 2. OCR/字段抽取 + 业务材料结构化 3. AI识别业务类型、补齐上下文并做初步风险判断 4. 规则/监督逻辑复核：金额、材料完整性、规则冲突、低置信度 5. RPA/API进入ERP/OA完成建单、填表、附件上传、提交 6. 高风险/异常 → 财务人员复核和最终审批 7. 审批结果、异常原因沉淀为后续规则和样例 组件：OCR/文档解析、LLM、规则/监督逻辑、RPA/API、ERP/OA/财务系统、Human-in-the-loop ## 人机责任 人工承担高风险、低置信度和最终审批责任。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗观察真实财务操作，找出员工自己说不清的隐性判断 - 把流程拆成“语义判断 / 机械执行 / 最终责任”三类任务 - 访谈老员工并把经验转成明确规则、例外和升级条件 - 尽量复用原ERP/OA，把AI做成上层intelligence而非重做财务系统 - 从小场景PoC验证，再决定私有部署和算力投入 - 用低置信度和高风险路由设计责任边界 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 形成“AI判断 + RPA执行 + 人终审”的可迁移架构；部分案例推动私有化算力投入。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI不等于一个万能Agent；最稳的结构往往是 AI判断 + 确定性执行 + 人负责 - 先改造一段高频流程，再扩展基础设施 - FDE的第一产物常常是新的工作流，而不是模型 ## 现场决策与研究 ### 为什么这样做 将非结构化理解交给AI，把跨系统确定性操作交给RPA。 ### 阻力与证据边界 本地基础设施投入要等窄场景价值验证；财务工作流加速不能绕过既有授权和核对责任。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 以账期样本回放，核对金额守恒、重复提交、跨期与失败重试，比较含复核的总工时。 研究依据： - [Datawhale FDE案例100｜NO.09 从“表哥表姐”到智能执行：FDE用AI重构央国企财务流程效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=87) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Datawhale FDE案例100｜NO.09 从“表哥表姐”到智能执行：FDE用AI重构央国企财务流程效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=87) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.09](https://fde100.datawhale.cn/cases/cases-018) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 中：Datawhale案例公开了业务分工和落地方法；具体模型、框架、接口产品未完整披露，组件层使用通用技术类别表示。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-009", "source": "Datawhale", "company": "匿名央国企", "industry": "财务/企业服务", "scenario": "财务流程自动化", "fde": "明确FDE", "problem": "报销、建单、审核等流程既有语义判断，也有大量重复系统操作，且责任要求高。", "solution": "AI负责信息组织、分类判断与风险识别；RPA/API负责建单、填表和提交；高风险事项升级人工。", "human": "人工承担高风险、低置信度和最终审批责任。", "result": "形成“AI判断 + RPA执行 + 人终审”的可迁移架构；部分案例推动私有化算力投入。", "maturity": "已落地/规模化", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=87", "architecture": [ "业务材料/发票/单据/申请", "OCR/字段抽取 + 业务材料结构化", "AI识别业务类型、补齐上下文并做初步风险判断", "规则/监督逻辑复核：金额、材料完整性、规则冲突、低置信度", "RPA/API进入ERP/OA完成建单、填表、附件上传、提交", "高风险/异常 → 财务人员复核和最终审批", "审批结果、异常原因沉淀为后续规则和样例" ], "components": [ "OCR/文档解析", "LLM", "规则/监督逻辑", "RPA/API", "ERP/OA/财务系统", "Human-in-the-loop" ], "fde_actions": [ "跟岗观察真实财务操作，找出员工自己说不清的隐性判断", "把流程拆成“语义判断 / 机械执行 / 最终责任”三类任务", "访谈老员工并把经验转成明确规则、例外和升级条件", "尽量复用原ERP/OA，把AI做成上层intelligence而非重做财务系统", "从小场景PoC验证，再决定私有部署和算力投入", "用低置信度和高风险路由设计责任边界" ], "reusable": [ "企业AI不等于一个万能Agent；最稳的结构往往是 AI判断 + 确定性执行 + 人负责", "先改造一段高频流程，再扩展基础设施", "FDE的第一产物常常是新的工作流，而不是模型" ], "evidence": "中：Datawhale案例公开了业务分工和落地方法；具体模型、框架、接口产品未完整披露，组件层使用通用技术类别表示。", "case_summary": "这个案例的关键不是单点使用AI，而是把“财务流程自动化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "规模化", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.09 从“表哥表姐”到智能执行：FDE用AI重构央国企财务流程效率", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=87", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 9, "printed_page": 86, "pdf_page": 87 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "中：Datawhale案例公开了业务分工和落地方法；具体模型、框架、接口产品未完整披露，组件层使用通用技术类别表示。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.09", "url": "https://fde100.datawhale.cn/cases/cases-018" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名线下零售企业｜门店对账 - ID：datawhale-010 - 行业：零售与消费 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 多门店、多支付渠道和多系统账单需要财务人员人工勾稽。 ## 解决方案 统一账单口径，自动匹配交易并把差异与异常集中交给财务人员处理。 ## 技术工作流 > 公开信息与编辑推演混合 1. 发票/单据/账单/业务材料 2. OCR/字段抽取 + 业务分类 3. LLM/规则判断业务类型与风险 4. 确定性匹配/校验/对账 5. RPA/API写入ERP/OA/财务系统 6. 异常件 → 人工复核 → 结果回写 组件：OCR/信息抽取、LLM、规则引擎、RPA/API、ERP/OA、Human-in-the-loop ## 人机责任 财务人员只处理未匹配、异常和高风险交易。 ## FDE 动作 > 访谈信息与编辑归纳混合 - shadowing财务人员，把“看材料—判断—建单—复核”拆成原子动作 - 区分语义判断、机械执行和责任审批三类任务 - 把老员工隐性审核规则显性化并建立异常类型 - 优先接现有ERP/OA，不重造系统 - 设置低置信度、金额阈值、规则冲突等人工升级条件 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 目标是从逐笔核对转为异常处理；公开资料未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - AI负责判断，RPA/API负责确定性执行，人承担责任 - 先自动化标准件，再集中处理异常件 - 财务类项目的核心不是聊天，而是可审计的流程编排 ## 现场决策与研究 ### 为什么这样做 从参与人数少、流程明确、价值可计算的门店对账切入，先建立业务信任。 ### 阻力与证据边界 原流程能够运行，需找到规模扩大后的具体瓶颈；金额计算和匹配应可复算。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 保留差异清单与处理结果，用未解释差额、误核销、日结用时衡量，不以生成报表为完成。 研究依据： - [Datawhale FDE案例100｜NO.10 从人工核对到智能对账：FDE用AI让线下零售对账又快又准](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=96) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.10 从人工核对到智能对账：FDE用AI让线下零售对账又快又准](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=96) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.10](https://fde100.datawhale.cn/cases/cases-015) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-010", "source": "Datawhale", "company": "匿名线下零售企业", "industry": "零售", "scenario": "门店对账", "fde": "明确FDE", "problem": "多门店、多支付渠道和多系统账单需要财务人员人工勾稽。", "solution": "统一账单口径，自动匹配交易并把差异与异常集中交给财务人员处理。", "human": "财务人员只处理未匹配、异常和高风险交易。", "result": "目标是从逐笔核对转为异常处理；公开资料未披露统一ROI。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=96", "architecture": [ "发票/单据/账单/业务材料", "OCR/字段抽取 + 业务分类", "LLM/规则判断业务类型与风险", "确定性匹配/校验/对账", "RPA/API写入ERP/OA/财务系统", "异常件 → 人工复核 → 结果回写" ], "components": [ "OCR/信息抽取", "LLM", "规则引擎", "RPA/API", "ERP/OA", "Human-in-the-loop" ], "fde_actions": [ "shadowing财务人员，把“看材料—判断—建单—复核”拆成原子动作", "区分语义判断、机械执行和责任审批三类任务", "把老员工隐性审核规则显性化并建立异常类型", "优先接现有ERP/OA，不重造系统", "设置低置信度、金额阈值、规则冲突等人工升级条件" ], "reusable": [ "AI负责判断，RPA/API负责确定性执行，人承担责任", "先自动化标准件，再集中处理异常件", "财务类项目的核心不是聊天，而是可审计的流程编排" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“门店对账”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.10 从人工核对到智能对账：FDE用AI让线下零售对账又快又准", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=96", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 10, "printed_page": 95, "pdf_page": 96 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.10", "url": "https://fde100.datawhale.cn/cases/cases-015" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名跨境快消企业｜Sell-in / Sell-through经营分析 - ID：datawhale-011 - 行业：零售与消费 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：已落地/持续迭代 - 独立核验：未记录 ## 业务问题 总部发货、渠道销售和终端动销口径断裂，漂亮报表并不能回答真实经营问题。 ## 解决方案 先统一数据口径并要求每个AI答案可追溯到原始记录，再做经营问数与洞察。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 业务人员定义口径并验证异常解释。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 建立可溯源的经营分析链路，而不是单纯做聊天式BI。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 先区分总部发货、经销商销售与终端动销的口径，再连接海外数据。 ### 阻力与证据边界 接口之外还有海外审批与系统适配；材料披露的问题发现比例不等于节省比例。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 给每个指标绑定来源、时间、币种和责任人；异常提示必须能回到原始业务单据。 研究依据： - [Datawhale FDE案例100｜NO.24 从发货到动销：FDE用AI打通跨境快消的海外数据断层](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=234) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Datawhale FDE案例100｜NO.24 从发货到动销：FDE用AI打通跨境快消的海外数据断层](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=234) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.24](https://fde100.datawhale.cn/cases/cases-016) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-011", "source": "Datawhale", "company": "匿名跨境快消企业", "industry": "消费品/零售", "scenario": "Sell-in / Sell-through经营分析", "fde": "明确FDE", "problem": "总部发货、渠道销售和终端动销口径断裂，漂亮报表并不能回答真实经营问题。", "solution": "先统一数据口径并要求每个AI答案可追溯到原始记录，再做经营问数与洞察。", "human": "业务人员定义口径并验证异常解释。", "result": "建立可溯源的经营分析链路，而不是单纯做聊天式BI。", "maturity": "已落地/持续迭代", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=234", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“Sell-in / Sell-through经营分析”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.24 从发货到动销：FDE用AI打通跨境快消的海外数据断层", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=234", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 24, "printed_page": 233, "pdf_page": 234 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.24", "url": "https://fde100.datawhale.cn/cases/cases-016" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名跨境物流企业｜集装箱装载优化 - ID：datawhale-012 - 行业：交通、旅行与物流 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 装载率直接决定利润，但排载高度依赖人工经验。 ## 解决方案 将空间、货物属性和业务约束转为优化问题，并用AI辅助解释与编排。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/订单/库存/供应商/约束数据 2. 统一实体与业务口径 3. 预测/优化/LLM识别异常与候选动作 4. 规则与优化器计算可行方案 5. 业务人员确认高影响动作 6. 执行结果回写并更新库存/订单状态 组件：ERP/WMS数据、语义/实体层、预测/优化算法、LLM/AIP、规则引擎、业务工作台 ## 人机责任 调度人员处理异常货物、特殊约束与最终排载。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 和计划/采购/调度人员一起定义真正的决策单位和约束 - 统一SKU、工厂、订单、供应商等实体口径 - 把“看报表”改成“识别异常→给动作→执行”的闭环 - 用财务影响/服务水平给建议排序 - 把人工采纳/拒绝原因反馈给系统 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 案例强调98方等装载阈值与利润直接相关；具体公司指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把装箱优化改为工人实际能执行的装车顺序，采用由内向外的截面规划。 ### 阻力与证据边界 外部尺寸不等于内部可用空间，重量、卸货顺序和人能否进入都影响方案；5小时到2小时属于预计值。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 同车型同货组比较装载体积、损伤率、装卸工时和重排次数；先做物理可行性验证。 研究依据： - [Datawhale FDE案例100｜NO.06 从经验装车到智能规划：FDE用AI优化跨境物流装载效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=56) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：视觉质检与现场优化 适用条件：缺陷或约束可以由专家定义，有真实现场样本与安全回退方式。 不适用：仅在合成样本上测试，或输出无法被现场人员执行的最优方案。 ### 输入条件 - 真实设备、光照、工况与缺陷分类样本 - 物理尺寸、重量、工序、节拍与安全约束 - 人工验收标准和误判成本 ### 实施步骤 - 观察现场工作和异常处理，核准采集条件与真正可用的物理空间。 - 可用合成数据补训练覆盖，但验收留出真实新批次数据。 - 让专家检查误报和漏报，先影子运行，再小范围接入现场流程。 - 记录复检、返工和停机，工况变化时重新验证并维护版本。 ### 验收指标 - 缺陷类型级漏检率、误报率与人工复检量。 - 实际生产节拍或装卸工时，连同损伤、安全与返工指标。 - 上线后的漂移和异常批次单独跟踪，不能仅报实验室准确率。 ### 异常处理 工况漂移或安全边界触发时退出自动判定，回到人工检查；保留批次和设备上下文。 ### 责任分工 现场专家定义可接受结果；算法团队做分层评测；工艺与安全负责人授权上线。 ## 来源账本 - [Datawhale FDE案例100｜NO.06 从经验装车到智能规划：FDE用AI优化跨境物流装载效率](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=56) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.06](https://fde100.datawhale.cn/cases/cases-010) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-012", "source": "Datawhale", "company": "匿名跨境物流企业", "industry": "物流/供应链", "scenario": "集装箱装载优化", "fde": "明确FDE", "problem": "装载率直接决定利润，但排载高度依赖人工经验。", "solution": "将空间、货物属性和业务约束转为优化问题，并用AI辅助解释与编排。", "human": "调度人员处理异常货物、特殊约束与最终排载。", "result": "案例强调98方等装载阈值与利润直接相关；具体公司指标未公开。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=56", "architecture": [ "ERP/WMS/订单/库存/供应商/约束数据", "统一实体与业务口径", "预测/优化/LLM识别异常与候选动作", "规则与优化器计算可行方案", "业务人员确认高影响动作", "执行结果回写并更新库存/订单状态" ], "components": [ "ERP/WMS数据", "语义/实体层", "预测/优化算法", "LLM/AIP", "规则引擎", "业务工作台" ], "fde_actions": [ "和计划/采购/调度人员一起定义真正的决策单位和约束", "统一SKU、工厂、订单、供应商等实体口径", "把“看报表”改成“识别异常→给动作→执行”的闭环", "用财务影响/服务水平给建议排序", "把人工采纳/拒绝原因反馈给系统" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“集装箱装载优化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.06 从经验装车到智能规划：FDE用AI优化跨境物流装载效率", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=56", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 6, "printed_page": 55, "pdf_page": 56 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.06", "url": "https://fde100.datawhale.cn/cases/cases-010" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 0, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名跨境电商企业｜库存与补货 - ID：datawhale-013 - 行业：零售与消费 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：验证中 - 独立核验：未记录 ## 业务问题 多平台销售、仓储和库存数据分散，库存判断与补货依赖人工汇总。 ## 解决方案 整合平台与库存数据，自动做库存诊断、补货建议和风险预警。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/订单/库存/供应商/约束数据 2. 统一实体与业务口径 3. 预测/优化/LLM识别异常与候选动作 4. 规则与优化器计算可行方案 5. 业务人员确认高影响动作 6. 执行结果回写并更新库存/订单状态 组件：ERP/WMS数据、语义/实体层、预测/优化算法、LLM/AIP、规则引擎、业务工作台 ## 人机责任 运营人员审核促销、季节性和资金约束下的补货决策。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 和计划/采购/调度人员一起定义真正的决策单位和约束 - 统一SKU、工厂、订单、供应商等实体口径 - 把“看报表”改成“识别异常→给动作→执行”的闭环 - 用财务影响/服务水平给建议排序 - 把人工采纳/拒绝原因反馈给系统 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 减少数据汇总与人工判断负担；具体指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 从SaaS与飞书同步扩展到库存、补货和广告联动，先复用客户已有补货公式。 ### 阻力与证据边界 多个团队刷新同一Key互相失效；保留图片、补货和广告决策的人工核对。交付后效果追踪不足是原文明确遗憾。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 建立统一凭据刷新代理和同步水位；上线前记录搬数工时、缺货及积压基线，按月回访。 研究依据： - [Datawhale FDE案例100｜NO.22 从库存割裂到业务联动：FDE用AI打通跨境电商的库存、补货与广告决策](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=216) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Datawhale FDE案例100｜NO.22 从库存割裂到业务联动：FDE用AI打通跨境电商的库存、补货与广告决策](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=216) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.22](https://fde100.datawhale.cn/cases/cases-012) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-013", "source": "Datawhale", "company": "匿名跨境电商企业", "industry": "电商", "scenario": "库存与补货", "fde": "明确FDE", "problem": "多平台销售、仓储和库存数据分散，库存判断与补货依赖人工汇总。", "solution": "整合平台与库存数据，自动做库存诊断、补货建议和风险预警。", "human": "运营人员审核促销、季节性和资金约束下的补货决策。", "result": "减少数据汇总与人工判断负担；具体指标未公开。", "maturity": "验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=216", "architecture": [ "ERP/WMS/订单/库存/供应商/约束数据", "统一实体与业务口径", "预测/优化/LLM识别异常与候选动作", "规则与优化器计算可行方案", "业务人员确认高影响动作", "执行结果回写并更新库存/订单状态" ], "components": [ "ERP/WMS数据", "语义/实体层", "预测/优化算法", "LLM/AIP", "规则引擎", "业务工作台" ], "fde_actions": [ "和计划/采购/调度人员一起定义真正的决策单位和约束", "统一SKU、工厂、订单、供应商等实体口径", "把“看报表”改成“识别异常→给动作→执行”的闭环", "用财务影响/服务水平给建议排序", "把人工采纳/拒绝原因反馈给系统" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“库存与补货”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.22 从库存割裂到业务联动：FDE用AI打通跨境电商的库存、补货与广告决策", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=216", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 22, "printed_page": 215, "pdf_page": 216 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.22", "url": "https://fde100.datawhale.cn/cases/cases-012" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名TikTok电商团队｜达人筛选与建联 - ID：datawhale-014 - 行业：零售与消费 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 找达人、筛达人、生成邀约和持续跟进耗费大量运营时间。 ## 解决方案 把达人数据筛选、匹配、邀约草稿和跟进编排成半自动工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 商品/门店/达人/品牌资料 2. 结构化素材与品牌规则 3. LLM/多模态生成候选内容或邀约 4. 合规/品牌规则检查 5. 运营人员审核与发布 6. 表现数据回流用于模板与策略迭代 组件：内容数据、LLM/多模态模型、模板/品牌规则、审核工作台、发布/CRM系统 ## 人机责任 运营人员决定重点达人、谈判与关系维护。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 从运营人员真实产能瓶颈出发选择批量化环节 - 将品牌语气、禁用词、商品事实结构化 - 把生成拆成可控模板和可编辑步骤 - 接入审核/发布/CRM，而不是单独做生成页面 - 跟踪采纳率、发布量和业务转化而非只看生成质量 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 扩大单人可覆盖达人数量；公开资料未披露精确效果。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 将达人筛选、商品匹配、创作支持与到期提醒连接，处理履约动力而非只催交付。 ### 阻力与证据边界 试运行履约周期由约30天到18天是特定群体结果；不能直接推导GMV增长。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 以同批次达人统计回复、样品到达、履约、内容通过率；控制商品和达人结构差异。 研究依据： - [Datawhale FDE案例100｜NO.05 从大海捞针到全链路提效：FDE用AI重构TikTok达人建联与履约](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=47) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Datawhale FDE案例100｜NO.05 从大海捞针到全链路提效：FDE用AI重构TikTok达人建联与履约](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=47) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.05](https://fde100.datawhale.cn/cases/cases-013) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-014", "source": "Datawhale", "company": "匿名TikTok电商团队", "industry": "电商", "scenario": "达人筛选与建联", "fde": "明确FDE", "problem": "找达人、筛达人、生成邀约和持续跟进耗费大量运营时间。", "solution": "把达人数据筛选、匹配、邀约草稿和跟进编排成半自动工作流。", "human": "运营人员决定重点达人、谈判与关系维护。", "result": "扩大单人可覆盖达人数量；公开资料未披露精确效果。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=47", "architecture": [ "商品/门店/达人/品牌资料", "结构化素材与品牌规则", "LLM/多模态生成候选内容或邀约", "合规/品牌规则检查", "运营人员审核与发布", "表现数据回流用于模板与策略迭代" ], "components": [ "内容数据", "LLM/多模态模型", "模板/品牌规则", "审核工作台", "发布/CRM系统" ], "fde_actions": [ "从运营人员真实产能瓶颈出发选择批量化环节", "将品牌语气、禁用词、商品事实结构化", "把生成拆成可控模板和可编辑步骤", "接入审核/发布/CRM，而不是单独做生成页面", "跟踪采纳率、发布量和业务转化而非只看生成质量" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“达人筛选与建联”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.05 从大海捞针到全链路提效：FDE用AI重构TikTok达人建联与履约", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=47", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 5, "printed_page": 46, "pdf_page": 47 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.05", "url": "https://fde100.datawhale.cn/cases/cases-013" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名外贸企业｜邮件、报价与产品资料自动化 - ID：datawhale-015 - 行业：企业运营与其他 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：落地/迭代 - 独立核验：未记录 ## 业务问题 外贸人员重复处理询盘、产品资料、报价单与往来邮件。 ## 解决方案 信息抽取 + 企业知识检索 + 文档/邮件生成，嵌入现有外贸流程。 ## 技术工作流 > 公开信息与编辑推演混合 1. 商品/门店/达人/品牌资料 2. 结构化素材与品牌规则 3. LLM/多模态生成候选内容或邀约 4. 合规/品牌规则检查 5. 运营人员审核与发布 6. 表现数据回流用于模板与策略迭代 组件：内容数据、LLM/多模态模型、模板/品牌规则、审核工作台、发布/CRM系统 ## 人机责任 业务员负责商业判断、价格与最终发送。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 从运营人员真实产能瓶颈出发选择批量化环节 - 将品牌语气、禁用词、商品事实结构化 - 把生成拆成可控模板和可编辑步骤 - 接入审核/发布/CRM，而不是单独做生成页面 - 跟踪采纳率、发布量和业务转化而非只看生成质量 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 减少重复文书劳动；具体指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 从老板能感知的小问题取得信任，再组织杂乱资料和后续自动化。 ### 阻力与证据边界 网络、权限和客户电脑环境成为真实交付成本；本地数据访问与长任务需稳定运行通道。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按客户、产品、版本建文件索引；验证权限拒绝、断网恢复和员工工作时不被打断。 研究依据： - [Datawhale FDE案例100｜NO.11 从文件散乱到随取随用：FDE用AI帮外贸企业把资料变成可用资产](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=106) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Datawhale FDE案例100｜NO.11 从文件散乱到随取随用：FDE用AI帮外贸企业把资料变成可用资产](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=106) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.11](https://fde100.datawhale.cn/cases/cases-004) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-015", "source": "Datawhale", "company": "匿名外贸企业", "industry": "贸易/外贸", "scenario": "邮件、报价与产品资料自动化", "fde": "明确FDE", "problem": "外贸人员重复处理询盘、产品资料、报价单与往来邮件。", "solution": "信息抽取 + 企业知识检索 + 文档/邮件生成，嵌入现有外贸流程。", "human": "业务员负责商业判断、价格与最终发送。", "result": "减少重复文书劳动；具体指标未公开。", "maturity": "落地/迭代", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=106", "architecture": [ "商品/门店/达人/品牌资料", "结构化素材与品牌规则", "LLM/多模态生成候选内容或邀约", "合规/品牌规则检查", "运营人员审核与发布", "表现数据回流用于模板与策略迭代" ], "components": [ "内容数据", "LLM/多模态模型", "模板/品牌规则", "审核工作台", "发布/CRM系统" ], "fde_actions": [ "从运营人员真实产能瓶颈出发选择批量化环节", "将品牌语气、禁用词、商品事实结构化", "把生成拆成可控模板和可编辑步骤", "接入审核/发布/CRM，而不是单独做生成页面", "跟踪采纳率、发布量和业务转化而非只看生成质量" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“邮件、报价与产品资料自动化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "未明确", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.11 从文件散乱到随取随用：FDE用AI帮外贸企业把资料变成可用资产", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=106", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 11, "printed_page": 105, "pdf_page": 106 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.11", "url": "https://fde100.datawhale.cn/cases/cases-004" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名鞋服电商企业｜商品图片与文案生产 - ID：datawhale-016 - 行业：零售与消费 - 来源：Datawhale - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：已落地 - 独立核验：未记录 ## 业务问题 SKU多、上新频繁，图片和商品文案制作速度成为瓶颈。 ## 解决方案 把商品数据与品牌规范接入生成式AI，批量生成并修改内容。 ## 技术工作流 > 公开信息与编辑推演混合 1. 商品/门店/达人/品牌资料 2. 结构化素材与品牌规则 3. LLM/多模态生成候选内容或邀约 4. 合规/品牌规则检查 5. 运营人员审核与发布 6. 表现数据回流用于模板与策略迭代 组件：内容数据、LLM/多模态模型、模板/品牌规则、审核工作台、发布/CRM系统 ## 人机责任 设计与运营负责品牌一致性和最终发布。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 从运营人员真实产能瓶颈出发选择批量化环节 - 将品牌语气、禁用词、商品事实结构化 - 把生成拆成可控模板和可编辑步骤 - 接入审核/发布/CRM，而不是单独做生成页面 - 跟踪采纳率、发布量和业务转化而非只看生成质量 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 提升内容量产能力；具体ROI未公开。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 从个人出图效率转为公司级素材生产流程，统一可复用的生产与验收标准。 ### 阻力与证据边界 人盯着AI反复改图仍然是瓶颈；单次漂亮样张无法证明批量合格率。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按商品保真、品牌规范、首稿通过率和返工工时评估，发布前由业务人员确认。 研究依据： - [Datawhale FDE案例100｜NO.12 从人工盯图到公司级生产：FDE用AI重塑鞋服电商素材工作流](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=119) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：内容与创意生产 适用条件：输入素材有使用权，质量标准和发布渠道明确，有业务人员审核。 不适用：一张好图或一篇好稿就当作量产能力，或者把生成数量当作营销效果。 ### 输入条件 - 品牌、商品事实、已授权素材与合格/不合格样本 - 任务类型、风格范围和渠道规格 - 审核原因、返工记录与最终发布结果 ### 实施步骤 - 拆解创意、事实整理、制作、审核与发布，识别真正消耗时间的环节。 - 为可规范部分建立约束，把审美和业务策略保留给负责人。 - 批量生成后执行事实和规格检查，人工处理主观质量与风险。 - 追踪首稿通过率和返工成本；传播与转化用单独实验评价。 ### 验收指标 - 首稿通过率与平均修改轮次，同时保留样本类型。 - 每件被接受资产的完整成本，包含失败生成和人工修改。 - 发布后的传播或转化与生产效率分别报告。 ### 异常处理 事实、商品细节或品牌规范不符时阻止发布；保留素材来源、生成版本和审核理由。 ### 责任分工 业务与品牌负责人定义质量；创作人员判断审美；工程团队编排流程；发布人最终确认。 ## 来源账本 - [Datawhale FDE案例100｜NO.12 从人工盯图到公司级生产：FDE用AI重塑鞋服电商素材工作流](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=119) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.12](https://fde100.datawhale.cn/cases/cases-021) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-016", "source": "Datawhale", "company": "匿名鞋服电商企业", "industry": "电商", "scenario": "商品图片与文案生产", "fde": "明确FDE", "problem": "SKU多、上新频繁，图片和商品文案制作速度成为瓶颈。", "solution": "把商品数据与品牌规范接入生成式AI，批量生成并修改内容。", "human": "设计与运营负责品牌一致性和最终发布。", "result": "提升内容量产能力；具体ROI未公开。", "maturity": "已落地", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=119", "architecture": [ "商品/门店/达人/品牌资料", "结构化素材与品牌规则", "LLM/多模态生成候选内容或邀约", "合规/品牌规则检查", "运营人员审核与发布", "表现数据回流用于模板与策略迭代" ], "components": [ "内容数据", "LLM/多模态模型", "模板/品牌规则", "审核工作台", "发布/CRM系统" ], "fde_actions": [ "从运营人员真实产能瓶颈出发选择批量化环节", "将品牌语气、禁用词、商品事实结构化", "把生成拆成可控模板和可编辑步骤", "接入审核/发布/CRM，而不是单独做生成页面", "跟踪采纳率、发布量和业务转化而非只看生成质量" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“商品图片与文案生产”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.12 从人工盯图到公司级生产：FDE用AI重塑鞋服电商素材工作流", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=119", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 12, "printed_page": 118, "pdf_page": 119 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.12", "url": "https://fde100.datawhale.cn/cases/cases-021" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名本地生活企业｜门店短视频内容工厂 - ID：datawhale-017 - 行业：媒体、营销与体育 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：已落地/验证中 - 独立核验：未记录 ## 业务问题 大量门店需要持续生产低成本短视频，一线不会写脚本也没有制作能力。 ## 解决方案 将门店信息、商品卖点和模板组织成脚本/素材/短视频生成工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 商品/门店/达人/品牌资料 2. 结构化素材与品牌规则 3. LLM/多模态生成候选内容或邀约 4. 合规/品牌规则检查 5. 运营人员审核与发布 6. 表现数据回流用于模板与策略迭代 组件：内容数据、LLM/多模态模型、模板/品牌规则、审核工作台、发布/CRM系统 ## 人机责任 运营人员挑选主题、审核品牌与违规风险。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 从运营人员真实产能瓶颈出发选择批量化环节 - 将品牌语气、禁用词、商品事实结构化 - 把生成拆成可控模板和可编辑步骤 - 接入审核/发布/CRM，而不是单独做生成页面 - 跟踪采纳率、发布量和业务转化而非只看生成质量 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 重点是降低单条内容生产成本并扩大产量。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把写稿经验拆成可反馈的工作步骤，避免固定范式在不同商户间机械复用。 ### 阻力与证据边界 单纯提供历史文案或部署本地模型未解决AI味；需比较提示、顺序和模型并保留回退。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 用同商户题材的盲评及实际修改工时检查质量，播放量与转化另设对照，不能归因给模型一项。 研究依据： - [Datawhale FDE案例100｜NO.15 从经验写稿到稳定量产：FDE用AI重构本地生活短视频内容生产](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=146) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：内容与创意生产 适用条件：输入素材有使用权，质量标准和发布渠道明确，有业务人员审核。 不适用：一张好图或一篇好稿就当作量产能力，或者把生成数量当作营销效果。 ### 输入条件 - 品牌、商品事实、已授权素材与合格/不合格样本 - 任务类型、风格范围和渠道规格 - 审核原因、返工记录与最终发布结果 ### 实施步骤 - 拆解创意、事实整理、制作、审核与发布，识别真正消耗时间的环节。 - 为可规范部分建立约束，把审美和业务策略保留给负责人。 - 批量生成后执行事实和规格检查，人工处理主观质量与风险。 - 追踪首稿通过率和返工成本；传播与转化用单独实验评价。 ### 验收指标 - 首稿通过率与平均修改轮次，同时保留样本类型。 - 每件被接受资产的完整成本，包含失败生成和人工修改。 - 发布后的传播或转化与生产效率分别报告。 ### 异常处理 事实、商品细节或品牌规范不符时阻止发布；保留素材来源、生成版本和审核理由。 ### 责任分工 业务与品牌负责人定义质量；创作人员判断审美；工程团队编排流程；发布人最终确认。 ## 来源账本 - [Datawhale FDE案例100｜NO.15 从经验写稿到稳定量产：FDE用AI重构本地生活短视频内容生产](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=146) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.15](https://fde100.datawhale.cn/cases/cases-003) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-017", "source": "Datawhale", "company": "匿名本地生活企业", "industry": "营销/内容", "scenario": "门店短视频内容工厂", "fde": "明确FDE", "problem": "大量门店需要持续生产低成本短视频，一线不会写脚本也没有制作能力。", "solution": "将门店信息、商品卖点和模板组织成脚本/素材/短视频生成工作流。", "human": "运营人员挑选主题、审核品牌与违规风险。", "result": "重点是降低单条内容生产成本并扩大产量。", "maturity": "已落地/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=146", "architecture": [ "商品/门店/达人/品牌资料", "结构化素材与品牌规则", "LLM/多模态生成候选内容或邀约", "合规/品牌规则检查", "运营人员审核与发布", "表现数据回流用于模板与策略迭代" ], "components": [ "内容数据", "LLM/多模态模型", "模板/品牌规则", "审核工作台", "发布/CRM系统" ], "fde_actions": [ "从运营人员真实产能瓶颈出发选择批量化环节", "将品牌语气、禁用词、商品事实结构化", "把生成拆成可控模板和可编辑步骤", "接入审核/发布/CRM，而不是单独做生成页面", "跟踪采纳率、发布量和业务转化而非只看生成质量" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“门店短视频内容工厂”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "媒体、营销与体育", "maturity_stage": "已上线", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.15 从经验写稿到稳定量产：FDE用AI重构本地生活短视频内容生产", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=146", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 15, "printed_page": 145, "pdf_page": 146 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.15", "url": "https://fde100.datawhale.cn/cases/cases-003" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名建筑设计企业｜图纸理解与交付辅助 - ID：datawhale-018 - 行业：专业服务 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：POC/验证中 - 独立核验：未记录 ## 业务问题 图纸和设计材料复杂，信息抽取、核对与交付过程耗时。 ## 解决方案 多模态理解图纸和文档，辅助抽取、核对、归纳与设计交付。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 建筑/工程专业人员保留设计责任与安全判断。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 减少重复检查和资料整理时间；指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 从CAD理解进入规则化消防图纸交付，把人员角色转向审核和特殊场景决策。 ### 阻力与证据边界 不同空间对应不同设计约束；最终图纸的合规、安全责任仍在人，结果不能黑箱。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 对空间识别、参数计算、覆盖关系分别测试；输出依据、可编辑图纸与签审记录。 研究依据： - [Datawhale FDE案例100｜NO.21 从人工绘图到智能协作：FDE用AI重塑建筑图纸交付流程](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=207) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.21 从人工绘图到智能协作：FDE用AI重塑建筑图纸交付流程](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=207) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.21](https://fde100.datawhale.cn/cases/cases-002) - [旧版使用的二次整理或汇总来源](https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-018", "source": "Datawhale", "company": "匿名建筑设计企业", "industry": "建筑/工程", "scenario": "图纸理解与交付辅助", "fde": "明确FDE", "problem": "图纸和设计材料复杂，信息抽取、核对与交付过程耗时。", "solution": "多模态理解图纸和文档，辅助抽取、核对、归纳与设计交付。", "human": "建筑/工程专业人员保留设计责任与安全判断。", "result": "减少重复检查和资料整理时间；指标未公开。", "maturity": "POC/验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=207", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“图纸理解与交付辅助”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "专业服务", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.21 从人工绘图到智能协作：FDE用AI重塑建筑图纸交付流程", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=207", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 21, "printed_page": 206, "pdf_page": 207 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.21", "url": "https://fde100.datawhale.cn/cases/cases-002" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://podcasts.apple.com/us/podcast/fde-24%E4%B8%AA%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E8%A7%A3%E8%AF%BB/id1827758935?i=1000788554765" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名电信企业｜网络数据分析 / 智能问数 - ID：datawhale-019 - 行业：企业运营与其他 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：验证中 - 独立核验：未记录 ## 业务问题 网络日志与指标规模大，问题定位与分析报告高度依赖分析师。 ## 解决方案 打通网络数据、指标口径与知识，允许AI查询、归因并生成分析草稿。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 网络专家确认根因和处置建议。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 目标是分钟级获取洞察；公开材料未披露统一效果。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把问数放回电信分析全流程，重点解决SQL语义、稳定性与成本。 ### 阻力与证据边界 客户此前已有Agent，能跑演示并不意味着取数正确；长SQL可能看似合理却读错数据。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 构建业务问题到标准查询的对照集，核对时间窗、维度、单位、行级权限和执行成本。 研究依据： - [Datawhale FDE案例100｜NO.16 从人工分析到分钟级洞察：FDE用AI重构电信网络数据分析](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=158) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Datawhale FDE案例100｜NO.16 从人工分析到分钟级洞察：FDE用AI重构电信网络数据分析](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=158) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.16](https://fde100.datawhale.cn/cases/cases-005) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-019", "source": "Datawhale", "company": "匿名电信企业", "industry": "电信", "scenario": "网络数据分析 / 智能问数", "fde": "明确FDE", "problem": "网络日志与指标规模大，问题定位与分析报告高度依赖分析师。", "solution": "打通网络数据、指标口径与知识，允许AI查询、归因并生成分析草稿。", "human": "网络专家确认根因和处置建议。", "result": "目标是分钟级获取洞察；公开材料未披露统一效果。", "maturity": "验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=158", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“网络数据分析 / 智能问数”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.16 从人工分析到分钟级洞察：FDE用AI重构电信网络数据分析", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=158", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 16, "printed_page": 157, "pdf_page": 158 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.16", "url": "https://fde100.datawhale.cn/cases/cases-005" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名生物科技企业｜经营台账数字化 - ID：datawhale-020 - 行业：医疗与生命科学 - 来源：Datawhale - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：验证中 - 独立核验：未记录 ## 业务问题 经营与项目数据散落在Excel和文件中，查询、汇总和经营分析困难。 ## 解决方案 先结构化台账和文档，再叠加查询、分析和经营助手。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 业务人员维护关键事实并审核经营结论。 ## FDE 动作 > 访谈信息与编辑归纳混合 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 形成统一数据底座和问数入口；指标未公开。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 先补CRM、数仓和BI，使经营数据可用，再将知识转成陪练与考试。 ### 阻力与证据边界 仅建知识库不足以训练新人；AI与裁员绑定会引发阻力，需要岗位责任和内部AI团队承接。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 追踪销售新人达标时间和数据延迟；招聘筛选只作辅助，保留人工决策、偏差检查与申诉路径。 研究依据： - [Datawhale FDE案例100｜NO.18 从纸质台账到AI经营：一家生物科技上市公司的0帧起手数智化](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=178) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Datawhale FDE案例100｜NO.18 从纸质台账到AI经营：一家生物科技上市公司的0帧起手数智化](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=178) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.18](https://fde100.datawhale.cn/cases/cases-020) - [旧版使用的二次整理或汇总来源](https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：访谈信息与编辑归纳混合 - result：案例发布方披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-020", "source": "Datawhale", "company": "匿名生物科技企业", "industry": "生命科学", "scenario": "经营台账数字化", "fde": "明确FDE", "problem": "经营与项目数据散落在Excel和文件中，查询、汇总和经营分析困难。", "solution": "先结构化台账和文档，再叠加查询、分析和经营助手。", "human": "业务人员维护关键事实并审核经营结论。", "result": "形成统一数据底座和问数入口；指标未公开。", "maturity": "验证中", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=178", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“经营台账数字化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "验证阶段", "fde_relation": "明确FDE", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.18 从纸质台账到AI经营：一家生物科技上市公司的0帧起手数智化", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=178", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 18, "printed_page": 177, "pdf_page": 178 }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "访谈信息与编辑归纳混合", "result": "案例发布方披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.18", "url": "https://fde100.datawhale.cn/cases/cases-020" }, { "title": "旧版使用的二次整理或汇总来源", "url": "https://bi-chao.com/articles/bank-lessons-from-datawhale-fde-case-100" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # 匿名省属国企电商子公司｜多业务线AI工作流与组织能力建设 - ID：datawhale-021 - 行业：零售与消费 - 来源：Datawhale - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜案例级直接来源 - 部署：已落地/扩展中 - 独立核验：未记录 ## 业务问题 多条电商业务线持续增长，但法务、财务、内控等专业岗位受编制限制；大量审核经验存在员工脑中，已有AI底座也没有真正进入业务工作流。 ## 解决方案 先由知识萃取师梳理岗位隐性知识与流程，再建设包含知识库、多模型调度、Agent编排和MCP接口的统一AI平台，按法务、财务、行政等场景逐步落地Agent，并通过培训建立业务团队的自我迭代能力。 ## 技术工作流 > 依据公开方案结构化整理 1. OA / ERP / 数据中台与岗位知识 2. 知识萃取与隐性流程显性化 3. 统一AI平台：知识库、多模型、Agent编排、MCP 4. 法务/财务/行政场景Agent 5. AI初筛与执行，人最终确认 6. 培训、使用反馈与新知识持续沉淀 组件：企业知识库、多模型调度、Agent编排、MCP/业务系统接口、OA/ERP、Human-in-the-loop ## 人机责任 AI负责合同初筛、票据核对等重复工作；法务、财务及业务人员保留最终确认和责任。 ## FDE 动作 > 依据公开页面归纳 - 进入法务、财务、运营等岗位梳理隐性流程 - 把专家经验转成规则、例外与人工升级条件 - 复用现有OA、ERP和数据中台，不重造业务系统 - 按场景构建Agent并明确人机责任边界 - 推动人事与业务部门参与培训和采用运营 ## 业务结果与盈利口径 **来源披露金额或成本影响** Datawhale审核案例称，法务场景可节省1个法务编制，整体覆盖法务、财务、人事、业务、技术等约10人/年的用工成本。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - AI底座上线不等于业务采用 - 知识萃取和流程梳理应早于Agent开发 - 企业AI转型需要业务、人事和IT共同负责 - 以窄场景验证价值，再扩展Agent矩阵 ## 现场决策与研究 ### 为什么这样做 已有AI底座不等于流程采用，需把法务财务等岗位的隐性判断转成业务能力。 ### 阻力与证据边界 员工担心经验交出后被替代，会阻碍知识萃取；需要明确岗位收益与业务Builder的责任。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 对每条流程分别登记使用率、实际处理量和专业复核；“人年”估算与真实编制变化分开报告。 研究依据： - [Datawhale FDE案例100｜NO.14 从技术交付到业务自驱：FDE用AI推动国企工作流程真正落地](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=136) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Datawhale FDE案例100｜NO.14 从技术交付到业务自驱：FDE用AI推动国企工作流程真正落地](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=136) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.14](https://fde100.datawhale.cn/cases/cases-014) ## 字段边界 - business_problem：公开页面披露 - solution：公开页面披露 - architecture：依据公开方案结构化整理 - fde_actions：依据公开页面归纳 - result：案例发布方披露 ## 待核对事项 - 页面标记为 VERIFIED CASE / 审核通过。 - 效果数字属于案例发布方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-021", "source": "Datawhale", "company": "匿名省属国企电商子公司", "industry": "零售/电商", "industry_group": "零售与消费", "scenario": "多业务线AI工作流与组织能力建设", "fde": "明确FDE", "fde_relation": "明确FDE", "problem": "多条电商业务线持续增长，但法务、财务、内控等专业岗位受编制限制；大量审核经验存在员工脑中，已有AI底座也没有真正进入业务工作流。", "solution": "先由知识萃取师梳理岗位隐性知识与流程，再建设包含知识库、多模型调度、Agent编排和MCP接口的统一AI平台，按法务、财务、行政等场景逐步落地Agent，并通过培训建立业务团队的自我迭代能力。", "human": "AI负责合同初筛、票据核对等重复工作；法务、财务及业务人员保留最终确认和责任。", "result": "Datawhale审核案例称，法务场景可节省1个法务编制，整体覆盖法务、财务、人事、业务、技术等约10人/年的用工成本。", "maturity": "已落地/扩展中", "maturity_stage": "已上线", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=136", "architecture": [ "OA / ERP / 数据中台与岗位知识", "知识萃取与隐性流程显性化", "统一AI平台：知识库、多模型、Agent编排、MCP", "法务/财务/行政场景Agent", "AI初筛与执行，人最终确认", "培训、使用反馈与新知识持续沉淀" ], "components": [ "企业知识库", "多模型调度", "Agent编排", "MCP/业务系统接口", "OA/ERP", "Human-in-the-loop" ], "fde_actions": [ "进入法务、财务、运营等岗位梳理隐性流程", "把专家经验转成规则、例外与人工升级条件", "复用现有OA、ERP和数据中台，不重造业务系统", "按场景构建Agent并明确人机责任边界", "推动人事与业务部门参与培训和采用运营" ], "reusable": [ "AI底座上线不等于业务采用", "知识萃取和流程梳理应早于Agent开发", "企业AI转型需要业务、人事和IT共同负责", "以窄场景验证价值，再扩展Agent矩阵" ], "evidence": "Datawhale FDE100审核通过的脱敏案例，公开了组织背景、解决方案和效果口径；未提供独立审计材料。", "case_summary": "这个案例最值得参考的是：项目没有停在统一AI平台，而是把岗位知识萃取、场景Agent和组织培训放进同一条落地链路。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.14 从技术交付到业务自驱：FDE用AI推动国企工作流程真正落地", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=136", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 14, "printed_page": 135, "pdf_page": 136 }, "analysis_boundary": { "business_problem": "公开页面披露", "solution": "公开页面披露", "architecture": "依据公开方案结构化整理", "fde_actions": "依据公开页面归纳", "result": "案例发布方披露" }, "verification_notes": [ "页面标记为 VERIFIED CASE / 审核通过。", "效果数字属于案例发布方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.14", "url": "https://fde100.datawhale.cn/cases/cases-014" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # 匿名头部基金公司｜AI Coding研发团队转型 - ID：datawhale-022 - 行业：金融与保险 - 来源：Datawhale - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜案例级直接来源 - 部署：已落地/持续迭代 - 独立核验：未记录 ## 业务问题 开发人员已经各自使用AI Coding工具，但工具、方法和能力标准不统一，传统PRD与角色分工也没有适应AI协作，个人提效无法变成组织能力。 ## 解决方案 构建面向AI Coding的Spec文档体系，重新定义产品、前后端、测试和运维的输入输出；用五天半线下深度实践边培训边诊断，并分阶段扩展到产品经理和管理者。 ## 技术工作流 > 依据公开方案结构化整理 1. 真实研发任务与现有协作流程 2. 团队能力与工具使用基线诊断 3. Spec文档体系与角色输入输出 4. AI Coding工具进入开发循环 5. 编译、测试、Review和生产约束 6. 复盘形成企业自己的协作规范 组件：Codex/Claude Code等AI Coding工具、Spec文档、代码仓库、测试与Review、分角色培训、组织采用机制 ## 人机责任 AI承担代码与文档生成、分析和执行；研发人员保留架构、评审、测试、合并与生产责任。 ## FDE 动作 > 依据公开页面归纳 - 现场验证团队真实AI Coding水平 - 识别个人习惯与团队统一之间的冲突 - 与客户共创Spec文档而非照搬模板 - 按老板、研发、产品和HR设计不同目标 - 分三期迭代培训内容与协作方式 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Datawhale审核案例称，写代码时间节省约三分之一，写文档时间节省50%以上。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - AI Coding转型不是单次工具培训 - 先定义角色输入输出，再统一工具 - 用真实项目验证方法而非只看课程完成率 - 把个人经验沉淀成团队可执行的Spec ## 现场决策与研究 ### 为什么这样做 从各自使用编码工具转向统一Spec文档、工具和协作方式。 ### 阻力与证据边界 前期访谈不一定准确，需真实操作与快速原型；省时数字来自数天短期统计，不能当长期ROI。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 连续追踪同类需求从定义到上线的周期，结合返工和缺陷，不以生成代码量验收。 研究依据： - [Datawhale FDE案例100｜NO.07 从个人提效到组织能力：FDE用AI推动企业研发转型](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=68) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Datawhale FDE案例100｜NO.07 从个人提效到组织能力：FDE用AI推动企业研发转型](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=68) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.07](https://fde100.datawhale.cn/cases/cases-017) ## 字段边界 - business_problem：公开页面披露 - solution：公开页面披露 - architecture：依据公开方案结构化整理 - fde_actions：依据公开页面归纳 - result：案例发布方披露 ## 待核对事项 - 页面标记为 VERIFIED CASE / 审核通过。 - 效果数字属于案例发布方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "datawhale-022", "source": "Datawhale", "company": "匿名头部基金公司", "industry": "金融", "industry_group": "金融与保险", "scenario": "AI Coding研发团队转型", "fde": "明确FDE", "fde_relation": "明确FDE", "problem": "开发人员已经各自使用AI Coding工具，但工具、方法和能力标准不统一，传统PRD与角色分工也没有适应AI协作，个人提效无法变成组织能力。", "solution": "构建面向AI Coding的Spec文档体系，重新定义产品、前后端、测试和运维的输入输出；用五天半线下深度实践边培训边诊断，并分阶段扩展到产品经理和管理者。", "human": "AI承担代码与文档生成、分析和执行；研发人员保留架构、评审、测试、合并与生产责任。", "result": "Datawhale审核案例称，写代码时间节省约三分之一，写文档时间节省50%以上。", "maturity": "已落地/持续迭代", "maturity_stage": "已上线", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=68", "architecture": [ "真实研发任务与现有协作流程", "团队能力与工具使用基线诊断", "Spec文档体系与角色输入输出", "AI Coding工具进入开发循环", "编译、测试、Review和生产约束", "复盘形成企业自己的协作规范" ], "components": [ "Codex/Claude Code等AI Coding工具", "Spec文档", "代码仓库", "测试与Review", "分角色培训", "组织采用机制" ], "fde_actions": [ "现场验证团队真实AI Coding水平", "识别个人习惯与团队统一之间的冲突", "与客户共创Spec文档而非照搬模板", "按老板、研发、产品和HR设计不同目标", "分三期迭代培训内容与协作方式" ], "reusable": [ "AI Coding转型不是单次工具培训", "先定义角色输入输出，再统一工具", "用真实项目验证方法而非只看课程完成率", "把个人经验沉淀成团队可执行的Spec" ], "evidence": "Datawhale FDE100审核通过的脱敏案例，公开了五天半实践方式、Spec体系及时间节省口径；未提供独立审计材料。", "case_summary": "这个案例展示了AI Coding从个人工具走向团队研发制度时，真正需要重构的是文档、角色边界和协作流程。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.07 从个人提效到组织能力：FDE用AI推动企业研发转型", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=68", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 7, "printed_page": 67, "pdf_page": 68 }, "analysis_boundary": { "business_problem": "公开页面披露", "solution": "公开页面披露", "architecture": "依据公开方案结构化整理", "fde_actions": "依据公开页面归纳", "result": "案例发布方披露" }, "verification_notes": [ "页面标记为 VERIFIED CASE / 审核通过。", "效果数字属于案例发布方披露，不代表独立审计。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.07", "url": "https://fde100.datawhale.cn/cases/cases-017" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # 匿名汽车零部件供应链企业｜制造经营流程透明化与异常闭环 - ID：datawhale-023 - 行业：制造与工业 - 来源：Datawhale - 详细度：深度案例｜关键链路较完整（11/12） - 证据：A级｜案例级直接来源 - 部署：已落地/演示中 - 独立核验：未记录 ## 业务问题 订单、采购、库存、发货和回款数据虽然都在ERP中，但没有按经营逻辑串联；真实业务偏差难以表达，异常依赖人工发现，老板仍需到处问人。 ## 解决方案 保留原ERP作为交易系统，只读同步到业务镜像库，以订单为主线重构业务链路；用AI和规则完成关系匹配与异常识别，通过经营看板和飞书卡片让异常主动上浮。 ## 技术工作流 > 依据公开方案结构化整理 1. 管家婆ERP中的订单/采购/库存/发货/回款数据 2. 只读同步到独立业务镜像库 3. 以订单为主线重构业务关系 4. AI与规则完成匹配、核对和异常识别 5. 经营看板与飞书异常卡片 6. 人工处置结果回写异常闭环 组件：ERP只读同步、业务镜像库、数据关系匹配、规则/AI异常识别、经营看板、飞书通知 ## 人机责任 系统负责关联、校验和异常提示；采购、生产、财务和管理者处理例外并承担业务决策责任。 ## FDE 动作 > 依据公开页面归纳 - 跟随真实订单识别ERP标准流程与现场事实的偏差 - 保留原ERP并设计只读集成边界 - 统一订单、采购、库存、发货和回款关系 - 把管理者提问转成异常规则与责任节点 - 设计正常自动流转、异常主动上浮的闭环 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 形成订单全链路穿透、异常主动提醒和经营看板；Datawhale公开页面未披露统一量化收益。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 企业已有数据不等于已经看清经营 - 先做只读镜像可降低替换核心系统的风险 - 看板应展示可行动异常而不只是汇总数字 - 按业务对象串联数据比按系统模块展示更有效 ## 现场决策与研究 ### 为什么这样做 先串联订单、采购、库存、发货和回款，使经营异常可见并交给责任人处理。 ### 阻力与证据边界 原访谈明确说上线时间短，尚不能证明利润或成本改善。能提醒和能自动运营是不同阶段。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 给每个异常绑定对象、责任人、截止时间与关闭证据，随后验证重复订货和资金占用。 研究依据： - [Datawhale FDE案例100｜NO.20 从看不清订单到看清经营：FDE用AI让制造企业的经营流程更透明](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=197) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Datawhale FDE案例100｜NO.20 从看不清订单到看清经营：FDE用AI让制造企业的经营流程更透明](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=197) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.20](https://fde100.datawhale.cn/cases/cases-022) ## 字段边界 - business_problem：公开页面披露 - solution：公开页面披露 - architecture：依据公开方案结构化整理 - fde_actions：依据公开页面归纳 - result：案例发布方披露 ## 待核对事项 - 页面标记为 VERIFIED CASE / 审核通过。 - 公开页面未给统一量化结果。 ## 完整原始结构化记录 ```json { "id": "datawhale-023", "technical_reference": true, "source": "Datawhale", "company": "匿名汽车零部件供应链企业", "industry": "制造业", "industry_group": "制造与工业", "scenario": "制造经营流程透明化与异常闭环", "fde": "明确FDE", "fde_relation": "明确FDE", "problem": "订单、采购、库存、发货和回款数据虽然都在ERP中，但没有按经营逻辑串联；真实业务偏差难以表达，异常依赖人工发现，老板仍需到处问人。", "solution": "保留原ERP作为交易系统，只读同步到业务镜像库，以订单为主线重构业务链路；用AI和规则完成关系匹配与异常识别，通过经营看板和飞书卡片让异常主动上浮。", "human": "系统负责关联、校验和异常提示；采购、生产、财务和管理者处理例外并承担业务决策责任。", "result": "形成订单全链路穿透、异常主动提醒和经营看板；Datawhale公开页面未披露统一量化收益。", "maturity": "已落地/演示中", "maturity_stage": "已上线", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=197", "architecture": [ "管家婆ERP中的订单/采购/库存/发货/回款数据", "只读同步到独立业务镜像库", "以订单为主线重构业务关系", "AI与规则完成匹配、核对和异常识别", "经营看板与飞书异常卡片", "人工处置结果回写异常闭环" ], "components": [ "ERP只读同步", "业务镜像库", "数据关系匹配", "规则/AI异常识别", "经营看板", "飞书通知" ], "fde_actions": [ "跟随真实订单识别ERP标准流程与现场事实的偏差", "保留原ERP并设计只读集成边界", "统一订单、采购、库存、发货和回款关系", "把管理者提问转成异常规则与责任节点", "设计正常自动流转、异常主动上浮的闭环" ], "reusable": [ "企业已有数据不等于已经看清经营", "先做只读镜像可降低替换核心系统的风险", "看板应展示可行动异常而不只是汇总数字", "按业务对象串联数据比按系统模块展示更有效" ], "evidence": "Datawhale FDE100审核通过的脱敏案例，公开了业务流程、只读集成与异常闭环方案；未披露统一量化收益。", "case_summary": "这个案例的核心不是再造ERP，而是在不干扰原交易系统的前提下，把分散数据重组为可追责、可处置的经营链路。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.20 从看不清订单到看清经营：FDE用AI让制造企业的经营流程更透明", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=197", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 20, "printed_page": 196, "pdf_page": 197 }, "analysis_boundary": { "business_problem": "公开页面披露", "solution": "公开页面披露", "architecture": "依据公开方案结构化整理", "fde_actions": "依据公开页面归纳", "result": "案例发布方披露" }, "verification_notes": [ "页面标记为 VERIFIED CASE / 审核通过。", "公开页面未给统一量化结果。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.20", "url": "https://fde100.datawhale.cn/cases/cases-022" } ], "detail_score": 11, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "量化结果" ] } ``` --- # 匿名食品消费品企业｜产品研发协同与包装智能审核 - ID：datawhale-024 - 行业：零售与消费 - 来源：Datawhale - 详细度：深度案例｜关键链路较完整（11/12） - 证据：A级｜案例级直接来源 - 部署：落地/持续迭代 - 独立核验：未记录 ## 业务问题 企业每年开发100多个SKU，包装审核涉及设计、法规、渠道和产品经理多方，重复检查形成排队瓶颈；研发与渠道经验分散在人脑和多个系统中。 ## 解决方案 把包装审核拆成OCR/VLM理解、确定性规则代码、历史经验和人工判断四层；让Agent进入业务群持续识别问题并沉淀上下文，同时培养业务Builder自行搭建工作流。 ## 技术工作流 > 依据公开方案结构化整理 1. 产品需求、配方、设计稿、法规与渠道规则 2. OCR/VLM解析包装内容 3. 确定性脚本校验错字、法规与NRV计算 4. 历史驳回与渠道反馈形成经验库 5. AI预审后由专业人员判断 6. 结果、整改闭环与新经验持续沉淀 组件：OCR/VLM、规则代码、知识库、Agent/Skill/Workflow、业务群上下文、Human-in-the-loop ## 人机责任 AI预审错字、法规、NRV计算和渠道历史规则；产品经理、设计师及法规人员保留审美、定位、合规和最终发布责任。 ## FDE 动作 > 依据公开页面归纳 - 拆解包装审核中的确定性检查和专业判断 - 把Agent放入业务群观察真实协作两到三周 - 将驳回、整改和渠道反馈沉淀为规则 - 设计AI架构师与AI HRBP双重角色 - 通过黑客松培养业务人员成为Builder ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 形成包装预审、产品生命周期知识沉淀和业务Builder培养方案；Datawhale公开页面未披露统一量化收益。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 高风险审核应让规则、模型和人分层负责 - 让Agent观察真实协作可补足访谈遗漏 - 把每次驳回变成下一次预审的上下文 - 组织自我造血能力比一次性交付更重要 ## 现场决策与研究 ### 为什么这样做 将包装分成不同视觉模块，OCR/VLM读取，NRV等固定计算转为确定性代码。 ### 阻力与证据边界 产品审美仍由产品与设计人员判断；法规、渠道反馈需版本化，不能要求AI满足无边界需求。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 用历史被退回包装构建集，区分漏检与误报；确认每条规则依据和业务发布签审。 研究依据： - [Datawhale FDE案例100｜NO.19 从人工排队到审核前置：FDE用AI重构消费品研发协同与包装审核](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=186) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Datawhale FDE案例100｜NO.19 从人工排队到审核前置：FDE用AI重构消费品研发协同与包装审核](https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=186) - 发布方：Datawhale FDE100 - 披露性质：案例发布方披露 - 原记录查阅日期：2026-09-19 - [Datawhale FDE100 单案例网页｜NO.19](https://fde100.datawhale.cn/cases/cases-023) ## 字段边界 - business_problem：公开页面披露 - solution：公开页面披露 - architecture：依据公开方案结构化整理 - fde_actions：依据公开页面归纳 - result：案例发布方披露 ## 待核对事项 - 页面标记为 VERIFIED CASE / 审核通过。 - 公开页面未给统一量化结果。 ## 完整原始结构化记录 ```json { "id": "datawhale-024", "technical_reference": true, "source": "Datawhale", "company": "匿名食品消费品企业", "industry": "消费品/食品", "industry_group": "零售与消费", "scenario": "产品研发协同与包装智能审核", "fde": "明确FDE", "fde_relation": "明确FDE", "problem": "企业每年开发100多个SKU，包装审核涉及设计、法规、渠道和产品经理多方，重复检查形成排队瓶颈；研发与渠道经验分散在人脑和多个系统中。", "solution": "把包装审核拆成OCR/VLM理解、确定性规则代码、历史经验和人工判断四层；让Agent进入业务群持续识别问题并沉淀上下文，同时培养业务Builder自行搭建工作流。", "human": "AI预审错字、法规、NRV计算和渠道历史规则；产品经理、设计师及法规人员保留审美、定位、合规和最终发布责任。", "result": "形成包装预审、产品生命周期知识沉淀和业务Builder培养方案；Datawhale公开页面未披露统一量化收益。", "maturity": "落地/持续迭代", "maturity_stage": "已上线", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=186", "architecture": [ "产品需求、配方、设计稿、法规与渠道规则", "OCR/VLM解析包装内容", "确定性脚本校验错字、法规与NRV计算", "历史驳回与渠道反馈形成经验库", "AI预审后由专业人员判断", "结果、整改闭环与新经验持续沉淀" ], "components": [ "OCR/VLM", "规则代码", "知识库", "Agent/Skill/Workflow", "业务群上下文", "Human-in-the-loop" ], "fde_actions": [ "拆解包装审核中的确定性检查和专业判断", "把Agent放入业务群观察真实协作两到三周", "将驳回、整改和渠道反馈沉淀为规则", "设计AI架构师与AI HRBP双重角色", "通过黑客松培养业务人员成为Builder" ], "reusable": [ "高风险审核应让规则、模型和人分层负责", "让Agent观察真实协作可补足访谈遗漏", "把每次驳回变成下一次预审的上下文", "组织自我造血能力比一次性交付更重要" ], "evidence": "Datawhale FDE100审核通过的脱敏案例，公开了分层审核、Agent进群与Builder培养方案；未披露统一量化收益。", "case_summary": "这个案例把包装审核从多人排队检查改成AI前置预审，并把每次驳回和整改转化为下一次可复用的组织知识。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Datawhale FDE案例100｜NO.19 从人工排队到审核前置：FDE用AI重构消费品研发协同与包装审核", "publisher": "Datawhale FDE100", "url": "https://assets.datawhale.cn/Datawhale%20FDE%E6%A1%88%E4%BE%8B100.pdf#page=186", "source_type": "官方案例合集 PDF", "directness": "案例级直接来源", "claim_origin": "案例发布方披露", "independently_verified": false, "accessed_at": "2026-09-19", "collection_title": "Datawhale FDE案例100", "case_number": 19, "printed_page": 185, "pdf_page": 186 }, "analysis_boundary": { "business_problem": "公开页面披露", "solution": "公开页面披露", "architecture": "依据公开方案结构化整理", "fde_actions": "依据公开页面归纳", "result": "案例发布方披露" }, "verification_notes": [ "页面标记为 VERIFIED CASE / 审核通过。", "公开页面未给统一量化结果。" ], "additional_sources": [ { "title": "Datawhale FDE100 单案例网页｜NO.19", "url": "https://fde100.datawhale.cn/cases/cases-023" } ], "detail_score": 11, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "量化结果" ] } ``` --- # Tyson Foods｜ACE → dbt 数据平台迁移 - ID：palantir-001 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 旧数据平台迁移到dbt需要大规模理解、重写、编译和审查数据模型，原估计需10–15人约3年。 ## 解决方案 历史正确迁移作为golden examples → 向量检索相似案例 → LLM生成dbt → dbt语法/编译验证 → 人审 → GitLab合并，并把已批准迁移继续沉淀为上下文。 ## 技术工作流 > 公开信息与编辑推演混合 1. Legacy ACE models + 已人工翻译的 dbt golden examples 2. 代码内容向量化，建立历史迁移语义索引 3. 从已批准案例抽取迁移 rules/insights，并由人审核 4. 新 ACE model → Semantic Search 找最相似迁移案例 5. GPT-4o / AIP Logic 基于案例+规则生成 candidate dbt 6. Ontology SDK 调 dbt 做 syntax / compilation checks 7. Feedback Cockpit：工程师 approve 或 reject + comment 8. 批准后写入 GitLab，走标准 dbt testing / merge；新批准案例回到语义库 组件：Foundry、AIP / AIP Logic、GPT-4o、Vector Search / Embeddings、Ontology / Ontology SDK、dbt、GitLab、Human review ## 人机责任 工程师审核翻译、给反馈、批准合并。 ## FDE 动作 > FDE视角编辑推演 - 识别真正瓶颈不是“写代码慢”，而是成千上万次理解—翻译—验证—审查循环 - 收集历史正确迁移，定义什么是可作为 golden example 的训练外上下文 - 把迁移知识显式化为可审查 rules/insights，而不是依赖模型隐式记忆 - 把LLM接入dbt编译器和GitLab，让生成结果进入真实工程链路 - 设计Feedback Cockpit，把人工拒绝原因转为下一轮重译条件 - 把批准后的迁移重新沉淀，形成无需fine-tuning的context flywheel ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir公开称由原估计10–15人×3年，缩短到1人约3–4个月。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业Agent的“学习”可以来自不断增长的上下文，而不一定重新训练模型 - 历史成功案例 + 明确规则 + 确定性验证 + 人审，是高可靠Agent的通用组合 - FDE价值在于把一次性的AI生成改造成可持续生产流水线 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Tyson Foods：ACE → dbt 数据平台迁移](https://www.palantir.com/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 高：Palantir公开案例披露了 Seeding → Insights → Translation → Feedback/Harvesting 流程以及 dbt、GitLab、Ontology SDK 等组件。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-001", "source": "Palantir", "company": "Tyson Foods", "industry": "食品/制造", "scenario": "ACE → dbt 数据平台迁移", "fde": "典型Forward Deployed", "problem": "旧数据平台迁移到dbt需要大规模理解、重写、编译和审查数据模型，原估计需10–15人约3年。", "solution": "历史正确迁移作为golden examples → 向量检索相似案例 → LLM生成dbt → dbt语法/编译验证 → 人审 → GitLab合并，并把已批准迁移继续沉淀为上下文。", "human": "工程师审核翻译、给反馈、批准合并。", "result": "Palantir公开称由原估计10–15人×3年，缩短到1人约3–4个月。", "maturity": "生产级", "url": "https://www.palantir.com/", "architecture": [ "Legacy ACE models + 已人工翻译的 dbt golden examples", "代码内容向量化，建立历史迁移语义索引", "从已批准案例抽取迁移 rules/insights，并由人审核", "新 ACE model → Semantic Search 找最相似迁移案例", "GPT-4o / AIP Logic 基于案例+规则生成 candidate dbt", "Ontology SDK 调 dbt 做 syntax / compilation checks", "Feedback Cockpit：工程师 approve 或 reject + comment", "批准后写入 GitLab，走标准 dbt testing / merge；新批准案例回到语义库" ], "components": [ "Foundry", "AIP / AIP Logic", "GPT-4o", "Vector Search / Embeddings", "Ontology / Ontology SDK", "dbt", "GitLab", "Human review" ], "fde_actions": [ "识别真正瓶颈不是“写代码慢”，而是成千上万次理解—翻译—验证—审查循环", "收集历史正确迁移，定义什么是可作为 golden example 的训练外上下文", "把迁移知识显式化为可审查 rules/insights，而不是依赖模型隐式记忆", "把LLM接入dbt编译器和GitLab，让生成结果进入真实工程链路", "设计Feedback Cockpit，把人工拒绝原因转为下一轮重译条件", "把批准后的迁移重新沉淀，形成无需fine-tuning的context flywheel" ], "reusable": [ "企业Agent的“学习”可以来自不断增长的上下文，而不一定重新训练模型", "历史成功案例 + 明确规则 + 确定性验证 + 人审，是高可靠Agent的通用组合", "FDE价值在于把一次性的AI生成改造成可持续生产流水线" ], "evidence": "高：Palantir公开案例披露了 Seeding → Insights → Translation → Feedback/Harvesting 流程以及 dbt、GitLab、Ontology SDK 等组件。", "case_summary": "这个案例的关键不是单点使用AI，而是把“ACE → dbt 数据平台迁移”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Tyson Foods：ACE → dbt 数据平台迁移", "publisher": "Palantir", "url": "https://www.palantir.com/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "高：Palantir公开案例披露了 Seeding → Insights → Translation → Feedback/Harvesting 流程以及 dbt、GitLab、Ontology SDK 等组件。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "人机与治理", "来源可定位性" ] } ``` --- # General Mills｜供应链智能执行 Project ELF - ID：palantir-002 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级/规模化 - 独立核验：未记录 ## 业务问题 4,000供应商、200+工厂、约120万订单，运营人员每年进行约5,000万次供应链决策。 ## 解决方案 先将约200张主数据/运营表接入Ontology，再用AIP实时读取约束、产能、网络成本，对订单给出调度和节省建议。 ## 技术工作流 > 公开信息与编辑推演混合 1. 约200张主数据/运营表 + 订单/产能/成本/网络数据 2. Foundry数据管道统一清洗并建供应链Ontology 3. 每个订单映射到工厂、SKU、供应商、产能、运输等实体关系 4. AIP实时读取业务约束并识别可优化订单 5. 算法/AI生成重路由、调度或节省建议并估算财务影响 6. 供应链人员在工作台审核建议 7. 接受的动作进入执行流程；采纳/拒绝反馈回流 组件：Foundry、Ontology、AIP、供应链优化逻辑、运营工作台、Human-in-the-loop ## 人机责任 供应链人员审核建议；公开材料称>70%建议被接受。 ## FDE 动作 > FDE视角编辑推演 - 把5,000万次年度人工决策拆成可重复的订单级决策单元 - 统一200张表中的实体和口径，使模型能理解订单与真实网络关系 - 和业务共同定义不可违反的约束以及“好建议”的财务目标 - 将AI从“分析报告”推进到每日约400条可执行建议 - 用采纳率、日节省额和服务指标迭代建议质量 ## 业务结果与盈利口径 **来源披露金额或成本影响** 约3,000订单/日被评估，约400条建议/日，约$40K/日、$14M/年节省。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先建可行动的语义层，再谈Agent - 建议必须附带业务影响才能进入运营优先级 - 采纳率比离线模型accuracy更接近真正的产品指标 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [General Mills：供应链智能执行 Project ELF](https://www.palantir.com/assets/xrfr7uokpv1b/1aLBn65y83vdytjpXJKZcO/16989b788b34cb677f6d763d56a72349/Building_an_Intelligent_AI-Driven_Supply_Chain_at_General_Mills_-_AIPCon_March_-24_Impact_Study.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 高：Palantir AIPCon Impact Study公开了数据规模、Ontology、建议数量、采纳率和节省指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-002", "source": "Palantir", "company": "General Mills", "industry": "消费品/食品", "scenario": "供应链智能执行 Project ELF", "fde": "典型Forward Deployed", "problem": "4,000供应商、200+工厂、约120万订单，运营人员每年进行约5,000万次供应链决策。", "solution": "先将约200张主数据/运营表接入Ontology，再用AIP实时读取约束、产能、网络成本，对订单给出调度和节省建议。", "human": "供应链人员审核建议；公开材料称>70%建议被接受。", "result": "约3,000订单/日被评估，约400条建议/日，约$40K/日、$14M/年节省。", "maturity": "生产级/规模化", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/1aLBn65y83vdytjpXJKZcO/16989b788b34cb677f6d763d56a72349/Building_an_Intelligent_AI-Driven_Supply_Chain_at_General_Mills_-_AIPCon_March_-24_Impact_Study.pdf", "architecture": [ "约200张主数据/运营表 + 订单/产能/成本/网络数据", "Foundry数据管道统一清洗并建供应链Ontology", "每个订单映射到工厂、SKU、供应商、产能、运输等实体关系", "AIP实时读取业务约束并识别可优化订单", "算法/AI生成重路由、调度或节省建议并估算财务影响", "供应链人员在工作台审核建议", "接受的动作进入执行流程；采纳/拒绝反馈回流" ], "components": [ "Foundry", "Ontology", "AIP", "供应链优化逻辑", "运营工作台", "Human-in-the-loop" ], "fde_actions": [ "把5,000万次年度人工决策拆成可重复的订单级决策单元", "统一200张表中的实体和口径，使模型能理解订单与真实网络关系", "和业务共同定义不可违反的约束以及“好建议”的财务目标", "将AI从“分析报告”推进到每日约400条可执行建议", "用采纳率、日节省额和服务指标迭代建议质量" ], "reusable": [ "先建可行动的语义层，再谈Agent", "建议必须附带业务影响才能进入运营优先级", "采纳率比离线模型accuracy更接近真正的产品指标" ], "evidence": "高：Palantir AIPCon Impact Study公开了数据规模、Ontology、建议数量、采纳率和节省指标。", "case_summary": "这个案例的关键不是单点使用AI，而是把“供应链智能执行 Project ELF”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "General Mills：供应链智能执行 Project ELF", "publisher": "Palantir", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/1aLBn65y83vdytjpXJKZcO/16989b788b34cb677f6d763d56a72349/Building_an_Intelligent_AI-Driven_Supply_Chain_at_General_Mills_-_AIPCon_March_-24_Impact_Study.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "高：Palantir AIPCon Impact Study公开了数据规模、Ontology、建议数量、采纳率和节省指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Eaton｜供应链短缺识别与处置 - ID：palantir-003 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 100k+每日销售订单、300+工厂、32M+零件、72+ ERP实例，缺料与优先级判断复杂。 ## 解决方案 建立供应链Ontology，统一ERP视图；AIP按收入影响排序短缺，并参考历史处置自动提出材料建议。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/订单/库存/供应商/约束数据 2. 统一实体与业务口径 3. 预测/优化/LLM识别异常与候选动作 4. 规则与优化器计算可行方案 5. 业务人员确认高影响动作 6. 执行结果回写并更新库存/订单状态 组件：ERP/WMS数据、语义/实体层、预测/优化算法、LLM/AIP、规则引擎、业务工作台 ## 人机责任 供应链经理确认优先级和解决方案。 ## FDE 动作 > FDE视角编辑推演 - 和计划/采购/调度人员一起定义真正的决策单位和约束 - 统一SKU、工厂、订单、供应商等实体口径 - 把“看报表”改成“识别异常→给动作→执行”的闭环 - 用财务影响/服务水平给建议排序 - 把人工采纳/拒绝原因反馈给系统 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir公开称生产率提升25%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Eaton：供应链短缺识别与处置](https://www.palantir.com/assets/xrfr7uokpv1b/5fyrfyRAFBtNSIBSWGc9xI/0741a1e422a8cacf1676dde769fb7102/One-Pager_-_Supply_Chain_Risk_Resilience.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-003", "source": "Palantir", "company": "Eaton", "industry": "工业制造", "scenario": "供应链短缺识别与处置", "fde": "典型Forward Deployed", "problem": "100k+每日销售订单、300+工厂、32M+零件、72+ ERP实例，缺料与优先级判断复杂。", "solution": "建立供应链Ontology，统一ERP视图；AIP按收入影响排序短缺，并参考历史处置自动提出材料建议。", "human": "供应链经理确认优先级和解决方案。", "result": "Palantir公开称生产率提升25%。", "maturity": "生产级", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/5fyrfyRAFBtNSIBSWGc9xI/0741a1e422a8cacf1676dde769fb7102/One-Pager_-_Supply_Chain_Risk_Resilience.pdf", "architecture": [ "ERP/WMS/订单/库存/供应商/约束数据", "统一实体与业务口径", "预测/优化/LLM识别异常与候选动作", "规则与优化器计算可行方案", "业务人员确认高影响动作", "执行结果回写并更新库存/订单状态" ], "components": [ "ERP/WMS数据", "语义/实体层", "预测/优化算法", "LLM/AIP", "规则引擎", "业务工作台" ], "fde_actions": [ "和计划/采购/调度人员一起定义真正的决策单位和约束", "统一SKU、工厂、订单、供应商等实体口径", "把“看报表”改成“识别异常→给动作→执行”的闭环", "用财务影响/服务水平给建议排序", "把人工采纳/拒绝原因反馈给系统" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“供应链短缺识别与处置”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Eaton：供应链短缺识别与处置", "publisher": "Palantir", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/5fyrfyRAFBtNSIBSWGc9xI/0741a1e422a8cacf1676dde769fb7102/One-Pager_-_Supply_Chain_Risk_Resilience.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Panasonic Energy North America｜Electrode Control Tower - ID：palantir-004 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 电极制造过程的多步骤判断与现场数据查看高度人工化。 ## 解决方案 Foundry/AIP把制造数据、流程和决策集中在一个控制塔中，实现快速判断与部分自动化。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 现场工程师保留关键生产处置。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 首个用例1个月交付；一个约4小时的多步骤流程降至约15分钟，并减少材料浪费。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Panasonic Energy North America：Electrode Control Tower](https://investors.palantir.com/files/Palantir%20Q2%202023%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-004", "source": "Palantir", "company": "Panasonic Energy North America", "industry": "电池/制造", "scenario": "Electrode Control Tower", "fde": "典型Forward Deployed", "problem": "电极制造过程的多步骤判断与现场数据查看高度人工化。", "solution": "Foundry/AIP把制造数据、流程和决策集中在一个控制塔中，实现快速判断与部分自动化。", "human": "现场工程师保留关键生产处置。", "result": "首个用例1个月交付；一个约4小时的多步骤流程降至约15分钟，并减少材料浪费。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q2%202023%20Business%20Update.pdf", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“Electrode Control Tower”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Panasonic Energy North America：Electrode Control Tower", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q2%202023%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Tampa General Hospital｜患者流 / 排班 / Sepsis管理 - ID：palantir-005 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级/规模化 - 独立核验：未记录 ## 业务问题 医院数据分散，患者流、人员配置和临床运营决策需要实时统一视图。 ## 解决方案 用Foundry Ontology整合关键数据，做预测规划、人员配置与患者流优化；在飓风Ian期间24小时内扩展出患者/医护360°实时视图。 ## 技术工作流 > 公开信息与编辑推演混合 1. EHR/床位/人员/运营事件数据 2. 统一患者与运营实体 3. 实时状态 + 预测/规则/AI分析 4. 按临床/运营优先级产生建议 5. 医护/运营人员确认与执行 6. 结果回写并持续监测 组件：医疗数据集成、Ontology/统一实体、预测/规则/AI、权限审计、临床/运营工作台 ## 人机责任 临床和运营团队基于建议做最终安排。 ## FDE 动作 > FDE视角编辑推演 - 与临床/运营团队共同定义问题和安全边界 - 先解决可度量的运营瓶颈，避免让AI承担诊断责任 - 打通数据权限与实时更新 - 设计告警、建议和人工确认机制 - 用住院时长、床位周转等业务指标验收 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 后续公开资料称Sepsis患者住院时长降低约15%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 医疗AI先从运营闭环切入通常更容易量化 - 临床责任必须留在人类专业人员 - 权限、审计、实时性和数据质量与模型同等重要 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Tampa General Hospital：患者流 / 排班 / Sepsis管理](https://investors.palantir.com/news-details/2022/Tampa-General-Hospital-and-Palantir-Partner-to-Improve-Patient-Care-Through-Data-and-Analytics-Platform) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-005", "source": "Palantir", "company": "Tampa General Hospital", "industry": "医疗", "scenario": "患者流 / 排班 / Sepsis管理", "fde": "典型Forward Deployed", "problem": "医院数据分散，患者流、人员配置和临床运营决策需要实时统一视图。", "solution": "用Foundry Ontology整合关键数据，做预测规划、人员配置与患者流优化；在飓风Ian期间24小时内扩展出患者/医护360°实时视图。", "human": "临床和运营团队基于建议做最终安排。", "result": "后续公开资料称Sepsis患者住院时长降低约15%。", "maturity": "生产级/规模化", "url": "https://investors.palantir.com/news-details/2022/Tampa-General-Hospital-and-Palantir-Partner-to-Improve-Patient-Care-Through-Data-and-Analytics-Platform", "architecture": [ "EHR/床位/人员/运营事件数据", "统一患者与运营实体", "实时状态 + 预测/规则/AI分析", "按临床/运营优先级产生建议", "医护/运营人员确认与执行", "结果回写并持续监测" ], "components": [ "医疗数据集成", "Ontology/统一实体", "预测/规则/AI", "权限审计", "临床/运营工作台" ], "fde_actions": [ "与临床/运营团队共同定义问题和安全边界", "先解决可度量的运营瓶颈，避免让AI承担诊断责任", "打通数据权限与实时更新", "设计告警、建议和人工确认机制", "用住院时长、床位周转等业务指标验收" ], "reusable": [ "医疗AI先从运营闭环切入通常更容易量化", "临床责任必须留在人类专业人员", "权限、审计、实时性和数据质量与模型同等重要" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“患者流 / 排班 / Sepsis管理”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Tampa General Hospital：患者流 / 排班 / Sepsis管理", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2022/Tampa-General-Hospital-and-Palantir-Partner-to-Improve-Patient-Care-Through-Data-and-Analytics-Platform", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Aramark｜产品匹配与餐食数据分类 - ID：palantir-006 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 产品、配方、供应和销售数据分散，产品匹配与分类依赖大量人工。 ## 解决方案 统一数据模型与Ontology，使用AI做产品匹配和分类，低置信度项目交人工。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 人工处理少数无法自动归类项目。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 9个月内约99%的meal data elements实现自动分类。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Aramark：产品匹配与餐食数据分类](https://www.palantir.com/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-006", "source": "Palantir", "company": "Aramark", "industry": "餐饮/服务", "scenario": "产品匹配与餐食数据分类", "fde": "典型Forward Deployed", "problem": "产品、配方、供应和销售数据分散，产品匹配与分类依赖大量人工。", "solution": "统一数据模型与Ontology，使用AI做产品匹配和分类，低置信度项目交人工。", "human": "人工处理少数无法自动归类项目。", "result": "9个月内约99%的meal data elements实现自动分类。", "maturity": "生产级", "url": "https://www.palantir.com/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“产品匹配与餐食数据分类”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Aramark：产品匹配与餐食数据分类", "publisher": "Palantir", "url": "https://www.palantir.com/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Associated Materials｜多业务用例 / OTIF提升 - ID：palantir-007 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 制造与履约数据碎片化，多个业务流程缺乏统一决策底座。 ## 解决方案 在Foundry/AIP上连续开发十余个运营用例，统一计划与执行。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/历史变更/需求 2. 检索相关文件与历史正确样例 3. LLM/Coding Agent生成修改 4. 编译/测试/Lint等确定性验证 5. 工程师Review与反馈 6. Git/CI合并 → 已批准变更成为新上下文 组件：代码检索、Coding Agent/LLM、编译器/测试框架、Git/CI/CD、Human code review ## 人机责任 运营团队在统一工作流中执行。 ## FDE 动作 > FDE视角编辑推演 - 盘点代码库、依赖关系、测试体系与发布流程 - 把历史正确改动作为golden examples，而不是只写prompt - 为Agent接上编译、测试、Git等可验证工具 - 定义哪些修改可以自动推进、哪些必须人工Review - 将被批准的变更和反馈持续沉淀 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir公开称9个月内上线10+用例，OTIF从40%提升到90%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型 - 优先使用编译/测试这种确定性反馈 - 批准后的结果形成学习飞轮 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Associated Materials：多业务用例 / OTIF提升](https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-007", "source": "Palantir", "company": "Associated Materials", "industry": "建材/制造", "scenario": "多业务用例 / OTIF提升", "fde": "典型Forward Deployed", "problem": "制造与履约数据碎片化，多个业务流程缺乏统一决策底座。", "solution": "在Foundry/AIP上连续开发十余个运营用例，统一计划与执行。", "human": "运营团队在统一工作流中执行。", "result": "Palantir公开称9个月内上线10+用例，OTIF从40%提升到90%。", "maturity": "规模化", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "architecture": [ "代码库/历史变更/需求", "检索相关文件与历史正确样例", "LLM/Coding Agent生成修改", "编译/测试/Lint等确定性验证", "工程师Review与反馈", "Git/CI合并 → 已批准变更成为新上下文" ], "components": [ "代码检索", "Coding Agent/LLM", "编译器/测试框架", "Git/CI/CD", "Human code review" ], "fde_actions": [ "盘点代码库、依赖关系、测试体系与发布流程", "把历史正确改动作为golden examples，而不是只写prompt", "为Agent接上编译、测试、Git等可验证工具", "定义哪些修改可以自动推进、哪些必须人工Review", "将被批准的变更和反馈持续沉淀" ], "reusable": [ "编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型", "优先使用编译/测试这种确定性反馈", "批准后的结果形成学习飞轮" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“多业务用例 / OTIF提升”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Associated Materials：多业务用例 / OTIF提升", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Trinity Rail｜库存优化 - ID：palantir-008 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 库存资金占用与跨业务库存决策复杂。 ## 解决方案 用AIP构建库存工作流，统一库存事实、异常与决策动作。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/订单/库存/供应商/约束数据 2. 统一实体与业务口径 3. 预测/优化/LLM识别异常与候选动作 4. 规则与优化器计算可行方案 5. 业务人员确认高影响动作 6. 执行结果回写并更新库存/订单状态 组件：ERP/WMS数据、语义/实体层、预测/优化算法、LLM/AIP、规则引擎、业务工作台 ## 人机责任 供应链与运营人员审批执行。 ## FDE 动作 > FDE视角编辑推演 - 和计划/采购/调度人员一起定义真正的决策单位和约束 - 统一SKU、工厂、订单、供应商等实体口径 - 把“看报表”改成“识别异常→给动作→执行”的闭环 - 用财务影响/服务水平给建议排序 - 把人工采纳/拒绝原因反馈给系统 ## 业务结果与盈利口径 **来源披露金额或成本影响** 3个月构建，公开称带来约$30M节省并改善运营利润率。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Trinity Rail：库存优化](https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-008", "source": "Palantir", "company": "Trinity Rail", "industry": "铁路/制造", "scenario": "库存优化", "fde": "典型Forward Deployed", "problem": "库存资金占用与跨业务库存决策复杂。", "solution": "用AIP构建库存工作流，统一库存事实、异常与决策动作。", "human": "供应链与运营人员审批执行。", "result": "3个月构建，公开称带来约$30M节省并改善运营利润率。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "architecture": [ "ERP/WMS/订单/库存/供应商/约束数据", "统一实体与业务口径", "预测/优化/LLM识别异常与候选动作", "规则与优化器计算可行方案", "业务人员确认高影响动作", "执行结果回写并更新库存/订单状态" ], "components": [ "ERP/WMS数据", "语义/实体层", "预测/优化算法", "LLM/AIP", "规则引擎", "业务工作台" ], "fde_actions": [ "和计划/采购/调度人员一起定义真正的决策单位和约束", "统一SKU、工厂、订单、供应商等实体口径", "把“看报表”改成“识别异常→给动作→执行”的闭环", "用财务影响/服务水平给建议排序", "把人工采纳/拒绝原因反馈给系统" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“库存优化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Trinity Rail：库存优化", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Nebraska Medicine｜Discharge Lounge / 床位周转 - ID：palantir-009 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 患者出院后床位释放不及时，影响医院容量。 ## 解决方案 将出院、床位与患者流程数据集中，优化Discharge Lounge使用和床位释放。 ## 技术工作流 > 公开信息与编辑推演混合 1. EHR/床位/人员/运营事件数据 2. 统一患者与运营实体 3. 实时状态 + 预测/规则/AI分析 4. 按临床/运营优先级产生建议 5. 医护/运营人员确认与执行 6. 结果回写并持续监测 组件：医疗数据集成、Ontology/统一实体、预测/规则/AI、权限审计、临床/运营工作台 ## 人机责任 医护与运营团队执行调度。 ## FDE 动作 > FDE视角编辑推演 - 与临床/运营团队共同定义问题和安全边界 - 先解决可度量的运营瓶颈，避免让AI承担诊断责任 - 打通数据权限与实时更新 - 设计告警、建议和人工确认机制 - 用住院时长、床位周转等业务指标验收 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开称Discharge Lounge利用率提升超过2,000%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 医疗AI先从运营闭环切入通常更容易量化 - 临床责任必须留在人类专业人员 - 权限、审计、实时性和数据质量与模型同等重要 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Nebraska Medicine：Discharge Lounge / 床位周转](https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-009", "source": "Palantir", "company": "Nebraska Medicine", "industry": "医疗", "scenario": "Discharge Lounge / 床位周转", "fde": "典型Forward Deployed", "problem": "患者出院后床位释放不及时，影响医院容量。", "solution": "将出院、床位与患者流程数据集中，优化Discharge Lounge使用和床位释放。", "human": "医护与运营团队执行调度。", "result": "公开称Discharge Lounge利用率提升超过2,000%。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "architecture": [ "EHR/床位/人员/运营事件数据", "统一患者与运营实体", "实时状态 + 预测/规则/AI分析", "按临床/运营优先级产生建议", "医护/运营人员确认与执行", "结果回写并持续监测" ], "components": [ "医疗数据集成", "Ontology/统一实体", "预测/规则/AI", "权限审计", "临床/运营工作台" ], "fde_actions": [ "与临床/运营团队共同定义问题和安全边界", "先解决可度量的运营瓶颈，避免让AI承担诊断责任", "打通数据权限与实时更新", "设计告警、建议和人工确认机制", "用住院时长、床位周转等业务指标验收" ], "reusable": [ "医疗AI先从运营闭环切入通常更容易量化", "临床责任必须留在人类专业人员", "权限、审计、实时性和数据质量与模型同等重要" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“Discharge Lounge / 床位周转”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Nebraska Medicine：Discharge Lounge / 床位周转", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 0, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Mount Sinai｜临床/运营流程效率 - ID：palantir-010 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 关键临床运营流程消耗大量人工并限制周转。 ## 解决方案 用Foundry/AIP重构数据与运营流程。 ## 技术工作流 > 公开信息与编辑推演混合 1. EHR/床位/人员/运营事件数据 2. 统一患者与运营实体 3. 实时状态 + 预测/规则/AI分析 4. 按临床/运营优先级产生建议 5. 医护/运营人员确认与执行 6. 结果回写并持续监测 组件：医疗数据集成、Ontology/统一实体、预测/规则/AI、权限审计、临床/运营工作台 ## 人机责任 医护和业务团队保留临床责任。 ## FDE 动作 > FDE视角编辑推演 - 与临床/运营团队共同定义问题和安全边界 - 先解决可度量的运营瓶颈，避免让AI承担诊断责任 - 打通数据权限与实时更新 - 设计告警、建议和人工确认机制 - 用住院时长、床位周转等业务指标验收 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** 公开称实现100% FTE效率提升，并预计新增>$13M收入。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 医疗AI先从运营闭环切入通常更容易量化 - 临床责任必须留在人类专业人员 - 权限、审计、实时性和数据质量与模型同等重要 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Mount Sinai：临床/运营流程效率](https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-010", "source": "Palantir", "company": "Mount Sinai", "industry": "医疗", "scenario": "临床/运营流程效率", "fde": "典型Forward Deployed", "problem": "关键临床运营流程消耗大量人工并限制周转。", "solution": "用Foundry/AIP重构数据与运营流程。", "human": "医护和业务团队保留临床责任。", "result": "公开称实现100% FTE效率提升，并预计新增>$13M收入。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "architecture": [ "EHR/床位/人员/运营事件数据", "统一患者与运营实体", "实时状态 + 预测/规则/AI分析", "按临床/运营优先级产生建议", "医护/运营人员确认与执行", "结果回写并持续监测" ], "components": [ "医疗数据集成", "Ontology/统一实体", "预测/规则/AI", "权限审计", "临床/运营工作台" ], "fde_actions": [ "与临床/运营团队共同定义问题和安全边界", "先解决可度量的运营瓶颈，避免让AI承担诊断责任", "打通数据权限与实时更新", "设计告警、建议和人工确认机制", "用住院时长、床位周转等业务指标验收" ], "reusable": [ "医疗AI先从运营闭环切入通常更容易量化", "临床责任必须留在人类专业人员", "权限、审计、实时性和数据质量与模型同等重要" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“临床/运营流程效率”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Mount Sinai：临床/运营流程效率", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202024%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # United Airlines｜技术运营延误预防 Chime - ID：palantir-011 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：概览案例｜作为线索使用（6/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 航班技术运营事件需要跨数据源快速识别与协调，延误/取消成本高。 ## 解决方案 在Foundry/AIP上构建事件识别与协同应用Chime。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 技术运营团队判断并执行处置。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **来源披露金额或成本影响** 公开称已避免近300次延误、20次取消，对应数百万美元成本避免。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [United Airlines：技术运营延误预防 Chime](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-011", "source": "Palantir", "company": "United Airlines", "industry": "航空/旅行", "scenario": "技术运营延误预防 Chime", "fde": "典型Forward Deployed", "problem": "航班技术运营事件需要跨数据源快速识别与协调，延误/取消成本高。", "solution": "在Foundry/AIP上构建事件识别与协同应用Chime。", "human": "技术运营团队判断并执行处置。", "result": "公开称已避免近300次延误、20次取消，对应数百万美元成本避免。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“技术运营延误预防 Chime”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "United Airlines：技术运营延误预防 Chime", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] } ``` --- # Fujitsu｜预测、库存与告警 - ID：palantir-012 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 运营数据与机器学习能力分散，难以直接进入日常运营。 ## 解决方案 把Foundry数据集成能力与Fujitsu ML结合，构建告警、需求预测和库存控制。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/订单/库存/供应商/约束数据 2. 统一实体与业务口径 3. 预测/优化/LLM识别异常与候选动作 4. 规则与优化器计算可行方案 5. 业务人员确认高影响动作 6. 执行结果回写并更新库存/订单状态 组件：ERP/WMS数据、语义/实体层、预测/优化算法、LLM/AIP、规则引擎、业务工作台 ## 人机责任 运营人员使用预测和告警做决策。 ## FDE 动作 > FDE视角编辑推演 - 和计划/采购/调度人员一起定义真正的决策单位和约束 - 统一SKU、工厂、订单、供应商等实体口径 - 把“看报表”改成“识别异常→给动作→执行”的闭环 - 用财务影响/服务水平给建议排序 - 把人工采纳/拒绝原因反馈给系统 ## 业务结果与盈利口径 **来源披露金额或成本影响** 公开称3个月实现约$9M年化成本降低。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Fujitsu：预测、库存与告警](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 - [Palantir Q2 2024 客户引述](https://investors.palantir.com/files/Palantir%20Q2%202024%20Business%20Update.pdf) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-012", "source": "Palantir", "company": "Fujitsu", "industry": "科技/制造", "scenario": "预测、库存与告警", "fde": "典型Forward Deployed", "problem": "运营数据与机器学习能力分散，难以直接进入日常运营。", "solution": "把Foundry数据集成能力与Fujitsu ML结合，构建告警、需求预测和库存控制。", "human": "运营人员使用预测和告警做决策。", "result": "公开称3个月实现约$9M年化成本降低。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "ERP/WMS/订单/库存/供应商/约束数据", "统一实体与业务口径", "预测/优化/LLM识别异常与候选动作", "规则与优化器计算可行方案", "业务人员确认高影响动作", "执行结果回写并更新库存/订单状态" ], "components": [ "ERP/WMS数据", "语义/实体层", "预测/优化算法", "LLM/AIP", "规则引擎", "业务工作台" ], "fde_actions": [ "和计划/采购/调度人员一起定义真正的决策单位和约束", "统一SKU、工厂、订单、供应商等实体口径", "把“看报表”改成“识别异常→给动作→执行”的闭环", "用财务影响/服务水平给建议排序", "把人工采纳/拒绝原因反馈给系统" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“预测、库存与告警”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Fujitsu：预测、库存与告警", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "Palantir Q2 2024 客户引述", "url": "https://investors.palantir.com/files/Palantir%20Q2%202024%20Business%20Update.pdf" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Jacobs｜工厂能耗与动态维护 - ID：palantir-013 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级/扩张 - 独立核验：未记录 ## 业务问题 工业现场能耗、化学品使用和维护决策与传感数据脱节。 ## 解决方案 在Foundry中连接预测AI与日常现场操作，做过程优化和动态维护。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 现场工程团队决定最终操作。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 试点站点6个月实现约20%年度全厂能耗降低。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Jacobs：工厂能耗与动态维护](https://investors.palantir.com/news-details/2023/Palantir-Launches-Foundry-for-Manufacturing-on-AWS-to-the-Broader-Market/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-013", "source": "Palantir", "company": "Jacobs", "industry": "工程/工业", "scenario": "工厂能耗与动态维护", "fde": "典型Forward Deployed", "problem": "工业现场能耗、化学品使用和维护决策与传感数据脱节。", "solution": "在Foundry中连接预测AI与日常现场操作，做过程优化和动态维护。", "human": "现场工程团队决定最终操作。", "result": "试点站点6个月实现约20%年度全厂能耗降低。", "maturity": "生产级/扩张", "url": "https://investors.palantir.com/news-details/2023/Palantir-Launches-Foundry-for-Manufacturing-on-AWS-to-the-Broader-Market/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“工厂能耗与动态维护”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Jacobs：工厂能耗与动态维护", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2023/Palantir-Launches-Foundry-for-Manufacturing-on-AWS-to-the-Broader-Market/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Walgreens｜药房端到端AI工作流 - ID：palantir-014 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：大规模部署 - 独立核验：未记录 ## 业务问题 原计划小规模试点，药房运营需要跨门店、流程与系统快速扩张。 ## 解决方案 Foundry/AIP组合端到端工作流，从试点直接扩展到大量门店。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 药房和运营团队执行与审核。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开称原计划6个月10家试点，约8个月扩到约4,000家门店。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Walgreens：药房端到端AI工作流](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-014", "source": "Palantir", "company": "Walgreens", "industry": "零售/医疗", "scenario": "药房端到端AI工作流", "fde": "典型Forward Deployed", "problem": "原计划小规模试点，药房运营需要跨门店、流程与系统快速扩张。", "solution": "Foundry/AIP组合端到端工作流，从试点直接扩展到大量门店。", "human": "药房和运营团队执行与审核。", "result": "公开称原计划6个月10家试点，约8个月扩到约4,000家门店。", "maturity": "大规模部署", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“药房端到端AI工作流”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Walgreens：药房端到端AI工作流", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Lowe's｜AI运营应用从POC到生产 - ID：palantir-015 - 行业：零售与消费 - 来源：Palantir - 详细度：概览案例｜作为线索使用（6/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 零售场景需要快速把AI试点变成真实生产工作流。 ## 解决方案 Palantir与业务/数据团队共同将数据、模型和操作界面组合成生产应用。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 业务团队持续使用并反馈。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开称不到4个月从POC推进到生产。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Lowe's：AI运营应用从POC到生产](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-015", "source": "Palantir", "company": "Lowe's", "industry": "零售", "scenario": "AI运营应用从POC到生产", "fde": "典型Forward Deployed", "problem": "零售场景需要快速把AI试点变成真实生产工作流。", "solution": "Palantir与业务/数据团队共同将数据、模型和操作界面组合成生产应用。", "human": "业务团队持续使用并反馈。", "result": "公开称不到4个月从POC推进到生产。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“AI运营应用从POC到生产”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Lowe's：AI运营应用从POC到生产", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Virgin Atlantic｜遗留代码重构与移动App质量 - ID：openai-001 - 行业：交通、旅行与物流 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 航空App上线窗口风险高，遗留代码重构和测试覆盖需要大量时间。 ## 解决方案 使用Codex加强测试覆盖、重构legacy code，并让分析团队直接在数据仓库上构建工具。 ## 技术工作流 > 公开信息与编辑推演混合 1. 大型移动App代码库 + issue/需求 + 既有测试 2. Codex读取相关代码与依赖上下文 3. 生成/修改legacy code并补充单元测试 4. 本地/CI测试与静态检查 5. 工程师review、修正和批准 6. 合并进入发布流水线；新测试提高后续Agent可验证性 组件：Codex、代码库上下文、单元测试、CI/CD、Human code review ## 人机责任 工程师审核代码、测试与上线；生产责任仍由航空公司团队承担。 ## FDE 动作 > FDE视角编辑推演 - 选择发布风险最高、又能被测试验证的工程任务切入 - 帮助团队把Codex接入真实repo和工程习惯，而不是孤立聊天 - 把测试覆盖率作为Agent工作的护栏 - 让分析/工程人员直接在原数据和代码环境工作 - 以重构周期、测试覆盖和P1缺陷等生产指标验收 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 遗留重构从约2周降到约30分钟；新App接近100%单测覆盖，发布时0个P1缺陷。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先补测试，再扩大coding agent自治范围 - 代码场景非常适合“生成→确定性测试→人审”的Agent闭环 - 衡量上线质量而不是只看代码生成速度 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Virgin Atlantic：遗留代码重构与移动App质量](https://openai.com/index/virgin-atlantic/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 高：OpenAI客户案例公开披露约2周→30分钟、接近100%单测覆盖、0个P1缺陷等结果。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-001", "source": "OpenAI", "company": "Virgin Atlantic", "industry": "航空/旅行", "scenario": "遗留代码重构与移动App质量", "fde": "企业部署案例", "problem": "航空App上线窗口风险高，遗留代码重构和测试覆盖需要大量时间。", "solution": "使用Codex加强测试覆盖、重构legacy code，并让分析团队直接在数据仓库上构建工具。", "human": "工程师审核代码、测试与上线；生产责任仍由航空公司团队承担。", "result": "遗留重构从约2周降到约30分钟；新App接近100%单测覆盖，发布时0个P1缺陷。", "maturity": "生产级", "url": "https://openai.com/index/virgin-atlantic/", "architecture": [ "大型移动App代码库 + issue/需求 + 既有测试", "Codex读取相关代码与依赖上下文", "生成/修改legacy code并补充单元测试", "本地/CI测试与静态检查", "工程师review、修正和批准", "合并进入发布流水线；新测试提高后续Agent可验证性" ], "components": [ "Codex", "代码库上下文", "单元测试", "CI/CD", "Human code review" ], "fde_actions": [ "选择发布风险最高、又能被测试验证的工程任务切入", "帮助团队把Codex接入真实repo和工程习惯，而不是孤立聊天", "把测试覆盖率作为Agent工作的护栏", "让分析/工程人员直接在原数据和代码环境工作", "以重构周期、测试覆盖和P1缺陷等生产指标验收" ], "reusable": [ "先补测试，再扩大coding agent自治范围", "代码场景非常适合“生成→确定性测试→人审”的Agent闭环", "衡量上线质量而不是只看代码生成速度" ], "evidence": "高：OpenAI客户案例公开披露约2周→30分钟、接近100%单测覆盖、0个P1缺陷等结果。", "case_summary": "这个案例的关键不是单点使用AI，而是把“遗留代码重构与移动App质量”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Virgin Atlantic：遗留代码重构与移动App质量", "publisher": "OpenAI", "url": "https://openai.com/index/virgin-atlantic/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "高：OpenAI客户案例公开披露约2周→30分钟、接近100%单测覆盖、0个P1缺陷等结果。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Virgin Atlantic｜客户旅程研究与产品规划 - ID：openai-002 - 行业：交通、旅行与物流 - 来源：OpenAI - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 浏览、购买、值机、乘机、反馈等客户旅程信息分散在不同系统与报告中。 ## 解决方案 ChatGPT Work帮助团队汇集信息、做竞品研究、产品规划与分析，将洞察转为行动。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 产品和管理团队决定优先级与战略。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开称将数周研究缩短至数小时。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Virgin Atlantic：客户旅程研究与产品规划](https://openai.com/index/virgin-atlantic/chatgpt-work/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-002", "source": "OpenAI", "company": "Virgin Atlantic", "industry": "航空/旅行", "scenario": "客户旅程研究与产品规划", "fde": "企业部署案例", "problem": "浏览、购买、值机、乘机、反馈等客户旅程信息分散在不同系统与报告中。", "solution": "ChatGPT Work帮助团队汇集信息、做竞品研究、产品规划与分析，将洞察转为行动。", "human": "产品和管理团队决定优先级与战略。", "result": "公开称将数周研究缩短至数小时。", "maturity": "生产级", "url": "https://openai.com/index/virgin-atlantic/chatgpt-work/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“客户旅程研究与产品规划”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Virgin Atlantic：客户旅程研究与产品规划", "publisher": "OpenAI", "url": "https://openai.com/index/virgin-atlantic/chatgpt-work/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # MUFG｜全员AI助手 / 零售金融创新 - ID：openai-003 - 行业：金融与保险 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：大规模部署 - 独立核验：未记录 ## 业务问题 大型金融集团需要在治理、安全和大规模员工采用之间取得平衡。 ## 解决方案 ChatGPT Enterprise面向约35,000名三菱UFJ银行员工部署，并与OpenAI共同推进运营转型和零售客户体验。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 员工和业务部门在治理框架下使用AI。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 约35,000名员工部署使用。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [MUFG：全员AI助手 / 零售金融创新](https://openai.com/index/mufg/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-003", "source": "OpenAI", "company": "MUFG", "industry": "金融", "scenario": "全员AI助手 / 零售金融创新", "fde": "企业部署案例", "problem": "大型金融集团需要在治理、安全和大规模员工采用之间取得平衡。", "solution": "ChatGPT Enterprise面向约35,000名三菱UFJ银行员工部署，并与OpenAI共同推进运营转型和零售客户体验。", "human": "员工和业务部门在治理框架下使用AI。", "result": "约35,000名员工部署使用。", "maturity": "大规模部署", "url": "https://openai.com/index/mufg/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“全员AI助手 / 零售金融创新”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "MUFG：全员AI助手 / 零售金融创新", "publisher": "OpenAI", "url": "https://openai.com/index/mufg/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 0, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理", "量化结果" ] } ``` --- # Samsung Electronics｜研发、制造、营销与软件开发 - ID：openai-004 - 行业：制造与工业 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：大规模部署 - 独立核验：未记录 ## 业务问题 需要把通用AI和编码Agent安全扩展到全球复杂组织。 ## 解决方案 ChatGPT Enterprise与Codex覆盖韩国全员及全球DX部门，并用于软件、营销、产品开发和制造。 ## 技术工作流 > 公开信息与编辑推演混合 1. 商品/门店/达人/品牌资料 2. 结构化素材与品牌规则 3. LLM/多模态生成候选内容或邀约 4. 合规/品牌规则检查 5. 运营人员审核与发布 6. 表现数据回流用于模板与策略迭代 组件：内容数据、LLM/多模态模型、模板/品牌规则、审核工作台、发布/CRM系统 ## 人机责任 各职能团队使用AI并保留专业决策。 ## FDE 动作 > FDE视角编辑推演 - 从运营人员真实产能瓶颈出发选择批量化环节 - 将品牌语气、禁用词、商品事实结构化 - 把生成拆成可控模板和可编辑步骤 - 接入审核/发布/CRM，而不是单独做生成页面 - 跟踪采纳率、发布量和业务转化而非只看生成质量 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** OpenAI称这是其规模最大的企业部署之一。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型 - 优先使用编译/测试这种确定性反馈 - 批准后的结果形成学习飞轮 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Samsung Electronics：研发、制造、营销与软件开发](https://openai.com/index/samsung-electronics-chatgpt-codex-deployment/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-004", "source": "OpenAI", "company": "Samsung Electronics", "industry": "电子/制造", "scenario": "研发、制造、营销与软件开发", "fde": "企业部署案例", "problem": "需要把通用AI和编码Agent安全扩展到全球复杂组织。", "solution": "ChatGPT Enterprise与Codex覆盖韩国全员及全球DX部门，并用于软件、营销、产品开发和制造。", "human": "各职能团队使用AI并保留专业决策。", "result": "OpenAI称这是其规模最大的企业部署之一。", "maturity": "大规模部署", "url": "https://openai.com/index/samsung-electronics-chatgpt-codex-deployment/", "architecture": [ "商品/门店/达人/品牌资料", "结构化素材与品牌规则", "LLM/多模态生成候选内容或邀约", "合规/品牌规则检查", "运营人员审核与发布", "表现数据回流用于模板与策略迭代" ], "components": [ "内容数据", "LLM/多模态模型", "模板/品牌规则", "审核工作台", "发布/CRM系统" ], "fde_actions": [ "从运营人员真实产能瓶颈出发选择批量化环节", "将品牌语气、禁用词、商品事实结构化", "把生成拆成可控模板和可编辑步骤", "接入审核/发布/CRM，而不是单独做生成页面", "跟踪采纳率、发布量和业务转化而非只看生成质量" ], "reusable": [ "编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型", "优先使用编译/测试这种确定性反馈", "批准后的结果形成学习飞轮" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“研发、制造、营销与软件开发”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Samsung Electronics：研发、制造、营销与软件开发", "publisher": "OpenAI", "url": "https://openai.com/index/samsung-electronics-chatgpt-codex-deployment/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Chip Ganassi Racing｜比赛日数据与策略工具 - ID：openai-005 - 行业：媒体、营销与体育 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：生产/现场使用 - 独立核验：未记录 ## 业务问题 赛车拥有200+传感器，比赛每小时接近10亿数据点，工程师需要在比赛中快速读取并连接信息。 ## 解决方案 OpenAI研究人员与FDE直接和车队共建race-day tools，把实时数据、分析与工程师工作流连接起来。 ## 技术工作流 > 公开信息与编辑推演混合 1. 赛车200+传感器 + 实时遥测/历史比赛数据 2. 数据流标准化与可访问接口 3. FDE/研究团队和车队共同定义比赛日问题 4. AI工具按工程师问题调用/汇总相关数据并生成分析 5. 工程师与策略团队结合赛况做最终决策 6. 比赛后复盘，把新问题和工具需求反馈到下一轮 组件：实时遥测数据、分析/检索工具、OpenAI模型、比赛日工作台、Human-in-the-loop ## 人机责任 赛车工程师与策略团队做最终比赛决策。 ## FDE 动作 > FDE视角编辑推演 - 直接进入车队场景，观察比赛日信息如何流动 - 和工程师共同选择时间敏感且能影响策略的查询/分析任务 - 把模型接上实时数据工具而不是依赖静态prompt - 围绕比赛日延迟和可用性迭代交互 - 保留工程师作为最终策略责任人 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 公开案例强调决策速度与数据访问改善，未给单一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - FDE最有价值时往往处在“数据很多但决策窗口很短”的现场 - 实时工具的关键指标是决策时延与可用性，不只是答案质量 - 与领域专家共建比通用助手更能形成壁垒 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Chip Ganassi Racing：比赛日数据与策略工具](https://openai.com/stories/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 中高：OpenAI公开明确出现Forward Deployed Engineer与车队共建race-day tools；底层具体技术栈未完整披露。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-005", "source": "OpenAI", "company": "Chip Ganassi Racing", "industry": "体育/赛车", "scenario": "比赛日数据与策略工具", "fde": "明确FDE/伴随式部署", "problem": "赛车拥有200+传感器，比赛每小时接近10亿数据点，工程师需要在比赛中快速读取并连接信息。", "solution": "OpenAI研究人员与FDE直接和车队共建race-day tools，把实时数据、分析与工程师工作流连接起来。", "human": "赛车工程师与策略团队做最终比赛决策。", "result": "公开案例强调决策速度与数据访问改善，未给单一ROI。", "maturity": "生产/现场使用", "url": "https://openai.com/stories/", "architecture": [ "赛车200+传感器 + 实时遥测/历史比赛数据", "数据流标准化与可访问接口", "FDE/研究团队和车队共同定义比赛日问题", "AI工具按工程师问题调用/汇总相关数据并生成分析", "工程师与策略团队结合赛况做最终决策", "比赛后复盘，把新问题和工具需求反馈到下一轮" ], "components": [ "实时遥测数据", "分析/检索工具", "OpenAI模型", "比赛日工作台", "Human-in-the-loop" ], "fde_actions": [ "直接进入车队场景，观察比赛日信息如何流动", "和工程师共同选择时间敏感且能影响策略的查询/分析任务", "把模型接上实时数据工具而不是依赖静态prompt", "围绕比赛日延迟和可用性迭代交互", "保留工程师作为最终策略责任人" ], "reusable": [ "FDE最有价值时往往处在“数据很多但决策窗口很短”的现场", "实时工具的关键指标是决策时延与可用性，不只是答案质量", "与领域专家共建比通用助手更能形成壁垒" ], "evidence": "中高：OpenAI公开明确出现Forward Deployed Engineer与车队共建race-day tools；底层具体技术栈未完整披露。", "case_summary": "这个案例的关键不是单点使用AI，而是把“比赛日数据与策略工具”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "媒体、营销与体育", "maturity_stage": "已上线", "fde_relation": "明确FDE与伴随式部署", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Chip Ganassi Racing：比赛日数据与策略工具", "publisher": "OpenAI", "url": "https://openai.com/stories/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "中高：OpenAI公开明确出现Forward Deployed Engineer与车队共建race-day tools；底层具体技术栈未完整披露。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] } ``` --- # BBVA｜从员工试用到全行生成式AI采用体系 - ID：openai-006 - 行业：金融与保险 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业自述直接来源 - 部署：全行规模化 - 独立核验：未记录 ## 业务问题 BBVA拥有12.5万多名员工和多国业务，需要让生成式AI从少数试用许可证变成可治理、可复用的全行能力；银行还必须解决用例发现、法律与合规审查、员工技能和输出错误监控，而不能只统计账号数量。 ## 解决方案 BBVA先向各层级发放3,000个ChatGPT Enterprise许可证，让一线员工自建GPT并由法律、合规和IT安全共同治理；随后扩展ChatGPT和Gemini访问，以8,000多个活跃用例和约700个战略用例形成筛选漏斗，并建立约750名内部“Wizards”、AI培训和9万多人实践社区推动落地。 ## 技术工作流 > 依据公开组织和知识流程整理 1. ChatGPT Enterprise与Gemini企业访问层 2. 自定义GPT及员工助手连接受控银行知识 3. 2,500多份HR产品、流程与薪酬文档知识库 4. 8,000多个用例进入价值与战略筛选漏斗 5. 法律、合规、IT安全和专业人员复核 6. Wizards网络、培训、实践社区与采用/节时度量 组件：ChatGPT Enterprise、Gemini、自定义GPT、企业知识库、用例组合管理、法律合规与安全治理、Wizards推广网络 ## 人机责任 员工在最了解流程的位置发现用例并审核输出；信贷分析师监控模型错误，九名法律顾问维护法律知识，法律、合规与IT安全共同设定使用边界，内部Wizards负责团队辅导和最佳实践扩散。 ## FDE 动作 > 依据公开采用路径归纳 - 先让各层级真实接触工具并主动发现问题 - 把高潜力个人GPT发布到内部商店复用 - 按活跃用例与战略用例两层管理组合 - 让法律、合规、安全和业务专家共同审核 - 用内部推广者、培训和社区解决持续采用 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** BBVA较早的自有材料披露超过一半员工每周使用生成式AI、平均每人每周节省约3小时。OpenAI 2026年6月客户案例更新为全球约100,000名员工使用、月活跃使用率超过70%、约每人每周节省3小时，部分工作流效率提升最高约80%。这些是采用和流程效率指标，未披露项目净利润或可归因的财务ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 全员工具部署需要配套用例筛选而非只看登录率 - 一线员工是发现流程改造机会的重要来源 - 内部推广者网络可缩短组织学习曲线 - 金融场景必须让专业人员监控错误并承担判断责任 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [BBVA drives AI adoption through talent](https://www.bbva.com/en/innovation/bbva-drives-ai-adoption-through-talent/) - 发布方：BBVA - 披露性质：企业管理层披露 - 原记录查阅日期：2026-09-23 - [BBVA sparks a wave of innovation with ChatGPT Enterprise](https://www.bbva.com/en/innovation/bbva-sparks-a-wave-of-innovation-among-its-employees-with-the-deployment-of-chatgpt-enterprise/) - [OpenAI customer story: BBVA](https://openai.com/index/bbva/) ## 字段边界 - business_problem：企业转型材料披露 - solution：BBVA两篇直接材料交叉整理 - architecture：依据公开组织和知识流程整理 - fde_actions：依据公开采用路径归纳 - result：企业内部统计披露 ## 待核对事项 - 每周约3小时为BBVA估算的重复任务自动化节省，不代表经审计的人均生产率提升。 - 8,000多个为活跃用例，其中约700个被认为具有潜力和战略重要性。 - 2026年6月OpenAI客户案例提供了较新的BBVA采用与效率指标；没有给出项目净利润或可归因ROI。 ## 完整原始结构化记录 ```json { "id": "openai-006", "source": "企业原始材料", "company": "BBVA", "industry": "银行", "industry_group": "金融与保险", "scenario": "从员工试用到全行生成式AI采用体系", "fde": "企业部署案例", "fde_relation": "企业级AI改造", "problem": "BBVA拥有12.5万多名员工和多国业务，需要让生成式AI从少数试用许可证变成可治理、可复用的全行能力；银行还必须解决用例发现、法律与合规审查、员工技能和输出错误监控，而不能只统计账号数量。", "solution": "BBVA先向各层级发放3,000个ChatGPT Enterprise许可证，让一线员工自建GPT并由法律、合规和IT安全共同治理；随后扩展ChatGPT和Gemini访问，以8,000多个活跃用例和约700个战略用例形成筛选漏斗，并建立约750名内部“Wizards”、AI培训和9万多人实践社区推动落地。", "human": "员工在最了解流程的位置发现用例并审核输出；信贷分析师监控模型错误，九名法律顾问维护法律知识，法律、合规与IT安全共同设定使用边界，内部Wizards负责团队辅导和最佳实践扩散。", "result": "BBVA较早的自有材料披露超过一半员工每周使用生成式AI、平均每人每周节省约3小时。OpenAI 2026年6月客户案例更新为全球约100,000名员工使用、月活跃使用率超过70%、约每人每周节省3小时，部分工作流效率提升最高约80%。这些是采用和流程效率指标，未披露项目净利润或可归因的财务ROI。", "maturity": "全行规模化", "maturity_stage": "规模化", "url": "https://www.bbva.com/en/innovation/bbva-drives-ai-adoption-through-talent/", "architecture": [ "ChatGPT Enterprise与Gemini企业访问层", "自定义GPT及员工助手连接受控银行知识", "2,500多份HR产品、流程与薪酬文档知识库", "8,000多个用例进入价值与战略筛选漏斗", "法律、合规、IT安全和专业人员复核", "Wizards网络、培训、实践社区与采用/节时度量" ], "components": [ "ChatGPT Enterprise", "Gemini", "自定义GPT", "企业知识库", "用例组合管理", "法律合规与安全治理", "Wizards推广网络" ], "fde_actions": [ "先让各层级真实接触工具并主动发现问题", "把高潜力个人GPT发布到内部商店复用", "按活跃用例与战略用例两层管理组合", "让法律、合规、安全和业务专家共同审核", "用内部推广者、培训和社区解决持续采用" ], "reusable": [ "全员工具部署需要配套用例筛选而非只看登录率", "一线员工是发现流程改造机会的重要来源", "内部推广者网络可缩短组织学习曲线", "金融场景必须让专业人员监控错误并承担判断责任" ], "evidence": "BBVA自有网站披露采用率、用例数、节时、知识库规模和治理方式；数据为企业估算，未见独立审计。", "case_summary": "BBVA案例从3,000个试用许可证演进到全行双工具访问、8,000多个用例漏斗和内部Wizards网络，重点是组织采用与治理而非单一模型。", "evidence_level": "A", "evidence_label": "A级｜企业自述直接来源", "source_record": { "title": "BBVA drives AI adoption through talent", "publisher": "BBVA", "url": "https://www.bbva.com/en/innovation/bbva-drives-ai-adoption-through-talent/", "source_type": "企业转型复盘", "directness": "案例级直接来源", "claim_origin": "企业管理层披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "企业转型材料披露", "solution": "BBVA两篇直接材料交叉整理", "architecture": "依据公开组织和知识流程整理", "fde_actions": "依据公开采用路径归纳", "result": "企业内部统计披露" }, "verification_notes": [ "每周约3小时为BBVA估算的重复任务自动化节省，不代表经审计的人均生产率提升。", "8,000多个为活跃用例，其中约700个被认为具有潜力和战略重要性。", "2026年6月OpenAI客户案例提供了较新的BBVA采用与效率指标；没有给出项目净利润或可归因ROI。" ], "additional_sources": [ { "title": "BBVA sparks a wave of innovation with ChatGPT Enterprise", "url": "https://www.bbva.com/en/innovation/bbva-sparks-a-wave-of-innovation-among-its-employees-with-the-deployment-of-chatgpt-enterprise/" }, { "title": "OpenAI customer story: BBVA", "url": "https://openai.com/index/bbva/" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Moderna｜研究与企业知识工作 - ID：openai-007 - 行业：医疗与生命科学 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 药企希望将生成式AI扩展到研究、分析和员工日常工作。 ## 解决方案 Moderna先通过内部mChat积累使用经验，再比较多种工具；通过专职变革团队、培训、内部骨干与业务答疑推广ChatGPT Enterprise。Dose ID用于临床团队的数据分析辅助，结果由专业人员复核。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 科研与职能团队保留科学和合规判断。 ## FDE 动作 > FDE视角编辑推演 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方案例披露部署两个月后已有750个GPT，40%的周活跃用户创建GPT，平均每名用户每周进行120次对话。这些是采用指标，不能直接等同于药物研发提速或患者获益。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 先从内部工具与员工研究积累采用经验，再选择企业工具并培养内部骨干。 ### 阻力与证据边界 GPT数量和对话频率是采用数据；Dose ID仍是辅助临床分析，需人类复核。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 分别验收知识任务、培训采用与临床分析；不把账号活跃度当研发成功率。 研究依据： - [Moderna：组织采用与临床分析辅助](https://openai.com/index/moderna/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Moderna：组织采用与临床分析辅助](https://openai.com/index/moderna/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-007", "source": "OpenAI", "company": "Moderna", "industry": "生命科学", "scenario": "研究与企业知识工作", "fde": "企业部署案例", "problem": "药企希望将生成式AI扩展到研究、分析和员工日常工作。", "solution": "Moderna先通过内部mChat积累使用经验，再比较多种工具；通过专职变革团队、培训、内部骨干与业务答疑推广ChatGPT Enterprise。Dose ID用于临床团队的数据分析辅助，结果由专业人员复核。", "human": "科研与职能团队保留科学和合规判断。", "result": "官方案例披露部署两个月后已有750个GPT，40%的周活跃用户创建GPT，平均每名用户每周进行120次对话。这些是采用指标，不能直接等同于药物研发提速或患者获益。", "maturity": "规模化", "url": "https://openai.com/index/moderna/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“研究与企业知识工作”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Moderna：组织采用与临床分析辅助", "publisher": "OpenAI", "url": "https://openai.com/index/moderna/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/" } ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Intercom｜AI客服 - ID：openai-008 - 行业：科技与软件 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 客服需要在质量、响应速度与规模之间平衡。 ## 解决方案 Intercom将Fin Voice与Fin Tasks作为持续演进的产品系统；模型版本先经过指令遵循、工具调用和对话质量离线评测，再用线上A/B验证；语音还单独检验延迟与脚本遵循。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 复杂问题升级人工客服。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 逐案例材料披露了模型替换与上线评测机制；不能从该机制本身推导所有客户的解决率或统一ROI。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 模型更新纳入离线评测与线上A/B，语音单独关注延迟、工具执行和脚本遵循。 ### 阻力与证据边界 模型升级不能跳过既有成功场景回归；电话接入成功不等于客户问题解决。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 加入打断、沉默、工具超时、转人工失败的会话回放，核对真实解决率。 研究依据： - [Intercom：实验、评测与可演进架构](https://openai.com/index/intercom/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Intercom：实验、评测与可演进架构](https://openai.com/index/intercom/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-008", "source": "OpenAI", "company": "Intercom", "industry": "SaaS/客服", "scenario": "AI客服", "fde": "企业部署案例", "problem": "客服需要在质量、响应速度与规模之间平衡。", "solution": "Intercom将Fin Voice与Fin Tasks作为持续演进的产品系统；模型版本先经过指令遵循、工具调用和对话质量离线评测，再用线上A/B验证；语音还单独检验延迟与脚本遵循。", "human": "复杂问题升级人工客服。", "result": "逐案例材料披露了模型替换与上线评测机制；不能从该机制本身推导所有客户的解决率或统一ROI。", "maturity": "生产级", "url": "https://openai.com/index/intercom/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“AI客服”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Intercom：实验、评测与可演进架构", "publisher": "OpenAI", "url": "https://openai.com/index/intercom/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 0, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理", "量化结果" ] } ``` --- # Lowe's｜员工与客户AI体验 - ID：openai-009 - 行业：零售与消费 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 大型零售需要把商品、服务和内部知识更快交到员工与客户手中。 ## 解决方案 将OpenAI能力嵌入零售知识与服务场景。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 门店和业务人员处理复杂/责任性任务。 ## FDE 动作 > FDE视角编辑推演 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** OpenAI 2025企业AI报告代表案例之一。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 将顾客项目咨询与门店员工支持作为相关但不同的工作流。 ### 阻力与证据边界 商品推荐涉及实时库存、位置和项目条件；一个渠道的使用规模不代表另一渠道收益。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 对顾客与员工分别设置任务集，检查商品来源、库存时点和安全问题升级。 研究依据： - [Lowe’s：Mylow 与门店员工助手](https://openai.com/index/lowes/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Lowe’s：Mylow 与门店员工助手](https://openai.com/index/lowes/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-009", "source": "OpenAI", "company": "Lowe's", "industry": "零售", "scenario": "员工与客户AI体验", "fde": "企业部署案例", "problem": "大型零售需要把商品、服务和内部知识更快交到员工与客户手中。", "solution": "将OpenAI能力嵌入零售知识与服务场景。", "human": "门店和业务人员处理复杂/责任性任务。", "result": "OpenAI 2025企业AI报告代表案例之一。", "maturity": "生产级", "url": "https://openai.com/index/lowes/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“员工与客户AI体验”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Lowe’s：Mylow 与门店员工助手", "publisher": "OpenAI", "url": "https://openai.com/index/lowes/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Indeed｜招聘匹配与求职体验 - ID：openai-010 - 行业：企业运营与其他 - 来源：OpenAI - 详细度：概览案例｜作为线索使用（5/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 大规模职位与求职者匹配需要更强语义理解和个性化。 ## 解决方案 OpenAI模型进入匹配与用户体验工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务数据/文档/系统输入 2. 数据清洗与业务语义整理 3. AI/规则完成理解、匹配或生成 4. 确定性校验或业务规则检查 5. 人工处理低置信度/高风险事项 6. 结果写回原业务流程并持续沉淀反馈 组件：企业数据/文档、LLM/语义理解、业务规则、Human-in-the-loop、原有业务系统 ## 人机责任 招聘方和求职者做最终选择。 ## FDE 动作 > FDE视角编辑推演 - 跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档 - 盘点可用数据、权限、系统接口和隐性业务规则 - 把任务拆成 AI、规则/传统软件、人三类责任边界 - 先做窄场景 PoC，用真实样本验证准确率与业务价值 - 嵌入原有系统，设计异常升级、反馈和后续迭代机制 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** OpenAI 2025企业AI报告代表案例之一。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 使用语义上下文解释职位与求职者的相关性。 ### 阻力与证据边界 匹配提示不等于录用决定；转化变化须与候选人覆盖和公平性一起看。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 核对事实与求职者授权，保留人工招聘决策与结果申诉。 研究依据： - [Indeed：有上下文的职位匹配](https://openai.com/index/indeed/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Indeed：有上下文的职位匹配](https://openai.com/index/indeed/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-010", "source": "OpenAI", "company": "Indeed", "industry": "招聘/平台", "scenario": "招聘匹配与求职体验", "fde": "企业部署案例", "problem": "大规模职位与求职者匹配需要更强语义理解和个性化。", "solution": "OpenAI模型进入匹配与用户体验工作流。", "human": "招聘方和求职者做最终选择。", "result": "OpenAI 2025企业AI报告代表案例之一。", "maturity": "生产级", "url": "https://openai.com/index/indeed/", "architecture": [ "业务数据/文档/系统输入", "数据清洗与业务语义整理", "AI/规则完成理解、匹配或生成", "确定性校验或业务规则检查", "人工处理低置信度/高风险事项", "结果写回原业务流程并持续沉淀反馈" ], "components": [ "企业数据/文档", "LLM/语义理解", "业务规则", "Human-in-the-loop", "原有业务系统" ], "fde_actions": [ "跟一线人员走完整工作流，确认真实瓶颈而不是只接需求文档", "盘点可用数据、权限、系统接口和隐性业务规则", "把任务拆成 AI、规则/传统软件、人三类责任边界", "先做窄场景 PoC，用真实样本验证准确率与业务价值", "嵌入原有系统，设计异常升级、反馈和后续迭代机制" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“招聘匹配与求职体验”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Indeed：有上下文的职位匹配", "publisher": "OpenAI", "url": "https://openai.com/index/indeed/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/" } ], "detail_score": 5, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Oscar Health｜医疗保险运营与知识工作 - ID：openai-011 - 行业：医疗与生命科学 - 来源：OpenAI - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 保险与医疗运营流程文本密集、规则复杂。 ## 解决方案 将OpenAI能力用于知识、运营和自动化场景。 ## 技术工作流 > 公开信息与编辑推演混合 1. EHR/床位/人员/运营事件数据 2. 统一患者与运营实体 3. 实时状态 + 预测/规则/AI分析 4. 按临床/运营优先级产生建议 5. 医护/运营人员确认与执行 6. 结果回写并持续监测 组件：医疗数据集成、Ontology/统一实体、预测/规则/AI、权限审计、临床/运营工作台 ## 人机责任 医疗与保险专业人员保留高风险判断。 ## FDE 动作 > FDE视角编辑推演 - 与临床/运营团队共同定义问题和安全边界 - 先解决可度量的运营瓶颈，避免让AI承担诊断责任 - 打通数据权限与实时更新 - 设计告警、建议和人工确认机制 - 用住院时长、床位周转等业务指标验收 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** OpenAI案例称，Oscar使用API使医疗沟通记录与检验结果审核所需时间减少近40%；这是特定文档任务的工时指标，不能直接解释为保费、理赔总成本或医疗风险下降40%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 医疗AI先从运营闭环切入通常更容易量化 - 临床责任必须留在人类专业人员 - 权限、审计、实时性和数据质量与模型同等重要 ## 现场决策与研究 ### 为什么这样做 从沟通记录、文档与理赔历史整理等具体文本任务切入。 ### 阻力与证据边界 近40%的省时口径不代表总医疗成本下降；不同业务链路的风险与责任不同。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 专业人员复核临床内容，理赔信息必须能追溯到原始记录和规则版本。 研究依据： - [Oscar Health：保险与临床文档工作流](https://openai.com/index/oscar/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Oscar Health：保险与临床文档工作流](https://openai.com/index/oscar/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-011", "source": "OpenAI", "company": "Oscar Health", "industry": "医疗/保险", "scenario": "医疗保险运营与知识工作", "fde": "企业部署案例", "problem": "保险与医疗运营流程文本密集、规则复杂。", "solution": "将OpenAI能力用于知识、运营和自动化场景。", "human": "医疗与保险专业人员保留高风险判断。", "result": "OpenAI案例称，Oscar使用API使医疗沟通记录与检验结果审核所需时间减少近40%；这是特定文档任务的工时指标，不能直接解释为保费、理赔总成本或医疗风险下降40%。", "maturity": "生产级", "url": "https://openai.com/index/oscar/", "architecture": [ "EHR/床位/人员/运营事件数据", "统一患者与运营实体", "实时状态 + 预测/规则/AI分析", "按临床/运营优先级产生建议", "医护/运营人员确认与执行", "结果回写并持续监测" ], "components": [ "医疗数据集成", "Ontology/统一实体", "预测/规则/AI", "权限审计", "临床/运营工作台" ], "fde_actions": [ "与临床/运营团队共同定义问题和安全边界", "先解决可度量的运营瓶颈，避免让AI承担诊断责任", "打通数据权限与实时更新", "设计告警、建议和人工确认机制", "用住院时长、床位周转等业务指标验收" ], "reusable": [ "医疗AI先从运营闭环切入通常更容易量化", "临床责任必须留在人类专业人员", "权限、审计、实时性和数据质量与模型同等重要" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“医疗保险运营与知识工作”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Oscar Health：保险与临床文档工作流", "publisher": "OpenAI", "url": "https://openai.com/index/oscar/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/" } ], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # 1Password｜工程开发效率 - ID：openai-012 - 行业：科技与软件 - 来源：OpenAI - 详细度：概览案例｜作为线索使用（6/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 大型代码库中的开发、修改与验证消耗工程时间。 ## 解决方案 Codex进入工程工作流，承担代码理解、修改和测试任务。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/历史变更/需求 2. 检索相关文件与历史正确样例 3. LLM/Coding Agent生成修改 4. 编译/测试/Lint等确定性验证 5. 工程师Review与反馈 6. Git/CI合并 → 已批准变更成为新上下文 组件：代码检索、Coding Agent/LLM、编译器/测试框架、Git/CI/CD、Human code review ## 人机责任 工程师审查并负责合并。 ## FDE 动作 > FDE视角编辑推演 - 盘点代码库、依赖关系、测试体系与发布流程 - 把历史正确改动作为golden examples，而不是只写prompt - 为Agent接上编译、测试、Git等可验证工具 - 定义哪些修改可以自动推进、哪些必须人工Review - 将被批准的变更和反馈持续沉淀 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** OpenAI客户案例页称工程生产力提升21%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型 - 优先使用编译/测试这种确定性反馈 - 批准后的结果形成学习飞轮 ## 现场决策与研究 ### 为什么这样做 从既有工程流程测量编码辅助的效果，而不是只统计代码生成量。 ### 阻力与证据边界 21%是来源方特定工程口径；审查、安全和交付质量仍需独立衡量。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 分层比较同类任务的交付周期、返工和生产缺陷，记录样本与测量窗口。 研究依据： - [1Password：工程生产力与 Codex](https://openai.com/index/1password/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [1Password：工程生产力与 Codex](https://openai.com/index/1password/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/customer-stories/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-012", "source": "OpenAI", "company": "1Password", "industry": "网络安全/软件", "scenario": "工程开发效率", "fde": "企业部署案例", "problem": "大型代码库中的开发、修改与验证消耗工程时间。", "solution": "Codex进入工程工作流，承担代码理解、修改和测试任务。", "human": "工程师审查并负责合并。", "result": "OpenAI客户案例页称工程生产力提升21%。", "maturity": "生产级", "url": "https://openai.com/index/1password/", "architecture": [ "代码库/历史变更/需求", "检索相关文件与历史正确样例", "LLM/Coding Agent生成修改", "编译/测试/Lint等确定性验证", "工程师Review与反馈", "Git/CI合并 → 已批准变更成为新上下文" ], "components": [ "代码检索", "Coding Agent/LLM", "编译器/测试框架", "Git/CI/CD", "Human code review" ], "fde_actions": [ "盘点代码库、依赖关系、测试体系与发布流程", "把历史正确改动作为golden examples，而不是只写prompt", "为Agent接上编译、测试、Git等可验证工具", "定义哪些修改可以自动推进、哪些必须人工Review", "将被批准的变更和反馈持续沉淀" ], "reusable": [ "编码Agent真正的壁垒在上下文、工具和验证闭环，不只是模型", "优先使用编译/测试这种确定性反馈", "批准后的结果形成学习飞轮" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“工程开发效率”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "1Password：工程生产力与 Codex", "publisher": "OpenAI", "url": "https://openai.com/index/1password/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/customer-stories/" } ], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Gilbert + Tobin｜律所AI治理与规模化 - ID：openai-013 - 行业：专业服务 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 法律行业既希望扩大AI使用，又需要严格治理、保密和专业责任。 ## 解决方案 与OpenAI建立治理与规模化采用框架，把AI用于法律知识工作。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 律师保留专业判断与最终责任。 ## FDE 动作 > FDE视角编辑推演 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 2026年9月公开案例；首版不补写未核准数值。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把律所AI采用与治理一起设计，而非先全员开放后补责任。 ### 阻力与证据边界 客户保密、专业判断与文件授权不能由模型代替；公开成功叙述未覆盖所有失败样本。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 选择内部低风险文档流程起步，明确可用资料、复核人和案件隔离。 研究依据： - [Gilbert + Tobin：AI 治理与规模化](https://openai.com/index/gilbert-tobin/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Gilbert + Tobin：AI 治理与规模化](https://openai.com/index/gilbert-tobin/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/customer-stories/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-013", "source": "OpenAI", "company": "Gilbert + Tobin", "industry": "法律/专业服务", "scenario": "律所AI治理与规模化", "fde": "企业部署案例", "problem": "法律行业既希望扩大AI使用，又需要严格治理、保密和专业责任。", "solution": "与OpenAI建立治理与规模化采用框架，把AI用于法律知识工作。", "human": "律师保留专业判断与最终责任。", "result": "2026年9月公开案例；首版不补写未核准数值。", "maturity": "规模化", "url": "https://openai.com/index/gilbert-tobin/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“律所AI治理与规模化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "专业服务", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Gilbert + Tobin：AI 治理与规模化", "publisher": "OpenAI", "url": "https://openai.com/index/gilbert-tobin/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/customer-stories/" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Polimill｜日本公共AI基础设施 - ID：openai-014 - 行业：政务与公共服务 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：部署中/规模化 - 独立核验：未记录 ## 业务问题 地方政府需要共享专家经验，同时满足公共部门治理和可持续运营。 ## 解决方案 与OpenAI伴随式建设可复用公共AI基础设施与知识能力。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 政府工作人员与专家负责政策、事实和最终决策。 ## FDE 动作 > FDE视角编辑推演 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 2026年8月公开案例；重点是把专家隐性知识变成跨自治体可复用资产。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 公共部门知识与工作流共享需要跨自治体的维护和责任安排。 ### 阻力与证据边界 公共基础设施推广数量不等于每个单位实际采用和效果。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按自治体分别验证数据权限、知识时效、人工责任和停服替代流程。 研究依据： - [Polimill：公共 AI 基础设施](https://openai.com/index/polimill/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Polimill：公共 AI 基础设施](https://openai.com/index/polimill/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/customer-stories/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-014", "source": "OpenAI", "company": "Polimill", "industry": "政务/公共服务", "scenario": "日本公共AI基础设施", "fde": "伴随式部署", "problem": "地方政府需要共享专家经验，同时满足公共部门治理和可持续运营。", "solution": "与OpenAI伴随式建设可复用公共AI基础设施与知识能力。", "human": "政府工作人员与专家负责政策、事实和最终决策。", "result": "2026年8月公开案例；重点是把专家隐性知识变成跨自治体可复用资产。", "maturity": "部署中/规模化", "url": "https://openai.com/index/polimill/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“日本公共AI基础设施”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "规模化", "fde_relation": "伴随式部署", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Polimill：公共 AI 基础设施", "publisher": "OpenAI", "url": "https://openai.com/index/polimill/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/customer-stories/" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # NVIDIA｜组织知识与专业能力扩展 - ID：openai-015 - 行业：科技与软件 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 超大规模技术组织需要把专业知识、研究和协作能力扩展到更多员工。 ## 解决方案 使用ChatGPT Work连接专业知识与日常工作。 ## 技术工作流 > 公开信息与编辑推演混合 1. SOP / 历史案例 / 专家访谈 2. 文档解析、切分与元数据标注 3. Embedding / 语义索引 4. 按当前问题检索相似案例与规则 5. LLM基于证据生成建议并附出处 6. 专家确认 → 新经验回写知识库 组件：知识库/RAG、Embedding/向量检索、权限与元数据、LLM、专家审核 ## 人机责任 工程和业务专家保留技术决策。 ## FDE 动作 > FDE视角编辑推演 - 跟岗识别“什么时候员工会去找老师傅” - 访谈专家，把隐性判断条件转成可检索案例和规则 - 设计知识粒度、标签、版本和权限，而不是只做文档上传 - 用真实问题做召回率/答案可用性验证 - 把反馈、错答和新案例持续回灌 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 2026年8月公开客户案例。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先选高频、高成本、可验证的窄流程 - 能用确定性工具验证的步骤，不让模型自评 - 高风险动作保留人工责任 - 把每次人工修正变成后续可检索的上下文/规则 ## 现场决策与研究 ### 为什么这样做 把活动规划、外部信息筛选和原型制作分成独立的知识工作流。 ### 阻力与证据边界 GTC周期省时与原型周期缩短属于不同团队实例，不能推导全公司统一人效。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按任务保留信息来源、人工修改和实际交付记录，控制季节与项目规模差异。 研究依据： - [NVIDIA：知识工作与专业能力扩展](https://openai.com/index/nvidia/chatgpt-work/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [NVIDIA：知识工作与专业能力扩展](https://openai.com/index/nvidia/chatgpt-work/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 - [原汇总来源](https://openai.com/business/customer-stories/) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 公开资料确认业务流程；技术组件为基于公开描述的架构抽象 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "openai-015", "source": "OpenAI", "company": "NVIDIA", "industry": "半导体/科技", "scenario": "组织知识与专业能力扩展", "fde": "企业部署案例", "problem": "超大规模技术组织需要把专业知识、研究和协作能力扩展到更多员工。", "solution": "使用ChatGPT Work连接专业知识与日常工作。", "human": "工程和业务专家保留技术决策。", "result": "2026年8月公开客户案例。", "maturity": "规模化", "url": "https://openai.com/index/nvidia/chatgpt-work/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“组织知识与专业能力扩展”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "NVIDIA：知识工作与专业能力扩展", "publisher": "OpenAI", "url": "https://openai.com/index/nvidia/chatgpt-work/", "source_type": "厂商案例页", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "原汇总来源", "url": "https://openai.com/business/customer-stories/" } ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Wendy's Quality Supply Chain Co-op｜餐饮供应链库存与异常处置 - ID：palantir-016 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 库存和供应异常过去可能持续数天甚至数周，团队需要跨供应链数据快速定位根因。 ## 解决方案 用Foundry/AIP把库存、供应商、订单和运营信号放到统一工作流中，让异常被快速识别、定位并处置。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/TMS/订单/库存/产能等多源数据 2. Foundry数据管道统一口径并映射到Ontology 3. 规则/优化模型/AIP识别风险、约束与候选动作 4. 运营工作台按业务影响排序建议 5. Human-in-the-loop确认或修改 6. Action写回业务系统，结果沉淀为下一轮上下文 组件：Foundry、AIP、Ontology、供应链数据、运营工作台 ## 人机责任 供应链团队确认关键处置与供应商动作。 ## FDE 动作 > FDE视角编辑推演 - 和供应链一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir公开称原本可能持续数天/数周的问题可在约5分钟内处理。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Wendy's Quality Supply Chain Co-op：餐饮供应链库存与异常处置](https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方AIPCon/Business Update明确披露业务结果；具体内部模型与规则未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-016", "source": "Palantir", "company": "Wendy's Quality Supply Chain Co-op", "industry": "餐饮/供应链", "scenario": "餐饮供应链库存与异常处置", "fde": "典型Forward Deployed", "problem": "库存和供应异常过去可能持续数天甚至数周，团队需要跨供应链数据快速定位根因。", "solution": "用Foundry/AIP把库存、供应商、订单和运营信号放到统一工作流中，让异常被快速识别、定位并处置。", "human": "供应链团队确认关键处置与供应商动作。", "result": "Palantir公开称原本可能持续数天/数周的问题可在约5分钟内处理。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf", "architecture": [ "ERP/WMS/TMS/订单/库存/产能等多源数据", "Foundry数据管道统一口径并映射到Ontology", "规则/优化模型/AIP识别风险、约束与候选动作", "运营工作台按业务影响排序建议", "Human-in-the-loop确认或修改", "Action写回业务系统，结果沉淀为下一轮上下文" ], "components": [ "Foundry", "AIP", "Ontology", "供应链数据", "运营工作台" ], "fde_actions": [ "和供应链一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方AIPCon/Business Update明确披露业务结果；具体内部模型与规则未公开。", "case_summary": "这个案例的重点是把“餐饮供应链库存与异常处置”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Wendy's Quality Supply Chain Co-op：餐饮供应链库存与异常处置", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方AIPCon/Business Update明确披露业务结果；具体内部模型与规则未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # AT&T｜S.C.O.U.T. 网络运营应用体系 - ID：palantir-017 - 行业：企业运营与其他 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：B级｜官方汇总来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 大型电信网络的数据与运营流程极其分散，需要让工程团队在同一平台持续构建运营应用。 ## 解决方案 Palantir与AT&T共同建设S.C.O.U.T.等应用，并把Foundry作为大规模内部应用底座。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、Ontology、内部应用开发、权限治理、运营数据 ## 人机责任 AT&T自有工程团队持续开发和运营应用，Palantir负责平台与前期共同构建。 ## FDE 动作 > FDE视角编辑推演 - 和网络运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方公开称S.C.O.U.T.从联合项目成长为100+名AT&T专职工程师维护，Foundry上已有约660个应用。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [AT&T：S.C.O.U.T. 网络运营应用体系](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - Palantir官网公开客户引述明确披露100+专职工程师与约660个Foundry应用；单个应用技术栈未完全公开。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-017", "source": "Palantir", "company": "AT&T", "industry": "电信", "scenario": "S.C.O.U.T. 网络运营应用体系", "fde": "典型Forward Deployed", "problem": "大型电信网络的数据与运营流程极其分散，需要让工程团队在同一平台持续构建运营应用。", "solution": "Palantir与AT&T共同建设S.C.O.U.T.等应用，并把Foundry作为大规模内部应用底座。", "human": "AT&T自有工程团队持续开发和运营应用，Palantir负责平台与前期共同构建。", "result": "官方公开称S.C.O.U.T.从联合项目成长为100+名AT&T专职工程师维护，Foundry上已有约660个应用。", "maturity": "规模化", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "Ontology", "内部应用开发", "权限治理", "运营数据" ], "fde_actions": [ "和网络运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "Palantir官网公开客户引述明确披露100+专职工程师与约660个Foundry应用；单个应用技术栈未完全公开。", "case_summary": "这个案例的重点是把“S.C.O.U.T. 网络运营应用体系”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "AT&T：S.C.O.U.T. 网络运营应用体系", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "Palantir官网公开客户引述明确披露100+专职工程师与约660个Foundry应用；单个应用技术栈未完全公开。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "来源可定位性" ] } ``` --- # Parexel｜监管申报材料生成与标准化 - ID：palantir-018 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 临床/监管申报材料需要跨文档、数据和专家反复整理，周期长且标准化困难。 ## 解决方案 将试验数据、申报文档与流程规则连接到统一数据/文档工作流，用AIP辅助材料准备、核对和标准化。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务文档/合同/研究材料/历史案例 2. Document Intelligence/OCR/结构化抽取 3. Ontology把文档事实与业务实体连接 4. AIP检索证据并生成草稿/建议 5. 规则/Evals/专家复核 6. 批准结果进入标准流程并留存审计轨迹 组件：Foundry、AIP、文档处理、Ontology、审计/权限 ## 人机责任 医学、统计和监管专家负责最终内容与合规签发。 ## FDE 动作 > FDE视角编辑推演 - 和临床与监管一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir官网公开称申报材料周期可从平均10–12周缩短到约3–4周，降幅超过50%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Parexel：监管申报材料生成与标准化](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 - [Parexel 企业AI工作流说明](https://www.parexel.com/solutions/parexelai/ai-in-clinical-development) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官网明确披露周期改善；具体LLM、提示词与监管规则实现未公开。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-018", "source": "Palantir", "company": "Parexel", "industry": "医药/CRO", "scenario": "监管申报材料生成与标准化", "fde": "典型Forward Deployed", "problem": "临床/监管申报材料需要跨文档、数据和专家反复整理，周期长且标准化困难。", "solution": "将试验数据、申报文档与流程规则连接到统一数据/文档工作流，用AIP辅助材料准备、核对和标准化。", "human": "医学、统计和监管专家负责最终内容与合规签发。", "result": "Palantir官网公开称申报材料周期可从平均10–12周缩短到约3–4周，降幅超过50%。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "业务文档/合同/研究材料/历史案例", "Document Intelligence/OCR/结构化抽取", "Ontology把文档事实与业务实体连接", "AIP检索证据并生成草稿/建议", "规则/Evals/专家复核", "批准结果进入标准流程并留存审计轨迹" ], "components": [ "Foundry", "AIP", "文档处理", "Ontology", "审计/权限" ], "fde_actions": [ "和临床与监管一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官网明确披露周期改善；具体LLM、提示词与监管规则实现未公开。", "case_summary": "这个案例的重点是把“监管申报材料生成与标准化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Parexel：监管申报材料生成与标准化", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官网明确披露周期改善；具体LLM、提示词与监管规则实现未公开。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "Parexel 企业AI工作流说明", "url": "https://www.parexel.com/solutions/parexelai/ai-in-clinical-development" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Heineken USA｜配送与运输供应链Agent - ID：palantir-019 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 配送、运输与供应链计划需要处理复杂约束，旧方式开发周期长。 ## 解决方案 用Foundry/AIP把订单、物流、配送约束和运营规则组合成AI驱动的供应链工作流与Agent。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/TMS/订单/库存/产能等多源数据 2. Foundry数据管道统一口径并映射到Ontology 3. 规则/优化模型/AIP识别风险、约束与候选动作 4. 运营工作台按业务影响排序建议 5. Human-in-the-loop确认或修改 6. Action写回业务系统，结果沉淀为下一轮上下文 组件：Foundry、AIP Agents、Ontology、物流/订单数据、优化与规则 ## 人机责任 供应链人员审核异常、优先级和实际调度动作。 ## FDE 动作 > FDE视角编辑推演 - 和物流与配送一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** AIPCon公开称团队用3个月构建出过去花3年才完成的能力。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Heineken USA：配送与运输供应链Agent](https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update明确披露3个月对比3年的建设周期；具体Agent编排未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-019", "source": "Palantir", "company": "Heineken USA", "industry": "消费品/食品", "scenario": "配送与运输供应链Agent", "fde": "典型Forward Deployed", "problem": "配送、运输与供应链计划需要处理复杂约束，旧方式开发周期长。", "solution": "用Foundry/AIP把订单、物流、配送约束和运营规则组合成AI驱动的供应链工作流与Agent。", "human": "供应链人员审核异常、优先级和实际调度动作。", "result": "AIPCon公开称团队用3个月构建出过去花3年才完成的能力。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf", "architecture": [ "ERP/WMS/TMS/订单/库存/产能等多源数据", "Foundry数据管道统一口径并映射到Ontology", "规则/优化模型/AIP识别风险、约束与候选动作", "运营工作台按业务影响排序建议", "Human-in-the-loop确认或修改", "Action写回业务系统，结果沉淀为下一轮上下文" ], "components": [ "Foundry", "AIP Agents", "Ontology", "物流/订单数据", "优化与规则" ], "fde_actions": [ "和物流与配送一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update明确披露3个月对比3年的建设周期；具体Agent编排未公开。", "case_summary": "这个案例的重点是把“配送与运输供应链Agent”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Heineken USA：配送与运输供应链Agent", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202025%20Investor%20Presentation.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update明确披露3个月对比3年的建设周期；具体Agent编排未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # L3Harris｜制造与供应链预测决策 - ID：palantir-020 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 管理者不缺“发生了什么”的看板，而缺能提前预测风险并给出可执行方案的系统。 ## 解决方案 将制造、供应、成本和交付数据映射到Ontology，用预测/优化/AIP把风险转成行动建议。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、Ontology、AIP、预测/优化、制造与供应链数据 ## 人机责任 业务与工程负责人负责高风险决策和资源调配。 ## FDE 动作 > FDE视角编辑推演 - 和制造与供应链一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 官方客户引述强调从事后看板转向预测和决策敏捷性，公开材料未给统一量化ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [L3Harris：制造与供应链预测决策](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - Palantir官网明确披露客户目标与部署方向；未披露单一财务指标与具体模型。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-020", "source": "Palantir", "company": "L3Harris", "industry": "国防/工业", "scenario": "制造与供应链预测决策", "fde": "典型Forward Deployed", "problem": "管理者不缺“发生了什么”的看板，而缺能提前预测风险并给出可执行方案的系统。", "solution": "将制造、供应、成本和交付数据映射到Ontology，用预测/优化/AIP把风险转成行动建议。", "human": "业务与工程负责人负责高风险决策和资源调配。", "result": "官方客户引述强调从事后看板转向预测和决策敏捷性，公开材料未给统一量化ROI。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "Ontology", "AIP", "预测/优化", "制造与供应链数据" ], "fde_actions": [ "和制造与供应链一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "Palantir官网明确披露客户目标与部署方向；未披露单一财务指标与具体模型。", "case_summary": "这个案例的重点是把“制造与供应链预测决策”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "L3Harris：制造与供应链预测决策", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "Palantir官网明确披露客户目标与部署方向；未披露单一财务指标与具体模型。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] } ``` --- # SOMPO Japan｜商业保险盈利与销售决策 - ID：palantir-021 - 行业：金融与保险 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 商业保险销售与承保需要把分散业务数据转成可执行的客户/风险决策。 ## 解决方案 以Foundry/RDP为业务数据底座，将盈利、客户、销售和灾害响应等数据接入工作流，并扩展到销售团队。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、Real Data Platform、Ontology、商业保险数据、销售工作流 ## 人机责任 销售、承保和管理团队根据建议做最终商业判断。 ## FDE 动作 > FDE视角编辑推演 - 和保险销售与承保一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **来源方披露利润/投资回报说法** Palantir官网公开客户引述称过去三年利润改善约6000万美元，并预计未来三年再增约1亿美元；相关工作流扩展到10,000+销售人员。 > 这是客户或厂商的公开说法，未独立核验；来源没有提供可复算的完整项目成本与归因。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [SOMPO Japan：商业保险盈利与销售决策](https://investors.palantir.com/news-details/2023/Palantir-Signs-50-Million-Expansion-with-SOMPO-Holdings/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿确认10,000+销售人员扩展与商业保险盈利工作流；利润数字来自Palantir官网客户引述。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-021", "source": "Palantir", "company": "SOMPO Japan", "industry": "保险", "scenario": "商业保险盈利与销售决策", "fde": "典型Forward Deployed", "problem": "商业保险销售与承保需要把分散业务数据转成可执行的客户/风险决策。", "solution": "以Foundry/RDP为业务数据底座，将盈利、客户、销售和灾害响应等数据接入工作流，并扩展到销售团队。", "human": "销售、承保和管理团队根据建议做最终商业判断。", "result": "Palantir官网公开客户引述称过去三年利润改善约6000万美元，并预计未来三年再增约1亿美元；相关工作流扩展到10,000+销售人员。", "maturity": "规模化", "url": "https://investors.palantir.com/news-details/2023/Palantir-Signs-50-Million-Expansion-with-SOMPO-Holdings/", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "Real Data Platform", "Ontology", "商业保险数据", "销售工作流" ], "fde_actions": [ "和保险销售与承保一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿确认10,000+销售人员扩展与商业保险盈利工作流；利润数字来自Palantir官网客户引述。", "case_summary": "这个案例的重点是把“商业保险盈利与销售决策”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "SOMPO Japan：商业保险盈利与销售决策", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2023/Palantir-Signs-50-Million-Expansion-with-SOMPO-Holdings/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿确认10,000+销售人员扩展与商业保险盈利工作流；利润数字来自Palantir官网客户引述。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # AARP｜会员服务原型快速生产化 - ID：palantir-022 - 行业：企业运营与其他 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：B级｜官方汇总来源 - 部署：生产/扩展中 - 独立核验：未记录 ## 业务问题 大型会员组织需要快速验证AI是否能改善会员服务与内部运营，而传统项目周期过长。 ## 解决方案 通过AIP/Foundry快速将会员数据、知识和服务规则组合成可用原型，并从原型继续生产化。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、AIP、会员数据、知识检索、快速应用开发 ## 人机责任 业务团队验证用户价值、服务边界与内容准确性。 ## FDE 动作 > FDE视角编辑推演 - 和会员服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方客户引述称首个原型在45天内上线。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [AARP：会员服务原型快速生产化](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 - [Palantir Q2 2024 客户引述](https://investors.palantir.com/files/Palantir%20Q2%202024%20Business%20Update.pdf) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官网明确披露45天原型周期；具体原型场景和底层模型未全部公开。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-022", "source": "Palantir", "company": "AARP", "industry": "会员/非营利", "scenario": "会员服务原型快速生产化", "fde": "典型Forward Deployed", "problem": "大型会员组织需要快速验证AI是否能改善会员服务与内部运营，而传统项目周期过长。", "solution": "通过AIP/Foundry快速将会员数据、知识和服务规则组合成可用原型，并从原型继续生产化。", "human": "业务团队验证用户价值、服务边界与内容准确性。", "result": "官方客户引述称首个原型在45天内上线。", "maturity": "生产/扩展中", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "AIP", "会员数据", "知识检索", "快速应用开发" ], "fde_actions": [ "和会员服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官网明确披露45天原型周期；具体原型场景和底层模型未全部公开。", "case_summary": "这个案例的重点是把“会员服务原型快速生产化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "企业运营与其他", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "AARP：会员服务原型快速生产化", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官网明确披露45天原型周期；具体原型场景和底层模型未全部公开。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [ { "title": "Palantir Q2 2024 客户引述", "url": "https://investors.palantir.com/files/Palantir%20Q2%202024%20Business%20Update.pdf" } ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # CAZ Investments｜投资线索筛选与伙伴服务 - ID：palantir-023 - 行业：金融与保险 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 投资团队每年审阅大量私募机会，同时需要扩展合作伙伴服务而不线性增加人力。 ## 解决方案 用AIP做线索/材料理解、优先级排序和next-best-action，把投资机会与伙伴关系数据接入统一工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务文档/合同/研究材料/历史案例 2. Document Intelligence/OCR/结构化抽取 3. Ontology把文档事实与业务实体连接 4. AIP检索证据并生成草稿/建议 5. 规则/Evals/专家复核 6. 批准结果进入标准流程并留存审计轨迹 组件：AIP、Foundry、Ontology、投资文档、Next-best-action ## 人机责任 投资经理负责最终尽调、投资判断和客户关系。 ## FDE 动作 > FDE视角编辑推演 - 和投资筛选与伙伴服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir官网称相同资源可处理超过100倍线索，线索处理时间下降90%以上。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [CAZ Investments：投资线索筛选与伙伴服务](https://investors.palantir.com/news-details/2023/CAZ-Investments-Selects-Palantir-for-its-Artificial-Intelligence-Platform-AIP/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿明确用途；100x与>90%来自Palantir官网客户引述。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-023", "source": "Palantir", "company": "CAZ Investments", "industry": "资产管理", "scenario": "投资线索筛选与伙伴服务", "fde": "典型Forward Deployed", "problem": "投资团队每年审阅大量私募机会，同时需要扩展合作伙伴服务而不线性增加人力。", "solution": "用AIP做线索/材料理解、优先级排序和next-best-action，把投资机会与伙伴关系数据接入统一工作流。", "human": "投资经理负责最终尽调、投资判断和客户关系。", "result": "Palantir官网称相同资源可处理超过100倍线索，线索处理时间下降90%以上。", "maturity": "生产级", "url": "https://investors.palantir.com/news-details/2023/CAZ-Investments-Selects-Palantir-for-its-Artificial-Intelligence-Platform-AIP/", "architecture": [ "业务文档/合同/研究材料/历史案例", "Document Intelligence/OCR/结构化抽取", "Ontology把文档事实与业务实体连接", "AIP检索证据并生成草稿/建议", "规则/Evals/专家复核", "批准结果进入标准流程并留存审计轨迹" ], "components": [ "AIP", "Foundry", "Ontology", "投资文档", "Next-best-action" ], "fde_actions": [ "和投资筛选与伙伴服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿明确用途；100x与>90%来自Palantir官网客户引述。", "case_summary": "这个案例的重点是把“投资线索筛选与伙伴服务”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "CAZ Investments：投资线索筛选与伙伴服务", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2023/CAZ-Investments-Selects-Palantir-for-its-Artificial-Intelligence-Platform-AIP/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿明确用途；100x与>90%来自Palantir官网客户引述。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # ESI｜扫描件理解与理赔判断辅助 - ID：palantir-024 - 行业：金融与保险 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：POC→生产验证 - 独立核验：未记录 ## 业务问题 保险业务存在大量质量较差的扫描文档，人工提取和判断耗时。 ## 解决方案 在AIP Bootcamp中把低质量扫描文档接入文档理解和业务判断流程，快速验证自动提取与建议。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务文档/合同/研究材料/历史案例 2. Document Intelligence/OCR/结构化抽取 3. Ontology把文档事实与业务实体连接 4. AIP检索证据并生成草稿/建议 5. 规则/Evals/专家复核 6. 批准结果进入标准流程并留存审计轨迹 组件：AIP、文档理解/OCR、业务规则、Human review ## 人机责任 理赔/业务人员复核AI判断并承担最终决定。 ## FDE 动作 > FDE视角编辑推演 - 和理赔/文档运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方客户引述称团队在约90分钟内构建出可读取质量很差扫描件并给出较好判断的AIP模块。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [ESI：扫描件理解与理赔判断辅助](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官网客户引述明确披露90分钟Bootcamp原型；后续规模化指标未公开。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-024", "source": "Palantir", "company": "ESI", "industry": "保险/理赔", "scenario": "扫描件理解与理赔判断辅助", "fde": "典型Forward Deployed", "problem": "保险业务存在大量质量较差的扫描文档，人工提取和判断耗时。", "solution": "在AIP Bootcamp中把低质量扫描文档接入文档理解和业务判断流程，快速验证自动提取与建议。", "human": "理赔/业务人员复核AI判断并承担最终决定。", "result": "官方客户引述称团队在约90分钟内构建出可读取质量很差扫描件并给出较好判断的AIP模块。", "maturity": "POC→生产验证", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "业务文档/合同/研究材料/历史案例", "Document Intelligence/OCR/结构化抽取", "Ontology把文档事实与业务实体连接", "AIP检索证据并生成草稿/建议", "规则/Evals/专家复核", "批准结果进入标准流程并留存审计轨迹" ], "components": [ "AIP", "文档理解/OCR", "业务规则", "Human review" ], "fde_actions": [ "和理赔/文档运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官网客户引述明确披露90分钟Bootcamp原型；后续规模化指标未公开。", "case_summary": "这个案例的重点是把“扫描件理解与理赔判断辅助”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "ESI：扫描件理解与理赔判断辅助", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官网客户引述明确披露90分钟Bootcamp原型；后续规模化指标未公开。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "技术工作流", "人机与治理", "来源可定位性" ] } ``` --- # Lennar｜企业数据与AI现场应用 - ID：palantir-025 - 行业：专业服务 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：B级｜官方汇总来源 - 部署：POC→扩展 - 独立核验：未记录 ## 业务问题 住宅开发流程横跨土地、施工、销售和客户数据，需要让一线团队直接看到AI带来的可操作价值。 ## 解决方案 通过AIP Bootcamp/联合构建，把企业数据和业务流程快速变成现场可操作应用。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、AIP、Ontology、快速原型、业务应用 ## 人机责任 业务负责人和一线团队验证结果并决定落地。 ## FDE 动作 > FDE视角编辑推演 - 和房地产运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** Palantir官网客户引述描述演示在约14分钟内让业务团队看到显著效果；公开材料未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Lennar：企业数据与AI现场应用](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官网确认客户现场反应与快速构建特征；具体流程和量化结果披露有限。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-025", "source": "Palantir", "company": "Lennar", "industry": "房地产/建筑", "scenario": "企业数据与AI现场应用", "fde": "典型Forward Deployed", "problem": "住宅开发流程横跨土地、施工、销售和客户数据，需要让一线团队直接看到AI带来的可操作价值。", "solution": "通过AIP Bootcamp/联合构建，把企业数据和业务流程快速变成现场可操作应用。", "human": "业务负责人和一线团队验证结果并决定落地。", "result": "Palantir官网客户引述描述演示在约14分钟内让业务团队看到显著效果；公开材料未披露统一ROI。", "maturity": "POC→扩展", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "AIP", "Ontology", "快速原型", "业务应用" ], "fde_actions": [ "和房地产运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官网确认客户现场反应与快速构建特征；具体流程和量化结果披露有限。", "case_summary": "这个案例的重点是把“企业数据与AI现场应用”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "专业服务", "maturity_stage": "验证阶段", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Lennar：企业数据与AI现场应用", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官网确认客户现场反应与快速构建特征；具体流程和量化结果披露有限。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] } ``` --- # Archer Aviation｜eVTOL制造与认证数据底座 - ID：palantir-026 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产/扩展中 - 独立核验：未记录 ## 业务问题 新型航空器制造和认证需要把工程、制造、供应链与认证证据持续对齐，传统系统割裂。 ## 解决方案 Foundry/AIP建立飞机项目Ontology，并用于扩大制造能力，同时延伸到空管、运行控制和路径规划等下一代系统。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、AIP、Ontology、制造数据、认证/工程工作流 ## 人机责任 工程、制造和认证专家保留安全与适航责任。 ## FDE 动作 > FDE视角编辑推演 - 和航空制造与认证一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方合作公告称双方以AI基础加速制造规模化；客户公开引述强调Ontology帮助大型认证项目更快整合。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Archer Aviation：eVTOL制造与认证数据底座](https://investors.palantir.com/news-details/2025/Archer-and-Palantir-to-Build-the-AI-Foundation-for-the-Future-of-Next-Gen-Aviation-Technologies/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿明确披露制造与下一代航空系统合作；具体认证节省比例未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-026", "source": "Palantir", "company": "Archer Aviation", "industry": "航空制造", "scenario": "eVTOL制造与认证数据底座", "fde": "典型Forward Deployed", "problem": "新型航空器制造和认证需要把工程、制造、供应链与认证证据持续对齐，传统系统割裂。", "solution": "Foundry/AIP建立飞机项目Ontology，并用于扩大制造能力，同时延伸到空管、运行控制和路径规划等下一代系统。", "human": "工程、制造和认证专家保留安全与适航责任。", "result": "官方合作公告称双方以AI基础加速制造规模化；客户公开引述强调Ontology帮助大型认证项目更快整合。", "maturity": "生产/扩展中", "url": "https://investors.palantir.com/news-details/2025/Archer-and-Palantir-to-Build-the-AI-Foundation-for-the-Future-of-Next-Gen-Aviation-Technologies/", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "AIP", "Ontology", "制造数据", "认证/工程工作流" ], "fde_actions": [ "和航空制造与认证一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿明确披露制造与下一代航空系统合作；具体认证节省比例未公开。", "case_summary": "这个案例的重点是把“eVTOL制造与认证数据底座”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Archer Aviation：eVTOL制造与认证数据底座", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2025/Archer-and-Palantir-to-Build-the-AI-Foundation-for-the-Future-of-Next-Gen-Aviation-Technologies/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿明确披露制造与下一代航空系统合作；具体认证节省比例未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理", "量化结果" ] } ``` --- # Cummins｜制造数据Ontology与运营决策 - ID：palantir-027 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：B级｜官方汇总来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 制造数据虽大量存在，但业务团队难以快速按真实业务对象访问并行动。 ## 解决方案 用Foundry把设备、零件、订单、工艺等数据组织成Ontology，供分析与AI工作流调用。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、Ontology、制造数据、AIP/分析、权限治理 ## 人机责任 工程和运营团队负责现场执行与安全判断。 ## FDE 动作 > FDE视角编辑推演 - 和制造运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 公开客户引述重点强调Ontology让企业能更快、更高效访问数据；未公开统一ROI。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Cummins：制造数据Ontology与运营决策](https://www.palantir.com/new-homepage/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官网公开客户引述确认Ontology价值；技术实现细节和指标披露有限。 - 当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。 ## 完整原始结构化记录 ```json { "id": "palantir-027", "source": "Palantir", "company": "Cummins", "industry": "工业制造", "scenario": "制造数据Ontology与运营决策", "fde": "典型Forward Deployed", "problem": "制造数据虽大量存在，但业务团队难以快速按真实业务对象访问并行动。", "solution": "用Foundry把设备、零件、订单、工艺等数据组织成Ontology，供分析与AI工作流调用。", "human": "工程和运营团队负责现场执行与安全判断。", "result": "公开客户引述重点强调Ontology让企业能更快、更高效访问数据；未公开统一ROI。", "maturity": "生产级", "url": "https://www.palantir.com/new-homepage/", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "Ontology", "制造数据", "AIP/分析", "权限治理" ], "fde_actions": [ "和制造运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官网公开客户引述确认Ontology价值；技术实现细节和指标披露有限。", "case_summary": "这个案例的重点是把“制造数据Ontology与运营决策”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Cummins：制造数据Ontology与运营决策", "publisher": "Palantir", "url": "https://www.palantir.com/new-homepage/", "source_type": "厂商官方客户材料", "directness": "汇总页或多案例报告", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官网公开客户引述确认Ontology价值；技术实现细节和指标披露有限。", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] } ``` --- # HCA Healthcare｜护理人员排班与能力匹配 - ID：palantir-028 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 传统排班难同时考虑病区需求、技能组合、员工偏好和未来人力需求，且数据轨迹不完整。 ## 解决方案 将人才画像、偏好、患者量预测、成本和业务规则组织成排班Ontology与数字化调度流程。 ## 技术工作流 > 公开信息与编辑推演混合 1. 患者/排班/保险/床位/运营等数据 2. Foundry统一受控数据层 3. Ontology建立患者、人员、资源、事件与规则 4. AIP/预测/规则定位瓶颈并生成建议 5. 临床/运营人员审核与执行 6. 结果持续回写用于容量和流程优化 组件：Foundry、Ontology、预测、排班优化、护理运营工作台 ## 人机责任 护理管理者确认最终班表并处理临床例外。 ## FDE 动作 > FDE视角编辑推演 - 和护理排班一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方资料称已扩展到9个急性住院设施，并计划面向180+医院、约90,000名护士。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [HCA Healthcare：护理人员排班与能力匹配](https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update披露工作流图和扩展规模；未公开单一成本节省数字。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-028", "source": "Palantir", "company": "HCA Healthcare", "industry": "医疗", "scenario": "护理人员排班与能力匹配", "fde": "典型Forward Deployed", "problem": "传统排班难同时考虑病区需求、技能组合、员工偏好和未来人力需求，且数据轨迹不完整。", "solution": "将人才画像、偏好、患者量预测、成本和业务规则组织成排班Ontology与数字化调度流程。", "human": "护理管理者确认最终班表并处理临床例外。", "result": "官方资料称已扩展到9个急性住院设施，并计划面向180+医院、约90,000名护士。", "maturity": "规模化", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "architecture": [ "患者/排班/保险/床位/运营等数据", "Foundry统一受控数据层", "Ontology建立患者、人员、资源、事件与规则", "AIP/预测/规则定位瓶颈并生成建议", "临床/运营人员审核与执行", "结果持续回写用于容量和流程优化" ], "components": [ "Foundry", "Ontology", "预测", "排班优化", "护理运营工作台" ], "fde_actions": [ "和护理排班一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update披露工作流图和扩展规模；未公开单一成本节省数字。", "case_summary": "这个案例的重点是把“护理人员排班与能力匹配”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "HCA Healthcare：护理人员排班与能力匹配", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update披露工作流图和扩展规模；未公开单一成本节省数字。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Cintra Ferrovial｜道路事件实时响应 - ID：palantir-029 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 高速公路事故与异常事件需要跨传感、交通和运营数据快速发现并派出支援。 ## 解决方案 把实时交通与资产数据统一到Foundry/AIP，形成事件检测、定位、通知和资源调度工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、实时数据、Ontology、事件告警、运营Action ## 人机责任 交通运营人员确认高风险事件和现场处置。 ## FDE 动作 > FDE视角编辑推演 - 和道路运营与应急一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 官方客户引述强调实时派出帮助既提升效率也能挽救生命；未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Cintra Ferrovial：道路事件实时响应](https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方AIPCon材料确认客户展示AIP工作流；具体算法和量化指标未完整披露。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-029", "source": "Palantir", "company": "Cintra Ferrovial", "industry": "交通基础设施", "scenario": "道路事件实时响应", "fde": "典型Forward Deployed", "problem": "高速公路事故与异常事件需要跨传感、交通和运营数据快速发现并派出支援。", "solution": "把实时交通与资产数据统一到Foundry/AIP，形成事件检测、定位、通知和资源调度工作流。", "human": "交通运营人员确认高风险事件和现场处置。", "result": "官方客户引述强调实时派出帮助既提升效率也能挽救生命；未披露统一ROI。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "实时数据", "Ontology", "事件告警", "运营Action" ], "fde_actions": [ "和道路运营与应急一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方AIPCon材料确认客户展示AIP工作流；具体算法和量化指标未完整披露。", "case_summary": "这个案例的重点是把“道路事件实时响应”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Cintra Ferrovial：道路事件实时响应", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方AIPCon材料确认客户展示AIP工作流；具体算法和量化指标未完整披露。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # CPKC｜铁路运营数据与可扩展决策平台 - ID：palantir-030 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产/扩展中 - 独立核验：未记录 ## 业务问题 跨区域铁路网络涉及列车、人员、货物和资产的复杂实时协调，需要统一且可扩展的运营平台。 ## 解决方案 以Foundry/AIP作为铁路业务数据和应用底座，把运营数据、分析和业务工作流逐步迁入统一平台。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、AIP、Ontology、铁路运营数据、应用平台 ## 人机责任 调度与运营团队负责最终运行决策。 ## FDE 动作 > FDE视角编辑推演 - 和铁路运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方AIPCon客户引述强调平台可面向未来扩展；具体ROI未公开。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [CPKC：铁路运营数据与可扩展决策平台](https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方AIPCon确认CPKC展示AIP工作流；公开资料对具体单点结果披露有限。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-030", "source": "Palantir", "company": "CPKC", "industry": "铁路/物流", "scenario": "铁路运营数据与可扩展决策平台", "fde": "典型Forward Deployed", "problem": "跨区域铁路网络涉及列车、人员、货物和资产的复杂实时协调，需要统一且可扩展的运营平台。", "solution": "以Foundry/AIP作为铁路业务数据和应用底座，把运营数据、分析和业务工作流逐步迁入统一平台。", "human": "调度与运营团队负责最终运行决策。", "result": "官方AIPCon客户引述强调平台可面向未来扩展；具体ROI未公开。", "maturity": "生产/扩展中", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "AIP", "Ontology", "铁路运营数据", "应用平台" ], "fde_actions": [ "和铁路运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方AIPCon确认CPKC展示AIP工作流；公开资料对具体单点结果披露有限。", "case_summary": "这个案例的重点是把“铁路运营数据与可扩展决策平台”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "CPKC：铁路运营数据与可扩展决策平台", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q3%202023%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方AIPCon确认CPKC展示AIP工作流；公开资料对具体单点结果披露有限。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Hospital for Special Surgery｜保险拒赔申诉自动化 - ID：palantir-031 - 行业：医疗与生命科学 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 保险拒赔申诉需要人工读取材料、核对索赔和准备申诉，单件耗时长。 ## 解决方案 AIP处理非结构化申诉材料，关联索赔数据和组织规则，生成供申诉协调员采取行动的建议。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务文档/合同/研究材料/历史案例 2. Document Intelligence/OCR/结构化抽取 3. Ontology把文档事实与业务实体连接 4. AIP检索证据并生成草稿/建议 5. 规则/Evals/专家复核 6. 批准结果进入标准流程并留存审计轨迹 组件：AIP、文档理解、索赔数据、组织规则、Human review ## 人机责任 申诉人员复核证据与最终提交。 ## FDE 动作 > FDE视角编辑推演 - 和保险申诉一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方Business Update称约45分钟人工工作降到约5分钟，应用在5周内构建。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Hospital for Special Surgery：保险拒赔申诉自动化](https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - AIPCon 8/Business Update明确披露45→5分钟和5周建设周期。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-031", "source": "Palantir", "company": "Hospital for Special Surgery", "industry": "医疗", "scenario": "保险拒赔申诉自动化", "fde": "典型Forward Deployed", "problem": "保险拒赔申诉需要人工读取材料、核对索赔和准备申诉，单件耗时长。", "solution": "AIP处理非结构化申诉材料，关联索赔数据和组织规则，生成供申诉协调员采取行动的建议。", "human": "申诉人员复核证据与最终提交。", "result": "官方Business Update称约45分钟人工工作降到约5分钟，应用在5周内构建。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "architecture": [ "业务文档/合同/研究材料/历史案例", "Document Intelligence/OCR/结构化抽取", "Ontology把文档事实与业务实体连接", "AIP检索证据并生成草稿/建议", "规则/Evals/专家复核", "批准结果进入标准流程并留存审计轨迹" ], "components": [ "AIP", "文档理解", "索赔数据", "组织规则", "Human review" ], "fde_actions": [ "和保险申诉一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "AIPCon 8/Business Update明确披露45→5分钟和5周建设周期。", "case_summary": "这个案例的重点是把“保险拒赔申诉自动化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Hospital for Special Surgery：保险拒赔申诉自动化", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "AIPCon 8/Business Update明确披露45→5分钟和5周建设周期。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # American Airlines｜航线网络规划生态 - ID：palantir-032 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 航线网络规划需要在飞机、机场、需求、时刻和运营约束之间做复杂权衡。 ## 解决方案 用Foundry/AIP重构网络规划生态，将数据、模型和规划动作放入统一运营系统。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、AIP、Ontology、网络规划模型、运营工作台 ## 人机责任 网络规划和运营团队负责最终航线与资源决策。 ## FDE 动作 > FDE视角编辑推演 - 和航空网络规划一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **来源披露金额或成本影响** 官方Business Update称约一年内已实现数千万美元节省。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [American Airlines：航线网络规划生态](https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - AIPCon 8/Business Update明确披露约一年与数千万美元节省；模型细节未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-032", "source": "Palantir", "company": "American Airlines", "industry": "航空/旅行", "scenario": "航线网络规划生态", "fde": "典型Forward Deployed", "problem": "航线网络规划需要在飞机、机场、需求、时刻和运营约束之间做复杂权衡。", "solution": "用Foundry/AIP重构网络规划生态，将数据、模型和规划动作放入统一运营系统。", "human": "网络规划和运营团队负责最终航线与资源决策。", "result": "官方Business Update称约一年内已实现数千万美元节省。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "AIP", "Ontology", "网络规划模型", "运营工作台" ], "fde_actions": [ "和航空网络规划一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "AIPCon 8/Business Update明确披露约一年与数千万美元节省；模型细节未公开。", "case_summary": "这个案例的重点是把“航线网络规划生态”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "American Airlines：航线网络规划生态", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "AIPCon 8/Business Update明确披露约一年与数千万美元节省；模型细节未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # bp｜油井故障管理 - ID：palantir-033 - 行业：能源与公用事业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 油井故障涉及实时设备、维护、生产与历史故障数据，传统排查反应慢。 ## 解决方案 将井、设备、故障和维护上下文接到Foundry/AIP，识别故障风险并把处置建议嵌入运营流程。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、AIP、设备/井数据、Ontology、维护工作流 ## 人机责任 工程师和现场团队确认安全相关动作。 ## FDE 动作 > FDE视角编辑推演 - 和油井与维护运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **来源方披露利润/投资回报说法** 官方客户引述称对Palantir投资持续取得“三位数”回报。 > 这是客户或厂商的公开说法，未独立核验；来源没有提供可复算的完整项目成本与归因。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [bp：油井故障管理](https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - AIPCon 8/Business Update确认“well failure management”与三位数回报引述；具体ROI口径未细化。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-033", "source": "Palantir", "company": "bp", "industry": "能源/油气", "scenario": "油井故障管理", "fde": "典型Forward Deployed", "problem": "油井故障涉及实时设备、维护、生产与历史故障数据，传统排查反应慢。", "solution": "将井、设备、故障和维护上下文接到Foundry/AIP，识别故障风险并把处置建议嵌入运营流程。", "human": "工程师和现场团队确认安全相关动作。", "result": "官方客户引述称对Palantir投资持续取得“三位数”回报。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "AIP", "设备/井数据", "Ontology", "维护工作流" ], "fde_actions": [ "和油井与维护运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "AIPCon 8/Business Update确认“well failure management”与三位数回报引述；具体ROI口径未细化。", "case_summary": "这个案例的重点是把“油井故障管理”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "能源与公用事业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "bp：油井故障管理", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q3%202025%20Investor%20Presentation.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "AIPCon 8/Business Update确认“well failure management”与三位数回报引述；具体ROI口径未细化。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Land O'Frost｜生产排程优化 - ID：palantir-034 - 行业：零售与消费 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 生产排程需要同时考虑订单、产线、换线、原料和交付约束，人工编排耗时。 ## 解决方案 将约束和实时生产数据组织进AIP排程工作流，快速生成可审查的生产计划。 ## 技术工作流 > 公开信息与编辑推演混合 1. ERP/WMS/TMS/订单/库存/产能等多源数据 2. Foundry数据管道统一口径并映射到Ontology 3. 规则/优化模型/AIP识别风险、约束与候选动作 4. 运营工作台按业务影响排序建议 5. Human-in-the-loop确认或修改 6. Action写回业务系统，结果沉淀为下一轮上下文 组件：AIP、Foundry、排程优化、生产约束、Human review ## 人机责任 供应链/生产计划人员审核并处理特殊约束。 ## FDE 动作 > FDE视角编辑推演 - 和生产计划一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方Business Update称排程从约40小时缩短至30分钟。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Land O'Frost：生产排程优化](https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - AIPCon 7/Business Update明确披露40小时→30分钟。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-034", "source": "Palantir", "company": "Land O'Frost", "industry": "食品/制造", "scenario": "生产排程优化", "fde": "典型Forward Deployed", "problem": "生产排程需要同时考虑订单、产线、换线、原料和交付约束，人工编排耗时。", "solution": "将约束和实时生产数据组织进AIP排程工作流，快速生成可审查的生产计划。", "human": "供应链/生产计划人员审核并处理特殊约束。", "result": "官方Business Update称排程从约40小时缩短至30分钟。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf", "architecture": [ "ERP/WMS/TMS/订单/库存/产能等多源数据", "Foundry数据管道统一口径并映射到Ontology", "规则/优化模型/AIP识别风险、约束与候选动作", "运营工作台按业务影响排序建议", "Human-in-the-loop确认或修改", "Action写回业务系统，结果沉淀为下一轮上下文" ], "components": [ "AIP", "Foundry", "排程优化", "生产约束", "Human review" ], "fde_actions": [ "和生产计划一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "AIPCon 7/Business Update明确披露40小时→30分钟。", "case_summary": "这个案例的重点是把“生产排程优化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Land O'Frost：生产排程优化", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "AIPCon 7/Business Update明确披露40小时→30分钟。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # U.S. Department of State｜外交人员医疗资格审查 - ID：palantir-035 - 行业：政务与公共服务 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 外交人员任职前医疗审查涉及大量材料、规则和跨团队处理，周期长。 ## 解决方案 用Palantir构建受控数据和审查应用，将材料、规则、状态和审核动作整合到一个工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 业务文档/合同/研究材料/历史案例 2. Document Intelligence/OCR/结构化抽取 3. Ontology把文档事实与业务实体连接 4. AIP检索证据并生成草稿/建议 5. 规则/Evals/专家复核 6. 批准结果进入标准流程并留存审计轨迹 组件：Foundry、受控数据、Ontology、审查工作流、Human approval ## 人机责任 医疗与行政人员保留最终资格判断。 ## FDE 动作 > FDE视角编辑推演 - 和医疗资格审查一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方Business Update称首个应用3个月上线，将候选人clearance周期从60天降至12天。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [U.S. Department of State：外交人员医疗资格审查](https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - AIPCon 7/Business Update明确披露3个月上线、60→12天。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-035", "source": "Palantir", "company": "U.S. Department of State", "industry": "政府/公共服务", "scenario": "外交人员医疗资格审查", "fde": "典型Forward Deployed", "problem": "外交人员任职前医疗审查涉及大量材料、规则和跨团队处理，周期长。", "solution": "用Palantir构建受控数据和审查应用，将材料、规则、状态和审核动作整合到一个工作流。", "human": "医疗与行政人员保留最终资格判断。", "result": "官方Business Update称首个应用3个月上线，将候选人clearance周期从60天降至12天。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf", "architecture": [ "业务文档/合同/研究材料/历史案例", "Document Intelligence/OCR/结构化抽取", "Ontology把文档事实与业务实体连接", "AIP检索证据并生成草稿/建议", "规则/Evals/专家复核", "批准结果进入标准流程并留存审计轨迹" ], "components": [ "Foundry", "受控数据", "Ontology", "审查工作流", "Human approval" ], "fde_actions": [ "和医疗资格审查一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "AIPCon 7/Business Update明确披露3个月上线、60→12天。", "case_summary": "这个案例的重点是把“外交人员医疗资格审查”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "U.S. Department of State：外交人员医疗资格审查", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20Q2%202025%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "AIPCon 7/Business Update明确披露3个月上线、60→12天。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # GE Aerospace｜机队管理与供应链性能 - ID：palantir-036 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 发动机生产与机队支持横跨复杂供应链、零件、质量和维修数据，交付压力高。 ## 解决方案 AIP/Foundry把供应链和机队运营数据统一到可执行工作流，支持预测、优先级和资源配置。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、AIP、Ontology、供应链/机队数据、预测与行动 ## 人机责任 工程、供应链和运营团队负责最终生产/维修行动。 ## FDE 动作 > FDE视角编辑推演 - 和航空发动机生产与机队一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方Q1 2026材料称2025年商业与军用发动机产出同比增加26%；Palantir将AIP列为支持机队与供应链表现的系统。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 ### 为什么这样做 GE企业公告可确认扩展合作，供应链、生产及机队就绪属于不同业务对象。 ### 阻力与证据边界 合作公告能证明部署方向，不能证明同期发动机产量变化由Palantir单独造成。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 将系统采用与整机产量分开；补充产线基线、供给约束和其他改善措施。 研究依据： - [GE Aerospace：机队管理与供应链性能](https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf) - [GE Aerospace 2026-03-12 合作公告](https://www.geaerospace.com/news/press-releases/ge-aerospace-and-palantir-expand-partnership-transform-military-aircraft-readiness) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [GE Aerospace：机队管理与供应链性能](https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 - [GE Aerospace 2026-03-12 合作公告](https://www.geaerospace.com/news/press-releases/ge-aerospace-and-palantir-expand-partnership-transform-military-aircraft-readiness) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update明确将AIP与机队管理、供应链表现及26%产出提升并列；不能据此把全部增量单独归因于Palantir。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-036", "source": "Palantir", "company": "GE Aerospace", "industry": "航空航天/制造", "scenario": "机队管理与供应链性能", "fde": "典型Forward Deployed", "problem": "发动机生产与机队支持横跨复杂供应链、零件、质量和维修数据，交付压力高。", "solution": "AIP/Foundry把供应链和机队运营数据统一到可执行工作流，支持预测、优先级和资源配置。", "human": "工程、供应链和运营团队负责最终生产/维修行动。", "result": "官方Q1 2026材料称2025年商业与军用发动机产出同比增加26%；Palantir将AIP列为支持机队与供应链表现的系统。", "maturity": "规模化", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "AIP", "Ontology", "供应链/机队数据", "预测与行动" ], "fde_actions": [ "和航空发动机生产与机队一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update明确将AIP与机队管理、供应链表现及26%产出提升并列；不能据此把全部增量单独归因于Palantir。", "case_summary": "这个案例的重点是把“机队管理与供应链性能”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "GE Aerospace：机队管理与供应链性能", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update明确将AIP与机队管理、供应链表现及26%产出提升并列；不能据此把全部增量单独归因于Palantir。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "GE Aerospace 2026-03-12 合作公告", "url": "https://www.geaerospace.com/news/press-releases/ge-aerospace-and-palantir-expand-partnership-transform-military-aircraft-readiness" } ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # USDA｜农业项目统一Ontology与在线发放 - ID：palantir-037 - 行业：政务与公共服务 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 数百个遗留系统碎片化，农民申请与项目发放需要跨系统统一事实和状态。 ## 解决方案 用AIP把遗留系统整合为受治理Ontology，并在其上构建面向农民的项目申请与发放工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、AIP、Ontology、遗留系统整合、政府项目工作流 ## 人机责任 项目管理和政府人员监督资格、异常和资金发放。 ## FDE 动作 > FDE视角编辑推演 - 和农业项目交付一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** 官方Q2 2026材料称项目开放62分钟即打破USDA在线报名记录，前5天向农民发放超过44亿美元。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [USDA：农业项目统一Ontology与在线发放](https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update明确披露数百遗留系统、62分钟记录与前5天$4.4B+发放。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-037", "source": "Palantir", "company": "USDA", "industry": "政府/农业", "scenario": "农业项目统一Ontology与在线发放", "fde": "典型Forward Deployed", "problem": "数百个遗留系统碎片化，农民申请与项目发放需要跨系统统一事实和状态。", "solution": "用AIP把遗留系统整合为受治理Ontology，并在其上构建面向农民的项目申请与发放工作流。", "human": "项目管理和政府人员监督资格、异常和资金发放。", "result": "官方Q2 2026材料称项目开放62分钟即打破USDA在线报名记录，前5天向农民发放超过44亿美元。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "AIP", "Ontology", "遗留系统整合", "政府项目工作流" ], "fde_actions": [ "和农业项目交付一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update明确披露数百遗留系统、62分钟记录与前5天$4.4B+发放。", "case_summary": "这个案例的重点是把“农业项目统一Ontology与在线发放”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "USDA：农业项目统一Ontology与在线发放", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update明确披露数百遗留系统、62分钟记录与前5天$4.4B+发放。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Parts Town｜客服与现场服务运营 - ID：palantir-038 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产/扩展中 - 独立核验：未记录 ## 业务问题 工业零配件业务的客户支持和现场服务需要把产品、订单、客户与服务历史快速结合。 ## 解决方案 用AIP把客户支持和现场服务上下文接到统一Ontology，让团队获得建议、自动化和下一步动作。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：AIP、Foundry、Ontology、客服数据、现场服务数据 ## 人机责任 客服和现场服务人员处理复杂例外与客户关系。 ## FDE 动作 > FDE视角编辑推演 - 和客户支持与现场服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** 官方Q2 2026材料称项目价值机会预计超过200个基点的EBITDA margin。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Parts Town：客服与现场服务运营](https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update明确披露场景和>200bps EBITDA margin机会；为公司预期价值而非审计后的实现值。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-038", "source": "Palantir", "company": "Parts Town", "industry": "工业零配件/服务", "scenario": "客服与现场服务运营", "fde": "典型Forward Deployed", "problem": "工业零配件业务的客户支持和现场服务需要把产品、订单、客户与服务历史快速结合。", "solution": "用AIP把客户支持和现场服务上下文接到统一Ontology，让团队获得建议、自动化和下一步动作。", "human": "客服和现场服务人员处理复杂例外与客户关系。", "result": "官方Q2 2026材料称项目价值机会预计超过200个基点的EBITDA margin。", "maturity": "生产/扩展中", "url": "https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "AIP", "Foundry", "Ontology", "客服数据", "现场服务数据" ], "fde_actions": [ "和客户支持与现场服务一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update明确披露场景和>200bps EBITDA margin机会；为公司预期价值而非审计后的实现值。", "case_summary": "这个案例的重点是把“客服与现场服务运营”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Parts Town：客服与现场服务运营", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q2%202026%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update明确披露场景和>200bps EBITDA margin机会；为公司预期价值而非审计后的实现值。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # SAP｜SAP云迁移Agent - ID：palantir-039 - 行业：科技与软件 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产验证/扩展 - 独立核验：未记录 ## 业务问题 大型ERP迁移包含对象映射、代码/配置转换、校验和大量人工复核，时间与成本高。 ## 解决方案 Palantir以AIP Agent连接源系统、目标SAP环境、迁移规则与验证工具，将迁移拆成可执行、可验证的Agent工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 源ERP对象/代码/配置 2. Ontology映射源与目标业务对象 3. AIP Agent生成迁移映射与转换 4. 确定性验证/对账工具检查结果 5. 迁移专家处理异常并批准 6. 批准模式沉淀用于后续批次 组件：AIP Agents、Ontology、ERP迁移规则、验证/Evals、SAP ## 人机责任 迁移专家审核映射、异常和最终切换。 ## FDE 动作 > FDE视角编辑推演 - 和ERP迁移一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **来源披露金额或成本影响** 官方Q1 2026材料称早期项目两周内达到>99%验证准确率，并把迁移时间与成本降低70%以上。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [SAP：SAP云迁移Agent](https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Q1 2026 Business Update引用SAP COO披露>99% validation accuracy与>70% timeline/cost reduction；具体客户名单未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-039", "source": "Palantir", "company": "SAP", "industry": "企业软件", "scenario": "SAP云迁移Agent", "fde": "典型Forward Deployed", "problem": "大型ERP迁移包含对象映射、代码/配置转换、校验和大量人工复核，时间与成本高。", "solution": "Palantir以AIP Agent连接源系统、目标SAP环境、迁移规则与验证工具，将迁移拆成可执行、可验证的Agent工作流。", "human": "迁移专家审核映射、异常和最终切换。", "result": "官方Q1 2026材料称早期项目两周内达到>99%验证准确率，并把迁移时间与成本降低70%以上。", "maturity": "生产验证/扩展", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf", "architecture": [ "源ERP对象/代码/配置", "Ontology映射源与目标业务对象", "AIP Agent生成迁移映射与转换", "确定性验证/对账工具检查结果", "迁移专家处理异常并批准", "批准模式沉淀用于后续批次" ], "components": [ "AIP Agents", "Ontology", "ERP迁移规则", "验证/Evals", "SAP" ], "fde_actions": [ "和ERP迁移一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Q1 2026 Business Update引用SAP COO披露>99% validation accuracy与>70% timeline/cost reduction；具体客户名单未公开。", "case_summary": "这个案例的重点是把“SAP云迁移Agent”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "SAP：SAP云迁移Agent", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20-%20Q1%202026%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Q1 2026 Business Update引用SAP COO披露>99% validation accuracy与>70% timeline/cost reduction；具体客户名单未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Airbus｜Skywise航空数据生态与A350生产 - ID：palantir-040 - 行业：交通、旅行与物流 - 来源：Palantir - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：行业级规模化 - 独立核验：未记录 ## 业务问题 飞机设计、生产、供应商和航空公司运营数据分散，难以形成行业级共享运营系统。 ## 解决方案 Palantir与Airbus长期共建Skywise，把生产、供应链、维护和航空公司运营数据连接到统一航空Ontology与应用生态。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、Skywise、Ontology、航空制造/运营数据、多组织权限 ## 人机责任 Airbus、供应商与航空公司在各自权限下使用并执行。 ## FDE 动作 > FDE视角编辑推演 - 和航空制造与运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** Palantir 2020年合作概览称，始于2015年的A350项目使交付加速33%；另一段引用第三方分析，估计Skywise生态每年可产生超过17亿美元成本节省机会。后者是机会估算，不是Airbus已实现的年度净收益。不同阶段的用户数和成果不能合并为同一测量。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 ### 为什么这样做 把A350生产协同、Airbus企业数字化与Skywise生态扩展区分为不同阶段。 ### 阻力与证据边界 17亿美元是合作概览引用的机会估算，不能写成Airbus实际节省；33%也不是2026年实时指标。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 引用时同时保留文件年份、PDF物理页与指标对象，经济收益需寻找原始估算方法。 研究依据： - [Airbus：Skywise航空数据生态与A350生产](https://www.palantir.com/assets/xrfr7uokpv1b/7uEHPTEM0MkKtBFcx2zh63/9d75da5b76439717ac95135b5012479e/Palantir-Airbus-Partnership_Overview.pdf) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Airbus：Skywise航空数据生态与A350生产](https://www.palantir.com/assets/xrfr7uokpv1b/7uEHPTEM0MkKtBFcx2zh63/9d75da5b76439717ac95135b5012479e/Palantir-Airbus-Partnership_Overview.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方合作材料确认长期共建Skywise；用户数和历史价值来自Palantir官方Business Update/公司资料。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-040", "source": "Palantir", "company": "Airbus", "industry": "航空航天", "scenario": "Skywise航空数据生态与A350生产", "fde": "典型Forward Deployed", "problem": "飞机设计、生产、供应商和航空公司运营数据分散，难以形成行业级共享运营系统。", "solution": "Palantir与Airbus长期共建Skywise，把生产、供应链、维护和航空公司运营数据连接到统一航空Ontology与应用生态。", "human": "Airbus、供应商与航空公司在各自权限下使用并执行。", "result": "Palantir 2020年合作概览称，始于2015年的A350项目使交付加速33%；另一段引用第三方分析，估计Skywise生态每年可产生超过17亿美元成本节省机会。后者是机会估算，不是Airbus已实现的年度净收益。不同阶段的用户数和成果不能合并为同一测量。", "maturity": "行业级规模化", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/7uEHPTEM0MkKtBFcx2zh63/9d75da5b76439717ac95135b5012479e/Palantir-Airbus-Partnership_Overview.pdf", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "Skywise", "Ontology", "航空制造/运营数据", "多组织权限" ], "fde_actions": [ "和航空制造与运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方合作材料确认长期共建Skywise；用户数和历史价值来自Palantir官方Business Update/公司资料。", "case_summary": "这个案例的重点是把“Skywise航空数据生态与A350生产”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "交通、旅行与物流", "maturity_stage": "规模化", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Airbus：Skywise航空数据生态与A350生产", "publisher": "Palantir", "url": "https://www.palantir.com/assets/xrfr7uokpv1b/7uEHPTEM0MkKtBFcx2zh63/9d75da5b76439717ac95135b5012479e/Palantir-Airbus-Partnership_Overview.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方合作材料确认长期共建Skywise；用户数和历史价值来自Palantir官方Business Update/公司资料。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Rio Tinto｜矿山运营统一数据与价值链优化 - ID：palantir-041 - 行业：能源与公用事业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 矿业运营涉及地下作业、设备、人员、安全、供应链和交易数据，系统割裂。 ## 解决方案 Foundry把多源运营与交易数据整合成关键矿山运营的统一表示，供现场与办公室人员共同决策。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、统一运营数据、安全/权限、矿业价值链、现场应用 ## 人机责任 矿山运营、安全和工程团队负责实际行动。 ## FDE 动作 > FDE视角编辑推演 - 和矿山运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 官方合作公告强调已在Borates价值链数字化、地下运营数据连接和员工安全等项目中落地；未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Rio Tinto：矿山运营统一数据与价值链优化](https://www.palantir.com/newsroom/press-releases/palantir-technologies-and-rio-tinto-sign-multi-year-enterprise-partnership) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿明确披露多业务单元的成功数据整合项目；量化财务结果未公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-041", "source": "Palantir", "company": "Rio Tinto", "industry": "矿业", "scenario": "矿山运营统一数据与价值链优化", "fde": "典型Forward Deployed", "problem": "矿业运营涉及地下作业、设备、人员、安全、供应链和交易数据，系统割裂。", "solution": "Foundry把多源运营与交易数据整合成关键矿山运营的统一表示，供现场与办公室人员共同决策。", "human": "矿山运营、安全和工程团队负责实际行动。", "result": "官方合作公告强调已在Borates价值链数字化、地下运营数据连接和员工安全等项目中落地；未披露统一ROI。", "maturity": "生产级", "url": "https://www.palantir.com/newsroom/press-releases/palantir-technologies-and-rio-tinto-sign-multi-year-enterprise-partnership", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "统一运营数据", "安全/权限", "矿业价值链", "现场应用" ], "fde_actions": [ "和矿山运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿明确披露多业务单元的成功数据整合项目；量化财务结果未公开。", "case_summary": "这个案例的重点是把“矿山运营统一数据与价值链优化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "能源与公用事业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Rio Tinto：矿山运营统一数据与价值链优化", "publisher": "Palantir", "url": "https://www.palantir.com/newsroom/press-releases/palantir-technologies-and-rio-tinto-sign-multi-year-enterprise-partnership", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿明确披露多业务单元的成功数据整合项目；量化财务结果未公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Scuderia Ferrari｜F1动力单元性能与可靠性决策 - ID：palantir-042 - 行业：制造与工业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 赛道和工厂需要把比赛、测试台、零件与动力单元数据快速连接，支持性能与可靠性判断。 ## 解决方案 Foundry整合Grand Prix、试验台和零件信息，让赛道与Maranello工程师共享分析和快速决策。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、比赛/试验数据、零件数据、工程分析、协同工作流 ## 人机责任 动力单元工程师负责最终工程和比赛决策。 ## FDE 动作 > FDE视角编辑推演 - 和赛车工程一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方新闻稿称过去需要数分钟计算的任务可在数秒完成。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Scuderia Ferrari：F1动力单元性能与可靠性决策](https://investors.palantir.com/news-details/2022/Palantir-Technologies-Extends-Partnership-with-Ferrari-to-Bring-Data-Driven-Performance-Decisions-to-Race-Operations/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿明确披露数据源、动力单元场景和“分钟到秒”改善。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-042", "source": "Palantir", "company": "Scuderia Ferrari", "industry": "赛车/制造", "scenario": "F1动力单元性能与可靠性决策", "fde": "典型Forward Deployed", "problem": "赛道和工厂需要把比赛、测试台、零件与动力单元数据快速连接，支持性能与可靠性判断。", "solution": "Foundry整合Grand Prix、试验台和零件信息，让赛道与Maranello工程师共享分析和快速决策。", "human": "动力单元工程师负责最终工程和比赛决策。", "result": "官方新闻稿称过去需要数分钟计算的任务可在数秒完成。", "maturity": "生产级", "url": "https://investors.palantir.com/news-details/2022/Palantir-Technologies-Extends-Partnership-with-Ferrari-to-Bring-Data-Driven-Performance-Decisions-to-Race-Operations/", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "比赛/试验数据", "零件数据", "工程分析", "协同工作流" ], "fde_actions": [ "和赛车工程一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿明确披露数据源、动力单元场景和“分钟到秒”改善。", "case_summary": "这个案例的重点是把“F1动力单元性能与可靠性决策”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Scuderia Ferrari：F1动力单元性能与可靠性决策", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2022/Palantir-Technologies-Extends-Partnership-with-Ferrari-to-Bring-Data-Driven-Performance-Decisions-to-Race-Operations/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿明确披露数据源、动力单元场景和“分钟到秒”改善。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # PG&E｜野火风险与公共安全断电(PSPS) - ID：palantir-043 - 行业：能源与公用事业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 极端天气下需要在极短时间内综合气象、电网、客户与资产数据，精准决定哪些线路断电并持续通知客户。 ## 解决方案 Foundry从数据摄取到PSPS范围计算、客户通知和外部系统写回形成端到端可审计工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、Ontology、气象与资产数据、PSPS工作流、客户通知/写回 ## 人机责任 电网运营和应急团队确认断电范围与高风险行动。 ## FDE 动作 > FDE视角编辑推演 - 和电网应急一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Palantir官方资料称平台支持PSPS和野火风险缓解；公司概览称2022年受野火影响面积相较2018–2020下降99%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 ### 为什么这样做 把电网数据整合视为风险管理的支撑，放回PG&E多层野火防护体系。 ### 阻力与证据边界 监管与投资者材料同时讨论植被治理、硬化、停电保护等措施，整体风险下降不能归因于单个平台。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按具体干预建立指标与反事实对照，区分燃烧面积、点火次数与建模风险。 研究依据： - [PG&E：野火风险与公共安全断电(PSPS)](https://investors.palantir.com/news-details/2021/Palantir-Providing-Technology-to-Enhance-Safety-and-Reliability-of-Electric-Grid-in-California/) - [CPUC 2025 年中安全监督报告](https://www.cpuc.ca.gov/-/media/cpuc-website/divisions/safety-policy-division/reports/2025-mid-year-som-report---september-2025.pdf) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [PG&E：野火风险与公共安全断电(PSPS)](https://investors.palantir.com/news-details/2021/Palantir-Providing-Technology-to-Enhance-Safety-and-Reliability-of-Electric-Grid-in-California/) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 - [CPUC 2025 年中安全监督报告](https://www.cpuc.ca.gov/-/media/cpuc-website/divisions/safety-policy-division/reports/2025-mid-year-som-report---september-2025.pdf) ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方新闻稿明确PSPS部署；99%面积指标来自Palantir官方公司概览，不能视为仅由软件单独造成。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-043", "source": "Palantir", "company": "PG&E", "industry": "公用事业", "scenario": "野火风险与公共安全断电(PSPS)", "fde": "典型Forward Deployed", "problem": "极端天气下需要在极短时间内综合气象、电网、客户与资产数据，精准决定哪些线路断电并持续通知客户。", "solution": "Foundry从数据摄取到PSPS范围计算、客户通知和外部系统写回形成端到端可审计工作流。", "human": "电网运营和应急团队确认断电范围与高风险行动。", "result": "Palantir官方资料称平台支持PSPS和野火风险缓解；公司概览称2022年受野火影响面积相较2018–2020下降99%。", "maturity": "生产级", "url": "https://investors.palantir.com/news-details/2021/Palantir-Providing-Technology-to-Enhance-Safety-and-Reliability-of-Electric-Grid-in-California/", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "Ontology", "气象与资产数据", "PSPS工作流", "客户通知/写回" ], "fde_actions": [ "和电网应急一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方新闻稿明确PSPS部署；99%面积指标来自Palantir官方公司概览，不能视为仅由软件单独造成。", "case_summary": "这个案例的重点是把“野火风险与公共安全断电(PSPS)”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "能源与公用事业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "PG&E：野火风险与公共安全断电(PSPS)", "publisher": "Palantir", "url": "https://investors.palantir.com/news-details/2021/Palantir-Providing-Technology-to-Enhance-Safety-and-Reliability-of-Electric-Grid-in-California/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方新闻稿明确PSPS部署；99%面积指标来自Palantir官方公司概览，不能视为仅由软件单独造成。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [ { "title": "CPUC 2025 年中安全监督报告", "url": "https://www.cpuc.ca.gov/-/media/cpuc-website/divisions/safety-policy-division/reports/2025-mid-year-som-report---september-2025.pdf" } ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Southern California Edison｜电网资产、气象与客户通知 - ID：palantir-044 - 行业：能源与公用事业 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 数千万资产、气象点和巡检记录需要统一，野火和电网事件下客户通知必须快速准确。 ## 解决方案 Foundry连接资产、气象、巡检和客户数据，支持设备定位、风险分析与客户通知流程。 ## 技术工作流 > 公开信息与编辑推演混合 1. 多源运营数据与历史事件 2. Foundry统一数据模型与权限 3. Ontology映射业务对象、关系、状态和可执行Action 4. AIP/规则/预测模型生成建议或自动化步骤 5. 一线人员在Workshop/应用中确认与执行 6. 反馈、结果和新事实写回Ontology形成闭环 组件：Foundry、资产数据、气象预测、巡检数据、客户通知工作流 ## 人机责任 电网运营、气象和客户团队负责风险判断与执行。 ## FDE 动作 > FDE视角编辑推演 - 和电网运营与野火防护一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方FY2022 Business Update披露：20M资产、150M气象预测点、5M巡检/植被记录；客户通知由小时降至分钟，漏通知减少60%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Southern California Edison：电网资产、气象与客户通知](https://investors.palantir.com/files/Palantir%20FY%202022%20Business%20Update.pdf) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - 官方Business Update明确披露数据规模和通知指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-044", "source": "Palantir", "company": "Southern California Edison", "industry": "公用事业", "scenario": "电网资产、气象与客户通知", "fde": "典型Forward Deployed", "problem": "数千万资产、气象点和巡检记录需要统一，野火和电网事件下客户通知必须快速准确。", "solution": "Foundry连接资产、气象、巡检和客户数据，支持设备定位、风险分析与客户通知流程。", "human": "电网运营、气象和客户团队负责风险判断与执行。", "result": "官方FY2022 Business Update披露：20M资产、150M气象预测点、5M巡检/植被记录；客户通知由小时降至分钟，漏通知减少60%。", "maturity": "生产级", "url": "https://investors.palantir.com/files/Palantir%20FY%202022%20Business%20Update.pdf", "architecture": [ "多源运营数据与历史事件", "Foundry统一数据模型与权限", "Ontology映射业务对象、关系、状态和可执行Action", "AIP/规则/预测模型生成建议或自动化步骤", "一线人员在Workshop/应用中确认与执行", "反馈、结果和新事实写回Ontology形成闭环" ], "components": [ "Foundry", "资产数据", "气象预测", "巡检数据", "客户通知工作流" ], "fde_actions": [ "和电网运营与野火防护一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "官方Business Update明确披露数据规模和通知指标。", "case_summary": "这个案例的重点是把“电网资产、气象与客户通知”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "能源与公用事业", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Southern California Edison：电网资产、气象与客户通知", "publisher": "Palantir", "url": "https://investors.palantir.com/files/Palantir%20FY%202022%20Business%20Update.pdf", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "官方Business Update明确披露数据规模和通知指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Andretti Racing｜RaceOS实时赛车性能应用 - ID：palantir-045 - 行业：媒体、营销与体育 - 来源：Palantir - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 赛道决策依赖实时赛车遥测、策略和历史性能数据，需要把多种分析快速变成可操作应用。 ## 解决方案 Andretti在Palantir架构上构建RaceOS，将实时车辆表现连接到一系列AI驱动应用。 ## 技术工作流 > 公开信息与编辑推演混合 1. 设备/质量/工艺/维护/供应链/历史事件 2. Foundry整合实时与历史工业数据 3. Ontology建立设备、零部件、订单、工艺与约束 4. AIP/预测/优化发现风险与推荐动作 5. 工程师/现场人员确认并操作 6. 执行结果和故障反馈沉淀为后续模型与规则上下文 组件：Foundry、AIP、Ontology、实时遥测、RaceOS应用 ## 人机责任 比赛工程和策略团队负责最终赛道行动。 ## FDE 动作 > FDE视角编辑推演 - 和赛车运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点 - 把分散数据源、权限和业务术语整理成统一可操作的Ontology - 将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办 - 把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action - 用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** Palantir架构文档将RaceOS列为客户扩展标准AIP/Foundry架构的代表案例；未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 先把业务对象、关系、状态和Action建模清楚，再谈Agent - 建议必须进入可执行工作流，否则只是另一张仪表盘 - 高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合 - 持续把执行结果写回，才能形成可积累的运营记忆 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Andretti Racing：RaceOS实时赛车性能应用](https://www.palantir.com/docs/foundry/architecture-center/platforms) - 发布方：Palantir - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - Palantir官方架构文档明确点名Andretti RaceOS及其连接实时赛车性能与AI应用；技术细节披露有限。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "palantir-045", "source": "Palantir", "company": "Andretti Racing", "industry": "赛车/体育", "scenario": "RaceOS实时赛车性能应用", "fde": "典型Forward Deployed", "problem": "赛道决策依赖实时赛车遥测、策略和历史性能数据，需要把多种分析快速变成可操作应用。", "solution": "Andretti在Palantir架构上构建RaceOS，将实时车辆表现连接到一系列AI驱动应用。", "human": "比赛工程和策略团队负责最终赛道行动。", "result": "Palantir架构文档将RaceOS列为客户扩展标准AIP/Foundry架构的代表案例；未披露统一ROI。", "maturity": "生产级", "url": "https://www.palantir.com/docs/foundry/architecture-center/platforms", "architecture": [ "设备/质量/工艺/维护/供应链/历史事件", "Foundry整合实时与历史工业数据", "Ontology建立设备、零部件、订单、工艺与约束", "AIP/预测/优化发现风险与推荐动作", "工程师/现场人员确认并操作", "执行结果和故障反馈沉淀为后续模型与规则上下文" ], "components": [ "Foundry", "AIP", "Ontology", "实时遥测", "RaceOS应用" ], "fde_actions": [ "和赛车运营一线团队共同走完整流程，找出真正需要决策而不是展示数据的节点", "把分散数据源、权限和业务术语整理成统一可操作的Ontology", "将业务规则、优化模型、LLM和传统软件按可靠性边界组合，而不是让LLM包办", "把建议直接嵌入现有操作工作台，并设计批准、驳回、升级和写回Action", "用业务KPI验收并根据真实反馈继续改Ontology、规则和自动化" ], "reusable": [ "先把业务对象、关系、状态和Action建模清楚，再谈Agent", "建议必须进入可执行工作流，否则只是另一张仪表盘", "高价值部署往往是数据整合 + 规则/优化 + AI + Human-in-the-loop的组合", "持续把执行结果写回，才能形成可积累的运营记忆" ], "evidence": "Palantir官方架构文档明确点名Andretti RaceOS及其连接实时赛车性能与AI应用；技术细节披露有限。", "case_summary": "这个案例的重点是把“RaceOS实时赛车性能应用”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "媒体、营销与体育", "maturity_stage": "已上线", "fde_relation": "典型前向部署模式", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Andretti Racing：RaceOS实时赛车性能应用", "publisher": "Palantir", "url": "https://www.palantir.com/docs/foundry/architecture-center/platforms", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "Palantir官方架构文档明确点名Andretti RaceOS及其连接实时赛车性能与AI应用；技术细节披露有限。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] } ``` --- # Cisco｜Codex企业级软件工程闭环 - ID：openai-016 - 行业：科技与软件 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 大型多仓库、C/C++代码库与严格安全治理让AI编码很难直接进入生产。 ## 解决方案 Cisco与OpenAI直接合作，把Codex接入真实多仓库、CLI、构建、测试、缺陷修复和安全流程，并用生产反馈共同改进企业能力。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：Codex、CLI、多仓库检索、编译/测试、CI/CD、安全治理 ## 人机责任 工程师定义规格、审查关键变更并负责发布。 ## FDE 动作 > FDE视角编辑推演 - 与软件工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称95%+新AI功能由Codex编写；缺陷修复吞吐提升10–15倍；每月节省1,500+工程小时。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Cisco：Codex企业级软件工程闭环](https://openai.com/index/cisco/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方客户案例明确披露工作流、指标以及Cisco与OpenAI直接共同改进Codex的方式。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-016", "source": "OpenAI", "company": "Cisco", "industry": "科技/软件", "scenario": "Codex企业级软件工程闭环", "fde": "伴随式部署", "problem": "大型多仓库、C/C++代码库与严格安全治理让AI编码很难直接进入生产。", "solution": "Cisco与OpenAI直接合作，把Codex接入真实多仓库、CLI、构建、测试、缺陷修复和安全流程，并用生产反馈共同改进企业能力。", "human": "工程师定义规格、审查关键变更并负责发布。", "result": "官方称95%+新AI功能由Codex编写；缺陷修复吞吐提升10–15倍；每月节省1,500+工程小时。", "maturity": "大规模生产", "url": "https://openai.com/index/cisco/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "Codex", "CLI", "多仓库检索", "编译/测试", "CI/CD", "安全治理" ], "fde_actions": [ "与软件工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方客户案例明确披露工作流、指标以及Cisco与OpenAI直接共同改进Codex的方式。", "case_summary": "这个案例的重点是把“Codex企业级软件工程闭环”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "伴随式部署", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Cisco：Codex企业级软件工程闭环", "publisher": "OpenAI", "url": "https://openai.com/index/cisco/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方客户案例明确披露工作流、指标以及Cisco与OpenAI直接共同改进Codex的方式。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # BNY｜企业Agent平台 Eliza - ID：openai-017 - 行业：金融与保险 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 大型金融机构需要在安全治理下让大量员工自己构建Agent，而不是由中央团队逐个开发。 ## 解决方案 BNY建立AI Hub和内部平台Eliza，接入OpenAI模型与企业治理，让员工在平台上开发受控Agent和工作流。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：OpenAI API、ChatGPT、内部Agent平台 Eliza、企业治理、权限/审计 ## 人机责任 员工负责业务判断；中央AI/风险团队定义治理与平台边界。 ## FDE 动作 > FDE视角编辑推演 - 与金融与企业知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称平台支持125+线上用例、20,000名员工主动构建Agent，法律审查时间减少75%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [BNY：企业Agent平台 Eliza](https://openai.com/index/bny/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露Eliza平台、20k构建者、125+用例和75%法律审查时间下降。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-017", "source": "OpenAI", "company": "BNY", "industry": "金融", "scenario": "企业Agent平台 Eliza", "fde": "企业部署案例", "problem": "大型金融机构需要在安全治理下让大量员工自己构建Agent，而不是由中央团队逐个开发。", "solution": "BNY建立AI Hub和内部平台Eliza，接入OpenAI模型与企业治理，让员工在平台上开发受控Agent和工作流。", "human": "员工负责业务判断；中央AI/风险团队定义治理与平台边界。", "result": "官方称平台支持125+线上用例、20,000名员工主动构建Agent，法律审查时间减少75%。", "maturity": "规模化", "url": "https://openai.com/index/bny/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "OpenAI API", "ChatGPT", "内部Agent平台 Eliza", "企业治理", "权限/审计" ], "fde_actions": [ "与金融与企业知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露Eliza平台、20k构建者、125+用例和75%法律审查时间下降。", "case_summary": "这个案例的重点是把“企业Agent平台 Eliza”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "BNY：企业Agent平台 Eliza", "publisher": "OpenAI", "url": "https://openai.com/index/bny/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露Eliza平台、20k构建者、125+用例和75%法律审查时间下降。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Rakuten｜Codex事件响应、CI/CD与自主开发 - ID：openai-018 - 行业：金融与保险 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 复杂产品生态中既要加快故障恢复和开发，也不能降低代码审查与安全标准。 ## 解决方案 Codex接入KQL日志分析、根因定位、CI/CD代码审查、漏洞检查和端到端项目构建。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：Codex、KQL/日志、CI/CD、漏洞检查、FastAPI/Swift示例 ## 人机责任 SRE/工程师验证修复、定义标准并负责生产发布。 ## FDE 动作 > FDE视角编辑推演 - 与SRE与软件工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称MTTR下降约50%；部分项目从季度压缩到数周，潜在开发速度提升3–4倍。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Rakuten：Codex事件响应、CI/CD与自主开发](https://openai.com/index/rakuten/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例详细披露三个工作流和指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-018", "source": "OpenAI", "company": "Rakuten", "industry": "零售/科技/金融", "scenario": "Codex事件响应、CI/CD与自主开发", "fde": "企业部署案例", "problem": "复杂产品生态中既要加快故障恢复和开发，也不能降低代码审查与安全标准。", "solution": "Codex接入KQL日志分析、根因定位、CI/CD代码审查、漏洞检查和端到端项目构建。", "human": "SRE/工程师验证修复、定义标准并负责生产发布。", "result": "官方称MTTR下降约50%；部分项目从季度压缩到数周，潜在开发速度提升3–4倍。", "maturity": "生产级", "url": "https://openai.com/index/rakuten/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "Codex", "KQL/日志", "CI/CD", "漏洞检查", "FastAPI/Swift示例" ], "fde_actions": [ "与SRE与软件工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例详细披露三个工作流和指标。", "case_summary": "这个案例的重点是把“Codex事件响应、CI/CD与自主开发”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Rakuten：Codex事件响应、CI/CD与自主开发", "publisher": "OpenAI", "url": "https://openai.com/index/rakuten/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例详细披露三个工作流和指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Boston Children's Hospital｜医院运营自动化 + 罕见病诊断辅助 - ID：openai-019 - 行业：医疗与生命科学 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 医院同时面临大量重复运营工作和极难的罕见病信息综合问题。 ## 解决方案 将AI作为医院基础设施：运营侧建设50+自动化；临床侧把遗传、表型和文献连接给“co-pilot geneticist”产生证据化候选。 ## 技术工作流 > 公开信息与编辑推演混合 1. 临床/运营数据与医学文献 2. 受控检索与结构化上下文 3. OpenAI推理模型生成证据链接的候选解释/草稿 4. 规则、Evals与专业人员复核 5. 医生/临床团队做最终诊断或运营决策 6. 确认结果与失败模式用于后续流程优化 组件：ChatGPT、OpenAI推理模型、自动化工作流、遗传/表型/文献数据、专家复核 ## 人机责任 医院人员审核运营输出；医生与遗传专家负责临床确认。 ## FDE 动作 > FDE视角编辑推演 - 与医院运营与遗传诊断团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** OpenAI称50多项自动化累计节省约60,000小时，并将其折算为超过700万美元的“重新配置劳动力价值”。这是时间节省对应的劳动力价值，不等于实际减少的现金支出或项目净利润；实施、运行成本及净ROI未披露。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Boston Children's Hospital：医院运营自动化 + 罕见病诊断辅助](https://openai.com/index/boston-childrens-hospital/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露运营与临床两类结果；诊断均由医生完成，模型只提供线索。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 - 700万美元为来源方所称的重新配置劳动力价值，不等于实际削减的现金成本。 ## 完整原始结构化记录 ```json { "id": "openai-019", "source": "OpenAI", "company": "Boston Children's Hospital", "industry": "医疗", "scenario": "医院运营自动化 + 罕见病诊断辅助", "fde": "伴随式部署", "problem": "医院同时面临大量重复运营工作和极难的罕见病信息综合问题。", "solution": "将AI作为医院基础设施：运营侧建设50+自动化；临床侧把遗传、表型和文献连接给“co-pilot geneticist”产生证据化候选。", "human": "医院人员审核运营输出；医生与遗传专家负责临床确认。", "result": "OpenAI称50多项自动化累计节省约60,000小时，并将其折算为超过700万美元的“重新配置劳动力价值”。这是时间节省对应的劳动力价值，不等于实际减少的现金支出或项目净利润；实施、运行成本及净ROI未披露。", "maturity": "规模化", "url": "https://openai.com/index/boston-childrens-hospital/", "architecture": [ "临床/运营数据与医学文献", "受控检索与结构化上下文", "OpenAI推理模型生成证据链接的候选解释/草稿", "规则、Evals与专业人员复核", "医生/临床团队做最终诊断或运营决策", "确认结果与失败模式用于后续流程优化" ], "components": [ "ChatGPT", "OpenAI推理模型", "自动化工作流", "遗传/表型/文献数据", "专家复核" ], "fde_actions": [ "与医院运营与遗传诊断团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露运营与临床两类结果；诊断均由医生完成，模型只提供线索。", "case_summary": "这个案例的重点是把“医院运营自动化 + 罕见病诊断辅助”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "伴随式部署", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Boston Children's Hospital：医院运营自动化 + 罕见病诊断辅助", "publisher": "OpenAI", "url": "https://openai.com/index/boston-childrens-hospital/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露运营与临床两类结果；诊断均由医生完成，模型只提供线索。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。", "700万美元为来源方所称的重新配置劳动力价值，不等于实际削减的现金成本。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Morgan Stanley｜财富管理知识助手 + Evals体系 - ID：openai-020 - 行业：金融与保险 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 财富顾问需要从庞大且高合规要求的研究与流程文档中快速获得可信答案。 ## 解决方案 Morgan Stanley与OpenAI共同优化检索和Evals：对摘要、翻译、检索进行专家评分和回归测试，再扩展到Advisor Assistant和会议Debrief。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：GPT-4、RAG/检索、Evals、Whisper、专家评分、回归测试 ## 人机责任 顾问与内部专家评估答案并承担客户建议责任。 ## FDE 动作 > FDE视角编辑推演 - 与财富管理团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称98%+顾问团队使用；可回答语料从约7,000问题扩到10万份文档；文档可访问率从20%升到80%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Morgan Stanley：财富管理知识助手 + Evals体系](https://openai.com/index/morgan-stanley/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例详细披露Evals、检索迭代、采用率与文档覆盖变化。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-020", "source": "OpenAI", "company": "Morgan Stanley", "industry": "金融", "scenario": "财富管理知识助手 + Evals体系", "fde": "伴随式部署", "problem": "财富顾问需要从庞大且高合规要求的研究与流程文档中快速获得可信答案。", "solution": "Morgan Stanley与OpenAI共同优化检索和Evals：对摘要、翻译、检索进行专家评分和回归测试，再扩展到Advisor Assistant和会议Debrief。", "human": "顾问与内部专家评估答案并承担客户建议责任。", "result": "官方称98%+顾问团队使用；可回答语料从约7,000问题扩到10万份文档；文档可访问率从20%升到80%。", "maturity": "大规模生产", "url": "https://openai.com/index/morgan-stanley/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "GPT-4", "RAG/检索", "Evals", "Whisper", "专家评分", "回归测试" ], "fde_actions": [ "与财富管理团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例详细披露Evals、检索迭代、采用率与文档覆盖变化。", "case_summary": "这个案例的重点是把“财富管理知识助手 + Evals体系”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "伴随式部署", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Morgan Stanley：财富管理知识助手 + Evals体系", "publisher": "OpenAI", "url": "https://openai.com/index/morgan-stanley/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例详细披露Evals、检索迭代、采用率与文档覆盖变化。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Klarna｜AI客服助手 - ID：openai-021 - 行业：金融与保险 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 大规模多语言支付与购物客服需要降低等待时间，同时保持解决率和客户满意度。 ## 解决方案 OpenAI模型进入客服工作流，处理多语言咨询、退款、退货和财务健康相关问题，并将复杂事项升级人工。 ## 技术工作流 > 公开信息与编辑推演混合 1. 用户请求/业务事件/历史上下文 2. OpenAI模型识别意图并检索企业知识 3. Agent调用业务系统/API/工具执行任务 4. 政策、权限、Evals和确定性检查约束行为 5. 复杂/高风险场景升级人工 6. 生产对话与失败案例进入持续改进循环 组件：OpenAI模型、客服知识、业务系统动作、多语言、人工升级 ## 人机责任 人工客服处理复杂例外；产品团队监控质量和升级率。 ## FDE 动作 > FDE视角编辑推演 - 与客服与支付运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 上线首月处理230万次对话、约占客服聊天2/3；相当于700名全职坐席工作量，重复咨询下降25%，平均解决时间11分钟→<2分钟。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Klarna：AI客服助手](https://openai.com/index/klarna/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露客服范围和多项指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-021", "source": "OpenAI", "company": "Klarna", "industry": "金融/电商", "scenario": "AI客服助手", "fde": "企业部署案例", "problem": "大规模多语言支付与购物客服需要降低等待时间，同时保持解决率和客户满意度。", "solution": "OpenAI模型进入客服工作流，处理多语言咨询、退款、退货和财务健康相关问题，并将复杂事项升级人工。", "human": "人工客服处理复杂例外；产品团队监控质量和升级率。", "result": "上线首月处理230万次对话、约占客服聊天2/3；相当于700名全职坐席工作量，重复咨询下降25%，平均解决时间11分钟→<2分钟。", "maturity": "大规模生产", "url": "https://openai.com/index/klarna/", "architecture": [ "用户请求/业务事件/历史上下文", "OpenAI模型识别意图并检索企业知识", "Agent调用业务系统/API/工具执行任务", "政策、权限、Evals和确定性检查约束行为", "复杂/高风险场景升级人工", "生产对话与失败案例进入持续改进循环" ], "components": [ "OpenAI模型", "客服知识", "业务系统动作", "多语言", "人工升级" ], "fde_actions": [ "与客服与支付运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露客服范围和多项指标。", "case_summary": "这个案例的重点是把“AI客服助手”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Klarna：AI客服助手", "publisher": "OpenAI", "url": "https://openai.com/index/klarna/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露客服范围和多项指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Commonwealth Bank of Australia｜全员AI能力 + 客服/反欺诈Agent扩展 - ID：openai-022 - 行业：金融与保险 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（8/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 大型银行既要普及AI，又要在安全、数据连接和高风险客户场景下维持一致治理。 ## 解决方案 向近5万员工部署ChatGPT Enterprise，配套连接器、培训、领导示范和内部实验，再逐步扩展到客服、诈骗/欺诈响应等Agent场景。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、Connectors、培训/治理、Agent扩展、风险控制 ## 人机责任 员工与风险团队控制高风险客户动作。 ## FDE 动作 > FDE视角编辑推演 - 与银行运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称近50,000名员工部署ChatGPT Enterprise；后续Agent业务仍在扩展。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Commonwealth Bank of Australia：全员AI能力 + 客服/反欺诈Agent扩展](https://openai.com/index/commonwealth-bank-of-australia/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露近50k员工部署和下一阶段高影响场景；未披露具体Agent ROI。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-022", "source": "OpenAI", "company": "Commonwealth Bank of Australia", "industry": "金融", "scenario": "全员AI能力 + 客服/反欺诈Agent扩展", "fde": "企业部署案例", "problem": "大型银行既要普及AI，又要在安全、数据连接和高风险客户场景下维持一致治理。", "solution": "向近5万员工部署ChatGPT Enterprise，配套连接器、培训、领导示范和内部实验，再逐步扩展到客服、诈骗/欺诈响应等Agent场景。", "human": "员工与风险团队控制高风险客户动作。", "result": "官方称近50,000名员工部署ChatGPT Enterprise；后续Agent业务仍在扩展。", "maturity": "规模化", "url": "https://openai.com/index/commonwealth-bank-of-australia/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "Connectors", "培训/治理", "Agent扩展", "风险控制" ], "fde_actions": [ "与银行运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露近50k员工部署和下一阶段高影响场景；未披露具体Agent ROI。", "case_summary": "这个案例的重点是把“全员AI能力 + 客服/反欺诈Agent扩展”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Commonwealth Bank of Australia：全员AI能力 + 客服/反欺诈Agent扩展", "publisher": "OpenAI", "url": "https://openai.com/index/commonwealth-bank-of-australia/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露近50k员工部署和下一阶段高影响场景；未披露具体Agent ROI。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理", "量化结果" ] } ``` --- # Taisei Corporation｜HR主导的全员AI人才培养 - ID：openai-023 - 行业：专业服务 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 传统建筑企业需要把AI从少数技术人员扩展为全员技能，同时真正进入日常工作。 ## 解决方案 由HR牵头将ChatGPT Enterprise作为人才发展基础设施，鼓励员工构建自定义GPT并把成功模式在组织内扩散。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、Custom GPTs、HR培训、企业治理 ## 人机责任 员工负责业务判断，HR/治理团队推动训练和规范。 ## FDE 动作 > FDE视角编辑推演 - 与人才与知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称创建3,300个Custom GPT，周活跃率90%，每名员工每周节省5.5小时以上。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Taisei Corporation：HR主导的全员AI人才培养](https://openai.com/index/taisei/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露使用率、GPT数量与节省时间。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-023", "source": "OpenAI", "company": "Taisei Corporation", "industry": "建筑/工程", "scenario": "HR主导的全员AI人才培养", "fde": "企业部署案例", "problem": "传统建筑企业需要把AI从少数技术人员扩展为全员技能，同时真正进入日常工作。", "solution": "由HR牵头将ChatGPT Enterprise作为人才发展基础设施，鼓励员工构建自定义GPT并把成功模式在组织内扩散。", "human": "员工负责业务判断，HR/治理团队推动训练和规范。", "result": "官方称创建3,300个Custom GPT，周活跃率90%，每名员工每周节省5.5小时以上。", "maturity": "规模化", "url": "https://openai.com/index/taisei/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "Custom GPTs", "HR培训", "企业治理" ], "fde_actions": [ "与人才与知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露使用率、GPT数量与节省时间。", "case_summary": "这个案例的重点是把“HR主导的全员AI人才培养”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "专业服务", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Taisei Corporation：HR主导的全员AI人才培养", "publisher": "OpenAI", "url": "https://openai.com/index/taisei/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露使用率、GPT数量与节省时间。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "技术工作流", "人机与治理" ] } ``` --- # ENEOS Materials｜制造企业全员知识与深度研究 - ID：openai-024 - 行业：制造与工业 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 材料制造企业在用工紧张和成本上升下，需要安全使用专有信息并降低数据汇总与调查时间。 ## 解决方案 先从ChatGPT Enterprise试点验证，再扩到全员；HR、研发和知识工作使用数据分析、深度研究与企业知识。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、Deep Research、数据分析、企业知识 ## 人机责任 专业人员验证技术与业务结论。 ## FDE 动作 > FDE视角编辑推演 - 与制造知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称试点80%员工认为工作显著改善；HR数据汇总与分析时间下降90%；部分调查从数月降至分钟。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [ENEOS Materials：制造企业全员知识与深度研究](https://openai.com/index/eneos-materials/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露试点与时间节省指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-024", "source": "OpenAI", "company": "ENEOS Materials", "industry": "材料/制造", "scenario": "制造企业全员知识与深度研究", "fde": "企业部署案例", "problem": "材料制造企业在用工紧张和成本上升下，需要安全使用专有信息并降低数据汇总与调查时间。", "solution": "先从ChatGPT Enterprise试点验证，再扩到全员；HR、研发和知识工作使用数据分析、深度研究与企业知识。", "human": "专业人员验证技术与业务结论。", "result": "官方称试点80%员工认为工作显著改善；HR数据汇总与分析时间下降90%；部分调查从数月降至分钟。", "maturity": "规模化", "url": "https://openai.com/index/eneos-materials/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "Deep Research", "数据分析", "企业知识" ], "fde_actions": [ "与制造知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露试点与时间节省指标。", "case_summary": "这个案例的重点是把“制造企业全员知识与深度研究”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "ENEOS Materials：制造企业全员知识与深度研究", "publisher": "OpenAI", "url": "https://openai.com/index/eneos-materials/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露试点与时间节省指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] } ``` --- # Dai Nippon Printing (DNP)｜跨部门流程自动化与处理量提升 - ID：openai-025 - 行业：制造与工业 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 大型多事业部企业需要证明AI不是个人助手，而是能在多个部门形成可测量流程改造。 ## 解决方案 ChatGPT Enterprise进入多事业部工作流，团队把重复流程改造成可复用的自动化和分析模板。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、流程模板、数据分析、企业治理 ## 人机责任 员工负责例外与最终业务输出。 ## FDE 动作 > FDE视角编辑推演 - 与跨部门流程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称90%的用例取得可测量结果、周活100%、时间缩减相关自动化率87%，部分处理量提升10倍。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Dai Nippon Printing (DNP)：跨部门流程自动化与处理量提升](https://openai.com/index/dai-nippon-printing/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露多项采用与效率指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-025", "source": "OpenAI", "company": "Dai Nippon Printing (DNP)", "industry": "制造/印刷", "scenario": "跨部门流程自动化与处理量提升", "fde": "企业部署案例", "problem": "大型多事业部企业需要证明AI不是个人助手，而是能在多个部门形成可测量流程改造。", "solution": "ChatGPT Enterprise进入多事业部工作流，团队把重复流程改造成可复用的自动化和分析模板。", "human": "员工负责例外与最终业务输出。", "result": "官方称90%的用例取得可测量结果、周活100%、时间缩减相关自动化率87%，部分处理量提升10倍。", "maturity": "规模化", "url": "https://openai.com/index/dai-nippon-printing/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "流程模板", "数据分析", "企业治理" ], "fde_actions": [ "与跨部门流程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露多项采用与效率指标。", "case_summary": "这个案例的重点是把“跨部门流程自动化与处理量提升”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Dai Nippon Printing (DNP)：跨部门流程自动化与处理量提升", "publisher": "OpenAI", "url": "https://openai.com/index/dai-nippon-printing/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露多项采用与效率指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] } ``` --- # Simplex｜量化验证AI原生软件交付 - ID：openai-026 - 行业：科技与软件 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产/规模化 - 独立核验：未记录 ## 业务问题 系统集成项目需要知道AI到底在设计、开发、测试哪个环节真正节省时间，而不是凭感受部署。 ## 解决方案 建立AI CoE，对ChatGPT Enterprise/Codex在设计、编码和集成测试环节进行量化测量，再将有效模式推广到项目。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：Codex、ChatGPT Enterprise、CoE、软件生命周期测量、测试 ## 人机责任 工程师验证生成物并负责交付质量。 ## FDE 动作 > FDE视角编辑推演 - 与系统开发团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称单屏开发时间减少70%，设计减少40%，内部集成测试减少17%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Simplex：量化验证AI原生软件交付](https://openai.com/index/simplex/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露按SDLC环节测量的效率指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-026", "source": "OpenAI", "company": "Simplex", "industry": "科技/软件", "scenario": "量化验证AI原生软件交付", "fde": "企业部署案例", "problem": "系统集成项目需要知道AI到底在设计、开发、测试哪个环节真正节省时间，而不是凭感受部署。", "solution": "建立AI CoE，对ChatGPT Enterprise/Codex在设计、编码和集成测试环节进行量化测量，再将有效模式推广到项目。", "human": "工程师验证生成物并负责交付质量。", "result": "官方称单屏开发时间减少70%，设计减少40%，内部集成测试减少17%。", "maturity": "生产/规模化", "url": "https://openai.com/index/simplex/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "Codex", "ChatGPT Enterprise", "CoE", "软件生命周期测量", "测试" ], "fde_actions": [ "与系统开发团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露按SDLC环节测量的效率指标。", "case_summary": "这个案例的重点是把“量化验证AI原生软件交付”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Simplex：量化验证AI原生软件交付", "publisher": "OpenAI", "url": "https://openai.com/index/simplex/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露按SDLC环节测量的效率指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Wayfair｜商品目录质量 + 供应商客服自动化 - ID：openai-027 - 行业：零售与消费 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 数百万商品的属性和标签错误影响搜索与体验；同时供应商支持工单量巨大。 ## 解决方案 把OpenAI模型嵌入商品目录和供应商支持系统，自动修正标签并处理可标准化工单。 ## 技术工作流 > 公开信息与编辑推演混合 1. 用户请求/业务事件/历史上下文 2. OpenAI模型识别意图并检索企业知识 3. Agent调用业务系统/API/工具执行任务 4. 政策、权限、Evals和确定性检查约束行为 5. 复杂/高风险场景升级人工 6. 生产对话与失败案例进入持续改进循环 组件：OpenAI API、商品目录系统、供应商客服、分类/抽取、Human escalation ## 人机责任 目录与支持团队处理低置信度和复杂问题。 ## FDE 动作 > FDE视角编辑推演 - 与零售目录与供应商运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称修正250万商品标签，每月自动化41,000个供应商支持工单，并部署1,200个ChatGPT Enterprise席位。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Wayfair：商品目录质量 + 供应商客服自动化](https://openai.com/index/wayfair/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露嵌入核心内部系统及三项量化指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-027", "source": "OpenAI", "company": "Wayfair", "industry": "零售/电商", "scenario": "商品目录质量 + 供应商客服自动化", "fde": "企业部署案例", "problem": "数百万商品的属性和标签错误影响搜索与体验；同时供应商支持工单量巨大。", "solution": "把OpenAI模型嵌入商品目录和供应商支持系统，自动修正标签并处理可标准化工单。", "human": "目录与支持团队处理低置信度和复杂问题。", "result": "官方称修正250万商品标签，每月自动化41,000个供应商支持工单，并部署1,200个ChatGPT Enterprise席位。", "maturity": "大规模生产", "url": "https://openai.com/index/wayfair/", "architecture": [ "用户请求/业务事件/历史上下文", "OpenAI模型识别意图并检索企业知识", "Agent调用业务系统/API/工具执行任务", "政策、权限、Evals和确定性检查约束行为", "复杂/高风险场景升级人工", "生产对话与失败案例进入持续改进循环" ], "components": [ "OpenAI API", "商品目录系统", "供应商客服", "分类/抽取", "Human escalation" ], "fde_actions": [ "与零售目录与供应商运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露嵌入核心内部系统及三项量化指标。", "case_summary": "这个案例的重点是把“商品目录质量 + 供应商客服自动化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Wayfair：商品目录质量 + 供应商客服自动化", "publisher": "OpenAI", "url": "https://openai.com/index/wayfair/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露嵌入核心内部系统及三项量化指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # HiBob｜内部GPT实验到客户产品 - ID：openai-028 - 行业：科技与软件 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 公司希望让员工快速实验AI，同时把真正有效的内部原型转成面向客户的产品能力。 ## 解决方案 员工在ChatGPT Enterprise中构建大量GPT进行实验，成功工作流再用OpenAI API产品化到Bob平台。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、Custom GPTs、OpenAI API、原型→产品化、HR数据 ## 人机责任 员工与产品团队筛选有效原型并控制产品发布。 ## FDE 动作 > FDE视角编辑推演 - 与HR产品与内部运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称90%+员工活跃使用；构建2,500+实验GPT，其中约200个成功进入内部工作流。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [HiBob：内部GPT实验到客户产品](https://openai.com/index/hibob/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露GPT漏斗与产品化路径。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-028", "source": "OpenAI", "company": "HiBob", "industry": "HR科技/SaaS", "scenario": "内部GPT实验到客户产品", "fde": "企业部署案例", "problem": "公司希望让员工快速实验AI，同时把真正有效的内部原型转成面向客户的产品能力。", "solution": "员工在ChatGPT Enterprise中构建大量GPT进行实验，成功工作流再用OpenAI API产品化到Bob平台。", "human": "员工与产品团队筛选有效原型并控制产品发布。", "result": "官方称90%+员工活跃使用；构建2,500+实验GPT，其中约200个成功进入内部工作流。", "maturity": "规模化", "url": "https://openai.com/index/hibob/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "Custom GPTs", "OpenAI API", "原型→产品化", "HR数据" ], "fde_actions": [ "与HR产品与内部运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露GPT漏斗与产品化路径。", "case_summary": "这个案例的重点是把“内部GPT实验到客户产品”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "HiBob：内部GPT实验到客户产品", "publisher": "OpenAI", "url": "https://openai.com/index/hibob/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露GPT漏斗与产品化路径。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # Scania｜全球工业员工AI采用 - ID：openai-029 - 行业：制造与工业 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 工程和一线团队知识密集，但AI采用不能只停留在总部或技术团队。 ## 解决方案 ChatGPT Enterprise面向全球员工推广，通过底层试用、内部社区和场景共创，将AI带入工程、学习和运营。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、员工赋能、知识工作、治理/培训 ## 人机责任 工程与一线人员保持安全、质量和生产责任。 ## FDE 动作 > FDE视角编辑推演 - 与工业知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** 官方案例称工程与一线出现强烈bottom-up adoption，并在生产力、质量和运营流程出现早期收益；未披露统一ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Scania：全球工业员工AI采用](https://openai.com/index/scania/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露采用方式和早期效果，但未给统一量化指标。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-029", "source": "OpenAI", "company": "Scania", "industry": "汽车/制造", "scenario": "全球工业员工AI采用", "fde": "企业部署案例", "problem": "工程和一线团队知识密集，但AI采用不能只停留在总部或技术团队。", "solution": "ChatGPT Enterprise面向全球员工推广，通过底层试用、内部社区和场景共创，将AI带入工程、学习和运营。", "human": "工程与一线人员保持安全、质量和生产责任。", "result": "官方案例称工程与一线出现强烈bottom-up adoption，并在生产力、质量和运营流程出现早期收益；未披露统一ROI。", "maturity": "规模化", "url": "https://openai.com/index/scania/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "员工赋能", "知识工作", "治理/培训" ], "fde_actions": [ "与工业知识工作团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露采用方式和早期效果，但未给统一量化指标。", "case_summary": "这个案例的重点是把“全球工业员工AI采用”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Scania：全球工业员工AI采用", "publisher": "OpenAI", "url": "https://openai.com/index/scania/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露采用方式和早期效果，但未给统一量化指标。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "技术工作流", "人机与治理", "量化结果" ] } ``` --- # CyberAgent｜ChatGPT + Codex组织级采用 - ID：openai-030 - 行业：媒体、营销与体育 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 互联网公司希望同时提升非技术知识工作和工程开发质量，并让AI自然进入团队决策。 ## 解决方案 ChatGPT Enterprise提供安全通用入口；Codex用于实现前的方案思考、编码和开发流程，提高团队速度与信心。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：ChatGPT Enterprise、Codex、工程工作流、安全治理 ## 人机责任 产品与工程人员保留设计、审核和发布责任。 ## FDE 动作 > FDE视角编辑推演 - 与互联网产品与工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称ChatGPT Enterprise月活跃使用率93%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [CyberAgent：ChatGPT + Codex组织级采用](https://openai.com/index/cyberagent/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露93%月活及Codex进入开发决策流程。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-030", "source": "OpenAI", "company": "CyberAgent", "industry": "互联网/媒体/游戏", "scenario": "ChatGPT + Codex组织级采用", "fde": "企业部署案例", "problem": "互联网公司希望同时提升非技术知识工作和工程开发质量，并让AI自然进入团队决策。", "solution": "ChatGPT Enterprise提供安全通用入口；Codex用于实现前的方案思考、编码和开发流程，提高团队速度与信心。", "human": "产品与工程人员保留设计、审核和发布责任。", "result": "官方称ChatGPT Enterprise月活跃使用率93%。", "maturity": "规模化", "url": "https://openai.com/index/cyberagent/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "ChatGPT Enterprise", "Codex", "工程工作流", "安全治理" ], "fde_actions": [ "与互联网产品与工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露93%月活及Codex进入开发决策流程。", "case_summary": "这个案例的重点是把“ChatGPT + Codex组织级采用”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "媒体、营销与体育", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "CyberAgent：ChatGPT + Codex组织级采用", "publisher": "OpenAI", "url": "https://openai.com/index/cyberagent/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露93%月活及Codex进入开发决策流程。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "技术工作流", "人机与治理" ] } ``` --- # Braintrust｜客户需求直接转预览分支 - ID：openai-031 - 行业：科技与软件 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：生产级 - 独立核验：未记录 ## 业务问题 客户反馈到可体验产品之间的周期限制了产品团队试错速度。 ## 解决方案 工程师把客户feature request交给Codex，Agent直接创建可运行的preview branch，再由团队和客户快速验证。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：Codex、Git分支、客户反馈、测试/Review ## 人机责任 工程师负责Review与是否合并，客户反馈决定方向。 ## FDE 动作 > FDE视角编辑推演 - 与产品工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称一个月内团队50%转向Codex；客户请求可在数分钟形成可演示分支。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Braintrust：客户需求直接转预览分支](https://openai.com/index/braintrust/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露“需求→preview branch”流程和50%团队迁移。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-031", "source": "OpenAI", "company": "Braintrust", "industry": "AI开发工具", "scenario": "客户需求直接转预览分支", "fde": "企业部署案例", "problem": "客户反馈到可体验产品之间的周期限制了产品团队试错速度。", "solution": "工程师把客户feature request交给Codex，Agent直接创建可运行的preview branch，再由团队和客户快速验证。", "human": "工程师负责Review与是否合并，客户反馈决定方向。", "result": "官方称一个月内团队50%转向Codex；客户请求可在数分钟形成可演示分支。", "maturity": "生产级", "url": "https://openai.com/index/braintrust/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "Codex", "Git分支", "客户反馈", "测试/Review" ], "fde_actions": [ "与产品工程团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露“需求→preview branch”流程和50%团队迁移。", "case_summary": "这个案例的重点是把“客户需求直接转预览分支”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Braintrust：客户需求直接转预览分支", "publisher": "OpenAI", "url": "https://openai.com/index/braintrust/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露“需求→preview branch”流程和50%团队迁移。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "技术工作流", "人机与治理" ] } ``` --- # Cars24｜语音/对话Agent + 服务流程自动化 - ID：openai-032 - 行业：制造与工业 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（9/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 二手车平台交易链路人工、碎片化且高度依赖对话，丢失线索和服务周转时间直接影响收入。 ## 解决方案 OpenAI驱动的Agent承接大规模对话，连接线索和服务工作流，用AI进行再触达与问题解决。 ## 技术工作流 > 公开信息与编辑推演混合 1. 用户请求/业务事件/历史上下文 2. OpenAI模型识别意图并检索企业知识 3. Agent调用业务系统/API/工具执行任务 4. 政策、权限、Evals和确定性检查约束行为 5. 复杂/高风险场景升级人工 6. 生产对话与失败案例进入持续改进循环 组件：OpenAI API、语音/对话Agent、CRM/线索系统、服务工作流、Human escalation ## 人机责任 复杂交易、监管和高价值谈判升级人工。 ## FDE 动作 > FDE视角编辑推演 - 与汽车交易与客服团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称AI Agent每月处理100万+分钟对话，客服解决率提升50%，关键服务周转时间下降80%，追回12%此前丢失卖家线索。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Cars24：语音/对话Agent + 服务流程自动化](https://openai.com/index/cars24/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露多个生产指标和Agent规模。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-032", "source": "OpenAI", "company": "Cars24", "industry": "汽车/平台", "scenario": "语音/对话Agent + 服务流程自动化", "fde": "企业部署案例", "problem": "二手车平台交易链路人工、碎片化且高度依赖对话，丢失线索和服务周转时间直接影响收入。", "solution": "OpenAI驱动的Agent承接大规模对话，连接线索和服务工作流，用AI进行再触达与问题解决。", "human": "复杂交易、监管和高价值谈判升级人工。", "result": "官方称AI Agent每月处理100万+分钟对话，客服解决率提升50%，关键服务周转时间下降80%，追回12%此前丢失卖家线索。", "maturity": "大规模生产", "url": "https://openai.com/index/cars24/", "architecture": [ "用户请求/业务事件/历史上下文", "OpenAI模型识别意图并检索企业知识", "Agent调用业务系统/API/工具执行任务", "政策、权限、Evals和确定性检查约束行为", "复杂/高风险场景升级人工", "生产对话与失败案例进入持续改进循环" ], "components": [ "OpenAI API", "语音/对话Agent", "CRM/线索系统", "服务工作流", "Human escalation" ], "fde_actions": [ "与汽车交易与客服团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露多个生产指标和Agent规模。", "case_summary": "这个案例的重点是把“语音/对话Agent + 服务流程自动化”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "制造与工业", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Cars24：语音/对话Agent + 服务流程自动化", "publisher": "OpenAI", "url": "https://openai.com/index/cars24/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露多个生产指标和Agent规模。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "人机与治理" ] } ``` --- # Holiday Extras｜全员AI生产力 + 旅行保险助手 - ID：openai-033 - 行业：金融与保险 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：规模化 - 独立核验：未记录 ## 业务问题 旅行公司需要既提高内部知识工作效率，又把AI扩展到客户保险和个性化旅行体验。 ## 解决方案 内部用ChatGPT Enterprise做写作、分析、调试；客户侧用OpenAI API构建Syd AI解释旅行保险，并推进个性化super app。 ## 技术工作流 > 公开信息与编辑推演混合 1. 企业知识/文件/数据/业务系统 2. ChatGPT Enterprise/Work在权限范围内获取上下文 3. 员工或自定义GPT/Agent完成分析、生成或自动化 4. 连接器/规则/企业治理控制数据与动作边界 5. 员工复核关键输出并执行 6. 高频流程沉淀为模板、GPT或Agent并持续评估 组件：ChatGPT Enterprise、OpenAI API、保险知识助手、代码调试、个性化推荐 ## 人机责任 员工审核业务内容，保险高风险解释保留受控知识与人工升级。 ## FDE 动作 > FDE视角编辑推演 - 与旅行运营与产品团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** OpenAI案例称员工每周累计节省500多小时，并折算为每年约50万美元节省；同一来源还称30%的客服咨询由AI机器人先行处理，客服成本下降、NPS由60升至70，但未给出成本降幅。50万美元是工时折算值，不应直接当作已实现现金节省；项目费用和净ROI未披露。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Holiday Extras：全员AI生产力 + 旅行保险助手](https://openai.com/index/holiday-extras/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-23 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露采用率、时间节省与客户AI产品方向。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 - 客服成本下降未量化；每年约50万美元来自节省工时折算，来源未披露项目净ROI。 ## 完整原始结构化记录 ```json { "id": "openai-033", "source": "OpenAI", "company": "Holiday Extras", "industry": "旅行/保险", "scenario": "全员AI生产力 + 旅行保险助手", "fde": "企业部署案例", "problem": "旅行公司需要既提高内部知识工作效率，又把AI扩展到客户保险和个性化旅行体验。", "solution": "内部用ChatGPT Enterprise做写作、分析、调试；客户侧用OpenAI API构建Syd AI解释旅行保险，并推进个性化super app。", "human": "员工审核业务内容，保险高风险解释保留受控知识与人工升级。", "result": "OpenAI案例称员工每周累计节省500多小时，并折算为每年约50万美元节省；同一来源还称30%的客服咨询由AI机器人先行处理，客服成本下降、NPS由60升至70，但未给出成本降幅。50万美元是工时折算值，不应直接当作已实现现金节省；项目费用和净ROI未披露。", "maturity": "规模化", "url": "https://openai.com/index/holiday-extras/", "architecture": [ "企业知识/文件/数据/业务系统", "ChatGPT Enterprise/Work在权限范围内获取上下文", "员工或自定义GPT/Agent完成分析、生成或自动化", "连接器/规则/企业治理控制数据与动作边界", "员工复核关键输出并执行", "高频流程沉淀为模板、GPT或Agent并持续评估" ], "components": [ "ChatGPT Enterprise", "OpenAI API", "保险知识助手", "代码调试", "个性化推荐" ], "fde_actions": [ "与旅行运营与产品团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露采用率、时间节省与客户AI产品方向。", "case_summary": "这个案例的重点是把“全员AI生产力 + 旅行保险助手”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "金融与保险", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Holiday Extras：全员AI生产力 + 旅行保险助手", "publisher": "OpenAI", "url": "https://openai.com/index/holiday-extras/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露采用率、时间节省与客户AI产品方向。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。", "客服成本下降未量化；每年约50万美元来自节省工时折算，来源未披露项目净ROI。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # NTT DATA Group｜Codex复杂事故分析 - ID：openai-034 - 行业：科技与软件 - 来源：OpenAI - 详细度：深度案例｜关键链路较完整（10/12） - 证据：A级｜案例级直接来源 - 部署：大规模生产 - 独立核验：未记录 ## 业务问题 关键系统事故分析需要多位资深工程师数天拼接日志、代码和上下文。 ## 解决方案 Codex在受治理环境中独立调查、执行、测试和修订，完成复杂incident analysis，并逐步扩展到技术与非技术员工。 ## 技术工作流 > 公开信息与编辑推演混合 1. 代码库/Issue/日志/内部规范 2. Codex检索相关代码与上下文 3. Agent制定计划并生成修改 4. CLI/编译/测试/安全检查形成确定性反馈 5. 工程师Review高风险变更 6. CI/CD合并并用生产反馈继续改进 组件：Codex、日志/代码上下文、Agent执行、测试、企业治理 ## 人机责任 工程师验证结论和修复，负责生产系统。 ## FDE 动作 > FDE视角编辑推演 - 与IT运维与系统开发团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称一项原需5名资深工程师3天的事故分析由Codex在30分钟完成；Codex约9,000名活跃用户。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [NTT DATA Group：Codex复杂事故分析](https://openai.com/index/ntt-data/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露5人×3天→30分钟和约9,000用户。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-034", "source": "OpenAI", "company": "NTT DATA Group", "industry": "IT服务", "scenario": "Codex复杂事故分析", "fde": "企业部署案例", "problem": "关键系统事故分析需要多位资深工程师数天拼接日志、代码和上下文。", "solution": "Codex在受治理环境中独立调查、执行、测试和修订，完成复杂incident analysis，并逐步扩展到技术与非技术员工。", "human": "工程师验证结论和修复，负责生产系统。", "result": "官方称一项原需5名资深工程师3天的事故分析由Codex在30分钟完成；Codex约9,000名活跃用户。", "maturity": "大规模生产", "url": "https://openai.com/index/ntt-data/", "architecture": [ "代码库/Issue/日志/内部规范", "Codex检索相关代码与上下文", "Agent制定计划并生成修改", "CLI/编译/测试/安全检查形成确定性反馈", "工程师Review高风险变更", "CI/CD合并并用生产反馈继续改进" ], "components": [ "Codex", "日志/代码上下文", "Agent执行", "测试", "企业治理" ], "fde_actions": [ "与IT运维与系统开发团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露5人×3天→30分钟和约9,000用户。", "case_summary": "这个案例的重点是把“Codex复杂事故分析”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "NTT DATA Group：Codex复杂事故分析", "publisher": "OpenAI", "url": "https://openai.com/index/ntt-data/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露5人×3天→30分钟和约9,000用户。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 10, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "人机与治理" ] } ``` --- # AdventHealth｜临床行政负担与文档工作流 - ID：openai-035 - 行业：医疗与生命科学 - 来源：OpenAI - 详细度：标准案例｜可参考但仍有缺口（7/12） - 证据：A级｜案例级直接来源 - 部署：生产/扩展中 - 独立核验：未记录 ## 业务问题 大型医院系统临床人员花大量时间在记录、行政和支持任务，压缩患者照护时间。 ## 解决方案 部署ChatGPT for Healthcare，围绕文档和行政支持重构临床工作流，把可自动化任务交给AI。 ## 技术工作流 > 公开信息与编辑推演混合 1. 临床/运营数据与医学文献 2. 受控检索与结构化上下文 3. OpenAI推理模型生成证据链接的候选解释/草稿 4. 规则、Evals与专业人员复核 5. 医生/临床团队做最终诊断或运营决策 6. 确认结果与失败模式用于后续流程优化 组件：ChatGPT for Healthcare、临床文档、医疗治理、Human review ## 人机责任 临床人员保留医疗判断和患者责任。 ## FDE 动作 > FDE视角编辑推演 - 与临床运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口 - 确定模型需要的企业上下文、系统权限、工具和安全边界 - 把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证 - 设计Human-in-the-loop与失败升级路径，确保责任边界清楚 - 根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 官方称部分行政任务时间减少80%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力 - 先找可量化工作流，再把成功模式产品化/平台化 - 编码Agent要尽量接入测试、CI/CD和安全检查形成闭环 - 高风险行业必须把专业责任留给人，并建立持续Evals ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [AdventHealth：临床行政负担与文档工作流](https://openai.com/index/adventhealth/) - 发布方：OpenAI - 披露性质：厂商或客户公开披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：基于公开材料概括 - solution：基于公开材料概括 - architecture：公开信息与编辑推演混合 - fde_actions：FDE视角编辑推演 - result：厂商或客户披露 ## 待核对事项 - OpenAI官方案例明确披露80%行政任务时间下降；具体任务比例和系统架构未完全公开。 - 来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。 ## 完整原始结构化记录 ```json { "id": "openai-035", "source": "OpenAI", "company": "AdventHealth", "industry": "医疗", "scenario": "临床行政负担与文档工作流", "fde": "企业部署案例", "problem": "大型医院系统临床人员花大量时间在记录、行政和支持任务，压缩患者照护时间。", "solution": "部署ChatGPT for Healthcare，围绕文档和行政支持重构临床工作流，把可自动化任务交给AI。", "human": "临床人员保留医疗判断和患者责任。", "result": "官方称部分行政任务时间减少80%。", "maturity": "生产/扩展中", "url": "https://openai.com/index/adventhealth/", "architecture": [ "临床/运营数据与医学文献", "受控检索与结构化上下文", "OpenAI推理模型生成证据链接的候选解释/草稿", "规则、Evals与专业人员复核", "医生/临床团队做最终诊断或运营决策", "确认结果与失败模式用于后续流程优化" ], "components": [ "ChatGPT for Healthcare", "临床文档", "医疗治理", "Human review" ], "fde_actions": [ "与临床运营团队一起选择高频且可度量的生产工作流，而不是只部署聊天入口", "确定模型需要的企业上下文、系统权限、工具和安全边界", "把模型接入真实软件/数据/业务流程，并建立测试、Evals或确定性验证", "设计Human-in-the-loop与失败升级路径，确保责任边界清楚", "根据生产使用、错误和用户反馈持续迭代Prompt、上下文、工具和流程" ], "reusable": [ "企业AI效果取决于上下文、工具、验证和采用率，不只取决于模型能力", "先找可量化工作流，再把成功模式产品化/平台化", "编码Agent要尽量接入测试、CI/CD和安全检查形成闭环", "高风险行业必须把专业责任留给人，并建立持续Evals" ], "evidence": "OpenAI官方案例明确披露80%行政任务时间下降；具体任务比例和系统架构未完全公开。", "case_summary": "这个案例的重点是把“临床行政负担与文档工作流”从一次性分析或单点工具，变成可嵌入真实业务、可验证、可持续迭代的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "AdventHealth：临床行政负担与文档工作流", "publisher": "OpenAI", "url": "https://openai.com/index/adventhealth/", "source_type": "厂商官方客户材料", "directness": "案例级直接来源", "claim_origin": "厂商或客户公开披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露80%行政任务时间下降；具体任务比例和系统架构未完全公开。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 0, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] } ``` --- # DBS Bank｜全行AI工业化与个性化客户经营 - ID：enterprise-dbs-001 - 行业：金融与保险 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业年报直接来源 - 部署：全行规模化 - 独立核验：未记录 ## 业务问题 DBS需要把分散在各业务条线的数据分析和机器学习项目，从漫长的一次性交付改造成可规模复制、可治理、可量化经济价值的全行能力，同时兼顾银行风险、客户信任和员工采用。 ## 解决方案 银行建立统一的数据与AI基础设施、模型交付和PURE责任治理框架，以跨职能客户旅程团队持续选择高价值用例；在客户侧大规模运行个性化提醒、理财规划和反诈骗模型，在组织侧推进生成式AI助手与专业人员培训，并以经济价值而非模型数量作为组合管理指标。 ## 技术工作流 > 依据公开治理和用例结构归纳 1. 客户交易、渠道、风险与经营数据 2. 统一数据与AI平台及可复用模型能力 3. 用例价值评估与PURE责任治理 4. 预测/推荐/反诈骗等模型组合 5. 个性化提醒、理财工具与员工工作流 6. 客户行为与经济价值反馈进入持续迭代 组件：企业数据平台、模型开发与运营、个性化推荐、风险评分、责任AI治理、价值度量体系 ## 人机责任 模型负责预测、推荐和大规模触达；业务、风险与合规人员共同审批用例、设定限制并对客户结果负责，客户仍保留理财和安全操作的最终决定权。 ## FDE 动作 > FDE视角编辑归纳 - 围绕客户旅程而不是部门系统组织跨职能团队 - 把模型交付周期和经济价值纳入组合管理 - 建立用途、意外性、尊重和可解释性治理检查 - 把模型能力嵌入客户触达和员工工作流 - 持续比较触达组和非触达组的客户行为 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** DBS 2024年报披露，超过1,500个模型覆盖370多个用例，全年产生超过7.5亿新元经济价值；向1,300多万客户发送超过12亿次个性化提醒。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 企业AI规模化要同时建设平台、治理和价值度量 - 按客户旅程组织团队比按模型类型组织更接近业务结果 - 模型数量不是成果，必须跟踪可归因的经济价值 - 高监管行业应在用例设计阶段嵌入责任治理 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Innovating impactful solutions for customers](https://www.dbs.com/annualreports/2024/innovating-impactful-solutions-for-customers.html) - 发布方：DBS Bank - 披露性质：企业年报披露 - 原记录查阅日期：2026-09-19 - [DBS AI industrialisation and workforce overview](https://www.dbs.com/artificial-intelligence-machine-learning/artificial-intelligence/singapore-fintech-festival-ai-in-banking-finance.html) ## 字段边界 - business_problem：企业年报与官方AI专题披露 - solution：企业公开材料披露与结构化整理 - architecture：依据公开治理和用例结构归纳 - fde_actions：FDE视角编辑归纳 - result：企业年报披露 ## 待核对事项 - 模型、用例、触达量和经济价值来自DBS 2024年报。 - 7.5亿新元为DBS自身经济价值度量，不等同于审计后的利润增量。 ## 完整原始结构化记录 ```json { "id": "enterprise-dbs-001", "source": "企业原始材料", "company": "DBS Bank", "industry": "银行", "industry_group": "金融与保险", "scenario": "全行AI工业化与个性化客户经营", "fde": "企业部署案例", "fde_relation": "企业级AI改造", "problem": "DBS需要把分散在各业务条线的数据分析和机器学习项目，从漫长的一次性交付改造成可规模复制、可治理、可量化经济价值的全行能力，同时兼顾银行风险、客户信任和员工采用。", "solution": "银行建立统一的数据与AI基础设施、模型交付和PURE责任治理框架，以跨职能客户旅程团队持续选择高价值用例；在客户侧大规模运行个性化提醒、理财规划和反诈骗模型，在组织侧推进生成式AI助手与专业人员培训，并以经济价值而非模型数量作为组合管理指标。", "human": "模型负责预测、推荐和大规模触达；业务、风险与合规人员共同审批用例、设定限制并对客户结果负责，客户仍保留理财和安全操作的最终决定权。", "result": "DBS 2024年报披露，超过1,500个模型覆盖370多个用例，全年产生超过7.5亿新元经济价值；向1,300多万客户发送超过12亿次个性化提醒。", "maturity": "全行规模化", "maturity_stage": "规模化", "url": "https://www.dbs.com/annualreports/2024/innovating-impactful-solutions-for-customers.html", "architecture": [ "客户交易、渠道、风险与经营数据", "统一数据与AI平台及可复用模型能力", "用例价值评估与PURE责任治理", "预测/推荐/反诈骗等模型组合", "个性化提醒、理财工具与员工工作流", "客户行为与经济价值反馈进入持续迭代" ], "components": [ "企业数据平台", "模型开发与运营", "个性化推荐", "风险评分", "责任AI治理", "价值度量体系" ], "fde_actions": [ "围绕客户旅程而不是部门系统组织跨职能团队", "把模型交付周期和经济价值纳入组合管理", "建立用途、意外性、尊重和可解释性治理检查", "把模型能力嵌入客户触达和员工工作流", "持续比较触达组和非触达组的客户行为" ], "reusable": [ "企业AI规模化要同时建设平台、治理和价值度量", "按客户旅程组织团队比按模型类型组织更接近业务结果", "模型数量不是成果，必须跟踪可归因的经济价值", "高监管行业应在用例设计阶段嵌入责任治理" ], "evidence": "DBS 2024年报直接披露模型、用例、客户触达和经济价值口径；经济价值由企业自行度量，未见第三方审计方法。", "case_summary": "DBS案例展示的不是单个聊天机器人，而是银行如何把数据平台、责任治理、跨职能交付和经济价值度量组合成持续运转的AI工业化体系。", "evidence_level": "A", "evidence_label": "A级｜企业年报直接来源", "source_record": { "title": "Innovating impactful solutions for customers", "publisher": "DBS Bank", "url": "https://www.dbs.com/annualreports/2024/innovating-impactful-solutions-for-customers.html", "source_type": "企业年度报告", "directness": "企业级直接来源", "claim_origin": "企业年报披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业年报与官方AI专题披露", "solution": "企业公开材料披露与结构化整理", "architecture": "依据公开治理和用例结构归纳", "fde_actions": "FDE视角编辑归纳", "result": "企业年报披露" }, "verification_notes": [ "模型、用例、触达量和经济价值来自DBS 2024年报。", "7.5亿新元为DBS自身经济价值度量，不等同于审计后的利润增量。" ], "additional_sources": [ { "title": "DBS AI industrialisation and workforce overview", "url": "https://www.dbs.com/artificial-intelligence-machine-learning/artificial-intelligence/singapore-fintech-festival-ai-in-banking-finance.html" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Vodafone｜客服、网络运维、员工助手与软件研发的企业级AI组合 - ID：enterprise-vodafone-001 - 行业：科技与软件 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜投资者材料直接来源 - 部署：跨市场规模化 - 独立核验：未记录 ## 业务问题 大型跨国电信运营商同时面对高频客服对话、复杂网络故障、现场服务和软件交付效率问题；如果各团队分别做孤立试点，难以形成跨市场复用、统一度量和持续采用。 ## 解决方案 Vodafone将AI嵌入四类真实工作流：SuperTOBi处理客户对话并闭环解决问题，坐席助手汇总历史沟通，Zero Touch Operation依据实时诊断推荐网络与现场动作，内部生成式AI助手服务员工，同时把代码辅助接入软件开发生命周期。 ## 技术工作流 > 依据四类工作流结构化整理 1. 客户历史、网络遥测、工单与代码上下文 2. 统一数据访问与实时诊断层 3. 客服/网络/员工/研发专用AI能力 4. TOBi、坐席助手、运维推荐与代码助手 5. 人工升级、处置确认和代码审查 6. 解决率、NPS、MTTR与采用率持续监控 组件：对话式AI、生成式AI摘要、实时网络诊断、现场服务推荐、企业员工助手、代码生成与审查 ## 人机责任 虚拟助手处理标准问题和诊断建议，复杂客户问题升级人工；网络人员确认高风险处置，工程师审查和接受AI生成代码，员工对最终业务沟通负责。 ## FDE 动作 > FDE视角编辑归纳 - 把AI拆入客服、网络、员工和研发四条可度量链路 - 为每条链路定义不同运营指标 - 跨欧洲市场推广同一虚拟助手能力 - 保留人工升级和工程审查边界 - 用采用率、解决率和MTTR管理上线后效果 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Vodafone H1 FY26投资者材料披露：TOBi每月处理约6,000万次对话，SuperTOBi端到端解决率70%、NPS提升8个百分点；网络平均修复时间下降43%；5万多名员工月采用率超过90%；2,800名工程师开发生命周期生产率提升12%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业级改造应按工作流建立指标而非只报总用户数 - 同一底座需要针对不同岗位设计专用交互 - 大规模推广必须同时跟踪采用和业务结果 - 高风险网络动作应保留人工确认与可追踪诊断 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Vodafone H1 FY26 Results Presentation – AI at scale](https://reports.investors.vodafone.com/H1FY26presentation/22/) - 发布方：Vodafone - 披露性质：企业投资者材料披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：依据企业投资者材料归纳 - solution：企业投资者材料披露 - architecture：依据四类工作流结构化整理 - fde_actions：FDE视角编辑归纳 - result：企业投资者材料披露 ## 待核对事项 - 全部数字来自Vodafone H1 FY26投资者演示第22页。 - 该材料汇总多个市场和工作流，不能把所有指标归因于同一个模型。 ## 完整原始结构化记录 ```json { "id": "enterprise-vodafone-001", "source": "企业原始材料", "company": "Vodafone", "industry": "电信", "industry_group": "科技与软件", "scenario": "客服、网络运维、员工助手与软件研发的企业级AI组合", "fde": "企业部署案例", "fde_relation": "企业级AI改造", "problem": "大型跨国电信运营商同时面对高频客服对话、复杂网络故障、现场服务和软件交付效率问题；如果各团队分别做孤立试点，难以形成跨市场复用、统一度量和持续采用。", "solution": "Vodafone将AI嵌入四类真实工作流：SuperTOBi处理客户对话并闭环解决问题，坐席助手汇总历史沟通，Zero Touch Operation依据实时诊断推荐网络与现场动作，内部生成式AI助手服务员工，同时把代码辅助接入软件开发生命周期。", "human": "虚拟助手处理标准问题和诊断建议，复杂客户问题升级人工；网络人员确认高风险处置，工程师审查和接受AI生成代码，员工对最终业务沟通负责。", "result": "Vodafone H1 FY26投资者材料披露：TOBi每月处理约6,000万次对话，SuperTOBi端到端解决率70%、NPS提升8个百分点；网络平均修复时间下降43%；5万多名员工月采用率超过90%；2,800名工程师开发生命周期生产率提升12%。", "maturity": "跨市场规模化", "maturity_stage": "规模化", "url": "https://reports.investors.vodafone.com/H1FY26presentation/22/", "architecture": [ "客户历史、网络遥测、工单与代码上下文", "统一数据访问与实时诊断层", "客服/网络/员工/研发专用AI能力", "TOBi、坐席助手、运维推荐与代码助手", "人工升级、处置确认和代码审查", "解决率、NPS、MTTR与采用率持续监控" ], "components": [ "对话式AI", "生成式AI摘要", "实时网络诊断", "现场服务推荐", "企业员工助手", "代码生成与审查" ], "fde_actions": [ "把AI拆入客服、网络、员工和研发四条可度量链路", "为每条链路定义不同运营指标", "跨欧洲市场推广同一虚拟助手能力", "保留人工升级和工程审查边界", "用采用率、解决率和MTTR管理上线后效果" ], "reusable": [ "企业级改造应按工作流建立指标而非只报总用户数", "同一底座需要针对不同岗位设计专用交互", "大规模推广必须同时跟踪采用和业务结果", "高风险网络动作应保留人工确认与可追踪诊断" ], "evidence": "Vodafone投资者演示第22页直接披露多个AI工作流及其结果指标；属于企业管理层披露，未见独立审计。", "case_summary": "Vodafone把AI从单一客服机器人扩展成客服、网络运维、员工生产力和软件工程的组合，并为每条链路分别设置解决率、NPS、MTTR和采用率。", "evidence_level": "A", "evidence_label": "A级｜投资者材料直接来源", "source_record": { "title": "Vodafone H1 FY26 Results Presentation – AI at scale", "publisher": "Vodafone", "url": "https://reports.investors.vodafone.com/H1FY26presentation/22/", "source_type": "企业投资者材料", "directness": "企业级直接来源", "claim_origin": "企业投资者材料披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "依据企业投资者材料归纳", "solution": "企业投资者材料披露", "architecture": "依据四类工作流结构化整理", "fde_actions": "FDE视角编辑归纳", "result": "企业投资者材料披露" }, "verification_notes": [ "全部数字来自Vodafone H1 FY26投资者演示第22页。", "该材料汇总多个市场和工作流，不能把所有指标归因于同一个模型。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Walmart｜商品企划Trend-to-Product与商采助手Wally - ID：enterprise-walmart-001 - 行业：零售与消费 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜投资者材料直接来源 - 部署：生产使用/继续扩展 - 独立核验：未记录 ## 业务问题 大型零售商品开发和库存经营横跨趋势判断、设计、采购、门店、渠道与库存数据，传统商品企划周期长，商采团队也很难及时解释单品在不同市场和渠道中的表现差异。 ## 解决方案 Walmart用Trend-to-Product把趋势信号、商品设计和供应链准备连接到服装开发流程；同时让商采助手Wally分析跨门店、市场和渠道的销售表现，解释单品超预期或不及预期的原因，并逐步进入商品数量与库存流转决策。 ## 技术工作流 > 依据公开工作流结构化整理 1. 趋势、商品目录、销售、门店与渠道数据 2. 商品语义与经营指标统一 3. Trend-to-Product商品企划工作流 4. Wally销售表现诊断与原因分析 5. 设计/商采/供应链人员确认决策 6. 销量和库存结果回流后续企划 组件：趋势分析、商品数据平台、生成式AI助手、销售诊断、库存优化、人工商品决策 ## 人机责任 AI负责汇总趋势和经营信号、生成诊断与建议；设计、商采和供应链团队仍决定商品、数量、质量标准和库存动作，并对顾客价值负责。 ## FDE 动作 > FDE视角编辑归纳 - 选择服装开发周期作为可观测改造链路 - 连接趋势、商品与销售上下文 - 将商采常问问题转成Wally诊断能力 - 把助手逐步推进到数量和库存流决策 - 用上市周期和销售表现验证业务价值 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Walmart 2025投资者会议材料称，首个由Trend-to-Product支持的服装系列比典型流程缩短18周并取得强劲售罄表现；Wally已用于商采团队的跨渠道销售诊断。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 零售AI要连接企划、商品和库存而非只做搜索 - 先让助手解释经营结果，再逐步授权行动 - 商品质量和品牌判断应由人负责 - 上市周期是比生成内容数量更接近业务的指标 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Walmart Investment Community Meeting 2025 prepared remarks](https://corporate.walmart.com/content/dam/corporate/documents/newsroom/events/walmart-investment-community-meeting-and-q-and-a-session/icm-2025-prepared-remarks-and-q-and-a.pdf) - 发布方：Walmart - 披露性质：企业管理层披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：企业材料与业务流程归纳 - solution：企业管理层披露 - architecture：依据公开工作流结构化整理 - fde_actions：FDE视角编辑归纳 - result：企业管理层披露 ## 待核对事项 - 18周缩短来自2025投资者会议第4页。 - “强劲售罄”没有公开基准、样本和具体比例。 ## 完整原始结构化记录 ```json { "id": "enterprise-walmart-001", "source": "企业原始材料", "company": "Walmart", "industry": "零售", "industry_group": "零售与消费", "scenario": "商品企划Trend-to-Product与商采助手Wally", "fde": "企业部署案例", "fde_relation": "企业级AI改造", "problem": "大型零售商品开发和库存经营横跨趋势判断、设计、采购、门店、渠道与库存数据，传统商品企划周期长，商采团队也很难及时解释单品在不同市场和渠道中的表现差异。", "solution": "Walmart用Trend-to-Product把趋势信号、商品设计和供应链准备连接到服装开发流程；同时让商采助手Wally分析跨门店、市场和渠道的销售表现，解释单品超预期或不及预期的原因，并逐步进入商品数量与库存流转决策。", "human": "AI负责汇总趋势和经营信号、生成诊断与建议；设计、商采和供应链团队仍决定商品、数量、质量标准和库存动作，并对顾客价值负责。", "result": "Walmart 2025投资者会议材料称，首个由Trend-to-Product支持的服装系列比典型流程缩短18周并取得强劲售罄表现；Wally已用于商采团队的跨渠道销售诊断。", "maturity": "生产使用/继续扩展", "maturity_stage": "已上线", "url": "https://corporate.walmart.com/content/dam/corporate/documents/newsroom/events/walmart-investment-community-meeting-and-q-and-a-session/icm-2025-prepared-remarks-and-q-and-a.pdf", "architecture": [ "趋势、商品目录、销售、门店与渠道数据", "商品语义与经营指标统一", "Trend-to-Product商品企划工作流", "Wally销售表现诊断与原因分析", "设计/商采/供应链人员确认决策", "销量和库存结果回流后续企划" ], "components": [ "趋势分析", "商品数据平台", "生成式AI助手", "销售诊断", "库存优化", "人工商品决策" ], "fde_actions": [ "选择服装开发周期作为可观测改造链路", "连接趋势、商品与销售上下文", "将商采常问问题转成Wally诊断能力", "把助手逐步推进到数量和库存流决策", "用上市周期和销售表现验证业务价值" ], "reusable": [ "零售AI要连接企划、商品和库存而非只做搜索", "先让助手解释经营结果，再逐步授权行动", "商品质量和品牌判断应由人负责", "上市周期是比生成内容数量更接近业务的指标" ], "evidence": "Walmart投资者会议逐字稿第4页直接披露Trend-to-Product、Wally及18周周期缩短；没有公开强劲售罄的统一计算口径。", "case_summary": "Walmart案例的价值在于把AI放进商品从趋势发现、设计到库存经营的连续链路，并用上市周期而不是演示效果评价首个生产成果。", "evidence_level": "A", "evidence_label": "A级｜投资者材料直接来源", "source_record": { "title": "Walmart Investment Community Meeting 2025 prepared remarks", "publisher": "Walmart", "url": "https://corporate.walmart.com/content/dam/corporate/documents/newsroom/events/walmart-investment-community-meeting-and-q-and-a-session/icm-2025-prepared-remarks-and-q-and-a.pdf", "source_type": "企业投资者会议材料", "directness": "案例级直接来源", "claim_origin": "企业管理层披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业材料与业务流程归纳", "solution": "企业管理层披露", "architecture": "依据公开工作流结构化整理", "fde_actions": "FDE视角编辑归纳", "result": "企业管理层披露" }, "verification_notes": [ "18周缩短来自2025投资者会议第4页。", "“强劲售罄”没有公开基准、样本和具体比例。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Lockheed Martin｜统一数据底座与安全AI Factory - ID：ibm-lockheed-martin-001 - 行业：制造与工业 - 来源：IBM - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：平台规模化/应用扩展 - 独立核验：未记录 ## 业务问题 Lockheed Martin的数据分散在多个数据湖以及46套数据管理、分析和商业智能系统中，工程人员难以快速找到高质量数据，也无法在安全约束下规模构建和治理AI应用。 ## 解决方案 公司与IBM先将46套分散系统收敛为单一连接的数据环境，再建设安全AI Factory，让工程师基于受治理数据和开放模型开发大型AI应用；面向员工的自然语言问数、研究和HR助手在统一数据及治理框架上运行，并通过提示与查询优化持续改进答案。 ## 技术工作流 > 依据公开方案结构化整理 1. 46套数据与分析系统及多个数据湖 2. 数据整合、质量和目录定义 3. 统一受治理的数据平台 4. 安全AI Factory与开放模型 5. 自然语言问数、研究与HR助手 6. 评测、提示优化和查询优化反馈 组件：统一数据平台、数据目录、IBM Granite、watsonx.governance、watsonx Orchestrate、Agent框架 ## 人机责任 AI提供数据查询、研究和员工服务回答；数据负责人维护定义和质量，工程师选择模型并验证结果，安全与治理团队控制敏感环境中的访问和上线。 ## FDE 动作 > 依据公开实施过程归纳 - 先整合数据系统再扩展AI应用 - 与工程和安全团队定义可访问数据边界 - 自动化数据目录定义降低使用门槛 - 用样例问题测量问答准确率 - 分别实验提示和查询优化的增益 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** IBM客户案例称，数据与AI工具数量减少50%，46套系统被一个集成平台替代，自动化216个数据目录定义；问答试点准确率从45.45%提升至提示优化后的56.8%，查询优化后达到66.0%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 数据割裂会直接限制企业AI规模化 - 安全AI Factory需要把开发速度与治理放在同一平台 - 问答系统应有固定样例集和分阶段优化数据 - 平台结果和单个Agent结果需要分别度量 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [A new era of AI takes off for Lockheed Martin](https://www.ibm.com/case-studies/lockheed-martin) - 发布方：IBM - 披露性质：IBM与客户披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开方案结构化整理 - fde_actions：依据公开实施过程归纳 - result：IBM与客户披露 ## 待核对事项 - 页面明确披露46套系统、216个目录定义及准确率变化。 - 准确率为早期样例问题试点，不代表所有生产查询。 ## 完整原始结构化记录 ```json { "id": "ibm-lockheed-martin-001", "source": "IBM", "company": "Lockheed Martin", "industry": "航空航天/国防", "industry_group": "制造与工业", "scenario": "统一数据底座与安全AI Factory", "fde": "伴随式部署", "fde_relation": "联合企业AI改造", "problem": "Lockheed Martin的数据分散在多个数据湖以及46套数据管理、分析和商业智能系统中，工程人员难以快速找到高质量数据，也无法在安全约束下规模构建和治理AI应用。", "solution": "公司与IBM先将46套分散系统收敛为单一连接的数据环境，再建设安全AI Factory，让工程师基于受治理数据和开放模型开发大型AI应用；面向员工的自然语言问数、研究和HR助手在统一数据及治理框架上运行，并通过提示与查询优化持续改进答案。", "human": "AI提供数据查询、研究和员工服务回答；数据负责人维护定义和质量，工程师选择模型并验证结果，安全与治理团队控制敏感环境中的访问和上线。", "result": "IBM客户案例称，数据与AI工具数量减少50%，46套系统被一个集成平台替代，自动化216个数据目录定义；问答试点准确率从45.45%提升至提示优化后的56.8%，查询优化后达到66.0%。", "maturity": "平台规模化/应用扩展", "maturity_stage": "规模化", "url": "https://www.ibm.com/case-studies/lockheed-martin", "architecture": [ "46套数据与分析系统及多个数据湖", "数据整合、质量和目录定义", "统一受治理的数据平台", "安全AI Factory与开放模型", "自然语言问数、研究与HR助手", "评测、提示优化和查询优化反馈" ], "components": [ "统一数据平台", "数据目录", "IBM Granite", "watsonx.governance", "watsonx Orchestrate", "Agent框架" ], "fde_actions": [ "先整合数据系统再扩展AI应用", "与工程和安全团队定义可访问数据边界", "自动化数据目录定义降低使用门槛", "用样例问题测量问答准确率", "分别实验提示和查询优化的增益" ], "reusable": [ "数据割裂会直接限制企业AI规模化", "安全AI Factory需要把开发速度与治理放在同一平台", "问答系统应有固定样例集和分阶段优化数据", "平台结果和单个Agent结果需要分别度量" ], "evidence": "IBM逐案例页面披露系统整合、目录自动化和问答准确率；结果由实施厂商与客户共同披露。", "case_summary": "Lockheed Martin先解决46套数据系统造成的基础问题，再用安全AI Factory承载自然语言查询和Agent，这是一条从数据治理走向规模化AI开发的完整路径。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "A new era of AI takes off for Lockheed Martin", "publisher": "IBM", "url": "https://www.ibm.com/case-studies/lockheed-martin", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "IBM与客户披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开方案结构化整理", "fde_actions": "依据公开实施过程归纳", "result": "IBM与客户披露" }, "verification_notes": [ "页面明确披露46套系统、216个目录定义及准确率变化。", "准确率为早期样例问题试点，不代表所有生产查询。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Medtronic｜工程图纸原材料与零件号智能提取 - ID：ibm-medtronic-001 - 行业：医疗与生命科学 - 来源：IBM - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：生产验证/扩展 - 独立核验：未记录 ## 业务问题 医疗器械产品工程图纸数量大且结构复杂，关键原材料和零件号识别依赖人工阅读与核对，既拖慢产品开发和供应链分析，也容易因为格式和图面差异产生遗漏。 ## 解决方案 Medtronic全球运营与供应链分析团队、供应商管理团队和IBM共同构建定制方案：Azure Document Intelligence先做OCR和版面提取，Azure OpenAI支持的RAG结合工程上下文验证材料信息，关键属性写入数据库并通过简单搜索应用供业务人员检索。 ## 技术工作流 > 依据公开组件和流程整理 1. 工程图纸与设计文档 2. Azure Document Intelligence OCR 3. Azure OpenAI 支持的 RAG 4. 提取材料与零件号等属性 5. 关键属性保存至数据库 6. 搜索应用提供查询与分析 组件：Azure Document Intelligence、Azure OpenAI、RAG、Azure Blob Storage、属性数据库、搜索应用 ## 人机责任 公开来源称方案减少了人工核验，但未披露复核岗位、阈值与异常处理流程。编辑建议由工程与供应链人员核对关键属性并保留来源，不能将此建议当作美敦力已实施事实。 ## FDE 动作 > 公开协作和技术组合的归纳；字段定义、分字段评测与异常复核属于编辑建议，原文未披露实施细节 - 来源披露：美敦力供应链分析、供应商管理团队与 IBM 合作 - 来源披露：组合 OCR 与 Azure OpenAI 支持的 RAG - 来源披露：将提取属性保存至数据库并提供搜索应用 - 编辑建议：按材料、零件号分别建立字段定义与评测集 - 编辑建议：保留原图定位，核对字符歧义并隔离版本冲突 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** IBM案例披露，关键材料信息提取准确率最高达到90%，零件号提取准确率超过85%，显著减少人工核验并节省数小时处理工作；未公开总体成本节省口径。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 复杂文档AI应拆分OCR、语义理解和人工复核 - 不同字段应分别评测而不是只报总准确率 - 抽取结果必须进入可查询的数据结构 - 高风险工程信息需要置信度和例外处理机制 ## 现场决策与研究 ### 为什么这样做 OCR读取图纸，RAG辅助定位材料属性，数据库与搜索界面承接后续分析。 ### 阻力与证据边界 材料属性与零件号准确率口径不同；剩余错误需专业复核，不能视为医疗质量自动放行。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 以图纸版本和字段类型分层抽样，核对单位、零件号一致性和低置信度修正流程。 研究依据： - [Material ID search revolutionized with Microsoft GenAI + IBM Consulting](https://www.ibm.com/case-studies/medtronic) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：文档、图纸与审核 适用条件：输入类型可列举，关键字段和业务规则可说明，异常件有人复核。 不适用：只用一项平均识别率验收全部字段，或模型输出直接成为不可逆审批结果。 ### 输入条件 - 真实格式、扫描质量和异常类型的分层样本 - 字段定义、单位、规则版本与原文坐标 - 专业复核记录与下游系统写入契约 ### 实施步骤 - 按材料类型与风险分层，明确哪些字段错误会导致业务损失。 - 提取字段同时保留页码、坐标与原文；计算、金额、单位转换使用确定性代码。 - 把低置信度、冲突和规则未覆盖项送入复核队列，让人能直接对照原件。 - 写回前校验版本与重复提交，完成后读取真实下游记录并关联处理结果。 ### 验收指标 - 字段级精确率和召回率按格式、字段与风险分别报告。 - 错误放行率和误拦截率分开统计，不能只报总体准确率。 - 端到端完成时间必须包含人工复核、排队与重做时间。 ### 异常处理 出现关键字段错误时暂停自动写回；保存原件、提取版本、规则和复核人，修复后回放历史失败集。 ### 责任分工 业务审核人定义规则并签发；工程团队负责可追踪提取；系统管理员控制写权限。 ## 来源账本 - [Material ID search revolutionized with Microsoft GenAI + IBM Consulting](https://www.ibm.com/case-studies/medtronic) - 发布方：IBM - 披露性质：IBM与客户披露 - 原记录查阅日期：2026-09-23 - [Medtronic company overview](https://www.medtronic.com/en-us/our-company.html) ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开组件和流程整理 - fde_actions：公开协作和技术组合的归纳；字段定义、分字段评测与异常复核属于编辑建议，原文未披露实施细节 - result：IBM与客户披露 ## 待核对事项 - 材料信息提取最高90%、零件号超过85%；属于厂商披露，非独立评测。 - 原文未披露准确率分母、样本规模、误差分布和外部评测。 - 本轮未找到本项目公开应用截图、可访问演示或源码；页面交互示例为编辑制作的虚构教学样例。 - 人工复核阈值、权限与异常处理未披露，不应从技术组件推断其已实施。 - 12分衡量结构化字段的完整程度，不等于实际系统可复现或实施细节齐备。 ## 完整原始结构化记录 ```json { "id": "ibm-medtronic-001", "technical_reference": true, "source": "IBM", "company": "Medtronic", "industry": "医疗器械制造", "industry_group": "医疗与生命科学", "scenario": "工程图纸原材料与零件号智能提取", "fde": "伴随式部署", "fde_relation": "联合业务流程改造", "problem": "医疗器械产品工程图纸数量大且结构复杂，关键原材料和零件号识别依赖人工阅读与核对，既拖慢产品开发和供应链分析，也容易因为格式和图面差异产生遗漏。", "solution": "Medtronic全球运营与供应链分析团队、供应商管理团队和IBM共同构建定制方案：Azure Document Intelligence先做OCR和版面提取，Azure OpenAI支持的RAG结合工程上下文验证材料信息，关键属性写入数据库并通过简单搜索应用供业务人员检索。", "human": "公开来源称方案减少了人工核验，但未披露复核岗位、阈值与异常处理流程。编辑建议由工程与供应链人员核对关键属性并保留来源，不能将此建议当作美敦力已实施事实。", "result": "IBM案例披露，关键材料信息提取准确率最高达到90%，零件号提取准确率超过85%，显著减少人工核验并节省数小时处理工作；未公开总体成本节省口径。", "maturity": "生产验证/扩展", "maturity_stage": "已上线", "url": "https://www.ibm.com/case-studies/medtronic", "architecture": [ "工程图纸与设计文档", "Azure Document Intelligence OCR", "Azure OpenAI 支持的 RAG", "提取材料与零件号等属性", "关键属性保存至数据库", "搜索应用提供查询与分析" ], "components": [ "Azure Document Intelligence", "Azure OpenAI", "RAG", "Azure Blob Storage", "属性数据库", "搜索应用" ], "fde_actions": [ "来源披露：美敦力供应链分析、供应商管理团队与 IBM 合作", "来源披露：组合 OCR 与 Azure OpenAI 支持的 RAG", "来源披露：将提取属性保存至数据库并提供搜索应用", "编辑建议：按材料、零件号分别建立字段定义与评测集", "编辑建议：保留原图定位，核对字符歧义并隔离版本冲突" ], "reusable": [ "复杂文档AI应拆分OCR、语义理解和人工复核", "不同字段应分别评测而不是只报总准确率", "抽取结果必须进入可查询的数据结构", "高风险工程信息需要置信度和例外处理机制" ], "evidence": "IBM逐案例页面公开技术组件、协作团队和两项准确率；没有披露样本规模及独立评测报告。", "case_summary": "Medtronic把工程图纸处理拆为OCR、RAG验证、结构化入库和专家复核，使AI不只“读图”，而是进入材料识别与供应链决策流程。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Material ID search revolutionized with Microsoft GenAI + IBM Consulting", "publisher": "IBM", "url": "https://www.ibm.com/case-studies/medtronic", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "IBM与客户披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开组件和流程整理", "fde_actions": "公开协作和技术组合的归纳；字段定义、分字段评测与异常复核属于编辑建议，原文未披露实施细节", "result": "IBM与客户披露" }, "verification_notes": [ "材料信息提取最高90%、零件号超过85%；属于厂商披露，非独立评测。", "原文未披露准确率分母、样本规模、误差分布和外部评测。", "本轮未找到本项目公开应用截图、可访问演示或源码；页面交互示例为编辑制作的虚构教学样例。", "人工复核阈值、权限与异常处理未披露，不应从技术组件推断其已实施。", "12分衡量结构化字段的完整程度，不等于实际系统可复现或实施细节齐备。" ], "additional_sources": [ { "title": "Medtronic company overview", "url": "https://www.medtronic.com/en-us/our-company.html" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` ## 企业与可视化解读 Medtronic · 美敦力 医疗科技与医疗器械企业。本例发生在工程资料与供应链分析场景，处理的是图纸中的材料、零件号等信息。 - 客户与业务团队：美敦力 GO&SC Analytics & Insights、Global Supplier Management - 方案合作方：IBM Consulting - 技术平台：Microsoft Azure [公司介绍](https://www.medtronic.com/en-us/our-company.html) · [IBM 案例原文](https://www.ibm.com/case-studies/medtronic) - 已找到｜IBM 官方客户案例：能确认企业、协作团队、主要组件与结果口径。 - 原文未展示｜实际图纸和产品界面：原文配图是工作场景照片和企业标识，并非应用截图。 - 本轮未找到｜可访问演示或公开代码：检索 IBM、Medtronic 与相关公开索引，尚不能还原实际产品。 ### 已披露组件流程（编辑绘制） 工程图纸（输入对象） → OCR（Azure Document Intelligence） → RAG + 模型（Azure OpenAI） → 属性数据库（保存提取结果） → 搜索应用（供业务查询） 依据 IBM 披露的组件与用途绘制。连线表达阅读顺序，不代表客户真实部署拓扑；原文未披露检索库、提示词和模型版本。Azure Blob Storage 也列为方案组件，但具体位置未说明。 ### 教学示意 · 非美敦力真实图纸或产品界面 图形、零件号、材料与复核过程均为虚构样例。仅切换预设展示，不调用 OCR 或模型；复核与版本隔离是编辑建议，不是客户已实施事实。 ![虚构教学图纸，非客户资料](../assets/cases/material-drawing-demo.svg) #### 看原始图纸 先看标题栏与材料备注，而不是让模型凭零件外形猜材质。这里的几何轮廓只用来说明“图”和“字段”在同一页。 - 文件：DEMO-P104 · 第 1 页 - 零件号：DEMO-P104 - 版本：B - 材料备注：MATERIAL: 316L 一份输入至少保留文件标识、页码与版本，便于以后回查。 #### 读出候选字段 示例故意把字母 L 识别成 I。OCR 给出文本还不够：候选字段必须连回原文，RAG 提供参考也不能自动证明候选正确。 - OCR 材料文本：316I（故意设置的识别错误） - 材料候选：316L · 尚未确认 - 定位：第 1 页 · 材料备注区域 - 状态：待核对原图 不要把模型自报的置信度当成测得的准确率。 #### 核对与留痕 教学流程中，复核人对照 B 版原图确认 316L，保存原 OCR 文本与修改原因。即使检索到 A 版资料，也不覆盖当前 B 版。 - 原 OCR → 确认值：316I → 316L - 确认依据：B 版原图材料备注 - 处理记录：示例复核人 · 字符纠错 - 版本冲突：A 版另存，不覆盖 B 版 这里的复核策略是建议。IBM 原文没有公布客户怎样处理这类异常。 #### 进入查询结果 确认后的字段变成可筛选记录，业务人员可以按材料找零件，再回到图纸定位。演示的“已确认”仅指样例数据核对完成，不是采购、设计或质量放行。 - 示例查询：材料 = 316L - 匹配零件：DEMO-P104 · 版本 B - 来源定位：第 1 页 · 材料备注区域 - 记录状态：教学样例已确认 从“一段 AI 回答”变成“带来源的业务记录”，才便于持续使用与追溯。 ### 仍未闭合的证据 - 真实图纸、应用界面、可访问演示与代码仓库 - 文档数量、评测样本量、准确率分母与测试集构成 - 人工复核规则、失败重试、版本冲突和权限控制的实际实现 - 开发与运行成本、回本周期、净利润和可归因的财务收益 ### 通用组件参考（非客户原型） [Microsoft Document Intelligence Studio](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/studio-overview?view=doc-intel-4.0.0)：官方说明包含可视化体验入口：查看文档与抽取结果。实际分析需要相应 Azure 资源；这是通用组件工具，不是美敦力应用。 [Azure 官方文档提取代码示例](https://github.com/Azure-Samples/document-intelligence-code-samples)：可查看多语言 SDK 示例与示例数据，用于自行验证文档提取。不是本案例源码，也不能复现客户的 RAG 与业务系统。 --- # Rolls-Royce｜发动机设计、涡轮叶片质检与预测维护数字线程 - ID：microsoft-rolls-royce-001 - 行业：制造与工业 - 来源：Microsoft - 详细度：深度案例｜关键链路较完整（11/12） - 证据：A级｜厂商逐案例来源 - 部署：多环节生产规模化 - 独立核验：未记录 ## 业务问题 发动机设计周期以年计，涡轮叶片每月约200万个冷却孔依赖人工检查并形成生产瓶颈；发动机在役维护还需要从上万项参数中提前发现故障，设计、制造与服务数据长期割裂。 ## 解决方案 Rolls-Royce建设中央数据仓库和贯穿设计、制造、运营的数字线程；设计端用高性能计算和AI扩大参数探索，制造端用Signature Analyzer结合机器振动分析识别叶片缺陷，运营端通过发动机健康监控单元和云端分析跟踪参数、预测维护事件。 ## 技术工作流 > 依据公开流程结构化整理 1. 设计、制造、质检和在役发动机数据 2. 中央数据仓库与数字线程 3. Azure Databricks/高性能计算参数探索 4. Signature Analyzer与机器振动缺陷识别 5. 发动机健康监控及云端分析 6. 工程、质检和维修人员闭环处置 组件：中央数据平台、Azure Databricks、高性能GPU、机器学习质检、发动机遥测、预测维护 ## 人机责任 AI负责参数搜索、缺陷定位和维护预警；设计工程师决定方案，质检人员聚焦模型标出的风险区域，维修与航空运营团队确认并执行维护动作。 ## FDE 动作 > FDE视角编辑归纳 - 连接设计、制造和运营三段价值链 - 以冷却孔人工检查瓶颈选择首批生产场景 - 让模型输出定位到具体待检区域 - 将健康监控与地面维护流程连接 - 分别跟踪机器利用率、处理时长和避免事件 ## 业务结果与盈利口径 **来源披露金额或成本影响** Microsoft与Rolls-Royce称发动机健康监控每年发现并避免约400次非计划维护，带来数百万维修成本避免；这是来源方报告的成本避免，不是经独立审计的现金净节省。项目全成本和单独归因于AI的净ROI未披露。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 工业AI需要贯穿产品全生命周期的数据线程 - 质检模型应把人工从全面扫描转向风险复核 - 预测维护价值应以避免事件和停机衡量 - 不同环节要使用各自可操作的业务指标 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Rolls-Royce saves millions in cost avoidance with Microsoft Cloud for Manufacturing](https://www.microsoft.com/en/customers/story/23201-rolls-royce-azure-databricks) - 发布方：Microsoft - 披露性质：Microsoft与客户披露 - 原记录查阅日期：2026-09-23 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开流程结构化整理 - fde_actions：FDE视角编辑归纳 - result：Microsoft与客户披露 ## 待核对事项 - 页面分别披露质检和发动机健康监控指标。 - 数百万成本避免为客户估算，未见独立审计。 - 原文称cost avoidance；此处译为成本避免，不将其扩写为现金净节省。 ## 完整原始结构化记录 ```json { "id": "microsoft-rolls-royce-001", "source": "Microsoft", "company": "Rolls-Royce", "industry": "航空发动机制造", "industry_group": "制造与工业", "scenario": "发动机设计、涡轮叶片质检与预测维护数字线程", "fde": "伴随式部署", "fde_relation": "联合企业AI改造", "problem": "发动机设计周期以年计，涡轮叶片每月约200万个冷却孔依赖人工检查并形成生产瓶颈；发动机在役维护还需要从上万项参数中提前发现故障，设计、制造与服务数据长期割裂。", "solution": "Rolls-Royce建设中央数据仓库和贯穿设计、制造、运营的数字线程；设计端用高性能计算和AI扩大参数探索，制造端用Signature Analyzer结合机器振动分析识别叶片缺陷，运营端通过发动机健康监控单元和云端分析跟踪参数、预测维护事件。", "human": "AI负责参数搜索、缺陷定位和维护预警；设计工程师决定方案，质检人员聚焦模型标出的风险区域，维修与航空运营团队确认并执行维护动作。", "result": "Microsoft与Rolls-Royce称发动机健康监控每年发现并避免约400次非计划维护，带来数百万维修成本避免；这是来源方报告的成本避免，不是经独立审计的现金净节省。项目全成本和单独归因于AI的净ROI未披露。", "maturity": "多环节生产规模化", "maturity_stage": "规模化", "url": "https://www.microsoft.com/en/customers/story/23201-rolls-royce-azure-databricks", "architecture": [ "设计、制造、质检和在役发动机数据", "中央数据仓库与数字线程", "Azure Databricks/高性能计算参数探索", "Signature Analyzer与机器振动缺陷识别", "发动机健康监控及云端分析", "工程、质检和维修人员闭环处置" ], "components": [ "中央数据平台", "Azure Databricks", "高性能GPU", "机器学习质检", "发动机遥测", "预测维护" ], "fde_actions": [ "连接设计、制造和运营三段价值链", "以冷却孔人工检查瓶颈选择首批生产场景", "让模型输出定位到具体待检区域", "将健康监控与地面维护流程连接", "分别跟踪机器利用率、处理时长和避免事件" ], "reusable": [ "工业AI需要贯穿产品全生命周期的数据线程", "质检模型应把人工从全面扫描转向风险复核", "预测维护价值应以避免事件和停机衡量", "不同环节要使用各自可操作的业务指标" ], "evidence": "Microsoft逐案例页面公开设计、质检与维护工作流及指标；指标由客户和实施厂商披露。", "case_summary": "Rolls-Royce案例覆盖从发动机设计、涡轮叶片制造到在役维护的完整数字线程，展示了AI如何分别进入工程、质检和维修责任链。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Rolls-Royce saves millions in cost avoidance with Microsoft Cloud for Manufacturing", "publisher": "Microsoft", "url": "https://www.microsoft.com/en/customers/story/23201-rolls-royce-azure-databricks", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "Microsoft与客户披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开流程结构化整理", "fde_actions": "FDE视角编辑归纳", "result": "Microsoft与客户披露" }, "verification_notes": [ "页面分别披露质检和发动机健康监控指标。", "数百万成本避免为客户估算，未见独立审计。", "原文称cost avoidance；此处译为成本避免，不将其扩写为现金净节省。" ], "additional_sources": [], "detail_score": 11, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "量化结果" ] } ``` --- # Presidio｜从低采用率到组织级Copilot生产力改造 - ID：microsoft-presidio-001 - 行业：科技与软件 - 来源：Microsoft - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：组织级采用 - 独立核验：未记录 ## 业务问题 Presidio最初向300名销售、营销、工程、IT、管理和项目人员部署Copilot，但采用率只有约60%；单纯发放工具没有形成稳定技能、场景和可度量业务收益。 ## 解决方案 公司开发60多个针对提示、会议、内容和岗位场景的培训视频，建设内部协作站点分享经验，并围绕邮件摘要、会议纪要、技术文档转客户演示、RFP和项目管理建立具体工作流；工程团队再用Copilot Studio和Azure OpenAI构建票务和费用等定制助手。 ## 技术工作流 > 依据公开采用路径整理 1. Microsoft 365中的邮件、会议和文档 2. Copilot通用工作入口 3. 60多个岗位培训与内部经验站点 4. RFP、演示、会议和项目管理工作流 5. Copilot Studio/Azure OpenAI定制助手 6. 采用率和节省工时持续度量 组件：Microsoft 365 Copilot、Copilot Studio、Azure OpenAI、培训内容库、经验分享社区、使用度量 ## 人机责任 AI负责摘要、初稿、转写和资料重组；销售、工程与项目经理审核面向客户的内容、主导沟通并对交付承诺负责，内部团队持续维护培训和使用规范。 ## FDE 动作 > 依据公开实施过程归纳 - 识别低采用率不是许可证问题而是能力问题 - 按岗位拆分培训和可复用场景 - 把技术文档到客户演示做成端到端流程 - 建立内部成功案例和提示共享机制 - 用采用率、工时与RFP周期验证效果 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Microsoft案例称采用率由约60%提升至90%以上，用户平均每月节省约1,200小时；RFP处理时间减少90%，项目经理每周平均节省6小时，一项原需3天的任务缩短至2小时。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - AI办公部署的第一指标应包含采用率 - 培训要围绕岗位任务而不是产品功能 - 通用助手与定制工作流应分层建设 - 节省时间需要落到具体任务和抽样口径 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Presidio adoption of Copilot streamlines operations](https://www.microsoft.com/en/customers/story/19401-presidio-network-solutions-microsoft-365-copilot) - 发布方：Microsoft - 披露性质：Microsoft与客户披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开采用路径整理 - fde_actions：依据公开实施过程归纳 - result：Microsoft与客户披露 ## 待核对事项 - 页面明确记录300人首批范围、60多个培训视频及采用率变化。 - 1,200小时为Presidio自行计算的平均月节省。 ## 完整原始结构化记录 ```json { "id": "microsoft-presidio-001", "source": "Microsoft", "company": "Presidio", "industry": "IT服务", "industry_group": "科技与软件", "scenario": "从低采用率到组织级Copilot生产力改造", "fde": "企业部署案例", "fde_relation": "组织采用与工作流改造", "problem": "Presidio最初向300名销售、营销、工程、IT、管理和项目人员部署Copilot，但采用率只有约60%；单纯发放工具没有形成稳定技能、场景和可度量业务收益。", "solution": "公司开发60多个针对提示、会议、内容和岗位场景的培训视频，建设内部协作站点分享经验，并围绕邮件摘要、会议纪要、技术文档转客户演示、RFP和项目管理建立具体工作流；工程团队再用Copilot Studio和Azure OpenAI构建票务和费用等定制助手。", "human": "AI负责摘要、初稿、转写和资料重组；销售、工程与项目经理审核面向客户的内容、主导沟通并对交付承诺负责，内部团队持续维护培训和使用规范。", "result": "Microsoft案例称采用率由约60%提升至90%以上，用户平均每月节省约1,200小时；RFP处理时间减少90%，项目经理每周平均节省6小时，一项原需3天的任务缩短至2小时。", "maturity": "组织级采用", "maturity_stage": "规模化", "url": "https://www.microsoft.com/en/customers/story/19401-presidio-network-solutions-microsoft-365-copilot", "architecture": [ "Microsoft 365中的邮件、会议和文档", "Copilot通用工作入口", "60多个岗位培训与内部经验站点", "RFP、演示、会议和项目管理工作流", "Copilot Studio/Azure OpenAI定制助手", "采用率和节省工时持续度量" ], "components": [ "Microsoft 365 Copilot", "Copilot Studio", "Azure OpenAI", "培训内容库", "经验分享社区", "使用度量" ], "fde_actions": [ "识别低采用率不是许可证问题而是能力问题", "按岗位拆分培训和可复用场景", "把技术文档到客户演示做成端到端流程", "建立内部成功案例和提示共享机制", "用采用率、工时与RFP周期验证效果" ], "reusable": [ "AI办公部署的第一指标应包含采用率", "培训要围绕岗位任务而不是产品功能", "通用助手与定制工作流应分层建设", "节省时间需要落到具体任务和抽样口径" ], "evidence": "Microsoft逐案例页面披露初始采用率、培训数量、采用提升和多项工时指标；计算方法未公开。", "case_summary": "Presidio案例说明企业AI采用失败往往不是模型问题：通过岗位培训、内部社区和具体流程设计，工具采用率才从约60%提升到90%以上。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Presidio adoption of Copilot streamlines operations", "publisher": "Microsoft", "url": "https://www.microsoft.com/en/customers/story/19401-presidio-network-solutions-microsoft-365-copilot", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "Microsoft与客户披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开采用路径整理", "fde_actions": "依据公开实施过程归纳", "result": "Microsoft与客户披露" }, "verification_notes": [ "页面明确记录300人首批范围、60多个培训视频及采用率变化。", "1,200小时为Presidio自行计算的平均月节省。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Syneos Health｜临床试验选址、预测与文档工作流 - ID：microsoft-syneos-health-001 - 行业：医疗与生命科学 - 来源：Microsoft - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：生产使用/扩展中 - 独立核验：未记录 ## 业务问题 Syneos Health同时运行500多项临床试验，试验选址需要人工收集和比较大量站点、受试者与历史数据，往往耗时数月；团队还要处理预测、文档和客户场景讨论。 ## 解决方案 公司在已迁移至Azure的数据资产上建设统一分析平台，使用Data Lake、Databricks、机器学习、数据质量能力和Azure OpenAI开发生成式AI应用；系统先生成候选站点清单，再支持逐步筛选，并通过预测模型提前提示试验延期风险，让员工实时演示不同方案。 ## 技术工作流 > 依据公开组件和流程整理 1. 临床试验、站点、受试者和运营数据 2. Azure Data Lake统一存储与数据质量 3. Azure Databricks转换和分析 4. 传统机器学习预测试验风险 5. Azure OpenAI生成候选清单与情景分析 6. 临床专家审核、选择和风险处置 组件：Azure Data Lake Storage、Azure Databricks、Azure OpenAI、MLOps、预测模型、专家审核 ## 人机责任 AI生成候选站点、预测风险并辅助情景分析；临床运营和医学专家审核站点资格、风险和合规要求，最终试验设计及患者安全责任仍由专业团队承担。 ## FDE 动作 > 依据公开实施过程归纳 - 先现代化数据平台再进入生成式AI场景 - 以站点选择周期定义首个端到端流程 - 连接预测模型与生成式交互 - 让临床团队在客户会议中实时比较方案 - 用候选清单时长和激活周期验证结果 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Microsoft案例称平台历时9个月部署，初始站点清单可在24至48小时生成，后续筛选由数月缩短至数周；2024年站点激活周期缩短约10%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 生成式AI应复用企业既有数据与预测能力 - 临床场景要把候选生成和最终资格决策分开 - 项目周期、局部处理时长和最终业务周期需分别度量 - 风险预警只有进入团队处置流程才产生价值 ## 现场决策与研究 ### 为什么这样做 在已有Azure数据体系上叠加生成式AI，先统一数据，再改造选址和预测。 ### 阻力与证据边界 24至48小时是初始名单时间；数周是后续筛选时间；约10%是站点激活周期，三个指标不可混用。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 保留选址依据、数据时点与专业复核，分别验证名单质量和实际激活时间。 研究依据： - [Syneos Health reduces time for clinical trial site activation](https://www.microsoft.com/en/customers/story/22558-syneos-health-azure-open-ai-service) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：经营分析与决策 适用条件：业务问题明确，关键指标有定义，数据来源、时间和责任人可追溯。 不适用：将发货当动销、将公司整体变化当单一系统收益，或让自由SQL直接访问生产敏感数据。 ### 输入条件 - 业务对象关系、指标字典、时间粒度和计量单位 - 历史决策、人工基线与业务约束 - 受权限约束的数据接口或语义查询层 ### 实施步骤 - 先问业务最终要做什么决定，列出决定所依赖的信息和现有误差。 - 审计连接键、粒度、时间窗与缺失值，建立可复算的标准查询。 - 模型解释意图和结果，计算与优化交给受约束工具，并呈现假设。 - 将建议交给责任人，跟踪是否采用及业务结果，按可比群体检验变化。 ### 验收指标 - 查询正确率由业务语义与数值共同确认，不以SQL可执行作为正确。 - 决策准备时间、预测误差、建议采用率分别记录。 - 经营收益扣除季节、业务结构和其他同时发生的改善，无法归因时明确标注。 ### 异常处理 数据口径不一致时停止生成确定结论；显示缺口并回到标准报表，修复后重算。 ### 责任分工 业务Owner定义决策；数据Owner确认口径；工程人员保证可复算；管理者承担最终决策。 ## 来源账本 - [Syneos Health reduces time for clinical trial site activation](https://www.microsoft.com/en/customers/story/22558-syneos-health-azure-open-ai-service) - 发布方：Microsoft - 披露性质：Microsoft与客户披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开组件和流程整理 - fde_actions：依据公开实施过程归纳 - result：Microsoft与客户披露 ## 待核对事项 - 站点清单24至48小时、筛选数周和激活周期下降10%是不同流程层级指标。 - 公开页面未披露试验类型、样本和对照方法。 ## 完整原始结构化记录 ```json { "id": "microsoft-syneos-health-001", "technical_reference": true, "source": "Microsoft", "company": "Syneos Health", "industry": "临床研究服务", "industry_group": "医疗与生命科学", "scenario": "临床试验选址、预测与文档工作流", "fde": "伴随式部署", "fde_relation": "联合数据与AI改造", "problem": "Syneos Health同时运行500多项临床试验，试验选址需要人工收集和比较大量站点、受试者与历史数据，往往耗时数月；团队还要处理预测、文档和客户场景讨论。", "solution": "公司在已迁移至Azure的数据资产上建设统一分析平台，使用Data Lake、Databricks、机器学习、数据质量能力和Azure OpenAI开发生成式AI应用；系统先生成候选站点清单，再支持逐步筛选，并通过预测模型提前提示试验延期风险，让员工实时演示不同方案。", "human": "AI生成候选站点、预测风险并辅助情景分析；临床运营和医学专家审核站点资格、风险和合规要求，最终试验设计及患者安全责任仍由专业团队承担。", "result": "Microsoft案例称平台历时9个月部署，初始站点清单可在24至48小时生成，后续筛选由数月缩短至数周；2024年站点激活周期缩短约10%。", "maturity": "生产使用/扩展中", "maturity_stage": "已上线", "url": "https://www.microsoft.com/en/customers/story/22558-syneos-health-azure-open-ai-service", "architecture": [ "临床试验、站点、受试者和运营数据", "Azure Data Lake统一存储与数据质量", "Azure Databricks转换和分析", "传统机器学习预测试验风险", "Azure OpenAI生成候选清单与情景分析", "临床专家审核、选择和风险处置" ], "components": [ "Azure Data Lake Storage", "Azure Databricks", "Azure OpenAI", "MLOps", "预测模型", "专家审核" ], "fde_actions": [ "先现代化数据平台再进入生成式AI场景", "以站点选择周期定义首个端到端流程", "连接预测模型与生成式交互", "让临床团队在客户会议中实时比较方案", "用候选清单时长和激活周期验证结果" ], "reusable": [ "生成式AI应复用企业既有数据与预测能力", "临床场景要把候选生成和最终资格决策分开", "项目周期、局部处理时长和最终业务周期需分别度量", "风险预警只有进入团队处置流程才产生价值" ], "evidence": "Microsoft逐案例页面公开平台组件、九个月建设周期、站点筛选过程与周期指标；结果由客户披露。", "case_summary": "Syneos Health把统一数据平台、预测模型和生成式AI组合到临床试验选址与风险管理中，既缩短候选生成，也保留临床专家最终决策。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Syneos Health reduces time for clinical trial site activation", "publisher": "Microsoft", "url": "https://www.microsoft.com/en/customers/story/22558-syneos-health-azure-open-ai-service", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "Microsoft与客户披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开组件和流程整理", "fde_actions": "依据公开实施过程归纳", "result": "Microsoft与客户披露" }, "verification_notes": [ "站点清单24至48小时、筛选数周和激活周期下降10%是不同流程层级指标。", "公开页面未披露试验类型、样本和对照方法。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Jabil｜全球制造数据底座与智能车间助手 - ID：aws-jabil-001 - 行业：制造与工业 - 来源：AWS - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：多基地扩展中 - 独立核验：未记录 ## 业务问题 Jabil在25个以上国家拥有100多个制造基地，机器数据长期孤立在各站点，跨域分析困难；既有车间应用还存在性能、扩展和部署效率问题，现场人员查故障资料依赖分散文档与工单。 ## 解决方案 Jabil与AWS通过多年项目逐步迁移和优化400多个业务应用，使用Redshift建立集中数据湖，通过EBA现场方法和培训提升团队能力；在此基础上用Amazon Q Business构建智能车间助手，连接文档、事故工单和知识文章，并继续扩展客户研究与采购助手。 ## 技术工作流 > 依据公开项目阶段整理 1. 各制造基地机器、应用、文档和工单数据 2. 混合云及400多个应用现代化 3. Redshift集中数据湖与跨域分析 4. Amazon Q Business车间/采购/研究助手 5. 操作员诊断与人工现场处置 6. 新站点和新数据源持续接入 组件：Amazon Redshift、Amazon EKS、AWS Glue Flex、Amazon Q Business、基础设施即代码、培训与EBA ## 人机责任 助手向操作员提供诊断资料和故障建议，现场人员确认设备状态并执行处置；采购和销售人员审核市场与客户研究结果，内部团队在培训后负责长期扩展。 ## FDE 动作 > 依据公开联合实施过程归纳 - 评估哪些负载适合云、边缘或本地 - 用现场EBA解决真实车间应用瓶颈 - 通过培训让内部团队接管长期建设 - 一周构建助手首版再逐步接数据源 - 同时跟踪部署、处理、成本和现场使用指标 ## 业务结果与盈利口径 **来源披露金额或成本影响** AWS案例将整体数据与云改造的部署时间缩短67%–83%、数据处理时间缩短74%，与生成式AI助手的结果分开披露。23%是Data Dispatcher迁移至AWS Glue Flex后、相对标准Glue ETL定价的成本节省，不是Amazon Q智能车间助手单独产生的ROI。助手首版一周完成，后续接入1,700多份资料并减少故障排查时间；未披露助手的独立财务收益。 > 来源披露的成本、收入或经济价值不自动等同于项目净利润；完整投入与独立归因仍未核验。 ## 原有复用建议 - 全球制造AI应先解决站点数据孤岛 - 云迁移、数据平台和AI助手是连续改造而非三个项目 - 首版助手应从可访问的文档和工单开始 - 组织技能建设决定多基地复制速度 ## 现场决策与研究 ### 为什么这样做 多年数据改造配合现场培训，再尝试智能车间助手；云与边缘按场景分工。 ### 阻力与证据边界 部署和数据处理提速来自整体平台改造，不能归给一周完成的助手首版。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 分开建立数据平台SLO与助手有效性指标，选择单厂故障资料先验证。 研究依据： - [Jabil drives manufacturing efficiency and process optimization](https://aws.amazon.com/solutions/case-studies/jabil-manufacturing-transformation-generative-ai/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Jabil drives manufacturing efficiency and process optimization](https://aws.amazon.com/solutions/case-studies/jabil-manufacturing-transformation-generative-ai/) - 发布方：AWS - 披露性质：AWS与客户披露 - 原记录查阅日期：2026-09-23 - [Jabil boosts manufacturing efficiency with AWS collaboration](https://aws.amazon.com/solutions/case-studies/jabil-case-study/) ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开项目阶段整理 - fde_actions：依据公开联合实施过程归纳 - result：AWS与客户披露 ## 待核对事项 - 67%至83%部署缩短和74%处理缩短来自整体云与数据改造。 - 一周指标指智能车间助手第一版，不代表全球全面上线。 - 23%成本节省属于Data Dispatcher的Glue Flex ETL定价比较；不可归因给Amazon Q助手。 ## 完整原始结构化记录 ```json { "id": "aws-jabil-001", "technical_reference": true, "source": "AWS", "company": "Jabil", "industry": "电子制造服务", "industry_group": "制造与工业", "scenario": "全球制造数据底座与智能车间助手", "fde": "伴随式部署", "fde_relation": "长期联合改造", "problem": "Jabil在25个以上国家拥有100多个制造基地，机器数据长期孤立在各站点，跨域分析困难；既有车间应用还存在性能、扩展和部署效率问题，现场人员查故障资料依赖分散文档与工单。", "solution": "Jabil与AWS通过多年项目逐步迁移和优化400多个业务应用，使用Redshift建立集中数据湖，通过EBA现场方法和培训提升团队能力；在此基础上用Amazon Q Business构建智能车间助手，连接文档、事故工单和知识文章，并继续扩展客户研究与采购助手。", "human": "助手向操作员提供诊断资料和故障建议，现场人员确认设备状态并执行处置；采购和销售人员审核市场与客户研究结果，内部团队在培训后负责长期扩展。", "result": "AWS案例将整体数据与云改造的部署时间缩短67%–83%、数据处理时间缩短74%，与生成式AI助手的结果分开披露。23%是Data Dispatcher迁移至AWS Glue Flex后、相对标准Glue ETL定价的成本节省，不是Amazon Q智能车间助手单独产生的ROI。助手首版一周完成，后续接入1,700多份资料并减少故障排查时间；未披露助手的独立财务收益。", "maturity": "多基地扩展中", "maturity_stage": "规模化", "url": "https://aws.amazon.com/solutions/case-studies/jabil-manufacturing-transformation-generative-ai/", "architecture": [ "各制造基地机器、应用、文档和工单数据", "混合云及400多个应用现代化", "Redshift集中数据湖与跨域分析", "Amazon Q Business车间/采购/研究助手", "操作员诊断与人工现场处置", "新站点和新数据源持续接入" ], "components": [ "Amazon Redshift", "Amazon EKS", "AWS Glue Flex", "Amazon Q Business", "基础设施即代码", "培训与EBA" ], "fde_actions": [ "评估哪些负载适合云、边缘或本地", "用现场EBA解决真实车间应用瓶颈", "通过培训让内部团队接管长期建设", "一周构建助手首版再逐步接数据源", "同时跟踪部署、处理、成本和现场使用指标" ], "reusable": [ "全球制造AI应先解决站点数据孤岛", "云迁移、数据平台和AI助手是连续改造而非三个项目", "首版助手应从可访问的文档和工单开始", "组织技能建设决定多基地复制速度" ], "evidence": "AWS逐案例页面披露多年改造、技术组件、人员培训和多项结果；部分结果属于底层现代化而非生成式AI单独贡献。", "case_summary": "Jabil案例从400多个应用和制造数据底座开始，再把生成式AI助手放进车间故障诊断，展示了全球多基地企业逐步改造而非一次性上模型的路径。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Jabil drives manufacturing efficiency and process optimization", "publisher": "AWS", "url": "https://aws.amazon.com/solutions/case-studies/jabil-manufacturing-transformation-generative-ai/", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "AWS与客户披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开项目阶段整理", "fde_actions": "依据公开联合实施过程归纳", "result": "AWS与客户披露" }, "verification_notes": [ "67%至83%部署缩短和74%处理缩短来自整体云与数据改造。", "一周指标指智能车间助手第一版，不代表全球全面上线。", "23%成本节省属于Data Dispatcher的Glue Flex ETL定价比较；不可归因给Amazon Q助手。" ], "additional_sources": [ { "title": "Jabil boosts manufacturing efficiency with AWS collaboration", "url": "https://aws.amazon.com/solutions/case-studies/jabil-case-study/" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Altisource｜生成式AI驱动遗留Java应用现代化 - ID：aws-altisource-001 - 行业：专业服务 - 来源：AWS - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：生产级研发转型 - 独立核验：未记录 ## 业务问题 Altisource需要改造十年以上的企业应用以支持新的房地产和抵押贷款业务，但遗留Java代码量大、上下文分散在Jira、Bitbucket和设计文件中，传统重构速度难以满足业务窗口。 ## 解决方案 公司把生成式AI纳入企业级现代化方法，让Amazon Q Developer结合整个代码库及Jira、Bitbucket和设计上下文进行重构、解释和变更建议；团队仍使用Scrum、测试、安全扫描和业务演示控制交付，并以故事点、漏洞和应用交付量验证效果。 ## 技术工作流 > 依据公开研发流程整理 1. 遗留Java代码、Jira、Bitbucket与设计文件 2. 企业级代码上下文索引 3. Amazon Q Developer理解与生成 4. 重构、测试和漏洞扫描流水线 5. 工程Review与业务演示验收 6. 故事点、交付周期与安全结果度量 组件：Amazon Q Developer、Java代码库、Jira、Bitbucket、CI/CD与测试、安全扫描 ## 人机责任 AI负责理解遗留上下文、生成和重构代码；工程师审查设计与代码、运行测试和安全检查，产品和业务负责人验收功能并决定发布。 ## FDE 动作 > 依据公开实施过程归纳 - 把工具接入完整研发上下文而非单文件补全 - 选择遗留现代化作为明确业务目标 - 保留Scrum、Review、测试和安全门禁 - 用真实应用而非样例代码验证 - 同时度量速度、产出和漏洞变化 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** AWS案例披露，团队现代化超过35万行Java代码，开发生产率提升25%，4个月交付4个新应用，代码漏洞减少54%；三个月平均Scrum故事点从约160升至200。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 代码Agent价值来自仓库和项目上下文 - 生产率指标必须与质量和安全指标并列 - 以可演示应用验证现代化进展 - AI生成代码不能绕过现有工程门禁 ## 现场决策与研究 ### 为什么这样做 先通过工作坊验证代码现代化方式，再把现有工程资料接入开发流程。 ### 阻力与证据边界 故事点增长是团队局部口径；代码行数并非业务价值，必须观察交付质量与停机。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 选一个可回滚模块，固定编译、回归、安全扫描和上线观测门槛。 研究依据： - [Altisource boosts developer productivity with Amazon Q Developer](https://aws.amazon.com/solutions/case-studies/altisource-case-study/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：软件研发与现代化 适用条件：有可运行的环境、版本管理、有效测试和能够审查变更的负责人。 不适用：没有回归基线就大面积重写，或者只用提交次数、代码行数证明生产力。 ### 输入条件 - 需求说明、仓库约定、依赖边界与历史设计记录 - 能复现现状的构建与测试环境 - 缺陷、交付周期、返工和运行质量基线 ### 实施步骤 - 挑选可独立验收和回滚的任务，将需求与接受标准写进版本化文档。 - 给Agent最小所需上下文与权限，产出可审查的变更和验证记录。 - 工程师审查业务语义，执行有意义的回归、安全与兼容性检查。 - 小范围发布，监测真实业务路径与运行错误；把失败沉淀为可复现用例。 ### 验收指标 - 需求到上线的中位数与长尾周期，并控制任务复杂度。 - 返工率、逃逸缺陷、回滚次数与工程师审查时间。 - 净效率：包含配置、提示、等待、审查、纠错的完整任务耗时。 ### 异常处理 测试不稳定或验收标准不清时缩小范围；生产异常按既有发布策略回滚，不能让Agent自行扩大变更。 ### 责任分工 需求Owner确认业务行为；开发人员实施并审查；测试和运行负责人确认回归与发布。 ## 来源账本 - [Altisource boosts developer productivity with Amazon Q Developer](https://aws.amazon.com/solutions/case-studies/altisource-case-study/) - 发布方：AWS - 披露性质：AWS与客户披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开研发流程整理 - fde_actions：依据公开实施过程归纳 - result：AWS与客户披露 ## 待核对事项 - 35万行、25%、4个应用、54%均来自AWS客户案例。 - 故事点不适合跨团队直接比较，只能作为该团队前后变化线索。 ## 完整原始结构化记录 ```json { "id": "aws-altisource-001", "technical_reference": true, "source": "AWS", "company": "Altisource", "industry": "房地产科技", "industry_group": "专业服务", "scenario": "生成式AI驱动遗留Java应用现代化", "fde": "企业部署案例", "fde_relation": "研发流程改造", "problem": "Altisource需要改造十年以上的企业应用以支持新的房地产和抵押贷款业务，但遗留Java代码量大、上下文分散在Jira、Bitbucket和设计文件中，传统重构速度难以满足业务窗口。", "solution": "公司把生成式AI纳入企业级现代化方法，让Amazon Q Developer结合整个代码库及Jira、Bitbucket和设计上下文进行重构、解释和变更建议；团队仍使用Scrum、测试、安全扫描和业务演示控制交付，并以故事点、漏洞和应用交付量验证效果。", "human": "AI负责理解遗留上下文、生成和重构代码；工程师审查设计与代码、运行测试和安全检查，产品和业务负责人验收功能并决定发布。", "result": "AWS案例披露，团队现代化超过35万行Java代码，开发生产率提升25%，4个月交付4个新应用，代码漏洞减少54%；三个月平均Scrum故事点从约160升至200。", "maturity": "生产级研发转型", "maturity_stage": "已上线", "url": "https://aws.amazon.com/solutions/case-studies/altisource-case-study/", "architecture": [ "遗留Java代码、Jira、Bitbucket与设计文件", "企业级代码上下文索引", "Amazon Q Developer理解与生成", "重构、测试和漏洞扫描流水线", "工程Review与业务演示验收", "故事点、交付周期与安全结果度量" ], "components": [ "Amazon Q Developer", "Java代码库", "Jira", "Bitbucket", "CI/CD与测试", "安全扫描" ], "fde_actions": [ "把工具接入完整研发上下文而非单文件补全", "选择遗留现代化作为明确业务目标", "保留Scrum、Review、测试和安全门禁", "用真实应用而非样例代码验证", "同时度量速度、产出和漏洞变化" ], "reusable": [ "代码Agent价值来自仓库和项目上下文", "生产率指标必须与质量和安全指标并列", "以可演示应用验证现代化进展", "AI生成代码不能绕过现有工程门禁" ], "evidence": "AWS逐案例页面公开代码量、应用数、生产率、故事点和漏洞指标；没有公开基线项目复杂度和外部审计。", "case_summary": "Altisource案例把代码Agent放进包含项目管理、代码仓库、测试和安全扫描的完整研发闭环，并用35万行代码和4个真实应用验证改造。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Altisource boosts developer productivity with Amazon Q Developer", "publisher": "AWS", "url": "https://aws.amazon.com/solutions/case-studies/altisource-case-study/", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "AWS与客户披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开研发流程整理", "fde_actions": "依据公开实施过程归纳", "result": "AWS与客户披露" }, "verification_notes": [ "35万行、25%、4个应用、54%均来自AWS客户案例。", "故事点不适合跨团队直接比较，只能作为该团队前后变化线索。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Berenberg｜投研助手、晨报生产与全行AI分层策略 - ID：google-berenberg-001 - 行业：金融与保险 - 来源：Google Cloud - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜厂商逐案例来源 - 部署：场景生产/全行推广中 - 独立核验：未记录 ## 业务问题 Berenberg的投资组合经理每天需要阅读和综合券商报告、公司文件与市场新闻，研究吞吐受人工时间限制；作为受监管银行，通用AI还必须接入专有投资框架并保留合规复核。 ## 解决方案 银行先用Vertex AI构建BegoChat，将券商报告、公司文件、新闻和内部投资方法结合；再构建每日Morning Mail内容工作流，并形成三层AI金字塔：顶部是带专有数据的定制场景，中层是NotebookLM等日常AI，底层是集中管理、合规连接的企业平台和Agent市场。 ## 技术工作流 > 依据公开三层策略整理 1. 券商报告、公司文件、新闻与专有投资框架 2. Vertex AI文档聚合和语义分析 3. BegoChat定制投研助手 4. Morning Mail内容生产工作流 5. NotebookLM日常AI与企业Agent市场 6. 分析师审核、合规和客户沟通 组件：Vertex AI、Gemini Enterprise、NotebookLM、专有投研数据、集中Agent管理、Human-in-the-loop ## 人机责任 分析师提供专有研究框架和原始判断，AI完成聚合、比较与初稿生产；分析师和销售人员在输出末端审核质量、合规并承担客户沟通和投资决策责任。 ## FDE 动作 > 依据公开实施演进归纳 - 从组合经理阅读瓶颈选择定制场景 - 把银行专有投资方法注入上下文 - 将高价值定制AI与通用日常AI分层 - 为全行推广设置培训和监控 - 用P&L方向和流程时间筛选项目 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Google Cloud案例称，Morning Mail等流程内容生产速度提升85%至90%，约为每名销售每天节省1小时；相同团队能够覆盖更广市场。企业级Gemini计划从2026年起分阶段推广。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 专有业务方法比通用模型本身更能形成差异 - 企业AI应区分定制场景和日常工具 - 受监管输出需要人在输入和输出两端负责 - 流程时间节省最终应映射到收入或成本 ## 现场决策与研究 现有公开材料尚不能还原完整决策过程。不得把模板化架构或建议冒充客户已实施事实。下一步应定位客户对现场发现、放弃方案、维护成本和长期采用的直接记录。 ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Early wins, big ambitions: Berenberg Gemini Enterprise transformation](https://cloud.google.com/customers/berenberg) - 发布方：Google Cloud - 披露性质：Google Cloud与客户披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：厂商客户案例披露 - solution：厂商客户案例披露 - architecture：依据公开三层策略整理 - fde_actions：依据公开实施演进归纳 - result：Google Cloud与客户披露 ## 待核对事项 - 85%至90%主要指Morning Mail等内容生产流程。 - 全行Gemini Enterprise仍处于分阶段推广，不能与已上线定制场景混为一谈。 ## 完整原始结构化记录 ```json { "id": "google-berenberg-001", "source": "Google Cloud", "company": "Berenberg", "industry": "私人银行/资产管理", "industry_group": "金融与保险", "scenario": "投研助手、晨报生产与全行AI分层策略", "fde": "伴随式部署", "fde_relation": "多年AI能力演进", "problem": "Berenberg的投资组合经理每天需要阅读和综合券商报告、公司文件与市场新闻，研究吞吐受人工时间限制；作为受监管银行，通用AI还必须接入专有投资框架并保留合规复核。", "solution": "银行先用Vertex AI构建BegoChat，将券商报告、公司文件、新闻和内部投资方法结合；再构建每日Morning Mail内容工作流，并形成三层AI金字塔：顶部是带专有数据的定制场景，中层是NotebookLM等日常AI，底层是集中管理、合规连接的企业平台和Agent市场。", "human": "分析师提供专有研究框架和原始判断，AI完成聚合、比较与初稿生产；分析师和销售人员在输出末端审核质量、合规并承担客户沟通和投资决策责任。", "result": "Google Cloud案例称，Morning Mail等流程内容生产速度提升85%至90%，约为每名销售每天节省1小时；相同团队能够覆盖更广市场。企业级Gemini计划从2026年起分阶段推广。", "maturity": "场景生产/全行推广中", "maturity_stage": "已上线", "url": "https://cloud.google.com/customers/berenberg", "architecture": [ "券商报告、公司文件、新闻与专有投资框架", "Vertex AI文档聚合和语义分析", "BegoChat定制投研助手", "Morning Mail内容生产工作流", "NotebookLM日常AI与企业Agent市场", "分析师审核、合规和客户沟通" ], "components": [ "Vertex AI", "Gemini Enterprise", "NotebookLM", "专有投研数据", "集中Agent管理", "Human-in-the-loop" ], "fde_actions": [ "从组合经理阅读瓶颈选择定制场景", "把银行专有投资方法注入上下文", "将高价值定制AI与通用日常AI分层", "为全行推广设置培训和监控", "用P&L方向和流程时间筛选项目" ], "reusable": [ "专有业务方法比通用模型本身更能形成差异", "企业AI应区分定制场景和日常工具", "受监管输出需要人在输入和输出两端负责", "流程时间节省最终应映射到收入或成本" ], "evidence": "Google Cloud逐案例页面披露多年演进、系统分层、人机边界和时间结果；属于厂商与客户联合材料。", "case_summary": "Berenberg不是一次性全员上工具，而是先用专有投研数据做高价值助手，再把定制AI、日常AI和集中平台分层扩展到全行。", "evidence_level": "A", "evidence_label": "A级｜厂商逐案例来源", "source_record": { "title": "Early wins, big ambitions: Berenberg Gemini Enterprise transformation", "publisher": "Google Cloud", "url": "https://cloud.google.com/customers/berenberg", "source_type": "厂商官方客户案例", "directness": "案例级直接来源", "claim_origin": "Google Cloud与客户披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开三层策略整理", "fde_actions": "依据公开实施演进归纳", "result": "Google Cloud与客户披露" }, "verification_notes": [ "85%至90%主要指Morning Mail等内容生产流程。", "全行Gemini Enterprise仍处于分阶段推广，不能与已上线定制场景混为一谈。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Uber｜值班工程支持与内部知识问答 Genie - ID：enterprise-uber-genie-001 - 行业：科技与软件 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业工程博客直接来源 - 部署：生产使用/持续评测 - 独立核验：未记录 ## 业务问题 Uber各平台团队每月在数百个Slack支持频道提出约4.5万个问题，答案散落在内部Engwiki、Stack Overflow、工程需求文档和历史对话中；重复问答和多轮等待同时消耗提问者与值班工程师时间。 ## 解决方案 Uber自研Genie，把内部资料经Spark抓取、LangChain切块和OpenAI Embedding转为向量，通过Sia与Terrablob构建受频道权限约束的索引；用户在Slack提问后，Knowledge Service检索相关片段并让LLM基于证据回答，同时记录成本、即时反馈和离线评测结果。 ## 技术工作流 > 企业工程博客逐层披露 1. Engwiki、内部Stack Overflow与工程需求文档 2. Spark抓取、LangChain切块与PySpark UDF批处理 3. OpenAI Embedding生成文档和问题向量 4. Sia向量数据库与Terrablob索引分发 5. Slack请求进入Knowledge Service检索并调用LLM 6. 频道级权限、UUID成本审计、Kafka/Hive反馈与LLM-as-a-judge评测 组件：Slack、Apache Spark、LangChain、OpenAI Embedding、Sia向量数据库、Terrablob、Michelangelo Gateway、Kafka/Hive ## 人机责任 Genie先处理已有文档可回答的问题；需要代码审查、上下文不足或回答无关时转给值班工程师。用户以Resolved、Helpful等标签反馈，平台团队用人工反馈和评测报告继续调整检索与生成。 ## FDE 动作 > 依据公开实施过程归纳 - 统计支持频道问题量和重复问答来源 - 比较微调与RAG后选择更快上线的RAG - 按Slack频道映射知识空间访问权限 - 为每次请求传递UUID并按请求核算模型成本 - 把用户反馈流入Hive并用Michelangelo评测检索与生成 ## 业务结果与盈利口径 **当前纳入来源未给出量化财务结果** Uber 2024年10月工程博客披露：自2023年9月上线后覆盖154个Slack频道，累计回答超过70,000个问题，helpfulness反馈率为48.9%，估算节省13,000工程小时。helpfulness不等于问题解决率，工时为企业估算；未披露完整财务ROI。 > 保留来源披露的定性结果；不根据业务规模、用户数或流程变化推算盈利。 ## 原有复用建议 - 内部知识助手必须继承原知识空间权限 - 支持机器人要明确哪些请求直接转人工 - 成本、用户反馈和离线质量评测应使用同一请求标识关联 - RAG组件需要分别评估召回与生成而不是只看最终答案 ## 现场决策与研究 ### 为什么这样做 优先RAG而非微调以降低启动的数据准备门槛，回答嵌入既有Slack支持渠道。 ### 阻力与证据边界 检索内容必须适合所在频道权限；helpfulness、解决率和估算节省工时是三种不同口径。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 建立无答案、过时文档和跨频道权限的测试样本，联动转人工与反馈回写。 研究依据： - [Genie: Uber’s Gen AI On-Call Copilot](https://www.uber.com/us/en/blog/genie-ubers-gen-ai-on-call-copilot/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Genie: Uber’s Gen AI On-Call Copilot](https://www.uber.com/us/en/blog/genie-ubers-gen-ai-on-call-copilot/) - 发布方：Uber Engineering - 披露性质：企业工程团队披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：企业工程博客披露 - solution：企业工程博客披露与中文结构化整理 - architecture：企业工程博客逐层披露 - fde_actions：依据公开实施过程归纳 - result：企业工程博客披露 ## 待核对事项 - 每月约4.5万个问题是需求基线，不是Genie处理量。 - 48.9%是helpfulness反馈率，不等于全部问题解决率；13,000工程小时为企业估算，非独立审计或财务ROI。 ## 完整原始结构化记录 ```json { "id": "enterprise-uber-genie-001", "technical_reference": true, "source": "企业原始材料", "company": "Uber", "industry": "出行平台/软件", "industry_group": "科技与软件", "scenario": "值班工程支持与内部知识问答 Genie", "fde": "企业部署案例", "fde_relation": "内部工程流程改造", "problem": "Uber各平台团队每月在数百个Slack支持频道提出约4.5万个问题，答案散落在内部Engwiki、Stack Overflow、工程需求文档和历史对话中；重复问答和多轮等待同时消耗提问者与值班工程师时间。", "solution": "Uber自研Genie，把内部资料经Spark抓取、LangChain切块和OpenAI Embedding转为向量，通过Sia与Terrablob构建受频道权限约束的索引；用户在Slack提问后，Knowledge Service检索相关片段并让LLM基于证据回答，同时记录成本、即时反馈和离线评测结果。", "human": "Genie先处理已有文档可回答的问题；需要代码审查、上下文不足或回答无关时转给值班工程师。用户以Resolved、Helpful等标签反馈，平台团队用人工反馈和评测报告继续调整检索与生成。", "result": "Uber 2024年10月工程博客披露：自2023年9月上线后覆盖154个Slack频道，累计回答超过70,000个问题，helpfulness反馈率为48.9%，估算节省13,000工程小时。helpfulness不等于问题解决率，工时为企业估算；未披露完整财务ROI。", "maturity": "生产使用/持续评测", "maturity_stage": "已上线", "url": "https://www.uber.com/us/en/blog/genie-ubers-gen-ai-on-call-copilot/", "architecture": [ "Engwiki、内部Stack Overflow与工程需求文档", "Spark抓取、LangChain切块与PySpark UDF批处理", "OpenAI Embedding生成文档和问题向量", "Sia向量数据库与Terrablob索引分发", "Slack请求进入Knowledge Service检索并调用LLM", "频道级权限、UUID成本审计、Kafka/Hive反馈与LLM-as-a-judge评测" ], "components": [ "Slack", "Apache Spark", "LangChain", "OpenAI Embedding", "Sia向量数据库", "Terrablob", "Michelangelo Gateway", "Kafka/Hive" ], "fde_actions": [ "统计支持频道问题量和重复问答来源", "比较微调与RAG后选择更快上线的RAG", "按Slack频道映射知识空间访问权限", "为每次请求传递UUID并按请求核算模型成本", "把用户反馈流入Hive并用Michelangelo评测检索与生成" ], "reusable": [ "内部知识助手必须继承原知识空间权限", "支持机器人要明确哪些请求直接转人工", "成本、用户反馈和离线质量评测应使用同一请求标识关联", "RAG组件需要分别评估召回与生成而不是只看最终答案" ], "evidence": "Uber工程博客披露了技术链路、154个频道、70,000多次问答、48.9%帮助率与估算13,000工程小时；这些为企业自述，不是独立审计。", "case_summary": "Uber Genie的参考价值在于，它不是只把文档接到聊天框，而是把Slack权限、向量索引分发、单请求成本和反馈评测全部纳入值班支持系统。", "evidence_level": "A", "evidence_label": "A级｜企业工程博客直接来源", "source_record": { "title": "Genie: Uber’s Gen AI On-Call Copilot", "publisher": "Uber Engineering", "url": "https://www.uber.com/us/en/blog/genie-ubers-gen-ai-on-call-copilot/", "source_type": "企业工程博客", "directness": "案例级直接来源", "claim_origin": "企业工程团队披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业工程博客披露", "solution": "企业工程博客披露与中文结构化整理", "architecture": "企业工程博客逐层披露", "fde_actions": "依据公开实施过程归纳", "result": "企业工程博客披露" }, "verification_notes": [ "每月约4.5万个问题是需求基线，不是Genie处理量。", "48.9%是helpfulness反馈率，不等于全部问题解决率；13,000工程小时为企业估算，非独立审计或财务ROI。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Grab｜从技术支持Bot演进为企业Agent开发平台 LLM-Kit - ID：enterprise-grab-llm-kit-001 - 行业：科技与软件 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业工程博客直接来源 - 部署：企业级平台规模化 - 独立核验：未记录 ## 业务问题 Grab技术基础设施团队每半年要处理数千个重复支持工单；早期支持Bot能回答问题，但每个新Agent团队仍要重复处理认证、密钥、部署、可观测性、工具连接和评测，导致原型难以稳定进入生产。 ## 解决方案 Grab先以Go服务构建Level-0支持Bot，让单Agent循环调用Glean、Kibana、GitLab、Slack和HTTP工具，无法解决时携带上下文转人工；再把踩过的坑沉淀为LLM-Kit模板，一键生成含FastAPI、LangGraph ReAct、远程MCP、pgvector、Vault、OIDC、OpenTelemetry、测试和Evals的生产仓库。 ## 技术工作流 > 企业工程博客代码与架构披露 1. 文档、Runbook、Slack、Jira、日志和GitLab文件 2. Glean检索及Kibana/GitLab/Slack等工具层 3. LangGraph ReAct推理循环与远程MCP工具发现 4. 统一LLM Gateway、模型路由与用量治理 5. FastAPI、Postgres/pgvector、Vault、OIDC与环境配置 6. OpenTelemetry可观测、黄金集、ROUGE/BLEU和LLM-as-a-judge评测 组件：LLM-Kit、LangGraph、FastAPI、MCP、Glean、Postgres/pgvector、Vault/OIDC、OpenTelemetry、Evalshub ## 人机责任 Bot先尝试回答文档化问题，未解决工单路由到正确的技术人员；Agent开发者只维护自己的业务逻辑和工具，平台团队统一维护认证、密钥、部署、网关、可观测与评测底座。 ## FDE 动作 > 依据公开演进过程归纳 - 先用一个高频支持流程暴露Agent生产化问题 - 把推理平面和工具平面分离 - 将认证、密钥、存储和部署固化为模板 - 让开发者从可运行Agent而不是空项目开始 - 在项目第一天内置黄金集和多种评测器 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Grab披露已有500多个服务运行在内部Agent框架上，注册50多个远程MCP服务器，统一LLM网关每月处理数十亿Token；过去至少两周的首日基础接线缩短到约1小时。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - Agent规模化的瓶颈通常是生产工程而不是第一次演示 - 统一框架应标准化基础设施但保留业务逻辑自由度 - MCP工具和模型调用都需要企业级注册与治理 - 评测能力应随模板交付而不是上线前补建 ## 现场决策与研究 ### 为什么这样做 从一个支持Bot反复遇到的工程问题抽取共享框架，没有先建设重型中央平台。 ### 阻力与证据边界 缺乏评测、模型切换困难、三层日志无法关联、生产包装耗时，才是规模化障碍。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 新服务模板默认包含认证、追踪、评测和超时；测量交付时间与故障定位时间。 研究依据： - [Agent platform (Part 1): How we help Grab build and run AI agents at scale](https://engineering.grab.com/how-grab-builds-and-runs-ai-agents-at-scale) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [Agent platform (Part 1): How we help Grab build and run AI agents at scale](https://engineering.grab.com/how-grab-builds-and-runs-ai-agents-at-scale) - 发布方：Grab Engineering - 披露性质：企业工程团队披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：企业工程博客披露 - solution：企业工程博客披露与中文结构化整理 - architecture：企业工程博客代码与架构披露 - fde_actions：依据公开演进过程归纳 - result：企业工程团队披露 ## 待核对事项 - 500多个服务不等于500个独立Agent产品，按原文保留“服务”口径。 - 两周到一小时指基础接线，不代表完整Agent交付周期。 ## 完整原始结构化记录 ```json { "id": "enterprise-grab-llm-kit-001", "technical_reference": true, "source": "企业原始材料", "company": "Grab", "industry": "出行与本地生活平台", "industry_group": "科技与软件", "scenario": "从技术支持Bot演进为企业Agent开发平台 LLM-Kit", "fde": "企业部署案例", "fde_relation": "内部平台化改造", "problem": "Grab技术基础设施团队每半年要处理数千个重复支持工单；早期支持Bot能回答问题，但每个新Agent团队仍要重复处理认证、密钥、部署、可观测性、工具连接和评测，导致原型难以稳定进入生产。", "solution": "Grab先以Go服务构建Level-0支持Bot，让单Agent循环调用Glean、Kibana、GitLab、Slack和HTTP工具，无法解决时携带上下文转人工；再把踩过的坑沉淀为LLM-Kit模板，一键生成含FastAPI、LangGraph ReAct、远程MCP、pgvector、Vault、OIDC、OpenTelemetry、测试和Evals的生产仓库。", "human": "Bot先尝试回答文档化问题，未解决工单路由到正确的技术人员；Agent开发者只维护自己的业务逻辑和工具，平台团队统一维护认证、密钥、部署、网关、可观测与评测底座。", "result": "Grab披露已有500多个服务运行在内部Agent框架上，注册50多个远程MCP服务器，统一LLM网关每月处理数十亿Token；过去至少两周的首日基础接线缩短到约1小时。", "maturity": "企业级平台规模化", "maturity_stage": "规模化", "url": "https://engineering.grab.com/how-grab-builds-and-runs-ai-agents-at-scale", "architecture": [ "文档、Runbook、Slack、Jira、日志和GitLab文件", "Glean检索及Kibana/GitLab/Slack等工具层", "LangGraph ReAct推理循环与远程MCP工具发现", "统一LLM Gateway、模型路由与用量治理", "FastAPI、Postgres/pgvector、Vault、OIDC与环境配置", "OpenTelemetry可观测、黄金集、ROUGE/BLEU和LLM-as-a-judge评测" ], "components": [ "LLM-Kit", "LangGraph", "FastAPI", "MCP", "Glean", "Postgres/pgvector", "Vault/OIDC", "OpenTelemetry", "Evalshub" ], "fde_actions": [ "先用一个高频支持流程暴露Agent生产化问题", "把推理平面和工具平面分离", "将认证、密钥、存储和部署固化为模板", "让开发者从可运行Agent而不是空项目开始", "在项目第一天内置黄金集和多种评测器" ], "reusable": [ "Agent规模化的瓶颈通常是生产工程而不是第一次演示", "统一框架应标准化基础设施但保留业务逻辑自由度", "MCP工具和模型调用都需要企业级注册与治理", "评测能力应随模板交付而不是上线前补建" ], "evidence": "Grab工程博客公开初代支持Bot、LLM-Kit目录结构、具体组件、规模指标和开发时间变化；属于企业自述，未有第三方审计。", "case_summary": "Grab案例完整展示了一个内部支持Bot如何因真实失败而演进成企业Agent框架，并把认证、工具、可观测、评测和部署变成可复用的生产模板。", "evidence_level": "A", "evidence_label": "A级｜企业工程博客直接来源", "source_record": { "title": "Agent platform (Part 1): How we help Grab build and run AI agents at scale", "publisher": "Grab Engineering", "url": "https://engineering.grab.com/how-grab-builds-and-runs-ai-agents-at-scale", "source_type": "企业工程博客", "directness": "案例级直接来源", "claim_origin": "企业工程团队披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业工程博客披露", "solution": "企业工程博客披露与中文结构化整理", "architecture": "企业工程博客代码与架构披露", "fde_actions": "依据公开演进过程归纳", "result": "企业工程团队披露" }, "verification_notes": [ "500多个服务不等于500个独立Agent产品，按原文保留“服务”口径。", "两周到一小时指基础接线，不代表完整Agent交付周期。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Bosch｜生成式合成缺陷数据与定子焊点视觉质检 - ID：enterprise-bosch-visual-inspection-001 - 行业：制造与工业 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业技术案例直接来源 - 部署：工厂试点/跨厂复制 - 独立核验：未记录 ## 业务问题 自动光学质检需要覆盖多种缺陷图像，但Bosch制造质量较高，新产线很难自然积累足够坏件；等待真实缺陷会拖慢模型和产线投产，故意破坏零件又成本高且无法覆盖全部变体。 ## 解决方案 Bosch研究团队用旧产品和每种缺陷仅两位数规模的真实图像做Domain Transfer，生成约1.5万张新产品合成缺陷图；2D与3D相机从12个位置拍摄定子焊点，视觉模型在实图与合成图上训练后快速判定并让可修复件自动回流，同时由图像专家持续修正误报规则和重训模型。 ## 技术工作流 > 企业公开流程与组件披露 1. 旧产品和少量真实缺陷图 2. Domain Transfer生成新产品合成缺陷图 3. 真实与合成数据联合训练视觉检测模型 4. 12个位置的2D/3D相机采集定子焊点 5. 在线判定并让可修复件自动返回生产流程 6. 专家复核误报、调整规则并人工重训模型 组件：生成式视觉模型、合成数据、Domain Transfer、2D/3D工业相机、自动光学检测、返修回流控制、专家重训 ## 人机责任 视觉模型完成高速初检与回流控制；图像处理工程师检查误报，例如判断弱焊是否仍可接受，并通过人工重训调整“合格/缺陷”边界。不可返修的缺陷仍按制造质量流程处置。 ## FDE 动作 > 依据公开项目过程归纳 - 先定义六类焊接缺陷及可返修边界 - 盘点可复用旧产品图像和少量新样本 - 以合成数据补齐长尾缺陷而非等待坏件 - 把检测输出直接接入返修流程 - 由现场专家持续校准误报与合格边界 ## 业务结果与盈利口径 **金额/财务价值含估算或代理口径** Bosch项目团队预计项目周期可比传统方法缩短6个月，并带来每年六位数欧元的生产率收益；这是扩展阶段的预期价值，不是已实现利润或经审计收益。来源未给出完整成本、实际收益周期和净ROI。 > 请按上方原文区分已实现结果、预测、机会值和时间折算价值；这些口径不等同于项目净利润或净现金节省。 ## 原有复用建议 - 高质量制造现场可用合成数据解决坏样本稀缺 - 合成数据必须与真实数据联合验证 - 模型判定需要映射到返修和报废动作 - 现场专家应持续维护视觉质量边界 ## 现场决策与研究 ### 为什么这样做 用现有产品真实缺陷图做领域迁移，为新产线补充稀缺的缺陷样本。 ### 阻力与证据边界 合成数据不等于独立测试集；可接受焊点被误判后仍需专家修正规则，收益包含预期值。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按真实新产线缺陷类型验证漏检与误报；分离训练合成图和真实验收集。 研究依据： - [Generative AI in manufacturing](https://www.bosch.com/stories/ai-image-recognition-production/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：视觉质检与现场优化 适用条件：缺陷或约束可以由专家定义，有真实现场样本与安全回退方式。 不适用：仅在合成样本上测试，或输出无法被现场人员执行的最优方案。 ### 输入条件 - 真实设备、光照、工况与缺陷分类样本 - 物理尺寸、重量、工序、节拍与安全约束 - 人工验收标准和误判成本 ### 实施步骤 - 观察现场工作和异常处理，核准采集条件与真正可用的物理空间。 - 可用合成数据补训练覆盖，但验收留出真实新批次数据。 - 让专家检查误报和漏报，先影子运行，再小范围接入现场流程。 - 记录复检、返工和停机，工况变化时重新验证并维护版本。 ### 验收指标 - 缺陷类型级漏检率、误报率与人工复检量。 - 实际生产节拍或装卸工时，连同损伤、安全与返工指标。 - 上线后的漂移和异常批次单独跟踪，不能仅报实验室准确率。 ### 异常处理 工况漂移或安全边界触发时退出自动判定，回到人工检查；保留批次和设备上下文。 ### 责任分工 现场专家定义可接受结果；算法团队做分层评测；工艺与安全负责人授权上线。 ## 来源账本 - [Generative AI in manufacturing](https://www.bosch.com/stories/ai-image-recognition-production/) - 发布方：Bosch - 披露性质：企业项目团队披露 - 原记录查阅日期：2026-09-23 ## 字段边界 - business_problem：企业技术案例披露 - solution：企业项目团队披露与中文结构化整理 - architecture：企业公开流程与组件披露 - fde_actions：依据公开项目过程归纳 - result：企业预期与项目团队披露 ## 待核对事项 - 6个月和六位数欧元为Bosch工厂预期，不写成已审计实现收益。 - 公开文章未给训练/测试集拆分、误报率和样本外评测。 - 六位数欧元为预期生产率价值，不是已实现利润。 ## 完整原始结构化记录 ```json { "id": "enterprise-bosch-visual-inspection-001", "technical_reference": true, "source": "企业原始材料", "company": "Bosch", "industry": "汽车零部件制造", "industry_group": "制造与工业", "scenario": "生成式合成缺陷数据与定子焊点视觉质检", "fde": "企业部署案例", "fde_relation": "生产质量流程改造", "problem": "自动光学质检需要覆盖多种缺陷图像，但Bosch制造质量较高，新产线很难自然积累足够坏件；等待真实缺陷会拖慢模型和产线投产，故意破坏零件又成本高且无法覆盖全部变体。", "solution": "Bosch研究团队用旧产品和每种缺陷仅两位数规模的真实图像做Domain Transfer，生成约1.5万张新产品合成缺陷图；2D与3D相机从12个位置拍摄定子焊点，视觉模型在实图与合成图上训练后快速判定并让可修复件自动回流，同时由图像专家持续修正误报规则和重训模型。", "human": "视觉模型完成高速初检与回流控制；图像处理工程师检查误报，例如判断弱焊是否仍可接受，并通过人工重训调整“合格/缺陷”边界。不可返修的缺陷仍按制造质量流程处置。", "result": "Bosch项目团队预计项目周期可比传统方法缩短6个月，并带来每年六位数欧元的生产率收益；这是扩展阶段的预期价值，不是已实现利润或经审计收益。来源未给出完整成本、实际收益周期和净ROI。", "maturity": "工厂试点/跨厂复制", "maturity_stage": "已上线", "url": "https://www.bosch.com/stories/ai-image-recognition-production/", "architecture": [ "旧产品和少量真实缺陷图", "Domain Transfer生成新产品合成缺陷图", "真实与合成数据联合训练视觉检测模型", "12个位置的2D/3D相机采集定子焊点", "在线判定并让可修复件自动返回生产流程", "专家复核误报、调整规则并人工重训模型" ], "components": [ "生成式视觉模型", "合成数据", "Domain Transfer", "2D/3D工业相机", "自动光学检测", "返修回流控制", "专家重训" ], "fde_actions": [ "先定义六类焊接缺陷及可返修边界", "盘点可复用旧产品图像和少量新样本", "以合成数据补齐长尾缺陷而非等待坏件", "把检测输出直接接入返修流程", "由现场专家持续校准误报与合格边界" ], "reusable": [ "高质量制造现场可用合成数据解决坏样本稀缺", "合成数据必须与真实数据联合验证", "模型判定需要映射到返修和报废动作", "现场专家应持续维护视觉质量边界" ], "evidence": "Bosch官方技术故事披露数据量、成像方式、训练与返修流程及预期周期和收益；收益为工厂预期，未见实际年度财务核验。", "case_summary": "Bosch案例把生成式AI用于“造训练数据”而不是直接生成质检结论，并把相机检测、自动返修和专家误报校准连成完整生产闭环。", "evidence_level": "A", "evidence_label": "A级｜企业技术案例直接来源", "source_record": { "title": "Generative AI in manufacturing", "publisher": "Bosch", "url": "https://www.bosch.com/stories/ai-image-recognition-production/", "source_type": "企业技术案例", "directness": "案例级直接来源", "claim_origin": "企业项目团队披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "企业技术案例披露", "solution": "企业项目团队披露与中文结构化整理", "architecture": "企业公开流程与组件披露", "fde_actions": "依据公开项目过程归纳", "result": "企业预期与项目团队披露" }, "verification_notes": [ "6个月和六位数欧元为Bosch工厂预期，不写成已审计实现收益。", "公开文章未给训练/测试集拆分、误报率和样本外评测。", "六位数欧元为预期生产率价值，不是已实现利润。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # BMW Group｜生产设备维护知识助手 Factory Genius - ID：enterprise-bmw-factory-genius-001 - 行业：制造与工业 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（11/12） - 证据：A级｜企业项目直接来源 - 部署：全球首期推广 - 独立核验：未记录 ## 业务问题 汽车工厂设备一旦停机，每分钟都会影响生产；维修人员需要在设备手册、质量数据、故障报告、规划文件和每天更新的交接班日志之间搜索，不同工厂还各自开发了相似方案，知识难以跨地点复用。 ## 解决方案 BMW在Dingolfing车身车间先行试点，用LLM做上下文检索，从设备资料和内部报告中返回带来源链接的答案与维修摘要，并加入多语言翻译；总部把Dingolfing、Spartanburg和Rosslyn等工厂的方案与需求整合成“best of”应用，通过内部云平台向全球工厂提供。 ## 技术工作流 > 依据公开数据源和功能整理 1. 设备手册、质量数据、内部故障报告和规划文件 2. 每日交接班日志持续更新知识 3. LLM理解维修问题与语言上下文 4. 上下文检索返回匹配内容和来源链接 5. 摘要、对话与多语言翻译界面 6. 维修人员现场确认并由内部云平台跨厂复制 组件：大语言模型、企业知识检索、来源链接、设备维护数据、多语言翻译、内部云平台、人工现场处置 ## 人机责任 助手在几秒内给出相关资料、来源和候选处理方法；维修人员结合现场设备状态确认故障原因并执行处置，工厂团队持续补充每日交接班知识，总部AI团队维护通用平台。 ## FDE 动作 > 依据公开试点与整合路径归纳 - 从停机诊断的资料查找瓶颈切入 - 先在单一车身车间用真实故障知识试点 - 让答案保留原始资料链接 - 汇总多工厂并行方案形成公司级最佳版本 - 将文档接入方法抽象为可复用助手能力 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Factory Genius已从Dingolfing试点整合为可在BMW内部平台全球使用的首期应用，并能很快提出故障解决线索；官方未披露平均修复时间、停机减少或财务收益。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 工厂知识助手必须给出处而不是只给摘要 - 交接班日志是维护知识保持新鲜的重要增量源 - 多地并行试点后应收敛为共享底座 - 维修建议不能替代人员对现场设备的确认 ## 现场决策与研究 ### 为什么这样做 将多个工厂已有维护助手需求整合成共享应用，持续纳入交接班信息。 ### 阻力与证据边界 跨厂设备、语言和文档版本不同；提供候选资料不等于自动完成维修。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 从一类设备试点，记录找资料耗时、答案出处及维修人员确认，不虚构停机收益。 研究依据： - [“Just ask Factory Genius!”: How AI helps maintain manufacturing equipment](https://www.press.bmwgroup.com/latin-america-caribbean/article/detail/T0451289EN/%E2%80%9Cjust-ask-factory-genius-%E2%80%9D:-how-ai-helps-maintain-manufacturing-equipment?language=en) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [“Just ask Factory Genius!”: How AI helps maintain manufacturing equipment](https://www.press.bmwgroup.com/latin-america-caribbean/article/detail/T0451289EN/%E2%80%9Cjust-ask-factory-genius-%E2%80%9D:-how-ai-helps-maintain-manufacturing-equipment?language=en) - 发布方：BMW Group - 披露性质：企业项目团队披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：企业项目材料披露 - solution：企业项目材料披露与中文结构化整理 - architecture：依据公开数据源和功能整理 - fde_actions：依据公开试点与整合路径归纳 - result：企业项目材料披露 ## 待核对事项 - “数秒”描述的是提供线索速度，不等于平均故障修复时间。 - 首期全球可用不等于所有工厂或设备已完成采用。 ## 完整原始结构化记录 ```json { "id": "enterprise-bmw-factory-genius-001", "technical_reference": true, "source": "企业原始材料", "company": "BMW Group", "industry": "汽车制造", "industry_group": "制造与工业", "scenario": "生产设备维护知识助手 Factory Genius", "fde": "企业部署案例", "fde_relation": "内部生产维护改造", "problem": "汽车工厂设备一旦停机，每分钟都会影响生产；维修人员需要在设备手册、质量数据、故障报告、规划文件和每天更新的交接班日志之间搜索，不同工厂还各自开发了相似方案，知识难以跨地点复用。", "solution": "BMW在Dingolfing车身车间先行试点，用LLM做上下文检索，从设备资料和内部报告中返回带来源链接的答案与维修摘要，并加入多语言翻译；总部把Dingolfing、Spartanburg和Rosslyn等工厂的方案与需求整合成“best of”应用，通过内部云平台向全球工厂提供。", "human": "助手在几秒内给出相关资料、来源和候选处理方法；维修人员结合现场设备状态确认故障原因并执行处置，工厂团队持续补充每日交接班知识，总部AI团队维护通用平台。", "result": "Factory Genius已从Dingolfing试点整合为可在BMW内部平台全球使用的首期应用，并能很快提出故障解决线索；官方未披露平均修复时间、停机减少或财务收益。", "maturity": "全球首期推广", "maturity_stage": "已上线", "url": "https://www.press.bmwgroup.com/latin-america-caribbean/article/detail/T0451289EN/%E2%80%9Cjust-ask-factory-genius-%E2%80%9D:-how-ai-helps-maintain-manufacturing-equipment?language=en", "architecture": [ "设备手册、质量数据、内部故障报告和规划文件", "每日交接班日志持续更新知识", "LLM理解维修问题与语言上下文", "上下文检索返回匹配内容和来源链接", "摘要、对话与多语言翻译界面", "维修人员现场确认并由内部云平台跨厂复制" ], "components": [ "大语言模型", "企业知识检索", "来源链接", "设备维护数据", "多语言翻译", "内部云平台", "人工现场处置" ], "fde_actions": [ "从停机诊断的资料查找瓶颈切入", "先在单一车身车间用真实故障知识试点", "让答案保留原始资料链接", "汇总多工厂并行方案形成公司级最佳版本", "将文档接入方法抽象为可复用助手能力" ], "reusable": [ "工厂知识助手必须给出处而不是只给摘要", "交接班日志是维护知识保持新鲜的重要增量源", "多地并行试点后应收敛为共享底座", "维修建议不能替代人员对现场设备的确认" ], "evidence": "BMW官方稿件披露数据源、检索与摘要方式、试点地点及全球整合路径；没有公开故障修复指标。", "case_summary": "BMW Factory Genius的价值不只在RAG，而在于把三个工厂的并行实践收敛为公司级平台，并保留来源链接、每日知识更新和维修人员责任。", "evidence_level": "A", "evidence_label": "A级｜企业项目直接来源", "source_record": { "title": "“Just ask Factory Genius!”: How AI helps maintain manufacturing equipment", "publisher": "BMW Group", "url": "https://www.press.bmwgroup.com/latin-america-caribbean/article/detail/T0451289EN/%E2%80%9Cjust-ask-factory-genius-%E2%80%9D:-how-ai-helps-maintain-manufacturing-equipment?language=en", "source_type": "企业项目新闻稿", "directness": "案例级直接来源", "claim_origin": "企业项目团队披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业项目材料披露", "solution": "企业项目材料披露与中文结构化整理", "architecture": "依据公开数据源和功能整理", "fde_actions": "依据公开试点与整合路径归纳", "result": "企业项目材料披露" }, "verification_notes": [ "“数秒”描述的是提供线索速度，不等于平均故障修复时间。", "首期全球可用不等于所有工厂或设备已完成采用。" ], "additional_sources": [], "detail_score": 11, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "量化结果" ] } ``` --- # McKinsey & Company｜企业知识与Agent平台 Lilli - ID：enterprise-mckinsey-lilli-001 - 行业：专业服务 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业项目直接来源 - 部署：全公司规模化/持续重构 - 独立核验：未记录 ## 业务问题 麦肯锡近百年知识分散在40多个内部来源中，顾问查找、综合和转化知识耗时；首版平台又依赖单一模型提供商，随着用例和调用增长出现成本、速度与准确率无法同时优化的扩展瓶颈。 ## 解决方案 四人团队先用一周完成概念验证，五周开发MVP并交给200名Alpha用户，再分三个月渐进式全员推广；Lilli以编排层组合大型和小型模型、内部与外部知识及权限控制，后来重构为LLM无关的可组合开源底座，并以Alpha/Beta、用户反馈和质量指标逐项发布能力。 ## 技术工作流 > 企业公开架构与重构决策披露 1. 40多个内部知识源及外部知识 2. 访问控制、数据安全和内容治理 3. 大模型与小型专家模型组合 4. 意图识别、知识编排与答案生成层 5. LLM无关的可组合开源平台 6. Alpha/Beta、使用分析、输出质量和成本评测 组件：Lilli平台、多模型编排、企业知识源、权限与安全控制、Agent框架、用户分析与质量评测、LLM无关架构 ## 人机责任 顾问用Lilli检索、综合和起草，但仍判断内容是否适合客户情境并承担交付责任；产品团队进行用户观察、用例优先级、Alpha/Beta测试和风险控制，知识贡献者持续改善可用资料。 ## FDE 动作 > 依据公开产品时间线归纳 - 用一周PoC验证领导投资意愿 - 通过访谈和工作坊按价值与可行性排用例 - 让200名Alpha用户先验证MVP - 根据真实单位成本把单一供应商架构重构为多模型 - 所有新能力经过Alpha/Beta及质量指标再全员发布 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** 麦肯锡披露平台上线后72%的公司人员活跃使用，每月回答50多万次提示，员工报告知识搜索与综合最多节省30%时间；团队从4人扩展到150多人。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业知识平台应把用例问题而不是模型作为产品路线中心 - 单一模型架构在规模化后可能造成成本与性能瓶颈 - 渐进发布可把真实使用反馈带入架构决策 - 知识工作节省时间仍需专业人员判断和客户责任 ## 现场决策与研究 ### 为什么这样做 知识平台扩张后要重构模型与成本路由，首版架构不是长期不变的终点。 ### 阻力与证据边界 活跃使用与员工自报省时不等于项目盈利；团队扩张意味着运营投入也在增加。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 按任务跟踪质量、引用完整性、延迟、单次有效答案成本和平台维护成本。 研究依据： - [Meet Lilli: McKinsey’s custom-built gen AI platform](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/what-mckinsey-learned-while-creating-its-generative-ai-platform) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：知识与经验助手 适用条件：同类问题高频出现，已有可授权的资料和愿意维护内容的专家。 不适用：知识没有责任人、资料长期失效，或业务要求无依据也必须给确定答案。 ### 输入条件 - 文档、工单、历史问答与专家确认的知识条目 - 文档版本、适用对象、权限与过期时间 - 真实问题、标准答案与不可回答样本 ### 实施步骤 - 跟岗记录问题发生的时刻和现有求助链路，测量查找与等待时间。 - 按业务问题清理资料，先解决文档解析、版本和权限，再搭建检索。 - 让回答带出处和适用条件，无依据时明确说明并转交原支持渠道。 - 嵌入原工作入口，记录问题是否解决、专家修正与资料缺口。 ### 验收指标 - 检索命中率：有标准依据的问题中，相关证据被召回的比例。 - 有效回答率：人工判定可用于当前任务的回答 / 受评回答；同时报告无答案样本。 - 净节省时间：原查找与等待时间减去新检索、复核及纠错时间。 ### 异常处理 回答越权或引用过期材料时，立即停用受影响资料集；回退人工，记录权限与版本缺陷。 ### 责任分工 业务专家维护知识；数据工程负责权限与版本；产品负责人负责入口和反馈；业务主管确认验收。 ## 来源账本 - [Meet Lilli: McKinsey’s custom-built gen AI platform](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/what-mckinsey-learned-while-creating-its-generative-ai-platform) - 发布方：McKinsey & Company - 披露性质：企业产品负责人披露 - 原记录查阅日期：2026-09-19 - [Building Lilli at the speed of change](https://ceros.mckinsey.com/building-lilli-at-the-speed-of-change-desktop) - [Plan for midstream adjustments](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/plan-for-midstream-adjustments) - [Rewiring the way McKinsey works with Lilli](https://www.mckinsey.com/capabilities/tech-and-ai/how-we-help-clients/rewiring-the-way-mckinsey-works-with-lilli) ## 字段边界 - business_problem：企业复盘材料披露 - solution：多篇企业自述材料交叉整理 - architecture：企业公开架构与重构决策披露 - fde_actions：依据公开产品时间线归纳 - result：企业内部统计披露 ## 待核对事项 - 72%、50万次和最多30%来自麦肯锡自述，不代表所有员工或所有任务平均效果。 - 平台并非单一RAG实例，公开材料明确描述为多模型知识编排层。 ## 完整原始结构化记录 ```json { "id": "enterprise-mckinsey-lilli-001", "technical_reference": true, "source": "企业原始材料", "company": "McKinsey & Company", "industry": "管理咨询", "industry_group": "专业服务", "scenario": "企业知识与Agent平台 Lilli", "fde": "企业部署案例", "fde_relation": "内部知识工作流改造", "problem": "麦肯锡近百年知识分散在40多个内部来源中，顾问查找、综合和转化知识耗时；首版平台又依赖单一模型提供商，随着用例和调用增长出现成本、速度与准确率无法同时优化的扩展瓶颈。", "solution": "四人团队先用一周完成概念验证，五周开发MVP并交给200名Alpha用户，再分三个月渐进式全员推广；Lilli以编排层组合大型和小型模型、内部与外部知识及权限控制，后来重构为LLM无关的可组合开源底座，并以Alpha/Beta、用户反馈和质量指标逐项发布能力。", "human": "顾问用Lilli检索、综合和起草，但仍判断内容是否适合客户情境并承担交付责任；产品团队进行用户观察、用例优先级、Alpha/Beta测试和风险控制，知识贡献者持续改善可用资料。", "result": "麦肯锡披露平台上线后72%的公司人员活跃使用，每月回答50多万次提示，员工报告知识搜索与综合最多节省30%时间；团队从4人扩展到150多人。", "maturity": "全公司规模化/持续重构", "maturity_stage": "规模化", "url": "https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/what-mckinsey-learned-while-creating-its-generative-ai-platform", "architecture": [ "40多个内部知识源及外部知识", "访问控制、数据安全和内容治理", "大模型与小型专家模型组合", "意图识别、知识编排与答案生成层", "LLM无关的可组合开源平台", "Alpha/Beta、使用分析、输出质量和成本评测" ], "components": [ "Lilli平台", "多模型编排", "企业知识源", "权限与安全控制", "Agent框架", "用户分析与质量评测", "LLM无关架构" ], "fde_actions": [ "用一周PoC验证领导投资意愿", "通过访谈和工作坊按价值与可行性排用例", "让200名Alpha用户先验证MVP", "根据真实单位成本把单一供应商架构重构为多模型", "所有新能力经过Alpha/Beta及质量指标再全员发布" ], "reusable": [ "企业知识平台应把用例问题而不是模型作为产品路线中心", "单一模型架构在规模化后可能造成成本与性能瓶颈", "渐进发布可把真实使用反馈带入架构决策", "知识工作节省时间仍需专业人员判断和客户责任" ], "evidence": "麦肯锡多篇自述材料公开团队规模、时间线、平台架构、采用率和时间节省；指标为企业内部统计，未见独立审计。", "case_summary": "Lilli案例同时公开了从四人PoC到全员平台的产品路径，以及因真实成本压力从单一供应商转向多模型、LLM无关架构的二次重构。", "evidence_level": "A", "evidence_label": "A级｜企业项目直接来源", "source_record": { "title": "Meet Lilli: McKinsey’s custom-built gen AI platform", "publisher": "McKinsey & Company", "url": "https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/what-mckinsey-learned-while-creating-its-generative-ai-platform", "source_type": "企业平台复盘", "directness": "案例级直接来源", "claim_origin": "企业产品负责人披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业复盘材料披露", "solution": "多篇企业自述材料交叉整理", "architecture": "企业公开架构与重构决策披露", "fde_actions": "依据公开产品时间线归纳", "result": "企业内部统计披露" }, "verification_notes": [ "72%、50万次和最多30%来自麦肯锡自述，不代表所有员工或所有任务平均效果。", "平台并非单一RAG实例，公开材料明确描述为多模型知识编排层。" ], "additional_sources": [ { "title": "Building Lilli at the speed of change", "url": "https://ceros.mckinsey.com/building-lilli-at-the-speed-of-change-desktop" }, { "title": "Plan for midstream adjustments", "url": "https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/plan-for-midstream-adjustments" }, { "title": "Rewiring the way McKinsey works with Lilli", "url": "https://www.mckinsey.com/capabilities/tech-and-ai/how-we-help-clients/rewiring-the-way-mckinsey-works-with-lilli" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Block｜Goose通用Agent与G2持久化工作流应用 - ID：enterprise-block-goose-g2-001 - 行业：金融与保险 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业投资者材料直接来源 - 部署：全公司规模化 - 独立核验：未记录 ## 业务问题 Block希望把AI从工程代码辅助扩展到HR、客服、法律和运营，但通用聊天模型无法安全读取实时专有数据或执行动作，非技术员工为每个自动化需求等待工程团队开发也难以规模化。 ## 解决方案 Block自研并开源本地运行、模型无关的Goose通用Agent，以MCP连接约150项内部服务和专有实时数据，允许员工读取数据并执行动作；同时建设G2文本到持久化应用平台，让非技术人员以“Tile”创建可异步持续运行的专用工作流，并把同一Agent底座复用于客户产品。 ## 技术工作流 > 企业公开平台与开源组件披露 1. 员工任务、专有数据与实时业务系统 2. 本地运行且模型无关的Goose Agent 3. MCP连接约150项内部服务并读取或执行动作 4. G2把自然语言转为持久化异步应用Tile 5. 工具权限、沙箱与员工确认控制动作 6. 内部反馈沉淀为共享Agent底座并复用到客户产品 组件：Goose、G2、MCP、本地Agent运行时、模型路由、工具权限与沙箱、持久化异步工作流 ## 人机责任 员工选择任务、连接工具并决定让Goose只起草还是完成动作；G2让业务人员自己建立持续工作流。企业仍通过工具权限、沙箱、岗位能力要求和业务责任控制高风险操作。 ## FDE 动作 > 依据公开实施结构归纳 - 让Agent连接实时专有数据而不只回答通用问题 - 用MCP统一内部工具读写接口 - 把工程Agent抽象为全职能通用底座 - 为非技术员工提供文本到持久化应用入口 - 同步跟踪人工工时、客服覆盖和工程速度 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Block投资者材料称，AI已覆盖75%以上员工并使人工工时减少25%；AI处理65%的Cash App客服案例，90%以上代码提交部分或全部由AI支持，工程师每周代码变更中位数提升30%。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 通用企业Agent需要工具层而不仅是模型层 - 本地和模型无关设计可保留选择权与数据控制 - 非技术采用需要把一次性对话升级为持久工作流 - 采用率、自动化比例和质量门槛必须一起治理 ## 现场决策与研究 ### 为什么这样做 用共享Agent能力连接内部服务，并通过G2让业务人员形成持久化任务。 ### 阻力与证据边界 公司级采用、工程代码变化与客服处理量来自不同工作流，不能相加形成统一ROI。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 先白名单接入少量读工具；写动作分权审批，验证幂等、撤销、失败恢复与审计。 研究依据： - [Block Investor Day 2025 – Full Transcript](https://block.xyz/documents/block-investor-day-2025-full-transcript.pdf) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [Block Investor Day 2025 – Full Transcript](https://block.xyz/documents/block-investor-day-2025-full-transcript.pdf) - 发布方：Block - 披露性质：企业管理层披露 - 原记录查阅日期：2026-09-19 - [Block Open Source – Goose](https://opensource.block.xyz/) - [Goose documentation](https://block.github.io/goose/) ## 字段边界 - business_problem：企业管理层材料披露 - solution：企业材料与开源技术文档交叉整理 - architecture：企业公开平台与开源组件披露 - fde_actions：依据公开实施结构归纳 - result：企业投资者材料披露 ## 待核对事项 - 25%工时减少是AI工具组合结果，不能全部归因于Goose或G2。 - 90%以上代码提交是“部分或全部获得AI支持”，不等同于AI独立完成。 ## 完整原始结构化记录 ```json { "id": "enterprise-block-goose-g2-001", "technical_reference": true, "source": "企业原始材料", "company": "Block", "industry": "金融科技", "industry_group": "金融与保险", "scenario": "Goose通用Agent与G2持久化工作流应用", "fde": "企业部署案例", "fde_relation": "全公司Agent化改造", "problem": "Block希望把AI从工程代码辅助扩展到HR、客服、法律和运营，但通用聊天模型无法安全读取实时专有数据或执行动作，非技术员工为每个自动化需求等待工程团队开发也难以规模化。", "solution": "Block自研并开源本地运行、模型无关的Goose通用Agent，以MCP连接约150项内部服务和专有实时数据，允许员工读取数据并执行动作；同时建设G2文本到持久化应用平台，让非技术人员以“Tile”创建可异步持续运行的专用工作流，并把同一Agent底座复用于客户产品。", "human": "员工选择任务、连接工具并决定让Goose只起草还是完成动作；G2让业务人员自己建立持续工作流。企业仍通过工具权限、沙箱、岗位能力要求和业务责任控制高风险操作。", "result": "Block投资者材料称，AI已覆盖75%以上员工并使人工工时减少25%；AI处理65%的Cash App客服案例，90%以上代码提交部分或全部由AI支持，工程师每周代码变更中位数提升30%。", "maturity": "全公司规模化", "maturity_stage": "规模化", "url": "https://block.xyz/documents/block-investor-day-2025-full-transcript.pdf", "architecture": [ "员工任务、专有数据与实时业务系统", "本地运行且模型无关的Goose Agent", "MCP连接约150项内部服务并读取或执行动作", "G2把自然语言转为持久化异步应用Tile", "工具权限、沙箱与员工确认控制动作", "内部反馈沉淀为共享Agent底座并复用到客户产品" ], "components": [ "Goose", "G2", "MCP", "本地Agent运行时", "模型路由", "工具权限与沙箱", "持久化异步工作流" ], "fde_actions": [ "让Agent连接实时专有数据而不只回答通用问题", "用MCP统一内部工具读写接口", "把工程Agent抽象为全职能通用底座", "为非技术员工提供文本到持久化应用入口", "同步跟踪人工工时、客服覆盖和工程速度" ], "reusable": [ "通用企业Agent需要工具层而不仅是模型层", "本地和模型无关设计可保留选择权与数据控制", "非技术采用需要把一次性对话升级为持久工作流", "采用率、自动化比例和质量门槛必须一起治理" ], "evidence": "Block投资者日逐字稿公开Goose、G2、MCP连接规模与业务指标；开源站点补充本地运行、模型无关和工具权限信息，指标未独立审计。", "case_summary": "Block用Goose解决“Agent如何访问数据和行动”，再用G2解决“非技术员工如何创建持续应用”，形成从底层连接到组织采用的完整Agent化路径。", "evidence_level": "A", "evidence_label": "A级｜企业投资者材料直接来源", "source_record": { "title": "Block Investor Day 2025 – Full Transcript", "publisher": "Block", "url": "https://block.xyz/documents/block-investor-day-2025-full-transcript.pdf", "source_type": "企业投资者材料", "directness": "案例级直接来源", "claim_origin": "企业管理层披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业管理层材料披露", "solution": "企业材料与开源技术文档交叉整理", "architecture": "企业公开平台与开源组件披露", "fde_actions": "依据公开实施结构归纳", "result": "企业投资者材料披露" }, "verification_notes": [ "25%工时减少是AI工具组合结果，不能全部归因于Goose或G2。", "90%以上代码提交是“部分或全部获得AI支持”，不等同于AI独立完成。" ], "additional_sources": [ { "title": "Block Open Source – Goose", "url": "https://opensource.block.xyz/" }, { "title": "Goose documentation", "url": "https://block.github.io/goose/" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # Telstra｜数据底座、员工知识助手与网络自愈的企业AI组合 - ID：enterprise-telstra-ai-001 - 行业：科技与软件 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业转型材料直接来源 - 部署：数百用例规模化 - 独立核验：未记录 ## 业务问题 Telstra要同时改善一线客服查知识、客户自助服务和网络故障，但历史上约80个数据平台造成数据与接口割裂；如果没有统一底座、岗位培训和责任控制，单个AI试点很难扩展为数百个业务用例。 ## 解决方案 Telstra把数据平台从约80个收敛到约20个，迁移到云和API-first架构；在此之上用Azure OpenAI与Azure AI Search构建基于可信企业知识的AskTelstra，为一线人员检索答案，同时部署客户生成式AI助手、One Sentence Summary和嵌入网络运营的SmartFix，并以AI Academy推动岗位采用。 ## 技术工作流 > 公开底座与具体技术组件整理 1. 从约80个收敛到约20个数据平台 2. 云端API-first架构与可复用AI能力 3. Azure AI Search检索可信企业知识 4. Azure OpenAI生成AskTelstra答案和会话摘要 5. 客户助手与SmartFix连接渠道和网络运营 6. 人工升级、责任AI控制、采用率与业务指标监测 组件：云数据平台、API-first架构、Azure OpenAI、Azure AI Search、AskTelstra、One Sentence Summary、SmartFix、责任AI框架 ## 人机责任 AskTelstra和摘要工具为一线员工提供答案与上下文，员工负责客户沟通和例外处理；网络自动修复处理可标准化问题，异常进入运维流程。责任AI、安全框架和20,000多人培训共同约束扩展。 ## FDE 动作 > 依据公开改造路径归纳 - 先收敛数据平台并统一API接入方式 - 从客服知识查找和网络主动修复两条高频链路切入 - 让生成答案只依据可信企业知识 - 为员工铺设AI Academy和岗位使用支持 - 分别跟踪通话时长、自助解决和预防来电 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** Telstra披露AskTelstra服务8,000多名一线员工，平均通话时间缩短1分多钟；客户助手无需升级即可回答的查询量接近原来的3倍；SmartFix在FY25执行250万次主动动作并预防近100万次支持来电。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 企业AI规模化通常依赖先行的数据与接口简化 - 同一AI战略应按工作流分别设业务指标 - 员工助手要以受控企业知识为依据 - 自动修复和对话助手需要不同的人机升级路径 ## 现场决策与研究 ### 为什么这样做 多年数据平台整合与员工训练先行，再扩展知识助手、客户服务和网络动作。 ### 阻力与证据边界 不同系统的来电时长、升级次数和主动动作数不能混为单一AI效果。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 分别设立知识质量、通话结果和网络变更的验收与回滚责任。 研究依据： - [How Telstra is reinventing itself with AI](https://www.telstra.com.au/exchange/telstra-s-ai-transformation--strategy--partnerships-and-real-wor) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：平台与组织采用 适用条件：多个团队已遇到相同的认证、数据、评测和运行问题，并有平台维护者。 不适用：没有真实用例就建设大平台，或只采购账号、统计培训人数就称为转型。 ### 输入条件 - 已验证用例及其共同基础设施需求 - 角色、权限、成本归属和服务责任 - 团队交付、活跃使用与有效任务基线 ### 实施步骤 - 从业务用例抽出重复工作，区分行业差异与真正可共享的能力。 - 统一认证、模型接入、工具契约、追踪和评测，保留业务团队的迭代自由。 - 把培训、答疑与内部骨干纳入上线计划，让业务团队能接手维护。 - 逐步扩展到其他团队，检查使用留存、真实结果与平台维护成本。 ### 验收指标 - 新用例从创建到生产的时间，包含权限和数据准备。 - 岗位级有效使用率、持续留存与已完成业务任务量。 - 单任务成本和共享平台运维负担，不能只报Token或账号数量。 ### 异常处理 平台复杂度超过业务价值时收缩能力；对不稳定组件独立降级，保留原业务系统。 ### 责任分工 平台团队维护共同能力；业务Owner负责结果；内部骨干支持采用；管理者保证长期投入。 ## 来源账本 - [How Telstra is reinventing itself with AI](https://www.telstra.com.au/exchange/telstra-s-ai-transformation--strategy--partnerships-and-real-wor) - 发布方：Telstra - 披露性质：企业管理层披露 - 原记录查阅日期：2026-09-19 - [Telstra scales up AI adoption](https://www.telstra.com.au/aboutus/media/media-releases/telstra-scales-up-ai-adoption) ## 字段边界 - business_problem：企业转型材料披露 - solution：企业多篇直接材料交叉整理 - architecture：公开底座与具体技术组件整理 - fde_actions：依据公开改造路径归纳 - result：企业管理层披露 ## 待核对事项 - 通话缩短、查询解决和预防来电是不同工作流指标，不能相互替代。 - SmartFix并非生成式AI单一功能，而是Telstra整体AI与自动化组合的一部分。 ## 完整原始结构化记录 ```json { "id": "enterprise-telstra-ai-001", "technical_reference": true, "source": "企业原始材料", "company": "Telstra", "industry": "电信", "industry_group": "科技与软件", "scenario": "数据底座、员工知识助手与网络自愈的企业AI组合", "fde": "企业部署案例", "fde_relation": "企业级AI改造", "problem": "Telstra要同时改善一线客服查知识、客户自助服务和网络故障，但历史上约80个数据平台造成数据与接口割裂；如果没有统一底座、岗位培训和责任控制，单个AI试点很难扩展为数百个业务用例。", "solution": "Telstra把数据平台从约80个收敛到约20个，迁移到云和API-first架构；在此之上用Azure OpenAI与Azure AI Search构建基于可信企业知识的AskTelstra，为一线人员检索答案，同时部署客户生成式AI助手、One Sentence Summary和嵌入网络运营的SmartFix，并以AI Academy推动岗位采用。", "human": "AskTelstra和摘要工具为一线员工提供答案与上下文，员工负责客户沟通和例外处理；网络自动修复处理可标准化问题，异常进入运维流程。责任AI、安全框架和20,000多人培训共同约束扩展。", "result": "Telstra披露AskTelstra服务8,000多名一线员工，平均通话时间缩短1分多钟；客户助手无需升级即可回答的查询量接近原来的3倍；SmartFix在FY25执行250万次主动动作并预防近100万次支持来电。", "maturity": "数百用例规模化", "maturity_stage": "规模化", "url": "https://www.telstra.com.au/exchange/telstra-s-ai-transformation--strategy--partnerships-and-real-wor", "architecture": [ "从约80个收敛到约20个数据平台", "云端API-first架构与可复用AI能力", "Azure AI Search检索可信企业知识", "Azure OpenAI生成AskTelstra答案和会话摘要", "客户助手与SmartFix连接渠道和网络运营", "人工升级、责任AI控制、采用率与业务指标监测" ], "components": [ "云数据平台", "API-first架构", "Azure OpenAI", "Azure AI Search", "AskTelstra", "One Sentence Summary", "SmartFix", "责任AI框架" ], "fde_actions": [ "先收敛数据平台并统一API接入方式", "从客服知识查找和网络主动修复两条高频链路切入", "让生成答案只依据可信企业知识", "为员工铺设AI Academy和岗位使用支持", "分别跟踪通话时长、自助解决和预防来电" ], "reusable": [ "企业AI规模化通常依赖先行的数据与接口简化", "同一AI战略应按工作流分别设业务指标", "员工助手要以受控企业知识为依据", "自动修复和对话助手需要不同的人机升级路径" ], "evidence": "Telstra官方文章和新闻稿披露底座、技术组件、采用规模及多项结果；为企业自述，未见独立审计或对照组。", "case_summary": "Telstra案例把“先清理80个数据平台”与后续知识助手、客户自助和网络自愈联系起来，说明企业AI落地既是数据工程，也是岗位与运营改造。", "evidence_level": "A", "evidence_label": "A级｜企业转型材料直接来源", "source_record": { "title": "How Telstra is reinventing itself with AI", "publisher": "Telstra", "url": "https://www.telstra.com.au/exchange/telstra-s-ai-transformation--strategy--partnerships-and-real-wor", "source_type": "企业转型复盘", "directness": "案例级直接来源", "claim_origin": "企业管理层披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业转型材料披露", "solution": "企业多篇直接材料交叉整理", "architecture": "公开底座与具体技术组件整理", "fde_actions": "依据公开改造路径归纳", "result": "企业管理层披露" }, "verification_notes": [ "通话缩短、查询解决和预防来电是不同工作流指标，不能相互替代。", "SmartFix并非生成式AI单一功能，而是Telstra整体AI与自动化组合的一部分。" ], "additional_sources": [ { "title": "Telstra scales up AI adoption", "url": "https://www.telstra.com.au/aboutus/media/media-releases/telstra-scales-up-ai-adoption" } ], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ``` --- # DoorDash｜客服LLM的离线仿真与评测飞轮 - ID：enterprise-doordash-eval-flywheel-001 - 行业：科技与软件 - 来源：企业原始材料 - 详细度：深度案例｜关键链路较完整（12/12） - 证据：A级｜企业工程博客直接来源 - 部署：生产质量平台 - 独立核验：未记录 ## 业务问题 DoorDash把确定性客服决策树升级为LLM对话后，提示改动可能改善一个场景却破坏另一个场景；直接上生产会把客户当测试样本，人工回放又慢、覆盖有限，欺诈、高额退款和极端延误等边缘问题尤其难验证。 ## 解决方案 DoorDash建设离线仿真与评测双系统：从历史生产会话提取行为场景，LLM扮演会追问和反驳的客户，Mock层混合生产与测试数据并模拟配送状态、退款和订单工具返回；校准后的LLM-as-a-judge对数百轮对话做幻觉、语气和分类评测，通过回归门槛后再A/B上线并复用同一评测监控线上。 ## 技术工作流 > 企业工程博客逐层披露 1. 历史生产对话生成行为测试场景 2. LLM客户模拟器生成追问、反驳和升级行为 3. 混合生产与测试数据的Mock工具及后端响应 4. LLM客服在完整多轮环境中调用配送/退款/订单工具 5. 校准的LLM-as-a-judge与50多项质量评测 6. 回归门禁、A/B发布及同一评测的线上监控 组件：场景生成流水线、LLM用户模拟器、混合Mock数据、工具调用模拟、LLM-as-a-judge、回归测试、A/B实验、生产监控 ## 人机责任 领域专家先校准评测器与人工判断的一致性，工程和数据团队根据失败案例修改提示、上下文或工具；只有全部护栏稳定后才进入标准A/B测试，生产监控继续确认改进是否保持。 ## FDE 动作 > 依据公开研发闭环归纳 - 从历史会话抽取真实行为而非手写所有脚本 - 同时模拟用户和后端工具响应 - 用专家人工判断校准自动评测 - 把每个生产失败固化成新的回归评测 - 通过护栏后再A/B上线并核对离线线上相关性 ## 业务结果与盈利口径 **以运营指标为主，未形成净利润/ROI口径** DoorDash披露一次关键改造使仿真中的幻觉减少90%，且效果延续到生产；单轮迭代从数天缩短到数小时，系统可在5分钟内运行200多段多轮会话，评测集已超过50项。 > 当前整理的材料没有提供足以复算项目净利润或ROI的完整财务数据；不把节省工时、采用率、准确率或产能变化直接换算成利润。 ## 原有复用建议 - 非确定性Agent需要行为仿真而不只是单轮测试 - LLM评测器必须先与人类专家校准 - 测试数据要覆盖工具返回和业务状态 - 生产失败应转成永久回归项形成飞轮 ## 现场决策与研究 ### 为什么这样做 把客户追问和工具返回一起模拟，提示改动先离线回归再在线A/B。 ### 阻力与证据边界 评测器需与领域专家校准；仿真收益不能自动推广到所有客户场景，线上仍需监控。 ### 本案例优先验证 > 以下为编辑建议，非客户实施事实。 将生产失败转为可重放场景，保留版本、Mock工具、回归门槛与线上复发率。 研究依据： - [A Simulation and Evaluation Flywheel to Develop LLM Chatbots](https://careersatdoordash.com/blog/doordash-simulation-evaluation-flywheel-to-develop-llm-chatbots-at-scale/) ## 迁移与验收建议 > 本节为编辑建议，未声称原客户实施了这些步骤。 参考模式：Agent 与流程执行 适用条件：工具接口稳定、动作可分级、流程有明确终点，业务人员可处理异常。 不适用：既没有可靠接口，也无法在用户可见的业务系统中确认结果，却承诺无人化执行。 ### 输入条件 - 业务对象、允许动作与角色权限矩阵 - API输入输出、超时、限流、幂等与重试语义 - 正常流程、异常分支与人工处理队列 ### 实施步骤 - 先把流程画成明确的状态变化，分开读、草拟、审批和执行权限。 - 从只读或草拟开始，用确定性工具约束写入字段和业务规则。 - 让高影响动作由责任人确认；请求使用幂等键，结果写入审计日志。 - 失败时显示真实阶段与错误，提供重试或接管，完成后读取业务端状态。 ### 验收指标 - 业务完成率：真实完成并有回执的任务 / 进入流程的任务。 - 错误动作、重复执行和人工接管率按动作风险分层。 - 任务成本包括推理、工具调用、人工接管及失败恢复。 ### 异常处理 写入结果不确定时先查询业务状态，不盲目重试；动作不能撤销时启用补偿流程并通知负责人。 ### 责任分工 流程Owner负责结果；平台团队负责工具契约；安全负责人配置权限；一线人员负责接管。 ## 来源账本 - [A Simulation and Evaluation Flywheel to Develop LLM Chatbots](https://careersatdoordash.com/blog/doordash-simulation-evaluation-flywheel-to-develop-llm-chatbots-at-scale/) - 发布方：DoorDash Engineering - 披露性质：企业工程团队披露 - 原记录查阅日期：2026-09-19 ## 字段边界 - business_problem：企业工程博客披露 - solution：企业工程博客披露与中文结构化整理 - architecture：企业工程博客逐层披露 - fde_actions：依据公开研发闭环归纳 - result：企业工程团队披露 ## 待核对事项 - 幻觉减少90%先在仿真中测得，文章称趋势延续到生产，但未公开绝对基线。 - 5分钟200多段是测试吞吐，不等于线上客服吞吐。 ## 完整原始结构化记录 ```json { "id": "enterprise-doordash-eval-flywheel-001", "technical_reference": true, "source": "企业原始材料", "company": "DoorDash", "industry": "本地生活/配送平台", "industry_group": "科技与软件", "scenario": "客服LLM的离线仿真与评测飞轮", "fde": "企业部署案例", "fde_relation": "生产AI质量工程改造", "problem": "DoorDash把确定性客服决策树升级为LLM对话后，提示改动可能改善一个场景却破坏另一个场景；直接上生产会把客户当测试样本，人工回放又慢、覆盖有限，欺诈、高额退款和极端延误等边缘问题尤其难验证。", "solution": "DoorDash建设离线仿真与评测双系统：从历史生产会话提取行为场景，LLM扮演会追问和反驳的客户，Mock层混合生产与测试数据并模拟配送状态、退款和订单工具返回；校准后的LLM-as-a-judge对数百轮对话做幻觉、语气和分类评测，通过回归门槛后再A/B上线并复用同一评测监控线上。", "human": "领域专家先校准评测器与人工判断的一致性，工程和数据团队根据失败案例修改提示、上下文或工具；只有全部护栏稳定后才进入标准A/B测试，生产监控继续确认改进是否保持。", "result": "DoorDash披露一次关键改造使仿真中的幻觉减少90%，且效果延续到生产；单轮迭代从数天缩短到数小时，系统可在5分钟内运行200多段多轮会话，评测集已超过50项。", "maturity": "生产质量平台", "maturity_stage": "已上线", "url": "https://careersatdoordash.com/blog/doordash-simulation-evaluation-flywheel-to-develop-llm-chatbots-at-scale/", "architecture": [ "历史生产对话生成行为测试场景", "LLM客户模拟器生成追问、反驳和升级行为", "混合生产与测试数据的Mock工具及后端响应", "LLM客服在完整多轮环境中调用配送/退款/订单工具", "校准的LLM-as-a-judge与50多项质量评测", "回归门禁、A/B发布及同一评测的线上监控" ], "components": [ "场景生成流水线", "LLM用户模拟器", "混合Mock数据", "工具调用模拟", "LLM-as-a-judge", "回归测试", "A/B实验", "生产监控" ], "fde_actions": [ "从历史会话抽取真实行为而非手写所有脚本", "同时模拟用户和后端工具响应", "用专家人工判断校准自动评测", "把每个生产失败固化成新的回归评测", "通过护栏后再A/B上线并核对离线线上相关性" ], "reusable": [ "非确定性Agent需要行为仿真而不只是单轮测试", "LLM评测器必须先与人类专家校准", "测试数据要覆盖工具返回和业务状态", "生产失败应转成永久回归项形成飞轮" ], "evidence": "DoorDash工程团队公开四部分架构、上线门禁、评测项目和线上结果；具体样本与评测提示未完全公开，结果未独立审计。", "case_summary": "DoorDash案例最可复用的是把真实失败转为场景、仿真、评测、回归和A/B的持续飞轮，从而不用在真实客户流量中盲测LLM改动。", "evidence_level": "A", "evidence_label": "A级｜企业工程博客直接来源", "source_record": { "title": "A Simulation and Evaluation Flywheel to Develop LLM Chatbots", "publisher": "DoorDash Engineering", "url": "https://careersatdoordash.com/blog/doordash-simulation-evaluation-flywheel-to-develop-llm-chatbots-at-scale/", "source_type": "企业工程博客", "directness": "案例级直接来源", "claim_origin": "企业工程团队披露", "independently_verified": false, "accessed_at": "2026-09-19" }, "analysis_boundary": { "business_problem": "企业工程博客披露", "solution": "企业工程博客披露与中文结构化整理", "architecture": "企业工程博客逐层披露", "fde_actions": "依据公开研发闭环归纳", "result": "企业工程团队披露" }, "verification_notes": [ "幻觉减少90%先在仿真中测得，文章称趋势延续到生产，但未公开绝对基线。", "5分钟200多段是测试吞吐，不等于线上客服吞吐。" ], "additional_sources": [], "detail_score": 12, "detail_level": "deep", "detail_label": "深度案例｜关键链路较完整", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 2, "human_governance": 2, "measured_outcome": 2, "source_traceability": 2 }, "missing_details": [] } ```