給 AI 寫程式用的 Markdown PRD 範本

產品需求文件（PRD，product requirements document）是一份散文，在工作拆成任務之前，先寫明問題與範圍。功能規範是 SpecScore 為一項產品能力準備的檔案：它做什麼、為什麼存在、行為如何。Markdown 是這份檔案的純文字格式。規範驅動開發（SDD，spec-driven development）是先寫規格、再寫程式，並把規格當作事實來源的做法。在 SpecScore 裡，需求（REQ，requirement）是功能內部一條有名字的規則。驗收標準（AC，acceptance criterion）是可選的抽象條件，指向其中一條或多條規則。情境是用 Given、When、Then 步驟寫成的具體例子。計畫是把功能拆成任務的文件。任務是一個人或一個代理能夠做完的一份工作。持續整合（CI，continuous integration）是對每一項提議變更的自動檢查。這項檢查是一條命令列介面（CLI，command-line interface）的命令 specscore spec lint，來自 specscore/specscore-cli 裡的 CLI。Easy Approach to Requirements Syntax（EARS）是一條需求可以使用的句式。Claude Code 是本站 CLI Skills 外掛所針對的 AI 寫程式代理。這份功能規格範本就是那份功能檔案，再加上指回它的計畫和任務。

最近更新：2026年11月5日

這份功能規格範本是什麼

PRD 常常是一個人閱讀的一份散文檔。SpecScore 把同一份簡述存成檢查器能夠檢查的檔案。功能規範把功能稱為產品規範的原子單位：spec/features/ 下的一個目錄，其中的 README.md 是這份功能做什麼的唯一事實來源。計畫規範把計畫稱為把該功能拆成任務的文件。情境在情境規範裡，是功能的 _tests/ 目錄中一份具體的 Given/When/Then 檔案。驗收標準規範讓標準維持抽象：標準說什麼必須為真，情境說怎樣證明。

下面的 checkout 檔案就是填好的範本。連同功能索引、一份規格 README 和 specscore.yaml，specscore spec lint 以 0 筆違規接受了它。這次檢查執行於 2026年11月2日，用的是 specscore 0.55.1 與 0.39.1。0.39.1 是 dogfood.yml 所安裝的標籤。功能檔案裡的 Studio 工具列那一行，是 specscore/specscore 裡功能 README 所帶的那一行。功能規範的必要小節表格並沒有列出它。

功能 README

功能規範的必要小節表格說，每份功能 README 都有標題 # Feature: {Title}、緊接標題的 **Status:** 行、Summary、Problem、Behavior 小節、Acceptance Criteria 小節、Open Questions 小節，以及遵循聲明頁尾。狀態值是 Draft、In Review、Approved、Implementing、Stable、Amending、Rejected 或 Deprecated 之一。只有功能帶有子目錄時，Contents 小節才是必要的。**Source Ideas:** 是可選的。被檢查的檔案把它設為 —。

Open Questions 從不省略。一條都沒有時，該小節寫 None at this time. Acceptance Criteria 也從不省略。還沒有定義標準時，該小節寫 Not defined yet.，並且 Open Questions 必須隨後包含 Acceptance criteria not yet defined for this feature. 頁尾是最後一行，它的 URL 是 https://specscore.md/feature-specification。

產物 frontmatter 約定說，每個產物都在 YAML frontmatter 裡帶 format: 鍵，帶狀態的產物還帶 status:，與正文裡的 **Status:** 對齊。同一項功能說明，強制這些鍵的 lint 規則有一段寬限期。被檢查的檔案包含這兩個鍵。本頁不聲稱 v0.39.1 這個釘選版本會拒絕省略它們的檔案。

specscore spec lint 接受的功能 README（2026年11月2日）

---
format: https://specscore.md/feature-specification
status: Draft
---

# Feature: Checkout validation

> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |

**Status:** Draft
**Source Ideas:** —

## Summary

The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.

## Problem

A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.

## Behavior

### Field validation

