AI學習與應用體會系列文章08:一個人加AI等於小型團隊?!
接上文
AI 確實可以令一個人同時處理研究、程式、內容、客服同分析，但佢放大嘅主要係執行能力，唔係自動補齊專業判斷。當產出變得便宜，驗收、協調、保安同責任反而會成為真正瓶頸。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
上一篇講到，筆者將網站內容、圖片、社交媒體、客戶查詢、數據分析同改善測試連成一個循環。當呢套流程開始運作，表面上好似同時做緊產品策劃、資料研究、程式開發、編輯、客服同營運分析。
呢個經驗令筆者開始認真問：一個人加 AI，係咪真係已經等於一隊小型團隊？答案係「某啲工作上接近，但本質上仍然唔一樣」。AI 可以大幅擴闊一個人能夠處理嘅範圍，但一隊成熟團隊提供嘅唔只有產量，仲有經驗、互相挑戰、專業責任、關係同長期判斷。
一個人開始可以同時處理多個角色
以前要建立一個網站或者早期產品，通常要先將工作分俾唔同人：有人做市場研究，有人設計資料結構，有人寫前台同後台，有人測試，有人寫內容，亦有人處理發布、分析同客戶查詢。每一個交接都需要時間，亦可能因為背景資料唔完整而出現落差。
有咗 AI Agent 之後，筆者可以先定義目標同邊界，再將研究、資料清理、程式修改、測試、內容草擬同報告整理分開執行。部分工作可以平行進行，部分可以夜晚排程，第二朝再將結果、錯誤同待決策事項交返俾筆者。
所以，最明顯嘅變化唔係筆者突然學識晒所有專業，而係大量原本會卡住項目嘅中間工作，開始可以由工具協助完成。筆者由逐項親手製作，慢慢轉為定義問題、安排工作、檢查結果同決定下一步。
AI 放大嘅係工作範圍，唔係專業年資
AI 可以喺短時間產生一份介面方案、一段程式、一篇文章或者一份分析，但呢啲輸出唔會自動帶有十年實務經驗。佢可能識得描述資訊保安原則，卻未必知道某個真實系統最容易喺邊個交接位出事；亦可能寫出合格設計文案，但未必理解品牌長期建立出嚟嘅細微語氣。
換句話講，AI 將「有能力嘗試」嘅門檻降得好低，但由第一次可運作版本去到可靠、易維護、符合責任要求嘅系統，中間仍然需要專業判斷。原型成功，唔等於生產環境已經安全；一篇文章通順，亦唔等於事實、法律同品牌風險全部處理好。
| AI 唔係將一個人複製成十個專家，而係將一個人嘅意圖，轉化成多條可以平行執行、可以交付、亦可以驗證嘅工作線。 |
筆者叫 Agent 「做設計師」或者「做工程師」仍然太含糊。較可靠嘅做法，係將每個角色拆成一份有輸入、有輸出、有完成標準嘅工作包。Agent 唔需要扮演一個完整職位，只需要完成當前可驗收嘅部分。
1｜產品與策劃：整理使用者問題、比較選項、寫出決策文件，但優先次序同取捨由人決定。
2｜研究與資料：搜集原始來源、標示日期、清理欄位、列出矛盾同缺口，而唔係直接將網上資料當結論。
3｜開發與測試：修改指定程式、執行測試、提交差異同錯誤紀錄；唔應該未經批准直接改生產系統。
4｜內容與設計：根據 brief 建立草稿、版面同素材版本，再由事實、品牌同可用性標準驗收。
5｜客服與分析：分類查詢、搜尋已批准資料、草擬回覆同整理趨勢，但敏感個案同公開承諾要人工處理。
工作包之間最好用具體 artifacts 交接，例如來源清單、結構化數據、程式差異、測試報告、內容 brief、預覽連結同決策紀錄。咁樣下一個 Agent 讀到嘅唔係一段模糊對話，而係可以核對、重播同保存版本嘅成果。
多個 Agent 唔等於多個獨立專家
用幾個 sub-agents 平行工作，的確可以增加速度，但唔應該將「三個 Agent 都同意」當成三位獨立專家確認。佢哋可能使用同一個模型、同一批資料、相似提示同相同盲點，最後只係將同一個錯誤講咗三次。
真正有價值嘅分工，要令驗證方法不同。例如研究 Agent 提出結論，核對 Agent 就返去開原始文件；程式 Agent 寫功能，測試 Agent 就用預先定義嘅案例同例外輸入挑戰；分析 Agent 計算結果，就由 Python 或 SQL 重做，而唔係再問另一個語言模型「你覺得啱唔啱」。
筆者亦會刻意設置反對角色，要求 Agent 找出最可能失敗嘅假設、遺漏條件同不利證據。不過，反對意見本身仍然只係候選問題，最後要靠來源、測試或者實際觀察判斷。多 Agent 最好被理解成多條工作線，而唔係自動形成一個有真正獨立責任嘅董事會。
一人加 AI 最適合嘅項目有共同特徵
筆者覺得一個人配合 Agent 最有優勢嘅，係學習、概念驗證、早期產品、內部工具，同埋範圍清楚而可以逐步驗收嘅小型營運。呢類項目通常以數碼資料做輸入，輸出亦可以用文件、程式、測試或者數據量度。
當需求未完全確定時，AI 可以快速建立幾個版本，令筆者用較低成本發現問題；當流程已經穩定時，佢又可以處理重複整理、定期報告同例行檢查。兩端都非常有價值：前者加快探索，後者降低日常摩擦。
相反，如果工作涉及生命安全、大額資金、複雜法規、深度保安、多人政治協調、長期客戶關係或者難以逆轉嘅實體操作，就唔應該因為 AI 可以產生一份似樣輸出，而將專業團隊簡化成幾個 prompts。風險愈高，獨立審核、清楚責任同專業資格愈重要。
真正瓶頸由「做唔切」變成「審唔切」
當草稿、程式同分析可以快速產生，項目最容易出現嘅新問題係 review backlog。Agent 一晚可以建立十個方案，但人未必有時間逐個理解；如果筆者只睇最表面嘅結果，產量增加反而可能令錯誤更容易漏過。
所以，每項工作要先定義「完成」係乜。低風險格式轉換，可以用自動規則驗收；程式修改要通過測試同差異檢查；公開內容要核對來源同語氣；涉及付款、權限、個人資料或者對外承諾，就一定要由指定人批准。
筆者亦唔會要求自己閱讀每一個中間思考過程，而係要求系統交付容易審核嘅證據：改咗邊啲檔案、引用咗邊啲來源、邊個測試失敗、同上一版有咩差異、仲有咩假設未證實。好嘅 Agent 系統唔只要做得快，仲要令審核成本下降。
月費只係成本入面最容易見到嘅部分
由表面睇，一個人每月支付幾百至幾千元使用LLM模型、設計、程式同自動化工具，確實可能做到以前需要幾個人配合先完成嘅工作。但訂閱費同 API 費只係最容易計算嘅成本。
真正成本仲包括：整理資料、建立 prompts 同 skills、連接 API、設計權限、處理模型更新、監察排程、修復失敗工作、重新核對輸出、保存日誌、建立備份，同埋筆者自己用嚟審批同維護嘅時間。系統愈多連接點，平台改版或者資料格式轉變時，維護成本亦會增加。
因此，筆者會用同強積金自動化一樣嘅問題去判斷：工作有幾頻繁？每次可以節省幾多時間？出錯影響有幾大？可唔可以容易發現同回復？如果一個高風險步驟每月只做一次，而且人手只需一兩分鐘，保留人工操作可能更合理。
AI 令試驗成本下降，但唔代表所有自動化都有正回報。最值得投資嘅，通常係重複、耗時、規則相對清楚，而且結果容易驗證嘅部分。
AI 可以夜晚做，但唔代表可以無人看管
筆者好重視 Agent 可以喺夜晚做研究、整理資料同執行測試，第二朝先交報告。呢種時間延伸，的確好似多咗一個輪班團隊。但「無人在線」同「無人監督」係兩回事。
夜間工作最好限制喺可逆、低權限嘅範圍，例如建立草稿、下載公開資料、執行只讀分析、跑測試同準備候選修改。正式發布、刪除資料、改付款、提升權限、發送大量訊息或者操作真實資金，就應該等人確認。
排程亦要有預算、逾時、最大重試次數同停止條件。資料來源失效、輸入突然增加、測試連續失敗、成本超過上限或者結果互相矛盾時，Agent 應該停止並通知，而唔係為咗「完成任務」不斷重試。
真正可靠嘅二十四小時系統，唔係永遠不停做，而係知道咩時候可以繼續、咩時候要排隊、同埋咩時候必須叫醒人。
同一個要求，點解每次結果唔完全一樣
使用 AI 時，另一個同傳統軟件非常唔同嘅地方，係同一個要求未必每次產生完全相同嘅文章、分析或者程式。即使表面 prompt 一樣，背後狀態亦可能已經改變。
1｜模型版本可能更新，能力、偏好同安全規則都會變。
2｜系統提示、可用工具、權限或者工作環境可能不同。
3｜對話歷史、項目記憶同已讀文件會改變模型理解嘅背景。
4｜輸入資料本身可能有新版本、不同時間點或者缺少欄位。
5｜搜尋結果、網站內容同 API 回應會隨時間改變。
6｜模型產生內容時通常包含抽樣機制，所以措辭、方案次序同部分選擇可以有變化。
呢種非確定性唔代表 AI 完全隨機，亦唔代表所有結果都唔可信。佢代表我哋唔可以只係見過一次成功，就假設之後每次都會用同一路徑成功。系統需要驗證結果，而唔係迷信某一句 prompt。
創意輸出可以容許變化，營運輸出要受約束
唔同工作對一致性嘅要求並不相同。叫 AI 提供十個標題、三種開場或者幾個設計方向，版本有變化反而係價值；只要內容符合 brief，人可以選擇最好嗰個。
但計算投資配置、更新數據庫、建立訂單、發送客戶回覆、修改權限或者部署程式，就唔可以接受每次「大致差不多」。呢類工作要將模型自由度限制喺理解同分類，真正數值、欄位、狀態轉移同操作規則交俾固定程式。
筆者會將輸出分成三類：探索型輸出可以有多個候選；分析型輸出要保留來源、假設同計算；操作型輸出就要符合嚴格 schema、權限同批准程序。唔同類型用同一套寬鬆工作方式，先係最常見嘅風險。
將非確定性變成一套可測試嘅流程
筆者唔可能令大型語言模型完全變成 Excel 公式，但可以將變化限制喺可接受位置，並用固定機制驗證最後結果。實際上，筆者會加入以下幾層控制。
1｜保存輸入快照：記錄資料日期、來源、檔案版本同使用嘅策略，確保日後知道模型當時睇過乜。
2｜規定輸出格式：用明確欄位、資料類型、必填項同錯誤狀態，減少自由文字直接進入下游系統。
3｜固定可計算部分：數學、日期、排序、去重、權限判斷同狀態更新，盡量由 Python、SQL 或普通程式執行。
4｜建立驗收測試：用正常案例、邊界案例同錯誤輸入，檢查結果係咪符合要求，而唔係只睇一個示範。
5｜比較版本差異：文章、程式、設定同資料更新前後要有 diff，令審核人只集中睇真正改動。
6｜按風險分級批准：低風險工作可自動通過；中風險要抽樣或覆核；高風險一定要指定人確認。
7｜保存日誌同回復方法：知道邊個 Agent、邊個模型、邊套規則做過乜，出錯時可以停止、撤回同追查。
8｜定期做回歸測試：模型、prompt、工具或者資料結構更新後，用一組固定案例重新檢查，避免舊功能靜靜失效。
重點唔係追求每一個字完全相同，而係確保核心事實、計算、規則、權限同業務結果保持喺可接受範圍。
固定 prompt 及skill 唔等於固定系統
有時我哋會將一條效果良好嘅 prompt 保存低，以為咁就已經建立咗可靠自動化。但 prompt 只係系統其中一層。模型、資料、工具、記憶、權限同下游程式任何一項改變，都可能令結果不同。
所以，一個可重複流程要有版本組合：使用邊個模型或模型系列、邊個 prompt 版本、邊套資料 schema、邊啲工具、邊個知識庫快照、邊組測試同邊套批准規則。未必所有服務都容許永久鎖定模型版本，但至少要保存當時狀態，並喺更新後重新驗證。
我亦會建立一組代表真實工作的固定案例，有正常、有模糊、有矛盾、有缺資料。每次改 Agent 流程，先重跑呢組案例。咁樣我睇到嘅唔只係新功能成功，而係舊有能力有冇退步。
用工具分工，而唔係所有事都交俾同一個模型
一人小隊要長期運作，成本同可靠性都要分層。較昂貴、推理能力較強嘅模型，可以用喺架構、複雜判斷、歧義處理同最終審核；速度較快、成本較低嘅模型，可以處理分類、格式轉換、摘要同大量重複草擬。
但最重要嘅分工唔只係大模型同細模型，而係語言模型同固定工具。搜尋器負責找原文，文件解析器負責提取內容，Python 負責計算，SQL 負責查詢，測試框架負責判定通過與否，排程器負責準時執行，權限系統負責限制操作。
大型語言模型最適合做理解、協調、分類、解釋同提出候選方案。當某一步已經可以寫成清楚規則，就唔需要每次再叫模型自由判斷。將確定部分移出模型，先可以同時降低成本、延遲同錯誤範圍。
人仍然提供方向、品味、關係同責任
專業團隊最難被取代嘅部分，喺人會理解一個決定點樣影響同事、客戶同品牌；會根據多年經驗察覺一個數字雖然合規但唔合理；亦會喺資料不足時知道應該暫停，而唔係勉強填滿答案。
筆者將人仍然需要提供嘅價值概括成四類。
第一係方向：真正要解決邊個問題，同埋有咩事情根本唔值得做。
第二係品味：邊個方案清楚、合適、可信，而唔只係技術上可行。
第三係關係：理解客戶、合作夥伴同團隊之間未必寫喺文件入面嘅背景。
第四係責任：當結果造成影響，邊個需要解釋、修正同承擔。
AI 可以令專業人士更有效率，亦可以令非專業人士先做出一個可討論版本；但當項目進入高風險、規模化或者長期營運階段，知道幾時需要設計師、工程師、保安、法律、財務或者其他專業人士介入，本身就係重要判斷。
點理解「一人小隊」
經過網站、投資、內容同自動化項目之後，筆者會話：一個人加 AI，今日已經可以具備一隊小型團隊嘅部分「工作能力」，但唔等於擁有一隊成熟團隊嘅全部「專業能力」。兩者差別，在於是否有獨立經驗、互相制衡、長期責任同足夠人手處理例外。
對筆者嚟講，一人小隊最實際嘅意思係：可以用自然語言定義目標，將工作拆成多條受控流程，利用 Agent 同工具完成研究、草擬、計算、測試同監察，再集中自己嘅時間做方向、驗收同重要決策。
呢種模式令以前一個人未必敢開始嘅項目，今日可以先建立一個可運作版本。但能力愈大，治理要求亦愈高。我需要更清楚資料從邊度嚟、邊個步驟可以自動、邊個結果要驗證、邊種操作必須批准，同埋失敗時點樣停止同回復。
所以，真正有價值嘅唔係表面上「一個人做到十個人嘅產量」，而係一個人能否建立一套有邊界、有證據、有測試同有責任嘅工作系統。
由數碼工作走向物理世界
到目前為止，網站、內容、投資分析同大部分 Agent 工作都發生喺數碼世界，出錯後通常仲可以刪除草稿、回復版本或者停止部署。但當 AI 連接感應器、摩打、門鎖、燈或者其他實體設備，錯誤就未必可以輕易 undo。下一篇筆者會由物聯網開始，講電腦點樣透過感應器理解溫度、距離、聲音、方向同移動，再用低成本開發板將 AI 判斷變成真實操作；由呢一步開始，可靠性會進一步變成物理安全問題。
下一篇
AI 由軟件走入現實世界：物聯網、感應器同低成本開發板
下一篇會由感應器、數碼訊號同控制器講起，解釋 AI 點樣由讀文字同數據，發展到感知溫度、距離、聲音同動作；亦會分享利用低成本開發板建立語音 AI 助手裝置嘅體會，以及硬件系統點解需要更嚴格嘅延遲、失效同安全設計。