Vibe Coding / Agentic Flow 面試題集

注：本題集不存在唯一標準答案。文中的“參考答案”主要用於啟發思考，方便讀者建立自己的判斷框架。

適用對象：每天使用 Claude Code、Codex 等 agentic CLI 工具的開發者，尤其是希望把 AI 編程從“人機聊天”升級為“工程化工作流”的用戶。

目錄

1. 背景知識篇 2. 細節梳理篇 3. 工作流篇 4. 系統設計篇：開放思辨 5. 概念哲學篇：開放思辨 6. 附錄：推薦學習路徑 7. 參考鏈接

一、背景知識篇

Q1. 什麼是 /command？它和 skill 的區別是什麼？什麼時候用 command，什麼時候用 skill？

參考答案

/command，也就是 Slash Command，是 Claude Code 早期的擴展機制。用戶可以在 .claude/commands/ 下放置 .md 文件，然後通過在對話中輸入 /command-name 來觸發。本質上，它是“用戶主動調用的一段 prompt 片段”。

Skill 是新一代擴展機制，一般位於 .claude/skills/<name>/SKILL.md、~/.claude/skills/ 或 plugin 中。它和 command 的主要區別在於：

實際使用中，幾乎所有新場景都應優先考慮 skill。尤其是當你希望模型在合適時機自動啟用某套規程，或者需要附帶腳本、示例文件、模板時，skill 更合適。

command 仍然可以用於少數簡單場景，例如團隊遺留資產，或者某些必須由用戶顯式觸發的一行 prompt 包裝。但新項目中不建議繼續重度依賴 command。

Q2. 什麼是 agent？什麼情況下使用 agent，什麼情況下使用 skill？

參考答案

Agent，尤其是 Sub-agent，可以理解為一個擁有獨立 system prompt、獨立上下文窗口、獨立工具白名單的“小型 Claude”。在 Claude Code 中，sub-agent 通常通過 .claude/agents/<name>.md 定義，由主對話派發任務。Sub-agent 完成任務後，只把總結返回給主對話，中間的大量搜索、讀取、日誌輸出不會污染主上下文。

Skill 則是一套指令或規程。它不開新上下文，而是在當前對話裏指導 Claude 接下來怎麼做。

一個簡單判斷原則是：

• 如果任務是在告訴 Claude 一套工作規程，例如“提交前先跑 lint 和測試”，用 skill。
• 如果任務會產生大量工具輸出，例如讀幾十個文件、跑很多 grep、分析日誌，用 agent。
• 如果任務只是讀取一個已知文件，主對話直接讀即可，不必開 agent。
• 如果任務需要把完整推理過程留在主對話裏，就不要交給 sub-agent。

Q3. Sub-agent 是什麼？Sub-agent 之間可以互相通信嗎？

參考答案

Sub-agent 的核心特徵是：獨立上下文、獨立工具集、只向主對話返回 summary。

默認情況下，sub-agent 之間不能直接通信。它們的通信模型更像星型結構：主對話是中心節點，所有 sub-agent 都只和主對話通信。如果 A agent 的發現需要傳給 B agent，通常由主對話轉述。

這種設計的好處是：

• 信息匯聚到主對話，便於用戶審計。
• 避免 agent 之間形成不可控的循環對話。
• 防止上下文和工具調用成本失控。

實驗性的 Agent Teams 模型可能引入同級 agent 之間的消息通信能力，但那已經是另一套更複雜的協作模型。

Q4. Agent Team 和 Sub-agent 最大的區別是什麼？

參考答案

Sub-agent 更像“僱一個臨時工去做一件事，回來彙報”。它通常是一次性的，主對話發起任務，sub-agent 執行，然後返回 summary。

Agent Team 更像“組建一個長期協作的小團隊”。每個 teammate 可以有獨立角色、獨立上下文，並可能通過消息機制互相溝通。

現實中，大多數日常開發任務用 sub-agent 已經足夠。Agent Team 更接近多 agent 協作研究方向，適合複雜項目，但也更難調試。

Q5. MCP 是什麼？它和 API 接口的區別是什麼？

參考答案

MCP，即 Model Context Protocol，是一種把外部工具、資源和 prompt 以標準格式暴露給大模型客戶端的協議。一個 MCP server 可以聲明自己提供哪些 tools、resources、prompts，客戶端連接後可以自動發現並調用。

