R-P-E：用 AI 的通用心法 — 從工程師到創作者都能用的工作流

「心法不會過時，工具會。」 「多數 AI coding 失控，不是模型問題，是工作流問題。」

開場：為什麼三個字母值得寫八千字

過去半年，我跟超過 50 個用 AI 寫程式的工程師、產品經理、創作者聊過。我發現一個共通模式：

多數人用 AI 失控，不是因為模型不夠強，是因為沒有工作流。

同樣的 Claude、ChatGPT、Cursor — 有人用來在一天內把企業系統從 0 推到 production，有人用了一週還在跟 AI 來回拔河。差別不在模型，在於前者有一套清楚的「先想清楚再動手」的紀律。

這套紀律可以用三個字母記住：

R · P · E

Research（研究）→ Plan（規劃）→ Execute（執行）。

這三個字母最早在 Claude Code、OpenAI 對齊團隊、Anthropic 工程社群裡被講開來。我把它整理成可以套在所有 AI 場景的版本 — 不只寫程式可以用，寫文章、做簡報、生圖片、做影片、做研究、問 AI 任何事，全部都這樣用。你的 AI 會變得跟別人不一樣，比別人強。

接下來的 8,000 字會做兩件事：

1. 把這三個字母拆開講清楚，每個字母對應什麼動作、為什麼這樣做、有哪些大師背書
2. 用一個真實的「一天內從 0 到 production」的工程案例（Cal-Sync），把 R-P-E 從心法走成肌肉記憶

但在那之前，先談談為什麼你需要這個心法。

一、為什麼需要心法？多數 AI coding 失控的真正原因

過去六個月，我跟超過 50 個用 AI 寫程式的工程師、產品經理、創作者聊過。我發現一個共通的失控模式 — 跟 AI 模型強不強完全無關。

三個常見的失控場景

場景 ①：一句話 prompt，一千行 code，越改越爛

「幫我做一個訂單管理系統。」三十秒後，AI 吐出 1,200 行 code。你看不太懂，但跑起來了。隔天客戶說「我要加一個批次匯入」，AI 又改了 300 行。一週之後，整個 codebase 變成你不敢動的黑盒子。

場景 ②：沒有規格，AI 每次理解都不一樣

你問 AI：「幫我寫一篇關於 SaaS 銷售的文章。」第一版風格嚴肅學術。你說「太硬了，要輕鬆一點」，第二版變成嘻哈口語。第三版你又說「太鬆了」，AI 開始跟你來回拔河。三小時後你發現：問題不是 AI，是你從來沒寫下「輕鬆」到底是多輕鬆。

場景 ③：動筆才發現方向錯

你給 AI 一個目標：「幫我做一個個人健身追蹤 app。」AI 直接開始寫 React Native code。一週後你發現，其實你真正需要的是「跟營養師同步紀錄」的工具，不是另一個健身 app。但 codebase 已經往「個人版」走了一公里。

共同的根因：沒有工作流

這三個場景的共同根因，不是 AI 不夠強，是你跟 AI 之間沒有一條清楚的工作流。

模型強不強，影響的是 5% 的差異。工作流好不好，影響的是 5 倍的差異。

這就是為什麼即使最厲害的工程師也會推薦你用 R-P-E：

注意他們的共識：spec / plan 是核心，但工具是選配。沒有人在推 Spec-Kit、OpenSpec、Kiro 那種重型 SDD 工具 — 他們都用 markdown + Plan Mode + Test。

這就是「心法不會過時，工具會」的真正意思。R-P-E 是工具消失後仍能用的肌肉記憶。

二、R-P-E 是什麼

把上面那些「先想清楚再動手」的共識壓縮成你能記得住的三個字母，就是 R-P-E。

三個字母的完整定義

R = Research（研究） 跟 AI 一起研究、討論、辯論、收斂。 重點：可行性、類比案例、市場現況、競爭分析、隱私 / 法規 / 技術風險。

P = Plan（規劃） 跟 AI 一起規劃 — 產品規劃、技術規劃、效能規劃。 重點：功能規格 + 非功能規格 + 驗收條件 + 調性規格。

E = Execute（執行） 計劃確認才動筆。Agent Teams 動起來。 重點：寫的都是 Plan 規範裡的東西，Definition of Done 清楚。

