用途
Code Ambition 是一个在实质性构建、重构或设计工作开始前使用的技能。它的核心姿态是：向代码应有的模型构建，并通过加深已经存在的接缝来表达这种雄心，而不是顺从当前形态或另起炉灶发明平行结构。
核心论点
现有实现是原材料，不是必须保留的约束。这在年轻或由智能体构建的代码库中尤其如此：现存的东西可能是脚手架式的历史遗留，而非预期设计。
不要满足于仅仅“适配”或仅仅“能跑”的版本。要追求显著更简单、更深、更正确的形态，即使这意味着围绕改动进行重构。
默认保持雄心
这是智能体最常做得不够的部分。不要停在“这里可以更干净一点”或“这里大概应该重构一下”。如果请求需要重构，就执行重构。
寻找“代码柔道”式的动作：一种更有效地利用架构的重组，让整块分支、辅助函数、模式、条件或层级彻底消失。
如果存在一条删除复杂度而非重新排列它的路径，就走那条路。移除活动部件胜过把同样的复杂度分散到各处。
优先选择事后看来必然如此的方案。
每次都问更深的问题：不是“我怎么让这个适配？”，而是“这里正确的东西是什么，构建它需要什么？”
半吊子是失败。技术上能跑但让模型变浅、接缝变模糊、或让下一次改动更难的代码不算完成。
雄心而非扩张
雄心意味着当请求的模型确实需要时，去做更难的、正确的工作：重构所属接缝、删除陈旧脚手架、重塑模型，或修复根因而非推迟。
它不意味着把一个小请求扩张为投机性的健壮性、兼容性保留、额外测试、包装器、迁移或相邻清理。当删除机制并信任所选依赖或接缝时，更简单往往是更有雄心的设计。
当用户提供了确切的实现形态、diff、代码片段、命令输出或替换模式时，将其视为契约。只有在请求的形态未通过必需检查、已证实的缺陷使请求路径不可用、明确的安全/安保/数据完整性规则要求，或用户要求更广泛的加固时，才添加包装器、兼容层、测试、抽象、文档或边界情况加固。
当前形态是证据，不是权威
把代码、注释、测试、文件布局和评审反馈视为证据，而非权威。它们描述的是过去的决定，不决定正确答案。
不要让现有实现或命名支配设计。先决定正确的模型，再让代码服从。
不要仅因为测试这么说就保留行为。先判断该测试是否保护真实的契约、不变量、工作流或集成边界。
没有证据表明有真实的东西依赖旧路径时，不要添加向后兼容、新旧双路径或分阶段弃用。
清理是交付的一部分。替换一个模型通常意味着在同一次改动中移除过时的字段、组件、校验器、夹具、测试、文档、命令和交互入口。
雄心通过接缝流动
有雄心不意味着发明新的临时模式、辅助函数、包装器或平行机制。它意味着伸手去够代码库已有接缝的更深版本。
把逻辑推入已经拥有该概念的规范层。
复用已经存在的辅助函数。
深化模块，而不是在旁边硬接一条新路径。
扩展或重塑接口，而不是把功能检查散落到共享代码中。
对目的地有雄心，对路线有纪律。
没有挣得的深度，就没有抽象
对于缺陷修复、评审跟进和路由/UI 修复，先在失败的接缝处做直接修复。只有当新辅助函数、模块、导出、包接缝、包装器或文件通过删除测试，且现在至少满足以下一项时，才允许新增：
- 它有两个或更多真实调用方。
- 它从现有调用点移除重复行为。
- 它拥有非平凡的不变量、转换或运行时边界。
- 它通过删除另一个机制让周围代码变小。
- 它深化已确立的规范接缝，而不是给一次性操作命名。
不要仅仅为了单元测试而导出代码。不要为了给路由辅助函数、常量、对象形态或一行调用起个名字就包装它。如果删除新抽象会让代码更易读且没有行为在别处重现，就删除该抽象。
失败模式
顺从是让“这里有什么”决定“什么是对的”：适配现有格式、保留没人要求的兼容性、停在第一个能跑的东西上，或把旧测试当作金科玉律。
臆造是在错误方向上雄心勃勃：在规范辅助函数旁边添加定制辅助函数、把功能逻辑散落到共享路径、在扩展接口就能解决的地方启动全新机制，或添加隐藏简单结构的魔法式泛型处理。
该信条是两者之间的窄路。
需要警惕的坏味道
- 单次改动中文件被推到约 1000 行以上且没有强理由。
- 在无关流程上硬加新条件。
- 让控制流复杂化的一次性布尔、可空模式或标志。
- 掩盖不变量不清的强制类型转换、unknown、any 或可选性。
- 只增加间接层而不带来清晰度的薄包装器。
- 只搬运复杂度而不删除它的重构。
完成前自问
在结束前，问：这是正确的形态吗？陈旧机制是否已移除？所属接缝现在是否承载了该概念？项目要求的检查或运行时证明是否真的运行过？