裸 API 和 MCP 的區別可以這樣理解：

類比一下：API 是“每家形狀不同的接口線”，MCP 更像“面向 LLM 工具調用的 USB-C”。

它的核心價值不只是傳數據，而是讓工具具備“自描述能力”：模型可以知道工具叫什麼、參數是什麼、是否可寫、是否需要確認，從而推理什麼時候調用、怎麼調用。

Q6. Sub-agent 可以再派生它自己的 sub-agent 嗎？

參考答案

通常不可以。Sub-agent 不應再啟動自己的 sub-agent。

這樣設計主要是為了避免三個問題：

1. 無限遞歸：如果 agent 可以無限派生 agent，調用樹很容易失控。 2. 信息不可審計：嵌套太深後，主對話難以知道每層到底發生了什麼。 3. 上下文和成本爆炸：每層 agent 都可能擁有獨立上下文，費用和延遲會迅速上升。

如果確實需要“嵌套委託”，更好的做法是：

• 讓主對話扁平化地派發多個 sub-agent。
• 在 sub-agent 內部使用 skill 組織步驟。
• 對極複雜任務，考慮 Agent Team，但要設置明確的邊界和預算。

二、細節梳理篇

Q7. CLAUDE.md / AGENTS.md 是什麼？加載順序和優先級如何？

參考答案

CLAUDE.md 和 AGENTS.md 可以理解為項目或用戶級別的“持久 prompt 注入”。它們用於聲明 agent 每次啟動時都應該知道的規則，例如代碼風格、測試命令、禁止修改的文件、提交規範等。

常見層級包括：

建議不要把它寫成項目介紹文章，而要寫成 agent 必須遵守的硬規則。例如：

• 修改代碼前先讀相關測試。
• 不要改 .env 和密鑰文件。
• 完成後必須運行 npm run typecheck。
• 不要新增不必要的依賴。

一個實用經驗是：每個文件儘量控制在 200 行以內。太長的內容應拆分為獨立文檔，再通過引用方式組織。

Q8. Hooks 是什麼？列舉幾種常用 hook 場景。

參考答案

Hook 是在 Claude Code 或類似 agentic 工具生命週期事件上註冊的確定性回調。它不是由模型“記得去做”，而是由工具運行時強制執行。

常見事件包括：

• 工具調用前：例如阻止危險命令。
• 工具調用後：例如文件修改後自動格式化。
• Session 開始時：例如注入當前 git 狀態。
• 停止時：例如發桌面通知。

常用場景包括：

Hooks 的價值在於“確定性”。Prompt 可能被模型忽略，但 hook 是工具層面的約束。

Q9. Permission Mode 有哪些？各自適合什麼場景？

參考答案

Permission Mode 決定 agent 在執行文件讀寫、命令運行、外部工具調用時是否需要用戶確認。

原則上，越接近生產環境，權限越應保守；越接近一次性實驗或隔離沙箱，權限可以更開放。

Q10. /compact 時，哪些上下文會保留，哪些會丟失？

參考答案

/compact 的本質是壓縮對話上下文。它會保留部分高優先級信息，但不會完整保留歷史工具調用細節。

通常會保留或重新注入的內容包括：

• System prompt。
• 項目級規則文件，例如 CLAUDE.md。
• 用戶或項目 memory。
• 對話摘要。
• 部分高優先級 skill 描述。

容易丟失的內容包括：

• 歷史工具調用的完整輸出。
• 曾經讀過但沒有寫入持久文件的細節。
• 只存在於對話裏的臨時約定。
• 某些按需加載工具的完整 schema。

實踐建議是：不要把長期約束只放在聊天裏。重要規則應寫入 CLAUDE.md、AGENTS.md、memory、PROGRESS.md 或項目文檔。

Q11. Plugin 和 Skill 的關係是什麼？

參考答案

Skill 是一個能力單元；Plugin 是一個打包發佈的擴展包。

一個 plugin 可以包含：

• 多個 skills。
• sub-agent 定義。
• hooks。
• MCP server。
• LSP server。
• 二進制工具。
• 默認 settings。

可以這樣理解：skill 是零件，plugin 是裝好的工具箱。團隊內部如果有一套穩定的 AI 編程流程，就可以把它打包成 plugin，讓新成員一鍵安裝。

