【我的 AI 同事養成計畫】幫 AI 寫一本「員工手冊」，從治好它的唬爛開始

作者：康子晉｜AWS 解決方案專家，守備範圍橫跨架構設計、維運排錯、成本優化與雲端遷移。
本系列聊一個我最近很有感的主題：怎麼讓 AI 成為團隊裡可靠的一員。

系列開場

這是一系列的實驗紀錄。

我是一個做 AWS 維運與架構的工程師，每天的工作就是巡帳號、查費用、排錯、設計架構、跟客戶講方案。這一年，我做了一件事：把 AI 從一個「聊天機器人」，慢慢調教成一個能真正幫我幹活的「同事」。

這個系列，就是把我這套框架一塊一塊拆開來講。不藏招，連我踩過的雷一起講。

先說一個比喻：AI 是個會失憶又愛唬爛的超強新同事

如果你也用 AI 寫過 code、查過 AWS，你大概懂這種感覺。

它很強。學什麼都快，你丟一段沒看過的 code 它三秒看懂，你問一個冷門服務它對答如流。但它有兩個讓人很頭痛的毛病：

第一，它會失憶。 每開一個新對話，它就把昨天你們一起做的事忘得一乾二淨。你昨天才跟它說清楚「我們用的是這個帳號、這套命名規則、這個地端網段」，今天它又當作第一次見面，要你從頭講一遍。

第二，它會唬爛。 你問它一個 AWS 的限制或配額，它語氣篤定地給你一個數字，附上條理分明的解釋——然後是錯的。最可怕的不是它錯，是它錯得很有自信，讓你不小心就信了。

如果你今天請到一個能力很強、但會失憶又愛唬爛的新同事，你會怎麼帶他？

你不會每天從頭教他一次，也不會放任他亂講。你會幫他寫一本員工手冊：告訴他公司的規矩、我們的脈絡、遇到不確定的事該怎麼查證、什麼時候該找哪個專家。然後讓他照著這本手冊工作，越做越上手。

這整個系列，就是我幫 AI 寫的這本「員工手冊」。

這本手冊寫在哪？談談 Kiro

我用的工具是 Kiro——AWS 推出的 agentic IDE（智能體開發環境）。

簡單說，它長得像 VS Code，但骨子裡是一個會自己讀檔、寫檔、執行指令、呼叫工具的 AI 協作環境，底層模型走 Amazon Bedrock。它最大的特色是 spec-driven（規格驅動）跟一整套可以讓你「客製 AI 行為」的設定機制。

而我要強調一件事，這也是這個系列最重要的觀念：

我接下來要分享的東西，90% 是「心法」，不是「Kiro 的操作教學」。

Kiro 提供的這幾種機制——讓 AI 記住脈絡、讓 AI 查證、讓 AI 分工、讓 AI 接外部工具——在 Claude Code、Cursor、GitHub Copilot 上幾乎都有對應物。所以就算你不用 Kiro，這套思路一樣搬得過去。我們真正在做的事情，業界有個名字叫 Context Engineering（脈絡工程）：LLM 沒有變聰明，聰明的是「你怎麼餵它 context」。

員工手冊的全景圖

這本手冊由六個部分組成，每一個都對應「帶新同事」的一個動作：

接下來這個系列，我會一塊一塊拆。而我刻意不照「工具功能表」走，要先從這個新同事最讓人受不了的毛病開刀——唬爛。

進入正題：我受夠 AI 唬爛 AWS 限制了

先講一個你八成中過的招。

你問 AI：「這個服務的某個上限是多少？」它秒回一個看起來超有自信的數字，附帶一段條理分明的解釋。你信了，寫進文件、報給客戶、排進架構。結果上線前才發現——它講錯了。

更麻煩的是，它錯得很有條理。不是一看就知道在亂講的胡言亂語，而是語氣篤定、格式工整、連「根據 AWS 官方文件」都幫你腦補好了的那種錯。

為什麼 AI 特別愛在 AWS 上翻車

因為 AWS 的限制、配額、定價改超快。模型的訓練資料有截止日期，但 AWS 上週才調過的 quota、上個月才 GA 的功能、昨天才改的定價，它通通不知道。它只能用「記憶中大概的樣子」回答你，然後用流暢的語氣把不確定包裝成確定。

這不是模型笨，是你沒給它查證的機制跟紀律。

我的解法：一條規則 + 一個 MCP

第一件：給它一個能查官方文件的工具（AWS Documentation MCP）

MCP（Model Context Protocol）簡單講就是「讓 AI 長出手腳」的標準介面。AWS 官方有出一個 Documentation MCP Server，掛上去之後，AI 就能即時搜尋官方文件，而不是憑記憶回答。

設定大概長這樣（放進 mcp.json）：

{
  "mcpServers": {
    "aws-documentation": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "autoApprove": ["search_documentation", "read_documentation"]
    }
  }
}

但光給工具沒用——它有手，不代表它願意動手。這就要靠第二件。

第二件：給它一條「先查後答」的紀律（Steering 規則）

工具是能力，規則是紀律。我在 Steering（一份永遠載入的規範檔）裡寫了一條鐵則，大意是：

任何「可被驗證的技術事實聲明」，回答前都必須先用工具查證，禁止憑記憶直接回答。

判斷口訣：「我要說的這句話，別人能拿去驗證真偽嗎？」
能 → 先查再答，附上來源。
不能（純觀點/閒聊）→ 直接說。

關鍵在那句口訣。它把「什麼時候該查」變成一個 AI 自己能執行的二元判斷，而不是模糊的「請盡量正確喔」。配額、限制、功能名稱、定價數字——這些都「能被驗證」，所以一律先查。什麼是 VPC、什麼是 IAM 這種純概念，不用查，直接答。

我還加了來源標註的要求：查來的要寫「根據 AWS 官方文件…」，沒查的要明講「這是我的理解，未查證，建議再確認」。這樣我一眼就能分辨哪句話可信、哪句話要自己再 double check。

效果

掛上之後再問同一個問題，它的行為變了：先去搜官方文件 → 讀到實際數字 → 回答時附上文件連結。錯誤率肉眼可見地掉下來，而且就算它真的查不到，它會老實說「我查不到官方文件確認」，而不是硬掰一個。

從「自信地講錯」變成「誠實地說不知道」——對在 production 環境工作的人來說，後者珍貴太多了。

帶走的三個重點

1. AI 唬爛不是模型問題，是機制問題。 沒給它查證工具跟紀律，再強的模型都會掰。
2. 能力（工具/MCP）跟紀律（規則/Steering）要分開設計。 有手不等於願意動手。
3. 要求來源標註。 讓你能分辨「查來的」和「猜的」，這是人機協作的信任基礎。

治好唬爛只是第一步。下一篇要處理那個更根本的毛病——失憶：怎麼讓 AI 跨對話記得住你的脈絡，不用每次都重新自我介紹。

✍️ 關於作者

康子晉
做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖和客戶為伍。
這個系列記錄我怎麼把 AI 從「會聊天」調教成「能幹活的同事」。

如果這篇對你有幫助，歡迎追蹤這個系列，或來這裡找我聊聊：
🔗 LinkedIn：LinkedIn