真實專案貫穿實戰

你是 Gemini CLI 工作流設計顧問。

【角色】
Gemini CLI 工作流設計顧問，按最小夠用、安全優先的原則給可落地方案。

【輸入】
- 專案型別和階段：___
- 最常做的任務：___
- 用得彆扭 / 重複返工的環節：___
- 團隊還是個人：___

【工作流程】
1. 診斷目前用法的不順點
2. 按理解→規劃→執行→驗證串工作流
3. 把長期約定沉澱進 GEMINI.md
4. 給固化習慣的建議

【輸出規範】
▌一、不順點
▌二、串起的工作流
▌三、該進 GEMINI.md 的約定
▌四、固化建議

【硬約束】
- 工作流可落地，不堆理論
- 長期約定進 GEMINI.md
- 驗證環節不能省
- 不要替我臆測情況或編造不存在的能力，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

這一篇把前面的概念串成一個真實專案流程。目標不是展示炫技，而是形成一套可重複、可驗證、低干擾的 Gemini CLI 工作方式。

場景

假設你要給一個文件站補一個新產品欄目。儲存庫裡還有其他 agent 在改別的欄目，所以你必須互不干擾。

第一步：只讀進入專案

先進入專案目錄，再執行 gemini。

第一條 prompt：

請只讀掃描目前專案，不要修改檔案，不要執行寫入命令。請說明專案技術堆疊、文件目錄、導航機制、驗證命令，以及我應該只改哪些路徑。

輸出裡必須能看到：

• 專案技術堆疊。
• 內容目錄。
• 導航檔案。
• 檢查命令。
• 不應觸碰的併發改動區域。

第二步：確認上下文真相源

讓 Gemini CLI 查：

請讀取目前目錄和父目錄的規則檔案，確認本次任務應遵守哪些 CLAUDE.md、AGENTS.md 或 GEMINI.md 規則。

如果專案還沒有 GEMINI.md，可以先生成一個小範圍專案規則草案，但不要把它寫入儲存庫，除非團隊確認。

第三步：寫計劃，不直接改

我要新增 Gemini CLI 教學欄目。請先給執行計劃：目錄結構、頁面清單、官方來源、每批修改檔案、驗證方式和停止條件。不要改檔案。

計劃裡應該明確：

計劃裡要明確只改 content/docs/gemini-cli/，不碰其他產品欄目；每批前檢查 git status，每批後跑 types:check 或至少跑 MDX 檢查。

第四步：分批寫入

按批次推進：

1. 建立根頁面和導航。
2. 寫官方教學中文版。
3. 寫從原理到實戰。
4. 補美化元件和交叉連結。
5. 跑驗證。

每批之間都檢查：

git status --short content/docs/gemini-cli

如果發現別人也改了 content/docs/gemini-cli/，暫停合併，不要覆蓋。

併發協作表

第五步：驗證

先做目標目錄檢查：

rg -n "[[:blank:]]+$" content/docs/gemini-cli

再跑專案檢查：

建議按順序跑 pnpm run types:check、pnpm run audit:content、pnpm run audit:quality、pnpm run build。

如果失敗，先判斷是不是本次目錄引起。併發儲存庫裡不要順手修別人改動造成的問題。

第六步：自動化沉澱

當這套流程跑通後，再考慮：

• 用 headless mode 定期對比官方 docs 變更。
• 用 GitHub Action 給 PR 自動檢查文件導航。
• 用 Skill 固化“教學欄目新增流程”。
• 用 hooks 阻止跨欄目誤改。

完整工作流

官方來源採集
  -> 內容藍圖
  -> 根頁面和導航
  -> 官方教學中文版
  -> 從原理到實戰
  -> 美化和交叉連結
  -> 型別檢查和構建
  -> 釋出前複檢

結束標準

一個真實專案任務不是“檔案寫完”就結束。結束標準應該是：

• 頁面能被導航發現。
• 連結不指向不存在的 slug。
• 型別檢查透過。
• 構建透過。
• 併發改動未被覆蓋。
• 官方來源和驗證日期可追溯。

到這裡，Gemini CLI 欄目就從“工具介紹”變成了一套可維護的教學工作流。

交付摘要模板

最後交付時至少說清：

• 修改了哪些路徑。
• 每批驗證跑了什麼。
• 哪些官方來源已複核。
• 是否有併發改動被避開。
• 哪些構建或部署動作還沒做。

這能讓下一位 agent 或人工編輯直接接手，而不是重新猜目前進度。

覆盤標準

真實專案做完後，要覆盤三件事：官方來源是否還需要定期重新整理，驗證命令是否覆蓋內容和構建，是否留下了可複用的 Skill、command 或 checklist。只有把這些沉澱下來，下一次新增欄目才會更快，而不是重新靠口頭經驗。

覆盤還要看併發協作是否順暢：有沒有覆蓋別人檔案，有沒有全域驗證失敗，有沒有因為導航或斷點遺漏導致上線後頁面不可用。真實專案的質量，最終體現在這些細節裡。

如果這些問題反覆出現，就應該把流程沉澱成 checklist 或 command，而不是繼續靠記憶提醒。

這份 checklist 應該進入儲存庫文件或團隊規則，而不是隻留在一次會話總結裡。能被後來者直接複用，才算真實專案流程完成。

官方資料

• 檔案管理教學：docs/cli/tutorials/file-management.md
• 自動化教學：docs/cli/tutorials/automation.md
• 任務規劃（todos）：docs/cli/tutorials/task-planning.md
• 會話管理：docs/cli/tutorials/session-management.md
• 上下文與記憶：docs/cli/tutorials/memory-management.md

回到入口