Spec-driven development 這個概念的擁護者不少, 但真正落地時常常遇到同一個尷尬: 規格文件往往是工程師在寫程式碼前臨時敲出來的, 其他人要麼沒看見, 要麼看見了也沒法參與。更常見的情況是, 規格寫完之後就躺在文件庫裡, 和最終程式碼完全脫節。Penling 想把這個流程徹底翻轉過來。
Penling 是一個 agentic spec-driven workflow 工具, 核心思路是"先寫規格, 再寫程式碼"。它把規格文件從 CLI 和單個工程師的鍵盤上拿出來, 放到一個團隊共享的工作區。產品經理、設計師、技術負責人和工程師都可以在這個空間裡共同定義"究竟要構建什麼", 而這些討論的結果會作為後續程式碼生成的依據。也就是說, 在 Penling 裡,"規不規格"不是某個人拍腦袋, 而是整個團隊的集體共識。
官網列出了三個支柱, 基本可以當作產品理念來看:
- Specified — 規格由團隊共同寫下, 而不是某個人獨自完成;
- Shared — 每個角色、每個決策都在共享空間裡流轉;
- Traceable — 從最初目標到合併後的 PR, 整個過程可追溯。
這三點的價值很容易被低估。很多團隊不是沒有規格, 而是規格和程式碼經常脫節。Penling 試圖把規格變成活文件, 讓 AI 在編碼階段直接參考團隊共識, 同時把推理過程保留下來。對遠端辦公或者非同步協作的團隊來說, 這種透明度尤其有意義——不再是事後補寫文件, 而是文件本身就參與構建。
一個更重視協作的 AI 開發流程
和市面上大多數 AI 程式設計工具相比, Penling 的切入點不太一樣。那些工具通常假設你已經知道要寫什麼, 然後幫你補全程式碼; Penling 則希望大家在寫任何程式碼之前, 先通過結構化目標和共享上下文達成一致。這種模式更接近產品評審, 而不是程式設計師日常的程式碼補全。它把"寫程式碼"這件事從個人行為變成了團隊行為。
從公開資訊看, Penling 目前處於 v0.14.2, 提供 14 天免費試用, 無需繫結信用卡, 而且可以通過 Google、Microsoft 或 GitHub 賬號快速登入。如果你所在團隊經常在"需求到底是什麼意思"上拉扯, 或者希望減少後期返工, 這套工作流值得試一下。
適合誰, 又有什麼限制
典型的使用場景是: 一個團隊在專案啟動時, 用 Penling 定義結構化目標, 所有相關角色都能看到並編輯規格, 然後 AI 根據規格生成程式碼, 最終輸出一個附帶完整構建說明的可評審 PR。這個過程把"寫規範"和"寫程式碼"繫結在一起, 也把責任分攤給了整個團隊。
當然, 它也不是萬能藥。Penling 要求團隊接受一種新的工作方式, 對於幾個人快速試想法的原型專案, 可能顯得有點重。另外, 官方公開的技術細節不多, 比如 AI 具體使用什麼模型、支援哪些程式碼託管平臺的深度整合, 都沒有在頁面上說明, 建議在實際使用前先關注這些問題。
如果你們團隊正在尋找一種讓所有人都能參與產品決策的 AI 開發工具, Penling 算是目前思路比較清晰的一個。它不一定適合所有專案, 但至少把"規格"重新放回了開發流程的核心位置。
評論
暫無評論
成為第一個評論的人