范围哨兵

最昂贵的代码行是你本不需要写的那一行。最昂贵的重构是你顺手开始的那一次。

功能概述

你坐下来修复结账流程中的一个bug。两小时后，你重构了认证模块、为三个工具文件添加了类型、重命名了一个数据库列、还升级了一个依赖。那个bug呢？还在那里。

范围哨兵监控你实际在做的事情，并将其与你声称要做的事情进行比较。当偏差过大时，它会介入——不是为了阻止你，而是让偏离可见，让你有意识地做出选择。

偏离模型

范围定义

范围锚点：
├── 任务陈述：修复国际地址结账失败
├── 目标文件：src/checkout/address.ts, src/checkout/validation.ts
├── 目标行为：国际地址应通过验证
├── 分支名称：fix/international-address-checkout
└── 预计涉及文件数：2-4

偏离检测

偏离梯度

范围内 ──── 相邻 ──── 边缘 ──── 偏离 ──── 兔子洞
✓ ✓ ⚠ 🔴 🕳️
这就是 这是修复 相关但 这是另一 现在
修复 的一部分 不是修复 个任务 是哪年？

工作原理

阶段1：锚定
├── 捕获任务陈述（来自分支名称、提交信息或明确声明）
├── 识别代码库的目标区域
├── 建立范围边界（文件、模块、行为）
└── 设置偏离容忍度（严格、正常或探索）

阶段2：监控
├── 对每次文件修改进行分类：
│ ├── 这个文件在目标区域内吗？
│ ├── 这个变更与所述任务相关吗？
│ ├── 这个变更对任务成功是必要的吗？
│ └── 这个变更作为单独的提交/PR有意义吗？
├── 跟踪累积偏离：
│ ├── 范围外涉及的文件
│ ├── 范围外变更的行数
│ └── 范围外花费的时间
└── 跟踪范围扩展事件（当你发现任务比预期更大时）

阶段3：警报
├── 当偏离累积超过阈值时：
│ ├── 命名偏离（你已经开始重构认证模块——这与结账无关）
│ ├── 量化偏离（4个文件，87行，约25分钟的偏离工作）
│ ├── 提供选择：
│ │ ├── 暂存：将偏离变更保存为单独任务
│ │ ├── 单独提交：为偏离工作创建单独提交
│ │ ├── 扩展范围：承认范围扩大（附理由）
│ │ └── 继续：你知道并选择继续
│ └── 记录决策供后续审查
└── 以更新后的范围（如果已扩展）恢复监控

阶段4：会话总结
├── 在会话结束时，报告：
│ ├── 范围内时间 vs. 偏离时间
│ ├── 范围内变更的文件 vs. 范围外变更的文件
│ ├── 偏离事件及其解决方式
│ └── 针对偏离发现的建议后续任务

警报格式

╔══════════════════════════════════════════════════════════════╗
║ 范围哨兵：检测到偏离 ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 你的任务：修复国际地址结账 ║
║ ║
║ 偏离： ║
║ 你已修改 src/auth/middleware.ts 18分钟。 ║
║ 该文件与结账或地址验证无关。 ║
║ ║
║ 你是如何到这里来的： ║
║ checkout/address.ts → 注意到未类型化的导入 ║
║ → 打开 utils/types.ts 添加类型 ║
║ → 注意到 auth/middleware.ts 也使用了这些类型 ║
║ → 开始修复认证类型 ║
║ ║
║ 累积偏离： ║
║ ├── checkout/ 之外的3个文件 ║
║ ├── 与bug无关的47行变更 ║
║ └── 约18分钟的偏离 ║
║ ║
║ 选项： ║
║ [1] 暂存偏离变更，返回结账bug ║
║ [2] 单独提交（为认证中间件添加类型） ║
║ [3] 扩展范围（理由：类型是前提条件） ║
║ [4] 继续（我知道，我很快会收尾） ║
╚══════════════════════════════════════════════════════════════╝

会话总结

╔══════════════════════════════════════════════════════════════╗
║ 范围哨兵：会话报告 ║
║ 任务：修复国际地址结账 ║
║ 时长：2小时14分钟 ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 专注度评分：68/100 ║
║ ║
║ 时间分解： ║
║ ├── 范围内： 1小时22分钟（62%） ████████████░░░░░░░░ ║
║ ├── 相邻： 18分钟（13%） ██░░░░░░░░░░░░░░░░░░ ║
║ ├── 边缘： 16分钟（12%） ██░░░░░░░░░░░░░░░░░░ ║
║ └── 偏离： 18分钟（13%） ██░░░░░░░░░░░░░░░░░░ ║
║ ║
║ 偏离事件：2次 ║
║ ├── 认证中间件类型化（已暂存 → 单独任务） ║
║ └── 工具函数重命名（已单独提交） ║
║ ║
║ 生成的后续任务： ║
║ ├── 为认证中间件添加TypeScript类型 ║
║ └── 全局重命名 formatAddress → formatPostalAddress ║
║ ║
║ 任务状态：Bug已修复。PR已就绪。 ║
╚══════════════════════════════════════════════════════════════╝

偏离容忍模式

何时使用

• - 在每个专注任务开始时。 设置你的范围锚点。
• 修复bug时（范围偏离在此处代价最高）
• 在截止日期前工作时（每偏离一分钟都有损失）
• 当你注意到自己在说既然进来了就顺便...时（经典的偏离用语）
• 在代码审查准备期间（确保你的PR是专注的）

为何重要

范围偏离不是懒惰——它是开发者思维方式的自然结果。你看到一个问题，就想修复它。这种冲动是富有成效的。但如果不加控制，它会把30分钟的bug修复变成4小时的PR，涉及15个文件，