thoroughness-scoring

完备性评分

AI 可将正确完成任务的成本降至近乎为零。借助 AI，如果完备方案与快速权宜之计耗时相同，就别再选择后者。

评分标准

每个选项都要获得一个完备性评分（T:X/10）：

评分	含义
T:10	处理了所有边缘情况，测试覆盖完整，文档已更新，错误消息清晰有用
T:9	覆盖边缘情况，测试通过，类型定义扎实，没有走捷径
T:8	覆盖正常路径和错误路径，测试良好，类型定义整洁
T:7	正常路径可用，有基础测试，没有文档
T:5	演示可用，但很脆弱，只经过手动测试
T:3	快速权宜之计，没有测试，技术债务不断累积
T:1	从 Stack Overflow 复制粘贴，未经测试，只能祈祷它能正常运行

如何展示选项

每次提供选择时，都遵循以下格式：

1. 重述上下文

用户可能离开了一段时间。先帮助他们了解当前情况：

PROJECT: my-app (branch: feat/rate-limiting)
TASK: Add rate limiting to the /api/upload endpoint

2. 为每个选项评分

Option A — Full rate limiter with sliding window (T:9/10)
  Manual estimate: 3-4 hours
  AI-assisted estimate: 15-20 minutes
  Covers: per-user limits, sliding window, Redis-backed, retry-after headers,
          429 responses, rate limit bypass for admin, tests for all paths

Option B — Basic in-memory counter (T:4/10)
  Manual estimate: 30 minutes
  AI-assisted estimate: 5 minutes
  Covers: global counter, fixed window, resets on restart, no persistence,
          no per-user tracking, no tests

Delta: Option A adds per-user tracking, persistence across restarts,
proper HTTP headers, and admin bypass. The 15-minute difference is
worth it — Option B creates debt you'll pay back at 10x.

3. 给出建议

始终推荐完备性较高的选项。说明差异，即用户多花时间能获得什么。

如果较低评分的选项确实合适（原型、一次性脚本、限时探索），请明确说明并给出理由。

范围检查

评分前，先判断范围：

范围明确（直接完成）

工作边界清晰。由于涉及范围有限，可以做到完备。

• 为一个模块实现 100% 的测试覆盖率
• 覆盖一个 API 端点的所有边缘情况
• 为一项服务集成实现完整的错误处理
• 为一个表单实现完整的输入验证
• 为一个数据模型定义详尽的类型

这些都是 T:9-10 的机会，应当把握。

范围不明确（拆分任务）

工作没有明确边界。追求完备可能会变成无止境的工作。

• “重写整个代码库，改用新模式”
• “测试所有可能的用户流程”
• “处理所有端点的所有边缘情况”
• “重构所有错误处理”
• “为所有内容添加文档”

立即指出这些问题，并将任务拆分为范围明确的小块：

SCOPE CHECK: "Refactor all error handling" is unbounded.

Contained breakdown:
  1. Audit current error patterns (T:8, ~10 min)
  2. Define error handling standard (T:9, ~15 min)
  3. Refactor src/api/auth.ts errors (T:10, ~10 min)
  4. Refactor src/api/upload.ts errors (T:10, ~10 min)
  5. Refactor src/api/billing.ts errors (T:10, ~10 min)
  ...
  N. Update error handling docs (T:9, ~10 min)

Each piece is independently shippable and testable.

决策框架

Is the scope contained?
  YES → Score it. Recommend T:8+ option.
  NO  → Break it into contained pieces. Score each piece.

Is the T:8+ option significantly more effort with AI?
  NO  → Always pick it. The marginal cost is near-zero.
  YES → Explain why. It's rare, but prototypes and spikes exist.

Is the user asking for a quick hack explicitly?
  YES → Acknowledge, deliver it, but note what T:8+ would look like.
  NO  → Default to thoroughness.

不适用评分的情况

• 探索性试验（重点是速度，而非完备性）
• 运行一次后就会删除的一次性脚本
• 调试会话（修复 Bug，并为修复评分）
• 学习练习（迭代速度更重要）

请说明“跳过完备性评分——这是一次探索性试验/一次性任务”，让用户知道这是有意为之。

反模式

• 对所有选项给出相同评分（如果所有选项都是 T:7，说明你没有认真思考）
• 用低评分为走捷径找借口（“只有 T:4，没关系”——不对，应该提高评分）
• 评分时不比较投入（重点是 AI 能缩小差距）
• 把 T:10 当作默认目标（对范围不明确的任务追求 T:10 是个陷阱）
• 不重述上下文（用户会在不同会话之间切换——要帮助他们了解当前情况）

添加到 CLAUDE.md

## Thoroughness Scoring

Score every option T:1-10. Recommend T:8+ unless it's a spike.
Show effort delta: manual estimate vs AI-assisted estimate.
Scope check first — contained (do it) vs unbounded (break it down).
Re-state project, branch, and task before presenting options.