---
GA: UA-34467841-15
---

# 你的編輯沒有關

# 從失控幻覺到可控協作：我們是怎麼訓練 AI 副駕，而不是放任 Agent - 余士鵬（Mario）

###### tags: `HelloWorld2025` `HWDC2025` `2025` `F 會議室` `AI 開發工具實戰和流程改造`

<blockquote>
用 CLAUDE.md／@import／記憶分層與 HITL/HOTL 治理，打造可回溯、可維護的 AI 協作流程

當團隊導入 AI，常把模型當成「全能 Agent」，最後卻被幻覺、記憶衝突與流程失控拖累。我們選擇不放任 Agent，而是「訓練副駕」。透過 CLAUDE.md 與 @import 條理上下文、分層管理記憶，並設計 HITL/HOTL 治理閘門與量化檢核，我們建立了一套可回溯、可維護的 AI 協作流程。本分享將以 Vibe Coding 專案為例，提供實際可落地的工程方法，適合想讓 AI 穩定融入開發流程的技術團隊。
</blockquote>

{%hackmd @HWDC/announcement-2025 %}

## 會議資訊

**時間：** 15:50 ~ 16:35
**地點：** F 會議室
**日期：** 2025年10月15日
**語言：** 中文
**難度：** 中階

**相關連結：**
- [Hello World Dev Conference 2025 官方網站](https://hwdc.ithome.com.tw/2025) [target=_blank]
- [Hello World 2025 議程表](https://hwdc.ithome.com.tw/2025/agenda) [target=_blank]
- [PPT](https://docs.google.com/presentation/d/1eS-JScmWeiuuCmWn1IfYVAmawbAMTniGd8P1bl9UrEc/edit?usp=sharing)
- [Sample Slash Command](https://docs.google.com/document/d/1emLXFU-KZhKO5EvPLtijtS10V-yf14soIoyQWKgiOfQ/edit?usp=sharing)

## 筆記區

根據錄音內容，這場分享圍繞「從AI新手到在生產環境落地Core Agent/AI Coding」的完整歷程，涵蓋從POC到Prototype再到Production的實務經驗、工具選型、提示詞與上下文管理方法、前後端差異、團隊協作與風險控管，以及在Spring Boot等框架上的實戰教訓。
會議主旨與背景
* 主講者以保險業數位團隊為背景，分享如何用Claude/ChatGPT等工具完成POC，並逐步導入到生產流程，期間經歷從「會話式自然語言開發」到「工程規範化與人機協作」的心態與方法轉變。
* 目標在於：用AI提升開發速度，但同時建立安全、規範與可維運的工程流程，避免將POC式打法直接搬到Production。
核心內容摘要
* 使用情境與成效
* 以壽險網站為POC：MVP包含保單瀏覽、問卷引導選保單、會員登入；從零到可運作版本約兩天完成（主講者自評前後端能力不強的前提下）。
* 工具組合：用ChatGPT/Gemini輔助PRD與MVP定義，無設計稿時用No-code原型工具產交互樣機，再以Claude系工具進行具體開發；早期同時保留IDE配合使用。
* 主要問題與風險
* 生成PDF等前端功能不穩，AI多次修正仍產出錯誤；觀察到AI程式中基礎概念混淆（如URI/URL），顯示黑箱產物難以掌握品質。
* 曾將敏感金鑰交給AI協助測試導致外洩，主講者強調生產前切勿將機敏憑證交予AI或出現在對話內容中。
* POC→Production時，非功能性需求（資安/授權/承載/觀測/部署）不可忽略，無法僅以「對話生成」替代工程流程。
* 實務觀察：AI在前端表現遠優於後端；後端需投入更多規範與審核成本，且企業後端代碼與實務經驗在公開語料中較少，生成更不穩定。
* AI特性與提示技巧
* 模型選型與適配：不同任務用不同模型；需接受AI有記憶限制/遺忘與幻覺風險。
* 三類提示技巧：
* TCR-EI（Google方法論脈絡）：以結構化提示規範任務、步驟、規則、範例與輸出格式，宜做成可重用的「Slash Command」模板。
* CoT（逐步推理）：特別適合除錯與雲端問題排查，要求AI先觀測（如先查雲端Log）再逐步推理，避免憑空猜測。
* 自我驗證（Self-Consistency）：同題多次生成、多數決選解；在低配模型或不穩定場景下提升可靠性。
* 上下文與記憶管理
* 永久佔用記憶：系統提示、工具宣告、MCP等會長期佔用Tokens，需精簡以保留任務上下文空間。
* 長文引入：以「手動Import文件」而非長駐於專案說明，降低上下文爆倉風險；.cloud.md只保留簡要專案說明與必要規範。
* 關閉自動補全：避免模型為了「填滿」而擅自展開導致上下文失控或成本飆升。
* 成本與容量：非專業版時可將關鍵對話片段轉貼至其他模型節省成本（同時需留意敏感資訊安全）。
* 專案結構與檔案佈局
* 建議標準目錄與.cloud檔放置策略：點開資料夾不等於會被讀取，應將讓AI讀的內容放在其可攝取的位置；常文規範另設docs並以Import控制讀取時機。
* Monorepo建議在各子資料夾配置各自的.cloud檔，提升任務界定清晰度；生產環境建議前後端分Repo以降低上下文干擾。
* 工程流程與人機協作
* 生產態的最佳實踐：以OpenAPI驅動代碼骨架、容器化與雲端部署、以MCP或工具協助雲端操作；關鍵規範（命名、DTO風格、CORS、安全邏輯）前置在「模範專案」中，讓AI遵循範例而不是即興創作。
* 人機協作模式分級：自動／HITL（人類在迴路）／HITM/HIC（人類居中/中介），實務上以HITM為主、需求與關鍵節點採HIC，並用風險評分（合規/法規/資料敏感度）決定採用何種模式。
* 團隊協作與規範：若無統一規範，不同人用AI生成的風格差異巨大；需建立統一標準與模範專案，並以AI輔助Review而非取代Review。
* 框架實戰教訓（以Spring Boot為例）
* 不熟框架時讓AI自動產碼，容易產生違反慣例的實作（例如為Health/Security另寫Controller，而非用框架標準設定），雖可運作但不符合最佳實踐，不利維護。
* 建議在「Explain模式＋Step-by-step」下進行，由人主導切分步驟與檢查點，而非一次性生成整坨代碼。
* 規格文件中避免夾雜業務長文與PRD原文，以免AI過度揣測與擴寫，導致偏離需求或引入多餘複雜度。
* 人才與組織觀察
* AI可能放大資深與初級工程師生產力差距；讓初級工程師單獨用AI具風險，需資深工程師在場景界定、規範與Review上加強把關。
* 不當使用AI常導致「Review成本高於自行編碼」，學會正確控制AI輸入/輸出與上下文是關鍵。
結論與建議
* AI在前端與樣板化任務上加速顯著，但在後端與框架性工作上需「規範先行、範例約束、人在迴路」，避免把會話式POC手法硬搬到生產。
* 建立「模範專案＋標準規範＋可重用提示模板（Slash Commands）」三支柱，並用Import控制長文文件注入時機，可顯著提升可靠性與可維運性。
* 嚴禁把金鑰/機敏資料置入對話，落實憑證隔離與測試資料脫敏；以風險評分決定AI自動化等級。
* 在複雜框架（如Spring Boot）採Explain+Step-by-step，由人分解任務、指定觀測與驗證步驟，避免一次性生成破壞慣例的實作。
建議的後續行動（Action Items）
* 建立並維護一個語言/框架對齊的「模範專案」，內含：分層結構、CORS/認證範式、DTO/註解風格、健康檢查與觀測配置。
* 制定AI使用守則：提示詞模板庫（TCR-EI/CoT/自我驗證）、上下文/Import策略、Auto-complete關閉原則、敏感資訊處理規範。
* 導入人機協作分級與風險評分表，用於挑選自動化程度與審核強度（特別是合規/法規敏感場景）。
* 推行OpenAPI優先與API契約驅動開發，使AI在「有邊界」下生成骨架與樣板，減少即興創作空間。
* 建立AI輔助的Code Review流程與度量（可用索引/搜尋工具輔助），並持續收斂團隊風格差異。
會中互動與觀察
* 主講者現場提問：在對Spring Boot不熟的前提下，是放手給AI自動產碼還是人主導？多數回饋傾向謹慎路線；主講者結論亦偏向人主導步進式實作，避免非慣例代碼進入生產。

## 討論區

> 歡迎在此進行討論與 Q&A

## 相關資源

- 投影片連結：[PPT](https://docs.google.com/presentation/d/1eS-JScmWeiuuCmWn1IfYVAmawbAMTniGd8P1bl9UrEc/edit?usp=sharing)
- 相關文件：[Sample Slash Command](https://docs.google.com/document/d/1emLXFU-KZhKO5EvPLtijtS10V-yf14soIoyQWKgiOfQ/edit?usp=sharing)