CodeGraph 管地圖、OpenSpec 管檔案、Impeccable 管門面：一份 Vibe coding 心得裡最值得看的分工邏輯

（專欄｜周允中）

2026 年 11 月 10 日，掘金出現一篇 Vibe coding 工具使用心得，作者整理了幾個月來實際搭配三款工具的做法：CodeGraph 用來排查問題、OpenSpec 用來推進功能、Impeccable 用來打磨頁面。文章本身不長，但它把一件常被忽略的事情說清楚了：Vibe coding 用到後段，難的已經不是讓 AI 產出程式碼，而是三種性質完全不同的工作，該用不同的工具去支撐。

三件事常在同一個專案裡，但解法不同

作者的第一個觀察很樸實：出問題時要找原因、做功能前要想清楚範圍、頁面出來後要調整呈現。這三件事會出現在同一個專案裡，卻很少有人意識到它們需要不同的輔助方式。

對照多數人的實際經驗，狀況通常是這樣的：拿了 AI 工具就一路問下去，排查 bug 和規劃功能用的是同一個對話框，結果上下文混雜，AI 給的答案也跟著發散。這篇心得的價值在於它按「工作的性質」拆工具，而不是按工具的名氣。

CodeGraph：先給 AI 一張地圖

CodeGraph（GitHub：colbymchenry/codegraph）做的事情，用比喻來說，就像替整棟大樓畫好管線圖。程式碼放在哪裡、彼此怎麼呼叫，先整理成可查詢的關係圖，AI 找相關內容時就不用憑記憶猜。作者也坦言，主要衝著官方標榜的省 token 而用。這一點很實際：當程式庫一大，把整包程式碼塞進上下文既貴又慢，先讓工具指出「哪幾段相關」，AI 的第一步就踏得準。

這與我們先前整理過的AI 全棧開發實踐心得方向一致：技能重心正從寫出每一段程式碼，移往設計讓 AI 有效工作的流程。

OpenSpec：把「為什麼做」變成可查的檔案

三個工具裡，OpenSpec（GitHub：Fission-AI/OpenSpec）佔的篇幅最多，因為它對應的是最容易被跳過的環節：動工前把需求講清楚，動工後留下紀錄。

它的預設工作流是這樣走的：openspec init 初始化並選擇 AI 編程工具後，用 /opsx:explore 和 AI 一起討論方案；/opsx:propose 把需求整理成「為什麼做、這次改什麼、怎麼實現、有哪些任務」的文件；人工確認沒有擴大範圍或理解偏差後，/opsx:apply 按任務清單改程式碼；驗收後 /opsx:sync 把功能說明併入正式文件，/opsx:archive 歸檔。

換成日常語言，這就像裝修前先寫施工圖，而不是口頭交代一句「幫我把廚房弄好一點」。口頭交代省事，但三個月後要改水電時，沒有人記得當初為什麼這樣配管。OpenSpec 留下的紀錄，讓下一次需求碰到同一個功能時，可以先查「上次做了什麼、為什麼這樣做」，再決定這次的改動範圍。

作者也點出它的限制：OpenSpec 要整個團隊一起用才有意義。只有一個人寫紀錄、其他人照舊直接改碼，檔案很快就會和程式碼對不上，等於花力氣維護一份會過期的地圖。

Impeccable：功能落地後的最後一哩

Impeccable（GitHub：pbakaus/impeccable）在心得中的角色相對單純：功能做出來之後，繼續調內容組織、視覺層級與留白。作者用它把自己拉回「使用者第一眼看到什麼」的視角，處理哪些資訊該優先、哪些元素該弱化。AI 生成的頁面常有「功能都在、但讀起來喫力」的問題，這個環節補的就是那一段。

所以呢

這篇心得可核實的部分就是三款工具的定位與 OpenSpec 的操作流程，至於各工具的實際效果，僅代表該名作者的使用情境。不過它指向的趨勢和近期的其他訊號互相印證：當 AI 產出程式碼的成本趨近於零，開發者花時間的地方轉向定義範圍、管理脈絡與留下紀錄。企業端也出現同樣的訊號，例如思朗科技面試專問 AI 工具使用的做法，篩選的已經換了一種基本功。

對個人開發者而言，可以從這篇拿走的判斷很簡單：先看自己當下卡在哪一種工作。是找不到問題源頭，還是功能越做越亂，或是頁面怎麼調都不對勁。不同的卡點對應不同的工具類型，而不是找一個「最強的」從頭用到尾。