AI Native Builder

主题

第 3 章｜外部 FDE 与内部 AI Native Builder ​

澄川工业的试点结束时，外部团队交付了一套可以运行的系统。会议记录能进入处理流程，销售可以查看 CRM 更新预览，写入沙盒的动作也有日志。项目总结会上，所有人都同意“第一阶段完成”。

两周后，外部 FDE 林越离场。销售经理才发现，团队没人知道新产品资料应由谁加入知识库；IT 只负责接口可用，不负责判断字段规则；安全团队批准过试点权限，却没有约定什么时候复审；那批评估样本则留在供应商的项目空间里。

系统还在线，建设却停了。这个差异构成了本章的问题：当外部交付已经能够产生结果，企业为什么还需要一种内部建设能力？

这一章会给出 AI Native Builder 的正式定义，说明它与外部 FDE 分别站在项目哪一侧、对什么结果负责，以及怎样合作。最后，我们会跟着澄川团队开一场角色契约会议，把模糊的“共同负责”改成明确的决定权、证据和停止条件。

交付物留下了，能力不一定留下 ​

部署项目通常会留下代码、配置、接口文档和培训材料。这些都很重要，但它们只记录了系统在某个时点怎样工作。业务政策会变化，模型会更新，用户会形成新习惯，风险也会随着权限和使用范围改变。

当这些变化出现，组织需要有人重新连接四类信息：业务为什么改变，系统哪里受影响，现有评估是否仍有效，哪些负责人必须参与决定。如果只保存最终方案，而没有保存这些判断如何形成，下一次修改时，组织就只能把这些判断重新发现一遍。

澄川的问题并不在于外部 FDE 没有完成交付。相反，我们在第 2 章已经看到，FDE 对现场发现、构建、运行、采用和产品反馈有很强的端到端责任。OpenAI 的 FDE 岗位说明也明确把这类工作放在客户交付与供应商核心平台之间。

缺口来自视角不同。供应商需要让自己的产品在客户现场成功，并把高频模式带回产品。客户组织还要长期维护本公司的知识、权限、流程、采用和跨团队复用。这些责任可能与 FDE 合作，却不会自动由一次外部部署解决。

AI Native Builder 描述的是另一份工作合同：有人站在企业内部的能力建设立场，把一次 AI 项目从问题发现推进到生产使用，并帮助团队或公司持续走向 AI Native。它并非 FDE 的新名称，也不代表 FDE 进入企业后的下一阶段。

本书怎样定义 AI Native Builder ​

AI Native Builder 目前不是一个边界统一、获得外部认证的行业标准岗位。不同企业可能把相近责任分配给产品经理、AI 工程师、解决方案团队、数字化负责人或业务创新团队。

本书提出这个名称，是为了给一组容易散落在多个岗位之间的责任建立共同语言。它是一套工作定义，也是一种学习目标：

AI Native Builder 是企业内部的建设者：从真实业务结果出发，找出哪些问题值得用 AI 解决，把 AI 效果做成跑得稳、评得出、管得住的系统，再推进到生产环境让团队真正用起来。

拆开来说是三件事：

  1. 判断业务里哪些问题适合用 AI、值得用 AI；
  2. 把 AI 输出从“偶尔好用”变成稳定效果；
  3. 把系统推到生产里，让真实团队在日常工作中用得下去。

这一定义没有要求一个人独自完成所有专业工作。Builder 可以是单一岗位，也可以由一个内部小组共同承担。这三件事会展开为七段相互连接的责任：

text
发现 → 重构 → 构建 → 评估 → 治理 → 采用 → 复用

这七个动词各自指向一段实际责任，既不是 FDE 能力清单的改写，也不是用来背诵的流程标签。发现与重构帮助团队选择值得建设的问题；构建、评估和治理帮助团队稳定 AI 效果；采用与复用检查应用能否进入真实工作，并逐渐成为组织能力。这几段责任是交织迭代的，不是各走各的流水线。

接下来逐段看这条链如何在澄川发生。

发现：先找出值得改变的工作 ​

