OpenSpec 完整教学:让 AI 编程助手听懂你在说什么

跟 AI 编程助手聊了半天，它写出来的东西跟你脑子里想的完全不一样——这种事太常见了。

问题出在需求描述不清。你说"加个暗黑模式"，AI 理解成换个深色背景；你说"优化性能"，它不知道从哪下手。聊天记录散落在对话框里，上周讨论过什么没人记得，每次新对话都得重新解释一遍。

没有 OpenSpec 时的典型场景：

You: 帮我加个暗黑模式AI:  好的，我来添加一个暗黑模式。     [生成了 500 行代码，但用了你不想要的 CSS 框架，      没考虑系统偏好检测，localStorage 也没做]You: 这不对，我要的是...AI:  抱歉，让我重新来。     [又生成 300 行，这次做了 localStorage，但样式全乱了]You: 样式不对，而且要支持跟随系统设置AI:  [继续改...]

来回折腾三四轮，时间浪费了，AI 也越改越糊涂。

有了 OpenSpec 之后：

You: /opsx:propose add-dark-modeAI:  我先生成一份规格说明，确认一下需求。     [自动生成 proposal.md、specs、design.md、tasks.md]     请检查一下这些文件，确认需求是否正确。You: [检查后发现少了一个需求，直接在 specs 里补上]You: /opsx:applyAI:  按照规格说明逐项实施...     ✓ 1.1 创建 ThemeContext     ✓ 1.2 添加 CSS 自定义属性     ✓ 1.3 实现 localStorage 持久化     ✓ 2.1 创建 ThemeToggle 组件     ...     全部完成！

一次到位。AI 在动手之前，已经通过规格说明跟你对齐了需求。

OpenSpec 是 Fission-AI 推出的开源规范框架，在你和 AI 之间加了一层"规格说明书"。说白了就是：先对齐要做什么，再动手写代码。

2025 年 8 月上线，GitHub 52000+ stars，支持 30 多种 AI 编程工具。

二、安装和初始化

需要 Node.js 20.19 以上版本：

npm install -g @fission-ai/openspec@latest

进入项目目录，跑初始化：

cd your-projectopenspec init

初始化时会让你选择用哪个 AI 工具（Cursor、Claude Code、Codex 等），然后自动生成对应的配置文件。

非交互式初始化，直接指定工具：

openspec init --tools cursor,claude

初始化完成后，项目根目录会多出一个 openspec/ 文件夹：

openspec/├── specs/              # 规格说明书（系统当前的行为描述）│   └── <domain>/│       └── spec.md├── changes/            # 正在进行的变更│   └── <change-name>/│       ├── proposal.md│       ├── design.md│       ├── tasks.md│       └── specs/      # 增量规格说明└── config.yaml         # 项目配置

specs/ 存放系统行为的真实描述，changes/ 里是正在规划或执行的修改。两者分开管理，互不干扰。

三、核心概念：两个目录的分工

搞清楚 specs/ 和 changes/ 的关系，就理解了 OpenSpec 的一半。

specs/ 是真相来源。 记录你的系统现在是怎么运作的——有什么功能、什么规则、什么约束。按领域组织，specs/auth/ 存认证，specs/payments/ 存支付。

changes/ 是提议的修改。 每个变更一个文件夹，包含这次修改的完整上下文。变更完成后，增量规格合并回 specs/，真相来源随之更新。

这种设计让你可以同时推进多个变更而不互相冲突。改完归档，规格自动更新，下一次变更基于最新的规格继续。

┌────────────────────────────────────────────────────────────────────┐│                        openspec/                                   ││                                                                    ││   ┌─────────────────────┐      ┌───────────────────────────────┐   ││   │       specs/        │      │         changes/              │   ││   │                     │      │                               │   ││   │  系统行为的真实描述   │◄─────│  正在提议的修改                │   ││   │  按领域组织          │ 归档 │  每个变更一个文件夹             │   ││   │                     │      │  包含规格和任务清单             │   ││   └─────────────────────┘      └───────────────────────────────┘   ││                                                                    │└────────────────────────────────────────────────────────────────────┘

四、四个工作产物详解

每个变更文件夹里有四个文件，各有分工：

四个文件之间有依赖关系：proposal 定义方向，specs 细化需求，design 规划技术方案，tasks 拆解成可执行步骤。但它们不是瀑布式的——实施过程中发现新情况，随时可以回头改前面的文件。

