造与最小可行部署（MVD）

给已经选定场景、拿到数据授权、准备开始动手的人。这一页回答：第一版东西造多大、用什么数据造、用什么节奏造、一个人带 agent 怎么造、以及造出来的东西离「能上生产」还差什么。

选题和 Context 的部分见 discovery-and-scoping.md 与 context-engineering.md；上线之后的采纳工作见 deployment-and-adoption.md。

一、MVD 这个词的出处与定义

1.1 词从哪来

截至 2026 年 9 月，"Minimum Viable Deployment"（最小可行部署，MVD）不是 Palantir 的官方术语。 Palantir 官方博客与 Foundry 文档里使用的是 "from 0 to use case in 5 days"、"minimum viable path"、"gravel road" 这类表述，没有把 MVD 定义成一个术语（Palantir AIP Bootcamp 官方页、Deploying Full Spectrum AI in Days）。

中文语境里 MVD 的定义与广为流传的「三条军规」，可查证的最早成体系出处是范冰（XDash）2026 年 8 月公开的《前线部署工程师》第 2 章第 5 节。作者在原文里明确写了这是自己的对应改写：

「互联网创业方法论里有个著名概念叫 MVP（Minimum Viable Product，最小可行产品）……FDE 对应的概念，我称之为 MVD（Minimum Viable Deployment，最小可行部署）——用最小的工程投入，在客户的真实环境里，对真实的痛点，验证一次价值的真实发生。」 —— xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer，02-第2章-解决正确的问题.md

【待核实】部分中文材料把「MVD 三军规」记到微信公众号《FDE 交付秘籍》系列名下。该系列确实存在（2026 年 8 月仍在更新），但本次检索未能确认其中含有与三军规对应的原创表述，也未确认其发布时间早于上述开源书。引用时建议以开源书为准，并注明这是中文圈的原创提炼，不是 Palantir 的原文。

1.2 定义与裁判

MVD 与 POC、MVP、pilot 的区别不在规模，在谁是裁判。

	POC（概念验证）	MVP（最小可行产品）	MVD（最小可行部署）
要证明什么	技术上做得出来	市场上有人要	在这一个客户身上产生了价值
裁判是谁	技术评审、实验室	早期用户、市场	这个客户的具体业务与具体用户
用什么数据	样例数据、构造的演示数据	早期用户自带	客户的生产数据切片
及格线	能跑通	有人愿意用或愿意付钱	业务指标动了，而且一线在用
终点形态	一次演示	一个能持续获客的产品	一个还在跑的系统

范冰的原文把这个差别概括为一句：MVP 验证「要不要做这个产品」，裁判是市场；MVD 验证「这个方案在这个客户身上能不能产生价值」，裁判是这个具体客户的具体业务。

需要提醒的一点是，MVD 的可迁移性天然很低。同一份原文写道：「一个在十个客户那里验证成功的方案，在第十一个客户那里照样可能失败——数据基础不同、组织惯性不同、痛点的形状不同。」这也解释了为什么 FDE 这个角色存在：价值没法从前十个客户那里继承。

1.3 三条军规（原文摘要）

1. 真实数据，没有例外。 用脱敏样例或构造数据做验证，是 POC 坟墓的第一块砖。真实数据里才有字段含义与文档不符、三成空值、三年前的编码规则，以及最麻烦的一种情况——数据里并存两个互相矛盾、各自「正确」的答案。
2. 缩小的是范围，不是价值。 不做「阉割版大方案」，只砍覆盖面，不砍链路深度。原文举的例子是：不追求「覆盖全公司的智能客服」，而是「只覆盖退换货这一类工单，但做到端到端、无人干预」。
3. 定死截止时间，倒逼取舍。 验证周期以周计不以月计。原文引的参照是 Palantir 训练营 1 到 5 天、Sierra 公开报道的最快上线案例 4 周、Decagon 的典型部署 4 到 8 周。

第三条在方法论谱系上并不新。它与 Basecamp《Shape Up》的 fixed time, variable scope（固定时间、可变范围）以及「断路器」规则同源——先定愿意花多少时间，再把方案锤进这个时间里，周期结束时没做完的东西不自动滚入下个周期（Shape Up 全书免费，Decide When to Stop 一章）。

