01.摸清现在的活是怎么干的
Gravibot会访谈一线员工，阅读你们授权的文件和记录，再看一段实际操作的录屏。书面流程里漏掉的步骤，录屏里一看就知道。
没有固定的问卷。两个团队对同一次交接说法不一样，Gravibot就追问差别在哪。某项工作老是被退回重做，它就把这些案例找出来，问清楚返工的原因。
最后你会拿到一张现有流程图，每一步都附上依据，外加待确认的问题，和一份排好优先级的改进清单。
在订单演示里，Gravibot发现一张订单要100件，库存只有80件。动手设计之前，它先问清楚缺货时要不要先发一部分。
02.把了解到的情况建成业务模型
Gravibot把业务拆成一个个对象，比如订单、发货单、发票、客户和审批。每个对象它都记下状态怎么变、数据存在哪个系统、相关规则归谁管。
每条规则都能追溯到出处，可能是某次访谈、某份文件或某条记录。访谈说法和系统记录对不上时，Gravibot会标出冲突，请负责人拍板。
在演示里，模型把订单数量、可用库存、发货状态，以及运营负责人定下的部分发货规则串在了一起。
03.设计新流程， 定好验收标准
哪些步骤可以去掉，哪些可以合并，哪些交给智能体，由Gravibot来判断。稳定的计算写成代码。格式不固定的输入，比如客户随手写的邮件，交给智能体处理。业务上规定要人来做的决定，仍然留给人。
写代码之前，设计里就写清楚预期结果、需要的权限和验收标准。如果有两种设计都说得通，Gravibot会讲清楚每种设计对相关人员的工作有什么影响，由你来选。
在演示里，部分发货规则决定了订单是分批发货，还是等货齐了一起发。这个选择会直接写进测试计划。
04.建出智能体、 代码和系统连接
一个工作流往往要用到好几种软件，比如读取来件的智能体、执行固定规则的程序、对接ERP的连接，还有一个让人处理例外的队列。Gravibot逐一建好，已有的直接复用。
有API就走API，没有就直接操作界面。所有开发都在开发环境里完成。它建的每个文件、改的每处配置、做的每个界面，你都能打开来看。
在演示里，Gravibot复用了现有的库存连接，新建了订单提取、产品匹配、分配规则和一个例外队列。
05.用你们确认过的案例来测试
自己出题自己考，说明不了什么。Gravibot用你们团队确认过的验收标准和参考案例来测试，覆盖正常情况、例外情况、权限边界，以及每个相连系统里的最终状态。
API返回成功，只能说明一部分问题。Gravibot还会确认订单确实只建了一张、数量没错、下游团队能接着处理。
测试没通过时，Gravibot先判断问题出在需求、代码还是环境，修好后重跑受影响的测试。失败过的案例会一直留在测试集里。
在演示里，同一张订单来了两次，系统建了两条记录。Gravibot加上重复检查，并确认重试时不会再多建一张。
06.先在小范围上线
Gravibot按你们为这个流程设定的权限和条件上线。风险大的，先和现有流程并行跑、对比结果，或者先只接一小部分业务。
上线前，它会写好操作说明，写明每类例外归谁处理。所有软件改动都能回滚。付款这类撤不回来的操作，上线计划里会写清楚由谁审批。
在演示里，试运行只在演示环境里处理示例订单，不碰任何真实系统。
07.持续改进， 找到下一件值得做的事
上线后，Gravibot会持续关注运行结果、例外和反馈。政策调整、来了新格式的文件、某个集成出了故障，都会触发新一轮设计、开发和测试。
它不只做修补。Gravibot还会找出能用上同一批业务知识的相关工作，估算工作量，提出下一个要建的流程。做不做，由你决定。
交付记忆把下一项任务和已经建好的一切连在一起。以前的一次纠正，变成了一个测试。一条确认过的规则，可以用到第二个流程里。一个现成的连接，可以服务另一项批准过的任务。
在演示里，Gravibot提议接着做报价准备，直接复用订单流程里的产品、价格和库存知识。
你们的团队在哪些环节参与
你们的团队负责定优先级、提供业务知识、拍板需要负责人决定的事。调查、开发、测试和后续跟进，由Gravibot在授权范围内完成。
需要拍板时，Gravibot会带着证据来，讲清楚每个选项分别意味着什么。日常的交接，不需要任何人来协调。
时间越长，你们团队要亲自做的交付工作越少，但Gravibot在做什么，你们始终一清二楚。
从你们手头的业务开始
一份书面流程、几条示例记录、一个现有系统，或者一段简短的操作演示，就足够开始了。缺什么，Gravibot会边做边问。