01
Schema-as-code
用 TypeScript 定義內容模型，讓欄位結構能進入版本控制、型別檢查與 CI/CD。
campaign.tsSchema
defineType({
name: "campaign",
type: "document",
fields: [
headline,
hero,
markets
]
})
Studio fieldsDraft
Headline
夏季品牌企劃
Hero image
已設定焦點與替代文字
Markets
zh-TW / en
Sanity CMS 顧問與導入
Why Sanity CMS?
當內容需要跨網站、App 與市場反覆使用，Sanity 把內容模型、編輯介面與發布流程放進同一套可客製的工作空間。
Model / Workspace
內容模型在程式碼裡，編輯工作在 Studio 裡。
Workspace anatomy
從 Schema 到發布，一個工作空間把變更串起來。
內容模型 / TypeScript
Schema 已載入
defineType({
name: "campaign",
type: "document",
fields: [
defineField({ name: "headline", type: "string" }),
defineField({ name: "hero", type: "image" }),
defineField({ name: "markets", type: "array" }),
],
})01headline必填字串與字數驗證
02hero圖片、替代文字與裁切焦點
03markets可重複使用的市場清單
Result
同一組欄位定義可進入版本控制，並銜接型別檢查與 CI/CD 流程。
Custom Studio
每個團隊的工作方式不同，Studio 也能跟著調整。
02
自訂輸入元件
用 React 製作適合品牌、資料格式或內部流程的編輯介面。
03
Structure Builder
依角色、內容關係與日常任務重組 Studio 的導覽和工作入口。
04
驗證規則
把必填、格式、關聯與發布前條件寫進內容模型，提早看見問題。
Collaboration
協作不只一起打字，還要看得見決策脈絡。
01
即時協作
多人可以在同一份內容上工作，並看見彼此的變更。
02
留言與任務
把討論和待辦留在內容旁，不必另外拼湊回覆脈絡。
03
版本記錄
保留內容變更的歷史，方便團隊理解修改來源與演進。
04
Content Releases
把一批跨文件變更整理成發布單位，再依權限完成檢視與核准。
Structured reuse
先把內容變成可組合的物件，再送到不同通路。
結構化欄位與 Portable Text 讓文字、媒體和關聯保留語意，不必把整張頁面綁死在單一前端。
01Web / SEO
品牌網站
首頁、服務頁、案例與跨語系內容共享品牌與 SEO 欄位。
02iOS / Android
App 與會員服務
會員訊息、教學、方案說明與介面文案由同一內容來源提供。
03Commerce
電商與產品
商品資料、規格、故事與 Portable Text 內容依通路重新組合。
04Campaign
行銷活動
活動模組、受眾版本與市場素材不必為每個頁面重做一份。
AI governance
AI 可以協助內容工作，但不能跳過治理。
Schema-aware 不代表無人監督。權限、變更檢視與人工核准仍是發布流程的一部分。
Content Agent
以 Schema 和內容脈絡協助處理內容任務，仍受角色與權限邊界約束。
AI Assist
在 Studio 內提供與欄位結構相關的協作能力，結果仍需被檢視。
權限
依角色限制可讀、可改與可發布的範圍，避免把 AI 當成額外後門。
人工核准
重要變更進入既有審核與發布流程，不把產生內容等同於自動上線。
Decision guide
可客製不是每個團隊都需要，先看工作條件。
適合 Sanity
- 01內容需要跨網站、App、電商或不同市場重複使用
- 02內容結構模組化，並有多語系或多品牌需求
- 03編輯、審核與發布需要多人協作和清楚權限
- 04內部或合作團隊有人能長期負責 Schema 與前端整合
先不要選 Sanity
NOT YET- 01只有一個很少更新的小型網站
- 02期待完全現成、不需開發的視覺拖拉式網站產生器
- 03沒有任何開發能量維護內容模型、Studio 與整合
- 04基礎設施政策要求完整自行託管內容平台
Tenten delivery
導入不是裝好後台，而是把內容工作方式做成系統。
01
內容與流程盤點
先看現有內容、使用者、審核責任與發布路徑。
02
內容模型與 Schema
把頁面拆成可重用的內容物件、關係與驗證規則。
03
Studio 客製
依角色建立導覽、自訂輸入元件與編輯預覽。
04
前端、整合與搬遷
串接網站與服務，整理內容轉換、匯入和重導策略。
05
QA、訓練與交接
驗證欄位、權限、發布和前端呈現，再交接文件與日常操作。
FAQ
從既有 CMS 搬遷、日常編輯到 AI 權限，先釐清導入後真正會改變的工作。
Sanity 跟 WordPress 最大的差別是什麼？
WordPress 常把頁面、後台與外掛放在同一套既有系統裡；Sanity 則把結構化內容存放在 Content Lake，並用程式碼定義內容模型與 Studio。前端可以依網站、App 或其他通路各自取用同一份內容。
日常編輯內容也需要找工程師嗎？
不需要每次都找工程師。導入時會由開發團隊定義 Schema、Studio 與驗證規則；完成後，編輯者可在 Studio 內處理既有內容。新增內容類型、改變資料關係或串接新通路時，才通常需要開發協作。
可以從 Webflow 或 WordPress 搬到 Sanity 嗎？
可以，但搬遷不是把 HTML 原封不動複製過去。通常要先盤點欄位與內容關係，建立新的 Schema，再轉換、清理、匯入資料，並處理媒體、網址與重導規則。
Sanity 適合多語系內容嗎？
適合，但多語系模型要依團隊工作方式設計。語言可以放在同一文件的欄位裡，也可以拆成互相關聯的文件；選擇會影響權限、查詢、翻譯流程與發布方式。
AI 會直接幫我們發布內容嗎？
不應把 AI 產生內容等同於自動發布。Content Agent 與 AI Assist 可依 Schema 協助內容工作，但仍應受角色、權限、變更檢視與人工核准流程管理。
什麼情況下你們不建議使用 Sanity？
如果網站規模小、很少更新，只需要現成視覺編輯器，或團隊沒有任何開發能量維護 Schema 與整合，Sanity 的可客製能力可能反而增加負擔。要求完整自行託管平台時，也應先評估其他選項。