判断范围切得对不对，有一个比清单更硬的问题：做完之后，这个组织里有没有一个具体的人，他每天的某个动作因此改变了。 答不上来，切的就不是范围，是链路。

二、Palantir AIP Bootcamp：几天出一个真部署

Bootcamp 是目前唯一被大规模、连续多年运行过的「几天出真部署」流程，值得当成 MVD 的工业化样本来读，但它的前提条件也必须一起读。

2.1 官方页面上实际公开的内容

Palantir 官网 bootcamp 页公开的只有一句承诺和三条目标：

"Palantir AIP Bootcamp — From 0 to use case in 5 days. 1 / Understand how to apply AI to mission-critical operations 2 / Develop initial use cases in the software 3 / Onboard and train users for rollout in operations"

官网没有逐日议程、没有价格、没有公开报名条件。 任何更细的议程都来自第三方或合作伙伴文档，引用时应标明层级。

另外注意官方有两种并存的时长口径：官网页面写「5 days」，2023-10-12 的官方博客原文写的是「one to five days」（一到五天）。本页第 1.3 节引的「训练营 1 到 5 天」用的是博客口径，两版对照见 delivery-lifecycle.md 第五节。

2.2 官方博客给的六条设计原则

Palantir 官方博客《Deploying Full Spectrum AI in Days: How AIP Bootcamps Work》给出的设计原则可以概括为六条，每一条都对着一个具体失败模式：

1. 没有入场门槛。 模型、企业数据工具、专家反馈闭环预先集成好，参与者的时间全部花在创造价值上，而不是攒零件。
2. 授人以渔，也给鱼吃。 现场解决客户今天的真实用例，同时让客户练出以后独立构建的直觉，不放预制 demo。
3. 从聊天走向自动化。 引导客户把 prompt 的触发源从「用户在对话框里打字」升级为真实业务事件（订单异常、设备报警、库存变化）。
4. 让 AI 变成客户自己的。 让业务专家在工作现场直接给系统反馈，把锁在非结构化数据和员工脑子里的知识变成客户独有的能力。
5. 用经验主义定义架构，不用神学。 用几个模型、要不要微调这类问题不靠开工前辩论解决，靠最短路径把第一个用例推上生产，跑通后回头修架构。
6. 任何行业、任何职能。 不是给博士办的活动。

第 5 条对技术选型的意义见本页第六节。

2.3 合作伙伴公开的准备清单与三段议程

Palantir 合作伙伴 PVM 公开的《Palantir Platform Bootcamp Guide》给出了四步准备与三阶段议程（属第三方公开文档，非 Palantir 官方口径）：

准备四步

步骤	原文
01 确认参与人角色	Business owners, users, and relevant IT stakeholders.
02 拿到数据	Static cuts of data based on workflow / use case, provided one – two weeks prior to your Bootcamp.
03 界定用例	High-level use case discussions to help the team pre-build as much as possible before the Bootcamp.
04 准备本体	One 30 minute discussion with data owners once data sets are shared.

议程三段：Phase 1 介绍与产品演示 → Phase 2 Hands on keyboards（客户的人和工程师并排敲键盘）→ Phase 3 成果展示与评估，当场对齐下一步。

这份清单里有三个动作单元值得单独记住，因为它们都有名字、有时长、有参与人、有产出，最容易被复制成模板：提前 1–2 周交真实数据切片、30 分钟数据/本体沟通会、hands-on-keyboard 而不是围观演示。

2.4 效果数据的证据强度

Bootcamp 的商业效果数据在中文圈流传很广，但一手程度差别很大，使用时要分层：

说法	证据层级
"From 0 to use case in 5 days"、三条目标	一手（官网原文）
六条设计原则	一手（官方博客）
四步准备、三段议程	第三方（合作伙伴 PVM 公开文档）
单季办了几百场、累计过千场、高峰期日均约 6 场	媒体对财报会的转述，二手，口径以财报为准
Bootcamp 后数周签下七位数至八位数合同（如某医疗公司五周后签五年期年合同额 2600 万美元、某全球银行四个月后扩为三年期年合同额 1900 万美元）	财报电话会披露内容经媒体与中文材料转述，二手