Q12. 什麼是 ToolSearch / Deferred Tools？為什麼要這樣設計？

參考答案

Deferred Tools 的核心思想是：啟動時不把所有工具的完整 schema 全部塞進上下文，而是先讓模型知道工具名。等模型真的要用某個工具時，再通過 ToolSearch 或類似機制加載詳細參數結構。

這樣設計的原因包括：

1. 節省 token：大型 MCP server 可能有幾十甚至上百個工具，全部 schema 非常占上下文。 2. 降低注意力噪聲：不相關工具長期掛在 prompt 裏，會干擾模型決策。 3. 按需加載：只有真正需要時才加載詳細說明。

代價是第一次使用某個工具時可能多一次 round trip，但總體上更划算。

三、工作流篇

Q13. 接到一箇中等複雜度的新功能任務，應該怎麼用 agentic 工具拆解？

參考答案

一個典型流程可以是：

1. 先進入 plan mode，只讀探索代碼，不急着改。 2. 用 Explore sub-agent 並行搜索相關文件，找入口、數據流、測試位置。 3. 由主對話或 Plan sub-agent 產出 TDD 風格方案：驗收標準、測試用例、最小實現、驗證策略。 4. 用第二個模型或 review agent 做 cross-model review，補盲點。 5. 在關鍵設計岔路上詢問用戶，而不是擅自決定高影響改動。 6. 退出 plan mode，進入可編輯模式。 7. 先寫或更新測試，再實現功能。 8. 實現後跑相關測試、typecheck、lint。 9. 最後用 review skill 或 code-review agent 自查。

這個流程的重點不是“多開 agent 顯得高級”，而是把探索、設計、實現、驗證、覆盤拆開。

Q14. 什麼時候應該開 sub-agent，什麼時候不該？

參考答案

應該開 sub-agent 的情況：

• 要讀 10 個以上文件做調研。
• 要跑大量 grep、find、日誌分析。
• 要做獨立代碼 review 或安全 review。
• 要並行處理多個無依賴子任務。
• 工具輸出會很長，不希望污染主上下文。

不應該開 sub-agent 的情況：

• 任務只需要 1–3 個工具調用。
• 只是讀取一個已知路徑。
• 任務需要頻繁和用戶確認。
• 你希望完整推理過程保留在主對話中。

一句話：sub-agent 適合“重搜索、重讀取、重日誌”的任務，不適合“短平快”的任務。

Q15. 怎麼避免主對話上下文被污染？

參考答案

可以從幾個方面控制：

• 大量讀取和調研交給 Explore sub-agent，只讓它返回 summary。
• 長命令輸出用 head、tail、grep 收斂，不要把幾千行日誌直接塞進對話。
• 重複性流程封裝成 skill，而不是每次重新粘貼一大段規則。
• 階段性完成後及時 /compact。
• 重要長期信息寫進 CLAUDE.md、AGENTS.md、memory 或 PROGRESS.md。
• 不要讓 agent 反覆讀同一個文件；文件狀態應通過 diff、測試和版本控制確認。

核心原則是：上下文不是越多越好，而是信噪比越高越好。

Q16. 代碼出了 bug，如何用 agentic 工具調試？

參考答案

比較穩妥的流程是：

1. 不要急着改代碼，先復現 bug。 2. 寫一個能穩定失敗的最小測試或最小用例。 3. 確認測試確實失敗，證明你理解了問題。 4. 用 Explore 找出 bug 發生路徑上的相關文件。 5. 提出假設，然後逐個驗證，而不是猜測式打補丁。 6. 修復後跑相關測試。 7. 最後跑全量或關鍵驗證命令。 8. 如果 agent 連續多次修不對，停止當前上下文，換思路或讓另一個模型獨立診斷。

Agent 調試最怕的是“邊猜邊改”。沒有可復現用例，模型很容易把代碼越改越亂。

Q17. 在多人協作倉庫裏，如何讓 agentic 工作流團隊化？

參考答案

團隊化的關鍵是把個人經驗沉澱為倉庫資產。

共享層可以包括：

• 倉庫根目錄 CLAUDE.md / AGENTS.md：團隊硬規則。
• .claude/skills/：共享工作流。
• .claude/agents/：共享 sub-agent。
• .claude/settings.json：共享 permission、hooks、工具白名單。
• PR 模板：要求說明 AI 參與的關鍵決策和驗證命令。

