代码审查须先确认pr描述与关联issue有效性，再聚焦可运行性、空值防御、敏感信息、结构可维护四类高危问题，逐项验证并给出具体修改指令。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要在团队协作中快速给出专业、可落地的代码审查意见，避免泛泛而谈的“写得不错”或“建议优化”，而是让开发者一眼看懂问题在哪、为什么重要、该怎么改。
明确审查目标与范围
打开 PR 页面后，先不急着看代码，点开 Description 区域，确认本次提交是否附带清晰的变更说明；没有说明的，【必须暂停审查，退回给提交人补充】——否则你无法判断这段逻辑是修复 Bug、新增功能，还是技术债务清理，后续所有意见都可能偏离重点。
检查关联的 Issue 编号是否真实存在且状态为 Open 或 In Progress；若链接失效或 Issue 已关闭，直接在评论区标注“请核实需求上下文”。
聚焦四类高危问题逐项扫描
方法一：可运行性验证
本地 checkout 该分支 → 运行 make test 或 npm test（根据项目实际命令）→ 观察是否全部通过；任一测试失败，立即标记为 Blocker 级别问题，不进入下一轮检查。
方法二：空值与边界防御
搜索新增代码中所有 .get()、.find()、[index]、response.data 字段访问操作，在其前一行插入断点式注释：// TODO: check null/undefined → 要求开发者显式处理或加断言；漏掉任意一处，上线后可能触发 TypeError。
方法三：敏感信息硬编码
全局搜索 'password'、'key'、'secret'、'token' 字符串，凡出现在 .js/.py/.go 源码中（非 test 文件或 .env.example）的，一律标为严重问题；【禁止在代码里写死任何凭证，必须走环境变量或密钥管理服务】。
结构与可维护性判断
第一步：定位新增函数或类，用编辑器折叠功能收起所有内部实现，只看函数签名和注释。
第二步：检查参数数量是否 ≤3；超过则提示“建议拆分为多个小函数或封装为配置对象”。
第三步：查看是否有超过 15 行未折叠的连续逻辑块；若有，直接引用《Clean Code》第 3 章原文：“函数应该只做一件事”，并建议提取为独立函数，命名需体现意图（如 calculateTaxAmount 而非 processStep2）。
