code-renewlisted

# 代码升级（code-renew）· 代码/项目升级手术 > **一句话**：对一个"能跑但有很多毛病/死改改不出来"的项目，做一次**先看清、再设计、后动刀、步步验证**的全面升级手术。适用于网页/工具/脚本类项目；视角 = 资深工程师 + 高级审美设计师双线。 > > 实战出身：一次真实项目的四期升级手术（41 项诊断 → 四期施工 → 全部实测验收），本文所有铁律和踩坑都来自那次手术及后续实战。 --- ## 〇、定位与触发 **什么时候用**： - 项目"能用但到处是小毛病"，零敲碎打改不动了 - 同一个问题反复改反复回潮（"死改改不出来"） - 想把工具升格成作品（实用 + 审美双跃升） - 接手一个别人/过去的自己写的、没人完全看懂的代码库 **什么时候不用**：单点小修（直接改）；纯新功能开发（不需要先诊断旧账）；纯数据录入。 **触发词**：全面升级 / 迭代升级 / 大重构 / 代码体检 / 这项目帮我做一次升级手术 --- ## 一、八条铁律（违反任何一条 = 手术事故） 1. **备份先行**：动刀前整包 zip 进 `_backup/`（gitignore 掉），`unzip -t` 校验。出事解包回滚。 2. **先看清全貌，再动第一刀**：诊断与治疗严格分离。诊断期一行业务代码都不许改。 3. **找根因，不打症状**：症状在哪层，根因常在上一层。沿数据流问三次"这个值是谁给的"。 4. **用证据，不用感觉**：关键数字用独立实现对数；修复后用脚本/浏览器实测；"我觉得好了"不算数。 5. **机器查机械错，人查品味错**：穷举型问题（字号失控/死代码/硬编码色）交给 grep 和脚本；体验型问题（动效讲不讲故事/层级有没有焦点）必须亲眼看截图。 6. **死代码先清再建**："改了没反应"的第一嫌疑人是死代码和被覆盖的声明。先 grep 引用计数确认死透，再整块删。 7. **按依赖分期：地基(bug/性能) → 行为(交互/叙事) → 视觉(艺术层) → 精修(排版/模式/适配)**。在坏架构上调表层是"死改"的最大根源。 8. **每期一个 commit，每期独立实测验收**。损失隔离在一期内；commit 信息写清做了什么为什么。 --- ## 二、五幕流程 ### 第〇幕 · 备份与边界（10 分钟） 1. `zip -rq _backup/项目_升级前备份_$(date +%Y%m%d_%H%M).zip 项目目录 -x 排除项` + 校验 + gitignore。 2. **问用户拿决策**（一次问全）：施工优先顺序？技术栈边界（能否上构建工具/新依赖）？特殊模式需求（如展示/工作台分离）？移动端投入深浅？——拿到授权再开工，避免做完被推翻。 ### 第一幕 · 三路独立诊断（核心，约占总时长 1/4） 并行三路，互相不通气，最后交叉： - **路 A·代码审查**：派子代理**逐行读完**核心代码（大文件分给多个代理：逻辑 JS 一个、样式+结构一个）。指令要求：按严重度分组（必修 bug / 交互缺陷 / 性能 / 动效生硬 / 代码债），每条带行号和证据，"只报真实存在的问题，引用具体代码为证"。 - **路 B·亲眼巡检**：本体用自动化浏览器把**每一种页面状态**截图过目（每个 tab、每个弹窗、每个模式、播放中、窄屏 ≤430px）。看的是层级、对齐、焦点、文案、动效节奏——审美问题全在这一路。 - **路 C·数据核算**：对页面展示的关键统计数字，用 Pyt