objectstack-ai · hotlong · Sep 3, 2026 · Sep 3, 2026
diff --git a/content/blog/ai-agent-workbench/index.zh-Hant.mdx b/content/blog/ai-agent-workbench/index.zh-Hant.mdx
@@ -170,7 +170,7 @@ Agent 工作臺不應該一開始覆蓋所有系統。更好的路徑是從一
 
 第五，完善 `agent_run` 和審計日誌，讓每次執行都能覆盤。
 
-第六，逐步跨系統擴充套件，把多個業務物件連線成更完整的執行工作臺。
+第六，逐步跨系統擴充，把多個業務物件連線成更完整的執行工作臺。
 
 這條路徑讓企業可以先驗證價值，再擴大 Agent 的權限。
 

diff --git a/content/blog/ai-ontology-open-protocol/index.zh-Hant.mdx b/content/blog/ai-ontology-open-protocol/index.zh-Hant.mdx
@@ -75,7 +75,7 @@ Palantir Foundry 的核心動作是兩個。第一，把企業散落各處的資
 
 這個反例值得認真接，因為接完恰好能看清規律。
 
-看一眼 AWS 是怎麼賺錢的：它託管的是 Linux、Kubernetes、Postgres——清一色的開放標準。iPhone 封閉，但它跑的網路是 TCP/IP 和 HTTP。再往前數：資料庫廠商殺成紅海，SQL 這個語言本身是公共的；容器編排打了三年，最後大家都跑在開放的 OCI 映象格式上。
+看一眼 AWS 是怎麼賺錢的：它託管的是 Linux、Kubernetes、Postgres——清一色的開放標準。iPhone 封閉，但它跑的網路是 TCP/IP 和 HTTP。再往前數：資料庫廠商殺成紅海，SQL 這個語言本身是公共的；容器編排打了三年，最後大家都跑在開放的 OCI 映像格式上。
 
 規律其實很整齊：**被整個生態依賴的可移植底座最終會走向開放——既包括定義，也包括解釋和執行這些定義的基礎執行時。** 廠商仍然可以獲得持續收入，但賣的是託管運營、升級、安全封裝、效能、支援和責任。AWS 自己就是最大的例證：Linux、Kubernetes、Postgres 保持開放，AWS 為可靠運營它們收費。
 

diff --git a/content/blog/ai-project-risk-assistant/index.zh-Hant.mdx b/content/blog/ai-project-risk-assistant/index.zh-Hant.mdx
@@ -30,7 +30,7 @@ AI 專案管理助手的價值，不是再做一個任務看板，而是持續
 
 ## 專案管理的問題，不只是任務沒更新
 
-很多專案工具預設假設：只要每個人按時更新任務狀態，專案經理就能看清全域性。
+很多專案工具預設假設：只要每個人按時更新任務狀態，專案經理就能看清全域。
 
 現實是，人們會在不同地方留下訊號：
 

diff --git a/content/blog/automation-cross-system-flows/index.zh-Hant.mdx b/content/blog/automation-cross-system-flows/index.zh-Hant.mdx
@@ -13,11 +13,11 @@ cover: ./cover.svg
 tags: []
 ---
 
-**先給結論**：可靠的自動化引擎，不是多接幾個 API，而是把外部呼叫、失敗、重試和補償都當成流程裡的受治理節點——聯結器是業務能力，不是介面清單，跨系統流程才不會變成指令碼堆。動手之前先把方向擺正：在 ObjectStack 裡，Webhook 是**出站**的，負責把平臺內發生的事推給外部系統；外部系統要把事件送進來，走的是另一條入口。兩個方向的失敗模式幾乎相反，用同一個詞概括它們，是跨系統整合最貴的一次口誤。
+**先給結論**：可靠的自動化引擎，不是多接幾個 API，而是把外部呼叫、失敗、重試和補償都當成流程裡的受治理節點——聯結器是業務能力，不是介面清單，跨系統流程才不會變成腳本堆。動手之前先把方向擺正：在 ObjectStack 裡，Webhook 是**出站**的，負責把平臺內發生的事推給外部系統；外部系統要把事件送進來，走的是另一條入口。兩個方向的失敗模式幾乎相反，用同一個詞概括它們，是跨系統整合最貴的一次口誤。
 
 最容易失控的自動化，往往不是因為流程太複雜，而是因為它跨了太多系統。
 
-CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務要提醒負責人。每一步都能用指令碼或一次 HTTP 呼叫接起來，但幾個月後，團隊常常只剩一個問題：這條流程到底是誰在控制？
+CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務要提醒負責人。每一步都能用腳本或一次 HTTP 呼叫接起來，但幾個月後，團隊常常只剩一個問題：這條流程到底是誰在控制？
 
 一個客戶續約流程可能要查 CRM 裡的客戶和商機，讀取合同系統裡的到期日，呼叫財務系統確認應收狀態，再把任務分派到客戶成功團隊。一個採購流程可能要連線供應商庫、ERP、合同系統、郵件服務和審批系統。一個工單流程也可能從客戶門戶進入，再流轉到客服、研發、知識庫和通知渠道。
 
@@ -29,7 +29,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 ## 跨系統流程為什麼容易失控
 
-很多企業一開始會用指令碼或整合工具把系統串起來：
+很多企業一開始會用腳本或整合工具把系統串起來：
 
 - CRM 狀態變化後呼叫合同系統；
 - ERP 更新後通知採購；
@@ -40,7 +40,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 某個介面超時了，流程是否重試？外部系統返回半成功，內部記錄是否回滾？同一條訊息被投遞了兩次，業務動作是否會重複執行？供應商 API 欄位改名，流程是否靜默失敗？管理員要查一條記錄為什麼被更新，能不能看到完整呼叫鏈？
 
-如果這些邏輯散落在指令碼、Webhook 配置、後臺任務和第三方工具裡，業務流程就會變成“能跑但難管”的整合拼圖。
+如果這些邏輯散落在腳本、Webhook 配置、後臺任務和第三方工具裡，業務流程就會變成“能跑但難管”的整合拼圖。
 
 自動化引擎要解決的不是能不能調 API，而是能不能把跨系統呼叫納入業務流程治理。
 
@@ -60,7 +60,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 把兩個方向都叫“Webhook”，最後就是拿一套假設去套兩種機制。被對方重發的那一次通知建立了兩條審批，和被平臺重投的那一次推送讓對方多記了一筆賬，是同一個錯誤的兩個方向。
 
-還有一條和方向無關、卻同樣常被跳過：不管哪一側，它們都只適合承擔邊界事件，不適合承擔業務邏輯。誰審批、改哪個欄位、通知誰，這些決定應該留在平臺內的流程裡。這樣，某條業務記錄為什麼進入高風險狀態，不需要去翻外部服務日誌和指令碼，只要看這條流程的觸發事件、判斷節點和動作日誌。
+還有一條和方向無關、卻同樣常被跳過：不管哪一側，它們都只適合承擔邊界事件，不適合承擔業務邏輯。誰審批、改哪個欄位、通知誰，這些決定應該留在平臺內的流程裡。這樣，某條業務記錄為什麼進入高風險狀態，不需要去翻外部服務日誌和腳本，只要看這條流程的觸發事件、判斷節點和動作日誌。
 
 ## 外部呼叫應該是流程節點
 
@@ -78,7 +78,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 例如供應商准入流程中，自動化可以先建立供應商記錄，再呼叫外部工商資訊服務，接著呼叫制裁名單檢查，最後根據結果決定是否進入採購經理複核。
 
-如果這些外部呼叫只是指令碼，業務人員很難知道發生了什麼；如果它們是流程節點，流程圖就能清楚表達“這個判斷來自哪個系統，失敗後會怎麼處理”。
+如果這些外部呼叫只是腳本，業務人員很難知道發生了什麼；如果它們是流程節點，流程圖就能清楚表達“這個判斷來自哪個系統，失敗後會怎麼處理”。
 
 ## 聯結器不是介面清單，而是業務能力
 
@@ -177,7 +177,7 @@ CRM 改了狀態，ERP 要查應收，合同系統要確認簽署，通知服務
 
 ObjectOS Automation 的重點不是把每個 API 都包裝成按鈕，而是讓跨系統呼叫進入可治理的業務流程。
 
-業務物件提供上下文，執行時註冊的聯結器提供外部能力，入站地址承接邊界事件，出站 Webhook 把結果推回外部系統，流程節點表達判斷和動作，執行日誌記錄每一步。這樣，跨系統自動化不再是看不見的整合指令碼，而是業務應用的一部分。
+業務物件提供上下文，執行時註冊的聯結器提供外部能力，入站地址承接邊界事件，出站 Webhook 把結果推回外部系統，流程節點表達判斷和動作，執行日誌記錄每一步。這樣，跨系統自動化不再是看不見的整合腳本，而是業務應用的一部分。
 
 對企業來說，跨系統流程能不能跑只是第一步。更重要的是：跑錯了能不能發現，失敗了有沒有補救，改流程時能不能看懂影響，審計時能不能解釋。
 

