在軟體開發裡面，Issue Ticket 其實就是我們常說的「工作單」或「任務卡」。
不管是工程師要幫系統加一個新功能，還是要修復一個 Bug，每一項工作都必須先有一張專屬的 Ticket。 這張單子就是整個開發流程的起點，也是所有紀錄的歷程。
如果每個人開工單都隨便亂寫，系統自動化就會大亂。所以我們必須在 Jira 或 Notion 這種工具裡，幫 Ticket 設好幾個必要的條件（欄位）：
任務 ID（像是編號 PROJ-123）：
變更類型（Type，像是功能、修復、文件）：
狀態（Status，像是進行中、審查中）：
完成準則（DoD，Definition of Done）：
為了將上述的標準化欄位與自動化思維落地，我們以客製化的 Notion 為例，說明如何將其轉化為 CI/CD 流程的起點：
資料庫屬性（Properties）的強型別化：在 Notion 建立 Task Database 時，必須利用 Select 或 Relation 屬性精準對應上述提到的欄位（如變更類型、優先順序）。透過嚴格的欄位格式，避免自由文本（Free text）帶來的格式混亂，確保後續 CI 工具透過 API 抓取資料時的準確性。
原生 GitHub 雙向同步：啟用 Notion 的原生 GitHub 整合功能。當開發者在 GitHub 建立 Pull Request 並在描述中輸入 Fixes PROJ-123（對應 Notion 的任務唯一 ID）時，Notion 端的任務狀態即可自動從「開發中」推進至「審查中（In Review）」。
API 驅動的自動化回填：結合 GitHub Actions 與 Notion API，當 CI 流程中的單元測試或安全掃描完成時，透過自動化腳本將測試結果（如覆蓋率、成功或失敗狀態）直接寫入 Notion 該任務的留言區。這讓非工程背景的 PM 也能在 Notion 上即時掌握品質數據。
我們提倡「單一任務原則」（Atomic Issue Principle），也就是讓一個 Issue 只對應一個修改目標。這能有效降低 Code Review 的難度，同時讓自動化流程在排查錯誤（Troubleshooting）時變得更加精確。
背景資訊結構化：在 Issue 中提供清楚且詳細的上下文。這對 GitHub Copilot 或 Cursor 等 AI 輔助開發工具非常關鍵，優質的工單描述能大幅提升 AI 產生程式碼的準確度與業務符合度。
DoD 的自動化驗證：將「完成準則」（Definition of Done）轉化為實際的測試腳本。當 CI 流程通過所有預設的驗收測試後，系統就能自動將 Issue 狀態更新為「待合併」或「已完成」。
在進階的 CI/CD 實踐中，我們會透過 Webhooks 讓 Issue 系統與版本控制系統緊密串聯，打造出流暢的自動化閉環：
自動狀態遷移：當開發者建立 Pull Request 時，系統會自動把相關聯的 Issue 標記為「進行中」。
測試結果回填：CI 執行完畢後，系統會自動把測試總結（Test Summary）與品質門禁報告（Quality Gate Report）以留言形式回填到 Issue 中，讓管理者與 QA 不用切換平台，就能隨時掌握專案進度。
部署後追蹤：當程式碼順利進入生產環境後，系統會自動關閉對應的 Issue，並標註這次上線的版本號。
Issue Ticket 是軟體開發流程中的數位地圖，也是自動化交付流程的驅動核心。透過標準化的欄位設計與流程自動化，我們能確保交付和開發過程中的每一項決策都是基於數據與事實，或是有討論紀錄。
在定義好需求的源頭後，明天我們將把焦點轉向開發者的 IDE，探討如何在那裡建立第一道自動化防線。
想請問~ 如果目標是讓AI能從Issue的需求描述出發，要先理解現有程式碼並準確定位需要修改的Module或Code，會做哪些前置作業呢?
有想建立類似的開發流程，但有一個考量是希望AI不需要每次都大範圍讀取整個Source Code，除了要提高定位準確度，也希望控制Token使用成本。
目前規劃一套開發知識庫放在Repo內，開發知識會依照公司實際的系統與開發方式，以Module為單位整理必要的知識，例如Module的用途、邊界、主要功能、商業邏輯、依賴、耦合，以及對應的Source Code位置。目的是希望在讓AI分析需求或執行時能先閱讀知識庫，了解模組的限制及背景，並更精確找到要異動的核心位置。
想請教大大這樣的設計是否合理及對於這樣設計的看法?
如果你今天是文件等固定不太變動的相關知識，我一定會建議建RAG。
但如果今天是codebase，表示它會隨時變動，但又要減少token的使用，我的經驗就是建一個index map，列出不同module和它的作用範圍，作為AI可以第一步參考的依據。
但這邊要注意，這種map也是需要根據code來做變動，所以不建議每次改code都要改這份，常常會忘記改造成map和codebase不符合。
建議加入CI流程之一來讓每次merge後就自動更新這份map，這類型的map不需要用AI就可以建出來，在以前還沒有AI的時候也都會用一些tool和doc-string來產生這些程式說明文件。例如Sphinx。
讓AI在去真的讀code之前，給一些prompt把這份map加進去prompt內，作為第一階段搜索，再結合一些skills或一些文件搜索、API串接，可以大幅減少token的使用。
如果覺得讀全部你寫的skills太多太發散，那就建agents把它當作micro-service，給它一些prompt讓他專注做某些事情，也是節省token的一種方式。
雖然我這系列幾乎沒提到整合AI的使用，比較像是建立未來整合AI的基礎建設。(畢竟是幾年前的文章)
但你的問題很好，讓我思考可以寫一系列使用AI的經驗分享。因為除了上述我講的方法以外，還可以結合向量資料的儲存、非監督式分類來快速且精確的定位"未來"的issue的解決方法，如IVF索引或Tree-based RAG。
另外，Issue/bug ticket本身的品質與內容也是蠻重要的一環，畢竟怎樣讓AI快速定位issue內容並找到相對應的code去修改，常常需要藉由判斷裡面的log來分析，debug log檔案通常也是超大。這又是另一個課題。
感謝分享!
根據你提到的內容，也讓我重新思考了Codebase知識文件的設計。也許應該將抽象的專案知識與建立Index Map這兩件事分開探討，畢竟兩者的作用不太一樣。
另外，對於Skills的處理方式，我原本也沒想到可以這樣做。總之這系列讓我多了蠻多思考方向的，我再好好拜讀＆研究一下，感謝大大分享!
iThome鐵人賽
看影片追技術