R-P-E 不是新發明

這套方法不是我發明的，全世界用 AI 最厲害的人都在做同一件事：

• Sean Grove（OpenAI） — 把 OpenAI 的 model spec 當作「執行版 spec」，所有 alignment 工作都從 spec 開始
• Boris Cherny（Anthropic） — Claude Code 的 Plan Mode 就是強制你 Research → Plan → Annotate → Implement → Iterate
• Boris Tane（資深工程師、日均實踐者） — 部落格〈How I Use Claude Code〉提出高度可實踐的個人版 R-P-E

他們用的工具不同（Claude Code、Cursor、純 ChatGPT），但方法論完全相通：Research → Plan → Execute。

一張表把流程說清楚

簡單一句話總結：R-P-E 不是新方法，是把「先想清楚再動手」這件事濃縮成你能記得住的三個字。

三、R-P-E 是「通用心法」 — 不只用在寫程式

R-P-E 最重要的觀念是這個：它不只是做產品的方法。

R-P-E 是用 AI 的通用心法。寫文章、做簡報、生圖片、做影片、做研究、問 AI 任何事 — 都這樣用。你的 AI 會變得不一樣，比別人強。

6 個場景的 R-P-E 對照

共通模式

不管要 AI 做什麼 — 先 R 再 P 再 E。

越克制「快點看到東西」的衝動，結果越好。

我帶過幾個一開始死活不信這個心法的學員。他們都有同樣的轉折時刻：發現自己花在「改 AI 產出」的時間，比花在 Research + Plan 的時間多 5 倍 — 而且最後成果還不如朋友先 Research 再 Plan 出來的版本。

接下來三段，我會把每個字母拆給你看。為了讓你看到「心法在真實場景活下來」的樣子，我會穿插一個真實案例：Cal-Sync — 一個一人公司用 R-P-E + 3 個 AI agent 並行，從規格寫作到 production 上線只花了大約一個工作天的 Calendar 同步系統。（順帶一提：這個專案的 SRS 原始預估工時是 4.5 天，最後實際耗時不到三分之一 — R-P-E 的威力之一。）

四、R = Research：先別寫，先吵清楚問題

Research 是 R-P-E 裡最常被跳過、CP 值最高的一段。

很多人覺得「Research 就是 google 一下、問 AI 一下」。錯。Research 的本質是找到真正的問題。

Research 的三層問題

第一層：問題層 — 表面需求是什麼？背後真正的目標是什麼？ 第二層：方案層 — 市面上有哪些解法？為什麼這些都不行？ 第三層：實作層 — 自建怎麼建？技術選型有哪些取捨？

直接給 AI 一個目標、跳過這三層，就會落入「happy path 陷阱」 — AI 給你的是「最直覺的解」，但常常解錯問題。

真實案例：「分享行事曆」不是真問題

Cal-Sync 的起點看起來再單純不過：

我是一人公司經營者，同時管理兩個 Google Calendar（家庭 + 公司）。跟合作夥伴協作時，對方負責跟終端客戶協調會議時間。雙方互不知道彼此行程，導致合作夥伴約客戶會議時容易跟我既有行程撞期。

直覺解法：「把行事曆分享給合作夥伴。」

但 Research 第一層的拷問是 — 真的是「分享行事曆」這個問題嗎？

往下挖一層，發現一個關鍵的隱私議題：時段密度本身就是 metadata。

即使用 Google Calendar 原生的「只顯示忙碌」功能，這些時間模式仍會洩漏給合作夥伴 — 而且過去的揭露無法收回。

真正的問題是：如何讓合作夥伴看到客戶會議可用時段，但完全看不到我非工作時段的存在狀態。

不是「如何分享行事曆」，而是「如何打造一個只暴露工作時段忙碌訊號、其他時段對合作夥伴完全不可見的同步機制」。

**這就是 Research 的價值。**沒這層拷問，後面所有的選擇都會走偏。

同樣的思路用在寫文章 / 做簡報

Research 不是工程師的專利。

寫文章：你說「我要寫一篇關於 AI 顧問怎麼選的文章」。Research 三層問 —