“发现”要得到的不是愿望清单，而是对当前任务、用户、基线、约束和责任人的可检查描述。在澄川，最初愿望是“自动写会议纪要”，现场观察却显示主要负担来自查资料、区分事实与判断、重复填入 CRM。

合格的发现会留下证据。可以是一段用户访谈、一次工作观察、系统日志或现有表单。证据不必一开始就完整，但团队必须知道哪些是事实，哪些只是经理判断，哪些仍待验证。

Builder 在这一段承担牵引责任：找到正确用户，让技术约束尽早进入讨论，并把大而模糊的问题收缩到可以判断的任务。业务负责人仍然拥有业务目标，Builder 不能替他决定什么结果值得公司投入。

重构：决定人、AI 和系统怎样重新分工 ​

知道痛点之后，团队很容易直接问“模型能做什么”。重构先问另一组问题：哪些步骤应该消失，哪些可以规则化，哪些需要模型判断，哪些必须由人决定，系统状态怎样流转。

澄川没有保留“先写完整纪要，再手工复制”的旧路径。新路径让 AI 抽取客户原话、显示产品依据并准备 CRM 更新，销售只核对高价值判断。这种改变不是在每个旧步骤旁边放一个 AI 按钮，而是重新安排任务和责任。

重构也包括主动不用 AI。会议参与人名单来自日历，字段映射由确定性规则完成，没有理由让模型猜。Builder 要把“更聪明”从方案目标里拿掉，改成更明确的判断：这一步是否真的需要不确定的语言推理。

构建：把工作流变成可运行系统 ​

构建阶段把任务对象、上下文、工具、状态和人机界面连接起来。它不要求 Builder 亲自编写每一行代码，但要求他能和工程团队一起把业务判断翻译成可测试的系统契约。

在澄川，客户原话、销售判断和建议动作是三类不同对象。产品资料带版本和有效期。CRM 写入先生成预览，再由用户确认。错误发生时，系统保留轨迹并允许查询实际状态。这些设计让后续评估有可观察对象。

如果构建只留下一个聊天框，团队就很难回答系统用了什么依据、调用了哪个工具、改变了什么状态。功能看起来更简单，验证和恢复却会变得更难。

评估：用任务证据决定能不能继续 ​

模型给出的句子“看起来不错”，只说明某一次输出通过了人的直觉检查。项目需要更具体的评估：关键事实是否有依据，字段是否正确，工具选择是否恰当，写入后的状态是否符合预期，用户是否需要大量修改。

Builder 要推动团队建立样本、评分方法、失败分类和版本记录。业务专家定义什么算正确，工程团队提供可观测数据，产品团队决定体验门槛。Builder 连接这些输入，并确保结果会改变发布决定。

评估不是只在上线前举行一次考试。资料变更、模型升级、提示修改或工具接口调整，都可能让旧结论失效。澄川需要知道评估集由谁维护、何时重跑、哪些失败会阻止扩大试点。

治理：让权限和责任跟着动作走 ​

生成摘要和向客户发信不是同一种风险。读取公开产品资料、读取客户数据、修改 CRM、发送外部承诺，也不能共享一张模糊的“系统已授权”证明。

治理要落到动作：谁可以批准数据使用，哪个身份调用工具，哪些字段允许写入，哪些结果必须人工确认，发生错误时谁有权暂停。安全、隐私、法务和业务负责人拥有各自正式决定权，Builder 的任务是让这些决定进入系统设计和发布门槛。

如果治理只在最后做一次审查，团队往往只能在“全部放行”和“全部停止”之间选择。较早拆开动作与风险，反而能让低风险部分先运行，把高风险部分留在人工控制中。

采用：确认真实用户是否改变了工作 ​

系统上线并不自动产生采用。用户可能试过一次后回到旧方法，也可能让助理代为操作，或者只在演示给经理看时使用。登录次数无法解释这些行为。

Builder 要观察真实任务：谁在什么情况下使用，在哪里修改，何时放弃，是否另建了一套影子流程。澄川若只看摘要生成量，会错过销售在生成后仍然手工重写 CRM 的事实。

采用工作通常需要培训、支持、界面调整、激励和流程责任共同变化。Builder 可以推动这些动作并提供证据，但不能替代销售经理管理团队，也不能把用户不采用一律解释为“抗拒变化”。

