objectstack-ai · hotlong · Sep 3, 2026 · Sep 3, 2026
diff --git a/content/blog/ai-wrote-your-app-dare-to-merge/index.zh-Hant.mdx b/content/blog/ai-wrote-your-app-dare-to-merge/index.zh-Hant.mdx
@@ -31,7 +31,7 @@ tags: []
 
 被推到前臺的，是另一件一直都在、但以前被寫程式碼的成本掩蓋的事：**有人得為這段程式碼負責。** 得有人能回答"它讀了哪些資料、能做哪些動作、出錯算誰的、審計查得到嗎"。在 AI 把"寫"的成本砍到零之後，"審與治"就成了整個流程裡最貴、也最關鍵的一段。**可審查性，是 AI 寫程式碼時代的新護城河**——不是誰生成得多，而是誰生成的東西敢上線。
 
-這正是 [Vibe Coding 技術債](/zh-Hans/blog/vibe-coding-technical-debt-2026/) 和 [AI Agent 試點失敗的四層原因](/zh-Hans/blog/why-ai-agent-pilots-fail-four-layers/) 兩篇講過的同一件事的另一面：vibe coding 讓人人都能生成應用，但生成完沒人敢上線——因為沒人能審、沒人能擔保。區別只在於，那兩篇是從企業和決策者視角看，這篇是從你——那個手指懸在 Merge 按鈕上的人——的視角看。
+這正是 [Vibe Coding 技術債](/zh-Hant/blog/vibe-coding-technical-debt-2026/) 和 [AI Agent 試點失敗的四層原因](/zh-Hant/blog/why-ai-agent-pilots-fail-four-layers/) 兩篇講過的同一件事的另一面：vibe coding 讓人人都能生成應用，但生成完沒人敢上線——因為沒人能審、沒人能擔保。區別只在於，那兩篇是從企業和決策者視角看，這篇是從你——那個手指懸在 Merge 按鈕上的人——的視角看。
 
 ## "讓另一個 AI 去審"為什麼閉不了環
 
@@ -45,7 +45,7 @@ tags: []
 
 ## 出路：把 AI 要交給你的東西，縮小到你審得動
 
-你審不動八千行，和這套系統半年後會爛掉，是**同一個原因**——沒人真正理解那一坨實現（這就是[那篇](/zh-Hans/blog/vibe-coding-technical-debt-2026/)講的"理解債"）。
+你審不動八千行，和這套系統半年後會爛掉，是**同一個原因**——沒人真正理解那一坨實現（這就是[那篇](/zh-Hant/blog/vibe-coding-technical-debt-2026/)講的"理解債"）。
 
 那就換掉 AI 交付的**形態**：不讓它生成實現，讓它生成**宣告**。同一個退款應用，AI 該交給你的不是八千行程式碼，而是這樣一份後設資料 diff：
 

diff --git a/content/blog/automation-cross-system-flows/index.zh-Hant.mdx b/content/blog/automation-cross-system-flows/index.zh-Hant.mdx
@@ -50,7 +50,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 在 ObjectStack 裡，Webhook 是出站的。你為某個物件宣告一條訂閱，當記錄被建立、更新或刪除時，平臺把這條變化推送到你指定的外部地址；你可以配置一個共享金鑰，平臺會用它對請求體簽名。批次更新和批次刪除是兩類單獨的訂閱事件，因為它們送出的內容本來就不一樣——沒有具體記錄，只有物件和命中條數。總之，Webhook 是平臺告訴外部系統“這裡發生了什麼”的方式，不是外部系統告訴平臺的方式。
 
