# 签百万AI灯塔共建省下60万，公开打法怎么脱敏才不亏？

> 灯塔共建不是交出商业机密换折扣，而是拿抽象架构换核心研发资源。只要把技术架构层、工作流编排层和业务参数层做好三级脱敏，公开打法反而能成为企业自身的技术背书。

来源：https://www.starboxai.cn/insights/ai-adoption/2026-11-02-lighthouse-partnership-ai-procurement/（星盒AI 知识中心，更新于 2026-11-02）

首期 AI 试点跑通后，服务商往往会拿着下一阶段的方案找过来。以常见的标准企业年框 200 万元为例，对方常抛出一个很有吸引力的条件：如果愿意作为行业的标杆案例，签署灯塔共建协议，费用可以直接折让到 140 万元，一口气省下 60 万元。

与此同时，服务商还会承诺配属前沿部署工程师（FDE，即直接驻场进企业写生产级代码、负责端到端交付的工程人员），并给出专属模型调用通道和高并发支持。条件只有一个：企业需要配合对外拆解落地打法，作为行业标杆联合发声。

这时候很多集团的 IT 负责人或 CTO 就会犯嘀咕：省钱确实诱人，但把自家刚摸索出来的打法全盘托出，竞品照抄怎么办？核心数据泄露了谁负责？

很多团队在面对这种合作时容易走两个极端：要么以为做标杆就必须把[提示词](/glossary/prompt/)（Prompt）和转化漏斗全盘公开，吓得不敢接大额折扣；要么为了省钱盲目签约，连自家的专有知识库和业务底牌都被服务商当成公共宣传材料发了出去。

这笔账其实可以算得非常清楚。灯塔共建的核心逻辑，是用对外公开的行业影响力，置换服务商不可替代的稀缺研发资源，同时必须用清晰的物理和法律边界，把核心业务资产牢牢锁在企业内部。

## 灯塔共建省下的60万，真正换到了什么资源？

做标杆不能只看账面省了多少钱，更要看资源置换的净收益。

在这类深度合作中，企业付出的对价是服务商梦寐以求的真实业务场景与品牌背书。MIT Project NANDA 在 2025 年的报告中指出，[生成式 AI](/glossary/aigc/) 在企业端存在巨大的落地鸿沟，高达 95% 的组织未获得可衡量的业务回报，定制试点真正进入生产环境的仅有 5%。因此，一个跑通了真实闭环的标杆客户，对服务商获取下一批客户至关重要。

弄清了对方的诉求，你在谈判桌上换取的就不能只是简单的降价，而是必须锁定三项高价值资源：

第一，核心研发资源的独占。要求服务商派驻具备全栈交付能力的 FDE 团队深度进场，直接在企业的系统架构内写生产级代码，而不是把通用系统扔给企业自己折腾。
第二，模型算力的高并发与独立路由保障。避免企业在业务高峰期与公有云上的中小客户争抢调用额度。
第三，系统功能的共建定制权。把企业未来一年规划中的高阶需求，直接列入服务商底层系统的迭代排期中，由对方团队承担定制研发成本。

算清楚这三笔技术账，省下的 60 万元才是实打实的利润，而不是为服务商做免费嫁衣。

## 对外公开做案例脱敏，必须守住哪三层边界？

很多企业之所以抗拒做标杆，是因为分不清打法公开和商业泄密的界限。打法对外拆解，必须严格遵守三层脱敏原则。

```
【对外公开三级脱敏结构】
├── 架构层（完全公开）    → 技术选型、多智能体协同逻辑、组织分工
├── 编排层（半公开脱敏）  → 工作流拓扑图（隐去特定分支触发阈值与异常逻辑）
└── 业务层（严禁公开）    → 专有知识库、完整提示词、转化率与客单价底牌
```

第一层是架构层，这一层完全可以公开。比如企业如何搭建私有知识库、如何通过三级权限（RBAC）管理员工数据访问、多智能体如何分工协作、内部设立了怎样的 AI 运营官岗位来调度流水线。公开这层内容，竞品看懂了也抄不走，因为他们没有你的底层组织协同和管理制度。相反，这类公开能直接坐实企业在行业内的数字化领头羊地位。