diff --git a/content/blog/automation-governed-flow-changes/index.zh-Hant.mdx b/content/blog/automation-governed-flow-changes/index.zh-Hant.mdx
@@ -23,7 +23,7 @@ tags: []
 
 折扣審批閾值會調整，客服升級規則會變化，採購複核條件會增加，合同流轉要加入新的法務節點，報銷政策每個季度都可能更新。
 
-如果每次變化都要找開發排期，業務會嫌慢；如果每次變化都讓業務人員直接改指令碼，系統會失控。自然語言改流程看起來是一個很好的答案：業務人員說出變化，平臺自動修改流程。
+如果每次變化都要找開發排期，業務會嫌慢；如果每次變化都讓業務人員直接改腳本，系統會失控。自然語言改流程看起來是一個很好的答案：業務人員說出變化，平臺自動修改流程。
 
 但這裡真正的難點不在“聽懂一句話”，而在“改完之後可不可靠”。
 
@@ -108,7 +108,7 @@ tags: []
 
 一個可治理的自動化引擎應該把變更變成 diff：流程圖層面的 diff、條件層面的 diff、動作層面的 diff、權限層面的 diff。
 
-這也是後設資料驅動的價值。因為流程是結構化的，平臺才能比較前後差異，而不是讓人去讀指令碼。
+這也是後設資料驅動的價值。因為流程是結構化的，平臺才能比較前後差異，而不是讓人去讀腳本。
 
 ## 校驗比生成更重要
 
@@ -127,7 +127,7 @@ tags: []
 
 業務人員不應該靠肉眼發現這些問題。平臺要在釋出前攔住它們。
 
-這也是為什麼“自然語言改流程”不能等同於“AI 直接寫指令碼”。指令碼能生成，但平臺很難知道它是否符合業務流程結構；後設資料流程可以被校驗。
+這也是為什麼“自然語言改流程”不能等同於“AI 直接寫腳本”。腳本能生成，但平臺很難知道它是否符合業務流程結構；後設資料流程可以被校驗。
 
 ## 執行中的流程如何處理
 

diff --git a/content/blog/automation-pause-resume-approvals/index.zh-Hant.mdx b/content/blog/automation-pause-resume-approvals/index.zh-Hant.mdx
@@ -17,15 +17,15 @@ tags: []
 
 很多流程不是“觸發後立刻做完”，而是“做到一半，等人、等時間、等外部結果”。
 
-如果自動化引擎不會等待，審批就會被拆到另一套系統裡；如果它不會恢復，流程後半段就只能靠指令碼、回撥和人工補救拼起來。
+如果自動化引擎不會等待，審批就會被拆到另一套系統裡；如果它不會恢復，流程後半段就只能靠腳本、回撥和人工補救拼起來。
 
 很多自動化工具擅長做短任務：觸發後馬上執行幾個動作，然後結束。
 
 但企業流程很少這麼簡單。它經常需要等人審批、等使用者補充材料、等三天後檢查結果、等外部系統回撥。流程不是幾秒鐘跑完，而是可能持續數小時、數天甚至數週。
 
 這就是為什麼自動化引擎必須支援暫停和恢復。
 
-如果沒有這個能力，審批就會被做成另一套系統，等待會被做成定時任務，外部回撥會被做成 Webhook 指令碼。業務流程被切成很多段，系統能跑，但很難看成一條完整鏈路。
+如果沒有這個能力，審批就會被做成另一套系統，等待會被做成定時任務，外部回撥會被做成 Webhook 腳本。業務流程被切成很多段，系統能跑，但很難看成一條完整鏈路。
 
 ![暫停和恢復讓審批進入同一條流程](./pause-resume.svg)
 
@@ -158,7 +158,7 @@ ObjectOS Automation 把審批、等待和外部訊號視為流程能力，而不
 
 當流程執行到需要人或時間的節點時，它可以暫停；當審批結果、時間或外部事件回來時，它可以從正確上下文繼續。通過、拒絕、超時和失敗都能進入不同分支，並留下執行記錄。
 
-這讓審批不再是另一套系統，等待不再是散落的定時任務，外部回撥也不再是孤立指令碼。
+這讓審批不再是另一套系統，等待不再是散落的定時任務，外部回撥也不再是孤立腳本。
 
 對企業來說，這一點非常關鍵。真正的業務自動化不是讓系統在幾秒鐘內做完所有事，而是讓系統在幾天、幾周的業務週期裡，始終知道流程在哪裡、等誰、下一步做什麼。
 

