"AI協作心得"
- 元件庫雙向約束方法論 - 設計端與工程端的雙向契約
元件庫是設計端與工程端之間的雙向約束：設計端先元件後組合、避免樣式發散；工程端禁自製元件、依語意選件。含 L1/L2/L3 分層架構、命名與通用元件判準、形態因素先決、元件文字歸屬（i18n-first）、豁免三條件與跨端契約
- codebase-memory-mcp：155 語言 tree-sitter 知識圖譜 MCP 的能力與邊界
codebase-memory-mcp (cbm) 的設計拆解：155 vendored tree-sitter grammar、11-signal 語意搜尋、Go / TS / C / C++ 上的 hybrid type resolution、跨 service HTTP/RPC 鏈接，以及在沒有 hybrid resolution 的語言上會降級成什麼樣。
- codegraph：用 tree-sitter per-language query 涵蓋 19+ 語言 call graph 的 MCP
codegraph MCP 的設計拆解：tree-sitter per-language query 抽 call graph、native OS file watcher 2 秒 debounce auto-sync、14 web framework routing、7 codebase benchmark 的 token 節省方法論。重點在 tree-sitter syntactic 路線能解到什麼程度、type-inferred dispatch 仍漏什麼。
- serena：把 LSP 包成 agent-first MCP 的 symbol-level 編輯方案
serena MCP 的設計拆解：直接整合各語言 LSP、symbol-level atomic edit（replace_symbol_body / insert_after_symbol / rename）、per-session project activation、跨 session memory。重點在 LSP 路線的型別精度可信度與 per-session 沒持久化的取捨。
- 三 MCP 工作流與 Dart 實測：cbm / codegraph / serena 的職責分工與三刀流
在同一個 Dart 商業專案上跑同一組 query，量化 codebase-memory-mcp / codegraph / serena 三個 code intelligence MCP 的能力差距，得到「不能互相取代、要互補使用」的三刀流結論。含 5 個實驗的 CLI baseline 跟 MCP 驗證對照。
- Codex 與 Claude Code Statusline 相容設計方法
用 case-first 查詢與 WRAP 判讀，整理 Claude Code statusLine 與 Codex tui.status_line 的差異，說明如何讓同一個 statusline 工具保留 Claude 原功能並預留 Codex 相容入口。
- Blog 文章模板設計：作者品質閘門與正文分工
文章模板的定位與 SSoT 歸屬：模板是作者品質閘門、正文仍走技術推導、backend 正文不暴露填表結構。
- Blog Markdown 寫作規範與 mdtools 檢查
本 blog 的 Markdown 排版規範權威契約。涵蓋 H1 禁用、MD024 siblings_only、反釣魚 TLD 校驗、卡片雙向完整性、front matter schema；改規則時要與 scripts/mdtools 實作同步。
- 5W1H 自覺決策方法論：系統化決策框架
同一個功能被重複實作、或難題被臨時解法蓋過去時，用來在任務建立的當下強制回答六個問題，包含執行者與分派者的職責邊界
- Clean Architecture 實作指引
要判斷哪些任務屬於同一層、哪些必須依序完成時，用來對照四層的依賴方向、設計與實作的相反順序、以及各階段的檢查點
- Ticket 生命週期：四個狀態與各自的進入條件
Ticket 只剩模糊標題、領取的人不知道從哪開始、關閉的人不確定算不算完成時，用來定義每個狀態的進入條件與必要欄位
- Ticket 設計派工：執行層與記錄層分開
工作日誌長到查一個設計決策要上下捲很久、而任務狀態也混在同一份文件裡時，用來把執行層拆成 Ticket、記錄層拆成三層日誌
- 主線程分派、代理人執行：AI 協作的重構流程
主線程 compact 之後失去全局、或代理人執行到一半才發現規格缺漏時，用來界定分派前的準備度檢查與各階段的強制驗證
- 用 Claude Code GitHub Actions 自動除錯 CI 建置失敗
GitHub Actions 整合 Claude Code 做 CI 修復與 Code Review。含觸發設定、成本控制、OAuth vs API key 計費差異。
- 用 Hook 把開發規範變成自動執行的基礎設施
開發規範寫在文件裡而執行率取決於當下記不記得時，用來判斷哪些規範該掛在哪個 hook 時機、以及阻斷與記錄各自的適用範圍
- 即時 Review：Ticket 完成就 Review，不累積
累積一批 Ticket 才一起 review、而錯誤的架構決定已經被後面幾張沿用時，用來把 review 的觸發時機與檢查項目固定下來
- 設計階段的品質閘門：C1/C2/C3 在寫程式之前擋下來
Ticket 的職責不清與範圍過大要到實作階段才浮現時，用來在文字階段就判定過大、模糊、不完整三種缺陷
- 程式碼自然語言化撰寫方法論
讀自己或別人的程式碼要反覆回上面確認變數與縮寫時，用來把命名、函式長度、變數用途還原成可逐項檢查的撰寫規則
- 註解保護需求，不解釋程式
註解寫成函式名稱的重述、或改動一段程式時查不到當初的業務約束時，用來判斷哪些內容該進註解、哪些該進命名或文件
- 層級隔離：讓每張 Ticket 只做一件層級的事
PR 一次動了四層、review 無從下手時，用來把 Clean Architecture 的分層轉成 Ticket 的拆法與執行順序
- MVVM ViewModel 開發方法論
建立完整的 ViewModel 開發規範，確保 MVVM 架構一致性
- Ticket 拆分標準方法論
Ticket 拆分標準
- Code Smell 檢查清單
在這裡列出常見的 Code Smell 清單，提供 設計和派工做 review 的參考及早察覺問題
- Ticket 設計派工方法論
本方法論提供完整的 Ticket 設計和派工機制，解決大型開發任務的協作效率問題，降低實作偏差風險
- 如何建立AI輔助系統開發
建立從理論到實踐的完整閉環
- 敏捷開發方法論
基於敏捷重構方法論追加文件設計規範以及實際跑一陣子後的範例說明
- v0.9.0 錯誤處理系統重構工作日誌
實際使用敏捷模式工作的工作日誌
- Claude Code Hook 系統 Exit Code 實驗
建立 Claude 內建自檢、Hook 系統驗證、修復模式補救的完整防護體系，從根本預防逃避行為
- Package 導入路徑語意化方法論
跨語言的導入聲明語意化原則，讓程式碼架構一眼可見
- AI 任務逃避偵測與預防三層防護方法論
建立 Claude 內建自檢、Hook 系統驗證、修復模式補救的完整防護體系，從根本預防逃避行為
- 如何要求ai使用正確的格式撰寫md文件
ai 寫的md會有許多格式上的錯誤，需要讓他先檢查再修正
- 開始一個新專案的做法
我已經跟AI描述過我的需求，請AI建立了相關的需求文件，現在要開始建立新專案
- 開始一個新專案的測試規劃
從測試開始規劃專案流程，分析事件交互的需求，之後再依據測試實作
- 大規模系統遷移方法論
描述如何設計重構的流程和檢驗的方法論
- 在文章中加入圖片的語法
Hugo 文章插圖的寫法、width / caption 參數、以及圖片路徑規則。