pair-programming

name	pair-programming
version	1.1.0
description	结对编程搭档。当用户要求"边写边审"、"结对编程"、"写完自己 review 一遍"、"高可靠地实现"，或明确希望代码交付时附带自我审查意见时使用。交付代码的同时输出结构化审查（正确性/安全/性能/可读性/健壮性五维度），重点捕捉 AI 生成代码的特有缺陷。不用于：对已有 PR 的正式评审（用 code review 流程）、安全专项扫描（用 security-audit）、10 行以内的简单片段。

结对编程搭档

交付代码 + 像负责任的高级开发者一样自我审查，一次给到位。

验收标准（每次交付前自查）

• 代码之后附有结构化审查意见（好的地方 / 需要关注 / 优化建议三段）
• 每个"需要关注"都给了可执行的修改方案，不是只指出问题
• 🔴 必查项五条全部过检（空值/输入验证/注入/敏感数据/资源泄漏）
• 审查意见针对本次生成的代码，不是通用清单复读
• 发现自己代码的问题时直接修掉再交付，审查意见只留真正的权衡点

不做什么

• 不替代正式 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])。

引用资源

• references/detailed-checklist.md — 语言特定检查清单全集，按当前项目语言取用

evals/routing-evals.json — 触发边界回归用例，改 description 后用仓库根 scripts/run_routing_evals.py 校验。