• 第一層：讀者真正想知道的是「選哪一家」還是「怎麼判斷我需不需要顧問」？
• 第二層：市面上類似主題的文章怎麼寫？哪些被罵爆、哪些被推爆？
• 第三層：你想表達的觀點，有哪些反方論點？

做簡報：你要對 30 個 CEO 簡報 AI 策略。Research 三層問 —

• 第一層：CEO 真的想聽 AI 策略嗎？還是想聽「我這位 CEO 要做什麼決定」？
• 第二層：別的 AI 顧問怎麼對 CEO 講？哪些 frame 有效、哪些被翻白眼？
• 第三層：CEO 會問哪些尖銳問題？你怎麼回？

同樣三層，問題不同，但動作完全一樣 — 先別寫，先吵清楚。

Research 的產出：Y-Statement ADR

工程師圈有一個很好用的格式叫 Y-Statement ADR（Architecture Decision Record）：

In the context of <問題情境>,
facing <取捨>,
we decided <決定>,
and against <淘汰的選項>,
to achieve <目標>,
accepting that <代價>.

這個格式的價值是：強迫你把「取捨」與「代價」也寫進去。

Cal-Sync 在 Research 階段產出 6 個 ADR（架構決策紀錄），涵蓋：

• 為什麼選自建而不用 OneCal / Reclaim.ai
• 為什麼只寫工作時段而不全寫
• 為什麼用 Polling 不用 Webhook
• 為什麼用 SHA-256 hash 當 idempotent key
• 為什麼用 syncToken 增量同步 + 每日 full resync

每一個 ADR 都用上面那個格式寫。

ADR 不是寫給「現在的自己」看的，是寫給「半年後忘記的自己」或「接手的同事」看的。

寫文章 / 做簡報的 Research 產出可以是更輕的版本 — 一份 markdown，紀錄「為什麼這個切角、為什麼不選那個切角」。但寫下來這件事，是 Research 真正的價值所在。

五、P = Plan：把研究的取捨變成可驗收的規格

Plan 是 R-P-E 裡最被誤解的一段。

很多人把 Plan 理解成「列 todo list」。錯。Plan 的本質是把 Research 階段選定的方向，變成 AI 可以照著做、你可以驗收的規格。

規格的三層

規格不是越多越好，而是要有結構。三層缺一不可：

FR（Functional Requirements）功能需求 — 系統 / 產出要做什麼 NFR（Non-Functional Requirements）非功能需求 — 系統 / 產出的品質約束 AC（Acceptance Criteria）驗收條件 — 怎麼驗證真的做對了

舉 Cal-Sync 的例子：

但更關鍵的是 AC（驗收條件）：

驗收條件先寫，後面的程式碼就有人盯著。

這 8 條 AC 後來直接變成 Cal-Sync 整合測試的骨架 — 寫程式之前驗收條件就已經把「對」的定義鎖死。

同樣的思路用在創作場景

寫文章的規格：

• FR：必須涵蓋 X / Y / Z 三個論點，每個論點要有一個真實案例
• NFR：字數 3000-5000、語氣輕鬆但專業、不能有 jargon
• AC：給三個目標讀者試讀，至少 2 個說「我懂了」「我會想轉發」

做簡報的規格：

• FR：必須回答聽眾「我為什麼要聽」「我聽完要做什麼」兩個問題
• NFR：每頁不超過 30 字、講者口語化、20 分鐘可講完
• AC：講完有人問「投影片可以給我嗎」、有人主動 follow up

Plan ≠ Waterfall

這裡要回應一個常見的誤解：「Plan 不就是 waterfall 嗎？AI 時代不是應該 vibe coding 嗎？」

AWS Distinguished Engineer Marc Brooker 對這個指控有很直接的反駁：

spec 是被 iterate 的對象，不是一次寫完。Spec 是上游驅動的工具，不是 freeze 的交付物。SDD 不是 waterfall，是「在動手前把昂貴的錯誤先抓出來」。

Plan 的意思不是「100% 寫死再動手」，而是**「動手前把 60% 的方向釘住，剩下 40% 在 Execute 階段邊做邊收斂」**。

兩者的差別是：

• Waterfall：寫完規格 → 動手 → 發現規格錯 → 改規格 → 重做
• R-P-E：寫主要規格 → 動手 → 發現邊界 case → 補規格 → 繼續做

