四天打造企業級知識萃取系統：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	必要時的架構調整

2026年6月6日 星期六