---
name: strict-scope
description: 严格限定改动范围：只做用户明确要求的事；涉及数据库、服务端配置、数据行的改动，以及需要在多个方案里做选择时，先停下来说给用户、由用户决策，不自行决定。本项目（叶雷讲数学）内的一切开发与运维操作都适用。
---

# 严格限定改动范围

## 三条硬规则

1. **只做被明确要求的事。** 要求是 A，就只做 A。不做"顺手一起弄好"的额外改动。
2. **需要改动数据库配置 / 数据行 / 线上状态时，先说给用户，由用户决定。** 觉得"这里应该改一下"不是动手的理由，是提问的理由。
3. **需要做选择时先问。** 有多个方案、或某个字段该填什么值、某条数据算不算"正确状态"——这些都不是我可以替用户定的。

## 属于「先说再做」的范围

| 类别 | 具体 |
|---|---|
| 服务端配置 | `.env`、环境变量（`WX_*`、`DATABASE_URL*`、`WX_PAY_ENV`、各类密钥、域名、端口） |
| 数据行 | 任何库里的 INSERT / UPDATE / DELETE，包括"修正""补录""恢复""纠正状态"这类听起来正当的操作 |
| 表结构 | `schema.prisma`、迁移文件、给某个库补迁移 |
| 线上状态 | 部署、重启进程、切换小程序数据源、清理线上数据 |

提出时把三件事说清楚：**发现了什么 → 建议怎么改 → 影响范围**，然后等回复。

## 不属于限制范围

- 用户明确要求过的改动，照做，不要在同一个任务里反复确认。
- 只读操作不受限：查数据、看日志、比对记录、跑诊断。
- 用户已经授权的那次操作，做完即可。

## 本项目真实踩过的坑

1. 用户说「删课程」，我执行了当时写的连带删除逻辑，把课程下 55 个课时一起删了，开发库数据丢失。
   → 要求是删课程，就该只删课程那一行；其余的要问。
2. 恢复那条被误删的数据时，我自作主张给 `status` 字段填了 0。
   → 用户的原话：「万一是我手动改的呢」。恢复数据必须原样，拿不准的值要问。
3. 发现开发库缺 4 个迁移，我自己判断后直接补上了。
   → 虽然是修复，但那是改表结构，应该先说。
4. 改动 `.env` 里的 `WX_PAY_ENV` 并重启服务。
   → 结论是对的，但涉及线上配置，应当先说明再动。

## 出问题时的处理

发现自己越界了：直接承认、说清改了什么、给出恢复方案，不要辩解，也不要顺手再改点别的来"补救"。