SpecScore 對照 Kiro
規範驅動開發（SDD）指的是這件事：AI 代理還沒開始寫程式碼，軟體該做的事就先寫好。Kiro 出自亞馬遜網路服務（AWS）。它是一套代理式開發環境，裡頭有編輯器、命令列介面（CLI）以及網頁應用程式。一段提示詞進去，出來的是 Kiro 規範：需求、設計、任務。那些需求採用 EARS（簡易需求語法，Easy Approach to Requirements Syntax），句子的形狀是「WHEN 有某件事發生，THE SYSTEM SHALL 做某件事」。SpecScore 則是規範本體的開源格式，另外附一支專門檢查這些檔案的 CLI。持續整合（CI）——每一項提議中的變更都會自動查一次——可以把一份寫壞格式的 SpecScore 規範退回去。
兩者的共同點。
Kiro 擅長什麼。
關於這項產品的說法，依據是 2026年10月30日讀過的 Kiro 官方文件。功能規範那一頁所標的更新日期，是 2026年8月4日。
行為寫成固定句型
Kiro 的規範把行為放在 requirements.md，句型只用一種 EARS：條件成立時寫 WHEN，系統該做的事寫 THE SYSTEM SHALL。文件給的例子是一張填了無效資料的表單，系統在該欄位旁邊顯示驗證錯誤。比起一段含糊其辭的文字，這種形狀更好測試。
提示詞到任務，路是通的
一份功能規範會依序經過需求、設計（design.md）與任務（tasks.md）。起點可以是需求，也可以是設計。快速規範（Quick Spec）一次把三步跑完，中間不設核准停點。修缺陷用的規範（Bugfix）另走一條路。文件也寫到：依照 tasks.md 裡的相依圖，把彼此獨立的任務分成幾波、平行執行。
檢查就做在產品裡
需求檢視（Analyze Requirements）在 IDE 與 CLI 都能用，設計開始之前會去找前後不一致、歧義、彼此衝突的約束，以及缺漏。正確性（Correctness）——從那些 EARS 句子抽出、以屬性為基礎的測試——在規範能力表上只列給 IDE。CLI、網頁版、行動版都不在那張表上。
功能對比。
Kiro 這項產品負責把規範起草出來。SpecScore 是儲存庫可以拿來檢查的格式。這張表對照的是這兩種角色。
| 能力 | Kiro | SpecScore |
|---|---|---|
| 主要角色 | 代理式 IDE、CLI 與網頁應用程式，負責起草規範並實作任務 | 開放的規範格式 + CLI |
| 規範檔案 | requirements.md（或 bugfix.md）、design.md、tasks.md | 一棵 spec/ 目錄樹，以 Markdown 加上 YAML 組成 |
| 需求怎麼寫 | EARS 寫成：WHEN … THE SYSTEM SHALL … | 需求識別碼（REQ: slug）與給定／當／那麼驗收標準 |
| 怎麼檢查規範 | IDE 與 CLI 裡的需求檢視（Analyze Requirements）。以屬性為基礎的測試只在 IDE。文件並沒有把它寫成你自己的 CI 能用的格式檢查器。 | specscore spec lint 在 CI 裡執行。/score 則是分開的、要手動跑的 AI 評分。 |
| 在哪裡跑 | Kiro IDE、Kiro CLI、Kiro 網頁版。有一部分檢查只在 IDE 裡。 | 任何儲存庫——一支 Go 二進位檔，不必擁有 Kiro 帳戶 |
| 授權 | Kiro 授權載明 IDE 與 CLI 屬於 AWS 客戶協議（AWS Customer Agreement）底下的 AWS 內容（AWS Content）。Kiro Crew 另外獨立成一個公開儲存庫。 | CC BY 4.0 格式 · Apache-2.0 CLI |
| 定價 | 有免費方案，也有付費方案。標價會改——見Kiro 定價，讀於 2026年10月30日。 | 不必付費，格式與 CLI 都一樣 |
SpecScore 增添了什麼。
格式本身就足以讓 CI 失敗
Kiro 的分析是在 Kiro 裡面跑的。SpecScore 的檢查則是一則命令。這個儲存庫的dogfood 工作流程會在每一則拉取請求上、也在 main 上執行 specscore spec lint。壞掉的規範會讓作業失敗，後果跟壞掉的測試一樣。/score 技能請 AI 審查者替措辭評分；這一關要手動跑，上面那個工作流程並不會去跑它。
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
規範並不拴在某一個 IDE
Kiro 規範是 Markdown，所以沒有那套產品也能讀。把它們生出來、再執行下去的工作流程，是 Kiro 的。一棵 SpecScore 目錄樹，不論交給 Claude Code、Cursor、Copilot，或根本沒有代理，都是同一批檔案——CLI 做檢查時不會呼叫模型。
需求留有識別碼
Kiro 的文件把可追溯性寫成：沿著一條需求追到實作。文件裡沒有寫一種改寫之後仍然穩得住的識別碼。SpecScore 以 REQ: slug 稱呼一條需求，驗收標準則各自帶著自己的識別碼。
EARS 與給定／當／那麼問的不是同一件事
依 Kiro 文件的寫法，EARS 就是一句系統行為。SpecScore 的驗收標準，是綁在需求識別碼上的給定／當／那麼情境。你可以在散文裡寫一行 EARS，同時把情境留在檢查器會檢查的那份 SpecScore 檔案裡。 句式見EARS 需求語法.
何時使用哪個。
遇到這些情況，選 Kiro……
- 你要的是 AWS 的代理式 IDE：從一段提示詞起草需求、設計與任務，接著把任務實作出來。
- 你要 EARS 句子，而且要在 IDE 裡有從這些句子產生、以屬性為基礎的測試。
- 你們團隊已經決定把標準定在 Kiro 的編輯器、CLI 或網頁應用程式。
以下情境適合使用 SpecScore……
- 代理的工作階段結束以後，規範仍須在 CI 裡維持有效，而且這個儲存庫不必裝 Kiro。
- 你需要需求識別碼、生命週期狀態，以及每次都一樣的檢查結果。
- 你希望這份格式開源，而且檢查器是一支二進位檔。
起草交給 Kiro。把關交給 SpecScore。
這裡沒有任何東西要取代 Kiro 的編輯器。若團隊是在 Kiro 裡下提示詞，就讓它起草。若規範必須以一份審過的檔案留下來，就把這份契約寫成 SpecScore，並讓 specscore spec lint 在結構壞掉時讓拉取請求失敗。這兩份檔案可以放進同一個儲存庫。
這一輪工作階段選 Kiro。那份 CI 作業可以拒絕的產物，選 SpecScore。
來源。
下方公開頁面讀於 2026 年 10 月 30 日。價格、方案名稱和發布線會改變。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.