AI 辅助编码变得很快但变得可预测的速度却慢得多。这正是规范驱动开发现在越来越受到关注的原因你不再将需求分散在聊天记录中而是将它们转化为人类和助手都能遵循的制品。OpenSpec 就是围绕这个理念构建的工具之一。它添加了一个轻量级的工作流让你先就变更达成一致生成规划制品然后根据这些制品进行实施。1、什么是规范驱动开发规范驱动开发Spec-driven development简称 SDD是一种在实施开始之前将规范作为唯一真相源的工作流。用 OpenSpec 的话来说它帮助你和你的 AI 编码助手在编写任何代码之前就构建内容达成一致。你不再依赖一个冗长的提示而是将工作分解为提案、规范、设计和任务等制品。这在重度使用 AI 的工作流中更为重要。一个好的助手可以快速生成大量代码但如果需求模糊结果通常是不一致的、不完整的或难以演进的。SDD 在不强制推行繁琐流程的情况下增加了结构。核心理念很简单描述变更、细化行为、规划工作然后根据达成一致的规范进行实施。OpenSpec 背后的一个优秀理念是工作流不被视为僵化的阶段关卡。其文档明确将模型定义为动作而非锁定的阶段因此你可以根据需要创建、实施、更新和归档。这使得它更符合真实的开发情况在真实开发中需求往往在实施进行中就已经发生变化。SDD 的发源地是 1960 年代的 NASA作为形式化开发和多重规范的结合体。所以我们在使用它时都可以感觉自己像太空探索者 )2、什么是 OpenSpecOpenSpec 是一个面向 AI 编码助手的规范驱动开发开源工具。该项目将自己描述为一个轻量级规范层帮助团队在编写代码之前就构建内容达成一致将每个变更组织在自己的文件夹中并通过生成的斜杠命令和技能与超过 20 个 AI 助手配合使用。OpenSpec 的主要目标是解决使用 AI 工具进行编码时可能出现的不可预测性和不一致性问题。由于 AI 工具是非确定性的它们可能难以持续遵循复杂的需求。OpenSpec 提供了一种结构化的方法允许团队和 AI 助手在编码开始之前就规范达成一致。这带来了更高效的开发、更少的错误和更好的代码质量。初始化后OpenSpec 会生成兼容的助手可以自动检测的指令。在其文档中这意味着位于.claude/skills/等位置的技能加上一个可选的项目配置文件openspec/config.yaml。默认模式是规范驱动的标准制品集包括提案、规范、设计和任务。OpenSpec 中一个特别有用的概念是增量规范delta specs的理念。你不需要每次都重写整个产品规范而是描述正在变化的部分。文档通过ADDED Requirements和MODIFIED Requirements等部分来呈现这一点这使得 OpenSpec 更适用于代码库已经存在的存量项目。我们将在接下来的章节中详细讨论这一点。3、如何安装 OpenSpecOpenSpec 需要Node.js 20.19.0 或更高版本。主要的README和安装文档展示了通过 npm 进行全局包安装以及 pnpm、yarn、bun 和 nix 的替代方案。node --version npm install -g fission-ai/openspeclatest如果你使用其他包管理器官方文档还列出了以下选项pnpm add -g fission-ai/openspeclatest yarn global add fission-ai/openspeclatest bun add -g fission-ai/openspeclatest4、如何使用 OpenSpec快速入门流程非常简单。安装 CLI进入你的项目运行openspec init然后在你的 AI 助手中通过/opsx:propose 你想要构建的内容启动工作流。文档中的默认快速路径是 propose → apply → archive。cd your-project openspec init此命令将在你的项目中创建以下目录结构openspec/ ├── specs/ # 唯一真相源你系统的行为描述 │ └── domain/ │ └── spec.md ├── changes/ # 拟议更新每个变更一个文件夹 │ └── change-name/ │ ├── proposal.md │ ├── design.md │ ├── tasks.md │ └── specs/ # 增量规范正在变化的内容 │ └── domain/ │ └── spec.md └── config.yaml # 项目配置可选两个关键目录specs/- 唯一真相源。这些规范描述了你系统的当前行为。按领域组织例如 specs/auth/、specs/payments/。changes/- 拟议变更。每个变更都有自己的文件夹包含所有相关制品。当变更完成后其规范将合并到主规范中。4.1 OpenSpec 制品每个变更文件夹包含指导工作的制品主要制品制品之间相互构建然后在你的 AI 助手中例如 Claude/opsx:propose Add dark theme support to the iOS app如果你想要一个更扩展的工作流OpenSpec 还支持诸如/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:sync、/opsx:bulk-archive和/opsx:onboard等命令。文档说这些命令通过openspec config profile选择工作流配置文件然后通过openspec update来启用。openspec config profile openspec updateOpenSpec 还可以通过openspec/config.yaml注入项目上下文和规则。官方文档展示了 schema、context 和针对每个制品的 rules 等字段当你希望 AI 始终遵循你的技术栈、风格、测试或架构期望时这非常有用。配置示例schema: spec-driven context: | Platform: iOS Language: Swift 6 UI: SwiftUI Architecture: MVVM Testing: XCTest Style: Keep features modular and accessibility-friendly rules: proposal: - Mention user-visible impact - Mention rollback strategy if theme breaks visual contrast specs: - Use Given/When/Then scenarios design: - Note persistence approach and affected views tasks: - Keep tasks small and implementation-ready4.2 什么是增量Delta以及为什么需要它OpenSpec 中最有用的概念之一是增量delta。简单来说增量是变更本身而不是从头重写的整个产品规范。OpenSpec 的概念文档将增量规范定义为描述正在添加、修改或删除的内容的规范。这很重要因为大多数实际工作发生在现有代码库中。你通常不是从零开始编写一个全新的产品规范。你是在添加暗色主题、更改引导流程、完善分析功能或替换遗留流程。每次都重写完整的规范会增加噪音使审查更加困难。增量规范将焦点保持在变化的部分。这也是增量与 AI 助手配合良好的原因。你不再告诉模型重新解释整个产品而是给它一个精确的目标实现这个差异。这使得输出更容易审查、更容易演进也更不容易偏离原始意图。最后一点是从 OpenSpec 的制品模型和工作流设计中推断出来的而不是文档中的直接引用。一个简单的理解方式完整规范 产品是什么增量规范 这个功能改变了什么典型的增量可以包含如下部分## ADDED Requirements ### Requirement: Manual Theme Override ## MODIFIED Requirements ### Requirement: Accessible Theme Colors ## REMOVED Requirements ### Requirement: Legacy Fixed Light Theme因此如果你的应用已经存在你想添加暗色模式增量不会描述整个应用。它只描述与主题支持相关的新的或变化的行为。这就是使规范更新随时间可管理的原因。5、示例iOS 添加暗色主题的规范这是 OpenSpec 非常适合的变更请求类型。想象一个现有的 SwiftUI 应用目前仅支持浅色主题现在你想正确地添加暗色模式而不是作为一个快速的视觉补丁。一个健壮的 OpenSpec 工作流通常从提案开始然后进入规范、设计说明和任务。OpenSpec 的文档将这些定位为默认模式中的标准制品其示例推荐使用小而结构化的任务和 Given/When/Then 风格的场景来描述需求。5.1 提案# Proposal: Add Dark Theme Support ## Summary Add full dark theme support to the iOS app so users can use the interface comfortably in low-light environments and align the app with modern iOS expectations. ## Motivation The app currently uses a light-only visual style. This creates poor visual comfort at night, makes the product feel less native on iOS, and limits accessibility for users who prefer darker interfaces. ## Goals - Support system light/dark appearance - Allow optional manual theme override in Settings - Persist user preference between launches - Update key screens and reusable components ## Non-Goals - Rebuild the design system from scratch - Add seasonal or branded themes - Change unrelated layout or navigation behavior ## Risks - Some screens may still use hard-coded colors - Charts, overlays, and custom backgrounds may need separate tuning - Contrast issues may appear on older screens ## Success Criteria - Main user flows look correct in light and dark mode - Theme switches without broken contrast - Manual selection persists after relaunch5.2 规范# Delta for Theme ## ADDED Requirements ### Requirement: System Theme Support The application MUST support both light and dark appearance modes. #### Scenario: Follow system appearance - GIVEN the user has not selected a manual theme override - WHEN the iOS system appearance changes between light and dark - THEN the application updates its appearance automatically ### Requirement: Manual Theme Override The application MUST allow the user to choose Light, Dark, or System in Settings. #### Scenario: Select dark theme manually - GIVEN the user opens Settings - WHEN the user selects Dark theme - THEN the application immediately applies dark appearance - AND the selection persists across app launches #### Scenario: Revert to system theme - GIVEN the user previously selected a manual theme - WHEN the user selects System - THEN the application follows the current iOS appearance again ### Requirement: Accessible Theme Colors The application MUST use theme-aware colors that preserve readable contrast in both appearances. #### Scenario: Readability in dark mode - GIVEN the app is displayed in dark mode - WHEN the user opens any primary screen - THEN text, icons, separators, and controls remain clearly readable5.3 设计# Design: Dark Theme Support ## Overview Implement a centralized theme layer for SwiftUI that supports: - system appearance - manual override - persistent storage - theme-aware semantic colors ## Architecture - Add AppTheme enum with cases: system, light, dark - Add ThemeStore as an observable state holder - Persist selected theme using AppStorage - Inject ThemeStore at the app root - Map theme selection to preferredColorScheme ## UI Impact Affected areas: - app root scene - settings screen - reusable buttons - cards and list rows - onboarding screens - charts and branded surfaces ## Edge Cases - legacy UIKit-hosted screens may ignore SwiftUI preference - hard-coded Color.white and Color.black usages must be replaced - image assets may require dark variants5.4 任务# Tasks ## 1. Theme Infrastructure - [ ] 1.1 Create AppTheme enum with system, light, dark - [ ] 1.2 Create ThemeStore observable object - [ ] 1.3 Persist selected theme with AppStorage - [ ] 1.4 Inject theme store into the app entry point ## 2. App Integration - [ ] 2.1 Apply preferredColorScheme at root level - [ ] 2.2 Add theme selector to Settings - [ ] 2.3 Ensure changes update UI immediately ## 3. UI Migration - [ ] 3.1 Replace hard-coded colors with semantic colors - [ ] 3.2 Audit reusable components - [ ] 3.3 Update custom backgrounds and overlays - [ ] 3.4 Test charts and illustrations in dark mode ## 4. Validation - [ ] 4.1 Test launch persistence - [ ] 4.2 Test system appearance switching - [ ] 4.3 Check accessibility contrast on key screens示例实施提示规划制品就位后你可以进入实施阶段。在 OpenSpec 的工作流中这就是/opsx:apply的角色它在实施任务的同时允许根据需要更新制品。/opsx:apply Implement the dark theme change for the SwiftUI iOS app. Respect the existing architecture. Use semantic colors where possible. Add manual theme selection in Settings. Persist the selected option. Flag any screens that still depend on hard-coded colors.6、进一步编辑首次实施后完善规范这是 OpenSpec 比单个大提示更有用的地方。在第一轮之后你经常会发现遗漏的细节。也许主题功能有效但图表仍然看起来不对引导插图太亮或者 UIKit 桥接忽略了选择的模式。OpenSpec 的文档明确支持在工作过程中更新制品其增量规范模型正是为了描述这些变化而构建的而不是重写所有内容。例如在审查了首次实施后你可能会这样扩展规范## MODIFIED Requirements ### Requirement: Accessible Theme Colors The application MUST use theme-aware colors that preserve readable contrast in both appearances, including charts, onboarding graphics, and empty states. #### Scenario: Charts in dark mode - GIVEN the app is displayed in dark mode - WHEN the user opens an analytics or chart-based screen - THEN chart axes, grid lines, labels, and highlighted values remain readable - AND color choices preserve sufficient contrast against the background你可以添加后续任务## 5. Dark Mode Polish - [ ] 5.1 Tune chart palette for dark backgrounds - [ ] 5.2 Add dark-compatible illustration assets where needed - [ ] 5.3 Audit UIKit-hosted views for color-scheme mismatch - [ ] 5.4 Re-test Settings, onboarding, and analytics screens这种迭代循环可能是 OpenSpec 方法中最强大的部分。你不是简单告诉助手修复暗色模式。你更新了唯一真相源然后从一个更好的制品集重新实施。为什么 OpenSpec 对 iOS 工作很有价值对于 iOS 开发来说OpenSpec 在大于单文件变更但小于完整 RFC 流程的功能工作中特别有用。暗色主题、引导流程重设计、分析埋点、订阅流程、付费墙实验或小组件更新都能从助手开始接触代码之前共享的行为定义中受益。它也比仅靠提示的编码方式更符合应用开发的现实。移动端工作通常包括 UI 状态、无障碍、持久化、迁移问题、资源变体、平台约定有时还有遗留 UIKit 或扩展目标。结构化的规范使这些细节在多个 AI 辅助的实施步骤中更容易保持。7、竞争对手说实话还有一个 Kiro。它将自己定位为一个围绕规范驱动开发、自定义代理和结构化工作流构建的 AI 开发环境而非仅靠提示的编码。最有趣的部分是强调从快速原型转向带有可执行规范、引导控制以及 IDE 和 CLI 支持的生产工作。但它有一个积分系统。8、结束语规范驱动开发本质上是对一个新问题的回应代码生成变得很快但可靠的意图传递却没有跟上。OpenSpec 通过围绕提案、规范、设计和任务构建的轻量级工作流加上一套对助手友好的命令和项目配置填补了这一空白。它不是要取代编码。它是要使 AI 生成的编码更具意图性、可审查性和可重复性。对于 iOS 团队甚至独立开发者来说这足以在不将每个功能变成文档项目的情况下提高可预测性。原文链接使用 OpenSpec 进行规范驱动开发 - 汇智网
使用 OpenSpec 进行规范驱动开发
AI 辅助编码变得很快但变得可预测的速度却慢得多。这正是规范驱动开发现在越来越受到关注的原因你不再将需求分散在聊天记录中而是将它们转化为人类和助手都能遵循的制品。OpenSpec 就是围绕这个理念构建的工具之一。它添加了一个轻量级的工作流让你先就变更达成一致生成规划制品然后根据这些制品进行实施。1、什么是规范驱动开发规范驱动开发Spec-driven development简称 SDD是一种在实施开始之前将规范作为唯一真相源的工作流。用 OpenSpec 的话来说它帮助你和你的 AI 编码助手在编写任何代码之前就构建内容达成一致。你不再依赖一个冗长的提示而是将工作分解为提案、规范、设计和任务等制品。这在重度使用 AI 的工作流中更为重要。一个好的助手可以快速生成大量代码但如果需求模糊结果通常是不一致的、不完整的或难以演进的。SDD 在不强制推行繁琐流程的情况下增加了结构。核心理念很简单描述变更、细化行为、规划工作然后根据达成一致的规范进行实施。OpenSpec 背后的一个优秀理念是工作流不被视为僵化的阶段关卡。其文档明确将模型定义为动作而非锁定的阶段因此你可以根据需要创建、实施、更新和归档。这使得它更符合真实的开发情况在真实开发中需求往往在实施进行中就已经发生变化。SDD 的发源地是 1960 年代的 NASA作为形式化开发和多重规范的结合体。所以我们在使用它时都可以感觉自己像太空探索者 )2、什么是 OpenSpecOpenSpec 是一个面向 AI 编码助手的规范驱动开发开源工具。该项目将自己描述为一个轻量级规范层帮助团队在编写代码之前就构建内容达成一致将每个变更组织在自己的文件夹中并通过生成的斜杠命令和技能与超过 20 个 AI 助手配合使用。OpenSpec 的主要目标是解决使用 AI 工具进行编码时可能出现的不可预测性和不一致性问题。由于 AI 工具是非确定性的它们可能难以持续遵循复杂的需求。OpenSpec 提供了一种结构化的方法允许团队和 AI 助手在编码开始之前就规范达成一致。这带来了更高效的开发、更少的错误和更好的代码质量。初始化后OpenSpec 会生成兼容的助手可以自动检测的指令。在其文档中这意味着位于.claude/skills/等位置的技能加上一个可选的项目配置文件openspec/config.yaml。默认模式是规范驱动的标准制品集包括提案、规范、设计和任务。OpenSpec 中一个特别有用的概念是增量规范delta specs的理念。你不需要每次都重写整个产品规范而是描述正在变化的部分。文档通过ADDED Requirements和MODIFIED Requirements等部分来呈现这一点这使得 OpenSpec 更适用于代码库已经存在的存量项目。我们将在接下来的章节中详细讨论这一点。3、如何安装 OpenSpecOpenSpec 需要Node.js 20.19.0 或更高版本。主要的README和安装文档展示了通过 npm 进行全局包安装以及 pnpm、yarn、bun 和 nix 的替代方案。node --version npm install -g fission-ai/openspeclatest如果你使用其他包管理器官方文档还列出了以下选项pnpm add -g fission-ai/openspeclatest yarn global add fission-ai/openspeclatest bun add -g fission-ai/openspeclatest4、如何使用 OpenSpec快速入门流程非常简单。安装 CLI进入你的项目运行openspec init然后在你的 AI 助手中通过/opsx:propose 你想要构建的内容启动工作流。文档中的默认快速路径是 propose → apply → archive。cd your-project openspec init此命令将在你的项目中创建以下目录结构openspec/ ├── specs/ # 唯一真相源你系统的行为描述 │ └── domain/ │ └── spec.md ├── changes/ # 拟议更新每个变更一个文件夹 │ └── change-name/ │ ├── proposal.md │ ├── design.md │ ├── tasks.md │ └── specs/ # 增量规范正在变化的内容 │ └── domain/ │ └── spec.md └── config.yaml # 项目配置可选两个关键目录specs/- 唯一真相源。这些规范描述了你系统的当前行为。按领域组织例如 specs/auth/、specs/payments/。changes/- 拟议变更。每个变更都有自己的文件夹包含所有相关制品。当变更完成后其规范将合并到主规范中。4.1 OpenSpec 制品每个变更文件夹包含指导工作的制品主要制品制品之间相互构建然后在你的 AI 助手中例如 Claude/opsx:propose Add dark theme support to the iOS app如果你想要一个更扩展的工作流OpenSpec 还支持诸如/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:sync、/opsx:bulk-archive和/opsx:onboard等命令。文档说这些命令通过openspec config profile选择工作流配置文件然后通过openspec update来启用。openspec config profile openspec updateOpenSpec 还可以通过openspec/config.yaml注入项目上下文和规则。官方文档展示了 schema、context 和针对每个制品的 rules 等字段当你希望 AI 始终遵循你的技术栈、风格、测试或架构期望时这非常有用。配置示例schema: spec-driven context: | Platform: iOS Language: Swift 6 UI: SwiftUI Architecture: MVVM Testing: XCTest Style: Keep features modular and accessibility-friendly rules: proposal: - Mention user-visible impact - Mention rollback strategy if theme breaks visual contrast specs: - Use Given/When/Then scenarios design: - Note persistence approach and affected views tasks: - Keep tasks small and implementation-ready4.2 什么是增量Delta以及为什么需要它OpenSpec 中最有用的概念之一是增量delta。简单来说增量是变更本身而不是从头重写的整个产品规范。OpenSpec 的概念文档将增量规范定义为描述正在添加、修改或删除的内容的规范。这很重要因为大多数实际工作发生在现有代码库中。你通常不是从零开始编写一个全新的产品规范。你是在添加暗色主题、更改引导流程、完善分析功能或替换遗留流程。每次都重写完整的规范会增加噪音使审查更加困难。增量规范将焦点保持在变化的部分。这也是增量与 AI 助手配合良好的原因。你不再告诉模型重新解释整个产品而是给它一个精确的目标实现这个差异。这使得输出更容易审查、更容易演进也更不容易偏离原始意图。最后一点是从 OpenSpec 的制品模型和工作流设计中推断出来的而不是文档中的直接引用。一个简单的理解方式完整规范 产品是什么增量规范 这个功能改变了什么典型的增量可以包含如下部分## ADDED Requirements ### Requirement: Manual Theme Override ## MODIFIED Requirements ### Requirement: Accessible Theme Colors ## REMOVED Requirements ### Requirement: Legacy Fixed Light Theme因此如果你的应用已经存在你想添加暗色模式增量不会描述整个应用。它只描述与主题支持相关的新的或变化的行为。这就是使规范更新随时间可管理的原因。5、示例iOS 添加暗色主题的规范这是 OpenSpec 非常适合的变更请求类型。想象一个现有的 SwiftUI 应用目前仅支持浅色主题现在你想正确地添加暗色模式而不是作为一个快速的视觉补丁。一个健壮的 OpenSpec 工作流通常从提案开始然后进入规范、设计说明和任务。OpenSpec 的文档将这些定位为默认模式中的标准制品其示例推荐使用小而结构化的任务和 Given/When/Then 风格的场景来描述需求。5.1 提案# Proposal: Add Dark Theme Support ## Summary Add full dark theme support to the iOS app so users can use the interface comfortably in low-light environments and align the app with modern iOS expectations. ## Motivation The app currently uses a light-only visual style. This creates poor visual comfort at night, makes the product feel less native on iOS, and limits accessibility for users who prefer darker interfaces. ## Goals - Support system light/dark appearance - Allow optional manual theme override in Settings - Persist user preference between launches - Update key screens and reusable components ## Non-Goals - Rebuild the design system from scratch - Add seasonal or branded themes - Change unrelated layout or navigation behavior ## Risks - Some screens may still use hard-coded colors - Charts, overlays, and custom backgrounds may need separate tuning - Contrast issues may appear on older screens ## Success Criteria - Main user flows look correct in light and dark mode - Theme switches without broken contrast - Manual selection persists after relaunch5.2 规范# Delta for Theme ## ADDED Requirements ### Requirement: System Theme Support The application MUST support both light and dark appearance modes. #### Scenario: Follow system appearance - GIVEN the user has not selected a manual theme override - WHEN the iOS system appearance changes between light and dark - THEN the application updates its appearance automatically ### Requirement: Manual Theme Override The application MUST allow the user to choose Light, Dark, or System in Settings. #### Scenario: Select dark theme manually - GIVEN the user opens Settings - WHEN the user selects Dark theme - THEN the application immediately applies dark appearance - AND the selection persists across app launches #### Scenario: Revert to system theme - GIVEN the user previously selected a manual theme - WHEN the user selects System - THEN the application follows the current iOS appearance again ### Requirement: Accessible Theme Colors The application MUST use theme-aware colors that preserve readable contrast in both appearances. #### Scenario: Readability in dark mode - GIVEN the app is displayed in dark mode - WHEN the user opens any primary screen - THEN text, icons, separators, and controls remain clearly readable5.3 设计# Design: Dark Theme Support ## Overview Implement a centralized theme layer for SwiftUI that supports: - system appearance - manual override - persistent storage - theme-aware semantic colors ## Architecture - Add AppTheme enum with cases: system, light, dark - Add ThemeStore as an observable state holder - Persist selected theme using AppStorage - Inject ThemeStore at the app root - Map theme selection to preferredColorScheme ## UI Impact Affected areas: - app root scene - settings screen - reusable buttons - cards and list rows - onboarding screens - charts and branded surfaces ## Edge Cases - legacy UIKit-hosted screens may ignore SwiftUI preference - hard-coded Color.white and Color.black usages must be replaced - image assets may require dark variants5.4 任务# Tasks ## 1. Theme Infrastructure - [ ] 1.1 Create AppTheme enum with system, light, dark - [ ] 1.2 Create ThemeStore observable object - [ ] 1.3 Persist selected theme with AppStorage - [ ] 1.4 Inject theme store into the app entry point ## 2. App Integration - [ ] 2.1 Apply preferredColorScheme at root level - [ ] 2.2 Add theme selector to Settings - [ ] 2.3 Ensure changes update UI immediately ## 3. UI Migration - [ ] 3.1 Replace hard-coded colors with semantic colors - [ ] 3.2 Audit reusable components - [ ] 3.3 Update custom backgrounds and overlays - [ ] 3.4 Test charts and illustrations in dark mode ## 4. Validation - [ ] 4.1 Test launch persistence - [ ] 4.2 Test system appearance switching - [ ] 4.3 Check accessibility contrast on key screens示例实施提示规划制品就位后你可以进入实施阶段。在 OpenSpec 的工作流中这就是/opsx:apply的角色它在实施任务的同时允许根据需要更新制品。/opsx:apply Implement the dark theme change for the SwiftUI iOS app. Respect the existing architecture. Use semantic colors where possible. Add manual theme selection in Settings. Persist the selected option. Flag any screens that still depend on hard-coded colors.6、进一步编辑首次实施后完善规范这是 OpenSpec 比单个大提示更有用的地方。在第一轮之后你经常会发现遗漏的细节。也许主题功能有效但图表仍然看起来不对引导插图太亮或者 UIKit 桥接忽略了选择的模式。OpenSpec 的文档明确支持在工作过程中更新制品其增量规范模型正是为了描述这些变化而构建的而不是重写所有内容。例如在审查了首次实施后你可能会这样扩展规范## MODIFIED Requirements ### Requirement: Accessible Theme Colors The application MUST use theme-aware colors that preserve readable contrast in both appearances, including charts, onboarding graphics, and empty states. #### Scenario: Charts in dark mode - GIVEN the app is displayed in dark mode - WHEN the user opens an analytics or chart-based screen - THEN chart axes, grid lines, labels, and highlighted values remain readable - AND color choices preserve sufficient contrast against the background你可以添加后续任务## 5. Dark Mode Polish - [ ] 5.1 Tune chart palette for dark backgrounds - [ ] 5.2 Add dark-compatible illustration assets where needed - [ ] 5.3 Audit UIKit-hosted views for color-scheme mismatch - [ ] 5.4 Re-test Settings, onboarding, and analytics screens这种迭代循环可能是 OpenSpec 方法中最强大的部分。你不是简单告诉助手修复暗色模式。你更新了唯一真相源然后从一个更好的制品集重新实施。为什么 OpenSpec 对 iOS 工作很有价值对于 iOS 开发来说OpenSpec 在大于单文件变更但小于完整 RFC 流程的功能工作中特别有用。暗色主题、引导流程重设计、分析埋点、订阅流程、付费墙实验或小组件更新都能从助手开始接触代码之前共享的行为定义中受益。它也比仅靠提示的编码方式更符合应用开发的现实。移动端工作通常包括 UI 状态、无障碍、持久化、迁移问题、资源变体、平台约定有时还有遗留 UIKit 或扩展目标。结构化的规范使这些细节在多个 AI 辅助的实施步骤中更容易保持。7、竞争对手说实话还有一个 Kiro。它将自己定位为一个围绕规范驱动开发、自定义代理和结构化工作流构建的 AI 开发环境而非仅靠提示的编码。最有趣的部分是强调从快速原型转向带有可执行规范、引导控制以及 IDE 和 CLI 支持的生产工作。但它有一个积分系统。8、结束语规范驱动开发本质上是对一个新问题的回应代码生成变得很快但可靠的意图传递却没有跟上。OpenSpec 通过围绕提案、规范、设计和任务构建的轻量级工作流加上一套对助手友好的命令和项目配置填补了这一空白。它不是要取代编码。它是要使 AI 生成的编码更具意图性、可审查性和可重复性。对于 iOS 团队甚至独立开发者来说这足以在不将每个功能变成文档项目的情况下提高可预测性。原文链接使用 OpenSpec 进行规范驱动开发 - 汇智网
