メニュー
需求分析skill。默認情況下、你應當先做需求分析 再設計實現。除非用戶明確要求你不用分析
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Avalime項目的文檔。開發Avalime項目時必須閱讀此skill
AI的持久化記憶。此skill爲必讀。執行任務前先看記憶、執行任務後再按需更新記憶
在需求分析之後 編碼實現之前 閱讀此skill
聲明與實現分離。編碼階段初步設計與詳細實現時必須閱讀此skill
遇到疑問時立即停止工作並與用戶確認。此skill爲必讀
寫代碼一定要有註釋。寫代碼寫註釋時使用此skill
| name | tsinswreng-requirements-analysis |
| description | 需求分析skill。默認情況下、你應當先做需求分析 再設計實現。除非用戶明確要求你不用分析 |
需求分析的本質是交流、不是猜測。
用戶丟出一段話之後、你不能自己悶頭分析然後直接輸出一大堆。 需求分析的核心動作是反問——反覆向用戶提問、直到所有模糊點都被澄清。
寧可多問讓用戶覺得煩、也不能不問就瞎搞。
記住: 你沒有上下文、你不知道用戶的業務背景、你不知道用戶心裏沒說出來的前提假設。 這些東西只能通過問來獲取、不能靠猜。
以下任何情況、必須停下來反問、不能自己假設:
每一輪反問之後、根據用戶的回答繼續追問、直到沒有模糊點爲止。
需求分析階段的輸出是一份需求確認單、用戶確認後此階段完成。 除非用戶明確要求、在用戶確認需求之前、不得進入設計階段、不得寫任何代碼。
以下情況必須加載此skill進行需求分析:
以下情況可以跳過:
收到需求後的第一反應不是開始分析、而是自問: “有什麼信息是我還不知道、但做好這件事必須要清楚的?”
常見的信息缺口:
不要假設這些信息。 直接列出你缺的信息、向用戶提問。 問的時候不要一口氣問十個問題、按重要程度分批問、每次 2-3 個。
用戶提出的需求往往是“要做什麼”(解法)、而非“想解決什麼”(問題)。 收到任務後、必須先區分二者:
如果兩者有差距——也就是用戶提出的解法未必是解決該問題的最佳方式——必須指出來、 說明原因、讓用戶確認是堅持原解法還是換個方向。
示例:
用戶說出來的往往只是冰山露出水面的部分。必須主動思考用戶沒有說但客觀上需要的東西。
每個需求拿到手後、從以下角度挖掘隱含需求:
列出這些隱含需求後、逐項讓用戶確認哪些要做、哪些不做、哪些後續再做。
必須明確劃定本次工作的範圍、防止 scope creep、也防止 AI 順手改一堆不相關的東西:
範圍界定的粒度應該到“改哪些模塊/哪些層、不改哪些模塊/哪些層”的程度。
在分析階段就強制思考以下場景、提前暴露潛在問題:
不是每個場景都需要處理、但要主動列出來讓用戶決定取捨。
從業務和功能角度分析本次改動的波及範圍:
注意: 此處側重業務和功能層面、代碼層面的具體影響在設計階段（由 tsinswreng-structure-design skill 負責）再詳細分析。
需求分析完成後、必須按照以下格式輸出需求確認、等待用戶確認後才能推進:
