前两周我把 DeepSeek Harness 从 0.1.1 一路折腾到最新版期间最满意的一笔改动就是给这套环境加上了 dsh-diff-approval——简单说就是让 AI 在 DeepSeek Harness 里写完代码之后改动不能直接落地所有 diff 必须先整整齐齐排在我面前等我逐条点头才真正写进项目文件。这个机制解决的是我长期以来的痛点AI 写代码的速度永远比人审代码快快就会出事。如果你也在搜“deepseek harness 是什么”“deepseek harness 怎么安装”或者刚把桌面版装好、正在困惑“AI 改的代码到底能不能信”那这篇文章应该是你要的。我会讲清楚 DeepSeek Harness 解决了什么问题为什么 AI 编程必须叠加一层代码改动审批以及我实际配置 dsh-diff-approval、跑通一次完整流程的全部操作和踩坑记录。1. 先把背景说清楚DeepSeek Harness 到底在管什么1.1 它不是模型而是“让模型干活”的壳很多人第一次听到 DeepSeek Harness第一反应是“这不就是又一个大模型吗”。实际上它和模型是两层东西。模型负责生成文本、代码、推理结果而 Harness 负责把模型输出的内容真正变成项目里的改动——它要调度工具、读写文件、执行命令、管理上下文还要处理模型和外部环境之间的数据流。打个比方模型是大脑Harness 是手和脚。没有 Harness你只能在大模型对话框里复制粘贴代码有了 HarnessAI 能自己打开项目目录、分析代码结构、修改文件、跑测试甚至命令执行完后把结果回传给模型继续下一步。社区里经常拿 DeepSeek Harness 和 Codex Harness 对比本质上是同一类东西给编程大模型套一层可执行、可控制的外壳区别在于后端用的是 DeepSeek 的模型能力、配置方式和插件体系不同。我在 Ubuntu 服务器上跑 Harness 核心服务本地 Windows 用桌面客户端和 VSCode 插件连上去操作整个体验其实挺像在用 IDE 的远程开发模式。这也是大家搜“deepseek harness desktop”“deepseek harness 本地连接 ubuntu”的原因——核心跑在算力好的机器上日常操作留在本地桌面。1.2 为什么“会改代码”和“敢让 AI 改代码”是两回事模型写出的代码片段看起来合理和它跑完一个任务后在你项目里留下的最终状态之间隔着很大的风险。我见过太多次AI 为了修一个空指针顺手改掉了三个文件的初始化顺序为了让单测通过把断言条件直接改成恒真甚至有一次它自己生成了密钥文件差点被提交进仓库。这些问题的共性不是模型能力不行而是缺少“门禁”。传统开发流程里任何人改代码都要走代码审查提交一个 Pull Request同事看 diff指出问题修改再合入。到了 AI 编程环节很多人因为图省事直接让模型原地修改文件等于把代码审查这道工序整个删掉了。dsh-diff-approval 想做的就是把代码审查这个好习惯重新装回 AI 编程流程里。模型照常干活但所有文件改动会被拦截、打包成 diff 进入审批队列开发者看完再决定是应用、拒绝还是微调。这个机制保证了一件事AI 负责“写”人负责“负责”。1.3 和直接在终端看 diff 有什么本质区别有人会问AI 改完之后我不也能用git diff看到改动吗何必多此一举区别在于时机和粒度。git diff是事后诸葛亮——等模型已经把所有操作执行完、文件已经被改写之后你看到的是一大片混杂的改动哪个文件是哪个任务的产物、中间经历了什么很难追溯。dsh-diff-approval 的机制是“事前闸门”模型在执行阶段把改动写入隔离的暂存区不碰真实文件。等到整个任务跑完系统统一汇总出结构化 diff这时候你面对的不是一团乱麻而是“任务 A 涉及 3 个文件各改了哪些行”每条改动都有对应的任务 ID 和模型推理摘要。我实际用下来最大的感受是终于不用在 AI 跑完之后“考古”了。2. dsh-diff-approval 的整体设计与功能拆解2.1 设计原则默认不信任审批要可追溯给 Harness 设计审批模块我给自己定了三条原则。第一条是“默认不信任”。模型生成的任何改动在没有被人审阅之前一律视为不可信。配置里默认mode: require_all也就是所有任务必须拿到审批才能落地。这条原则看着简单执行起来最容易被人忽略因为总有人为了效率临时关掉审批而事故往往就出在“就跑这一次不审了”的侥幸里。第二条是“审批动作可追溯”。谁在什么时间批准了哪条改动是全部批准还是部分批准有没有人在批准前手动编辑过 diff这些信息要完整记录到日志里。后期如果线上出了故障要能顺着记录翻回去看是不是某次 AI 改动导致的。第三条是“可以慢但不能堵”。审批虽然多了一道关卡但不能让任务队列堵死。我设计了“审批挂起”机制模型跑完任务后先把 diff 挂起任务状态标记为awaiting_approval开发者有空时统一处理。这样既能保证改动不落地又不会让 AI 的任务流水线停下来等人工。2.2 四个核心模块怎么配合整套 dsh-diff-approval 由四个模块协作完成。diff 采集模块负责追踪 Harness 执行期间发生的所有文件变更。它会在任务开始时记录文件快照任务结束时对比出新增、修改、删除的行按统一格式合并成 patch。这里有个关键细节它追踪的是 Harness 里的文件状态不直接依赖 Git。这样即使项目还没初始化仓库也能做审批等审批完再统一提交。审批请求模块负责把 diff 转换成“待办事项”。每个待审批项包含任务描述、涉及文件列表、具体变更块、模型的修改说明。如果配置了审批规则文件系统会读取这个 Markdown 文档把自定义规则附加到审批请求中。比如我在.dsh/approval-rules.md里写了“禁止修改锁文件”“新增依赖必须说明原因”这些内容会随审批请求一起推送到桌面端。审批执行模块是核心交互入口。开发者可以对整个任务统一批准也可以针对单个文件批准拒绝时可以选择“丢弃改动”或“打回重做”。比较实用的功能是“编辑 diff”——直接在界面上把模型改得不理想的部分改掉其余部分照常应用省去让模型反复返工的时间。日志审计模块把所有操作流记录下来。模型生成 diff、开发者审阅、修改、批准、拒绝全部带时间戳和人名或机器名。配合 Harness 本身的任务日志同一时间线上能看到非常完整的因果链。2.3 审批粒度文件级、代码块级与策略匹配审批粒度直接决定人工成本。一开始我全用文件级审批一眼扫过去看看文件名还算轻松但文件一大几百行的 diff 要一口气看完到后半段注意力明显下降。后来我改成“代码块级 策略匹配”的混合模式。策略匹配的做法是给 diff 设置自动预筛规则。比如纯注释改动、格式化工具产生的空白调整、README 文档更新这些可以直接标记为low_risk默认放行并记入日志。而涉及依赖清单、构建配置、认证鉴权相关代码的改动强制标记为high_risk必须人工逐块审阅。这样既能保证安全性又不会让低价值改动消耗大量人工精力。实际用下来代码块级审批的体验最均衡——每次只需要集中看十到二十行改动上下文一目了然。遇到大文件我会按文件分批审批而不是一口气滑到底。3. 实操从安装配置到跑通一次审批流程3.1 环境准备与安装步骤我目前的环境是一台 24 核的 Ubuntu 22.04 服务器当核心运行节点本地笔记本装桌面端和 VSCode 插件做交互终端。整个安装过程大约是以下几个步骤以 0.1.1 版本为参照# 服务器端安装核心服务 pip install deepseek-harness0.1.1 dsh server start --host 0.0.0.0 --port 8787这里我要强调一下--host的配置如果是个人使用建议只监听127.0.0.1通过 SSH 隧道转发到本地访问不要直接暴露到公网。Harness 要执行代码本质上是一个远程执行环境暴露公网等于把一把枪递到陌生人手里。本地端相对简单装上桌面版客户端连接服务器的地址和端口即可。VSCode 插件提供的是编辑器内交互体验适合边写代码边使用 Harness。我的习惯是本地连接配置保持和服务器一致的认证方式不额外开启免密登录避免插件意外暴露在局域网内被人扫到。# 本地 Ubuntu / macOS 安装客户端 pip install deepseek-harness-client dsh connect --server 127.0.0.1:87873.2 启用量身定制的审批配置安装完成后核心一步是修改配置文件。Harness 的配置入口在~/.dsh/config.yaml我贴一份经过实战调优的最小配置diff_approval: enabled: true mode: require_all # 可选: off / low_risk_only / require_all ignore_paths: - docs/** - *.lock - tests/fixtures/** high_risk_paths: - package.json - requirements.txt - **/auth/** - Dockerfile prompt_file: .dsh/approval-rules.md auto_apply_low_risk: true model: provider: deepseek temperature: 0.2 max_tokens: 8192有几个参数我单独解释一下。ignore_paths是审批白名单命中路径的改动不进入审批队列。我给docs/**和*.lock开了白名单因为文档改动和依赖锁文件不太可能引入逻辑问题。但注意白名单不能开太大我曾经图省事把tests/**也扔进去结果模型改测试用例让断言从assertEqual(a, b)变成了assertEqual(a, a)几乎不可能被断言拦住这个坑后面细说。high_risk_paths是红名单命中路径的改动无论大小都必须人工审批。我的习惯是把依赖清单、鉴权模块、Docker 相关配置都放进红名单因为这些地方一旦出错影响面是整个项目。prompt_file指定的是审批规则文档路径。Harness 会读取这个 Markdown 文件把其中的规则和项目的实际 diff 内容一起打包这样审阅者在看 diff 的时候就能直接对照项目自身的红线要求。3.3 完整跑通一次审批流程配置好之后我用一个实际问题演示完整流程。假设项目里有一段登录接口代码存在空指针我让 Harness 修复。$ dsh task submit 修复登录接口的空指针问题 [agent] 读取项目结构... [agent] 定位到 auth_service.py, login_view.py, config.py [agent] 生成修复方案共涉及 3 个文件 17 行改动 [agent] 任务完成等待人工审批... Pending diff review: auth_service.py 8 -2 login_view.py 3 -1 config.py 6 -0 Run dsh diff show file to inspect changes. Run dsh diff approve to apply all approved changes.这一步模型已经完成了所有分析和修改但真实文件还没被碰过。我继续查看具体改动$ dsh diff show auth_service.py --- a/auth_service.py b/auth_service.py -45,7 45,13 def login(username, password): - user find_user(username) if username is None or password is None: raise ValueError(username and password must not be empty) user find_user(username.strip()) if user is None: raise UserNotFoundError(username)这时我可以选择审批也可以先手动修改 diff 再应用$ dsh diff approve auth_service.py [approval] auth_service.py 已批准 $ dsh diff approve --all [approval] 所有改动的审批完成正在应用... [approval] 3 个文件已更新 $ dsh task test login [test] 登录接口测试通过整个流程的体验非常接近“看 Pull Request → 点同意合并”只是审查对象从同事的代码变成了 AI 的代码。核心区别在于同事做代码审查还要考虑沟通、解释设计意图而面对 AI 只需要验证逻辑正确性审批速度反而更快。4. 常见问题与排查实录4.1 模型“胡乱冒字”怎么排查搜“deepseek harness 胡乱冒字出来”的人不少我遇到过两次一次是模型在代码文件里生成了大段自然语言解释一次是在终端日志里突然冒出与任务无关的文字。排查思路按顺序来。第一步检查上下文长度。Harness 会把项目文件内容、修改记录、模型输出统一塞进上下文超过窗口长度后模型容易丢失指令约束出现“出戏”。通过dsh task log --last看该任务的 token 消耗如果接近上限就该压缩上下文、拆分任务。第二步检查temperature设置。写代码任务建议0.1~0.3我配置里用的0.2。高于0.7时模型会趋于发散代码场景很容易冒出解释性文字。第三步检查是否是多个任务并发导致的日志交错。Harness 的终端输出是任务级别混流的两个任务同时跑A 任务的中间结果可能冲到 B 任务的日志区看起来就像“胡乱冒字”。对应办法是开启任务隔离日志或者把并发数降到 1。4.2 “怎么读取 md 文件”其实是个上下文管理问题很多人问 DeepSeek Harness 怎么读取 md 文件其实 Harness 本身能读任何文件问题是“读进来了放哪里、有没有被带进审批上下文”。默认情况下模型只会关注当前任务显式涉及的文件不会主动读取项目里的说明文档。想让 Harness 读懂项目文档两个途径。第一种是把文档路径直接写进任务描述比如“请阅读docs/auth-flow.md后修复登录逻辑”模型启动时会主动加载。第二种是充分利用prompt_file配置让审批规则常驻上下文这样不仅模型行为会受到规则约束审批界面也会把规则和 diff 一起呈现给审阅者。还有个细节md 文件里的中文内容要确保文件编码是 UTF-8。我遇到过用 GBK 编码的 README 被读取后出现乱码Harness 内部处理上下文时非 UTF-8 文件经常会出现截断或转换异常。4.3 审批流程和 Git 工作流怎么配合才不打架刚开始用的时候我让 Harness 改完直接自动提交 Git结果审批界面和 Git 提交历史经常对不上——有时候审批还没通过文件已经进了暂存区。后来我调整了策略Harness 的改动全部留在工作区approve只负责把改动写入工作区文件提交操作完全由人工在 Git 侧完成。这个改动让工作流清晰了很多。审批通过之后我再手动执行git add和git commit提交信息里标注任务 ID。万一哪次线上出问题顺着任务 ID 就能定位到具体的 AI 任务和当时的审批记录。给 Harness 开了自动提交权限看似省事实际上失去了代码审查里最重要的一道缓冲。另外一个建议是审批通过后立刻跑一遍测试。dsh-diff-approval 只管“改动是否被允许”不管“改动是否正确”。我在流程里加了一步批准后强制执行模块级测试再把结果追加到审计日志。这一步看着简单但能把大量逻辑问题拦截在合入之前。4.4 从安全视角看审批时应该重点盯哪些 diffdsh-diff-approval 还有一个很重要的价值它是多数人面对 AI 编码工具时最容易忽略的安全防线。 Harness 能执行命令、修改文件、写密钥如果完全不设防等于把仓库的写权限交给一个可能犯错的模型。我在审批时总结了四类高危改动第一类是权限相关代码包括任何涉及sudo、chmod、umask、用户权限判断的改动必须逐行确认逻辑正确第二类是密钥和敏感信息涉及password、token、secret、api_key等字符串一旦新增就要警惕是否会把硬编码密钥写进代码第三类是依赖变化package.json、requirements.txt里出现新依赖时要看是否真的需要以及来源是否可信第四类是命令执行os.system、subprocess、exec相关改动必须确认命令参数不会被注入。我做了个简单的审阅速查表贴在审批界面旁边风险类型观察点处置方式权限提升出现sudo、chmod 777、root拒绝并修改为最小权限敏感信息泄露新增密钥、密码、token 字符串立即移除检查是否已写入历史记录依赖投毒出现不熟悉的第三方包核查包名、来源、下载量无把握就拒绝命令注入拼接字符串后传给 shell改用参数化方式拒绝直接 eval/exec测试造假断言被改成恒真或直接 return改回有效断言必要时人工重写测试这些看起来是安全常识但落到 AI 生成代码的语境里信息密度一下就上来了——你以为它在修 bug实际上可能是为了“让测试变绿”偷偷把断言改没了。5. 一些藏在细节里的经验与后续扩展方向5.1 先跑通最小闭环再谈优化如果你刚接触 DeepSeek Harness 和 dsh-diff-approval我的建议是别一上来就把配置表填满。先保持最简配置开require_allignore_paths先留空跑一两个小任务把“改写文件 → 生成 diff → 人工审批 → 应用”这条链路走通。等你有信心了再把文档路径、自动应用低风险改动、红名单这些高级配置加进去。我见过太多人一开始就把各种路径写进ignore_paths结果模型在一个没被纳入审批的文件里搞出大问题事后追责才发现是白名单开太大了。审批的第一价值是“有”第二才是“精”。先把关卡立住再逐步放宽。5.2 审批粒度别贪细也别放太宽代码块级审批最直观但不是什么场景都值得用。我现在的策略是小任务、改动范围明确直接批量快速审批涉及架构调整、重构、依赖变更的大任务逐个文件细看。完全不用粒度策略和大文件直接整体放行这两种极端都不推荐——前者累死人后者等于没有审批。5.3 后面我准备做的三个扩展dsh-diff-approval 目前在我的环境里已经很顺手但还有几个方向想继续折腾。第一个是接 CI 门禁审批通过后自动触发对应模块的测试测试不过就不允许真正落地把“人工审批”和“自动验证”连成一道更深的安全网。第二个是生成人类可读的 diff 摘要让模型在代码块级 diff 后面补一句“为什么这么改”能显著降低审查者的阅读负担。第三个是规则预筛的精细化把high_risk_paths扩展成带语义规则的模式比如识别“任何修改了测试断言中比较运算符”的改动直接自动升级为高危。用到现在我最大的体会是AI 写代码这件事真正的瓶颈从来不是模型能不能写出代码而是人有没有能力审得过来、审得明白。dsh-diff-approval 就是把“审得过来”变成可能的那个关卡。它没有改变 AI 写代码的速度但它改变了 AI 改动落地的门槛——从“改了就算”变成“看过才生效”。这中间差出的一条防线就是我开始真正放心把项目交给 AI 修改的关键。