proposal.md 示例：

# Proposal: Add Dark Mode## Intent用户反馈夜间使用时眼睛疲劳，需要暗黑模式。## Scope- 在设置页面添加主题切换- 支持跟随系统偏好- 用 localStorage 持久化用户选择## ApproachCSS 自定义属性做主题变量，React Context 管理状态。

design.md 示例：

# Design: Add Dark Mode## Architecture### Theme Provider- React Context 存储当前主题状态- 支持三种模式：light、dark、system- 初始化时读取 localStorage，fallback 到 system### CSS Variables- 在 :root 和 [data-theme="dark"] 上定义颜色变量- 所有组件使用 var(--color-xxx) 引用- 切换主题时修改 data-theme 属性### Persistence- localStorage key: "theme-preference"- system 模式下监听 prefers-color-scheme 变化## Tradeoffs- CSS Variables 而非 CSS-in-JS：性能更好，兼容性更强- React Context 而非 Redux：状态简单，不需要全局状态管理

tasks.md 示例：

# Tasks## 1. 主题基础设施- [ ] 1.1 创建 ThemeContext，支持 light/dark/system 三种模式- [ ] 1.2 在 :root 和 [data-theme="dark"] 上定义颜色变量- [ ] 1.3 实现 localStorage 读写逻辑## 2. UI 组件- [ ] 2.1 创建 ThemeToggle 组件，支持三档切换- [ ] 2.2 添加到设置页面- [ ] 2.3 在 Header 添加快速切换按钮## 3. 样式适配- [ ] 3.1 定义暗色主题色板（背景、文字、边框、强调色）- [ ] 3.2 所有组件改用 CSS 变量- [ ] 3.3 处理图片和图标的暗色适配

五、增量规格：变更追踪的核心机制

增量规格（Delta Spec）是 OpenSpec 最有意思的设计。它不重写规格说明，而是用标记告诉你这次变更对原有规格做了什么：

# Delta for Auth## ADDED Requirements### Requirement: Two-Factor Authentication系统登录时必须要求二次验证。#### Scenario: OTP required- GIVEN 用户已启用 2FA- WHEN 用户提交正确的账号密码- THEN 弹出 OTP 验证界面## MODIFIED Requirements### Requirement: Session Timeout会话超时时间从 60 分钟改为 30 分钟。（之前是 60 分钟）#### Scenario: Idle timeout- GIVEN 一个已认证的会话- WHEN 30 分钟无活动- THEN 会话失效## REMOVED Requirements### Requirement: Remember Me（已被 2FA 取代）

归档的时候：

• • ADDED 的内容追加到主规格
• • MODIFIED 的替换原有内容
• • REMOVED 的删除

自动完成，不用手动合并。

六、全部指令详解

6.1 核心指令（core profile，默认可用）

/opsx:propose — 一步创建变更

最常用的起始指令。创建变更文件夹，一次性生成所有规划产物。

语法：

/opsx:propose [change-name-or-description]

参数：

• • change-name-or-description（可选）：kebab-case 名称或自然语言描述

它会做什么：

1. 1. 创建 openspec/changes/<change-name>/ 目录
2. 2. 生成 proposal.md
3. 3. 生成 specs/（增量规格）
4. 4. 生成 design.md
5. 5. 生成 tasks.md
6. 6. 停下来等你确认

示例：

You: /opsx:propose add-user-avatarAI:  Created openspec/changes/add-user-avatar/     ✓ proposal.md — 用户头像功能的需求和范围     ✓ specs/users/spec.md — 用户模块的增量规格     ✓ design.md — 技术方案     ✓ tasks.md — 实施清单     Ready for implementation. Run /opsx:apply.

使用技巧：

• • 用自然语言描述也行：/opsx:propose 给用户加一个头像上传功能
• • 想要更细粒度的控制？用扩展模式的 /opsx:new + /opsx:continue

/opsx:explore — 探索和调研

需求不清楚的时候先用这个。跟 AI 一起调研，不会生成任何文件。

语法：

/opsx:explore [topic]

参数：

• • topic（可选）：你想探索的主题

它会做什么：

1. 1. 打开一个探索性对话
2. 2. 分析代码库，回答你的问题
3. 3. 比较不同的技术方案
4. 4. 画图帮助理解
5. 5. 准备好后可以转入 /opsx:propose

