雲端方程式 Cloud F1 Cole Medin Context Engineering 在地化：TW Indie Hacker 的 SaaS Ship Loop 實戰
更新於 2026年7月22日
Cole Medin Context Engineering 在地化：TW Indie Hacker 的 SaaS Ship Loop 實戰
Answer Capsule：副業 SaaS 寫 6 個月還沒 ship 的根本原因是「沒 PRP（Product Requirements Prompt）」+「Plan/Code/Verify 沒拆」+「Connectors 沒接好」。Cole Medin 在 2026 Q1 提出的 PRP loop 是 indie 圈 gold standard（GitHub coleam00/context-engineering-intro 數萬 fork），但全英文 + 偏 SaaS 通用。本文把 Alex P5 三階驗證 + Cole Medin PRP 合體，加 TW 在地案例（Cloud-F1 / 寰宇移民）+ worktree session 隔離 + sub-agent 平行度上限，用 Claude Code 的
/shipSkill 把 ship loop 變成 SOP。Alex 案例：7 天 ship 5 個 feature。
你有沒有遇過這種情況？
你以為卡住的是「這個功能怎麼做」，實際上卡住的是「根本沒有一套流程讓你把事情做完」。
去年某個週末你想到一個 SaaS idea。當天晚上你開了 GitHub repo，寫好 README，打了第一個 commit。
你跟自己說：「3 個月內 ship 第一個 paying user。」
6 個月過去。
repo 裡有 47 個 commit，3 個半完成的 feature（auth flow / billing / dashboard），一個沒 deploy 的 staging 環境。沒有任何 paying user。
朋友問你「ship 沒？」你支支吾吾說「快了快了，再修個 bug」。其實你心裡知道——這個 SaaS 永遠不會 ship 了。
根本原因：不是 idea 問題，是 ship loop 問題
SaaS 卡半年沒上線的真正原因通常是沒有 PRP、沒拆三階、Connectors 沒接好——三個都是流程問題，不是技術問題。
90% indie 卡 SaaS，第一反應是「我 idea 不夠好」「找個更熱門的市場」。
通常不是。
SaaS ship 卡，本質是：
1. 沒有 PRP（Product Requirements Prompt）。
每次新 session / 新 feature，你重講一次「我 SaaS 是什麼、user 是誰、這個 feature 要做什麼」。Context 沒堆疊，每次重來。
2. Plan / Code / Verify 沒拆。
你不能寫 100 行 code 才發現「啊原本 design 就錯了」。沒拆三階，你的 ship 卡在「寫 code 寫到一半發現 design 不對」。
3. Connectors 沒接好。
SaaS feature 通常要接 Stripe（billing） + GitHub（issue tracking） + Linear（PM） + email service。每個都要寫 webhook / API client / error handling。每個整合花 1-2 週。
我在陪跑其他案子的時候也常看到同一種模式——重點來了：不是技術難，是流程分析難。 你要串的 API 技術上幾乎都做得到，難的是把「誰要什麼、什麼時候要、資料要對到哪個欄位」講清楚。SaaS ship 卡住，本質上是同一種病，只是換了個名字。
這是 ship loop 設計問題，不是 idea 問題。
Cole Medin PRP — 2026 Q1 indie 圈 gold standard
PRP 是把「這個 feature 要做什麼」寫成一份結構化 markdown，分 Context / Requirement / Verify 三段，讓每次開新 session 不用重講一次。
Cole Medin 是 2026 年 indie hacker 圈最有影響力的 Claude Code 教練之一。他的 GitHub repo coleam00/context-engineering-intro 在 2026 Q1 變成 default starter — 數萬人 fork 後拿來當自己的 SaaS 開發框架。
他提出 PRP（Product Requirements Prompt） = 一份結構化 markdown，每個 SaaS feature 一份。內容三段：
第一段：Context（這個 feature 是什麼）
- User persona（誰會用）
- 解什麼問題
- 跟其他 feature 怎麼互動
- 商業意義（影響哪個 metric）
第二段：Requirement（怎麼做）
- 詳細 acceptance criteria
- API surface design
- Data model changes（schema migration）
- UI flow（如果有 frontend）
第三段：Verify（怎麼算完成）
- Test cases（happy path + N edge cases）
- Smoke test 命令
- Rollback plan
- Observability（log / metric）
每個 feature 寫一份 PRP，存 .claude/prps/<feature-name>.md。implement 時從 PRP 啟動，不用 reload context。
P5 + PRP 合體
P5 的三階驗證跟 PRP 的三段結構幾乎一一對應，差別只在粒度：P5 管一個 PR，PRP 管一個 feature。
P5（Plan-Code-Verify 三階驗證）是 Alex 6 條原理之一，B1 module 在 PR 級別教過。
Cole Medin 的 PRP 三段：Context / Requirement / Verify。
剛好對齊：
| 階段 | P5 | Cole Medin PRP |
|---|---|---|
| 第一階 | Plan stage | Context + Requirement 段 |
| 第二階 | Code stage | implement 時從 PRP 啟動 |
| 第三階 | Verify stage | Verify 段 |
差別是粒度：
- P5 = PR 級別（一次 review 一個 PR）
- PRP = feature 級別（一個 SaaS feature 可能跨多個 PR）
合體效果：feature 用 PRP 規劃 + 拆成多個 PR + 每個 PR 用 P5 三階 review。
兩個 Claude Code 命令
這套流程只靠兩個命令撐起來：/generate-prp 問你幾個問題自動產出 PRP，/execute-prp 讀完 PRP 之後平行叫出好幾個 sub-agent 幫你完成實作。
Cole Medin 的repo 提供兩個關鍵 slash command：
/generate-prp <feature-name>
互動式生 PRP — Claude 訪問你 5-7 個問題（user persona / 商業目標 / 技術 constraint），自動產出結構化 markdown 存到 .claude/prps/。
每個 feature 5-10 分鐘生成 PRP，比你手寫快 10 倍。
/execute-prp <prp-path>
讀 PRP，spawn 多個 sub-agent 平行 implement：
- plan-agent 確認 requirement 對齊 architecture
- code-agent 寫 implementation
- test-agent 寫 test
- verify-agent 跑 smoke test
最終回 PR ready for human review。
TW 在地化：缺什麼？
Cole Medin 的範本是英文 + 通用 SaaS，TW 團隊要自己補中文 persona、在地金流／通知 Connectors、跟法規 compliance 三塊。
Cole Medin 全英文 + 偏 SaaS 通用。TW indie hacker 用會卡這幾個：
1. PRP context 段需要中文 user persona
「客戶是 50 歲台灣中小企業老闆，會用 LINE 不太會用 Slack」這種 audience profile 在 Cole Medin 範本裡沒有。本地化後 Claude 才會給對應 calibration。
2. Connectors 需要 TW 場景整合
Cole Medin 範例多用 Stripe / GitHub / Linear。TW 場景多了：
- 綠界 (ECPay) / 藍新 (NewebPay) — TW 金流取代 Stripe
- LINE Notify / LINE Bot — 客戶通知通道
- TWNIC 域名管理
- GAM (Google Workspace) — TW 企業客戶高比例
3. PRP 範本沒涵蓋 TW 法規
個資保護法（PIPA）/ 電子簽章法 / 消保法。SaaS PRP Verify 段需要 compliance check。
PRP Session 隔離：Worktree 是被低估的細節
多個 PRP 平行跑最容易踩到的坑，是好幾個 Claude Code session 共用同一份 working tree，互相蓋掉彼此還沒 commit 的檔案。
Cole Medin 的教學沒講這塊——他的範本假設你一次只跑一份 PRP。但你像後面案例 Day 4-5 那樣，兩份 PRP 平行 ship 的時候，兩個 session 共用同一份 checkout 會撞出三種真實會發生的問題：
- 一個 session 的
git add -A把另一個 session 還沒 commit 的檔案一起掃進去 - 一個 session 跑
git reset --hard把另一個 session 的改動蓋掉 - 兩個 session 搶著切同一個分支，PRP B 還沒開始 implement，分支就被 PRP A 切走
有時候，我們會遇到這種情況：Day 3 那份太大的 PRP 拆成兩份之後，你直覺就想開兩個視窗同時跑——這正是最容易踩到 worktree 沒隔離的時間點。
解法不是「小心一點」，是結構性隔離：每份 PRP 開一個獨立的 git worktree，各自帶一條分支，各自完工才開 PR 進 main。這跟我自己內部管理多個 Claude session 的方式完全一樣——一個 session 一個 worktree、一個分支、一個 PR，這個 session 要做的事批次做完才合併，不會每個 session 都直接改同一份共用 working tree。PRP 數量越多，隔離帶來的差別越明顯：2 份平行你可能還沒感覺，5 份以上不隔離大概率會撞。
Claude Code 怎麼落地（中文版 PRP loop）
整套流程只要三個步驟：先 fork 原始 repo 中文化，接著生出第一份中文 PRP，最後跑 /execute-prp，一個 feature 從發想到 PR ready 大概只要 1-3 小時。
Step 1 — Fork Cole Medin repo + 中文化
gh repo fork coleam00/context-engineering-intro context-engineering-tw
cd context-engineering-tw
# 客製 .claude/commands/ 加中文版
# /generate-prp.md 改成中文 question template
# /execute-prp.md 改成中文 sub-agent personaStep 2 — 寫第一個中文 PRP
/generate-prp tw-newsletter-subscription互動 (繁中)：
> User persona for this feature?
你: 30 歲 TW 自由工作者，月入 50K-150K，每天看 newsletter 1 小時
> 解什麼問題？
你: 訂太多 newsletter 沒時間看，想用 Claude 自動 Tier 分類
> 商業目標？
你: 月費訂閱 NT$199，targeting 50 個 founding users
> 技術 constraint？
你: 用 LINE Notify 推送（不用 email），TW 用戶習慣 LINE
> 接 ECPay 收月費（不用 Stripe，TW 中小企業習慣綠界）
> Acceptance criteria 簡單列？
你: 1) Self-serve 訂閱 UI; 2) ECPay 月費自動扣款; 3) 早報自動推 LINE; 4) 取消訂閱 UIClaude 產出 .claude/prps/tw-newsletter-subscription.md (~80 行)。
Step 3 — 跑 /execute-prp
/execute-prp .claude/prps/tw-newsletter-subscription.mdClaude Code 內部：
- Read PRP——讀整份 markdown 進 context
- Spawn plan-agent——驗證 PRP 對齊 CLAUDE.md architecture invariants
- Plan PASS → Spawn code-agent + test-agent 平行
- Spawn verify-agent——跑 test、smoke test、log check
- Verify PASS → 回 PR URL + summary
過程 1-3 hours（看 feature 複雜度）。你期間可以離開電腦。
Connectors：feature 接外部 service 的標準層
Connectors 是 Claude 內建的整合層，PRP 裡列好要用哪些 Connector，/execute-prp 就自動處理 webhook 簽章跟 retry，不用你自己重寫一次。
Claude Connectors（2026 Q1 後普及的整合層）解這個：
## Connectors required (in PRP)
# TW 在地版
- ecpay.subscriptions.create_or_upgrade # 綠界月費訂閱
- ecpay.webhooks.subscribe (events: payment.success, payment.failed)
- line_notify.send (template: morning-newsletter)
- linear.issues.link_to_prp
# 通用版
- github.pulls.create_with_branch/execute-prp 自動引用 Connector SDK，你不需要寫 webhook signature 驗證、retry logic、對帳。
Sub-agent 平行度上限：不要無腦開好幾十個
Sub-agent 不是開越多越好，每個都要吃 context 跟 token，PRP 一多平行開，帳單跟你自己盯得過來的量反而先撐不住。
簡單來說，/execute-prp 一次 spawn 4 個 sub-agent（plan / code / test / verify）。如果你像後面 Day 4-5 案例一樣兩份 PRP 平行跑，等於同時有 8 個 sub-agent 在燒 context。
我自己內部團隊分派 sub-agent 的時候，訂了一個很簡單的上限：預設一次最多 4 個平行，真的要衝也不超過 8 個，超過就分批做。這不是為了省事，是因為超過這個數字之後兩件事會一起變差：
- 你要同時看好幾個 sub-agent 回報，眼睛跟腦袋先撐不住，反而漏看某一個的 FAIL
- Token 帳單跟 context 視窗同時吃緊，尤其如果你的 PRP 寫得不夠精簡，每個 sub-agent 又要重新載入一次專案背景
Cole Medin 的預設範本沒有這個上限——他假設你一次只跑一份 PRP。TW indie hacker 如果想搶速度，一次排 3-4 份 PRP 平行跑，記得先看一下你自己方案的用量上限，不要等帳單爆了才發現。
ship-feature Skill 變成 SOP
把整個 PRP loop 從頭到尾包成一個可重複使用的 Skill，之後你想 ship 新 feature，只需要敲一行 /ship，其他所有步驟都由 Skill 自動幫你帶完。
把整個 PRP loop 變成 reusable Skill。
.claude/skills/ship-feature/SKILL.md：
---
name: ship-feature
description: End-to-end SaaS feature ship loop. PRP → review → execute → ship.
---
You ship SaaS features following Cole Medin PRP loop + Alex P5 三階驗證.
## Steps
1. Generate PRP — /generate-prp <feature-name>
2. Pause for human review
3. Execute PRP — /execute-prp <path> after approval
4. Spawn 4 sub-agents (plan / code / test / verify)
5. Output PR URL + summary
## Connectors used (TW 在地)
- ecpay (if billing)
- line_notify (if 客戶通知)
- github / linear (always)之後你想 ship feature 直接：
/ship pricing-tier-upgradeSkill 自動帶 PRP loop 完整跑一次。
Alex 真實案例：7 天 ship 5 個 feature
這是我自己拿一個新 SaaS idea 實測第一輪 PRP loop 的真實結果：7 天內 ship 出 5 個 feature 的 v0，如果沒有這套 loop，我估計至少要花 6-8 週才能做到同樣進度。
我 2026 Q1 試做一個 SaaS：「Claude prompt sharing platform」，用 PRP loop 跑：
- Day 1：
/generate-prp landing-page→ 30 min PRP review →/execute-prp→ 2 hr 後 PR ready - Day 2：
/generate-prp auth-flow→ 同樣節奏，PR 隔天 ready - Day 3：
/generate-prp prompt-storage→ 寫的 PRP 太大，被 plan-agent 報 reject「scope 太大」 - Day 3 下午：拆成 2 份 PRP（prompt-crud + prompt-search）
- Day 4-5：兩份 PRP 平行 ship（就是上面 worktree 隔離那段的實際場景）
- Day 6：
/generate-prp share-flow+ Stripe Connector → 1.5 hr PR - Day 7：deploy staging + smoke test PASS
7 天 ship 5 個 feature 的 v0。沒有 PRP loop 我估計會花 6-8 週。
不是說每個 indie 都能複製這個 — 但 ship 速度的瓶頸從「寫 code」變「review PRP」這個轉折是真的。
對照其他做法
PRP loop 解的是「feature ship 結構」，跟自己寫模板、vibe coding、找工程顧問比，換來的是可重複，不是一次性。
| 做法 | 解的是什麼 | 限制 |
|---|---|---|
| PRP loop（中文版） + Connectors | feature ship 結構 + 整合層 boilerplate | 需要 Claude Code Pro+ + Cole Medin repo fork |
| 自己寫 prompt 模板 | Tactical layer | 沒結構化，每次重新發明 |
| 直接 vibe coding | 速度感 | scope 不停膨脹，6 個月 ship 不出去 |
| 找一般工程顧問 | 1-on-1 unblock | 小時費 NT$5K-15K，不可重複 |
| Cole Medin Dynamous community | 通用 PRP | 全英文，TW 場景需要客製 |
⚠️ 老實說：PRP loop 不是萬靈丹
PRP loop 假設你已經知道要做什麼，如果連這個 feature 該不該做都還沒想清楚，先別急著寫 PRP。
三種情況我會建議先不要套這套流程：
- Idea 還在發散階段。 你連「這個 feature 到底解什麼問題」都還在猜，PRP 的 Context 段你會寫不出來——先花時間跟真實用戶聊，不是先生 PRP。
- 一次性的小 script。 一個 30 行、跑一次就丟的小工具，寫 PRP 的時間比直接寫完還久，這種摩擦成本不划算。
- ML model 訓練這類實驗性工作。 PRP 的 Verify 段假設「跑得動 = 對」，但 model 訓練的「對」是機率性的，這套 gate 邏輯套不上去（下面 FAQ Q2 也有講）。
PRP loop 適合的是「你已經知道要做什麼，卡在怎麼有結構地做完」的那個階段——不是每個卡住的地方都是這個階段。
Key Takeaways
六句話濃縮全文：沒 PRP 是根因、Cole Medin 是標準、TW 在地化補三塊、worktree 跟平行度是被忽略的細節、Alex 案例是真實驗證。
- 副業 SaaS 寫 6 個月沒 ship 的根本原因是「沒 PRP」+「沒拆三階」+「Connectors 沒接好」
- Cole Medin PRP loop 是 2026 Q1 indie 圈 gold standard，全英文 + 偏 SaaS 通用
- TW 在地化需要：中文 user persona / TW Connectors（ECPay / LINE Notify）/ 法規 compliance check
- P5 + PRP 合體：feature 用 PRP 規劃 + 拆多個 PR + 每個 PR P5 三階
- 多份 PRP 平行跑要記得 worktree session 隔離 + sub-agent 平行度上限（預設 4、上限 8）
- Alex 案例：7 天 ship 5 個 feature（沒 PRP loop 估計 6-8 週）
FAQ
七題常見問題，從「這跟我原本訂的服務重不重複」排到「我不是 indie hacker 也能用嗎」。
Q1：Cole Medin Dynamous（USD $99/月）我訂了，重複嗎？
互補不重複。Cole Medin 偏英文 PRP loop / 通用 SaaS。Track B B3 module 偏 TW 在地場景 + 整合 P5 三階 + ECPay/LINE Connectors。買 Track B 模組包 + 仍然訂 Cole Medin = 兩邊互補。
Q2：我 SaaS feature 涉及複雜 ML model 訓練？
PRP loop 不適合。ML training pipeline 走 ADR + experiment notebook，不是 ship loop。
Q3：PRP 太大被 plan-agent reject 怎辦？
拆 2-3 份小 PRP。Cole Medin 建議「每份 PRP 對應 1 個 PR （理想） / 最多 4 個 PR」。
Q4：sub-agent 一直 fail？
跑 /execute-prp <path> --focus plan 只跑 plan-agent 看哪卡。debug 完再跑全 loop。
Q5：cost 控制？
每月跑 /skills --sort tokens 看 ship-feature Skill 燒多少。如果單個 feature > 100K tokens，考慮 split 成更小 PRP。
Q6：我不是 indie hacker，是 team 工程師？
PRP loop 也適用 team — 把 PRP review 變 sprint planning meeting 的 agenda。但 team 還需要 P6（Skills+Plugins+Sub-agents 三位一體）整套，那是 Track B B4 module 主場。
Q7：兩份 PRP 平行跑，是不是每次都要開兩個 worktree？
不是每次都要，是超過某個數量後強烈建議。1 份 PRP 你自己一個人跑感覺不出差異；2-3 份以上平行、又是團隊共用同一顆 repo，worktree 隔離能省下你事後排查「誰蓋了誰的改動」的時間。
Next Steps
先看 Track B B3 module，再決定要不要 fork Cole Medin repo；如果團隊連基本 AI 協作習慣都還沒有，先從入門課打底再談 PRP 這種進階紀律。
如果你卡在副業 SaaS：
- 看 Track B B3 module 完整內容（5 lessons + saas-ship-loop-prp template + Cole Medin fork 路徑 + ship-feature Skill）
- Fork Cole Medin coleam00/context-engineering-intro 起步 + 加 TW 客製
- 如果你的團隊還沒建立基本 AI 工作習慣（不只工程師，PM、行政都要會跟 AI 協作講清楚需求）：可以先從 《AI 職場工作術》 這門課打底——PRP loop 是進階的工程紀律，前提是團隊已經習慣把工作講清楚給 AI 聽，地基沒打，PRP 寫再漂亮也是空中樓閣
- 如果 ship 卡的是非技術問題（pricing / GTM / launch sequence）：考慮陪跑制（NT$50-80K/月，限量 2 位/月）
詳細 Track B 模組包 sales page（Founding 50 NT$6,800 lifetime）含 B3 + 其他 4 modules，或先加入 Skool 工程師圈 看免費內容再決定。
Related Resources
延伸閱讀涵蓋同系列 P5 文章、工具選型、零基礎入門，跨程度都能找到下一篇。
- Track B B3 SaaS Ship Loop module
- Cole Medin context-engineering-intro — 原始 PRP repo
- ai-coding-template — Track B B2 reference (本 repo
.claude/commands/athena/含 plan / execute / ship 命令) - P5 PR Review Pipeline blog — 本系列 Blog 1，P5 三階驗證完整拆解
- Vibe Coding 工具比較 2026 — 選 AI coding 工具的完整評測
- 什麼是 AI Coding？ — 零基礎入門定義
- Claude Cowork 3 分鐘做表教學 — 非工程角色也能上手的 Claude 用法
- Skool 工程師圈 — Track B 學員 lifetime member 入場
變更紀錄
這篇從初版到 D9 重定位重寫的版本異動記錄，方便追蹤內容什麼時候加了什麼。
| 版本 | 日期 | 變更 |
|---|---|---|
| 1.0 | 2026-04-29 | 初版（Plan 4 §Phase 7 Blog 3） |
| 1.1 | 2026-07-22 | D9 內容重定位重寫：擴充 worktree session 隔離 + sub-agent 平行度上限 + 老實說邊界段 + 3 篇內鏈 + CTA 導 academy.cloud-f1.com |
