第 7 章 Phase 3: Build（构建期）

第 7 章 Phase 3: Build（构建期，1-3 月）¶

Note

本章导读：四阶段的第三步——把原型"改装成量产车"。从容忍脏数据的原型走向必须治理的生产系统：数据源扩展与集成深化、数据质量治理、用户培训与冠军用户培养，并首次系统性地识别与登记能力回注点。本章是从"能用"到"可靠、可运维、可规模化"的关键锤炼期。 读完本章，你能把原型改造成可运维的生产系统，并按移交标准和 Gate 清单判断它是否已经可靠。

7.1 目标与进入条件¶

战略意义（给高管）： 这是一个充满阵痛的时期。从原型到生产，相当于把一辆在测试场地跑的拉力赛车，改装成能够每天在早高峰安全行驶的量产车。投入巨大，但这是确立护城河的关键。 操作意义（给一线）： 技术执行工程师（对标 Palantir Delta/FDE）需要从"黑客"转变为"架构师"和"布道师"。你需要面对脏数据、复杂的安全权限，以及无数个想放弃的用户。

目标： 从原型走向生产，交付真正可用的系统。
进入条件： Prototype 阶段 Gate 通过，客户确认投入并组建联合团队。

7.2 数据源扩展与集成深化¶

从快赢场景的 2-3 个数据源，向完整数据生态扩展。

数据集成的层次：

数据接入： 建立稳定连接（JDBC/API/Kafka 等）。
数据清洗： 处理空值、修正异常字符。
数据标准化： 映射为统一实体。
数据融合： 消除数据孤岛。

处理策略： 增量数据与历史数据的处理策略应当是"新老划断，用时才洗"。

7.3 从原型到生产：关键差异¶

理解原型与生产的差异，是避免项目在构建期翻车的核心。

维度	原型 (Prototype)	生产 (Production)
数据质量	容忍脏数据	必须治理
性能	够用就行	需要优化
安全	简单控制	完整权限
运维	手动	自动化
文档	可选	必须

7.4 数据质量治理¶

不要指望客户的数据一开始就是干净的。

数据质量的六个维度：

完整性、准确性、一致性、及时性、唯一性、有效性。

规则设计和监控： 将数据质量规则直接写在流水线中。

工程化的数据质量实践（把"规则"变成"可执行、可观测、可进化的系统"）：

规则要可声明、可测试：把质量规则写成数据/配置（规则的 DSL 或规则表），而不是散落在流水线代码里——这样每条规则都能被单元测试、能被追溯、能被业务方评审。
三类规则分治：①结构规则（字段是否存在、类型、非空、唯一）——通常自动生成；②业务规则（如"库存不能为负""金额必须等于明细之和"）——需与业务共同定义；③统计规则（均值/分布漂移、异常突刺）——用于发现"看起来合法但不对劲"的数据。
异常处理要"堵+通"并举：堵（拦截不合格数据、不进主链路）与通（自动告警并推送业务源头负责人修正）并行的 OK 模式，不能只堵不修、也不能只放行不改。
数据质量也要有 SLA：与客户约定关键指标的可接受范围（如"生产报表延迟 ≤ 15 分钟""核心字段完整率 ≥ 99%"），把质量从"尽力而为"变成"可验收、可持续的承诺"。
建立"数据管家"角色：在客户侧指定数据负责人（Data Owner），异常数据最终回流到他手里闭环，FDE 只做规则引擎和工具，不做永久的"人工洗数员"——否则 FDE 就被钉死在洗数据上，能力永远无法回注。

Caution

数据质量是"铲雪"不是"扫雪"：每一轮都用人力去修正同一类脏数据，说明规则没写进流水线。正确的做法是每发现一次重复性问题，就把"这一类的修正规则"沉淀进管道——这正是能力回注在数据维度上的最小闭环。

7.5 从原型到生产的工程实践：质量、代码与流水线¶

这是"从 0.5 到 1"最考验功力的阶段——原型可以"够用就行"，生产必须"可靠、可运维、可审计"。以下四件事是生产化的底线，缺一不可。

1. 代码审查（Code Review）标准：

