這套工作流適合非技術背景的 PM 嗎？

這套工作流主要為 Technical PM 設計，需要基本的命令列操作能力和對 API 概念的理解。如果你熟悉 Git、能閱讀 Python 腳本，就能上手。對於完全非技術背景的 PM，建議先從 MCP 搭配 Claude Code 的部分開始，跳過自定義 API 腳本的步驟，等熟悉後再逐步引入自動化。

使用 API 腳本直接更新 Jira 或 Confluence 有什麼風險？

最大的風險是大規模覆蓋——如果腳本解析出錯或格式轉換不完美（例如 Markdown 轉 ADF 格式），可能意外抹除數月的協作歷史。因此文章強調安全至上的 SOP：務必先在沙盒環境測試、推送前審閱差異（Review Diffs）、盡量以草稿或評論形式推送而非直接覆蓋主頁面。API Token 也應遵循最小權限原則。

為什麼要混合使用 API 腳本和 MCP，而不是全部交給 AI Agent？

API 腳本在處理複雜的過濾條件（如特定 JQL 查詢、遞歸抓取子頁面）時更精準且節省 Token，避免 Agent 在搜尋和過濾過程中的浪費與不穩定。而 Claude Code 搭配 MCP 則擅長智能推理、跨文檔關聯分析和內容產出。混合使用讓各工具發揮所長：腳本負責精準的數據搬運，AI 負責理解和創作。

PRD 寫作革命：類 Git Flow 的高效「離線優化」工作流

TL;DR

離線協作 (Offline-First)：不再受限於網頁編輯器的緩慢與分心。這套工作流程讓你在慣用的 IDE（如 Cursor, VS Code）或 AI 代理（如 Claude Codeosts/claude-computer-use-macos-guide-2026) Code, Antigravity）中，以 Markdown 專注產出。
混合效率 (Hybrid Efficiency)：利用精準的 API 腳本負責「大量數據傳輸」（精準且節省 Token），而將 Claude Code/MCP 用於「邏輯分析、關聯參考與內容產出」。
擺脫瀏覽器限制：像寫代碼一樣對待 PRD。在本地環境「拉取 (Pull)」上下文，使用 Markdown 進行高效編輯，並在審閱差異 (Diff) 後「推回 (Push)」雲端。
安全至上 (Safety First)：務必在沙盒環境進行測試，並建立「審閱差異」的思維，嚴防自動化工具導致的 Jira 或 Confluence 內容大規模覆蓋。

作為一名 Technical Product Manager (TPM)，你的工作處於高層戰略與深層技術實現的交匯點。日常使用的工具——通常是 Jira、Confluence 和 Slack 的大雜燴——有時會讓人感到與實際的工程開發脫節。現在，是時候借鑒開發者的工具箱了：像管理代碼一樣管理你的需求。

這就是所謂的 Claude Code PRD 工作流。

現狀：瀏覽器與上下文的瓶頸

撰寫一份 PRD 通常意味著：

打開 Confluence，在編輯器不穩定的格式中苦苦掙扎。
在 15 個以上的瀏覽器分頁中切換，查找技術文檔與相關 Jira Tickets。這個過程不僅緩慢，且難以讓 LLM 發揮最大價值。若只是單純將混亂的資料丟給 AI，往往會因為上下文過多而導致 Token 浪費，甚至產生幻覺。

解決方案：「混合型」Pull/Push 工作流

最有效率的工作流並不完全依賴 AI Agent 來搬運數據，而是採用 「混合模式 (Hybrid Approach)」：

API 腳本：負責精準、高效的原始數據傳輸（省 Token、保證格式）。
Claude Code + MCP：負責智能推理、跨文檔參考與草案生成。

第一步：精準拉取 (Pull) 上下文

比起要求 AI Agent 在茫茫文檔中「搜尋」，直接利用針對 Jira REST API 編寫的腳本會更有效率。

混合策略：使用 API 腳本來處理 複雜的過濾條件 並精準控制 Fetch Data 的範圍。這正是 API 腳本的價值所在——當你面臨複雜的 JQL 條件、需要遞歸抓取子頁面，或是根據特定自定義字段進行篩選時，API 腳本能提供比 AI Agent 更穩定的精準度。

# 示例：針對複雜過濾條件的精準抓取
python scripts/fetch_jira.py --jql "project = 'AUTH' AND status = 'In Progress' AND labels in ('v2-refactor')" --depth 2 --output target_scope.md

透過 API 處理「數據搬運」，你能為 Claude 提供一個乾淨且高度精煉的上下文。這在過濾條件複雜、數據範圍需要嚴格掌控時尤為重要，同時也避免了 Agent 在「尋找與過濾」過程中浪費的大量 Token。

第二步：智能關聯參考 (Cross-Referencing) 與撰寫

這是最具魔力的部分。你不再只是編輯文字，而是與一個擁有「全域視野」的智能夥伴共同開發需求。

多源導引：利用 Claude Code + MCP 來關聯參考從 Jira 和 Confluence 抓取的數據。

指令示例：「Claude，分析我剛剛從 Jira 拉取的 user-stories，並與 Confluence 上的 architecture-spec 進行關聯參考。找出我們提議的 API 身份驗證流程中可能存在的技術缺口。」

進階技巧：引入 RAG 與 NotebookLM 當你的技術文檔累積到數百頁時，即使是再大的上下文窗口 (Context Window) 也難免力不從心。

策略：將 NotebookLM 作為你的外部大腦。索引大量的 PDF 規格書、舊版 Confluence 導出文檔以及 Slack 對話紀錄。
橋樑：利用如 NotebookLM Claude Skill 這樣的工具，直接從 CLI 查詢你索引的知識庫。這讓你能「與文檔對話」並將精準的片段提取到 PRD 草案中，完全無需手動搜索。

第三步：安全推回 (Push) 更新

⚠️ 安全至上：使用自動化工具更新生產環境的 Confluence 或 Jira 具有極高的風險。如果解析出現故障，可能會意外抹除數月來的協作歷史。

安全標準操作程序 (SOP)：

沙盒優先：在應用到正式環境前，務必先在測試用的 Jira 專案或獨立的 Confluence 空間進行流程測試。
審閱差異 (Review Diffs)：像 Code Review 一樣審視文檔更新。在同步回雲端前，務必對比本地 Markdown 與雲端版本的差異，確保沒有非預期的變更。
草稿模式：如果可能，請先將更新推送到「草稿」或「評論」區，而非直接覆蓋主頁面內容。

常見陷阱與避免方案

ADF 格式轉換：Confluence 使用的是 ADF 格式。Markdown -> ADF 的轉換可能不完美，建議使用功能完整的庫（如 atlassian-python-api）來處理。
上下文窗口限制：面對超大型 PRD，不要一次丟入所有內容。利用 Anthropic 的 MCP 進行局部索引。
權限管理：確保你的 API Token 遵循「最小權限原則」，僅授權寫入特定的專案或空間。

權威資源參考

Anthropic Academy：學習與 Claude 進行 Agentic Coding 的最佳實踐。
Atlassian Rovo MCP Server：連接 Claude 與 Atlassian 數據的官方橋樑。
Jira Cloud API 参考：開發自定義精準腳本的必備文檔。
Model Context Protocol (MCP)：AI 數據集成的開放標準。

透過消除需求定義與開發工具之間的隔閡，你不僅能寫出更高質量的 PRD，還能與工程團隊建立更深層的技術共識。