g.9方法⏱ 约 6 分钟
用 P4 方法做 code review
给整个项目来一次"靠谱化"体检
🔎 最后验证 2026-05📚 来源:《AI编程实战三卷书》卷二 §8–12🧰 Claude Code、Git✅ 46 人学过👁 85 次阅读
为什么学这个
项目能用了,但"能用"不等于"靠谱"。上线之前,该用 P4 学的那张自检清单给整个项目做一次彻底体检——把藏在里面的坑(误删、安全、边界、逻辑错)揪出来。这一步,正是 P4 护城河在你自己项目上的实战。
💡 打个比方
就像新房入住前的验收:水电、墙面、门窗一项项查一遍,有问题趁早修。项目上线前的 code review,就是这道验收——别等用户(或你自己)踩坑了才发现。
- 拿出 P4 #22 的一页纸自检清单,逐项过你的项目:
- 改动范围 / 误删?2. 逻辑对吗?3. 边界处理了吗?4. 安全(密钥/输入校验/注入)?5. 测试有效、无回归?6. 一致/无重复/不过度?7. 写法没过时?8. 别被 AI 自信骗
- 做法:可以让 AI 先按清单自查并列出问题(P4 m.7 的提示词),但你来复核拍板(它的自查是第一道筛,不是终判)
- 发现的问题逐个修:改前 commit、改后 diff、修完验证(全套 P3/P4 流程)
- 重点扫一遍安全:这是上线前绝不能漏的(密钥别进仓库、用户输入要校验)
❓ 测验
项目上线前做 code review,正确的方式是?
⚠️ 避坑自己项目最容易'护短',更要照清单硬过
对自己做的项目,人容易'我觉得没问题'就放过(P4 #20 的自我版)。正因为是自己的,越要严格照清单一项项过,尤其安全。上线意味着真实用户和真实风险——把 P4 的每一条都当回事,你的作品才经得起检验。
🤖 给项目做全面体检(去真实环境)
请对我这个准备上线的项目做一次全面 code review,逐项报告问题:1) 越界/误删;2) 逻辑正确性;3) 边界与异常;4) 安全(硬编码密钥、输入校验、注入);5) 测试是否有效、有无回归;6) 一致性/重复/过度设计;7) 是否有过时写法。每项列出具体问题和位置,先只报告不改动,我逐项确认后再修。
🔎 来源与核验· 1 条,点开核对
本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。
「上线前用系统化自检清单审查项目(尤其安全)是质量保障的关键环节」
📚 《AI 编程实战三卷书》卷二 §8–12✓ 已核验 2026-05
🔧 试一试:让 AI 埋个雷,再用自检清单把它挖出来(8 分钟)
- 让 Claude 写一小段"能跑但藏了隐患"的功能代码(比如一个处理用户输入的接口),故意留一两个问题(没校验输入 / 密钥硬编码 / 边界没处理),先别告诉你埋在哪。
- 你拿 P4 #22 那张自检清单,自己逐项过一遍这段代码,把可疑处标出来。
- 再让它对照清单自查、公布埋的雷。对一下:你抓到几个?漏了哪个?
你会看到:安全类问题(硬编码密钥、没校验输入)最容易被肉眼放过,而照着清单一项项过就能稳稳兜住。
为什么:review 靠的不是"感觉",是一张固定清单逐项扣。对自己的项目尤其容易"护短"放过,清单就是替你顶住这份侥幸——上线前的安全项,一条都不能靠运气。
✅ 小结
体检发现的问题修完了。要让"靠谱"可持续,光靠一次 review 不够——下一节给关键功能补上测试,让质量被自动守护。
下一节 → 写测试保证靠谱
都看到这了，打个赏呗！
接下来 · g.10
写测试保证靠谱
继续读下一节 →