# altitude进场：重构赛道三条路线横评——simplify改描述了 ## 概述 ## 一、新闻钩子：四件套里，唯独重构件改了描述 先摆证据。09-03 存档《出厂四件套》逐字引用过 simplify 的描述： > Review the changed code for reuse, simplification, and efficiency cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that. 而本会话技能清单里随名下发的同一描述，现在是： > Review the changed code for reuse, simplification, **efficiency, and altitude** cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that. 逐词对齐后，变更只有一处：清理维度的清单从三项扩成四项，插入的正是 **altitude**。同期比对的 code-review、verify、run 三件描述均与存档逐字一致——**四件套里唯一动了的，是重构件；唯一加的维度，是抽象层级。** 解释一下这个词。altitude（高度/层次）指一类特殊的代码病：代码本身没有错、甚至跑得很快，但它长在了错误的抽象层级上——该下沉到工具函数的逻辑内联在业务里，该留在调用方的决策被压进了被调方，三层循环里藏着本该是一个数据结构变换的东西。这类问题 bug 工具查不出来（因为没错），性能工具也查不出来（因为不慢），只有「站在更高一层看结构」才看得见。把它写进清理清单，等于官方给重构下了一个新的操作定义：**重构不只是去重和提效，还包括把代码搬回它该在的楼层。** 要与本系列此前的两个描述变更案例划清界限。《撞名九组》记录过为排他而设计的描述，《改牌第二例》记录过市场件为去品牌化而改写描述——那两回改的都是「门面」（何时被触发、撞不撞邻居的名字）。这次不一样：**simplify 的触发条件一个字没动，动的是能力清单本身。门面改写是营销行为，维度增补是发版行为**——前者说明作者在抢流量，后者说明官方在给这个赛道加需求。对一个想给重构写 Skill 的开发者，这是比任何榜单都值钱的信号：市场公认的重构定义正在从「清理」扩到「矫正层级」，而 altitude 恰好是当前所有社区重构件都没写的维度。 另一个一手观察顺带记录：本会话出厂清单的末排，`code-review` 之外还并列列出了 `review` 与 `security-review` 两个命令名（清单未随发描述文本）。审查线在出厂层的编制似乎在裂殖成一队，而重构件的编制仍是单兵——**审查在扩编，重构在升维**，两条线的官方投入方向不同，这个对照留给读者自行解读。 ## 二、评测对比表 权重沿用本栏目固定口径：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%。**维度替换**：simplify 作为出厂件无可观测社区数据，「社区」替换为「维护确定性」（precedent 见 09-03 期）。**置信度标注**：improve-codebase-architecture 本期未取得 SKILL.md 正文，仅依据存档侧写评分，功能/实战两格为黑箱估分，带 ※；refactoring-ui-skill 沿用 09-01 期实测口径。 | 重构 Skill | 路线 | 功能 | 设计 | 实战 | 上手 | 社区 | 加权 | |-------|------|------|------|------|------|------|------| | simplify（出厂件） | 顺手修 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | **4.80** | | improve-codebase-architecture ※ | 先访谈再动刀 | ★★★※ | ★★★★★ | ★★★※ | ★★★ | ★★★★★ | **4.05** | | refactoring-ui-skill（s0xDk） | 规则编译 | ★★★★ | ★★★★ | ★★★ | ★★★★ | ★★★ | **3.78**（存档分） | | code-review（对照行，非重构件） | 审查邻居 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | **4.80**（存档分） | > 说明：simplify 功能格从存档的四星升到五星，理由即第一节——描述在本期窗口内发生了能力增补，这是可验证的功能面变化，升到 4.80，与审查旗舰 code-review 的存档分打平。**重构赛道第一次在评分表上追平了审查赛道**，这个打平本身就是本期最大的生态新闻。 ## 三、主拆三条路线 ### 路线一：顺手修——simplify，把重构做成结账动作 simplify 的定位是「改变之后」的清账员：你已经改了代码，它把改动里的可复用、可简化、可提效（现在还有可升层）顺手清掉，然后**直接落地修复**（apply the fixes）。它与审查件共享同一个输入（the changed code），却比审查件多走一步——审查产出报告，重构产出 diff。这种「顺手」定位的成本是它直接改你的工作区，胆小的团队需要先在分支上试用；收益则是零仪式感，不需要专门的「重构日」，每次小改动顺手清一笔。 它的设计精华仍然是那句让位句——"Quality only — it does not hunt for bugs; use /code-review for that."——09-03 已逐句拆过，不再重复。本期要看的是**新维度怎么融进旧句式**：altitude 被插在 efficiency 之后、句式结构未动、让位句原样保留。这是一个值得抄写的修改示范：**给 Skill 加能力时，改清单不改结构；加的维度如果与旧维度有边界风险（altitude 清理有时会大面积挪代码，可能「看起来像引入了 bug」），靠原有的让位句继续兜底，而不是新起一段解释。** 16 个字母的增量，零结构成本，全句的契约关系一分未动。 短板也照旧：它的视野锁死在 the changed code——一次 diff 之内。全仓库级的层级矫正（把一整个模块搬到该在的楼层）不归它管，这正是路线二的存在理由。 ### 路线二：先访谈再动刀——improve-codebase-architecture，重构作为问答过程 这条侧写足以定位它的路线：如果说 simplify 是「改完再清」，它是「动刀之前先问透」——架构级重构最大的成本不是改错代码，而是改错方向，所以在任何 diff 产生之前，先用结构化访谈把意图、约束、现状逼问清楚。grilling 原语复用保证了访谈质量不随技能数量稀释，这是套件级设计对单文件设计的代差。 置信度声明：本期未取得其 SKILL.md 正文，以上是基于套件架构的推演，功能与实战两格的黑箱属性已在评分表标 ※。它也有明确的上手摩擦：需要装入全家桶（或至少其依赖），且访谈式工作流要求用户愿意陪它问完——赶时间的贡献者会觉得慢。**simplify 适合每天，它适合每个季度**，两件不构成竞品，构成节奏。 ### 路线三：规则编译——refactoring-ui-skill，把重构的对象扩到界面 把它放进重构赛道不是拉郎配：Refactoring UI 这本书的原名动词就是 refactoring，界面重构与代码重构共享同一个内核——**在不改变行为的前提下改变结构**（界面行为=功能不变，代码行为=语义不变），差别只在「行为」由谁验收：代码由测试验收，界面由眼睛验收。这正是它短板的根源——它选了一条验收成本最高的赛道，却没有像 webapp-testing 那样自带侦察环节，也没有像 goldie 那样把验收做成护城河。给它的改进建议一句话就够：**加一个前后截图对照步骤，许愿就变成了验收。** ## 四、边界地图：一次「帮我改改」的路由 重构赛道的设计质量，最终体现在与邻居的边界上。把三件加两位邻居放进同一次请求的路由图： ```mermaid flowchart TD A[用户：帮我改改这段代码] --> B{改什么的判定} B -->|有 bug 嫌疑| C[code-review
找错 · 档位化输出 · --fix 可选] B -->|没错 但乱| D{simplify
去重/简化/提效/altitude · 直接落地} B -->|整个架构方向不对| E[improve-codebase-architecture
grilling 访谈 · 先问后改 ※] B -->|不是代码 是界面| F[refactoring-ui-skill
书改规则 · 缺自查闭环] C -.让位句导流.-> D D -.超出 diff 范围.-> E ``` 这张图里有两条已有的线（code-review 与 simplify 之间的让位句导流、simplify 与架构件之间的范围让渡）和一条新增的线——**altitude 让 simplify 与架构件的边界变模糊了**：把内联逻辑下沉成函数是 altitude 清理（simplify 管），把整个模块重新分层是架构重构（它管），两者的分界恰好在「一次 diff 能不能装下」。出厂件用输入范围（the changed code）划界，而不是用任务类型划界，这个划界手法本身值得社区件学习——**按范围划界天然无歧义，按任务类型划界总会打架。** ## 五、推荐排行榜 **按场景选型**：每次提交后的日常清账 → simplify（零安装、直接落地）；季度性架构大手术前的评估 → improve-codebase-architecture ※（先问后动刀，但需陪访）；界面改版 → refactoring-ui-skill（配一张前后对照截图当验收）；不确定是 bug 还是乱 → 先 code-review 后 simplify（让位句已经替你排好了顺序）。 **按设计水线**：simplify（让位句 + 档位继承 + altitude 增补的三重示范）> improve-codebase-architecture（原语复用的套件打法）> refactoring-ui-skill（规则编译完整、验收环节缺位）。 **按上手成本**：simplify（出厂随发、命令即用）> refactoring-ui-skill（单件 clone 即用、无依赖）> improve-codebase-architecture（建议整桶安装、有访谈时间成本）。 **给想写重构 Skill 的读者的三条抄作业**：维度可以抄 altitude——「抽象层级矫正」是当前所有社区重构件的共同空白；边界要按输入范围划（diff 内 / diff 外），不要按任务类型划；验收环节必须在 SKILL.md 里闭环到可产出物（测试、截图、diff 报告任选其一），否则规则只是许愿。 ## 六、安装与使用 ```bash # simplify：出厂件，零安装。Claude Code 内直接： # /simplify # improve-codebase-architecture：随 mattpocock 全家桶分发（53 件） npx skills add mattpocock/skills # 或手动落位后按需取用 git clone --depth 1 https://github.com/mattpocock/skills ~/.agents/skills # refactoring-ui-skill：单件安装 git clone https://github.com/s0xDk/refactoring-ui-skill ~/.claude/skills/refactoring-ui ``` ## 参考来源 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。