AI Native Builder

主题

第 1 章｜为什么企业 AI 需要新的建设角色 ​

那个已经“成功”的演示 ​

[!example] 教学案例 本章中的澄川工业及相关人物、数据均为教学设定，只用于展示项目判断。

周五下午，澄川工业的会议室里正在演示“客户跟进助手”。项目成员上传一段脱敏会议记录，几秒钟后，页面生成了结构清楚的摘要、三个客户需求、两项风险和一组行动建议。

销售经理看完很满意。他问：“下个月能不能让全部销售都用起来？”技术团队也松了一口气。模型输出通顺，演示没有报错，计划里的主要功能都出现了。按原来的项目定义，这个原型已经成功。

坐在后排的销售许岚却没有马上点头。摘要把客户提到的“希望六月前完成”写成了“承诺六月前交付”；行动建议引用了一份半年前的产品资料；其中一个 CRM 字段在正式系统里还需要经理批准。她如果逐条核对，可能并不比自己整理更快。

项目成员继续追问，问题很快变长：系统应该从哪里取得有效产品资料？怎样区分客户愿望和公司承诺？写入失败一半时，已经更新的字段怎么处理？销售修改了多少内容才愿意提交？经理想改善的是记录完整率，还是后续任务逾期？

这些问题都无法靠“再换一个更强的模型”直接回答。演示已经证明模型能够生成内容，却没有证明新的工作方式能够成立。

本章要解释的就是这段距离：模型已经足够有用，企业为什么仍需要一种新的建设角色？

这个角色要持续回答三个问题：业务中哪些问题能用、值得用 AI 解决；怎样把 AI 的效果稳定下来；怎样把 AI 应用推进生产环境，让它在真实工作中可用。本书把在企业内部牵引这三项工作的建设者称为 AI Native Builder。

一次模型调用，为什么会变成一项组织工程 ​

个人使用 AI 写邮件时，链路很短。使用者知道背景，自己提供材料，生成后自己判断，也承担发错内容的后果。AI 没有得到邮箱权限，通常也不会在用户不知情时改变其他系统。

企业流程会把这条链路拉长。会议摘要可能来自录音转写、CRM 历史、产品资料和销售政策；输出需要进入商机、任务和审批系统；不同字段由不同角色负责；错误会影响同事、客户和后续决策。

可以把一项企业 AI 建设写成下面这条链：

text
业务结果
→ 真实任务与流程
→ 数据、知识和上下文
→ 模型判断
→ 工具与系统动作
→ 环境状态
→ 人类责任
→ 质量与风险评估
→ 持续采用
→ 组织复用

这条链并不只向前走。评估发现资料过期，团队要返回上下文设计；试点发现销售绕开系统，团队可能要返回流程重构；第二个团队无法使用已有资产，也会暴露最初方案过度依赖作者本人。

每个箭头处都要做一次转换：业务目标要拆成可观察的任务，政策得落到系统能执行的约束上，模型输出要接上带权限的动作，技术指标也得换回用户和业务能看懂的说法。哪一步没转过去，局部成功就跟整体结果脱了节。

澄川案例里，模型已经正确完成了一部分语言任务。问题出在整条建设链没有共同的负责人：业务方等待技术交付功能，技术方等待业务提供需求，安全人员直到准备上线才看到权限设计，销售则在演示结束后才第一次接触新流程。

五个责任断层怎样连续出现 ​

企业 AI 项目很少因为某一个错误瞬间失败。更常见的情况是，几个看似合理的交接依次发生，最后没有人能解释结果为什么没有出现。

业务愿望没有变成可验证问题 ​

澄川项目最初收到的需求是“做一个会议纪要 Agent”。这句话给出了方案名称，却没有说明谁遇到了什么问题。经理关注 CRM 字段是否完整，销售关心会后工作是否占用晚上时间，销售运营则担心行动项没有负责人。

如果团队直接围绕“纪要 Agent”开工，三种问题会被压成一个功能。项目完成后，即使摘要很好，也无法判断它是否改善了经理、销售或销售运营真正关心的结果。

业务人员了解现场，却未必知道怎样把经验变成可测试的系统问题；工程人员能够实现方案，却可能在问题尚未确认时过早接受了功能名称。第一个断层出现在业务语言与建设语言之间。

原型没有进入生产条件 ​

演示使用的是一段经过整理的文本，产品资料也由项目成员提前放进提示词。真实任务中的录音可能缺失，资料存在多个版本，销售身份决定他能查看哪些客户记录，CRM 写入还会产生外部状态变化。

生产系统需要处理身份、权限、版本、日志、超时、重试、部分成功和人工接管。原型可以用人工准备掩盖这些问题，真实流程不会。第二个断层出现在“能够展示”与“能够受控运行”之间。

