從整理建議，進入產品決策

Day 8，我用親和圖把 ChatGPT、Claude、Grok Bot 提出的 PRD 建議整理成群組。原本落落長的內容，變成 74 張問題卡片、9 個討論區塊，終於比較知道可以從哪裡開始了 XD。

接下來，就要回到 Day 7 提到的目標：請 AI 協助我看見盲點，再由自己判斷哪些建議適合這個產品。

今天我和 ChatGPT 逐區討論，從第一版範圍、開始練習的流程，一路談到中斷、紀錄、資料保存與驗收。這篇挑幾個有感的例子，分享我怎麼從「這個建議好像不錯」走到「那第一版就這樣做」。

AI 幫我看見了哪些盲點？

在 Day 7，我請 AI 從產品、設計與工程三種視角檢視 PRD。實際逐區討論後，我發現它提出的問題，主要幫我看見三種不同的缺口。

第一種，是有寫下功能，但還沒有定義清楚它的規則。

例如，我寫了「記錄每次呼吸練習」，卻還沒想清楚：設定十分鐘、只練三分鐘算不算？同一天練三次，累積天數怎麼計算？跨午夜又算哪一天？

AI 沿著這些情境追問，才讓我發現，一句看似清楚的功能描述，實際上還有很多需要回答的問題。

第二種，是想法已經改了，文件卻沒有一起更新。

像是 Day 5 已經改成先選當下感受，PRD 前面的流程仍寫著先選呼吸模式；Day 6 決定採用累積天數，前面的段落卻還留著連續天數。

這些是我自己寫作與設計過程中留下的版本落差。AI 把前後不一致的地方指出來，讓我能重新確認哪一個才是目前的決定。

第三種，是我不熟悉的技術問題，會反過來影響使用體驗。

我原本覺得，閉眼時用震動提示吸氣、吐氣應該就可以了。但接著被問到手機會不會放旁邊、會不會鎖屏，才發現還需要驗證這些情況下能不能跟上節奏。

另外，原稿雖然已經列出來電、切換 App、意外關閉等情境，卻還沒有定義各自要怎麼處理。AI 進一步把問題拆成：計時是否暫停、聲音是否停止、回來後從哪裡繼續，以及紀錄要不要保留。

這一輪讓我更清楚，有些地方是自己沒想到，有些是想到卻還沒決定，也有些只是沒有寫清楚。釐清缺口之後，接下來就能和 AI 一起把它們補齊。

和 AI 一起補齊：先說清楚自己的使用情境

在 Day 1，我希望最後能透過 TestFlight 使用自己做的 App。實際討論第一版的交付目標時，我把它拆成兩個層次：

• 最低目標：能透過 Xcode 跑在自己的 iPhone 上，讓我日常使用。
• 理想目標：進一步透過 TestFlight，提供其他人試用。

我預期在鐵人賽第 25 天附近把 App 做出來，但進度還是會受到現實生活的忙碌程度影響。先把最低目標說清楚，後面遇到新的建議，才有判斷是否要放進第一版的依據。

像是 HealthKit 串接，我覺得是個好概念，但目前自己沒有需求，就先放進 backlog。呼吸動畫我也很想做，不過自己有時會閉眼練習，聲音和觸覺的優先度就會更高。

這些取捨都和我當下的使用情境有關。先讓自己真的用起來，之後才有機會知道哪些功能值得繼續投入。

透過追問，把模糊的想法變成明確規則

討論時，我補充自己的使用習慣與設計意圖，AI 協助拆解情境、說明選項，再把確認後的答案整理成規則。遇到需要實際操作才能判斷的問題，就先記下要驗證什麼。

我的討論方式很直接：請 AI 每次帶一個區塊，我依照卡片編號回答。不懂的問題就請它解釋，還沒想法的就先保留，避免硬選一個答案。

例如，狀態選擇要不要支援複選？確實有可能焦慮又睡不著，但我目前還沒有明確的使用需求，能支撐後面更複雜的呼吸法對應。因此第一版先單選，讓使用者選最符合當下感受的一項，複選放入 backlog。

討論時，我也請 AI 先記錄，等各區談完後再一起更新 PRD。這樣可以回頭檢查前後是否一致，也比較容易分清楚：哪些是我的決定，哪些只是 AI 提出的選項。