示例：

You: /opsx:exploreAI:  你想探索什么？You: 移动端的认证方案该怎么设计？AI:  让我看看现有的认证架构...     [分析代码库]     你目前用的是 session 认证。移动端有三个选项：     1. JWT（无状态，支持离线）     2. OAuth2（需要第三方登录时）     3. 扩展现有 session（简单但需要网络）     你想走哪个方向？You: JWT 吧。AI:  好，运行 /opsx:propose add-jwt-auth 开始正式变更。

使用技巧：

• • 不确定需求时先探索，别急着创建变更
• • 探索阶段可以随时转入正式流程
• • AI 会读取代码库来回答问题

/opsx:apply — 实施任务

规格确认后，用这个指令开始写代码。

语法：

/opsx:apply [change-name]

参数：

• • change-name（可选）：要实施的变更名称（从上下文推断）

它会做什么：

1. 1. 读取 tasks.md
2. 2. 按顺序逐项实施
3. 3. 每完成一项打勾
4. 4. 实施过程中发现需要修改规格，会自动提醒

示例：

You: /opsx:applyAI:  Working through tasks for add-dark-mode...     ✓ 1.1 Created ThemeContext with light/dark/system modes     ✓ 1.2 Added CSS custom properties to globals.css     ✓ 1.3 Implemented localStorage persistence     ✓ 2.1 Created ThemeToggle component     ✓ 2.2 Added to settings page     ✓ 2.3 Added quick toggle to Header     ✓ 3.1 Defined dark theme color palette     ✓ 3.2 Updated components to use CSS variables     ✓ 3.3 Handled image/icon dark mode adaptation     All tasks complete! Run /opsx:archive when ready.

使用技巧：

• • 实施过程中发现规格有问题？直接改 specs 文件，AI 会按新规格继续执行
• • 可以指定变更名：/opsx:apply add-dark-mode
• • 被打断了？下次再跑 /opsx:apply 会从上次停下的地方继续

/opsx:sync — 同步规格

实施完成后，把增量规格合并到主规格。

语法：

/opsx:sync [change-name]

它会做什么：

1. 1. 读取变更的增量规格
2. 2. 按 ADDED/MODIFIED/REMOVED 规则合并到 specs/
3. 3. 显示合并结果

示例：

You: /opsx:syncAI:  Syncing specs for add-dark-mode...     ✓ ADDED: Theme Selection requirement → specs/ui/spec.md     ✓ ADDED: Theme Persistence requirement → specs/ui/spec.md     ✓ MODIFIED: None     ✓ REMOVED: None     Main specs updated. Ready to archive.

/opsx:archive — 归档变更

所有工作完成后，归档变更。

语法：

/opsx:archive [change-name]

它会做什么：

1. 1. 合并增量规格（如果还没 sync）
2. 2. 把变更文件夹移到 openspec/changes/archive/
3. 3. 更新 specs 为最新的真相来源

示例：

You: /opsx:archiveAI:  Archiving add-dark-mode...     ✓ Specs synced     ✓ Change archived to openspec/changes/archive/2026-06-02-add-dark-mode/     Ready for the next feature!

6.2 扩展指令（需要手动启用）

默认 profile 是 core，只包含上面 5 个指令。想用更多指令，切换 profile：

openspec config profile    # 选择 workflowsopenspec update            # 更新配置

/opsx:new — 创建变更骨架

只创建文件夹，不生成产物。适合想要逐步控制的情况。

语法：

/opsx:new [change-name] [--schema <schema-name>]

示例：

You: /opsx:new add-dark-modeAI:  Created openspec/changes/add-dark-mode/     Schema: spec-driven     Ready to create: proposal     Use /opsx:continue to create it, or /opsx:ff to create all artifacts.

/opsx:continue — 逐个生成产物

按照依赖顺序，一次生成一个产物。适合想要逐步审核的情况。

语法：

/opsx:continue [change-name]

示例：

You: /opsx:continueAI:  Change: add-dark-mode     Artifact status:     ○ proposal.md    — ready to create     ○ specs/         — blocked (needs proposal)     ○ design.md      — blocked (needs specs)     ○ tasks.md       — blocked (needs design)     Creating proposal.md...     ✓ proposal.md created     Next ready: specs/     Run /opsx:continue to create it.

/opsx:ff — 快速生成所有产物

