diff --git a/content/blog/ai-agent-workbench/index.zh-Hant.mdx b/content/blog/ai-agent-workbench/index.zh-Hant.mdx index 52233ae..21a8e4d 100644 --- 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 index d14be6d..291162d 100644 --- 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 index 5adc4cd..257981b 100644 --- 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 index 1e404fb..ef7da18 100644 --- 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 index e45beef..dfbf4c4 100644 --- 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 index 3bd4426..271bf60 100644 --- a/content/blog/automation-pause-resume-approvals/index.zh-Hant.mdx +++ b/content/blog/automation-pause-resume-approvals/index.zh-Hant.mdx @@ -17,7 +17,7 @@ tags: [] 很多流程不是“觸發後立刻做完”，而是“做到一半，等人、等時間、等外部結果”。 -如果自動化引擎不會等待，審批就會被拆到另一套系統裡；如果它不會恢復，流程後半段就只能靠指令碼、回撥和人工補救拼起來。 +如果自動化引擎不會等待，審批就會被拆到另一套系統裡；如果它不會恢復，流程後半段就只能靠腳本、回撥和人工補救拼起來。 很多自動化工具擅長做短任務：觸發後馬上執行幾個動作，然後結束。 @@ -25,7 +25,7 @@ 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 index 961fc2c..3fbbe33 100644 --- 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 index 12e717f..65331cc 100644 --- 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 index c7a7479..968a73c 100644 --- 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 index 717e4c2..8ff2df5 100644 --- 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 index ede219d..0c10cf6 100644 --- 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 index d9fef3c..4c8e640 100644 --- 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 · 最初的幾條工作流** | 兩三條端到端的流程——一條審批鏈、一個分派佇列、一次續約——連同圍繞它們的動作、檢視和通知。 | 一個不給你打工的人,在這個應用裡完成了真實一天的工作。 | diff --git a/content/blog/from-requirement-to-app/index.zh-Hant.mdx b/content/blog/from-requirement-to-app/index.zh-Hant.mdx index f5a80ba..6c1a79e 100644 --- a/content/blog/from-requirement-to-app/index.zh-Hant.mdx +++ b/content/blog/from-requirement-to-app/index.zh-Hant.mdx @@ -319,7 +319,7 @@ agent 不需要猜資料庫結構。它通過受控工具查詢 `repair_order` ## 這和一次性程式碼生成的區別 -一次性程式碼生成的結果通常是很多檔案：頁面、API、資料庫、權限判斷、指令碼。第一版看起來快，但後續需求變化會讓程式碼逐漸分叉。 +一次性程式碼生成的結果通常是很多檔案：頁面、API、資料庫、權限判斷、腳本。第一版看起來快，但後續需求變化會讓程式碼逐漸分叉。 ObjectStack 後設資料的價值在於：**業務結構只有一個源頭**。 diff --git a/content/blog/low-code-vs-ai-native-app-platform/index.zh-Hant.mdx b/content/blog/low-code-vs-ai-native-app-platform/index.zh-Hant.mdx index be11c3b..8a80cb4 100644 --- a/content/blog/low-code-vs-ai-native-app-platform/index.zh-Hant.mdx +++ b/content/blog/low-code-vs-ai-native-app-platform/index.zh-Hant.mdx @@ -90,7 +90,7 @@ tags: [] AI 加入以後，問題變了：系統必須讓 AI 也讀得懂。 -如果一個應用的業務規則散落在幾十個配置頁面、隱藏指令碼、條件表示式和平臺私有 +如果一個應用的業務規則散落在幾十個配置頁面、隱藏腳本、條件表示式和平臺私有 元件裡，AI 很難一次性理解它。它不知道哪個配置是核心規則，哪個是歷史補丁；不 知道改一個欄位會影響哪條流程；更不知道哪些動作會觸碰權限邊界。 @@ -106,7 +106,7 @@ AI 加入以後，問題變了：系統必須讓 AI 也讀得懂。 這還不夠。 -真正的 AI-native 應用平臺，核心不是讓 AI 幫你拖控制元件，而是讓整個應用本身變成 +真正的 AI-native 應用平臺，核心不是讓 AI 幫你拖控制項，而是讓整個應用本身變成 AI 能讀懂、能修改、能驗證的結構。 這意味著應用的核心應該是清晰的後設資料和原始碼級宣告： diff --git a/content/blog/mcp-governed-tool-layer/index.zh-Hant.mdx b/content/blog/mcp-governed-tool-layer/index.zh-Hant.mdx index ee10412..c321456 100644 --- a/content/blog/mcp-governed-tool-layer/index.zh-Hant.mdx +++ b/content/blog/mcp-governed-tool-layer/index.zh-Hant.mdx @@ -43,7 +43,7 @@ agent 很樂意地照做了——全公司的，一條不落，包括這位銷 這話對，但它低估了兩件事。 -第一，**它不擴充套件。** 一兩個 server 你能仔細加鑑權，可企業很快就是幾十個 server、上百個工具，每一個都要手寫一遍身份核驗、權限判斷、審計落賬——這本身就是一大坨沒人讀的膠水程式碼，正是"技術債"那篇講的那種債，只是這次長在工具層。 +第一，**它不擴充。** 一兩個 server 你能仔細加鑑權，可企業很快就是幾十個 server、上百個工具，每一個都要手寫一遍身份核驗、權限判斷、審計落賬——這本身就是一大坨沒人讀的膠水程式碼，正是"技術債"那篇講的那種債，只是這次長在工具層。 第二，**"我們會小心"不是一種架構。** 它是一種依賴人始終不犯錯、不趕工、不走捷徑的承諾。而我們都知道，deadline 一來，"先連上、鑑權回頭補"的那條路，往往是最好走的那條。一個安全屬性如果要靠每個人每次都自覺，它遲早會破——開頭那家公司的工程師，也並不是不懂安全，他只是趕時間。 diff --git a/content/blog/objectos-action-tools/index.zh-Hant.mdx b/content/blog/objectos-action-tools/index.zh-Hant.mdx index db413e3..c7423c1 100644 --- a/content/blog/objectos-action-tools/index.zh-Hant.mdx +++ b/content/blog/objectos-action-tools/index.zh-Hant.mdx @@ -56,7 +56,7 @@ ObjectOS 的方向是讓 AI 呼叫同一個業務動作，而不是另寫一套 在 ObjectOS 裡，Action 不只是一個按鈕。它描述的是“這個業務應用允許做什麼”。 -一個 Action 可以出現在記錄詳情頁、列表行選單、批次操作區，也可以觸發 API、流程或後臺指令碼。它包含輸入引數、可見條件、停用條件、確認文案、執行目標和返回結果。 +一個 Action 可以出現在記錄詳情頁、列表行選單、批次操作區，也可以觸發 API、流程或後臺腳本。它包含輸入引數、可見條件、停用條件、確認文案、執行目標和返回結果。 這讓 Action 成為連線人和 AI 的自然入口： diff --git a/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx b/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx index 152ca61..4f8c360 100644 --- a/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx +++ b/content/blog/objectos-agent-permission-boundaries/index.zh-Hant.mdx @@ -99,7 +99,7 @@ ObjectStack 裡 agent 的資料工具從不直接碰引擎。它們走的是和 - 把 `exposed` 設為 `true`，**強制要求**一段面向大模型的 `description`，且至少 40 個字元。你沒法在不說明"什麼時候、為什麼該呼叫它"的前提下，把一個動作武裝給整個 agent 佇列。工具契約是被人寫下來的，不是從介面按鈕的標籤裡推匯出來的。 - 這個塊是**嚴格模式**的，而且那些"讀起來像開關、其實不是開關"的鍵，會被**重新命名到真正的那個鍵上**，而不是被靜默丟棄。這是平臺反覆撞到的失效形態：作者設了一個自己以為是閘門的鍵，而這個鍵根本不存在。有五種拼寫會落到 `exposed` 上——包括 `enabled`、`expose`，以及最像的那個 `visible`。在這個形狀被關嚴之前，它們是被靜默丟棄的：**動作照樣註冊、照樣執行，只是那個鍵本來要管的事情沒人管。** -同一個原則也管介面：`visible` 和 `disabled` 是 UI 謂詞，它們隱藏或置灰一個按鈕。**隱藏不是攔截**——按鈕沒了，路由還在。真正的閘門是 `requiredPermissions`，在平臺動作路由上以 403 強制執行。一個看不見、也沒被閘門管住的控制元件，是一條很有禮貌的紙面權限。 +同一個原則也管介面：`visible` 和 `disabled` 是 UI 謂詞，它們隱藏或置灰一個按鈕。**隱藏不是攔截**——按鈕沒了，路由還在。真正的閘門是 `requiredPermissions`，在平臺動作路由上以 403 強制執行。一個看不見、也沒被閘門管住的控制項，是一條很有禮貌的紙面權限。 這裡還有一個更常見的混淆：**三道閘門是三件事，不要指望在一個鍵上把它們都辦了。** @@ -122,7 +122,7 @@ ObjectStack 裡 agent 的資料工具從不直接碰引擎。它們走的是和 現實的推論只有一句：**開放給 AI 的動作，是被評審過的動作。** 行級權限不會替你評審它。如果一個平臺告訴你"有權限就夠了，暴露動作是安全的"，它沒有走過這條路徑。 -**第二，服務端的能力檢查只覆蓋平臺自己的呼叫路徑。** `requiredPermissions` 的 403，發生在平臺動作路由（`POST /api/v1/actions/{物件}/{動作}`）和 AI 呼叫路徑上——指令碼、流程、彈窗這三類動作都落在這裡。但一個 `type: 'api'` 的動作，如果它指向的是你自己寫的端點，那是**瀏覽器直連**的：平臺根本看不到這個請求，也就沒有任何東西在服務端檢查這條宣告。 +**第二，服務端的能力檢查只覆蓋平臺自己的呼叫路徑。** `requiredPermissions` 的 403，發生在平臺動作路由（`POST /api/v1/actions/{物件}/{動作}`）和 AI 呼叫路徑上——腳本、流程、彈窗這三類動作都落在這裡。但一個 `type: 'api'` 的動作，如果它指向的是你自己寫的端點，那是**瀏覽器直連**的：平臺根本看不到這個請求，也就沒有任何東西在服務端檢查這條宣告。 所以在那種動作上，介面上的閘門只是一種禮貌，不是邊界——**那個端點必須自己再檢查一次能力**。這不是缺陷，是邊界的位置：平臺只能強制它自己經手的呼叫。但如果沒人把這句話說給你聽，你會以為那條 `requiredPermissions` 在保護你。 diff --git a/content/blog/objectos-automation-engine/index.zh-Hant.mdx b/content/blog/objectos-automation-engine/index.zh-Hant.mdx index da777fb..2ddb4cd 100644 --- a/content/blog/objectos-automation-engine/index.zh-Hant.mdx +++ b/content/blog/objectos-automation-engine/index.zh-Hant.mdx @@ -21,7 +21,7 @@ tags: [] 這些功能有用，但它們還不是企業級 AI 自動化。 -真正的業務流程會判斷上下文、等待人工決策、處理異常分支、留下執行證據，還要允許業務人員用自然語言持續調整規則。否則自動化越多，系統越像一堆看不見的指令碼：誰觸發了它、為什麼走這個分支、哪個節點改了資料，都很難說清楚。 +真正的業務流程會判斷上下文、等待人工決策、處理異常分支、留下執行證據，還要允許業務人員用自然語言持續調整規則。否則自動化越多，系統越像一堆看不見的腳本：誰觸發了它、為什麼走這個分支、哪個節點改了資料，都很難說清楚。 ObjectOS 的 Automation 值得關注，不是因為它多了幾個“自動發通知”的模板，而是因為它把流程做成了後設資料。業務需求可以先變成流程結構，平臺再負責校驗、執行、暫停、恢復和審計。 @@ -66,13 +66,13 @@ ObjectOS 的 Automation 值得關注，不是因為它多了幾個“自動發 ## 後設資料讓 AI 生成的流程可以被治理 -如果 AI 直接生成一段指令碼，短期看很快，長期會帶來三個問題。 +如果 AI 直接生成一段腳本，短期看很快，長期會帶來三個問題。 第一，業務人員看不懂。腳本裡到底有哪些分支、改了哪些欄位、什麼時候通知誰，不容易被審查。 -第二，平臺不好管。權限、審批、日誌、版本和回滾都要靠指令碼自己實現，越寫越分散。 +第二，平臺不好管。權限、審批、日誌、版本和回滾都要靠腳本自己實現，越寫越分散。 -第三，AI 不好修改。業務人員說“把 50 萬改成 80 萬，並增加法務確認”，AI 需要先理解指令碼，再改指令碼，出錯風險很高。 +第三，AI 不好修改。業務人員說“把 50 萬改成 80 萬，並增加法務確認”，AI 需要先理解腳本，再改腳本，出錯風險很高。 ObjectOS 的做法是讓 AI 生成流程後設資料，而不是臨時程式碼。流程由節點、連線、條件、輸入輸出和執行策略組成。這樣平臺可以在釋出前檢查結構是否完整，執行時記錄每一步，介面裡展示流程圖，後續還能繼續用自然語言修改。 @@ -116,7 +116,7 @@ ObjectOS 的流程支援“暫停並等待”。流程執行到審批、表單 評估 AI 自動化能力時，不要只看能不能“用一句話建立規則”。更應該問： -- 這句話最終會生成什麼？是指令碼，還是可管理的流程後設資料？ +- 這句話最終會生成什麼？是腳本，還是可管理的流程後設資料？ - 流程釋出前能不能校驗條件和結構？ - 審批、等待和人工確認是否是一等能力？ - AI 修改流程後，業務人員能不能看懂變化？ @@ -128,7 +128,7 @@ ObjectOS 的流程支援“暫停並等待”。流程執行到審批、表單 ## ObjectOS 的差異 -ObjectOS 把物件、檢視、權限、動作、Agent 和流程都放在後設資料體系裡。Automation 不是外接指令碼工具，而是業務應用執行時的一部分。 +ObjectOS 把物件、檢視、權限、動作、Agent 和流程都放在後設資料體系裡。Automation 不是外接腳本工具，而是業務應用執行時的一部分。 這意味著業務人員可以先用自然語言提出目標，AI Builder 生成流程初稿；產品或運營人員檢查流程圖、條件和審批節點；管理員確認權限和風險；釋出後，流程在同一套物件、動作和審計體系中執行。 diff --git a/src/lib/zhconvert.ts b/src/lib/zhconvert.ts index 6c8092c..767ba60 100644 --- a/src/lib/zhconvert.ts +++ b/src/lib/zhconvert.ts @@ -23,37 +23,86 @@ import type { DictGroup, DictLike, LocalePreset } from 'opencc-js/core'; // fail with ERR_MODULE_NOT_FOUND. Keep relative imports out of this file — the // same constraint `src/lib/term-data.ts` documents, for the same reason. -// ─── Taiwanese vocabulary: s2twp, minus two wrong entries ────────────────── +// ─── Taiwanese vocabulary: s2twp, minus eight wrong entries ──────────────── // // `twp` is the right preset. Its phrase layer is what turns 数据 into 資料, // 程序 into 程式, 对象 into 物件, 接口 into 介面, 服务器 into 伺服器, 软件 into // 軟體, 信息 into 資訊, 缓存 into 快取, 用户 into 使用者 and 默认/缺省 into -// 預設 — 123 of its 603 phrase entries fire in the blog corpus, and all but two -// are the ordinary Taiwanese term. Dropping to plain `tw` to escape those two -// would lose every one of the rest, so the preset stays and the two are +// 預設 — 123 of its 603 phrase entries fire in the blog corpus, and all but +// eight are the ordinary Taiwanese term. Dropping to plain `tw` to escape those +// eight would lose every one of the rest, so the preset stays and the eight are // shadowed. // // HOW THE SHADOW WORKS. `s2twp` runs three conversion groups in order: // [STPhrases, STCharacters] → [TWPhrases] → [TWVariants]. Inside one group the // FIRST dictionary wins — `Trie.loadDictGroup` loads a group in reverse, so a -// dictionary listed earlier is loaded later and overwrites. An identity entry at -// the head of the TWPhrases group therefore disables exactly that one TWPhrases -// rule and nothing else: the correction lands at the stage that introduces the -// defect, and the character conversion underneath is untouched. +// dictionary listed earlier is loaded later and overwrites. An entry at the head +// of the TWPhrases group therefore replaces exactly that one TWPhrases rule and +// nothing else: the correction lands at the stage that introduces the defect, +// and the character conversion underneath is untouched. An entry whose two sides +// are equal disables the stock rule outright; an entry with a different right +// side substitutes for it. // -// WHY IDENTITY ENTRIES AND NOT A POST-PASS. Rewriting 許可權 back to 權限 after +// WHY OVERRIDE ENTRIES AND NOT A POST-PASS. Rewriting 許可權 back to 權限 after // the fact would also rewrite a genuine 许可权 — a real Simplified word — that // the preset had converted correctly. Shadowing leaves 许可权 → 許可權 alone and -// only stops 权限 from being rewritten. TWPhrases is the only dictionary in the -// chain that can emit 許可權 or 例項 at all: STPhrases (49276 entries), -// STCharacters (3882) and TWVariants (39) contain neither string. +// only stops 权限 from being rewritten. The same asymmetry is why 適配器 → +// 介面卡 is repaired here and not afterwards: 介面卡 is a real Taiwanese word (a +// network interface card), it is what a source 介面卡 must stay, and STPhrases +// carries it as an identity entry to keep it that way. A post-pass could not +// tell the two apart; the shadow never sees the genuine one. +// +// WHY THE SHADOW REACHES ALL EIGHT. Keyed on the post-s2t form, which is what +// the TWPhrases group sees — 权限 arrives as 權限, 镜像 as 鏡像, 扩展 as 擴展. +// And TWPhrases is the only dictionary in the chain that can emit any of the +// eight wrong strings at all, which is what makes shadowing it sufficient: +// across STPhrases (49276 entries), STCharacters (3882) and TWVariants (39), +// the only hit for any of them is STPhrases' identity entry 介面卡 → 介面卡, +// which can preserve a NIC but can never introduce one. export const TWP_PHRASE_OVERRIDES: readonly (readonly [string, string])[] = [ // 权限 → 許可權 is a Microsoft-glossary rendering; 權限 is the ordinary term in - // Taiwanese technical and legal writing. Keyed on the post-s2t form, which is - // what the TWPhrases group sees. + // Taiwanese technical and legal writing. ['權限', '權限'], // 实例 → 例項 is not standard Taiwanese usage in any register. ['實例', '實例'], + + // ── Mechanical over-substitutions: a fragment appended or swapped ──────── + // + // These five are not contested vocabulary. The preset glues on a word part, + // or swaps a character, in a way that is wrong in Taiwanese usage in any + // register and for any audience — so each is corrected to the ordinary term + // rather than merely disabled, since leaving the mainland spelling standing + // would be its own defect. + // + // 全局 → 全域性 appends a 性 that turns the noun into an adjective. + ['全局', '全域'], + // 扩展 → 擴充套件 appends 套件 ("package"). Every use in this corpus is the + // verb — extend a system, extend an object model — never a plug-in. + ['擴展', '擴充'], + // 适配器 → 介面卡 substitutes different hardware: 介面卡 is a network + // interface card. The adapter of the adapter pattern is 配接器. + ['適配器', '配接器'], + // 控件 → 控制元件 appends 元件 ("component"). The standard UI-control term is + // 控制項, which this corpus already ships elsewhere from a source 控制项 — + // closing the split is half the point of the entry. + ['控件', '控制項'], + // 镜像 → 映象 swaps the second character; a disk or container image is 映像. + // TWPhrases carries the same 象/像 slip a second time in 顯像管 → 映象管, + // left alone deliberately: no source here writes 显像管, and a CRT is not + // this card's business. + ['鏡像', '映像'], + + // ── One normalization, not a repair ───────────────────────────────────── + // + // 脚本 → 指令碼 is the Microsoft-glossary rendering; 腳本 is the ordinary + // Taiwanese word, and in this corpus the referent is always shell or webhook + // glue in an automation argument, never a screenplay. The reason it cannot + // wait for a vocabulary round is that the corpus already shipped BOTH: the + // STPhrases entry 本里 matches across the word boundary in 脚本里 and blocks + // the phrase layer along with the character layer, so a handful of sites + // escaped the substitution and read 腳本 while the rest read 指令碼. The + // identity entry settles every site the same way, straddled or not. + ['腳本', '腳本'], ]; /** `s2twp` with TWP_PHRASE_OVERRIDES shadowing the head of its phrase group. */ @@ -104,8 +153,11 @@ function buildVocabularyConverter(): (text: string) => string { // never sees it — so this is a whitelist by construction. It cannot fire on 公里, // 英里, 里程碑, 鄰里, 里長 or a place name, because none of those follow one of // the listed words. The straddle also blocks the phrase layer, which is why the -// text these rules touch reads 腳本 and 函數 rather than 指令碼 and 函式; both -// spellings are listed so the rule holds once a straddle stops hiding one. +// text these rules touch reads 函數 rather than 函式; both spellings are listed +// so the rule holds once a straddle stops hiding one. 腳本 no longer depends on +// that — TWP_PHRASE_OVERRIDES settles it everywhere — but 指令碼 stays in the +// alternation for the same reason 函式 does: this list must not be the thing +// that breaks if an override above is ever reconsidered. export const LOCATIVE_LI: readonly (readonly [RegExp, string])[] = [ // …里 directly after a technical artifact. `(?!程)` holds 里程碑 out: 系統里程碑 // is a milestone, not something inside the system. @@ -172,6 +224,36 @@ export const CONVERSION_CASES: readonly (readonly [string, string])[] = [ // …and a genuine 许可权 / 例项 in the source still converts on its own terms. ['许可权', '許可權'], ['例项', '例項'], + // The five mechanical over-substitutions, bare and in the phrase shapes the + // corpus actually writes. Each pins BOTH halves: the wrong string is gone and + // the ordinary term is what took its place, so a preset bump that reinstated + // 全域性 and a well-meant edit that merely disabled it both fail here. + ['全局', '全域'], + ['看清全局', '看清全域'], + ['错误却是全局的', '錯誤卻是全域的'], + ['一个全局定时服务', '一個全域定時服務'], + ['扩展', '擴充'], + ['逐步扩展', '逐步擴充'], + ['扩展存量系统', '擴充存量系統'], + ['适配器', '配接器'], + ['接入适配器', '接入配接器'], + ['控件', '控制項'], + ['拖控件', '拖控制項'], + ['镜像', '映像'], + ['开放镜像格式', '開放映像格式'], + ['离线容器镜像', '離線容器映像'], + // 脚本 normalized, straddled (see LOCATIVE_LI) and not. + ['脚本', '腳本'], + ['写一段脚本', '寫一段腳本'], + ['脚本和 webhook', '腳本和 webhook'], + // …and the genuine words these five must never disturb. 介面卡 IS a Taiwanese + // word — a network interface card — and a source that writes one keeps it; + // that is the whole reason 适配器 is repaired in the phrase layer rather than + // rewritten afterwards. 控制项 already converts to the same 控制項 the 控件 + // override now emits, which is the split this closes. + ['介面卡', '介面卡'], + ['全域', '全域'], + ['控制项', '控制項'], // The rest of the preset still applies. This is the whole reason `twp` is // kept rather than dropped to `tw` to escape the two entries above. ['数据 程序 对象 接口 服务器', '資料 程式 物件 介面 伺服器'],