兩星期建了一個 AI Chatbot。第三句就崩潰了。

客戶需要一個 AI 教育顧問聊天機器人。不是套上 ChatGPT 的外殼——而是具備危機偵測、多代理路由、以及 137 所香港學校資料庫的系統。時間很緊。

我用兩星期交付了。沒有僱用任何人。我的「團隊」是我自己加上一組 AI agent。

這篇文章不是在講速度。而是在講真正交付一個 AI 產品的時候，哪些地方會出問題。

第三句就崩潰

前兩句完美。第三句，系統死了。

錯誤訊息非常籠統：「抱歉，處理你的請求時出現問題。」沒有 stack trace，沒有線索。

花了一個小時才找到原因。系統設有 MaxLengthGuardrail，上限為 5,000 字元——原本是防止用戶將整篇文件貼入對話。這是合理的安全措施。但這個防護機制檢查的並非用戶輸入的內容，而是整個 assembled context——包含對話歷史、系統提示、agent 路由元數據與用戶訊息的完整組合。

到了第三句，assembled context 已超過 5,000 字元。防護機制觸發。每次對話到第三或第四句就中斷。

修復只需六行程式碼：在執行長度檢查前，先提取用戶的實際訊息。但找到這六行，前提是理解框架中「用戶發送的內容」與「框架組裝出來的內容」之間的區別。

這正是任何「十分鐘建立聊天機器人」教程都不會告訴你的差距。

一人開發模式

如何在沒有工程團隊的情況下交付產品？

Phase 0 必須手動完成。 我花了兩天學習框架（Agno Agent OS），深入到能做出架構決策的程度。哪個 agent 處理哪種對話模式、路由如何運作、防護機制放在流程的哪個位置。AI agent 能寫程式碼，但無法做出基礎架構決策。跳過這一步，後面會全面崩塌。

每個階段有一份獨立的開發摘要。 包含範圍、現有程式碼模式、檔案路徑、驗證清單。Coding agent 讀完摘要、讀完程式碼庫、獨立執行並驗證。我審核、批准、提交。下一個階段從已知的乾淨狀態開始。

瓶頸從來不是寫程式碼的速度，而是規格說明的精確度。

當摘要寫得精準——包含十六進制色碼、API 參考文檔、現有模式範例——agent 第一次就能交出乾淨的程式碼。當摘要寫得含糊，agent 會自行發明命名慣例，導致整個程式碼庫風格不一致。

繼承的程式碼庫問題

在重建之前，有一套既有的程式碼庫。三個程式碼庫，167,000 行程式碼。

我進行了安全審計。18 項發現。7 項為嚴重等級。

其中包括直接寫死在原始碼中的 API 金鑰——不是環境變數，不是密鑰管理器，而是硬編碼在程式碼裡。有一個程式碼庫甚至將 Apple .p8 私鑰一同提交到版本控制。任何有程式碼庫存取權限的人都擁有正式環境的憑證。

移交評分：3 分（滿分 10 分）。最關鍵的 AI 後端程式碼庫甚至不在移交範圍內。

因此，「我們已經有 AI 聊天機器人了」這句話，往往不代表你以為的意思。

「兩星期」的真實內容

第 1-2 天：學習框架。閱讀文件。做出 AI 無法代勞的架構決策。

第 3 天：撰寫 Phase 1 規格說明。

第 4-5 天：Phase 1 執行與審核。

第 6-8 天：Phase 2 加部署。然後第三句崩潰了。

第 9 天：偵錯。六行程式碼修復。一行遺漏的 Dockerfile 指令。

第 10-14 天：測試、迭代、舊程式碼庫安全審計、撰寫非技術人員能理解的執行摘要。

兩星期是真的。但其中有兩天學習、兩天撰寫規格、一天偵錯六行修復。真正由 AI 協助寫程式碼的時間，大約四天。

規格精確度的瓶頸

最大的教訓：AI agent 寫程式碼很快，但模糊的規格產出模糊的結果，速度再快也沒有意義。

當我寫「實作學校顧問功能」時，agent 產出的東西技術上可運作，但命名慣例與其他部分不一致，忽略了既有的設計標記，並建立了三個重複現有功能的新工具檔案。

當我寫「使用 agents/base.py 中 AdvisorAgent 的類別模式、styles/tokens.ts 中的色彩標記、以及危機 agent 實作中的串流模式來實作學校顧問功能」時——第一次就產出了乾淨、一致的程式碼。

差異不在 AI 的能力，而在規格的精確度。

這意味著什麼

一個人可以建立正式環境的 AI 產品。工具已經存在，框架已經成熟，coding agent 已經具備足夠能力。

但工作並沒有消失。它轉移了。從寫程式碼變成寫規格說明。從偵錯語法變成偵錯架構。從管理工程師變成管理上下文。

聊天機器人在第三句崩潰了。不是因為 AI 失敗，而是因為防護機制守護的是錯誤的東西。

我撰寫關於 AI 產品開發與企業 AI 落地的文章。如果這篇對你有幫助，歡迎在 LinkedIn 交流。