一次性生成所有规划产物（proposal、specs、design、tasks）。

语法：

/opsx:ff [change-name]

示例：

You: /opsx:ffAI:  Creating all planning artifacts for add-dark-mode...     ✓ proposal.md     ✓ specs/ui/spec.md     ✓ design.md     ✓ tasks.md     Ready for implementation! Run /opsx:apply.

/opsx:verify — 验证实施是否符合规格

实施完成后，检查代码是否符合规格说明。

语法：

/opsx:verify [change-name]

检查三个维度：

1. 1. 完整性 — 所有任务都完成了吗？所有需求都有对应代码吗？
2. 2. 正确性 — 实现符合规格的意图吗？
3. 3. 一致性 — 代码和规格描述一致吗？

示例：

You: /opsx:verifyAI:  Verifying add-dark-mode...     COMPLETENESS     ✓ All 12 tasks in tasks.md are checked     ✓ All requirements in specs have corresponding code     ⚠ Scenario "System preference detection" not tested     CORRECTNESS     ✓ Theme toggle works as specified     ✓ localStorage persistence works     ✓ CSS variables defined correctly     CONSISTENCY     ✓ Implementation matches design.md     ⚠ Some components use hardcoded colors instead of variables     Issues found: 2     Run /opsx:apply to fix remaining issues.

/opsx:bulk-archive — 批量归档

同时归档多个已完成的变更。

语法：

/opsx:bulk-archive

示例：

You: /opsx:bulk-archiveAI:  Found 3 completed changes:     - add-dark-mode (all tasks done)     - fix-login-redirect (all tasks done)     - update-footer (all tasks done)     Checking for spec conflicts...     ⚠ add-dark-mode and update-footer both touch specs/ui/     Inspecting codebase to resolve...     Both changes are implemented. Will apply in chronological order.     Archive all 3 changes?You: YesAI:  ✓ Archived add-dark-mode     ✓ Archived fix-login-redirect     ✓ Archived update-footer     Specs merged in order: add-dark-mode → update-footer

/opsx:onboard — 新手引导教程

交互式教程，带你走一遍完整的 OpenSpec 流程。

语法：

/opsx:onboard

它会做什么：

1. 1. 分析你的代码库
2. 2. 找到一个小的改进点
3. 3. 创建一个真实的变更
4. 4. 逐步生成所有产物
5. 5. 实施并归档
6. 6. 总结整个流程

示例：

You: /opsx:onboardAI:  Welcome to OpenSpec!     I'll walk you through the complete workflow using your actual codebase.     We'll find something small to improve, create a proper change for it,     implement it, and archive it.     Let me scan your codebase for opportunities...     [分析代码库]     I found a few things we could work on:     1. Add input validation to the contact form     2. Improve error messages in the auth flow     3. Add loading states to async buttons     Which interests you? (or suggest something else)

使用技巧：

• • 第一次用 OpenSpec 就跑这个，15-30 分钟走完全流程
• • 用的是真实代码，不是玩具例子
• • 创建的变更可以保留也可以删掉

6.3 CLI 命令（终端使用）

除了斜杠指令，OpenSpec 还有一系列终端命令：

常用场景：

# 查看当前有哪些变更openspec list# 查看某个变更的状态openspec status --change add-dark-mode# 验证所有变更openspec validate --all# 归档一个变更openspec archive add-dark-mode

七、使用前后的对比

场景一：加一个新功能

没有 OpenSpec：

You: 帮我加一个用户头像上传功能AI:  好的，我来添加头像上传。     [生成代码，但没考虑文件大小限制、图片裁剪、      存储方案、默认头像等问题]You: 要支持裁剪AI:  [加了裁剪，但用了你不想要的第三方库]You: 不要用这个库，用原生 canvasAI:  [改了，但忘了处理大文件]You: 还要加文件大小限制...AI:  [继续改...]

有 OpenSpec：

You: /opsx:propose add-user-avatarAI:  [生成规格说明]     proposal.md: 头像上传功能，包含裁剪、大小限制、存储     specs/: 定义了 5 个需求，8 个场景     design.md: 用 canvas 裁剪，上传到 S3，CDN 分发     tasks.md: 12 个任务     请检查规格说明。You: [检查后补上了"默认头像"的需求]You: /opsx:applyAI:  [按照规格一次性完成所有任务]

场景二：修一个 Bug