The checkout system checks the form when the shopper submits it.

#### REQ: show-field-error

When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.

#### REQ: reject-invalid-email

If the submitted email is not a valid address, then the checkout system MUST reject the form.

## Acceptance Criteria

### AC: invalid-submission

**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email

Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/feature-specification*

同一次檢查執行的功能索引

---
format: https://specscore.md/features-index-specification
---

# Features

| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/features-index-specification*

同一次檢查執行的規格 README

# Checkout specification

## Open Questions

None at this time.

同一次檢查執行的 specscore.yaml

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

功能的識別碼是它相對於 spec/features/ 的目錄路徑。索引連結 checkout/README.md 表示檔案位於 spec/features/checkout/README.md，因此需求和標準使用的功能 id 是 checkout。索引列出每一個頂層功能。沒有列出的子目錄是 index-entries 的違規，在 CI 中檢查規格說明了這條規則。那棵樹裡的規格 README 只有一小節，Open Questions，寫的是 None at this time. 設定檔是 CLI 向上尋找的那個檔案。沒有 specscore.yaml 時，命令以 3 結束，並點出 specscore init。

REQ 識別碼、驗收標準與情境

需求規範把每條規則放在 ## Behavior 內部的主題標題之下。標題是 #### REQ: {slug}，冒號後面是一個空格。slug 使用小寫字母、數字和連字號。標準 id 是 {feature-path}#req:{slug}。在 checkout 檔案裡，那就是 checkout#req:show-field-error 和 checkout#req:reject-invalid-email。一條需求陳述一項義務。規範說，需求 SHOULD 使用 RFC 2119 關鍵詞 MUST、MUST NOT、SHOULD、SHOULD NOT 與 MAY。REQ: 標題在 ## Behavior 之外無效。EARS 句子可以當作那段散文。檢查器不為英語打分。這些句式在 EARS 需求語法詳解與範例。

驗收標準

驗收標準規範說，每條標準是一個 ### AC: {slug} 標題，位於 ## Acceptance Criteria 內部，然後是一行 **Requirements:**，列出 {feature-id}#req:{slug} 的值，再然後是一句抽象的話，說明什麼必須為真。標準是可選的。規範說，把兩條或更多相關需求歸併到一起能讓意思更清楚時，就加一條。checkout 檔案把兩條規則都歸進 checkout#ac:invalid-submission。這句話裡沒有 Given、When 或 Then。怎樣寫驗收標準是寫作指南。規則 ac-heading-format（ac_heading.go，CLI 標籤 v0.55.1）檢查標題是 ### AC: <id>，並且 id 為 kebab-case。檢查規格的文章記錄這條規則並不要求 **Requirements:** 那一行，也不為用字打分。驗收標準規範仍然要求那一行。

情境

情境規範把情境放在 _tests/ 裡。那裡不是子功能，也不進入功能索引。檔案以 # Scenario: {Title} 開頭，有一行指向需求或標準的 **Validates:**，以及一小節 ## Steps，其關鍵字是大寫的 GIVEN、WHEN、THEN 與 AND。每個 _tests/ 目錄都必須有一份帶情境索引的 README。下面的樣本就是那種檔案形狀。它不屬於 2026年11月2日的那次檢查。specscore spec lint 不檢查情境步驟關鍵字。specscore rehearse 執行情境檔案。Rehearse 就是那個執行器。dogfood 工作流程執行檢查器，並不呼叫 rehearse。

按情境規範得到的情境檔案形狀

# Scenario: Reject an invalid email

**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)

## Steps

GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed

按順序讀這三層。需求說出規則。驗收標準說出它所點名的規則必須為真的是什麼。情境給出一條具體流程。只看得到 PRD 散文的代理，得自己發明這層拆分。範本裡已經有了。

計畫與任務

