AI agent 執行完之後，最常的檢查做法是檢查它的結果有沒有做正確：ticket (例如 Trello card) 最後變成什麼樣子、有疑慮的 AC 有沒有被標出來，但是它中間查了幾次網路上的資料、呼叫了哪些工具、存取過哪些 codebase，這些時常會被忽略。

昨天提的兩個例子都是壞在同一件事：沒有一個「正確的模樣」可以拿來比。而要寫得出那個「正確的模樣」，得先弄清楚這隻 agent 的輸入是什麼、它可以改動什麼、輸出該有哪些資訊。

那 AI 該做什麼，不該做什麼？

之前碰過一個狀況：需求方為了加快流程，用 AI 一口氣開了 20 幾張 ticket 放到 Trello Board，還附上 AI 做的 mockup html，想讓 developer 更清楚需求，乍看之下跟平常在 Teams 或 Slack 私訊丟來的一行文的需求相比，好像可以馬上實作？

但是實際打開一張 ticket 來看，ticket 內文少則 500 行，多的可以到 2000 行，內文也被 AI 寫的非常冗長，難以閱讀確認需求。

想說都有 AC 了，那就讓 AI 直接做做看，如果是 grill me 這類 skill、被自己的 AI 一路追問下去，會發現：

• AC 1 和 AC 3 衝突
• mockup 和 AC 衝突
• 有幾條 AC 根本沒寫怎樣算做完

假如是讓 AI 全自動開發，結果做出來的跟預期不符、bug 一堆的功能。

需求方是怎麼用 AI 的 —— 可能只丟一句話，或是產完 mockup 後簡單看過。工程師以為需求方看過自己列的需求，mockup 跟 AC 對不上就進了開發，到了 Demo 當天才發現問題，責任很難釐清。

所以要做的是哪一隻 agent？

所以這 30 天要做的，是一隻需求釐清 agent，專門接上面那種卡：把需求方寫的原始 ticket 讀進去，像 PM 整理過一樣轉成結構化的 ticket，並標出 AC 裡有問題的那幾條。

「有問題」指三類：

• 彼此衝突
• 無法驗證
• 與描述不符

判斷的結果會掛回那一條 AC 上，後面一律叫它標註（flag）：一條 AC 中幾類問題就掛幾個標註，所以標註的數量會比有問題的 AC 條數多。

它手上 7 個工具：4 個只對外查資料，3 個會把結果寫回卡上。

一張雜亂的 ticket 長什麼樣子？

name: 優惠碼功能
description:
  業務下週要跑活動，所以要有優惠碼。輸入代碼價格會變，後台要能新增，
  注意不要被亂用。之前客戶反應結帳頁很慢，順便看一下。手機上也要能用。
AC:
  1. 使用者輸入優惠碼後看到折扣後金額
  2. 優惠碼一人只能用一次
  3. 優惠碼可以無限次使用
  4. 結帳流程要順
  5. 後台可以設定折扣百分比或固定金額
  6. 活動結束後過期的碼不能用，但已套用的訂單不受影響
  7. 手機版體驗要好

這種卡每個人都收過：Goal 跟 Scope 混在一句話裡，「順便看一下」又塞進第二件事。

這張卡丟進去，它會做哪幾件事？

整條路是這樣的：

四步各自有一件圖上看不出來的事：

• 拆 description 拆的是身分：哪句講目標、哪句畫範圍、哪句其實是其他 ticket 的事。
• 補背景 要查到什麼程度由 agent 當下決定。優惠碼是不是已經做了一半，description 不會寫，它得去 repo 跟 DB 裡找。跟純文字整理器的差別就在這裡：查什麼、查幾次沒有寫死在流程裡。
• 逐條檢查 AC 是 21 次獨立判斷，不是一次整體印象 —— 7 條 AC，每條對三類問題各判斷檢查一次。
• 寫回去 的三個工具裡有兩個收不回：覆寫掉需求方寫的那 7 條 AC（replace_acceptance_criteria），對方明天開會才發現不見了；tag 了人（post_comment），通知送出就已經被看到。只有 update_ticket 可以重寫。

出來的東西該長什麼樣？

Goal:   活動期間可用的優惠碼，前台可套用、後台可建立
Scope:  in  — 優惠碼套用、後台建立、過期處理
        out — 結帳頁效能（description 順便提到，屬於另一張卡）
AC 標註:
  3. 優惠碼可以無限次使用   → 彼此衝突（與 2）、與描述不符（description 說不要被亂用）
  4. 結帳流程要順           → 不可驗證
  7. 手機版體驗要好         → 不可驗證

上面這張不是 agent 跑出來的輸出，是我寫的一份答案：這張卡整理完該長這樣。順序是刻意的 —— 先確定「該長什麼樣」，才問得出「它做到了沒有」。 反過來做，就變成看它產出什麼、再回頭說那就是對的。

同一張 ticket，人來檢查會找出幾個問題？

這張卡先由人檢查一遍，第一遍抓出 3 條有問題（第 3、4、7 條），一共 3 個標註。第二遍回頭讀 description 才發現，第 3 條除了跟第 2 條打架，也違背 description 裡「不要被亂用」—— 同一條 AC 同時中兩類，標註從 3 個變 4 個。

第 3 條身上因此掛了兩條線：

漏掉的那筆會怎麼走下去？第 2、3 條都留在卡上進了到開發，工程師照兩條打架的 AC 各做一半：前台限一次、後台不設限。review 一條條對都對得上，PR 就過了。活動開跑後有人拿同一組碼刷十次，才有人問「到底算哪一條」—— 那時要改的不是程式，是需求。

由真人來檢查，不確定的地方還可以反思，但是 agent 一次跑完不會回頭確認。

昨天提到的三個問題變得更具體了：案例是我挑的；算對的標準是我寫的，還沒說清楚憑什麼算對；下次改動要拿什麼跟這次比，手上仍然沒有東西。但今天多了三件釘得住的事：輸入是什麼、它可以改動什麼、輸出該有哪些欄位，有了這三件，「它有沒有壞」才有依據。

明天試試只改 agent 的一行 prompt，然後把同一張 ticket 再送進去一次 —— 它的運作方式整個會變，不會有人注意到它其實有問題。