整理成可以重複使用的 Prompt，大概會是這樣：

請依照親和圖的區塊，逐區和我討論。保留問題編號，讓我能對照回答。

每輪整理我的決定、取捨理由，以及尚未確認的事項。沒有回答的地方先標示待確認，不要自行補成規格，也不要把你的建議直接當成我的決定。

等全部討論完成後，再依照確認的內容建立新版 PRD，保留原版與變更紀錄。

三個和 AI 一起補齊盲點的例子

1. 設定十分鐘，只練三分鐘，算不算一次？

Day 6，我已經決定使用累積天數，讓自己看見過去投入的時間。但真正要做統計時，還是得先回答：什麼才算一筆練習？

AI 提出的問題包含：有沒有最低時間？一定要完成設定時長嗎？中途離開，要不要留下紀錄？

我的答案是：有練就算。

如果設定十分鐘，實際只練了三分鐘，就記錄一次、累積三分鐘。暫停時間不計入，但也不會因為沒有完成原先設定，就把這三分鐘刪掉。

因為我在意的是自己有沒有留時間照顧當下的狀態。這個想法也延續到心得：想寫就寫，不想寫可以跳過，不需要為了保存紀錄多完成一道作業。

接著還有一個我原本沒想到的問題：如果晚上 11:58 開始，練到隔天 12:03，要算哪一天？

最後我選擇整筆歸到開始練習的日期，不拆成兩天。同一天練三次，則算三次練習、一個練習日。

這些看起來是計算細節，但它們會直接決定使用者回頭看見什麼。當我說「希望紀錄帶來鼓勵」，就需要把這個意圖繼續落到每一條統計規則裡。

2. 人聲先不做，那閉眼時怎麼跟上呼吸？

原本 PRD 裡有提到人聲和背景聲，但我對音訊處理不熟，自己錄音也需要另外準備。

回到使用習慣，我比較想保留自然的 ASMR 背景聲，再用不同的觸覺回饋區分吸氣、吐氣。人聲引導就先移到 backlog，呼吸動畫則有時間再處理。

討論到這裡，AI 又追問：閉眼練習時，我會一直握著手機嗎？還是會放旁邊、甚至鎖屏？

我想了一下，好像沒有固定方式。有時握著、有時放旁邊，也可能忘記螢幕開著，讓手機自己鎖屏。

這讓原本看似簡單的「改用震動」多了一個需要驗證的條件：在我實際會使用的情境裡，觸覺能不能讓我跟上節奏？

目前先確認自然背景聲與觸覺的方向，接下來用真機測試握持、放旁邊、鎖屏與切換 App 的情況。還沒測過之前，我不會把這些體驗都當成已經解決。

這也是這輪討論很有幫助的地方。原本我只在選功能，問到具體情境後，才發現要先做一個小實驗。

3. 這個 App 第一版需要 Supabase 嗎？

在 Day 3，我把 Supabase 寫進 PRD 的初步技術想法，原因很單純：在 Vibe Coding 社群裡常看到，自己過去工作也稍微接觸過，所以想知道這次適不適合使用。

但重新檢查需求後，我目前只想先在自己的手機練習、存紀錄和寫心得，也沒有帳號或跨裝置同步的需求。

因此，第一版決定採用：

核心功能離線可用，紀錄與心得存在手機，App 不主動上傳，也不提供雲端同步。

這代表背景聲和 Quote 清單也要預先放在 App 裡，才能在沒有網路時使用。

同時，我也接受這個範圍的限制：第一版先不做 App 自建備份與匯出；如果刪除 App、手機遺失，而且沒有可用備份，紀錄就可能無法找回。這部分先記錄下來，後續有需要再處理。

不過，資料存手機還是要認真處理。前面既然決定中途離開也保留紀錄，就不能只期待使用者正常完成練習後才存檔。保存進度、意外關閉和更新後的舊資料，都要列入實作與驗收。

AI 整理的答案，也要回頭對照自己的意圖

除了做決策，我也發現需要持續確認 AI 有沒有理解我的畫面。

例如討論首頁時，AI 曾建議把 Quote、累積天數和開始按鈕排出層級。但我的首頁就是先選狀態，接著選呼吸法與時間；Quote 是放在呼吸計時器附近。

如果只看那段建議，確實像是一個合理的首頁設計，但它和我原本的想法有落差。因此我直接把位置與流程重新說清楚，再請它修正紀錄。

