[ { "id": "cn-official-anker-sales", "source": "飞书（客户CEO演讲）", "company": "安克创新", "industry": "消费电子", "scenario": "销售产品知识问答与专家纠错闭环", "fde": "FDE相邻实践", "problem": "海外销售与分销伙伴的产品问题依赖GTM手工答复。", "solution": "按品类加载产品文档，助手多语言答疑并返回出处。", "human": "专家可观察知识提取与模型输入，调参纠错并修订知识库；未披露逐条审批要求。", "result": "CEO阳萌称已提供10种语言的全天候产品问答；未给出该场景准确率或净节省工时。", "maturity": "公开案例称已应用", "url": "https://www.feishu.cn/content/wechat_post_5510", "architecture": [ "品类产品文档", "带出处的问答", "专家诊断并修订知识" ], "components": [ "飞书智能伙伴", "产品知识库", "反馈纠错" ], "fde_actions": [ "教学推演：访谈岗位负责人，确认输入、输出与失败条件", "教学推演：用真实任务建立验收集，记录人工复核与异常处理成本" ], "reusable": [ "先定义可验收的业务输出，再选模型和编排工具", "来源未披露的审核、权限和异常机制应在实施前补齐" ], "evidence": "第一方公开案例；效果为发布方或客户自述，未独立审计。", "case_summary": "可用于分析销售产品知识问答与专家纠错闭环的输入、处理、交付与责任边界。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "FDE相邻实践", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "安克创新CEO阳萌分享AI Ready之路", "publisher": "飞书（客户CEO演讲）", "url": "https://www.feishu.cn/content/wechat_post_5510", "source_type": "官方客户案例网页", "directness": "案例级直接来源", "claim_origin": "客户CEO公开演讲自述", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "按官方所述流程简化，非完整部署架构", "fde_actions": "编辑教学建议，非企业原始实施记录", "human": "明确区分已披露边界与未披露项", "result": "客户或供应商自述，未经独立审计" }, "verification_notes": [ "已与现有127条公司及场景名单去重；匿名旧案例无法确认是否同一企业。", "未找到公开材料证明使用FDE岗位或FDE服务，不标为明确FDE。", "已核验文章为演讲文字与配图，未验证到对应企业案例的可播放视频；不提供视频标签。", "详细度为本站依六维公开信息完整性给出的编辑评分，不代表实施成功或独立核验。" ], "missing_details": [ "检索与回答评测集", "权限隔离细节", "使用量、成本及效果基线" ], "detail_score": 8, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "additional_sources": [], "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 2, "measured_outcome": 0, "source_traceability": 2 } }, { "id": "cn-official-huafeng-intelligence", "source": "飞书", "company": "华峰集团", "industry": "制造业", "scenario": "销售市场情报日报自动化", "fde": "FDE相邻实践", "problem": "销售从十多个来源手工整理价格、竞品和政策信息。", "solution": "RPA采集后写入多维表格，aily提炼摘要，以卡片发到业务群。", "human": "原页称生成与推送无人值守，业务决策仍由人完成；未披露发布前复核。", "result": "飞书自述人工制报从2小时转为全自动、整合准确率95%以上；无样本量与评测定义。", "maturity": "公开案例称已应用", "url": "https://www.feishu.cn/customers/huafen_ai_case#/", "architecture": [ "多源行情采集", "表格沉淀", "AI摘要", "卡片推送" ], "components": [ "RPA", "多维表格", "aily", "飞书消息卡片" ], "fde_actions": [ "教学推演：访谈岗位负责人，确认输入、输出与失败条件", "教学推演：用真实任务建立验收集，记录人工复核与异常处理成本" ], "reusable": [ "先定义可验收的业务输出，再选模型和编排工具", "来源未披露的审核、权限和异常机制应在实施前补齐" ], "evidence": "第一方公开案例；效果为发布方或客户自述，未独立审计。", "case_summary": "可用于分析销售市场情报日报自动化的输入、处理、交付与责任边界。", "industry_group": "制造与工业", "maturity_stage": "已上线", "fde_relation": "FDE相邻实践", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "AI + 智能销售：华峰集团 AI 情报员上岗，助力销售洞悉市场先机", "publisher": "飞书", "url": "https://www.feishu.cn/customers/huafen_ai_case#/", "source_type": "官方客户案例网页", "directness": "案例级直接来源", "claim_origin": "供应商官方案例披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "按官方所述流程简化，非完整部署架构", "fde_actions": "编辑教学建议，非企业原始实施记录", "human": "明确区分已披露边界与未披露项", "result": "客户或供应商自述，未经独立审计" }, "verification_notes": [ "已与现有127条公司及场景名单去重；匿名旧案例无法确认是否同一企业。", "未找到公开材料证明使用FDE岗位或FDE服务，不标为明确FDE。", "云浏览器核验正文，页面未发现video元素或案例视频入口；不提供视频标签。", "详细度为本站依六维公开信息完整性给出的编辑评分，不代表实施成功或独立核验。" ], "missing_details": [ "准确率口径和统计周期", "来源授权与过期检测", "错报拦截和人工复核机制" ], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "additional_sources": [], "detail_dimensions": { "business_context": 1, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 } }, { "id": "cn-official-yumi-comics", "source": "火山引擎", "company": "余米", "industry": "文娱传媒", "scenario": "漫剧内容生产与风格一致性", "fde": "FDE相邻实践", "problem": "漫剧业务向AI制作转型，需要统一角色与画面风格。", "solution": "语言模型抽取角色道具，固定场景提示词，结合Seedream生图与SeedEdit局部修改。", "human": "供应商响应失败样例并优化提示词；未披露成片人工审核责任。", "result": "火山引擎称月产能提升3倍；未披露基线、周期、返工率。", "maturity": "公开案例称已应用", "url": "https://docs.volcengine.com/docs/87254/2075760?lang=zh", "architecture": [ "角色道具抽取", "模板化生图", "局部修改" ], "components": [ "豆包模型", "Seedream", "SeedEdit" ], "fde_actions": [ "教学推演：访谈岗位负责人，确认输入、输出与失败条件", "教学推演：用真实任务建立验收集，记录人工复核与异常处理成本" ], "reusable": [ "先定义可验收的业务输出，再选模型和编排工具", "来源未披露的审核、权限和异常机制应在实施前补齐" ], "evidence": "第一方公开案例；效果为发布方或客户自述，未独立审计。", "case_summary": "可用于分析漫剧内容生产与风格一致性的输入、处理、交付与责任边界。", "industry_group": "媒体、营销与体育", "maturity_stage": "已上线", "fde_relation": "FDE相邻实践", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "客户案例：多场景视频创作实践｜余米", "publisher": "火山引擎", "url": "https://docs.volcengine.com/docs/87254/2075760?lang=zh", "source_type": "官方客户案例网页", "directness": "案例级直接来源", "claim_origin": "供应商官方案例披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "按官方所述流程简化，非完整部署架构", "fde_actions": "编辑教学建议，非企业原始实施记录", "human": "明确区分已披露边界与未披露项", "result": "客户或供应商自述，未经独立审计" }, "verification_notes": [ "已与现有127条公司及场景名单去重；匿名旧案例无法确认是否同一企业。", "未找到公开材料证明使用FDE岗位或FDE服务，不标为明确FDE。", "官方页有其他客户作品视频，但未明确标为余米项目；未据此给余米附视频。", "详细度为本站依六维公开信息完整性给出的编辑评分，不代表实施成功或独立核验。" ], "missing_details": [ "产能统计口径", "成片审核与版权流程", "单位内容成本" ], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "additional_sources": [], "detail_dimensions": { "business_context": 1, "solution_workflow": 1, "technical_workflow": 1, "human_governance": 0, "measured_outcome": 1, "source_traceability": 2 } }, { "id": "microsoft-dow-freight-001", "source": "Microsoft", "company": "Dow", "industry": "化工", "industry_group": "制造与工业", "scenario": "运输发票审计与费用异常调查", "problem": "运输发票、合同费率与计提成本分散，PDF账单中的附加费用难以逐一核查。", "solution": "Copilot Studio代理读取邮件PDF并结构化账单，标记异常；员工用Freight Agent追问明细和成本差异。", "human": "原文明确由员工查看异常仪表盘并进一步调查；未证实AI可独立裁定付款或追回费用。", "result": "微软2024年案例称首年预计节省数百万美元，属于预期而非已实现收益。", "maturity": "初步应用 / 概念验证后扩展", "maturity_stage": "POC/试点", "url": "https://www.microsoft.com/en/customers/story/19829-dow-microsoft-365-copilot", "architecture": [ "邮件PDF发票", "结构化账单与成本数据", "异常标记", "员工自然语言追问", "核实后纠正" ], "components": [ "Copilot Studio", "Microsoft 365 Copilot", "PDF解析", "异常仪表盘" ], "fde_actions": [ "将高额物流支出收敛到北美陆运发票", "对齐发票与计提成本字段", "让异常可追溯到明细" ], "reusable": [ "先缩小业务范围，再验证异常是否可行动", "严格区分识别节省机会与实际回款" ], "additional_sources": [ { "title": "Microsoft WorkLab：Dow发票代理工作流", "url": "https://www.microsoft.com/en-us/worklab/ai-impact-at-dow-copilot-identifies-millions-in-cost-savings" } ], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "Copilot Studio代理读取邮件PDF并结构化账单，标记异常；员工用Freight Agent追问明细和成本差异。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Dow reimagines productivity and supply chain efficiency with Microsoft 365 Copilot", "publisher": "Microsoft", "url": "https://www.microsoft.com/en/customers/story/19829-dow-microsoft-365-copilot", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "费用节省为预计口径。", "人工调查流程由微软WorkLab补充材料说明。", "案例页有企业图片；未核验具体视频。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ] }, { "id": "aws-bmw-rca-001", "source": "AWS", "company": "BMW Group", "industry": "汽车与软件运维", "industry_group": "制造与工业", "scenario": "联网汽车云服务故障根因分析", "problem": "云服务跨团队、跨账户依赖复杂，值班工程师需反复查日志、指标与配置变化。", "solution": "Bedrock Agent调用Lambda工具，联查系统架构、CloudWatch与CloudTrail，提出有证据的根因假设。", "human": "值班工程师描述故障、引导继续调查并负责修复；代理辅助诊断。", "result": "BMW与AWS合著文章披露85%测试案例正确识别根因；演示故障为测试环境故意修改安全组，不能当作真实生产事故统计。", "maturity": "已开发应用 / 测试案例验证", "maturity_stage": "POC/试点", "url": "https://aws.amazon.com/blogs/machine-learning/innovating-at-speed-bmws-generative-ai-solution-for-cloud-incident-analysis/", "architecture": [ "工程师描述故障", "系统依赖图定位范围", "工具查询日志/指标/配置", "提出根因假设", "工程师验证修复" ], "components": [ "Amazon Bedrock Agents", "AWS Lambda", "CloudWatch", "CloudTrail", "C4架构图" ], "fde_actions": [ "把专家排障动作封装为工具", "让架构依赖约束查询范围", "用受控故障验证诊断" ], "reusable": [ "测出正确根因不等于允许自动修复", "保留测试集与生产指标的口径差异" ], "additional_sources": [], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "Bedrock Agent调用Lambda工具，联查系统架构、CloudWatch与CloudTrail，提出有证据的根因假设。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Innovating at speed: BMW’s generative AI solution for cloud incident analysis", "publisher": "AWS", "url": "https://aws.amazon.com/blogs/machine-learning/innovating-at-speed-bmws-generative-ai-solution-for-cloud-incident-analysis/", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "2025-03-05发布，BMW员工与AWS共同署名。", "与站内BMW Factory Genius维护知识助手是不同流程。", "原文有真实方案架构图；未核验同一RCA流程视频。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ] }, { "id": "google-wendys-freshai-001", "source": "Wendy’s / Google Cloud", "company": "Wendy’s", "industry": "餐饮", "industry_group": "零售与消费", "scenario": "得来速语音点餐 FreshAI", "problem": "菜单俗称、定制组合和环境噪音增加点餐难度，重复问答占用店员时间。", "solution": "FreshAI理解口语和菜品定制，生成对话答复并处理订单；门店团队反馈持续改善系统。", "human": "店员处理需要人工介入的订单，负责制作和交付食品；技术与运营人员现场观察并优化。", "result": "Wendy’s 2023-12试点更新披露86%订单无需员工介入完成；这是当时试点口径，不是所有门店当前准确率。", "maturity": "真实门店试点 / 后续扩展", "maturity_stage": "已上线", "url": "https://www.wendys.com/blog/drive-thru-innovation-wendys-freshai", "architecture": [ "顾客车道语音", "理解菜单与定制", "澄清并形成订单", "必要时人工接管", "制作交付与反馈" ], "components": [ "生成式对话AI", "Google Cloud", "语音点餐", "门店反馈" ], "fde_actions": [ "在真实门店观察噪音和顾客用词", "定义无需人工介入的订单成功率", "小范围迭代后扩店" ], "reusable": [ "对话成功应以真实业务闭环衡量", "界面与人工接管同样重要" ], "additional_sources": [ { "title": "Google Cloud：Wendy’s门店试点", "url": "https://cloud.google.com/blog/transform/wendys-generative-ai-drive-thru-reinvention-worker-freedom" } ], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "FreshAI理解口语和菜品定制，生成对话答复并处理订单；门店团队反馈持续改善系统。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Leading Drive-Thru Innovation with Wendy’s FreshAi", "publisher": "Wendy’s / Google Cloud", "url": "https://www.wendys.com/blog/drive-thru-innovation-wendys-freshai", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "来源为Wendy’s自身运营回顾。", "与已有Wendy’s QSCC供应链条目不同。", "Wendy’s原文有得来速门店照片；只建议链接原文，不默认转载权。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ] }, { "id": "microsoft-thyssenkrupp-copilot-001", "source": "Siemens / Microsoft", "company": "thyssenkrupp Automation Engineering", "industry": "工业设备", "industry_group": "制造与工业", "scenario": "电池检测设备自动化工程与编程", "problem": "复杂电池检测机器需要控制代码、传感器配置和检验记录，工程师面临重复劳动与技能短缺。", "solution": "Siemens Industrial Copilot辅助TIA Portal工程，生成控制代码、处理配置和文档，以自然语言支持工程任务。", "human": "工程师负责机器编程、测试和复杂工程判断；原文未披露完整安全审批链，不能推定AI直接控制设备。", "result": "官方确认已在电池检测机器中集成，2024年公告计划后续全球扩展；未披露可归属于该客户的统一ROI。", "maturity": "设备场景已集成 / 计划扩展", "maturity_stage": "已上线", "url": "https://press.siemens.com/global/en/pressrelease/siemens-and-microsoft-scale-industrial-ai", "architecture": [ "工程需求与设备上下文", "自然语言Copilot", "生成代码/配置/文档", "工程师编程测试", "机器工程交付" ], "components": [ "Siemens Industrial Copilot", "Azure OpenAI Service", "TIA Portal", "工业控制代码" ], "fde_actions": [ "按具体机器需求共同适配", "以工程环境承接模型输出", "把重复文档和配置纳入流程" ], "reusable": [ "工业代码需要工程验证", "供应商整体指标不能移作客户ROI" ], "additional_sources": [ { "title": "Siemens：已集成电池检测机器与扩展计划", "url": "https://press.siemens.com/global/ro/node/7042" } ], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "Siemens Industrial Copilot辅助TIA Portal工程，生成控制代码、处理配置和文档，以自然语言支持工程任务。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Siemens and Microsoft scale industrial AI", "publisher": "Siemens / Microsoft", "url": "https://press.siemens.com/global/en/pressrelease/siemens-and-microsoft-scale-industrial-ai", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "供应商关于30秒可视化和20%代码调整的总体描述不作为该客户专属效果。", "微软官方YouTube有客户案例视频；核验了发布者、标题和说明，未逐帧验看。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ], "media": [ { "type": "official-video-page", "url": "https://www.youtube.com/watch?v=Zi6I8rIdzZ4", "title": "微软官方：Siemens与thyssenkrupp工业Copilot", "verified_at": "2026-10-03", "verification_note": "检索核验为Microsoft已认证频道发布，2024-10-24；标题及简介与该工业Copilot案例一致。视频页直接抓取失败，未验证当前可播放性或逐帧内容。" } ] }, { "id": "uipath-dentsu-001", "source": "UiPath", "company": "Dentsu Americas", "industry": "广告与营销服务", "industry_group": "专业服务", "scenario": "企业自动化推广与内部知识问答 dentsuGPT", "problem": "各地区自动化分散，员工难以发现既有能力和找到HR、合规、自动化知识。", "solution": "通过Automation Cloud协同自动化，再以dentsuGPT从内部资源回答问题、帮助员工找到自动化自助资料。", "human": "自动化团队负责平台治理、能力推广与开发指导；公开材料未说明每类AI答复的审批规则。", "result": "UiPath称截至2023年底整体自动化年化节省60万小时，已部署600余项自动化；不可将该数字归因于dentsuGPT或生成式AI。", "maturity": "自动化规模化 / AI问答应用", "maturity_stage": "已上线", "url": "https://www.uipath.com/resources/automation-case-studies/dentsu-builds-on-massive-success-with-automation", "architecture": [ "内部HR/合规/自动化资源", "dentsuGPT自然语言问答", "员工自助学习", "自动化团队指导", "跨地区能力复用" ], "components": [ "UiPath Automation Cloud", "内部知识资源", "dentsuGPT", "自动化治理" ], "fde_actions": [ "集中分散的自动化能力", "让员工通过问答获取自助资源", "沉淀机器人开发指导" ], "reusable": [ "分别计算传统自动化与AI增量收益", "知识入口需要连接组织推广" ], "additional_sources": [], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "通过Automation Cloud协同自动化，再以dentsuGPT从内部资源回答问题、帮助员工找到自动化自助资料。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Dentsu builds on massive success to take automation to the next level", "publisher": "UiPath", "url": "https://www.uipath.com/resources/automation-case-studies/dentsu-builds-on-massive-success-with-automation", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "AI与自动化组合案例，不是纯大模型ROI案例。", "未公开模型选型和细粒度知识检索架构。", "原文有案例配图，未核验视频；不默认配图具备转载授权。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ] }, { "id": "intercom-anthropic-support-001", "source": "Intercom / Fin", "company": "Anthropic", "industry": "AI软件", "industry_group": "科技与软件", "scenario": "产品客服分流、知识维护与Fin部署", "problem": "用户类型多且新产品发布带来咨询波峰，客服需把精力留给复杂问题。", "solution": "利用Claude整理帮助内容与常见答复，部署Fin处理重复咨询，并通过报告与内容维护改进。", "human": "人工支持专家处理复杂咨询，审阅和补齐知识内容；原文中退款自动化仍在测试，不能写成全面上线。", "result": "供应商客户故事披露上线约一个月解决率50.8%、首月节省1700小时；属于该早期阶段客户/供应商自述，不代表当前服务水平。", "maturity": "已上线 / 持续内容优化", "maturity_stage": "已上线", "url": "https://fin.ai/customers/anthropic", "architecture": [ "帮助中心与常见问答", "Claude整理知识片段", "Fin解答重复咨询", "人工深入调查复杂问题", "报告定位知识缺口并修订" ], "components": [ "Fin", "Claude", "Intercom帮助中心", "客服报告" ], "fde_actions": [ "先准备可回答的知识内容", "按用户问题复杂度分工", "组织专家补全和重组知识" ], "reusable": [ "买工具之后仍需运营知识和评测", "区分AI参与率与真正解决率" ], "additional_sources": [ { "title": "Anthropic产品支持负责人官方访谈（音频）", "url": "https://www.intercom.com/blog/podcasts/why-anthropic-chose-fin-to-transform-their-customer-support/" } ], "fde": "FDE式交付", "fde_relation": "FDE式交付", "evidence": "第一方案例级来源；效果为客户/厂商自述，非独立审计。", "case_summary": "利用Claude整理帮助内容与常见答复，部署Fin处理重复咨询，并通过报告与内容维护改进。", "evidence_level": "A", "evidence_label": "A级｜案例级直接来源", "source_record": { "title": "Build vs buy: Why Anthropic chose Fin", "publisher": "Intercom / Fin", "url": "https://fin.ai/customers/anthropic", "source_type": "第一方客户案例/技术文章", "directness": "案例级直接来源", "claim_origin": "客户/厂商披露", "independently_verified": false, "accessed_at": "2026-10-03" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息的编辑抽象，并非完整生产架构", "fde_actions": "编辑归纳，不代表官方职位或逐项实施记录", "result": "客户/厂商披露，按来源注明测试、预期或历史范围" }, "verification_notes": [ "与Intercom自身构建Fin产品的既有条目是不同企业和流程。", "退款动作在来源中为测试阶段。", "原文有团队照片，另有官方音频访谈；不把音频伪标成视频。", "公开可访问不等于图片或视频拥有转载授权；建议原创示意图加原始链接。" ], "detail_score": 9, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 2, "solution_workflow": 2, "technical_workflow": 1, "human_governance": 1, "measured_outcome": 1, "source_traceability": 2 }, "missing_details": [ "生产运行成本", "完整权限与异常处理", "独立效果审计" ] }, { "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", "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", "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", "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", "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", "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", "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", "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", "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", "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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", "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", "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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", "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", "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", "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", "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", "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", "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [] }, { "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", "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", "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": [ "量化结果" ] }, { "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": [ "业务背景", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "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": [], "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "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，识别8,000多个活跃用例、其中约700个具战略价值；平均每名员工每周节省约3小时，员工助手基于2,500多份文档每月处理3.4万多次查询。", "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-19" }, "analysis_boundary": { "business_problem": "企业转型材料披露", "solution": "BBVA两篇直接材料交叉整理", "architecture": "依据公开组织和知识流程整理", "fde_actions": "依据公开采用路径归纳", "result": "企业内部统计披露" }, "verification_notes": [ "每周约3小时为BBVA估算的重复任务自动化节省，不代表经审计的人均生产率提升。", "8,000多个为活跃用例，其中约700个被认为具有潜力和战略重要性。" ], "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": [] }, { "id": "openai-007", "source": "OpenAI", "company": "Moderna", "industry": "生命科学", "scenario": "研究与企业知识工作", "fde": "企业部署案例", "problem": "药企希望将生成式AI扩展到研究、分析和员工日常工作。", "solution": "ChatGPT Enterprise与内部GPT/工作流用于研究、知识和企业职能。", "human": "科研与职能团队保留科学和合规判断。", "result": "OpenAI 2025企业AI报告将其列为代表案例。", "maturity": "规模化", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“研究与企业知识工作”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Moderna：研究与企业知识工作", "publisher": "OpenAI", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "id": "openai-008", "source": "OpenAI", "company": "Intercom", "industry": "SaaS/客服", "scenario": "AI客服", "fde": "企业部署案例", "problem": "客服需要在质量、响应速度与规模之间平衡。", "solution": "将OpenAI模型嵌入客户服务产品与工作流，自动处理可标准化请求。", "human": "复杂问题升级人工客服。", "result": "OpenAI 2025企业AI报告代表案例之一。", "maturity": "生产级", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": "Intercom：AI客服", "publisher": "OpenAI", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": 5, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 1, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "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/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“员工与客户AI体验”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "零售与消费", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Lowe's：员工与客户AI体验", "publisher": "OpenAI", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "id": "openai-010", "source": "OpenAI", "company": "Indeed", "industry": "招聘/平台", "scenario": "招聘匹配与求职体验", "fde": "企业部署案例", "problem": "大规模职位与求职者匹配需要更强语义理解和个性化。", "solution": "OpenAI模型进入匹配与用户体验工作流。", "human": "招聘方和求职者做最终选择。", "result": "OpenAI 2025企业AI报告代表案例之一。", "maturity": "生产级", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": "Indeed：招聘匹配与求职体验", "publisher": "OpenAI", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": 4, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "id": "openai-011", "source": "OpenAI", "company": "Oscar Health", "industry": "医疗/保险", "scenario": "医疗保险运营与知识工作", "fde": "企业部署案例", "problem": "保险与医疗运营流程文本密集、规则复杂。", "solution": "将OpenAI能力用于知识、运营和自动化场景。", "human": "医疗与保险专业人员保留高风险判断。", "result": "OpenAI 2025企业AI报告代表案例之一。", "maturity": "生产级", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "architecture": [ "EHR/床位/人员/运营事件数据", "统一患者与运营实体", "实时状态 + 预测/规则/AI分析", "按临床/运营优先级产生建议", "医护/运营人员确认与执行", "结果回写并持续监测" ], "components": [ "医疗数据集成", "Ontology/统一实体", "预测/规则/AI", "权限审计", "临床/运营工作台" ], "fde_actions": [ "与临床/运营团队共同定义问题和安全边界", "先解决可度量的运营瓶颈，避免让AI承担诊断责任", "打通数据权限与实时更新", "设计告警、建议和人工确认机制", "用住院时长、床位周转等业务指标验收" ], "reusable": [ "医疗AI先从运营闭环切入通常更容易量化", "临床责任必须留在人类专业人员", "权限、审计、实时性和数据质量与模型同等重要" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“医疗保险运营与知识工作”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "医疗与生命科学", "maturity_stage": "已上线", "fde_relation": "企业部署案例", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Oscar Health：医疗保险运营与知识工作", "publisher": "OpenAI", "url": "https://openai.com/business/guides-and-resources/the-state-of-enterprise-ai-2025-report/", "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": 4, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 1, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "id": "openai-012", "source": "OpenAI", "company": "1Password", "industry": "网络安全/软件", "scenario": "工程开发效率", "fde": "企业部署案例", "problem": "大型代码库中的开发、修改与验证消耗工程时间。", "solution": "Codex进入工程工作流，承担代码理解、修改和测试任务。", "human": "工程师审查并负责合并。", "result": "OpenAI客户案例页称工程生产力提升21%。", "maturity": "生产级", "url": "https://openai.com/business/customer-stories/", "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": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "1Password：工程开发效率", "publisher": "OpenAI", "url": "https://openai.com/business/customer-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": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 5, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 0, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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/business/customer-stories/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“律所AI治理与规模化”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "专业服务", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Gilbert + Tobin：律所AI治理与规模化", "publisher": "OpenAI", "url": "https://openai.com/business/customer-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": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "id": "openai-014", "source": "OpenAI", "company": "Polimill", "industry": "政务/公共服务", "scenario": "日本公共AI基础设施", "fde": "伴随式部署", "problem": "地方政府需要共享专家经验，同时满足公共部门治理和可持续运营。", "solution": "与OpenAI伴随式建设可复用公共AI基础设施与知识能力。", "human": "政府工作人员与专家负责政策、事实和最终决策。", "result": "2026年8月公开案例；重点是把专家隐性知识变成跨自治体可复用资产。", "maturity": "部署中/规模化", "url": "https://openai.com/business/customer-stories/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“日本公共AI基础设施”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "政务与公共服务", "maturity_stage": "规模化", "fde_relation": "伴随式部署", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "Polimill：日本公共AI基础设施", "publisher": "OpenAI", "url": "https://openai.com/business/customer-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": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 7, "detail_level": "standard", "detail_label": "标准案例｜可参考但仍有缺口", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 1, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "id": "openai-015", "source": "OpenAI", "company": "NVIDIA", "industry": "半导体/科技", "scenario": "组织知识与专业能力扩展", "fde": "企业部署案例", "problem": "超大规模技术组织需要把专业知识、研究和协作能力扩展到更多员工。", "solution": "使用ChatGPT Work连接专业知识与日常工作。", "human": "工程和业务专家保留技术决策。", "result": "2026年8月公开客户案例。", "maturity": "规模化", "url": "https://openai.com/business/customer-stories/", "architecture": [ "SOP / 历史案例 / 专家访谈", "文档解析、切分与元数据标注", "Embedding / 语义索引", "按当前问题检索相似案例与规则", "LLM基于证据生成建议并附出处", "专家确认 → 新经验回写知识库" ], "components": [ "知识库/RAG", "Embedding/向量检索", "权限与元数据", "LLM", "专家审核" ], "fde_actions": [ "跟岗识别“什么时候员工会去找老师傅”", "访谈专家，把隐性判断条件转成可检索案例和规则", "设计知识粒度、标签、版本和权限，而不是只做文档上传", "用真实问题做召回率/答案可用性验证", "把反馈、错答和新案例持续回灌" ], "reusable": [ "先选高频、高成本、可验证的窄流程", "能用确定性工具验证的步骤，不让模型自评", "高风险动作保留人工责任", "把每次人工修正变成后续可检索的上下文/规则" ], "evidence": "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "case_summary": "这个案例的关键不是单点使用AI，而是把“组织知识与专业能力扩展”重构成可执行、可验证、有人类责任边界的生产工作流。", "industry_group": "科技与软件", "maturity_stage": "规模化", "fde_relation": "企业部署案例", "evidence_level": "B", "evidence_label": "B级｜官方汇总来源", "source_record": { "title": "NVIDIA：组织知识与专业能力扩展", "publisher": "OpenAI", "url": "https://openai.com/business/customer-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": [ "公开资料确认业务流程；技术组件为基于公开描述的架构抽象", "当前链接为官方汇总入口，尚需补充可直接定位该案例的深链接或页码。" ], "additional_sources": [], "detail_score": 6, "detail_level": "overview", "detail_label": "概览案例｜作为线索使用", "detail_dimensions": { "business_context": 1, "solution_workflow": 0, "technical_workflow": 2, "human_governance": 0, "measured_outcome": 2, "source_traceability": 1 }, "missing_details": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "来源可定位性" ] }, { "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": [], "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [], "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "技术工作流", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "来源可定位性" ] }, { "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": [ "业务背景", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果", "来源可定位性" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [], "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": "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "id": "palantir-040", "source": "Palantir", "company": "Airbus", "industry": "航空航天", "scenario": "Skywise航空数据生态与A350生产", "fde": "典型Forward Deployed", "problem": "飞机设计、生产、供应商和航空公司运营数据分散，难以形成行业级共享运营系统。", "solution": "Palantir与Airbus长期共建Skywise，把生产、供应链、维护和航空公司运营数据连接到统一航空Ontology与应用生态。", "human": "Airbus、供应商与航空公司在各自权限下使用并执行。", "result": "Palantir官方资料称Skywise日常用户超过50,000；历史官方材料称A350生产加速33%，并识别每年17亿美元以上成本节省。", "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [], "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": "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "id": "openai-019", "source": "OpenAI", "company": "Boston Children's Hospital", "industry": "医疗", "scenario": "医院运营自动化 + 罕见病诊断辅助", "fde": "伴随式部署", "problem": "医院同时面临大量重复运营工作和极难的罕见病信息综合问题。", "solution": "将AI作为医院基础设施：运营侧建设50+自动化；临床侧把遗传、表型和文献连接给“co-pilot geneticist”产生证据化候选。", "human": "医院人员审核运营输出；医生与遗传专家负责临床确认。", "result": "官方称50+自动化节省约60,000小时、重配劳动力价值$7M+，并帮助确认40+此前未解决的罕见病。", "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-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露运营与临床两类结果；诊断均由医生完成，模型只提供线索。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "技术工作流", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "技术工作流", "人机与治理", "量化结果" ] }, { "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": [ "业务背景", "技术工作流", "人机与治理" ] }, { "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": [ "业务背景", "技术工作流", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "人机与治理" ] }, { "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": "官方称95%受访员工每周使用，92%每周节省2小时以上，代码调试时间下降75%，每周累计节省500+小时，约合每年$500k。", "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-19" }, "analysis_boundary": { "business_problem": "基于公开材料概括", "solution": "基于公开材料概括", "architecture": "公开信息与编辑推演混合", "fde_actions": "FDE视角编辑推演", "result": "厂商或客户披露" }, "verification_notes": [ "OpenAI官方案例明确披露采用率、时间节省与客户AI产品方向。", "来源可直接定位到该案例；数值仍属于来源方披露，不代表独立审计。" ], "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "人机与治理" ] }, { "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": [ "业务背景", "改造流程", "技术工作流", "人机与治理" ] }, { "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": [] }, { "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": [] }, { "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": [] }, { "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": [] }, { "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": "AI完成图纸识别、信息抽取和候选结果生成；供应链与工程专家验证关键属性、处理低置信度例外，并对材料和设计决策负责。", "result": "IBM案例披露，关键材料信息提取准确率最高达到90%，零件号提取准确率超过85%，显著减少人工核验并节省数小时处理工作；未公开总体成本节省口径。", "maturity": "生产验证/扩展", "maturity_stage": "已上线", "url": "https://www.ibm.com/case-studies/medtronic", "architecture": [ "复杂工程图纸与设计文档", "Azure Document Intelligence OCR与版面解析", "RAG检索工程上下文", "Azure OpenAI生成并验证候选属性", "关键材料与零件号写入数据库", "搜索应用与专家异常复核" ], "components": [ "Azure Document Intelligence", "Azure OpenAI", "RAG", "Azure Blob Storage", "属性数据库", "专家复核" ], "fde_actions": [ "与供应链和工程团队定义关键提取字段", "组合OCR确定性解析与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-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开组件和流程整理", "fde_actions": "依据公开协作过程归纳", "result": "IBM与客户披露" }, "verification_notes": [ "90%和85%分别对应材料信息与零件号提取。", "公开页面未给样本量、误差分布和外部评测。" ], "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": [] }, { "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客户案例称，叶片质检使机器利用率提升30%，故障处理从数天缩短至近实时；发动机系统跟踪超过10,000项参数，每年发现并避免约400次非计划维护事件，节省数百万维修成本。", "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-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开流程结构化整理", "fde_actions": "FDE视角编辑归纳", "result": "Microsoft与客户披露" }, "verification_notes": [ "页面分别披露质检和发动机健康监控指标。", "数百万成本避免为客户估算，未见独立审计。" ], "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": [] }, { "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": [] }, { "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": [] }, { "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%，采用Glue Flex后ETL成本降低23%；智能车间助手首版在1周内完成，随后逐步接入更多数据源。", "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-19" }, "analysis_boundary": { "business_problem": "厂商客户案例披露", "solution": "厂商客户案例披露", "architecture": "依据公开项目阶段整理", "fde_actions": "依据公开联合实施过程归纳", "result": "AWS与客户披露" }, "verification_notes": [ "67%至83%部署缩短和74%处理缩短来自整体云与数据改造。", "一周指标指智能车间助手第一版，不代表全球全面上线。" ], "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": [] }, { "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": [] }, { "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": [] }, { "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": "Genie已进入Uber内部支持流程并建立可追踪的反馈、成本与幻觉评测闭环；公开工程文章披露了问题规模和完整架构，但没有披露解决率、节省工时或投资回报。", "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工程博客逐层公开数据源、切块、向量存储、检索服务、权限、成本和评测流程；文章没有公开生产效率或解决率指标。", "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处理量。", "文章未给上线后的解决率、响应时间或节省工时，不据此推算ROI。" ], "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": [ "量化结果" ] }, { "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": [] }, { "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称约1.5万张合成图只需每类两位数真实样本，预计项目周期比传统方法缩短6个月并带来每年六位数欧元生产率收益；检测在一瞬间完成，项目仍处于新产线训练和扩展阶段。", "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-19" }, "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": [] }, { "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": [ "量化结果" ] }, { "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": [] }, { "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": [] }, { "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": [] }, { "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": [] }, { "id": "enterprise-bayer-prince-001", "technical_reference": true, "source": "企业原始材料", "company": "Bayer", "industry": "制药/临床前研发", "industry_group": "医疗与生命科学", "scenario": "PRINCE：临床前研究资料检索与多Agent研究助手", "fde": "伴随式部署", "fde_relation": "拜耳与Thoughtworks联合建设；公开材料未称为FDE", "problem": "拜耳的临床前研究数据分散在多个系统中，既有结构化研究元数据，也有数十年积累的PDF安全性研究报告；历史迁移造成部分元数据缺失或错误。关键词检索难以回答跨研究、跨文档的问题，研究人员需要花时间手工查找和核对原始报告。", "solution": "拜耳与Thoughtworks逐步把PRINCE从结构化数据搜索平台扩展为研究助手。先汇集研究报告和元数据，再用RAG检索PDF证据、用Text-to-SQL查询结构化数据；LangGraph协调意图澄清、规划、研究、证据充分性检查与答案撰写。回答附原始文档引用；撰写监管相关文档前由研究人员复核提示，最终内容仍由人审核。", "human": "研究人员可选择或调整数据来源，并核查回答链接到的报告页码和原文片段；涉及监管文档时，用户先审改写作提示，再负责审阅、验证和定稿。领域专家整理评测题与参考答案，团队根据用户反馈和生产流量持续检查质量。", "result": "拜耳与Thoughtworks合著论文称，PRINCE整合超过18,000项内部研究；在15至20名高频用户的反馈中，75%表示查找信息所花时间显著减少；引入多Agent后，复杂查询的平均响应时间改善30%。系统满足用户需求的平均评分为3.1/5；未披露药物研发周期或财务收益。", "maturity": "内部生产使用/持续迭代", "maturity_stage": "已上线", "url": "https://martinfowler.com/articles/reliable-llm-bayer.html", "architecture": [ "内部研究系统与PDF报告汇入S3；文档提取、切分并附研究及章节元数据", "结构化研究元数据经整理后由Amazon Athena提供查询", "报告片段嵌入OpenSearch，按元数据过滤并结合关键词与向量做混合检索、重排", "Text-to-SQL按相关Schema和示例生成只读SELECT语句，并限制返回条数", "LangGraph协调意图澄清、规划、Researcher、Reflection与Writer，答案引用原文", "PostgreSQL保存工作流检查点，DynamoDB保存应用状态；失败时重试或切换模型", "Langfuse保存追踪及专家评测集，对生产查询每日做无参考答案评测" ], "components": [ "React / FastAPI", "LangGraph", "Amazon S3 / Athena / OpenSearch", "RAG混合检索与重排", "Text-to-SQL只读校验", "PostgreSQL / DynamoDB", "Langfuse / RAGAS", "人工复核与来源引用" ], "fde_actions": [ "从研究人员跨系统寻找安全性研究证据的流程入手，先建设可搜索的数据入口", "将PDF原文与不完整的历史元数据关联，保留报告作为可核查依据", "按问题类型路由非结构化检索与结构化SQL查询，并约束工具权限", "用领域专家问题集与真实用户反馈评估检索、答案和复杂查询响应", "为多步骤工作流增加检查点、节点重试、模型回退与生产追踪", "让科学家在文档生成前后保留审改、验证和最终责任" ], "reusable": [ "历史元数据可能不可靠时，以获批原始文档作为可追溯事实依据", "同时有结构化表和非结构化报告时，分别设计SQL和检索路径再汇总证据", "多Agent工作流需要可恢复状态、明确工具边界和分阶段评测", "高风险研究与监管文档应显示逐句出处并保留专家定稿权" ], "evidence": "Thoughtworks项目参与者在martinfowler.com发布技术复盘；拜耳与Thoughtworks合著论文披露演进、架构与有限用户反馈。两份资料都直接指向PRINCE，但论文并非独立第三方审计。", "case_summary": "PRINCE的参考价值在于把几十年临床前报告与结构化研究数据接进同一可追溯工作流，并将证据引用、只读SQL、人工复核、失败恢复和持续评测做成生产系统的一部分。", "evidence_level": "A", "evidence_label": "A级｜项目参与者案例级技术复盘", "source_record": { "title": "Building Reliable Agentic AI Systems", "publisher": "martinfowler.com / Thoughtworks项目团队", "url": "https://martinfowler.com/articles/reliable-llm-bayer.html", "source_type": "项目参与者技术复盘", "directness": "案例级直接来源", "claim_origin": "项目参与者与拜耳合著论文披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "技术复盘与拜耳合著论文披露", "solution": "两份项目参与者材料披露并结构化整理", "architecture": "公开组件与工作流逐层披露", "fde_actions": "依据公开项目演进与工程措施归纳；未公开FDE岗位安排", "result": "拜耳与Thoughtworks合著论文中的内部评测和用户反馈" }, "verification_notes": [ "martinfowler.com是刊载网站，文章作者是Thoughtworks的Sarang Sanjay Kulkarni，不是Martin Fowler本人。", "论文由拜耳和Thoughtworks项目人员合著；同行评审不等于结果经过独立审计。", "75%来自15至20名高频用户的反馈；30%是复杂查询平均响应时间改善，论文未公开完整基线和测试样本。", "论文同时报告系统满足用户需求的评分仅3.1/5；不能据此推断药物研发周期缩短或监管决策自动化。", "文中按领域拆分Researcher子Agent及自动修复元数据属于演进计划，未写作已上线功能。" ], "additional_sources": [ { "title": "拜耳与Thoughtworks合著论文｜PRINCE的演进、实现与用户反馈", "url": "https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1636809/full" } ], "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": "enterprise-nubank-support-agents-001", "technical_reference": true, "source": "企业原始材料", "company": "Nubank", "industry": "数字银行/金融服务", "industry_group": "金融与保险", "scenario": "五类生产客服Agent：评测驱动的迭代与A/B上线", "fde": "企业内部AI改造", "fde_relation": "Nubank内部团队建设；未披露FDE岗位", "problem": "Nubank的客服需要处理卡片配送、债务管理、信用额度、卡片管理和产品解释等不同问题。传统知识库型机器人难以调用实时业务数据、执行受控操作或处理复杂分支；若只看离线答题分数，也无法证明真实客户满意度和自助解决率会改善。", "solution": "团队把客服SOP拆成可版本化的指令、例行流程、工具说明和工作记忆，并按场景配置Agent。以卡片配送为例，Agent读取物流与客户资料、按地址类型排查、必要时发起补卡或带上下文转人工。团队先用人工标注、LLM评审器和离线模拟定位失败，再用GEPA优化评测提示，最终以小流量A/B逐步发布并跟踪交易NPS和自助服务率。", "human": "人工客服承接低置信度、客户不满或自动流程无法解决的场景，交接时保留上下文。领域专家标注评测集并校准LLM评审器；受监管的授信和债务相关决策仍受既有规则、人工监督与申诉机制约束。对话数据经最小化、去标识化和受控访问。", "result": "论文报告5个生产客服Agent。卡片配送Agent相对先前版本，AI交易NPS提高37个百分点、自助服务率提高29个百分点；其NPS仍比专家人工客服低10个百分点。债务管理Agent虽有改善，NPS仍低于专家人工客服23.6个百分点；产品解释Agent的自助服务率短暂下降1.5个百分点。论文未公开完整财务回报或独立审计。", "maturity": "五个场景生产部署/持续A/B", "maturity_stage": "已上线", "url": "https://arxiv.org/html/2606.08867", "architecture": [ "把人类客服SOP改写为可组合、语义版本化的指令、例行流程、工具描述与工作记忆", "卡片配送Agent通过客户资料、配送状态与补卡工具执行受控步骤", "离线案例和人工标注构建场景评测集，LLM评审器与人工判断做一致性校准", "用GEPA在DSPy中优化评审提示词，并比较不同模型上的评测稳定性", "新版本先在1%流量发布，再按离线失败率和线上表现扩大A/B流量", "线上同时测交易NPS、自助服务率、任务完成率，并在低置信度时转人工", "客服数据最小化与去标识化，日志及评测集按角色、审计与时限授权" ], "components": [ "模块化上下文工程", "领域SOP/例行流程", "客户资料与配送工具", "LLM-as-a-Judge", "GEPA / DSPy", "离线模拟与人工标注", "线上A/B和交易NPS", "转人工与隐私治理" ], "fde_actions": [ "先选高频且可观测的卡片配送问题，明确老版本机器人与人工服务基线", "将客服SOP拆成可维护的步骤、工具权限和触发条件", "用专家标注校准自动评测，而非直接信任模型自评", "根据失败案例逐项增加物流工具、补卡能力、挫败识别和简洁性约束", "从1%流量开始做真实客户A/B，并同时衡量满意度和自助解决率", "为隐私、争议处理和人工接管建立生产边界" ], "reusable": [ "离线评测应与线上业务指标建立可检验关联", "满意度与自助率可能互相牵制，不能只优化一个指标", "先在单一高频场景验证再扩展为多场景共用框架", "生产Agent的工具权限、人工交接和数据保护与提示词同等重要" ], "evidence": "Nubank员工署名的KDD 2026论文直接披露五个生产Agent、技术流程和A/B结果；同行评审不等于独立审计公司业务指标。", "case_summary": "Nubank把客服Agent做成评测驱动的生产工程：SOP与工具模块化、人工标注校准评审器、离线模拟筛选版本、1%流量起步A/B，最终在五类客服场景复用。", "evidence_level": "A", "evidence_label": "A级｜企业团队论文直接来源", "source_record": { "title": "Building Customer Support AI Agents at 100M-User Scale: An Evaluation-Driven Framework", "publisher": "Nubank团队 / KDD 2026论文", "url": "https://arxiv.org/html/2606.08867", "source_type": "企业员工署名技术论文", "directness": "案例级直接来源", "claim_origin": "企业项目团队披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "论文背景与客服场景披露", "solution": "依据论文所述Agent、评测和上线流程整理", "architecture": "论文逐层披露", "fde_actions": "依据公开工程过程归纳；未披露FDE岗位", "result": "企业团队论文中的线上A/B结果" }, "verification_notes": [ "100M+是Nubank客户规模，不是这些Agent的实际用户数。", "37和29都是百分点，不是相对百分比；对照组是先前Agent版本。", "五个Agent的交易NPS均改善，但产品解释场景自助服务率短暂下降；不得写作所有指标全面提升。", "论文未给出完整ROI，线上结果和隐私控制均属于企业团队自述。" ], "additional_sources": [ { "title": "arXiv论文摘要、作者与KDD 2026收录信息", "url": "https://arxiv.org/abs/2606.08867" } ], "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": "enterprise-meta-expert-second-brain-001", "technical_reference": true, "source": "企业原始材料", "company": "Meta", "industry": "互联网/企业合规", "industry_group": "科技与软件", "scenario": "面向特定合规领域的专家知识Agent与反馈修正闭环", "fde": "企业内部AI改造", "fde_relation": "Meta工程团队自建；未披露FDE岗位", "problem": "在特定合规领域，专家需要查阅大量组织立场、历史判断与外部材料才能完成评估。关键知识往往散落在文档或专家脑中，简单RAG每次仍要从原始片段重新推断规则，导致评估耗时、解释不一致，也难以把一次人工纠错可靠地保存下来。", "solution": "Meta团队将200多个文件整理为立场、术语、路由和准入规则，使用YAML依赖关系形成可追踪知识图；高密度常用知识进入结构化wiki，稀疏资料按需RAG检索。另以可组合recipe规定分析步骤，与知识事实分离。专家在检查点审核或对模糊问题升级；纠错再经根因归类、最小文件修补、盲测回放、回归测试和专家批准后合并。", "human": "领域专家负责在关键检查点确认、纠正或改写分析，并对真正模糊的判断作决定；自动修改只形成待审差异和证据链，由专家审核后才能进入知识库。独立评审Agent与确定性结构校验用于发现冲突，但不能取代专家最终责任。", "result": "Meta工程文章称，3个开发冲刺、约6周后，单次评估由数天缩至数分钟；改为分阶段recipe后，每轮消耗的token约减少80%；团队报告改进周期中没有回归。文章未给出评估样本量、完整时间基线、回归测试数量或独立审计。", "maturity": "特定领域内部系统/持续迭代", "maturity_stage": "试点", "url": "https://engineering.fb.com/2026/09/02/ml-applications/organizational-second-brain-ai-learns-from-experts/", "architecture": [ "离线整理内部与外部资料，形成200多个立场、术语、路由和准入文件", "每个文件用YAML声明适用场景、depends_on与referenced_by，便于依赖追踪", "常用高密度知识进入结构化wiki，低频参考资料通过语义或词法RAG检索", "顶层recipe选择下游分析步骤，按阶段加载必要知识和指令", "关键检查点向专家展示中间分析，证据不充分或存在歧义时升级", "从专家纠错中区分知识缺口、流程缺陷与真正歧义，生成最小补丁", "独立评审、结构lint、盲测回放和回归测试后提交人工审核PR" ], "components": [ "结构化知识wiki", "YAML双向依赖图", "RAG检索", "可组合recipe工作流", "专家检查点与升级", "自动纠错编译管线", "确定性lint", "盲测回放与回归测试" ], "fde_actions": [ "选择一个判断标准密集、专家负荷高的合规领域", "先从既有文档与专家判断中提炼可审查的组织立场，而非直接全量检索", "把知识事实和分析程序拆开，建立路由与依赖关系", "将专家介入点和歧义升级条件写入流程", "把每次纠错诊断成知识、流程或歧义问题，再做最小修改", "要求独立检查、原场景回放、回归测试和专家批准后上线" ], "reusable": [ "专家知识应编码为可版本化、可审计的事实与程序，而非只依赖向量索引", "对高风险判断，纠错流程比自动生成答案更值得工程化", "让专家纠错变成带回归用例的版本化变更", "内部效率提升数字需说明样本和基线缺口" ], "evidence": "Meta Engineering项目团队的第一方技术复盘，公开知识结构、纠错管线与团队自报成效；未披露独立测量。", "case_summary": "Meta把合规专家的知识和分析步骤分别编码为文件与recipe，之后用专家纠错、自动最小补丁、盲测回放、回归测试和人工PR审核形成可追溯的改进闭环。", "evidence_level": "A", "evidence_label": "A级｜企业工程博客直接来源", "source_record": { "title": "An Organizational Second Brain: Building an AI That Learns From Experts", "publisher": "Engineering at Meta", "url": "https://engineering.fb.com/2026/09/02/ml-applications/organizational-second-brain-ai-learns-from-experts/", "source_type": "企业工程博客", "directness": "案例级直接来源", "claim_origin": "企业工程团队披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "Meta工程文章披露", "solution": "依据公开项目过程结构化整理", "architecture": "文章直接披露文件、recipe及验证管线", "fde_actions": "编辑归纳；未披露FDE岗位", "result": "Meta工程团队自报的内部改进结果" }, "verification_notes": [ "这是Meta特定合规领域的系统，不应与另一个面向知识工作者的Second Brain项目混同。", "数天到数分钟没有公开样本量和统计口径；零回归也没有公开测试总量。", "文中没有证明组织级普遍上线，故记为特定领域内部系统而非全公司规模化部署。" ], "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": [] }, { "id": "enterprise-doctolib-ai-factory-001", "technical_reference": true, "source": "企业原始材料", "company": "Doctolib", "industry": "数字医疗/软件平台", "industry_group": "医疗与生命科学", "scenario": "从分散AI产品到共享Data & AI平台及Agent黄金路径", "fde": "企业内部AI改造", "fde_relation": "Doctolib内部平台团队建设；未披露FDE岗位", "problem": "Doctolib早期的数据、机器学习和工程平台彼此分散，AI产品团队各自建设评测、模型接入和Agent框架。前几个AI原生产品到生产环境需数个季度，业务团队在组装基础设施上耗时，产品能力跨团队复用低。", "solution": "Doctolib用一年多整合Data & AI平台，并按先评测、后模型治理、再框架标准化的顺序改造。共享评测与可观测平台让产品经理和领域专家参与实验；统一GenAI网关接入合规模型并支持故障回退；共同Agent框架和黄金路径模板预置记忆、评测、观测、模型访问及护栏，产品团队在此基础上开发具体业务逻辑。", "human": "产品团队对质量、成本及生产运行负责，领域专家和产品经理直接参与评测；平台团队维护共享网关、评测和标准框架。医疗场景的安全与质量仍需人工治理。文章也承认团队资产复用仍低，未来的交互式Agent Builder尚未完成。", "result": "Doctolib平台负责人称，团队现在每天运行数百次评测实验；早期AI原生产品从构想到生产用数个季度，而一次内部黑客松中的团队约3周将一个Agent产品以beta形式运行在生产环境。该例不能代表所有产品的平均交付时间，也未披露患者疗效、整体ROI或独立审计。", "maturity": "共享平台已用于产品团队；黄金路径已验证beta", "maturity_stage": "已上线", "url": "https://medium.com/doctolib/from-one-ai-product-to-an-ai-factory-e6337ffa75d9", "architecture": [ "Data与ML平台合并为Data & AI平台，并与独立的Engineering平台协调部署体验", "共享评测及可观测层连接实验与生产，产品经理和领域专家可参与", "GenAI网关集中管理合规模型选择、切换与供应商故障自动回退", "共同Agent框架替代早期产品各自选型，降低重复维护", "黄金路径模板集成记忆、观测、评测、模型访问和标准护栏", "产品团队基于模板开发业务逻辑并负责线上质量和成本" ], "components": [ "Data & AI Platform", "共享评测平台", "生产可观测性", "GenAI网关", "多模型故障回退", "共同Agent框架", "黄金路径Agent模板", "标准护栏" ], "fde_actions": [ "盘点早期产品重复建设的评测、接入和部署工作", "先建立共享评测与模型网关，再统一Agent框架", "让产品经理及领域专家直接参与质量评估", "把记忆、评测、观测、护栏预装进可复用模板", "用一个团队的生产beta验证起步速度，同时跟踪后续复用缺口" ], "reusable": [ "平台建设应按最能解锁产品交付的依赖顺序推进", "统一网关和评测是多产品AI化的基础能力", "黄金路径要提供可运行的起点，而不是只给文档规范", "单个beta上线速度不能外推为全部产品的平均收益" ], "evidence": "Doctolib ML Platform负责人在企业官方Medium频道发布项目复盘，披露平台能力、实验量与一次beta案例；数字属企业自述。", "case_summary": "Doctolib将各产品重复搭建的评测、模型接入、Agent框架和护栏沉淀为共享平台与黄金路径模板，公开了平台采用量、一次约三周beta实践以及尚未解决的复用问题。", "evidence_level": "A", "evidence_label": "A级｜企业负责人项目复盘", "source_record": { "title": "From one AI product to an AI factory", "publisher": "Doctolib官方Medium频道", "url": "https://medium.com/doctolib/from-one-ai-product-to-an-ai-factory-e6337ffa75d9", "source_type": "企业负责人项目复盘", "directness": "案例级直接来源", "claim_origin": "Doctolib ML Platform负责人披露", "independently_verified": false, "accessed_at": "2026-09-23" }, "analysis_boundary": { "business_problem": "平台负责人披露", "solution": "依据公开平台演进整理", "architecture": "公开的平台层及模板组件", "fde_actions": "依据演进过程归纳；未披露FDE岗位", "result": "企业负责人报告的内部实验量及一次beta周期" }, "verification_notes": [ "约3周是一个黑客松团队进入生产beta的个例，不是所有AI产品交付周期。", "数百次是每天的评测实验次数，不是生产产品数或用户数。", "Agent Builder及更高产品资产复用仍属后续计划，不能标记为已完成。", "文章没有公开具体框架厂商、患者结局、成本节约总额或独立审计。" ], "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": [] } ]