keep-focused

# 防跑偏 Skill ## 触发条件 以下任一情况出现时，立即执行"拉回机制"： ### 🚨 红色信号（立即拉回） | 信号 | 示例 | 处理 | |------|------|------| | AI 说"顺便..." | "我顺便优化了..." | `/undo` + 拒绝 | | AI 说"我重构了..." | "我把整个模块重构了" | `/undo` + 拒绝 | | AI 说"为了更好的扩展性" | "添加了一个抽象层" | `/undo` + 拒绝 | | 超出 Change Budget | 修改了 4+ 文件 | `/undo` + 重新约束 | | 涉及任务外文件 | 修改了无关模块 | 拒绝 + 重新明确范围 | ### ⚠️ 黄色信号（警惕） | 信号 | 处理 | |------|------| | AI 开始添加新文件 | 确认是否必要 | | AI 提到设计模式 | 提醒当前是中小型项目 | | AI 提到 service/repository | 提醒规范要求 | | AI 输出超过 200 行 | 提醒精简 | --- ## 拉回机制 ### 第一步：识别跑偏 ``` 检测到以下信号： - [具体信号] - 任务范围：[原定范围] - 实际改动：[超出部分] ``` ### 第二步：立即干预 ```bash # 如果 AI 已经做了改动 /undo # 或者拒绝 "你的改动超出了任务范围。请： 1. /undo 撤销刚才的改动 2. 只实现我要求的功能 3. 其他需求我会另外开任务" ``` ### 第三步：重新明确范围 ``` 任务：[原任务描述] Change Budget： - 文件数：≤ 3 - 行数：≤ 80 - 不修改：[具体排除的文件/模块] 请继续完成任务。 ``` --- ## 验收标准（每任务必查） ### 功能验收 - [ ] 功能是否正常工作 - [ ] 返回结果是否符合预期 ### 范围验收 - [ ] 修改文件数 ≤ 3 - [ ] 修改行数 ≤ 80 - [ ] 没有修改任务范围之外的文件 ### 规范验收 - [ ] 没有引入新依赖 - [ ] 没有创建多余的抽象层 - [ ] 没有使用禁止的模式 ### 质量验收 - [ ] 代码没有明显的 BUG - [ ] 没有硬编码的密钥/密码 - [ ] 没有 console.log/调试代码 --- ## 对话节奏控制 ### 超过 10 轮对话 ``` "对话已经较长，为防止上下文混乱： 1. 先完成当前任务 2. /new 新建会话继续下一个任务 3. 或 /compact 压缩上下文" ``` ### AI 连续 3 次尝试扩展范围 ``` "你连续多次试图扩展任务范围。这违反了 Change Budget 原则。 请只完成我最初要求的任务，其他需求另外开任务讨论。" ``` --- ## 正面引导 ### 鼓励的行为 ✅ - 简洁的实现方案 - 在现有代码上修改 - 小步迭代 - 满足基本需求即可 ### 阻止的行为 ❌ - "顺手优化一下代码" - "增加一个抽象层" - "顺便加个日志" - "为了更好的可维护性" --- ## 使用场景 ### 场景 1：AI 开始大拆大改 ``` 用户："添加一个按钮" AI："好的，我来重构一下整个组件结构..." → 立即拉回，只添加按钮 ``` ### 场景 2：AI 超出预算 ``` 用户："修改用户详情页" AI："我还要修改一下相关的 API..." → 拒绝 API 修改，只改页面 ``` ### 场景 3：AI 添加多余功能 ``` 用户："实现登录功能" AI："我来加个记住密码和自动登录..." → 拒绝，先完成基本登录 ``` --- ## 核心原则 ``` 1. 小 ≠ 不完整 2. 简单 ≠ 不专业 3. 够了 ≠ 要更好 4. 当前任务 ≠ 全部任务 ```