AI Native Builder

主题

第 10 章｜把一次项目变成组织能力 ​

澄川试点作出“缩小并迭代”后，项目组把流程图、提示词、工具说明、评估表和使用手册放进一个共享目录。华南渠道销售组听说项目有效，复制文件，打算用在自己的会后记录中。

两个小时后，他们仍没能生成第一张可信预览。手册里的“风险备注”沿用大客户销售的定义，渠道团队却需要记录经销商承诺；批准资料 v2.3 对他们没有访问权；工具示例中的负责人映射也找不到对应角色。

原项目作者加入会议，边解释边改配置。系统最终在沙盒跑了起来，但第二团队搞不清哪些改动属于本地适配，哪些已经破坏了原有安全约束。文件是复制过去了，能力并没有跟着过去。

第 9 章证明窄场景里出现了使用与提速信号，也暴露了支持成本和范围问题。本章要决定哪些部分值得长期维护，哪些能够交给第二团队，哪些应留在原项目，哪些应该停止。

本章继续使用“澄川工业客户跟进助手”教学案例。团队、时间、复用结果与评审决定均为教学材料，不代表真实企业结果或行业产品化标准。

先决定它应该成为什么 ​

试点结束后的默认反应常常是“做成产品”。但这个词太笼统，背后其实是几种投入差很多的选项。

一次性脚本就是解决一次明确问题，执行者留个说明就完了。团队产品要服务一组持续用户，需要入口、状态、权限、反馈、支持和版本管理。共享组件给多个项目提供稳定接口，但不直接承诺完整业务结果。平台则要长期服务多个团队，兼容、容量、治理、迁移都得管。

还有一个经常被忽略的选项：停止。若任务低频、资料无法维护、净负担长期为负，保留一份复盘和退役记录，比给一个无人使用的系统续命更有价值。

澄川的证据只支持窄范围团队产品。现有商机、客户关联明确、资料覆盖充分的标准跟进会议，已有两名销售重复使用；渠道、续约和新线索尚未成立。第二团队提出类似需求，只能算共性信号，不能直接支持平台决定。

产品化意味着持续投入。CRM 变了要改，资料过期要更新，模型版本升级要测，用户反馈要回，故障要修，权限要复审，成本要盯——这些都得有人长期做。如果项目只能靠原作者临时救火，试点过了也不代表组织接得住。

产品化判断要算未来责任 ​

项目组从五个问题判断是否继续。第一，任务是否稳定重复；第二，用户是否愿意在真实流程中使用；第三，数据和权限能否持续获得；第四，质量、风险与支持成本是否可管理；第五，是否有人承诺维护和停止。

澄川的窄场景通过前三项的初步检查。CRM 入口固定，四个字段有负责人，批准资料已经拥有版本规则，两名用户能够独立完成任务。但支持记录显示，客户关联和资料例外仍会消耗工程与内容人员时间。

团队因此没有承诺全时段服务，也没有开放更多字段。产品初期只在原销售组运行，工作时段有人支持；超出资料范围的任务退回人工流程。产品负责人每月查看使用、实质修改、阻塞、支持和风险记录。

长期投入还要比较替代方案。如果一个表单改动就能解决负责人缺失的问题，就没必要把它塞进 AI 产品；某类会议每季度才发生一次，保留人工流程可能更划算。有些能力还给普通软件或人工处理，是正常判断，不算产品化失败。

这个判断不同于第 9 章的试点决定。上一章回答的是当前证据支持怎样继续；本章还要决定由谁长期承担、如何复用和何时退役。

产品交付包要让服务能够被经营 ​

共享目录最初按文件类型组织：提示词、代码、流程图、评估表、会议记录。第二团队知道里面有什么，却不知道怎样完成一项任务。项目组改成围绕运行责任组织交付。

产品概要先限定用户、任务、允许字段和禁止范围。使用说明从会议结束写到 CRM 最终状态，保留正常、阻塞和未知状态的处理。系统说明串联上下文来源、CRMChangeSet、工具、权限和轨迹，不再单独展示一张架构图。

运行手册回答谁值守、怎样判断故障、怎样降为只读、怎样核对未知写入、怎样恢复和通知。用户支持说明入口、响应范围与升级角色。发布记录保存工作流、模型别名、资料、适配器与评估版本。

每个长期责任都指定一个人，而不是写“项目组”。业务产品负责人决定范围和优先级；技术负责人维护工作流与适配器；内容负责人维护批准资料；评估负责人维护高风险和回归样本；CRM 管理员管理身份与字段。

GOV.UK Service Standard 关于多学科团队的要求强调服务需要由能够持续建设和运营的多专业团队负责，并让参与决定的人承担责任。AI 服务还需要理解模型及其影响的专业能力。澄川借用的是持续运营与责任组合原则，不是政府服务的组织模板。

可复用部分与本地部分要分开 ​

第一次复制失败，因为所有内容都混成了“澄川配置”。项目组重新审视资产，把稳定机制与场景语义分开。

稳定核心包括变更单对象、审批状态、未知写入协调、幂等约束、轨迹字段、权限检查和评估运行方式。它们可以进入共享组件，但仍需版本和测试。

