Spec Kit：讓编码代理先寫规格，再把任務推到實現

github-spec-kit-deep-analysis｜ · github-spec-kit-deep-analysis

github-spec-kit-deep-analysis｜ · github-spec-kit-deep-analysis 的專案脈絡：用 AI 编码代理做過專案的人都熟悉那種落差：你敲下一段需求，代理立刻吐出成百上千行程式碼，跑起來的那一刻却發現和你想的根本不是一回事。问題往往不在模型的程式碼能力，而在於沒人先把「要做什么、為什么做」讲清楚，代理只能凭一句 prompt 去猜。几十年來程式碼一直是國王，规格只是開工後就被丢掉的脚手架。github/spec-kit 把顺序反過來，它把规格當成流程的起点，這套思路叫 Spec-Driven Development。與其先寫程式碼、再指望意图在過程中幸存，不如先寫下意图，讓實現從一份寫定的规格裡長出來。

github-spec-kit-deep-analysis｜ · github-spec-kit-deep-analysis：核心判断是规格應當是可執行的，直接生成可用的實現，而不是僅僅為编码指個方向。底層的哲学是意图驱動：先定 what 再谈 how，在護栏與組织原则下寫规格，用多步精化取代一次成稿。它不是某個模型或某個 IDE 的附属品，而是一套能接進你現有代理的流程，决定權仍握在你手裡。把它跑起來很轻量：specify CLI 通過 uv 安裝，既可以直接 `uv tool install specify-cli` 從 PyPI 装，也可以钉到 GitHub 倉庫的某個發布標簽；前置条件也很朴素：Python 3.11 以上、Git、一個受支援的代理，以及 Linux、macOS 或 Windows 上的 uv 或 pipx。

github-spec-kit-deep-analysis｜把 what 和 how 切成两道先後關卡 · github-spec-kit-deep-analysis

github-spec-kit-deep-analysis｜把 what 和 how 切成两道先後關卡 · github-spec-kit-deep-analysis 的專案脈絡：装好 specify 這個指令行工具後，工作流的每一步都是一条显式指令，顺序是設計好的。先跑 `specify init my-project --integration copilot` 把專案骨架和代理集成搭起來，再用 `/speckit.constitution` 寫下這個專案要守的原则：程式碼质量、測試標準、性能要求、體驗一致性，這些约束会一路管住後面的每一步。接著 `/speckit.specify` 只谈要做什么和為什么做，刻意不碰技术栈；`/speckit.plan` 才轮到技术选型與架構。两者分開，是為了逼你在定方案前先把意图說透。`/speckit.tasks` 把方案拆成可執行的任務清單，`/speckit.implement` 再按清單逐条實現。如果中途發現程式碼偏离了规格，`/speckit.converge` 会把程式碼庫和 spec、plan、tasks 對照一遍，把剩下的活儿补成新任務。

github-spec-kit-deep-analysis｜把 what 和 how 切成两道先後關卡 · github-spec-kit-deep-analysis：還有几条可选指令來加固這条链，而且不添额外仪式感。`/speckit.clarify`（旧名 `/quizme`）在规划前拷问含糊之處；`/speckit.analyze` 在任務生成後、實現前做一致性與覆盖檢查；`/speckit.checklist` 生成校驗需求完整性的质量清單，作者比作「給英文寫的單元測試」；`/speckit.taskstoissues` 把任務清單转成 GitHub issues，讓跟踪發生在團隊本來就用的地方，不必有人把方案手動重錄進工單系統。

github-spec-kit-deep-analysis｜三十多種代理都能接，斜杠指令是同一套 · github-spec-kit-deep-analysis

github-spec-kit-deep-analysis｜三十多種代理都能接，斜杠指令是同一套 · github-spec-kit-deep-analysis 的專案脈絡：Spec Kit 不绑死某一家代理，README 列出它支援 30 多種 AI 编码代理，從指令行工具到 IDE 裡的助手都覆盖，具體清單随版本變化，跑 `specify integration list` 就能看到當前装了哪些。大多數代理把 spec-kit 暴露成 `/speckit.*` 這類斜杠指令；Codex CLI 和 Command Code 在 skills 模式裡用的是 `$speckit-*`；GitHub Copilot CLI 则走 `/agents` 去选中代理或在 prompt 裡直接点名。面向支援 skills 模式的集成，加 `--integration <agent> --integration-options='--skills'` 会把指令装成 agent skills 而不是斜杠提示檔案。這套「同一套流程、贴著不同代理的接口」的設計，意味著你换工具時不用重学一套方法論。

