OpenSpec先对齐再让AI动手——规范驱动开发实战指南【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpecAI编码助手让写代码的门槛大幅降低但一个尴尬的问题也随之而来需求只存在于聊天记录里时AI会自信地写错。OpenSpec正是一个面向AI编码助手的规范驱动开发Spec-driven Development工具它用一份轻量的契约层让人和AI在动手写代码之前先就要构建什么达成共识。本文将从真实痛点切入跟随一次完整变更走完OpenSpec的整个工作流并拆解其跨平台、跨团队的设计考量为技术决策者和开发者提供一份可直接落地的实践参考。一、为什么AI越强大先想清楚越重要如果你已经让AI助手写过代码大概率经历过这样的场景一句帮我加个暗黑模式AI立刻生成了几百行改动看起来一切正常但仔细一检查——主题切换没持久化、系统偏好没检测、组件里硬编码了一堆颜色。问题不在AI的能力而在需求本身是模糊的。当需求只存在于聊天上下文里时AI只能靠猜测补全所有未言明的细节。一次误会在修改一段proposal时被发现成本几乎为零但当AI已经写完400行代码之后才发现方向错了返工成本会成倍放大。这正是OpenSpec要解决的核心矛盾AI编码助手需要一份双方都能读懂的行为契约而不是一段对话记录。OpenSpec的答案是给项目加一层轻量规范层先写清楚系统应该做什么再让AI动手。它的设计哲学很明确——灵活而非僵化、迭代而非瀑布、为存量项目而生而非只服务绿地项目。这不是又一套沉重的流程文档而是一个可以直接嵌入现有仓库、随代码一起版本化的规范体系。二、两个文件夹撑起整个心智模型OpenSpec的全部机制可以浓缩成一句话specs是真相changes是提案。初始化之后项目里会出现一个openspec/目录核心只有两块openspec/ ├── specs/ # 真相系统当前如何运作 │ └── domain/ │ └── spec.md ├── changes/ # 提案每个变更一个文件夹 │ └── change-name/ │ ├── proposal.md │ ├── design.md │ ├── tasks.md │ └── specs/ # 增量规范这次改什么 │ └── domain/ │ └── spec.md └── config.yaml # 项目配置可选specs/描述系统现在的行为按领域组织如auth/、payments/、ui/由需求Requirement和场景Scenario组成——需求用SHALL/MUST这类规范用语场景用WHEN/THEN格式给出可测试的例证。而changes/里每个变更文件夹装着这个功能的全部计划为什么做proposal、做什么specs、怎么做design、按什么顺序做tasks。这套设计最精妙的地方在于增量规范delta spec。在一个变更内部你不需要重写整个规范文件只需要描述变化## ADDED Requirements ### Requirement: Theme Selection The system SHALL allow users to choose between light and dark themes. #### Scenario: Manual toggle - GIVEN a user on any page - WHEN the user clicks the theme toggle - THEN the theme switches immediately - AND the preference persists across sessions为什么要费心写增量而不是整篇规范因为这让OpenSpec特别适合存量项目brownfield。给一个5万行的老应用加功能你不需要先花几周把整个系统的行为全部文档化——只需要写出这次改动的差异。这个描述差异而非目的地的设计是OpenSpec区别于许多重量级规范工具的关键。归档时ADDED需求追加进主规范MODIFIED需求替换旧版本REMOVED需求从主规范中删除变更文件夹则移入changes/archive/带日期戳的归档区。一个循环就此闭合提案变成真相系统重新处于可继续演进的状态。三、跟一个真实变更走完全程暗黑模式的五个动作把概念落地最快的方式是完整跟一遍流程。假设你要给应用加暗黑模式从想法到归档OpenSpec的默认工作流是五个动作/opsx:explore → /opsx:propose → /opsx:apply → /opsx:update → /opsx:archive (可选) 起草计划 实施构建 修订计划 归档合并第一步探索可选项。还没想清楚要做什么时可以先用/opsx:explore。它像一个零风险的思考伙伴读取你的代码、权衡方案、把模糊的想法打磨成具体计划——这个过程不会产生任何工件。已经明确目标的话可以直接跳到下一步。第二步提出变更。在AI助手的聊天框输入/opsx:propose add-dark-modeAI会在你的仓库里创建完整的变化包Created openspec/changes/add-dark-mode/ ✓ proposal.md — why were doing this, whats changing ✓ specs/ — requirements and scenarios ✓ design.md — technical approach ✓ tasks.md — implementation checklist Ready for implementation!此刻是人工审查的关键窗口。读一遍proposal确认动机、翻一遍specs确认行为边界、扫一遍tasks确认实施顺序——发现方向不对改一段Markdown的成本几乎为零。这正是规范驱动开发的价值兑现点代码还没写错误就已经被拦截。第三步实施。输入/opsx:applyAI按tasks.md的清单逐项实现每完成一项就勾选一个复选框进度实时可见✓ 1.1 Created ThemeContext with light/dark state ✓ 1.2 Added CSS custom properties to globals.css ✓ 1.3 Implemented localStorage persistence ✓ 2.1 Created ThemeToggle component ... All tasks complete!第四步修订。实现过程中发现设计需要调整直接输入/opsx:update。这个动作专门修订变更内的规划工件并自动检查其他工件是否需要连带更新保持计划整体连贯。它有两个重要护栏只改规划文件、绝不碰代码如果修订后的计划意味着代码改动会转交/opsx:apply处理同时它是schema驱动的读工件ID和路径都来自openspec status因此对自定义规范模式同样适用。值得注意的是连贯性是双向的——编辑design可能也需要回头修订proposal而不是简单地从上往下单向传播。第五步归档。全部完成后/opsx:archive把增量规范合并进openspec/specs/变更文件夹移入归档区系统重新回到真相与提案的清晰状态✓ Merged specs into openspec/specs/ui/spec.md ✓ Moved to openspec/changes/archive/2025-01-24-add-dark-mode/ Done! Ready for the next feature.五个动作构成一个闭环且每一步之间没有强制门禁——你可以随时回到任何一步修改工件。这些工件是使能器而不是关卡发现设计错了就改design.md继续走发现范围该收缩就更新proposal。依赖关系存在的目的只是确保AI在起草任务清单时有规范可依而不是把人框死。四、双脑分工终端CLI与聊天斜杠命令各司其职第一次接触OpenSpec的人最容易困惑的一个问题命令到底该敲在哪里答案其实很清晰——OpenSpec是一个项目两顶帽子。CLI是引擎。在终端运行openspec init、openspec list、openspec validate、openspec view。它掌握规则变更文件夹长什么样、工件之间如何依赖、增量规范如何合并进真相库。无论你用什么AI工具这个引擎的行为完全一致。斜杠命令是方向盘。在AI助手的聊天框输入/opsx:propose、/opsx:apply、/opsx:archive。它们告诉AI按OpenSpec的工作流行动。每个AI工具的方向盘形状略有不同——Claude Code用/opsx:proposeCursor和GitHub Copilot用/opsx-proposeAmazon Q用opsx-propose——但意图完全一致。openspec init会为你在init时选中的工具生成正确格式的命令文件。YOUR TERMINAL YOUR AI ASSISTANTS CHAT ┌──────────────────────┐ ┌──────────────────────────────┐ │ $ openspec init │ installs │ /opsx:propose add-dark-mode │ │ $ openspec list │ ──────────► │ /opsx:apply │ │ $ openspec view │ commands │ /opsx:archive │ └──────────────────────┘ skills └──────────────────────────────┘ run openspec here run /opsx:* here这个引擎与方向盘的拆分解释了OpenSpec为什么能适配30多种AI工具工作流只需学一次就能带着走遍所有助手。终端里的openspec view则提供了一个交互式仪表盘让技术管理者对规范资产一目了然。如图所示仪表盘将规范库的状态可视化规范数量与需求总数、进行中与已完成的变更、任务完成率以及每个变更的进度条。对团队负责人来说这意味着规范覆盖率、变更周转时间、验证通过率等关键指标随时可查决策有了数据支撑而非直觉。五、当规划大于一个仓库Stores让规划独立成库前面的工作流都假设规划和代码住在同一个仓库——这也是OpenSpec的默认形态。但当团队规模变大这个假设会开始失效一个功能横跨API服务、Web应用和共享库规划文件该放谁的openspec/文件夹里需求由平台团队所有、被多个产品团队消费wiki版本文档会漂移而且编码助手根本读不到wiki。OpenSpec给出的答案是Store目前处于beta一个独立的、专职做规划的仓库。它拥有你熟悉的openspec/结构specs和changes外加一个身份文件在本机注册一次之后所有常规命令都能在store中工作team-plans (a store: planning in its own repo) ├── .openspec-store/store.yaml identity: I am team-plans └── openspec/ ├── specs/ what is true └── changes/ what is in motion ▲ │ registered on each machine by name; │ shared by pushing/cloning like any repo ┌─────────────┼─────────────┐ │ │ │ web-app api-server mobile-app (code repo) (code repo) (code repo)创建和使用store只需两个命令openspec store setup team-plans --path ~/openspec/team-plans openspec new change add-login --store team-plansstore的设计遵循两条简单规则store就是一个git仓库——提交、推送、拉取、审查全部照旧OpenSpec从不替你自动克隆或推送任何东西声明而非机制——代码仓库可以声明自己与store的关系但声明只改变OpenSpec能告诉你什么绝不改变命令作用于哪里。这解决了三个真实痛点跨仓库功能可以一个变更、一个计划哪怕代码最终落在三个仓库共享需求由平台团队维护specs产品团队只读引用编码助手在需要的地方就能读到杜绝了wiki漂移规划可以先行——现在就把计划写进store代码仓库后续再跟上。对采用平台工程模式的团队来说这几乎是为规范跨团队流转量身定制的方案。六、配置驱动与跨平台让规范体系适配你的环境OpenSpec在设计之初就考虑了长在别人项目上的能力这体现在两个层面。配置驱动行为。项目的openspec/config.yaml定义了全局行为策略包括验证严格度和遥测设置。团队可以在不修改核心代码的情况下定制工具行为——开发初期用宽松验证快速迭代生产环境启用严格验证把质量门禁收紧。模式可扩展。schemas/spec-driven/schema.yaml以声明式的方式定义了规范文档的结构提案、规范、设计、任务四个工件每个都有生成规则、模板和依赖关系artifacts: - id: proposal generates: proposal.md description: Initial proposal document outlining the change template: proposal.md requires: [] - id: specs generates: specs/**/*.md description: Detailed specifications for the change template: spec.md requires: - proposal这意味着团队可以扩展规范结构、添加自定义元数据字段或调整验证规则而无需改动工具的核心解析逻辑——这也是OpenSpec能适配不同团队工作习惯的基础。跨平台一致性。规范本身还承载了平台要求工具运行在macOS、Linux和Windows上文件路径必须使用path.join()或path.resolve()而非硬编码分隔符涉及文件路径的需求必须明确跨平台行为涉及路径的变更要添加Windows CI验证。这些约束以规范中的规范形式存在让跨平台兼容性不再是口头承诺而是可验证的工程要求。七、给采用者的行动建议如果你决定在项目中引入OpenSpec建议参考渐进式采用的路径而不是一步到位试点阶段挑一个非关键模块作为试点建立规范基线跑通提出→实施→归档的闭环。扩展阶段把成功经验复制到其他模块沉淀团队的规范写法约定。标准化阶段建立组织级规范标准把验证接入CI流水线形成质量门禁。优化阶段基于使用反馈持续调整比如扩展规范类型、增强仪表盘的可视化能力。对个人开发者OpenSpec的价值在于让AI和自己都保持诚实——每个变更都有据可查六个月后重读specs依然能明白系统为什么长成这样。对团队而言它把最难的部分——跨仓库规划、共享需求、先规划后编码——变成了可以用git推送的普通工程实践。值得记住的是OpenSpec本身也是用OpenSpec构建的仓库里那些真实的specs和进行中的changes就是这套方法论在规模化场景下的活样本。规范驱动开发的真正价值不在于流程的完备而在于它让先达成共识再动手这件朴素的事变成了AI时代可执行、可审查、可归档的日常习惯。下一次当你的AI助手准备自信地写错之前不妨先让它把计划写下来——成本极低收益却远超预期。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenSpec：先对齐，再让AI动手——规范驱动开发实战指南
OpenSpec先对齐再让AI动手——规范驱动开发实战指南【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpecAI编码助手让写代码的门槛大幅降低但一个尴尬的问题也随之而来需求只存在于聊天记录里时AI会自信地写错。OpenSpec正是一个面向AI编码助手的规范驱动开发Spec-driven Development工具它用一份轻量的契约层让人和AI在动手写代码之前先就要构建什么达成共识。本文将从真实痛点切入跟随一次完整变更走完OpenSpec的整个工作流并拆解其跨平台、跨团队的设计考量为技术决策者和开发者提供一份可直接落地的实践参考。一、为什么AI越强大先想清楚越重要如果你已经让AI助手写过代码大概率经历过这样的场景一句帮我加个暗黑模式AI立刻生成了几百行改动看起来一切正常但仔细一检查——主题切换没持久化、系统偏好没检测、组件里硬编码了一堆颜色。问题不在AI的能力而在需求本身是模糊的。当需求只存在于聊天上下文里时AI只能靠猜测补全所有未言明的细节。一次误会在修改一段proposal时被发现成本几乎为零但当AI已经写完400行代码之后才发现方向错了返工成本会成倍放大。这正是OpenSpec要解决的核心矛盾AI编码助手需要一份双方都能读懂的行为契约而不是一段对话记录。OpenSpec的答案是给项目加一层轻量规范层先写清楚系统应该做什么再让AI动手。它的设计哲学很明确——灵活而非僵化、迭代而非瀑布、为存量项目而生而非只服务绿地项目。这不是又一套沉重的流程文档而是一个可以直接嵌入现有仓库、随代码一起版本化的规范体系。二、两个文件夹撑起整个心智模型OpenSpec的全部机制可以浓缩成一句话specs是真相changes是提案。初始化之后项目里会出现一个openspec/目录核心只有两块openspec/ ├── specs/ # 真相系统当前如何运作 │ └── domain/ │ └── spec.md ├── changes/ # 提案每个变更一个文件夹 │ └── change-name/ │ ├── proposal.md │ ├── design.md │ ├── tasks.md │ └── specs/ # 增量规范这次改什么 │ └── domain/ │ └── spec.md └── config.yaml # 项目配置可选specs/描述系统现在的行为按领域组织如auth/、payments/、ui/由需求Requirement和场景Scenario组成——需求用SHALL/MUST这类规范用语场景用WHEN/THEN格式给出可测试的例证。而changes/里每个变更文件夹装着这个功能的全部计划为什么做proposal、做什么specs、怎么做design、按什么顺序做tasks。这套设计最精妙的地方在于增量规范delta spec。在一个变更内部你不需要重写整个规范文件只需要描述变化## ADDED Requirements ### Requirement: Theme Selection The system SHALL allow users to choose between light and dark themes. #### Scenario: Manual toggle - GIVEN a user on any page - WHEN the user clicks the theme toggle - THEN the theme switches immediately - AND the preference persists across sessions为什么要费心写增量而不是整篇规范因为这让OpenSpec特别适合存量项目brownfield。给一个5万行的老应用加功能你不需要先花几周把整个系统的行为全部文档化——只需要写出这次改动的差异。这个描述差异而非目的地的设计是OpenSpec区别于许多重量级规范工具的关键。归档时ADDED需求追加进主规范MODIFIED需求替换旧版本REMOVED需求从主规范中删除变更文件夹则移入changes/archive/带日期戳的归档区。一个循环就此闭合提案变成真相系统重新处于可继续演进的状态。三、跟一个真实变更走完全程暗黑模式的五个动作把概念落地最快的方式是完整跟一遍流程。假设你要给应用加暗黑模式从想法到归档OpenSpec的默认工作流是五个动作/opsx:explore → /opsx:propose → /opsx:apply → /opsx:update → /opsx:archive (可选) 起草计划 实施构建 修订计划 归档合并第一步探索可选项。还没想清楚要做什么时可以先用/opsx:explore。它像一个零风险的思考伙伴读取你的代码、权衡方案、把模糊的想法打磨成具体计划——这个过程不会产生任何工件。已经明确目标的话可以直接跳到下一步。第二步提出变更。在AI助手的聊天框输入/opsx:propose add-dark-modeAI会在你的仓库里创建完整的变化包Created openspec/changes/add-dark-mode/ ✓ proposal.md — why were doing this, whats changing ✓ specs/ — requirements and scenarios ✓ design.md — technical approach ✓ tasks.md — implementation checklist Ready for implementation!此刻是人工审查的关键窗口。读一遍proposal确认动机、翻一遍specs确认行为边界、扫一遍tasks确认实施顺序——发现方向不对改一段Markdown的成本几乎为零。这正是规范驱动开发的价值兑现点代码还没写错误就已经被拦截。第三步实施。输入/opsx:applyAI按tasks.md的清单逐项实现每完成一项就勾选一个复选框进度实时可见✓ 1.1 Created ThemeContext with light/dark state ✓ 1.2 Added CSS custom properties to globals.css ✓ 1.3 Implemented localStorage persistence ✓ 2.1 Created ThemeToggle component ... All tasks complete!第四步修订。实现过程中发现设计需要调整直接输入/opsx:update。这个动作专门修订变更内的规划工件并自动检查其他工件是否需要连带更新保持计划整体连贯。它有两个重要护栏只改规划文件、绝不碰代码如果修订后的计划意味着代码改动会转交/opsx:apply处理同时它是schema驱动的读工件ID和路径都来自openspec status因此对自定义规范模式同样适用。值得注意的是连贯性是双向的——编辑design可能也需要回头修订proposal而不是简单地从上往下单向传播。第五步归档。全部完成后/opsx:archive把增量规范合并进openspec/specs/变更文件夹移入归档区系统重新回到真相与提案的清晰状态✓ Merged specs into openspec/specs/ui/spec.md ✓ Moved to openspec/changes/archive/2025-01-24-add-dark-mode/ Done! Ready for the next feature.五个动作构成一个闭环且每一步之间没有强制门禁——你可以随时回到任何一步修改工件。这些工件是使能器而不是关卡发现设计错了就改design.md继续走发现范围该收缩就更新proposal。依赖关系存在的目的只是确保AI在起草任务清单时有规范可依而不是把人框死。四、双脑分工终端CLI与聊天斜杠命令各司其职第一次接触OpenSpec的人最容易困惑的一个问题命令到底该敲在哪里答案其实很清晰——OpenSpec是一个项目两顶帽子。CLI是引擎。在终端运行openspec init、openspec list、openspec validate、openspec view。它掌握规则变更文件夹长什么样、工件之间如何依赖、增量规范如何合并进真相库。无论你用什么AI工具这个引擎的行为完全一致。斜杠命令是方向盘。在AI助手的聊天框输入/opsx:propose、/opsx:apply、/opsx:archive。它们告诉AI按OpenSpec的工作流行动。每个AI工具的方向盘形状略有不同——Claude Code用/opsx:proposeCursor和GitHub Copilot用/opsx-proposeAmazon Q用opsx-propose——但意图完全一致。openspec init会为你在init时选中的工具生成正确格式的命令文件。YOUR TERMINAL YOUR AI ASSISTANTS CHAT ┌──────────────────────┐ ┌──────────────────────────────┐ │ $ openspec init │ installs │ /opsx:propose add-dark-mode │ │ $ openspec list │ ──────────► │ /opsx:apply │ │ $ openspec view │ commands │ /opsx:archive │ └──────────────────────┘ skills └──────────────────────────────┘ run openspec here run /opsx:* here这个引擎与方向盘的拆分解释了OpenSpec为什么能适配30多种AI工具工作流只需学一次就能带着走遍所有助手。终端里的openspec view则提供了一个交互式仪表盘让技术管理者对规范资产一目了然。如图所示仪表盘将规范库的状态可视化规范数量与需求总数、进行中与已完成的变更、任务完成率以及每个变更的进度条。对团队负责人来说这意味着规范覆盖率、变更周转时间、验证通过率等关键指标随时可查决策有了数据支撑而非直觉。五、当规划大于一个仓库Stores让规划独立成库前面的工作流都假设规划和代码住在同一个仓库——这也是OpenSpec的默认形态。但当团队规模变大这个假设会开始失效一个功能横跨API服务、Web应用和共享库规划文件该放谁的openspec/文件夹里需求由平台团队所有、被多个产品团队消费wiki版本文档会漂移而且编码助手根本读不到wiki。OpenSpec给出的答案是Store目前处于beta一个独立的、专职做规划的仓库。它拥有你熟悉的openspec/结构specs和changes外加一个身份文件在本机注册一次之后所有常规命令都能在store中工作team-plans (a store: planning in its own repo) ├── .openspec-store/store.yaml identity: I am team-plans └── openspec/ ├── specs/ what is true └── changes/ what is in motion ▲ │ registered on each machine by name; │ shared by pushing/cloning like any repo ┌─────────────┼─────────────┐ │ │ │ web-app api-server mobile-app (code repo) (code repo) (code repo)创建和使用store只需两个命令openspec store setup team-plans --path ~/openspec/team-plans openspec new change add-login --store team-plansstore的设计遵循两条简单规则store就是一个git仓库——提交、推送、拉取、审查全部照旧OpenSpec从不替你自动克隆或推送任何东西声明而非机制——代码仓库可以声明自己与store的关系但声明只改变OpenSpec能告诉你什么绝不改变命令作用于哪里。这解决了三个真实痛点跨仓库功能可以一个变更、一个计划哪怕代码最终落在三个仓库共享需求由平台团队维护specs产品团队只读引用编码助手在需要的地方就能读到杜绝了wiki漂移规划可以先行——现在就把计划写进store代码仓库后续再跟上。对采用平台工程模式的团队来说这几乎是为规范跨团队流转量身定制的方案。六、配置驱动与跨平台让规范体系适配你的环境OpenSpec在设计之初就考虑了长在别人项目上的能力这体现在两个层面。配置驱动行为。项目的openspec/config.yaml定义了全局行为策略包括验证严格度和遥测设置。团队可以在不修改核心代码的情况下定制工具行为——开发初期用宽松验证快速迭代生产环境启用严格验证把质量门禁收紧。模式可扩展。schemas/spec-driven/schema.yaml以声明式的方式定义了规范文档的结构提案、规范、设计、任务四个工件每个都有生成规则、模板和依赖关系artifacts: - id: proposal generates: proposal.md description: Initial proposal document outlining the change template: proposal.md requires: [] - id: specs generates: specs/**/*.md description: Detailed specifications for the change template: spec.md requires: - proposal这意味着团队可以扩展规范结构、添加自定义元数据字段或调整验证规则而无需改动工具的核心解析逻辑——这也是OpenSpec能适配不同团队工作习惯的基础。跨平台一致性。规范本身还承载了平台要求工具运行在macOS、Linux和Windows上文件路径必须使用path.join()或path.resolve()而非硬编码分隔符涉及文件路径的需求必须明确跨平台行为涉及路径的变更要添加Windows CI验证。这些约束以规范中的规范形式存在让跨平台兼容性不再是口头承诺而是可验证的工程要求。七、给采用者的行动建议如果你决定在项目中引入OpenSpec建议参考渐进式采用的路径而不是一步到位试点阶段挑一个非关键模块作为试点建立规范基线跑通提出→实施→归档的闭环。扩展阶段把成功经验复制到其他模块沉淀团队的规范写法约定。标准化阶段建立组织级规范标准把验证接入CI流水线形成质量门禁。优化阶段基于使用反馈持续调整比如扩展规范类型、增强仪表盘的可视化能力。对个人开发者OpenSpec的价值在于让AI和自己都保持诚实——每个变更都有据可查六个月后重读specs依然能明白系统为什么长成这样。对团队而言它把最难的部分——跨仓库规划、共享需求、先规划后编码——变成了可以用git推送的普通工程实践。值得记住的是OpenSpec本身也是用OpenSpec构建的仓库里那些真实的specs和进行中的changes就是这套方法论在规模化场景下的活样本。规范驱动开发的真正价值不在于流程的完备而在于它让先达成共识再动手这件朴素的事变成了AI时代可执行、可审查、可归档的日常习惯。下一次当你的AI助手准备自信地写错之前不妨先让它把计划写下来——成本极低收益却远超预期。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考