Qoder 辅助节点开发

核心问题

需求文档写好了，任务也拆解完了，现在要开始写代码了。Qoder 具体怎么帮你加速和保质量？

这一章聚焦在编码阶段——Qoder 的 Rule、Skill、CodeReview 如何在编码过程中发挥作用。

⚠️ 注意：form.json + script.ps1 的节点架构设计是 Growth 产品自身的架构，Qoder 不参与这个设计。Qoder 的角色是让这个设计被严格执行——用 Rule 约束、用 Skill 加速、用 Review 兜底。

使用篇：Rule 约束编码行为

Rule 在编码阶段做了什么

你在第二章配置了 Rule，现在它们开始发挥作用。

假设你在写"文件压缩节点"的代码。没有 Rule 的情况下，AI 可能会这样写：

csharp

// 没有 Rule 约束的 AI 代码
public async Task<Dictionary<string, object>> ExecuteAsync(Dictionary<string, object> input)
{
    try
    {
        var sourcePath = input["sourcePath"].ToString();
        var outputPath = input["outputPath"].ToString();
        var format = input["format"].ToString();
        
        if (sourcePath != null)
        {
            if (outputPath != null)
            {
                if (format != null)
                {
                    // 真正的压缩逻辑被三层 if 包裹
                }
            }
        }
    }
    catch (Exception ex)
    {
        // 什么都不做——异常被吞掉了
    }
}

这段代码的问题：

深层嵌套（三层 if）
异常被吞掉（空的 catch）
没有日志（不知道执行到哪一步了）

有了 Rule 之后，AI 生成的代码会自动变成这样：

csharp

// 有 Rule 约束的 AI 代码
public async Task<Dictionary<string, object>> ExecuteAsync(
    Dictionary<string, object> input, ILogger logger, CancellationToken ct)
{
    LogFormatHelper.EnterScope("执行文件压缩节点", LoggerName);
    
    // early-return：前置条件不满足直接返回
    if (!input.TryGetValue("sourcePath", out var sourcePathObj))
        return CreateErrorResult("缺少 sourcePath");
    if (!input.TryGetValue("outputPath", out var outputPathObj))
        return CreateErrorResult("缺少 outputPath");
    
    var sourcePath = sourcePathObj.ToString();
    var outputPath = outputPathObj.ToString();
    var format = input.GetValueOrDefault("format", "zip").ToString();
    
    // 核心业务逻辑——不套 try-catch，异常向上抛出
    var result = await CompressAsync(sourcePath, outputPath, format, ct);
    
    LogFormatHelper.ExitScope("成功", LoggerName);
    return new Dictionary<string, object>
    {
        ["success"] = true,
        ["outputPath"] = result.OutputPath,
        ["fileSize"] = result.FileSize
    };
}

区别一目了然：Rule 约束下的代码更规范、更安全、更容易维护。

Rule 约束效果对比

贯穿案例：写"文件压缩节点"的代码

回到贯穿案例。需求文档确认后，你让 AI 开始编码：

按方案实现"文件压缩节点"

因为 Rule 已经配置好了，AI 自动：

使用 LogFormatHelper 输出日志（EnterScope/ExitScope 成对出现）
使用 early-return 处理参数校验
不套 try-catch，异常向上抛出
使用正确的命名风格（PascalCase）

你不需要额外提示这些——Rule 已经替你说了。

实践篇：Skill 骨架生成

Skill 在编码阶段的另一个作用

除了编码规范约束，Qoder 的 Skill 还可以直接生成代码骨架。

假设我们有一个 create-node Skill，它的作用是为新节点生成标准化骨架：

markdown

---
name: create-node
description: 创建一个新的工作流节点骨架
---

步骤：
1. 在 Workflow.Node/Nodes/ 下创建 {NodeName}Node.cs
2. 生成标准节点模板（继承 BaseNode、实现 ExecuteAsync）
3. 在 node-registry.json 中添加注册条目
4. 生成 form.json 参数定义骨架
5. 生成 script.ps1 执行脚本骨架

使用效果：

/create-node 文件压缩

AI 一键生成以下骨架文件：

Workflow.Node/Nodes/
├── FileCompressNode.cs    ← 节点执行器（继承 BaseNode）
├── form.json              ← 参数定义（SourcePath/OutputPath/Format）
└── script.ps1             ← 执行脚本（参数注入 + 核心逻辑）

然后你在骨架基础上填充实际逻辑。Skill 生成骨架，你填充逻辑——比从零开始快得多。

