坑库
临时方案要写明撤销条件
为赶发版加的临时绕路，事后没人记得撤，成了长期隐患。防止“临时”悄悄变成永久
亲历产品阶段 · 开发更新于 2026-10-16
一句话规则
任何临时绕路，都在 PR 里写明撤销条件，并记入待撤清单
发生了什么
为了赶一次发版，我在安装流程里加了一个临时绕路，想着发完就撤。
发完之后，没有任何事情提醒我这件事。它能用，也就没人再看它，就这么从“临时”变成了长期隐患。
为什么会这样
加和撤的成本严重不对称。赶时间的时候，--no-verify 跳过检查、写死一个兜底值，都是几秒钟的事；撤掉它却需要有人记得、有人负责，还得等到合适的时机。
临时方案通常缺三样东西：负责人、撤销条件、记录。“什么时候撤”只存在于加它的那个人脑子里，发版压力一过，再没有任何事件会让人想起它。
agent 让这件事更糟。新会话看不到“这是临时的”这段口头背景，只看到一段正常运行的代码，会把它当成既定设计，在上面接着搭。
怎么做
适用范围：--no-verify 提交、硬编码的兜底值、为赶时间加的绕路、临时关掉的检查。
在代码里标出来，写明为什么加、什么条件下撤：
// TEMP(#123): 安装时绕过 X，为赶 v1.4 发版
// 撤销条件：上游修复 X 并发版后，删除本段PR 描述里单列一节：
## 临时方案
- 做了什么：
- 为什么：
- 撤销条件：（具体到版本、日期或事件）
- 跟踪 Issue：#123记入待撤清单，用一个固定的 Issue 标签：
gh label create temp-fix --description "待撤销的临时方案" # 只需建一次
gh issue create --title "撤销：安装流程临时绕路" --label temp-fix --body "撤销条件：……"
gh issue list --label temp-fix # 待撤清单
git grep -n "TEMP(" # 代码里还剩哪些定期过一遍：放进每周复盘，或者用 /schedule 建一个定时运行的 agent，检查撤销条件是否已经满足。试用中