# 籤百萬AI燈塔共建省下60萬，公開打法怎麼脱敏才不虧？

> 燈塔共建不是交出商業機密換折扣，而是拿抽象架構換核心研發資源。只要把技術架構層、工作流編排層和業務參數層做好三級脱敏，公開打法反而能成為企業自身的技術背書。

來源：https://www.starboxai.cn/zh-hant/insights/ai-adoption/2026-11-02-lighthouse-partnership-ai-procurement/（星盒AI 知識中心，更新於 2026-11-02）

首期 AI 試點跑通後，服務商往往會拿着下一階段的方案找過來。以常見的標準企業年框 200 萬元為例，對方常拋出一個很有吸引力的條件：如果願意作為行業的標杆案例，簽署燈塔共建協議，費用可以直接折讓到 140 萬元，一口氣省下 60 萬元。

與此同時，服務商還會承諾配屬前沿部署工程師（FDE，即直接駐場進企業寫生產級代碼、負責端到端交付的工程人員），並給出專屬模型調用通道和高併發支持。條件只有一個：企業需要配合對外拆解落地打法，作為行業標杆聯合發聲。

這時候很多集團的 IT 負責人或 CTO 就會犯嘀咕：省錢確實誘人，但把自家剛摸索出來的打法全盤托出，競品照抄怎麼辦？核心數據泄露了誰負責？

很多團隊在面對這種合作時容易走兩個極端：要麼以為做標杆就必須把[提示詞](/zh-hant/glossary/prompt/)（Prompt）和轉化漏斗全盤公開，嚇得不敢接大額折扣；要麼為了省錢盲目簽約，連自家的專有知識庫和業務底牌都被服務商當成公共宣傳材料發了出去。

這筆賬其實可以算得非常清楚。燈塔共建的核心邏輯，是用對外公開的行業影響力，置換服務商不可替代的稀缺研發資源，同時必須用清晰的物理和法律邊界，把核心業務資產牢牢鎖在企業內部。

## 燈塔共建省下的60萬，真正換到了什麼資源？

做標杆不能只看賬面省了多少錢，更要看資源置換的淨收益。

在這類深度合作中，企業付出的對價是服務商夢寐以求的真實業務場景與品牌背書。MIT Project NANDA 在 2025 年的報告中指出，[生成式 AI](/zh-hant/glossary/aigc/) 在企業端存在巨大的落地鴻溝，高達 95% 的組織未獲得可衡量的業務回報，定製試點真正進入生產環境的僅有 5%。因此，一個跑通了真實閉環的標杆客戶，對服務商獲取下一批客戶至關重要。

弄清了對方的訴求，你在談判桌上換取的就不能只是簡單的降價，而是必須鎖定三項高價值資源：

第一，核心研發資源的獨佔。要求服務商派駐具備全棧交付能力的 FDE 團隊深度進場，直接在企業的系統架構內寫生產級代碼，而不是把通用系統扔給企業自己折騰。
第二，模型算力的高併發與獨立路由保障。避免企業在業務高峯期與公有云上的中小客戶爭搶調用額度。
第三，系統功能的共建定製權。把企業未來一年規劃中的高階需求，直接列入服務商底層系統的迭代排期中，由對方團隊承擔定製研發成本。

算清楚這三筆技術賬，省下的 60 萬元才是實打實的利潤，而不是為服務商做免費嫁衣。

## 對外公開做案例脱敏，必須守住哪三層邊界？

很多企業之所以抗拒做標杆，是因為分不清打法公開和商業泄密的界限。打法對外拆解，必須嚴格遵守三層脱敏原則。

```
【對外公開三級脱敏結構】
├── 架構層（完全公開）    → 技術選型、多智能體協同邏輯、組織分工
├── 編排層（半公開脱敏）  → 工作流拓撲圖（隱去特定分支觸發閾值與異常邏輯）
└── 業務層（嚴禁公開）    → 專有知識庫、完整提示詞、轉化率與客單價底牌
```

第一層是架構層，這一層完全可以公開。比如企業如何搭建私有知識庫、如何通過三級權限（RBAC）管理員工數據訪問、多智能體如何分工協作、內部設立了怎樣的 AI 運營官崗位來調度流水線。公開這層內容，競品看懂了也抄不走，因為他們沒有你的底層組織協同和管理制度。相反，這類公開能直接坐實企業在行業內的數字化領頭羊地位。

