加个简单的 feature?先 plan。
重构一个小函数?还是先 plan。
# 改之前
def process_data(data: List[Dict]) -> Dict:
...
# 改之后——签名都变了
def process_data(data: DataFrame) -> DataFrame:
...
# 不只是改一个函数 src/service/api.py # API 层 src/service/business.py # 业务逻辑层 src/repository/database.py # 数据访问层 tests/test_api.py # 测试
- 需求模糊,需要探索
- 多种方案,需要比较
- 风险较高,需要验证
# 改之前
if user.age > 18:
return True
# 改之后
if user.age >= 18:
return True
- 日志里明确说了哪行报错
- 堆栈清晰,原因明确
- 修复方案简单直接
- 加个配置项
- 改个默认值
- 调整个顺序
改动涉及公共 API? ├─ 是 → plan mode └─ 否 → 继续 改动跨多个文件? ├─ 是 → plan mode └─ 否 → 继续 需求是否含糊? ├─ 是 → plan mode └─ 否 → 直接改 自己是否还没想清楚? ├─ 是 → plan mode └─ 否 → 直接改
- 当前会话的 todo
- 会话结束就失效
- 工具自动维护
- 跨会话、跨天、跨人
- 落到 GitHub/GitLab Issue
- 需要手动管理
## Task List - [x] 分析代码结构 - [ ] 重构 API 层 - [ ] 更新测试 - [ ] 提交 PR
# Issue: 重构用户认证系统 ## Day 1 - [x] 分析现有认证流程 - [x] 设计新的认证架构 ## Day 2 - [ ] 实现新的认证中间件 - [ ] 更新所有 API 端点 ## Day 3 - [ ] 编写测试 - [ ] 部署到 staging - [ ] 性能测试
# Issue: 实现 payment webhook ## TODO - [ ] @alice 设计 webhook schema - [ ] @bob 实现接收端点 - [ ] @charlie 编写测试 - [ ] @alice 部署和监控
- 需要同步状态
- 需要协调优先级
- 需要跟踪进度
- 会话结束就失效
- 无法共享给他人
- 无法持久化状态
这个功能能今天完成吗? ├─ 是 → 会话级 Task List └─ 否 → 继续 需要别人接手吗? ├─ 是 → Issue └─ 否 → 继续 需要跨多天吗? ├─ 是 → Issue └─ 否 → 会话级 Task List
为什么在这儿偏离 spec? 兼容性问题。
为什么用这个算法? 时间复杂度最优。
同事问了:"这儿当初为啥这么写?" 你:额……我想想……
issue#XXXX.html 是唯一还记得答案的地方。# 为什么不用缓存?
# note-it: Redis 在这个环境里不可用,跨云部署成本太高。
# 暂时用内存缓存,等基础设施到位再迁移。
def get_user(user_id: int) -> User:
# 直接查数据库,不用缓存
return db.query(User).filter_by(id=user_id).first()
为什么选 A 方案不选 B? - A 方案性能更好(O(n) vs O(n²)) - B 方案需要引入新依赖,增加维护成本 - A 方案代码更简单,易于理解
- 翻 Git log:10 分钟
- 看当时的讨论:20 分钟
- 重新分析代码:30 分钟
- 还可能想不起来
# spec 要求返回 List[Dict]
# note-it: 改成返回 DataFrame 是因为下游需要用 pandas 处理
# 如果其他调用方不需要,可以考虑加个 adapter
def process_data() -> DataFrame:
...
# 为什么不用多线程? # note-it: 这里的数据库连接池不支持并发,多线程会导致连接泄漏 # 等升级到支持 asyncio 的驱动再考虑并行化
# note-it: 这是一个临时的 workaround
# 根本问题是第三方 API 的 bug,已经提了 issue
# 等 API 修复后需要移除这段代码
def workaround_api_bug():
...
# note-it: 这里用 C 扩展是因为 Python 版本太慢(100ms vs 5ms) # 如果有更快的纯 Python 实现,可以考虑替换 import fast_c_extension
- 为什么:为什么这么做
- 为什么不:为什么不用其他方案
- 权衡:选择了什么,放弃了什么
- 风险:有什么潜在问题
- 代码注释里(最重要)
- Issue 描述里
- 文档里
- commit message 里
- 简洁:3-5 句话
- 具体:提到具体的数据、事实
- 可追踪:如果有讨论,附上链接
## 做这个决定时,我记了吗? - [ ] 为什么选这个方案? - [ ] 为什么不用其他方案? - [ ] 有什么权衡? - [ ] 有什么风险? - [ ] 未来需要改进吗?
这个改动需要 plan mode 吗? ├─ 公共 API?→ 需要 ├─ 跨多个文件?→ 需要 ├─ 需求含糊?→ 需要 ├─ 自己没想清楚?→ 需要 └─ 否 → 直接改 这个任务需要落 Issue 吗? ├─ 跨天?→ Issue ├─ 跨人?→ Issue └─ 否 → Task List 这个决策需要 note-it 吗? ├─ 偏离 spec?→ 需要 ├─ 绕开方案?→ 需要 ├─ 技术债务?→ 需要 ├─ 性能关键?→ 需要 └─ 否 → 可选
- [ ] 改动涉及公共 API
- [ ] 改动跨多个文件
- [ ] 需求含糊不清
- [ ] 自己还没想清楚
- [ ] 让工具自动维护
- [ ] 扫一眼确认没拆歪
- [ ] 只在跨天/跨人时落 Issue
- [ ] 记录为什么选这个方案
- [ ] 记录为什么不用其他方案
- [ ] 记录权衡和风险
- [ ] 记录未来改进方向
- 不该 plan 的别 plan,省几分钟
- 不该落 Issue 的别落,省维护成本
- 该 note-it 的别省,省考古时间
- plan mode 减少大改动的失误
- Task List 减少遗漏
- note-it 减少误理解
- note-it 让代码可读
- Issue 让进度可追踪
- 计划让决策可回顾
- note-it 让同事理解你的决定
- Issue 让协作更顺畅
- 计划让讨论更聚焦
- 精密手术刀,不是万能钥匙
- 只在改动有分量、需求含糊时用
- 单文件小修直接改
- 会话级轻量,让工具维护
- 只在跨天/跨人时落 Issue
- 扫一眼确认没拆歪就行
- 5 分钟记录,换 3 个月不考古
- 记决策、不记代码
- 给未来的自己留条后路
> 工具应该为你服务,不是你为工具服务。轻量优先,持久化慎重。记录决策,不是记录代码。
夜雨聆风