Ponytail 极简开发

解决什么问题

当代码库被过度设计裹挟时，最常见的失败不是缺少抽象，而是凭空造了没人要的东西：只有一个实现的接口、永远不会变化的配置项、“为以后预留”的脚手架。更隐蔽的是把同一个根因在每个调用点各打一次补丁，diff 越滚越大，问题照旧。Ponytail 把资深开发者“先确认它是否需要存在”的反射，固化成一套可复用的代码审计流程。

核心能力：选择阶梯

每接到一个改动，沿阶梯停在第一个站得住的一级：

1. 它需要存在吗？ 猜测性需求直接跳过，一行说明理由（YAGNI）。
2. 代码库里已有？ 先复用已有的 helper、util、type 或模式，重复实现几行之外已有的东西是最常见的 slop。
3. stdlib 能做？ 用它。
4. 平台原生能力覆盖？ 原生 picker 胜过第三方库，CSS 胜过 JS，DB 约束胜过应用层代码。
5. 已装依赖能解决？ 用它，不为几行代码引入新依赖。
6. 能否一行解决？ 那就一行。
7. 以上都不行： 才写最小可用代码。

阶梯是反射，不是调研：先完整阅读任务与相关代码、端到端追踪真实流程，再开始爬。两级以上同时成立时，选更高的一级。

Bug 修复只认根因：报告写的是症状。改函数前先 grep 所有调用方，在共享函数加一处防护，比给每个调用点各加一处更短，也不会漏掉 ticket 没提到的兄弟路径。

规则清单：没有未被请求的抽象（单实现的接口、单产品的工厂、不变值的配置都不要）；删除优先于新增；无聊优先于聪明；文件数尽可能少。刻意砍掉有明确上限的简化（全局锁、O(n²) 扫描、朴素启发式）必须留一行 # ponytail: 注释，写明上限与升级路径。输出格式固定为 [code] → skipped: [X], add when [Y]，解释不允许比代码长。

强度三档：lite 照做但附一行更懒的替代，由用户选择；full（默认）强制执行阶梯，stdlib 与原生优先；ultra 走 YAGNI 极端，能一行就一行，并当场质疑其余需求。

适用边界

不能简化掉的东西：信任边界的输入校验、防止数据丢失的错误处理、安全措施、可访问性基础，以及用户明确要求的实现。用户坚持完整版就直接做，不再争辩。

不能简化的是理解本身：阶梯缩短的是方案，不是阅读。先追踪所有受影响文件和真实调用流，再选层级——跳过去理解的小 diff，本质是一次自信的错误修复。硬件永远不是纸面理想值，校准旋钮必须保留，物理世界需要最小模型看不见的调节。

懒代码不能没有检查：非平凡逻辑（分支、循环、解析器、涉及钱或安全的路径）留下唯一一个可运行检查——基于 assert 的 demo()/__main__ 自检，或一个小的 test_*.py。一行能解决的逻辑不需要测试，YAGNI 同样适用于测试本身。