原型期的"个人英雄式"提交到此结束，所有合入主干的代码必须经过至少一名同行评审。
审查关注点排序：正确性 > 可维护性 > 性能 > 风格。在客户生产环境里，一个隐蔽的逻辑错误远比一段"不够优雅"的代码致命。
关键路径（结算、风控、安全相关）必须双人复核（Four-eyes），并留痕。

2. 测试策略（分层的金字塔）：

单元测试：覆盖数据转换、清洗逻辑、规则引擎等纯逻辑——在规则 DSL 之上，单测就是最好的规则验证。
集成测试：验证与外部系统（ERP、数据源、消息队列）的对接契约是否成立。
端到端（E2E）/ 验收测试：跑通至少一条核心业务主链路，作为"从原型到生产"的移交验收标准。
即便客户环境受限，也要至少保证"核心业务闭环"有回归测试——原型期没测出来的问题，生产期会用事故还回来。

3. CI/CD 在客户环境的搭建：

生产环境往往在客户内网，无法直接拉公网依赖。常见做法是在客户环境内架设自托管的构建/发布流水线（如内网 GitLab Runner / 内网制品仓库），前置依赖镜像推入客户内网。
流水线要覆盖：构建 → 静态检查 → 测试 → 镜像/制品 → 部署 → （可选）回滚。
信创/私有化场景下，提前验证工具链（Git、构建器、Docker/容器运行时）在国产 OS/CPU 上的兼容性——否则到验收阶段才发现环境不支持就晚了。
可回滚是第一原则：任何部署都必须有可一键回滚的方案，尤其是金融、政务等不允许长时间不可用的场景。

4. 可观测与运维（Observability）：

生产系统至少要有：日志（Logging）、指标（Metrics）、告警（Alerting）。别到了客户报故障才靠 log 现场翻。
为关键数据管道设置运行状态看板，让"管道昨晚跑挂了"这类问题在客户察觉前先被己方发现。

7.6 安全加固清单（客户生产环境）¶

在客户生产环境部署，安全不是"加分项"而是"入场券"——尤其政务、金融、医疗客户。以下是最小安全基线：

1. 身份与访问（IAM）：

最小权限原则：FDE 与客户用户均按角色分配最小所需权限，杜绝"全员管理员"。
行级/列级权限与审计日志：确保谁看了哪个客户的数据都可追溯（金融合规硬性要求）。

2. 数据安全：

数据不出域：核心数据留在客户侧，必要的外发（模型训练、离线分析）走脱敏/联邦方案。
加密：传输加密（TLS）、存储加密（敏感字段至少加密落盘）。
密钥管理：凭据/密钥进密钥管理系统（Vault/云 KMS），不写死在代码或配置文件里。

3. 供应链与依赖安全：

对引入依赖做漏洞扫描（SBOM / CVE 扫描），锁版本、不盲目升级。
内部镜像/制品需有来源校验，防范供应链投毒。

4. 维护与应急：

与客户约定应急响应预案（故障级别、升级路径、RTO/RPO）。
保留变更记录：所有生产变更（发布、配置调整）留痕，便于回溯与审计。

Note

合规不仅限于技术：等保 2.0、数据安全法、个人信息保护法（PIPL）等制度约束，详见第 13 章的政企合规讨论与合规检查清单。技术安全基线只是其中"落地"的一环，制度与流程层面同样不可省略。

Important

AI 与本体项目的两项新增检查：

写回一致性：业务动作写回外部系统时，检查幂等键、重试策略与失败补偿；"外部成功、内部失败"要有可见状态与人工处置入口（附录 J V05）。
索引新鲜度：检查底表变化多久反映到对象与检索索引。部分平台的本体索引需手动或定时构建，不会随底表写入自动更新（第 14 章），必须事先约定新鲜度目标并测试删除传播（附录 J V01）。

7.7 用户培训与冠军用户培养¶

培训层次：

管理层认知培训： 如何通过系统看 KPI、做决策。
操作层使用培训： 手把手教标准 SOP 流程。
高级用户深度培训： 能够自行搭建看板或配置规则。

冠军用户的定义： 客户内部最积极使用和推广系统的人。 如何发现和培养冠军用户： 寻找痛点最深、反馈最积极的业务骨干，给予技术支持特权，并在内部推广时树立其为标杆。

