代码审查与发布经理

开篇速查：推荐模型与工具

推荐模型：复杂影响分析用 GPT-5.6 Sol 或 Claude Opus 5；日常高频审查用 Kimi K2.7 Code。
理由：强模型适合跨模块风险判断；合并、发布和扩流必须受测试、扫描、灰度指标与人工授权约束。
推荐产品：Codex、Claude Code、Cursor（本岗位涉及复杂开发、仓库或运行环境）。 常用工具：GitHub/GitLab PR、CI 门禁、变更日志、灰度发布、Feature Flag 与回滚监控。 核对日期：2026-08-04；上线前再查厂商官方模型列表并用内部评测集验证。

历史依据：从 8,276 条用户消息中命中 570 条，精确去重后 281 条。以下工作方式优先针对这些历史任务和返工问题。

1. 历史记录暴露的问题

• 明确验收标准：20/281（7%）。
• 明确要求验证：73/281（26%）。
• 提供失败/复现证据：29/281（10%）。
• 出现“功能不可用/报错”类返工：20 条。
• 出现“再检查/再测试”类返工：7 条。
• 出现“继续/不要停”但退出条件不清：17 条。

因此本岗位的模板会把验证、证据和退出条件写进首轮提示，而不是等失败后补充。

2. 什么时候使用

• 审查当前改动和跨模块影响
• 发布前统一需求、测试、安全和运维门禁
• 大型任务阶段交接
• 避免‘做完了’但没有证据

3. 责任边界

• 聚焦可触发的错误和发布风险
• 不把个人风格偏好当缺陷
• 不替实现者静默修复所有问题
• 不在门禁失败时强行发布

4. 开始前必须提供

• 变更目标、diff和文件范围
• 业务不变量和风险
• 测试、扫描和构建结果
• 迁移、配置、监控和回滚
• 发布窗口和负责人

缺少信息时，先从仓库、配置、运行状态和现有资料中查证。只有会改变业务方向、造成生产影响或无法安全推断的内容才询问。

5. 完整可复制提示词

你是代码审查员与发布经理。审查【PR/提交/工作树】并决定是否满足发布门。

变更目标：【内容】
允许范围：【内容】
业务不变量：【内容】
发布环境和窗口：【内容】

审查正确性、数据、并发、权限、安全、兼容、性能、可观测性、迁移和测试。每项问题必须给严重度、位置、触发条件、用户/业务影响、证据和修复方向；不报告纯风格偏好。

逐项核对：需求验收、构建、测试、扫描、配置、迁移、备份、监控、告警、回滚、负责人和观察窗口。门禁失败则停止发布。

发布后执行核心用户旅程、日志/指标、任务状态和数据库检查。最终输出可发布/不可发布、阻塞项、残余风险和回滚触发条件。

6. 推荐执行流程

1. 确认变更与需求范围一致
2. 审查正确性、数据、权限、兼容和并发
3. 核实测试证据而非只看通过文字
4. 检查迁移、配置、监控和回滚
5. 冻结版本并记录哈希/镜像
6. 分阶段发布并观察
7. 完成发布后用户旅程和数据检查

每一步都要留下可复核产物：文件、命令、截图、请求、任务ID、数据库记录、指标或决策记录。

7. 标准交付物

• 按严重度的审查问题
• 需求到证据追踪
• 发布门禁和签字状态
• 部署/回滚/观察计划
• 发布后验证和复盘

8. 历史中常见失败写法

• 任务长期‘继续’但没有阶段完成定义
• 改动文件超出范围且无说明
• 测试/构建未跑仍声称可发布
• 数据库迁移没有回滚或前滚
• 发布后只看服务启动，不看用户流程
• 遗留问题未分严重度和负责人

修正提示词

当前结果未满足验收。不要整体重做，先按证据定位差距。

原目标：【目标】
原验收：【可观察标准】
实际结果：【截图/日志/请求/任务ID/数据库记录】
差距：【逐条列出】
必须保持：【已正确部分和接口不变量】

请先复现并说明根因，再实施最小修正。修正后重复原验证，并给出修改前后证据。未通过的项继续保留为失败，不要用“基本完成”代替。

9. 完成检查清单

• 目标、范围和不做项没有漂移。
• 关键假设已用代码、运行或数据验证。
• 成功、失败、空、重复、超时和权限路径已处理。
• 交付物可由另一人独立打开或运行。
• 验收命令/路径已实际执行并保留证据。
• 未完成项、风险和数据限制被明确列出。
• 下游岗位得到接口、不变量、文件和验证入口。

10. 交接模板

岗位：代码审查与发布经理
已完成：【内容】
证据：【文件、命令、截图、日志、任务ID、数据库记录或指标】
接口与不变量：【下游必须遵守】
配置/迁移影响：【内容】
未完成与风险：【内容、严重度、负责人】
下一岗位：【岗位】
下一步输入：【精确文件、环境、账号或任务】
禁止假设：【仍未知内容】

11. 实用组合技巧

• diff自动路由审查岗位：前端改动交给视觉/无障碍审查，迁移交给数据库，权限交给安全，部署交给SRE，最后汇总发布风险。
• 历史缺陷自动影响分析：根据修改文件和依赖图，Agent 找出过去同模块缺陷与应运行的回归测试。
• 发布说明自动生成：从提交、配置、迁移和功能开关生成用户变化、运维影响、监控项和回滚条件。
• 灰度指标自动守门：发布 Agent 对比新旧版本错误率、延迟和业务完成率，达到阈值才扩大流量。
• 未完成项自动建账：把残余风险、临时开关和后续修复生成负责人、截止时间和验证标准，避免发布后遗忘。