尧图网站建设 
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载在 GSDGitHub 加速计划 gs / gsd-2的 spec-driven workflow 体系中verify字段是每个步骤产出质量的自动化守门员它定义了引擎如何验证步骤输出是否达标。本文围绕 verification-policies.md 展开完整讲解content-heuristic、shell-command、prompt-verify、human-review四种策略的配置语法、适用场景、校验规则与底层实现并给出真实模板中可直接复用的 YAML 示例。读完本文你将能根据步骤性质为工作流挑选合适的校验策略编写通过定义加载校验的合法verify配置。verify字段的定位步骤输出的验证契约在 V1 工作流定义中每个步骤step由id、name、prompt三个必填字段构成并可选携带requires/depends_on、produces、context_from、iterate与verify参见 yaml-schema-v1.md。其中verify是专门描述如何验证该步骤输出的字段它必须是一个包含policy字段的对象policy只能是以下四个枚举值之一content-heuristic对产物内容做轻量启发式检查shell-command执行 shell 命令以退出码判定通过/失败prompt-verify将验证提示词交给 LLM 进行质量评判human-review暂停执行等待人工审批。从源码看四种策略在 definition-loader.ts 中被建模为一个联合类型| { policy: content-heuristic; minSize?: number; pattern?: string } | { policy: shell-command; command: string } | { policy: prompt-verify; prompt: string } | { policy: human-review };这直观地揭示了每种策略各自的附加字段约束content-heuristic的minSize、pattern可选shell-command必须携带commandprompt-verify必须携带prompthuman-review不需要任何附加字段。实际运行时四种策略在 custom-verification.ts 中分别被映射为三种执行结果continue/retry/pause本文将逐一展开。策略一content-heuristic— 轻量级内容启发式检查content-heuristic针对产物文件执行尺寸与文本模式两项检查所有子字段均可选用于对步骤确实产出了实质性内容做快速健康检查。配置语法verify: policy: content-heuristic minSize: 500 # optional — minimum byte size of the artifact pattern: ## Summary # optional — string pattern that must appear in the artifact字段说明字段类型必填说明policystring是固定为content-heuristicminSizenumber否产物文件的最小字节数patternstring否产物内容中必须出现的文本模式适用场景当你不希望为每个步骤都编写完整的外部校验脚本时用它做步骤是否有实质输出的轻量 sanity check例如检查研究笔记是否达到一定长度、草稿是否包含## Summary标题。该策略在官方模板中应用最广blog-post-pipeline.yaml的三个步骤全部采用该策略见下文release-checklist.yaml的 changelog 步骤与code-audit.yaml的 inventory 步骤也用它兜底。底层实现细节src/resources/extensions/gsd/custom-verification.ts 中的处理流程可以概括为三步产物存在性首先检查produces声明的产物文件是否存在缺失即判定验证失败minSize字节数检查若设置了minSize通过stat.size比较实际文件大小小于阈值即失败pattern正则匹配若设置了pattern用new RegExp(verify.pattern)对文件内容做测试不匹配即失败若该模式本身不是合法正则引擎会记录 warning 并按失败处理。值得注意虽然文档中pattern表述为string pattern但其底层实际以 JavaScript 正则表达式执行匹配因此你可以传入类似^- .\.ts$这样的正则模式而不只是字面字符串。此外三种失败原因文件缺失、低于 minSize、模式不匹配都会在日志中具体输出便于定位问题。策略二shell-command— 程序化命令校验shell-command通过执行一条 shell 命令来验证步骤输出判定标准是命令的退出码退出码为 0 表示验证通过非 0 表示失败。这是四者中表达能力最强、最贴近 CI/CD 习惯的策略文件存在性检查、测试套件执行、lint、编译等都适用。配置语法verify: policy: shell-command command: test -f output/report.md wc -l output/report.md | awk {print ($1 10)}字段说明字段类型必填说明policystring是固定为shell-commandcommandstring是非空要执行的 shell 命令适用场景当验证逻辑需要程序化判定——例如产物文件是否存在、测试套件是否通过、代码是否通过 lint、项目能否编译——优先使用本策略。官方模板中有两个典型用法release-checklist.yaml用grep校验版本号格式verify: policy: shell-command command: grep -E ^[0-9]\\.[0-9]\\.[0-9]$ version.txtcode-audit.yaml用test -f校验审计结果文件是否生成verify: policy: shell-command command: test -f audit-results.md底层实现与安全边界src/resources/extensions/gsd/custom-verification.ts 揭示了三个关键实现细节执行方式命令通过sh -c执行cwd设为运行目录stdio为 pipe并设置了30 秒超时超时或被信号终止同样视为失败retry。退出码语义result.status 0返回continue放行否则返回retry重试。验证失败后的重试行为由引擎统一处理custom-verification.ts顶部注释说明exit 0 → continue, else retry。注入防护实现内置了危险模式正则/\$\(||;\s*(rm|curl|wget|nc|bash|sh|eval)\b/一旦命令包含命令替换、反引号或与删除/下载/反弹 shell 相关的拼接模式校验器会跳过执行并返回pause暂停而非直接放行。需要强调的信任边界命令字符串来源于 workflow 定义时冻结的 DEFINITION.yaml命令以 GSD 进程同等权限运行因此只应对信任的工作流定义使用shell-command——这一安全提示同样明确写在该文件的注释中。编写命令时注意 YAML 中\与$的转义如上面grep示例中正则里的\\。策略三prompt-verify— 交给 LLM 的智能评判prompt-verify将一段验证提示词发送给 LLM由模型对步骤输出进行评估。它适用于无法用 shell 命令表达的判断型验证质量评估、完整性审查、风格符合度检查等。配置语法verify: policy: prompt-verify prompt: Review the generated API documentation. Does it cover all endpoints with request/response examples? Answer PASS or FAIL with reasoning.字段说明字段类型必填说明policystring是固定为prompt-verifypromptstring是非空发送给 LLM 的验证提示词适用场景当验证需要超出命令表达能力的判断力时使用。官方code-audit.yaml的最终 report 步骤即采用此策略验证报告是否覆盖所有被审计文件并按严重级别分组verify: policy: prompt-verify prompt: Does the report cover all audited files and group findings by severity? Answer PASS or FAIL.编写prompt时建议像示例一样给出明确判定规则Answer PASS or FAIL并补充可核对的具体标准如是否覆盖所有端点、是否包含请求/响应示例以提高评判的一致性与可追溯性。运行时行为在 custom-verification.ts 中prompt-verify与human-review一样总是返回pause——即引擎暂停该步骤的自动化放行将验证交还给上层 Agent 驱动 LLM 完成评判。这是设计中确定性与智能性的分工确定性校验两种启发式策略由引擎直接判定而需要理解力的验证则回到 Agent 的循环中由模型结合提示词产出 PASS/FAIL 结论后再决定是否继续。策略四human-review— 人工审批门控human-review暂停执行流程等待人类对步骤输出做出批准或拒绝。它不包含任何附加字段是最简单也最重的校验策略。配置语法verify: policy: human-review字段说明字段类型必填说明policystring是固定为human-review适用场景当步骤产出需要人类判断力时使用例如涉及设计决策的产出、面向公众的内容、安全敏感变更。release-checklist.yaml的最终 publish 步骤就是典型代表——发布动作不可逆交给人工把关verify: policy: human-review从实现看该策略与prompt-verify一样返回pause等待人工检查意味着引擎不会自动放行工作流停留在该步骤等待用户确认。定义加载期的校验规则引擎在**定义加载时definition-load time**就会对verify对象做静态校验而不是等到运行期才暴露问题。从 definition-loader.ts 可确认以下规则policy必须是content-heuristic、shell-command、prompt-verify、human-review四个字符串之一任何其他取值都会被拒绝shell-command必须携带非空command字段缺失或为空字符串会被拒绝错误信息形如Step id verify policy shell-command requires a non-empty command fieldprompt-verify必须携带非空prompt字段缺失或为空会被拒绝content-heuristic与human-review除policy外没有必填子字段。这套校验意味着一个非法policy或缺少必要子字段的verify会在/gsd workflow validate阶段直接被拦截便于在写入.gsd/workflows/后立即发现错误。相关规则同时被 definition-loader.test.ts 与 custom-verification.test.ts 中的测试用例覆盖是经过回归保障的契约行为。组合实战从官方模板看策略选型理解四种策略后关键在于在正确的位置用正确的策略。官方模板集中展示了三种典型组合模式1. 线性链 content-heuristic全程兜底templates/blog-post-pipeline.yamlparams: topic: AI audience: developers steps: - id: research name: Research the topic prompt: - Research the topic {{ topic }} for an audience of {{ audience }}. Write detailed findings including key trends, important facts, and relevant examples. Save the results to research.md. requires: [] produces: - research.md verify: policy: content-heuristic minSize: 200 - id: outline name: Create an outline prompt: - Using the research findings, create a structured blog post outline targeting {{ audience }}. Include section headings, key points for each section, and a logical flow. Save to outline.md. requires: - research context_from: - research produces: - outline.md verify: policy: content-heuristic - id: draft name: Write the draft prompt: - Write a complete blog post draft following the outline. The post should be engaging for {{ audience }}, cover all outlined sections, and include a compelling introduction and conclusion. Save to draft.md. requires: - outline context_from: - outline produces: - draft.md verify: policy: content-heuristic minSize: 5002. 迭代扇形展开 命令校验 LLM 评判templates/code-audit.yamlinventory用content-heuristic确保文件清单非空audit-file用iterate按^- (.\.ts)$模式逐个审计文件并以shell-command的test -f audit-results.md确认每个子执行都写入了结果最终report步骤用prompt-verify检查报告完整性。3. 菱形依赖 人工审批收口templates/release-checklist.yamlchangelog用content-heuristicversion-bump用shell-command的grep校验 semver 格式test-suite用test -f确认测试结果文件存在publish作为汇聚点用human-review把最终发布交给人工把关。这三种模式覆盖了日常绝大多数工作流形态可作为自建工作流的起点。空白脚手架见 templates/workflow-definition.yaml其中四种verify策略均已注释形式给出可直接复制反注释使用更完整的字段说明可查阅 references/yaml-schema-v1.mdcontext_from、iterate、params的进阶用法见 references/feature-patterns.md。选型速查与验证闭环步骤产出特征推荐策略关键附加字段只需确认有实质输出content-heuristic可选minSize、pattern需要确定性程序判定存在性/测试/lint/编译shell-command必填command需要质量、完整性、风格等智能评判prompt-verify必填prompt设计决策、公众内容、安全敏感变更human-review无将工作流定义写入.gsd/workflows/name.yaml项目级建议入库或~/.gsd/workflows/name.yaml全局加--global之后先运行/gsd workflow validate name触发上文所述的加载期校验再运行/gsd workflow name执行。校验失败时shell-command会得到retry重试机会prompt-verify与human-review会得到pause等待上层决策而content-heuristic的具体失败原因文件缺失/尺寸不足/模式不匹配会写入日志——理解这些运行时行为能让你在定位工作流卡点时快速判断是该修产物还是该换策略。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐gsd-core 版本管理与发布策略全解析从 SemVer 三级发布、npm dist-tag 到自动化 Release 工作流gsd core 版本管理与发布策略全解析从 SemVer 三级发布、npm dist tag 到自动化 Release 工作流 Git. Ship. Dongsd-2 GitOps 发布分支策略next / release 分支自动化工作流脚手架全解析gsd 2 GitOps 发布分支策略next / release 分支自动化工作流脚手架全解析 本篇技术指南以 gsd 2 仓库中 docs/dev/pro人工智能AI Agent代码智能体Agent 编排CLIAI 应用GSD Bugfix 工作流模板实战从缺陷识别到 PR 提交的四阶段自动化修复流程GSD Bugfix 工作流模板实战从缺陷识别到 PR 提交的四阶段自动化修复流程 GSD 2 内置的 Bugfix 工作流模板 src/resources人工智能AI Agent代码智能体Agent 编排CLIAI 应用上一篇揭秘AI图层分离神器layerdivider如何让设计师告别手动抠图下一篇QtNodes API 全景速查核心类、数据模型与扩展接口指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GSD 工作流校验策略全解：从 content-heuristic 到 human-review 的四级自动化门控
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载在 GSDGitHub 加速计划 gs / gsd-2的 spec-driven workflow 体系中verify字段是每个步骤产出质量的自动化守门员它定义了引擎如何验证步骤输出是否达标。本文围绕 verification-policies.md 展开完整讲解content-heuristic、shell-command、prompt-verify、human-review四种策略的配置语法、适用场景、校验规则与底层实现并给出真实模板中可直接复用的 YAML 示例。读完本文你将能根据步骤性质为工作流挑选合适的校验策略编写通过定义加载校验的合法verify配置。verify字段的定位步骤输出的验证契约在 V1 工作流定义中每个步骤step由id、name、prompt三个必填字段构成并可选携带requires/depends_on、produces、context_from、iterate与verify参见 yaml-schema-v1.md。其中verify是专门描述如何验证该步骤输出的字段它必须是一个包含policy字段的对象policy只能是以下四个枚举值之一content-heuristic对产物内容做轻量启发式检查shell-command执行 shell 命令以退出码判定通过/失败prompt-verify将验证提示词交给 LLM 进行质量评判human-review暂停执行等待人工审批。从源码看四种策略在 definition-loader.ts 中被建模为一个联合类型| { policy: content-heuristic; minSize?: number; pattern?: string } | { policy: shell-command; command: string } | { policy: prompt-verify; prompt: string } | { policy: human-review };这直观地揭示了每种策略各自的附加字段约束content-heuristic的minSize、pattern可选shell-command必须携带commandprompt-verify必须携带prompthuman-review不需要任何附加字段。实际运行时四种策略在 custom-verification.ts 中分别被映射为三种执行结果continue/retry/pause本文将逐一展开。策略一content-heuristic— 轻量级内容启发式检查content-heuristic针对产物文件执行尺寸与文本模式两项检查所有子字段均可选用于对步骤确实产出了实质性内容做快速健康检查。配置语法verify: policy: content-heuristic minSize: 500 # optional — minimum byte size of the artifact pattern: ## Summary # optional — string pattern that must appear in the artifact字段说明字段类型必填说明policystring是固定为content-heuristicminSizenumber否产物文件的最小字节数patternstring否产物内容中必须出现的文本模式适用场景当你不希望为每个步骤都编写完整的外部校验脚本时用它做步骤是否有实质输出的轻量 sanity check例如检查研究笔记是否达到一定长度、草稿是否包含## Summary标题。该策略在官方模板中应用最广blog-post-pipeline.yaml的三个步骤全部采用该策略见下文release-checklist.yaml的 changelog 步骤与code-audit.yaml的 inventory 步骤也用它兜底。底层实现细节src/resources/extensions/gsd/custom-verification.ts 中的处理流程可以概括为三步产物存在性首先检查produces声明的产物文件是否存在缺失即判定验证失败minSize字节数检查若设置了minSize通过stat.size比较实际文件大小小于阈值即失败pattern正则匹配若设置了pattern用new RegExp(verify.pattern)对文件内容做测试不匹配即失败若该模式本身不是合法正则引擎会记录 warning 并按失败处理。值得注意虽然文档中pattern表述为string pattern但其底层实际以 JavaScript 正则表达式执行匹配因此你可以传入类似^- .\.ts$这样的正则模式而不只是字面字符串。此外三种失败原因文件缺失、低于 minSize、模式不匹配都会在日志中具体输出便于定位问题。策略二shell-command— 程序化命令校验shell-command通过执行一条 shell 命令来验证步骤输出判定标准是命令的退出码退出码为 0 表示验证通过非 0 表示失败。这是四者中表达能力最强、最贴近 CI/CD 习惯的策略文件存在性检查、测试套件执行、lint、编译等都适用。配置语法verify: policy: shell-command command: test -f output/report.md wc -l output/report.md | awk {print ($1 10)}字段说明字段类型必填说明policystring是固定为shell-commandcommandstring是非空要执行的 shell 命令适用场景当验证逻辑需要程序化判定——例如产物文件是否存在、测试套件是否通过、代码是否通过 lint、项目能否编译——优先使用本策略。官方模板中有两个典型用法release-checklist.yaml用grep校验版本号格式verify: policy: shell-command command: grep -E ^[0-9]\\.[0-9]\\.[0-9]$ version.txtcode-audit.yaml用test -f校验审计结果文件是否生成verify: policy: shell-command command: test -f audit-results.md底层实现与安全边界src/resources/extensions/gsd/custom-verification.ts 揭示了三个关键实现细节执行方式命令通过sh -c执行cwd设为运行目录stdio为 pipe并设置了30 秒超时超时或被信号终止同样视为失败retry。退出码语义result.status 0返回continue放行否则返回retry重试。验证失败后的重试行为由引擎统一处理custom-verification.ts顶部注释说明exit 0 → continue, else retry。注入防护实现内置了危险模式正则/\$\(||;\s*(rm|curl|wget|nc|bash|sh|eval)\b/一旦命令包含命令替换、反引号或与删除/下载/反弹 shell 相关的拼接模式校验器会跳过执行并返回pause暂停而非直接放行。需要强调的信任边界命令字符串来源于 workflow 定义时冻结的 DEFINITION.yaml命令以 GSD 进程同等权限运行因此只应对信任的工作流定义使用shell-command——这一安全提示同样明确写在该文件的注释中。编写命令时注意 YAML 中\与$的转义如上面grep示例中正则里的\\。策略三prompt-verify— 交给 LLM 的智能评判prompt-verify将一段验证提示词发送给 LLM由模型对步骤输出进行评估。它适用于无法用 shell 命令表达的判断型验证质量评估、完整性审查、风格符合度检查等。配置语法verify: policy: prompt-verify prompt: Review the generated API documentation. Does it cover all endpoints with request/response examples? Answer PASS or FAIL with reasoning.字段说明字段类型必填说明policystring是固定为prompt-verifypromptstring是非空发送给 LLM 的验证提示词适用场景当验证需要超出命令表达能力的判断力时使用。官方code-audit.yaml的最终 report 步骤即采用此策略验证报告是否覆盖所有被审计文件并按严重级别分组verify: policy: prompt-verify prompt: Does the report cover all audited files and group findings by severity? Answer PASS or FAIL.编写prompt时建议像示例一样给出明确判定规则Answer PASS or FAIL并补充可核对的具体标准如是否覆盖所有端点、是否包含请求/响应示例以提高评判的一致性与可追溯性。运行时行为在 custom-verification.ts 中prompt-verify与human-review一样总是返回pause——即引擎暂停该步骤的自动化放行将验证交还给上层 Agent 驱动 LLM 完成评判。这是设计中确定性与智能性的分工确定性校验两种启发式策略由引擎直接判定而需要理解力的验证则回到 Agent 的循环中由模型结合提示词产出 PASS/FAIL 结论后再决定是否继续。策略四human-review— 人工审批门控human-review暂停执行流程等待人类对步骤输出做出批准或拒绝。它不包含任何附加字段是最简单也最重的校验策略。配置语法verify: policy: human-review字段说明字段类型必填说明policystring是固定为human-review适用场景当步骤产出需要人类判断力时使用例如涉及设计决策的产出、面向公众的内容、安全敏感变更。release-checklist.yaml的最终 publish 步骤就是典型代表——发布动作不可逆交给人工把关verify: policy: human-review从实现看该策略与prompt-verify一样返回pause等待人工检查意味着引擎不会自动放行工作流停留在该步骤等待用户确认。定义加载期的校验规则引擎在**定义加载时definition-load time**就会对verify对象做静态校验而不是等到运行期才暴露问题。从 definition-loader.ts 可确认以下规则policy必须是content-heuristic、shell-command、prompt-verify、human-review四个字符串之一任何其他取值都会被拒绝shell-command必须携带非空command字段缺失或为空字符串会被拒绝错误信息形如Step id verify policy shell-command requires a non-empty command fieldprompt-verify必须携带非空prompt字段缺失或为空会被拒绝content-heuristic与human-review除policy外没有必填子字段。这套校验意味着一个非法policy或缺少必要子字段的verify会在/gsd workflow validate阶段直接被拦截便于在写入.gsd/workflows/后立即发现错误。相关规则同时被 definition-loader.test.ts 与 custom-verification.test.ts 中的测试用例覆盖是经过回归保障的契约行为。组合实战从官方模板看策略选型理解四种策略后关键在于在正确的位置用正确的策略。官方模板集中展示了三种典型组合模式1. 线性链 content-heuristic全程兜底templates/blog-post-pipeline.yamlparams: topic: AI audience: developers steps: - id: research name: Research the topic prompt: - Research the topic {{ topic }} for an audience of {{ audience }}. Write detailed findings including key trends, important facts, and relevant examples. Save the results to research.md. requires: [] produces: - research.md verify: policy: content-heuristic minSize: 200 - id: outline name: Create an outline prompt: - Using the research findings, create a structured blog post outline targeting {{ audience }}. Include section headings, key points for each section, and a logical flow. Save to outline.md. requires: - research context_from: - research produces: - outline.md verify: policy: content-heuristic - id: draft name: Write the draft prompt: - Write a complete blog post draft following the outline. The post should be engaging for {{ audience }}, cover all outlined sections, and include a compelling introduction and conclusion. Save to draft.md. requires: - outline context_from: - outline produces: - draft.md verify: policy: content-heuristic minSize: 5002. 迭代扇形展开 命令校验 LLM 评判templates/code-audit.yamlinventory用content-heuristic确保文件清单非空audit-file用iterate按^- (.\.ts)$模式逐个审计文件并以shell-command的test -f audit-results.md确认每个子执行都写入了结果最终report步骤用prompt-verify检查报告完整性。3. 菱形依赖 人工审批收口templates/release-checklist.yamlchangelog用content-heuristicversion-bump用shell-command的grep校验 semver 格式test-suite用test -f确认测试结果文件存在publish作为汇聚点用human-review把最终发布交给人工把关。这三种模式覆盖了日常绝大多数工作流形态可作为自建工作流的起点。空白脚手架见 templates/workflow-definition.yaml其中四种verify策略均已注释形式给出可直接复制反注释使用更完整的字段说明可查阅 references/yaml-schema-v1.mdcontext_from、iterate、params的进阶用法见 references/feature-patterns.md。选型速查与验证闭环步骤产出特征推荐策略关键附加字段只需确认有实质输出content-heuristic可选minSize、pattern需要确定性程序判定存在性/测试/lint/编译shell-command必填command需要质量、完整性、风格等智能评判prompt-verify必填prompt设计决策、公众内容、安全敏感变更human-review无将工作流定义写入.gsd/workflows/name.yaml项目级建议入库或~/.gsd/workflows/name.yaml全局加--global之后先运行/gsd workflow validate name触发上文所述的加载期校验再运行/gsd workflow name执行。校验失败时shell-command会得到retry重试机会prompt-verify与human-review会得到pause等待上层决策而content-heuristic的具体失败原因文件缺失/尺寸不足/模式不匹配会写入日志——理解这些运行时行为能让你在定位工作流卡点时快速判断是该修产物还是该换策略。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐gsd-core 版本管理与发布策略全解析从 SemVer 三级发布、npm dist-tag 到自动化 Release 工作流gsd core 版本管理与发布策略全解析从 SemVer 三级发布、npm dist tag 到自动化 Release 工作流 Git. Ship. Dongsd-2 GitOps 发布分支策略next / release 分支自动化工作流脚手架全解析gsd 2 GitOps 发布分支策略next / release 分支自动化工作流脚手架全解析 本篇技术指南以 gsd 2 仓库中 docs/dev/pro人工智能AI Agent代码智能体Agent 编排CLIAI 应用GSD Bugfix 工作流模板实战从缺陷识别到 PR 提交的四阶段自动化修复流程GSD Bugfix 工作流模板实战从缺陷识别到 PR 提交的四阶段自动化修复流程 GSD 2 内置的 Bugfix 工作流模板 src/resources人工智能AI Agent代码智能体Agent 编排CLIAI 应用上一篇揭秘AI图层分离神器layerdivider如何让设计师告别手动抠图下一篇QtNodes API 全景速查核心类、数据模型与扩展接口指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考