复用：让第二个团队不用重买一次发现过程 ​

一次项目产生的资产不只有代码。问题定义、流程图、评估样本、失败分类、工具契约、权限决定、运行手册和停止条件，都可能帮助下一次建设。

复用也不是把澄川方案原样复制给另一个部门。采购团队的对象、风险和流程不同。可复用的是经过抽象的模式：如何标记知识有效期，如何把写入拆成预览与提交，如何处理部分成功，如何记录人工修改原因。

检验复用最直接的方法，是让第二个团队在有限帮助下使用这些资产。如果他们仍需要原项目成员口头解释每个关键决定，资产就没有真正离开个人。

两种角色怎样分工与合作 ​

FDE 与 AI Native Builder 都会进入真实工作、缩小问题、先构建范围明确的可运行方案、观察生产采用。这些相似动作来自企业 AI 落地面对的共同困难，不表示一个角色继承自另一个角色。

外部 FDE 的首要目标，是让供应方的模型或平台在客户现场产生结果，并把重复模式和失败反馈给供应方产品。内部 AI Native Builder 的首要目标，是推动本公司的团队和流程走向 AI Native；他对本组织的业务优先级、知识、权限、评估、采用和长期能力建设负责。

两者可以在同一个项目中合作。外部 FDE 带来产品能力、部署经验和跨客户观察，内部 Builder 确认本组织值得解决的问题，连接业务与专业负责人，并确保系统离开供应商的高强度支持后仍有人维护、评估、使用和停止。具体分工仍要写进项目合同。

澄川的角色契约会议 ​

项目第二阶段准备把 CRM 写入从沙盒移到小范围生产。会议上，销售经理希望系统自动完成所有字段，理由是“用户每次确认就省不了多少时间”。IT 认为接口已经通过测试，剩下都是业务决定。安全同事则要求任何写入都逐条审批。

三方都在维护各自合理的目标，却没有用同一种动作粒度讨论。Builder 周岚把“自动写 CRM”拆成五个动作：读取客户记录、生成字段建议、显示依据、更新批准字段、创建对外跟进任务。每个动作分别讨论数据、权限、错误代价和恢复办法。

她没有替安全团队批准权限，也没有替销售经理接受业务风险。她先把决定结构写在屏幕上：

试点范围由 Builder 提议，销售负责人确认用户和任务；字段含义由销售运营负责，接口身份与技术权限由 IT 负责，风险等级和审批要求由安全团队决定；Builder 负责把这些决定实现为流程、评估和运行证据。

讨论后，团队决定：读取和生成建议可以自动执行；预览必须显示依据；两项低风险字段在销售确认后写入；价格承诺与对外任务继续由销售手工完成。若出现未经确认的写入、重复任务或敏感信息泄露，试点立即暂停。

这份约定的价值，是每个决定都能改变系统行为；分工表写得是否工整并不重要。谁批准、拿什么证据批准、批准作用于哪个动作、什么事件会撤销批准，都有了明确答案。

Builder 不是全包的项目负责人 ​

七段责任很宽，最危险的误读是让 Builder 包办所有事情。业务目标需要业务负责人承担，产品路线需要产品角色长期维护，工程可靠性需要专业工程团队，安全与隐私决定也必须由具备正式授权的人作出。

Builder 的独特责任是连接。他要看见一项业务选择怎样改变系统对象，一项模型失败怎样影响用户采用，一项权限决定怎样限制试点范围，并让相关负责人基于同一份证据作出决定。

如果组织把所有责任都压给一人，短期沟通可能更快，长期却会出现两个问题：专业判断失去制衡，知识再次集中在个人。AI Native Builder 不是对职能分工的否定，而是一份跨越交接处的建设责任。

相邻角色与它会有明显重叠，区别仍然要看项目合同：

