产品经理的长需求交给 Agent，怎样拆成可独立讨论的用户故事

长需求拆成用户故事，首先要让每一片对应一个可讨论的业务结果。Agent可以把PRD中的角色、触发、操作和结果关联起来，再提出切分候选。它的交付应是产品经理能调整的故事集合，而不是将所有句子改成“作为用户，我希望”。本文设计一个处理企业软件需求的助手，样例均为虚构材料。

用一次完整业务来识别切分位置

例如预约功能包含查空位、提交预约、获得确认。三步构成一次价值流，但不意味着必须合为一张巨型卡。已有查询能力时，新增故事可以只承诺“用户对选定时段提交预约并看到结果”；没有查询能力时，卡片则要明确依赖哪个已有入口。决定故事大小的依据是业务结果能否独立说明，以及前置能力是否真实存在。

先给原文段落编号，再为候选填角色、目标、起始条件、结束观察和未包含内容。PRD里出现管理员，不能默认和申请人共用同一个目标。申请人希望知道自己是否约到，管理员可能希望看到需要处理的场次；它们共享场地数据，却有不同的完成观察。

技术分工另放一层

“建表、写后端、做页面”可以是研发任务，但每项单独交给业务人员时，往往无法回答它带来了什么变化。故事卡应连接这些任务，而不被它们替代。Agent遇到只有技术层拆分的材料，应保留原分工，再提出业务切片建议，让产品和研发一起确认两者的对应。

官方机制说明1：工作项表达需求，Epic/Feature聚合场景；本文的切分与缺口检查是拟设计方法。

这里借用工作项层级表达需求，不假定平台会自动识别价值边界。若现成看板已经可以维护故事，定制部分可以只做原文定位、切片建议和依赖提示，没必要另造一套看板。需要接入时再确认字段及引用方式。

三种切分输入怎样处理

合成输入1。 PRD写预约人查询空位、预约并查看确认，拆分建议仅为前端/后端/数据库

预期处置：指出是技术层切分；提出有业务结果的故事候选，保留预约依赖

合成输入2。 PRD同时面向申请人和场地管理员，各有不同目标

预期处置：分成两种角色结果，保留共同场地对象

合成输入3。 一句需求要求完整移动端离线巡检，却没有现有离线边界

预期处置：列为仍需澄清的较大故事，不虚构可独立交付切片

第一条的关键不是换一组更好听的标题，而是能给每个候选写出可观察结果。第二条应允许两张故事连接同一场地对象；把共有对象重复创建成两套需求，会带来后续规格冲突。第三条说明有些大故事还缺信息，保留“大故事待澄清”比强行切出十张空卡更有用。

反向拼回去检查遗漏

评审时从每个候选回看原文，确认角色、特殊条件和排除范围都能找到去向。再从每个原文段落查它落到哪张卡，未映射内容必须解释为背景、重复、待定或明确不在本期，不能悄悄丢弃。若两张卡都声称负责最终确认，要核对它们是不同场景，还是重复承诺同一结果。

故事集合还应显示依赖的性质。共享术语不等于前后阻塞；必须先取得场地时段才可预约，则属于需要实现或复用的前置能力。把两类关系分开，产品经理才不会因为同用一张表就把所有故事重新合成一个整体。

最终用一条新的PRD段落做人工复核：另一位产品经理能否按这些故事解释用户最后获得什么、哪些尚未决定、需要哪项已有能力。数量不是验收目标，可讨论且可追溯的切片才是。

故事卡怎样交给研发继续分工

每张候选卡还可分成业务承诺区和实施备注区。前者写用户得到什么，后者记录查询接口、数据准备或页面组件等依赖。研发任务可以继续细分，但应能回指同一业务承诺，避免后来一项技术任务完成就把故事整体勾成完成。

预约案例可保留“查询已有结果”作为前置引用，而不每张卡都重新描述查场地。管理员故事则突出处理对象和最后确认，不复制申请人操作。离线巡检因范围尚缺，先输出待澄清问题：哪些对象允许本地保留，联网后谁确认。问题得到回答后再重新切片，不把占位卡的数量当成需求分析产能。这些记录均沿用附件三条输入，不声称对应真实研发看板。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。

还没写清任务边界时，先用相近旧文；故事切片后，可分别检查审批系统需求写了会签和或签，Agent 怎样整理人数变化与完成条件的参与集合和需求里写着快速和方便，Agent 怎样生成可评审的验收示例的行为结果。带一段PRD与候选卡到定制咨询，讨论哪些关系值得接入看板，相关任务收在文档与数据处理专题。