背景
过去笔者曾写过文章《AI辅助需求规格描述评审》，我们今天简单测试需求拆分任务，为什么需要markdown格式，因为MD格式1）容易通过GIT版本控制管理 2）LLM最擅长处理是MD文档 3）需求描述MD是代码逻辑生成基础。
初始化
我们把需求文档放入到文件夹后
/INIT
生成
原始需求文档，比较粗糙，来自互联网仅用于测试
需求分析
claude主动询问我，我告诉他需求文档名
他生成了，实施路线图文档IMPLEMENTATION_ROADMAP_CN.md与需求分析文档REQUIREMENTS_ANALYSIS_CN.md
需求分析文档REQUIREMENTS_ANALYSIS_CN.md
实施路线图文档
需求拆分与评审
请按已定义的需求描述卡片模板进行需求评审：FR-UI-010: 每日考勤记录（时间、地点、进出方向，评审内容来自文件原始需求文档《智慧校园安防服务平台.docx》
{需求编号：包含"采集时刻 + 采集者"信息
需求类型：（在进行评审时填写）功能需求、非功能需求......
来源（Who）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验
场景（Where、When）：产生该需求的用户活动特定的时间、地理、环境
描述（What）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）：
-
用量化的语言
-
无法量化寻找标竿
需求重要性权重（How much）：
满足后（1一般~5非常高兴）
未实现（1略感遗憾~5非常懊恼）
需求生命特征（When）：
-
需求的紧急度
-
时间持续性
需求关联（Which）：
-
人：需求关联的用户影响人物
-
事：需求关联的用户业务与关联需求编号
-
物：需求关联的客户系统、设备；需求关联的公司产品及版本
参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节
竞争者对比：（按照1分差~10分好进行评估）
-
竞争者对该需求的满足方式
-
用户、客户对竞争者及公司在该需求的评价
说明：需求特征的描述，通常有如下几个维度：重要性（细分为"满足后、未实现"，或者说"基本、扩展、增值"，参见KANO模型）、紧急度、持续时间（生命周期）。实用主义的考虑，可以综合抽象为一个指标：商业价值（或者叫商业优先级）。然后除以开发量就得到了"性价比"，我们先做性价比高的需求。}
继续，变为英文
需求评审记录文件
Review_Summary
进一步需求拆分
其他参数参考
需求评审场景
top_p和temperature
-
低风险、高确定性场景：如果业务对输出的准确性和确定性要求极高，比如法律条文解释、财务报告生成、医疗诊断辅助等，建议将 top_p 设置为较低的值，如0.1 - 0.4。这样模型倾向于选择概率最高的词，输出结果较为稳定，减少生成不合理或错误内容的可能性。
-
严格规范场景：在对输出格式、内容准确性有严格规范的场景，如代码生成、技术文档编写等，应将 temperature 设置为较低的值，如0.1 - 0.3。较低的温度使得模型更倾向于选择常见且合理的词汇，生成的内容更加符合预期和规范。
需求拆分
这次我们在init后，直接让他拆需求文档，提示词如下：
请将我提供{需求文档-智慧校园安防服务平台}文档，按已定义的需求描述卡片模板进行拆分生成为独立markdown格式的文件(.md)，输出使用中文语言
{需求编号：包含"采集时刻 + 采集者"信息
需求类型：（在进行评审时填写）功能需求、非功能需求......
来源（Who）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验
场景（Where、When）：产生该需求的用户活动特定的时间、地理、环境
描述（What）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）：
-
用量化的语言
-
无法量化寻找标竿
需求重要性权重（How much）：
满足后（1一般~5非常高兴）
未实现（1略感遗憾~5非常懊恼）
需求生命特征（When）：
-
需求的紧急度
-
时间持续性
需求关联（Which）：
-
人：需求关联的用户影响人物
-
事：需求关联的用户业务与关联需求编号
-
物：需求关联的客户系统、设备；需求关联的公司产品及版本
参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节
竞争者对比：（按照1分差~10分好进行评估）
-
竞争者对该需求的满足方式
-
用户、客户对竞争者及公司在该需求的评价
说明：需求特征的描述，通常有如下几个维度：重要性（细分为"满足后、未实现"，或者说"基本、扩展、增值"，参见KANO模型）、紧急度、持续时间（生命周期）。实用主义的考虑，可以综合抽象为一个指标：商业价值（或者叫商业优先级）。然后除以开发量就得到了"性价比"，我们先做性价比高的需求。}
输出后目录结构
│ 需求文档-智慧校园安防服务平台.docx
│ 需求文档-智慧校园安防服务平台.txt
│
├─.codebuddy
│ └─rules
└─requirements
│ raw_content.txt
│
├─split
│ 20250908_claude_attendance_calendar_requirement.md
│ 20250908_claude_attendance_management_requirement.md
│ 20250908_claude_attendance_notification_requirement.md
│ 20250908_claude_attendance_video_requirement.md
│ 20250908_claude_dashboard_requirement.md
│ 20250908_claude_identity_switch_requirement.md
│ 20250908_claude_login_requirement.md
│ 20250908_claude_payment_requirement.md
│ 20250908_claude_student_binding_requirement.md
│
└─templates
requirement_template.md
实际输出的目录，我们查看其他支付场景需求卡片如下
拆分需求token消耗
Total cost: $2.73 (costs may be inaccurate due to usage of unknown models)
Total duration (API): 6m 44.6s
Total duration (wall): 15m 37.2s
Total code changes: 1395 lines added, 0 lines removed
Usage by model:
longcat-flash-chat: 831.0k input, 15.6k output, 0 cache read, 0 cache write
小结
我们今天使用ClaudeCode+longcat-flash-chat实现简单需求文档分析与拆分，希望对大家有启发。其他实现方式还有基于 Dify 实现将需求文档拆分为"业务场景需求卡片"的 Markdown 格式文档，是一个典型的自然语言处理（NLP）任务，核心是利用 Dify 的 工作流（Workflow） 和 提示词工程（Prompt Engineering） 能力，通过大语言模型（LLM）自动解析、拆分和结构化需求内容。Dify 作为开源 LLM 应用开发平台，提供了可视化工作流设计、提示词优化和集成能力。