關鍵差異是「規格是不是活的」。R-P-E 的規格是活的；waterfall 的規格是死的。

多 AI agent 並行的關鍵：共用契約

Cal-Sync 在 Plan 階段做了一個關鍵決策：3 個 AI agent 並行開發。

但 3 個 agent 並行最大的風險是「各自寫各自的、最後整合是災難」。怎麼避免？

Plan 階段把共用契約鎖死。

具體做法：在所有 agent 動工之前，先寫一份 types.py：

@dataclass(frozen=True)
class SourceEvent:
    calendar_id: str
    event_id: str
    start: datetime
    end: datetime
    is_all_day: bool = False
    is_cancelled: bool = False
 
    def __post_init__(self) -> None:
        if not self.is_cancelled:
            _require_aware(self.start, ...)
            _require_aware(self.end, ...)
            if self.end <= self.start:
                raise ValueError(...)

frozen=True 是 immutable，避免下游 agent 意外修改。嚴格時區檢查，拒絕 naive datetime。

三個 agent 都用這同一份契約：

• Agent A 拿 SourceEvent 進 → 吐 BusyBlock 出
• Agent B 從 Google API 拿原始 dict → 轉成 SourceEvent
• Agent C 用 Protocol 描述介面，整合期注入

只要型別不破，三個 agent 之間完全不需要協調。

結果：三次 git merge 全部零衝突。共用契約規劃得好的證據。

六、E = Execute：計劃確認才動筆

Execute 是 R-P-E 裡**最容易做、也最容易演成「假 R-P-E」**的一段。

什麼是「假 R-P-E」？就是 Research 做了 10 分鐘、Plan 做了 5 分鐘，然後就跳進 Execute 做 5 小時。這不是 R-P-E，這是「Execute 配兩個 garnish」。

真正的 R-P-E，Research + Plan 應該佔 30%-50% 的時間。動筆才動筆。

Plan Mode：動筆前最後一道防線

Claude Code 內建了一個叫 Plan Mode 的功能。它的作用是 — 強制你在「核准 plan」之前，AI 不會寫任何 code。

這個機制看起來限制了 AI，其實是給你的最後一道防線：在動筆前，確認方向。

Boris Cherny（Claude Code 創造者）的原話：「never let Claude write code without approved plan.」每天 ship 20-30 PR、從 2025/11 沒手寫過一行 code 的人，把這當鐵則。

Agent Teams 動起來：3 個 AI agent + git worktree

Cal-Sync 的 Execute 階段示範了「Agent Teams 動起來」是什麼意思。

calendar-sync/                                    主 worktree (我)
├── .claude/worktrees/agent-a0ff36d1.../          Track B (純邏輯)
├── .claude/worktrees/agent-a9a71e08.../          Track C (Google API)
└── .claude/worktrees/agent-a4fa8c14.../          Track D (Scheduler)

三個 AI agent 各自在獨立的 git worktree 內工作，基於同一個 commit 開新分支，互不影響。我自己留在 main，agent 失敗不會污染我。

完成後由我 merge 回來。

Agent prompt = 合約，不是工作交辦

這是 Execute 階段最關鍵的觀念。

不要寫：

幫我實作 Google Calendar API 整合

要寫（節錄一段 Cal-Sync 的真實 agent prompt）：

你是 Track B agent，在獨立的 git worktree 內工作（基底是 main 上的 Phase 0 骨架，commit 7fbb720）。

你的範圍：實作四個純邏輯模組與完整單元測試。

必須產出的檔案：

1. backend/app/domain/working_hours.py — WorkingHoursFilter
   • 輸入: WorkingHoursSchedule、(start, end, tz)
   • 輸出: 與該事件重疊的「工作時段子區間」list
   • 嚴格依 ADR-002 規則
2. backend/app/domain/clipper.py — EventClipper
   • 函式 clip_event(event, schedule) -> list[BusyBlock]
   • 取消事件返回空 list
   • 部分重疊 → 裁切至工作時段邊界

（...省略 Merger、Anonymizer 兩個模組規格 ...）

不能動的檔案：

