企业数字化平台建设有一个普遍的落差：买平台容易，落价值难。蓝图评审会上人人点头，演示环境里处处惊艳，可六个月后盘点，能真正跑在业务里的场景寥寥无几。问题往往不在技术，而在缺一套把业务想法变成上线能力的标准作业程序。
Palantir 在 Foundry 官方文档里给了一套完整的方法论，叫用例生命周期（Use Case Life Cycle）。它回答的问题很朴素：一个业务想法，从需求到方案、再到开发排序、再到角色分工，一步一步怎么走。这套方法不是理论框架，是 Palantir 在大量客户现场反复锤炼出来的作业程序。本文按照官方文档五个部分，把它完整拆开。
官方定义原文："一个用例（use case），是一个专项团队在有限时间内，为一组用户在平台上交付新能力的努力。"四个要素：有限时间、专项团队、新能力、明确的用户群。
文档特意强调了用例不是什么：它不是"接入某个源系统"，也不是"应用某种机器学习技术"。用例的锚点永远是用户获得的能力，而不是实现细节。"接入系统 X"是实现手段，"航线运营分析员能实时分诊航班告警"才是用例。
为什么坚持用这个单位来组织工作？官方给了两个理由。第一，用例的写法逼着团队从第一天就直面价值主张：谁的工作被改善了？拿什么指标证明成功？第二，做用例的过程会解锁 Foundry 的复利特性：通过集成、数据科学技术和业务逻辑持续增富数据（enriching data）；沉淀一个灵活可复用的数据资产，作为组织和业务流程的数字孪生；构建可复用的用户界面，把运营决策捕获为数据、闭合运营回路。
一句话：用例是 Foundry 上兑现价值的载体，让复杂的平台建设始终拴在真实世界的产出上。
全景图：从业务需求到平台组件
整个生命周期的骨架，是把业务需求一步步翻译成平台组件。官方的方案设计框架图（下图）画得非常清楚：业务需求先提炼为功能需求，然后按三个桶分解。
第一个桶：转换（Transforming）用例数据。对应 ETL 管道和数据集，负责把源系统数据清洗加工成可用资产，工具层面是数据管道与数据血缘。
第二个桶：结构化（Structuring）用例数据。对应对象类型与链接类型，进入本体（Ontology），包括动作类型（action types）与接口（interfaces），由 Ontology Manager 管理。文档里有一句关键定位：本体充当用例的 API 层，把管道实现细节与最终用户交互隔离开。用户面对的是业务对象和动作，不是表和脚本。
第三个桶：交互（Interacting）用例数据。对应各类应用前端：Workshop、Quiver、Object Views、Slate、Carbon。
这个框架把开发视角"从纯粹以用户为中心的需求，转向以平台为中心的组件"。它还提供四样东西：常见模式的蓝图、标识额外开发复杂度的旗标、选项之间的默认选择与替代考量、以及在开发复杂度与业务需求严格程度之间做权衡的依据。
文档举了一个权衡的例子：业务方指定要某种图表加一个表单输入。硬用 Slate 从零搭建，可能需要别扭的本体配置和大量前端开发；而功能等价的 Workshop 可视化加 Action，前端投入大约只要十分之一，本体结构还更干净。方案设计阶段的价值，就是在写第一行代码之前把这类账算清楚。
用例的完整解剖可以看下图：用户工作流运行在界面之上，界面操作的是本体对象（属性、链接、动作、接口），本体对象建立在数据集之上，数据集来自各来源系统。层层向上，每层各司其职。
第一步：提炼功能需求
生命周期第一站，是在动手开发之前，为用例写一份简短说明。文档明确说：如果组织已有惯用的文档格式，就用你自己的；官方模板只是没有格式时的方向性指引。这份说明叫用例概览（Use Case Overview），六个部分：
一，摘要。这个用例是什么、为什么要做，要写到外行也能看懂价值所在。
二，决策。用例最终支撑什么决策、中间有哪些决策、分别由哪些用户做出。注意，落点永远是决策，不是功能。
三，干系人。利益相关方是谁，各自关心什么。
四，功能需求。解决方案必须提供的能力，也是整份文档最核心的部分，下面单独展开。
五，成果与 KPI。定量的、定性的成果，以及如何度量。
六，背景与上下文。这项工作现在是怎么做的，局限和痛点在哪里。
功能需求是"用例在能力层面最细粒度的描述"，官方建议用五段式表达：[用户类型] [界面] [决策] [决策输入] [动作]。直接看航班运营用例的官方示例：
-
• 一名航线运营分析员，在告警收件箱界面，查看自己负责航线的航班告警，依据优先级、航班详情和组织影响进行分诊，重新指派、解决或上报每条告警。 -
• 一名航线分析员，使用即席点选工具，基于历史航班模式对上报告警做根因分析，推荐处置策略。 -
• 一名数据科学家，在点选工具中基于历史航班模式制定告警生成规则。 -
• 一名区域经理，通过汇总航班数据与第三方来源的总览仪表盘识别趋势，做出战略性投资决策。
同一张界面需求清单，四种用户、四种决策。这正是五段式的巧思所在：它锚定的是用户意图，而不是具体界面元素，给实现方式留足弹性；同时它天然带出了需要哪些数据增富（可视化、指标、推荐），并暗示了建模数据和决策输出所需的本体结构。
文档同时列出四个反模式旗标，写完需求自查一遍：对当前痛点调研不足；需求锚定在具体界面元素上；用户群定得太窄；范围划定了却没有落到用户决策上。
这一步的产出物就是那份用例概览文档加结构化的功能需求清单。官方还有个小贴士：文档协作可以用项目内 Documentation 目录下的页面完成。
第二步：方案设计
有了功能需求这份原材料，方案设计把它蒸馏成可实现的 Foundry 组件。官方归纳了四个 broadly 有用的组件，我们逐一过。
组件一：对象模型（Object Model）草图。画出核心对象类型、派生对象类型、用例对象类型和链接类型。画法有讲究：圆圈代表对象类型，连线代表链接类型；考虑标出主键与基数（一对一、一对多、多对多）；用颜色区分三类对象：核心类型（core，反映数据源的真实粒度）、派生类型（derived，通过增富加工创建）、用例类型（use case，在运营工作流中被用户编辑）。
在航班告警的例子里：Flights、Aircraft、Airlines、Airports 来自记录系统，是核心类型；Routes 是派生类型（在转换中每条航线生成一行）；Team 和 Employee 建模组织；告警票据、评论、上传文件这类工单式对象是用例类型，承载运营操作。
组件二：生命周期图（Lifecycle Diagram）。"用户修改对象所执行动作的状态机图。"说白了：这个对象从生到死有哪些状态，什么动作把它从一个状态推到下一个状态。后续还可以在图上补充动作元数据、可用性校验和用户权限。
组件三：增富清单（Enrichments）。列出为支撑决策输入所需的全部数据增富，分两级。对象级：源数据里没有、需要新建的派生概念，比如 Route、Alert Ticket。属性级：给已有对象类型增强属性，办法是"应用组织规则、聚合更低粒度的数据，或运行模型"，比如为每条告警算出优先级和组织影响。
增富放在哪一层做？官方给了一条很实用的判据：如果增富不依赖用户通过动作（Action）改变的数据，就把它放在数据层。在界面里现算指标（比如按起降机场对航班做透视汇总）有三个缺点：无法复用、加载时计算慢、算出来的指标是临时的、没法用来驱动筛选；它的唯一好处是即时反映动作带来的变化。所以判据就是看数据会不会被用户的动作改写。
组件四：界面期望与意图（Interface Expectations and Intent）。把功能需求里的界面归拢，明确每类界面的意图。示例里有三类：运营用户的独立引导式界面，意图是直接行动；分析员查看并调查告警、探索数据、记录结论，意图是分析与记录；管理层看流程成效仪表盘，意图是理解。
组件到工具的默认映射也给了：独立告警分诊应用对应 Workshop 项目；单对象交互用 Object View，上下文与动作集中一处；管理驾驶舱起步用 Quiver 模板，将来可演进为 Workshop 模块加用例对象类型；需要统一检索与统一体验时，用 Carbon 工作区把对象类型和自定义界面聚到一起。更细的选择依据在管道、本体与应用构建的专门文档里。
方案设计的完整产出，就是对象模型草图、生命周期图、增富清单、界面意图四件套。功能需求里那句"分析员分诊告警"，到这里已经变成：一个独立的告警分诊界面、一套连接航线与人员的对象模型、一个带状态与指派人的告警对象及其生成机制、航班与优先级等增富数据，以及一组定义告警对象完整状态机的动作。
第三步：开发排序
方案齐了，先建什么后建什么？官方引用了 Palantir 的企业数字化转型层级框架，它"为全企业数字化转型提供了一张地图"，也体现了一种合理的实施顺序。
顺序是先地基、后高级：先建数据资产（打通数据管道），再做引导式决策（本体结构加初始界面），然后才进入决策空间的扩展与增富（数据科学上场，形成模型驱动的运营工作流）。
对应要夯实四个地基：一条健壮高效的数据管道；一个平衡、反映现实且实用的对象模型；一套灵活的数据增富方法（基于数据科学、规则与人工方式打标和计算指标）；一组可复用的界面组件（对象视图与决策捕获）。
模型驱动的反馈回路、数字孪生、链式场景推演这些高级玩法，可以并行探索，但官方提醒：底层构件是上级能力的技术倍增器。同时也敲了一记警钟：这些构件并不等于你用例潜力的全部，在管道加本体之上建一堆大而全的视图，只是"解锁灵活、互联、数据驱动运营工作流潜力的起点"。
角色与协作：谁来做
方法论最后一环是人。官方定义了七种角色，从投资回报到日常使用各归其位。
领域负责人（Domain Lead）。组织里的领域主管，"对特定组织领域的投资回报（ROI）负责"，管理领域内多个工作流，向项目团队提供战略输入，参与用例优先级的定期讨论。
工作流负责人（Workstream Lead）。通过信息共享（分析、模型、本体表）生产规模效应，确保相邻用例部署正确的专业能力，比如把应用交付给同一批用户。当一个领域内用例多了，这个角色最见价值。
用例负责人（Use Case Lead）。和工程师并肩的项目经理，对"用例的 ROI、执行和最终用户采用"负责，管理项目级权限与访问控制，协调团队支持、健康检查、排期和应用支持，同时确保技术目标与组织目标对齐、遵守最佳实践、跨团队协同。
产品负责人（Product Owner）。"对用例功能的开发路线图和实施负责"，早期即介入开发，是进度与成果问询的主要联系人。
业务专家（SME）。提供领域知识，保证工作贴合组织需要。典型人选是老系统的资深用户，最懂现在的流程、流程的毛病、以及改进的机会在哪。
用例开发者（Use Case Developer）。使用"来源于本体层的数据"开展开发的工程师和分析师，按专长分四路：数据分析师做即席与模板化分析、报告和仪表盘；数据工程师做数据转换与数据集治理，并按项目团队规范向本体贡献；数据科学家和机器学习专家做建模、分类、回归，支撑决策工作流；应用开发者在 Workshop、Slate、Quiver、Object Explorer 里搭界面，在 Ontology Manager 里定义对象类型与动作，通过 Foundry Gateway API 对接外部应用。
最终用户（End User）。在开发好的工作流、应用或数据制品里完成日常工作、即席分析、汇报与决策。别忘了，前面所有角色的存在的意义，就是这一层人的工作被改善。
协作模型也清晰：项目团队居中制定规范，比如数据集治理、本体贡献流程；领域负责人定期把战略输入带进优先级讨论；往下逐层是工作流负责人、用例负责人与产品负责人、专家与开发者、最终用户。早期旅程中，一个项目经理统管全部也很常见。
结语：一套把能力翻译成价值的流水线
把五个部分连起来看，Palantir 的用例方法论其实是一条标准化流水线：用五段式把业务诉求钉在用户决策上，用四组件把需求蒸馏成对象模型、生命周期、增富与界面，用先地基后高级的顺序安排建设，用七种角色把责任切干净。
对正在做ERP、数字化平台、数据中台和业务应用的团队，这份文档值得对照自查的点不少：我们的需求文档落点是决策还是功能清单？我们的方案设计有没有对象模型和状态机这样的硬核中间产物？我们的建设顺序是跟着业务声量走，还是跟着依赖层级走？我们的角色定义，能不能让投资回报、执行与采用各有人扛？
用例不大，方法不小。把一个个用例做扎实，平台的价值才真正长出来。
参考资料：Palantir Foundry 官方文档 Use Case Life Cycle 系列（Overview、Distilling Functional Requirements、Solution Design、Sequencing Development、Use Case Roles，palantir.com/docs/foundry/use-case-life-cycle/）。
提醒：请朋友们将“智见AI视界”加“星标”，觉得写得好就点击右下角“拇指”和“收藏”哦，不然会慢慢收不到文章推送~
关联阅读