01
需求分档：什么能走 vibecoding
先划红线，再谈提效。判据不是「看起来简单」，而是五个维度同时成立。
走 vibecoding（下列条件全部满足）
| 维度 | 条件 |
|---|---|
| 系统边界 | 只改内部后台或运营工具，不碰 C 端、交易、账号、资金 |
| 数据 | 不改表结构、不做数据迁移；写操作只落在已有表的已有字段 |
| 依赖 | 改动落在一个服务、一个页面内，不需要跨系统协调排期 |
| 可逆性 | 出错能回滚，且不产生不可逆动作（不发消息、不扣款、不改用户状态） |
| 验收 | 验收标准能一句话说清，产品自己能在测试环境点出来 |
典型形态：
- 列表加筛选项 / 展示字段
- 后台文案与选项调整
- 报表加维度
- 导出加列
- 运营配置项开关
必须走 scrum
- 涉及 C 端、交易，或外呼 / 企微触达等对外发出即不可逆的动作
- 需要改表结构或数据迁移
- 涉及权限、鉴权逻辑
- 跨 2 个以上系统，需要多方排期
- 有性能 / 并发要求，或涉及定时任务、大批量数据处理
- 需求本身没想清楚 —— 这类卡在决策而非编码，只有评审会能拍清
灰区：产品写，研发必须 CR
字段增删、报表新增指标、已有逻辑的条件分支调整。产品可以动手，但 CR 不能省。
02
SOP：对比原流程
八步逐一对照，说明每步是保留、降级还是取消。
| 原流程 | 新流程 | 说明 |
|---|---|---|
| 业务调研 | 保留（周会现场） | 业务提需时当场判分档，够简单的直接进快车道 |
| 产出 PRD | 降级为一句话验收标准 | 不写 PRD，写「改完之后 XX 页面能看到 XX」 |
| 需求评审 | 取消，改为口头确认分档 | 研发只判「能不能走 vibecoding」，不评方案 |
| 研发开发 | 产品自建分支 vibecoding | 产品在测试环境自测通过为止 |
| QA 测试 | 阶段性保留（见 04） | 前期照测，后期看自动化覆盖情况收缩 |
| 产品验收 | 合并进自测 | 自己写自己验，不再单列一步 |
| 需求上线 | 研发 CR 通过后合并发布 | CR 是唯一强制关卡 |
| 业务验收 | 当天给业务看 | 上线当天完成，不跨天 |
当天时间箱
上午周会 / 对接确认验收标准与分档 → 产品动手 → 自测 → 提 PR → 研发 CR → 合并上线 → 业务当天看
关键约束
CR 不通过就不上线，当天上不了就退回 scrum，不留半成品。
03
研发侧准备与培训
权限、环境、工具三件事到位，培训文档在陪跑中沉淀。
权限
仓库读写权限开到指定的后台 / 运营工具仓库，不给主干直推权限；一律走 PR，至少一名研发 approve 才能合；生产环境发布权限不下放，由研发点发布。
环境
研发预置一键启动的开发环境（脚本或容器），产品不自己装依赖链；提供测试环境账号 + 一份可用测试数据；明确写清「跑起来」的验证命令，产品能自查环境是否正常。
工具与约束
AI coding 工具 + 仓库级规则文件：写清可改目录、禁改目录、代码风格、提交前必须跑的命令。规则文件里明确列出边界清单（哪些文件绝对不能碰），把红线交给工具而不是靠记性。
沉淀的培训文档清单
- 环境从零到跑起来（含常见报错处理）
- 分支、提交、PR 三件事怎么做
- 怎么把需求描述给 AI —— 含验收标准写法、上下文该给什么
- 自测清单：改完之后必须点的几件事
- 出错怎么回滚，什么情况立刻叫研发
- 边界清单：绝对不能改的范围
文档由带过前几个需求的研发在陪跑过程中写，不预先闭门造。
04
推进节奏（建议）
由窄到宽三个阶段。减人要有前置条件，不靠信任。
阶段一 · 前 4–6 周
跑通流程，不追求提效数字
只做单人单页面、独立无依赖的小需求。研发全程 cowork（结对），QA 照常测。目标是跑通流程和沉淀培训文档。
阶段二
产品独立做，研发只做 CR
QA 抽测。开始统计一次 CR 通过率、当天上线率。需求复杂度按 01 的判据往上放，红线不越。
阶段三：收缩研发与 QA 介入
| 想减掉的 | 前置条件 |
|---|---|
| QA 逐个测试 | 该模块回归用例已自动化覆盖，且集成测试在 PR 上自动跑 |
| 研发人工 CR | 自动化 CR（静态检查 + 规则校验）接入，且连续 N 个需求人工 CR 无阻塞性问题 |
底线
在自动化兜底建成之前，CR 和 QA 都不减。