最佳實踐：清晰描述、檢查點利用、範圍控制與迭代技巧

學完你能做什麼

學完本課，你將掌握：

• 如何編寫高品質的產品描述，讓 AI 理解你的想法
• 如何利用檢查點機制控制每個階段的輸出品質
• 如何透過非目標明確範圍邊界，防止專案膨脹
• 如何透過逐步迭代，快速驗證想法並持續優化

你現在的困境

你是不是也遇到過這些情況：

• "我說的很清楚了，為什麼生成的不是我想要的？"
• "一個地方不滿意，後面全錯了，改起來很痛苦"
• "做著做著功能越來越多，完全沒法收尾"
• "想一次性把所有功能都做出來，結果什麼都沒做出來"

什麼時候用這一招

無論你是第一次使用 AI App Factory，還是已經有過幾次經驗，這些最佳實踐都能幫你：

• 提高輸出品質：讓生成的應用更符合預期
• 節省修改時間：避免錯誤累積，早期發現問題
• 控制專案規模：聚焦 MVP，快速交付
• 降低開發成本：分階段驗證，避免無效投入

🎒 開始前的準備

前置要求

• 已閱讀 快速開始 了解 AI App Factory 的基本概念
• 已閱讀 7 階段流水線概覽 了解完整流程
• 已完成至少一次完整的流水線執行（這樣你對每個階段的輸出有直觀感受）

核心思路

AI App Factory 的最佳實踐圍繞四個核心原則：

1. 輸入品質決定輸出品質：清晰、詳細的產品描述是成功的第一步
2. 檢查點是品質防線：每個階段完成後仔細確認，避免錯誤累積
3. MVP 聚焦：明確非目標，控制範圍，快速交付核心功能
4. 持續迭代：先驗證核心想法，再逐步擴展功能

這些原則來自源碼和實戰經驗的總結，遵循它們能讓你的開發效率提升數倍。

跟我做

技巧 1：提供清晰的產品描述

為什麼

AI 理解你的想法時，只能依賴你提供的文字資訊。描述越清晰，生成的產物越符合預期。

怎麼做

好的產品描述包含以下要素：

• 目標使用者：誰會使用這個產品？
• 核心問題：使用者遇到了什麼困難？
• 解決方案：產品如何解決這個困難？
• 關鍵功能：必須包含哪些功能？
• 使用場景：使用者在什麼情況下使用？
• 約束條件：有什麼限制或特殊要求？

對比示例

❌ 差的描述	✅ 好的描述
做一個健身應用	幫助健身新手記錄訓練的應用，支援記錄運動類型、時長、消耗卡路里，並查看本週訓練統計。目標使用者是剛開始健身的年輕人，核心功能是快速記錄和查看進度，不包含社交分享或付費功能
做一個記帳應用	幫助年輕人快速記錄日常支出的行動端記帳應用，主要功能是記錄金額、選擇分類（飲食、交通、娛樂、其他），查看本月總支出和分類統計。支援離線使用，資料僅保存在本地
做一個任務管理工具	幫助小團隊管理任務的簡單工具，支援建立任務、分配成員、設定截止日期、查看任務列表。團隊成員之間可以共用任務狀態。不需要複雜的工作流程或權限管理

檢查點 ✅

• [ ] 描述中明確了目標使用者
• [ ] 描述中說明了使用者遇到的核心問題
• [ ] 描述中列出了關鍵功能（不超過 5 個）
• [ ] 描述中包含了約束條件或非目標

---

技巧 2：在檢查點仔細確認

為什麼

流水線的每個階段完成後都會暫停檢查點，等待你確認。這是品質防線，能讓你早期發現問題，避免錯誤傳播到後續階段。

如果在這個階段發現問題，只需重跑當前階段；如果等到最後才發現，可能需要回滾多個階段，浪費大量時間和 Token。

怎麼做

每個檢查點確認時，檢查以下內容：

Bootstrap 階段檢查點：

• [ ] input/idea.md 中的問題定義準確
• [ ] 目標使用者畫像清晰具體
• [ ] 核心價值主張明確
• [ ] 假設條件合理

PRD 階段檢查點：

• [ ] 使用者故事清晰，包含接受條件
• [ ] 功能列表不超過 7 個（MVP 原則）
• [ ] 明確列出了非目標（Non-Goals）
• [ ] 未包含技術細節（如 React、API、資料庫）

UI 階段檢查點：

• [ ] 頁面結構合理，不超過 3 頁
• [ ] 可以在瀏覽器中預覽原型
• [ ] 互動流程清晰
• [ ] 審美風格鮮明（避免常見的 AI 風格）

Tech 階段檢查點：

• [ ] 技術棧選擇合理，符合 MVP 原則
• [ ] 資料模型設計簡單，表數量不超過 10 個
• [ ] API 端點列表完整
• [ ] 未引入微服務、快取等過度設計

Code 階段檢查點：

