觀點 · 資訊分享
文件老是跟不上程式碼？AWS 分享用 Bedrock AgentCore 自動補文件，30 個程式庫一週搞定
AWS 公部門部落格分享一個實際案例：用 Amazon Bedrock AgentCore 打造的 AI 代理，自動讀程式碼、比對舊文件、更新 Confluence。30 個沒有文件的程式庫，連人工審查一週內完成，每個程式庫的 AWS 費用只有幾美元。
- 發布
- 2026-09-20
- 篇幅
- 約 4 分鐘 · 1,669 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：AWS 分享一個實際案例：用 Bedrock AgentCore 打造的 AI 代理，自動讀程式碼、更新技術文件，30 個沒文件的程式庫一週內補齊。
先用白話講：什麼是「文件漂移」？
想像你家冰箱上貼了一張「家裡東西放哪裡」的清單。一開始很準，但大家每天搬東西、換位置，卻沒人記得改清單。半年後，照著清單找剪刀，永遠找不到。
軟體也一樣。程式碼每天在改，說明文件卻很少跟著更新，這就叫 文件漂移（Documentation Drift）。新同事接手、客戶要交接時，看到的都是過期的說明。
發生什麼事
AWS 在 9 月 20 日的公部門部落格，分享了 AWS 夥伴 Corley 替衛星通訊業者 Eutelsat 打造的解法：一個專門「讓文件跟上程式碼」的 AI 代理。
文章引用的研究數字點出問題有多普遍：
- 文件的更新頻率，比程式碼少 5.7 到 25 倍
- 開發者每週因為效率問題損失超過 8 小時，文件不足是第二大原因（僅次於技術債）
代理的做法分成幾步：
- 領域專家先把背景知識（例如航太、衛星的專有名詞）放進知識庫
- 使用者指定要處理的程式庫
- 代理讀取程式碼，再從知識庫找相關背景
- 對照現有文件，以程式碼為唯一真相：文件缺漏或跟程式碼矛盾，就產生更新
實際效果
Eutelsat 拿 30 個完全沒有文件的程式庫實測：
| 指標 | 結果 |
|---|---|
| 代理執行時間（分析＋更新＋發布） | 每個程式庫約 15～20 分鐘 |
| 人工審查 | 每個程式庫約 1～2 小時 |
| 30 個程式庫總時程 | 約 1 週（含人工審查） |
| AWS 費用 | 每個程式庫幾美元 |
| 估計節省時間 | 超過 90% |
對照組是：資深工程師手寫一個中等複雜度程式庫的文件，要 1～3 人天，30 個就是 30～90 人天。另一個附加收穫是，代理還整理出不同程式庫之間的關聯，這是人工通常不會去做的。
給開發者的技術細節
這套架構用到的 AWS 服務與工具：
- 知識庫：Markdown 文件放在 S3，由 EventBridge Scheduler 每天觸發 Lambda，匯入 S3 Vectors，供 Bedrock 知識庫檢索
- 代理執行：代理打包成 Docker 映像檔放在 ECR，由 Bedrock AgentCore Runtime 啟動，框架是開源的 Strands Agents
- 讀程式碼：透過 GitLab MCP 伺服器，由 AgentCore Gateway 對代理開放
- 寫文件：透過 Atlassian 的 MCP 伺服器，直接更新或建立 Confluence 頁面
- 知識庫的文件（領域背景）和要維護的專案文件是兩回事，文章特別說明兩者不同
我的看法
接案最常遇到的情境，就是「上一個工程師留下來的專案，完全沒有文件」。如果有工具能先讀完程式碼、產出一份八成正確的說明，再讓人花一兩個小時修正，對接手舊專案的人來說非常實用。
不過這篇是 AWS 夥伴的客戶案例，數字只代表這一家公司的 30 個程式庫，不能當成通用保證。小團隊也不一定要照抄整套 AWS 架構；我覺得真正值得學的是概念：用 MCP 讓 AI 讀得到程式碼和文件系統、以程式碼為準、最後一定留人工審查。這套思路用本地模型或其他雲也做得出來。
名詞小辭典
- Bedrock AgentCore：AWS 用來部署、執行 AI 代理的服務，負責代理的執行環境與對外工具連線。
- MCP（Model Context Protocol）：讓 AI 代理用統一方式連接外部工具與資料的協定。
- 知識庫（Knowledge Base）：存放背景資料的地方，AI 回答或寫作前會先從這裡找相關內容。
- Confluence：Atlassian 的團隊文件協作平台，很多公司用它放技術文件。