把交接审批做成流程，Bridge 在小团队里怎么用

个人用 Bridge 靠记性，团队不行：三个人三种习惯，交接质量会随人波动。下面这套流程核心只有一句：把「换 preset」当成一次要审批的变更，而不是一次随手操作。

先定清楚：什么情况下必须交接

三类场景写进团队约定：任务中途需要另一套工具装配；需要换到有视觉能力的目标；需要把一段工作从实验性 preset 挪到稳定 preset。

不在这三类里的就别开新会话，原地继续更省事。交接的成本是固定的：一次摘要 worker、一次人工审阅、一次确认请求。

五段模板怎么填

Bridge 的五段是固定的：Goal、Current state、Key decisions and conventions、Key files、Next step。模板固定意味着它可以被检查，团队要约定的是每段写到什么粒度。

Goal 写一句可验收的话，不要写「继续优化」。「把导出接口从 v1 切到 v2，并让现有 12 个调用点全部通过测试」是合格的，「继续做导出」不是。

Current state 写「做到哪、卡在哪」，用完成态描述，不用过程叙述。

Key decisions and conventions 写已经定下来的事，以及为什么这么定。这一段最容易被写空，也最值钱：目标会话不需要重新争论一遍已经拍过板的选择。

Key files 写路径加一句作用，不要把文件内容贴进来。交接是索引，不是拷贝。

Next step 写一个可执行动作，最好带验收条件。

约定一条就够：五段里任何一段如果写不出内容，说明这次交接还没准备好，先回去把工作推进到能描述的状态。

人工过一遍，再点 Confirm

Bridge 的承诺是「你确认的那一版被逐字送出」，不是「它替你想全了」。所以流程里必须有一个人的环节：确认前把五段读一遍，重点看 Key files 的路径对不对、Next step 是不是你真正想让它做的下一步。

硬边界要写进流程文档：预览编辑只存在内存里，重启客户端或系统就丢，确认状态也一起丢。团队的做法是确认前把编辑后的五段存一份到工单或本地文件，出问题可以重贴。

默认模式还是 --continue

两种模式的差别很具体。默认 --go 会让目标会话先把五段 restate 一遍，然后停下来等你确认，到首次有效工作需要 2 次目标请求；--go --continue 把 restate 和开工合并在同一次目标请求里，只需要 1 次。配对名义中位数上，默认模式比 --continue 多 8.1% 的确认开销。

选择规则写死：改动会影响仓库状态、或者五段里有你不确定的条目，用默认模式，多一道闸门；五段已经过评审、下一步动作明确，用 --continue，少一次往返。--continue 仍受既有的独立审批与安全上限约束，它不是「跳过审批」。

把 plan-review 接进流程

自 0.4.0 起，官方 plan-review 卡片上有 Approve in new session，在 DSH 0.2.0-rc.2 与 0.2.1-alpha.1 的 WebUI 上验证过。它的行为是：停在原规划轮、原会话留在 plan mode、新建一个同 preset / 模型 / workspace 的会话，并把已批准的 plan 逐字转进 kickoff。

流程上把它固定在「评审会通过之后」：由主持评审的那个人点，不要再手工复制 plan 到新会话。手工复制最容易丢信息，也最难追责。

图片材料怎么分工

三档，按材料状态选，不要凭感觉：

已有 assistant 分析过的图，逐字复制那段回复，默认不重发原图；原图未解析、目标又接受图片，复制原附件并保留源 VLM，视觉计费按所选 provider 走；原图未解析、目标是纯文本模型，Bridge 会发一段可见的文本兜底，不会偷偷起本地 VLM，也不会假装看懂了。

团队约定应该是：需要看图的任务，目标 preset 必须带视觉能力。纯文本目标配图片材料，等于让接手的人闭着眼睛干活。

升级之后先跑一次 --doctor

/bridge --doctor 只检查必需 gateway 方法是否存在，它给出的是「契约还在不在」，不是「端到端可用」。所以流程是两步：升级 Harness 后先跑 doctor，再自己走一遍完整迁移，两步都过才算升级完成。

engines.dsh 也要按准入区间读，不要当成已验证清单。

阿里云上的权限边界

WebUI 放在内网或跳板机后面，不要为了「方便同事访问」把端口开到公网。常见的妥协是关掉鉴权、只靠安全组挡，这个口子一旦开了，插件能读写与删除本地文件这件事就变成了实际暴露面。

ECS 上还要限定谁能动 profile：用系统账号和目录权限把「装插件、换版本、卸载」收在少数人手里。Bridge 的站点标注是 🔵 含敏感能力，尚无人工评估，站点也未做风险分级，这条要写在流程文档第一页，不是最后一页。

总结

团队用 Bridge 的关键不是把操作练熟，而是把「五段写全、人工过一遍、草稿落盘、按风险选确认模式」变成默认动作；想对照同类插件的中文清单见 DeepSeek Harness Hub 插件清单。

适合与不适合

适合：有多人共用同一台 ECS、需要统一交接质量的团队；已经把计划评审做成固定环节的小组；经常在实验 preset 与稳定 preset 之间搬工作的场景。
不适合：一个人用、交接全凭记性的场景；没有评审环节、也没人愿意读五段的团队；希望插件自动判断该不该交接的组织。

标签：dsh-plugin-bridge、DeepSeek Harness、团队协作流程

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。