Note

Build 阶段的重点是培养出单个或少数几名深度冠军用户（让系统先有人真正用起来、用出价值）。至于把冠军"由点连成网、依靠同侪影响力自发推广"，那是下一阶段（Scale）的任务——详见第 8 章的冠军用户网络建设。切勿在系统尚未做实做稳时就急于铺网。

7.8 能力回注识别：构建期是回注的黄金窗口¶

为什么构建期最适合识别回注点？ 因为此时经历了从原型到生产的锤炼，逻辑最成熟、最贴近真实痛点。

回注信号识别： "这个功能在其他客户（比如同行业的竞争对手，或跨行业的类似场景）那里，也会需要吗？" 建议： 每周记录"能力回注日志"。

能力回注需求卡片模板（SOP 4）

Tip

SOP 4: 能力回注需求卡片

字段	填写内容示例
需求名称	供应链多级库存水位动态优化算法插件
来源项目	某快消企业数字供应链大脑项目
通用性评估	极高（适用于仓储调拨）
技术方案简述	基于 Ontology 的参数化模型，输入为：节点库存、运输时效；输出为：调拨建议
工作量评估	约 2 周开发 + 1 周测试联调
ROI 预测	预期能为后续项目节约约 30%的定制开发时间
优先级建议	高 (High)

7.9 与 Palantir Sequencing Development 的对齐：开发排序（RICE 变体）¶

Build 阶段的官方方法论强调"开发排序"——不是把所有需求一起做，而是按"用户价值递减"排序、滚动交付。客户的资源与耐心都是有限的，最忌一次性铺开所有功能：既拉长价值可见的时间，又让 FDE 团队疲于应付、什么都做不深。

Note

排序原则是要回答一个前置问题："这个功能明天就上线，还是放到下周、下个月？" 排序的依据不是功能的技术炫酷程度，而是它给真实用户带来的价值大小与确定性。以下 RICE 变体正是把这一判断拆成了四个可打分的维度。

RICE 因素表（交付排序评分框架；RICE 为业界通用的需求优先级评分法，源自 Intercom，本表为面向 FDE 交付的本地化变体）：

因素	权重	说明	评分口径示例
Reach（触达面）	高	多少用户每天会用到这个功能	覆盖核心业务角色的比例
Impact（影响度）	高	对客户核心 KPI 的改善幅度	对收入/成本/效率指标的拉动
Confidence（可信度）	中	我们对上述估计有多确定	有数据/试点支撑 vs 纯猜测
Effort（工作量）	中	需要多少人天	人天估算及其稳定度

Tip

读法与使用：Reach、Impact 权重高，优先保住客户最核心的日常价值；Confidence、Effort 权重居中，用于在"高价值但心里没底/很费工"的功能之间取舍。建议对候选功能逐一打分后排序，把"高 Reach、高 Impact、高 Confidence 且 Effort 可控"的功能前置，把高价值但高不确定、高成本的功能与客户明确后置或砍掉。

排序后的 8 周示例交付节奏：

第 1-2 周： 核心数据管道 + 最高 Reach 的功能——先把主链路跑通，让最多用户"用起来"。
第 3-4 周： 权限体系 + 数据质量规则——把安全基线与质量规则落到生产。
第 5-6 周： 次要功能 + 培训——在主干稳定的前提下补齐周边能力，并同步展开用户培训与冠军用户培养。
第 7-8 周： 能力回注识别 + Gate 准备——沉淀可复用能力，对照阶段 Gate 清单收尾移交。

Caution

排序不是"一次性定死"。每周应以价值反馈为准回调节奏：某功能触达面比预估高，就提前；某功能引进新数据源风险大，就后置。排序服务于"持续交付价值"，而不是给 FDE 自己贴一张静态的排期表。

7.10 生产化的"可运营移交"标准¶

Build 的终极产出不是"系统能跑"，而是"FDE 撤场后系统还能跑"。一个只在 FDE 驻场期间正常、撤场即瘫痪的系统，本质上仍是原型。所谓"可运营移交"标准，衡量的是：系统是否具备进入"能力转移"阶段的技术条件——即客户自己的团队不需要 FDE 也能维持系统运转。这是输出交付物能否真正被客户接住的分水岭。

