ClaudeCode实现简单需求文档分析与拆分

背景

          过去笔者曾写过文章《AI辅助需求规格描述评审》，我们今天简单测试需求拆分任务，为什么需要markdown格式，因为MD格式1）容易通过GIT版本控制管理 2）LLM最擅长处理是MD文档 3）需求描述MD是代码逻辑生成基础。
初始化

我们把需求文档放入到文件夹后
/INIT
生成

CLAUDE.md


原始需求文档，比较粗糙，来自互联网仅用于测试

需求分析

claude主动询问我，我告诉他需求文档名

他生成了，实施路线图文档IMPLEMENTATION_ROADMAP_CN.md与需求分析文档REQUIREMENTS_ANALYSIS_CN.md
需求分析文档REQUIREMENTS_ANALYSIS_CN.md

实施路线图文档

需求拆分与评审

请按已定义的需求描述卡片模板进行需求评审：FR-UI-010: 每日考勤记录（时间、地点、进出方向，评审内容来自文件原始需求文档《智慧校园安防服务平台.docx》
{需求编号：包含“采集时刻 + 采集者”信息
需求类型：（在进行评审时填写）功能需求、非功能需求……
来源（Who）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验
场景（Where、When）：产生该需求的用户活动特定的时间、地理、环境
描述（What）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句
原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）：
1. 用量化的语言
2. 无法量化寻找标竿
需求重要性权重（How much）：
满足后（1一般~5非常高兴）
未实现（1略感遗憾~5非常懊恼）
需求生命特征（When）：
1. 需求的紧急度
2. 时间持续性
需求关联（Which）：
1. 人：需求关联的用户影响人物
2. 事：需求关联的用户业务与关联需求编号
3. 物：需求关联的客户系统、设备；需求关联的公司产品及版本
参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节
竞争者对比：（按照1分差~10分好进行评估）
1. 竞争者对该需求的满足方式
2. 用户、客户对竞争者及公司在该需求的评价
说明：需求特征的描述，通常有如下几个维度：重要性（细分为“满足后、未实现”，或者说“基本、扩展、增值”，参见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）：
1. 用量化的语言
2. 无法量化寻找标竿
需求重要性权重（How much）：
满足后（1一般~5非常高兴）
未实现（1略感遗憾~5非常懊恼）
需求生命特征（When）：
1. 需求的紧急度
2. 时间持续性
需求关联（Which）：
1. 人：需求关联的用户影响人物
2. 事：需求关联的用户业务与关联需求编号
3. 物：需求关联的客户系统、设备；需求关联的公司产品及版本
参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节
竞争者对比：（按照1分差~10分好进行评估）
1. 竞争者对该需求的满足方式
2. 用户、客户对竞争者及公司在该需求的评价
说明：需求特征的描述，通常有如下几个维度：重要性（细分为“满足后、未实现”，或者说“基本、扩展、增值”，参见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 应用开发平台，提供了可视化工作流设计、提示词优化和集成能力。


今天先到这儿，希望对AI，云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理，信息安全，团队建设 有参考作用 , 您可能感兴趣的文章:
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变 如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！