過去一個月，我把整套個人開發流程改成 agent 驅動。下面是目前的狀態，與一個還沒解完的問題。

Agent 架構

7 個 orchestrator skills、18 個 agents、23 個 utility skills,透過 MCP 與 Gitea、YouTrack、Kubernetes 整合。

三層架構：

  • Planning：把模糊需求拆成模組、再拆成 lane-level issue
  • Orchestrator：驅動「issue → 派工 → PR → merge」迴圈,最多 5 輪
  • Specialist：按技術棧切分（前端、後端、infra、docs、PR review 等）,在獨立 worktree 實作

流程

人類給幾行簡易的功能模組描述,剩下的事 agent 接手:

planner 改寫規格 → orchestrator 派工 → designer 出 mockup → coder 實作 → reviewer 跑規格整合檢查 → resolver 處理改動 → merge

最近一次產出的速度

這個 epic 的目標是 WebRTC 視訊會議的基礎實作——視訊框、對話框、房間管理。

11 個 issue,從規格到 13 個 PR 全數 merge,總時間 3 小時 28 分鐘,產出 10,224 行 code,平均約 49 行 / 分鐘。

成品:https://lnkd.in/gYpdhEYD

速度看起來很快,但成品仍有不少地方需要修正。能做到的,是把骨幹立起來。

目前的限制

以這個 Meeting 專案為例,我只給了 5 到 10 行的功能簡述,agent 確實把功能做出來了。但在模組之間的銜接、畫面之間的過渡這些「規格沒明寫的部分」,agent 一律自由發揮——而那個發揮的結果,跟我心中真正想要的成品有不小的距離。

最後我仍然花了 1 到 2 小時手動處理需求變更與 bug 修正,才把這個 PoC 收到一定的完整度。

問題不在 agent 寫不出 code,而在它沒辦法通靈——那些沒寫進規格的細節,例如對話框顏色跟背景太接近、Blazor 互動性的小問題,agent 抓不到。

這些東西人類工程師可以邊做邊看,邊看邊改,因為他們知道「看起來應該像什麼」。但 agent 沒有這個過程,只能照規格走。

另一個層面是 context 與規則的問題。

context 有上限,當塞到滿,前面講過的東西就會被擠掉。每個新 session 起來,agent 也不一定會讀到上次的脈絡——上次怎麼裝某個工具、上次踩過哪個坑、上次選定了哪個方案,都有機會被遺忘。結果就是有時候會失敗、有時候會錯選工具。

更麻煩的是規則本身。即使你把所有規範用自然語言寫下來,agent 仍然有機會繞過、或選擇性遺忘——它會找到一個聽起來合理的解釋,讓自己跳過某條規則。

這代表你必須花時間把「環境的隱性知識」寫成顯性文件,並且把重要的規則做成不留商量空間的硬性檢查。否則每一次都會從零開始,變貴、變慢,產出也不穩定。

下一步

規格寫越清楚,產出越接近預期,這沒例外。但要寫多細才夠?沒答案。寫太少 agent 自由發揮,寫太多人類就把該省的時間花掉了。

中間有兩條路:讓 agent 遇到沒寫到的就先問再做,或讓 agent 自己 QA 把問題抓出來。但這兩條都會吃更多 token,而且都還需要把更多使用案例寫清楚。

整套流程怎麼平衡,目前還在嘗試。這一步本身就花了不少時間。

結論

agent 確實提升了效率,甚至取代了寫程式碼這整個過程。但走到最後,會發現問題還是回到那些工程上的老問題——規格、邊界、規則、溝通。

怎麼寫一份完整的開發規格?怎麼建構與分派 agent 的職責與邊界?怎麼用自然語言描述一個規則,又不留模糊地帶?角色與角色之間,輸入輸出的規範該怎麼定?

這些問題本來就是團隊運作要解決的——角色怎麼分、規範怎麼定、訊息怎麼傳。以前靠人的默契還能撐,agent 接手後就撐不住了,因為 agent 不會默契,只會照規則走。

換句話說,agent 處理掉的只是「實作」這一環,其他的環節反而更需要被明確寫下來。

工具換了,但工程的本質沒換。

過去這些議題常常因為時程或成本被犧牲掉——「先動手再說」、「之後再補文件」、「先讓功能跑起來」。AI 出現後,這些被擠到後面的事,反而被拉回了最該被處理的位置。