他山之石
镔鑫数研院学习Palantir先进模式
对内部转型、能力提升与目标转换的思考与学习
前言
近期，数研院组织学习了Palantir模式的相关文章，文章深入剖析了这家"伪装成软件公司的咨询公司"如何通过独特的工作模式帮助企业实现数字化转型。文章的主旨是：企业软件的价值来自对业务的深度理解，数据治理是AI的基础设施，而AI Agent的上限，由底层数据的质量和语义丰富度决定。
这篇文章与我们数研院目前正在强化的几个方向高度契合——价值挖掘与对话能力、先锋组快速开发能力、搭配Agent的持续运转与衍生分析。以下是数研院伙伴们的学习思考与总结。
一、业务提升，价值导向
文章引用：Palantir的"前线部署工程师"（FDE）模式要求工程师每周3-4天驻场客户，这不是咨询，而是一种获取隐性知识的方法。
许超（高级应用工程师）：
先锋组在近几个月的精益系统开发中，在全栈能力（业务、技术）上都有所提升，尤其在技术侧基本实现前后端全栈式开发。但是在业务能力侧，基本聚焦于个人精益系统侧业务知识，很少深入现场与用户深度对话，对业务理解的深度上需要持续提升和学习。客户提供的"需求列表"是扁平化的、失真的，只有亲身嵌入业务流程，才能理解真正的痛点。软件开发人员不应只做需求的被动接收者，要主动走到用户面前，学会说"客户的语言"。
提升策略：
- 后续开发人员可以通过解决、总结各业务域的系统问题，形成根因分析，逐步了解和学习业务知识，提升与业务针对需求的对话能力。
- 把握生产现场学习的机会，建立业务感知，结合开发需求学会主动思考和延伸，避免成为被动接受方。
二、敏捷开发，效率为先
文章引用：FDE团队出现在客户现场，通常在1-2周内交付可用的软件，这让习惯于年度"瀑布式"交付的客户大为震惊。
许超（高级应用工程师）：
目前我们开发组内部已经具备并正在实施敏捷开发模式，复盘敏捷开发流程中的环节，整理并梳理内部敏捷开发标准流程规范（需求→数据→开发→迭代），尽可能提高敏捷效率。在企业软件领域，能快速交付可用产品，就能建立别人难以复制的信任优势。
三、数据集成是企业AI的核心基础设施
文章引用：数据集成（Data Integration）才是Palantir真正的核心竞争力，而不是算法或UI。
许超（高级应用工程师）：
数据集成不是AI的"准备工作"，它本身就是AI能力的组成部分——模型是引擎，数据集成是燃料供应系统，没有后者，引擎再好也跑不起来。目前我们推进数据字典、系统索引、第零章、标注数据集等工作，都是逐步在提升AI Agent能力的上限。
薛泽宇（大数据工程师）：
文章第3节中说"FDE所做的另一件关键事情是数据集成"。而Agent的衍生分析前提是数据集成、数据整合。Agent要能持续运转，前提是它能稳定访问到干净、可信的数据。这让我想到我们现在正在做的"第零章"还有数字化管理平台等，就在做这样的事儿。而我们在做的数据资产管理平台，包括数据中台，也是在把这件事，越来越简单化、效率化、条理化。
四、Agent需要业务本体（Ontology）而不只是原始数据
文章引用：Palantir AIP的核心设计哲学是：让LLM操作的不是原始SQL或文件，而是有业务含义的本体对象（如"工单"、"质量问题"、"零件"），这大幅降低幻觉风险、提升可解释性。
许超（高级应用工程师）：
构建企业AI Agent时，应在数据层和LLM之间插入一个语义/本体层，而不是让Agent直接面对原始数据；企业Agent不应该只做通用RAG，应结合业务本体做结构化检索，才能在实际工作流中可靠决策。
五、价值导向的需求挖掘
王吉勇（副院长）：
Palantir所需能力并非单一技术或执行能力，而是业务与技术深度融合的复合能力。目前公司业务提的需求往往是"功能及其如何实现？"没有思考"为什么做？希望通过系统建设实现哪些价值？"（如指标优化、成本挖潜、效率提升、费用降低等），未来应该有效引导业务问题导向与价值导向提出需求，同时数研院伙伴应该多去现场了解业务，发掘或评估需求，推动数智化工具提升公司核心竞争力。
六、面对业务根因的拆解能力
王吉勇（副院长）：
法国的飞机制造商最大的问题是空客A350量产效率低，Palantir团队不是停留在"客户需要一个管理系统"的表层理解，而是从数据集成、工单管理、质量追溯寻找根因，再快速构建端到端解决方案，最终帮助推动A350制造的激增，并成功将制造速度提高了4倍，同时保持了空客的高质量标准。
目前数研院每天都会接到大量的问题（飞书群、微信、电话），如果简单处置，表面上是解决了，但同样问题大概率会重复发生，只有多问几个"为什么"、多做一些问题拆解，才能找到根因，通过有效举措制定并标准化，确保问题不再发生。
七、精细化工具敏捷开发与迭代
王吉勇（副院长）：
Palantir工程师（FDE）倾向于编写能够快速完成工作的代码。能用极简代码、临时解决方案，在1-2周内搭建出客户可直接使用的产品原型，区别于传统软件公司"瀑布式开发"的长周期模式；核心目标是"快速提供价值"，让客户看到实际效果。
外部合作的IT/自动化建设往往周期长、问题多、迭代缓慢，数研院先锋组近期完成的数字化系统效率持续提升，背后不只是编写代码，而是深入业务并基于迭代需求持续赋能。未来项目应首先考虑自研，若外购需采用合作模式在保证数据和代码自主权的前提下，提升内部团队开发及问题处理能力。
八、Agent业务流程的持续运转及多场景衍生分析能力
王吉勇（副院长）：
Agent并非一次性分析工具，而是能嵌入企业核心业务流程，实现持续的自动化运转，比如制造场景中实时监控生产数据、预警质量问题，成为企业业务的"智能助手"。另外，Agent能从核心业务分析中，衍生出更多关联场景的价值，比如从空客生产效率分析，衍生出供应链优化、零件库存管理的分析，实现"一次数据集成，多次智能衍生"，最大化数据价值。
随着BXAI Agent在公司的持续实践，一方面逐步让分析结果辅助各级人员应用变现，二是拓展公司典型应用场景，通过训练提升Agent对业务的理解、分析及建议质量，通过封装skill实现推广与效率最大化。
九、从"数据搬运工"到"业务翻译官"
于祥（大数据工程师）：
Palantir的工作模式，PD（产品开发工程师）是核心，FDE（前沿部署工程师）亦是核心，两者相辅相成，快速迭代产品，帮助企业业务赋能。Palantir成功的点在于解决了企业最痛的"数据孤岛"和"知行分离"问题。
钢厂的这种工作模式，对于钢厂的IT部门来说，非常具有思考方向。我们IT人员未来肯定要具备"将业务逻辑翻译为数据逻辑"的能力。
出发阶段：
- 目前我们开发的"第零章"为司提供了一部分数据底座，也为快速开发打下了一定的基石。
- 依托BXAI生成第零章分析报告，降低了技术门槛，让业务人员（或管理层）通过自然语言获取生产经营的描述、诊断性的分析，契合了翻译业务的方向。
- "第零章"开发和BXAI分析基于底层业务需求，数据口径统一、来源真实、质量可靠，一定程度上消除了AI幻觉。
前方的路——IT人员：
- 深入一线，从"数据搬运工"到"业务翻译官"；着眼痛点，缩短开发周期，解决急难险重问题。
- 不仅仅是做好开发，还要积极挖掘数据价值与提升业务理解能力，将复杂的业务分解为可计算的单元和数据。
- 快速原型、敏捷迭代，解决问题。
前方的路——AI Agent：
- 基于"第零章"，让AI认知业务对象，而不仅仅是字段（在AI与数据表之间加一层"语义层"）。比如：告诉AI，"炉温"过高不仅仅是数字变大，而是"加热炉异常"这个对象的状态改变。
- 决策建议后，可以借助skill工具，给出决策建议的同时，梳理对应的处理流程，发送给对应的岗位人员（飞书或邮件）确认操作指令，岗位人员仅需判断决策及操作是否合理，即可让AI一键处理问题。
- 数据融合：目前的第零章只是结构化数据，后续可以引入非结构化数据（视频、音频等），利用多模态大模型，结合两者数据，给出更精准的归因分析。
- 安全与治理：确保"人机回环"环节、建立信任机制。即AI生成的报告或决策，需要对应岗位专家确认，同时建立一套机制来评估AI的分析是否准确。防止AI为了"凑报告"而强行解释数据。
十、组织能力的成功
薛泽宇（大数据工程师）：
Palantir的成功，本质上不是一家"软件公司"的成功，而是一种组织能力的成功（伪装成软件公司的咨询公司）。它验证了我们数研院目前在强化的几个方向是一条经过实战检验的路径。
Palantir的FDE（前线部署工程师）之所以能成事，是因为他们不是"传话筒"，而是能钻进客户业务里、重新定义问题的人。传话能力只是起点，能拆解业务，甚至重新定义问题，给出执行方案才是质变。
先锋组的价值在于快速验证业务可行性、摸清价值点、为后续规模化铺路。写代码是手段，不是目的。
十一、"环境是稀缺的"——深入业务与快速验证
康宝明（智慧经营组经理）：
看完这篇文章我觉得我们现在做的事情与Palantir是一致的，"深入业务、快速验证、数据底座、Agent分析"方向是对的，但是痛点也是存在的。
另外文章里提到了"一群持怀疑态度的人非常关心，他们想争论世界将走向何方，以及软件如何融入其中"，我觉得我们团队现在也逐步有了这种氛围——大家在群里讨论技术、分享文章，其实就是在做这件事。
"环境是稀缺的"，精益办代表的深入理解现场业务及价值：
经常"先上飞机，后问问题"，到了客户那儿就在车间里晃悠、跟工人聊天、搞清楚这摊事到底是咋运作的。他们的FDE不是派出去做实施的，而是派出去扎根在业务里的。这让我想到咱们有时候去现场调研，待个半天一小时就回来了，回来之后写需求文档，其实很多细节根本没摸到。我们是要真实深入了解业务同时获得中业务流程的痛点/价值，是不是也可以多问几个"为什么"，而不是只盯着"怎么做",然后利用这些知识来设计真正解决问题的软件和系统。
"允许试错"，先锋组代表的快速提供价值：
文章中提到：FDE倾向于编写能够快速完成工作的代码，甚至留下技术债务和hack解决方法；我觉得这个做法有有二面性，但"先跑起来，再优化"的思路与咱们现在先锋组一样，——第一版跑通了或者一二周先交付一个能用的东西，只要业务认、价值在，让业务先用起来、看到效果，然后再迭代和慢慢打磨；
"样板"沉淀，精益办与先锋组的互补与复用：
精益办的深度理解和先锋组的快速响应，不是对立而是互补；文章里还提到：FDE和PD分工协作，FDE在一线打样，PD把打样的东西产品化。我们现在也是这样的分工，之前我们做了很多"一次性的活"解决完成就过去了；精益办的深入挖掘为先锋组提供"往哪个方向快速实现"的方向，先锋组的快速交付模式为精益办提供"真实业务反馈"工具，先锋组和精益办打的样能和思路要沉淀、固化下来并辐射到部门每一位员工，成为部门及大家后续工作的模板；
Agent和"第零章"最难的不是技术，是数据：
现在做第零章，技术上没问题，但最难的不是技术，是数据能不能拿到、能不能拿全、能不能实时。把数据理顺，这一点比写代码更需要下功夫。而且现在我们的BX Agent更多还是读数据出报告，先把数据底座打好，让Agent能稳定访问干净、可信的数据，再来讨论文章中提到的"端到端的解决方案"；找数知识第一步，更要基于业务找数，什么样的数据能真实反映业务流程的关键节点？哪些数据是业务决策的"锚点"......
方向是对的，那么接下来就是踏踏实实的干！
群聊讨论实况
@吴明德：这篇文章得多看几遍 @王吉勇 @许超 @康宝明 @薛泽宇 @于祥 @王兴超 很棒的文章，这也符合我什么我希望大家强化：
（1）价值挖掘、业务分解、对话能力，而不是只有传话能
（2）先锋组的快速开发能力，而不是只编程
（3）搭配agent的持续运转衍生分析。基本就是我理解的palantir需要的能力！这篇文章希望@的几位试着发表一下看法分享。
结语
Palantir的模式为我们揭示了一个核心真理：在企业数字化转型中，技术是手段，不是目的。 只有深入业务、理解业务、重新定义问题，才能真正为企业创造价值。
数研院正在这条路上探索前行，从价值挖掘到快速开发，从数据治理到Agent智能，我们相信方向正确，便只顾风雨兼程。