第二層是工作流編排層，這一層需要半公開脱敏。你可以公開從需求輸入、內容質檢到分發復盤的標準步驟（SOP），甚至可以對外展示系統流水線的運作邏輯圖。但在對外拆解時，必須隱去具體的判斷閾值、質檢過濾詞庫的精確規則，以及針對異常情況的容錯機制。展示邏輯骨架，收起工業細節。

第三層是業務參數與樣本層，這一層屬於核心資產，嚴禁任何形式的公開。它包括三樣東西：一是企業長期積累的專有知識庫原始切片；二是經過反覆調試成型的核心[系統提示詞](/zh-hant/glossary/system-prompt/)（System Prompt）；三是精準的業務結果數據，如真實的客單價、獲客成本、各渠道準確轉化率等。這一層必須在協議中列為商業秘密，並設置高額違約條款。

## 集團AI年框採購的四步核驗流程

如果你正準備把試點項目升級為集團級年框採購，並以標杆客戶形式簽約，建議嚴格按照四步流程完成准入核驗：

第一步，輸入業務邊界。明確本次年框覆蓋的業務部門數量、併發調用需求，以及需要對接的內部系統接口列表。
第二步，核算資源對價。要求服務商把合同中的權益逐一拆解。除了基礎的系統部署外，明確核驗 FDE 駐場工程師的人天數、模型專屬通道的調用上限、針對企業需求開發新功能的交付週期。
第三步，劃定脱敏宣發清單。在簽署共建協議前，把服務商未來對外宣發的公關稿、案例拆解 PPT 模板提前進行合規界定，明確哪些字段屬於第三層禁區，必須由企業法務與 IT 安全部門雙重簽字後方可定稿。
第四步，鎖定退出機制與資產沉澱。明確約定如果服務商交付的系統或模型表現不達標，企業享有的降級與退出權利。更關鍵的是，合同中必須明確：服務商撤場後，系統沉澱的業務知識庫、文風模型、工作流配置資產的所有權完全歸企業所有，且服務商不得將企業數據用於其底層基礎模型的任何訓練。

為了方便實操把關，下面這份核算表可以直接用在商務談判和法務審查環節：

| 評估維度 | 考察項 | 審查標準與動作 | 交付物/條款要求 |
|---|---|---|---|
| 資源收益 | 研發與駐場支持 | 核對服務商派出人員是否為懂業務的交付工程師，拒絕純銷售型支持 | 明確約定 FDE 駐場人天數及每月代碼交付成果 |
| 算力保障 | API 路由與穩定性 | 確認企業調用是否走獨立通道，避免公網併發限流影響業務 | 寫入 SLA 服務等級協議，明確高峯期響應時間與可用性 |
| 數據脱敏 | 案例公開範圍界定 | 按照三層脱敏標準，對擬公開的 PPT、PR 稿件進行字段級審查 | 案例發佈前必須由企業 IT 負責人書面審核簽字蓋章 |
| 資產歸屬 | 知識庫與工作流沉澱 | 明確合作過程中產出的提示詞模板、清洗後的知識庫資產歸屬 | 合同明確數據不出私有空間，絕不用於公有模型訓練 |

## 怎樣籤燈塔共建協議才不會吃虧？

做標杆是手段，把能力真正留在企業內部才是目的。

很多企業把年框合同一簽，以為萬事大吉，服務商為了對外做宣傳，往往搶着把案例推出去，但內部的實際落地卻跟不上。為了避免這種情況，必須在商務框架中設立交付卡點。

建議把年框款項分為首付款、系統驗收款和年終運維款。同時明確約定：服務商發佈標杆宣發材料的時間節點，必須嚴格置後於實際業務指標的階段性驗收。只有當企業內部的 AI 運營官能夠獨立調度整套流水線、產出符合標準的業務結果後，服務商才被允許啓動對外宣傳。

這樣一來，服務商的核心交付團隊為了拿到對外宣發的品牌資本，就必須拼盡全力先把企業的實際業務場景跑通、跑透。把服務商的宣發渴望，變成壓實交付質量的最好槓桿。