Important

先分清三个环节，勿把"移交准备"当"已经撤场"：

本节（Build 侧）只管一件事：系统是否具备进入能力转移的技术条件（运维手册、值班 SOP、健康度看板是否备齐）。Build Gate 通过 ≠ 客户已接管、FDE 可撤场。
第 8 章（Scale 侧）才回答：客户如何从观摩、辅导逐步进入自治，FDE 何时、按什么路线撤出（撤场是 Scale 阶段逐步完成的动作，不是 Build 结束时一次性发生的）。
第 11 章（协作侧）回答：甲乙双方各自交什么、验什么、签什么（交接的具体清单与验收/签字安排）。

本节是"能不能转"的技术准备，真正"转出去了没有、要不要撤"，看第 8 章与第 11 章。

Important

可运营移交的三件套——这几样缺一不可，是系统"能否进入能力转移"的硬性标准：

1. 运维手册（而非只有开发文档）：

开发文档回答"系统是怎么实现的"；运维手册回答"系统要怎样才能一直正常"。
至少覆盖：部署与版本升级步骤、配置清单及其修改方法、常见故障的表征与处置、备份与恢复流程、回滚方案。
措辞面向值守者而非开发者：让不熟悉代码的客户运维也能按步骤操作。

2. 值班 SOP（谁在什么时候看什么指标、出问题找谁）：

明确谁（客户侧值守人）、什么时候（每日/每周/告警触发时）检查哪些指标。
明确定义故障升级路径：第一响应人 → 客户 IT → 对应的 FDE 或厂商支持，各自联系方式与响应时限。
值班 SOP 要贴出"当 XXX 指标异常时，先做 A，再做 B，仍未解决则联系 C"，避免故障发生时现场抓瞎。

3. 数据管道的健康度看板（客户自己能看到"昨晚的管道跑成功了吗"）：

面向客户侧，而非仅 FDE 内部使用。
关键指标：上次成功运行时间、成功/失败状态、数据延迟、处理行数、质量规则命中数。
让客户在 FDE 撤场后依然能自证管道健康——"昨晚的管道跑成功了吗"这个问题，客户自己打开看板就能回答，而不是打电话问 FDE。

Tip

自我检验：可以在正式撤场前做一次"FDE 静默演练"——某段时间内 FDE 不参与日常值守，只看客户能否凭运维手册、值班 SOP 与健康度看板独立完成一次完整的巡检与故障处置。能独立完成，才算真正"可运营移交"（这是进入第 8 章撤场路线的技术前提）。

7.11 输出交付物¶

完全可用的生产级系统。
完整的数据资产字典与 Ontology 说明文档。
系统操作手册与管理员维护手册。
运维手册与值班 SOP（见本节"可运营移交的三件套"）。
数据管道健康度看板（客户侧可自查看的天数）。
能力回注需求卡片。
大规模培训签到表及满意度问卷。

7.12 阶段 Gate 检查清单¶

Important

Build Gate 检查清单

核心数据管道是否已实现自动化调度并稳定运行？
系统的行级/列级安全权限是否已通过客户合规部门/IT 部门验证？
是否已建立代码审查、测试与 CI/CD 流水线，且核心业务闭环有回归测试？
是否已对照安全基线完成安全加固，并与客户确认应急与回滚预案？
是否已至少培养出 3 名能够熟练使用系统的客户方冠军用户？
是否已将通用业务逻辑提取，并提交了能力回注卡片？
客户业务部门的核心指标是否初步通过系统得到体现并确认？
对应交付物：本 Gate 各项与输出交付物清单逐项对应，验收时逐项勾对。
未通过怎么办：Gate 未全部打勾时的分级处置（轻微/重大/致命，含"架构性错误回退 Prototype 重验"）、跨阶段回滚与止损判据，见第 5 章 How 总纲"四、阶段 Gate 的运行规则"。

Important

本章小结：构建期把原型改成可靠、可运维的生产系统，数据质量、工程实践、安全加固和用户培养缺一不可。它也是识别能力回注点的黄金窗口，移交标准和 Gate 清单决定能否进入扩展期。