把需求拆成范围清楚的开发任务

这个场景能帮你做什么

“实现这个需求”不足以约束一次开发。WorkBuddy 可以结合产品要求和工程现状，拆出修改对象、允许范围、依赖与验收，使任务能独立执行和检查。

开始前需要准备什么

提供已确认需求、代码或模块说明、工程规则、接口约定及本轮范围。列出用户已有修改、禁止改动区域、验收样例和运行环境；需求为何做与在哪里改分别说明。

具体怎么做

第一步：确认需求已清楚

核对目标、输入输出、规则、异常与完成标准。必要信息缺失时先列问题，不把不确定需求直接拆成看似明确的代码任务。

第二步：对应工程对象

将每项需求关联模块、接口、数据和调用方，列可新增、可修改和禁止修改范围。一个任务触及共享逻辑时明确下游影响。

第三步：划分工作与依赖

按可交付结果拆任务，写前置条件、负责人角色和验证办法。避免多个任务同时修改同一核心对象，必要时调整顺序或明确接口。

第四步：形成任务书

每项保留需求编号、修改范围、验收、异常与待确认事项。对尚不能估算的工作写先调查或验证，不编造精确工期。

可以直接交给 WorkBuddy 的完整要求

依据附件需求和工程事实拆开发任务。每项写目标、需求关联、具体模块/接口、允许新增修改范围、禁止范围、依赖、输出与验收。
保留用户已有修改，发现冲突先列出。需求不清或调用关系未知时安排澄清/调查，不补造工程事实。
检查任务是否重叠、是否漏下游调用和异常验证。输出任务书，不直接开始修改代码。

完成后会得到什么

一组范围明确的开发任务，执行者能知道改什么、不能改什么，以及怎样证明完成。

结果应该怎么检查

需求能否逐项对应到任务，任务能否对应到验收；检查共享文件冲突和未分配的联调、回归工作。不要只统计任务数。

遇到这些情况怎么处理

现有代码与需求假设不符时先反馈。接口未确定时先约定再分工。一个任务太宽难验证时按独立结果拆分，避免仅按文件数量拆。

哪些必须人工决定

产品确认范围，研发负责人确认分工、工程约束和验收。AI 起草任务，不自行扩需求或承诺排期。