dsh-egm：DeepSeek Harness 里先定设计再写代码的评审流程

它是做什么的？

EGM 是 DeepSeek Harness（DSH）的设计评审插件，把「大象—金鱼」模型（Elephant-Goldfish Model）搬进 DSH：先由一个上下文丰富的 Elephant 会话访谈你并起草设计文档，再由零上下文、只读的 Goldfish 评审员挑出歧义、隐藏假设与实现缺口，最后由你拍板取舍、批准规格，然后才写代码。它解决的是「设计决策还没想清楚就动手写代码」的麻烦，适合需要先定设计的中等以上改动；小而明确的 bug 修复仍走常规编码流程。该插件是 Google EGM 的独立社区移植版，由 dryw 维护，采用 Apache-2.0 协议，最近更新于 2026-11-01。

核心功能

• 双角色分工：Elephant 掌握项目背景、需求与既往决策，负责探索问题、权衡取舍并起草规格；Goldfish 只拿到文档及其引用的源材料，看不到先前对话，专门找缺失假设、含糊需求与实现风险。
• 只读评审员：评审通过插件自带的 egm_reviewer 工具启动，运行在捆绑的 egm-reviewer 只读 agent 预设中，只能读文件和搜索，没有写入、编辑、执行命令、向用户提问、读取会话或委派子代理的工具。
• 分节起草：把讨论结论整理成 docs/designs/ 下的分节设计文档，每写完一节就停下来等你在对话里反馈。
• 金鱼协议评审：依次执行拉远视角、朴素读者理解度、设计批评、中间拉远、实现就绪度五轮检查，再做一次综合汇总，产出可逐条处理的发现项。
• 上游原样移植：上游的技能、角色与标准按固定提交原样随插件发布，DSH 侧机制放在一层很小的集成层里，注册技能时由宿主插件前置拼接。

怎么使用这个插件？

在 DSH 中启用后，先挑一个需要设计决策的功能，例如 webhook 投递失败或同一事件重复到达时该怎么处理。第一步输入 /egm-brainstorm 加一句需求描述，和 Elephant 讨论需求与取舍，新启动的评审员会挑战你的方案，达成一致的方向保存为 concepts_brief.md。第二步用 /egm-draft 把简报转成分节设计文档，每节写完暂停等你反馈。第三步用 /egm-review 指向设计文档路径，跑完整套金鱼协议评审，再用 /egm-resolve 选择要处理的发现项。最后把设计交人工评审，通过后再让 agent 按批准的计划实现。注意评审必须用 egm_reviewer 而不是普通 subagent，后者会继承父会话的工具集，不是只读的，不能用来做金鱼评审；同一上下文里的评审也不算金鱼评审。插件要求 DeepSeek Harness 0.2.x 系列 0.2.1-rc.5 或更新版本，且组合中需具备技能注册表、工具注册表、子代理服务、agent 预设服务与进程内 spawn 子代理提供方。

报错怎么排查？

评审员能写文件或执行命令，通常是误用了普通 subagent 而非 egm_reviewer，后者继承父会话工具集、并非只读，金鱼评审必须走 egm_reviewer 工具。评审结论与设计文档脱节、抓不到先前讨论里的假设，多半是在同一上下文里做的评审，只有零上下文的新会话才算金鱼评审。插件未生效或技能、工具缺失时，先确认 Harness 版本在 0.2.x 且不低于 0.2.1-rc.5，并检查组合是否包含技能注册表、工具注册表、子代理服务、agent 预设服务与进程内 spawn 子代理提供方，按官方说明修复。