附录：参考来源与官方资料

Note

本附录的用途与说明 本书正文中凡标注"据 Palantir 官方""可查证事实"之处，其原始出处集中列于此，供读者溯源核对。请注意以下边界：

• 本附录为引用来源清单（含关键原文摘录），非官方文档全文转载；完整内容请以所列 URL 的原始页面为准。

• 所列资料截取于本书编写时点，官方页面可能更新或调整，URL 亦可能失效，引用时请以最新官方发布为准。

• 本书正文中的四阶段方法论、各类交付物/Gate/SOP 清单属本书的提炼与实操建议（见第三篇 How 总纲说明），不在本附录官方来源之列——本附录仅收录可溯源的第三方/官方资料。

附录 A：Palantir 官方角色定义（招聘 JD 节选）

Note

关于角色序列命名的说明：经核查 Palantir 官方招聘系统，其岗位序列（Team）中与 FDE 直接相关的三个是 Delta（驻场工程序列，含 FDSE、Forward Deployed AI/Infrastructure Engineer 等）、Echo（驻场策略序列，即 Deployment Strategist）、以及 Engineering（含 Site Reliability Engineer、Forward Deployed Enablement Engineer 等保障/使能角色）。本书"技术执行 / 业务策略 / 基础设施"三角色，分别对标 Delta / Echo / Engineering。 需特别说明：业界常把基础设施保障角色称为"Baseline"，但"Baseline" 并非 Palantir 官方公开使用的序列名——官方对应的是 Engineering 序列（及 Delta 序列下的 Forward Deployed Infrastructure Engineer）。本书如提及"Baseline"，均指此通俗代称。

A-1　Deployment Strategist（部署策略师，对标本书"业务策略工程师"，序列：Echo）

• 来源：Palantir Technologies 官方招聘页（Lever 平台）
• URL：https://jobs.lever.co/palantir/e0ab8226-b928-4e3a-bf87-08fe7b1ea595
• 性质说明：此为 Palantir 某次公开招聘的岗位描述（JD），代表该角色的官方定位，非"角色手册"全文。
• 关键原文摘录：

  "At its core, the Deployment Strategist role centers around using data in operational and real-world action... Deployment Strategists are responsible for turning that hunch into reality." "Your mission is to synthesize disconnected streams of thought into an understanding of what the most important problem is, what the data means, what the product needs, what users are motivated by, and where the impact could be." 职责含："Work with Forward Deployed Engineers to integrate the data into a stable and extensible pipeline"、"Embed with our Software Engineering and Product Design teams to incorporate what you saw in the field into cross-Palantir product offerings"。 硬性要求："Experience with programming, scripting or statistical packages (e.g. Python, R, Matlab, SQL)"。 序列归属：页面标注该岗位属 Echo track。

A-2　Forward Deployed Software Engineer / FDSE（对标本书"技术执行工程师"，序列：Delta）

• 来源：Palantir Technologies 官方招聘页（Lever 平台）
• URL：https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850
• 关键原文摘录：

  "At Palantir, the Forward Deployed Software Engineer (FDSE) role isn't just a job title: it's the blueprint. We pioneered this unique position, embedding talented engineers directly with our customers to tackle their most pressing challenges head-on." "FDSEs work side by side with our customers, rapidly understanding their toughest issues; architecting and building solutions that leverage business-critical data and the latest advancements in AI to solve them." 技术要求："Strong coder with demonstrated proficiency in programming languages such as Python, Java, C++, TypeScript/JavaScript, or similar." 序列归属：页面标注该岗位属 Delta track。

A-3　基础设施工程师（对标本书"基础设施工程师"；官方归 Engineering 序列，业界俗称 Baseline）

• 来源：Palantir Technologies 官方招聘页（Lever 平台）岗位列表 https://jobs.lever.co/palantir（按 Team = Engineering 筛选）
• 官方序列实况：Engineering 序列下与"基础设施保障 / 系统可靠性 / 驻场使能"职能相关的真实岗位包括 Site Reliability Engineer、Forward Deployed Enablement Engineer（Customer Success） 等；此外 Delta 序列下另有 Forward Deployed Infrastructure Engineer 承担驻场基础设施建设。本书"基础设施工程师"这一角色综合对应上述职能。
• 代表岗位（驻场基础设施，序列 Delta）— Forward Deployed Infrastructure Engineer
  • URL：https://jobs.lever.co/palantir/72e51928-07f0-4be0-aae5-0ae6956a4846
  • 摘录：

    "We're looking for Forward Deployed Infrastructure Engineers who can help us build, operate, and maintain high-performance, scalable, and reliable services for Palantir platforms, products, and deployments." 职责含："Deploy new Palantir products across many production environments and perform migrations"、"Handle support and operations... monitoring and alerting, configuration management, and upgrades"。

• 说明："Baseline" 为业界通俗代称，非 Palantir 官方序列名。

A-4　平台工程师（Dev）与 FDE 负责人（Lead）的来源说明

• 两者均无公开招聘 JD，附录 A 因此不为其单列 JD 摘录：
• 平台工程师（Dev）：依据 Palantir 官方博客对 "a traditional software engineer, or 'Dev'" 的表述（见第 10 章 10.1 对标表）；Dev 属后方产品/后端工程序列，非前线 FDE 编制。
• FDE 负责人（Lead）：为 Palantir 部署团队的内部角色（官方博客提及 Lead 承担带教/统筹），非公开招聘 title。
• 对应正文：第 10 章 10.1"五大核心角色"对标表（其中平台工程师与 FDE 负责人为本书扩展编制，详见该表说明）。

附录 B：Palantir 官方方法论文档

B-1　用例交付的三要素框架：Outcome / Data / Tools

• 来源：Palantir Foundry 官方文档《Delivering a use case》
• URL：https://www.palantir.com/docs/foundry/getting-started/delivering-a-use-case
• 对应正文：2.3 节"启动期用例筛选三要素"。
• 关键原文摘录：

  "To choose the right path, you will need to balance three factors: the desired outcome, the available data, and platform tools." "instead of starting with a need to build a sales dashboard, seek to understand what decisions and outcomes your work might enable"（以结果为导向）。

B-2　用例生命周期（Use Case Lifecycle）

• 来源：Palantir Foundry 官方文档《Use case lifecycle》
• URL：https://www.palantir.com/docs/foundry/use-case-life-cycle/overview
• 对应正文：第三篇 How 总纲对"四阶段来源属性"的说明。
• 官方阶段划分：Distilling functional requirements（提炼功能需求）→ Solution Design（方案设计）→ Sequencing development（开发排序）。
• 关键原文摘录：

  "A use case is a time-bound effort by a dedicated team to deliver new capabilities on the platform for a set of users."

B-3　平台采纳四阶段（Foundry Adoption）

• 来源：Palantir Foundry 官方文档《Foundry adoption》
• URL：https://www.palantir.com/docs/foundry/foundry-adoption/program-overview
• 官方四阶段：Phase 1 聚焦用例（Focus on use cases）→ Phase 2 建设基础设施以解锁规模化 → Phase 3 通过自治实现平台增长 → Phase 4 超速增长（Hypergrowth）。
• 说明：这是 Palantir 官方的采纳分期，与本书采用的 Discovery/Prototype/Build/Scale 属不同命名体系（见第三篇 How 总纲说明）。

B-4　Ontology（本体层）官方定义

• 来源：Palantir Foundry 官方文档《Ontology overview》
• URL：https://www.palantir.com/docs/foundry/ontology/overview
• 对应正文：3.1 节 Ontology、4.4 财富 500 强案例的 Writeback/Actions。
• 关键原文摘录：

  "the Ontology serves as a digital twin of the organization, containing both the semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security)"。 Action types "orchestrate decision-making processes that connect to your existing systems"（支持写回源系统，含 Webhooks）。

B-5　FDE 方法论的官方比喻："人肉反向传播"

• 来源：Palantir Foundry 官方文档《Architecture center》
• URL：https://www.palantir.com/docs/foundry/architecture-center/overview
• 对应正文：2.3 节"通用性是训练出来的"。
• 关键原文摘录：

  "Palantir's platforms and offerings are continuously developed through the methodology of Forward Deployed Engineering. This is the human equivalent of backpropagation..."

附录 C：案例与财务数据来源

C-1　空客 Airbus / Skywise

• Palantir 官方（2026-02-10 新闻，businesswire 转载）：https://www.businesswire.com/news/home/20260210301221/en/

  "Since 2015, Palantir's team in France has worked alongside Airbus to deliver and evolve the Skywise platform."

• Airbus 官方 Skywise 平台页：https://www.skywise.com/en（Skywise 为开放航空数据平台，覆盖航司、OEM/供应商、MRO；参与方含 Delta、GE Aerospace 等）。
• 对应正文：4.1 案例。

C-2　BP（英国石油）

• Palantir 官方（2024-09-09 五年战略协议，businesswire）：https://www.businesswire.com/news/home/20240909534283/en/

  双方合作"build on a decade of deep collaboration that has created a firm foundation for bp's oil and gas production operations"。

• 对应正文：4.2 案例（油气生产运营，非能源交易）。

C-3　NHS（英国国民健康服务）COVID 相关

• 综合来源：Wikipedia "Palantir" 词条（含内联一手引用）：https://en.wikipedia.org/wiki/Palantir

  "Palantir was one of four large technology firms to start working with the NHS on supporting COVID-19 efforts through the provision of software from Palantir Foundry." "Palantir also developed Tiberius, a software for vaccine allocation used in the United States." "In November 2023, NHS England awarded Palantir a seven-year contract valued at £330 million to design and operate a Federated Data Platform..."

• 对应正文：4.3 案例。

C-4　美国陆军 Army Vantage

• Palantir 官方 Army Vantage 页：https://www.palantir.com/army-vantage

  "Since 2018, Army has leveraged Palantir's software... Vantage is the core software system enabling the Army Data Platform."

