ForceInjection 的 OpenSpec 实践仓库（规格驱动开发的中文实践整理）

背景和目标

ForceInjection 在 GitHub 上维护 OpenSpec-practise 仓库（https://github.com/ForceInjection/OpenSpec-practise），围绕 OpenSpec 规格驱动开发流程整理中文手册、实践指南与协作命令。目标是把自然语言需求先转写为 proposal、spec、design、tasks 等结构化文档，再让 AI 助手按文档推进开发，在保留自然语言开发速度的同时提高复杂项目的可控性与可审查性。

本案例描述的是方法实践仓库而非单一产品项目——仓库本身就是案例的载体。

输入与条件

• 创作者：ForceInjection，中文开发者。
• 现有项目与开发工具链（Git、coding agent 等）。
• 一次需要修改或新增的功能、用户场景与验收标准。
• 团队或 Agent 跨会话持续协作的需要。

过程

1. 用 proposal 描述这次变更的原因与范围。
2. 把用户场景、行为与验收条件写入 spec。
3. 对复杂架构选择补充 design，记录关键技术决策。
4. 将实现拆为 tasks，让 Agent 一项一项执行。
5. 每项任务完成后运行测试并对照 spec 验收。
6. 完成变更后归档文档，保留决策与实施历史。

仓库中提供中文手册示范各阶段文档的写法，并展示如何让 AI 助手（典型如 Claude Code、tools/Codex-CLI）按这些文件推进开发。

产物或结果

• proposal、spec、design、tasks 等可追踪文件。
• 按规格实现并通过测试与 spec 验收的代码变更。
• 归档的决策与实施历史，供后续 Agent 会话或团队成员复用。
• 一份公开的中文实践手册，可供其他开发者复用工作流。

限制

• 仓库未对所有样例进行独立部署或性能测试，"提高可控性"的论断属于作者主张。
• OpenSpec 的具体命令和目录结构可能随上游版本变化，以收录时仓库版本为准（观察日期 2026-07-13）。
• 该方法增加前期文档成本，不适合一次性脚本或极小改动。
• 规格写错时，AI 会更稳定地实现错误目标——见 规格驱动开发中规格错误被稳定放大的风险。

相关教程和工具

• 仓库：OpenSpec-practise
• 工具：OpenSpec，可配合 Claude Code、tools/Codex-CLI
• 方法：规格驱动开发（Spec-driven development）配合 AI 助手
• 任务：把模糊需求整理成可验收的规格、让 coding agent 按任务清单逐项推进、为 AI 开发项目保留决策与实施历史

来源

来源：OpenSpec-practise，作者 ForceInjection，收录于 SRC-DEV-006。