github-spec-kit-deep-analysis｜三十多種代理都能接，斜杠指令是同一套 · github-spec-kit-deep-analysis：你在一個代理裡寫下的规格，在另一個代理裡讀起來是同一份，所以這份產物比围著它的工具更長寿。這種可移植性正是重点：规格是你團隊拥有的文檔，不是锁在某一個產品裡的 prompt。核心之外，文檔站上的社区板块收集了社区貢獻的扩展、預設、bundle 和端到端走查，還有一個 friends 頁面列出在 Spec Kit 之上構建的專案。那些貢獻後面都附了一句提醒，值得认真對待：每一樣都由作者独立維護，所以安裝前你應當讀一讀源码，自行斟酌使用。

github-spec-kit-deep-analysis｜改它不难，團隊也能各自定製 · github-spec-kit-deep-analysis

github-spec-kit-deep-analysis｜改它不难，團隊也能各自定製 · github-spec-kit-deep-analysis 的專案脈絡：Spec Kit 的預設流程只是起点，它給了三層可改的空間。最轻的是專案本地覆盖，把檔案丢進 `.specify/templates/overrides/` 就能针對單個專案做一次性调整，不必另建預設；往上是 presets，用來改現有工作流的「長相」，比如强製合规导向的规格格式、换一套领域术语、或把整個流程本地化成另一種语言，也能把方法本身掰向 Agile、Kanban、Waterfall、jobs-to-be-done 或领域驱動設計，一個海盗腔调的 demo 展示了這種定製能走多远。再往上是 extensions，用來加核心沒有的新指令和能力，比如接 Jira、加實現後的程式碼评審，或引入 V 模型測試可追溯性。

github-spec-kit-deep-analysis｜改它不难，團隊也能各自定製 · github-spec-kit-deep-analysis：三者按優先級堆叠：專案本地最高，核心最低，模板在執行時自顶向下取第一個命中；執行 `specify extension add` 或 `specify preset add` 時，指令檔案会寫進代理目錄。再進一步，bundle 把一組扩展、預設、步骤打包成按角色划分的 setup，由一份手寫的 `bundle.yml` 描述；`specify bundle install <id>` 一条指令就能給產品经理、安全研究員或開發者配齐整套組件。安裝是幂等的，刪除也绝不会誤刪別的 bundle 還在用的东西，所有 catalog 操作都能對著本地或钉死的來源离線跑。bundle 自身又從專案、用戶、內置三種來源按優先級排成的 catalog 栈裡解析，每種來源带一個安裝策略：install-allowed 的可以装，discovery-only 的只在搜尋裡出現但拒绝安裝。

github-spec-kit-deep-analysis｜從空倉庫到老程式碼庫 · github-spec-kit-deep-analysis

github-spec-kit-deep-analysis｜從空倉庫到老程式碼庫 · github-spec-kit-deep-analysis 的專案脈絡：Spec Kit 不是只盯著從零開始的專案，已有的程式碼庫同樣適用。README 把適用場景分成三種：0-to-1 的绿地開發從高層需求一路生成可上線的應用；創意探索阶段鼓励同一需求並行试多種技术栈和交互方案，再挑最顺的；迭代增强则面向已有的老程式碼庫，一边加功能一边現代化遗留系統。對已有專案，它提醒你把工具链更新和规格演進分開：升級時刷新受管理的專案檔案，只有行為真的變了才去動 `specs/` 裡的產物，Evolving Specs 指南专門讲了這套棕色地循環。CLI 自己也能管自己：`specify self check` 只讀地查有沒有新版本，`specify self upgrade --dry-run` 先演习不真改，`specify self upgrade` 原地升到最新稳定版，`specify self upgrade --tag vX.Y.Z` 還能钉死某個發布標簽，連 dev、alpha、beta、rc 這類後缀都认。

github-spec-kit-deep-analysis｜從空倉庫到老程式碼庫 · github-spec-kit-deep-analysis：装 uv tool 時它底層跑 `uv tool install --force`，用 Ctrl+C 就能中断，`SPECIFY_UPGRADE_TIMEOUT_SECS` 變量控製安裝子進程最多能跑多久。在交付的工具之下，專案把自己做的研究框定為一組實驗性目標，而不是已经兑現的產品保證。它想證明這套流程不依赖任何特定的技术栈，想說明它能扛住云厂商、合规要求這類企業约束，想支援從 vibe-coding 到 AI-native 開發的不同用戶群體，還想驗證能延伸到升級與現代化的並行和迭代工作流。README 很坦诚地讲明這些仍是實驗，不是定論，這一点在你打算把它压到關键業務上之前，值得記在心裡。

編輯結論

github/spec-kit 把 Constitution、Specify、Plan、Tasks、Implement 和 Converge 串成可移植流程，並允許用扩展與預設改造它。 適合愿意先在隔离環境核對安裝、權限和版本行為的開發者，不適合把 README 的自报結果直接當成生產保證的人。先按文中專案专属指令跑最小流程，記錄實際輸出、日志和失败边界，再决定是否纳入日常工作。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes