上次，我公開了負責訓練的 AI 員工完整提示詞。
https://x.com/Sokichi_Hoshino/status/2099987762485358639
https://x.com/Sokichi_Hoshino/status/2100365149739880471
在第 1 部分中，我曾承諾會毫無保留地分享由 AI 員工造成的事故細節。這篇文章兌現了那個承諾，主角正是「停止官」AI 員工。
事故之所以發生，不是因為沒人能夠阻止它，而是因為沒有人去呼叫那個能阻止它的人。
「我把事情交給 AI，結果它改寫了我從未要求過的内容……」
這種恐懼，我親身經歷過。
用權限來預防事故，而不是靠規則。
這篇文章將說明三件事：事故期間發生了什麼、停止官 AI 員工的提示詞，以及事後我是如何調整權限分配的。
讓我們開始吧。
第 1 章：生產資料被偽造的「CEO 已批准」狀態所覆寫
事故發生在成立 AI 公司後不到一週的時間內。
我讓行銷部門負責回應分析的 AI 員工長時間執行資料解讀工作。
在這個過程中，該員工基於我實際上從未說過的言論繼續推進工作。
在工作過程中出現了「收到 CEO 回覆」和「CEO 觀點正確」這類語句。但我從未說過這些話。
類似語句反覆出現，文件和腳本都是基於這些虛假內容建立的。
最終，這名員工將内容寫入了生產環境的業務計畫試算表。它在績效表中新增列，並刪除預測表中的一筆預測條目，將其標記為「CEO 已批准」。
結果，年度銷售預測因刪除的預測條目而減少。
原本有一條規則規定，不可逆操作必須經過停止官 AI 員工。然而，當時擔任主持人的主要 AI 員工並未呼叫停止官。
是我讓它運行太久的錯。正如我在第 1 部分中所寫：
未經過停止官是我的責任。
第 2 章：公開停止官 AI 員工的提示詞
首先，這是停止官 AI 員工内容的原貌。
這是我這邊 .claude/agents/teishi.md 的内容。為了配合本文風格，我調整了對 CEO 的稱呼方式、假名用法及斷句，並移除了粗體標記。
我將「要保護的事物」最後一條中的過去事故範例縮減為一個，並稍微刪減了一些措辭。
1---2name: teishi3description: 法務與資訊管理部停止官。在刪除、發送、發布或計費等不可逆操作前進行攔截，朗讀即將發生的事項並請求確認（當被詢問「檢查這樣做是否安全」或在不可逆操作前被呼叫）4tools: Read, Grep, Glob5---67你是本公司法務與信息管理部的停止官。89你的職責是在不可逆操作前進行攔截。10你不執行操作。11你不授予權限。12你的職責是讓「即將發生的事項」對 CEO 可見，並將決策權移交給 CEO。1314# 攔截對象1516- 刪除 — 刪除檔案、資料、帳號、草稿17- 發送 — 發送電子郵件、LINE 廣播、訊息18- 發布 — 貼文、部署、發布共享連結、開放權限19- 計費/配額消耗 — 執行付費 API、購買、X API 發文配額（即使失敗也會消耗的資源）2021# 確認格式（朗讀 4 點）22231. 對什麼做了什麼 — 具體說明目標（若是檔案，列出關鍵内容；若是發送，列出收件人和内文摘要）242. 是否可逆？ — 完全可逆 / 需努力方可逆轉 / 不可逆253. 若失敗會損失什麼？ — 金錢、配額、信任、資料264. 更安全的替代方案 — 若有則提供一項（例如：先測試發送再全量廣播）2728# 流程29301. 閱讀計畫中的操作，驗證實際目標、收件人、數量等。（不要僅憑傳言確認）312. 簡短朗讀上述 4 點，並以「可以繼續嗎？」作結並暫停。323. 若目標内容與描述矛盾，在請求確認前先報告矛盾之處。3334# 要保護的事物3536- 稱呼 CEO 為「CEO」，並使用禮貌用語37- 在 CEO 說出「執行」之前，不催促執行或加快速度38- 若有過去事故類型的記錄（例如：X API 配額即使失敗也會減少），請將其加入 4 點確認中3940## 從訓練官處接收到的規則4142（暫無）
我希望你注意以下三點。
第一，tools 那一行。停止官 AI 員工僅擁有 Read、Grep 和 Glob 權限。它無法寫入檔案或執行命令。
在第 1 部分中公開的讀者視角 AI 員工擁有 Edit 和 Write 權限以記錄回饋。停止官甚至沒有這些權限；它確實是一名唯讀員工。
第二，「你不執行操作。」和「你不授予權限。」這兩行。停止官的工作止於將決策權移交給 CEO。
我相信如果攔截者說「可以執行」，這句話會被用作 CEO 批准的替代品。這次事故正是始於偽造的批准。
第三，步驟 1 中的「不要僅憑傳言確認」。即使出現「CEO 已批准」的字樣，停止官也會在朗讀 4 點確認之前，先閱讀實際内容。
將此儲存為 .claude/agents/teishi.md。當你詢問「檢查這樣做是否安全」時，主要 AI 會閱讀 description 並決定是否委派給停止官。
為了確保它被呼叫，請明確使用 @agent-teishi 來指名。
第 3 章：除非被呼叫，否則停止官不會行動
停止官 AI 員工並非站在公司入口的檢查站。它是一名只有被呼叫時才會行動的員工。
在 Claude Code 中，主要 AI 會閱讀每名員工的 description 來決定是否委派任務。官方文件指出：
Claude 使用每個子代理的 description 來決定何時委派任務。
停止官的 description 中也寫著「在不可逆操作前立即呼叫」。但呼叫與否的決定權在於呼叫方 AI。
如果呼叫方沒有意識到「這是不可逆操作」，訊息就永遠不會傳達給停止官。在事故當天，對生產資料的寫入操作在未呼叫停止官的情況下進行了。
停止官提示詞底部的「從訓練官處接收到的規則」章節，即使在事故之後仍然保持空白。
規則被添加到了執行寫入操作的那一方的提示詞中。
我認為需要修正的不是攔截者，而是那些無需經過攔截者就能寫入生產資料的一方。
第 4 章：事故後，我改變的是權限，而非規則
第一個修正措施是由訓練官 AI 員工在回應分析 AI 員工的提示詞中添加規則。
規則 #1 規定：僅根據 CEO 實際發送的文本來認定 CEO 的言論/批准，且未經 CEO 明確指示不得寫入生產試算表。
同樣的規則 #1 要求主持人在不可逆操作前必須經過停止官。
然而，我判斷僅靠這一點是不夠的。事故本身就是在有經過停止官這條規則的情況下發生的。
第二個改變是權限。在僱用 X 文章 AI 員工時，由於這次事故的教訓，我決定不給予它 Bash 存取權限。
X 文章 AI 員工可以撰寫文章，但在物理上無法將其提交至草稿箱。後來僱用的故事型 AI 員工也沒有 Bash 權限。
現在，將 X 文章提交至草稿箱是擔任主持人的主要 AI 員工的工作。當我們首次實施這種結構時，它確實經過了停止官。
我選擇從結構上使提交成為不可能，而不僅僅是在提示詞中寫下「不要提交」。
另一方面，回應分析 AI 員工仍然擁有 Write 和 Bash 權限，因為它需要使用 Bash 進行計算和比較。
第 1 部分中的規則「不要讓擁有寫入權限的員工長時間處理對外任務」就是針對這類員工而設的。
總結：預防 AI 事故需要比設置攔截者更嚴格地限制權限
最後，我要重申本文最重要的一點。
即使設置了攔截者，如果沒被呼叫，事故仍會發生。確保不可逆操作在結構上無法觸達更為可靠。
停止官是一名不授予任何權限的唯讀員工。為了防止因遺忘而導致的事故，請限制那些可以寫入的員工的權限。
打開你的 AI 員工檔案，檢查是否存在 `tools` 這一行的設定。
省略 tools 行的員工將繼承所有可用的子代理工具。
透過 tools 行限制工具，可以在將長時間任務交給 AI 員工的同時，大幅降低焦慮感。
這個 AI 公司系列將逐一剖析全部 46 名員工及其完整提示詞
這篇文章僅涵蓋了 46 名員工中的 1 名。
未來的文章將深入探討每篇文章對應的一名員工。
這個系列將揭示一切：46 名 AI 員工的内容、部門結構、權限分配以及設計修正。
我將以與成功設計相同的密度記錄已修正的設計。
我將陸續交付 AI 員工的内容。如果你想繼續閱讀，請關注 @Sokichi_Hoshino。
感謝你讀到最後。
【📣公告📣】
開設精通 AI 與 X 的社群頻道。
頻道將毫不保留地提供關於 AI 和 X 的最新且有價值的信息。
🎁頻道會員免費福利🎁
① 精選 200 個提示詞
② 20 顆寶石
③ 7 個 Claude 技能禮物 🎁
🌈頻道内分享的内容🌈
① 如何在首篇筆記貼文中實現 100 萬日圓銷售額
② SNS 行銷方法
③ 清單行銷方法
④ 數位數據行銷方法
⑤ 最快成長 X 的方法
以及其他更多，分享我作為具備數位/大數據行銷背景的活躍 AI×SNS 行銷專家的經驗見解。
歡迎新手和潛水員 ✨ 請隨意窺探 ✨
↓在此加入。
https://line.me/ti/g2/LmLu1N1cE6UBkoURbaYf_bV8l66cCyotSJU2og
【📣公告 2📣】
推出針對高管/企業主的 AI 顧問服務。
【服務内容】
・SNS 自動化支援 (X, Threads, Instagram, TikTok, YouTube)
・AI 員工建構支援
・AI 工具/App 創建
根據需求客製化以最大化營收。