個人層可以包括：

• CLAUDE.local.md：個人偏好，通常不提交。
• .claude/settings.local.json：個人權限覆蓋。

更進一步，可以把團隊通用能力打包成 plugin，統一安裝、統一升級、統一維護。

四、系統設計篇：開放思辨

以下問題沒有標準答案，重點是訓練取捨框架和風險意識。

Q18. 設計一個 agentic 低代碼平台，優先考慮哪些原則？

討論方向

首先要確定 source of truth。到底是 agent 生成的代碼為準，還是低代碼 DSL 為準？二者雙向同步看似美好，實際很容易變成工程地獄。

還要考慮：

• 可逆性與版本控制：agent 一次改 50 個組件後，必須能 diff、revert、review。
• 沙箱與權限分級：平台用戶的 agent 不能直接訪問數據庫，必須經過權限網關。
• 上下文供給：業務知識如何進入 agent？靠用戶寫規則，還是從已有文檔自動提煉？
• 失敗可觀測性：agent 調用第三方 API 或 MCP 失敗後，必須能回放。
• 關鍵決策確認：不要替代用戶思考，高影響決策必須顯式確認。
• 成本可見：每個操作的 token、API 調用、時延都要可見。

好的 agentic 低代碼平台不是“魔法按鈕”，而是一個可審計、可回滾、可組合的工程系統。

Q19. 設計企業內部 MCP 網關，如何處理權限、審計、限流？

討論方向

一個企業級 MCP 網關至少要處理以下問題：

• 權限：不同角色能看到不同工具。只讀角色不應該看到 delete_* 工具的 schema。
• 審計：每次 tool call 都記錄 user、agent_id、參數、返回大小、耗時和結果狀態。
• 限流：限制同一用戶或同一 agent 的 QPS、併發數和日調用量。
• 數據脱敏：返回給 agent 前先處理 PII、密鑰、內部敏感字段。
• 降級策略：後端服務異常時返回 structured error，而不是無限等待。
• 版本管理：tool schema 變更要有版本號，避免舊客戶端突然失效。
• 租户隔離：不同團隊、不同項目的工具和數據必須隔離。

MCP 網關的核心不是“接入更多工具”，而是“安全地讓模型使用工具”。

Q20. 多 agent 協作模型應該選擇星型還是網狀？為什麼？

討論方向

星型結構的優點是清晰、可控、易審計。主對話是中心，所有 sub-agent 都向它彙報。缺點是主對話會成為瓶頸，並行度有限。

網狀結構更接近真實團隊，多個 agent 可以互相溝通，理論上並行度更高。但問題也明顯：

• agent 之間可能循環對話。
• 上下文容易爆炸。
• 責任邊界不清。
• 調試難度大幅提升。

現實中，大多數任務星型已經夠用。只有在複雜多角色任務中，才值得嘗試網狀協作，而且必須配合消息預算、線程上限、對話圖可視化和強審計機制。

更深一層的問題是：多 agent 協作的 ROI 是否真的高於“一個更強的單 agent”？如果模型能力繼續增強，多 agent 編排可能只在少數複雜場景中有穩定價值。

Q21. 設計一個 AI 安全 review agent，要避免哪些坑？

討論方向

安全 review agent 不能只看 diff。很多安全問題出現在調用鏈和上下文中，而不是當前改動的幾行代碼裏。

還要避免：

• 盲信測試通過：測試覆蓋不到的地方，往往才是漏洞高發區。
• 自己執行攻擊命令：review 階段應儘量只讀，避免 review agent 變成攻擊面。
• 追求零誤報：安全 review 寧可合理誤報，也不要漏掉高危問題。
• 缺乏分級：必須區分 P0、P1、P2，幫助人工聚焦。
• 不可解釋：不能只說“unsafe”，要說明為什麼危險、影響範圍是什麼、如何修。

更穩妥的做法是：一個模型 review，另一個模型 cross-check，再由人工做最終判斷。

Q22. 設計長期記憶機制，如何決定記什麼、不記什麼？

討論方向

應該記的內容包括：

• 用戶反覆糾正過的代碼風格。
• 項目級硬約束。
• 常用命令。
• 容易忘記但長期有效的工程信息，例如端口號、測試入口、文檔位置。

不應該記的內容包括：

