智能體軟體工程｜別再用人類的尺量 AI 的活：智能體原生工作估算

《智能體軟體工程》可能是一系列文章，記錄我從傳統軟體工程向智能體軟體工程的遷移過程。

一個老工程師的頓悟

我寫了快二十年程式碼了。估算工時這件事，早已刻進肌肉記憶——拆解任務、排列優先順序、乘以經驗係數、加上聯調與 Buffer（緩衝量），最後給出一個「兩到三週」。這套方法論伴隨我度過了瀑布式、敏捷開發、DevOps 的每一次典範轉移，從不失靈。

直到 AI 編程到來。

我最近用 AI Agent 實作了一個 CLI 工具。腦海中的第一反應是這個工具的實作過程：解析參數、核心轉換、驗證邏輯、錯誤處理、測試，一整套下來，按古法編程怎麼也得兩三天。結果 Agent 從動手到交付，連半小時都沒用完。

效率提升了嗎？表面上看，當然。

但更深層的問題隨之浮現：我甚至無法正確預判 AI 需要多久。

我的整個估算框架是錨定在「人類開發者」這個基座上的。多少行程式碼、多少次 Debug、多少輪 Code Review。當執行者從人變成智能體，這把尺就徹底失靈了。

更諷刺的是，AI Agent 自己也犯同樣的錯。你問 Claude 或 GPT：「做這個功能要多久？」它會一本正經地告訴你「大約 2-3 天」。因為它的訓練數據裡，Stack Overflow 和技術部落格就是這麼寫的。Agent 在用人類的經驗估人類的時間，然後自己十分鐘幹完。

我開始意識到，當軟體工程邁向智能體軟體工程（Agentic Software Engineering）的過程中，第一個需要改變的，就是這種「拿人的尺量 AI 的活」的心態。

所以我寫了一個 Skill，agent-estimation^[1]，專門解決這個問題。

問題根源：人類時間錨定

我把這個現象叫做Human-Time Anchoring（人類時間錨定）。

它的運作機制是這樣的：

AI Agent 在生成估算時，會不自觉地調用訓練數據中的「集體經驗」。一個 REST API 專案？論壇上說要一週。一個帶即時圖表的全端 Dashboard？技術負責人在 Sprint Planning 裡估了三個迭代。這些數字是人類開發者在人類的認知帶寬、上下文切換成本、溝通損耗下產出的經驗值。它們對人類成立，但對一個可以每 3 分鐘完成一輪「思考→寫碼→執行→驗證→修復」循環的 Agent 來說，完全不適用。

這導致了一個系統性偏差：AI 幾乎總是高估自己的工時。

而我們這些老工程師，反過來也在犯同樣的錯：我們拿自己過去的經驗去預期 AI 的產出速度，然後在「哇，這麼快？」和「等等，它真能做到嗎？」之間反覆橫跳。

問題不在於 AI 編碼快不快。問題在於：我們還沒有一套AI 原生的度量體系來衡量它到底有多快，以及哪些地方其實沒那麼快。

一種解法：讓 Agent 用自己的單位思考

我設計的這個 Skill（Agent Work Estimation Skill），核心思路只有一句話：

先用輪次（Round）估算，最後才轉換成人類時間。

這裡的「輪次」是 Agent 的原子操作單位——一個完整的工具調用循環：思考 → 編寫程式碼 → 執行 → 查看輸出 → 決定是否修復

一輪大約 2-4 分鐘。這不是拍腦袋的數字，而是實際觀察 AI Coding Agent 在真實專案中的運行節奏得出的經驗值。

在這個基礎上，我定義了四層估算單位：

單一 Agent 順序編碼用「輪次」，多 Agent 並發編碼用「波次」。這就是AI Native 的估算方式。

五步估算法

第一步：拆解模組

把任務分成可以獨立構建和測試的功能模組。核心問題是：「如果我一次只做一件事，我會按什麼順序做？」

第二步：估算每個模組的輪次

這裡有一組校準錨點：

關鍵的校準規則很直覺：如果 Agent 一次生成就能跑通，那就是 1 輪；如果要生成、報錯、修復，那就是 2-3 輪；如果函式庫的文件稀爛需要靠猜，那就是 5 輪起步。

第三步：加風險係數

第四步：計算總量

順序模式：模組有效輪次 = 基礎輪次 × 風險係數
專案輪次 = Σ(模組有效輪次) + 整合輪次（基礎總量的 10-20%）

