code-simplifierlisted

# 代码简化 只优化本次最近修改的代码，使实现更直接、清晰、符合当前项目习惯；不改变业务行为，不顺手重构无关代码。 ## 先确定范围 优先以当前 `git diff`、本次会话实际修改文件和用户指定范围为准。 除非用户明确要求扩大范围，否则不要因为发现旧代码也能优化，就继续整理整个文件、模块或项目。 简化前先读取当前项目 `AGENTS.md`。涉及项目已有实现方式时，同时按 `.agents/skills/code-consistency/SKILL.md` 检查附近和同类代码，不用通用“最佳实践”覆盖项目已经形成的合理约定。 ## 简化目标 重点检查本次改动是否出现： - 没有额外语义、只服务下一行调用的一次性临时变量。 - 为当前单次业务步骤新增的薄函数、包装层或中转参数。 - 可以直接表达却被拆成初始化再覆盖、重复判断或多余状态的逻辑。 - 不必要的嵌套、重复分支、重复转换或重复读取。 - 只为形式分层新增的 Service、Manager、Context、Helper 等业务抽象。 - 与当前模块已有代码相比明显更绕、更啰嗦或采用了第二套等价写法的实现。 - 逐行复述代码、没有解释业务意图的注释。 简化时优先让真实业务顺序直接可见，并遵守项目已有的函数边界、日志、异常处理和 xbot API 使用方式。 ## 保持行为不变 简化不是重新设计。不得无理由改变： - 业务条件、执行顺序、循环边界和停止条件。 - 返回值、数据结构、异常传播和失败语义。 - 日志中承担排查价值的业务上下文。 - 用户已确认的字段名、XPath、CSS、URL、按钮文案、Sheet 名、状态值和配置值。 - xbot / 市场指令的 API、参数、调用时机和页面交互顺序。 - 已有必要封装提供的后置条件，例如“返回一个已经登录且可直接使用的 page”。 如果无法确认某个改写是否保持行为一致，就不要为了更短或更“优雅”而修改。 ## 不要过度简化 目标不是减少行数。 以下情况应保留显式结构： - 分支包含多个业务动作、副作用或异常处理。 - 中间变量会复用、参与后续判断，或名称能明显解释业务含义。 - 函数 / 类确实隐藏一组实现细节，并向调用方提供稳定完整的结果或后置条件。 - 展开写法更方便排查、调试或理解真实业务顺序。 不要生成密集 one-liner、复杂条件表达式、难读的链式调用或仅为了“更少代码”合并多个业务步骤。 ## 完成后验证 修改后重新检查 diff，确认： 1. 只修改了本次简化范围。 2. 没有引入与当前项目不同的新实现模式。 3. 业务行为、失败语义和关键常量没有变化。 按项目 `AGENTS.md` 的验证规则做与本次简化直接相��的最小必要验证。没有实际运行或可验证证据时，只能说明静态检查结果，不能声称业务运行行为已经验证一致。 如果当前改动已经足够直接清楚，不需要为了执行本 Skill 而强行产生新的代码修改。