四天打造企業級知識萃取系統：AI 代理人驅動開發的完整剖析
寫作目的： 本文記錄一段真實的開發歷程——從一個預設好的專案腳手架開始，在 AI 代理人工具的輔助下，四天內建構出具備完整功能的企業級知識萃取平台。這份文件同時是技術分析、方法論總結，也是對未來合作夥伴說明：AI 代理人時代，一個掌握正確方法的人究竟能做到什麼程度。
第一章 成果概覽：四天的數字說話
系統簡介
KMCollector 是一套企業級知識萃取平台，核心功能包含：
- 多平台媒體轉錄：YouTube、抖音、通用影片連結，自動下載音訊後以 OpenAI Whisper 轉錄為文字，支援分段處理（克服 1400 秒限制）、繁體中文自動保底
- 文件萃取：透過 MarkItDown 將 PDF、Word、Excel 等文件轉換為結構化 Markdown
- 分類與團隊管理：多標籤分類系統、RBAC 團隊權限控管（非管理員只能存取公開或授權團隊的紀錄）
- 完整 CRUD 後台：使用者、角色、專案、工作、會議、音訊轉錄、文件萃取全模組
- 企業基礎設施：Cookie 認證、多語系（zh-TW / en-US）、分散式快取（Memory / Redis）、健康監控、NLog 日誌、Swagger API
技術規模
| 指標 | 數值 |
|---|
| 開發天數 | 4 天（97 小時） |
| Git Commits | 117 個 |
| 版本迭代 | 32 個版本（v0.2.10 → v0.2.41） |
| 原始碼檔案 | 292 個（.cs + .razor） |
| 說明文件 | 50 份（架構、PRD、SOP、規格、發行說明） |
| 資料庫 Migration | 12 組（雙資料庫，SQLite + SQL Server） |
| 單元測試 | 9 個測試模組 |
| 自動化腳本 | 5 個 PowerShell 腳本 |
| 外部整合 | OpenAI Whisper、ffmpeg、yt-dlp、Playwright、MarkItDown |
程式碼規模：從腳手架到完成品
統計說明： 腳手架為 commit c5cad3cb（2026-06-02 08:55，重命名 MyProject → KMCollector 的第一個業務 commit），初始 commit 只有 README.md 與 .gitignore 共 2 個檔案。
| 項目 | 腳手架起點 | 四天後完成 | 增加量 |
|---|
| C# 原始碼（.cs） | 15,682 行 / 128 個檔案 | 33,836 行 / 250 個檔案 | +18,154 行（+115%）/ +122 個檔案 |
| Razor 元件（.razor） | 2,167 行 / 34 個元件 | 2,986 行 / 42 個元件 | +819 行（+38%）/ +8 個元件 |
| 說明文件（.md） | 537 行 | 8,205 行 | +7,668 行（+14 倍） |
| PowerShell 腳本（.ps1） | 326 行 | 657 行 | +331 行（+102%） |
| Node.js 工具（.mjs） | 0 行 | 277 行 | +277 行（新增） |
| 源碼合計（.cs + .razor） | 17,849 行 | 36,822 行 | +18,973 行（+106%） |
從這些數字看到了什麼？
把兩個時間點的程式碼數字放在一起比較，第一個引人注意的事實是：完成品的 36,822 行源碼中，有 17,849 行（佔 48.5%）來自腳手架。這些不是業務代碼，而是認證、授權、多語系、健康監控、日誌、快取等「每個企業系統都必須有，但與業務邏輯完全無關」的基礎設施。如果從零開始打造這層基礎，一個有經驗的工程師至少需要 2–4 週。腳手架讓這部分成本在四天的計算中直接消失——這是時間壓縮的第一個槓桿。
四天內真正新增的 18,973 行，才是這個專案獨有的業務靈魂：音訊轉錄的分段處理邏輯、文件萃取的格式轉換、抖音的 Playwright 自動化整合、分類與團隊的 CRUD 模組、RBAC 跨記錄權限控管、分享文字的 URL 自動解析……每天平均產出 4,743 行有明確業務目的的代碼，沒有填充、沒有廢棄路徑。
文件的數字更能說明問題。源碼在四天內增加了 106%，而說明文件卻增加了 1,428%，幾乎是 14 倍的成長。從 537 行增至 8,205 行，涵蓋架構設計、PRD、操作 SOP、部署說明、發行說明。這在傳統開發中幾乎是不可能的事——文件永遠是待補狀態，技術債的形式不只有程式碼，更大的債務往往藏在沒有人寫完的文件裡。AI 代理人把「邊開發邊同步文件」從一個口號變成了可執行的工作節奏。
從代碼的結構品質看，122 個新增的 C# 檔案平均每個 149 行。這個數字透露了一件重要的事：AI 產出的程式碼遵循單一職責原則，每個 Service、Helper、Client 都是焦點明確的小型類別，而非一個包山包海的上帝類別。新增的 8 個 Razor 元件平均 102.4 行，比腳手架原有元件（平均 63.7 行）稍複雜，因為它們承載了多選標籤、即時過濾、團隊權限聯動等實質業務互動，複雜度與功能密度完全匹配。
這代表什麼？傳統開發 vs. AI 代理人開發的成本對比
傳統開發：需要一個什麼樣的團隊？
要用傳統方式建構相同功能的系統，一個負責任的交付團隊通常需要以下角色同時到位。
專案經理（PM） 負責需求訪談、功能清單整理、進度追蹤、跨角色溝通協調，以及最終的驗收確認。這個角色光是做好需求釐清與規格文件，就需要 1–2 週的投入，整個專案期間持續消耗工時。
UI/UX 設計師 負責使用者介面設計、互動流程規劃、元件視覺稿的繪製與修改。即使採用現成的設計系統（如 AntDesign），仍然需要設計師針對各個功能頁面做佈局決策、體驗優化與設計審核，最少需要 2–3 週的設計工作量。
後端工程師（資深，1–2 人） 負責資料模型設計、資料庫 Migration、Service 層業務邏輯、Web API 設計與實作、外部服務整合（OpenAI、ffmpeg、yt-dlp、Playwright）。這是工作量最重的部分，保守估計需要 4–6 週。
前端工程師（1 人） 負責 Blazor 元件實作、與後端 API 串接、多語系整合、UI 互動邏輯。本專案的 Blazor 前端複雜度中等，包含多選標籤、即時搜尋、權限聯動顯示，估計需要 2–4 週。
QA 測試工程師 負責測試案例設計、單元測試與整合測試撰寫、手動功能驗証、回歸測試。這個角色的工作並非只在最後衝刺，而是要跟著每個功能模組同步進行，整體需要 2–3 週。
技術文件負責人（兼任或專人） 負責架構文件、操作 SOP、部署說明、API 文件的撰寫與維護。傳統開發中文件往往是最被壓縮的工作，但本專案交付了 50 份完整文件，若要做到同等品質，至少需要 1–2 週的文件工作量。
傳統開發的時間與成本估算
將上述角色的工作週期疊加，考慮到需求確認、設計迭代、開發返工、測試修正等常見的摩擦成本，完成相同功能範圍的系統，實際需要 2–3 個月（8–12 週），且這還是在需求清晰、溝通順暢的理想情況下的估算。
以台灣市場的中高階人力成本計算：
| 角色 | 月薪估計 | 投入時間 | 人力成本 |
|---|
| 專案經理 | NT$80,000 | 2.5 個月 | NT$200,000 |
| UI/UX 設計師 | NT$70,000 | 1.5 個月 | NT$105,000 |
| 資深後端工程師 | NT$100,000 | 2.5 個月 | NT$250,000 |
| 後端工程師（協作） | NT$80,000 | 1.5 個月 | NT$120,000 |
| 前端工程師 | NT$90,000 | 2.5 個月 | NT$225,000 |
| QA 測試工程師 | NT$70,000 | 2 個月 | NT$140,000 |
| 技術文件（兼任） | NT$60,000 | 1 個月 | NT$60,000 |
| 合計 | — | — | NT$1,100,000 |
加計管理費用、員工勞健保與福利（約 30%）後，總用人成本約 NT$143 萬（約 4.4 萬美元）。若是外包給系統整合商，考慮到專案管理利潤與風險溢價，報價通常在 NT$200–300 萬 之間。
AI 代理人開發：實際投入了什麼？
這個專案的實際資源投入是：1 個人、4 個工作天。
開發者人力成本（以相同的資深工程師薪資計算）：4 天 × NT$5,000/天 ≈ NT$20,000。AI 工具訂閱與 API 費用（Claude Code、OpenAI Whisper API）：約 NT$3,000–8,000。實際總成本：約 NT$23,000–28,000，不到傳統開發的 2%。
更關鍵的是時間。傳統方式需要 8–12 週，AI 代理人方式完成只需 4 天。時間縮短了 95% 以上。對於需要快速驗證市場假設的新創企業，或需要在有限預算內交付系統的中小型組織，這個差距直接決定了一個商業機會能否被把握住。
一個人，抵得上多少人力？
若以「人月」（person-month）為單位計算，傳統方式需要約 13–14 人月的工作量才能完成相同的交付成果。AI 代理人方式由 1 人在 4 天內完成，換算約 0.13 人月。兩者相比，效率差距約為 100 倍。
然而，更準確的理解方式不是倍數，而是角色替代。在這 4 天裡，同一個人同時扮演了：PM（撰寫 PRD 與設計文件）、後端架構師（資料模型、API 設計、服務分層）、後端工程師（業務邏輯實作）、前端工程師（Blazor 元件、互動邏輯）、QA（單元測試、整合驗証）、技術文件負責人（50 份文件），以及 DevOps（部署腳本、環境配置）。
AI 代理人工具讓這一切成為可能的方式，不是讓一個人「更快地完成每件事」，而是讓許多原本需要等待他人、協調接口、反覆溝通的工作，直接在一個上下文中無縫串接。消除的不只是人力成本，消除的更是溝通成本、等待成本、認知切換成本——這些才是傳統協作模式裡真正讓時間消失的黑洞。
一個掌握 AI 代理人工具、具備正確方法論的開發者，在今天的市場裡，能夠獨立承擔一個原本需要 6–7 人團隊才能交付的專案範疇。這不是誇大，這是有 git 歷史為證的事實。
第二章 開發歷程：五個階段的演進
階段一：框架搭建（第 1 天上午，約 2 小時）
從腳手架到可運行系統
這個專案從一個預先準備好的腳手架（starter project）出發。腳手架已預先整合：登入認證、角色管理、AntDesign 元件庫、多語系、健康監控、NLog 日誌等基礎建設。
這一階段的工作是「個人化初始化」：
- 修正系統名稱綁定設定（不再是硬編碼範本名稱）
- 調整選單 Z-index 問題
- 整理文件目錄結構為 7 個分類
- 建立
MediaTranscription 資料庫 Entity 與初始 Migration
關鍵洞察： 好的腳手架節省了 90% 的基礎設施時間。不從零開始，而是從「已解決共同問題的起點」開始。
階段二：核心功能實作（第 1–2 天，約 12 小時）
音訊/影片轉錄完整鏈路
| 版本 | 功能 |
|---|
| 0.2.14 | FFmpeg 絕對路徑配置 |
| 0.2.15 | 轉錄處理器逐段進度日誌 |
| 0.2.16 | 文件萃取功能（MarkItDown 整合） |
| 0.2.18 | YouTube 來源 + 語言選擇 + 繁體中文保底 |
| 0.2.20 | 依音訊時長自動分段（修正 OpenAI 1400 秒上限） |
這階段最關鍵的技術決策是音訊分段策略：OpenAI Whisper API 有時長限制，必須實作 MediaChunker 自動計算分段計畫，再並行送出轉錄請求、依序合併結果。這不是一個簡單問題，但 AI 代理人在有清楚規格的情況下，一次就設計出正確架構並配套寫出測試。
階段三：多平台整合（第 2–3 天，約 8 小時）
突破平台壁壘
YouTube 有完整 API 支援，相對容易。抖音則有強力的反爬蟲機制。
解法：用 Playwright 自動化瀏覽器模擬真實使用者登入、攔截音訊串流 URL，再下載。這需要：
- 一個 Node.js 助手腳本（
get-douyin-audio.mjs）控制 Playwright - 一個初始化腳本（
douyin-init.mjs）處理 Cookie/登入狀態 - C# 端的
DouyinAudioDownloader 呼叫 Node.js 子程序
這個跨語言（C# ↔ Node.js）、跨技術棧的整合，同時產出了完整的部署 SOP 與設計文件。
抽象化設計： 同時設計了 MediaUrlDownloader，統一處理「任意影片連結」來源，並實作 ShareTextParser 自動從分享文字中提取 URL 與標題。
階段四：資料治理與權限控管（第 3–4 天，約 16 小時）
企業級的資料隔離
| 版本 | 功能 |
|---|
| 0.2.34 | 分類清單 CRUD |
| 0.2.35 | 團隊清單 CRUD |
| 0.2.36 | 紀錄加入分類/團隊標籤欄位與過濾 |
| 0.2.37 | 角色預設團隊與紀錄團隊權限控管 |
| 0.2.38 | 紀錄預帶入使用者授權團隊 |
這階段引入了最複雜的業務邏輯：RBAC（角色基礎存取控制）的延伸。非管理員使用者只能查看「無團隊（公開）」或「與自己角色所屬團隊有交集」的紀錄。
實作涉及：
IRecordAccessScopeProvider（定義存取範圍介面）TagStringHelper（分隔字串格式的標籤轉換與精確比對）TeamJsonHelper（JSON 格式的角色→團隊映射）- 6 個資料庫 Migration（分類、團隊、標籤各 2 個，Sqlite + SQL Server 各一套）
全部配套 PRD 文件、測試模組、發行說明。
階段五：細節打磨（第 4 天，約 4 小時）
讓系統在真實環境中穩定運行
- 修正 NLog 及 yt-dlp 的 UTF-8 編碼問題（CJK 字元亂碼）
- 編輯紀錄時可修改原始檔名
- 抖音腳本支援
--ffmpeg 外部路徑參數（解決新機器部署問題） - 輸出 ffmpeg 錯誤訊息以診斷 ExitCode=4
- 新增外部工具一鍵安裝 PowerShell 腳本
這階段的特點是「問題驅動」：在真實部署環境中發現問題，快速診斷、快速修復。每個問題平均耗時不超過 20 分鐘。
第三章 AI 代理人為何能做到這一切：機制分析
3.1 零切換成本的全域知識
傳統開發中，工程師需要不斷在不同視窗間切換：IDE、Stack Overflow、API 文件、Jira、設計文件……每次切換都是認知成本。
AI 代理人的上下文窗口可以同時持有：
- 整份需求規格
- 相關程式碼片段
- 架構設計原則
- 歷史決策記錄（CLAUDE.md 中的不變量）
結果： 生成的程式碼天然符合既有架構風格，不需要事後「對齊」。
3.2 規格→程式碼的直接轉換
只要需求夠清楚，AI 代理人可以：
PRD（產品需求文件）
→ 資料庫 Entity + AutoMapper Profile
→ Service 層（CRUD 方法）
→ Controller（Web API）
→ Blazor 頁面（AdapterModel + 檢視邏輯）
→ 單元測試
→ 發行說明
這整條鏈路，AI 可以在一次對話中完成，而且每個環節都遵循 CLAUDE.md 裡定義的不變量（雙資料庫 migration、建構式注入、精確標籤比對…）。
傳統方式： 一名工程師完成這條鏈路需要 1–2 天。
AI 代理人： 30–60 分鐘（大量時間花在人工審查上，而非生成）。
3.3 並行思考：程式碼與文件同時產出
每一個功能的 commit 都伴隨著：
- 更新的
docs/ 文件 - 配套的測試模組
- 更新的
appsettings.json 版本號
這在傳統開發中幾乎不可能做到——文件永遠在「待補」狀態，測試永遠在「下週」。AI 代理人將文件和測試視為需求的一部分，而非附加工作。
3.4 即時錯誤診斷與修正
這個專案中，許多「fix」commits 都在 feat commits 之後的 1–2 小時內出現。這不是因為程式碼品質差，而是因為真實環境總是與開發環境不同。
AI 代理人的優勢在於：
- 給它錯誤訊息（如 ffmpeg ExitCode=4），它能立刻識別問題根源
- 給它重現步驟，它能設計正確修復方案
- 修復完成後立刻重寫測試來覆蓋這個案例
診斷速度比傳統方式快 5–10 倍，因為它不需要「搜尋問題」，它直接分析。
3.5 守護不變量的「護欄機制」
這個專案在 CLAUDE.md 中定義了多條關鍵不變量（如：所有查詢必須套用團隊權控、雙資料庫 migration 等）。
AI 代理人在每次生成程式碼前都會讀取這些規範，確保新程式碼不違反既有設計決策。這相當於有一個永遠在場、永遠記得所有規則的資深同事在 review 每一行程式碼。
第四章 核心方法論：如何正確駕馭 AI 代理人
方法一：從好的腳手架出發
不要從零開始。好的腳手架已解決了「所有專案都會遇到的共同問題」：認證、授權、日誌、健康監控、CI/CD 鉤子……
每次都從空白頁面開始，是在重複浪費時間。
本專案的腳手架預先包含： 25+ 個預整合功能，讓開發者第一天就能專注在「這個專案獨有的業務邏輯」上。
方法二：規格先於程式碼
每個功能在實作前，都先有：
- PRD（產品需求文件）：What + Why + Success Criteria
- 設計文件：How（架構、資料流、介面設計）
AI 代理人的程式碼品質與輸入規格的清晰度直接相關。模糊的需求產出模糊的程式碼；清晰的規格產出精確的實作。
本專案的 50 份文件不是「事後補寫」，而是「實作的前提條件」。
方法三：用護欄替代事後 Code Review
CLAUDE.md（或 AGENTS.md）定義的不變量就是護欄。這些護欄不是給人看的建議，而是 AI 代理人每次行動前的強制檢查清單。
護欄機制確保：
- 新加入的程式碼自動符合架構規範
- 不會因為「AI 沒注意到」而引入安全漏洞或技術債
- 每個開發者（包括 AI）都遵循相同的編碼標準
方法四：版本作為完成的儀式
本專案規定：每次可建置的異動 = 一個版本號 + 一個 Commit。
這個規定看似繁瑣，實際上創造了：
- 清楚的「完成」定義（不是「大概差不多」，是「版本號已遞增」）
- 可追溯的決策歷程（每個版本對應的 commit 訊息說明了為什麼）
- 回滾的錨點（任何一個版本都是穩定可部署的狀態）
4 天 32 個版本 = 平均每 3 小時完成一個可部署的功能增量。
方法五：問題驅動的真實環境驗證
每一個「fix」commit 背後都是真實的問題：
- 在不同機器上部署時發現的路徑問題
- CJK 字元在 Windows 終端的編碼問題
- 第三方平台（抖音）的反爬蟲機制
不逃避真實環境的測試，用問題驅動快速迭代。真實問題比假設的測試案例更有價值。
第五章 AI 新紀元的個人能力圖譜
在 AI 代理人工具出現之前，一個人的開發能力等於「他能寫多少程式碼、記住多少 API」。
在 AI 代理人時代，這個等式改變了。
5.1 價值轉移：從「執行者」到「指揮者」
| 舊範式 | 新範式 |
|---|
| 會寫程式 | 會定義問題 |
| 記得 API 文件 | 能判斷 AI 輸出的正確性 |
| 快速編碼 | 快速定義規格 |
| 解決技術問題 | 分解複雜業務問題 |
| 寫測試驗程式碼 | 寫規格驗業務假設 |
AI 代理人是高效的執行者，但它需要一個清楚知道「要執行什麼、為什麼」的指揮者。
5.2 核心能力一：領域知識
AI 代理人可以生成抖音下載器的程式碼，但它不知道你的業務場景為什麼需要抖音下載器，也不知道使用者的痛點在哪裡。
領域知識讓你能夠：
- 定義正確的成功標準
- 識別 AI 輸出中的業務邏輯錯誤
- 做出 AI 無法做的架構取捨決策
沒有領域知識的 AI 使用者，是在請一個聰明但對業務一無所知的助手工作。
5.3 核心能力二：清晰溝通（Prompt Engineering）
AI 代理人的輸出品質 = 輸入描述的清晰度。
清晰溝通不是「學會特定咒語」，而是訓練自己：
- 明確說明目標（不是「做一個下載器」，是「從抖音分享連結中提取 MP3 音訊，支援 DASH 與合併 MP4 兩種格式，輸出到指定路徑」）
- 說明限制條件（「必須支援 Windows 路徑，不能依賴全域環境變數」）
- 定義成功標準（「轉錄完成後，音訊時長誤差不超過 5 秒」）
- 提供上下文（「這個系統的其他下載器都實作了
IMediaDownloader 介面，新的也要遵循」）
5.4 核心能力三：品質判斷
AI 代理人很少「完全錯誤」，但經常「看起來對、其實有細微問題」。
品質判斷能力包含：
- 能夠 code review AI 的輸出
- 識別可能的資安漏洞（SQL injection、XSS、未授權存取）
- 識別架構不一致（違反既有設計模式）
- 識別邊界案例沒有處理
這需要真正的工程素養，不是被 AI 取代的能力，而是使用 AI 的必要前提。
5.5 核心能力四：系統思考
單個功能 AI 可以完美實作，但功能之間的依賴、架構的整體一致性、技術債的累積——這些需要系統思考能力。
本專案的 CLAUDE.md 和 docs/architecture/開發慣例與限制速查.md 就是系統思考的結晶：把跨功能的設計決策明確化，讓整個系統在快速迭代中保持一致性。
5.6 核心能力五：敏捷調整
AI 的輸出不是一次就完美的，而是「第一個版本夠好，可以快速迭代改進」。
敏捷調整的能力包含：
- 接受「夠好但不完美」的初版輸出
- 快速識別需要調整的部分
- 用清楚的反饋引導 AI 做精準修正（而不是「這不對，重來」）
本專案 117 個 commits 中有 13 個 fix commits，fix 率 11%。 每個問題從發現到修復平均不超過 20 分鐘。
5.7 工作方式的轉變：從「一個人寫程式」到「指揮 AI 團隊」
傳統開發：1 個工程師，1 條工作線，串行完成。
AI 代理人開發：1 個指揮者，N 個並行的 AI 代理人：
- 代理人 A 正在寫後端 Service 邏輯
- 代理人 B 同時在寫對應的測試
- 代理人 C 同時在更新 PRD 文件
- 指揮者在審查輸出、做架構決策、規劃下一步
效率倍數不是 2x，而是 5–10x，因為是並行的，不是串行的加速。
第六章 成功的前提：什麼是 AI 工具無法替代的
AI 代理人做不到的事
列出這些，不是要貶低 AI，而是要說明指揮者的價值在哪裡：
- 理解使用者的真實痛點（AI 只知道你說的，不知道使用者沒說出口的）
- 做優先順序決策（應該先做哪個功能？資源有限時砍哪個？）
- 評估業務風險（這個設計決策的商業後果是什麼？）
- 建立人際信任（客戶、同事、合作夥伴的關係）
- 判斷「夠好了」的時機（完美是效率的敵人）
讓 AI 工具發揮最大效益的前提
- 你知道要解決什麼問題（問題定義能力）
- 你能評估解決方案的品質（技術鑑賞力）
- 你有護欄保護系統不偏軌（CLAUDE.md、不變量文件）
- 你有好的起點（可複用的腳手架，不從零開始）
- 你有紀律做版本管理（每個增量都是可部署的狀態）
第七章 結語：給合作夥伴的話
我能帶來什麼
這個專案是一個存在於 git 歷史中的真實證明：
我能夠在四天內，以一個人的資源，交付：
- 具備企業功能完整度的 Web 應用系統
- 完整的技術文件（架構、PRD、SOP、發行說明）
- 可維護的程式碼（測試覆蓋、清晰架構、雙資料庫 migration）
- 可部署的生產就緒系統
這不是運氣，也不是一次性的衝刺。這是一套可複現、可擴展的方法論。
這代表什麼樣的合作可能性
| 傳統合作模式 | AI 代理人時代的合作模式 |
|---|
| 「招 5 個工程師，6 個月後上線」 | 「1 個懂方法的人，配合清晰需求，4 週可以上線可用版本」 |
| 文件永遠落後於程式碼 | 文件與程式碼同步生成 |
| 技術債隨時間累積 | 護欄機制防止架構腐化 |
| 需要完整規格才能開始 | 可以邊做邊細化，快速驗證假設 |
如何合作才能最大化效益
對合作夥伴最重要的一點：你的業務知識 + 我的方法論 = 快速交付真正有價值的系統。
我最需要從合作夥伴那裡獲得的不是技術需求，而是：
- 真實的使用者問題（不是「我要一個系統」，是「使用者在哪個步驟卡住了」）
- 優先順序的判斷（什麼功能必須有、什麼可以之後再說）
- 成功的定義（系統上線後，什麼樣的結果代表成功）
有了這三樣，AI 代理人工具就能以你無法預期的速度，把它們轉換成可運行的系統。
附錄：開發統計數字一覽
提交活動分布
日期 Commits 主要里程碑
─────────────────────────────────────────────
2026-06-02 34 框架搭建 + 音訊轉錄基礎
2026-06-03 25 完整轉錄鏈路 + 文件萃取
2026-06-04 34 抖音整合 + 多平台支援
2026-06-05 21 分類/團隊 CRUD + 權限控管
2026-06-06 3 抖音腳本微調
─────────────────────────────────────────────
合計 117 平均 29.25 commits/天
版本演進時間軸
v0.2.10 框架個人化（06-02 09:30）
v0.2.13 音訊轉錄資料模型（06-02 14:58）
v0.2.16 文件萃取（06-03 10:36）
v0.2.18 YouTube 來源整合（06-03 13:17）
v0.2.20 音訊分段策略（06-03 14:06）
v0.2.22 抖音 Playwright 整合（06-04 11:11）
v0.2.27 分享文字自動解析（06-04 14:25）
v0.2.34 分類清單 CRUD（06-05 09:18）
v0.2.35 團隊清單 CRUD（06-05 10:04）
v0.2.37 RBAC 團隊權限控管（06-05 14:59）
v0.2.41 抖音腳本完善（06-06 11:08）
提交類型分布
| 類型 | 數量 | 說明 |
|---|
| feat（功能新增） | 32 | 每個都是可展示的功能增量 |
| docs（文件） | 15 | 與程式碼同步生成，非事後補寫 |
| fix（錯誤修正） | 13 | 真實環境問題快速修復 |
| chore（維護） | 7 | 配置、腳本、工具整合 |
| refactor（重構） | 1 | 必要時的架構調整 |