对照本页第 1 节的纪律：没有基准的百分比不如有分母的绝对值。引用这些数字时把层级一起写出来，比把数字写得更大有用。

2.5 复制这套模式的三个前提

1. 要有平台底座。 几天出活的前提是集成、安全、数据管道预制好了。没有底座，五天连环境都搭不起来。
2. 数据要能提前离场。 「提前 1–2 周把静态数据切片交给外部团队」在很多行业与地区走不通。可替代的做法是把 Bootcamp 办进客户机房、用客户内网环境加现场脱敏，把「数据不动、人动」写进准备协议。
3. 拍板人要提前锁进日程。 三段议程的终点是「对齐下一步」，验收当天没有能拍板的人在场，前面几天的产出就没有出口。

三、只用真实数据

这条军规在实践上比听起来贵，也比听起来重要。

为什么必须真实数据。 企业数据的真实难度占了 MVD 工作量的大半：表名无法解读、同一个日期有四种格式、同一种缺陷在三个分厂有三套叫法、名义上叫「缺陷等级」的字段实际被挪用成了备注栏。用样例数据等于把最难的部分留到最后。

一个有价值的对照。 Salesforce 把自家客服 agent 当第一客户用了一年，踩到的最大的坑不是准确率，是数据里并存两个互相矛盾、各自「正确」的答案——agent 遇到这种情况会试图调和甚至编造，一份过时又没被链接的旧页面就足以污染回答。他们的处理是回头把公司内部六百多条数据流整合成唯一权威数据源，每个问题只留一个权威答案（转述自《前线部署工程师》第 2.5 节，原始出处见该书附录 C）。

这条规则在组织上怎么落。 OpenAI 的做法是把它做成岗位边界：解决方案架构师可以用匿名样例数据做演示和验证，FDE 则必须在客户的基础设施上、用客户的真实数据写生产代码。Palantir 的做法是把它写进 Bootcamp 的入营规则（数据切片提前 1–2 周到位）。两家的共同点是：真实数据不是工程偏好，是流程门禁。

拿不到数据怎么办。 三种常见处理：

• 把「安全与审计」当敲门砖。数据进平台后有行级权限和完整审计日志，通常比散在个人电脑的 Excel 里更可控，这是化解数据看门人的标准论证路径。
• 缩小到能拿到的最小切片：一个月、一条产线、一个门店、一个区域。
• 拿不到就不开工。这是最被低估的一条——拿不到真实数据的项目，往往真正缺的不是数据，是那个能拍板的人。

四、上午造、下午给人看

4.1 节奏来自哪里

Palantir 官方博客《A Day in the Life of a Palantir Deployment Strategist》公开过一份日程实录：上午 10:15 在做数据管道，把客户的 ERP 接进一个自动处理发货差异的应用；13:30 就开客户迭代会，展示上午刚做出来的进展，听真实痛点。开发和客户反馈在同一天闭环。

把它抽象成节拍就是：一周跑 4 到 5 个完整的「造—看—改」循环，而不是一周做一次演示。

4.2 两周冲刺的一种典型排法

下面这份排法综合了 Palantir 的驻场节奏与中文材料里几种两周冲刺版本，属于可裁剪的参考，不是唯一正确答案。

三个不能挪的日子：

• D0 数据实际到手（不是承诺到手）才允许开工；
• D4 第一次给真实用户看半成品，此时东西一定很丑，推迟这一天是最常见的错误；
• D10 由客户的人操作演示，而不是交付方演示。

4.3 为什么半成品要早见人

三条理由，按重要性排：

1. 早暴露的问题便宜。 D4 发现方向错了还有六天，D9 发现方向错了这一仗就结束了。
2. 迭代密度等于信任积累的速度。 一起改过五轮的用户会把交付方当自己人，这直接决定后面采纳阶段的难度。
3. 一个打磨过的成品只会得到「挺好的」，一个半成品才会得到「这个字太小了我看不清」。 后者才是有用信息。

