面向前沿部署工程師
像最強的 FDE 團隊那樣交付，並交出他們從不交出的東西：本體。
前沿部署模式已經勝出：嵌入客戶現場、建模業務、快速交付能用的軟體。它的弱點在交接——本體被鎖在客戶要永遠租用的平臺裡。ObjectStack 把本體變成客戶倉庫裡的型別化開放檔案；ObjectOS 讓它受治理地執行，在雲端或客戶自己的環境。
- 16k token
- 一個完整 CRM——小到客戶能整體審完
- 本體優先
- 先建模名詞與動詞，再談任何介面
- 客戶所有
- 定義放在客戶倉庫裡，Apache-2.0
交付物
交接才是產品：一份放在客戶倉庫裡的本體
前沿部署專案終會結束。留下什麼決定它值多少：型別化的物件、許可權和流程，客戶自己的團隊——以及他們的 AI 智慧體——不依賴你也能讀懂、執行、持續修改。
client-repo/
├── objectstack.config.ts # 應用清單
├── src/objects/ # 客戶的名詞——型別化、可校驗
├── src/flows/ # 客戶的動詞——審批與自動化
├── src/permissions/ # 誰能看到什麼、做什麼
└── dist/objectstack.json # 一個製品，任何 ObjectStack 執行時可執行打法
本體優先——被驗證有效的那套方法
有效的 FDE 方法在任何 AI 應用交付之前先構建業務本體——通用模型給通用答案，價值在客戶自己的名詞和動詞裡。
1. 發現
嵌入業務現場，捕捉真正支撐業務運轉的物件、關係、許可權與審批路徑。
2. 建模
用你的編碼智慧體把發現變成型別化後設資料——物件、流程、許可權,緊湊且經校驗的定義。
3. 交付
執行時從定義派生資料庫、REST API、管理 Console 和 MCP 工具。當週即可在真實流程上演示。
4. 治理與離場
許可權、審批、審計由執行時強制執行——你撤場之後，系統仍在治理邊界內。
為什麼開放
客戶留下本體，你留下客戶。
開放的定義改變了前沿部署業務的經濟學：整個專案不依賴轉售任何平臺席位。
沒有席位要賣
框架是 Apache-2.0。你的報價是工程能力,而不是客戶日後會怨恨的 license 加價。
安全評審直接讀 diff
許可權與審計就是後設資料。客戶安全團隊審的是 2000 行可讀定義,不是一個黑盒平臺邊界。
任何 AI,都在治理內
應用天生就是 MCP 伺服器——客戶的 Claude、Cursor 或本地模型在使用者許可權內操作它。
模式可複利
每個專案都沉澱可複用的型別化模式——物件、流程、許可權集——你的智慧體帶著它們服務下一個客戶。
決策面
改什麼、誰來審、跑什麼
| 專案關注點 | 封閉平臺(如 Foundry) | ObjectStack / ObjectOS |
|---|---|---|
| 本體在哪裡 | 鎖在供應商平臺內 | 客戶倉庫裡的型別化檔案(Apache-2.0) |
| 客戶為什麼付費 | 平臺席位,無限期 | 運營服務(ObjectOS)——或零 license 自託管 |
| 之後誰來維護 | 供應商培訓的專家 | 任意編碼智慧體 + 人工評審 |
| AI 接入 | 僅平臺自帶助手 | 開放 MCP——Claude、Cursor、本地模型 |
| 安全評審 | 信任平臺邊界 | 直接讀 diff——許可權與審計就是後設資料 |
評審清單
FDE 專案檢查清單
- 先把客戶的名詞和動詞建模成物件與流程,再談任何介面。
- 讓整個定義保持上下文體量,智慧體才能整體推理、整體重構。
- 許可權預設從嚴;每一次許可權變更都要在 diff 裡顯式可見。
- 交接的是倉庫、編譯製品和評審清單——不是你租戶裡的一個賬號。
- 保持 MCP 開啟,讓客戶自己的 AI 在其許可權內操作應用。
FAQ
這一頁應該回答的問題
這是 Palantir Foundry 的替代品嗎?
就"本體優先的應用工作流"——為業務建模並在其上交付受治理應用——而言,重疊是真實的,而且這裡的定義層是開放的而非專有的。Foundry 在超大規模資料聯邦與分析管道上仍更強;很多客戶需要的只是應用層。
服務客戶必須用 ObjectOS 嗎?
不必須。開源 ObjectStack 執行時可零 license 自託管,Console 與治理齊全。ObjectOS 是面向希望"平臺被託管運營"的客戶的商業產品——瀏覽器內 AI Builder、雲端或企業版部署與支援。
下一步