# 給 AI 寫程式用的 Markdown PRD 範本

Canonical: https://specscore.md/zh-tw/articles/feature-spec-template/

最近更新：2026年11月5日

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

## 這份功能規格範本是什麼

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

下面的 checkout 檔案就是填好的範本。連同功能索引、一份規格 README 和 `specscore.yaml`，`specscore spec lint` 以 0 筆違規接受了它。這次檢查執行於 2026年11月2日，用的是 specscore 0.55.1 與 0.39.1。0.39.1 是 [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 所安裝的標籤。功能檔案裡的 Studio 工具列那一行，是 [specscore/specscore](https://github.com/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 約定](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md)說，每個產物都在 YAML frontmatter 裡帶 `format:` 鍵，帶狀態的產物還帶 `status:`，與正文裡的 `**Status:**` 對齊。同一項功能說明，強制這些鍵的 lint 規則有一段寬限期。被檢查的檔案包含這兩個鍵。本頁不聲稱 v0.39.1 這個釘選版本會拒絕省略它們的檔案。

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

```markdown
---
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*
```

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

```markdown
---
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

```markdown
# Checkout specification

## Open Questions

None at this time.
```

### 同一次檢查執行的 specscore.yaml

```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 中檢查規格](https://specscore.md/zh-tw/articles/lint-specs-in-ci/)說明了這條規則。那棵樹裡的規格 README 只有一小節，Open Questions，寫的是 `None at this time.` 設定檔是 CLI 向上尋找的那個檔案。沒有 `specscore.yaml` 時，命令以 3 結束，並點出 `specscore init`。

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

[需求規範](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md)把每條規則放在 `## 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 需求語法詳解與範例](https://specscore.md/zh-tw/articles/ears-requirements/)。

### 驗收標準

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

### 情境

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

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

```markdown
# 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`。[計畫規範](https://specscore.md/plan-specification)要求標題 `# 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](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/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 小節，因為那棵樹裡沒有計畫。

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

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

```markdown
---
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*
```

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

```markdown
---
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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 把 `SPECSCORE_VERSION` 設為 `v0.39.1` 來安裝 CLI，然後在 pull request 以及推向 main 的 push 上執行 `specscore spec lint`。工作流程摘錄、失敗報告和規則一覽在 [在 CI 中用規格檢查器檢查規格](https://specscore.md/zh-tw/articles/lint-specs-in-ci/)。

格式授權是 [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)，在 [specscore/specscore](https://github.com/specscore/specscore)。CLI 授權是 [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)，在 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。

其他規範驅動工具公布的檢查各不相同。下面的句子只用那些專案自己的頁面所說的內容。[工具彙整](https://specscore.md/zh-tw/spec-driven-development/tools/)把同樣的頁面記為 2026年10月30日讀過，Spec Kit 文件首頁除外，那一頁印著 2026年9月28日。

[OpenSpec](https://github.com/Fission-AI/OpenSpec) 記錄了 `openspec validate`，寫在它的 [CLI 參考](https://openspec.dev/docs/cli) 裡。該命令檢查 OpenSpec 的變更和規格結構，驗證失敗時以非零結束。它不檢查 SpecScore 的 `### AC:` 標題，也不檢查 SpecScore 的索引。

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

[GitHub Spec Kit](https://github.github.io/spec-kit/) 描述一套代理工作流程，其階段寫下 Markdown 產物。那份文件首頁沒有描述一條在 CI 中檢查 SpecScore 功能 README 的命令。那些工具的比較是 [工具彙整](https://specscore.md/zh-tw/spec-driven-development/tools/)。

## Claude Code 讀得懂的規格範本

這些檔案是 Markdown，所以讀得了儲存庫的代理，就讀得了這份範本。Claude Code 是 [CLI Skills](https://specscore.md/zh-tw/ai/cli-skills/) 頁面所針對的代理。該頁記錄了 `ai-plugin-specscore`，一個包住 CLI 的薄 Claude Code 外掛。外掛儲存庫是 [specscore/ai-plugin-specscore](https://github.com/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](https://specscore.md/zh-tw/ai/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 流程。[驗收標準規範](https://specscore.md/acceptance-criteria-specification)說，標準不得規定步驟。情境檔案則會寫出步驟。

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

不會。`specscore spec lint` 檢查的是結構：標題、必要的小節、索引列，以及 `P-001` 和 `P-002` 這樣的參照。它不判斷產品是不是個好主意。[在 CI 中用規格檢查器檢查規格](https://specscore.md/zh-tw/articles/lint-specs-in-ci/) 是對那條命令更長的說明。

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

能。範本是儲存庫裡的 Markdown。[CLI Skills](https://specscore.md/zh-tw/ai/cli-skills/) 外掛在 Claude Code 裡露出 `specscore spec lint`，以及功能和任務命令。`specscore agent setup claude` 為那個代理寫一份指示檔案。外掛不會另造一份範本。

### 計畫會取代功能規範嗎？

不會。功能 README 是需求和驗收標準的來源。計畫把該功能拆成任務，每條任務用 `**Verifies:**` 指回去。[計畫規範](https://specscore.md/plan-specification) 和 [任務規範](https://specscore.md/task-specification) 就是這次拆分的兩份文件。

## 來源

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日。

- [功能規範](https://specscore.md/feature-specification)
- [specscore/specscore — 功能規範](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md)
- [specscore/specscore — 需求規範](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md)
- [驗收標準規範](https://specscore.md/acceptance-criteria-specification)
- [specscore/specscore — 驗收標準規範](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md)
- [specscore/specscore — 情境規範](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md)
- [計畫規範](https://specscore.md/plan-specification)
- [specscore/specscore — 計畫規範](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md)
- [任務規範](https://specscore.md/task-specification)
- [specscore/specscore — 任務規範](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md)
- [specscore/specscore — 產物 frontmatter 約定](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md)
- [specscore/specscore](https://github.com/specscore/specscore)
- [specscore/specscore — CC BY 4.0 授權](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli](https://github.com/specscore/specscore-cli)
- [specscore-cli — Apache-2.0 授權](https://github.com/specscore/specscore-cli/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml（CLI v0.39.1）](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specscore-cli v0.55.1 — ac-heading-format](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go)
- [specscore-cli v0.55.1 — 計畫規則 P-001 與 P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go)
- [在 CI 中用規格檢查器檢查規格](https://specscore.md/zh-tw/articles/lint-specs-in-ci/)
- [寫出 AI 代理驗得過的驗收標準](https://specscore.md/zh-tw/articles/acceptance-criteria/)
- [EARS 需求語法詳解與範例](https://specscore.md/zh-tw/articles/ears-requirements/)
- [CLI Skills — Claude Code 裡的 SpecScore CLI](https://specscore.md/zh-tw/ai/cli-skills/)
- [SpecStudio Skills](https://specscore.md/zh-tw/ai/specstudio-skills/)
- [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore)
- [SpecScore 驗證什麼](https://specscore.md/zh-tw/validators/)
- [Rehearse](https://specscore.md/rehearse)
- [OpenSpec CLI 參考 — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)
- [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master)
- [GitHub Spec Kit 文件（頁面日期 2026年9月28日）](https://github.github.io/spec-kit/)
- [規範驅動開發工具](https://specscore.md/zh-tw/spec-driven-development/tools/)

## 相關

- [用 Claude Code 和 Cursor 做規範驅動開發](https://specscore.md/zh-tw/articles/claude-code-specs/)
- [功能規範](https://specscore.md/feature-specification)
- [驗收標準規範](https://specscore.md/acceptance-criteria-specification)
- [計畫規範](https://specscore.md/plan-specification)
- [任務規範](https://specscore.md/task-specification)
- [寫出 AI 代理驗得過的驗收標準](https://specscore.md/zh-tw/articles/acceptance-criteria/)
- [EARS 需求語法詳解與範例](https://specscore.md/zh-tw/articles/ears-requirements/)
- [在 CI 中用規格檢查器檢查規格](https://specscore.md/zh-tw/articles/lint-specs-in-ci/)
- [規範驅動開發](https://specscore.md/zh-tw/spec-driven-development/)
- [規範驅動開發工具](https://specscore.md/zh-tw/spec-driven-development/tools/)
- [給 Claude Code 用的 CLI Skills](https://specscore.md/zh-tw/ai/cli-skills/)
- [CLI](https://specscore.md/zh-tw/cli/)