與 AI 程式碼工具協作

現在，在 iMBrace 上大多數的建置工作都可以交給 AI 程式碼工具完成。這沒有問題，而且幾乎不會改變「完成」這件事的定義。這一頁要說的，就是真正會改變的部分。

立場

工具負責協助，由人來決策。 這不是因為工具能力不足，而是因為責任無法轉移。必須有人簽核確認這個建置成果可以運作，而這個人不能是寫出它的那個東西。

絕不採信建置成果對自己的回報。 AI 工具讓這個問題更為突出：一份令人信服的「測試通過」摘要很容易產生，也很難與真正通過的結果區分。要親自執行它、親眼看著它跑，並且到平台上查看結果。你沒有親眼看到的綠燈，就不算綠燈。

誠實說出目前的狀態。 建置成果的每一個部分，都只會是以下三種狀態之一：

proposed（已提出）——已設計，但尚未建置；
built（已建置）——已建置，但尚未在平台上實際執行並檢查過；
live（已上線）——已在平台上執行，且結果已由人檢查過。

沒有人會因為狀態是「built（已建置）」而被苛責。把從未執行過的東西寫成「live（已上線）」，才是真正的失敗。

該給工具什麼

這份指南的 AGENTS.md，或是管轄你眼前這項工作的那一頁就好，不要一次全部都給——讀了所有東西的工具，留給你問題本身的空間反而更少。
SDK 自己的地圖，在它撰寫 SDK 程式碼時，從 engineer.imbrace.co 即時抓取，絕不使用舊的副本。
組織本身，透過 MCP 連線取得——當問題是關於現在有什麼、或發生過什麼事的時候，請見設定你的程式碼工具。

防護措施

絕不把憑證放進工作流、程式碼步驟、提示詞，或任何已提交的檔案中。 憑證只存放在組織的連線儲存區，或本機一個絕不提交的 .env 檔案裡。
程式碼步驟必須是「純」的——輸入數字、輸出結果，不做網路呼叫、不用金鑰——否則就要清楚說明為什麼不是。
拒絕回答也是一種資料，不是錯誤。 「我找不到這個」本身就是一個有效、有用的答案。
被跳過的檢查絕不算通過。 如果測試無法執行，就要說它沒有執行。
測試資料、記錄、提示詞或範例中不得含有個人資料，一律用虛構的。
寫給一個陌生人看。 句子要平實清楚，不用簡稱代號，也不寫只有當時在對話裡的人才看得懂的內容。

最重要的幾個習慣

先看商業成果。 誰會用它、現在卡在哪裡、它能解開什麼。回答一個沒有人問過的問題，答案再聰明也是錯的。
先由人畫出草圖。 在工具提出設計之前，先讓人畫出這個使用案例——它的輪廓、組成部分，以及哪裡該由人來決策。這樣設計才會真正屬於這個人。
用證據表達不同意見。 當工具認為這個人的想法有誤時，要立刻連同證據說出來，而不是默默照著要求去做。
每一個主張都要有依據。 一筆 board 資料列、一個執行 id、一段貼上的輸出結果。沒有依據，就不能主張。
更正紀錄時要註明日期。 當某項發現或決策紀錄後來證實有誤時，就在原地註明日期說明，並保留原文可見。
交由另一個人審查。 在成果上線之前，由沒有參與建置的人執行審查清單。
程序的繁簡要與變更的大小相稱。 小變更只需簡短的紀錄。

委派要保持淺層

如果你的工具把工作交給它自己的助手，請把交接保持在最上層，給每個助手完整的說明，並且親自檢查每一項結果：當助手說它修好了什麼，就打開檔案親自看一看。

「完成」代表什麼

是另一個人可以安裝的東西、一份他們可以照著做的說明、一個他們可以執行的測試，以及每個部分都誠實標示的狀態。