不會寫 code 的醫師，怎麼架構一批臨床專案
我不會寫程式，雖然可以開終端機、剪貼指令，但要我從零生一個能運行的東西出來，是完全不行。可是過去一個月，我就任智慧醫療專任醫師，用 AI 寫了一批臨床服務專案，包括去個資、統一向資料庫查詢資料的服務、住院病歷 AI 生成中樞、即時臨床藥師照會…等等。每行 code 都不是我寫的，是一批 AI 代理人(Agents)寫的。
到去年底，寫程式都還要在 AI 的聊天介面把程式碼複製過來貼上，讓人覺得只能小小修改，很難做很大的專案。結果沒想到在年底的時候，Claude 變得越來越厲害，讓頂級的工程師說出「80% 的程式都是 Claude Code 寫的」。我正好在那時密集嘗試，慢慢學會怎麼指揮 AI agent 寫複雜功能的程式。經過了四個月的試作，我慢慢建立了以下的 AI 工作流，可以在睡前把 4-6 個任務釐清後去睡覺，早上起來就都完成了。
整體架構只分兩個階段：
圖裡的 /scope 就是計畫、/execute 就是執行（裡面 runner 寫、reviewer 審、退回最多三次），最外層 /conduct 是下面會講的「指揮者 AI」。
計畫階段
需求進來通常是一句話：「能不能做個東西，讓我查房的時候自動把病人的趨勢整理出來。」這是一句話，不是一個專案。
我先用 AI agent 把它拆成一張一張獨立的票，每張小到能單獨做完、單獨驗、不會卡在另一張還沒做的票上面。
然後對每張票，我問的不是「這要怎麼寫」，是「這裡面哪些決定只有我能拍板，哪些 agent 自己定就好」。資料來源正確不正確、隱私的邊界在哪、某個欄位要不要顯示給醫師看——這些我來。變數叫什麼、用哪個 library、function 怎麼切——agent 來，我管反而管得比它差。
這個區分我會直接寫進規格。每一條驗收標準前面掛一個標籤，[AFK] 或 [HITL]：[AFK](Away from keyboard) 是 agent 自己做、自己驗，做完不用回頭找我；[HITL](Human in the loop) 是要我親自簽名才算數的。哪些是我的決定，就這樣一條一條圈出來。
最後 agent 把這些寫成一份規格，叫它 Agent Brief。重點是「可驗證」——驗收條件要具體到 agent 做完能自己對答案。例如「最後這格會產出 ooxx 資料」可以驗收；「把排程功能加好」不行。
整個計畫階段就這樣，只在 GitHub issue 跟 markdown 裡打轉，一行 code 都沒碰。規格定稿，我這邊大致就告一段落。
執行階段
接下來是把規格變成跑得動的 code。
每張票都從一個乾淨的 context 開始。 同一個 AI 連做好幾張會鈍掉，前面的東西全塞在 context 裡，後面判斷就開始飄（註一）。所以一張票一個新的開始，進行中的狀態寫在一個 state 檔，要接手的讀一下就接得上。
一個寫，一個審，而且用不同的 AI。 寫 code 的（runner）交出來之後，我派另一個（reviewer）去審，兩個刻意用不同模型——Claude 寫的丟給 Codex 審，反過來也一樣。reviewer 我還調成預設找碴，挑不出問題才放行。用不同 AI 是因為同一個模型有同樣的盲點，自己審自己常常看不到。
資訊只能由上往下。 我看得到 runner 跟 reviewer 在幹嘛，但它們看不到我，也看不到對方的全貌。這樣 runner 只能照規格做，不會去猜「他其實是不是想要別的」。
退回最多三次。 reviewer 退回就交回 runner 改，改完再審。但同一張票來回三次還過不了，我就讓它停——通常那代表規格裡有我沒想清楚的東西，這時候該我自己進去看，而不是再叫它試第四次。
一張票收掉，寫個交班，開下一張的新 context。就這樣一張接一張。
指揮者 AI
上面的流程很繁瑣。如果讓一個人坐在電腦前面，他不時就要回來按一下確認，或是把這個指令複製到另一個視窗裡面。
因此，我決定在上面包了一層「指揮者 AI」。它的運作邏輯如下：
- 讀取需求：它會先讀取人類給它的原始需求。
- 釐清任務：在釐清需要處理的部分後，就交給 AI 自行處理。
- 自動化行政：也就是包辦中間繁瑣的行政手續。
如果中間遇到確實需要人類確認的問題，它也會再丟過來給你。
會不會寫 code，好像不是重點
看到這樣可能會發現，會不會寫程式根本不是重點。真正花時間的是把需求講清楚——這點我是從 Matt Pocock 在一個影片中 (https://www.youtube.com/watch?v=v4F1gFy-hqg) 學到的。他說「AI 時代，你更需要知道程式設計的基礎」。但看完影片，我發現到最後，他還是都在講「如何讓 AI 與自己的想法完全同步」，這點讓我也覺得蠻意外的。
這套流程我目前也還在優化，時常修改，但我把裡面最關鍵的細節公開在 GitHub：github.com/liyoungc/LY-workflow。它可以跑在 Claude 或是 Codex，也可以跑在 Windows 或是 Mac；如果你想實驗看看的話，你只要把網址丟給你的 AI，請他幫你安裝。通常要經過一小段時間的測試，才能在自己的環境上成功運作。
（小提醒一下：叫 AI 去安裝網路上別人寫的東西，就算看起來只是文件或設定檔，也都有潛在風險。記得請它別照單全收——先幫你看過、確認這些指示安不安全，再決定要不要動手。）
2026-05-31
註一：AI 模型的上下文(Context window)是有限的，就像人一樣，從早上醒來到晚上，大腦會慢慢變得越來越難用。因此，為了解決這個問題，我讓一個 AI agent 在做自己的工作之後，寫好交班單或更新 GitHub，再透過 Tmux 叫出下一任 AI Agent，把提示詞送過去，確認他正常運作之後再停止。這樣每一個細微的任務，AI 都在腦力最好的階段，不會被前後的上下文干擾。Tmux 的好處在於，在裡面的 AI 可以看得到別的視窗，也可以傳送指令過去，這點方便他們在需要的時候互相協助。