为什么骨架生成有价值

骨架的价值不在于"省了几行代码"，而在于消除了每次新建节点时的不一致性。

没有 Skill 的时候，每次新建节点可能会有不同的：

文件命名风格（FileCompressNode.cs vs compress_node.cs）
参数定义方式（JSON Schema vs 自定义格式）
输出格式（返回 Dictionary 还是自定义对象）
错误处理方式（抛出异常还是返回错误码）

有了 Skill，所有这些不一致在骨架阶段就被消除了。

实践篇：编码中引导——让 AI 参考已有代码

为什么需要引导

即使有了 Rule 和 Skill，AI 在编码过程中仍然可能偏离方向。原因是：AI 不知道项目中已有的代码风格和模式，除非你引导它去参考。

如何引导

在编码过程中，随时让 AI 参考已有代码：

"参考 Components/Workflow/Nodes/DirCompressNode.cs 的实现风格，
新建一个 FileCompressNode.cs，逻辑类似但改为文件压缩"

这样 AI 会先阅读 DirCompressNode 的代码，理解它的实现模式，然后用同样的风格写 FileCompressNode。

引导的三个层次

层次	示例	效果
模糊引导	"参考已有的压缩节点"	AI 可能找到也可能找不到
精确引导	"参考 DirCompressNode.cs"	AI 精确定位到目标文件
路径+意图	"参考 Workflow.Nodes/DirCompressNode.cs 的错误处理模式"	AI 理解参考的具体方面

实践篇：CodeReview 兜底

代码写完了，然后呢

AI 写完了代码，但你不能直接信任它。Growth 项目的要求是每次代码改动后都做一次 CodeReview。

在 Agent 模式下，改完后直接说：

"审查本次修改"

Qoder 会自动触发 CodeReview SubAgent，加载审查 Checklist，对本次修改的代码进行专业审查。

CodeReview 发现什么问题

在"文件压缩节点"的开发中，CodeReview 可能发现：

[Critical] 未处理源文件不存在的情况
  → 如果 sourcePath 指向的文件不存在，会抛出未处理的 FileNotFoundException

[Suggestion] 7z 格式的压缩级别未暴露
  → form.json 中缺少 compressionLevel 参数

你根据审查结果修正代码，然后再次审查，直到所有问题都解决。

CodeReview 的原则

发现问题，不是做风格检查。 CodeReview SubAgent 关注的是：

逻辑缺陷：边界条件是否覆盖、异常路径是否处理
安全问题：路径遍历、命令注入等
架构合规：是否违反了模块边界、依赖方向
一致性：是否与项目中同类节点的实现风格一致

风格问题（缩进、命名）不应该出现在 CodeReview 中——它们应该由 Rule 提前规避。

知识篇：为什么需要四步走

你可能觉得"写个节点而已，需要 Rule + Skill + 引导 + Review 四步吗？"

答案是：单步走很快，但四步走的累积速度更快。

步骤	省了什么
Rule	省了"每次提醒 AI 规范"的成本
Skill	省了"每次新建节点重复劳动"的成本
引导	省了"AI 理解项目风格"的学习成本
Review	省了"上线后发现 Bug"的修复成本

每一层都在消除一类不确定性。四层叠加，不是 4 倍效率，而是一个数量级的效率提升——因为 Bug 在更早的阶段就被消除，不需要返工。

编码四步走

本章小结

Qoder 能力	编码阶段的作用	对贯穿案例的贡献
Rule 约束	自动规范编码行为	节点代码符合规范
Skill 骨架	一键生成标准化骨架	减少重复劳动
编码引导	参考已有代码保持风格	节点风格统一
CodeReview	审查发现潜在缺陷	上线前消除 Bug

关联：第一部分 05（Rule 规则系统）、第一部分 04（Skill 技能包）。

Qoder 辅助节点开发 ​

核心问题 ​

使用篇：Rule 约束编码行为 ​

Rule 在编码阶段做了什么 ​

贯穿案例：写"文件压缩节点"的代码 ​

实践篇：Skill 骨架生成 ​

Skill 在编码阶段的另一个作用 ​

为什么骨架生成有价值 ​

实践篇：编码中引导——让 AI 参考已有代码 ​

为什么需要引导 ​

如何引导 ​

引导的三个层次 ​

实践篇：CodeReview 兜底 ​

代码写完了，然后呢 ​

CodeReview 发现什么问题 ​

CodeReview 的原则 ​

知识篇：为什么需要四步走 ​

本章小结 ​