保守式代码编辑

要解决什么问题

让 AI 或协作者在改代码时，默认只做与任务直接相关的 diff，而不是顺手重构、全文件格式化或「顺便优化」。很多线上问题来自无关改动：公共组件被改坏、状态流转被悄悄换掉、深色主题里又写死 #FFFFFF。这类技能把最小必要改动和改前先问写成可执行的约束，而不是口头提醒。

技能如何约束改动

编码原则层面：保持现有架构、交互逻辑、状态流转、模块职责、命名与实现模式；不做无关重构、格式化、优化或清理，也不删除改动前已存在、但与本次任务无关的旧代码。改之前先想影响面，改之后尽量验证；实现上简洁优先，只在关键位置加通俗注释。

项目硬性规则层面：若要动架构、交互、状态、模块职责或核心实现风格，必须先说明原因、影响范围与风险，并等待确认。若要改公共基础代码（基类、公共 UI、工具类、网络/存储/路由、日志、埋点、权限、主题等），必须先列出影响范围并等待确认。项目已支持深色模式时，禁止硬编码固定 UI 色值，须动态适配并优先用现有颜色资源。

优先级为：用户明确要求 > 项目硬性规则 > 编码原则。

适用边界

它规范的是「怎么改」，不替代需求澄清或测试策略。用户若明确要求大范围重构或改公共层，在说明风险并确认后仍可执行；技能目的是避免默认越界，而非禁止所有结构性变更。