Terry Yao's Blog

專案管理系統在管什麼：一張工單誰能結案，以及 API 說成功其實沒改

專案管理系統在管什麼：一張工單誰能結案，以及 API 說成功其實沒改

閱讀時間約 9 分鐘

客服接到客訴：手機結帳時折扣碼沒有套用。她要把這件事交給工程師。接下來會有一連串問題：

  • 這件事現在誰在處理？
  • 處理到哪一步了？
  • 工程師說修好了，誰確認過？
  • 三個月後同樣的問題又出現，當時是怎麼修的？

用聊天訊息交辦，這些問題的答案會散在好幾個對話裡。專案管理系統要解的就是這件事：每件事有一張工單，誰在做、做到哪、誰說它做完了，都記在同一個地方。

核心的東西：工單、狀態、角色

以 open source 的 Redmine（GPL-2.0）為例，核心有三樣：

  • 工單：一件要做的事。分成幾種追蹤類型，例如 bug、新功能、支援。
  • 狀態：工單走到哪一步。預設有新建、處理中、已解決、回饋、已結案、已拒絕。
  • 角色：每個人在專案裡的身分。預設有經理、開發者、回報者。

這三樣加起來，就是 Redmine 最重要的設定：工作流程。它是一張表，規定每個角色可以把工單從哪個狀態改成哪個狀態。

在本機跑起來

我用 Docker 官方 image 加 docker compose，在本機跑了 Redmine 7.0.2，資料庫用 PostgreSQL。兩個容器合計大約 250 MB 記憶體。

架設時有一件事一定要做：Redmine 預設的管理員帳號密碼是 admin/admin。第一次啟動後要立刻換掉。我用指令換掉密碼後，再用 admin/admin 呼叫 API，回 401。

接著建了一個專案和四個人：

  • 經理（pm）
  • 兩位工程師（dev1、dev2）
  • 客服（cs），角色是回報者

Redmine 的 API 有一個功能：管理員的金鑰加上「切換使用者」的標頭，就能扮演其他人操作。這讓我可以用一支程式，模擬四個人輪流處理同一張工單。

一張 bug 走一遍：預設流程

流程是這樣設計的：客服開單 → 工程師處理 → 工程師標示已解決 → 經理驗收後結案。

用預設的工作流程跑一次，結果是：

步驟誰要改成結果
開單客服新建成功
接手工程師處理中成功
自己結案工程師已結案成功
標示已解決工程師已解決回應成功，狀態沒變
結案客服已結案回應成功，狀態沒變

工程師可以跳過驗收，自己結案。 查了預設的工作流程才知道，不只工程師，連回報者（客服）都可以從任何狀態直接改成已結案。預設流程裡，只有經理多一項權力：把已結案的工單重新打開。

預設流程寬鬆，是為了讓小團隊裝好就能用，不會卡在權限上。但如果公司要求「修好的東西要有人驗收」，這個預設值就不符合需求。導入時要先看工作流程的表，不能假設預設值就是你要的流程。

收緊之後：只有經理能結案

我把開發者和回報者「改成已結案」的權限全部拿掉，等於在後台的工作流程頁面取消勾選。總共拿掉 24 個狀態轉換。

用一張新的 bug 重跑：

  • 工程師要自己結案：狀態維持「處理中」。
  • 工程師標示已解決：成功。
  • 客服要結案：狀態維持「已解決」。
  • 經理結案：成功。

工單的歷史紀錄很清楚（欄位名稱譯成中文）：

Dan Developer   狀態：新建 -> 處理中，指派給：dev1
Dan Developer   狀態：處理中 -> 已解決   備註：Fixed rounding in coupon service.
Pei Manager     狀態：已解決 -> 已結案   備註：Verified on staging.

誰在什麼時候把狀態改成什麼，附上什麼說明，都記下來了。三個月後同樣的問題再出現，翻這張工單就知道當時怎麼修、誰驗收的。

最意外的發現：API 說成功，其實沒改

回頭看上面的表，有一件事很奇怪：被擋下的變更，API 回的是 204，也就是「成功」。

工程師要結案、客服要結案，都被工作流程擋下了。但 API 沒有回錯誤，只是安靜地不改狀態。如果同一個請求裡有附備註，備註會存進去；如果沒有，歷史紀錄裡完全沒有這次嘗試的痕跡。

在畫面上操作不會有這個問題，因為畫面只會列出你可以選的狀態。但用 API 串接時，這代表：

  • 串接程式不能相信 204。 改完要重新讀一次工單，確認狀態真的變了。
  • AI 透過 MCP 操作時，問題更嚴重。 AI 呼叫「結案」工具，收到成功，可能就回報「已經結案了」。使用者相信了，工單其實還開著。後來我接上真的 AI 實測：Opus 5.5 會自己回頭確認，Haiku 5.5 三次都相信了「成功」。

這跟 Snipe-IT 那篇遇到的是同一類問題：系統的回應不能直接當結果。 Snipe-IT 是錯誤回 HTTP 200，Redmine 是沒改也回 204。寫 MCP 的人要把這些不一致擋在 AI 前面。

AI 和 MCP 的角色

2026-10 查證時，Redmine 已經有好幾個社群版的 MCP server，最多星的有 248 顆星，說明寫著涵蓋將近 100% 的 Redmine API，包含寫入。我沒有測試這些 MCP server，所以不知道它們有沒有處理「204 但沒改」的情況。

適合交給 AI 的，是讀取和整理：

  • 「這週有哪些工單改了狀態？誰改的？」歷史紀錄裡每一筆都有人、時間、舊值、新值，很適合讓 AI 整理成週報。
  • 「這張 bug 以前有沒有類似的？當時怎麼修的？」
  • 「客服描述的問題，幫我整理成一張格式完整的工單草稿。」

要小心的是寫入：

  • 改狀態之後一定要重新讀取確認。 MCP 工具要自己做這一步，把「實際狀態」回給 AI，而不是回傳 API 的 204。
  • 結案、拒絕這類動作要人確認。 結案代表有人驗收過。AI 沒有驗收，就不應該結案。
  • MCP 的帳號照角色給。 用開發者角色的帳號，工作流程就會擋住結案；用管理員的帳號，所有流程規則都擋不住。

想看實作，可以讀這幾套

系統授權特色AI／MCP 現況（2026-10）
RedmineGPL-2.0Ruby on Rails，工作流程可以細到每個角色、每種追蹤類型社群 MCP 最多 248 顆星，MPL-2.0
OpenProjectGPL-3.0源自 Redmine 的分支，介面較新，有甘特圖與看板社群 MCP 最多 88 顆星，未標授權

相關主題

關係圖譜

反向連結