diff --git a/content/blog/automation-trigger-model/index.zh-Hant.mdx b/content/blog/automation-trigger-model/index.zh-Hant.mdx
@@ -191,6 +191,6 @@ ObjectOS Automation 的價值，不是提供很多零散觸發器，而是把不
 
 這讓企業自動化更容易治理。
 
-當業務問“為什麼這條流程被觸發”，平臺可以回答觸發來源；當業務問“不同入口是否執行同一套規則”，平臺可以展示流程版本；當管理員要修改規則，也不需要到處找指令碼。
+當業務問“為什麼這條流程被觸發”，平臺可以回答觸發來源；當業務問“不同入口是否執行同一套規則”，平臺可以展示流程版本；當管理員要修改規則，也不需要到處找腳本。
 
 自動化引擎真正統一的不是事件，而是事件之後的業務執行方式。
diff --git a/content/blog/beyond-agentforce-copilot-open-runtime/index.zh-Hant.mdx b/content/blog/beyond-agentforce-copilot-open-runtime/index.zh-Hant.mdx
@@ -41,7 +41,7 @@ tags:
 | 模型選擇 | 偏向自家或繫結模型 | 自由換，模型在外、執行時在內 |
 | 業務定義歸屬 | 長在平臺裡 | 你倉庫裡的開放協議後設資料（Apache 2.0） |
 | 計費 | 按動作 / 按席位 | 按執行時與基礎設施，與用量解耦 |
-| 起步姿態 | 先把業務搬進生態 | 擴充套件存量系統，不要求先遷移 |
+| 起步姿態 | 先把業務搬進生態 | 擴充存量系統，不要求先遷移 |
 
 這張表沒有"全對"的一列。
 