4.4 试运行那天该看什么

真实用户试运行的那一天，交付方在旁边只记不说，重点记三样：

• 每一次停顿超过三秒的地方——那是他不知道下一步该干什么；
• 每一次他去问别人或打开另一个窗口——那是系统没覆盖到的信息需求；
• 每一次他绕过系统直接用老办法——那是这个系统在他心里的真实位置。

五、agentic 开发：一个人带一支 agent 军团

2026 年 FDE 的造法与 2023 年最大的差别，是执行工作可以大比例交给 coding agent，而 FDE 的时间被重新分配到判断和现场。

5.1 编制：从「配对」到「个体 + agent」

Palantir 前线的经典编制是两个人：FDSE（管造）与 Deployment Strategist（管推），两个角色的分工与代号考据见 ../03-role/README.md。这套配对经过二十年验证，但它服务的问题之一——外部人不了解客户组织，需要专人做组织导航——在企业内部 FDE 的场景里并不存在。

2026 年出现的第三种编制是个体制加 agent 军团：一个人负责结果，agent 承担执行。这种编制在公开材料里还没有像 Palantir 配对制那样的长期证据，属于正在形成中的实践，读者应把它当作一种选项而不是定论。

5.2 一种可操作的分工：四个 agent 岗位

把 agent 拆成职责、输入、输出都明确的几个岗位，比用一个通用助手干所有事更容易归因质量。下表是中文材料里较完整的一种拆法：

agent	职责	交付物	人在这里守什么判断
调研	外部检索、同行做法、技术选型、失败案例	一页简报 + 三条可选路线 + 每条的已知坑	选哪条路；哪些「行业最佳实践」在这里不成立
数据	剖面统计、清洗、字段对齐、口径核对	字段质量报告 + 异常清单 + 可用数据集	哪个异常是脏数据，哪个是真实业务
代码	写、改、测、部署	能跑的东西 + 自测结果	范围切在哪；什么时候停手
推进	日报、进度跟踪、纪要、汇报材料、待办跟催	一句话通报 / 周报 / 汇报草稿	哪句话能对外说

三条经验规则：

• 给调研 agent 的指令必须带约束（数据不能出内网、只有一个人、两周内要有能给真人用的东西），否则拿到的是维基百科式的技术综述。
• 给数据 agent 的指令最后一句应该是「列出你认为我应该去问业务方的三个问题」，这把它从「回答我问的」变成「告诉我该问什么」。
• 给代码 agent 的指令要一次一个可验证的小目标。 下「帮我做一个客服分类系统」这种指令，问题不在它做不出来，在于做出来的东西无法判断对错，等于把判断点交了出去。

5.3 agent 承担多少、人承担什么

公开可查的行业动作正在往同一个方向走：

• Maven 上 Hamza Farooq 的 Forward Deployed Engineering Bootcamp（6 周、$2,000、11 场直播 40 个 lesson）把 Module 0 直接做成「Getting Started with Claude Code」，把 agent harness、subagents 与多 agent 架构放进正课主线（课程页，抓取于 2026-09-01）。
• Anthropic 面向技术负责人发布了《Scaling Agentic Coding Across Your Organization》指南，主题是「如何从几个早期使用者扩到整个工程组织」（resources.anthropic.com/scaling-agentic-coding，截至 2026 年 9 月需留邮箱下载）。
• Interview Kickstart 的 23 周 FDE 课程里，第 12 周单独是 "Pair Programming with Claude"，涵盖 Claude Skills / Projects / Artifacts / Claude Code（课程页）。

而这些材料共同没有替代掉的，是三类判断：

1. 去现场。 agent 越好用，越容易一整天不离开屏幕，而 MVD 的胜负手在给用户看半成品和陪跑试运行这两天。
2. 数据异常的性质。 「这 200 单金额是负数」可能是数据错误，也可能是这家公司真的有一类冲销单。这个判断只能问人。
3. 哪句话能对外说。 推进 agent 会把「模型准确率提升到 89%」写进群通报，而这句话在特定组织里会被谁怎么理解，只有人知道。

