aicodeguide：把 AI 寫程式的散落資源收成一本可 PR 的指南
AI Code Guide is a roadmap to start coding with AI
秒懂
- 它是什麼？
- automata/aicodeguide 由 Vilson Vieira 與 Eric S. Raymond 掛名，用 FAQ 式結構整理 AI coding、vibe coding 與 agentic coding 的實務與連結。它的價值在於選材與持續更新，不在於可安裝的程式碼，而授權與版本資訊在現有素材中並未交代。
- 適合誰用？
- 已經在寫程式、但還沒把 AI 助手納入日常工作流程的工程師，以及想理解 vibe coding 這條路線的非傳統開發者，可以從它的 FAQ 結構與資源清單開始讀。需要可執行工具、可安裝套件或明確授權條款的人，這份倉庫給不了答案：素材中沒有 license 欄位、沒有 release，主要語言也標示為 unknown，連程式碼與文件的比例都無法從描述判斷。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 176 天前。
- 用什麼語言寫的？
- GitHub 沒有提供這個儲存庫的主要語言。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一份文件型倉庫，不是可安裝的套件
從倉庫描述與 README 的內容判斷，aicodeguide 是一份以文字為主的指南，而不是函式庫或命令列工具。README 通篇沒有安裝指令、沒有相依套件清單、沒有 API 介面，只有章節、說明段落與外部連結。主要語言欄位顯示為 unknown，這與「內容以 Markdown 為主、沒有明顯的程式碼主體」相符。倉庫沒有檢索到任何 release，最後推送時間為 2026-03-23，代表它以滾動更新的方式維護，而不是以版本號發布。對讀者來說，這意味著採用它的方式是 clone 下來讀，或是直接看首頁 aicode.guide，而不是把它加進 build 流程。
它想解決的問題：資源散落，而不是工具不足
README 的開頭把動機講得很直白：模型每週都在出新的，工具、編輯器、協定（文中點名 MCP、A2A、SLOP）不斷冒出，而「Everything is scattered in different places, websites, repos, YouTube videos, etc.」。這份指南要處理的是資訊聚合與篩選，不是技術缺口。作者在開頭就把讀者切成兩類。第一類是已經會寫程式、但還沒用 AI 助手的人，指南提供近期工具與實務做法；第二類是完全沒寫過程式、被 vibe coding 吸引想自己做 SaaS 的人，作者說會盡量「remove obscurity」，同時對「just hype」保持批判。這個雙讀者設定決定了它的寫法：不能假設讀者懂編譯器，也不能假設讀者懂 agent loop。
FAQ 式結構與資源清單的維護方式
README 說明整份指南刻意寫成 FAQ-ish 的形式，讓讀者可以直接搜尋、跳到想看的問題，不必從頭讀到尾。每個章節底下都有 Resources 清單，而作者表示清單會持續更新，最新的項目放在最上面。這是一個很具體的維護約定：排序本身就是時間戳，讀者可以從清單頂端判斷某個章節最近是否有人動過。貢獻路徑也寫在 README 裡，發現遺漏可以開 PR 或 issue，或到 Discord 分享。這種「文件即產品」的做法讓更新成本很低，但也讓品質取決於維護者與社群是否持續投入。README 沒有提到任何審核流程、編輯準則或事實查核機制，這是選材類專案常見的弱點。
三個名詞的分界，以及它選擇不談的事
指南花了一節區分 AI coding、vibe coding 與 agentic coding。它把 AI coding 定義為用 LLM 及周邊工具協助寫軟體的任何方式，並指出這條線可以追溯到 1950 年代用 Lisp 生成程式碼，現在主引擎是 LLM，也開始出現 neurosymbolic 的混合路線。vibe coding 被描述為「AI coding cranked up」，作者引 Karpathy 在 2025 年的貼文作為術語來源，並說這種模式下你不太在意產生的程式碼，只給提示、期待 AI 全部寫完。agentic coding 則是讓 agent 在迴圈裡跑很多輪，最好帶有測試之類的回饋訊號，也可以用 orchestrator（文中點名 GasTown）同時跑多個 agent。作者最後選擇用 AI coding 當總稱。這一段的價值在於詞彙對齊，但它沒有給出各模式的失敗案例或成本比較，對於想選工具的人來說仍然偏薄。
兩種使用姿態：AI 當副駕駛，以及你當副駕駛
在 How can I use it 一節，指南把用法分成兩類。第一類是 AI 當 copilot：用模型增強自己，例如開 ChatGPT 腦力激盪 SaaS 點子，或用 Cursor 自動補完 docstring，作者認為這在創意探索與自動化枯燥工作上收益明顯。第二類是 AI 當 pilot，你當 copilot，也就是 vibe coding 的位置，文中具體提到 Cursor Agent 的 YOLO 模式，以及用 `--dangerously-skip-permissions` 旗標執行 Claude Code。這個旗標名稱本身就說明了風險：它會略過權限確認。指南把它寫成「信任 agent 做的一切」，並接著說這種方式「demands some good practices on how to design systems」，但提供的 README 內容在此截斷，沒有交代那些實務是什麼。這是全文最需要讀者自己補齊的地方。
何時它會是錯的工具
如果你的需求是自動化、可重現或可稽核，這份指南幫不上忙。它沒有可執行的程式碼、沒有測試、沒有 CI 設定，主要語言未知，也沒有任何 release 可供鎖定版本。想找一份能放進 repo 的 AI 使用政策、或想要一份可被工具解析的規則檔（例如給 agent 讀的設定），這裡沒有。另一個限制是時效性。README 自己承認 AI 變化很快、作者盡力更新，但一份以外部連結為主的文件，其價值會隨著連結失效而衰減。素材中無法確認這些連結目前的存活率，也無法確認首頁 aicode.guide 與倉庫內容是否同步。若你需要的是穩定、可引用的技術規格，這份倉庫的性質與你需要的東西不同。
與 LLM 程式碼生成研究文獻的差別
同樣處理 AI 寫程式這個題目，學術路線與這份指南走的是完全不同的路。以 LLM 程式碼生成為主題的研究工作，通常會定義基準任務、報告通過率一類的量化指標，並附上可重現的實驗設定，產出的是可被引用的方法與數字。aicodeguide 走的是相反方向：它不產生新數據，而是把既有的文章、影片、podcast 與部落格整理成入口。README 的 Resources 清單就是這個取向的證據，清單裡同時出現 Karpathy 的演講、Simon Willison 的長文、Steve Yegge 的系列文章與 Mary Rose Cook 的實務建議，來源橫跨影片、電子報與個人部落格。這種編排適合建立全景，不適合驗證某個工具在你的程式庫上到底有沒有用。要判斷後者，你仍然得自己跑一次。
維護成本、授權與採用前該確認的事
維護成本落在兩個地方。一是連結與內容的更新，作者已把 Discord 與 PR 設為回報管道，代表這是一份需要社群持續餵養的文件。二是讀者的時間：FAQ 結構降低了檢索成本，但沒有解決「讀完之後要選哪個工具」的問題，因為指南刻意不給單一答案。授權方面，現有素材沒有提供 license 欄位，因此無法判斷能否重製、翻譯或商用。若你打算把內容搬進內部訓練教材，必須先到倉庫根目錄確認是否有 LICENSE 檔案，這是採用前的第一個動作。第二個動作是確認首頁 aicode.guide 與倉庫的關係，因為 README 把它列為 Homepage，但素材沒有說明兩者是否為同一份內容的不同呈現。第三個動作是檢查你關心的那個章節，其 Resources 清單頂端是否為近期項目，這比看任何總體評價都更能反映該節是否仍有人維護。
編輯結論
已經在寫程式、但還沒把 AI 助手納入日常工作流程的工程師，以及想理解 vibe coding 這條路線的非傳統開發者，可以從它的 FAQ 結構與資源清單開始讀。需要可執行工具、可安裝套件或明確授權條款的人，這份倉庫給不了答案：素材中沒有 license 欄位、沒有 release，主要語言也標示為 unknown，連程式碼與文件的比例都無法從描述判斷。採用前先確認三件事：倉庫根目錄是否有 LICENSE 檔案、首頁 aicode.guide 是否提供與 README 不同的內容、以及 Discord 邀請連結是否仍然有效，因為 README 把它當成主要的更新回報管道。
社群筆記