DSH 任務看板：讓 Agent 照著看板幹活
三段逐幀核實的 B 站錄屏，覆蓋兩款 DSH 看板外掛——dsh-graph 的目標泳道看板（含一次 5 小時 44 分鐘真實交付實錄）和五列 cron 任務板。從登記條件到打上已交付，每一幀都點到原影片。
最近更新: 2026-10-11
對話流是最差的任務管理介面：Agent 說做完了，你只能翻記錄、靠猜。這一頁講的兩款外掛把工作搬上看板——每個目標一張卡，每張卡寫著驗收條件，每次派發都留下收據。首圖來自一次真實的 5h44m 交付實錄：收集卡上的 token 計數器在跳，八張目標卡在泳道里排隊等派發。
本頁是「任務看板」單點深挖——卡片即工作單。想看人機協作把一個真實專案從需求做到交付的完整流程，去 從需求到交付:用 DSH 做完一個真實專案
要點速覽
- ▸兩款外掛兩種形態：dsh-graph 用版本泳道把目標推過 draft → planning → collecting → ready → in_progress → review → delivered 全生命週期；五列任務板保持待規劃到已失敗的樸素列，卡片上直接掛 cron。
- ▸條件先於程式碼：主管先給每個目標登記書面驗收條件，派發即啟動隔離 git worktree 的 attempt，評審貼收據而不是憑感覺。
- ▸真實實錄的賬面：5h44m、負責人 6 條訊息、22 次裁決、9 個目標全部交付、33 次提交（約 1.7 萬行，產品程式碼 7700 行）、439 個自動化用例全綠——p95 超預算那項，直接變成了看板上的下一個目標。
- ▸兩條安裝命令別混用：目標看板 dsh plugin --profile web add dsh-graph；五列任務板 dsh plugin --profile web add @linxin666/dsh-client-ui-task-board@latest。
十個逐幀核實的步驟
第一部分 · 真實交付實錄（dsh-graph 實戰篇）
- 1
寫程式碼之前，先立目標和驗收條件
實錄開場是主管智慧體連續呼叫八次 graph_create_goal，再給每個目標配上 graph_set_description 和 graph_set_criteria——軌跡裡能看到 g-001 到 g-003。此時一行程式碼都還沒寫；第一道人工門禁，就是確認這份拆解。外掛 README 把規矩寫在明處：條件先於執行登記，後面評審就按這些提前寫好的條目逐一核驗產出。
條件先寫好——第一道門禁就是確認這份拆解。去原影片 1:08 處看 - 2
派發一個目標 = 啟動一個隔離 worktree 的 attempt
派發就是一次呼叫：主管軌跡裡可見 graph_start_attempt、worktree: true。g-002 卡片進入執行列，掛著即時計數（196.2K tokens、上下文 4%）和「開工：繼承 worktree 與基線」徽章——attempt 在固定基線上繼承倉庫狀態，怎麼改都不碰主分支。右上角彈出面板裡還有一位收集代理在並行查 IEC 60617 符號資料。
一次派發，一個隔離 worktree，一條固定基線。去原影片 1:36 處看 - 3
評審貼的是收據，不是感覺
到了評審章節，看板本身就是證據：g-003 在確認列顯示評審中，收據寫著「完工：165 用例/綠 + 實測 35/35 + driver 40/40 無迴歸」，旁邊 g-002 已經打上已交付。頂部軌跡裡還能看到主管用真滑鼠重現子代理斷言的記錄——這次實錄正是靠這種較真，抓出了子代理截圖掩蓋的 4.7 畫素接線縫隙，並按返工單打回。
收據貼在卡上，裁決權留給人。去原影片 2:30 處看 - 4
連收尾都要過人工門禁
七個目標合入後，看板反過來問負責人怎麼收尾 v0.1：清理 worktree 與 tmp（推薦）、打本地 tag、配遠端並推送——每一步都是顯式授權，沒有遠端就不推。稍後版本詳情彈窗直接亮紅：無法發布，1 個目標未 delivered。這一晚收在 9 個目標全部交付、33 次提交、約 1.7 萬行、439 個自動化用例全綠。
沒有負責人點頭，一步都不往外推。去原影片 4:45 處看
第二部分 · 功能演示（同外掛，虛構演示資料）
- 5
演示盤：一塊看板看全生命週期
功能演示片跑在外掛自帶的虛構演示盤上（工作區就叫 demo-zh，應用內徽章寫著「演示資料 · 真實流程」——流程是真的，卡片是編的）。一條版本泳道把卡片送過描述/收集/執行/確認/交付：收集卡顯示已複核·共享並貼著 CRDT 選型對比，執行卡正在滾動「正在最佳化 SQLite FTS5 索引/表」，交付列裡兩張卡剛被主管裁決·確認交付。
卡片是演示的，機制是真的——演示盤全貌。去原影片 3:30 處看 - 6
目標卡 = 描述 + 條件，派發前隨時改
點開 g-012「任務列表：按狀態篩選」就看全一張目標卡的構造：背景與動機講清為什麼要做篩選，範圍與邊界寫明包含和不包含什麼，驗收要點給出可測的硬指標（60fps 下 16ms），外加三條書面品質條件——第三條明確要求空結果要給提示而不是白屏。定義/潤色按鈕把草稿交給產品經理助手把關，它只給邊界建議，不會擅自改你的目標。
契約寫在卡上，派發之前隨便改。去原影片 1:55 處看 - 7
派發臺：模型選擇、指令注入、返工交接
執行上下文頁籤就是派發臺：provider/model 下拉（DeepSeek · DeepSeek-V41-Flash、標準模式）在上一任子代理不可用時會亮警告，最近指令會在下次 attempt 自動注入，返工 Handoff 欄登記返工單——寫清哪裡錯了、哪些程式碼保留、用什麼命令複查，讓來修的 Agent 從事實開始而不是從記憶開始。
派發臺三件套：模型、指令、返工單。去原影片 2:30 處看
第三部分 · 五列 cron 任務板
- 8
第二種形態：五列樸素看板，卡片掛 cron
SolitudeLin 的任務板走樸素路線：待規劃/待辦/進行中/已完成/已失敗五列，彩色標籤篩選（設計、巡檢、文件……），卡片上直接排期。「DSH 每日洩漏巡檢」卡掛著定時 · 3 次執行——每晚 22:00 掃描工作區裡有沒有洩露的金鑰令牌，走外掛自己的宿主側 cron、支援 IANA 時區，賬本存在宿主程序裡，關掉頁面照跑。
五條列，卡上掛 cron，賬本存宿主。去原影片 0:15 處看 - 9
黏一段碎碎念，換一張結構化任務卡
新建任務的 AI 解析框吃碎碎念：把「修掉皮膚配置沒覆蓋外掛的問題；看板週報接到飛書文件；每天 22:00 跑一次洩漏巡檢」整段黏進去，模型自動填好標題、描述和完整的執行 Prompt。下面幾個摺疊項提前釘死執行方式：執行設定繼承部署預設，執行方式選多輪 /goal 做多輪續跑，點建立並執行就真的開一個 DSH 會話——工作區、預設、權限都按你訂的來。
一段碎碎念進去，一張能跑的任務卡出來。去原影片 0:32 處看 - 10
獨立驗收：兩輪 A/B 換位，65 分及格
幹完不算完：驗收報告彈窗顯示品質驗收 1/2 · 驗收異常 0/2，裁判模型是 deepseek-official/deepseek-v4-flash（推理強度 high）。三項條件——Specification Adherence 88.0%、Output Match 84.0%、Error Signal Detection 86.0%——全部越過 65.0 的及格線，每一項都判兩輪、A/B 位置換著來以消除位置偏置，底部連證據範圍（128,400 字元、57 條軌跡）和裁判自己的 token 賬單都印得清清楚楚。
判兩輪、換位置，65 分才過關。去原影片 1:04 處看
常見問題
關於 DSH 任務看板，問得最多的幾個問題，答案都來自錄屏和外掛倉庫。
這頁覆蓋哪幾款 DeepSeek Harness 看板外掛？
兩款。dsh-graph（miuzel/dsh-graph，安裝：dsh plugin --profile web add dsh-graph）是目標看板——版本泳道、驗收條件先行、worktree 派發、評審收據，51 個 graph_* 工具，資料以純文字加只追加 events.jsonl 落在 .dsh-graph 目錄。第二款是 @linxin666/dsh-client-ui-task-board（安裝：dsh plugin --profile web add @linxin666/dsh-client-ui-task-board@latest）——五列看板，帶 cron 排期、真實會話執行和 A/B 驗收，經 zhu1090093659/dsh-web 聚合生態分發。兩個名字都來自 UP 自己的簡介，倉庫已於 2026-10-10 用 GitHub API 複核。
畫面裡的內容是真實工作還是演示資料？
故意混著用，而且分源標註。第一部分實錄是 UP 自報的真實錄屏——5h44m 交付一個 220kV 變電站接線圖編輯器，負責人只發 6 條訊息、點 22 次裁決。第二部分演示盤跑在外掛自帶的虛構資料上（工作區 demo-zh/nebula-notes，簡介寫明，應用內徽章是「演示資料 · 真實流程」）。第三部分是真實介面加虛構任務內容，同樣是 UP 自述。三個源各說各話，頁面不混寫。
任務看板和直接聊天、和 plan 模式有什麼區別？
Plan 模式管的是一場對話：先提方案、再審、批了再執行。看板管的是對話之間的工作：目標在上下文重置後還在，條件在派發前就寫好，attempt 跑在隔離 worktree 裡，狀態由卡片而不是你的記憶來記。dsh-graph 甚至自帶 graph_handoff 和 graph_claim_supervisor，新會話可以冪等地接管一塊已有看板。
這些看板能定時跑任務嗎？
五列任務板可以：宿主側 cron 支援 IANA 時區（洩漏巡檢卡每晚 22:00 跑），賬本存在宿主程序裡，關掉頁面排程照常。dsh-graph 本身是看板不是排程器——DSH 官方的定時任務與提醒是另一條軸（見自動化任務頁）。兩者可以組合：定時任務建卡挪卡，卡片點開真實會話。
怎麼防止 Agent 自己說做完就做完？
兩款外掛都靠機制。dsh-graph 的生命週期由引擎強制（draft → planning → collecting → ready → in_progress → review → delivered），評審按派發前登記的條件逐條核驗，已交付徽章必須負責人裁決——實錄裡版本彈窗因為一個目標未 delivered 直接拒絕發布。五列任務板加了獨立驗收：另一個裁判模型給三項條件打分，每項判兩輪、A/B 位置互換取平均，65 分是底線。
有沒有工作流畫布類的替代品？
有——dsh-deepseek-flow 把工作流畫成畫布來管理，是相鄰位置而不是看板。想要的是對話分叉而非工作單的話，那是 ThoughtDAG 思維畫布。另外 dsh-web 生態裡還列著專做「人與 Agent 共用看板」的 dsh-kanban 專案（alpacachen/dsh-kanban，2026-10-10 查為 ★13）。
相關攻略
工作流簇裡的鄰居——各自到底講什麼。
從需求到交付:用 DSH 做完一個真實專案
完整交付流程:追問需求、寫成 CONTEXT.md 與 ADR,整理成 PRD,拆成 GitHub 任務單,再逐單開發、合併、實機驗收。
閱讀教學dsh 自動化任務實操
在對話裡建立定時提醒，打開內建 Automation tasks 面板，看懂投遞紀錄——10 步逐幀實錄
閱讀教學dsh 無限畫布：用 ThoughtDAG 做會話分支
問題變節點，連線注入摘要或完整上下文，PDF 長出分支，舊 Claude Code 工作階段唯讀匯入——畫布工作流圖文攻略。
閱讀教學計畫模式:/plan、審閱、核准
DeepSeek Harness 的 /plan 命令實測:橘色計畫標記、exit_plan_mode 審核卡,以及和直接執行的差別,10 張截圖逐步講清楚。
閱讀教學會話管理實操：歸檔、刪除與批次操作
在桌面端側欄找到會話入口，用內建面板歸檔恢復，再用 multiselect 外掛批次選取——9 幀實錄，每幀帶時間戳
閱讀教學DSH 工作狀態外顯：工作列狀態燈與完工通知
工作列三色燈即時映照 agent 狀態，提問、幹完活的第一時間彈窗與推送來找你——8 張逐幀核驗截圖。
閱讀教學來源與署名
三段錄屏均來自 B 站創作者——兩段來自 dsh-graph 作者（簡介自報 GitHub miuzel），一段來自任務板外掛作者（簡介自報 zhu1090093659 / npm linxin666）；身份均為簡介自報、未經獨立核實，且都不是 DSH 官方素材。上方每一幀都可點回原影片對應時間點。播放量為 2026-10-10 B 站 API 值；星標數為同日 GitHub API 實查。