• [ ] 前後端程式碼結構完整
• [ ] 包含測試用例
• [ ] 無明顯的 any 類型
• [ ] 包含 README.md 說明如何運行

Validation 階段檢查點：

• [ ] 驗證報告中無嚴重安全問題
• [ ] 測試覆蓋率 > 60%
• [ ] 依賴安裝無衝突
• [ ] TypeScript 類型檢查透過

Preview 階段檢查點：

• [ ] README.md 包含完整的運行說明
• [ ] Docker 配置可正常建置
• [ ] 本地可啟動前後端服務
• [ ] 包含環境變數配置說明

檢查點確認流程

在每個檢查點，系統會提供以下選項：

• 繼續：如果輸出符合預期，繼續下一階段
• 重試：如果輸出有問題，提供修改意見並重跑當前階段
• 暫停：如果需要更多資訊或想要調整想法，暫停流水線

決策原則：

• ✅ 繼續：所有檢查項都符合要求
• ⚠️ 重試：小問題（格式、遺漏、細節），可以立即修正
• 🛑 暫停：重大問題（方向錯誤、範圍失控、無法修正），需要重新規劃

踩坑提醒

常見錯誤

不要為了"趕緊完成"而跳過檢查點確認！

流水線設計成"每階段暫停確認"就是為了讓你及時發現問題。如果你習慣性地點擊"繼續"，等到最後才發現問題，可能需要：

• 回滾多個階段
• 重新執行大量工作
• 浪費大量 Token

記住：檢查點確認的時間投入，遠小於回滾重做的時間成本。

---

技巧 3：利用非目標控制範圍

為什麼

非目標（Non-Goals）是 MVP 開發的核心武器。明確列出"不做什么"，能有效防止範圍蔓延。

很多專案失敗的根源不是功能太少，而是功能太多。每個新功能都會增加複雜度、開發時間和維護成本。明確邊界，聚焦核心價值，才能快速交付。

怎麼做

在 Bootstrap 階段，明確列出非目標：

## 非目標（本版本不做的功能）

1. 不支援多人協作
2. 不支援即時同步
3. 不支援第三方服務整合（如支付、地圖）
4. 不提供資料分析或報表功能
5. 不包含社交分享功能
6. 不需要使用者驗證或登入功能

在 PRD 階段，將非目標作為獨立章節：

## 非目標（本版本明確不做）

以下功能雖然有價值，但不在本次 MVP 範圍內：

| 功能 | 理由 | 未來規劃 |
| --- | --- | --- |
| 多人協作 | 聚焦個人使用者 | v2.0 考慮 |
| 即時同步 | 增加技術複雜度 | 使用者反應強烈後再考慮 |
| 支付整合 | 非核心價值 | v1.5 考慮 |
| 資料分析 | MVP 不需要 | v2.0 考慮 |

非目標的判斷標準

如何判斷是否應該作為非目標：

• ❌ 這個功能對驗證核心想法不是必需的 → 作為非目標
• ❌ 這個功能會大幅增加技術複雜度 → 作為非目標
• ❌ 這個功能可以透過手動方式替代 → 作為非目標
• ✅ 這個功能是產品存在的理由 → 必須包含

踩坑提醒

範圍蔓延陷阱

常見的範圍蔓延信號：

1. "反正很簡單，順手加一個..."
2. "競品都有這個功能，我們也要..."
3. "使用者可能會需要，不如先做出來..."
4. "這個功能很有趣，能提升產品亮點..."

遇到這些想法時，問自己三個問題：

1. 這個功能對驗證核心想法有用嗎？
2. 如果不做這個功能，產品還能用嗎？
3. 加這個功能會推遲交付時間嗎？

如果答案是"不需要"、"能用"、"會推遲"，那就果斷劃到非目標。

---

技巧 4：逐步迭代，快速驗證

為什麼

MVP（最小可行產品）的核心理念是快速驗證想法，而不是一次性做完美。

透過迭代開發，你可以：

• 早期獲得使用者回饋
• 及時調整方向
• 降低沈沒成本
• 保持開發動力

怎麼做

迭代開發的步驟：

第一輪：核心功能驗證

1. 使用 AI App Factory 生成第一版應用
2. 只包含最核心的 3-5 個功能
3. 快速運行並測試
4. 向真實使用者展示原型，收集回饋

第二輪：基於回饋優化

1. 根據使用者回饋，確定優先級最高的改進點
2. 修改 input/idea.md 或 artifacts/prd/prd.md
3. 使用 factory run <stage> 從對應階段重新執行
4. 生成新版本並測試

第三輪：功能擴展

1. 評估是否達到核心目標
2. 選擇 2-3 個高價值功能
3. 透過流水線生成並整合
4. 持續迭代，逐步完善

迭代實戰示例

場景：你想做一個任務管理應用

第一輪 MVP：

• 核心功能：建立任務、列表查看、標記完成
• 非目標：成員管理、權限控制、提醒通知
• 交付時間：1 天

第二輪優化（基於回饋）：