• Palantir 投资者关系（2024-12-18，扩展 Army Vantage 合作，合同 $400.7M、上限 $618.9M）：https://investors.palantir.com/
• 美国海军近 10 亿美元独立合同（2024-11）：见 Wikipedia "Palantir" 词条内联引用。
• 对应正文：4.5 案例（注意陆军与海军为两笔不同合同）。

C-5　Palantir 财务数据（毛利率 / 经营利润率 / 净利率 / 营收）

• 来源：Palantir（NASDAQ: PLTR）公开财报，经 stockanalysis.com（数据源 Fiscal.ai）整理：https://stockanalysis.com/stocks/pltr/financials/
• 对应正文：2.4 节财务证据表（截至 2025 财年）。

C-6　Palantir 净收入留存率（NRR）与单客户收入

• NRR：FY2021 总体 131%、美国商业 150%、政府 146%；FY2022 约 115%；2024 年约 118%。
  • 官方来源：Palantir《Accompanying Remarks – 2021 Financial Results》https://investors.palantir.com/files/Accompanying%20Remarks%20-%202021%20Financial%20Results.pdf（含 131% / 146% / 150%）；FY2022 数值经权威财经媒体 The Motley Fool 引 Palantir 投资者材料报道。
• 单客户收入：每政府客户年均收入 2020 年 680 万美元 → 2021 年 1000 万美元（出处同上 Accompanying Remarks）；Top 20 客户近十二个月平均收入 2024 年 6460 万美元 → 2025 年 9390 万美元（出处：Palantir FY2025 10-K，https://investors.palantir.com/）。
• 对应正文：2.4 节"落地生根、卖能力"的补充证据。

C-7　4.4 匿名"财富 500 强"案例的说明：该案例（Writeback / Actions 场景）采用匿名处理，无独立公开来源；其方法论依据见 B-4（Ontology 官方文档），业务场景描述为本书基于 Palantir 公开能力（Writeback/Actions）的提炼，引用时请按第 4 章章首"数据严谨性说明"处理。

附录 D：中国云厂商实践参考来源

Note

本附录的性质：第 15 章对四家中国云厂商模式的描述（如"铁三角""TAM 模式""OTSS→FDE 演进"等）属于业界通行的分析归纳，并非逐条引自某篇官方文档；其新增的"2026 年 FDE 生态三类新玩家"（大模型厂商、数字化服务商、云厂商能力外溢）基于 2026 年的公开报道与厂商发布。因此本附录提供的是相关产品的官方页面与权威二手来源，供读者按图索骥、核对基本事实；凡本书中的"模式命名/对比结论"，均为本书基于公开信息的提炼，非厂商官方定性。所列 URL 截至编写时点有效，可能随时间失效。

阿里云

• DataWorks（一站式大数据开发治理平台） — 官方：https://www.aliyun.com/product/dataworks/。页面明确"以阿里巴巴集团大数据建设方法论为基础"。
• Dataphin（智能数据建设与治理） — 官方：https://www.aliyun.com/product/bigdata/dataphin。页面明确其为"阿里巴巴十余年内部实践及方法论的产品化输出"，并点名依托 OneData 方法论。
• OneData 方法论（OneModel/OneID/OneService） — 线上以上述 Dataphin 官方页间接佐证；概念完整溯源建议参阅权威书籍《大数据之路：阿里巴巴大数据实践》（阿里巴巴数据技术及产品部 著）。注：阿里云官网无 OneData 三件套的独立官方专页。
• Quick BI（智能商业分析） — 官方：https://www.aliyun.com/product/quick-bi。
• 可引用案例（对应 15.6）：雅戈尔×Quick BI 官方客户案例页 https://www.aliyun.com/customer-stories/retail-2025-youngor（16 系统→1 平台）；森马×DataWorks 数据中台（阿里云开发者社区官方博客）；德清县城市大脑 2026 运维（湖州绿色采购服务平台公告）。
• 对应正文：15.1 节。

华为云

• DataArts Studio（数据治理中心 / 数据使能） — 官方：https://www.huaweicloud.com/product/dayu.html。页面明确"结合华为数据之道方法论""完整的数据治理生产线"。
• "铁三角"（AR/SR/FR）组织模式 — 华为官网无系统介绍此模式的公开专页；权威溯源建议参阅公开出版书籍《华为铁三角工作法》（范厚华、张力 著，中信出版社）、《华为团队工作法》（吴建国 等著）。
• 可引用案例（对应 15.6）：CMPak（巴基斯坦）智慧中台官方案例页 https://www.huaweicloud.com/intl/ja-jp/cases/cmpakinpakistan.html；华为云×通汇诚泰数据中台（IT168 等报道）；海通证券鲲鹏改造（华为企业业务案例库）。
• 对应正文：15.2 节。（注：正文提及的"工业互联网平台回注"为泛指华为云工业互联网能力，不特指某一已下线产品名。）

腾讯云

• 技术服务与支持体系（含驻场服务） — 官方：https://cloud.tencent.com/act/event/service-support。页面列出"专属技术支持…1V1 的驻场服务""护航服务"等。注："OTSS"为业界/内部叫法，腾讯云官方页面未使用该缩写，正文用它仅作概念指代。
• 智能体开发平台 ADP（原大模型知识引擎升级形态） — 官方：https://cloud.tencent.com/product/lke。提供 LLM+RAG、Workflow、Multi-agent 等能力。
• 可引用案例（对应 15.6）：广东政务智能中枢"湾擎"上线（2026-06，广东省主导，"全国首个"为媒体口径；腾讯云为共建企业之一，非独家/主导，来源：羊城晚报 https://news.ycwb.com/ikimvkmtjm/content_54179777.htm、东方财富 https://finance.eastmoney.com/a/202606243781769918.html 等）；百望股份×腾讯云共建 AI 智能体（证券日报等上市公司公告）；FDE 工程师认证与 FDE 合作伙伴招募（2026-09，覆盖场景理解/交付实施/安全合规三维度，来源：DoNews、福建日报等报道）。
• 对应正文：15.3 节。

火山引擎

• 火山引擎官网（AI 云：大模型 / 大数据 / 推荐算法） — 官方：https://www.volcengine.com/
• 火山方舟（大模型服务平台） — 官方：https://www.volcengine.com/product/ark
• 豆包大模型 — 官方：https://www.volcengine.com/product/doubao
• 可引用案例（对应 15.6）：奇瑞汽车×火山引擎战略合作、豆包接入"小奇同学"（2026-04，证券时报 https://stcn.com/article/detail/3818772.html）；超 50 个汽车品牌采用豆包（C114 等报道）；东风汽车×火山引擎战略合作。
• 对应正文：15.4 节。（注：正文提及的"与头部咨询机构联合交付""千人级 FDE 铁军"为对其模式的概括描述，本书编写时未获得可公开引用的一手权威报道佐证，读者引用时请自行核实。）

---

2026 年 FDE 生态新增来源（第 15 章 15.5 / 15.7）

以下为新增"FDE 生态三类新玩家"与第 13 章第六大挑战相关内容时使用的公开来源。凡涉及厂商表述者以官方发布为准；标注"媒体口径"的措辞，请勿当作厂商官方唯一性声明。生态动向变化较快，引用前请自行核对最新公开信息。

D-1　月之暗面 Kimi 企业合作伙伴"登月计划"（大模型厂商以 FDE 模式做末端部署） - 首批签约伙伴：中软国际（00354.HK）、金山云（03896.HK）、华胜天成（600410.SH）、亚康股份（301085.SZ）、亚信科技（01675.HK）。 - 官方口径：以 FDE 模式与系统集成商共建前置部署工程师队伍，进入客户现场交付；将以开放合作方式向伙伴输出模型能力与工程方法论。 - 来源：21 世纪经济报道（2026-09-10）；腾讯新闻同题报道（2026-09-10）。 - 媒体口径提示："国内首家采用 FDE 模式进行 AI 末端部署的大模型公司"为媒体报道措辞。

D-2　中软国际与月之暗面共建 FDE 创新实验室（Token 分成 + 联合创新） - 来源：证券时报（2026-07-20）；中软国际（00354.HK）自愿性公告。

D-3　数字化与运营商服务商的 FDE 体系（第二类新玩家） - 微盟推出企业专属 AI 定制服务"星程"，通过 FDE 做交付（钛媒体、北青网，2026-09-08）。 - 赛意信息以"FDE 体系破局交付困局"（东方财富网，2026-08-13）。 - 中国电信"智惠工程师"打通 AI 落地"最后一公里"（科技日报，2026-09-11）。

D-4　阿里云 FDE 对外表述（第 15 章 15.1.1 补充锚点） - 《阿里云 FDE 专家让 AI 真正进入产线》（阿里云政企业务站，2026-05-27）。 - 旁证：阿里云开发者社区《从百炼到 FDE：六大门派里，工程师该选哪一段？》（2026-08-13）按"身份"将国内 FDE 玩家划分为模型厂 / 云厂 / AI 原生 / 咨询 / 外包等类别（用户投稿内容，非阿里云官方观点）。

D-5　FDE 市场规模、薪酬与岗位增长（第 13 章 13.7 使用） - 领英（LinkedIn）2026 年 1 月《全球劳动力市场趋势洞察报告》：FDE 新增岗位自 2023 年至 2025 年增长 42 倍；同期 AI 工程师岗位增长 13 倍；过去两年企业新增至少 130 万个 AI 相关岗位。 - 国内招聘薪酬（招聘平台公开信息）：字节跳动"豆包 AI 大模型 FDE" 3.5 万至 7 万元/月 × 15 薪；蚂蚁数科 B 端 FDE 4 万至 6 万元/月 × 15 薪；智谱华章 FDE 负责人 6 万至 8 万元/月。 - 海外对标：OpenAI FDE 年薪 16.2 万至 28 万美元 + 股权（纽约）；Anthropic FDE 年薪 20 万至 30 万美元。 - 从业者口径：国内"年薪百万"集中于核心顶尖人才，非行业平均；多数高职级 FDE 年包 40 万元以上。 - 来源：中新经纬《年薪百万，"AI 圈最火岗位"，FDE 到底是干嘛的？》（2026-06-05，中国经济网转载）。

