Slack Code 可以讓你和團隊一起看：
AI 的計畫。
Code Diff。
Live Preview。
再決定要不要接受修改。
但如果一開始只跟 Agent 說：
「幫我把這裡改好。」
後面即使所有人都看得到，
還是可能發生一個問題：
大家心裡想的「改好」，根本不是同一件事。
所以今天只學一個動作。
在 Agent 開始改以前，
先寫三格：
現在。
要變成。
不能動。
第一格：現在怎樣？
先把目前問題說清楚。
例如不要寫：
手機版按鈕不好看。
改成：
手機版首頁第一屏的「免費試用」按鈕目前太靠近頁面底部，使用者需要往下滑才能看到。
這一格是在定義：
起點。
因為如果連現在發生什麼都沒有說清楚，
AI 就會開始自己判斷：
是哪一個按鈕？
哪個頁面？
哪個尺寸？
什麼叫不好看？
第二格：要變成怎樣？
接著不要只說：
「改善一下。」
要告訴 AI：
最後你希望看到什麼。
例如：
手機版首頁打開後，不捲動畫面就能看到完整的免費試用按鈕。
這就是：
驗收條件。
修改完成後，
不用爭論：
「感覺好像有比較好。」
直接看：
有沒有做到？
第三格：不能動什麼？
這一格反而最容易被忘記。
例如你的真正需求只有：
手機版 CTA 往上。
但是 Agent 為了做到這件事，
可能順便修改：
桌面版間距。
字體。
導覽列。
其他 Button Style。
甚至共用 CSS。
所以第三格可以寫：
桌面版版型、按鈕文字、品牌字體與其他頁面不得修改。
這是在告訴 Agent：
成功不是改得愈多愈好。
成功是：
把指定問題修掉，
其他正常的東西留下來。
三格合起來就完成了
最簡單格式就是：
現在
目前發生什麼問題？
要變成
修改完成後，使用者應該看到什麼？
不能動
哪些原本正常的功能、頁面或資料必須保持不變？
例如：
現在： 手機版首頁第一屏看不到完整的免費試用按鈕。
要變成： iPhone 尺寸打開首頁後，不捲動就能看到完整 CTA。
不能動： 桌面版、CTA 文字、導覽列、其他頁面與登入流程都不要修改。
先根據這三個條件提出計畫。
如果需要改動「不能動」區域才能完成，先停下來告訴我，不要自行擴大範圍。
這已經是一個很好用的 Slack Code 任務起點。
為什麼 Slack Code 特別需要這種寫法？
因為 Slack Code 的重點不是：
一個人和 Agent 私下工作。
它把：
產品。
工程。
設計。
其他相關同事
拉進同一個 Code Channel。
Slack 官方設計就是讓大家可以在同一空間：
規劃。
Prompt Agent。
查看變更。
查看 Preview。
一起 Review。
所以這時候最怕的不是：
沒有人看到。
而是：
每個人看到的目標不同。
例如產品經理想的是 A
產品經理說：
手機版 CTA 要明顯一點。
他心裡可能只是希望：
按鈕提高 40 像素。
設計師想的是 B
設計師看到後可能理解成：
整個 Hero Section 重新排版。
AI 又可能理解成 C
Agent 為了讓 CTA 更明顯，
可能：
換顏色。
加大字。
改 Margin。
重排版面。
三個人都沒有錯。
問題只是：
「明顯一點」沒有明確驗收條件。
所以不要等 Code Diff 出來才第一次討論需求
Code Diff 告訴你的事情是：
AI 改了什麼。
它不能替你回答：
這些修改是不是原本真正想要的。
Live Preview 告訴你：
現在畫面變成什麼樣子。
它同樣不能替你回答：
這是不是正確的產品需求。
因此最便宜的修正時間，
永遠是在：
Agent 還沒開始大量修改以前。
「現在」這一格要盡量可觀察
不要寫：
網站很難用。
因為這太大。
可以改成：
手機版結帳頁的折扣碼欄位位於付款按鈕下方，測試使用者容易找不到。
或者：
深色模式下，主要 CTA 文字與背景對比不足。
或者：
商品頁在 390px 寬度時，價格與加入購物車按鈕重疊。
這些都有一個特色：
看得到。
AI 改完後，
也比較容易：
驗證。
「要變成」不要寫技術做法，先寫結果
例如不要第一句就要求：
把 padding 改成 16px。
因為你真正要解決的問題可能是：
按鈕被遮住。
如果 AI 發現：
16px 還是被遮住，
它反而會被你鎖在錯誤解法裡。
比較好的寫法是：
修改完成後，在指定手機尺寸下，按鈕不得被遮擋，而且第一屏可以完整看到。
你定義：
結果。
Agent 再提出：
怎麼做到。
什麼時候才指定技術做法？
如果那個技術本身就是限制，
再寫。
例如：
不准改 API。
不准改 Database Schema。
不增加新的 Dependency。
必須保留現有 Design Token。
這些就很適合放到：
不能動。
因為它們不是偏好。
而是：
邊界。
「不能動」尤其適合保護共用元件
AI Coding 很容易碰到一種情況：
你只是改：
A 頁。
Agent 發現 A 頁用了：
Shared Component。
於是它直接改：
Shared Component。
結果：
B。
C。
D。
三頁一起變。
所以如果你知道：
這是正式網站，
就可以直接寫：
如果修改 Shared Component 會影響其他頁面，先停下來說明影響範圍，不要直接修改。
這一句非常實用。
在 Slack Code 裡，讓團隊先回一個「同意」
既然 Code Channel 本來就是多人協作，
不要急著讓 Agent Build。
可以先貼：
現在。
要變成。
不能動。
然後讓相關人確認：
產品：
需求正確。
設計：
視覺邊界正確。
工程師：
技術限制正確。
確認完成，
再讓 Agent 往下做。
真正節省的不是：
這 30 秒。
而是避免二十分鐘後才有人說：
「等等，我不是這個意思。」
接下來再看 Slack Code 的 Plan
Slack Code 可以讓 Agent 在專屬 Code Channel 裡呈現：
Planning Document。
Code Diff。
Live HTML Preview
等工作內容。
所以三格寫完以後，
下一步才是：
看 Agent 的 Plan。
這時你只需要問：
它的計畫有沒有違反剛才三格？
看 Plan 時只檢查三件事
第一：
它是不是在修：
真正的問題？
第二：
它做完是不是會得到：
你寫的結果？
第三：
它有沒有碰到：
你說不能動的範圍？
如果第三個答案是：
有，
先不要 Build。
然後再看 Code Diff
Plan 是：
它說準備怎麼改。
Code Diff 是：
它真的改了什麼。
所以當 Diff 出來時，
還是用同一張三格卡檢查。
不用突然換一套標準。
例如：
明明「不能動」寫了：
桌面版。
結果 Diff 裡出現：
Desktop Layout CSS。
就值得問：
為什麼？
這比只看：
AI 說「已完成」
可靠很多。
最後看 Preview
如果是網站或介面修改，
Preview 才是最接近：
使用者真正看到的結果。
這時又回到：
第二格。
要變成怎樣？
例如你寫：
手機第一屏不捲動就看到 CTA。
那就真的切到：
手機尺寸。
確認：
看不看得到。
不要只看：
桌面 Preview 很漂亮，
就批准。
所以今天的方法其實一路都不用換
開始前：
現在／要變成／不能動。
看 Plan：
對照三格。
看 Diff：
對照三格。
看 Preview：
再對照三格。
最後才批准。
這樣團隊不用每到一個階段，
重新發明一套判斷標準。
這和 Replit Plan Mode 教學有什麼不同？
8 月 20 日我們已經教過：
AI 改 App 前先看 Plan，不先動程式。
今天再寫一次：
「先看 Plan」
就會變成重複內容。
所以今天往前推一層：
Plan 出來以前，你自己先定義什麼叫做成功。
Plan Mode 解決的是：
AI 準備怎麼做？
今天這三格解決的是：
人類到底要它做到什麼程度？
兩個是上下游關係。
也不要把「不能動」誤會成系統鎖定
這一點一定要分清楚。
你在 Prompt 寫：
不要改 Database。
不代表系統真的把 Database：
鎖起來。
它首先仍然是：
給 Agent 的工作指令。
如果某個 Agent 本身擁有更大的 Repository、部署或資料權限，
真正的技術安全還是需要：
權限。
Branch Policy。
Review。
測試。
Deployment Control。
所以三格方法的用途是：
讓目標與邊界更清楚。
不是取代：
工程權限治理。
可以直接複製這個模板
在開始修改以前，先用下面三個條件理解任務。
現在：
【目前可以觀察到的問題】
要變成：
【完成後可以直接驗證的結果】
不能動：
【不允許修改的頁面、功能、資料、元件或流程】
先提出你的修改計畫。
如果計畫必須超出「不能動」的範圍才能完成，先停下來說明原因。
不要自行擴大修改範圍。
一個完整例子
假設網站會員登入頁，
手機版 Logo 被切掉。
可以寫：
現在：
在 390px 寬度下，登入頁頂部 Logo 右側被裁切。
要變成：
在 360px～430px 的手機寬度下，Logo 都完整顯示，登入表單位置保持正常。
不能動：
不改 Logo 圖檔、不改登入 API、不改桌面版、不改會員驗證流程。
先提出計畫，不要直接部署。
這就比：
Logo 壞掉了，幫我修。
清楚很多。
如果你不懂程式也可以寫
因為三格根本不要求：
會 Coding。
你只要知道：
現在看到什麼？
希望最後變什麼？
哪些東西不要跟著改？
這也是 Slack Code 很有意思的地方。
Slack 官方現在就是希望：
非技術成員也能進入 Code Channel，
查看 Agent 正在做什麼、
看 Preview、
提出回饋，
再由相關人員一起 Sign Off。
今天的一分鐘方法
下次用 Slack Code 叫 AI 改網站或 App，
不要第一句就寫：
幫我改好。
先填：
現在
問題現在長什麼樣？
要變成
成功後可以看到什麼？
不能動
哪些正常東西必須留下？
然後才讓 Agent：
Plan。
Build。
Diff。
Preview。
Review。
今天真正要記住的一句話
AI Coding 最容易出錯的地方，不一定是程式寫錯，而是它成功完成了一個大家從來沒有真正說清楚的需求。
所以 Slack Code 開始以前，
先不要急著讓 AI 寫。
先讓整個團隊對：
現在是什麼。
要變成什麼。
什麼不能變。
有同一個答案。
後面 AI 跑得愈快，
這三格反而愈重要。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
