1. 为什么“规范驱动开发”在AI编程时代突然变得不可绕过OpenSpec 这个词最近在技术社区里出现的频率已经快赶上“提示词工程”和“Agent编排”了。但很多人点开文档的第一反应是这不就是个写 YAML 的格式规范吗跟 AI 编程有啥关系我用 Cursor 写代码、用 Dify 拖节点、用 ComfyUI 连工作流不也挺好——这种想法非常真实我也这么想过直到我在一个需要交付给客户、要被第三方审计、且必须支持三年以上维护周期的 AI 辅助设计系统里连续踩了三次“看似无关紧要”的坑。第一次是提示词版本失控。我们团队五个人各自维护一套“生成电路板布局建议”的提示词有人加了温度参数有人删了约束条件有人把“禁止跨层布线”写成“尽量避免”结果模型输出的可制造性评估报告在测试环境和生产环境里给出完全相反的结论。没人能说清哪一版是对的因为没人记录过“这个提示词到底定义了什么业务规则”。第二次是工作流逻辑漂移。我们用 n8n 搭建了一个简历初筛流程PDF解析 → 关键词提取 → 岗位匹配度打分 → 邮件通知。上线两周后HR 提出要把“Python 经验”权重从 0.3 调到 0.45技术同学改完配置发现打分模块的输入结构变了——原来传的是纯文本现在前端加了个字段叫raw_content_hash而打分脚本没做兼容直接报错。没人知道这个字段是谁加的、为什么加、是否影响其他环节。第三次最致命合规审计失败。客户要求提供“AI决策链路的可追溯性证明”。我们拿出了所有日志、所有模型调用记录、所有工作流执行图……但审计方只问了一句话“请指出在‘岗位匹配度打分’这个环节中‘Python 经验’权重为 0.45 这一业务规则其来源、生效范围、变更审批记录分别对应哪个可验证的、独立于代码的权威定义” 我们哑口无言。那一刻我才明白不是 AI 不够聪明是我们没有给它一个“能被所有人共同理解、共同签署、共同遵守”的契约。OpenSpec 就是这份契约。它不是又一个“AI 工具”而是一种开发范式升级把过去散落在 README、Confluence、口头约定、甚至开发者脑回沟里的业务规则、接口契约、流程边界、质量约束全部收束到一份机器可读、人类可审、版本可控、变更可溯的规范文件里。OPSXOpenSpec Execution则是让这份契约真正活起来的执行引擎——它不写业务逻辑它只负责确保所有参与方人、模型、工具、服务都严格按契约行事。就像建筑行业的施工图纸图纸本身不盖楼但没有它钢筋工、水电工、监理方根本没法协同。OpenSpec 是 AI 时代的“施工图纸”OPSX 是那个拿着图纸逐项核验的“现场监理”。所以“规范驱动开发”不是给程序员多加一道工序而是把原本隐性的、高风险的、靠人肉对齐的协作成本显性化、标准化、自动化。它解决的从来不是“怎么让 AI 更聪明”而是“怎么让一群聪明的人和聪明的模型不因为彼此理解偏差而集体翻车”。当你开始为一个需要长期演进、多人协作、对外交付的 AI 系统构建工作流时OpenSpec 不是“可选项”而是你规避系统性熵增的唯一安全阀。2. OpenSpec 规范的本质一份面向 AI 协作的“三方协议”很多人把 OpenSpec 简单理解为“YAML 版本的 OpenAPI”这是个危险的误解。OpenAPI 描述的是 HTTP 接口的请求/响应结构它管的是“服务之间怎么通信”而 OpenSpec 描述的是AI 协作单元之间的契约关系它管的是“人、模型、工具之间关于‘做什么’、‘做成什么样’、‘谁来保证’的共识”。这份契约之所以必须存在是因为 AI 编程引入了三个前所未有的变量非确定性输出、能力黑箱化、执行主体多元化。一个 LLM 调用可能返回格式正确但语义错误的结果一个图像生成模型的能力边界远比 REST API 的 404 或 500 错误更模糊而一个工作流里可能同时混着 Python 脚本、Claude API、本地部署的 Stable Diffusion、甚至人工审核节点。OpenSpec 的核心价值就在于为这三类变量建立可协商、可验证、可执行的锚点。2.1 OpenSpec 文件的骨架四个不可分割的“契约支柱”一个最小可用的 OpenSpec 文件.openspec.yaml其结构绝非随意堆砌而是由四个相互咬合的契约支柱构成spec规范元数据这是契约的“法律效力声明”。它包含version规范版本号强制语义化版本、title人类可读的契约名称、description该契约要解决的核心业务问题例如“确保所有简历筛选结果均基于客户最新版 JD 权重规则”、owner契约责任方如hr-teamcompany.com。这里的关键是owner字段——它明确指出了当契约被违反时谁拥有最终解释权和修订权。这不是一个邮箱地址而是一个组织承诺。inputs输入契约这是对“上游”提供的数据的精确约束。它不只是定义字段名和类型更强调业务语义。例如inputs: job_description: type: object description: 客户提供的、经 HR 主管签字确认的正式岗位说明书 required: [title, required_skills, experience_years] properties: title: type: string description: 岗位官方名称需与内部职级体系完全一致 required_skills: type: array items: type: string description: 技能名称必须来自公司《技术栈白名单》v3.2 experience_years: type: number minimum: 2 maximum: 15 description: 最低要求年限取整数四舍五入注意description里嵌套的业务规则“白名单 v3.2”、“四舍五入”以及minimum/maximum对数值边界的硬性规定。这比 JSON Schema 严格得多因为它约束的是业务意图而非仅仅是数据格式。outputs输出契约这是对“下游”可依赖结果的终极承诺。它定义的不是“模型可能返回什么”而是“系统必须保证交付什么”。例如outputs: screening_report: type: object description: 一份可供 HR 直接用于面试邀约决策的结构化报告 required: [candidate_id, overall_score, skill_match_scores, compliance_flag] properties: overall_score: type: number minimum: 0 maximum: 100 description: 加权综合得分计算公式见附件《JD-Weighting-Logic-v2.1.pdf》 compliance_flag: type: boolean description: true 表示报告完全符合当前生效的《AI 简历审核合规手册》第4.7条这里compliance_flag是灵魂。它不是一个计算结果而是一个可验证的担保声明。OPSX 执行引擎在生成报告后必须调用一个独立的合规性校验器可能是另一个 OpenSpec 定义的服务来确认该标志位是否为true否则整个工作流视为失败。这把抽象的“合规要求”变成了一个可自动化的布尔值断言。workflow工作流契约这是对“执行过程”的刚性约束。它不描述具体实现比如用 Python 还是 Node.js而是定义状态转换的合法性。一个典型片段workflow: start: parse_pdf states: parse_pdf: type: action input: {pdf_bytes: $.raw_input.pdf} output: {text_content: $.result.text, page_count: $.result.pages} next: extract_keywords extract_keywords: type: action # 此处省略具体配置... next: score_matching score_matching: type: action # 此处省略具体配置... next: validate_compliance validate_compliance: type: action # 调用独立的合规校验服务 next: $default end: true关键在于next字段。它强制规定了状态流转的唯一合法路径。任何试图跳过validate_compliance直接进入end的行为都会被 OPSX 引擎拦截并报错。这杜绝了“为了赶进度临时注释掉校验步骤”的灰色操作。这四个支柱共同构成了一个闭环spec定义契约身份inputs约束入口outputs承诺出口workflow管控过程。它们缺一不可共同回答了 AI 协作中最根本的三个问题谁说了算spec什么能进来inputs什么才算完成outputs workflow。这才是 OpenSpec 区别于其他配置文件的底层逻辑。3. OPSX 工作流引擎如何让规范从纸面走向产线理解 OpenSpec 规范的静态结构只是第一步。真正的挑战在于如何让这份写在 YAML 里的“宪法”变成每天在服务器上跑、在 IDE 里调试、在 CI/CD 流水线里卡点的“活的法律”这就是 OPSXOpenSpec Execution引擎的核心使命。它不是另一个低代码平台而是一个规范感知型的执行中间件。它的设计哲学很朴素绝不替代你的代码只负责确保你的代码在规范划定的轨道内运行。3.1 OPSX 的三层执行模型从“契约解析”到“行为仲裁”OPSX 的执行并非线性流水而是一个分层仲裁的过程每一层都承担着不同的“守门人”职责第一层契约解析与静态验证Compile-Time Guardrail当你执行opsx validate --spec my-spec.yaml时OPSX 并不做任何实际计算它只做三件事语法与结构校验检查 YAML 是否合法spec/inputs/outputs/workflow四个顶级字段是否齐全workflow.states中的next指向是否都存在于states列表中。这相当于编译器的语法检查。语义一致性检查这是关键。它会扫描inputs中定义的required_skills字段然后去workflow的parse_pdf状态的output中查找是否有$.result.skills这样的路径被声明为输出。如果inputs要求“必须提供技能列表”而workflow的任何输出路径都无法产生这个列表OPSX 就会报错“Input requirement required_skills has no corresponding output path in workflow.” 这种跨章节的关联性检查是传统配置校验器做不到的。版本兼容性检查如果spec.version是1.2.0而你本地安装的 OPSX 引擎只支持1.0.x规范它会明确拒绝执行并提示你需要升级引擎。这保证了规范的演进不会导致旧系统无声崩溃。第二层运行时契约注入与上下文编织Runtime Context Weaving当opsx run --spec my-spec.yaml --input data.json启动时OPSX 才真正开始工作。它做的第一件事是将inputs和outputs的契约定义动态注入到每一个工作流节点的执行环境中。以score_matching节点为例它的 Python 脚本假设叫scorer.py本身并不知道什么是“客户最新版 JD 权重规则”。OPSX 在调用scorer.py之前会先读取my-spec.yaml中inputs.job_description.required_skills的定义并将其解析为一个带有元数据的对象例如{skills: [Python, SQL], source: whitelist-v3.2}然后作为额外的、只读的上下文参数--context传递给脚本。scorer.py的代码可以这样写import sys, json # 从标准输入读取主数据 input_data json.load(sys.stdin) # 从命令行参数读取 OPSX 注入的契约上下文 context json.loads(sys.argv[1]) if len(sys.argv) 1 else {} # 现在脚本可以安全地使用 context[source] 来决定加载哪个权重配置文件 weights_config load_weights_from_source(context[source]) # e.g., whitelist-v3.2 result calculate_score(input_data[resume_text], weights_config) print(json.dumps(result))这种设计彻底解耦了业务逻辑与契约规则。scorer.py只关心“怎么算分”而“用哪个规则来算分”这个决策权交给了 OpenSpec 规范本身。这正是“规范驱动”的精髓——规则在 YAML 里逻辑在代码里两者通过 OPSX 无缝缝合。第三层契约履行仲裁与异常熔断Execution Arbitration这是 OPSX 最体现“守门人”价值的一层。它全程监控工作流的每一步输出并与outputs契约进行实时比对当score_matching节点输出一个overall_score为105时OPSX 会立刻捕获这个违反maximum: 100的行为并中断流程抛出OutputContractViolationError: overall_score (105) exceeds maximum allowed value (100)。当validate_compliance节点返回{compliance_flag: false}时OPSX 不会简单地将这个false传给下游而是触发预设的“熔断策略”——它可以自动发送告警邮件给spec.owner或者将本次执行的完整 trace 数据存入审计数据库或者直接回滚到上一个已知的合规状态。更重要的是OPSX 会生成一份契约履行报告--report参数其中清晰列出哪些输入字段被成功验证、哪些输出字段被精确满足、哪些工作流状态被按契约执行、以及在哪个环节、因哪个具体契约条款被违反而导致了失败。这份报告就是你向审计方提交的“可追溯性证明”的核心证据。这三层模型让 OPSX 成为了一个强大的“契约翻译器”和“行为裁判员”。它不关心你的scorer.py是用 PyTorch 还是 TensorFlow 写的它只关心你是否在契约允许的范围内做出了契约所要求的输出。这种分离正是大规模、高可靠性 AI 系统得以构建的基石。4. 从零搭建一个真实场景用 OpenSpec OPSX 实现“MCU 固件需求变更影响分析”工作流理论讲得再透不如亲手搭一个能跑起来的实例。我们来做一个非常典型的工业场景一家 MCU微控制器芯片公司的固件团队需要快速评估一个新提出的硬件功能需求比如“增加 USB-C 充电握手协议支持”会对现有固件代码库产生哪些影响。过去这需要资深工程师花 2-3 天手动 grep、阅读文档、咨询硬件同事。现在我们用 OpenSpec 定义一个自动化工作流目标是输入一个自然语言需求描述输出一份结构化的、带引用链接的影响分析报告且报告中的每一项结论都必须能追溯到具体的 OpenSpec 契约条款。4.1 第一步定义核心契约.mcu-impact-analysis.openspec.yaml我们先不写一行代码只专注定义“这件事到底要达成什么共识”。根据前面的四个支柱我们写出规范spec: version: 1.0.0 title: MCU 固件需求变更影响分析服务 description: 自动化分析任意新增硬件功能需求对现有固件代码库、文档、测试用例的潜在影响范围 owner: firmware-archchipco.com inputs: hardware_requirement: type: object description: 由硬件架构师提交的、经评审会议纪要编号确认的需求描述 required: [text, meeting_minutes_id, hardware_block] properties: text: type: string description: 需求的自然语言描述需包含明确的协议名称或标准号如USB-C PD 3.1 meeting_minutes_id: type: string pattern: ^MM-[0-9]{6}$ description: 评审会议纪要的唯一ID格式为 MM-YYYYMM hardware_block: type: string enum: [USB, BLE, CAN, SPI, I2C] description: 需求所涉及的硬件功能模块 outputs: impact_report: type: object description: 一份供固件负责人决策的结构化影响分析报告 required: [summary, code_impact, doc_impact, test_impact, confidence_score] properties: summary: type: string description: 一句话结论必须包含高/中/低风险等级和立即行动/观察/无需干预建议 code_impact: type: array items: type: object required: [file_path, line_numbers, reason] properties: file_path: type: string description: 受影响源码文件的绝对路径必须存在于 git 仓库中 line_numbers: type: array items: {type: integer} description: 具体受影响的行号范围格式为 [start, end] reason: type: string description: 影响原因必须引用《固件架构指南》v4.2 第3.1节 confidence_score: type: number minimum: 0.0 maximum: 1.0 description: 分析结果的置信度低于0.7需人工复核 workflow: start: parse_requirement states: parse_requirement: type: action input: {requirement_text: $.hardware_requirement.text} output: {parsed_protocol: $.result.protocol, parsed_standard: $.result.standard} next: search_codebase search_codebase: type: action input: {protocol: $.parsed_protocol, standard: $.parsed_standard} output: {code_matches: $.result.matches} next: analyze_doc_references analyze_doc_references: type: action input: {code_matches: $.code_matches} output: {doc_links: $.result.links} next: generate_report generate_report: type: action input: {code_matches: $.code_matches, doc_links: $.doc_links} output: {report: $.result.report} next: validate_report validate_report: type: action # 调用一个独立的合规校验器检查 report 是否满足 outputs 契约 next: $default end: true这个规范文件就是我们整个工作的“宪法”。它明确了谁负责owner、输入必须是什么inputs、输出必须长什么样outputs、以及执行步骤的铁律workflow。注意outputs.code_impact[].reason的描述它强制要求所有分析结论都必须引用《固件架构指南》这确保了分析的权威性而不是某个 AI 模型的主观臆断。4.2 第二步编写可插拔的节点逻辑search-codebase.py现在我们为search_codebase这个状态编写具体的 Python 脚本。记住它不需要知道整个规范只需要处理 OPSX 注入的上下文#!/usr/bin/env python3 import sys, json, re, subprocess from pathlib import Path def main(): # 1. 读取 OPSX 注入的主输入来自 workflow.input try: input_data json.load(sys.stdin) protocol input_data.get(protocol, ) standard input_data.get(standard, ) except Exception as e: print(fERROR: Invalid input JSON: {e}, filesys.stderr) sys.exit(1) # 2. 读取 OPSX 注入的契约上下文来自 --context 参数 # 这里我们假设上下文里包含了代码库根路径和搜索策略 context {} if len(sys.argv) 1: try: context json.loads(sys.argv[1]) except Exception as e: print(fERROR: Invalid context JSON: {e}, filesys.stderr) sys.exit(1) repo_root context.get(repo_root, str(Path.cwd())) search_strategy context.get(strategy, grep) # 3. 执行搜索逻辑这里简化为 grep实际可调用 ctags 或 LSP matches [] if search_strategy grep: # 在固件源码目录下搜索协议关键词 for file_path in Path(repo_root).rglob(*.c): try: with open(file_path, r, encodingutf-8) as f: content f.read() # 简单的正则匹配实际应更复杂 if re.search(rf\b{re.escape(protocol)}\b, content, re.I): # 找到匹配行号 lines content.split(\n) for i, line in enumerate(lines, 1): if re.search(rf\b{re.escape(protocol)}\b, line, re.I): matches.append({ file_path: str(file_path.relative_to(repo_root)), line_numbers: [i], reason: Protocol keyword found in source }) except Exception as e: continue # 跳过无法读取的文件 # 4. 输出符合 outputs.code_impact 结构的 JSON # OPSX 会在后续步骤中验证这个输出是否满足契约 print(json.dumps({matches: matches})) if __name__ __main__: main()关键点在于脚本本身不硬编码repo_root或strategy它们都来自 OPSX 的注入。这意味着同一个search-codebase.py可以在开发环境repo_root./firmware-dev和生产环境repo_root/opt/firmware-prod无缝切换只需修改 OpenSpec 文件中的context配置即可。契约驱动了环境的可移植性。4.3 第三步集成与实测一次真实的“USB-C 充电”需求分析现在我们准备一个真实的输入文件usb-c-req.json{ hardware_requirement: { text: 为 MCU 增加对 USB-C 充电握手协议USB Power Delivery 3.1的支持需兼容现有 Type-A 充电器。, meeting_minutes_id: MM-202405, hardware_block: USB } }然后执行完整的 OPSX 工作流# 1. 首先验证规范本身是否合法 opsx validate --spec .mcu-impact-analysis.openspec.yaml # 2. 运行工作流注入必要的上下文repo_root 和 strategy opsx run \ --spec .mcu-impact-analysis.openspec.yaml \ --input usb-c-req.json \ --context {repo_root: ./firmware-src, strategy: grep} \ --report impact-report.json几秒钟后impact-report.json生成。打开它你会看到类似这样的结构化输出{ summary: 高风险。需立即行动USB 协议栈核心文件存在多处硬编码依赖需重构以支持 PD 3.1。, code_impact: [ { file_path: src/usb/usb_core.c, line_numbers: [142, 143], reason: Protocol keyword found in source }, { file_path: src/power/charger_ctrl.c, line_numbers: [88], reason: Protocol keyword found in source } ], confidence_score: 0.82 }更重要的是--report生成的审计报告会详细记录code_impact[0].file_path的值src/usb/usb_core.c是如何被search-codebase.py的输出所产生而这个输出又如何被outputs.code_impact.file_path的description“必须存在于 git 仓库中”所验证。整个链条环环相扣无可辩驳。这个例子展示了 OpenSpec OPSX 的威力它没有发明新的 AI 模型也没有取代工程师的思考。它只是把工程师的领域知识《固件架构指南》、团队的协作规则会议纪要 ID 格式、以及系统的物理约束代码库路径全部编码为一份机器可执行的契约。然后OPSX 这个“守门人”确保每一次自动化分析都严格遵循这份契约。这才是 AI 时代真正可持续、可审计、可信赖的“智能”。5. 踩坑实录那些 OpenSpec 新手必经的“顿悟时刻”从一个 OpenSpec 的好奇者到一个能用它构建生产级 AI 工作流的实践者中间隔着的不是技术鸿沟而是一系列“啊哈原来如此”的顿悟时刻。这些时刻往往伴随着一次失败的opsx run一次被validate拦下的git push或者一次审计会上尴尬的沉默。我把这些最痛、也最有价值的经验浓缩成三个核心顿悟它们比任何教程都更能帮你少走弯路。5.1 顿悟一不要在inputs里定义“你想让 AI 做什么”而要定义“你必须提供什么”这是新手最容易栽的第一个跟头。看着热词榜上“ai编程提示词”、“ai编程一些常用的skill”很多人的第一反应是我要把我的提示词模板一股脑儿塞进 OpenSpec 的inputs里于是写出这样的东西# ❌ 错误示范把提示词当输入 inputs: prompt_template: type: string description: 用于生成代码的提示词模板 default: 你是一个资深嵌入式工程师请基于以下需求生成 C 代码...这完全违背了 OpenSpec 的设计初衷。inputs是外部世界向你的工作流提供的、不可变的、事实性数据。一个提示词模板是你的工作流内部的“实现细节”它应该藏在search-codebase.py这样的节点脚本里或者作为context注入而不是暴露为inputs。把它放进来会导致两个灾难性后果契约污染prompt_template的任何微小改动比如加个标点都会导致spec.version必须升级进而触发所有下游消费者如 CI 流水线、监控系统的重新适配。这把本该稳定的“输入契约”变成了一个高频变动的“实现开关”。责任错位当模型输出错误时你是该怪prompt_template写得不好还是该怪inputs.hardware_requirement.text描述得不清晰把提示词放进inputs就等于把“如何解决问题”的责任推给了输入方。而 OpenSpec 的哲学是输入方只负责提供“问题是什么”解决方案的质量由工作流内部的outputs契约来保障。正确的做法是把提示词逻辑下沉到具体的节点实现中。如果你真的需要多个提示词变体应该用context来区分# ✅ 正确示范用 context 控制提示词变体 workflow: states: generate_code: type: action input: {requirement: $.hardware_requirement.text} # 不在这里定义 prompt而是在 context 里指定 next: validate_output然后在运行时通过--context {prompt_variant: strict-mode}来切换。generate_code.py脚本内部根据context[prompt_variant]加载不同的模板。这样inputs保持了稳定和纯粹而灵活性则由context和节点逻辑来承载。5.2 顿悟二outputs的description不是注释而是可执行的“验收测试用例”很多新手写完outputs就以为大功告成觉得description里写清楚就行。直到他们第一次看到opsx run报出OutputContractViolationError才恍然大悟OPSX 真的会去“读”这些description并把它翻译成代码级别的断言。例如你在outputs.impact_report.summary的description里写了“一句话结论必须包含高/中/低风险等级和立即行动/观察/无需干预建议”。OPSX 引擎或你集成的校验器会把这个句子自动解析为一个正则表达式断言# OPSX 内部可能执行的校验逻辑示意 import re summary report.get(summary, ) pattern r(高|中|低)风险.*?(立即行动|观察|无需干预) if not re.search(pattern, summary): raise OutputContractViolationError(summary does not match required pattern)所以description的写作本质上是在写自然语言版的单元测试用例。它必须是可形式化、可判定、无歧义的。像“内容要专业”、“表述要清晰”这种模糊描述OPSX 是无法处理的它只会让你的validate永远通过而run永远失败。实战技巧写description时强迫自己回答三个问题Q1这个字段的值是否可以用一个布尔表达式,in,re.match()来判断对错如果答案是“否”说明描述太模糊需要重写。Q2这个字段的值是否可以从输入数据中通过一个确定性的函数计算出来如果答案是“否”说明这个字段可能不该放在outputs而应该放在workflow的某个中间状态里。Q3如果这个字段的值错了是否会导致下游消费者人或系统做出错误决策如果答案是“否”那它很可能只是一个日志信息不该成为outputs的required字段。遵循这三个问题你的outputs契约就会从一堆漂亮的文字变成一张张坚不可摧的“质量防火墙”。5.3 顿悟三workflow的next不是“下一步做什么”而是“只有这一步才能做”这是最深刻、也最常被忽视的顿悟。新手常常把workflow当成一个简单的执行顺序列表认为next: validate_compliance只是告诉 OPSX “做完 A 就做 B”。但next的真正含义是在A状态成功完成后B是唯一被允许的、合法的后续状态。任何其他状态包括A自身、或C、或end都是非法的会被 OPSX 强制阻止。这个特性是 OpenSpec 实现“强一致性”的核心。它意味着你不能在score_matching节点的代码里偷偷加一个if condition: goto end的逻辑来跳过校验。OPSX 会像一个严厉的交通警察只认路标next不认司机你的代码的任何借口。因此设计workflow的本质是在绘制一张“状态机图”而next就是图上的有向边。一个健壮的workflow必须考虑所有可能的分支# ✅ 正确示范显式处理分支 workflow: start: parse_requirement states: parse_requirement: type: action next: check_complexity check_complexity: type: action # 这里可以有条件分支 choices: - variable: $.result.complexity_score numeric: {greaterThan: 8} next: escalate_to_architect - variable: $.result.complexity_score numeric: {lessThanOrEqual: 8} next: search_codebase escalate_to_architect: type: action # 发送邮件给架构师 next: wait_for_approval wait_for_approval: type: wait # 等待人工审批 next: search_codebase search_codebase: type: action next: generate_report generate_report: type: action next: validate_report validate_report: type: action # 如果校验失败回到等待审批形成闭环 on_failure: wait_for_approval next: $default end: true这个workflow显式地处理了“需求过于复杂”的情况引入了人工审批环节并且为校验失败提供了重试路径。它不再是线性的“流水线”而是一个有反馈、有兜底、有决策点的“活的系统”。当你开始用这种思维去设计workflow时你就真正理解了 OpenSpec 的力量——它不是在编排任务而是在编排协作的规则。这三个顿悟没有一个是关于“怎么安装”或“怎么写 YAML”的。它们全都是关于思维方式的切换从“写代码”切换到“写契约”从“做功能”切换到“定规则”从“跑通流程”切换到“保障履约”。掌握了这些你写的就不再是一个 OpenSpec 文件而是一份能在 AI 时代让团队、模型、系统真正高效、可信、可持续协作的“数字宪法”。