PythonAI大前端
用 Codex + GitHub Spec-Kit 实践规格驱动开发
本文介绍如何使用 Codex 配合 GitHub Spec-Kit 进行规格驱动开发（SDD）实战。通过命令行工具初始化工作区，建立宪法、规格、计划、任务到实现的标准化流水线。重点讲解了 spec-kit 的初始化方式、目录结构、命令输入规则及分阶段实现策略，旨在将 AI 开发转化为可控的工程流程，确保需求不漂移、改动可追踪、产物可复现。适用于希望提升 AI 辅助编程规范性的开发者。
本文介绍如何使用 Codex 配合 GitHub Spec-Kit 进行规格驱动开发（SDD）实战。通过命令行工具初始化工作区，建立宪法、规格、计划、任务到实现的标准化流水线。重点讲解了 spec-kit 的初始化方式、目录结构、命令输入规则及分阶段实现策略，旨在将 AI 开发转化为可控的工程流程，确保需求不漂移、改动可追踪、产物可复现。适用于希望提升 AI 辅助编程规范性的开发者。
——命令行/操作流完整版本（聚焦 spec-kit 用法）
很多人用 AI 写代码是'想到什么问什么'：一句 prompt、生成一段代码、跑一下、再修一下。短期很快，但一旦需求变多、模块变复杂，这种方式很容易失控：方向漂移、上下文断裂、改动不可追踪，最后变成'能跑但不可控'。
这次用 Codex 配合 GitHub 的 Spec Kit（Spec-Driven Development / SDD） 跑了一遍完整链路： 宪法（Constitution）→ 规格（Spec）→ 计划（Plan）→ 任务（Tasks）→ 实现（Implement）。 核心变化不是'写得更快'，而是：每一步都有文件产物、流程可复现、AI 不容易跑偏。
文中只用'一个浏览器扩展项目'作为背景，不展开具体业务细节，重点讲 speckit 的初始化、命令输入方式、产物位置、推进节奏。
推荐是先创建项目目录，再初始化 Spec Kit：
mkdir my-project
cd my-project
接下来选一种初始化方式即可（目标一致：生成 .specify/ 等结构，并让 Codex 里出现 /prompts:speckit.* 指令）。
适合不想全局安装工具，只想在当前目录把工作区拉起来：
uvx --from git+https://github.com/github/spec-kit.git specify init --here --ai codex
没有
uv/uvx的话，先装uv（例如 macOS 可用brew install uv），再跑上面命令。
适合频繁使用：
uv tool install --from git+https://github.com/github/spec-kit.git specify
specify init --here --ai codex
如果习惯 pipx 管理 CLI：
pipx install git+https://github.com/github/spec-kit.git
specify init --here --ai codex
.specify/：Spec Kit 工作区（模板、脚本、记忆）
memory/constitution.md（宪法写在这里）templates/（spec/plan/tasks 的模板）scripts/（辅助脚本）.codex/：Codex 项目级 home
prompts/ ✅（关键：speckit 的 prompts 在这里）rules/、skills/、sessions/、log/ 等specs/<feature>/：每个功能/迭代的产物目录（spec/plan/tasks 等）src/：代码目录（等 implement 之后才会逐渐长出来）重点：这套结构里 prompts 在
.codex/prompts/，所以命令形式是/prompts:speckit.*。
在 Codex 输入框里执行 speckit 命令时，节奏固定：
/），例如：/prompts:speckit.plan也就是：先提交命令 → 再提交内容，两次回车完成一阶段。
目的：先把'护栏'写死，避免 AI 自由发挥跑偏。
/prompts:speckit.constitution
产物通常落在：.specify/memory/constitution.md
目的：只写'做什么/为什么'，把 MVP 与验收标准讲清楚，先不谈技术实现。
/prompts:speckit.specify
产物通常落在：specs/<feature>/spec.md
目的：把规格里容易分歧的灰区问死，减少返工。
/prompts:speckit.clarify
目的：把 spec 翻译成工程方案（模块划分、数据流、依赖、风险与降级）。
/prompts:speckit.plan
基于 constitution + spec，输出工程实现计划：模块边界、数据结构、构建方式、测试策略、风险与降级、里程碑。
产物通常落在：specs/<feature>/plan.md
目的：把 plan 变成可执行清单，明确依赖顺序与验收条件。
/prompts:speckit.tasks
请拆成阶段化 tasks：Setup → Foundational → Feature slices → Polish，并为每个任务写验收标准与依赖。
产物通常落在：specs/<feature>/tasks.md
目的：让 Codex 不是'随便写'，而是'按 tasks 逐条交付'。
/prompts:speckit.implement
先只实现 Phase 1（Setup）相关 tasks，完成后停止，并给出 build/test 的运行方式。
为什么要分阶段？因为这能保证你每一步都能跑起来、可回退、可审查，避免'几十个文件一波流大改动'。
当觉得 spec/plan/tasks 之间可能不一致，或者 implement 跑了一段后想检查是否'违宪'，就用 analyze：
/prompts:speckit.analyze
请检查 spec.md、plan.md、tasks.md 的一致性，是否遗漏验收项，是否违反 constitution 的隐私/性能/安全约束，并给出修订建议。
这一步适合当'质量闸门'，尤其在任务多、模块多时很管用。
Spec Kit + Codex 的价值不在于写多少代码，而在于把 AI 开发变成可控工程流程：
这套流程的最大收益是：复现性与可迭代性。你以后做任何新 feature，都可以在 specs/<new-feature>/ 里再走一遍同样流水线，工程不会越做越乱。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online