D-6　对 FDE 模式的质疑（第 13 章 13.8 使用） - Gartner《2026 中国数据、分析和人工智能技术成熟度曲线》将"前沿部署工程师（FDE）"标注为 "X"。 - 三条中国适配障碍：① 缺少能同时具备高层触达、客户筛选、长周期投入能力的厂商；② 中国 IT 项目制采购（范围/数据/预算/验收标准前置）与 FDE 强绑定目标、持续探索边界的模式冲突；③ 知识产权边界难以界定。 - 替代建议：企业可先考虑内部"上下文工程"岗、低代码/低门槛平台，或由厂商与应用厂商延续交付。 - 来源：至顶网 ZDNet《Gartner：代理式 AI 最热，FDE 被打"X"，上下文决定落地深度》（2026-09-03）；澎湃新闻同题报道。 - 术语提示："被打 X"为媒体对成熟度曲线标记方式的通俗解读，非 Gartner 官方中文表述。

D-7　FDE 项目间资产沉淀的现场观察（第 13 章 13.4 / 13.7 佐证） - PEC 2026 AI 创造者大会圆桌观察：项目越做越多、人力无法同比例增加；一支 FDE 团队服务完一个客户后，第二个客户能否少花力气，取决于项目之间沉淀的资产而非项目本身资产。 - 来源：至顶网 ZDNet《PEC 2026：FDE 走红背后：企业 AI 正在重写交付方式》（2026-09-12）。

政策、运营商与关键行业来源（第 14 章、第 16 章、第 13 章 13.1）

本组来源服务于 v1.19 新增的第 14 章（运营商）、第 16 章（关键行业）与第 13 章 13.1（政策窗口）。政策以原文为准；解读文章注明为作者观点；企业披露的指标一律视为企业口径。

D-8　政策原文与地方落实 - 工业和信息化部办公厅《关于开展人工智能应用服务商培育专项行动的通知》（工信厅科函〔2026〕414 号，2026-08-27 成文、2026-08-31 发布）：https://www.miit.gov.cn/zwgk/zcwj/wjfb/tz/art/2026/art_6fbc038bf15c445ab53b2a94a3f9d4e4.html - 广东省工业和信息化厅落实通知（2026-09-11）：https://gdii.gd.gov.cn/gkmlpt/content/4/4956/post_4956821.html - 浙江省经济和信息化厅落实通知（2026-09-21）：https://jxt.zj.gov.cn/col/col1229886900/art/2026/art_b2e4981e2f23402fb6fc502da9cdcd90.html - 江西省工业和信息化厅落实通知（2026-09-22）：http://gxt.jiangxi.gov.cn/jxsgyhxxht/cydt/content/content_2102216256771403776.html - 解读观点：王春晖《人工智能应用服务商培育：FDE 模式的中国化路径》（人民邮电报，深圳政府在线转载，2026-09-10）：https://www.szzg.gov.cn/2026/xwzx/szkx/202609/t20260910_5369965.htm——作者观点，非文件原文。 - 国务院国资委"AI+"专项行动进展（国新办发布会，2026-01-28，中国发展网报道）：http://www.chinadevelopment.com.cn/news/zj/2026/01/1980792.shtml - 合规依据：《生成式人工智能服务管理暂行办法》https://www.gov.cn/zhengce/202311/content_6917778.htm；《促进和规范数据跨境流动规定》https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm

D-9　运营商平台（第 14 章） - 中国电信：天翼云息壤官方定义 https://www.ctyun.cn/document/10813361/11066629；星辰超级智能体 TeleAgent 操作手册 https://www.teleai.com.cn/doc/7czHMDStGDQr1JsAMKcZ/Gik5VRTWAer7xDrqNBS7；星辰智能体平台 FAQ https://www.teleai.com.cn/doc/xPAhsmN9P4GC3Umku1Us/wjiG4MAUZXS7Ucyr3ejO；星海 AI-Studio 官方介绍 https://www.teleai.com.cn/learnMore/newsDetail?newsId=777afbc640fc43e79434d724a7a3ba73；星海智能动态本体平台发布报道 https://news.bjd.com.cn/2026/08/29/11938253.shtml - 中国电信北京公司智惠工程师：科技日报 https://www.stdaily.com/web/gdxw/2026-09/11/content_579510.html；北京日报客户端 https://news.bjd.com.cn/2026/09/10/11953903.shtml - 中国联通：星罗与京元发布（科技日报）https://www.stdaily.com/web/gdxw/2026-09/13/content_580152.html；联通发布（通信世界网）http://www.cww.net.cn/article?id=613564；元景万悟开源仓库 https://github.com/UnicomAI/wanwu - 中国移动：九天 AI OS 发布（新华网）https://www.news.cn/info/20260509/dd54a0289d1048448861377f9468e445/c.html；2026 产品体系（中国网）http://szjj.china.com.cn/2026-09/03/content_43485939.html；梧桐 KnoVa 案例转载 https://www.modb.pro/db/2043932649513906176 - Palantir 对标基线：集成平台架构 https://www.palantir.com/docs/foundry/architecture-center/platforms/；安全模型 https://www.palantir.com/docs/foundry/security/overview/

D-10　关键行业 FDE 实践（第 16 章） - 中国石油昆仑数智 × 阿里云炼化工业智能体（上海证券报，2026-07-18）：http://finance.sina.com.cn/roll/2026-07-18/doc-iniifhty3927957.shtml - 石化盈科 × 火山引擎"工具底座 + 实操培训 + FDE 驻场"（火山引擎稿，2026-09-20）：https://app.myzaker.com/news/article.php?pk=6aafc1cb8e9f090b9b7ad00b - 科大讯飞 × 国家能源集团智慧招采（界面新闻）：https://m.jiemian.com/article/14893334.html - 明略科技 2026 年中期业绩与 FDE 路径（界面新闻）：https://www.jiemian.com/article/15040533.html；收购普联软件（东方财富财富号，作者观点）：https://caifuhao.eastmoney.com/news/20260901100122539147830 - 宇信科技银行 FDE 团队（南方财经，2026-09-03）：https://finance.eastmoney.com/a/202609033864252617.html - 阿里云"点金"金融智能体平台（经济日报，2026-06-17）：http://www.jingjiribao.cn/static/detail.jsp?id=663718 - 中软国际 × 华为云"伙伴智能体先锋计划"（北京软件和信息服务业协会，2026-09-17）：https://www.bsia.org.cn/site/content/34938.html

---

附录 E：FDE 技术栈推荐清单

Note

本附录的定位与边界：本附录是本书为转型企业提炼的工具选型建议清单，属实操建议，不是任何厂商的官方标准，也不虚构官方出处。清单秉持中国本土视角——在信创、数据不出域的大背景下，优先推荐国产/可私有化部署的选项，并为每个领域附 1 个国际备选做对标与兜底。 与第 18 章的口径一致性：AI/LLM 相关各领域（大模型底座、智能体编排、RAG/向量库、评测、AI 编程、算力部署）的推荐完全对齐第 18 章 18.4（中国本土技术栈），细节请详见第 18 章 18.4；本表仅做横向汇总并补充数据集成、建模、原型、协作、代码管理、可视化等领域。 选型总原则：涉密/高合规客户一律全私有化 + 信创栈；云上互联网客户走云厂商生态、API 优先；两者之间用同一套智能体编排抽象层避免绑定单一平台（见 18.4.7 选型决策树）。

E-1　数据集成 / 数据管道（Data Integration & Pipeline）

领域	国产优先选项	国际备选	一行使用说明
数据集成与开发	DataWorks（阿里云）、DataArts Studio（华为云）	dbt / Apache Airbyte / Apache Airflow	国产平台面向"数据开发+治理"一体化、政企信创适配好；开源场景可用 dbt（建模转换）+ Airflow（编排）组合兜底。
数据计算底座	Spark / Flink（开源原生生态）、MaxCompute（阿里）	Databricks Lakehouse	Spark/Flink 为跨云信创通用的开源底座；国产云各有托管版（MaxCompute 等），与上游 DataWorks/DataArts 集成最顺。

E-2　数据建模 / 本体（Modeling & Ontology）

领域	国产优先选项	国际备选	一行使用说明
数据建模与治理方法论	Dataphin（阿里，OneData：OneModel/OneID/OneService）、自研本体层	Palantir Ontology（方法参考）	用 Dataphin 落地 OneData 三件套可打通"指标口径统一→对象识别→服务化"；推崇以业务对象为中心建模，与本书 Ontology 思路同源（见 3.1 / 6.3）。
业务关系建模	自研本体 / 知识图谱（开源图库如 NebulaGraph、国产知识中台）	Neo4j	涉密/信创场景建议自建"结构化本体 + 知识图谱"双轨，避免绑定厂商封闭建模工具。

E-3　前端快速原型（Rapid Prototyping）

领域	国产优先选项	国际备选	一行使用说明
原型应用外壳	钉钉宜搭、飞书低代码	Retool / Streamlit / Gradio	交互外壳用低代码快速搭、数据链路仍用代码，匹配 18.4.7 前端原型选型；国产低代码信创兼容性更优。
AI 原型/图表	Trae / Qoder CN（写码）+ ECharts（图表）	Streamlit + Plotly	用国产 AI IDE 快速生成原型代码，ECharts 做国产可视化底座，整体可私有化（见 18.4.4）。

E-4　协作与文档（Collaboration & Documentation）

领域	国产优先选项	国际备选	一行使用说明
团队沟通与协作文档	飞书 / 语雀 / 腾讯文档	Notion / Confluence	飞书等国产协作工具在政企内网可用、合规友好，适合作为 FDE 前线车间文档（访谈纪要、SOP、Gate 检查清单）的载体。
知识库沉淀	飞书知识库 / 语雀、自建 Wiki	Confluence / Notion	把 5.2 干系人地图、12 章 Playbook 录入团队知识库，作为能力沉淀与新人上手的统一入口。