第二层是工作流编排层，这一层需要半公开脱敏。你可以公开从需求输入、内容质检到分发复盘的标准步骤（SOP），甚至可以对外展示系统流水线的运作逻辑图。但在对外拆解时，必须隐去具体的判断阈值、质检过滤词库的精确规则，以及针对异常情况的容错机制。展示逻辑骨架，收起工业细节。

第三层是业务参数与样本层，这一层属于核心资产，严禁任何形式的公开。它包括三样东西：一是企业长期积累的专有知识库原始切片；二是经过反复调试成型的核心[系统提示词](/glossary/system-prompt/)（System Prompt）；三是精准的业务结果数据，如真实的客单价、获客成本、各渠道准确转化率等。这一层必须在协议中列为商业秘密，并设置高额违约条款。

## 集团AI年框采购的四步核验流程

如果你正准备把试点项目升级为集团级年框采购，并以标杆客户形式签约，建议严格按照四步流程完成准入核验：

第一步，输入业务边界。明确本次年框覆盖的业务部门数量、并发调用需求，以及需要对接的内部系统接口列表。
第二步，核算资源对价。要求服务商把合同中的权益逐一拆解。除了基础的系统部署外，明确核验 FDE 驻场工程师的人天数、模型专属通道的调用上限、针对企业需求开发新功能的交付周期。
第三步，划定脱敏宣发清单。在签署共建协议前，把服务商未来对外宣发的公关稿、案例拆解 PPT 模板提前进行合规界定，明确哪些字段属于第三层禁区，必须由企业法务与 IT 安全部门双重签字后方可定稿。
第四步，锁定退出机制与资产沉淀。明确约定如果服务商交付的系统或模型表现不达标，企业享有的降级与退出权利。更关键的是，合同中必须明确：服务商撤场后，系统沉淀的业务知识库、文风模型、工作流配置资产的所有权完全归企业所有，且服务商不得将企业数据用于其底层基础模型的任何训练。

为了方便实操把关，下面这份核算表可以直接用在商务谈判和法务审查环节：

| 评估维度 | 考察项 | 审查标准与动作 | 交付物/条款要求 |
|---|---|---|---|
| 资源收益 | 研发与驻场支持 | 核对服务商派出人员是否为懂业务的交付工程师，拒绝纯销售型支持 | 明确约定 FDE 驻场人天数及每月代码交付成果 |
| 算力保障 | API 路由与稳定性 | 确认企业调用是否走独立通道，避免公网并发限流影响业务 | 写入 SLA 服务等级协议，明确高峰期响应时间与可用性 |
| 数据脱敏 | 案例公开范围界定 | 按照三层脱敏标准，对拟公开的 PPT、PR 稿件进行字段级审查 | 案例发布前必须由企业 IT 负责人书面审核签字盖章 |
| 资产归属 | 知识库与工作流沉淀 | 明确合作过程中产出的提示词模板、清洗后的知识库资产归属 | 合同明确数据不出私有空间，绝不用于公有模型训练 |

## 怎样签灯塔共建协议才不会吃亏？

做标杆是手段，把能力真正留在企业内部才是目的。

很多企业把年框合同一签，以为万事大吉，服务商为了对外做宣传，往往抢着把案例推出去，但内部的实际落地却跟不上。为了避免这种情况，必须在商务框架中设立交付卡点。

建议把年框款项分为首付款、系统验收款和年终运维款。同时明确约定：服务商发布标杆宣发材料的时间节点，必须严格置后于实际业务指标的阶段性验收。只有当企业内部的 AI 运营官能够独立调度整套流水线、产出符合标准的业务结果后，服务商才被允许启动对外宣传。

这样一来，服务商的核心交付团队为了拿到对外宣发的品牌资本，就必须拼尽全力先把企业的实际业务场景跑通、跑透。把服务商的宣发渴望，变成压实交付质量的最好杠杆。