用 TRAE Work 拆解一次"老订单系统加退款状态机"的紧急方案
我有一个前同事老陈，在一家电商公司负责订单系统。去年夏天，他接到一个任务：周五前给出"老订单系统增加退款状态机"的技术方案。
原有订单状态只有"待支付、已支付、已发货、已完成"，现在要增加"退款中、部分退款、已退款、退款失败"四类状态，而且不能影响线上正在运行的订单，也不能停机发布。
老陈说，这类任务最容易陷入两个极端：要么直接翻代码，几个人各自理解一遍，最后在会议上争论状态定义；要么把整份需求丢给 AI，让它一次性生成一份看起来完整、实际无法落地的方案。
他最后选择的做法，是把任务拆成可检查的步骤，让 TRAE Work 负责信息整理和初稿生成，再由人工确认业务规则、资金相关逻辑和发布风险。
先明确任务边界
老陈这个任务的输入材料包括：
- 老订单服务的核心代码仓库，约 3 万行 Java 和 MyBatis 代码；
- 产品侧新写的退款需求 PRD，共 12 页，包含正向和逆向流程；
- 当前订单表、支付流水表的字段说明；
- 约束条件：不允许停机发布，必须兼容旧状态码，周五 18:00 前提交方案。
他后来复盘说，如果直接提出"请分析代码并输出技术方案"，模型需要同时完成代码检索、需求理解、状态建模、数据库设计和发布规划。任何一层理解错误，都会污染后面的全部内容。
所以他第一步不是让 AI 写方案，而是先定义验收标准：
- 必须列出当前系统已有的订单状态，以及每个状态的写入位置。
- 必须区分订单主状态、退款状态和支付流水状态，不能混为一个字段。
- 所有退款事件都要有来源和触发条件。
- 不确定的状态跃迁必须显式标记，不能根据常识补全。
- 涉及资金和兼容旧状态码的内容，必须由人工最终确认。
- 最终方案需要包含状态图、数据库变更、接口改动和灰度发布清单。
这一步的意义，是把"写一份方案"变成一组可以逐项检查的交付要求。
第一步：先建立现状事实层
老陈把 PRD、核心代码目录和表结构说明放入 TRAE Work 的工作上下文后，第一轮只做信息提取，不让它直接设计新方案。
他给 AI 的任务说明大致是这样：
请只基于已提供的代码、PRD 和表结构说明，整理当前订单状态、状态写入位置、支付流水字段及其用途。每条结论保留来源文件或章节。材料中没有明确说明的内容标记为"待人工确认"，不要根据常见电商流程推断。
这里有一个非常重要的约束：先提取，不判断。
例如，代码里可能有多个地方修改订单状态。某个方法名称看起来像"支付成功"，并不意味着它一定是唯一的状态入口；某个字段叫 status，也不意味着它只代表订单主状态。先把候选位置列出来，再由开发者回到代码确认，比直接让模型总结"系统是怎么工作的"更容易发现遗漏。
第一轮的产出应该是一张现状清单，而不是最终设计：
| 信息类别 | 需要确认的内容 | 来源 | 状态 |
|---|---|---|---|
| 订单状态 | 当前已有状态值 | 订单服务代码 | 已提取，待复核 |
| 状态写入 | 修改订单状态的方法和调用路径 | 服务层与持久层代码 | 待复核 |
| 支付流水 | 退款相关字段及含义 | 表结构说明 | 待确认 |
| 业务规则 | 退款触发条件和限制 | 退款 PRD | 待复核 |
表格本身并不难生成，难的是保留"待复核"这个状态。没有确认的内容不应因为整理得很完整，就被误认为已经确定。
第二步：把复杂问题拆成四个子任务
现状事实层确认后，老陈再拆分设计任务。这个场景可以分为四个相互关联、但可以分别检查的子任务。
子任务 A：枚举退款事件
先列出所有可能触发退款的事件：
- 用户主动申请退款；
- 商家同意退款；
- 退款超时后自动处理；
- 部分商品退款；
- 支付成功后订单取消；
- 退款失败后的重试或人工处理。
任务指令应要求每个事件都包含触发方、前置状态、预期结果和来源。若 PRD 没有说明某个事件是否存在，就标记为待确认，而不是主动增加业务流程。
子任务 B：枚举合法状态跃迁
状态机的核心不是状态数量，而是哪些跃迁被允许。
老陈让 TRAE Work 输出这样的结构：
| 当前状态 | 触发事件 | 目标状态 | 前置条件 | 是否明确 | 来源 |
|---|---|---|---|---|---|
| 已支付 | 用户申请退款 | 退款中 | 支付流水存在 | 是/待复核 | PRD 章节 |
| 退款中 | 退款成功 | 已退款 | 金额校验通过 | 是/待复核 | 接口说明 |
| 退款中 | 退款失败 | 退款失败 | 第三方返回失败 | 是/待复核 | 待确认 |
输出时需要特别要求：不要自动补全"看起来合理"的跃迁。状态机中最危险的，往往是那些业务人员没有明确允许、模型却根据常见流程补出来的路径。
子任务 C：识别边界条件
退款状态和订单主状态之间的关系，通常比枚举值更复杂。老陈至少列出以下几个问题：
- 部分退款时，订单主状态是否仍然保持"已完成"？
- 已发货订单能否直接全额退款？
- 退款失败后，订单回到原状态，还是进入异常状态？
- 多次部分退款如何累计金额？
- 订单状态和支付流水状态不一致时，以谁为准？
- 旧订单没有退款字段时，读取逻辑如何兼容？
这些问题不能靠模型替业务方拍板。更合理的处理方式，是让工具整理出问题清单，并把每个问题关联到可能影响的表、接口和状态跃迁，供负责人集中确认。
子任务 D：生成方案骨架
最后才让 TRAE Work 根据已确认和待确认的信息，输出技术方案骨架。方案可以包含：
- 背景和约束；
- 现状状态模型；
- 新增退款状态模型；
- 状态跃迁图；
- 数据库变更；
- 接口与服务层改动；
- 旧状态码兼容策略；
- 灰度发布与回滚清单；
- 待业务确认的问题。
这一步的关键词是"方案骨架"。先生成结构，再由人工填充和修正，比要求一次写出完整方案更容易控制风险。
第三步：逐轮迭代，而不是盲目重写
初稿出来后，老陈最有效的迭代方式不是反复说"再详细一点"，而是针对具体错误提出可验证的修正要求。
例如，模型把"已发货订单可以直接退款"列为合法路径时，他回传：
当前结论缺少来源。请重新检查 PRD 中关于发货后退款的限制，只保留有明确依据的状态跃迁；无法确认的路径放入待确认清单，并说明它会影响哪些接口和数据校验。
如果模型把订单主状态和退款状态合并，他回传：
请将订单主状态、退款单状态、支付流水状态拆成三列重新整理。不要假设它们共用一个字段，也不要修改原有状态码定义。对字段关系缺少依据的部分标记为待人工确认。
这种迭代有两个好处：
第一，错误会被定位到具体的规则，而不是笼统地说"结果不对"。
第二，修正后的结果可以继续作为下一轮输入，逐渐形成一份有来源、有边界的方案材料。
人工复核必须放在关键位置
TRAE Work 在这个场景中的职责，是帮助整理材料、生成状态清单、发现待确认问题和形成方案初稿。它不应直接决定资金状态，也不应自动执行数据库变更或生产发布。
老陈团队的人工复核至少覆盖以下内容。
复核状态跃迁
逐条检查当前状态、触发事件、目标状态和前置条件。尤其关注退款失败、部分退款、重复退款和已发货退款等边界路径。
复核金额与资金逻辑
涉及退款金额、支付流水、累计金额和幂等处理的内容，必须回到真实代码、表结构和业务规则确认。任何看似合理的金额逻辑，都不能仅凭模型生成的表述直接采用。
复核兼容方案
旧订单没有新增字段，旧状态码又不能改变时，需要确认读取和写入逻辑是否会影响既有订单。这里要检查的不只是数据库字段，还包括查询条件、状态判断、接口返回和下游调用。
复核发布策略
"不停机发布"不是一句口号，而是需要落实到数据库变更顺序、代码兼容顺序、灰度范围、回滚条件和异常处理。工具可以帮助整理清单，但发布责任仍然属于人工团队。
结果证据要区分工具贡献和人工判断
据老陈复盘，整个过程中模型生成和整理耗时约 2 小时，人工复核约 1.5 小时，相比团队以往先开会讨论、再整理文档的方式，整体时间大约减少一半。
最终产出包括：
- 一份 8 页 Markdown 技术方案；
- 一张状态跃迁图；
- 12 条关键 SQL 变更说明；
- 一份灰度发布清单。
这些数据来自老陈团队的单次实践，不同团队、不同系统的实际结果会有差异，仅供参考。
更重要的是，不能把这些产出全部归功于 TRAE Work。工具主要承担了材料归纳、状态枚举、问题分组和文档初稿生成；关键状态跃迁、资金相关 SQL、兼容策略和发布风险，仍由人工逐项确认。
"生成了多少内容"不是这类任务的核心指标。真正值得保留的结果证据应该包括：哪些输入被覆盖，哪些问题被提前发现，哪些内容经过人工确认，以及哪些风险仍然没有结论。
常见失败方式
老陈总结了几种容易踩坑的做法。
一次性输入所有材料并要求直接给最终方案
材料越多，越需要分阶段处理。一次性生成最终方案，会让错误被隐藏在完整的文档结构中，后续很难判断问题来自需求理解、代码定位还是设计推断。
没有要求保留来源
没有来源的结论无法复核。尤其是老系统，代码中可能存在历史兼容逻辑，PRD 中也可能有更新后的规则。每条关键判断都应尽量保留文件、章节或方法位置。
把待确认内容写成确定结论
"部分退款后订单变成已完成"可能是正确的，也可能不是。只要材料没有明确说明，就不能因为它符合常见经验而直接写入最终设计。
让工具直接生成生产代码
这个场景适合方案初稿整理，不适合让工具直接生成并执行生产变更。涉及订单状态、支付流水和退款金额的代码，必须经过熟悉业务的开发者、测试人员和相关负责人共同确认。
可复用的方法模板
把老陈这次经历抽象后，可以得到一个适用于复杂技术方案整理的模板。
明确目标
先写清楚交付对象、截止时间、输入材料和验收标准。不要从"帮我写方案"开始，而要从"方案必须回答哪些问题"开始。
补齐上下文
提供需求、代码范围、表结构和现有限制。对不能提供的上下文，明确写成未知项，不让工具自行补全。
分步执行
先提取现状，再枚举事件，接着整理状态跃迁和边界条件，最后生成文档骨架。每一步都要有独立的检查结果。
迭代修正
针对具体错误反馈，要求补来源、拆字段、标记不确定项，并重新生成受影响部分。避免只用"再优化一下"这种无法执行的指令。
人工验证
将资金、权限、状态兼容、数据变更和发布风险列为人工必查项。工具负责加速整理，业务责任不能外包。
沉淀模板
把最终确认过的任务拆分方式、检查清单和方案结构保存下来。下一次遇到类似老系统改造时，可以复用流程，再根据具体领域调整问题列表。
适用边界
这种方法适合输入材料较多、任务步骤可以明确拆分、需要快速形成方案初稿的工作，例如代码阅读辅助、需求规则整理、状态模型梳理和发布清单生成。
它不适合替代业务决策，也不适合直接处理未经授权的生产操作。涉及资金、权限、隐私、数据迁移和线上状态变更时，人工复核必须是流程的一部分。
TRAE Work 的价值不在于一口气生成一份漂亮文档，而在于帮助团队把复杂问题拆成可执行步骤，把模糊判断变成待确认问题，把容易遗漏的边界条件提前暴露出来。
当工具负责整理和初稿，人负责事实、风险和最终决策，AI 才真正进入了工程流程，而不是停留在"看起来会写代码"的演示里。