输出质量没有自动变成业务结果 ​

假设新系统把摘要生成时间从十分钟降到一分钟，销售却需要十五分钟检查来源、修正承诺和补充遗漏字段。模型环节更快了，端到端工作反而可能更慢。

项目还可能提高记录完整率，却没有减少行动项逾期，因为逾期来自资源不足或经理没有及时分配负责人。输出指标发生变化，并不代表业务结果会因同一个原因而改变。第三个断层出现在局部质量与净价值之间。

上线没有带来持续采用 ​

账号开通、培训完成和调用次数上涨，只能说明用户获得了入口。销售可能在培训当天尝试一次，随后回到自己的模板；也可能复制 AI 内容，却绕开正式 CRM 写入。还有人会因为审查负担太重，从一开始就拒绝使用。

采用意味着用户行为的改变：在真实任务中尝试、采纳、重复使用，并在项目组减少陪同时仍能完成工作。第四个断层出现在技术发布与工作方式改变之间。

第一个团队的成功没有变成组织能力 ​

即使澄川的销售团队最终稳定使用，项目仍可能依赖最初的 Builder 手工更新资料、解释错误和修复集成。换到售后团队后，原来的字段、评估样本和权限规则都不再适用，第二个团队只能重新开始发现。

只有当经验被整理成有适用条件、版本、负责人、评估和退役机制的资产，下一次建设才可能更便宜、更稳。第五个断层出现在单点交付与组织复用之间。

这五个断层并非五项并列的检查项，它们会互相放大：问题定义含糊会让评估无从设计；评估不足会让试点只看活跃度；试点证据失真又会推动一个不值得维护的方案过早产品化。

企业正在怎样描述这类工作 ​

AI 公司公开材料不能单独证明某种组织模式必然成功，但岗位与服务设计能够说明它们正在把哪些责任放到同一支团队里。

Anthropic 在 2026 年 5 月公布一家新的企业 AI 服务公司时，写道：把 Claude 用于组织核心运营，既需要现场工程能力，也需要理解每家企业怎样运行。其描述的典型合作从小团队与客户共同寻找影响点开始，再由工程人员结合客户现场知识构建系统并长期支持。查看 Anthropic 原文。

OpenAI 当前的 Forward Deployed Engineer 岗位说明则把发现、技术范围、系统设计、构建和生产发布放在一个端到端角色中，并把生产采用、可度量的工作流影响、评估驱动的产品反馈列为成功信号。查看 OpenAI 岗位说明。

这两份资料出自不同的组织背景，却指向相似的外部交付现实：当供应方把 AI 带进客户的重要流程，模型能力、客户现场、系统交付、采用和反馈很难由彼此隔离的团队依次转交。

这些材料能够说明 FDE 等供应方角色正在怎样处理客户落地，不能替企业定义内部责任。第 2 章会进一步介绍 FDE，并把它明确放在外部合作方的位置；第 3 章再说明企业内部为什么仍要有自己的 AI Native Builder。

同一个任务，可以有三种 AI 形态 ​

“AI 赋能”“AI 增强”和“AI 原生”在本书中是用于诊断的工作定义，不是行业统一的成熟度等级，也不存在必须从第一档升级到第三档的路线。

先看 AI 赋能。许岚把会议记录粘贴到个人 AI 工具，得到一份摘要，再手工复制到 CRM。这个方法几乎不改变原流程，启动很快，也适合低风险的个人草稿。但资料来源、提示方式和质量判断都留在个人手中，组织很难观察或复用。

AI 增强会改造局部任务。系统自动取得经授权的会议记录，生成带来源的结构化草稿，销售确认后再提交。它减少复制和整理工作，同时保留销售的关键判断。路径大体稳定，通常用确定性流程控制步骤，让模型处理语言理解。

AI 原生设计从业务结果重新检查整条工作链。团队可能先删掉重复录入，统一行动项对象，再决定哪些内容由模型提取，哪些由规则校验，哪些必须由销售或经理批准。模型进入流程内部，但不一定获得更高自主性。

三种形态可以总结如下：

形态澄川案例中的做法主要建设责任容易忽略的问题
AI 赋能销售用通用工具生成草稿并手工复制使用规范和个人判断结果不可观察，知识留在个人
AI 增强系统准备带来源的 CRM 更新，销售确认提交集成、上下文、人审和基础评估局部优化可能增加其他环节负担
AI 原生从会后结果重新设计对象、流程、责任和系统端到端工作流、评估、治理、采用与复用容易为了“原生”而过度使用 Agent

AI 原生的判断标准不在于用了多少 AI。一个团队发现问题可以通过删除审批、增加表单必填或普通系统集成解决，这同样是合格的建设结果。不确定的部分交给模型，稳定的规则写进软件，高风险决定让有责任的人来拍板——这样做通常比追求全自动更可靠。

