方法论学了七篇，明天上班先做哪个？
如果你跟着这个小节看下来，手里应该攒了一堆东西：重构六味、优化三问、测试四靶、Review 五关、注释三层、风格三步走、文档五件事……
看着挺唬人。但真到明天早上打开电脑那一刻，大概率是：“学是学了，可我今天到底该干哪一件？” 这就是方法论的通病——单个都有用，堆一起反而动不了。
这一篇不讲新东西，做三件事：把七篇串成一条时间轴、压成一张纸、点破五个误区。 看完就知道明天先动哪只手。
一、先纠正一个要命的认知
新手默认的质量流程是：写代码 → 写代码 → 写代码 → 最后检查一遍 → 交付。这个”最后检查”就是所有质量问题的根源——到了最后那一刻，你面对几千行已互相缠在一起的代码，发现命名混乱改不动了、结构不合理重写来不及了、没测试补都不知道从哪补。于是”最后检查”变成”最后看两眼，然后祈祷”。
正确的认知是：质量不是查出来的，是一路防住的。 七篇里的每件事，都对应开发流程里的一个特定时刻。放对时刻，每件事只花几分钟；全堆到最后，每件事都变灾难。
一句话：质量是分摊在每一天的小动作，不是交付前的一场大扫除。
二、质量时间轴：七件事各自的位置
把七篇按”什么时候做”排开，一切就清楚：
| 时机 | 做什么 | 对应篇 | 花多久 |
|---|---|---|---|
| 动手之前 | 定一页纸规范（命名/结构/风格） | 第82篇 | 一次性，半天 |
| 写的过程中 | 风格自动格式化 + 只写 Why 注释 | 第82、81篇 | 0（自动）+ 顺手 |
| 写完立刻 | 让 AI 写单元测试，四靶跑一遍 | 第79篇 | 10 分钟 |
| 提交之前 | AI Code Review 过五关 | 第80篇 | 5 分钟 |
| 交付对接时 | 生成 API 文档，五件事齐全 | 第83篇 | 10 分钟 |
| 发现代码难改时 | 重构，四步法一次改一味 | 第77篇 | 按需 |
| 用户真的说慢时 | 优化，先过三问再动手 | 第78篇 | 按需 |
前五件是”日常动作”，绑在流程上每次都做，加起来不到半小时；后两件是”触发式动作”——重构等代码难改再做，优化等用户喊慢再做。最常见的错就是把这两类搞反：日常动作一个不做，天天琢磨”该不该重构”“性能会不会有问题”。
记住：没触发就别动手。 重构触发条件是”改不动了”，优化触发条件是”用户觉得慢”。自己脑补出来的问题，不值得花时间。
三、七篇方法论一页纸（建议截图存手机）
这张表是本小节全部精华，每一行都是一篇文章压出来的：
| 篇 | 主题 | 核心口诀 | 展开 |
|---|---|---|---|
| 77 | 重构 | 六味 + 四步法 | 六味：长重名套魔杂；四步：锁（快照备份）→ 闻（只诊断）→ 拆（一次一味）→ 验（快照全跑） |
| 78 | 优化 | 三问 + 四招 | 三问：值（用户真慢？3秒分水岭）位（先测）价（代价值不值）；四招：少 > 批 > 延 > 缓 |
| 79 | 单元测试 | 四靶 + 四步 | 四靶：正边错空；四步：框说生补。覆盖率是找洞，不是追高分 |
| 80 | Code Review | 五关 | 正（正确）安（安全）错（错误处理）洁（可读）快（性能），顺序即优先级 |
| 81 | 注释 | 三层 + 两步法 | 三层：What 不写、How 少写、Why 必写；两步：AI 扮外人问→你口语答→AI 转注释 |
| 82 | 代码风格 | 三步走 | 盘现状→定一页纸→自动强制执行；外观交工具，命名交 AI+规矩 |
| 83 | API 文档 | 五件事 + 四步法 | 五件事：址入出错例；四步：喂补生验。错误码三要素：码+境+办 |
如果这张表你只记得住一行，记这个：
一次只改一件事，改完必须验一次。
这话套七篇都成立——重构一次只改一味，优化一次只上一招，Review 一次只改一档，注释一次只补一处，文档改完照着调一次。
四、五个新手最容易踩的质量误区
误区 1：质量是最后检查出来的。 排第一因为最贵。改法：五个日常动作绑到流程上，别攒着。
误区 2：追求 100% 测试覆盖率。 新手想拉满，为几个没用分支写一堆废测试。覆盖率正确用法是”找洞”：看哪些关键逻辑一行没测到——那才是危险区。getName() 这种一行函数测不测无所谓。
误区 3：憋着搞一次性大重构。 “等这版本上完我把整个项目重构一遍”——90% 结局是没干成或干出一堆新 Bug。正确做法：寄生式重构——改业务需求时顺手收拾当前文件，一年下来整个项目自然干净，零风险。
误区 4：提前优化性能。 “以后数据量大了会不会慢？我先优化”——大概率你优化的地方一辈子不会成瓶颈，而可读性代价团队天天还。记住优化三问第一问：用户真的觉得慢吗？没有就别动。
误区 5：文档留到最后补。 拖到最后要么不写，要么写的是三个月前的记忆（还是错的）。改法：接口写完那一刻趁热十分钟生成，所有细节都在脑子里，成本最低。
五、用 AI 做质量把控的三条铁律
工具再好，用法不对照样翻车。这三条没有例外：
铁律 1：给完整文件，别给片段。 这是所有 AI 编程问题的头号原因。你贴一段孤零零的函数，AI 看不到它被谁调用、依赖什么，只能猜，猜出来的建议落地就炸。完整文件贴不下，至少说清这三件事：
- 被谁调用
- 参数从哪来
- 返回值给谁用
铁律 2：一次只让 AI 干一件事。 “帮我重构，顺便优化，加注释，写测试”——结果四件都半吊子，你根本不知哪被改了。拆开问，一次一件，每件验收完再进下一件。慢就是快。
铁律 3：AI 说”没问题” ≠ 真的没问题。 AI 有讨好倾向，常给无关痛痒建议或干脆说”整体不错”。两招反制：
- 验伪追问——「你说没问题，给我一个能让它真出事的具体场景，举不出来我才信」
- 强制排序——「按严重程度分三档：会出事故/该改/无所谓，每档最多三条」
最终那道关永远是你自己。
六、如果只能做三件事，做哪三件？
第一件：装自动格式化（第82篇）。 一次配置永久生效，零维护，立刻消灭”改3行显示改300行”。性价比第一。
第二件：提交前让 AI 过五关（第80篇）。 每次 5 分钟，拦的是低级错误和安全漏洞——最易出事故也最易被 AI 发现。
第三件：接口写完立刻出文档（第83篇）。 省的不止你时间，是你和对接方两个人的成倍沟通成本。
这三件共同点：成本极低、见效极快、不依赖意志力。等变肌肉记忆了，再去碰重构和测试。
📦 提示词模板盒子
模板 1：质检母版（万能骨架，套七篇任意一件事）
你是一位资深工程师。请对下面这段代码做【重构诊断/性能分析/Code Review/注释补充/文档生成】（五选一，一次只选一个）。
代码（完整文件）：【粘贴代码】
背景：这段代码做什么用、被谁调用、目前遇到的具体问题
约束：不能改变对外行为；不能引入新依赖；【其他限制】
输出要求：1.按严重程度分三档（会出事故/该改/无所谓），每档最多3条 2.每条说明：问题在哪行、为什么是问题、改了有啥好处 3.这一轮只诊断，不给我改好的代码
模板 2：交付前一键体检
我这段代码马上要提交/交付，请按下面五关依次检查，一关一关来，不要混：
1.正确性：逻辑写反没、边界漏没 2.安全：硬编码密钥、未校验外部输入 3.错误处理：异常被静默吞没、失败没提示 4.可读性：看不懂的命名和魔法数字 5.性能：循环里查库这类低效
每一关给结论：通过/有问题（列行号）。确实没问题的直接说"通过"，别硬凑毛病。
模板 3：周质量复盘（每周五花十分钟）
这是我这周改动过的主要文件：【粘贴 2-3 个】
请做一次质量体检，答三个问题：1.哪个最"难改"？为什么（按重构六味：长重名套魔杂） 2.有没有关键逻辑完全没测试覆盖？列出来 3.下周只花两小时改进质量，建议改哪处？给理由。
不要给我改好的代码，只要诊断和优先级。
模板 4：验伪追问（防 AI 敷衍）
你刚才说这段代码"没有明显问题"。请给我一个具体场景：什么输入、什么时机，会让它真出错或产生错误结果。要具体到数据和步骤，能复现的。
确实举不出来就明确说"举不出来"，别编理论上的可能性凑数。
八、本小节收官速查
| 记忆点 | 内容 |
|---|---|
| 总纲 | 质量不是查出来的，是一路防住的 |
| 日常五动作 | 定规范 → 自动格式化+Why注释 → 写完自测 → 提交前 Review → 交付出文档 |
| 触发两动作 | 重构（触发：改不动了）、优化（触发：用户说慢） |
| 通用铁律 | 一次只改一件事，改完必须验一次 |
| AI 三铁律 | 给完整文件、一次一件事、AI 说没问题不算数 |
| 五大误区 | 最后才查、追覆盖率、大重构、提前优化、文档拖后 |
| 只做三件 | 自动格式化 + 提交前五关 + 接口即时出文档 |
结语
这个小节从第77篇讲到第84篇，其实只想说明一件事：代码质量不是天赋，也不是靠”细心”，是一套可以照做的动作。 以前这套动作对新手不友好——你得先有经验才知道哪里该改。现在 AI 把”经验”这个门槛砍掉大半：它能替你闻坏味道、列测试用例、找安全漏洞、生成整齐文档。你要做的，是知道什么时候调用它、怎么问它、以及不要全信它。
下篇预告
第85篇：用 AI 做技术选型与架构讨论。 前面一直在写代码、改代码，下一篇往上走一层：动手之前先决定”怎么干”——什么技术栈、数据存哪、功能自写还是找现成的、老板说”以后撑百万用户”现在按什么规模设计。关键是学会让 AI 给你”选项 + 代价”，而不是替你做决定。