AI 需求怎么分级？一套风险分轨方法，避免小改也走重流程
AI 进入研发流程后，团队很容易走向两个极端：要么“让它直接改”，要么给所有需求都套上完整评审、测试和发布流程。前者不稳，后者又会让小改动失去效率。
更合理的办法是给需求分轨：用失败成本决定控制成本，而不是只看工作量或改动行数。
四条常用轨道
| 快车道 | 文案、样式、低风险配置 | 明确范围、基础验证 |
| 标准轨道 | 常规功能、小范围接口调整 | 方案、代码评审、测试说明 |
| 重型轨道 | 资金、权限、状态机、跨系统数据 | 完整方案、独立审查、回滚预案 |
| 技术债轨道 | 重构、依赖升级、性能治理 | 基线、迁移策略、分阶段验证 |
分轨不是给需求贴一个漂亮标签，而是提前决定：谁能做决策、需要哪些证据、失败时怎么收敛。
不能只按工时判断
“只改一行”也可能是高风险。比如把金额保留两位小数，看似很小，却可能影响结算、对账、发票和历史数据；给订单状态机新增一个状态，也可能影响消息、报表、权限和下游消费。
因此，分轨应优先看这几个信号：
- 是否涉及资金、权限、隐私、合规或不可逆数据操作。
- 是否改变核心状态、接口契约、数据结构或系统边界。
- 是否跨仓库、跨团队、跨端协同。
- 是否缺少可验证的业务规则。
只要其中一项不确定，就应该升一档处理。AI 的第一轮工作也应是“分诊”：列出风险、影响范围和待确认项，而不是立刻给出实现方案。
建一张快车道禁入清单
建议把以下事项直接排除在快车道外：删除或迁移数据、支付和计费、身份与权限、库存扣减、状态机变更、对外协议变更、需要跨端同时上线的改动。
这张清单的价值在于：不必每次重新争论“这个需求到底算不算小”，让流程有统一底线。
三个容易分错的案例
案例 1：修改一条页面提示
如果只改展示文案、没有引入新的业务含义，通常可以走快车道：明确页面和文案来源，完成页面验证与基本回归即可。但若文案涉及价格、法律承诺或用户权限，就应升级为标准轨道，因为“文字”也可能改变业务表达。
案例 2：调整金额精度
这类需求看似只改一个格式化函数，实际往往涉及计算、存储、展示、导出和对账。只要金额参与结算，就应至少进入重型轨道：先确定精度规则、历史数据策略、边界值和回滚方案，再让 AI 生成实现与测试用例。
案例 3：给状态机新增状态
状态机改动的风险不在代码量，而在“所有消费者是否都认识这个状态”。除服务端外，还要检查前端展示、消息订阅、任务重试、报表、权限判断和历史数据处理。任何一个下游缺失，都可能造成卡单或数据不一致，因此应默认升级审视。
让分轨结论可被下游使用
分轨不能停在一句“这是标准需求”。它应该成为下游的执行合同：标准轨道需要哪些材料、谁来评审、测试最低覆盖哪些场景、哪些信号必须升级。建议在需求单中固定字段：
轨道：快车道 / 标准 / 重型 / 技术债
判定证据：
必须完成的门禁：
升级信号：
最终批准人：
升级信号尤其重要。例如发现跨仓库影响、数据迁移、无法确认的规则、上线窗口受限时，即使原本走快车道也要自动升档。相反，经过证据确认后，如果重型需求被拆成多个独立低风险步骤，也可以让每个步骤按合适的轨道执行。
先用人工判断，后谈自动化
第一版分轨表不需要复杂评分模型。让产品、技术和质量角色基于禁入项与风险信号达成一致，先运行两到三个迭代；收集哪些需求被误分、哪些门禁没有价值，再逐步调整。
过早让 AI 或平台自动给需求打分，容易把团队尚未说清楚的规则固化为错误流程。好的分轨体系不是“分得多精细”，而是在每次风险出现前，让团队知道该多做哪一步验证。
流程分级之外，模型调用也应有边界
不同风险轨道不仅流程不同，模型调用的成本、权限和留痕也应该可见。例如个人试验、日常开发和高风险发布前核查，可以使用不同的 Key 或分组，便于复盘请求量、失败原因和成本。
云舒 API 可作为统一的 OpenAI 兼容调用入口，集中管理 Key、分组、额度和调用记录。它不会自动替团队判断风险或路由模型，但能让“分轨后的调用边界”更容易执行和回查。具体可用模型与权限，以后台实际配置为准。
一个可直接复用的分诊模板
在 AI 输出方案前，要求它先给出：
需求目标：
影响模块：
风险主题：
建议轨道：
进入下一轨的原因：
待确认事实：
需要的交接物与验证：
这比一句“帮我实现一下”多花不了几分钟，却能显著减少范围遗漏。流程并不是越重越好；正确的目标是让低风险任务足够快，让高风险任务在错误扩散前被拦住。
云舒实践：把不同风险任务的调用留痕分开
需求分轨确定的是研发控制强度，模型调用也应有可管理的边界。一个可行的起步方式是：个人探索、日常开发、自动化任务和高风险需求评审使用不同 API Key 或分组；所有客户端仍通过云舒 API 的 OpenAI 兼容接口接入。
这样做不代表云舒会自动替团队给需求分级或路由模型。分轨判断仍然来自业务规则和人工授权；云舒提供的是统一的模型调用入口，让团队可以在后台查看不同 Key 的模型调用、额度和失败记录，为成本复盘与异常排查提供事实依据。
建议先按下面顺序实施：
不要把真实 Key 放进需求单、截图或仓库。模型名、额度策略和价格以云舒后台实际配置为准。
关注与下篇预告
本文是《让 AI 负责项目：研发篇》系列第 3 篇，共 9 篇。关注「小陈日常笔记」，下一篇开始进入多 Agent 协作的责任设计。
下一篇：《别让一个 AI 既当产品又当架构师：6 个 Agent 角色怎么分工》，讲清提案、执行和审查为什么必须分离。