這件事也提醒我，要檢查 AI 整理出來的答案，是否仍然對應自己原本想解決的問題。 尤其經過很多輪對話後，一個尚未採納的建議，很容易在下一輪變成「前面已經決定的事」。

最後，把決策整理回 PRD

九個區塊討論完後，我請 AI 讀取原本的 PRD，保留舊版，另外建立 PRD_Final v1.0，並記錄這次改了什麼。

下面先用表格整理第一版與 Final 版的差異，以及每個調整背後的決策理由。文末再附上 PRD_Final v1.0 全文，方便大家直接對照完整規格。

以下以 Day 3 的 PRD 初稿為起點，摘要整理到 Final 版的主要差異與決策理由。部分調整已在 Day 5、Day 6 逐步形成，這次再一起確認並補齊規則。

新版也補上練習狀態對照表與 27 個驗收情境。例如，練習中暫停時，聲音與計時都要停止，等待時間不計入紀錄；中斷結束後，要等使用者手動繼續。

這些目前都是接下來要檢查的項目，還沒有進行實作與真機驗收。把預期結果先寫清楚，之後才能對照功能有沒有照自己的想法運作。

這也呼應 Day 3 提到的 PRD 用途：留下設計意圖，以及當時做這個決定的理由。

有些細節仍留到實作時處理，像是震動模式、聲音素材、日曆一次顯示多長的範圍；這些都有另外標示，沒有因為檔名叫 Final 就突然全部確定。希望之後不要再出現 Final_真的Final XD。

這次討論的心得

Day 8 最有感的是 AI 幫我節省整理資料的時間。今天進一步討論後，我覺得它的幫助也在於，能把我一句比較模糊的想法，繼續追問成具體情境。

「我想記錄每次練習」會接著遇到提前結束、跨午夜、心得沒寫等問題；「我想用震動引導」則需要考慮手機放在哪裡、螢幕有沒有鎖定。

但問得越完整，也越需要提醒自己這一版的目標。合理的建議可以先留下，現在不需要的放進 backlog，涉及實際體驗的就安排驗證。逐項留下處理方式之後，才比較知道接下來要做什麼。

這次也更能體會，設計師除了畫出畫面，還需要把這些平常不一定看得見的行為定義清楚。等自己真的開始使用，再回頭檢查今天做的判斷。

Day 10 內容預告

接下來會逐步進入開發準備與實作與開發環境以及工具的事前準備。ChatGPT、Claude 和 Grok Bot 這次提出建議的差異，我也想另外整理成一篇使用心得，發布日期尚未確定，目前先以產品開發任務為優先項。今天先把產品決策收斂到這裡。明天見，Cheers 🍻

附錄：PRD_Final v1.0 全文

以下直接附上這輪整理後的完整 PRD，方便對照前面的決策過程。這是 2026-09-19 的 v1.0 快照；之後實作若有調整，會另記版本變更。

版本：v1.0 — Day 9 決策整合版

建立日期：2026-09-19

產品負責人：Astro

狀態：已確認需求基準；技術、素材與 UI 細節於實作時處理。尚未進行程式或真機驗收。

原始文件：呼吸放鬆 App - PRD

本頁根據原始 PRD 與 Day 8–9 九區討論整理。原始文件保留，不覆寫；原頁內的 Wireframe、設計探索與研究參考仍可回看。舊圖或舊描述若與本版衝突，以本版已確認需求為準。

「Final」是本輪收斂後的文件名稱，不代表所有實作細節已定案。下文清楚區分已確認規格、待實作決定與開發建議。

1. 版本控制與本次變更

後續規則：文案修正使用 v1.0.x；需求或驗收行為有變動時提升次版本（例如 v1.1），記錄日期、改動、原因與影響的需求／驗收編號。涉及範圍的大改版，先保留前一版獨立快照。Notion 頁面歷程可作輔助，不只靠檔名追蹤。

2. 為什麼做、為誰做

產品定位：一個單純做呼吸練習的 iPhone App。

Astro 平時已有使用呼吸放鬆產品的習慣，但其他 App 往往涵蓋太多功能，因此希望做一個可以每天使用、開始練習負擔較低的產品。透過呼吸給自己片刻放鬆，並透過累積紀錄看見有留時間照顧自己的狀態。

