一个需求从想法做到上线，中间该做哪几步
需求模糊、时间又紧的时候，最容易犯的错是直接让 AI 写代码。这套流程先把不确定性留在前面的步骤里，再用测试和配置检查收口。
怎么做
把原始需求变成实体和状态机
把需求原文整段贴进「把需求转成数据模型」，先不要让它写代码。要求输出实体清单、关系基数、核心对象的状态机，以及价格、权限、软删除这类半年内一定会改的字段，最后列出三处必须问产品的地方。这几处没确认，后面的拆分都建在猜测上。
按接口契约拆成能并行的任务
把上一步的实体和状态机连同团队人数一起给「把需求拆成可并行的任务」。让它先标出不可并行的顺序约束（数据模型、接口契约、迁移），再把其余工作按一个人一周能独立交付来切，写清输入、输出和验收方式，并指出最容易冲突的共享文件。
在提测前补上最可能漏的用例
代码能跑通后，把实现和现有测试一起贴进「给测试用例挑漏」。重点看它列出的未覆盖分支，按线上影响排出前五个该补的用例，每个写清输入和预期；重复用例和断言实现细节的测试可以删掉，它们只增加维护成本。
上线前算清这次改动会伤到谁
把 diff、调用方清单和流量规模交给「估算一次改动的风险面」。让它按影响人数和恢复难度排出风险最高的三处，指出这次改动依赖但没验证的假设，并给一份上线顺序与回退方案，包含判断回退的指标阈值。
逐项挑配置的刺，再点发布
最后把配置文件和不同环境的环境变量交给「上线前挑配置的刺」。让它写出所有靠默认值工作的项、只在线上出问题的路径，并生成一份按风险排序的检查清单。清单和第 4 步的回退方案一起存档，下次发布直接复用。
用到的提示词
常见问题
AI 写的代码能直接上线吗
不能。它看不到你的部署环境、真实数据规模和历史包袱，这三样往往正是上线后出问题的来源。这套流程的第 4、5 步就是补这部分：算清影响面、逐项核对配置，再准备回退。代码本身仍然要有人读过、跑过测试。
需求还只有一句话，能直接让 AI 拆任务吗
可以拆，但拆出来的是基于猜测的任务。先让它列出「需求里没写清楚、必须先问产品的地方」，把那几个问题问完再拆，任务的输入和验收才站得住。
这套流程小改动也要全走一遍吗
不用。改文案或加日志可以只做第 3 步和第 5 步；涉及数据模型、权限、外部调用方的改动，五步都值得走。判断标准是出错后能不能快速回退，而不是改动行数。