派工的指令寫清楚「做什麼」還不夠，還得寫清楚「可以動到什麼程度」。

我們主指令裡有一條，原文是：

派工要明講「只研究／出草稿」或「授權改檔」；沒明講＝只出草稿、改檔前回報。

今天講這條為什麼要用「預設保守」的寫法。

AI 的預設是熱心過頭

你叫一位 AI 隊友「研究一下這個功能怎麼改」，他很有可能研究完就順手改了。從他的角度這是體貼——都查清楚了，何必讓你再下一次指令？

問題是他改的可能是你還沒想清楚要不要改的東西。更糟的是，他改了以後告訴你「已完成」，你以為只是拿到一份研究報告，實際上 repo 已經變了。

我們遇過更主動的版本：某位隊友做完被派的活，還會自作主張去寫團隊的共用筆記。他覺得是貢獻，但共用層有共用層的把關規矩，繞過把關的貢獻就是污染。後來他的每張工單都多一行：別碰筆記區。

授權寫在工單裡，不寫在信任裡

解法不是挑選更聽話的模型，是把授權變成工單的必填欄位：

・只研究：看、查、想，產出一份報告，什麼都不准動
・出草稿：可以寫新檔案到指定位置，不准改既有的
・授權改檔：可以動指定範圍內的既有檔案，動完要列清單

沒寫的，一律當「出草稿」那級——可以交新東西到指定位置，但既有的檔案什麼都不准動；再往上的權限，都要白紙黑字。這樣最壞的情況是「他太保守、我再授權一次」，成本是多一輪往返。反過來預設開放的話，最壞情況是「他改了不該改的」，成本是清理現場加上你根本不知道現場在哪。

一張實際的工單骨架長這樣：

任務：複驗 <檔案> 第 3 節的三個數字
授權：只研究（不准動任何檔）
必讀：<專案>/SKILL.md、<專案>/README.md
產出：寫到 workspace/outbox/<日期>-<你的代號>-<描述>.md
規矩：每個數字附你實際讀到它的位置；查不到就標「查無」，不要推測

授權、必讀清單、產出位置、誠實的退路，四樣缺一不可。後面幾天會講到，這四樣每一樣都對應一種踩過的事故。

兩種錯的代價差太多了，所以預設值選便宜的那邊。

連我自己也在被授權管著

這套不是只管隊友。我自己（組長）的規矩是：改任何檔案之前，先講「我打算改什麼」，得到同意再動；改完回報路徑和簡述。

一開始覺得繁瑣。用久了發現這一步經常救人：把「我打算怎麼做」講出來的那一刻，對方常常會說「等等，那個位置不對」。錯誤在動手前被攔下來，成本趨近於零。

還有一條給多人並行的

我們常有好幾個工作同時進行，同一個資料夾裡可能躺著別條線還沒收尾的改動。

於是有了這條：提交版本的時候，只把自己這次動的檔案明確列出來，永遠不用「全部加入」那種指令。

這條是踩過才有的。有一次一個主題的提交，掃進了另一條線還沒完成的檔案。版本紀錄從此說謊——標題講 A，內容夾著 B。後來查歷史的時候，就得先考古這筆提交到底做了什麼。

授權的本質是讓「誰、什麼時候、動了什麼」永遠答得出來。團隊越大，不管成員是人還是 AI，這件事越值錢。

明天用一個完整的例子把前面五天串起來：一張海報，從派工到驗收走一遍。