-外部系統要把事件送進平臺，用的是另一套機制：把流程宣告成 api 型別，引擎會為它掛出一條專屬的入站地址，路徑形如 /api/v1/automation/hooks/流程名/鉤子標識。這條地址只做兩件事——校驗簽名、放進佇列，然後回一個“已接收”；它從不在這次請求裡把流程跑完。金鑰按流程配置，鉤子標識可以輪換，等於在不改流程名的前提下作廢舊地址。入口模型本身，[觸發模型那篇](/zh-Hans/blog/automation-trigger-model/)單獨講過。
+外部系統要把事件送進平臺，用的是另一套機制：把流程宣告成 api 型別，引擎會為它掛出一條專屬的入站地址，路徑形如 /api/v1/automation/hooks/流程名/鉤子標識。這條地址只做兩件事——校驗簽名、放進佇列，然後回一個“已接收”；它從不在這次請求裡把流程跑完。金鑰按流程配置，鉤子標識可以輪換，等於在不改流程名的前提下作廢舊地址。入口模型本身，[觸發模型那篇](/zh-Hant/blog/automation-trigger-model/)單獨講過。
 
 方向之所以值錢，是因為兩個方向交給你的問題幾乎相反。
 

diff --git a/content/blog/enterprise-ontology-race-open-vs-closed/index.zh-Hant.mdx b/content/blog/enterprise-ontology-race-open-vs-closed/index.zh-Hant.mdx
@@ -172,7 +172,7 @@ os start   # 同一份定義，跑在你自己的基礎設施上
 
 現在再問那個要命的問題："H 集團明年續約風險多高？"agent 面對的是**一個**統一的、帶許可權和審計的"客戶"：訂單健康，但疊著兩次高管級投訴和一筆 90 天回款爭議——它會答"高風險，建議提前介入"。同一個模型、同一個問題，只因為腳下的定義不再分裂，結論從"丟了幾百萬"變成了"提前一個季度預警"。
 
-MCP 那一點在這裡同樣成立，而且方向恰好是對的：同一份定義，正是執行時作為受治理工具交給 agent 的那一份——讀取通道是開放的，**同時**定義是你的。這正是[為什麼定義與執行時都該開放](/zh-Hans/blog/ai-ontology-open-protocol/)完整論證的那件事。
+MCP 那一點在這裡同樣成立，而且方向恰好是對的：同一份定義，正是執行時作為受治理工具交給 agent 的那一份——讀取通道是開放的，**同時**定義是你的。這正是[為什麼定義與執行時都該開放](/zh-Hant/blog/ai-ontology-open-protocol/)完整論證的那件事。
 
 這就是 ObjectStack 與 ObjectOS 的分工，也是它對這場競賽的回答：
 

diff --git a/content/blog/give-your-agent-rules-for-governable-apps/index.zh-Hant.mdx b/content/blog/give-your-agent-rules-for-governable-apps/index.zh-Hant.mdx
@@ -31,7 +31,7 @@ tags:
 
 ## 把"可治理性"寫進規則，而不是事後補
 
-事後補治理，是當下最常見、也最貴的錯法：先讓 agent 生成，再回頭審許可權、補審計、加審批——也就是 [AI Agent 試點進不了生產那篇](/zh-Hans/blog/why-ai-agent-pilots-fail-four-layers/)裡說的治理返工。每生成一個應用就返工一次，規模化之後這筆賬會越來越難付。
+事後補治理，是當下最常見、也最貴的錯法：先讓 agent 生成，再回頭審許可權、補審計、加審批——也就是 [AI Agent 試點進不了生產那篇](/zh-Hant/blog/why-ai-agent-pilots-fail-four-layers/)裡說的治理返工。每生成一個應用就返工一次，規模化之後這筆賬會越來越難付。
 
 更省的做法，是讓規則把 agent 指向一個**本身就可治理的目標**。一份這樣的規則，核心不是風格，是約束產出的形態：
 
@@ -50,13 +50,13 @@ tags:
 
 這裡有個繞不過去的問題：憑什麼 agent 能把一個特定的目標格式寫對？規則寫得再好，模型不會寫也白搭。
 