没有 OpenSpec：

You: 登录有时候会失败AI:  我来看看...[分析后修了一个地方]You: 还是会失败AI:  [又修了一个地方]You: 好像好了，但不确定有没有其他问题

有 OpenSpec：

You: /opsx:explore 登录偶尔失败的问题AI:  让我分析一下...     [发现三个可能的原因]     1. Session 过期处理有问题     2. 并发请求导致 token 刷新冲突     3. 网络超时没有重试机制     你想先处理哪个？You: 先处理 token 刷新的问题You: /opsx:propose fix-token-refresh-raceAI:  [生成规格说明，明确了问题、修复方案、测试场景]You: /opsx:applyAI:  [按照规格修复，并验证所有场景]You: /opsx:verifyAI:  验证结果：     ✓ 所有任务完成     ✓ 所有场景通过     ✓ 代码和规格一致     可以归档了。

场景三：重构代码

没有 OpenSpec：

You: 把认证模块重构一下AI:  好的...[改了一堆代码]You: 这不对，原来的接口要保持兼容AI:  [又改...]You: 测试跑不过了AI:  [继续修...]

有 OpenSpec：

You: /opsx:explore 认证模块重构AI:  让我分析现有架构...     [分析代码库，画出依赖关系图]     现有模块有 3 个主要问题：     1. Session 和 JWT 混用     2. 没有统一的错误处理     3. 测试覆盖不足     重构建议：     - 保持现有接口不变     - 内部改为 JWT     - 添加统一的错误处理层     要开始正式变更吗？You: 好，开始You: /opsx:propose refactor-auth-moduleAI:  [生成规格说明，包含：     - 哪些接口保持不变（MODIFIED Requirements）     - 哪些内部实现要改（ADDED Requirements）     - 哪些废弃代码要删（REMOVED Requirements）     - 向后兼容性保证     - 测试场景]You: [仔细检查规格，确认接口兼容性]You: /opsx:applyAI:  [按照规格重构，每一步都打勾]You: /opsx:verifyAI:  验证结果：     ✓ 所有接口保持兼容     ✓ 所有测试通过     ✓ 代码符合新架构

八、工作流程详解

8.1 快速路径（默认）

/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive

最简单的流程，适合大部分场景。

8.2 扩展路径

/opsx:new → /opsx:ff → /opsx:apply → /opsx:verify → /opsx:archive

扩展模式适合需要更细粒度控制的情况。

8.3 探索路径

/opsx:explore → /opsx:propose → /opsx:apply → /opsx:archive

需求不清楚时先探索。

8.4 并行变更

Change A: /opsx:propose → /opsx:apply (进行中)                              │                         紧急 bug 需要修                              │Change B: /opsx:propose ───→ /opsx:apply → /opsx:archive回到 Change A: /opsx:apply add-dark-mode → 继续未完成的任务

8.5 何时更新现有变更 vs 创建新变更

更新现有变更：

• • 同一意图，调整执行方式
• • 范围缩小（先做 MVP，剩下的以后再说）
• • 实施过程中发现新情况，需要调整
• • 设计细节需要修改

创建新变更：

• • 意图根本改变了
• • 范围膨胀成了完全不同的工作
• • 原来的变更可以独立完成
• • 补丁会让人更困惑

九、如何很好地使用 OpenSpec

9.1 命名要具体

变更文件夹用描述性的名字：

好的命名：                    不好的命名：add-dark-mode                feature-1fix-login-redirect           updateoptimize-product-query       changesimplement-2fa                wip

9.2 保持变更聚焦

一个变更只做一件事。如果你在做"加功能 X 同时重构 Y"，拆成两个变更。

好处：

• • 更容易理解和审查
• • 归档历史更清晰
• • 可以独立发布
• • 出问题更容易回滚

9.3 需求不清楚时先探索

别急着创建变更。先用 /opsx:explore 调研：

You: /opsx:exploreAI:  你想探索什么？You: 我们要不要引入 GraphQL？AI:  让我看看你们现在的 API 架构...     [分析代码库]     你们目前用的是 REST，有 47 个端点。     引入 GraphQL 的话：     - 优点：减少 over-fetching，前端更灵活     - 缺点：学习曲线，需要重构现有端点     建议：先在一个新模块试水，不要全面迁移。     要开始一个试点变更吗？

9.4 归档前验证

用 /opsx:verify 检查实施是否符合规格：

You: /opsx:verifyAI:  Verifying add-dark-mode...     ✓ All tasks in tasks.md are checked     ✓ Requirements in specs have corresponding code     ✓ Design decisions are reflected in implementation     Ready to archive!

9.5 实施过程中可以改规格

发现规格有问题？直接改。OpenSpec 的设计就是支持迭代的：

You: /opsx:applyAI:  Working on task 3.2...     I found that some components use inline styles that     can't use CSS variables. Should I:     1. Refactor those components to use CSS variables     2. Add a fallback mechanism     What do you prefer?You: 选 1，顺便更新一下 design.mdAI:  ✓ Updated design.md with inline style refactoring approach     ✓ Refactored components to use CSS variables     ✓ Updated tasks.md to include the new task     Continuing...

9.6 用高推理能力的模型

OpenSpec 的效果跟模型能力直接相关。官方推荐：

• • Codex 5.5
• • Opus 4.7

弱模型生成的规格说明可能不够准确，需要更多人工修正。

9.7 保持上下文干净

开始实施前清理一下上下文窗口。规格文件本身会注入上下文，窗口里还有旧的对话记录容易互相干扰。

十、支持的工具

OpenSpec 支持 30 多种 AI 编程助手：

初始化时选择你用的工具，OpenSpec 会自动在对应目录生成 skill 文件和 command 文件。

十一、和其他工具的对比

对比 GitHub 的 Spec Kit

对比 AWS 的 Kiro

对比不用任何工具

十二、自定义和扩展

通过 schema 机制，你可以定义自己的产物类型和依赖关系。

创建自定义 Schema

openspec schema init my-workflow

这会创建一个 schema 配置文件，你可以定义：

• • 有哪些产物类型
• • 产物之间的依赖关系
• • 每个产物的模板

社区 Schema

社区有第三方 schema 包，提供针对特定场景的预设工作流：

• • 敏捷开发工作流
• • 文档驱动工作流
• • 测试驱动工作流

配置文件

配置文件在 openspec/config.yaml：

# 默认 schemaschema: spec-driven# 语言（影响生成的文档语言）language: zh-CN# 产物模板templates:  proposal: ./templates/proposal.md  design: ./templates/design.md

十三、常见问题排查

"Change not found"

指令找不到要操作的变更。

解决：

• • 明确指定变更名：/opsx:apply add-dark-mode
• • 检查变更文件夹是否存在：openspec list
• • 确认在正确的项目目录

"No artifacts ready"

所有产物要么已完成，要么被依赖阻塞。

解决：

• • 查看状态：openspec status --change <name>
• • 检查是否有缺失的依赖产物
• • 先创建缺失的依赖

"Schema not found"

指定的 schema 不存在。

解决：

• • 列出可用 schema：openspec schemas
• • 检查拼写
• • 如果是自定义 schema，先创建它

指令不被识别

AI 工具不认识 OpenSpec 指令。

解决：

• • 确认已初始化：openspec init
• • 重新生成技能文件：openspec update
• • 检查对应目录是否存在（比如 .claude/skills/）
• • 重启 AI 工具

产物生成不完整

AI 生成的产物有问题。

解决：

• • 在 openspec/config.yaml 里添加项目上下文
• • 用 /opsx:continue 而不是 /opsx:ff，逐步控制
• • 给变更描述里加更多细节

十四、总结

OpenSpec 解决一个问题：AI 编程助手需要明确的规格才能干活。

你说"加个暗黑模式"，AI 可能理解成十种不同的东西。OpenSpec 的做法是在动手之前，先让你们在一份规格说明上达成一致。规格确认了，再按任务清单一项项实施。

四个核心流程：/opsx:propose 创建变更 → /opsx:apply 实施 → /opsx:verify 验证 → /opsx:archive 归档。

两个关键目录：specs/ 存系统当前行为（真相来源），changes/ 存正在规划的修改。变更完成归档后，增量规格自动合并回 specs/。

适合用的人： 用 AI 编程助手写正经项目的开发者，尤其是需求经常变、需要并行处理多个功能的场景。

不太适合的情况： 只写一两行脚本、不愿意花时间写规格说明、或者用的模型太弱。

如果你用 AI 编程助手写代码，但总觉得产出质量不稳定——先跑一个 /opsx:onboard，15 分钟走完一遍，自己感受。