新角色怎样与现有专业角色合作 ​

一次澄川项目评审会上，销售经理负责确认哪些业务结果值得改善；销售代表说明实际任务和审查负担；产品经理决定体验与范围；工程师评估集成和运行可靠性；数据负责人确认资料来源；安全和 IT 人员审查权限与正式写入。

如果没有连接者，这场会议容易变成六份互不相干的意见。业务说“尽快上线”，工程说“需求不清”，安全说“准备好方案再来评审”，销售则担心系统增加工作。每个人都可能是对的，但项目仍然无法前进。

AI Native Builder 要做的是把分歧转成可以决策的材料。例如，他可以把“尽快上线”改成一个限定范围的影子试验；把“需求不清”改成三条待验证假设；把安全人员关心的写入风险落实为只读工具、字段白名单和人审节点。

Builder 没有因此获得所有决定权。他不能代替销售经理承诺业务结果，不能代替安全人员批准权限，也不能绕过工程团队决定生产架构。这个角色拥有的是建设链的牵引责任：发现缺口，召集正确的人，让决定基于同一份证据，并跟踪决定是否在系统和现场中兑现。

把一个工具愿望改写成项目 ​

下面用澄川项目展示问题表述怎样逐步变得可以验证。

第一版只有一个方案名称：

为销售团队做一个会议纪要 Agent。

它没有用户任务、问题证据或成功标准。第二版补上发生场景：

销售在客户会议结束后，需要整理纪要、更新 CRM 并创建行动项。项目希望减少会后整理工作。

这时已经能看到用户和任务，但“减少”仍无法测量，也不知道问题是否真的来自整理。第三版加入证据计划和替代解释：

先抽样记录销售会后处理的操作时间、等待时间、字段遗漏和返工，确认主要负担来自信息整理、重复录入，还是审批和责任分配。

团队现在保留了“不使用 AI”的可能。第四版加入方案动作与风险边界：

如果问题得到证实，系统为销售准备带来源的结构化纪要和 CRM 更新预览。销售确认后才能写入沙盒；价格、交期和正式商机阶段禁止自动提交。

最后一版说明试点要支持什么决定：

试点比较端到端耗时、关键字段完整率、人工修改、放弃使用、支持成本和高风险错误。净负担没有下降，或任何高风险动作绕过批准时，项目停止扩大并返回流程与系统设计。

完整表述不保证项目成功，但能让项目有可能被证伪。团队能够知道需要什么材料、哪些动作被允许、怎样判断继续，以及什么情况应该停止。

轮到你改写 ​

从自己的组织中选择一个 AI 想法，先保留原始说法，再完成三次改写。每次只补一层：先补用户和触发事件，再补证据与基线，最后补动作、风险和阶段决定。

一个较弱的答案可能是：

做一个客服知识库，提高客服效率和回答准确率。

它给出了工具和愿望，却没有说明客服在哪类任务中受阻，也没有解释“效率”和“准确”怎样观察。

一个达到本章要求的答案可以写成：

客服处理退换货咨询时，需要在三套资料中查找规则。第一阶段抽样最近两周的真实工单，记录查找时间、转交、引用错误和返工，确认问题来自检索还是政策冲突。如果问题成立，先提供带出处的候选答案，由客服确认后发送。涉及补偿金额和例外审批时只提示流程，不自动承诺。试点根据端到端处理时间、引用正确率、人工修改和升级率决定继续或停止。

后一个答案的优势来自可检查性。别人能够检查问题是否存在、方案是否改善任务、风险是否受到控制，以及什么证据会让团队改变决定。

完成后，请用四个问题自评：你是否写出了真实角色和触发事件？是否保留了不用 AI 的选项？是否区分模型输出与业务结果？是否说明谁能批准高风险动作？答不上来的部分，就是下一轮需要补的现场证据。

这一章留下的判断 ​

企业 AI 的难点并没有随着模型变强而消失。模型越能处理开放内容、调用工具和参与决策，业务问题、系统状态、权限、评估和人类责任之间的连接就越重要。

AI Native Builder 由此出现：他负责把整条建设链串起来，让专业角色围绕同一问题和同一份证据协作，发现到复用之间哪个环节断了，就盯住哪个环节，直到有人接住。这是一份角色契约，不是一个“什么都能搞定”的岗位。

下一章将介绍外部合作方一侧的 Forward Deployed Engineer。我们会看 FDE 怎样把供应方的工程能力带到客户现场、完成生产交付并反馈产品。理解这份外部责任后，第 3 章才能更清楚地定义企业内部 AI Native Builder 的位置。

继续阅读：第 2 章：FDE 是什么。

本章来源 ​