計畫 README 位於 spec/plans/{plan-slug}/README.md。計畫規範要求標題 # Plan: {Title}，以及標頭欄位 Status、恰好一行來源、Date、Owner 與 Supersedes。以來源為功能的計畫使用 **Source Feature:** 加上功能 slug，這裡是 checkout。另外允許的來源行是 **Source:** idea:{slug} 與 **Source:** none。必要的小節是 Summary、Approach、Tasks 與 Open Questions。計畫內部，每條任務是一個 ### Task N: 標題，帶一行 **Verifies:**，形式為 feature-slug#ac:ac-slug。規則 P-001（在 plan_rules.go）報告一條沒有任何任務覆蓋、也沒有列在 ## Deferred AC Coverage 之下的驗收標準標題。規則 P-002 報告一個對不上那些標題的 **Verifies:** 值。來源為 idea 的計畫，以及帶 **Source:** none 的計畫，免除 P-001。

下面的計畫按已公布的形狀為 checkout 功能填寫，包括 frontmatter 裡的 format: 與 status:。它不在 2026年11月2日的那次檢查裡。計畫觸及的功能必須包含一張 ## Plans 表，欄是 Plan、Status、Author 與 Approved。被檢查的功能檔案沒有 Plans 小節，因為那棵樹裡沒有計畫。

任務規範還把任務定義為計畫之下自己的目錄和 README.md。標題是 # Task: {Title}。必要欄位是 **Status:**、**Depends on:**（沒有依賴時的字面值是 none）和 **Model:**（small、medium、large 或 inherit）。包含子任務目錄的目錄是計畫，不是任務。下面的任務檔案把這些欄位用於 checkout 的第一個任務。它不在 2026年11月2日的那次檢查裡。任務文件的頁尾 URL 是 https://specscore.md/task-specification。

按計畫規範的形狀，為 checkout 填好的計畫

---
format: https://specscore.md/plan-specification
status: Draft
---

# Plan: Show checkout validation errors

**Status:** Draft
**Source Feature:** checkout
**Date:** 2026-11-05
**Owner:** @example
**Supersedes:** —

## Summary

This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address.

## Approach

Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section.

## Tasks

### Task 1: Show a validation error beside the invalid field

**Verifies:** checkout#ac:invalid-submission

When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field.

### Task 2: Reject an email that is not a valid address

**Verifies:** checkout#ac:invalid-submission

If the submitted email is not a valid address, reject the form.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/plan-specification*

按任務規範得到的任務文件形狀

---
format: https://specscore.md/task-specification
status: queued
---

# Task: Show a validation error beside the invalid field

**Status:** queued
**Depends on:** none
**Model:** medium

## Acceptance Criteria

- Submitting the checkout form with invalid data shows a validation error next to the invalid field.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/task-specification*

功能檔案回答 checkout 表單必須做什麼。計畫回答這項工作如何拆分，每條行內任務都寫出它所驗證的標準。任務文件是人或代理接手的末端。讓標準的識別碼保持不變。checkout#ac:invalid-submission 就是功能和計畫都使用的那串文字。

在 CI 中檢查這份範本

specscore spec lint 對照結構約定的違規來驗證規格樹。一次乾淨的執行印出 0 violations found 並以 0 結束。發現違規的執行為每筆發現印出一行，並以 1 結束。這個結束碼會讓 CI 作業失敗。無效參數以 2 結束。缺少 specscore.yaml 時以 3 結束。dogfood.yml 把 SPECSCORE_VERSION 設為 v0.39.1 來安裝 CLI，然後在 pull request 以及推向 main 的 push 上執行 specscore spec lint。工作流程摘錄、失敗報告和規則一覽在在 CI 中用規格檢查器檢查規格。

格式授權是 CC BY 4.0，在 specscore/specscore。CLI 授權是 Apache-2.0，在 specscore/specscore-cli。

其他規範驅動工具公布的檢查各不相同。下面的句子只用那些專案自己的頁面所說的內容。工具彙整把同樣的頁面記為 2026年10月30日讀過，Spec Kit 文件首頁除外，那一頁印著 2026年9月28日。

