用 TRAE Work 拆解一次“老订单程序加退款状态机”的紧急方案

我有一个前同事老陈，在一家电商公司负责订单程序。去年夏天他接到一个任务：周五前给出“老订单程序增加退款状态机”的技术方法。

原有订单状态只有“待支付、已支付、已发货、已完成”。现在要增加“退款中、部分退款、已退款、退款失败”四类状态，而且不能影响线上正在运行的订单，也不能停机发布。

老陈说这类任务最容易陷入两个极端：

• 直接翻代码。几个人各自理解一遍，最终在会议上争论状态定义；
• 把整份需求丢给 AI，让它一次性生成一份看起来完整、实际无法落地的方案。

他最终选择的做法，是把任务拆成可检查的步骤。让 TRAE Work 负责信息整理和初稿生成，再由人工确认业务规则、资金相关逻辑和发布风险。

先明确任务边界

老陈这个任务的输入材料包括：

如果直接提出“请分析代码并输出技术方法”，模型需要同时完成代码检索、需求理解、状态建模、数据库设计和发布规划。按理说，任何一层理解错误，都会污染后面的全部内容。

验收标准：

1. 列出当前程序已有的订单状态，还有每个状态的写入位置。怎么说呢，
2. 区分订单主状态、退款状态和支付流水状态。不能混为一个字段，
3. 所有退款事件都要有来源和触发条件。
4. 不确定的状态跃迁必须显式标记，不能根据常识补全。
5. 涉及资金和兼容旧状态码的内容，必须由人工最终确认。
6. 最终方案需要包含状态图、数据库变更、接口改动和灰度发布清单。

从第一步先来看。建立现状事实层

老陈把 PRD、主要代码目录和表结构说明放入 TRAE Work 的工作上下文后只做信息提取，不让它直接设计新方案。

关键约束：先提取，不判断。

例如代码里可能有多个地方修改订单状态。某个方法名称看起来像“支付成功”，并不代表着它一定是唯一的状态入口；不过，某个字段叫 Status也不代表着它只代表订单主状态。先把候选位置列出来再由开发者回到代码确认，比直接让模型“程序是怎么工作的”更容易发现遗漏。

再看接下来，把复杂问题拆成四个子任务

子任务 A：枚举退款事件

• 使用者主动申请退款；
• 商家同意退款；
• 退款超时后自动处理；
• 部分商品退款；支付成功后订单取消，
• 退款失败后的重试或人工处理。

The task instruction must require each event to contain: trigger party,pre‑state,expected result and source. If PRD does not clarify an event。mark it “待确认”.

子 任务 B ： 枚举 合 法 状 态 跃 迁

子 任务 C ： 识 别 边 界 条 件          

• ...

子 任 务 D ： 生 成 方 案 骨 架  

1. …