E-5　代码管理（Version Control & DevOps）

领域	国产优先选项	国际备选	一行使用说明
代码托管与协作	Gitee 企业版 / Coding.net（腾讯）/ 极狐 GitLab CN	GitHub / GitLab	内网/信创环境优先选可私有化部署的国产托管（极狐 GitLab CN 支持国产 OS/CPU）；开源临时仓库可用 GitHub。
CI/CD 与流程	Jenkins / GitLab CI（自托管）、国产云原生 CI 平台	GitHub Actions	配合 7.5 的代码审查与测试流水线，把数据管道与前端的构建、测试、发布流程自动化。

E-6　可视化（Visualization & BI）

领域	国产优先选项	国际备选	一行使用说明
前端可视化组件	Apache ECharts（开源国产）	Chart.js / D3.js	数据看板、洞察卡片的前端标配，license 友好、文档全中文。
BI/分析平台	Quick BI（阿里）/ 帆软 FineBI	Tableau / Apache Superset	面向业务用户的自助式报表/看板；政企交付优先国产 BI 以兼容信创与私有化。

E-7　AI/LLM 集成（AI & LLM，详见第 18 章 18.4）

读法：第 18 章 18.4 已把选型改为"判据为主、快照为辅"——因为国内模型供给高频迭代，任何版本清单都会过期。本表因此按"需要的能力档位 / 形态"组织，"快照候选"一列仅供起步参考（快照时点：2026 年 9 月），落地请以厂商官网为准。

领域	需要的能力档位 / 形态	快照候选（会过期）	国际备选	一行使用说明
大模型底座	可私有化的开源旗舰 / 轻量多模态	DeepSeek V4 系列、Qwen3.8 系列、GLM 系列（豆包 / Kimi 视客户）	OpenAI / Claude	先看"能否私有化 + 信创部署"，再看能力是否够用；政企首选"开源 + 昇腾适配"，阿里生态选 Qwen。见 18.4.1。
智能体编排	可私有化的编排引擎 / 云平台托管	Dify（开源私有化）、Coze、阿里云百炼、火山方舟、百度千帆	LangChain 等智能体框架	涉密必须私有化 Dify；互联网客户用其云生态；预留跨端互联能力（AHA 协议）。见 18.4.2。
RAG / 向量库	自建 RAG 层 + 向量库（可控、可迁移）	Milvus + 自研 RAG 层	Pinecone / Weaviate	信创优先 Milvus 私有化；建议"RAG + 结构化本体"双轨；知识库与评测集留在客户侧。见 18.4.3。
评测（Eval）	可自带、可回归的评测集与框架	Ragas / DeepEval / 自研评测集	TruLens / Phoenix	智能体交付必须补"生产环境/线上评测"，把 Eval 集作为交付物。见 18.4.3。
AI 编程	内网/信创可用的代码助手	Trae / Qoder CN / 文心快码 / CodeBuddy	Cursor / Copilot	工具格局比模型格局稳定；内网环境提前验证可用性与许可；政企优先文心快码。见 18.4.4。
算力与部署	国产信创算力 / 云上国产算力专区	华为昇腾集群、国产信创推理服务器	NVIDIA GPU 云	数据不出域走私有化 + 信创算力；以项目环境实际适配认证为准。见 18.4.5。
合规备案	备案事项逐项确认（不假设统一术语）	备案四轨（大模型/算法/登记/智能体）确认	（SOC2/FedRAMP 参考）	与客户法务确认"谁做备案、备案主体"；PIPL 单独同意；AI 关键决策人工确认环。见 18.4.6。

Important

使用提醒：上表为"推荐清单"，不是"必须清单"，且快照必然滞后。落地前请：① 用第 18 章 18.4.1 的四条判据（能否私有化/能力够用/许可证/集成迁移成本）做筛选，再用本表做起点；② 核对各厂商官网最新版本与信创兼容性；③ 按 18.4.7 选型决策树确定"全私有化 / 云上 / 混合"；④ 新技术引入前先过 7.5 的工具链验证流程（尤其国产 OS/CPU/GPU 环境）。清单中所涉工具口径，均以第 18 章 18.4 为准，并建议按季度复核快照。

---

附录 F：术语表（Glossary）

Note

使用说明：本表收录 FDE 交付语境下的核心术语，按首字母/拼音大致排序以便检索。"首次出现章节"依据本书结构推断给出最合理章号，个别不确定处标注"约"，仅供定位参考；同义或跨章节反复出现的术语，取概念首次系统出现的位置。英文保留原文便于对照官方资料。

术语（英文原文）	中文	一句话定义	首次出现章节
Forward Deployed Engineer（FDE）	前沿部署工程师	驻扎在客户现场、在复杂真实场景中把"非标痛点"转化为"平台能力"的复合型工程师	第 1 章 1.1
Forward Deployed Engineering	前沿部署工程（方法论）	以"现场定制 + 平台承载 + 能力回注"为核心的一套交付方法论与商业模式	第 1 章 1.1
FDSE（Forward Deployed Software Engineer）	前沿部署软件工程师	Palantir Delta 序列的软件工程岗位，负责驻场写码、打通数据、构建原型	约第 3 章 3.2（亦见第 1 章 1.2）
Delta	技术执行序列（Palantir 团队代号）	Palantir 前线"技术执行工程师"所在序列，对代码与交付质量负责	约第 3 章 3.2（概念见 1.2）
Echo	业务策略序列（Palantir 团队代号）	Palantir 前线"业务策略师/Deployment Strategist"所在序列，判断"最该解决什么问题"	约第 3 章 3.2（概念见 1.2）
Dev	平台研发（Palantir 后方序列）	坐镇后方的平台/后端工程师，负责把前线定制"集成"为标准平台能力	约第 3 章 3.2（概念见 1.2）
Baseline	基础设施保障工程师（业界俗称）	负责网络、部署、安全合规等底层保障的角色；注意并非 Palantir 官方序列名（官方对应 Engineering 序列）	约第 3 章 3.2
Ontology（本体层）	本体 / 本体层	用业务语言描述现实世界的"数字孪生"，把异构数据表映射为业务对象及其关系	第 3 章 3.1
Object Type	对象类型	Ontology 中代表一类业务对象（如"订单""飞机"）的建模单元	约第 3 章 3.1
Link	链接 / 关系类型	Ontology 中表达业务对象之间联系的建模单元（如"供应商—供应→零件"）	约第 3 章 3.1
Action	动作（可写回）	Ontology 上可执行、可写回源系统（如 SAP）的业务动作	约第 4 章 4.4（Writeback/Actions）
能力回注（Feedback Loop / Upstreaming）	能力回注	把现场的"一次性定制"抽象、沉淀为平台通用能力并反馈循环的机制；须经两级验证才"毕业"——V1 来源项目回归 + V2 第二场景复用（见 9.1）	第 9 章（概念 1.3 起）
飞轮（Flywheel）	飞轮	FDE 越做越强的正向循环：定制→回注→平台更强→下一单更省	概念第 1 章 1.3 起（系统定义 2.3）
死亡螺旋（Death Spiral）	死亡螺旋	传统项目制"越定制越亏、越亏越无力建平台"的自我强化恶性循环	第 2 章 2.1
经验曲线（Experience Curve Effect）	经验曲线效应	成本随累计交付量按 \(n^{-\alpha}\) 递减的规律，是 FDE 边际成本递减的数学基础	第 2 章 2.3
Discovery	发现期（第一象限）	四阶段第一步：不写代码，先听客户说话、找"快赢"切入点	第 1 章 1.5（详第 5 章）
Prototype	原型期	四阶段第二步：用最小可行架构快速搭出能演示、用真实数据证明价值的原型	第 1 章 1.5（详第 6 章）
Build	构建期	四阶段第三步：把验证过的原型打磨成稳定、安全、可运维的生产系统	第 1 章 1.5（详第 7 章）
Scale	扩展期	四阶段第四步：从单场景向全组织扩展，并完成能力回注与客户自运营	第 1 章 1.5（详第 8 章）
Gate	阶段验收关卡	每个阶段末的"检查清单 + 决策点"，全部通过才能进入下一阶段	第 5 章 5.7
Champion User	冠军用户	客户内部最积极使用、推广系统并带动他人的业务骨干	约第 5 章 5.2（培养见 7.7/8.4）
SOP（Standard Operating Procedure）	标准作业程序	把交付动作固化成可复制的标准化操作模板（如 SOP 0-9）	第 5 章（SOP 0 起）
Playbook	打法手册 / 作战手册	沉淀某行业发展 Know-how、可复用组件与排坑经验的知识资产	约第 3 章 3.5（体系见第 12 章）
PPT 框架（People–Process–Technology）	人员流程技术	从"人员组织、业务流程、技术平台"三维度审视企业级交付的经典框架（中文定名"人员流程技术"，缩写 PPT）	第 5 章 How 总纲
快赢（Quick Win）	快赢场景	2-4 周内能用最小数据集跑通闭环、展示明确业务价值的切入点	第 5 章 5.5
MVP（Minimum Viable Product）	最小可行产品/原型	以最低成本验证核心价值的可用最小版本（MVP 数据管道等）	第 6 章 6.2
RAG（Retrieval-Augmented Generation）	检索增强生成	让大模型先检索企业知识库再生成回答，提升私域知识使用准确率	约第 1 章 1.4
Agent	智能体	能自主执行"感知—决策—行动"闭环并调用工具/LLM 的软件组件	第 18 章（AIP Logic 见 3.1）
MCP（Model Context Protocol）	模型上下文协议	连接 AI 模型与外部工具/数据源的开放协议，让智能体跨端调用统一标准（注：本书正文未展开该协议，此处仅作术语收录）	约第 17 章
TTFV（Time to First Value）	首次价值时间	从项目启动到客户第一次看见/用上可衡量价值的时长，越快越好	第 9 章 9.5.1
NRR（Net Revenue Retention）	净收入留存率	衡量老客户较上年多付/少付比例的指标，>100% 说明"落地生根、增购扩展"	第 2 章 2.4
Writeback	数据回写	业务人员直接通过应用把修改/决策安全写回底层源系统的能力	第 4 章 4.4
碎石路→铺装公路（Gravel Road → Paved Highway）	碎石路→铺装公路	把现场"脏代码式的临时定制"沉淀为平台标准配置项的产品化哲学	第 3 章 3.4
五次部署法则（Five-Deployment Rule）	五次部署法则	完成约 5 个不同客户部署前，不急于固化 Playbook/标准产品的作战纪律	第 3 章 3.5
AIP（AI Platform）	人工智能平台	Palantir 将大模型接入企业数据/本体实现自然语言分析与决策建议的平台	第 3 章 3.1
AIP Logic	AIP 逻辑（AI 编排）	AIP 中编排"LLM + 业务逻辑"的工作流组件，可把重复过程做成智能体	第 3 章 3.1
信创（信息技术应用创新）	信创 / 国产化	以国产软硬件（OS/CPU/GPU/平台）替代国外产品以满足数据与供应链安全的工程体系	约第 5 章（深化见 18.4.5/18.4.6）
等保（MLPS，等级保护）	等级保护制度	我国对网络系统按重要性分等级、实施相应安全保护要求的制度（如等保 2.0）	约第 4 章 4.3（详 13.6）
PIPL（个人信息保护法）	个人信息保护法	我国规范个人信息收集、处理与保护的法律；处理敏感个人信息、向第三方提供或出境需单独同意	第 13 章 13.6（亦见第 7 章）
上下文工程（Context Engineering）	—	为模型与智能体构建并治理其运行所需上下文（业务系统连接、知识检索、结构化数据、状态与历史）的系统性工程实践，被视为企业 AI 落地的关键使能层；也被部分研究机构列为可替代外采 FDE 的路径之一	第 13 章 13.8（技术栈见第 18 章）
前线部署工程师 / 前置部署工程师 / 前端部署工程师 / 智惠工程师	FDE 的其他中文译名	分别见于工信厅科函〔2026〕414 号、科大讯飞、明略科技相关报道与中国电信北京公司；与本书"前沿部署工程师"同指一类角色，本书正文统一用"前沿部署工程师"	第 1 章 1.1
人工智能应用服务商（AI Application Service Provider）	AI 应用服务商	414 号文界定为"围绕用户单位智能化需求，提供人工智能解决方案咨询规划、交付实施、运营管理、安全治理等服务的企业或机构"	第 13 章 13.1
服务商资源池	服务商资源池	按 414 号文由各省组织入库的 AI 应用服务商名单，目标为 2026 年底 2000 家以上、2027 年底 3000 家以上；是资源池目标，不是 FDE 岗位数	第 13 章 13.1
人工智能应用服务团	服务团	414 号文要求由 1 家服务商牵头、不少于 2 家上下游单位联合参与的服务组织，类型如"模数共振""算电协同"，面向用户提供一体化解决方案	第 13 章 13.1
"小快轻准"产品包	"小快轻准"产品包	414 号文提倡围绕高频、刚需、可复用业务封装的模块化、标准化解决方案产品包	第 13 章 13.1
业务本体（Business Ontology）	业务本体	用对象、关系、属性、行动描述业务的语义层；国内运营商平台（如元景万悟、梧桐 KnoVa）已出现同类能力	第 14 章 14.2（概念见第 3 章）
写回一致性（Writeback Consistency）	写回一致性	智能体或应用把决策写回源系统时，保证重试、失败、并发下业务状态不出错的工程要求（幂等、补偿、对账）	第 14 章 14.6（检查项见第 7 章）
Token 供给（Token Supply）	词元供给 / Token 服务	以 Token 为计量单位向企业提供模型调用能力的服务形态，运营商与云厂商均已推出统一 Token 服务平台	第 14 章 14.2