• 一次性的臨時對話。
• 含有敏感數據的內容。
• 已經過時的 bug 狀態。
• 不確定是否長期有效的猜測。

長期記憶還需要更新機制：寫入時合併，避免重複；定期清理過時條目；允許用戶審查、編輯、刪除。跨項目共享也要謹慎：偏好可以跨項目，項目知識不應隨便跨項目。

五、概念哲學篇：開放思辨

Q23. 為什麼應該保持 context 簡單？一個塞滿信息的 prompt 不是更好嗎？

討論方向

Context 的價值不在於長，而在於信噪比。

塞滿信息會帶來幾個問題：

• 注意力稀釋：關鍵規則被大量無關信息淹沒。
• 成本上升：每次推理都要處理更多 token。
• 延遲增加：長上下文通常意味著更慢的響應。
• 可調試性下降：出問題時，很難定位是哪條規則衝突。
• 演化困難：複雜 prompt 像一團 spaghetti，越改越亂。

好的 context 不是“少信息”，而是“只放當前任務真正需要的信息”。

Q24. Agent 應該主動還是被動？什麼時候該問用戶，什麼時候該自己決定？

討論方向

判斷標準可以看三個維度：

1. 行動是否可逆：可逆的本地改動可以自決；不可逆的 push、delete、send email 必問。 2. 影響半徑：隻影響本機可以更主動；影響團隊、生產、客戶必須謹慎。 3. 不確定度：agent 自己沒把握時應該問，而不是賭。

真正好的 agent 不是“什麼都問”，也不是“什麼都不問”，而是問對問題：關鍵岔路問，雞毛蒜皮不打擾。

Q25. Vibe Coding 到底是 hype，還是範式革命？

討論方向

Hype 派會說：這只是更智能的自動補全。複雜項目裏 agent 仍會犯低級錯誤，維護成本被低估。

範式派會說：編程的主單位正在從“行 / 函數”上升到“意圖 / 約束”。工程師的角色從打字員變成架構師、審稿人、系統設計者。

比較穩妥的中間立場是：它確實是範式變化，但不是 1:1 替代。它會放大高水平工程師的能力，因為他們能給出更好的 spec 和 review；也會放大低水平使用者的破壞力，因為他們可以更快地產出垃圾代碼。

關鍵追問是：

• 如果 agent 寫代碼，知識在哪裏沉澱？倉庫、文檔、測試，還是個人大腦？
• 代碼 review 的重要性是否會超過寫代碼本身？
• 初級崗位和編程教育會如何變化？

Q26. 一個 agent 反覆改不對一個 bug，應該讓它繼續試，還是關掉自己上？

討論方向

如果 agent 已經反覆嘗試同一種錯誤解法，說明上下文可能被污染了。繼續讓它燒 token，往往只會把死衚衕挖得更深。

更好的做法是：

• 給 agent 設定嘗試上限，例如連續 3 次失敗就停。
• 停止當前修補循環，重新整理最小復現、日誌、失敗測試。
• 換一個模型做獨立診斷。
• 必要時人工接手關鍵路徑。

Agent 卡住通常不是“推理不夠努力”，而是信息缺失、測試不清、上下文污染或方向錯誤。

Q27. 為什麼 TDD 在 agentic 工作流裏比傳統工作流更重要？

討論方向

Agent 容易自信地寫錯。它可能編 API、編字段、編返回值。測試是少數能客觀裁判它是否真的完成任務的機制。

TDD 對 agentic 工作流尤其重要，因為：

• 測試是和 agent 溝通的契約。
• 失敗測試給 agent 提供明確反饋循環。
• 測試把模糊需求變成可執行規約。
• 驗收測試能防止“看起來完成了，其實沒完成”。

但也要注意：不要完全讓 agent 自己寫測試、自己寫實現、自己宣佈通過。關鍵驗收測試和安全測試最好由人寫，或由另一個模型獨立 review。

Q28. “agent 寫的代碼可讀性差”怎麼辦？這是工具問題還是用法問題？

討論方向

兩者都有。

工具側，模型確實容易過度抽象、過度防禦、過度註釋。用法側，如果用戶不給約束、不 review、直接接受 first try，垃圾代碼一定會堆積。

可操作的改法包括：

• 在 CLAUDE.md 或 AGENTS.md 中寫明可讀性硬規則。
• 限制函數長度、命名風格、註釋風格。
• 把“簡化 / 重構 / 刪冗餘”作為獨立步驟。
• 用 code-review skill 強制 agent 自審。
• 對關鍵模塊要求人工讀一遍 diff。

