dsh-research-solver

科研式解题器（dsh-research-solver）

把「做一个方案」当成写一篇论文来做：先证明别人哪里做得不够，再用同一把尺子量遍所有方案，最后靠数字迭代，而不是靠感觉。

它不是一个更长的提示词。提示词会随会话消失、结论不可复算、阶段会跳步——这三件事正是它要补的洞。

两条原则

原则	落到代码上是什么
一、以别人的不足为创新点	每条「不足」(gap) 必须挂在一条真实资料 (source) 上；每个方案必须认领它补的是哪几条不足。没有认领不足的方案，human/成品/方案.md 会直接写出「这还不能算创新点」。
二、最大幅度省资源，先本地后联网	每条资料带 tier：0 本地工作区 → 1 本地知识库/文献库 → 2 本机应用/MCP → 3 网络。走 tier 3 必须写清 whyLocalFailed，否则体检报 S001；本地占比低于 50% 报 S002。

四个阶段

① 资料收集 ──→ ② 指标与评估 ──→ ③ 改进与融合 ──→ ④ 迭代改善
   找别人的不足      同一把尺子量所有方案     针对短板补/合        用同一把尺子再看一次

阶段不是你声明的，是从产物推导出来的（computeStage）：有资料才算 1；有指标且已评分到 2；出现融合方案到 3；完整迭代两轮才到 4。跳过一步，research_task action=status 会指出来。

三个工具

research_task — 推进流程

action	作用
init	建项目：research/<slug>/，落 ai/state.json 与 human/ 全树
status	当前阶段、排名、体检结果、下一步该干什么
source	登记一条资料（含 tier、whyLocalFailed）
gap	登记一条「谁做不好什么」，必须给 evidence（资料 id）
metric	定义评价指标（0–10 分、direction: higher/lower、权重）；replace: true 可整套替换并让旧结论过期
candidate	登记候选方案；kind: fused + fuses: [父方案 id] 表示融合
choose	定稿，写入 human/成品/方案.md
check	重渲染全部文档并逐字节比对：H001 缺文件 / H002 人改过 / H003 状态与产物不一致

research_score — 算分与迭代

action	作用
evaluate	给某方案打分，写入评审意见
iterate	冻结一轮快照，必须写 hypothesis（这轮想验证什么）
compare	只复算、不写盘，用于质疑现有结论

file_layout — 文件治理（不限于研究项目）

你最初的要求是「把文件分成给人用的和给 AI 用的，给人用的再分交流、流程展示、成品、可验证中间过程」——这四格加 ai/ 就是本工具唯一认的骨架，任何目录都能套。

action	作用
init	建骨架：5 个格子 + 6 份目录说明（README.md）。已存在的文件一律不覆盖
audit	按确定性规则判断每个文件该去哪，输出 放错 / 待确认 / 根目录游离 三类
move	挪文件。all: true 只搬高/中置信的；path + kind 手动指定低置信的
map	重建 human/README.md（人看的目录地图）与 ai/index.json（机器索引）

分类靠两条线索，顺序固定：先名字、后扩展名。

名字命中                      扩展名命中
对话|纪要|会议|transcript  → 交流        jsonl|log|csv        → 可验证中间过程
评分|校验|清单|证据        → 可验证中间过程  json|yaml|py|mjs|ps1 → ai/
流程|阶段|计划|过程        → 流程展示     docx|pptx           → 成品
成品|定稿|最终|方案        → 成品         md|txt|drawio       → 流程展示（低置信）

判不出来的一律标 ? 并写清「为什么判不出来」，不替人搬。这是刻意的：搬错一个文件的代价，比让用户点一下 kind 高。

散在根目录的文件不会被当成「暂时放一下」，而是「还没决定给谁看」——audit 会把它们单独列成一节。

评分是确定的

norm  = direction === 'higher' ? s/10 : (10-s)/10
total = Σ (weight / Σweight) × norm

同一个 ai/state.json，无论谁、什么时候、算几次，total 都一样。没有模型判断参与算分——模型只提供 0–10 的原始分和理由，账是引擎算的。

外加两个不看总分的视角：

• 帕累托前沿：不被任何方案全面压过的方案，防止「高总分掩盖单项塌陷」。
• 不足覆盖率：被及格方案（≥0.60）认领的不足比例。方案分再高，覆盖率低就说明它没在解决你最初发现的问题。

产物：两棵树

research/<slug>/
├── ai/                      ← 给 AI 读：唯一事实来源
│   ├── state.json           全部状态（可整体重放）
│   ├── index.json           文件清单 + sha256（判手改）
│   ├── evidence/sources.jsonl
│   └── log.jsonl            每次操作一行，追加不覆盖
└── human/                   ← 给人读：全部由 state 渲染，不要手改
    ├── 交流/{README.md, 决策记录.md}
    ├── 流程展示/{00-总览, 01-资料收集, 02-方案评估, 03-改进与融合, 04-迭代分析}.md
    ├── 成品/方案.md
    └── 可验证中间过程/{评分表.csv, 校验清单.md}

human/ 下每个文件都是 renderAll(state) 的纯函数输出，所以能被 check 逐字节比对。想让文档变，只能改 state——这就是「可验证」的意思：结论不靠人自觉维护，靠重算。

安装

从 npm（推荐，一条命令，之后随 dsh 一起升级）：

dsh plugin add dsh-research-solver

从 GitHub：

dsh plugin add github:LoneLeave/dsh-research-solver

本机开发时直接指向目录：

plugin_manager action=install_bundle target=<本目录绝对路径>

Host-only bundle，无 Client/UI，无第三方依赖，node >= 22。装好后会注册技能 research-solver（说明两原则与四阶段的调用顺序）。

自检

node scripts/selftest.mjs

最初 22 项断言，不经过 DSH 运行时，直接验证引擎与落盘层：总分独立重算、lower 方向反转、排名连续、帕累托子集、覆盖率、渲染确定性、落盘往返、S001/C001/G001/R001 负例。

当前为 32 项：额外覆盖文件治理——分类规则、低置信不硬猜、init 不覆盖既有文件、audit 找出根目录游离文件、move 后复检干净、move 不覆盖同名目标、map 落盘两张索引、目录说明文件不参与归类。

已知局限

• 只记账，不查证。 资料是否真存在、分数是否公道，引擎不管；它保证的是「记录一致、结论可复算」。whyLocalFailed 也只校验「有没有写」，不校验「写得对不对」。
• human/ 是只读的。 手改会被 H002 抓出来并被下一次渲染覆盖——这是刻意的，但意味着想改措辞得改渲染模板。
• 不支持并发写。 同一个项目被两个会话同时推进，后写的会覆盖前者（没有文件锁）。
• 权重是人定的。 换一套权重可能换一个冠军，这很正常；metric replace 会让旧结论标记为过期（R001），但不会替你重评。
• 与本地已有科研技能的关系：ccf-*、academic-research-suite、idea-evaluator 强在领域知识与写作，本插件不重复这些内容，只在它们缺少的「状态、复算、阶段纪律、人机分树」上补位。两者可以叠用：用它们产出内容，用本插件记账与评分。
• 文件分类是启发式的。 file_layout 只认名字与扩展名，不读内容：一份叫「方案.md」的过程记录会被建议进成品。规则命不中时报 ? 而不是猜，但它不会比命名更聪明——整理前先看一眼 audit 的建议列，比事后 git mv 回来便宜。
• move 会改路径。 依赖相对路径的脚本、链接、IDE 配置会断开。整批搬动前建议先 audit 确认清单，或在版本控制干净的仓库里操作。