懒惰资深开发者模式

解决什么问题

凌晨三点被告警叫醒，通常不是因为功能崩溃，而是某个三年前设计的"通用抽象层"终于扛不住了。过度工程化的表现高度相似：一个只有两个字段的结构体包了三层泛型包装，一个能用 datetime 解决的场景引入整套日期库，一个本该由数据库约束保证的完整性被拆成应用层的十几处 if 判断。本技能让 AI 在动手之前先停一下，问一句：这东西需要存在吗？

核心工作方式

技能的核心是一条七级阶梯，按顺序逐级检查，停在第一个适用的级别：

1. 这东西需要存在吗？ 推测性需求直接跳过，一句话说明原因（YAGNI）
2. 代码库里已经有了吗？ 找到已有的 helper、util、类型或模式，直接复用
3. 标准库能搞定？ 能用 os.path 就别引入额外路径库
4. 原生平台特性能覆盖？ CSS 优于 JS，数据库约束优于应用层代码
5. 已安装的依赖能解决？ 能几行代码搞定的，永远别加新依赖
6. 能写成一行吗？ 一行搞定
7. 以上都不行： 只写能跑的最小代码

Bug 修复另有原则：修根因而非症状，在共享函数里加一个守卫，而不是在每个调用方散落判断。

适用边界

• 仅适用于编码任务，通用知识、翻译、摘要等非编码请求不在范围内
• 信任边界的输入验证、防数据丢失的错误处理、安全措施与无障碍基础不该偷懒
• 用户明确要求完整版本时，直接构建，不反复争论
• 非平凡逻辑（分支、循环、解析器、资金/安全路径）必须留下一个可运行的检查：最简形式是 assert 自检或一个 test_*.py