前言：從「當場糾正」到「事先講清楚」

前面六天分析完現象、根因、案例，今天開始進入這個系列真正的核心動作：把反覆發生的糾正，轉換成一條可以事先講清楚的規則。這是把「每次都要靠使用者當場介入」的協作模式，變成「規則先講好，AI 自己照著做」的關鍵一步。

今日目標

• 認識把糾正轉換成規則的具體做法
• 看一組「事後糾正 vs 事先講清楚」的對照
• 理解這條規則該包含哪些具體要素

❌ vs ✅：事後糾正 vs 事先講清楚

❌ 反例：每次遇到才臨時糾正

（AI 連線失敗，下結論走不通）
使用者：不對，多試幾次
（下一次協作，AI 又在另一個情境下遇到失敗就下結論）
使用者：一樣用 ssh 接著做啊！又不是連不上

同樣的糾正說了不只一次，因為規則從來沒有被明確寫下來，只存在於當下的對話裡，換一個情境、換一次協作，又要重新講一次。

✅ 正例：把規則寫進協作開始前就講清楚的前提條件

基本規則：遇到連線/網路類的失敗，不能單次失敗就下結論「走不通」。
至少要用不同方式重試 3 次以上，仍然失敗才能回報「無法連線」，
並且要附上已經試過哪幾種方式的紀錄。

這條規則該包含的具體要素

一條有效的規則，至少要講清楚三件事：觸發情境（什麼樣的失敗算數）、門檻（要試到什麼程度才能下結論）、回報方式（下結論時要附上什麼證據）。少了任何一項，規則還是會留下模糊地帶——例如只講「要多試幾次」而沒講清楚「幾次」跟「換哪些方式試」，AI 還是得自己猜測門檻在哪裡，跟完全沒有規則時的處境沒有本質上的差別。

為什麼「一句話」很重要

規則不需要寫得又長又複雜，但要具體到可以被直接套用。這正是這個系列強調「把糾正變成規則」而不是「把糾正變成長篇說明」的原因——一條清楚的前提條件，比十次事後糾正更有效率，因為它只需要被講一次，就能套用在所有符合觸發情境的未來場景。

今日思考題

回想你重複糾正過的某一件事，如果要把它寫成一句前提條件，觸發情境、門檻、回報方式這三個要素，你會怎麼寫？

今日重點回顧

• 把反覆糾正轉換成規則，是從「事後介入」變成「事先講清楚」的關鍵一步
• 一條有效的規則要包含：觸發情境、門檻、回報方式
• 規則不需要長，但要具體到可以被直接套用，這比重複糾正更有效率

明日預告

明天講另一條規則：授權範圍要包含「怎麼驗證」，不是只有「做什麼」。