---

附录 G：课后研讨题集

Note

使用说明：本附录配合各章训练目标生成，每题含题目 + 参考答案要点（2-4 行）。题目刻意"可落地"——要求读者以自己所在公司/项目为对象分析、用SOP 模板实操、回顾自身代码/经验找复用模式，而非空谈概念。第 17–18 章（AI 篇）题目分别结合第 17 章（Echo 视角·甲方共识）与第 18 章（Delta 视角·技术与场景）作答。供讲师课堂研讨或学员自修使用。

第 1 章 FDE 是什么

1. 用一句话向一位非技术高管解释"FDE 是什么、不是什么"，并说明为什么"卖能力"和"卖人力"是本质区别。

   要点：FDE = 驻扎现场的工程师，把"非标痛点"定制化落地、再抽象回注为平台能力；它不是驻场外包（卖人力）也不是 IT 咨询（卖 PPT）。判断标准：这次交付后"公司能力有没有增长"——只有客户与己方双向增长才是 FDE（1.1/1.3）。

2. 回顾你所在公司最近的一个真实项目，判断它是"卖人力"还是"卖能力"，并列出 2 个"退化成外包"的自检信号。

   要点：看"交付后平台/资产是否沉淀"、是否连续项目仍重复造轮子、收入是否靠堆人头线性增长（2.2 自检信号）。给出判断依据与改进动作。

第 2 章 为什么需要 FDE

1. 画一张你所在公司的"成本—项目数"曲线，判断它处在飞轮的哪个阶段（启动/加速/成熟），并说明依据。

   要点：用经验曲线 \(C_n=C_1 n^{-\alpha}\) 定性——成本随项目数下坠（FDE）还是持平/上升（外包）；结合定制代码占比、可复用组件数判断阶段（2.3）。

2. 用 NRR（净收入留存率）的视角，分析你公司的一个大客户：目前是"1 个用例"还是"多场景扩展"，如何把单客户做深（land-and-expand）。

   要点：NRR>100% 说明老客户在增购扩展；对比 Palantir 案例的单客户收入增长（2.4/附录 C），提出"先快赢切入→再横向扩展"的落地方案。

第 3 章 Palantir 的平台与 FDE 体系

1. 对照"三角色（Delta/Echo/Engineering）"，画出你所在交付团队当前的"角色—职责"地图，标出缺口与职责重叠之处。

   要点：识别"谁在写码（技术执行）、谁在定义问题（业务策略）、谁做底层保障（基础设施）"；若代码最强的人在做客户关系/环境杂活，即存在缺口（3.2）。

2. 用"碎石路→铺装公路"复盘你最近的一个定制项目：举出 1-2 段本应抽象回注却写成死代码的逻辑，并说明如何改进。

   要点：识别→抽象→集成→验证四步；对照"拒绝过早标准化"红线（走通碎石路再铺路），避免为想象未来过度抽象（3.4）。

第 4 章 Palantir 经典案例集

1. 从空客或财富 500 强案例中，标出"解决孤立痛点 → 沉淀平台能力"的完整链路，并映射到你所在的行业。

   要点：痛点（数据割裂/响应慢）→ FDE 现场方案（Ontology 优先、Writeback）→ 能力回注（行业建模范式）→ 复用；映射到自身行业可复用组件。（4.1/4.4）

2. 你的系统里是否存在"BI 让人'看见'问题、却不能让人'直接解决'问题"的场景？如果引入 Writeback/Actions，会带来什么价值与风险？

   要点：对比 BI 只读 vs Ontology+Writeback 可动；价值=缩短决策闭环、嵌入业务血液；风险=源系统一致性、权限与操作审计（4.4）。

第 5 章 Discovery（发现期）

1. 用 SOP 2 数据盘点表，盘点你手头一个候选项目的系统与核心对象，评估数据就绪度。

   要点：按"系统清单/数据源/质量/接口/共享现状"逐行填写，坚持"业务牵引"逆向盘点（5.4）；标出数据断点。

2. 用快赢矩阵（SOP 3）从 3 个候选场景中选出 1 个 P0，并说明评分依据。

   要点：按"业务价值×可见度×数据就绪×技术复杂度"打分，选"价值高 + 可行"的切入（5.5）；注意与 2.3 场景/项目两层筛选的区分。

3. 模拟一次"听客户说话"：为你的受访者设计 3 个开放性问题，并预判答会暴露哪类痛点。

   要点：参考 5.3 关键问题清单（最耗时环节、凭经验而非数据做的决策、跨部门最大卡点）；区分流程/数据/决策/协作四类痛点。

第 6 章 Prototype（原型期）

1. 为一个快赢场景搭建 MVP 数据管道（从数据源到可视化前端），画出最简链路并说明"哪些生产级特性暂时不做"。

   要点：数据源→清洗→最小转换→可视化；坚持"够用就行"，高可用/自动重试/灾备暂不做（6.2）。

2. 用业务语言为你的核心业务场景建一个 3-5 个 Object Type 的 Ontology 草图（实体/属性/关系）。

   要点：命名用业务术语（"订单"而非 t_order），突出关系（6.3）；先窄后宽、只画关键对象。

3. 场景题：客户看完 Demo 说"这不就够了吗，为什么还要做 Build？"你如何管理预期？

   要点：埋三颗种子——① 展示"原型能看到问题但解决不了"的环节；② 用安全合规做挡箭牌（原型跑沙箱，进生产要过审计）；③ 量化 Build 的增量价值（6.8 期望管理）。

第 7 章 Build（构建期）

1. 用"结构 / 业务 / 统计"三类数据质量规则，为你的系统设计一份数据质量规则清单（含示例）。

   要点：结构规则（非空/唯一/类型，可自动生成）、业务规则（如库存不为负，与业务共定）、统计规则（均值漂移/异常突刺）（7.4）；规则写成可测试的可声明配置。

2. 为你的系统搭建"可运营移交三件套"的框架：运维手册、值班 SOP、数据管道健康度看板。

   要点：运维手册（非仅开发文档）、值班 SOP（谁在什么指标异常时找谁）、健康度看板（客户自己能看昨晚管道是否跑成功）（7 章可运营移交标准）。

3. 回顾你最近写过的代码，找出 3 段"可能在下一个客户复用"的模式，并用 SOP 4 能力回注需求卡片登记。

   要点：识别→抽象→登记；评估通用性（技术重复 + 业务普遍）；分清"真实重复 vs 想象通用"，避免为回注而回注（9.1/9.2，7.7）。

第 8 章 Scale（扩展期）

1. 用场景扩展优先级评估表（SOP 5），为你的系统规划 3 个新场景的扩展序位（N+1/N+2/暂缓）。

   要点：按"复用现有 Ontology 比例 + 高层关注度 + 冠军用户覆盖 + 边际成本"评分；相邻场景优先、避免底座崩塌（8.2）。

2. 设计一个"冠军用户网络"的落地计划：如何选人、如何培养、如何用同侪影响自推广。

   要点：每进一个新部门发展 1 名本地冠军；组织技术交流会/用户日，用同侪压力驱动采纳；目标是 FDE 撤场后系统仍自我繁殖（8.4）。

3. 用"阻力—应对矩阵"分析一个你在客户推广中遇到/预判的阻力，并给出化解动作。

   要点：区分习惯路径依赖/利益受损/信任缺失等阻力；用简化 UI、保留操作隐喻、利益绑定、高层背书等应对（8.3）。

第 9 章 能力回注方法论

1. 把一个你团队的已有组件按"识别→抽象→集成→验证"四步法完整走一遍，输出每个步骤的负责人与产出物。

   要点：识别（谁发现重复）→抽象（剥离客户特化、参数化）→集成（平台评审入库、不搬原样代码）→验证（下个项目复用并反哺）（9.1）。

2. 用"通用性 × 实现成本"回注优先级矩阵，对 3 个候选回注点排序，并说明哪些坚决不做。

   要点：高通用+低成本立即做、低成本+低通用顺手做、低成本+低通用/高成本不做；低通用+高成本留作一次性定制（9.2）。

第 10 章 FDE 角色体系

1. 对照"三角色 vs 五角色"，画出你团队当前的"角色编成表"，标出缺失与重叠的角色。

   要点：检查技术执行/业务策略/基础设施是否齐备；是否把"平台工程师/负责人"纳入；避免一个人兼任多职导致职能落空（10.1）。

2. 为团队每个角色写一条"最容易退化成外包"的行为红线，并给出纠偏动作。

   要点：如技术执行只会写死代码不回注、业务策略变成纯客户经理、基础设施把环境外包化；对照各角色核心职责与"卖能力"基线（10.1–10.4；角色明细见 10.1.1–10.1.5）。

第 11 章 四阶段中的角色协作

1. 用 RACI 矩阵模板，为一次真实项目的四阶段关键活动各自填一遍 R/A/C/I，并标出可能冲突之处。

   要点：注意"每个活动只能有一个 A"；标出权责重叠（多人争 R）或空白（无人负责）处并给出取舍（11.1）。

2. 场景题：Build 期销售突然插入一个紧急需求，你如何用 RACI/汇报线机制处理，避免项目失控？

   要点：先用 RACI 定位"谁该决定是否接"（负责人/平台 vs 销售）；结合 3.3 汇报线原则（FDE 不对签单负首要 KPI）；用的是"价值排序 + 变更管理"而非一味拒绝（11 章 + 7 章排序法）。

第 12 章 FDE 人才培养与知识管理

1. 参考 12.1 的三大面试维度，自己设计一道 FDE 面试题，并写出"考点解析"（加分/减分信号）。

   要点：从"极端受限破局 / 沟通逆商 / 快速学习"三选一命题，题目须是开放题、能测"垃圾条件下也能交付"的本能与结果导向（12.1）。

2. 为你的团队建立一个行业 Playbook 的骨架目录，列出前 5 个必须沉淀的条目。

   要点：如行业痛点清单、核心 Ontology 草稿、常见数据源与接口坑、可复用组件清单、交付节奏模板（12 章知识管理）；目标让新人可据此上手。

第 13 章 政策导向下的中国区 FDE 转型：挑战与应对

1. 为你的定制项目设计一道"资产税"验收门槛：要求每个项目必须产出的可复用组件类型与最低数量。

   要点：借鉴 13.2"资产税"制度——要求提炼 ≥1-2 个可复用组件（管道模板/Widget/行业模型）否则不予结项；把第 9 章四步法制度化。

2. 设计一份"数据不出域 + 等保 2.0 + 信创"约束下的 FDE 交付预案（参考 13.6 政企挑战）。

   要点：PoV 前置打动一把手、私有化/信创极简打包能力、把"合规与信创"当作第一天设计约束而非补丁；列出权限/脱敏/验收合规清单（13.6/16.9）。

3. Gartner 将 FDE 标注为"关注度过热、预期降温"。请以乙方技术负责人的身份，向客户 CTO 做一次 10 分钟回应：承认哪些、反驳哪些、我们的差异化在哪。

   要点：承认中国确实缺少能完整承载 Palantir 模式的厂商；反驳"模式不成立"不等于"模式无价值"，用 PoV 切片、Gate 约束探索边界、合同中的知识产权二分给出可执行对策；差异化落在行业深水区 Know-how 与现场破局判断力（13.8）。

4. 当 FDE 岗位薪酬被大厂抬高、在岗资深工程师与新招 FDE 出现薪资倒挂时，如何在有限预算下同时解决"招得到"和"留得住"？

   要点：区分"借助伙伴网络补足队伍"与"用真实项目战绩与晋升窗口留住骨干"两条线；说明关键行业资产必须文档化、双人配置、可轮换，避免能力与客户关系绑定在单个人身上（13.7/16.9 成本与资源层）。

5. 有人说"414 号文要培养 3000 名 FDE"。指出这句话的错误，并用一段话向客户准确说明文件的目标与边界。

   要点：2000/3000 是服务商资源池数量目标，不是 FDE 岗位数；文件未规定部署形态（13.1）。

6. 你的公司准备申报省级服务商资源池并牵头组建服务团。按六大挑战逐一列出政策能帮上什么、帮不上什么。

   要点：参照 13.1.6 对照表；入池不等于有交付能力，回注机制仍需自建（13.1）。

第 14 章 三大运营商的 AI 平台与 FDE 实践

1. 把"息壤、星辰、星罗、元景、京元、九天"放进四层图谱，说明为什么不能直接比较它们"谁更强"。

   要点：区分算力与模型底座、Token 供给、智能体执行、业务语义与本体四层；指出同名品牌下的不同组件；证据等级不等于性能分数（14.2）。

2. 有人说"运营商也有本体了，可以替代 Foundry"。请用五个比较点反驳或支持这一判断。

   要点：数据→对象状态、权限全链贯通、写回一致性、变更与发布、跨场景复制；同时指出 Foundry 自身的边界（14.6）。

3. 为"政企专线故障影响分析与工单协同"设计一次两周 PoC：选出你认为最关键的 4 项检查，并说明失败时的判定。

   要点：参照附录 J 的 V01–V12 与四项硬门槛；要求平台方标注能力来源（14.7）。

4. 你是一家行业软件商，当地运营商邀请你加入其牵头的人工智能应用服务团。你会在哪一层站位？怎样避免"算力换项目"？

   要点：牵头方、底座供给方、FDE 人力方三种站位；看牵头方有无专人负责沉淀、有无可复制的行业本体（14.8）。

第 15 章 中国云服务商的 FDE 实践图谱

1. 用统一考察框架（PPT + 能力回注 + 飞轮阶段 + 卖人力/卖能力）横向点评你所在公司（或一家云厂商）的现状。

   要点：四把尺子逐一打分，指出"偏科"处；如平台统一度（Technology）、回注通道是否通畅、处在飞轮哪阶段（13 章统一框架）。

2. 阿里云 OneData 与华为"铁三角"分别体现了怎样的能力回注通道？各自的堵点在哪、如何破解？

   要点：OneData=方法论产品化输出（OneModel/OneID/OneService）；铁三角=AR/SR/FR 组织协同；堵点多在"前线经验是否制度化回流平台"（15.1/13.2），结合"资产税"制度设计解决办法。

3. 区分 2026 年中国 FDE 生态中的三类主体（云厂商自建队伍、大模型厂商×ISV 联合体、数字化服务商自建体系），说明各自靠什么挣钱、在产业链上占据什么位置。

   要点：重点讲清"模型厂商出能力与方法论 + ISV 出驻场队伍 + 分成计费"与云厂商自建模式的根本差异（15.5/13.7）；结论应落到"我方在这张分工网络里占哪一环、凭什么不可替代"。

第 16 章 关键行业 FDE 实践

1. 比较昆仑数智 × 阿里云与石化盈科 × 火山引擎两种组队方式，说明各自把能力留在了哪里。

   要点：甲方科技公司混编 vs 工具底座 + 培训 + 驻场；内部教练与"给 AI 看的新人手册"作为回注到人的形态（16.2）。

2. 讯飞 × 国家能源集团案例中，"无人化率超过 89%"能否写进你给能源客户的方案？应该怎样表述？

   要点：企业口径、仅指询价通知单子场景；主观项仍有专家复核；"零人工干预"式表述不能替代责任设计（16.2.3）。

3. 给你一篇"某银行上线 AI 平台"的报道，列出判断它是否属于 FDE 案例的三条标准。

   要点：有无驻场团队、现场共创与能力回注描述；以"点金"作为平台案例而非 FDE 案例的反例（16.3.2）。

4. 明略科技转型期毛利率下行、研发投入上升。用第 2 章经济学原理解释这一现象，并给管理层写一段风险提示。

   要点：飞轮启动期先投入；Skill 资产积累到规模后才出现边际成本递减（16.3.1）。

5. 为电力或交通领域的首个 FDE 项目列出三条最低安全要求。

   要点：公开证据缺口不等于没有实践；人工确认环、专家复核、责任留痕，并优先遵守行业主管部门规定（16.4）。

第 17 章 AI FDE 落地（Echo 视角）：甲方共识与业务对齐

Note

以下题目结合第 17 章（17.1 全景、17.2 流程共识、17.3 技术选型共识、17.4 成熟度、17.5 甲方自评、17.6 合同协作、17.7 ROI）作答。

1. 用"AI 是放大器而非替代者"（17.1）这一判断，分析你团队里最值得用 AI 提效的一个环节，并指出"AI 能做什么、人必须把住什么"。

   要点：选择"最可标准化、最重复"的环节（转写/写码/文档速读）；AI 负责提速，人负责判断业务真伪与质量把关；守住第 18 章 18.1 四条红线（尤其人工确认环）。

2. 以"编排 AI 智能体的架构师"（17.1 角色演变）为镜，列出你从"经典 FDE"到"AI FDE"需要补的三项能力，并给出 30 天内的补课动作。

   要点：能力增量=Prompt/智能体编排、RAG、Eval；动作示例：用 Dify/Coze 搭一个最小智能体、建一个 Eval 集、写一份"AI 输出人工确认规则"。

3. 从 18.5 的 8 张场景卡中选一个最贴合你客户业务的场景，起草一份《FDE 协作共识书》关键条款（17.2：合作模式/计费/验收 Gate/安全边界/成功指标）。

   要点：选"规则可结构化 + 数据可得 + 痛点可量化"的种子场景（如知识库问答、流程自动化）；成功指标锚定 9.5.1（TTFV、健康度、效率提升）；验收 Gate 与四阶段对齐、AI 决策路径写人工确认环。

4. 合同条款审查题（17.6）：给出一份报价单与合同草稿，找出其中"把合同所有权全压给 Echo""价值挂钩把全部费用置于不确定结果之上""把复购预期直接算成已实现收益"三处问题，并改写为风险共担、可验收的条款。

   要点：报价/付款/退出归商务、法务、Lead 主责，Echo 提供价值依据（17.6 职责表）；价值挂钩只挂增量部分；复购只能作"潜在价值"单列并给概率与时间（17.7 三口径）。

5. ROI 纠错题（17.7）：判断"年化价值 = Σ(人力节省+成本降低+增量收入+风险避免) − 年合同额；年化价值 ≥ 2×合同额即两年回本"这个说法哪里错了，并用三口径指标重算。

   要点：前式实际是"年度净收益"，不能直接等价"两年回本"；回本要用"静态回收期 = 初始投资 ÷ 月均净现金流入"；"释放工时"≠"实际减少成本"；风险避免须给出概率与损失口径。

6. 有人建议把"配备驻场 FDE"写进招标评分项与验收条件。分别从甲方和乙方角度分析利弊，并起草一条既保证投入、又不退化为按人头计价的条款。

   要点：保证现场投入 vs 按人头计价风险；约定驻场人员产出证据与撤出条件；首购首用、风险补偿与付款关系写清（17.6）。

第 18 章 AI FDE 落地（Delta 视角）：技术与场景执行

Note

以下题目结合第 18 章（18.1 红线、18.2 AI 辅助四阶段、18.4 技术栈、18.5 场景地图、18.6 SOP 9、18.7 最佳实践、18.8 行业案例、18.9 反模式清单）作答。

1. 为一家"数据不出域"的政企客户设计一套 AI FDE 技术栈（含模型、智能体编排、RAG/向量库、算力、合规备案），并说明为何这样选。

   要点：涉密/高合规走全私有化——模型 DeepSeek V4（开源+昇腾适配）或 GLM-5、编排 Dify 私有化、向量库 Milvus 2.6、算力昇腾/信创栈；明确"谁做备案、备案主体"（大模型/算法/智能体四轨）与 PIPL 单独同意；预留跨端（AHA）能力避免绑定单平台（18.4.5/18.4.6/18.4.7）。

2. 用 SOP 9（18.6），为你的一个项目列出四个阶段的 AI 赋能动作、所用国产工具与风险等级，并给出风险控制。

   要点：Discovery（转写/RAG 咨询，低）→ Prototype（AI 写码 + 智能体 Demo，中）→ Build（数据质量 AI 监控 + LLM 代码审查，中）→ Scale（自助 Copilot + 智能体运维，高）；高风险项必须人工确认环与回滚预案（18.1）；每一行要能落到"谁主责、交什么证据"（18.6 两列）。

3. 评估你的团队当前处于第 17 章 17.4 成熟度模型的哪一级，并列出提升到下一级的 3 个硬缺口（工具/流程/合规）及动作。

   要点：按"个人提效 L1 → 流程嵌入 L2 → 智能体交付 L3 → AI 原生 L4"定位自己；重点识别"从 L2 升 L3"的最大跨越（需 Eval 体系 + 编排平台 + AI 作为交付物），把缺口写入团队 OKR（第 17 章 17.4）。

4. 智能体反模式诊断题（18.9）：给出一段某智能体交付项目的复盘描述（含"Demo 惊艳但上线没人用""一个智能体什么都干""AI 直接批了结算单"等信号），请你逐条诊断踩中了哪几类反模式，并给出整改项。

   要点：对应 18.9 六类反模式（Demo 即上线/万能智能体/无人确认环/为智能体而智能体/模型绑架/无 Eval 集）；每个整改都要落到 18.1 红线、Eval 集与人工确认环。

5. Engineering 生产就绪评审题（18.1/18.6/18.7）：作为 Engineering，对一个即将上线的 AI 服务做生产就绪评审，列出必须检查的安全、可观测、发布回滚、灾备与"AI 输出人工确认"各要点，并给出放行/整改结论。

   要点：IAM 与网络、数据不越权、监控告警与日志、灰度发布与回滚、灾备演练、Eval 线上回流、人工确认环边界；对照 18.1 角色责任边界表（Engineering 主责环境/安全/可观测/回滚）。

按角色设计的补充题（HR / 甲方 / 乙方）

使用说明：以上按章节出题面向所有读者；本小节按读者角色补充 6 道题，供 HR 总监、甲方 BDM/TDM、乙方管理者各自找到"属于自己的思考题"。题目编号独立，与既有各章题目编号互不冲突。

HR 总监（2 题）

1. 如果你是甲方 HR，FDE 团队进场后，你会如何设计组织沟通与再培训机制？

   要点：先正视组织政治张力——对接 FDE 的甲方员工往往是被要求投入更多时间、又最可能被流程自动化替代的人（第 12 章 12.6）；把"被替代焦虑"转化为"转型机会"，设计面向员工的再培训/转岗通道；沟通上由下而上、让"被自动化影响最大"的角色先看到自己的新位置，而非空谈变革。

2. 如何向管理层证明 FDE 薪酬投入的合理性？

   要点：用"薪资倒挂"数据说明 FDE 是稀缺复合人才而非普通驻场（2026 年 7 月公开报道：字节 FDE 专家月薪 3.5–7 万、15 薪，阿里云 2–5 万、16 薪，来源：界面新闻/新浪财经《大厂正在花百万年薪抢人，FDE 到底是什么？》）；转向"价值定价"逻辑——投入对应的是"卖能力"带来的可衡量结果，而非堆人头；可用行业约 40 万/人的年基准做对标，并挂钩成功指标（TTFV、健康度）证明回报。

甲方 BDM / TDM（2 题）

1. 用第 17 章 17.5 甲方自评清单判断：你的公司现在需要 FDE 吗？勾选并说明。

   要点：逐条勾选自评清单（是否已有需要深度定制的复杂场景、是否在验证产品阶段、客户是否高度依赖现场集成），判断"该现在投入 / 暂缓 / 尚不需要专职 FDE"；说明每一项勾选背后的业务证据，避免为追热点而投入。

2. 起草一份验收条款：如何把四阶段 Gate 与成功指标（9.5.1）写进合同？

   要点：把四阶段 Gate 改为"联合评审"条款，明确每个阶段末由甲乙双方共同过 Gate、而未过 Gate 即暂停下一阶段；把成功指标锚定 9.5.1（TTFV、系统健康度、效率提升等可量化指标）写进合同，让"验收"从"最后一次"变成分阶段、可追溯的过程。

乙方管理者（2 题）

1. 你如何向客户解释"为什么按价值收费"？

   要点：用 PoV 先行降低甲方初始投入顾虑，说明小投入先验证可衡量价值、价值兑现后再计费的逻辑；诚实面对国内"买一送三、人天单价十年不涨"的付费习惯差异（据公开行业观察），把主张讲清楚而非回避；强调按价值收费能让甲乙双方风险共担、利益一致。

2. 复盘你上一个项目的失败风险点，用第 13 章 13.12 的失败案例框架做一次根因分析。

   要点：按 13.12 框架逐层拆解（如验收迟迟无法通过、组织权责博弈、预期管理失效等）；区分"技术失败"与"商务/组织失败"，找到真正的根因而非表面症状；输出可复用的改进动作写入团队 Playbook。

---

附录 H：甲乙方术语对照表

使用说明：同一个词在甲方和乙方语境里含义经常不同，这是贯穿全书的摩擦点，也是"谁定义做成了"之争的根源。下表单独列出高频分歧词，供双方对齐认知、减少履约争议。

