القائمة
需求分析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 負責）再詳細分析。
需求分析完成後、必須按照以下格式輸出需求確認、等待用戶確認後才能推進:
