Posted by 
一個人 + 幾個 AI agent = 一支工程團隊。工程師也該學著當當Manager了嗎？被自家的Hermes兇回來可是難得的經驗
我一直覺得 Karpathy 提過的 LLM Wiki 概念，可能是 PKMS 比較合理的答案。不是把知識整理成一套靜態筆記，而是讓 LLM 在需要時自己找出相關內容，組成當下真正需要的 context。
我先試了 Obsidian 的 OLW。它會自動分析、拆解和索引筆記，再在對話時把相關知識片段塞給 LLM。概念是對的，體驗也很好，但它原本只在本機上使用。如果想讓別人也能用，甚至支援多人和不同專案，就得把整套東西搬上雲端。
三個禮拜後，LLM Wiki Cloud誕生了。它支援多租戶和 BYOK，前端是 Next.js on Vercel，後端是 Go on Cloud Run，pipeline worker 透過 GCS FUSE 處理檔案，資料面則用 Firestore 和 GCS。從 infra、i18n、admin portal 到 rate limiting，幾乎都是我一個人和 AI 協作完成的。
現在可以到 wiki.rayer.idv.tw 點「試用 Demo」。裡面有生活筆記、AI 文件和模擬專業知識庫幾個專案。你可以在生活筆記裡搜尋「台北適合工作的咖啡廳」，再切換 Wiki 模式和完整模式，看看同一個 query 在回答深度和引用方式上有什麼不同。LLM Wiki 的核心不是再做一個聊天機器人，而是讓 LLM 先讀你的知識，再回答問題，而且能告訴你答案是從哪些條目來的。
產品還沒正式開放，還有一些東西要修。不過這篇真正想談的，不是產品功能，而是我後來摸索出來的開發流程：為什麼我不再把一整個需求直接丟給 coding agent，然後滿懷期待地看著它自己做完。
—
一個 Agent 打全部，問題不只是 Context 太長
「其實我腦袋記住的東西，都會反映在你付出的Token Fee帳單喔」
現在很多人的做法是打開 Cursor、Claude Code 或 Codex，用自然語言描述需求，讓 AI 自己讀 code、做設計、修改檔案、跑測試、開 PR。這種方式很爽，我也試過，但後來我放棄讓同一個 agent 同時負責所有事情。
問題通常不在於它寫的 code 能不能跑。多數時候可以。真正麻煩的是，你不知道它有沒有理解這次修改涉及的模組 contract，有沒有忽略某條隱含資料流，選的方案是不是超出產品真正需要的範圍。更麻煩的是，它寫的測試可能只是驗證自己對需求的理解，而不是驗證需求本身。
單一 agent 同時扮演 architect、PM、developer 和 reviewer，意味著它不只要理解 codebase，還要記得產品需求、測試方式、PR 規則、部署限制和各種隱含約定。Context 一大，重要訊息就很容易被埋掉。最後人類還是不敢不逐行看，等於 coding agent 加快了輸出速度，卻沒有真正降低理解和驗證成本。
有人會說，這可以用 sub-agent 解決。把大任務拆成小任務，交給不同 sub-agent，各自只讀一部分 context，當然比一個 agent 從頭扛到尾好。但我覺得這還不算真正的責任分離。
一方面，單一 coding-agent 平台內建的 sub-agent，通常仍受限於同一供應商提供的模型選項。就算設定不同，它們的錯誤模式仍可能高度相關。這不是說同一家族的模型一定會犯一模一樣的錯，而是多個 sub-agent 得出一致結論，不能直接視為獨立驗證。
另一方面，即使工具有保留 sub-agent 的執行紀錄，那些內容通常還是某次 session 裡的對話。真正出問題時，我需要的不是幾萬字 transcript，而是能快速回頭看懂：當初判斷的 root cause 是什麼、為什麼選這個方案、哪些替代方案被放棄、驗收條件是什麼。
所以我的做法不是讓 agent 彼此一直聊天，而是要求它們把結論寫進 ticket。
不是 agent 跟 agent 對話，是 agent 跟票對話。我說啊，會議都有紀要，總不能純對話聊天，然後明天就忘光光了吧？
—
AI降低了成本… 以極低的薪水幫你找隊友
「阿不就AI Agent不適用勞基法」 — 某次AI對話的吐槽… 我家Hermes被我養得怪怪的
目前我的流程有幾個明確角色：
我（Rayer） ↕ 討論產品方向、架構與 priority Hermes（TPM + Orchestrator） ↕ 分析問題、整理 spec、開票、dispatch Coding Agent（Codex / Grok Build） ↕ 讀 spec、列 plan、寫測試、實作、開 PR YouTrack + Git repository ↕ 保存任務 context、長期規則與執行紀錄
PR review 階段，我通常還會再找另一個模型家族的 build agent來當吃瓜群眾Reviewer，提供一個比較獨立的觀點。
我的工作不是每次都逐行 review 所有 code，而是守住產品方向、架構邊界和高風險區域。小範圍 UI 調整或局部純函數，我主要看方向、測試和輸出；跨模組行為要看 contract 和 side effect；auth、權限、資料遷移、infra 這種東西，我還是會深入看。責任分離不是讓人類不 review，而是讓人類把注意力用在真正危險的地方。
Hermes 扮演的 TPM 也不是傳統上只整理需求的 PM。它必須能讀 codebase、定位問題、理解跨模組影響，並把問題整理成 coding agent 能執行的 ticket。它不需要親自寫 production code，但至少要先回答：root cause 是什麼、在哪個檔案和函數發生、什麼條件會觸發、fix 要怎麼做、可能影響哪些模組、哪些回歸測試一定要跑。
這些結論會寫進 YouTrack。理想上，一張票要詳細到讓 coding agent 不必重新理解整個產品歷史，但也不能把全專案所有資訊都複製進去。
後來我把 context 分成三層。長期穩定的東西，例如架構、模組邊界、API contract、安全規則、logging convention 和 ADR，留在 repo；當前任務的 root cause、scope、fix plan、acceptance criteria 和測試大綱，放在 ticket；實作完成後的 PR、測試結果、review concern 和未解問題，則留在 PR 和 ticket comment。
所以更準確地說，不是「所有 context 都在票上」，而是穩定規則留在 repo，任務決策留在 ticket，執行證據留在 PR 和 comment。
—
一個「重整頁面就被登出」的例子
有一張票的症狀是：使用者在頁面上按重新整理，就被強制登出。
第一眼看起來很像 auth token 過期。但 TPM 後來拆出了兩個彼此獨立的 root cause。
這就像天花板漏水。你以為只有樓上水管裂了，修完卻還是漏，因為排水孔同時也堵住。兩個問題各自獨立，但最後呈現的是同一個症狀。
第一個 root cause 在 API 層：token refresh 失敗時，不管原因是網路瞬斷、cookie 過期還是後端 500，前端一律當成「使用者未授權」，直接強制登出。
第二個 root cause 在頁面初始化：localStorage 裡明明已有可用 token，頁面載入時卻還是強制 refresh；只要這次 refresh 回傳 401，連原本可用的 token 也會一起被清掉。
兩個 root cause 都可能把使用者踢出去。只修其中一個，問題還是可能重現。
TPM 的工作不是在票上寫一句「修 auth refresh」，而是把兩條路徑拆開，說清楚各自在哪裡發生、觸發條件是什麼、哪些錯誤應該登出、哪些不應該，以及每一條路徑要怎麼驗證。Coding agent 不需要重新推導整個 auth flow 的歷史，但仍然要理解這次修改涉及的 contract。
—
Coding Agent 專心做個無情的寫code機器
…像極了愛情，不對，像極了我那加班寫Code的同事
我的 coding agent 會安裝 Superpowers。本文寫的是我當時使用的 v6 流程，大致是先讀 ticket 和 repo instructions，列 implementation plan，根據 acceptance criteria 寫測試，再實作、跑測試、開 PR，最後把 PR link、測試結果和 concern 寫回 ticket。
這裡的重點不是讓 coding agent 變笨，而是把它的能力集中在一個受控範圍內。每張票 scope 越清楚，它越不需要反覆載入無關的專案歷史，也比較不容易讓錯誤假設一路滾到後面的功能。
但有測試不代表一定正確。同一個 agent 可能先誤解 spec，再按照自己的誤解寫測試，最後寫出一份能通過這些測試的實作。整套流程看起來全綠，卻只是把同一個誤解從頭貫徹到底。
所以關鍵 acceptance case 最好在 coding 前就由 TPM 寫進票裡；高風險功能還需要 reviewer 補 adversarial cases。測試能防止實作偏離已知規則，不能保證規則本身沒有問題。
YouTrack 在這套流程裡，也不只是 issue tracker。每張票是一個相對 self-contained 的 context package：TPM 寫 root cause、fix plan 和驗收條件，coding agent 讀票後實作，再把 PR 和測試結果寫回去，reviewer 的 concern 則留在 PR 或同一張票裡。
Coding agent 做完一張票後，可以把 session context 丟掉。下一個 agent 不需要知道上一段對話說過什麼，只要讀正式紀錄。Context 不再依附在某個 agent 的短期記憶裡，而是變成可以跨 session、跨模型、跨工具使用的工程紀錄。
YouTrack 對小團隊有免費方案，雖然操作邏輯和 Jira 有些差異，但拿來做這種事滿合適的。
—
放心，工程師不會失業，只會繼續熬夜
因為 coding agent 寫了大部分 code，很容易讓人覺得工程師只剩下按按鈕和看 PR。但翻一下 ticket 就會發現，很多關鍵決定都是 LLM 提出方案，我否決，最後換成更簡單的路。
例如登入機制。LLM 一開始提議用 NextAuth。這其實是合理方案，功能完整，支援 OAuth、session management 和 CSRF protection。
但我否決了。有必要現在搞這塊嗎？
一個剛起步的 side project，當時不需要 GitHub 或 Google OAuth，也不需要完整的 session abstraction。我真正需要的只是 email + password，登入後拿 JWT，放進 httpOnly cookie。當然，我也得先忍住「我們弄個Sign in with Apple吧～」這種不切實際的衝動…
最後我們砍掉 NextAuth，改成一個 login page 直接呼叫 BFF 的 /auth/login。少了數百行程式碼、少一個 dependency，也少了一整套當下不需要的 abstraction。NextAuth 不是不好，只是它不值得出現在那個時間點的 scope 裡。
另一個例子是首頁搜尋建議。LLM 看完前端後提議，在搜尋框下面放幾個範例 chip，例如「機器學習」「親子景點」「RAG」。這也是很常見的產品設計。
但 LLM Wiki 不是通用搜尋引擎，每個專案的內容完全不同。在生活筆記裡放「機器學習」這個搜尋建議，這跟你到餐廳門口，門口服務生問你要休息還是住宿一樣令人尷尬。
這個功能顯然要從長計議，YouTrack上的票丟到之後的版本討論怎麼實作。未來比較合理的方向，是讓 worker 從專案實際內容裡抽出三到五個 suggested queries。不是「我們猜你想搜什麼」，而是「你的資料裡有什麼值得問」。
這類決定不是單純的技術能力問題。LLM 很擅長在給定需求後列出可行方案，但工程師真正難以取代的地方，是判斷這件事值不值得做、現在就需要嗎、這個 abstraction 是否超出產品規模、少做一點是不是反而更安全。
當我說 coding agent 不需要包辦所有決策，不是因為 AI 不重要，而是聰明不應該全部堆在執行端。怎麼做是一種能力，值不值得做則是另一種能力。
—
AI 是能力放大器，但不會替你長出經驗
用 prompt 做出一個能動的 demo，現在並不難。難的是 demo 之後。
LLM Wiki Cloud 的每個 concept 都需要 URL。最直覺的做法，是直接用檔名當 slug：
/concepts/台北適合工作的咖啡廳
看起來很乾淨，但檔案一改名，外部連結、書籤和引用就可能失效。
另一個極端是只用 ID：
/concepts/3f7a2b1c
它比較穩定，但完全不可讀。
最後採用的格式是：
/concepts/{id}-{slug}
穩定 ID 負責識別 concept，slug 只負責可讀性。Routing 時以 ID 為主，舊 slug 仍然可以被解析，再重新導向目前的 canonical URL。
真正讓 URL 穩定的，不是 ID 長得像 12-hex，而是持久化的 identity mapping 和 backward-compatible routing policy。只要 ID mapping 不變，檔案改名後，舊 URL 還是可以導向新 URL。
為了做出這個看起來很簡單的決定，我們開了一張 spike ticket，讓 agent 去讀 OLW 約 2476 行的 Python 原始碼，確認 slug 在哪個階段生成、是否唯一、是否穩定；接著討論 URL schema、ID 規則和 slug 更新策略，最後再實作 rebuild-index，維護 id_map.json，並處理 concurrent rebuild 和 GCS 更新。
AI 可以幫你分析原始碼，也可以幫你把 rebuild-index 寫出來，但它不一定會主動提醒你：如果產品活得夠久，使用者會收藏連結，檔案也會改名，所以 slug 不能同時拿來當 identity。這類判斷通常來自你以前真的被 broken URL 搞過，也可以讓你在扮演這個AI Team Leader甚至Manager角色時，自我檢視一下有沒有閃過「喔這個slug改id應該不難吧，叫工程師自己看看怎麼弄」這念頭！
AI 可以放大你的能力，但不會自動補上你沒有建立過的工程直覺。
—
模型個性不同，角色提示不同，脾氣也不同
在 PR review 階段，我通常會再找一個不同模型家族的 build agent 做獨立吃瓜群眾 review。後來我發現，最有資訊量的不是哪個 agent 宣稱自己很有信心，而是不同角色之間是否出現歧異。
如果 TPM 說 OK、coding agent 說 OK，但 reviewer 說有問題，通常表示 spec 或實作有模糊地帶，我就會介入確認。
Reviewer 有時也會提出最後證明不是問題的 concern。這沒有關係。只要意見被寫下來，能和 spec、code、測試結果互相比對，誤會通常可以釐清。這個機制不要求 reviewer 永遠正確，只要求它提供足夠獨立的觀點。
但反過來，TPM、coding agent 和 reviewer 全部說 OK，也不代表程式一定正確。三方可能共同依賴同一份錯誤 spec，或共享某個沒被發現的假設。
所以更準確的說法是：歧異是很強的風險 signal；一致只是基本門檻，不是正確性的證明。最後還是要搭配測試、模組 contract、實際系統行為，以及高風險區域的人工 review。
所以我在某次Code Review被我家的Hermes(背後是最近很夯的GPT5.6 sol)再一次漫長的PR來回跟對照Spec後兇了 — 被指著鼻子說：這個Spec開始就缺了條件，這樣PR來回Review只會浪費時間而已…噢，好喔
—
這套流程還是出過包
Side effect 還是發生過。
有一次 pipeline log 的修改，意外讓 pipeline 的數值壞掉。事後回頭看，不是 coding agent 沒照票做，而是 TPM 在分析階段漏掉了一條隱含資料流。
更麻煩的是，當時 Python pipeline 被迫承擔很多和 Go backend 重疊的邏輯，等於同一件事要在兩種語言裡各維護一套實作。同一種語言裡出現兩份差不多的邏輯已經夠糟，兩種語言各寫一份，世界末日大概也不過如此。
最後我決定把整條 pipeline 從 Python 重寫成 Go，讓共用邏輯回到同一個 codebase。
這次事故也提醒我，ticket 能隔離 task context，卻不會自動發現所有 global invariant。如果某條資料流、架構限制或 ownership 邊界沒有寫進 repo 裡的長期文件，TPM 和 coding agent 都可能在局部看起來合理的情況下做錯事。
所以這套流程不是保證不會出錯，而是讓錯誤發生後比較容易回答：當初知道什麼、漏掉了什麼、是 spec、global context、實作還是 review 出問題，以及下一次應該把規則補在哪一層。
目前也還有其他限制。TPM 和 Orchestrator 現在還是同一個 agent，票量少時問題不大，但如果未來要自己處理依賴、平行排程和升級判斷，可能就需要拆開。Ticket scope 也不可能永遠切得漂亮，有些任務本來就跨模組，硬切得太小，反而可能每張票都局部正確，合起來卻互相衝突。
換模型家族做 reviewer 可以降低錯誤相關性，但也不可能消除共因錯誤。高風險功能仍然需要外部行為測試、正式 contract，甚至人工 threat modeling。
—
回到核心問題：為什麼不直接把需求丟給 Coding Agent？
因為當一個 agent 同時負責 architect、PM、developer 和 reviewer 時，你很難判斷它做不出來，是 spec 有問題，還是執行能力不足；它選的方案，是符合產品需要，還是只是技術上做得到；測試通過，是需求真的被滿足，還是 agent 驗證了自己的誤解。
我現在的流程把責任拆開：產品和架構方向由我負責，問題分析和 task spec 由 TPM 負責，實作和基礎測試由 coding agent 負責，獨立觀點由 reviewer 提供；長期規則放在 repo 和 ADR，任務決策放在 YouTrack，執行證據則留在 PR 和 ticket comment。
Coding agent 不必每次重建完整產品脈絡，但仍然要理解這次修改涉及的 contract。TPM 不必親自完成 production code，但必須能定位問題並定義驗收條件。Reviewer 不必永遠正確，但要提供足夠獨立的觀點。
每個角色都可能犯錯。這套流程的目的不是假設某個 agent 完美，而是讓錯誤在跨越責任邊界時，有機會被看見。
一個人加上一群 AI，確實可以像一支小型工程團隊。但讓它成為團隊的，不是 agent 數量，也不是模型有多聰明，而是責任邊界、正式紀錄，以及最後仍然有人對產品和系統負責。
下一篇，我想再談談：每個角色到底需要多「聰明」，以及哪些角色其實不值得使用最強的模型。
—
Rayer，2026 年 7 月。LLM Wiki Cloud 開發筆記。