關於星盒AI
星盒AI：
專注企業增長。
星盒AI（Starbox AI，簡稱星盒 / Starbox）是一家 AI 原生營銷服務公司，2021 年創立，運營主體為杭州星盒人工智能科技有限公司。我們以企業知識工程為核心，為企業搭建專屬知識庫、定製營銷智能體，並派工程師駐場，把 AI 用進企業的營銷和經營。
概要
星盒不是隻賣工具的軟件公司，也不是用了 AI 的傳統服務公司。星盒把 15 年企業營銷服務方法論、自研 AI 平台和駐場交付放在同一套體系裏：先把企業的產品、客戶、口徑和方法整理成可檢索、可追溯、可授權的知識資產，再交給 AI 執行。
我們在做的事
把業務經驗結構化，再交給 AI 執行。
數據來源：星盒《商務白皮書 V3》《技術白皮書 V3》（2026 年 9 月），星盒內部統計。
三條業務線
企業 AI 化的三個入口，共用同一個內核。
品牌 AI 搜尋優化
用戶不再搜關鍵詞，而是直接問 AI。星盒 GEO 讓豆包、DeepSeek、ChatGPT 等 AI 回答相關問題時提到、引用、推薦你的品牌，國內和海外雙軌。
瞭解星盒 GEO → AGENT02 · 對內提效企業智能體
為企業搭建專屬知識庫和 300+ 實戰智能體，內容、設計、銷售、辦公都能調用。把散在個人身上的經驗，變成企業可以反覆調用的能力。
瞭解星盒內容工廠 → FDE03 · 組織改造企業 AI 化改造
前置部署工程師駐場，先梳理業務流程，再逐個部門把 AI 用進去。輕量形態「星盒星盒！」把企業知識庫和協同裝進員工的微信。
瞭解 FDE 顧問服務 →發展歷程
從營銷服務，到 AI 原生。
由創始人王朋友創立，從企業營銷服務和營銷人才培養起步，積累了 500 多家企業的營銷服務經驗。
用一年半時間系統測試 AI 落地路徑，標準是比專業操盤手寫得更好；2024 年 9 月，深度思考模型第一次達到這個標準，星盒全面投入 AI。
先在真實項目裏驗證「1 人 + AI」的產能，再對外推出，發展為包含組織空間、專屬知識庫和 300+ 智能體的企業智能體平台。
推出星盒 GEO（國內與海外）、星盒內容工廠、「星盒星盒！」和 FDE 顧問服務；城市節點覆蓋全國 18 個省級行政區。看節點分佈 →
技術能力
一個內核：企業知識工程。
通用大模型掌握的是公開知識，不認識某一家企業的產品規格、價格底線、客戶進度和表達口徑。企業引入大模型，核心的工程問題不是選哪個模型，而是在模型和業務之間建一層可維護的知識與記憶系統。GEO、智能體平台、FDE 和「星盒星盒！」都建在這一層上。
- 01訪談採集
- 02清洗去重
- 03本體抽取
- 04語義切分
- 05向量化
- 06人工審定
- 07迴歸測試
老闆和核心崗位多輪結構化訪談；收集手冊、報價、話術、合同模板、案例。
→ 原始語料集清洗去重、統一命名和口徑；按營銷本體抽取實體與關係；語義切分、向量化。
→ 知識圖譜 · 向量與全文索引公司 / 客戶 / 員工三層範圍、角色權限、版本鏈、口徑審定、禁用詞清單。
→ 可授權、可追溯的知識資產檢索增強生成、多智能體編排、寫回確認和審計。
→ 有出處的回答、內容和任務一次提問怎麼找到答案
三路召回，融合打分，答不準就拒答。
S = α·Svec + β·Skw + γ·Sbiz業務加權：公司卡 > 客戶卡 > 員工卡；已審定加權；價格、進度按時間衰減
工程設計原則
六條原則，決定系統靠不靠得住。
理解、寫作、推理由大模型提供；事實和口徑由企業知識庫提供。知識不進入模型參數，模型可以升級，知識可以隨時修改、刪除。
事實性輸出必須來自可檢索的證據並附出處；證據不足時明確説「沒有」，不補編。
模型只負責語義判定和打標；計分、聚合、報告由確定性腳本完成，結果可復算、可審計。
租戶級隔離、一企一套部署、檢索層權限過濾，越權內容不進入候選證據。
AI 負責批量執行，人負責審定口徑和把關發佈；寫入公司知識必須經人確認。
基線 → 生產 → 複測 → 回寫。沒有基線的系統無法驗收，沒有回寫的系統無法迭代。
平台架構
五層架構，從界面到數據。
Multi-Tenant SaaS · White-Label UI · RBAC · WebSocket · SSE 流式輸出品牌專屬界面、實時交互Multi-Agent · DAG 工作流引擎 · Agent Routing · Tool Use / Function Calling · Prompt Chain · 異步任務隊列複雜任務拆解與協作RAG Pipeline · Hybrid Search · Multi-Index · Semantic Chunking · Metadata Filtering · Reranking · Query Rewriting懂行業、懂企業Multi-Model Router · LLM Gateway · Token 優化 · 多模態 · Prompt Template Engine · Style Transfer按任務路由合適的模型向量數據庫 · 對象存儲 · 關係型數據庫 · 租戶隔離 · 加密存儲 · 日誌審計 · 自動擴縮容持久化、隔離、彈性關鍵技術
八項關鍵技術，點開看細節。
向量、全文、結構化三路召回
向量檢索把文本映射成高維向量，「客戶嫌貴怎麼辦」和「報價被壓價時的應對口徑」字面幾乎不重合，向量距離卻很近，因此能被找到；全文檢索（中文分詞 + BM25）負責客戶名、合同號、金額、日期這類精確資訊；結構化條件按項目、客戶、狀態、時間和權限強制過濾。三路結果融合打分，再由重排序模型逐條精排、去重合並。
sim(q, d) = q·d / (‖q‖·‖d‖)- 向量與業務數據放在同一個 PostgreSQL 實例，一條查詢同時施加權限和業務條件
- HNSW 近似最近鄰索引，數十萬到百萬級片段毫秒級查找
- 舊報價和新報價同時被召回時，優先採用最新的已審定版本
- 最高分低於拒答閾值 τ 時，寧可説「沒有」
離線建索引，在線改寫、過濾、壓縮
不是「向量檢索後拼進提示詞」，而是一條完整管線：離線時按語義邊界切分並保留重疊，不同類型的知識建不同的索引；在線時先改寫問題，用 HyDE 假設文檔擴展語義提高召回，再按知識類型、品牌、時間、權限過濾，重排序後把冗長結果壓縮成關鍵資訊，控制上下文長度和 Token 成本。
- Semantic Chunking + Overlap
- Multi-Index：按知識類型分索引
- Query Rewriting + HyDE
- Metadata Filtering · Reranking · Knowledge Distillation
DAG 工作流，多個智能體按流程協作
平台上的智能體不是各自獨立的單點，而是由有向無環圖（DAG）工作流引擎編排的協作系統。一個請求可以觸發多個智能體串行或並行執行，每個節點完成子任務後把中間結果交給下游；多模型路由按任務類型選用合適的模型，長任務進入異步隊列。
- Agent Routing：按意圖路由到對應智能體
- Prompt Chaining：中間結果鏈式傳遞
- Tool Use / Function Calling：調用檢索、聯網、生圖等工具
- 條件分支 · 循環控制 · 異步任務隊列
種子庫 + 組合採樣 + 語義去重
AI 規模化生產內容最大的隱患是同質化。平台用經過合理性認證的情景種子作為內容起點，再組合受眾、場景、情緒基調、切入角度和內容框架，每個創作維度可以組合出百萬級不同方向；入庫前做語義相似度去重。IP 的説話方式被提取成可執行的風格參數，風格和內容解耦，人員流動不影響品牌調性。
seed → audience × scene × tone × angle × frame- 情景種子：痛點、賣點、感官細節、兼容受眾與場景
- Style Transfer：用詞、句式、節奏、口頭禪參數化
- 選題 12 + N 維度，按未使用 / 已使用 / 已發佈追蹤
- 21 種情緒 × 16 種共鳴框架，300+ 痛點庫
按審定口徑説話，生成後再校驗
生成前，模型只能基於提供的證據陳述事實，證據沒有覆蓋的數字、日期、承諾不能補充；每條事實標註來源編號，可以回到知識庫後台查看原文；審定過的口徑以原文注入並標記「不可改寫」。生成後逐項校驗，命中即改寫或攔截。
- 禁用詞：命中即改寫或攔截，並提示原因
- 數字底線：讓利上限、報價口徑、交付週期不得超出
- 承諾類表述：「回本」「效果保證」轉為合規表述
- 一致性：與已定稿話術、海報文案衝突時提示對齊
共享大腦不能被寫錯
能讀不難，難的是寫得對——共享知識庫一旦寫錯，錯誤會傳給全公司。系統對寫入設了四道機制：只有叫出喚醒詞才進入讀寫模式；擬寫入內容先作為提案複述給成員，確認後才寫入；已審定記錄不被覆蓋，修改生成新版本；寫入前檢測同範圍、同主題記錄的衝突，公司卡優先。
record.status: superseded → confirmed- 喚醒門控：日常閒聊不被讀取或寫入
- 提案—確認：未確認的提案不會被當作證據
- 版本鏈：舊版本標記「已替代」並保留
- 員工卡個人草稿僅本人可見，不進公司總賬
LLM 判定 + 確定性計分，結果可復算
生成式引擎的答案不是固定的，同一問題多次提問答案會變，所以單題不下結論、聚合才下結論。150 個買家真實會問的問題，在國內 4 個引擎（海外按目標市場）上跑出基線：模型只把答案打成結構化標籤，計分、聚合和報告全部由腳本完成，每題按 run_id 留存答案全文、引用列表和截圖，可以逐題對賬。
s = b × e V ∝ R × T- b ∈ {0, 3, 6, 10}：未提及 / 一筆帶過 / 進入推薦 / 首位推薦
- e ∈ {1.0, 0.8, 0.5, 0}：明確推薦 / 中性 / 謹慎 / 負面
- 四張記分卡：可見度指數 · 五層熱力圖 · 引用源分佈 · 競品 SOV
- 排產優先級 = 問題價值 × (10 − 當前得分)
一企一套，數據和雲資源都歸企業
每家企業獨立部署，數據庫、存儲、伺服器都不共用；預設部署在企業自有賬號下的公有云，也可以部署在自有機房，數據庫不開放公網。知識服務通過 MCP（模型上下文協議）對外提供，基於 OAuth 2.1 逐人授權，訪問密鑰只留在服務端；權限在檢索層強制過濾，越權內容不會出現在回答裏。星盒不使用企業數據訓練任何模型。
- RBAC：管理員 / 員工 / 合夥人 / 加盟商四類角色
- TLS 傳輸加密 · 雲盤、數據庫、對象存儲加密
- 檢索、讀取、寫入、推送全量審計
- 合作終止可導出全部結構化記錄和文件
交付驗收
用指標説話，不用形容詞。
正確證據出現在前 K 條候選中的比例。
正確證據排名倒數的平均值，越接近 1 越好。
回答和審定口徑一致的比例。
知識庫裏確實沒有時，如實回答「沒有」的比例。
知識庫裏有答案卻回答「沒有」的比例。
建庫時和企業一起整理一套真實問題集（價格口徑、政策、項目進度、禁區等），標註標準答案和出處；知識庫大幅變更或參數調整後重跑。參數為星盒標準配置，實際以實施方案為準。來源：星盒《技術白皮書 V3》（2026 年 9 月）。
和其他 AI 服務有什麼不同
AI 不是買回來的工具，是在企業里長出來的能力。
| 對比項 | 工具型 AI 公司 | 傳統服務商 + AI | 星盒 · AI 原生 |
|---|---|---|---|
| 交付什麼 | 賬號和功能 | 人力和文檔 | 可以運行的能力資產 |
| 懂不懂業務 | 不進業務，只給通用能力 | 懂業務，不懂工程 | 先診斷業務，再做 AI 化 |
| 知識留在哪 | 對話結束就消失 | 留在個人身上 | 沉澱為企業知識庫 |
| 怎麼衡量結果 | 看使用量 | 看交付件數量 | 看和基線對比的真實數據 |
| 人員離開之後 | 能力隨賬號停用消失 | 能力隨人流失 | 能力留在組織里 |
名稱説明
一個品牌，四種寫法。
| 用途 | 寫法 |
|---|---|
| 中文全稱 | 星盒AI |
| 中文簡稱 | 星盒 |
| 英文全稱 | Starbox AI |
| 英文簡稱 | Starbox |
| 運營主體 | 杭州星盒人工智能科技有限公司 |
| 口號 | 星盒AI：專注企業增長 |