OpenSpec 記錄了 openspec validate，寫在它的 CLI 參考裡。該命令檢查 OpenSpec 的變更和規格結構，驗證失敗時以非零結束。它不檢查 SpecScore 的 ### AC: 標題，也不檢查 SpecScore 的索引。

Task Master 的 README 描述用 task-master parse-prd 把 PRD 解析成任務。它沒有描述針對那份 PRD 的檢查器。PRD 仍然可以是你改寫成此頁功能檔案的輸入。隨後檢查該功能檔案的是 specscore spec lint。

GitHub Spec Kit 描述一套代理工作流程，其階段寫下 Markdown 產物。那份文件首頁沒有描述一條在 CI 中檢查 SpecScore 功能 README 的命令。那些工具的比較是工具彙整。

Claude Code 讀得懂的規格範本

這些檔案是 Markdown，所以讀得了儲存庫的代理，就讀得了這份範本。Claude Code 是 CLI Skills 頁面所針對的代理。該頁記錄了 ai-plugin-specscore，一個包住 CLI 的薄 Claude Code 外掛。外掛儲存庫是 specscore/ai-plugin-specscore。該頁說，外掛把 specscore spec lint、specscore feature、specscore task 和 specscore feature change-status 作為外掛命令露出。該頁上的安裝行是 /plugin marketplace add specscore/ai-marketplace 和 /plugin install cli-skills@specscore。

同一頁還記錄了在 SpecScore 管理的專案裡執行的 specscore agent setup <agent-name>，用於 claude、copilot、cursor、codex、antigravity.google、pi.dev 或 opencode。SpecStudio Skills 是有引導的工作流程（/ideate、/specify、/plan、/implement），並且也是一個 Claude Code 外掛。本頁的範本就是那些命令所檢查的檔案。外掛不取代功能 README。

常見問題

什麼是 Markdown 中的 PRD 範本？

它是寫成固定形狀的 Markdown 檔案的產品需求文件。在 SpecScore 裡，這個形狀是一份功能 README：標題、狀態、摘要、問題、帶 #### REQ: 規則的行為、驗收標準，以及開放問題。本頁的 checkout 檔案就是 specscore spec lint 接受過的一份。

功能規格範本裡，REQ 識別碼放在哪裡？

放在 ## Behavior 內部的主題標題下，寫作 #### REQ: {slug}。識別碼是 {feature-path}#req:{slug}。驗收標準在 **Requirements:** 上列出這些識別碼。計畫裡的任務在 **Verifies:** 上列出標準識別碼。

驗收標準和情境有什麼不同？

驗收標準是抽象條件。情境是 _tests/ 裡一條具體的 Given/When/Then 流程。驗收標準規範說，標準不得規定步驟。情境檔案則會寫出步驟。

檢查器會為 PRD 的散文打分嗎？

不會。specscore spec lint 檢查的是結構：標題、必要的小節、索引列，以及 P-001 和 P-002 這樣的參照。它不判斷產品是不是個好主意。在 CI 中用規格檢查器檢查規格是對那條命令更長的說明。

Claude Code 能用這份規格範本嗎？

能。範本是儲存庫裡的 Markdown。CLI Skills 外掛在 Claude Code 裡露出 specscore spec lint，以及功能和任務命令。specscore agent setup claude 為那個代理寫一份指示檔案。外掛不會另造一份範本。

計畫會取代功能規範嗎？

不會。功能 README 是需求和驗收標準的來源。計畫把該功能拆成任務，每條任務用 **Verifies:** 指回去。計畫規範和任務規範就是這次拆分的兩份文件。

來源

checkout 功能、功能索引、規格 README 和 specscore.yaml 已於 2026年11月2日由 specscore spec lint 用 specscore 0.55.1 與 0.39.1 接受。計畫和任務樣本遵循已公布的規格，不屬於那次執行。其他專案的頁面就是下面連結的那些；工具彙整把它們記為 2026年10月30日讀過，Spec Kit 文件首頁除外，那一頁印著 2026年9月28日。