| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 天前 | ||
| 9 天前 | ||
| 9 天前 | ||
| 9 天前 | ||
| 9 天前 | ||
| 9 天前 | ||
| 9 天前 | ||
| 21 小时前 |
cuda2ascend
社区版直调算子开发工作流。用户描述算子需求，Agent 团队按统一流程从需求分析走到代码上库，全程可追溯、可恢复、可定制。
借鉴了面向对象的设计思想，本仓内维护一套通用工作流基类，各生态算子仓作为子类，可以拉取使用本工作流，覆写与自身耦合的领域知识，按照仓内开发流程定制本工作流，达到一套核心流程服务所有算子仓，消除重复建设的目的。
设计思想
借鉴面向对象思想重构直调算子工作流：CANNBot 仓维护一套通用工作流作为基类，各算子仓的工作流作为子类，继承基类编排流程，仅覆写与自身耦合的领域知识和验收实现。
- 封装：对算子仓隐藏编排的复杂实现，工作流将编排逻辑封装为知识接口。算子仓只关心"我提供什么知识"，不关心"工作流怎么用"。
- 继承：CANNBot 提供基类，算子仓继承基类，只覆写自己需要的部分。
- 多态：工作流核心始终通过逻辑名引用可覆写 Skill（领域知识、验收标准），实际实现在 init 时由 symlink 绑定确定。
知识分层
知识分布按抽象层级从高到低分层，越靠上越通用稳定、越靠下越具体易变：
| 层级 | 承载形式 | 职责 | 可否被子仓覆写 |
|---|---|---|---|
| 主 Agent | 根目录 AGENTS.md | PM Agent 的全局知识，规范行为边界 | 可覆写（子仓 agent/AGENTS.md 存在时链接子仓） |
| 工作流 | ops-direct-invoke-workflow skill |
编排流程的组织与调度 | final |
| 可插拔流程插件 | skills/plugin-*/ |
可插拔子流程（提交 PR 到上库、性能迭代、开发经验总结等），frontmatter 声明挂载点，init 注册到 .cannbot/settings.json，自闭环且可单独触发 |
可覆写、可新增 |
| 子 Agent | agents/*.md |
调度执行的最小单位，规范每一个子步骤的行为 | final |
| Skill | skills/repo-*/、skills/workflow-*/ |
仓库领域知识、工作流定义（模板/验收标准） | virtual |
| 仓内文档 | 仓库 doc 目录 | 面向开发者的参考资料 | 仓库自有 |
其中 Agent 与 Skill 相邻两层职责最易混淆，判定原则：会变、需被子仓 override 的领域知识归 Skill；跨仓通用、用于定义角色身份与行为边界的内容归 Agent。
参与角色
| 角色 | 类型 | 职责 |
|---|---|---|
| 用户 | 验收/决策 | 需求提出、各确认点审批 |
| PM（主 Agent） | 调度 | 用户交互、流程编排、问题裁定；只调度不执行 |
| architect | 执行 | 需求分析、开发方案与测试方案设计 |
| developer / -code / -test / -doc | 执行 | 代码、测试、文档开发与修复 |
| QA | 验收 | 各 CP 点验收，加载对应 workflow-cp* Skill 完成判定，产出验收报告与用户确认问卷 |
开发流程概览
完整流程从开发准备到开发总结分 8 个阶段，方案线与测试线在设计/开发阶段并行；提交 PR 到上库、性能迭代、开发经验总结为可插拔流程（plugin-* skill），按 .cannbot/settings.json 的启用状态在对应挂载点触发，不在本表列出：
| 编号 | 流程 | 角色 | 说明 |
|---|---|---|---|
| 阶段0：开发准备 | |||
| 0 | 开发准备 | developer | 检查环境，统计环境信息 |
| ⛔ CP0 | 环境确认 | QA | 问卷确认环境 |
| 阶段1：需求分析 | |||
| 1.1 | 需求分析 | architect | 产出需求文档并给出架构选型推荐，用户拍板 |
| ⛔ CP1 | 需求确认 | QA | 问卷确认需求；硬伤打回 1.1 |
| 阶段2：方案设计（方案线 / 测试线并行） | |||
| 2.1 | 黑盒测试设计 | architect | 产出测试方案 |
| CP2.1 | 测试检查 | QA | 评审测试方案；不通过打回 2.1 |
| 2.2 | 开发方案设计 | architect | 产出开发方案 |
| ⛔ CP2.2 | 方案检查 | QA | 评审方案并问卷确认；不通过打回 2.2 或 1.1 |
| 阶段3：代码开发（开发线 / 测试线并行） | |||
| 3.1 | 算子开发 | developer-code | 实现算子代码，编译验证通过 |
| 3.2 | 测试工程开发 | developer-test | 开发测试工程（golden、用例、性能采集框架） |
| 3.3 | 白盒测试补全 | developer-test | 补全白盒用例 |
| 3.4 | 联调 | developer-code | 联合调试代码与测试，精度比对通过；问题按归属回退 3.1 或 3.2 |
| CP3 | 功能验收 | QA | 全量功能测试与精度比对；不通过回退 3.1 或 2.1 |
| 阶段4：性能验收 | |||
| 4.1 | 性能采集执行 | developer-test | 采集性能数据 |
| CP4 | 性能验收 | QA | 评估性能是否达标；不通过回退 3.1 |
| 阶段5：代码检视 | |||
| CP5 | 代码检视 | QA | 多维度代码检视；不通过回退 3.1 |
| 阶段6：上库准备 | |||
| 6.1 | 文档补全 | developer-doc | 补全算子使用文档 |
| 阶段7：开发总结 | |||
| 7.1 | 开发报告 | developer-doc→PM | 整理开发报告 |
| 7.2 | 经验总结 | developer-doc→PM | 沉淀经验总结 |
设计约束
为保证实现一致性、在方案出现分歧时提供统一指导，本工作流约定了一组设计约束。理解这些约束能帮助参与开发的开发者把握最初的设计思路——为什么定制要靠 override 而非改编排、为什么执行方与验收方必须分离、为什么中间状态要落盘。
约束由 skill 看护：这组约束不是一次性文档，而是由
ops-direct-invoke-workflow-maintainskill 持续看护的维护红线。任何对工作流文件的新增/修改/删除都须先触发该 skill，改完后按其派生的可执行检视条款逐条自查——约束不通过则回退修改。开发者若要演进工作流，务必先阅读该 skill。
结构约束（SOLID）
| 条款 | 说明 |
|---|---|
| 单一职责（S） | 每个 Skill 只负责一个功能域，只有一种原因引起它需要修改 |
| 开闭（O） | 编排对扩展开放、对修改关闭；子仓扩展步骤应 override virtual skill，而非改动编排 |
| 里氏替换（L） | 子仓 override 后须保持相同逻辑名、输入输出格式与调用方式，上层无感知 |
| 接口隔离（I） | 子仓只 override 自己需要的组件，不被迫实现全部 virtual 组件 |
| 依赖倒置（D） | 上层只依赖抽象逻辑名，不依赖具体实现路径 / 章节结构 |
| 基类演进兼容 | 基类对外契约（逻辑名 / 输入输出格式 / 调用约定）一经发布只增不破坏；确需破坏性变更须提供迁移路径并通知已接入仓 |
层级感知
层级感知方向：主 Agent → 工作流 → 子 Agent → Skill → 仓内文档。
- 层级间单向感知：下级模块不感知上级（子 Agent 不知自己在流程哪一步，Skill 不提及被谁调用）。
- 层级内黑盒感知：同级模块之间互不了解对方内部逻辑。
调度约束
| 条款 | 说明 |
|---|---|
| 职责分离 | 任务的执行方与验收方不能是同一 Agent 实例 |
| 最小信息 | 每个子 Agent 只获取完成当前任务所需的最小信息集 |
| 最小权限 | 每个子 Agent 只获取完成当前任务所需的最小操作权限（当前由 hook 落地为写权限约束） |
| 过程有界 | 所有可能循环/重试的环节必须声明最大次数，超限暂停并报告 |
| 确定性交付 | 每个子环节有明确交付件与可判定的通过指标 |
| 状态可观测 | 每阶段完成后状态持久化到外部（.cannbot/<算子名>/state.json），不依赖会话记忆 |
| 可恢复性 | 暂停/失败落盘到可恢复状态点，恢复时不重跑已通过阶段 |
| 修改不越权 | 执行角色严格遵循上游设计，发现问题回退上游修改，不自行变更上游决策 |
风格约束
- SKILL.md 只做路由：入口文件只做意图识别与路由分发，知识细节放 references。
- 机制优于自然语言：能用 hook / 脚本 / 权限声明约束的行为，不写成 prompt 自然语言。
- 引用而非硬编码：涉及仓库领域知识时引导 Agent 读原文，而非全文硬编码进 Skill。
- 开发者知识外置：对开发者同样可见的知识优先放仓内 doc，Skill 只做引导。
- 举例不引入外部概念：举例只用仓内已有知识或通用概念，不引入需额外背景才懂的概念。
工作流配置与静默模式
运行时配置统一由 .cannbot/settings.json 承载——唯一配置文件与唯一权威（工作流模式、插件注册信息与启用状态、询问状态全部聚合于此；init 生成、会话中可显式修改）：
- 生成：
init.sh --mode interactive|silent与--plugin-enable <name> on|off；未传--mode时保留现有配置（首次默认interactive）。 - 交互模式（默认）：⛔ 用户确认点由 QA 用会话问卷工具（opencode
question/ claudeAskUserQuestion/ dshask_user_question/ traeAskUserQuestion）直接发送用户并收集结论，进度逐环节汇报。 - 静默模式（
silent，完全无人值守）：不输出中间进度、不发问卷（确认点由 QA 按默认决策执行，架构选型固定采用 SIMD），失败自动回退至最大轮次；仅输出启动时的权限预检警告（opencode 检查 opencode.json 未全量授权、dsh 检查运行上下文声明的文件/审批策略未全量授权时提示一次）与任务完成总结（含阻断中止性总结）。启动静默工作流前 PM 执行权限预检，未全量授权时提示「运行期间权限确认可能打断自动流程」。 - 会话内切换：直接对 PM 说「开启静默模式 / 关闭静默模式」，即修改配置并落盘，无需重跑 init。
- DSH 部署级权限守卫（可选）：dsh 无项目级 hook（角色写隔离默认靠 prompt 约束）；运行
hooks/dsh/install.sh可安装部署级 Cordis 守卫插件（挂$DSH_HOME/cordis.patch.yml，对所有 profile 生效），恢复按角色的写权限隔离与静默问卷拦截的机制保证（仅作用于 cuda2ascend 初始化的工作区）。
结构、模式语义与静默默认决策详见 skills/ops-direct-invoke-workflow/references/settings.md。