• backend/app/domain/types.py（共用契約）
• backend/app/google/、scheduler/、api/、db/
• docker-compose.yml、Dockerfile、pyproject.toml

怎麼跑測試（不污染 host）：

docker run --rm -v "$(pwd)/backend:/app" -w /app \
  calendar-sync-cal-sync-backend:latest pytest tests/unit -v

Definition of Done：

1. 四個模組實作完成、簽名與型別精準
2. 單元測試全綠、覆蓋率 ≥ 80%
3. ruff + mypy strict 通過
4. 不破壞既有 smoke tests
5. Git commit 以 feat(domain): 開頭

一個好 prompt 的 7 段結構

少了任何一段，agent 都可能走偏。Terse command-style prompts produce shallow, generic work.

16 分鐘三 agent 並行交付

Cal-Sync 的真實成果：

三個 agent 同時跑 16 分鐘，各自在自己的 worktree 內 commit、自己跑測試、最後回報。我 merge 進 main 時，三次 --no-ff merge 全部零衝突。

這就是「Agent Teams 動起來」的真實樣子。

同樣的思路用在創作

寫文章 / 做簡報的 Execute 也是一樣：

• 不要寫：「幫我寫這篇文章」
• 要寫：「請依照這份大綱（連結）和風格規格（連結），寫第一段。約 300 字，目標讀者是 CEO，要在第一句就帶出衝突，最後一句要有 hook 引到第二段。完成後請報告：你做了什麼、有沒有偏離大綱、有沒有想到我沒交代的問題」

規格越具體，AI 給你的東西越接近你要的。

七、上線後 PDCA：心法不在 Execute 結束

很多 R-P-E 的教學到 Execute 就結束了。錯。

真實世界裡，Execute 完了之後才是最有料的階段。

Cal-Sync 上線後跑了一週，跑出 4 個生產 bug。每一個 bug 都不是 happy path 測試能抓到的，每一個都是規格的盲點。

真實 Bug ①：syncToken delta 把目標 Cal 全砍光

上線第二天，我看到一筆奇怪的 sync_run log：

id=2, sync_kind=incremental, source_events_fetched=0, events_deleted=17

為什麼 fetched=0 但 deleted=17？

追根究柢：

1. id=1 是 full sync，syncToken 拿了並存到 DB，target 寫了 17 個事件 + 17 個 mappings
2. id=2 是 10 分鐘後的 periodic incremental sync
3. fetch_events_incremental 用 syncToken 拉資料，只回傳 delta（變更的事件）
4. 沒任何變更，回傳 events=[]
5. Orchestrator 把這個 events=[] 當成「完整的 desired state」
6. 跟 current_mappings (17 筆) 做 diff → 17 個 DELETE 操作
7. 17 個 target 事件被砍光

這個 bug 在測試中沒被抓到 — 因為 FakeGoogleCalendarClient 的 list_events 不模擬 syncToken delta 行為，永遠回傳完整事件列表。

真實世界打到了實作的盲點。

修法：先用 band-aid（每次都 force full list），代價是 API 配額每天 600 次（Google 日免費額度的 0.06%），換來邏輯正確。Per-source delta diff 留待重新設計。

教訓：測試的 fake 越接近真實，bug 暴露越早。Band-aid 是合法的工程選擇 — 先確保 correctness、再優化 performance。

真實 Bug ②：測試 fixture 污染 prod DB

更慘的 bug：整合測試 fixture 預設連 CAL_SYNC_DATABASE_URL（= production DB），跑完 drop_all 把表清光。

更糟的是 drop_all 只清 model 裡的表，alembic_version 沒被清 — 導致 prod DB 變成「alembic 認為 up-to-date 但表不存在」的殭屍狀態。

修法：

1. 預設改用 cal_sync_test 而非 cal_sync
2. 加 _assert_isolated() 防呆：如果偵測到 test URL == runtime URL 就拒跑
3. 改用 DROP SCHEMA public CASCADE 一起清 alembic_version

def _assert_isolated(test_url):
    if runtime.path == test.path and runtime.hostname == test.hostname:
        raise RuntimeError("Refusing to run integration tests against runtime DB")

教訓：破壞性測試 fixture 必須有防呆。_assert_isolated() 看起來多餘 — 但它擋住的就是這次親身踩到的災難。