• 使用者回饋：想給任務加標籤
• 修改 PRD，增加"標籤分類"功能
• 從 UI 階段重新執行流水線
• 交付時間：半天

第三輪擴展（驗證成功後）：

• 增加成員管理功能
• 增加截止日期提醒
• 增加任務評論功能
• 交付時間：2 天

檢查點 ✅

每次迭代前，檢查：

• [ ] 新功能是否與核心目標一致
• [ ] 新功能是否有使用者需求支撐
• [ ] 新功能是否會大幅增加複雜度
• [ ] 是否有明確的驗收標準

---

高級技巧

技巧 5：利用分會話節省 Token

為什麼

長時間運行流水線會導致上下文累積，消耗大量 Token。分會話執行可以讓每個階段獨享乾淨上下文，大幅降低使用成本。

怎麼做

在每個檢查點，選擇"新建會話繼續"：

# 在新的命令列視窗中執行
factory continue

系統會自動：

1. 讀取 .factory/state.json 恢復狀態
2. 啟動新的 Claude Code 視窗
3. 從下一個待執行階段繼續
4. 僅加載該階段所需的輸入檔案

對比：

方式	優點	缺點
同一會話繼續	簡單，不用切視窗	上下文累積，Token 消耗大
新建會話繼續	每階段獨享乾淨上下文，節省 Token	需要切換視窗

推薦做法

對於大型專案或 Token 預算有限的情況，強烈推薦使用"新建會話繼續"。

詳細說明見 上下文優化 教程。

---

技巧 6：處理失敗和重試

為什麼

流水線執行過程中可能會遇到失敗（輸入不足、權限問題、程式碼錯誤等）。了解如何處理失敗，能讓你更快恢復進度。

怎麼做

失敗處理的最佳實踐（參考 failure.policy.md:267-274）：

1. 早期失敗：盡早發現問題，避免在後續階段浪費時間
2. 詳細日誌：記錄足夠的上下文資訊，便於排查問題
3. 原子操作：每個階段的輸出應該是原子的，便於回滾
4. 保留證據：失敗產物歸檔後再重試，便於對比分析
5. 漸進重試：重試時提供更具體的指導，而非簡單重複

常見失敗場景：

失敗類型	症狀	處理方案
輸出缺失	input/idea.md 不存在	重試，檢查寫入路徑
範圍蔓延	功能數量 > 7 個	重試，要求精簡到 MVP
技術錯誤	TypeScript 編譯失敗	檢查類型定義，重試
權限問題	Agent 寫入未授權目錄	檢查能力邊界矩陣

失敗恢復檢查清單：

• [ ] 失敗原因已明確
• [ ] 修復方案已實施
• [ ] 相關配置已更新
• [ ] 從失敗的階段重新開始

失敗是正常的

不要害怕失敗！ AI App Factory 設計了完善的失敗處理機制：

• 每個階段允許自動重試一次
• 失敗產物自動歸檔到 artifacts/_failed/
• 可以回滾到最近的成功檢查點

遇到失敗時，冷靜分析原因，按照失敗策略處理即可。

---

本課小結

本課介紹了 AI App Factory 的六大最佳實踐：

1. 清晰的產品描述：詳細描述目標使用者、核心問題、關鍵功能和約束條件
2. 檢查點仔細確認：每個階段完成後檢查輸出品質，避免錯誤累積
3. 利用非目標控制範圍：明確列出不做什麼功能，防止範圍蔓延
4. 逐步迭代：先驗證核心想法，再基於使用者回饋逐步擴展
5. 分會話節省 Token：在每個檢查點新建會話，降低使用成本
6. 正確處理失敗：利用失敗處理機制，快速恢復進度

遵循這些最佳實踐，能讓你的 AI App Factory 使用體驗更順暢，生成的應用品質更高，開發效率提升數倍。

---

下一課預告

下一課我們將學習 CLI 命令參考。

你會學到：

• factory init 命令的所有參數和選項
• factory run 命令如何從指定階段開始
• factory continue 命令如何新建會話繼續
• factory status 和 factory list 如何查看專案資訊
• factory reset 如何重置專案狀態

---

附錄：源碼參考

點擊展開查看源碼位置

更新時間：2026-01-29

功能	檔案路徑	行號
產品描述技巧	README.md	186-210
檢查點機制	agents/orchestrator.checkpoint.md	98-112
非目標控制	README.md	199-203
失敗處理策略	policies/failure.policy.md	267-274
上下文隔離	policies/context-isolation.md	10-42
程式碼規範	policies/code-standards.md	全文

關鍵常量：

• MAX_RETRY_COUNT = 1：每個階段預設允許自動重試一次

關鍵規則：

• Must Have 功能數量 ≤ 7 個（MVP 原則）
• 頁面數量 ≤ 3 頁（UI 階段）
• 資料模型數量 ≤ 10 個（Tech 階段）
• 測試覆蓋率 > 60%（Validation 階段）