背景

          過去筆者曾寫過文章《AI輔助需求規(guī)格描述評審》，我們今天簡單測試需求拆分任務(wù)，為什么需要markdown格式，因為MD格式1）容易通過GIT版本控制管理 2）LLM最擅長處理是MD文檔 3）需求描述MD是代碼邏輯生成基礎(chǔ)。

初始化

我們把需求文檔放入到文件夾后

/INIT

生成

CLAUDE.md

原始需求文檔，比較粗糙，來自互聯(lián)網(wǎng)僅用于測試

需求分析

claude主動詢問我，我告訴他需求文檔名

他生成了，實施路線圖文檔IMPLEMENTATION_ROADMAP_CN.md與需求分析文檔REQUIREMENTS_ANALYSIS_CN.md

需求分析文檔REQUIREMENTS_ANALYSIS_CN.md

實施路線圖文檔

需求拆分與評審

請按已定義的需求描述卡片模板進(jìn)行需求評審：FR-UI-010: 每日考勤記錄（時間、地點、進(jìn)出方向，評審內(nèi)容來自文件原始需求文檔《智慧校園安防服務(wù)平臺.docx》

{需求編號：包含“采集時刻 + 采集者”信息

需求類型：（在進(jìn)行評審時填寫）功能需求、非功能需求……

來源（Who）：（方便追根溯源）公司提供者：需求提供者的部門、聯(lián)系方式產(chǎn)生需求的客戶：用戶需求的公司、部門、聯(lián)系方式客戶背景資料：受教育程度、崗位經(jīng)驗、其他與本單項需求相關(guān)經(jīng)驗

場景（Where、When）：產(chǎn)生該需求的用戶活動特定的時間、地理、環(huán)境

描述（What）：用（主語+謂語+賓語）的語法結(jié)構(gòu)，禁止使用修飾語句

原因（Why）：（保持懷疑的心，很多時候理由是假想出來的）

驗收標(biāo)準(zhǔn)（How）：

1. 用量化的語言

2. 無法量化尋找標(biāo)竿

需求重要性權(quán)重（How much）：

滿足后（1一般~5非常高興）

未實現(xiàn)（1略感遺憾~5非常懊惱）

需求生命特征（When）：

1. 需求的緊急度

2. 時間持續(xù)性

需求關(guān)聯(lián)（Which）：

1. 人：需求關(guān)聯(lián)的用戶影響人物

2. 事：需求關(guān)聯(lián)的用戶業(yè)務(wù)與關(guān)聯(lián)需求編號

3. 物：需求關(guān)聯(lián)的客戶系統(tǒng)、設(shè)備；需求關(guān)聯(lián)的公司產(chǎn)品及版本

參考材料：在需求采集活動中的輸入材料，僅僅輸入援用的條目、章節(jié)

競爭者對比：（按照1分差~10分好進(jìn)行評估）

1. 競爭者對該需求的滿足方式

2. 用戶、客戶對競爭者及公司在該需求的評價

說明：需求特征的描述，通常有如下幾個維度：重要性（細(xì)分為“滿足后、未實現(xiàn)”，或者說“基本、擴(kuò)展、增值”，參見KANO模型）、緊急度、持續(xù)時間（生命周期）。實用主義的考慮，可以綜合抽象為一個指標(biāo)：商業(yè)價值（或者叫商業(yè)優(yōu)先級）。然后除以開發(fā)量就得到了“性價比”，我們先做性價比高的需求。}

繼續(xù)，變?yōu)橛⑽?/font>

需求評審記錄文件

Review_Summary

進(jìn)一步需求拆分

其他參數(shù)參考

需求評審場景

top_p和temperature

- 低風(fēng)險、高確定性場景：如果業(yè)務(wù)對輸出的準(zhǔn)確性和確定性要求極高，比如法律條文解釋、財務(wù)報告生成、醫(yī)療診斷輔助等，建議將 top_p 設(shè)置為較低的值，如0.1 - 0.4。這樣模型傾向于選擇概率最高的詞，輸出結(jié)果較為穩(wěn)定，減少生成不合理或錯誤內(nèi)容的可能性。

