应用示例
一个需求进入，完整的流程向前。
以重复发生的内部请求为例：流程获取当前信息、提出下一步动作、检查执行权限，完成允许的步骤，或将例外交给负责人。我们验证的是这个完整闭环。
按具体流程约定的衡量维度
- 任务完成情况
- 人工复核与返工
- 恰当的异常升级
- 总体运行成本
开始前约定范围、节奏、费用、团队投入与支持责任。已有的系统与能力，是计划的起点。
构建与验证
适合这样的起点
- 新产品已有一段清晰的用户旅程需要验证。
- 重复发生的工作有明确负责人和可衡量的起点。
- 已有原型，需要真正集成和评测后再扩大使用。
开始前需要什么
- 一个有边界的目标，以及能够验收的人。
- 获准使用的数据、工具访问与代表性测试样本。
- 明确的专业评审时间和发布决策归属。
怎样知道它真的有效
在构建前约定成功的含义。我们评估任务完成、产出质量，以及复核、纠错和运行所需的总投入。演示提供直观感受，验收决定由完整证据支持。
让合适的人，承担合适的工作。
你的团队
定义什么是正确结果，评审专业内容，并决定哪些改变可以进入实际工作。
Spell.fm
构建并集成系统，实现运行控制，与业务评审者一起完成验证。
从意图到证据，前后连贯。
产品旅程与业务流程背后的工程闭环。每次交接，都带着上下文、产物和明确的决定。
让工作前后相连交付流程示意
01 / 发现
从值得改变的工作开始。
观察真实工作、发生频率和实际约束。共同确定基线、要作出的决定，以及需要参与的人。
交付给下一阶段
- 流程与价值基线
- 成功标准
- 有边界的需求
02 / 设计
给想法一个形状。
连接产品思考、体验设计与技术架构。用可运行的原型探索可能，在进入开发前确定方向。
交付给下一阶段
- 产品规格
- 可运行原型
- 确认的方向
03 / 构建
让智能体接棒。
围绕共同的计划协调工程智能体。为每项任务提供所需的上下文、工具和隔离工作区，再将成果汇合。
交付给下一阶段
- 可用的软件
- 可审查的变更
- 可复用的知识
04 / 验证
把好坏交给证据。
用代表性任务、失败场景和权限测试，对照约定的基线。把人工复核、纠错与运营所需的投入一起算进去。
交付给下一阶段
- 任务与边界评测
- 审查证据
- 发布决策
05 / 发布
上线被确认的变更。
让发布与审查过的产物一一对应。通过受控上线、可观测性与恢复路径，把成果带进生产环境。
交付给下一阶段
- 版本化产物
- 受控发布
- 恢复方案
06 / 演进
让下一步接住已有成果。
带着已实现的系统、运行知识与评测历史进入下一轮。让每项变更有人负责，并随着业务变化重新验证假设。
交付给下一阶段
- 运行反馈
- 版本化的工作知识
- 有证据支持的下一步
人确定方向，智能体执行，证据贯穿每一次交接。
合作中的实际问题
试点就是生产系统吗？
交付状态会明确区分：原型探索可行性，受控试点验证限定场景。进入生产前，需要通过约定的访问、质量、安全、监控与恢复检查。
是不是每个人都要学会写代码？
业务专家定义工作并评估结果，工程师负责集成与控制的实现。赋能围绕各角色实际要接手的任务展开。
如何验证安全护栏？
检查真实的执行路径，包括身份、权限、工具边界及其他可用路径。测试覆盖不被允许的动作与失败行为。模型指令提供指导，控制还需要在系统层落实。