数据库后端【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址https://gitcode.com/gh_mirrors/druid/druid点击查看免费下载导读本文面向使用 AgentAI 编码助手参与 Druid 连接池项目开发的开发者系统讲解如何借助 OpenSpec 的openspec-apply-change技能把一个 OpenSpec Change变更提案从任务清单逐步落地为真实代码改动。读完本文你将掌握选择 Change → 解析状态与指令 → 阅读上下文工件 → 逐任务实现 → 输出进度 → 暂停/收尾的完整可复用流程并理解本仓库中openspec/目录能力基线 Spec、模板、归档变更与流程各环节的对应关系。一、什么是 openspec-apply-changeopenspec-apply-change是仓库 .qoder/skills/openspec-apply-change/SKILL.md 中定义的 Agent 技能Skill其定位是Implement tasks from an OpenSpec change——当用户希望开始实现、继续实现或逐任务推进某个 OpenSpec 变更时使用。该技能具备以下元信息属性值nameopenspec-apply-change适用时机开始实现、继续实现、逐任务推进某个 Change前置条件需要 openspec CLIcompatibility: Requires openspec CLI许可MIT版本1.0generatedBy 1.1.1它在 OpenSpec 的actions on a change对变更执行动作模型中扮演执行者角色既有 proposal/design/tasks 的规划也有 code review、archive 等其它动作而本技能专门负责把任务清单变成代码。二、仓库中的 OpenSpec 基础设施技能中提到的openspec list、openspec status、openspec instructions apply等 CLI 命令其背后依赖仓库内这套目录结构也是本文后续所有示例的落地依据openspec/ ├── config.yaml # 项目级 OpenSpec 配置schema 为 spec-driven ├── specs/ # 能力基线 Spec保持稳定的主干契约 │ ├── sql-parser-core/spec.md │ ├── connection-pool-core/spec.md │ ├── filter-chain/spec.md │ ├── wall-security/spec.md │ ├── monitoring-stat/spec.md │ └── README.md ├── changes/ # 变更目录活跃变更 archive/ 归档历史 │ └── archive/2026-05-12-fix-grouping-sets-comma/ │ ├── proposal.md │ ├── tasks.md │ ├── specs/sql-parser-core/spec.md # delta spec │ └── verification-notes.md └── templates/ # 工件模板 ├── proposal.md ├── design.md ├── spec.md └── tasks.md2.1 config.yamlspec-driven 工作流openspec/config.yaml 的第一行就声明了schema: spec-driven这正是技能步骤 2 中了解 schema 以解析状态所针对的默认工作流。该配置文件还向 AI 注入了项目上下文Druid 为 Alibaba 出品的高性能 JDBC 连接池Java 8Maven 多模块含 core / druid-spring-boot-* / druid-wrapper / druid-demo-petclinic 等模块以及一系列 per-artifact 规则例如proposal必须说明受影响模块、变更类型、向后兼容影响specs使用 WHEN/THEN 格式描述场景delta spec 必须放在openspec/changes/change/specs/capability/spec.mdtasks要求 checkstyle 合规验证、单元测试架构级变更还必须加入MySqlPerfTest与内存测试并在任务执行前先跑基线性能/内存测试与改动后对比。这些规则解释了为什么技能在实现阶段会反复强调最小化、聚焦的代码改动 测试 构建验证。2.2 specs/ 与 changes/基线与增量openspec/specs/README.md 说明了演进方式在openspec/changes/change-name/下创建变更用openspec/changes/change-name/specs/capability/spec.md写 delta spec运行同步工作流例如/opsx:sync将 delta 合并回主干 specs。归档变更 2026-05-12-fix-grouping-sets-comma/proposal.md 就是一个典型样例它修改了sql-parser-core能力新增 Requirement GROUP BY GROUPING SETS Separator Preservation并给出 6 个覆盖 roundtrip、默认构造、equals、clone 的场景——这正是技能步骤 4 中读取 contextFiles时你会看到的工件形态。三、完整实施流程Skill 步骤详解3.1 步骤 1选择 Change技能要求首先确定要实现的 Change 名称用户显式提供名称直接使用从对话上下文推断用户提到的变更只有一个活跃变更自动选中存在歧义运行openspec list --json获取可用变更列表并通过 AskUserQuestion 工具让用户选择。无论哪种方式都要对外播报Using change: name并说明覆盖方式例如/opsx:apply other。这个明确告知 提供覆盖途径的做法能有效避免 Agent 实现错误变更。3.2 步骤 2检查状态以理解 Schemaopenspec status --change name --json解析返回的 JSON确认两件事schemaName正在使用的工作流本仓库为spec-driven任务位于哪个工件spec-driven 下通常是tasks其它 schema 以 status 输出为准。结合 openspec/config.yaml 中声明的schema: spec-driven本仓库的规范路径就是tasks 工件承载任务清单。3.3 步骤 3获取实施指令openspec instructions apply --change name --json该命令返回Context 文件路径因 schema 而异spec-driven 为 proposal/specs/design/tasks其它 schema 可能为 spec/tests/implementation/docs进度total / complete / remaining任务列表及状态基于当前状态生成的动态指令。随后要处理三种状态状态处理方式blocked缺少工件提示用户建议使用openspec-continue-changeall_done全部完成祝贺用户建议归档archive该变更其它进入实现流程3.4 步骤 4阅读上下文文件读取contextFiles中列出的文件。spec-driven 工作流对应四件套proposal.md—— 变更动机、影响模块、API 变化、兼容性specs/delta spec—— 以 WHEN/THEN 描述的行为契约design.md—— 架构决策、类设计、线程安全与配置tasks.md—— 可勾选的任务清单。仓库中的模板文件展示了每类工件的完整骨架见 openspec/templates/proposal.md、openspec/templates/design.md、openspec/templates/tasks.md。以归档变更 2026-05-12-fix-grouping-sets-comma 为例其proposal.md明确了问题GROUP BY a, GROUPING SETS(...)与无逗号形式被解析器坍缩成同一 AST输出访问器无条件去掉逗号导致 SQL roundtrip 被静默改写tasks.md则按Core Implementation → Testing → Code Quality → Build Release → Verification Checklist组织全部任务已勾选完成verification-notes.md记录了复现代码、修复前后输出对比、回归测试命令与结论。这些文件就是阅读上下文阶段的最佳参照物。3.5 步骤 5展示当前进度在动手前向用户展示使用的 Schemaspec-driven进度N/M tasks complete剩余任务概览CLI 返回的动态指令。3.6 步骤 6逐任务实现循环直到完成或阻塞对每个待办任务声明正在处理哪个任务完成所需代码改动保持改动最小且聚焦对应 config.yaml 中Keep changes minimal的精神在 tasks 文件中将- [ ]标记为- [x]进入下一个任务。出现以下情况必须暂停任务不清晰 → 请求澄清实现暴露设计问题 → 建议更新工件proposal/specs/design/tasks遇到错误或阻塞 → 报告并等待指引用户打断。Guardrails 明确要求Pause on errors, blockers, or unclear requirements - dont guess不要猜。这与 openspec/config.yaml 中考虑线程安全、记录边界情况、保持基线 spec 稳定的工程约束一脉相承——对于 Druid 这种高并发连接池 SQL 解析器项目任何猜着改都可能引入行为回归。3.7 步骤 7完成或暂停时展示状态完成列出本次会话完成的任务、总进度全部完成则建议归档暂停说明暂停原因并等待指引。四、三种输出格式可直接复用的模板4.1 实施过程输出## Implementing: change-name (schema: schema-name) Working on task 3/7: task description [...implementation happening...] ✓ Task complete Working on task 4/7: task description [...implementation happening...] ✓ Task complete4.2 完成输出## Implementation Complete **Change:** change-name **Schema:** schema-name **Progress:** 7/7 tasks complete ✓ ### Completed This Session - [x] Task 1 - [x] Task 2 ... All tasks complete! Ready to archive this change.4.3 暂停输出遇到问题## Implementation Paused **Change:** change-name **Schema:** schema-name **Progress:** 4/7 tasks complete ### Issue Encountered description of the issue **Options:** 1. option 1 2. option 2 3. Other approach What would you like to do?这套格式化的进度输出与仓库中tasks.md的勾选机制配合构成了人机协作的透明执行记录。五、Guardrails高质量实施的底线技能最后给出十条护栏是实现质量的关键持续推进直到完成或阻塞才停下先读上下文动手前必须读取 apply instructions 输出的 contextFiles任务模糊即暂停不要猜测发现问题即建议更新工件实现暴露设计缺陷时暂停并建议修订 proposal/specs/design/tasks改动最小化每个任务的代码改动保持最小、作用域聚焦及时勾选每个任务完成立即更新- [ ]→- [x]出错即停错误、阻塞、需求不清晰时暂停以 CLI 输出为准使用 contextFiles 字段不要臆测具体文件名。上述护栏在 openspec/templates/tasks.md 的 Verification Checklist 中得到呼应代码无警告编译、mvn test全绿、mvn checkstyle:check通过、Javadoc 无错、向后兼容、并发组件线程安全、连接相关改动无内存泄漏、架构级变更必须包含MySqlPerfTest与内存测试且留存基线对比。六、Fluid Workflow非阶段锁定的灵活集成该技能支持actions on a change模型可在任意时机调用在全部工件完成之前只要 tasks 存在即可调用部分实现之后可以再次调用继续推进可与其他动作review、sync、archive 等交错进行实现中若发现设计问题允许回头更新工件——不强制阶段锁定。归档变更中 2026-05-12-fix-grouping-sets-comma/verification-notes.md 正是这种流动协作的产物它记录了范围盘点两种GROUPING SETS表面形式、复现代码、修复前后输出、核心实现摘要AST 新增hasPrefixComma字段、SQLSelectParser.parseGroupBy追踪previousWasComma、SQLASTOutputVisitor.visit(SQLSelectGroupByClause)按标志输出逗号、回归测试命令与结论。整个过程体现了实现 → 验证 → 记录 → 归档的闭环。七、在本仓库实战一个端到端示例假设当前存在一个活跃变更其任务清单参照 openspec/templates/tasks.md 组织Agent 的完整执行路径如下选中变更Using change: 2026-05-12-fix-grouping-sets-comma此处为归档示例活跃变更同理检查状态openspec status --change name --json确认schemaName: spec-driven、任务在tasks工件获取指令openspec instructions apply --change name --json得到 contextFiles 与进度如 0/3 complete读上下文读取 proposal.md → specs 下的 delta spec → design.md → tasks.md展示进度Schema: spec-driven | Progress: 0/3 tasks complete实现循环逐任务改动core源码例如 SQLGroupingSetExpr、补充 BVT 测试如 OdpsGroupingSetsCommaTest每完成一项即勾选- [x]并运行mvn -pl core test -Dtest...与 checkstyle 验证收尾全部完成后建议执行/opsx:archive归档。注意仓库是只读的本文仅说明查看、运行与配置方式实际执行上述 CLI 与代码改动发生在你自己的变更分支环境中。八、总结openspec-apply-change把从 OpenSpec Change 到代码落地的过程标准化为一条清晰、可审计、可暂停/恢复的流水线选变更 → 查状态 → 取指令 → 读工件 → 显式进度 → 最小化实现 → 格式化输出。它与仓库中 openspec/config.yaml 的 spec-driven 配置、openspec/specs/ 的能力基线、openspec/templates/ 的工件模板以及 openspec/changes/archive/ 的完整变更样例相互印证。对 Druid 这类以高并发连接池 多方言 SQL 解析 防火墙/统计/过滤器链著称的基础设施项目这种契约先行、任务可勾选、验证可追溯的规范驱动开发方式能显著降低大规模重构如解析器优化、继承体系调整带来的行为回归风险。无论你是维护者还是贡献者都可以直接把本文中的命令、模板与护栏作为你下一次 Agent 协作开发的起点。赞分享数据库后端【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址https://gitcode.com/gh_mirrors/druid/druid点击查看免费下载相关推荐Druid 项目中的 OpenSpec 变更工作流openspec-new-change Skill 实战指南Druid 项目中的 OpenSpec 变更工作流openspec new change Skill 实战指南 本指南以 Druid 仓库阿里云计算平台 D数据库后端Druid 仓库 OpenSpec 变更实施指南openspec-apply-change 技能工作流全解析Druid 仓库 OpenSpec 变更实施指南openspec apply change 技能工作流全解析 本指南围绕仓库内 .cursor/skills/数据库后端Druid 仓库 OpenSpec 变更续作工作流openspec-continue-change实战指南Druid 仓库 OpenSpec 变更续作工作流openspec continue change实战指南 导读 本文围绕仓库 .qoder/skills/数据库后端上一篇深度神经网络构建指南从零开始实现多层神经网络下一篇在YaLTeR/niri项目中使用systemd管理Wayland组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考