术语	甲方（客户）理解	乙方（FDE/厂商）理解	摩擦点与对齐建议
结果	业务真的变好（降本、提效、增收落地）	系统按时上线、功能可用	分歧在于"上线≠变好"。建议把"结果"提前锚定为可量化指标（TTFV、健康度、业务指标），写进合同与验收条款（见 9.5.1）。
交付	把"要的东西"完整做出来交给我	完成一个阶段里程碑（Gate 通过）	甲方要"终态成品"，乙方要"过程交付"。建议把交付拆成四阶段产出物清单，双方按 Gate 逐项确认，避免"一次性交付"的误会。
验收	最后一次性、全面盖章通过	四阶段 Gate 联合评审、逐项过关	"最后一次性"风险是全推倒重来。建议约定分阶段联合评审，每阶段过 Gate 且留痕，最后一站式终验只是走完流程。
驻场	有人驻点就行，人在现场即可	工程师 + 业务策略的复合驻场，深度嵌入组织	甲方看"人到位"，乙方看"嵌入深度与产出"。建议在条款里写清驻场人员的角色、时频、以及交付价值，而非仅"驻点人数"。
成功	需求都满足了，我的目标达成	项目按合同范围完成、客户续约/扩单	需求满足 ≠ 业务成功。建议双方在项目启动即对齐"成功指标"（9.5.1）并由乙方主动回访验证，而非只对需求勾对勾。
需求	我说的每一个字都是边界，变更是对方的问题	需求会随认知演进，需要变更管理	甲方把需求当冻结合同，乙方当迭代输入。建议建立"需求变更管理 + 优先级排序"机制，把合理演进纳入流程而非对抗。
上线	上了线就结束了，别的都与我无关	上线是起步，还要运维、扩展、能力回注	甲方把上线当终点，乙方把上线当"落地生根"的起点。建议明确上线后的运维期、回注与持续运营义务（见第 8 章 Scale）。
维护	出了问题你得免费一直管	维护有明确定义与边界，超出范围另计	分歧在"免费甩锅式维护"。建议在合同里写清 SLA、响应时效与维护边界（含回注范围），避免"上线即终身免费"的预期。
定制	我要的就是独一份，你们照做	定制会沉淀为可复用组件，反哺平台	甲方要"一次性独特性"，顾虑"把我们做成模板"。建议说明定制与"资产税/回注"机制的价值（见第 9 章、13.2），让甲方理解独特性也被保护。
POC	免费的试一下，测出问题再来找我	低成本的可行性验证，验证价值而非完整交付	甲方把 POC 当"无成本试用/试用版"，乙方当"价值证明小切片"。建议先对齐 POC 的范围、成功标准与后续是否计费，避免"POC 转正白嫖"。

---

附录 I：合规速查表（按行业分列）

使用说明：13.6.1 是跨行业的通用合规清单；本表按行业分列红线，方便 TDM / 合规负责人直接查阅、不必翻正文。注意：表内"红线"为依据本书与公开信息提炼的操作要点，具体条款请以最新监管口径为准（据公开信息整理，如《个人信息保护法》PIPL、《网络安全等级保护》等轨制）。

行业	核心合规红线	部署要求	关键机制	对应本书
金融	大模型调用金融数据多级隔离（"数据→模型→业务"链路层层受控；"数据不出域"通常是机构内控与合同要求，出境与否按数据跨境规则逐项判断）；PIPL 敏感信息从严；面向公众服务的算法与大模型备案	头部机构普遍要求大模型私有化部署，统一平台管理算力 / 私域数据 / 模型能力	多级隔离 + 权限最小化 + 备案轨道确认（以最新监管口径为准）	13.6.1、18.4.6
制造	零容错场景下的责任机制——"责任留痕"：每一步可追溯可审计	视场景私有化或混合，算力/数据链路按产线安全要求部署	操作员勾选"采纳"AI 建议，系统自动生成事后复核记录（人工确认环）	18.1 人工确认环
政务 / 公共事业	自主可控是一票否决项——信创适配认证是硬指标	必须私有化部署，确保敏感数据不出内网	信创适配认证 + 内网闭环流转；存量系统年代久远无 API 时，可能需要视觉识别等额外操作能力	13.6.1、第 18 章 18.4.5
能源 / 流程工业	生产控制系统安全分区；AI 进入生产环节须保留人工确认与责任留痕，"零人工干预"类表述不能替代验收中的责任设计	生产侧私有化、管理侧可混合；工控网与办公网隔离	老师傅经验沉淀为规则 + 智能体双轨；异常处置保留人工接管入口	16.2、18.1
跨行业（政策面）	工信厅科函〔2026〕414 号要求安全、伦理、合规嵌入研发、部署、应用全流程；推动安全可靠操作系统、数据库、训推芯片等软硬件适配	按客户行业规则执行，政策本身不设部署形态	合规映射表（适用依据→控制措施→测试证据→责任人）作为交付物	13.6.1、13.1

NOTE：以上为操作速查，具体条款以最新监管口径为准。

---

附录 J：AI 平台对标 PoC 验证清单

Note

使用说明：本清单配合第 14 章使用，把"产品介绍看起来相似"转成可复现的采购、合作与 FDE 实验验证。清单中的数据规模、门槛、权重与工期均为设计建议，不是任何厂商的实测结论；未演示是本次验证结果，不可写成产品永久不支持。本清单同样适用于云厂商平台与其他行业智能体平台。

J-1　统一业务题目

政企专线故障影响分析与工单协同。涉及对象：客户、专线、站点、设备、告警、合同 SLA、工单、处理组。闭环为：接入数据 → 统一对象身份 → 关联告警与客户影响 → 规则计算优先级 → AI 解释证据并建议派单 → 有权限人员确认 → 模拟工单系统写入 → 回收处理结果 → 更新对象视图与指标。

Caution

禁止事项：不接生产网络，不导入真实用户通信记录，不进行真实计费、退费、关停、服务变更或网管命令。必须在技术层面用沙箱接口与权限白名单阻断，而不是只写进提示词。

控制条件：所有候选平台使用同一份合成数据（约 1 万客户、3 万专线、2 千设备、10 万条告警与工单历史，可按教学环境等比缩减）；三类数据源（SQL 数据库、CSV 或对象存储、模拟 HTTP 告警事件）；三类身份（省 A 坐席、省 B 坐席、跨省授权主管）；先固定模型与资源做平台比较，再单独做模型与算力优化。若某平台只提供算力或 Token 服务，应与同一应用与数据栈组合比较，组合新增成本计入总成本。

J-2　十二项验收实验

编号	测试	操作与失败注入	必留证据	核心判据
V01	接入与更新	导入三类源；增量新增、更新、删除；断网后恢复	连接配置、刷新时间、重试与对账记录	数据一致；新鲜度符合事前约定；说清轮询、索引构建与 CDC 的区别
V02	质量与血缘	注入重复主键、缺失 SLA、非法状态	质量规则、隔离区、上下游链路	坏数据被发现，不静默产生错误派单；可定位源与变换版本
V03	业务对象	将三个系统的客户 ID 对齐；新增关系与属性	对象与关系定义、映射、查询 API	不靠提示词猜测身份；查询与应用使用同一对象定义
V04	逻辑与解释	规则算优先级、模型作建议、图关系算影响范围	可复用函数、对象绑定、证据输出	确定性规则结果可复算；AI 不把建议当事实
V05	受控写回	有权与无权派单；重复提交；外部成功内部失败	授权、请求 ID、幂等键、状态与补偿记录	无越权与重复生效；任何不一致都有可见状态、补偿或人工处置
V06	权限全链路	省 A 用户查省 B 数据；缓存、向量检索、日志、导出交叉测试	逐条权限测试与拒绝记录	权限不能只藏 UI 按钮；明确服务账号代理与用户身份透传
V07	业务操作台	同一对象构建告警列表、影响视图、工单编辑与审批	UI 演示、对象 API 调用、角色差异	不只是聊天回答；能推动任务状态并追踪处理责任
V08	智能体评测	固定题集，更换提示词或模型；注入文档恶意指令	测试集、版本差异、质量与 Token 与时延	评测可重跑；能识别工具滥用与提示注入
V09	运行追踪	工具超时、模型限流、检索无结果	跨模型、工具、业务动作的追踪 ID	可定位失败步骤、输入输出与授权主体；日志脱敏
V10	变更与回滚	改对象属性与业务规则；保留旧应用；失败升级	分支与审查、依赖图、兼容性测试、回退记录	说明 Schema、配置、代码、数据各自如何回退，不声称删除可自动恢复
V11	多环境与隔离	测试环境迁生产沙箱；断开外网；替换模型	安装包、镜像、许可、出站流量清单	明确哪些组件依赖公网；外部服务关闭时降级或受控失败
V12	跨省复制与退出	向省 B 复制应用与对象定义但不复制省 A 数据；导出迁移	依赖清单、数据绑定、权限重建、导出包	资产复用与数据隔离同时成立；退出成本透明

J-3　打分方式：硬门槛、权重与证据分开

1. 四项硬门槛：身份、安全、数据、写回。出现越权泄露、未经批准的真实写操作、无法解释数据去向、关键状态不一致且无处置之一的，不得以高平均分抵消。
2. 建议权重（合计 100）：数据接入治理 15、对象语义与逻辑 20、动作闭环 15、应用与智能体 10、安全治理 15、运行与发布 10、复用与退出 5、总成本与交付责任 10。
3. 每项 0–4 分：0 未提供或未演示；1 只有方案；2 可运行成功路径；3 通过异常与权限测试；4 可重复交付并有运行证据。
4. 证据标签另列：技术文档、正式产品说明、案例与媒体、厂商口头解释、现场实测。宣传材料的数量不加分。
5. 能力来源逐项标注：原生功能、厂商配套产品、第三方集成、项目自研，并注明版本、许可证与责任人。

J-4　总成本口径

按同一业务规模与统计周期核算：平台许可、计算与存储、模型 Token、网络、数据治理、接口开发、对象建模、应用开发、测试与安全、部署迁移、人工复核、运维升级、退出迁移。建议同时报告：

• 完成一个合格业务任务的总成本，而不只比较每百万 Token 价格；
• 首个场景交付周期，以及复制到第二个省份的增量工时；
• 故障定位与恢复时间，而不只比较模型回答速度；
• 可独立运维的比例、依赖厂商驻场的工作量与服务响应责任。

Tip

安排建议：账号、数据与许可齐备时，可安排 2-3 周受控 PoC——第一周身份、架构与数据，第二周对象、应用与动作，第三周异常、安全、复现与成本。前提不具备时先做文档与录屏核验，不承诺相同工期。本清单也可改造为 FDE 课程实验，此时优先选择可进入、可复现、可观测、可安全失败的平台。