逆向索引

正在發生這種狀況 → 該怎麼做

不是依標題查找，而是依症狀查找。點選「該怎麼做」下方的連結，就能跳到寫著具體做法的那一節。連載文章列表在這個頁面的下方（不屬於逆向索引）。

本表以 Claude Code（Anthropic 的程式設計代理）為前提。hook、CLAUDE.md、subagent、auto memory 都是它的功能名稱。

出問題時，由人輸入的一句話

「請清空所有 todo。查看 https://typing-tube.net/articles/zh-TW/lookup.md，回顧本次工作階段，檢查是否有問題。」

這裡得到的只是問題清單。怎麼修，請依你自己的專案決定。

以 markdown 格式開啟建議的做法是依自己的專案重新做一份。重新做的表可以自由使用，不必標示出處。原樣使用的行，哪怕只有一行，也屬於 CC BY 4.0 的範圍，標示出處是條件。這樣後續的負責人能追溯來源。交給 AI 時，不要貼上表格，而是用上面那句話把 URL 交給它。

贊助商

正在發生這種狀況	因應方案
No.1 AI 每次執行測試，都會有數萬行輸出湧入上下文	因應範例：把測試執行整合進 wrapper，只把失敗摘要回傳給 AI。読まない技術第1回：テスト結果を読まない技術
No.2 AI 儲存的知識筆記越多，之後每個工作階段要讀的量就越大	因應範例：寫入 memory 前先讀檢查清單，常讀檔案裡只留 1 行。読まない技術第2回：メモリを読まない技術
No.3 測試都通過了，但不知道它們是不是真的有在保護什麼	因應範例：指示 AI 執行 mutation testing。読まない技術第3回：単体テストを読まない技術
No.4 註冊好的 skill，AI 有時候會用、有時候不會用	因應範例：在入口擋下錯誤的呼叫方式，並指向該讀的文件。読まない技術第4回：スキルを使わない技術
No.5 交給 sub-agent 的工作，在完成之前看不到裡面發生了什麼	因應範例：把可委派的工作列成清單，啟動前用 hook 確認。読まない技術第5回：サブエージェントの出力だけは読め
No.6 指示檔案裡規則加得越多，先前加的規則就越沒被遵守	因應範例：把每條「不要做」逐條改寫成能偵測違規的自動測試。読まない技術第6回：ルールを読まない技術
No.7 並行執行的多個工作階段共用的 memory 變得雜亂，就算讓它讀方針也沒用	因應範例：內容不變，只把出現時機改成儲存後立即顯示。読まない技術第7回：共有メモリを整理しない技術
No.8 就算寫好同一種失敗的處理方式，AI 下次還是會犯同樣的錯	因應範例：偵測到失敗的當下，自動插入重試方針。読まない技術第8回：修正履歴を読まない技術
No.9 讀了交接說明和完成報告，對自己不利的部分還是被漏掉了	因應範例：完成報告旁邊，每次都附上機器算出的數字。読まない技術第9回：引き継ぎを読まない技術
No.10 機器算出來的數字，傳到報告時已經變成另一個數字	因應範例：在數字那一行加上固定前綴，用 hook 檢查是否逐字複製。読まない技術第10回：AIに要約しろと言わない技術
No.11 在 AI 工作中插話，之後的動作就會亂掉	因應範例：工作中不插話，等到段落結束。插話交給機制處理。読まない技術第11回：口を挟まない技術
No.12 工作階段結束時，該讀什麼、不用讀什麼並沒有定下來	因應範例：不讀成果物也不讀作業紀錄，只看 exit code 判斷合否。読まない技術第12回：作業結果を読まない技術
No.13 已經回絕過的提案，在下一個工作階段又被提出來	因應範例：把回絕的判斷集中進一份文件。 AIの意見を聞かない技術第1回：提案を検討しない技術
No.14 明明寫了一行禁止事項，卻還是被過度解讀或過度限縮解讀	因應範例：每條禁止事項都在結論旁寫上「理由」。 AIの意見を聞かない技術第2回：禁止を書かない技術
No.15 禁止事項明明寫得沒錯卻沒被遵守，每次都要被問一次	因應範例：每條禁止事項寫「適用範圍」，逐行列出容易判斷不清的邊界。 AIの意見を聞かない技術第3回：禁止ルールを作らない技術
No.16 把同一份指示分給多個 sub-agent，回來的格式卻各不相同	因應範例：在可交辦工作清單裡，明列啟動前需要的輸入。 AIの意見を聞かない技術第4回：サブエージェントの入力だけは、確かめろ
No.17 沒有自動化測試的禁止事項，只是寫在那裡不斷堆積	因應範例：每條禁止事項都標明是否有對應的自動測試。 AIの意見を聞かない技術第5回：自動テストを書かない技術
No.18 AI 的工作每次都以「請打開畫面確認一下」收尾	因應範例：合否不看畫面外觀，而是看留下的資料判定。 AIの意見を聞かない技術第6回：AIの確認依頼を断る技術
No.19 AI 每次講得有點偏，都要自己解釋再糾正	因應範例：不由人解釋糾正，改用 hook 和測試失敗訊息回應。 AIの意見を聞かない技術第7回：AIの話を聞かない技術
No.20 回絕過的判斷清單不斷變長，眼看就要沒人再讀了	因應範例：把回絕的提案送進文件末尾的「未採用方案」。 AIの意見を聞かない技術第8回：ルールを整理しない技術
No.21 指示檔案裡「請務必執行」的項目一直堆在那裡，沒有變少	因應範例：比對指示檔案裡「務必執行」的指令，是否也存在於機制中。言わない技術第1回：検証を指示しない技術
No.22 連做法都寫清楚交出去了，結果改回來的還是不一樣	因應範例：不指示步驟，只決定開始前需要的輸入。言わない技術第2回：具体的な指示を出さない技術
No.23 每次回報 bug，都要自己把重現步驟和症狀重新寫一遍	因應範例：人只寫一句症狀，其餘自動收集。言わない技術第3回：不具合詳細を書かない技術
No.24 每次都要花力氣打一句「先給我計畫」	因應範例：放一份設計文件，AI 就會沿用它的格式。言わない技術第4回：計画を書けと言わない技術
No.25 越希望被遵守的內容寫得越強調，卻不知道有沒有效果	因應範例：不再測量效果，改數強調用語的行數並設上限。言わない技術第5回：念を押さない技術
No.26 sub-agent 交回來的成果，格式跟原本預想的不一樣	因應範例：交辦工作前先決定成果物的驗收條件。言わない技術第6回：サブエージェントの出力だけは、細かく指示しろ
No.27 發現錯誤時，忍不住想追問「你真的有讀過嗎」	因應範例：不追問，改用「……不是嗎？」的疑問句。言わない技術第7回：AI を問い詰めない技術
No.28 對回來的答案回一句「不是這個意思」，情況也不會變好	因應範例：不由人指出，儲存後立即連同 diff 顯示禁止事項。言わない技術第8回：AI にダメ出ししない技術
No.29 AI 會像打開過某個檔案一樣，講述它其實沒打開過的內容	因應範例：讓參照處和實作兩邊都寫上相同的識別碼，再用自動測試檢查該識別碼是否存在。言わない技術第9回：AI に考えさせない技術
No.30 AI 不斷問「要選 A 還是 B」，手上的工作就停下來了	因應範例：不當場回答，讓判斷基準交給機制決定。言わない技術第10回：質問に答えない技術
No.31 讓 AI 做 review，但不知道它到底沒看到什麼	因應範例：從外部找出走訪檔案卻沒有替筆數設下限的自動測試。言わない技術第11回：AI にレビューをさせない技術
No.32 截圖越存越多，卻分不清哪一張驗證了什麼	因應範例：拍攝前先寫「要驗證什麼」，並從便宜的做法先試起。確かめない技術第1回：スクリーンショットを撮らない技術
No.33 設了要求先寫聲明的步驟，卻數不出有多少次執行是沒寫聲明就直接跑的	因應範例：截圖或 E2E 前要求先寫「要驗證什麼」，沒寫就不執行。確かめない技術第2回：宣言を信じない技術
No.34 程式碼明明沒有改動，同一批測試卻又跑了一次，白白多等	因應範例：讓上一次的日誌可以重讀，不必重複執行相同測試。確かめない技術第3回：テストを再実行しない技術
No.35 什麼都沒弄壞，卻冒出一大串沒看過的錯誤	因應範例：測試執行時取得互斥鎖，拿不到鎖就不執行。確かめない技術第4回：偽の失敗を読まない技術
No.36 「測試都通過了」的報告裡，沒寫出哪些部分根本沒跑	因應範例：耗時測試預設跳過，每次都列出沒執行的範圍。確かめない技術第5回：全部走らせない技術
No.37 指定了進行方式的指示，事後沒辦法判斷有沒有被遵守	因應範例：不加強措辭，讓步驟的痕跡留在成果物裡。動かさない技術第1回：手順を守らせない技術
No.38 設好的 wrapper，用到一半又被換回原始指令	因應範例：不加強措辭，檢查是否還留著改用原始指令的理由。動かさない技術第2回：ラッパーを使わせない技術
No.39 同一個問題問好幾次，每次答案都不一樣，一彙整又漏掉了什麼	因應範例：彙整前，先依指摘種類列出幾件中有幾件提到。動かさない技術第3回：集めない技術
No.40 寫了「如有需要請執行……」這樣的條件式指示，卻不知道有沒有觸發	因應範例：不寫「如有需要」，改成不經過該步驟就無法往下走。動かさない技術第4回：役に立たない技術
No.41 回一句「再想一次」答案就會變，卻不知道它是不是真的想通了	因應範例：不打回重做，具體指出哪個前提錯了。動かさない技術第5回：選び直させない技術
No.42 寫了「不要用猜的」之後，AI 變成什麼都不產出就交回來了	因應範例：不只給禁止事項，一併給「不適用」這樣的退路。動かさない技術第6回：逃げ道を塞がない技術
No.43 順利的對話一直延續下去，需要確認的工作量卻越積越多	因應範例：在段落結束工作階段，下一個任務用新的工作階段開始。動かさない技術第7回：セッションを続けない技術
No.44 成果物全部都正確，但不會留在成果物裡的浪費卻在不斷累積	因應範例：成果物齊全時，對作業紀錄做一次統計。動かさない技術第8回：成果物で判断しない技術
No.45 為後人留下的知識筆記，會跟實際狀況脫節、變得過時	因應範例：不把知見寫進文件，改嵌入中止訊息裡。動かさない技術第9回：知見を残さない技術
No.46 一直挖下去找原因，答案出來之後還在繼續讀	因應範例：數清楚沒改動任何東西的連續讀取，並在深挖前寫下結束條件。追わない技術第1回：深追いしない技術
No.47 沒有評估用途，就把單價最便宜的模型當成預設選項	因應範例：同一課題交給便宜和昂貴兩邊的模型，數清楚來回和用量再決定。追わない技術第2回：一番安いモデルを使わない技術
No.48 一旦不順利，想到的不是改善機制，而是換更高階的模型	因應範例：同一課題交給兩邊的模型，把便宜那邊沒過的地方做成自動測試。追わない技術第3回：最新モデルを使わない技術
No.49 本體自己就能查完的東西，卻為了保險起見交給 sub-agent	因應範例：父 agent 已有的前提不交辦，只交出它沒有的讀取部分。追わない技術第4回：サブエージェントを使わない技術
No.50 不假思索就分成 4 份，同時跑起來	因應範例：交給 sub-agent 的量只到一次回覆能回傳的大小。決定成本的是往返次數，不是數量。追わない技術第5回：エージェントチームを使わない技術
No.53 作業進行到一半，就從外部插入「這裡也看一下」的要求	因應範例：等到段落結束，縮小範圍再提出要求。並附上「如果已經足夠，請寫明已經足夠」。追わない技術第6回：途中でレビューさせない技術
No.52 想靠比較來決定要用哪個模型	因應範例：開始比較前，先數清楚這次比較值幾個機制的工夫。追わない技術第7回：モデルを選ばない技術
No.51 用一句「沒有差異」就想收掉驗證	因應範例：收掉之前，重新數清楚被排除在統計外的結果，以及所有條件都是 0 的項目。追わない技術第8回：諦めさせない技術
No.54 某一天起 AI 的做法變了，而你既沒改指令也沒改設定	因應範例：不寫與產品端指令衝突的內容，只補充它沒規定的部分。想改變做法時就切換設定。番外編 A-7 読まれたかを確かめる技術 —— 確かめるのをやめて、読めていない形を止めた

連載文章列表

從這裡往下不屬於逆向索引，而是各篇連載文章的連結。依連載排列，從序論到最終回。

正在發生這種狀況 → 該怎麼做

連載文章列表

はじめに —— 3 つの連載を、1 冊に

バイブコーディングにおける読まない技術

AIの意見を聞かない技術

言わない技術

付録

はじめに —— 前巻の続きを、もう 1 冊に

確かめない技術

動かさない技術

追わない技術

番外編