• 第一階段使用者為 Astro 本人；進度允許時再透過 TestFlight 讓他人試用。
• 焦慮、難以專注、睡前是呼吸練習的使用情境，不新增冥想課程、專注工具、睡眠追蹤等獨立功能。
• 成效以日常 dogfooding 的主觀感受與使用體驗判斷，暫不設定連續使用 N 天、留存率或療效目標。
• 開始是否順暢、引導是否容易跟上、紀錄是否帶來鼓勵，可作為觀察提示；不是已承諾的量化成效。

交付目標

• 最低目標：透過 Xcode 將可用 App 跑在自己的 iPhone 上，完成練習與紀錄回顧。
• 理想目標：進一步透過 TestFlight 提供他人試用；不等同承諾 App Store 正式上架。
• 預期鐵人賽 Day 25 附近完成 App；實際完成程度與交付方式依生活安排和開發進度調整。
• 若需要縮減已確認範圍，需另記新決策，不把未完成的必要功能默默改成選配。

3. V1 範圍

非 V1／Backlog／選配

• **Backlog：**人聲錄音引導、HealthKit／第三方串接、平靜但想練習的入口或 tag、狀態複選、App 自建匯出／備份／搬移、無障礙支援、睡前低亮度／深色模式議題。
• **V1 不做：**冥想／專注／睡眠額外功能、帳號與第三方登入、Supabase 後端／App 雲端同步、Onboarding 與首次操作提示、自訂感受、自訂呼吸秒數、沿用上次選擇或個人化、人聲／背景分軌控制。
• **有時間再做：**呼吸動畫。動畫不作核心練習可用的前提。
• **未納入已確認範圍：**非人聲階段提示音、手動補登練習、修改實際計時、遠端 Quote 更新、Heatmap 強度分級與原稿每週時長長條圖。若實作時要加入，另記決策。
• 深色議題延後不代表本版已選定淺色主題；也未承諾主題切換功能。

4. 資訊架構與核心流程

底部導覽

• 主頁：直接選當下感受；首頁沒有 Quote，也不是先經過 Quote＋天數＋開始按鈕的入口頁。
• 紀錄：累積與狀態統計、日期選擇、每日列表與心得。
• 設定：提供設定入口；提醒時間是已確認需求，具體設定項目與布局實作時決定，不額外推導一套帳號或音效設定。

練習流程

選狀態 → 同一步選呼吸法與時間 → 開始背景聲與呼吸練習 → 設定時間到，或長按停止提前結束 → 保存實際練習 → 可選填心得。

心得不填也保存。正常結束後的畫面導向與心得呈現方式留待 UI 設計。App 意外關閉後重新開啟則回首頁，不恢復未完成練習。

回顧流程

進入紀錄 Tab → 查看統計與有／無練習的日曆格 → 點日期 → 當日練習列表 → 回顧單次內容、修改心得或刪除紀錄。狀態次數是否另有點擊下鑽，尚未定案。

5. 感受、呼吸法與時長（#07–14、#62–64、#71）

選擇規則

• 先問當下感受，降低使用者先理解全部呼吸法的負擔；這是設計假設，待自用驗證。
• 感受固定清單、一次只能選一個最符合當下的狀態，不能跳過、不能自訂。
• 選狀態後只顯示該狀態對應方法，不另展開所有呼吸法。
• 可預選方法；單一方法可直接預選，焦慮三種中預選哪一種仍待實作時決定。
• 時長與方法同一步，固定 5／10／15 分鐘，預選 5 分鐘；每次重新選，不沿用上次設定。

以上保留使用者目前的狀態名稱；正式顯示文案留待 UI。狀態與方法的對應是產品決策，不代表已驗證醫療效果。

呼吸節奏

使用者不可自行改秒數。設定時間到立即結束，不等待當輪完成。可先用已確認的 555 驗證整條流程，但不能據此將其餘已列方法從 V1 範圍刪除。

6. 練習畫面、聲音與觸覺（#15–20、#55、#67）

