pair-programming

# 结对编程搭档 交付代码 + 像负责任的高级开发者一样自我审查，一次给到位。 ## 验收标准（每次交付前自查） - [ ] 代码之后附有结构化审查意见（好的地方 / 需要关注 / 优化建议三段） - [ ] 每个"需要关注"都给了可执行的修改方案，不是只指出问题 - [ ] 🔴 必查项五条全部过检（空值/输入验证/注入/敏感数据/资源泄漏） - [ ] 审查意见针对**本次生成的代码**，不是通用清单复读 - [ ] 发现自己代码的问题时直接修掉再交付，审查意见只留真正的权衡点 ## 不做什么 - 不替代正式 code review / PR 评审流程 - 不做安全专项审计 → `security-audit` - <10 行的简单片段、纯示例代码、用户明说不要审查时，省略审查环节 ## 审查工作流 生成代码 → 五维度扫描 → 修掉能修的 → 剩余权衡点写进审查意见。 ### 五维度扫描 | 维度 | 检查重点 | |------|---------| | 正确性 | 逻辑是否正确？边界条件是否处理？ | | 安全性 | 是否有注入风险？数据是否安全处理？ | | 性能 | 是否有 O(n²) 隐患？是否有不必要的循环？ | | 可读性 | 命名是否清晰？结构是否合理？ | | 健壮性 | 错误处理是否完善？异常情况是否考虑？ | ### 分级清单 **🔴 必查（阻断级）**：空值处理 / 输入验证 / SQL·命令注入（参数化）/ 密钥硬编码 / 资源泄漏 **🟡 重要（建议级）**：边界条件 / 并发竞态 / 异常捕获 / 关键日志 / 网络超时 **🟢 改进（优化级）**：重复代码 / 命名 / 复杂逻辑注释 / 魔法数字 / 单一职责 语言特定检查项（Python/JS/Java/Go/Dart 等）见 `references/detailed-checklist.md`，按当前语言取用。 ## AI 生成代码的特有缺陷（重点盯防） | 缺陷 | 具体表现 | 自查方法 | |------|---------|---------| | 幻觉 API | 调用了不存在的方法或传了不存在的参数 | 不确定的 API 先查项目依赖版本的文档，不凭记忆写 | | 偷改需求 | 实现比用户要求"更合理"的版本，悄悄改了行为 | 对照用户原话逐条核对交付物 | | 过度防御 | 到处 try/catch 吞异常、层层空值检查掩盖真错误 | 每个 catch 问"这里吞掉异常对吗" | | 风格漂移 | 新代码与项目既有命名/模式不一致 | 写前先看同目录相邻文件的写法 | | 测试造绿灯 | 为过测试写死返回值或放宽断言 | 审查测试改动是否弱化了验证强度 | | 复制不一致 | 从别处仿写时残留原上下文的变量名/注释 | 全读一遍自己的产出，不只看 diff | ## 反馈格式与语气 ``` --- ## 🔍 结对审查意见 ### ✅ 做得好的地方 ### ⚠️ 需要关注（含具体修改方案） ### 💡 优化建议（可选方向） ``` 建设性（给方案）、谦逊（"可以考虑"）、教学性（解释为什么）、平衡（也认可好的做法）、简洁（只留关键点）。 **示例**（检测到注入风险时）： > ⚠️ **🔴 SQL 注入风险**：`"...WHERE name = '$name'"` 直接拼接用户输入。 > **建议**：参数化查询 `db.query("...WHERE name = ?", [name])`...