本地适配包括会议类型、CRM 字段语义、角色映射、批准资料目录、风险定义和支持流程。第二团队必须重新确认这些内容，不能继承原团队的答案。

text
共享核心
  对象与状态 + 工具安全约束 + 轨迹 + 评估运行器

本地适配
  任务定义 + 字段语义 + 来源目录 + 角色权限 + 支持与升级

两层之间使用明确接口。共享核心只接受经过本地配置声明的字段和来源；本地配置不能关闭审批、修改未知状态语义或扩大环境权限。若第二团队确实需要新动作，应当走新的风险与产品决定。

这种拆分也避免“为了复用把一切做成配置”。有些行为属于不能改变的不变量，例如禁止用新幂等键掩盖未知写入；把它暴露为开关，只会让错误更容易发生。

组织资产不是项目文件的副本 ​

每项资产都需要回答使用问题。它适合什么任务，不适合什么任务；需要哪些输入、权限和依赖；输出和失败是什么；由谁维护；当前版本通过了哪些评估；什么变化会触发复审或退役。

澄川把首批资产整理为场景说明、上下文地图模板、业务对象约定、字段受限写入适配器、未知状态测试、评估集、事件卡和试点复盘。项目中的完整会议内容没有进入通用资产，只有脱敏或合成样本可供复用。

资产还要保留失败。T-018 状态查询再次超时导致重复任务，不能只留最终修复代码；复用团队需要知道故障条件、发现信号、影响、修复和回归任务。否则他们只继承结果，没有继承判断。

版本升级必须写影响范围。资料目录变化只需要重跑相关上下文样本，状态机或权限变化则需要完整高风险回归。使用方能据此判断升级成本，而不是看到“最新版”就覆盖本地配置。

知识库中的一篇文档很容易过期。把检查嵌入工作过程更可靠：新项目启动时必须填写适用性与依赖，发布时自动调用回归集，事件关闭前要增加测试或说明为什么无需增加。

第二团队复用要限制原作者帮助 ​

若原作者全程陪同，第二团队即使成功，也无法区分资产贡献和专家服务。澄川重新设计复用测试：华南团队只获得公开给内部使用的资产包和一个沙盒账号，先独立判断是否适用、准备配置、运行评估和解释失败。

第一次正式记录中，他们在三个小时内遇到五个未说明依赖，原作者随后介入 160 分钟。八条本地评估任务有三条因字段语义错误失败。项目组判定这次复用检查不通过，没有以“最终跑通”覆盖过程。

资产版本 0.6 随后增加适用性问卷、依赖清单、本地字段示例、禁止覆盖的不变量、最小测试数据和故障说明。批准资料不再引用原团队目录，而是要求使用方登记自己的来源与负责人。

第二次运行由一名未参与项目的渠道运营独立执行。她完成沙盒配置并跑完八条任务，原作者只在一次权限问题上提供了 50 分钟帮助。六条共享机制任务通过，两条渠道政策样本因缺少批准来源而正确阻塞。

这次结果证明共享核心可以被第二团队安装、运行和解释，也证明渠道业务场景尚未准备好。项目组分别记录“技术资产复用通过”和“场景价值待验证”，没有用一个复用成功的标签代替两种结论。

支持时间从 160 分钟降到 50 分钟是一个教学信号，样本只有两次，不能据此预测规模化成本。下一团队仍需记录适配工作和原作者介入，组织才会知道复用是否真的在变便宜。

失败复盘要产生有主人的改动 ​

第 4 章闪回过一次重复写入事故。后来团队发现，后续版本为了改善等待体验，绕过了第 7 章已经建立的未知状态不变量。事故不能被写成“开发者忘记复用旧逻辑”。

复盘要还原当时的触发、影响、检测、遏制和恢复，解释为什么评审与发布流程允许这个改动进入。行动项分别指向服务端状态检查、回归任务、发布条件和界面设计，每项拥有负责人、优先级和可验证终点。

Google SRE 关于无责复盘的章节强调以事实和系统条件解释事故，并给后续行动指定负责人和可验证结果。无责不等于无人负责；它避免把问题缩成个人过错，让组织修正允许错误发生的系统。

复盘还要被其他团队找到。华南团队在适配时直接看到重复写入反模式和测试，才知道不能把 unknown 当成普通失败。事故由此从原团队的痛苦变成第二团队的预防信息。

维护和退役是同一项设计 ​

长期资产会随模型、资料、权限和业务变化折旧。所有者需要定期检查使用、质量、成本与风险，也要在关键变化发生时触发复审。

澄川规定几类触发事件：CRM 字段或权限变化、批准资料负责人缺失、模型或工作流版本变化、高风险回归失败、用户长期不再使用、支持成本超过团队承诺。触发后可以修复、缩小、降为只读、暂停或退役。

退役不是删除入口。团队先通知用户和负责人，停止新任务，撤销工具身份，处理未完成与未知状态，按保留要求归档必要审计记录，删除不再需要的数据，再把用户迁回人工流程或替代服务。

