前言¶

日常開發裏兩種常見的翻車：需求剛說兩句就動手，寫到一半才發現交互沒對齊；改了代碼忘了文檔，交付物和說明互相打架，最後拿到的是源碼，還要自己再加工才能用。下面介紹的這個 Skill 把「結構化調研 → 文檔 → 編碼 → 測試 → 交付打包」固定成一條流程，要求每個階段的文檔先經用戶確認，再進入下一環。它面向從零開始的新項目或中大型新功能開發，不是給一句話腳本用的。

這是什麼¶

一句話定位：一個社區 Skill，座標 @user_2bb1379b/structured-dev-flow，版本 2.0.1，發佈者 user_2bb1379b，來源 community，分類 dev-programming。它把開發流程明確規定爲「開源調研 → 產品文檔(PRD) → 交互文檔 → 系統設計文檔 → 編碼 → 功能測試 → UI 交互測試 → 人機交互合理性校驗 → 交付打包」。

它解決兩個問題：一是代碼和文檔脫節，二是交付停在源碼層面。流程要求每一階段都產出文檔，經用戶確認後才進入下一階段；全部完成後，打包可直接使用的產出物交付，而不是扔一份源碼過來。

核心功能¶

固定的九步流程，順序不能亂：

開源調研 → 產品文檔(PRD) → 交互文檔 → 系統設計文檔 → 編碼
→ 功能測試 → UI 交互測試 → 人機交互合理性校驗 → 交付打包

每一步的要點：

1、開源調研：優先借鑑 GitHub 高分開源項目；
2、產品文檔：產出 PRD；
3、交互文檔：描述用戶操作路徑；
4、系統設計文檔：進入編碼前最後一份設計產物；
5、編碼：接口與 Service 層必須寫文檔和註釋（這是硬要求，不是建議）；
6、功能測試：驗證業務功能；
7、UI 交互測試：驗證頁面上的實際交互；
8、人機交互合理性校驗：按主流設計規範檢查字體、字號、顏色、佈局、觸摸目標；
9、交付打包：產出可直接使用的成品。

每階段文檔須經用戶確認後才進入下一階段，這是整個流程的控制點。

文檔與代碼同步：修復問題或調整內容時，同步修改對應文檔並記小版本，改後必回測；發現設計缺陷可以回溯修正文檔，而不是讓文檔跟着代碼跑偏。

安裝與啓用¶

該 Skill 發佈在 SkillHub，標籤 requires_api_key=false，說明不需要 API Key，加載後即可使用。官方地址：

https://api.skillhub.cn/user_2bb1379b/structured-dev-flow

SkillHub 頁面：https://www.skillhub.cn/skills/user_2bb1379b/structured-dev-flow

接入方式沿用通用 SKILL.md 格式。本文未覈實到官方安裝命令與目錄約定，安裝時以 SkillHub 頁面說明爲準。

觸發方式：用戶說「按流程開發」「先出文檔再寫代碼」「規範化開發」「新項目/新功能開發」等表述時觸發。不需要額外配置，用自然語言調用即可。

典型用法¶

以中大型新功能開發爲例，走一遍流程：

1 開源調研，優先看 GitHub 高分項目
2 產出 PRD，交用戶確認
3 寫交互文檔，走一遍用戶操作路徑
4 寫系統設計文檔，接口與 Service 層留註釋
5 用戶確認後開始編碼
6 功能測試 → UI 交互測試 → 人機交互合理性校驗
7 打包可直接使用的成品交付

每一環的文檔確認是硬門檻，跳過意味着流程還沒走完。修復問題時先回到對應文檔做改動，記一個小版本號，然後把相關功能回測一遍，確認文檔和代碼一致。

適用場景與注意¶

適合：從零開始的新項目、中大型新功能開發、需要長期維護和協作的任務。

不適合：一句話能完成的腳本、純問答類任務。小型 bug 修復可以不用整套流程，但必須遵守變更與修復規則：同步改文檔、記小版本、改後回測。

注意：這套流程會增加前期文檔工作量，如果項目週期極短或需求高度不確定，前期投入可能超過收益。沒有用戶確認環節的自動化場景，也難以發揮它的作用。

寫在最後¶

這個 Skill 的價值不在於「多寫文檔」，而是把文檔確認當作過關的門檻，把打包交付當作流程終點，同時把接口與 Service 層的註釋變成硬約束。適合需要長期維護、多人協作的項目。官方地址：https://api.skillhub.cn/user_2bb1379b/structured-dev-flow