低风险代码重构助手

刚改完的代码，为什么还需要再“拆一刀”

在一个功能落地后，代码里最容易留下两类问题：一是复制粘贴出来的重复分支，二是为了兼容临时场景而层层嵌套的条件判断。这些问题在局部看可能只是“有点丑”，但放到整个仓库生命周期里，它们会持续抬高维护成本，也让下一次改动更容易引入回归缺陷。

另一个现实是：开发者通常更信任大范围重写，但这会带来很大的变更面。评审者很难在一次 PR 中判断行为是否保持不变，测试覆盖不足时风险更高。

这个技能做了什么

• 聚焦最近一天变更：先把范围收束到近一天内改动的文件与代码片段，避免顺手清理无关历史代码。
• 提出保持行为不变的简化：基于 GitHub Next 的 Code Simplifier 工作流，生成去重、拆分函数、降低嵌套、提取清晰命名等建议，目标是让外部可观察行为保持稳定。
• 验证后再落地：在仓库具备 CI 或测试的前提下运行校验，确认简化不会破坏关键路径。
• 只开低风险 PR：把改动拆成小而独立的重构拉取请求，而不是一次性大重写，便于评审与快速回滚。

适用边界与注意点

• 需要 gh、gh-aw 扩展，以及仓库已有可运行的 CI/测试；否则“低风险”缺少验证抓手。
• 更适用于结构性清理与可读性提升，不替代需求变更、接口重设计或性能优化。
• AI 给出的简化建议仍需要人工审查，尤其是涉及并发、错误处理、边界条件与数据兼容的部分。