• 保留呼吸計時器；呼吸階段文字、階段倒數與總剩餘時間的具體呈現方式於 UI 階段決定。
• 自然 ASMR 背景聲為必要項目；聲音選材、循環接點、檔案與使用條件由 Astro 另找時間定義，未指定日期。
• 素材隨 App 提供，讓沒網路時也能練習；V1 不依賴串流。
• 不做人聲引導，不加入額外聆聽教學步驟；不做人聲與背景聲的分軌控制。
• 使用觸覺協助分辨吸氣、吐氣等呼吸階段；各階段的震動模式、停頓提示與舒服程度需真機實驗。
• 練習計時、背景聲、觸覺共用一致的進行／暫停邏輯；未來若加動畫亦須對齊。
• Quote 在呼吸計時器附近，從內建清單隨機呈現。清單由 Astro 後續建立；更新時機、句子來源與使用條件尚待確認。
• 使用者可能閉眼、握持手機或放旁邊，也可能手動／自動鎖屏；不可默認使用者願意一直握住手機或保持亮屏。
• 背景聲能播放，不等於鎖屏觸覺一定能持續。先做真機驗證；若無法滿足，回報結果再由 Astro 決定降級方案，不自行加聲音提示或改成禁止鎖屏。

7. 練習狀態 UI 與工程行為對照（#21–28、#72）

下表是依已確認需求整理的實作對照。狀態名稱為內部協作使用，不要求在紀錄頁展示完成／放棄／中斷標籤。確切文案、按鈕位置與樣式仍由 UI 設計決定。

不與其他 App 音樂混音。不禁止使用者開啟其他 App；若其他音訊中斷本 App，依自動暫停與手動恢復規則處理。

鎖定畫面採系統播放器能力。Play／Pause／Resume 的可用操作須驗證；App 內的「長按停止」不直接等同系統鎖定畫面也提供相同操作。

8. 紀錄、日期與統計（#29–43、#66、#68）

一筆練習的定義

• 有練就算：已開始且有實際練習時間，即計一次；不設最低秒數或完成比例。
• 正常結束、提前結束、意外關閉均適用。只選感受而未開始不算。
• 累加實際練習時間，不用預設時長充數；暫停、中斷等待、App 已關閉的時間不計入。
• 同日三筆是 3 次練習、1 個累積練習日；同筆暫停／繼續不得新增次數。
• 每筆以開始當下的當地日期作固定歸屬。跨午夜不拆筆，之後換時區不改歷史歸屬。
• 開始／結束時間照實保存。例如 23:58 至 00:03、無暫停的 5 分鐘練習，全部歸開始日，翌日不因此增加練習日。
• 異常終止可能來不及最後存檔；「練多少記多少」是需求目標，可恢復精度需先量測，不承諾零秒遺失。

心得與編輯

• 心得為 optional 文字，最多 150 字，不設最低字數；空白不影響紀錄或統計。
• 心得與單次練習關聯，可在紀錄中回顧與修改；修改亦使用 150 字限制。
• 支援刪除整筆紀錄，連動重算次數、時間、練習日、狀態統計與日曆標記。
• 刪除某日最後一筆後，該日回到無練習；刪除部分紀錄但仍有有效紀錄，該日仍保留。
• 不從「CRUD」推導手動補登、改計時或改其他欄位的權限；這些尚未定案。

紀錄頁內容

9. 離線、資料保存與隱私（#44–47、#69–70）

V1 核心功能離線可用；紀錄與心得存在手機，App 不主動上傳，不提供 App 雲端同步。

• 呼吸設定、背景素材與 Quote 內建；練習、回顧、心得編輯與刪除不依賴網路。無網路不顯示阻擋核心流程的 lost connection 畫面。
• 採手機本機持久化、無帳號、無自建後端；不使用 Supabase 保存練習資料。資料庫具體選型實作時決定。
• TestFlight 試用者各自在自己的手機保存資料；不因提供多人下載就加入多人雲端資料庫。
• 工程需處理過程存檔、重複結算、寫入失敗與更新資料格式；不只等正常結束或 App 關閉才存。
• 換機、手機遺失／損壞、刪除 App 且無可用備份，可能無法恢復紀錄；App 自建匯出／備份維持 backlog。
• iOS 系統備份與 App 自建同步不同。iCloud Backup 可能依使用者設定納入 App 資料；本版未決定排除系統備份，不宣稱資料絕不離開手機。Apple：iCloud 備份內容
• 中斷事件 log 與使用者紀錄分開：使用者不看完成／放棄分類，但工程保留可辨識中斷資訊。無法觀測的原因不得臆測。

