需求驅動開發:我們怎麼讓不寫程式的人,把需求變成可運行的產品
官網上寫著「設計文件先行、AI 加速開發」。這篇講我們內部怎麼把這兩句話變成一套可執行的流程——包括它踩過的坑,和它刻意不做的事。
我們常對創作者說:「你不需要懂技術,只要說清楚你要什麼。」但「說清楚」這件事,其實是整個軟體開發裡最難的一環。所以我們在內部做了一套需求驅動開發框架,目標很單純:任何人用白話提需求,AI 負責結構化成規格、規劃、寫碼、部署,人只在關鍵處做決定。
這篇是它的實作筆記。
規格是唯一的真相來源
框架的七條原則裡,最核心的一條是:規格(spec)是唯一真相來源。需求以任何格式進來——一段語音逐字稿、一封信、一張截圖——先被原封不動存進「不可變的收件匣」,再由 AI 翻譯成結構化規格與使用者角色(personas)。之後的規劃、任務拆解、程式碼,全部從規格長出來,並且可以一路回溯:這行程式是為了哪個任務、哪個任務對應哪條規格、哪條規格來自哪一份原始需求。
整個流程拆成十四個指令、三個子代理,從收件、調研、翻譯、衝突偵測、審核、規劃、實作、部署到回饋,形成閉環——生產環境的問題會自動變成新的需求,回到收件匣。
人只守三道閘門
AI 負責翻譯、分析、生成;人類負責做選擇題和按批准鈕。但有三道閘門,在任何自主等級下都不可繞過:
- 衝突裁決——當不同角色的需求互相矛盾(業務要快、法務要嚴),AI 只負責把矛盾攤開,由人拍板
- 規格審核——規格定案前必須有人讀過並批准
- 正式部署——上線的按鈕永遠在人手上
自主等級我們設了三級,並且刻意不設「全自動」那一級。設定檔的註解寫得很直白:再高的自主等級,都要搭配規格與程式碼的漂移稽核當補救網。這是我們對「全自動 AI 開發」的克制立場——不是做不到,是不該。
一個踩坑的真實案例
框架做好之後,我們用它做了第一個產品:框架自己的對話式介面——讓完全不會用命令列的人,在聊天視窗裡走完整個流程,最後產出一個可運行的網頁應用。從收件到實作,五個階段、二十七個任務,一天內走完。
有趣的是第一次調研就出了錯。AI 在分析框架本身時,因為一個環境細節沒設好,把框架誤判成「一堆 shell 腳本」,漏掉了最關鍵的整合路線。這個錯誤是在人類審核閘門被抓出來的,規格從 1.0 修到 1.2 才定案。這正是閘門存在的理由:AI 產出的品質很高,但它不知道自己不知道什麼。
確定性的事交給腳本,AI 不即興
我們量測過十四個指令的 prompt 用量,合計約一萬六千個 token,其中七個指令的邏輯其實是完全確定性的——讀檔、比對、產生選項——根本不需要模型「思考」。把這些搬進腳本後,估算可以省下約 74% 的 token。
這帶來一個我們現在奉行的原則:腳本產生選項,AI 做判斷,人做決定。不只省錢,更重要的是讓每一步都可預期、可重跑。
誠實的現況
這套框架目前是設計完整的可用原型:流程與文件成熟,但真實專案的量化指標還在累積,對話式介面也還在實驗階段。我們把它寫出來,不是因為它完美,而是因為它就是我們替創作者做產品時,實際運轉的方法。
當我們說「設計文件先行」,指的不是多開幾次會,而是有一套系統,讓你的一句話變成可追溯的規格,再變成程式;當我們說「AI 加速開發」,指的是這套流程真的讓一個產品在一天內從需求走到可運行——這是分潤模式能成立的成本前提。
想聊聊你的產品想法,歡迎來信。