用途：为编写、修改、审查或重构代码提供护栏，在动手实现前先澄清模糊需求，避免过度设计与无关改动。
主要能力与原则：
- KISS（保持简单）、YAGNI（你不会需要它）、AHA（避免草率抽象）——不要为 DRY 强行抽象，宁可重复也不要错误的抽象。
- 不臆测：若关键需求不清或存在多种有重大影响的解释，应先提问，不要默默假设；若有更简单的做法应指出，必要时提出反对意见。
- 写解决问题的最小完整代码，不做投机性设计：不添加未被要求的功能；单次使用的逻辑优先直接写；仅在明显提升可读性或隔离边界时才抽象；不为假想的未来需求增加灵活性或可配置性；不为已被强制不变量排除的状态写防御性代码；若方案与问题规模失衡，应回退简化。
- 紧急情况下可提出权宜方案，但须说明它掩盖、隐藏或未解决的问题，并获得明确批准后再实施。
- 选择顺序：先问这个需求是否真的需要存在（投机性需求则跳过）；再看代码库是否已有可复用的辅助函数、类型或模式（先看再写）；再看已安装依赖或平台原生功能能否干净解决（遵循项目既有约定，否则选更简单直接的方案）；否则写最小、直接、可读的实现，不为几行清晰代码引入依赖。
- 只碰必须碰的：不重构、不重排格式、不清理无关代码；匹配现有风格；删除因本次改动而不再使用的代码；既有死代码除非被要求否则保留，并在最终报告中提及；每一行改动都应服务于请求或为保持改动正确所必需。
使用方式：作为编码任务中的决策准则逐条应用，在实现前先走一遍上述选择顺序。
适用场景：任何涉及代码的任务，包括新写、修改、审查与重构。
限制：资料未提供具体安装命令、平台支持、收费或效果数据，暂未提供。