六、demo 与 production 的差别

一个能演示的东西和一个能上生产的东西，中间隔着的不是「再优化一下」，是一组结构性的差别。下表是速查版，完整的生产化清单（监控、回退、权限、成本上限、SLA、交接）见 ../05-practice/demo-to-production.md。

维度	demo	production
数据	一份静态切片	持续到达的数据流，含迟到、重放、口径变更
失败	失败就重跑	失败要被捕获、记录、可重试、可回滚
权限	一个账号	行级/字段级权限，最小权限，可审计
边界情况	演示路径	空值、超长、乱码、并发、重复提交
质量	演示时看着对	有评估集、有回归、有线上采样与告警（见 evaluation.md）
写回	只读展示	能改变系统状态，且改动可追溯
成本	不计	单次调用成本、日预算、路由与缓存策略
交接	只有作者会用	有值班对接人、有运行文档、有配置的负责人

其中「写回」这一条常被低估。Palantir 的 Ontology 里有一个叫 Action Type 的原语，官方文档把它定义为「用户可以一次性执行的、对对象/属性值/关系的一组变更的模式定义」，也就是说这套产品架构把「写回」当成一等公民（Palantir Ontology core concepts）。没有这类产品强制的团队，只能靠检查表强制：一个只能查询、不能改变世界状态的系统，不改变任何人的动作，因此也不产生任何采纳。

「先做查询，写回下一期再打通」是最常见的一种自杀式范围切割。同一类的还有「先不接真实数据，用导出的样表」「界面先糊弄一下」。判断切法好坏可以用四问，必须全部答「是」才能砍：砍掉这块之后，数据还是真实的吗？还有一个具体的人的具体动作会改变吗？约定的那个指标还测得出来吗？用户还能在他原来干活的地方拿到结果吗？

七、技术选型：自建、平台、还是厂商

MVD 阶段的技术选型有一个反直觉的结论：这个决定应该被推迟，而且应该由跑通的第一个用例来做，不由开工前的架构辩论来做。 这正是 Palantir 六条设计原则里第 5 条（用经验主义定义架构，不用神学）的意思。

7.1 三条路线的边界

路线	适合什么情况	主要代价	典型信号
自建（开源模型 + 自己的编排层）	数据完全不能出内网；场景高度独特；长期要沉淀成自有资产	前六个月可能都在搭基建；运维与安全全部自担	团队里有人能对生产事故负责
买平台（Foundry/AIP 这类一体化平台，或云厂商的 agent 平台）	需要几天内出活；集成、权限、审计的成本高于建模成本	能力与平台强绑定，迁移成本高；采购周期长	数据源多且散，权限与审计是硬要求
接厂商方案（某个垂直 SaaS 或模型厂商的托管服务）	场景标准、已有成熟产品；内部没有工程承接能力	定制空间小；关键 Context 沉淀在厂商侧	场景与厂商产品的重合度超过八成

7.2 MVD 阶段的三条实用规则

1. 不做旧环境的寄生体。 验证期的系统运行在自己可控的边界内，通过接口与旧系统交互，不要把代码写进旧系统。理由有三：验证期方案有很大概率被推翻重写，寄生越深浪费越大；写入旧系统要走客户的变更管理流程，周期以月计，与周级节奏冲突；保持「可撤离」姿态本身就是谈判筹码。（《前线部署工程师》2.6 节）
2. 顺着用户的旧入口。 如果业务用户的核心动作发生在表格和邮件里，第一版界面就应该出现在表格插件和邮件里，而不是要求用户登录一个新门户。OpenAI 在西班牙对外银行的部署从 12 万员工已经在用的 ChatGPT 界面切入，是同一条原则的例子。这条在采纳阶段还会展开，见 deployment-and-adoption.md。
3. 把选型问题降级成可回退的实验。 「用几个模型」「要不要微调」这类问题在第一个用例跑通前不值得辩论，跑通后再回头修架构的成本，通常低于开工前辩论三周的成本。

7.3 一条常被忽略的成本线

