CC Workflow Studio AI 编辑流程解析：从 Mermaid 流程图到工作流精修提示词的自动化管线-北京尧图网络

AI 应用Agent 工作流开发工具MCP 服务【免费下载链接】cc-wf-studioCC Workflow Studio项目地址https://gitcode.com/gh_mirrors/cc/cc-wf-studio点击查看免费下载CC Workflow Studiocc-wf-studio是一套面向 Claude Code、GitHub Copilot、Codex 等 AI Agent 的可视化工作流编辑器。本文围绕仓库中 ai-editing-process-flow.md 这份AI 编辑过程流程规范文档展开完整剖析其定义的 AI 编辑决策流程请求类型判定 → 澄清触发 → 最小化修改 → 原样保留未改动节点 → 结构化 JSON 输出并结合 generate-editing-flow.ts 的解析生成逻辑、refinement-prompt-builder.ts 的提示词组装、refinement-service.ts 的精修执行链路说明这份文档如何在构建期被编译为 TypeScript 常量、又在运行时被注入 AI 提示词从而约束 AI 在工作流精修Workflow Refinement场景下的行为。读完本文你将掌握该流程的每一步在源码中的落地位置、三类请求与三种响应状态的对应关系、以及如何把Markdown 规范 → 生成常量 → 提示词约束这一模式复用到自己的项目。一、这份文档是什么AI 编辑流程的单一事实来源在 CC Workflow Studio 的 VSCode 扩展packages/vscode中AI 精修工作流功能允许用户通过聊天面板反复提出修改意见如增加错误处理让提示词更清晰由 AI 基于当前工作流与对话历史输出一份修改后的完整工作流 JSON。为了让 AI 的输出行为可预期、可约束项目维护了一份人可读的 Markdown 规范——即本文的主角 ai-editing-process-flow.md。文件头部明确写出它的定位This file defines the AI editing process flow for workflow refinement. It is used by thegenerate-editing-flow.tsscript to generate TypeScript constants.也就是说这份文档不是一份仅供参考的说明书而是会被构建脚本直接消费、编译进扩展运行时代码的规格文件。文档中所有结构化内容流程图、步骤、判定规则、触发条件最终都会变成提示词里 AI 必须遵循的约束项。文档内的四大内容块内容块Markdown 标题说明Mermaid 流程图## Mermaid Diagram9 个节点/判定组成的决策流程图直观展示 AI 的处理路径过程步骤## Process Steps编号列表共 9 步是流程图的文字版请求类型判定## Request Type Guidelines3 个子节Question/Understanding、Edit、Unclear 各自的识别特征澄清触发条件## Clarification Triggers5 条必须反问用户的情形二、AI 编辑决策流程全图9 步判定链文档用 Mermaid 定义了完整的编辑决策链见 ai-editing-process-flow.md其核心思想是先分类、再澄清、后最小化修改、最后完整输出逐步骤拆解Review current workflow先完整理解现有全部节点及其数据字段这是后续精确修改、不误伤的前提Analyze user request识别用户意图Request type check判定请求是提问/理解型还是编辑型无法判定则直接进入澄清Clarity check编辑型请求若含糊不清返回澄清请求Identify changes仅列出需要修改的具体节点/连接Determine change type把变更归类为 add / modify / delete 三类Apply minimal changes只执行已识别的变更新增走 7a、修改走 7b、删除走 7cPreserve unchanged原样复制所有未变更节点及其精确原始数据字段——这是防止 AI 顺手重写整张工作流的关键一步Output输出应用变更后的完整工作流 JSON。从源码看这一步链并非停留在文档层面。在 refinement-prompt-builder.ts 中构建提示词时会在结构化 prompt 中注入editingProcessFlow字段并明确标注// AI Editing Process Flow - MUST follow this process strictly // Generated from: resources/ai-editing-process-flow.md editingProcessFlow: { description: You MUST follow this editing process step by step. Do NOT skip any steps., mermaidDiagram: EDITING_PROCESS_MERMAID_DIAGRAM, steps: EDITING_PROCESS_STEPS, requestTypeGuidelines: REQUEST_TYPE_GUIDELINES, clarificationTriggers: CLARIFICATION_TRIGGERS, }也就是说AI 在每次精修请求中都会同时看到流程图、9 步步骤、判定规则与澄清触发条件四份约束并以不得跳步作为硬性要求。三、请求类型判定三类输入三种响应文档的第 3 步Request type?是整条流程的分水岭判定规则详见 ai-editing-process-flow.md。3.1 提问/理解型请求Question or Understanding Request识别特征以 What、Why、How、Explain、Tell me 开头的提问请求对工作流进行解释或澄清不含 add、modify、delete、change、update、remove 等动作动词。响应约定使用{ status: clarification, message: your answer }—— 注意这里虽然是clarification状态但语义是直接回答问题不修改工作流。3.2 编辑型请求Edit Request识别特征包含 add、modify、delete、change、update、remove、insert 等动作动词指明了目标节点或位置描述了期望的结果或新内容。响应约定依次执行流程第 4~9 步最终使用{ status: success, ... }并在values.workflow中携带完整修改后的工作流。3.3 不明确请求Unclear Request识别特征含糊指令如 improve、make better、fix、optimize缺少目标说明改哪个节点改哪里存在多种可能解释、语义歧义。响应约定使用{ status: clarification, message: ask for details }向用户追问细节而不是贸然动手。3.4 三种响应状态在源码中的落地上述三种响应在运行时被 refinement-service.ts 中定义的AIRefinementResponse类型严格约束interface AIRefinementResponse { status: success | error | clarification; values?: { workflow: Workflow }; message?: string; // For clarification or error messages }随后 parseRefinementResponse 会校验status是否属于[success, error, clarification]不属于则判定解析失败。此外该函数还包含一个重要的兜底策略当 AI 返回的是非 JSON 的对话文本常见于非英语环境或模糊的初始消息时会把它当作一条clarification消息处理保证用户体验的连续性if (!parsed || typeof parsed ! object) { const trimmedOutput output.trim(); if (trimmedOutput.length 0) { log(INFO, Treating non-JSON AI response as clarification message, ...); return { status: clarification, message: trimmedOutput }; } return null; }对应到 UI 消息层REFINEMENT_CLARIFICATION消息类型也在 messages.ts 中有完整定义由 workflow-refinement.ts 中的sendRefinementClarification发送回 Webview 聊天面板。四、澄清触发条件什么时候必须反问用户文档在 Clarification Triggers 一节给出了 5 条必须发起澄清的情形用户请求未指明要修改哪个节点用户请求对期望结果表述含糊请求存在多种合理解释缺少必要信息节点名、位置、内容用户请求与现有工作流结构冲突。这些条件与请求类型判定共同构成宁可多问、不可乱改的护栏。从实现上看澄清触发条件不仅被写入提示词clarificationTriggers: CLARIFICATION_TRIGGERS还体现在输出格式约束中。在 refinement-prompt-builder.ts 的outputFormat里AI 被要求每次响应都必须包含status和message字段并给出了三种示例// success 示例 { status: success, message: Brief description of what was changed, values: { workflow: { id: workflow-id, name: workflow-name, nodes: [... all nodes with data ...], connections: [... all connections ...] } } } // clarification 示例 { status: clarification, message: Your answer or question here } // error 示例 { status: error, message: Error description }同时criticalRules数组反复强化关键纪律refinement-prompt-builder.ts只输出一个JSON 对象不得输出多个 JSON 块或解释性文字成功时工作流必须嵌套在values.workflow内不能单独另起 JSON 块不得用 json 代码块包裹输出裸 JSON输出工作流时必须原样复制未变更节点的精确原始数据绝不为未要求修改的节点重新生成数据提问型请求用clarification状态作答模糊编辑请求用clarification状态追问细节清晰编辑请求用success状态返回完整工作流。五、构建期自动化Markdown 是如何变成 TypeScript 常量的文档与运行时代码之间的桥梁是 generate-editing-flow.ts约 230 行它在构建期把 Markdown 解析成结构化数据再生成 TypeScript 常量文件。5.1 解析策略脚本按 Markdown 的章节结构做正则切片而不是引入 Markdown 解析器提取函数目标内容实现要点extractMermaidDiagrammermaid\n([\s\S]*?) extractNumberedList## Process Steps下的编号列表匹配^\d\.\s(.)$extractBulletList### Question/Understanding、### Edit Request、### Unclear Request下的条目匹配^-\s(.)$并去掉行内反引号extractTopLevelBulletList## Clarification Triggers下的条目顶层^-\s(.)$注意其中有一个跨平台细节脚本在解析前先执行content.replace(/\r\n/g, \n)做 CRLF 归一化generate-editing-flow.ts确保在 Windows 环境下同样能正确解析——这一点在注释中明确写着 Windows support。5.2 生成的常量文件脚本把解析结果渲染为 editing-flow-constants.generated.ts由脚本生成仓库中为构建产物文件头标注 AUTO-GENERATED FILE - DO NOT EDIT DIRECTLY导出四组常量export const EDITING_PROCESS_MERMAID_DIAGRAM ...; export const EDITING_PROCESS_STEPS: readonly string[] [...]; // 9 步 export const REQUEST_TYPE_GUIDELINES { questionOrUnderstanding: [...], editRequest: [...], unclearRequest: [...], } as const; export const CLARIFICATION_TRIGGERS: readonly string[] [...]; // 5 条这些常量随后被 refinement-prompt-builder.ts 以import方式消费最终通过 TOON 格式编码进提示词。5.3 触发时机该脚本挂接在 VSCode 扩展的构建流程中package.jsongenerate:editing-flow: npx tsx scripts/generate-editing-flow.ts, build: npm run sync:license npm run sync:schema npm run generate:editing-flow npm run build:webview npm run build:extension也就是说只要执行npm run build发布前由vscode:prepublish自动触发Markdown 规范就会先被编译进常量文件再随扩展一起打包。开发者修改流程规范的路径是改ai-editing-process-flow.md→ 运行npm run generate:editing-flow或完整npm run build→ 重新编译扩展而不是直接手改生成文件。这种文档即代码模式的价值在于流程图、步骤、规则以人可读的形式维护天然可评审、可 diff、可被非开发者理解同时又能零手工同步地进入 AI 提示词。六、运行时执行链路从用户消息到画布更新理解了流程规范的生成与注入再看它在完整精修功能中的位置。一次精修的运行时调用链如下Webview 聊天面板RefinementChatPanel → 消息 REFINE_WORKFLOWcontracts/refinement-messages.json → Extension Host 命令处理器 workflow-refinement.ts → refinement-service.refineWorkflow() ├─ 并行loadWorkflowSchemaByFormat() scanAllSkills()可选 ├─ filterSkillsByRelevance() 按相关性过滤技能 ├─ constructRefinementPrompt() → RefinementPromptBuilder.buildPrompt() │ └─ 注入 editingProcessFlow本文主角 workflowSchema outputFormat criticalRules ├─ executeAiStreaming() / executeAi() 调用 AI CLIClaude Code / Copilot / Codex 等 ├─ parseRefinementResponse() 解析三态 JSON ├─ resolveSkillPaths() / resolveSubAgentFlows() 修复 Skill 与 SubAgentFlow 引用 └─ validateAIGeneratedWorkflow() 校验后返回 → 消息 REFINEMENT_SUCCESS / REFINEMENT_CLARIFICATION / REFINEMENT_FAILED 回传 Webview → 画布自动更新几个值得展开的源码细节6.1 提示词上下文是完整的在 refinement-prompt-builder.ts 中currentWorkflow会携带全部节点的完整data字段注释强调 Include COMPLETE node data for ALL node types to enable precise editing / this is CRITICAL for preserving existing content这正是流程第 8 步原样复制未变更节点的数据基础——AI 只有拿到精确的原始数据才可能做到不重写。对话历史则取最近 6 条约 3 轮往返见 refinement-service.ts既保留上下文又不无限膨胀。6.2 附加约束比文档更细在流程规范之上提示词还附加了若干工程化约束例如节点命名必须匹配/^[a-zA-Z0-9_-]$/仅 ASCII 字母数字、连字符、下划线禁止空格、日语字符等节点布局规范水平间距 300px、Start 后 250px、End 前 350px、垂直间距 150px、分支节点垂直偏移 150pxSkill 节点必须恰好 1 个输出端口需要分支时在 Skill 节点后接 ifElse/switch 节点新 Skill 节点只能使用availableSkills列表中的名字Codex Agent 启用时注入codexNodeConstraints与模型、reasoningEffort、sandbox 等配置说明。这些内容与文档共同构成 AI 的完整行为约束集。6.3 失败重试带错误上下文如果上一次精修通过校验失败previousValidationErrors会被注入下一轮提示词refinement-prompt-builder.ts并附带errorRecoveryInstructions指导 AI 对照错误修复输出再次强调命名模式、必填字段等。这与REFINEMENT_FAILED消息的VALIDATION_ERROR错误码见 refinement-messages.json 的 errorCodes 定义形成闭环失败 → 带上下文重试 → 校验通过 → 成功。6.4 会话续接与取消refineWorkflow支持sessionId续接会话当会话过期时会自动降级重试匹配 session not found、thread expired 等模式后去掉 sessionId 重跑见 refinement-service.ts。取消操作由handleCancelRefinement对三种 provider 并行调用cancelAiRequest完成workflow-refinement.ts。6.5 迭代上限保护conversationHistory中的maxIterations固定为 20达到上限后命令处理器直接返回ITERATION_LIMIT_REACHEDworkflow-refinement.ts提示用户清理对话历史Webview 侧在接近上限≥18 次时展示警示横幅。七、消息协议与错误码三态响应在系统边界上的契约精修功能在 Webview 与 Extension Host 之间的通信由 refinement-messages.json 定义该契约与 AI 响应三态一一对应方向消息类型触发场景Webview → ExtensionREFINE_WORKFLOW用户发送精修请求Webview → ExtensionCLEAR_CONVERSATION用户清空对话历史Extension → WebviewREFINEMENT_SUCCESSAI 返回success且工作流校验通过Extension → WebviewREFINEMENT_CLARIFICATIONAI 返回clarification提问解答或追问细节Extension → WebviewREFINEMENT_FAILED命令缺失/超时/解析失败/校验失败/超迭代Extension → WebviewCONVERSATION_CLEARED确认对话已清空其中REFINEMENT_FAILED的error.code枚举对应 6 类故障refinement-messages.jsonCOMMAND_NOT_FOUNDAI CLI 未安装或不在 PATH 中 → 建议安装 CLI 或检查 PATHTIMEOUT超时默认 90 秒可配置→ 建议简化请求或调大超时PARSE_ERRORAI 返回无法解析的 JSON → 属于需要上报的格式问题VALIDATION_ERROR修改后的工作流未通过校验 → 建议换个措辞重试ITERATION_LIMIT_REACHED达到 20 次上限 → 建议清空对话历史或手动编辑UNKNOWN_ERROR未知异常 → 查看 Extension Host 日志。需要说明的是DEFAULT_REFINEMENT_TIMEOUT_MS在 refinement-service.ts 中定义为 9000090 秒与契约示例中早期设计的 60 秒不同——实际行为以当前源码为准Webview 侧可通过设置覆盖。八、工程实践总结这套文档驱动 AI 约束模式的要点用 Markdown 当规范源流程图、步骤、规则放在一个文件里Git 历史清晰、评审友好构建期编译成常量generate-editing-flow.ts用轻量正则解析避免运行时解析 Markdown 的开销与脆弱性也保证规范与代码强同步常量注入提示词RefinementPromptBuilder把流程图与步骤直接拼进 AI prompt并辅以criticalRules、refinementGuidelines、outputFormat等结构化约束结构化三态响应success/clarification/error三态贯穿提示词、解析器、消息协议与 UI任何一环都能对不合法输出兜底如把非 JSON 文本降级为澄清消息最小修改原样保留是防退化关键提示词中反复强调复制未变更节点的精确数据、不重新生成节点 ID从流程第 8 步到criticalRules层层加固防止 AI 把整张工作流重写得面目全非失败可恢复校验失败的错误上下文进入下一轮重试提示词配合 20 次迭代上限与会话续接形成完整闭环。九、延伸阅读流程规范原文ai-editing-process-flow.md生成脚本scripts/generate-editing-flow.ts提示词构建器services/refinement-prompt-builder.ts精修服务services/refinement-service.ts命令处理器commands/workflow-refinement.ts消息协议契约contracts/refinement-messages.json功能规格specs/001-ai-workflow-refinement/spec.md 与 quickstart.md构建脚本入口package.json技能相关服务services/skill-service.ts、services/ai-editing-skill-service.ts若需在本地复现这套管线克隆仓库后在packages/vscode目录执行npm install运行npm run generate:editing-flow观察常量文件生成或直接npm run build走完整构建流程在 VSCode 中以扩展开发模式F5或npm run debug打开后通过工具栏的AI 精修聊天面板即可体验完整流程。赞分享AI 应用Agent 工作流开发工具MCP 服务【免费下载链接】cc-wf-studioCC Workflow Studio项目地址https://gitcode.com/gh_mirrors/cc/cc-wf-studio点击查看免费下载相关推荐从提示词到艺术画作DiffSynth Studio零基础AI绘画全流程从提示词到艺术画作DiffSynth Studio零基础AI绘画全流程你还在为AI绘画参数复杂而头疼想快速生成专业级AI画作却不知从何入手本文将通过Di人工智能大模型媒体生成深度学习预训练微调apt multiarch多架构支持揭秘如何优雅处理跨架构软件包依赖冲突apt multiarch多架构支持揭秘如何优雅处理跨架构软件包依赖冲突 apt 是 Debian 系 Linux 的核心包管理工具其 multiarchThorium 浏览器安装教程3 种 SIMD 版本怎么选5 步源码构建指南Thorium 浏览器安装教程3 种 SIMD 版本怎么选5 步源码构建指南你装好原版 Chromium 后发现 HEVC 视频播不了、FTP 链接打不桌面应用跨平台上一篇BilldDesk10分钟连上你的第一台远程桌面下一篇QRemeshify 四边形重网格指南3 步把三角面转成规整四边形拓扑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

CC Workflow Studio AI 编辑流程解析：从 Mermaid 流程图到工作流精修提示词的自动化管线

相关推荐

深入理解 monoio 为何使用 GAT：从 Future 定义到 IO trait 设计的演进之路

本地部署AI数字人形象克隆系统：源码包架构、参数调优与性能优化实战

相控阵终端为什么这么贵？

更多资讯

NaughtyAttributes ShowAssetPreview 详解：在 Unity Inspector 中直接预览 Sprite 与 Prefab 资源

Varlet Pagination 分页组件完全指南：两种模式、属性配置与源码原理剖析

cortex 项目中的 go-openapi/swag jsonutils 模块：动态 JSON、有序键 JSONMapSlice 与可插拔序列化 Adapter 机制全解析

LunaTranslator 游戏实时翻译器使用指南：HOOK、OCR 与内嵌翻译

从Blending到Bagging：集成学习如何用群体决策提升模型稳定性

AI日报自动化实战：多源采集与结构化输出

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？