- 嚴(yán)格規(guī)范場景：在對輸出格式、內(nèi)容準(zhǔn)確性有嚴(yán)格規(guī)范的場景，如代碼生成、技術(shù)文檔編寫等，應(yīng)將 temperature 設(shè)置為較低的值，如0.1 - 0.3。較低的溫度使得模型更傾向于選擇常見且合理的詞匯，生成的內(nèi)容更加符合預(yù)期和規(guī)范。

需求拆分

這次我們在init后，直接讓他拆需求文檔，提示詞如下：

請將我提供{需求文檔-智慧校園安防服務(wù)平臺}文檔，按已定義的需求描述卡片模板進(jìn)行拆分生成為獨立markdown格式的文件(.md)，輸出使用中文語言

{需求編號：包含“采集時刻 + 采集者”信息

需求類型：（在進(jìn)行評審時填寫）功能需求、非功能需求……

來源（Who）：（方便追根溯源）公司提供者：需求提供者的部門、聯(lián)系方式產(chǎn)生需求的客戶：用戶需求的公司、部門、聯(lián)系方式客戶背景資料：受教育程度、崗位經(jīng)驗、其他與本單項需求相關(guān)經(jīng)驗

場景（Where、When）：產(chǎn)生該需求的用戶活動特定的時間、地理、環(huán)境

描述（What）：用（主語+謂語+賓語）的語法結(jié)構(gòu)，禁止使用修飾語句

原因（Why）：（保持懷疑的心，很多時候理由是假想出來的）

驗收標(biāo)準(zhǔn)（How）：

1. 用量化的語言

2. 無法量化尋找標(biāo)竿

需求重要性權(quán)重（How much）：

滿足后（1一般~5非常高興）

未實現(xiàn)（1略感遺憾~5非常懊惱）

需求生命特征（When）：

1. 需求的緊急度

2. 時間持續(xù)性

需求關(guān)聯(lián)（Which）：

1. 人：需求關(guān)聯(lián)的用戶影響人物

2. 事：需求關(guān)聯(lián)的用戶業(yè)務(wù)與關(guān)聯(lián)需求編號

3. 物：需求關(guān)聯(lián)的客戶系統(tǒng)、設(shè)備；需求關(guān)聯(lián)的公司產(chǎn)品及版本

參考材料：在需求采集活動中的輸入材料，僅僅輸入援用的條目、章節(jié)

競爭者對比：（按照1分差~10分好進(jìn)行評估）

1. 競爭者對該需求的滿足方式

2. 用戶、客戶對競爭者及公司在該需求的評價

說明：需求特征的描述，通常有如下幾個維度：重要性（細(xì)分為“滿足后、未實現(xiàn)”，或者說“基本、擴(kuò)展、增值”，參見KANO模型）、緊急度、持續(xù)時間（生命周期）。實用主義的考慮，可以綜合抽象為一個指標(biāo)：商業(yè)價值（或者叫商業(yè)優(yōu)先級）。然后除以開發(fā)量就得到了“性價比”，我們先做性價比高的需求。}

輸出后目錄結(jié)構(gòu)

│  CLAUDE.md
│  需求文檔-智慧校園安防服務(wù)平臺.docx
│  需求文檔-智慧校園安防服務(wù)平臺.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

小結(jié)

        我們今天使用ClaudeCode+longcat-flash-chat實現(xiàn)簡單需求文檔分析與拆分，希望對大家有啟發(fā)。其他實現(xiàn)方式還有基于 Dify 實現(xiàn)將需求文檔拆分為“業(yè)務(wù)場景需求卡片”的 Markdown 格式文檔，是一個典型的自然語言處理（NLP）任務(wù)，核心是利用 Dify 的 工作流（Workflow） 和 提示詞工程（Prompt Engineering） 能力，通過大語言模型（LLM）自動解析、拆分和結(jié)構(gòu)化需求內(nèi)容。Dify 作為開源 LLM 應(yīng)用開發(fā)平臺，提供了可視化工作流設(shè)計、提示詞優(yōu)化和集成能力。