Skip to main content

BLOGE 0.9.8-RC1 在线版 · 事实校验 2026-09-15 · English

第二阶段回顾 —— 可维护编写（第 5–9 章）

你现在可以编写带分支、带韧性的工作流，并用干净、可审查的 DSL 文件表达它们。

你学到了什么​

第 5 章——做决策的分支 引入了 branch on 进行控制面路由。你了解了引擎如何将未选中的路径标记为 SKIPPED、otherwise 为什么必不可少，以及 branch on（路由）和 when（值选择）的区别。

第 6 章——韧性设计 展示了 retry、timeout、fallback 和 compensate 都是 graph 级声明，而非 try/catch 内联代码。你学会了将策略附加到节点上、将它们分层组合（retry → timeout → fallback），并预测策略交互时的引擎行为。

第 7 章 —— 设计良好的 Operator 把注意力转向了 operator 边界。你了解了什么让 operator 可测试（单一职责、无隐藏状态、声明式 schema）、如何惯用地处理失败，以及何时返回丰富结果类型而非直接抛异常。

第 8 章——把个人 DSL 草稿变成团队资产 将所有内容整合到可维护的 .bloge 文件中。你练习了 graph 级 schema、文档注释、命名 schema、let 绑定和一致的文件布局，让个人草稿变成可审查的团队资产。

第 9 章 —— 工具链工作流 补上了编写闭环。你让一次修改依次经过编辑器诊断、lint、测试、graph 渲染和 PR 证据，使“我能写”升级为“别人能审”。

你现在应该能做到​

  • 用 branch on 将执行路由到不同路径，并用 otherwise 提供安全默认值。
  • 为需要的节点附加 retry、timeout 和 fallback，并解释其他节点为什么不需要。
  • 设计一个具有清晰输入/输出契约和可测试边界的 operator。
  • 编写一个包含 schema、文档注释、分支、韧性策略和 transform 的完整 .bloge 文件。
  • 审查他人的 .bloge 文件并识别结构性问题。
  • 跑通编辑 → lint → 测试 → 可视化闭环，并为评审附上最小充分证据。

这个阶段的常见错误​

错误为什么会犯如何纠正
分支表达式类型不匹配在引擎期望 enum 或 boolean 的位置用了字符串让 branch on 表达式的类型与声明的 case 完全匹配。
给每个节点都加 retry防御本能只对调用不稳定外部系统的节点加 retry；纯逻辑节点不应该重试。
忘记 otherwise自信地认为所有 case 都已覆盖始终包含 otherwise——即使它路由到错误节点——以避免 graph 静默卡住。
Operator 内部依赖 graph 结构把 graph context 内部信息传递给了 operator 逻辑Operator 接收类型化输入和 context；它不应该导航 graph 模型。
不写 schema 文档"类型很明显"添加 /// 文档注释和显式 schema 块；成本为零，却能为下一位读者节省大量时间。
把编辑器诊断当成正确性证明红线看起来很权威编辑器负责缩短反馈，parser 与行为测试才负责判定正确性。

新增核心词汇​

术语含义
branch on控制面路由：根据运行时值将执行导向多个目标节点之一。
otherwise当没有显式 case 匹配时的默认分支目标。
SKIPPED未被选中的分支路径上的节点所获得的状态。
retry韧性策略：失败时最多重新执行 N 次。
timeout韧性策略：节点执行超过指定时长时取消。
fallback韧性策略：主逻辑失败时替换为默认结果。
compensate韧性策略：当已成功的节点需要撤销时执行清理操作。
Schemagraph 或 node 的输入/输出契约的命名或内联类型声明。
编写闭环让同一次修改依次经过编辑、lint、测试、可视化与评审。

试一试：准备一个可评审改动​

同事给支付 graph 的每个 node 都加了 retry，PR 里只有一张 DSL 截图。请给每个 node 标记“保留 retry”或“删除 retry”，再写出评审前必须补齐的三份证据。好的答案会区分不可靠 I/O 与确定性逻辑，并要求 lint 结果、聚焦行为测试，以及能看出路径变化的 graph 图。

下一步​

第三阶段回顾教你组合：子图复用、批处理迭代、等待外部事件和持久执行。从第 10 章 —— 用子图复用开始。