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 实查。