角色常见强项与内部 Builder 的分工
产品经理用户、需求、范围和路线运行评估、风险动作与能力交接
AI 工程师模型、上下文、工具和可靠性业务基线、采用与跨团队复用
解决方案架构师系统集成、架构和技术范围持续工作流结果与用户行为证据
业务咨询诊断、流程、价值和变革把建议推进为可运行、可评估系统
自动化开发者快速连接系统和规则流程不确定性评估、行动治理与资产责任
外部 FDE供应方产品的端到端客户部署和产品反馈内部 Builder 持有本公司的目标、政策、授权、采用与长期能力

这张表不是招聘职级对照。现实中的一个人可能跨越多列，一个团队也可以共同承担 Builder 合同。使用它时，先看当前项目缺少哪段责任，再决定由谁补上。

三种常见成长起点 ​

业务或交付背景的人通常擅长发现、范围判断和采用。他们知道怎样进入现场、处理利益相关者分歧，却需要补系统对象、工具契约、评估和可靠性。

技术背景的人擅长构建、调试和运行。他们能快速识别数据与接口限制，却需要练习业务基线、用户观察、工作流重构和组织采用，避免把可实现性当成价值。

产品或项目组合背景的人擅长排序、资源协调和治理门槛。他们需要保持对一线任务的接触，并能亲自读懂失败样本和运行轨迹，否则“复用”容易变成没有现场依据的平台规划。

三种起点都可以成长为 Builder。目标是拥有一项能亲自下场的强项，同时能识别其他责任何时需要专业伙伴；把所有能力练到同一深度既无必要，也不现实。

写一份能改变项目的角色契约 ​

角色契约不是岗位说明书。它只服务当前项目，至少要回答五件事：Builder 推动什么结果，必须交付哪些证据，可以独立决定什么，哪些决定需要谁批准，出现什么情况必须停止或重新讨论。

一个较弱契约常写成这样：

Builder 负责协调业务与技术团队，推动 AI 助手落地；各部门积极配合，项目成功后推广到全公司。

这段话没有对象、证据或决定权。“推动落地”可以包含任何事情，“积极配合”无法处理分歧，“成功”也没有判定方式。出现错误时，没有人知道谁能暂停。

一个合格契约可以写成：

Builder 负责把销售会后跟进改造成可运行试点，并交付问题定义、流程、版本化评估、权限记录和采用报告。Builder 可提议试点范围与人审位置；销售负责人批准用户、字段语义和业务目标；IT 批准写入身份；安全团队批准数据与动作边界。任何未经确认的写入或敏感信息泄露都触发暂停。是否扩大使用由销售负责人基于质量、采用、负担和事件记录决定。

后一个版本仍没有让 Builder 拥有所有决定，却让他对证据和连接承担明确责任。每位专业负责人也知道自己的批准会作用于哪一部分系统。

你的练习 ​

为自己的项目写一页角色契约。先写一句项目结果，再分别写出 Builder 的交付物、可提议事项、必须取得的批准、停止条件和下一次复审时间。若只能做虚构案例，要在标题下标明“教学模拟”，不要把练习结果写成真实授权。

完成后做一次反向检查：删掉“负责协调”“推动落地”“保障成功”这类宽泛动词，剩下的句子是否仍能指导一次分歧会议？如果不能，为每句话补上对象、证据或决定人。

本章小结：内部建设者对组织变化负责 ​

FDE 让供应方工程能力进入客户现场，并对端到端部署和供应方产品反馈负责。AI Native Builder 站在企业内部，持续回答哪些问题值得用 AI、怎样稳定效果、怎样进入生产使用，并推动这些能力进入团队的日常工作。

叫不叫这个名字不重要。一个组织完全可以不用“AI Native Builder”这个头衔，但如果这七段责任长期散着没人串，AI 项目还是会在交接处卡住。

下一章，澄川准备让助手从“生成预览”走向“调用工具”。当 AI 能改变真实系统状态，Builder 面对的对象会从内容质量扩展到权限、轨迹、恢复和人类责任。

下一章：为什么智能体时代更需要 AI Native Builder

本章来源与定义边界 ​

“AI Native Builder”、三条课程承诺、七段责任链及本章角色契约均为本书作者提出的教学框架。外部资料只用于说明 FDE 等供应方客户交付角色的公开职责，不构成 AI Native Builder 的概念来源、外部认证或岗位标准。