-答案正是 [開放語義層那篇](/zh-Hans/blog/enterprise-ontology-race-open-vs-closed/) 論證過的飛輪——**agent 更容易生成它見過、能檢索到、能被規則約束的東西**。一個封閉平臺的私有格式，如果公開材料少、示例少、校驗反饋弱，再怎麼寫規則也很難穩定生成。而 ObjectStack 是 Apache 2.0 的開放協議，這讓"讓 agent 寫對它"具備了三個現實前提：
+答案正是 [開放語義層那篇](/zh-Hant/blog/enterprise-ontology-race-open-vs-closed/) 論證過的飛輪——**agent 更容易生成它見過、能檢索到、能被規則約束的東西**。一個封閉平臺的私有格式，如果公開材料少、示例少、校驗反饋弱，再怎麼寫規則也很難穩定生成。而 ObjectStack 是 Apache 2.0 的開放協議，這讓"讓 agent 寫對它"具備了三個現實前提：
 
 1. **可被學到**：開放 + 公開 + 被討論 → 更容易被模型和檢索系統學到；
 2. **可被約束**：一份規則檔案把 agent 的產出錨定到這個宣告式目標；
 3. **可在生成時校驗**：執行時會校驗生成的後設資料——非法的定義直接被拒，agent **當場拿到糾錯訊號**。這是自由格式程式碼給不了的關鍵差別：一段錯的 SQL 可能照樣跑、上線才爆，而一份錯的後設資料進不了門、當場就被打回重寫。
 
-正是第 3 點，把"讓 agent 寫對"變成了有反饋的收斂過程——agent 寫錯、被拒、改對，像編譯錯誤一樣即時。更進一步，你還可以把執行時的受治理工具通過 **MCP** 暴露出來，讓 agent 在生成時就調取權威定義、在執行時又能在邊界內操作它——寫和用，同一套治理。（受治理工具層這件事，[MCP 那篇](/zh-Hans/blog/mcp-governed-tool-layer/) 單獨講過。）
+正是第 3 點，把"讓 agent 寫對"變成了有反饋的收斂過程——agent 寫錯、被拒、改對，像編譯錯誤一樣即時。更進一步，你還可以把執行時的受治理工具通過 **MCP** 暴露出來，讓 agent 在生成時就調取權威定義、在執行時又能在邊界內操作它——寫和用，同一套治理。（受治理工具層這件事，[MCP 那篇](/zh-Hant/blog/mcp-governed-tool-layer/) 單獨講過。）
 
 ## 落地：今天就能加的三條
 

diff --git a/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx b/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx
@@ -17,7 +17,7 @@ tags:
 
 **先給結論**：agent 該不該受許可權約束，這件事已經不用爭了。真正決定這道邊界是真是假的，是**檢查跑在哪一層**——在資料進入模型上下文之前，還是之後。之後才補的過濾不是邊界，是**紙面許可權**：寫下來像訪問控制，執行時什麼都不做。所以採購和評審時該問的不是"你們有沒有許可權模型"，而是"你們能不能證明某一條許可權不是紙做的"。
 
-"agent 到底該不該繼承使用者身份、該不該受審批和審計約束"，我們在 [AI Agent 資料安全邊界：如何在企業許可權內工作](/zh-Hans/blog/ai-agent-business-data-security-boundaries/) 裡單獨論證過。這篇預設你已經同意那一層，只問後面那個更難回答的問題：這道邊界具體落在哪一行程式碼上，以及它失效的時候，你能看見嗎？
+"agent 到底該不該繼承使用者身份、該不該受審批和審計約束"，我們在 [AI Agent 資料安全邊界：如何在企業許可權內工作](/zh-Hant/blog/ai-agent-business-data-security-boundaries/) 裡單獨論證過。這篇預設你已經同意那一層，只問後面那個更難回答的問題：這道邊界具體落在哪一行程式碼上，以及它失效的時候，你能看見嗎？
 
 ![同一個請求的兩條路徑：紅線之前攔，還是紅線之後補](./security-pipeline.svg)