授权与合规声明本文为技术实操分享全部示例均运行于作者自建的隔离环境文中涉及的第三方服务均使用其官方公开接口与公开文档。内容仅代表个人实践经验不构成任何商业或法律建议涉及平台规则以官方最新发布为准。一、为什么模糊需求是开发的第一道坎「做个智能客服」「搞个数据看板」「加个推荐能力」——这类一句话需求几乎每个团队都接过。问题在于它同时缺少范围、缺少验收口径、也缺少拆分路径直接交给开发往往会引发三轮以上的返工。传统做法是由资深工程师或产品经理人工展开成任务清单耗时且高度依赖个人经验。大模型出现后我们可以把它定位成一个初稿生成器给它一个模糊需求它能在几秒内产出一份结构化的分层任务草稿再由人来校验和兜底。需要明确的是LLM 的拆解结果不能直接当交付物。它的价值在于把「从 0 到 1 展开」这一步自动化把人的精力省下来做「校验与决策」。二、结构化 Prompt 的四个要素让 LLM 稳定产出可校验的拆解关键不在模型本身而在 Prompt 的结构。我习惯用四要素约束输出角色Role明确它扮演「资深技术负责人 / 需求分析师」限定专业语境。输入Input给原始需求、业务背景、已知约束技术栈、工期、合规要求。输出 schemaOutput schema强制它按固定字段返回而不是自由发挥写一段散文。约束Constraints限定层级、粒度、验收标准写法、禁止项。这四要素合起来相当于把「你帮我拆一下需求」这种低效提问升级成「按指定结构产出可机器解析的结果」。三、最小可用结构化 Prompt 模板与输出约定下面是一份可直接复用的模板。把{{...}}替换为真实内容即可。# 角色 你是一名有 8 年经验的资深技术负责人擅长把模糊业务需求拆解为可执行的研发任务。 # 输入 原始需求{{一句话需求}} 业务背景{{背景说明}} 已知约束{{技术栈 / 工期 / 合规要求}} # 输出 schema 请严格按下方 JSON 结构返回不要输出额外解释文字。 # 约束 1. 任务分为四层epic史诗→ feature功能→ task任务→ acceptance验收标准。 2. 每个 task 必须能在 1–3 人日内估点和交付。 3. 每个 task 必须配至少一条可验证的 acceptance。 4. 不要遗漏非功能性需求性能、安全、监控。 5. 若信息不足在 notes 字段诚实标注「待确认」不要编造。与之配套我约定一份输出 schema让结果既能被人读也能被脚本解析{requirement:string,epics:[{id:E1,title:string,features:[{id:story-1,title:string,tasks:[{id:T1,title:string,estimate_days:number,acceptance:[string],type:functional | non_functional}]}]}],notes:[string]}⚠️代码待验证# 调用示例把模板与需求拼接后发给模型并强制 JSON 输出importos,requests,json promptopen(decompose_prompt.txt,encodingutf-8).read()resprequests.post(https://api.openai.com/v1/chat/completions,headers{Authorization:fBearer{os.environ[API_KEY]}},json{model:gpt-4o-mini,messages:[{role:user,content:prompt}],response_format:{type:json_object},},)datajson.loads(resp.json()[choices][0][message][content])print(data[epics][0][features][0][tasks][0][title])这份资料是什么需求拆解的结构化 Prompt 模板与分层清单速查卡和本章讲的四要素、JSON schema 直接相关放在资料包里扫码即可获取四、分层任务清单史诗 / 功能 / 任务 / 验收标准拆解的层级不是越多越好四层足够覆盖绝大多数中小项目。各层的职责与粒度如下层级英文职责典型粒度谁来拍板史诗Epic对齐业务目标框定范围数周到数月技术负责人 / 业务方功能Feature一个可Demo的用户价值点数天到一周产品经理任务Task可估点、可指派的具体工作1–3 人日开发组长验收标准Acceptance可验证的完成定义一条可测断言开发 QA以「做个智能客服」为例epic 是「智能客服系统」feature 可能是「意图识别」「知识库检索」「人工兜底」task 落到「搭建意图分类接口」「接入向量检索」这类可估点的粒度每个 task 配一条 acceptance例如「意图识别在测试集上返回 top1 标签字段包含 confidence」。非功能性需求性能、安全、监控容易被 LLM 漏掉需要在约束里显式要求并在验收标准里单独留位置。五、怎么校验拆解质量检查清单LLM 产出草稿后不要直接进排期。用下面这份清单逐条过任何一项不达标就打回重拆或人工补。检查项判定标准不达标的表现层级完整四层齐全且父子关系正确只有功能没有任务或任务直接挂在史诗下粒度可估每个 task 在 1–3 人日内可交付出现「搭建整个后台」这类大块验收可验每条 acceptance 可测、有断言写「体验良好」「尽快完成」非功能覆盖性能/安全/监控有对应 task完全没提限流、日志、鉴权范围收敛与原始需求一一对应无臆造自行加入未提及的付费模块诚实标注信息不足处写 notes 待确认编造接口名、编造工期这份清单本身也能沉淀成团队规范配合下一节的人审流程使用。六、人审兜底与渐进细化LLM 的拆解是「初稿」人审是把关环节。建议走一个轻量闭环技术负责人过结构层级对不对、范围有没有跑偏。开发组长过粒度task 是否真的可估点能否拆分到 1–3 人日。QA 过验收acceptance 是否可测、有无遗漏边界。业务方过价值每个 feature 是否对齐原始目标。回填 notes把待确认项补齐或标红再进排期。渐进细化progressive elaboration的核心原则是先粗后细按需展开。不要一上来就逼 LLM 拆到最底层——先要 epic 和 feature 对齐方向方向确认后再对单个 feature 二次拆解到 task。这样既能控住上下文长度也能让每一层都有人审兜底。粒度判断可参考下表现象处理task 估点 3 人日继续拆直到可独立估点task 无验收标准退回补 acceptance禁止直接排期task 跨多个 feature拆成多个 task各自归属notes 出现待确认先补信息未补前不进排期这份资料是什么人审兜底检查单与渐进细化流程图和本章的闭环、粒度判断表直接对应放在资料包里扫码即可获取七、小结LLM 拆解是初稿生成器把模糊需求喂给大模型靠「角色 输入 输出 schema 约束」四要素确实能快速产出分层任务草稿。但它始终是初稿生成器必须配人工校验用质量检查清单过一遍用人审闭环兜底用渐进细化控制粒度。落到实践上建议把本文的模板、schema、检查清单都固化成团队资产让 LLM 负责「展开」让人负责「拍板」。这样需求拆解这一步既能提速也不丢质量。附表 A本文引用事实与出处对照表关键事实 / 数据出处出现位置大模型可按指定 JSON schema 返回结构化结果response_formatjson_objectOpenAI 官方 API 文档公开可检索第三章 调用示例任务分解常用 Epic/Feature/Task/Acceptance 四层结构通用敏捷研发实践共识公开可检索第四章 分层表渐进细化progressive elaboration为迭代式需求展开方法PMBOK / 通用项目管理共识公开可检索第六章 人审兜底非功能性需求性能/安全/监控易被遗漏需显式约束通用软件工程共识公开可检索第四章、第五章文中示例代码运行环境为作者自建隔离环境本文作者实践标注「代码待验证」第三章 调用示例附表 B术语速查表术语含义Epic史诗对齐业务目标的高层范围单元Feature功能一个可演示的用户价值点Task任务可估点、可指派的具体研发工作Acceptance验收标准定义「完成」的可验证断言渐进细化先粗后细、按需逐层展开需求的方法初稿生成器本文对 LLM 在需求拆解中定位的比喻写在最后这篇用到的资料写这篇文章时我把日常做需求拆解的 Prompt 模板、分层清单和质量检查单整理了出来顺手也整理了几份配套的东西全套 AGI 大模型学习路线从入门到实战的系统性路线先建立全局认知Claude Skills 全指南把可复用能力封装成 skill 的实操参考LangGraphMCP 智能体实战视频目录智能体编排与工具调用的跟练素材资料是我自己整理的放在下面这个码上扫码即可获取资料较多建议先看「全套 AGI 大模型学习路线」再挑一个实战项目跟练。