# 兩星期建了一個 AI Chatbot。第三輪對話就崩潰

> 一個人加一隊 AI coding agent，兩星期建好涵蓋 137 間學校的 multi-agent chatbot，卻在第三輪對話死掉。原因是一條檢查組裝 context 而非用戶訊息的 guardrail——修復只需 6 行 code，找到它用了 1 小時。

- URL: https://hyperfocusam.com/blog/ai-chatbot-2-weeks-what-broke-tc/
- Language: zh-Hant
- Author: Sam Wong (黃力桐), https://hyperfocusam.com/
- English edition: https://hyperfocusam.com/blog/ai-chatbot-2-weeks-what-broke/ (Markdown: https://hyperfocusam.com/blog/ai-chatbot-2-weeks-what-broke/index.md)

---

[黃力桐 Sam Wong](https://hyperfocusam.com/)

[黃力桐 Sam Wong](https://hyperfocusam.com/zh/about/) · 2026 年 3 月 27 日

客戶需要一個 AI 顧問 chatbot。不是 ChatGPT 套殼——是一個真正的 [multi-agent 系統](https://hyperfocusam.com/blog/zh-agentic-ai-five-lessons/)：危機偵測、個人化路由、一個涵蓋 137 間香港學校的知識庫。而且要快。

兩星期，我交貨了。僱員人數：0。團隊是我自己，加一隊 AI coding agent。

但這不是一個吹速度的成功故事。這篇講的，是一個人加一隊 agent 出貨的 AI 產品，真正會在哪裡壞。

## Turn 3 崩潰

chatbot 頭兩輪對話完美。第三條訊息就死。

錯誤訊息極其行貨：「Sorry, there was a problem processing your request.」用戶那邊沒有 stack trace，只有沉默。我花了 1 小時才找到根本原因：系統有一條 MaxLengthGuardrail，上限 5,000 字元——防止用戶把整份文件貼進對話框，合理。

但這條 guardrail 檢查的，不是用戶訊息，是「組裝後的 context」——對話歷史加 system prompt 加 agent routing metadata 加用戶訊息的完整 payload。到第三輪，組裝 context 超過 5,000 字元，guardrail 觸發，每一段對話都死在第三、四輪。

修復是 6 行 code：先抽出用戶的實際訊息再檢查長度。但找到它，需要理解「用戶送出的」和「framework 在幕後組裝的」是兩樣東西。這正是所有「10 分鐘建 chatbot」教學不會為你準備的落差。

## 一人開發模式

沒有工程團隊。要把一個 multi-agent chatbot 從零推到 production，做法是這樣。

Phase 0 是人手做的：我花了 2 天深入學 framework——Agno Agent OS，深到能做架構決定。哪個 agent 管哪種對話模式、routing 怎樣走、[guardrail 該放在 pipeline 哪個位置](https://hyperfocusam.com/blog/claude-code-mastery-part-3-hooks-guardrails-tc/)。AI agent 能執行 code，但不能替你下架構判斷；跳過這步，得到的是一個起得快、但被自己重量壓垮的系統。

之後每個 phase 一份自足的 brief：spec 包含範圍、現有 code pattern、檔案路徑、驗證清單。coding agent 讀 spec、讀 codebase、執行、驗證；我 review；下一個 phase 開始。流程是這樣：第一，我決定建甚麼；第二，coordinator agent 把意圖翻譯成有具體 pass/fail 標準的技術 spec；第三，coding agent 自主執行；第四，我 review、批准、commit；第五，下一個 phase 由乾淨的已知狀態開始。兩個 phase 就跑起核心系統：3 種對話模式的 multi-agent routing（危機偵測、升學顧問、一般育兒）、137 校知識庫、streaming 回應、用戶登入。

樽頸從來不是寫 code 的速度，是 spec 的清晰度。brief 寫得精確——設計 token 連 hex code、framework API 參照、現有 pattern 例子——agent 就交出乾淨的 code；brief 含糊時，agent 自創慣例，之後要逐條拆。

## 「兩星期」實際的樣子

Day 1-2：學 framework、讀文件、做 AI 替代不了的架構決定。

Day 3：寫 Phase 1 spec，細到 coding agent 不用發問。

Day 4-5：Phase 1 執行與 review——核心 agent、routing 邏輯、知識庫、guardrail。

Day 6：寫 Phase 2 spec——個人化功能、家庭 profile、回應偏好。

Day 7-8：Phase 2 執行、部署上 production，然後就是 turn-3 崩潰。

Day 9：debug——guardrail 修復，另加一行漏掉的 Dockerfile，漏了的話任何一次部署都會令 backend 崩潰。

Day 10-14：測試、迭代、寫給非技術持份者的 executive summary。

兩星期是真的。但「兩星期」包含 2 天學習、2 天寫 spec、1 天 debug 一個 6 行的修復，真正 AI 輔助寫 code 的日子大約只有 4 天。

## Spec 清晰度這個樽頸

最大的一課：AI agent 寫 code 快，但垃圾 spec 產出垃圾更快。

跟 coding agent 說「implement the school advisor feature」，出來的東西技術上可行，但命名慣例和 codebase 其他部分不同、漏用現有 design token、另開 3 個和現有 function 重複的 utility 檔。改成「implement the school advisor feature using the AdvisorAgent class pattern from agents/base.py, the color tokens from styles/tokens.ts, and the streaming pattern from the crisis agent implementation」——第一次就交出乾淨一致的 code。分別不在 AI 的能力，在 spec 的精確度。

## 這代表甚麼

一個人可以出貨 production 級 AI 產品。工具存在，framework 夠成熟，coding agent 夠能力。但工作沒有消失，只是轉移了：由寫 code 變成寫 spec；由 debug 語法變成 debug 架構；由管理工程師變成管理 context。

chatbot 死在第三輪，不是因為 AI 失敗——是因為 guardrail 守錯了東西。