如果完全不讀 agent 寫的代碼，本質上就是把生產代碼外包給一個不會被追責的實習生。

Q29. “我讓 agent 跑了一整晚，它做了什麼我看不懂”——這是 agent 的問題，還是用戶的問題？

討論方向

兩邊都有責任。

工具方應提供可觀測性：文件 diff、命令日誌、關鍵決策點、失敗記錄、階段性總結。

用戶方也要設置邊界：不要無約束地讓 agent 跨夜亂跑。長任務應拆成階段，每個階段有明確目標、權限範圍和 checkpoint。

越長的自主任務，越需要強約束。完全無人監督的長跑 agent，有點像“無人監督的初級實習生 + sudo 權限”，在生產環境中風險很高。

Q30. Agentic 工具最終會讓程序員這個職業消失嗎？

討論方向

更可能的情況不是“程序員消失”，而是“程序員的抽象層次上升”。

會被削弱的是那種只負責把明確 spec 翻譯成代碼的崗位。仍然重要的是：理解需求、拆分系統、判斷對錯、承擔責任、維護長期架構。

未來可能更重要的角色包括：

• Agent 架構師：設計 agent 協作圖、skill 庫和上下文策略。
• AI 審稿員：高速 review agent 輸出。
• Context 工程師：把領域知識結構化為 agent 可消化的形式。
• 工程負責人：決定哪些任務可以自動化，哪些必須人工把關。

歷史類比是：編譯器沒有讓程序員消失，但讓手寫彙編的人大幅減少。AI agent 也可能類似：不是取消工程師，而是把工程師推向更高抽象層。

六、附錄：推薦學習路徑

入門階段

先讀官方文檔，跑通最基礎能力：

• 項目規則文件：CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• Codex / Claude Code 的基本權限模式

目標不是記概念，而是知道它們分別解決什麼問題。

進階階段

把自己最常做的 3 件事封裝起來，例如：

1. 生成 commit message。 2. 寫 PR 摘要。 3. 修改代碼後自動跑測試和 typecheck。

這一步的關鍵是從“我每次都對 AI 重複說一遍”升級到“把流程沉澱為項目資產”。

高級階段

為團隊或個人項目建立一套 agentic workflow：

• CLAUDE.md / AGENTS.md：長期規則。
• skills/：可重用規程。
• agents/：調研、review、debug 等專用角色。
• hooks/：確定性約束。
• PROGRESS.md：長任務狀態記錄。
• TASKS.md：任務拆解。

專家階段

開始研究更複雜的問題：

• hooks 在 PreToolUse 上的權限決策。
• MCP 網關和企業權限模型。
• 多 agent 協作的消息預算和審計。
• 長任務 overnight workflow 的 checkpoint 設計。
• 如何讓測試、文檔、規則文件共同成為 agent 的可靠上下文。

七、參考鏈接

• Claude Code Docs：llms.txt
• Claude Code Docs：Hooks Reference
• Claude Code Docs：Automate workflows with hooks
• OpenAI Codex：Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex：Installation Docs
• OpenAI Cookbook：Codex Prompting Guide

更多 Codex 實踐可以參考 《深度用好 Codex》；如果想快速在 Claude 工具間切換，參考 CC Switch 工具介紹。

常見問題

這篇文章適合什麼水平的開發者？

可參考正文中的「適用對象」說明；本站編程欄目的文章覆蓋從入門到 AI 編程工作流等不同層次，每篇會有不同的預設背景。

文章中的工具或命令在不同系統上會有差異嗎？

會。macOS、Linux 和 Windows 的終端環境、路徑格式和命令語法存在差異，文章中若未說明具體系統，建議結合官方文檔對應調整。

推薦配合哪些 AI 工具學習編程？

Claude Code 和 Codex 是目前能力較強的編程 AI 工具，可以用來解釋代碼、補全邏輯、調試錯誤和生成腳本。相關工具介紹可參考本站 CC Switch 工具文章 和 Vibe Coding 面試題集。

學編程最重要的習慣是什麼？

動手做比看教程更重要。建議儘早找一個真實項目（哪怕很小）來練手，遇到問題時查文檔和代碼，而不只是看完理論再說。