Claude，把「加入購物車」按鈕改成藍色：一個小網頁戳破 AI Agent 失控的日常
只叫 AI 改一顆按鈕的顏色，它常會順手改掉整頁。範圍沒框死，多做的部分比按鈕更貴。
依我們在 2026 年 9 月 10 日發稿前讀取的 Hacker News 快照，一個標題叫做「Claude, change the “Add to Cart” button to blue」的網頁，由 HN 用戶 matthieu_bl 在不到一天前貼上，拿到 1039 分、406 則留言，網址是 opusfived.dev。來源快照裡沒有這個網頁本身的說明文字，也沒公布作者是誰，所以下面不猜它的機制，只談 HN 上那四百多則留言在吵什麼。
那些留言之所以值得台灣的中小企業老闆看，是因為留言者幾乎都是每天在用 AI Agent 寫程式的人，而他們抱怨的東西，跟你叫 AI 改一段網站文案、改一張報價單時碰到的，是同一件事。
為什麼叫 AI 改一個網站按鈕顏色，它會順便改掉其他東西？
模型被訓練成傾向多幫一點。你講「改藍色」，它聽到的是「讓這個頁面更好」，於是相容性、測試、重構全被它一起扛上來。範圍是它自己放大的，你沒有要。
先講一句白話定義。AI Agent，指的是會自己拆步驟、自己動工具、自己判斷「做完了沒」的 AI，跟你在聊天框問一句答一句的用法不同。它能自主，就代表它有機會自主過頭。
HN 用戶 dudeinhawaii 在討論串裡的說法很具體：現在的模型會「double-triple-quadruple check」，明明已經有能跑的解法，它還要「用 Rust 再寫一個版本來證明收斂」。他點名 Opus 是最容易在這件事上跑偏的模型之一，但也補了一句，這不算壞事，只是他常得喊停：「這是第一版，之後還要改一百萬次，你測五十輪延遲對我沒有幫助。」
另一位用戶 bahbahbahbah 講得更狠：模型會為一個「兩小時前才建、零用戶」的專案嚴格維護向下相容。cruffle_duffle 接著說，這正是垃圾程式碼堆積的方式，模型把兩小時的小玩意當成「停機一秒就損失幾十億」的企業系統在對待。
這就是「AI 範圍蔓延」，英文叫 scope creep，白話說是任務邊界自己長大。你要一顆藍色按鈕，它交給你一次全頁改版。
HN 上四百多則留言，實際抱怨的是哪幾種行為？
可以歸成四種：過度驗證、自作主張的向下相容、順手加的遷移機制、以及死抱舊做法不肯重想。每一種都有留言者用具體案例佐證。
第一種是過度驗證，前面 dudeinhawaii 已經講了。
第二種是向下相容癖。用戶 MisterMunchkin 的例子最好懂：他叫模型把下拉選單的一個值改名，模型在整份程式碼裡把舊值也留著，理由是「以防有人透過 API 呼叫舊值」。throwaway7783 補充，模型會記得同一個對話裡自己改過哪些東西，然後努力對「自己剛剛的版本」保持相容，他得反覆講「不要向下相容」才壓得住。
第三種是遷移機制。用戶 stillpointlab 說，他加了功能 A、合併，再加功能 B，模型就冒出「糟了，我們得幫用功能 A 的使用者做遷移」，然後開始寫遷移腳本和整套測試機器。零用戶的專案，遷移誰？
第四種比較細，同樣是 stillpointlab 講的：模型會錨定在既有實作上。他跟模型討論一個罕見的資料遺失邊界案例，模型只想「在現有架構下怎麼補」，很難被拉去想「換一種更穩的做法是不是反而省事」。他的評語是，好的工程師會兩條路都算一次成本再選，模型傾向只算一條。
以上四種行為的共同點是：模型缺你的處境資訊時，會往「最保險、最完整、最囉嗦」的方向補，而那個方向通常最貴。
這對台灣中小企業意味著什麼？
意味著你現在最常做的那個動作，「丟一句話叫 AI 改」，是風險最高的用法。老闆改的東西多半沒有版本控制，改壞了沒地方回退。
我們的立場很直接：一句話指令只適合「產出新東西」，不適合「修改既有東西」。要修改，就先框範圍。
台灣的中小企業主現在拿 AI 做什麼？改官網文案、改 Landing Page 的按鈕、改報價單的一條條款、改公版回信的一段話。這些任務跟「按鈕改藍色」的結構一模一樣：對象很小、周圍全是不能動的東西。
工程師的處境比你好。他們有 git，改壞了一鍵回到上一版。你叫 AI 改報價單，AI 順手把付款條件的措辭「優化」了，你多半要到客戶問起才發現。那一句「優化」的代價，遠遠高於一顆按鈕的顏色。
所以我們對非工程用途的判斷是三條：
- 修改類任務，永遠框範圍。 指令裡明寫「只改這一項，其他一律不動」。
- 修改前先要清單。 叫它先列出打算動的地方，你點頭它才動。多一輪對話，省一次重做。
- 交代處境。 這份文件是草稿還是已寄出的合約？沒用戶還是有客戶在用？模型不知道，就會用最重的尺度來對待。
第三條有實證。HN 用戶 theshrike79 在每個專案放一份 PROJECT.md，明寫「這是單人、不出區域網路的新專案」，他說這能收斂部分過度保守行為。同一串裡 gopher_space 補了一個比喻，他寧可給模型幾顆明確的按鈕可以按，也不給一張空白支票，並附上一個 Black Mirror 條目)連結作比喻。theshrike79 的回應說出了大家的心聲：我們有一台什麼都能做的超級電腦，卻得花大把時間蓋圍籬、挖護城河、寫極度詳細的說明，它才不會跑去「幫忙」。
指令要怎麼寫，AI 才會只做一件事？
把「要做什麼」、「不准做什麼」、「做之前先回報什麼」三件事寫在同一段指令裡。三者缺一，模型就會自己補，補的方向通常是往大做。
下表是我們實際在客戶交付流程裡比較過的四種寫法。範例以「改網站按鈕顏色」為題，換成改文案、改報價單，結構不變。
| 指令寫法 | 實際改動範圍 | 常見副作用 | 你要花的檢查成本 |
|---|---|---|---|
| 一句話丟過去：「按鈕改藍色」 | 不可預測，常擴到整頁 | 順手改排版、改文字、加相容處理 | 最高，得整頁重看 |
| 框死範圍：「只改這顆按鈕的顏色，其他一律不動」 | 多數時候只動目標 | 偶爾仍加「以防萬一」的殘留 | 中，看目標與鄰近區域 |
| 框範圍＋先復述：「先復述你理解的任務，再動手」 | 只動目標 | 復述時就能抓到理解偏差 | 低，看復述是否正確 |
| 框範圍＋先報清單：「列出所有你打算改的位置，我確認後再改」 | 只動核准的位置 | 幾乎沒有 | 最低，看一張清單就好 |
第三列那招來自 HN 用戶 cruffle_duffle，他固定會叫模型「重新陳述我要你做什麼、以及為什麼這件事重要」，讓它退一步看整體再動手。第四列是我們自己加的一道閘門，用在客戶交付物上：模型先報清單，人點頭，才進行修改。這一道閘門就是我們說的「人類只做閘門點頭」的實際樣子。
常見的疑問是，這樣不會很慢嗎？會慢一輪對話，大約十秒到一分鐘。對照的是改壞一份已寄出報價單的代價。這筆帳不難算。
把限制寫進專案說明檔，真的能約束 AI 嗎？
能，效果有 HN 上的第一手證詞，但它約束的是「預設尺度」，不是每一次的行為。專案檔講處境，單次指令講範圍，兩層要一起用。
前面提到 theshrike79 的 PROJECT.md 做法。它的原理是把模型缺的處境資訊一次補齊：專案階段、用戶數、對外與否。模型有了這些，就不會把每個專案都當成企業級系統。
但要注意 throwaway7783 的經驗：即使講過，模型在同一段對話裡還是會回到向下相容的習慣，他得反覆提醒。所以說明檔負責降低發生率，單次指令負責兜底。兩層都做，才接近「只做一件事」。
對非工程用途，這個「說明檔」可以是你放在對話開頭的一段固定文字，例如：「以下所有修改任務，預設只改我指定的部分。任何額外建議請列在最後，不要直接動手。」這段文字寫一次，之後每次貼，比每次臨場想要穩定。
那 AI 幫忙多做的部分，全部都該擋掉嗎？
該擋的是「未經同意的改動」，該留的是「列出來等你決定的建議」。把模型的主動性從「動手」改成「提案」，你就同時拿到它的判斷力和你的控制權。
HN 用戶 genxy 在討論串裡反問了一句值得記住的話：如果模型訓練時不是往積極方向調，你會花所有時間逼它動起來。你要哪一種？
這句話點出真正的取捨。模型的「太熱心」和它的「能幹」來自同一個來源。把熱心關掉，能幹也會跟著掉。比較好的做法是保留熱心，但改變出口：它可以想到十件事，但只能做你點頭的那一件，其他九件寫成清單給你。
這也是我們替客戶跑交付產線時的原則。AI 全包重複執行，改動範圍由指令框死，額外發現一律進待確認清單，人只在閘門上點頭或打回。想看這套做法在 AI 搜尋可見度上的實際應用，可以看 AIRUN 的 AEO 服務頁。
結論：一顆按鈕的顏色，值得你改變下指令的習慣
這個網頁在 HN 上拿到一千多分，靠的是每個用 AI Agent 的人都被戳中。它把一個抽象的風險「agentic AI 自主過頭」壓縮成一句人人懂的笑話。
我們的判斷是：從今天起，對 AI 的任何修改類指令，都應該帶三個元素，範圍、禁區、確認點。沒有這三個元素的一句話指令，得到的結果由運氣決定。這條規則對工程師是效率問題，對老闆是損失控制問題。按鈕顏色改錯了很便宜，改錯的是你沒叫它動的那一段，才會貴。
常見問題
為什麼叫 AI 改一個按鈕顏色，它會順便改別的東西？
因為模型被訓練成傾向「多幫一點」。它會替你想相容性、想測試、想遷移，於是自己把任務範圍放大。Hacker News 上這串討論裡，多位工程師描述的都是同一種行為：兩小時的新專案被當成有百萬用戶的舊系統在維護。你不畫邊界，它就自己畫一個很大的。
下指令時最有效的一句話是什麼？
「只改這一項，其他檔案、其他文字、其他樣式一律不動；改之前先列出你打算動的清單給我確認。」這句把範圍、禁區、確認點三件事一次講清楚。HN 討論中有人靠「請先復述我要你做什麼、為什麼重要」這招把偏航的模型拉回來，原理相同。
我不是工程師，也需要在意 AI Agent 失控嗎？
需要，而且更需要。工程師有版本控制，改壞了可以回退。老闆直接叫 AI 改網站文案、報價單、公版信，多半沒有備份，改壞了只能憑記憶還原。把「一次只做一件事」寫進你的固定指令模板，成本是十秒，省下的是整份文件重做。
把限制寫在專案說明檔真的有用嗎？
HN 上有工程師分享，他在每個專案放一份 PROJECT.md，明寫「這是單人使用、不對外的新專案」，能收斂部分過度保守行為。原理是模型缺乏你的處境資訊時會往最安全、也最囉嗦的方向補。你把處境講清楚，它就不必自己猜。這招對非工程用途同樣適用。
AI 多做一點檢查和測試，難道不是好事？
要看階段。第一版、沒用戶、還要改一百次的東西，模型跑五十輪延遲測試、寫第二種語言驗證，只是在燒你的時間和額度。上線後、有真實客戶的系統，那些檢查才值錢。判斷權在你，所以指令裡要交代「現在是哪個階段」，模型才不會用錯尺度。