波次模式（多 Agent 並發）：波次耗時 = 波內模組的最大有效輪次
專案輪次 = Σ(波次耗時) + 協調輪次 + 整合輪次

第五步：最後才轉換為人類時間

預設每輪 3 分鐘。但這個參數可調——快速迭代可以用 2 分鐘，需要使用者手動測試的場景可以用 5 分鐘。

重點是：人類時間是輸出，不是輸入。整個推理鏈條裡沒有「一個開發者大概需要……」這種話。

實戰校準：三個尺度的對照

小專案示例：CLI JSON-to-YAML 轉換器（約 8 輪）

總計 8 輪，約 24 分鐘。如果按人類經驗估，你會說「一天」，甚至「兩天」。

中型專案示例：桌面鍵盤廣播器（約 36 輪）

一台 Mac 鍵盤控制 27 台裝置，涉及 HTTP/WebSocket 服務、Makepad UI、macOS CGEvent 鍵盤擷取、QR Code 生成等模組。

順序執行：約 108 分鐘（1.5-2 小時）。

如果用 3 個 Agent 並行的波次模式：

• Wave 1：HTTP 服務、QR Code、手機端（無依賴，並行）→ 3 輪
• Wave 2：主 UI、客戶端管理、分類過濾 → 10 輪
• Wave 3：鍵盤擷取 → 8 輪
• 整合 → 5 輪
• 協調開銷 → 3 輪

並行時間約 57 分鐘，比順序快 47%。按人類經驗？你大概會估「兩到三週」。

大型專案示例：全端即時 Dashboard（約 63 輪）

React 前端 + Rust 後端 + WebSocket 串流推送 + 圖表元件 + 認證。

順序執行約 189 分鐘（3-3.5 小時）。三 Agent 並行約 108 分鐘。

人類估時？「三個月」不算誇張。

六個必須避免的反模式

這些是這個 Skill 存在的根本原因。每一條都是我在實踐中踩過的坑：

1. 人類時間錨定。「一個開發者大概需要兩週」。不。從輪次開始推。

2. 憑感覺加 Buffer。「以防萬一加點餘量」。不。用風險係數，每一分鐘的膨脹都要有理由。

3. 混淆複雜度和程式碼量。500 行模板程式碼不等於難。一行 macOS CGEvent API 也不等於簡單。按不確定性估算，不按行數。

4. 忘記整合成本。模組各自跑通，合在一起就炸。永遠加整合輪次。

5. 忽略使用者側瓶頸。如果使用者需要手動授權、重啟應用程式、在真機上測試——調整每輪分鐘數，別憑空加輪次。

6. 假設並行是免費的。多 Agent 協作有協調成本，合約定義、衝突解決都需要額外輪次。

不只是估算方法，更是思維範式的遷移

寫這個 Skill 的過程中，我越來越覺得，這不僅僅是一個技術問題。

我們正處在一個過渡期。軟體工程的基本假設，「人寫程式碼、人 Debug、人溝通、人做決策」，正在被 Agent 重新定義。但我們的思維慣性還停留在舊範式裡。我們用 Story Point 估算 Agent 的工作量，用 Sprint 規劃 Agent 的迭代週期，用「人天」衡量 Agent 的產出——這就像用馬車的速度去規劃火車的時刻表。

AI Coding 的效率提升並不是簡單的「同樣的事做得更快」。它改變了工作的粒度。人類開發者的原子操作是「一天的編碼」，Agent 的原子操作是「一輪工具調用」。當原子尺度變了，所有建立在舊原子之上的度量體系都需要重建。

同時我們也不能走向另一個極端，盲目樂觀地認為 AI 什麼都能秒殺。macOS 權限 API 的詭異行為、未文件化的框架邊界、跨系統整合的隱式依賴——這些不確定性不會因為執行者是 AI 就消失。風險係數的存在就是為了尊重這個現實。

寫在最後

這個 Skill 是開源的，遵循 Agent Skills 開放標準，支援 Claude Code、Cursor、Codex CLI 等主流 Agent。你可以直接安裝：npx skills add ZhangHanDong/agent-estimation

但比安裝一個 Skill 更重要的是：開始練習用 Agent 的視角看問題。

下次你想說「這個功能大概要三天」的時候，停一下。問自己：Agent 做這件事需要幾輪？每輪的不確定性有多高？有哪些模組可以並行？

當你開始這樣思考，你就已經踏入了智能體軟體工程的大門。

這不是 AI 替代人的故事。這是人學會用新的尺量新世界的故事。