团队共用一个 DeepSeek Harness 实例：交接与提示词规范
先定驾驶员，再 fork 会话；五字段交接单比长散文管用。
多人共用同一 DeepSeek Harness 实例时：一人驾驶会话，其他人只读 Trajectory；交接至少含入口机、版本、工作区、会话标识、未完成目标。提示词用短模板（目标/约束/路径/验收/停手）。交接中文用翻译输入法写；安装见 下载页。
1 共用实例先定「驾驶员」，再谈功能开关
同一 Web 入口上，会话日志、工具调用与工作区是连着的；没有驾驶员规则就会互相踩。
公开产品把每次模型所见写入可回放的会话流（Trajectory 可按来源查看；resume / fork / search / replay 等能力以你打开的版本为准）。多人盯同一屏有价值，多人同时提交互相矛盾的指令没有价值。
值班表写清：当前驾驶员、观察者、禁止事项（例如「勿在客人演示时切换工作区」「勿清会话目录」）。驾驶员换人时，先停当前工具轮次，再交键盘——比抢输入框更省一次灾难恢复。
2 交接清单：五字段就够，多了没人填
交接失败通常不是少写一万字，而是缺「现在到底停在哪」。
用固定五字段：① 入口机 + OS 用户；② dsh / 插件概况版本；③ 工作区绝对路径；④ 会话名或 ID；⑤ 未完成目标 + 已验证事实 + 明确不要做的事。贴到内部工单，不贴密钥。
接班人先打开 Trajectory 回放最近几轮，确认工具是否改过磁盘，再发新提示。不要假设「页面还开着就等于状态干净」。
若会话过大或上下文脏了：按官方能力 fork 干净分支，或新开会话并粘贴「已验证事实」摘要——摘要用中文写结论，英文保留路径与命令原文。
3 提示词规范：字段化，拒绝散文诗
团队规范要的是可扫描，不是文采。
模板固定顺序：目标（可验收的一句话）→ 约束（权限、勿动路径）→ 允许触达的目录/文件 → 验收步骤 → 停手条件（何时问人而非继续瞎试）。第一轮就写停手条件，能少烧一轮工具配额。
模式名（公开页可见的 Standard / Code / Minimal / Creator 等）以当前 UI 为准，Wiki 截图会过期。换模式当变更：驾驶员说一声，观察者改记录。
评审别人贴进会话的提示：先看有没有可检索的英文错误原文，再看中文目标是否可测。缺验收的提示一律退回重写，不靠 Agent「自己理解业务」。
4 联用翻译输入法：只服务交接与记录
这里不教怎么混打 flag；只规定写什么、写在哪。
交接单与群结论用翻译输入法写中文，标题里带会话短名便于搜索。命令、路径、Issue 关键字从终端或日志复制，不手打。
远程桌面或共享浏览器里偶发打字异常：走特定应用排查。全局输入法失灵：走用不了排查。都与「Harness 会话坏了」分流。
需要装或更新输入法时回本站下载页；需要搭团队 Web 入口时读部署专文；需要系统级中英输入技巧时读混打专文。
继续核对
常见问题
共用一个实例等于可以同时狂点同一个会话吗？
不建议。一个入口进程上的会话与工具执行是共享状态。更稳的约定是：同时只一人「驾驶」当前会话，其他人只读 Trajectory / 投屏；要并行就 fork 新会话或换工作区，而不是两个人抢同一个输入框。
交接时要交什么？
最少五项：入口机与 OS 用户、dsh 版本、工作区路径、当前会话标识或标题、未完成目标与禁止事项。密钥不口头报、不进聊天记录；只说明「凭证已按 Runbook 落在机器上」。
提示词团队规范要写多长？
一张短模板即可：目标 / 约束 / 允许改动的路径 / 验收 / 停手条件。路径与报错原文保持英文可检索；叙述可用中文。不要把整份设计文档糊进第一轮提示。
翻译输入法在交接里做什么？
写交接单、值班群结论、会话标题里的中文摘要。系统级中英混打技巧见 deepseek-harness-coding-input-method；部署拓扑见 deepseek-harness-web-team-deploy。本文不重复那两篇。