MVD 阶段的成本侧不只有人天。运行成本（token、向量库、运维）在立项时就应该有一个粗估口径，否则算账阶段会出现「省下的人力成本被推理成本吃掉一半」的尴尬。测算表的结构见 value-accounting.md。

八、常见失败模式

1. 用测试数据把两周干完了。 结果是做了个 POC，前面所有死法一个不少地等在后面。
2. 范围膨胀。 中途加需求，社交上很难拒绝。可用的处理是当面记录、承认价值、挂到第二期清单，并说明「现在动它，约定的那个数字就交不出来」。
3. 拍板人缺席。 只有 IT 陪着做，验收那天没人能说「上」。宁可推迟开工也要等到人。
4. 做成了给高管看的 demo。 真实用户一天都没用过。半成品见人与试运行陪跑这两天是专门防这个的。
5. 把 MVD 做成免费 POC。 结束时没有关于下一步的书面结论与时间表，两周后热度归零。
6. agent 跑得很顺，人一整天没离开屏幕。 造得快不等于造得对，这是 agentic 开发带来的新失败模式。

延伸阅读

• discovery-and-scoping.md：MVD 之前的选题与范围界定
• evaluation.md：评估集怎么设计，及格线由谁定
• deployment-and-adoption.md：造完之后怎么让人用起来
• value-accounting.md：成本与收益怎么算，怎么向决策者汇报
• frameworks-compared.md：各家方法论在「造」这一段的差异
• ../06-toolbox/agent-dev-stack.md：编码 agent、agent 框架、低代码平台、MCP 生态四层的选型
• ../05-practice/demo-to-production.md：本页第六节那张 demo / production 对照表在生产化环节的完整展开
• ../00-start/glossary.md：MVD、POC、Ontology、Eval 等术语定义
• Ryan Singer《Shape Up》（Basecamp，2019，全书免费）：固定时间、可变范围与断路器规则的原始出处，https://basecamp.com/shapeup
• Alistair Cockburn "Start with a Walking Skeleton"（收录于《97 Things Every Software Architect Should Know》）：端到端最窄链路的经典表述，https://www.oreilly.com/library/view/97-things-every/9780596800611/ch60.html

来源

1. 范冰（XDash），《前线部署工程师：人工智能时代的客户价值交付秘籍》第 2 章第 5 节「用最小可行部署验证价值」，GitHub 开源全文，2026 年 8 月（截至 2026-09-06 该仓库 4,548 star）。https://github.com/xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer
2. Palantir，AIP Bootcamp 官方页。https://www.palantir.com/bootcamp/
3. Palantir Blog，"Deploying Full Spectrum AI in Days: How AIP Bootcamps Work"。https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
4. PVM，"Palantir Platform Bootcamp Guide"（合作伙伴公开文档，抓取于 2026-09-01）。https://blog.pvmit.com/pvm-blog/palantir-platform-bootcamp-guide
5. Palantir Blog，"A Day in the Life of a Palantir Deployment Strategist"。https://blog.palantir.com/a-day-in-the-life-of-a-palantir-deployment-strategist-951cb59a5a96
6. Palantir 官方文档，Ontology core concepts（Action Type 定义）。https://www.palantir.com/docs/foundry/ontology/core-concepts
7. Ryan Singer，《Shape Up》，Basecamp，2019。https://basecamp.com/shapeup ；"Decide When to Stop" 章 https://basecamp.com/shapeup/3.5-chapter-14
8. Maven，Forward Deployed Engineering Bootcamp（Hamza Farooq，6 周，$2,000，抓取于 2026-09-01）。https://maven.com/boring-bot/ai-system-design
9. Interview Kickstart，Forward Deployed Engineering（23 周课程页，抓取于 2026-09-01）。https://interviewkickstart.com/courses/forward-deployed-engineering
10. Anthropic，"Scaling Agentic Coding Across Your Organization"（需留邮箱下载）。https://resources.anthropic.com/scaling-agentic-coding
11. Alistair Cockburn，"Start with a Walking Skeleton"，《97 Things Every Software Architect Should Know》，O'Reilly，2009。https://www.oreilly.com/library/view/97-things-every/9780596800611/ch60.html