cmhub/docs/quality-document.md

质量文档

给项目的每个产品领域和架构层打分，跟踪代码库随时间是变强还是变弱，回答"这个项目在变强还是变弱"。 它评的是代码库本身的质量；单次 agent 输出质量见 evaluator-rubric.md。

使用时机

• 开始会话前：读它，了解代码库当前哪里最弱，优先处理。
• 会话结束后：更新评级。
• 长期：对比不同时间点的快照，看哪些改动真正改善了代码库健康度。
• 做基准对比、清理简化、或换新 agent / 新模型时，也更新一次。

评级标准

• A：验证全部通过，结构干净，agent 能读懂，测试稳定。
• B：验证通过，基本干净，可读性或测试覆盖有少量缺口。
• C：部分可用，有已知缺口，部分代码 agent 不容易理解。
• D：不可用，或存在重大结构问题。

---

产品领域

把下面的占位领域换成本项目 02-requirements.md 里的真实功能域。

领域	评级	验证状态	Agent 可读性	测试稳定性	关键缺口	上次更新
【核心流程 1】	-	-	-	-	-	-
【核心流程 2】	-	-	-	-	-	-
【数据 / 持久化】	-	-	-	-	-	-
【账号 / 鉴权】	-	-	-	-	-	-

架构层

把下面的占位层换成本项目 04-architecture.md 里的真实分层 / 模块边界。

层级	评级	边界执行	Agent 可读性	关键缺口	上次更新
【前端 / 客户端 / CLI】	-	-	-	-	-
【后端 API / 核心模块】	-	-	-	-	-
【数据 / 存储层】	-	-	-	-	-
【外部服务适配】	-	-	-	-	-

变更历史

YYYY-MM-DD

• 变更内容：
• 提升：
• 下降：
• 新发现的缺口：
• 已关闭的缺口：

---

进阶：验证 harness 是否可以简化

Harness 里的每个组件（规则、脚本、检查清单）都编码了一个假设——"模型做不到这件事"。模型变强后，这些假设可能过时。用本文档检查某个组件是否还有必要：

1. 拍一份本文档快照。
2. 移除一个 harness 组件。
3. 跑一轮基准任务。
4. 再拍一份快照。
5. 对比——评级没降，说明那个组件多余，可以去掉；降了，就恢复。