dsh 自动代码审查：评审预设、工作台体检与修复派发
看一套真实的 DeepSeek Harness 环境怎么审自己的插件仓库：只读评审 Agent 按清单技能逐项过，变更必须过守卫脚本和测试才算完，工作台还能当场抓 README 与运行时行为的出入。
最近更新: 2026-09-29
大多数「AI 代码审查」演示到「模型给我的 diff 写了评论」就停了。这段 16 分钟的屏幕实录（Ubuntu 虚拟机里跑 dsh Web UI，模型 DeepSeek-V4-Flash）展示了一套更有想法的做法：评审是独立的只读 Agent；任何改动都要过 37 条可移植性守卫、19 个测试套件、1347 条断言才算数；还有一个工作台界面，专门核对每个插件的 README 承诺和运行时实际注册的东西是否一致。
视频里的工作台和预设都是作者的自研插件（发布在 Gitee 的 hecong_dsh_plugins 仓库），不是 dsh 内置功能——但整套模式用标准的预设体系就能复刻，预设基础看 Agent 预设实战
20 秒看懂这套打法
- ▸单独建一个只读评审预设（风控），按 code-risk-audit 清单审代码风险——输入边界、路径与权限、端点与凭据、数据一致性、测试质量——产出带 file:line 和复现方式的发现。
- ▸编码预设自带纪律：先读域约定与技能，改完必跑预检与测试——演示报告里是 37 条守卫通过、预检 exit 0、19 套件 / 1347 条断言。
- ▸编码预设的 PTC（Code Mode）孪生版适合批量巡检：模型写一段 TypeScript 程序组合多步调用，不用一轮轮地追问。
- ▸插件工作台整仓审计——158 个插件按 7 层依赖排卡，还能当场标出 README 与运行时不一致；修复以「开发任务」派发回去。
审查闭环，一步一步
先搭好评审者和被审者
- 1
给评审者单独建一个只读预设
设置 → Agent 预设里，作者把评审这件事单独放在一个叫「风控」的自定义预设里，描述就是完整规格：只读的评审 Agent，按技能 code-risk-audit 的清单审代码风险（输入边界、路径与权限、端点与凭据、数据一致性、测试质量），产出带 file:line 和复现方式的发现，用 agent_ask 把修复交给编码 Agent，自己审不改。旁边是两个编码预设：插件编码（先读域约定与技能，改完必跑预检与测试）和它的 PTC 孪生版——本会话挂的就是后者。
设置 → Agent 预设：只读评审、编码预设和 PTC 孪生版同屏。看 12:30 处 - 2
确认预设到底挂载了什么
Agent 工作台是一张只读地图：预设 → 插件流 → 会话。选中编码预设能看到它的两张身份卡（plugin-dev 和 plugin-dev-ptc）、各自拖进来的 16 个对话级插件，以及底下的 L3 能力提供者——fs-sandbox、subprocess、jobs、skill、goal、web、settings、会话持久化。右侧的挂载会话面板把每个会话对应到工作区路径和模式，放人干活之前先确认评审者和编码者不在一个上下文里。
Agent 工作台把预设 → 插件流 → 会话画成一张只读地图。看 13:00 处
跑评审，读懂三层报告
- 3
跑评审，把三层报告都读一遍
实录开场就是一轮跑完的仓库审查，报告读起来像发布清单。发现层：Agent 自己写出的文件权限是 600，被 chmod 成 644；同时报告点出仓库里既有 59 个 600 文件是本地 umask 的老状态，git 只记可执行位，不该顺手改。验证层：37 条可移植性守卫通过、预检 exit 0、全量自测 19 套件 / 1347 条断言。边界层：Agent 提醒署名和许可要作者自己定，并明确说自己没有 git commit——提交这一步留给人。
报告分三层：发现、机器验证、明说的边界。看 0:30 处 - 4
用工作台做整仓体检
插件工作台把仓库里每个插件渲染成一张卡：158 个运行级插件按 7 层依赖排开（L0 底座：credentials、isolate、loader、locale、storage；L1 传输：api-gateway、webserver），每张卡带提供/调用/发送徽章和违反计数。切到功能域视图，同一批插件按媒体生成、音频、视觉、小说、直播、平台分域——停止级的标红，事故级的打标。分层和分域的计数是活的：卸载一个插件，它就在视图之间移动。
功能域视图：红色是停着的插件，平台域里放观测工具。看 9:10 处 - 5
抓出 README 和运行时对不上的地方
点开任意插件卡，工作台会并排给出「声明 vs 事实（README 与运行时不一致）」：拿 audio-player 这个例子来说，consumes/listen 有些条目只写在 README（webServer「注册路由，提供托管」）、有些只在运行时存在、有些两边都有——这类文档漂移靠肉眼永远看不出来，但集成的时候准出问题。描述本身就地可改，来源是插件的 README，文件路径就标在旁边。
声明 vs 事实：工作台把每份 README 和运行时注册逐项对账。看 6:30 处
派发修复，复检，发布
- 6
把修复派发成任务，而不是一句聊天消息
同一个对话框直接把发现变成工作：在描述里写下你想要的行为（「我想让你负责 xxxxx 功能」），工具条上就有保存并 AI 研发、蓝图版派发「开发」任务、重新检查会话三个动作。对话框自己维护「已改动，未保存」状态，还标出会话的工作目录——改动就落在编码 Agent 之后要跑的那个工作区里。
发现变成任务：改描述、派发，不用往聊天框里粘贴。看 11:00 处 - 7
让 bootstrap 和 preflight 把守最后一道门
实录结尾停在作者发布到 Gitee 的仓库（hecong_dsh_plugins，MIT），README 把这套纪律收成两条命令：bootstrap 装构建依赖、修软链、构建产物、自检；preflight 退出码 0 才谈启动 dsh。前置条件表写明 Node.js 18+（实测 v22/v24 都行）、npm 任意版本、首跑需要联网装 esbuild 和 winbox——之后可离线。这就是审查闭环的最后一条性质：机器验证的那道门放在仓库里，不放在任何人的记忆里。
$node scripts/bootstrap.mjs$node scripts/preflight.mjs
发布出去的仓库把纪律收成两条命令：bootstrap，然后 preflight。看 15:50 处
常见问题
哪些是内置的，哪些是作者自研的，该抄什么。
插件工作台和风控评审是 dsh 官方功能吗？
不是。工作台、风控评审预设和插件编码预设都是视频作者的自研 Cordis 插件，发布在 Gitee 的 hecong9402/hecong_dsh_plugins 仓库（MIT）。dsh 本身内置四个预设（标准、PTC、极简、创造）。视频演示的是一套模式——只读评审预设、放在仓库里的验证脚本、运行时巡检界面——每一样都能用 dsh 文档化的机制复刻。
code-risk-audit 清单都查什么？
按视频里的预设卡：输入边界、路径与权限、端点与凭据、数据一致性、测试质量。发现带 file:line 定位和复现方式。它是作者机器上的自定义技能——你完全可以把自己的清单写成技能，再让你的评审预设指向它。
为什么评审者要只读？
这样裁判就永远不是运动员。预设描述的结尾是「审不改」：发现通过 agent_ask 交回编码 Agent。这套分工还让你天然拿到两路报告——编码者的「做完了」和评审者的「还有这些问题」——第 3 步那份报告就是这个结构。
批量巡检为什么用 PTC 版？
PTC 预设卡自己写了：它以 Code Mode 呈现工具——模型写一段 TypeScript 程序组合多步调用——适合「多次往返」的活，比如扫一遍仓库、反复跑验证。逐步改代码仍然走普通编码预设，每一步都盯得住。
相关攻略
用文档化的零件搭出同一套闭环。
来源与署名
本文 8 张截图全部来自下方 Bilibili 视频（1080p，无任何字幕轨；画面文字逐帧核对），每张深链到原片时间点。视频里的工作台与预设是作者自研插件，发布在 Gitee 的 hecong9402/hecong_dsh_plugins 仓库（MIT），README 已于 2026-09-29 与视频互证。页面文字全部原创，未搬运视频字幕。