@@ -91,7 +91,7 @@ export const Customer = ObjectSchema.create({
 - **之前**：agent 接 Salesforce，看到商機活躍，答"值得"；它壓根不知道自建系統裡這個客戶的交付一直在延期、工單積壓。
 - **之後**：agent 面對的是**一個**統一的客戶，商機、交付、工單一起看，答"商機不錯，但交付風險高，先解決履約再談擴單"。
 
-同一個模型、同一個問題，只因為腳下的"客戶"不再被牆切開，結論就從片面變成了全域性。而這一切不需要為每個牆外系統重寫同步管道——業務定義是你倉庫裡可 diff、可遷移的後設資料；執行時跑在你自己的基礎設施上，強制權限、記錄審計；模型可以來自外部任何一家。你沒有把"自己業務的定義"交給任何一家保管。
+同一個模型、同一個問題，只因為腳下的"客戶"不再被牆切開，結論就從片面變成了全域。而這一切不需要為每個牆外系統重寫同步管道——業務定義是你倉庫裡可 diff、可遷移的後設資料；執行時跑在你自己的基礎設施上，強制權限、記錄審計；模型可以來自外部任何一家。你沒有把"自己業務的定義"交給任何一家保管。
 
 ## 一個誠實的選擇題
 

diff --git a/content/blog/business-app-in-16k-tokens/index.zh-Hant.mdx b/content/blog/business-app-in-16k-tokens/index.zh-Hant.mdx
@@ -40,7 +40,7 @@ find objectstack/examples/app-crm/src -name '*.ts' -not -name '*.test.ts' \
 
 五十年來我們用程式碼行數度量軟體，因為約束條件是人類讀者。現在讀者換了。AI 智慧體要*安全地*修改一個系統，得先把系統裝進上下文——這把所有程式碼庫分成兩種狀態：
 
-- **系統大於上下文。** 智慧體只能 grep、抽樣、猜測。它的修改是區域性的，錯誤卻是全域性的。每次變更都是隔著鑰匙孔做考古。
+- **系統大於上下文。** 智慧體只能 grep、抽樣、猜測。它的修改是區域性的，錯誤卻是全域的。每次變更都是隔著鑰匙孔做考古。
 - **系統小於上下文。** 智慧體一次讀完所有東西——每個物件、每條權限規則、每個依賴。*「改這裡會弄壞什麼？」*從一個願望變成一個可回答的問題。跨領域的變更——把一個概念在資料模型、權限、API 和介面裡統一重新命名——是一個連貫的 diff。
 
 這不是漸進式改善，是狀態切換。而分界線就畫在你的上下文視窗所在的位置。

diff --git a/content/blog/crm-ai-understands-customers/index.zh-Hant.mdx b/content/blog/crm-ai-understands-customers/index.zh-Hant.mdx
@@ -85,7 +85,7 @@ tags:
 **第一種，資料是散的。** 客戶在一張表，聯絡人在另一張表，商機又是另一套欄位，
 還有自定義備註、附件、工單、合同。人知道它們的關係，AI 不知道。
 
-**第二種，權限是糊的。** 銷售只能看自己的客戶，區域經理能看區域，老闆能看全域性。
+**第二種，權限是糊的。** 銷售只能看自己的客戶，區域經理能看區域，老闆能看全域。
 如果 AI 一接入就拿管理員權限，那就不是智慧化，而是越權。
 
 **第三種，語義是缺的。** 資料庫裡可能叫 `acct_id`、`opp_stage`、`last_touch_at`。

diff --git a/content/blog/extend-existing-systems-with-ai/index.zh-Hant.mdx b/content/blog/extend-existing-systems-with-ai/index.zh-Hant.mdx
@@ -172,7 +172,7 @@ Postgres 上以 `SELECT … WHERE …` 執行，並基於真實、當前的資
 
 | | 重建到新平臺 | 用 ObjectOS 連線 |
 |---|---|---|
-| **首次見效時間** | 數月 | 從少量物件開始，逐步擴充套件 |
+| **首次見效時間** | 數月 | 從少量物件開始，逐步擴充 |
 | **對記錄系統的風險** | 高 —— 資料遷移、雙寫、切換上線 | 低 —— 先只讀連線，源應用繼續執行 |
 | **資料存放在哪** | 被搬走 | 原地不動 |
 | **建模工作量** | 手工重新實現每個實體 | 編碼 Agent 從真實 schema 起草物件 |

diff --git a/content/blog/forward-deployed-engineer-tools/index.zh-Hant.mdx b/content/blog/forward-deployed-engineer-tools/index.zh-Hant.mdx
@@ -1,7 +1,7 @@
 ---
 # @generated zh-Hant from zh-Hans (s2twp) — edit the zh-Hans file; delete this line to hand-maintain.
 title: "FDE(前沿部署工程師)用什麼工具？一套本體優先的開源技術棧"
-description: "FDE 在一次 60–180 天的部署裡真正寫下什麼:接入介面卡、實體解析、權限對映、最初的幾條工作流。加上定義這份工作的五個痛點,以及 2026 年的模仿潮為什麼只抄走了崗位、沒抄走底下的基質。"
+description: "FDE 在一次 60–180 天的部署裡真正寫下什麼:接入配接器、實體解析、權限對映、最初的幾條工作流。加上定義這份工作的五個痛點,以及 2026 年的模仿潮為什麼只抄走了崗位、沒抄走底下的基質。"
 author: ObjectStack Team
 date: 2026-07-23
 updated: 2026-09-02T10:00:00+08:00
@@ -30,7 +30,7 @@ tags:
 
 | 部署天數 | 真正被寫下來的東西 | 什麼時候算做完 |
 |---|---|---|
-| **0–15 · 接入介面卡** | 每個源系統一個介面卡——他們的 ERP、他們的工單系統、那份其實才是事實來源的電子表格。先做讀取路徑:連線,不遷移。 | 介面上的一個業務物件,顯示出今天早上從他們系統裡出來的一條真實記錄。 |
+| **0–15 · 接入配接器** | 每個源系統一個配接器——他們的 ERP、他們的工單系統、那份其實才是事實來源的電子表格。先做讀取路徑:連線,不遷移。 | 介面上的一個業務物件,顯示出今天早上從他們系統裡出來的一條真實記錄。 |
 | **15–45 · 實體解析** | 沒人拿去演示的那一半苦活。"客戶"在四個系統裡是四個不同的主鍵:你要寫匹配規則、存活規則,以及本體認定為規範的那個識別符號。 | 同一家公司的兩條記錄合併了——而且他們的運營負責人認同就該合併。 |
 | **30–60 · 權限對映** | 把他們的組織架構翻譯成角色、權限集、行級共享和欄位級規則,包括那些只有三個人能看的欄位。 | 安全評審變成讀檔案而不是開會:評審人能直接指出誰能看到什麼。 |
 | **45–90 · 最初的幾條工作流** | 兩三條端到端的流程——一條審批鏈、一個分派佇列、一次續約——連同圍繞它們的動作、檢視和通知。 | 一個不給你打工的人,在這個應用裡完成了真實一天的工作。 |