資料模型需要涵蓋的資訊（邏輯需求，非已定 DB schema）

工程建議：log 不複製心得全文；為資料結構建立版本與遷移機制，測試帶著舊紀錄更新。這些是支援需求的實作建議，不指定 framework。

10. 每日提醒與視覺方向

• 每日一次、時間可自訂，避免過度打擾；晚上九點只是使用者舉例，不是已定預設。
• 因核心離線，本機通知是建議方案；通知權限、開關、改時間後替換舊排程、時區與拒絕授權的行為，實作時定義。
• 設計方向：平靜、自然、溫暖；開始練習負擔低、紀錄支持鼓勵與累積。
• 文案、字級、背景對比、透明卡片、按鈕尺寸、No data 樣式與長按回饋留到 UI 階段。
• V1 不做 Onboarding／首次操作提示；無障礙支援與睡前亮度議題列 backlog。
• 呼吸動畫為選配；不讓動畫成為聲音、觸覺或計時的唯一時間來源。

11. 開發環境與先行驗證（#59–60）

已知設備與工具

• Mac：Apple M4、24 GB 記憶體；使用者稱「MBP Air M4」。此處只採已知晶片與記憶體，不猜 Pro／Air 具體型號。
• 真機：iPhone 16e；目前 iOS 版本未提供。
• 支援範圍：先做 iPhone。
• 計畫使用 Codex 與 Claude Code。
• macOS／Xcode 版本、最低支援 iOS、原生或跨平台與資料庫選型，實作準備時確認；本 PRD 不擅自鎖定 SwiftUI 或 SwiftData。

優先做真機小實驗

先用已確認的 555、單一背景聲與最簡控制，驗證下列項目，再擴大 UI 與方法：

1. 在 iPhone 16e 開啟 App 並握持，能否舒服地辨識各階段觸覺。
2. 手機放旁邊且閉眼，實際能否感知並跟上；記錄限制，不當作已通過。
3. 手動／自動鎖屏、切 App 後，聲音、觸覺、階段與總計時是否仍符合需求。
4. 暫停、被中斷、手動繼續是否在原位置接續，等待時間是否排除。
5. 系統鎖定畫面控制是否能正確連動 session，強制結束／重開後能恢復多少已練習時間。

紀錄裝置、OS、測試情境、預期、實際、差異與處置。若平台限制與需求衝突，回到產品決策，不以測試失敗為由默默修改規格。

12. 驗收情境（#61）

以下均為待執行清單，不代表已測試通過。 行為已定案者可直接驗收；仍待決定參數的案例，先補參數再驗證。

13. 音訊與背景真機驗收（#74）

每列都需記錄「實際結果」，目前全部待測。依驗證結果選音訊 category、背景模式與計時策略，本版不鎖定 API 設定。

14. 實作時處理的未決事項（#58）

以下不是本輪要 Astro 逐題重答的清單；進入相關功能實作時再處理。產品取捨仍由 Astro 決定，AI 不自行補規格。Backlog 與「V1 實作前要補」分開。

15. Codex 與 Claude Code 協作建議（待採用，非產品規格）

Astro 已決定使用兩個工具，具體分工尚在詢問。建議先採「Codex 主寫、Claude Code 獨立 review、Astro 真機驗收」：

1. 每次挑一個完整但小的功能，交付本版需求與相關 AC 編號。
2. Codex 實作、建置及必要測試，整理修改內容與尚未驗證的地方。
3. 固定本次 Git diff／commit，讓 Claude Code 用獨立對話只檢查該改動、需求偏差、資料遺失、計時及中斷風險，先提供問題與證據，不直接改碼。
4. 由 Codex 處理確認需要修的問題，兩者不要同時修改同一份工作目錄。
5. Astro 在 iPhone 16e 上驗證聲音、觸覺與流程；通過後記錄驗收結果並提交版本。

共用一份 PRD 與驗收清單，避免兩套需求。分工可以交換，這不是宣稱某個模型天生更適合寫或審。小型視覺修正不必每次都做雙重 review，優先用在計時、音訊、中斷與資料。

Codex 官方亦提供針對 diff／commit 的 review；Claude Code 官方說明獨立工作流程及只讀規劃模式，工具角色不必固定。Codex CLI · Claude Code workflows

16. 決策追溯