NIST AI RMF Core把持续监控、角色责任和安全退役都放在治理结果中。做 AI Native Builder，能关停一个不再可靠的系统，与把它建起来同样重要。

没有退役条件的资产会变成隐性承诺。下一团队看见它还在目录里，可能以为资料、权限和评估仍然有效。状态、版本和维护人必须在入口可见。

哪些内容值得长期维护和复用 ​

团队需要根据当前证据选择长期形态，也要检查作品集和贡献是否足以被复查。这是一次项目决定，不是外部产品认证。

澄川团队把决定分成三部分。原销售组的窄场景进入团队内部产品阶段，继续保留四字段、人工确认和工作时段支持。共享核心、评估集和反模式进入受控资产库，由明确角色维护。

华南渠道场景仍停留在影子验证。两条政策任务正确阻塞，说明系统守住了边界，也说明该场景尚不能产生完整结果。缺少批准来源之前，不增加工具权限。

平台化延期。现在只有一个第二团队测试，业务语义差异明显，长期维护成本也未得到稳定证据。团队把平台化记录为一个候选问题，但不先建设一个“通用销售 AI 平台”。

这个决定保留了已经验证的共性，也拒绝把局部成功无限放大。判断组织能力有没有建立起来，不看资产堆了多少，而看下一个团队能不能在不怎么依赖原作者的情况下，自己判断适用性、完成构建、做完评估、该停就停。

几种会制造“伪复用”的做法 ​

把文件往共享盘一传，只是解决了存放问题。没有适用条件、依赖关系、版本、负责人和失败案例，第二团队拿到手还是得从头摸。

让原作者全程帮忙迁移，等于把专家服务当成了资产能力。复用测试要限制原作者的帮助，把介入时间和原因记下来。

平台化做得太早也有问题：错误的抽象还没稳定就被冻住了。一个团队有需求是一个项目，多个团队独立出现同样的机制才是更强的共性信号，而且还得比较泛化和维护的成本。

只存成功案例，下一个团队就会重复踩坑。失败在什么条件下发生、怎么检测到、怎么修、回归怎么测，这些都得进资产。

资产没有“退役”状态也很危险。过期资料比没资料还误导人，因为使用者会以为这是组织批准的答案。

把方法迁移到合同初审组件 ​

法务团队把合同初审流程交给采购团队复用时，合同解析、证据引用、状态和轨迹可能属于共享核心；模板、风险等级、审批角色和条款库则是本地语义。

采购团队能够安装解析组件，不代表它能沿用法务的风险结论。第二团队测试应先验证依赖与权限，再用自己的批准政策建立评估。缺少采购条款负责人时，系统正确停止，也是一项有价值的复用结果。

若多个团队后来都需要相同的条款差异对象、引用方式和审批状态，组织可以考虑共享组件。只有当接口、维护与支持成本变得稳定，才讨论平台服务。

你的练习 ​

从第 9 章的试点决定开始，为项目选择一次性交付、团队产品、共享组件、平台候选或退役。写下支持这个选择的使用、成本、风险、维护与复用证据，以及尚未满足的条件。

选择三项最有价值的资产，为每项补上适用与不适用、输入输出、依赖权限、版本、负责人、评估和退役条件。把案例专有配置与不允许改变的系统约束分开。

邀请一名未参与项目的人进行复用测试。限制原作者帮助，记录独立完成部分、卡点、失败、介入时间、适配改动和最终环境状态。正确阻塞与完整运行要分别解释。

用这次结果决定哪些内容继续维护、复用或退役。你可以使用练习册中的产品责任与资产登记记录资产和第二团队复用。

怎样判断答案是否合格 ​

先拿走原作者。使用者能否判断资产是否适合，能否找到依赖、权限、示例、失败和支持入口？不能时，文件还没有变成可复用资产。

再改变一个本地条件，例如字段语义、资料目录或审批角色。共享核心能否保持不变量，本地适配又能否被明确替换？全部写死和全部配置化都需要返工。

检查长期责任。模型或政策变化时谁触发回归，故障由谁响应，多久无使用要复审，退役怎样撤权和处理数据？没有名字与触发条件的维护计划无法执行。

合格作业允许得出“不产品化”或“平台化延期”。判断质量来自证据和边界，不来自项目最终做得多大。

本章小结：复用的是判断和控制，不只是结果 ​

澄川第一次把项目文件交给华南团队，复制成功却运行失败。重组共享核心和本地语义、补足依赖与反模式后，第二团队能够独立运行共享技术部分，也能让缺少依据的渠道任务正确停止。

团队只同意继续维护原团队的窄场景产品和一组受控资产；渠道场景继续影子验证，平台化延期。下一章将把全书各阶段的证据放进一次作品集评审，讨论学习者怎样准确说明自己完成了什么、依赖了谁，以及还不能声称什么。

下一章：毕业项目与自我认证

本章来源与框架边界 ​

产品层级、复用测试、长期去向选项和澄川的支持时间是本书为教学案例设计的方法，不代表上述机构提供的产品化阈值。真实组织要结合用途、责任、成本、监管和服务能力决定产品、平台、资产与退役方式。