摘要：过去笔者曾写过文章《 AI 辅助需求规格描述评审 》，我们今天简单测试需求拆分任务，为什么需要 markdown 格式，因为 MD 格式1）容易通过 GIT 版本控制管理 2）LLM 最擅长处理是 MD 文档 3）需求描述 MD 是代码逻辑生成基础。
过去笔者曾写过文章《 AI 辅助需求规格描述评审 》，我们今天简单测试需求拆分任务，为什么需要 markdown 格式，因为 MD 格式1）容易通过 GIT 版本控制管理 2）LLM 最擅长处理是 MD 文档 3）需求描述 MD 是代码逻辑生成基础。
claude 主动询问我，我告诉他需求文档名
他生成了，实施路线图文档 IMPLEMENTATION_ROADMAP_CN.md 与需求分析文档 REQUIREMENTS_ANALYSIS_CN.md
需求分析文档 REQUIREMENTS_ANALYSIS_CN.md
请按已定义的需求描述卡片模板进行需求评审：FR-UI-010: 每日考勤记录（时间、地点、进出方向，评审内容来自文件原始需求文档《智慧校园安防服务平台.docx》
{需求编号：包含“采集时刻 + 采集者”信息
需求类型：（在进行评审时填写）功能需求、非功能需求……
来源（Who）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验
场景（Where、When）：产生该需求的用户活动特定的时间、地理、环境
描述（What）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
需求重要性权重（How much）：
满足后（1一般~5非常高兴）
未实现（1略感遗憾~5非常懊恼）
需求生命特征（When）：
需求的紧急度时间持续性需求关联（Which）：
人：需求关联的用户影响人物事：需求关联的用户业务与关联需求编号物：需求关联的客户系统、设备；需求关联的公司产品及版本参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节
竞争者对比：（按照1分差~10分好进行评估）
竞争者对该需求的满足方式用户、客户对竞争者及公司在该需求的评价说明：需求特征的描述，通常有如下几个维度：重要性（细分为“满足后、未实现”，或者说“基本、扩展、增值”，参见 KANO 模型）、紧急度、持续时间（生命周期）。实用主义的考虑，可以综合抽象为一个指标：商业价值（或者叫商业优先级）。然后除以开发量就得到了“性价比”，我们先做性价比高的需求。}
继续，变为英文
需求评审场景
top_p 和 temperature
低风险、高确定性场景：如果业务对输出的准确性和确定性要求极高，比如法律条文解释、财务报告生成、医疗诊断辅助等，建议将 top_p 设置为较低的值，如0.1 - 0.4。这样模型倾向于选择概率最高的词，输出结果较为稳定，减少生成不合理或错误内容的可能性。严格规范场景：在对输出格式、内容准确性有严格规范的场景，如代码生成、技术文档编写等，应将 temperature 设置为较低的值，如0.1 - 0.3。较低的温度使得模型更倾向于选择常见且合理的词汇，生成的内容更加符合预期和规范。这次我们在 init 后，直接让他拆需求文档，提示词如下：
请将我提供{需求文档-智慧校园安防服务平台}文档，按已定义的需求描述卡片模板进行拆分生成为独立 markdown 格式的文件(.md)，输出使用中文语言
{需求编号：包含“采集时刻 + 采集者”信息
需求类型：（在进行评审时填写）功能需求、非功能需求……
来源（Who）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验
场景（Where、When）：产生该需求的用户活动特定的时间、地理、环境
描述（What）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
需求生命特征（When）：
需求的紧急度时间持续性说明：需求特征的描述，通常有如下几个维度：重要性（细分为“满足后、未实现”，或者说“基本、扩展、增值”，参见 KANO 模型）、紧急度、持续时间（生命周期）。实用主义的考虑，可以综合抽象为一个指标：商业价值（或者叫商业优先级）。然后除以开发量就得到了“性价比”，我们先做性价比高的需求。}
输出后目录结构
│ CLAUDE.md │ 需求文档-智慧校园安防服务平台.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 │ README.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 应用开发平台，提供了可视化工作流设计、提示词优化和集成能力。
来源：墨码行者