加防禦：Tombstone — 使用者手動操作永遠優先

最有意思的 bug 是這個。

用戶反映：「我手動刪除了該行程，請確認這樣操作。資料順序一定是以我手動修改和調整的為主。」

問題：當用戶修改了 source 的時間（不是內容），然後手動刪除了 target 事件 — 下次 sync 會：

1. desired time ≠ mapping time → PATCH
2. PATCH 到一個已被刪除的 target_event_id
3. Google Calendar 收到 PATCH 後會把 cancelled event 復原回去

也就是說，用戶的手動刪除會被自動同步覆蓋。

這在原本的規格（SRS）裡完全沒涵蓋 — 我們講了「來源變更如何同步」，但完全沒講「使用者手動改 target 怎麼辦」。這是規格的盲點。

解法：加 schema 欄位 event_mappings.user_deleted_at TIMESTAMPTZ NULL，搭配 partial index：

op.add_column("event_mappings",
    sa.Column("user_deleted_at", sa.DateTime(timezone=True), nullable=True))
op.create_index(
    "idx_event_mappings_active",
    "event_mappings", ["user_deleted_at"],
    postgresql_where=sa.text("user_deleted_at IS NULL"),
)

每次 sync 比對：mapping 還在但 target_event_id 不見 → 標 user_deleted_at = now()。標為 tombstone 的 mapping：clipping 階段跳過該 source、compute_plan 不看到該 mapping。

效果：用戶手動刪除一次，永久生效。

教訓：「使用者的手動操作優先」是一個系統設計原則，需要明文寫進架構。沒有 tombstone 機制的同步系統就是會跟使用者作戰。

PDCA 的真意：每個 bug 都是規格的盲點

這三個生產 bug 的共通模式是：它們不是「程式碼錯了」，是「規格沒涵蓋這個情境」。

PDCA 的真意不是「修 bug」，是「把規格盲點補回 spec」 — 下次設計同類系統時，這些 case 不會再漏。

R-P-E 的循環在這裡閉合：上線後發現的 bug → 回頭改 Plan（補 spec、補 ADR）→ Execute 修補 → 再上線。

八、為什麼這套方法在 AI 時代特別重要

讀到這裡，你可能會想：「這些觀念聽起來很合理，但跟 AI 有什麼特別關係？」

答案是：AI 把 R-P-E 從『推薦做法』變成『生存技能』。

公式：AI 產出品質 = 你的 spec 品質 × AI 的能力

過去（沒 AI 時代）：

• 你寫差的 spec → 工程師會問你、會幫你補
• 你寫差的文案大綱 → 設計師會跟你 push back

現在（AI 時代）：

• 你寫差的 spec → AI 照著差的 spec 給你差的 code
• 你寫差的文案大綱 → AI 照著差的大綱寫差的文章

AI 不會反問你（除非你叫它反問）。AI 也不會 push back（它有點太順從）。

這就是為什麼 spec 品質直接決定產出品質。你的 spec 是 1，AI 就只能給你 1.2；你的 spec 是 10，AI 可以給你 100。

AI 不是替代開發者，是放大開發者

很多人把 AI 想成「替代我做 X」。錯。AI 是放大你做 X 的能力。

• 你 R-P-E 做得好，AI 替你交付 10x 速度
• 你 R-P-E 做得差，AI 替你交付 10x 的爛東西

從 Cal-Sync 案例看：

• Research 階段我做（決定要做什麼、為什麼這樣做）
• Plan 階段我做（決定怎麼切、誰先誰後）
• Execute 階段：地基我做、核心並行委派、整合我做
• 上線後 PDCA：問題我看、根因我判斷、修法我設計、實作可委派

AI 在每個階段都有貢獻 — 讀規格、寫程式、跑測試、debug — 但決定權永遠在我這邊。我給 AI 的 prompt 品質決定產出品質；我對 ADR 的堅持決定系統的內聚性；我對「使用者手動操作優先」的判斷決定 tombstone 是否該加。

沒做 R-P-E 的後果 vs 做了的好處

用 AI 寫程式不是「給 AI 一句話然後等好結果」。

「給 AI 一句話」假設 AI 能讀心。實際上 AI 只能看到你給它的字。把 spec 寫好（Research + Plan 的產出），AI 就能寫出好程式。

