2026/8/24 2:50:20
FEATURED · 精选文章 
用 OpenSpec 做规范驱动开发从提案到归档的完整指南【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpecOpenSpec 是一个面向 AI 编程助手的规范驱动开发Spec-Driven Development框架它把需求写进版本库中的 Markdown 规范用增量变更Delta Changes追踪每次修改并让 AI 助手按依赖顺序逐个落地任务。下文以一个新需求从提出到归档的完整过程为主线逐段讲解对应的命令、文件结构与团队协作方式。第一步把想法变成变更文件夹如果方向还没想清楚可以先用/opsx:explore让 AI 读代码、权衡方案把计划打磨成形需求明确后执行/opsx:propose add-dark-mode会直接创建openspec/changes/add-dark-mode/目录其中包含proposal.md动机与范围、specs/需求与场景、design.md技术方案和tasks.md实现清单四类工件。习惯终端的开发者也可以用 CLI 完成同样的事openspec new change add-billing-api在终端直接创建变更脚手架--schema参数可指定工作流--json供脚本解析。每个变更都是彼此独立的文件夹这一点后面会解释为什么对并行开发很重要。openspec init还会根据--tools claude,cursor这类参数为已选的 30 多种 AI 工具生成对应的技能与斜杠命令配置。需求怎么写ADDED / MODIFIED / REMOVED 增量标记主规范存放在openspec/specs/是系统行为的唯一事实来源变更阶段不直接改它而是在openspec/changes/{id}/specs/capability-path/spec.md下写增量文件用操作头声明这次到底改了什么## ADDED Requirements、## MODIFIED Requirements、## REMOVED Requirements或## RENAMED Requirements。需求本身遵循固定句式### Requirement:后跟 SHALL 描述再挂#### Scenario:场景例如## ADDED Requirements ### Requirement: Theme selection The app SHALL let users switch between light and dark themes, defaulting to the system preference. #### Scenario: User toggles dark mode - **WHEN** the user clicks the theme toggle - **THEN** the app switches to dark mode and persists the choice要修改已有需求时用## MODIFIED标记这样每次调整在文件历史里都有明确记录归档后 delta 才会被合并进主规范。小步增量正是控制风险的手段单条需求的措辞争议只发生在几行 Markdown 上而不是几百行代码 diff 里。掌握进度status、instructions、view 三个命令查看某个变更的工件完成度与依赖阻塞用这条命令省略--change时交互式选择openspec status --change add-slash-command-support默认spec-drivenschema 下工件按 proposal → specs/design → tasks 的依赖图推进design与specs只依赖proposal、可以并行完成tasks则被前两者阻塞输出会直接标出来Change: add-dark-mode Schema: spec-driven Progress: 2/4 artifacts complete [x] proposal [x] specs [ ] design [-] tasks (blocked by: design)这背后的拓扑排序与状态检测逻辑由 artifact-graph 规范定义源码在src/core/artifact-graph/。写下一个工件时openspec instructions design --change add-dark-mode会聚合模板内容、项目上下文和依赖工件内容作为 AI 助手的创作输入加--json后isPlanningComplete、applyRequires等字段可直接被脚本消费。需要全局视角时运行openspec view进入交互式仪表板规范、活跃变更与归档历史一览无余收尾validate 校验与 archive 归档合并前用openspec validate检查变更与规范零 delta 会被直接拒绝除非.openspec.yaml声明skip_specs此时 status 会把 specs 阶段显示为显式跳过而非待办缺少## Purpose、## Requirements等必需章节时报错会附上可复制的最小骨架把 WHEN/THEN 写成普通列表项而非#### Scenario:头时校验器会给出转换示例提示。校验逻辑见 validator 源码。实现完成、变更合并到主分支后执行/opsx:archive或openspec archivedelta 被折叠进openspec/specs/变更目录移入openspec/changes/archive/YYYY-MM-DD-name/。归档前它还会检查任务是否全部完成避免半成品被合并。归档时机在团队里是个约定问题——推荐 PR 合并后再归档这样共享的specs/只随真正上线的代码前进。团队协作变更即文件夹OpenSpec 不碰 gitOpenSpec 只读写openspec/下的纯 Markdown从不 commit、branch 或 push因此可以直接叠在现有 PR 流程上开分支 → propose 起草计划 → 评审方先读proposal.md与 delta 规范、再读代码 diff → apply 实现 → PR 同时携带规范 delta 与代码 → 合并后归档。并行开发时add-dark-mode和rate-limit-login分属不同文件夹、不同分支互不干扰真正的冲突点只有一个——两个变更修改同一条需求并在归档时合并到同一个spec.md此时按普通 git 冲突解决即可这恰恰是系统行为分歧的显式信号。原则是一个变更一个负责人跨仓库的规划则交给 beta 阶段的 Stores把规划放进独立仓库任何代码仓库都能通过--store id指向它详见 Stores 用户指南。自定义工作流 schema内置spec-drivenschema 的定义与模板位于 schemas/spec-driven/openspec schemas可列出全部可用 schema 及其工件流。团队若沉淀了 TDD 类流程用openspec templates --schema tdd查看该 schema 各工件的模板解析路径--json输出供程序化处理模板本身是 AI 助手生成工件的骨架替换模板即可改变产出风格。OpenSpec 适合已有代码库brownfield的单人或团队场景规范随代码一起进入版本历史进度随时可查每次行为变更在归档后的主规范里可回溯。把先对齐规范、再写代码固化为日常习惯AI 助手的产出边界会明显收窄在计划之内。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
用 OpenSpec 做规范驱动开发：从提案到归档的完整指南
用 OpenSpec 做规范驱动开发从提案到归档的完整指南【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpecOpenSpec 是一个面向 AI 编程助手的规范驱动开发Spec-Driven Development框架它把需求写进版本库中的 Markdown 规范用增量变更Delta Changes追踪每次修改并让 AI 助手按依赖顺序逐个落地任务。下文以一个新需求从提出到归档的完整过程为主线逐段讲解对应的命令、文件结构与团队协作方式。第一步把想法变成变更文件夹如果方向还没想清楚可以先用/opsx:explore让 AI 读代码、权衡方案把计划打磨成形需求明确后执行/opsx:propose add-dark-mode会直接创建openspec/changes/add-dark-mode/目录其中包含proposal.md动机与范围、specs/需求与场景、design.md技术方案和tasks.md实现清单四类工件。习惯终端的开发者也可以用 CLI 完成同样的事openspec new change add-billing-api在终端直接创建变更脚手架--schema参数可指定工作流--json供脚本解析。每个变更都是彼此独立的文件夹这一点后面会解释为什么对并行开发很重要。openspec init还会根据--tools claude,cursor这类参数为已选的 30 多种 AI 工具生成对应的技能与斜杠命令配置。需求怎么写ADDED / MODIFIED / REMOVED 增量标记主规范存放在openspec/specs/是系统行为的唯一事实来源变更阶段不直接改它而是在openspec/changes/{id}/specs/capability-path/spec.md下写增量文件用操作头声明这次到底改了什么## ADDED Requirements、## MODIFIED Requirements、## REMOVED Requirements或## RENAMED Requirements。需求本身遵循固定句式### Requirement:后跟 SHALL 描述再挂#### Scenario:场景例如## ADDED Requirements ### Requirement: Theme selection The app SHALL let users switch between light and dark themes, defaulting to the system preference. #### Scenario: User toggles dark mode - **WHEN** the user clicks the theme toggle - **THEN** the app switches to dark mode and persists the choice要修改已有需求时用## MODIFIED标记这样每次调整在文件历史里都有明确记录归档后 delta 才会被合并进主规范。小步增量正是控制风险的手段单条需求的措辞争议只发生在几行 Markdown 上而不是几百行代码 diff 里。掌握进度status、instructions、view 三个命令查看某个变更的工件完成度与依赖阻塞用这条命令省略--change时交互式选择openspec status --change add-slash-command-support默认spec-drivenschema 下工件按 proposal → specs/design → tasks 的依赖图推进design与specs只依赖proposal、可以并行完成tasks则被前两者阻塞输出会直接标出来Change: add-dark-mode Schema: spec-driven Progress: 2/4 artifacts complete [x] proposal [x] specs [ ] design [-] tasks (blocked by: design)这背后的拓扑排序与状态检测逻辑由 artifact-graph 规范定义源码在src/core/artifact-graph/。写下一个工件时openspec instructions design --change add-dark-mode会聚合模板内容、项目上下文和依赖工件内容作为 AI 助手的创作输入加--json后isPlanningComplete、applyRequires等字段可直接被脚本消费。需要全局视角时运行openspec view进入交互式仪表板规范、活跃变更与归档历史一览无余收尾validate 校验与 archive 归档合并前用openspec validate检查变更与规范零 delta 会被直接拒绝除非.openspec.yaml声明skip_specs此时 status 会把 specs 阶段显示为显式跳过而非待办缺少## Purpose、## Requirements等必需章节时报错会附上可复制的最小骨架把 WHEN/THEN 写成普通列表项而非#### Scenario:头时校验器会给出转换示例提示。校验逻辑见 validator 源码。实现完成、变更合并到主分支后执行/opsx:archive或openspec archivedelta 被折叠进openspec/specs/变更目录移入openspec/changes/archive/YYYY-MM-DD-name/。归档前它还会检查任务是否全部完成避免半成品被合并。归档时机在团队里是个约定问题——推荐 PR 合并后再归档这样共享的specs/只随真正上线的代码前进。团队协作变更即文件夹OpenSpec 不碰 gitOpenSpec 只读写openspec/下的纯 Markdown从不 commit、branch 或 push因此可以直接叠在现有 PR 流程上开分支 → propose 起草计划 → 评审方先读proposal.md与 delta 规范、再读代码 diff → apply 实现 → PR 同时携带规范 delta 与代码 → 合并后归档。并行开发时add-dark-mode和rate-limit-login分属不同文件夹、不同分支互不干扰真正的冲突点只有一个——两个变更修改同一条需求并在归档时合并到同一个spec.md此时按普通 git 冲突解决即可这恰恰是系统行为分歧的显式信号。原则是一个变更一个负责人跨仓库的规划则交给 beta 阶段的 Stores把规划放进独立仓库任何代码仓库都能通过--store id指向它详见 Stores 用户指南。自定义工作流 schema内置spec-drivenschema 的定义与模板位于 schemas/spec-driven/openspec schemas可列出全部可用 schema 及其工件流。团队若沉淀了 TDD 类流程用openspec templates --schema tdd查看该 schema 各工件的模板解析路径--json输出供程序化处理模板本身是 AI 助手生成工件的骨架替换模板即可改变产出风格。OpenSpec 适合已有代码库brownfield的单人或团队场景规范随代码一起进入版本历史进度随时可查每次行为变更在归档后的主规范里可回溯。把先对齐规范、再写代码固化为日常习惯AI 助手的产出边界会明显收窄在计划之内。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
