Wave Project Evaluator
v0.2.0对项目进行结构化评估与优化，借鉴达尔文技能的质量方法论。 2026-05-14 v0.2.0: 新增过程级评估维度（借鉴 代理Lens 方法论）。 Trigger: "评估项目", "项目健康检查", "project review", "项目评分", "优化项目", "项目质量检查" Best for: 评估项目交付质量、识别改进方向、项目收口把关 Not for: 代码审查（用原生工具）、项目管理（用 JIRA/其他） Version: 0.2.0
by 运行时依赖
安装命令
点击复制技能文档
Project Evaluator — 项目评估优化器 v0.2.0
将达尔文的评估→改进→验证→棘轮方法论应用到项目任务。不只是给项目打分，更要指出具体改什么、怎么改、改完验证。
v0.2.0 新特性：借鉴 代理Lens 论文（微软×伯克利，arXiv:2605.12925），引入过程级评估 发现 10.7% 的「幸运通过」——只看结果不看过程会产生错误的可靠性判断。
评估 Rubric（9 维度，总分 110）
- 目标锚定 (权重 10) — 方向是否清晰
评分标准：
项目目标可验证（有明确 成功 criteria） "不做什么"有定义（避免 scope creep） 用户/受众明确 1分 5分 10分 目标模糊，无验收标准 有大致目标，但无法定量验证 目标可衡量、不做什么明确、成功标准量化
- 架构可运行 (权重 15) — 能否跑起来
评分标准：
代码/构建无崩溃级错误 依赖完整可安装 核心路径可执行 1分 5分 10分 代码有崩溃 bug，无法运行 能运行但有报错 构建通过、核心功能端到端可用
- 边界条件覆盖 (权重 10) — 异常处理
评分标准：
错误/异常路径有处理 已知限制有文档 用户误操作有恢复路径 1分 5分 10分 无任何错误处理 部分关键路径有处理 完整错误处理 + 边界文档
- 交付完成度 (权重 10) — 是不是成品
- 质量水位 (权重 10) — 代码/文档质量
- 迭代纪律 (权重 10) — 能否识别"够了"
- 工具匹配度 (权重 10) — 用对工具了吗
- 可维护性 (权重 10) — 后续能续
- 过程质量 (权重 15，v0.2.0 新增) — 不是只看结果
借鉴 代理Lens（微软×伯克利，arXiv:2605.12925）方法论。 通过项目/产物中有 10.7% 属于「幸运通过」——结果正确但过程有问题。 只看最终结果不看过程，会产生错误的可靠性判断。
评分标准：
过程中的决策路径可追溯、可审计 无回归循环（反复在同一个问题上打转） 无盲目重试（失败后不是换参数再试，而是先诊断根因） 验证环节完整（修改后有验证，不是"看起来对了就行"） 中间状态可复现（不是"跑了一次出了结果，但没法再跑一次"） 1分 5分 10分 过程不可追溯，结果全靠运气 部分步骤可追溯但验证缺失 完整可追溯、无盲目重试、全部验证通过
代理Lens 轨迹分级参考：
等级 特征 判定 🎲 Lucky 通过了但轨迹有回归循环、盲目重试、验证缺失 <5分 🟢 Solid 过程干净，验证完整，可复现 5-8分 🔷 Ideal 过程最优，无冗余步骤，每步都有明确目的 9-10分 工作流 Phase 0: 项目扫描
读取项目目录结构，确定项目类型：
ls -la projects//
识别：
是否有 README / 产品说明书 代码文件类型（JS/Python/HTML 等） 依赖清单（package.json / requirements.txt） 测试文件 上次修改时间（是否活跃） Phase 1: 启动评分
第一次评估：跑全 9 维度。输出评分卡：
┌──────────────────────┬──────┬──────────────────────────────┐ │ 维度 │ 得分 │ 短板 / 幸运通过风险 │ ├──────────────────────┼──────┼──────────────────────────────┤ │ 1. 目标锚定 │ X │ ... │ │ 2. 架构可运行 │ X │ ... │ │ 3. 边界条件 │ X │ ... │ │ 4. 交付完成度 │ X │ ... │ │ 5. 质量水位 │ X │ ... │ │ 6. 迭代纪律 │ X │ ... │ │ 7. 工具匹配度 │ X │ ... │ │ 8. 可维护性 │ X │ ... │ │ 9. 过程质量 │ X │ Lucky? 有回归/盲目重试？ │ ├──────────────────────┼──────┼──────────────────────────────┤ │ 总分 │ XX │ 最低维度: X │ ├──────────────────────┼──────┼──────────────────────────────┤ │ 幸运通过风险 │ 低/中/高 │ 过程质量评分 <5 时警告 │ └──────────────────────┴──────┴──────────────────────────────┘
Phase 2: 诊断 → 改进
找到最低分维度，生成 1 个具体改进方案：
维度 常见改进方向 目标锚定低 定义验收标准、明确不做什么 架构可运行低 修复崩溃 bug、补依赖 边界条件低 加 try/catch、补错误提示、加 fallback 交付完成度低 补 TODO、补数据源、移除占位符 质量水位低 统一命名/风格、加测试 迭代纪律低 冻结功能、进入收口模式 工具匹配度低 替换成更合适的 技能/工具 可维护性低 写 README、沉淀知识到 Memory Wiki 过程质量低 识别回归循环 → 诊断根因 → 清除盲目重试 → 补充验证步骤 → 让过程可复现
检查点：展示改进方案给用户确认再执行。展示修改预览（diff 或具体改了什么）后等待用户确认。
Phase 3: 执行改进 → 重评 执行改进（改代码/文档/配置） git commit（message: "project-eval: {项目名} 改进 {维度}"） 重新评分
棘轮：
新分数 > 旧分数 → 保留 否则 → git revert（回滚） 棘轮保证分数只升不降 Phase 4: 报告生成
输出结构化报告（同时写入 memory/project-evals/-.md）：
# 项目评估报告 — [项目名]
评估时间: YYYY-MM-DD HH:mm 项目路径: projects/[项目名]/
评分
| 维度 | 分数 | 改进前 | 说明 |
|---|---|---|---|
| 1. 目标锚定 | X | Y | ... |
| 9. 过程质量 | X | Y | Lucky/Solid/Ideal? 回归循环? |
主要改进
- [改了什么]
待办
- [ ] 可继续改进项
触发场景 场景 触发 项目交付前检查 "评估一下 XX 项目" 项目健康度周报 "项目健康检查" / 每周自审触发 需要决定是否继续 "XX 项目值得继续吗"（评分 <60 建议暂停） 回顾总结 "给 XX 项目打分" 已验证项目类型 类型 评估重点 小程序/网页 应用 架构可运行 + 质量水位 + 过程质量 文档/说明书 交付完成度 + 目标锚定 工具/命令行工具 边界条件 + 可维护性 + 过程质量 AI 技能 用达尔文评估（本 技能 不适用） 边界条件 场景 处理 项目目录不存在 提示目录不存在 只有 README 没有代码 按文档类项目评估 项目长期未更新 (>30天) 标注"可能已停滞"，降低可维护性分 项目本身就是 技能 建议用 darwin-技能 而非本 技能 多个项目需要评估 逐个评估，每个有独立报告 无 git 仓库 跳过棘轮机制，每次改进前手动备份当前状态 与达尔文的对比 维度 darwin-技能 project-evaluator 评估对象 技能.md 项目目录（代码+文档+结构） Rubric 8 维度 技能 专用 9 维度项目专用（含过程质量） 改进方式 编辑 技能.md 改代码/文档/配置 测试方法 test-prompts 子 代理 跑 实际运行验证 输出 结果s.tsv + 评分卡 评估报告 markdown