同時用 Codex 處理幾個功能之後，最容易亂掉的往往是工作脈絡：這個需求在哪段對話討論過、哪個分支正在修改、AI 說完成的功能到底驗收了沒有。對話標題能幫忙分類，卻不容易直接回答這些問題。
dashi-taskboard 將專案、任務狀態、討論紀錄與 Codex 對話連結放進同一個看板。專案目前的 README 使用 Codex Taskboard 這個名稱。它是第三方開源工具，主要價值在於讓任務有可追蹤的入口，並將 AI 執行與人工驗收接起來。
內容目錄
先把工作放進任務，再用對話推進它
聊天很適合探索問題，但專案通常會同時存在尚未決定、可以開始、正在實作與等待驗收的工作。如果只靠對話列表管理，過幾天回來時，就得重新翻找背景、判斷進度。
任務卡片可以固定保存目標、需求與驗收條件，評論則補上後續決策、實作說明和待處理問題。你從卡片回到相關對話，就比較容易知道當時為什麼這樣改，也能把新的要求接回同一個任務。
這屬於Harness Engineering 的工作流程設計：除了模型怎麼回答，也要安排任務如何開始、怎麼追蹤、在哪裡驗證，以及何時交回人處理。
backlog 與 todo：先收集想法，再決定什麼可以做
開發到一半想到新功能，可以先記到 backlog。這個狀態用來保存靈感、尚未釐清的需求與需要挑選的工作，並不代表已同意 AI 立刻執行。等目標、範圍與驗收條件清楚，再移到 todo，作為可領取的工作。
這個區分讓人不必一直配合 Agent 的執行節奏。AI 正在重構時，你仍能記下下一個想法，不用把它塞進正在工作的對話。模型額度暫時不足時，也能先整理需求，等條件允許再安排執行。任務佇列可以保存工作，但不會替帳號增加額度，也不保證額度恢復後必然自動續跑。
同一個功能的討論、實作與修正也可能分散在不同對話。卡片與評論保留各次工作的對話來源，就能按功能回查這些紀錄，不必強迫所有修改都擠在同一段越來越長的聊天裡。
看板與 GitHub Issues 有什麼差別？
看板、優先級、標籤和評論都是成熟的專案管理概念。若團隊已經用 GitHub Issues 與 PR 追蹤需求，而且每個工作都有清楚的驗收條件，未必需要再維護另一套任務資料。
dashi-taskboard 值得評估的部分，是它與本機 Codex 工作環境的連接。依目前文件，卡片可以關聯開發分支或 worktree，也能記錄處理該任務的 Codex 對話。這讓任務、執行過程與工作目錄之間多了一條回查路徑。
是否要採用，可以先看一個問題：你花最多時間的是找不到討論紀錄，還是需求本來就沒有說清楚？前者適合測試任務與對話的連結，後者則要先補需求規格。多一個看板無法自動解決模糊的目標。
需求規格、對話、看板與 Git 各自保存什麼？
- 需求規格保存這次要完成什麼、限制是什麼，以及如何判定完成。
- 對話紀錄保存探索、取捨與執行過程，方便回查決策背景。
- 任務看板整理工作狀態、負責範圍、阻礙與驗收入口。
- Git 與 PR保存實際程式碼變更、版本與合併審查紀錄。
同一個功能可以在規格文件寫完整需求，在卡片放規格連結與驗收條件，再把相關對話和分支連進來。這樣可以減少在不同地方複製同一份需求後，版本逐漸不一致的問題。
也要分清楚對話恢復與檔案還原。像 Pi Agent 的 Session Tree可以保留不同探索路徑，程式碼版本仍要另外管理。找回一段 Codex 對話，同樣不代表工作目錄已經回到當時的狀態。
人工審核要分成執行授權與成果驗收
AI 自己完成實作與檢查之後，仍應留一個讓人驗收的狀態。目前專案附帶的 manage-taskboard Skill 已明確安排這段流程：先認領工作、移到 in_progress，完成實作與驗證後移到 in_review。只有使用者接受成果，或明確要求標記完成，才移到 done。
這是成果的驗收流程。執行期間是否允許某個命令、工具或權限操作，則是另一層問題。任務卡片顯示正在進行，不能當成所有操作都已獲得授權。OpenAI 的 Codex 整合說明也把工具邊界、對話生命週期與核准請求列為執行框架的一部分。
實際使用時，可以要求 AI 在待審核評論中寫清楚改了什麼、如何驗證、哪些情境尚未測試。人再按驗收條件檢查結果。Skill 裡的規則有助於固定流程，但不能把它直接當成不可繞過的權限控制。
排程領取任務，需要另外配置執行流程
可以把工作安排成一個循環：先讀取可執行任務，確認尚未被其他對話認領，再移到進行中。完成實作與自我檢查後交付待審核，人發現問題就留下具體評論，明確退回修改，再讓下一輪工作依最新要求繼續。
定時檢查、挑選任務與啟動 Agent，仍需要配置排程或控制流程，也取決於 Codex 的執行環境、帳號狀態與可用工具。只執行 npm start 啟動看板，不代表背景已經有 Agent 會持續認領工作。多個執行者更新同一卡片時，還要依回傳的 version 處理版本衝突。
也能管理內容研究，但資料收集要有清楚入口
這套方式也適用於內容製作。先把值得研究的題目放進 backlog，選題確認後移到 todo，再讓 Agent 蒐集資料、整理判斷與交付文件連結。方向不對時，把修改要求寫回卡片，讓後續工作有明確依據。
若要降低每次手動布置任務的成本，可以另外設計流程，從已授權存取的收藏清單、團隊表格或 GitHub Issues 整理候選題目。這些來源整合需要個別設定，不能把影片中的工作設計理解成看板已內建所有平台的收藏讀取或文件同步功能。
沒有人即時參與時，可以先產出候選清單或研究初稿，保留等待挑選的成果。外部來源出現的要求，仍應先當成待判斷的資料，尤其是從公開 issue 匯入任務時，要保留篩選與執行授權的界線。
需要分支的工作，用任務關係補上交接
一份研究結果可能接著產生文章、簡報與影片，工作不一定只會沿著同一條看板欄位前進。此時可以拆成各自有交付物與驗收條件的子任務，並記錄前置依賴及輸入文件。
專案 CLI 目前提供父子、阻擋與關聯等任務關係，可以用來描述工作如何接續。不過，可視化節點編排、特定生圖或生影片 API 的自動呼叫，仍要依實際整合確認。流程構想與已經可用的產品功能，應分開看待。
本機安裝：先從瀏覽器版開始
以下以 2026 年 11 月 6 日查核的原始碼為準，固定在 revision bdf7698f6c3f3737a65377814dbb9db7ce81ea38。目前 main 的 package.json 要求 Node.js 22.22.3 以上的 22.x，或 24.8.0 以上版本。以下採用 Node.js 24.8.0 以上環境，請先準備 Git、Node.js 與 npm。
這組命令供 macOS 或 Linux 的終端機使用。先下載並固定原始碼，再安裝依賴與建置前端：
mkdir -p "$HOME/AI"
git clone https://github.com/chuspeeism/dashi-taskboard.git "$HOME/AI/dashi-taskboard"
cd "$HOME/AI/dashi-taskboard"
git checkout bdf7698f6c3f3737a65377814dbb9db7ce81ea38
node --version
npm --version
npm ci
npm run build:web如果同名資料夾已存在，先確認它是不是原本的專案，避免直接覆寫。這裡使用已存在於專案腳本中的 build:web，先單純建置看板介面，不啟動桌面嵌入流程。
接著啟動本機服務，讓這個終端機持續執行：
CODEX_TASKBOARD_HOST=127.0.0.1 npm start在瀏覽器開啟 http://127.0.0.1:47823。原始碼模式的 SQLite 資料庫預設放在專案的 .data/taskboard.sqlite，需要保留任務資料時，應一併考慮該資料目錄與附件。
明確設定 127.0.0.1 是因為目前服務的預設綁定位址為 0.0.0.0。第一次本機試用，可以先讓服務只接受自己電腦的連線。區域網路分享與雲端協作另有設定與驗證需求。
以上已核對文件、版本需求與腳本名稱，本文未實際安裝執行 Taskboard，也未測試各平台的桌面嵌入相容性。實際安裝時，請以命令輸出與目前專案文件為準。
建立專案，讓 CLI 與看板讀取同一套資料
服務啟動後，另外開一個終端機，回到相同專案資料夾，先列出專案：
cd "$HOME/AI/dashi-taskboard"
export CODEX_TASKBOARD_URL="http://127.0.0.1:47823"
npm run taskctl -- project list --json接著可以用看板介面建立專案與任務。如果要用 CLI 建立專案，以下工作目錄請換成真正要開發的程式碼目錄，不是 Taskboard 工具自己的資料夾：
npm run taskctl -- project create \
--id my-project \
--name "My project" \
--workspace-path "/absolute/path/to/your-repository" \
--json拿到看板回傳的實際任務 ID 後，可以用讀取命令檢查內容：
npm run taskctl -- issue get 'ACTUAL_ISSUE_ID' --jsonACTUAL_ISSUE_ID 要替換成真正的識別碼。任務或評論的寫入還需要對話來源資訊，Codex 環境通常由 CODEX_THREAD_ID 提供。不要為了讓命令通過而隨意編造對話 ID，進一步寫入語法可查看taskctl CLI 文件。
安裝 Skill，將領取與交付流程交給 Codex
若要讓 Codex 按看板規則工作，可以先將 taskctl 加入命令列路徑，再建立 Skill 連結。以下假設你使用前面的下載位置，而且目標 Skill 路徑尚未存在：
cd "$HOME/AI/dashi-taskboard"
npm link
mkdir -p "$HOME/.agents/skills"
ln -s "$HOME/AI/dashi-taskboard/skills/manage-taskboard" "$HOME/.agents/skills/manage-taskboard"若連結提示檔案已存在，先確認是不是先前安裝的版本，不必強制覆寫。完成後開啟新的 Codex 任務，並明確指定使用 manage-taskboard 處理哪張卡片。瀏覽器看板、CLI 與 Codex 都要指向同一個服務與正確工作目錄。
一張適合交付的卡片，可以描述「新增匯出功能」，再補上輸出格式、欄位、空資料時的行為與檢查方式。不要只寫「把後端做好」，否則看板再整齊，也很難判定任務是否完成。
對話連結與 worktree 解決的是不同問題
對話連結讓你找回實作背景，分支或 worktree 則讓任務對應到開發環境。目前專案會記錄實際處理任務的對話來源，並提供回到 Codex 的入口。若只有一個 session ID，仍需要原本的對話資料、工作環境與帳號，不能保證換到另一台機器就能直接恢復。
Codex CLI 本身也提供恢復既有對話的功能。看板增加的是任務與對話之間的索引。當多個 Agent 要同時處理不同工作時，仍要清楚安排檔案範圍、分支與整合順序，這與多 Agent 的工作分工是相同的管理問題。
桌面嵌入與雲端協作，可以等基本流程確認後再加
專案除了瀏覽器版，也提供桌面包裝與嵌入 Codex 的方式。這部分依賴第三方啟動器及 Codex 介面相容性，不宜視為官方內建功能。桌面整合若使用調試介面，還會涉及本機存取邊界，因此本文先保留為進階選項，操作請對照專案目前的整合文件。
Linux 桌面安裝包目前文件列出 Ubuntu 24.04 x64，不能直接把這個支援範圍延伸成 ARM64 桌面包已可用。原始碼瀏覽器版與桌面安裝包的支援條件也應分開確認。
本地優先指的是看板服務與資料儲存的位置。Codex 使用模型服務時，仍依原本帳號與服務條款連線，不能把本機看板解讀成全部 AI 推理都離線。需要跨裝置協作時，再依文件配置雲端資料庫與本機配套服務，避免同時維護不一致的任務副本。
第一次試用，先追蹤一個能驗收的小功能
先選一個範圍明確的功能，在卡片寫下目標、工作目錄與驗收條件，交給 Codex 實作。完成後檢查它是否留下變更說明、驗證結果與對話連結，並停在待審核狀態。等你實際驗收，再標記完成。
如果這個流程能減少找對話與重新交代背景的時間，再逐步加入其他任務。若現有 GitHub Issues、規格與 PR 流程已經順暢，也可以保留原本做法，避免讓同一個需求多出另一份要同步的狀態。
常見問題
dashi-taskboard 是 OpenAI 官方產品嗎？
不是。它是第三方開源任務管理工具，目前文件稱為 Codex Taskboard，可連接本機看板、CLI 與 Codex 工作流程。
安裝本機看板後，Codex 就能完全離線使用嗎？
不會。本機看板主要處理任務資料與介面，Codex 的模型連線仍依原本帳號與服務設定運作。
AI 完成程式碼後，任務就會直接變成 done 嗎？
專案目前的 Skill 要求先完成自我驗證，再移到 in_review。只有使用者接受成果或明確要求完成，才標記 done。
一定要把看板嵌入 Codex App 才能用嗎？
不必。可以先使用本機瀏覽器版，確認專案、任務與 CLI 讀取正常，再評估桌面整合。
看板中的對話 ID 可以取代 Git 嗎？
不能。對話 ID 用於回查執行脈絡，Git 用於保存程式碼變更與版本。恢復對話也不代表檔案已回到當時狀態。