Markdown 版本
AI-translated from English; not yet reviewed by a fluent editor.
# 讓核准功能經過 Jira 與檢查完畢的 Claude Code 變更
> 把核准功能落實為真正的 Jira 史詩、所有故事與有實質用途的子任務。檢查每項 Claude Code 變更、確認問題更新,並審查專案指引的處理決定。
By BIG CHANGE Editorial
Published: 2026-10-20T13:23:38.288Z
Updated: 2026-10-20T13:23:38.288Z
Canonical: https://bigchange.ai/blog/claude-code-jira-approved-feature-guide

AI-generated conceptual illustration by BIG CHANGE.
一項核准功能在完成前,可能橫跨三套系統:需求文件、Jira 問題階層,以及程式碼儲存庫。Claude Code 能協助起草與實作,但各系統間的對應關係仍須由人核准並直接查核。本指南帶領開發者或團隊負責人推進一項真實功能,包含**每一個核准故事**、原有測試、經授權的 Jira 更新,以及經過審查的專案指引處理決定。
這是根據文件撰寫的操作程序。BIG CHANGE 沒有存取 Jira 專案、執行 Claude Code、修改儲存庫或測量功能交付時間。確切的問題類型、欄位、狀態轉換、指令與費用,取決於你的專案和帳戶。
## 關鍵改變
- **改變了什麼:** 功能可從核准需求,追蹤到真正的 Jira 父問題與所有故事,再到經審查的程式碼、原有檢查及授權問題更新。
- **為何重要:** 問題對照表、測試紀錄,以及直接從 Jira 回讀的資料,能顯示哪些核准工作已完成、哪個故事仍未完成。
- **應留意什麼:** 專案特有的欄位和狀態轉換、結果不確定的寫入及失敗的檢查,需要人工處理;Claude Code 指引本身不構成工作授權。
## 開始之前
選擇一項功能,須有負責人核准的簡報、你有權修改的儲存庫,以及可執行的原始驗收檢查。其實際工作必須適合在所選 Jira Cloud 專案中設置一個史詩層級父問題、全部核准故事,以及至少一個故事下有意義的子任務。若工作沒有真正的子任務,本指南的完整結果便尚未達成;新增裝飾性問題會使計畫失真。記錄請求人、核准權責者、來源修訂版本、允許資料、起始 Git 提交、隔離或回復方式,以及有權審查程式碼與更改 Jira 狀態的人。
檢查已安裝環境的[Claude Code 版本、驗證與權限](https://code.claude.com/docs/en/permissions)。確認儲存庫的 `CLAUDE.md` 只提供專案指引,不授權修改、執行指令或傳送資料。決定 Claude 能接收哪些需求和程式碼、能執行哪些指令,以及這項功能的用量上限。使用 Claude Code 可能耗用訂閱額度,或產生供應商費用;[Anthropic 的費用指南](https://code.claude.com/docs/en/costs)無法事先確定你的帳單。
在 Jira,取得瀏覽與建立相關問題類型的權限,並取得之後以授權身分留言或轉換問題狀態的權限。私有指令碼可採用[Atlassian 文件記載的電子郵件與 API 權杖方式](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis);整合應用可能需要 OAuth。將憑證存放在私有機密儲存空間,不要放進提示、問題內容、`CLAUDE.md`、日誌或版本控制。將需求傳給 Jira 前,先決定問題的可見範圍。
操作時保留七種私有紀錄:`docs/feature-prd.md`、`ticket-plan.json`、只能附加內容的問題寫入日誌、`ticket-map.json`、每個故事的實作憑據、Jira 更新日誌,以及回顧決定。這些是你的功能紀錄,不是 BIG CHANGE 提供或執行的檔案。
## 1. 核准一份內容明確的 PRD
把實際核准的功能簡報交給 Claude Code,請它在起草 `docs/feature-prd.md` 前找出尚未釐清的問題。文件須包含請求人與核准負責人、輸入修訂版本、問題與目標使用者、範圍及排除項、編號需求 ID、驗收檢查及證據來源、非功能限制、Jira 專案,以及待解問題。由負責人將草稿與原始簡報對照,核准一個確切的內容修訂版本及雜湊值。建立問題或修改程式碼前,先解決實質疑問。
雜湊值讓後續紀錄有明確的來源依據。若 PRD 變動,重新審查受影響的問題計畫和檢查;實作失敗不能成為修改驗收標準來換取通過結果的理由。
## 2. 查明這個專案的 Jira 階層與欄位
透過經授權的**唯讀** Jira REST API v3 請求,逐頁讀取 `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes`。對每個擬用問題類型,逐頁讀取 `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`,找出建立時的必填欄位與允許值。Atlassian 已將範圍廣泛的 `GET /issue/createmeta` 操作標為淘汰,詳見其[問題 API 參考文件](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/)。
確認此專案真正存在的史詩等級父問題、故事層級子問題,以及支援的子任務。Atlassian 說明了[預設階層及其設定](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/);類型名稱和 ID 並非通用。檢查專案的 Parent 欄位在各子層級如何運作,以及建立時需要哪些自訂欄位或可見性設定。若專案無法表示核准的問題結構,記錄缺少的類型、欄位或權限,並暫停建立。一般問題連結不代表父子關係。
## 3. 寫入前審查完整問題計畫
將每項 PRD 需求與驗收檢查對應到 `ticket-plan.json`。記錄其 `planVersion`、PRD 雜湊值、Jira 網站與專案鍵、本機執行 ID,以及計畫核准人和時間。每個擬建問題都要記錄唯一的本機 ID、預期父問題的本機 ID、已查明的問題類型 ID、專案必填欄位、摘要、描述、需求與驗收 ID、負責人及允許的可見範圍。故事及子任務數量應由核准工作決定。每個子任務都須在真正所屬故事下完成實際工作。
Jira REST v3 使用 **Atlassian Document Format (ADF)** 這種結構化 JSON 文件表示多行問題描述與留言。根據核准內容準備文件,並在組成每次請求前檢查網站回傳的欄位中繼資料。[問題 API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/)文件說明建立操作,但無法替未知專案提供現成欄位物件。在任何 `POST` 之前,應由人工核准完整結構、全部需求涵蓋情形、父子關係,以及確切寫入目的地。
## 4. 先建立父問題,再逐項回讀
透過 `POST /rest/api/3/issue` 建立核准父問題,再建立其故事,最後建立每個真正的子任務。在**每一次**請求前,向私有日誌附加一列,記錄執行 ID、本機問題 ID、適用時已確認的父問題鍵、目的地、確切核准請求的雜湊值、UTC 嘗試時間,以及 `pending` 狀態。不要記錄權杖。收到 HTTP 201 後,記錄 Jira 回傳的問題 ID 和鍵,接著直接呼叫 `GET /rest/api/3/issue/{issueIdOrKey}`。把專案、類型、摘要、描述或 PRD 引用及父問題與核准計畫對照。完成回讀後,才能將該列標記為 `confirmed`。父問題確認後,才可建立其子問題。
若請求逾時或回應遺失,將其標記為 `unknown`。依專案、時間、核准摘要與計畫引用檢查 Jira,直接開啟可能符合的問題,請授權負責人確認其身分。[Atlassian 提醒,寫入後的搜尋可能延遲](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/)。找不到搜尋結果,不能證明建立失敗。執行 ID 與日誌能協助核對,但不會讓伺服器拒絕重複建立。切勿盲目重送結果不確定的 `POST` 請求。
直接讀取完成的問題結構並記錄到 `ticket-map.json`:各本機 ID、實際 Jira ID 和鍵、標準問題 URL、專案、類型、父問題鍵、PRD 與驗收 ID、回讀時間及日誌引用。將**所有**核准問題和標準與 PRD 對照。若有問題遺漏或父問題錯誤,停止後續寫入,採用專案經審查的修正流程。
## 5. 實作並獨立審查每個核准故事
依相依順序推進核准故事。對每個故事,記錄 Jira 鍵、起始 Git 提交及分支或工作樹、原始驗收指令、允許路徑與指令。請 Claude Code 使用 [Plan mode](https://code.claude.com/docs/en/common-workflows),將該故事的標準對應到儲存庫。由開發者檢查計畫並授權範圍明確的修改。故事邊界讓變更便於審查,並不表示其餘核准故事可以從功能中刪除。
修改後,保留確切差異、原始檢查指令及完整輸出與結束狀態、相關針對性測試,以及每個需求 ID 的判定。檢查實際程式碼和日誌。書面計畫、生成檔案,或 Claude 聲稱測試通過,都無法證明變更可正常運作。檢查失敗、發現意外機密、相依套件變更、外部寫入或大幅重構時,暫停該故事;在核准範圍內修復,再執行原始檢查。由另一位程式碼審查者決定接受最終提交或暫緩差異。每個故事都要記錄此決定。[我們先前關於一項經審查的 Claude Code 變更指南](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide)涵蓋較窄的程式碼審查階段;這裡的 PRD 與完整 Jira 結構則界定更廣的功能範圍。
## 6. 確認經授權的 Jira 更新
對每個已審查故事,讀取目前的 Jira 狀態並請求 `GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields`。檢查該操作身分實際可用的轉換、目標狀態、必填欄位與允許值。授權負責人接著可透過 `POST /rest/api/3/issue/{key}/transitions` 提交所選轉換,帶入由專案確定的欄位值。再次直接讀取問題,確認新狀態。程式碼檢查通過本身不授權設定 Done、合併或部署。
在 Jira 更新日誌記錄寫入前狀態、預期轉換、操作身分、請求與回應。透過 `POST /rest/api/3/issue/{key}/comment` 發布如實的 ADF 證據留言:接受的提交或暫緩的差異、原始檢查與針對性測試、剩餘失敗項及審查決定。從 Jira 的[留言 API](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/)回讀新留言的 ID 與內文。任一寫入回應不確定時,考慮再次請求前,先直接檢查狀態或留言。轉換清單為空或必填欄位不可用,是應與專案負責人解決的工作流程或權限缺口,不是捏造 ID 的理由。
## 7. 決定是否修改 `CLAUDE.md` 檔案
對照實際 PRD、問題、差異、測試、審查及 Jira 日誌。請 Claude 做簡短回顧,指出實際觀察到的誤解或遺漏檢查。由人工選定明確的指引修改,或記錄不修改的決定,連同審查人與時間。若核准,僅檢查並提交這份 `CLAUDE.md` 差異及其雜湊值。[Anthropic 的記憶指南](https://code.claude.com/docs/en/memory)說明專案指引;這次審查不會自動授權未來工作。不要加入機密,也不要將推測經驗變成專案規則。
## 完成條件與復原
只有滿足以下條件,功能才算完成:核准 PRD 修訂版本對應直接確認的史詩、故事與子任務結構;**每個核准故事**都有起始狀態、接受的差異、原始檢查與針對性測試證據,以及獨立審查;每個授權 Jira 轉換及證據留言都有直接回讀;並且人工已作出回顧決定。若任何項目缺少,記錄確切的剩餘階段。[選擇第一個 AI 任務](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide)這份指南停在較早的任務選擇及擬定檢查階段,無法證明這裡的實作結果。
結果不確定的 Jira 建立操作保持 `unknown`,直到人工核對身分。父問題錯誤時停止建立子問題。測試失敗時保留原標準。缺少轉換或用量耗盡時,為負責人保留附日期的部分完成紀錄。只將核准的最少需求與客戶資料提供給 Claude 和 Jira,檢查目前帳戶費用與權限,並為人工程式碼審查預留資源。本指南說明一條有條件的工具操作路徑,並未報告 BIG CHANGE 已完成的功能、Jira 寫入、模型執行、實測節省、合併或部署。
## 來源與延伸閱讀
- [Atlassian:Jira Cloud REST API v3 問題操作](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/):限定範圍的建立中繼資料、問題建立與讀取,以及狀態轉換操作。讀者專案的欄位和 ID 必須在該專案查明。
- [Atlassian:問題留言](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/):ADF 留言建立及回讀。權限與實際回應仍依網站而異。
- [Atlassian:搜尋與核對](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/):解釋為何寫入後立即搜尋不到結果,不能釐清一次結果不確定的建立操作。
- [Atlassian:問題類型階層](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/):預設層級及設定;仍須檢查所選專案的結構。
- [Anthropic:Claude Code 工作流程](https://code.claude.com/docs/en/common-workflows)、[權限](https://code.claude.com/docs/en/permissions)、[記憶](https://code.claude.com/docs/en/memory)及[費用](https://code.claude.com/docs/en/costs):規劃、修改權限、`CLAUDE.md`指引及用量。這些文件並未記錄本功能的一次執行。
## Sources
- [Atlassian Jira Cloud REST API v3 問題](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — 說明限定範圍的建立中繼資料、問題 POST/GET 及轉換;廣泛的建立中繼資料操作已淘汰。專案欄位、ID 和允許的轉換,必須來自讀者的網站。
- [Atlassian Jira Cloud REST API v3 問題留言](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — 說明 ADF 留言建立及回讀,受實際權限限制。本指南未發布任何留言。
- [Atlassian 搜尋與核對](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — 說明搜尋的最終一致性;建立回應不確定後,搜尋未命中無法證明問題不存在。
- [Atlassian 設定問題類型階層](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — 解釋預設及可設定階層。所選專案的層級和 Parent 行為需要直接查明。
- [Atlassian REST API 基本驗證](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — 說明私有簡單指令碼使用電子郵件加 API 權杖的方式,及整合應用的差異;憑證必須保持私密。
- [Anthropic Claude Code 常見工作流程](https://code.claude.com/docs/en/common-workflows) — 說明 Plan mode 與編碼流程模式;不能證明讀者已完成實作或檢查。
- [Anthropic Claude Code 權限](https://code.claude.com/docs/en/permissions) — 說明實際工具權限及核准機制;僅有 CLAUDE.md 指引不授權執行指令或寫入。
- [Anthropic Claude Code 記憶](https://code.claude.com/docs/en/memory) — 解釋 CLAUDE.md 專案指引;擬議的回顧修改須經人工審查,不是自動學習。
- [Anthropic Claude Code 費用](https://code.claude.com/docs/en/costs) — 用量及計費因方案與供應商而異;這份僅依文件撰寫的指南,未測量費用或節省。
BIG CHANGE 電子報
掌握全貌,按照自己的步調。
關於人工智慧和機器人技術的近期報導、值得關注的轉變,以及可運用的實用想法。選擇每日快訊、每週摘要或每月觀點。
下次預定寄送時間(UTC): . 確認訂閱後,您將在下一個預定寄送時間收到第一期電子報。