dsh-method

很多「快」的做法，本质上是省略：不澄清目标、不比较方案、不写约束、也不定义怎么算做完。在自己熟悉的领域里，这些省略往往被经验补上了；换到陌生任务或换人执行，就容易返工。dsh-method 给 DeepSeek Harness 一套通用做事方法：任何非平凡任务都要先产出结构化执行计划，而且计划的形状和内容不是靠提示词「请认真写」，而是由 JSON Schema 与 validate.js 两层校验硬性把关。

开启 method 模式后，模型必须通过 plan_submit 提交计划。校验通过后会落盘到项目根下的 .method/plan.md，并把渲染后的全文回给模型，再按计划推进。计划被强制包含目标与非目标、带 hard/soft 标记的约束、至少两个候选的方案比较、可依赖且无环的任务分解，以及每条任务的可观察完成判定与失败原因；验证步骤必须覆盖全部任务。空话式的「确认一切正常」「完成了」一类表述会被拒绝，技术场景与非技术交付（邮件确认、签署验收等）都有结构化判据。

它刻意追求「最普遍」的计划，而不是最短路径：换领域、换执行者仍然能读懂、能验收。适合希望 Agent 在复杂或多步骤任务里先想清楚再动手、需要可审计计划与明确验收标准的团队与个人。若你更需要硬拦截「没计划就不许写文件」，README 也说明了当前版本不做 tools.guard 级强制，仍依赖 method 模式与 plan_submit 的约定；同一工作目录下多会话会共用一份 plan.md，使用时需心里有数。