dbs-resonate

1实现原理 · 为什么它能做到

纯 prompt 编排的理论诊断器：知识底座是 SKILL.md 内联的一张 5 主理论 + 3 条件理论表（含作者、年份、DOI），把「共鸣」拆成可逐步筛查的机制清单

诊断流程是「先定主张、再选机制、后定位问题、最后给改法」的五步固定顺序，避免上来就给改写建议

核心纪律一：一篇文稿只保留一个核心主张，多主张并列即标记「核心被稀释」

核心纪律二：一次诊断只选一个主理论，辅助理论须同时满足三个条件（覆盖新机制 + 原文有明确触发证据 + 删除它会损失一条重要建议）

核心纪律三：每条结论必须指向原文原句——哪句话激活了什么机制、缺失发生在哪句、应该怎么改

核心纪律四：把「文稿能力」与「平台结果」切开，并明确列出超出边界的三类承诺（预测指标、承诺必火、分析已传播内容）

输出格式固定为带图标的六段诊断报告（核心机制审查/理论诊断/具体改法…），改法必须落到删除、压缩、强化、保持不动四类动作

附五种可复用的常见问题模式（身份对象含混/框架缺因果桥梁/只有情绪标签/用途不清/分享理由不足），作为诊断加速器

2核心能力

4管控建议与判定依据

5第二遍独立确认

• [ok] 外部资源/工具：是否引用了 SKILL.md 未内联的外部文献或服务 — 理论仅以「作者+年份+DOI」文字形式内联，无链接抓取、无参考文献文件、无 API。DOI 只是可核对标识，不构成网络调用。external_deps 空数组成立。
• [ok] 安全结论：是否存在文件读写遗漏 — 全文无读取文件指令（不要求读用户草稿文件，用户直接贴进对话即可），无落盘要求；输出是对话内的 markdown 诊断报告。
• [ok] 实现原理是否成立：理论机制是否真能落到「改哪一句」 — Step 4 要求「说明问题出现在哪一句，并写清缺少身份、归因、评价路径、内容用途或传播理由中的哪一项」；Step 5 与输出模板的【具体改法】要求给出具体原句与改法。机制到句子的映射是设计内的强制项，不是可选建议。
• [ok] 理论表完整性：条件理论是否真的「只在条件下使用」 — 条件理论表三行各带触发条件，且正文另加禁令「禁止把条件理论泛化成日常共鸣标签」；Step 3 再次要求「条件理论必须满足对应触发条件」。三处要求一致，无冲突。
• [unlocatable] 证据定位：仓库级元数据（stars/last_push）与 installs — stars=10121、last_push=2026-09-07 来自站点池 data/pool.json（GitHub API 采集），pin 源码内无法逐字定位；installs 未采集记 null。license 可在仓库根 LICENSE 逐字命中。

6结论