Cal-Sync 的量化結果

最後給你幾個數字感受 R-P-E 的威力：

SRS 原本預估 4.5 天，實際從規格到 production 大約一個工作天。這不是因為 AI 比人快，而是因為 R-P-E 讓人可以指揮 AI 像指揮一個小團隊 — 規格清楚、邊界明確、驗收先寫，AI 就能在 16 分鐘內並行做完原本要拆給三個工程師三天的事。

九、你怎麼開始

讀到這裡你應該已經抓到 R-P-E 的骨幹。但讀懂不等於會用。R-P-E 是肌肉記憶，需要練。

我給三種讀者三個起點。

給工程師：今晚就試

打開 Claude Code，下次想叫它幫你寫 code 時，先打這句：

please don't write code, just plan first. ask me clarifying questions about the spec until you have 90% confidence you know what to build.

或更簡單地按 Shift+Tab 切到 Plan Mode。

看 AI 會問你什麼。每一個問題都是你 spec 的盲點。

接著嘗試把 ADR Y-Statement 模板帶入你的工作流：每做一個有取捨的技術決策，寫一份 markdown，五行格式：

In the context of <問題情境>,
facing <取捨>,
we decided <決定>,
and against <淘汰的選項>,
to achieve <目標>,
accepting that <代價>.

放在 repo 的 docs/adr/ 目錄。半年後你會感謝今天的自己。

給創作者：寫文章 / 做簡報 / 生圖，先 R 再 P 再 E

下一次你要叫 AI 寫文章 / 做簡報 / 生圖時，強迫自己花至少 20% 時間做 Research + Plan。

• R：跟 AI 對話 10-15 分鐘，把「我為什麼要做這個」「目標讀者 / 觀眾是誰」「市面上類似內容怎麼做」聊清楚
• P：寫一份 200-500 字的「規格」 — 大綱 + 風格 + 範例段落 + 驗收條件（「給三個朋友看，至少 2 個說我會轉發」）
• E：把規格 + 範例段落丟給 AI，讓它一段一段寫，你一段一段改

第一次嘗試會覺得「好麻煩」，但你會發現改的時間大幅縮短。

給企業決策者：把 R-P-E 變成 AI 採購的選擇標準

如果你正在評估 AI 顧問 / AI 工具 / AI 服務商，問三個問題：

1. Research：你們的方法論裡，「跟我們一起搞清楚問題」這段佔多少時間？如果不到 25%，警鈴響。
2. Plan：你們交付的規格長什麼樣？有 FR / NFR / AC 三層嗎？有沒有 ADR？
3. Execute：你們的 AI 工程師動筆前，有沒有 plan approval 的 gate？

R-P-E 不只是個人心法，也可以當成評估工作流成熟度的標尺。

一週挑戰（如果你想自己練）

**做出來就贏 99% 沒做的人。**不用完美，做出來就是贏家。

結語：把三個字母變成肌肉記憶

R-P-E 不是一個概念，是一套需要練的肌肉記憶。

讀到這裡你應該已經能背 — Research → Plan → Execute。但下次你準備丟一句話給 AI 之前，你會記得「我現在要進哪個階段」嗎？

光是停那 5 秒、問自己這個問題，會讓你的 AI 比別人強。

如果你只記得這篇的三句話，我希望是這三句：

心法不會過時，工具會。

多數 AI coding 失控，不是模型問題，是工作流問題。

寫好 spec 比寫好程式重要。寫好程式比寫多程式重要。AI 讓「寫好 spec、寫好程式」的成本史無前例的低。

R-P-E 不是限制你 — R-P-E 是放大你。

如果你想看 Cal-Sync 案例的完整工程紀錄（從 6 個 ADR 到 169 個測試到 4 個生產 bug 的細節），或想把 R-P-E + Claude Code Agent Teams 導入你的團隊，歡迎聯絡昊智未來。

我們用同樣的方法論服務過上市集團 CDO、AI startup founder、傳產數位轉型 PM。三家企業客戶都已經在 production 跑。

作者：Ethan Tsui｜昊智未來創辦人｜前精誠資訊副總經理暨數據長 發布：2026-05-14