在一个业务跑了三五年的成熟系统中，最难理解的不是代码，而是：
- 复杂的流程
- 混乱的状态
- 分散的逻辑
- 各种历史产物
- 到处都是 if…else
- 每个功能都靠“口口相传”
我最近在接手一个老系统时找到一个新方法：
让 Trae Solo 来帮我梳理业务流程图。
这不是画图软件能做的事情，它是一种“语义理解 + 代码阅读 + 推理”的组合，你几乎可以把 Trae Solo 当一个“业务拆解助手”。
🧱 一、把业务描述丢给它，让它帮你重建“标准流程”
比如我告诉它：
“我们有一个请假系统，涉及三类人：员工、主管、人事。
不同请假类型还需要审批链路不同。”
然后加一句：
请帮我把这个业务拆成清晰的流程图（文字版），并指出关键节点。
Trae Solo 会生成类似：
员工提交申请
↓
主管审批（如请假 <= 3 天）
↓
人事审批（如请假 > 3 天）
↓
归档并通知员工
同时标记关键业务点，例如：
- 请假类型影响审批链
- 请假时长影响审批权限
- 是否需要人事确认
- 是否需要补材料
这一步能让你从“需求泥沼”中抬头看到整体结构。
🔍 二、让它帮你找“业务例外情况”
真实业务永远不是走主流程就完了，还会有大量“例外逻辑”：
请帮我列出这个流程中所有可能的异常或边界情况。
它会列出：
- 员工当天已请过假
- 请假时长超过上限
- 请假类型需要额外附件
- 主管审批超时未处理
- 人事关闭流程
- 补假流程与销假流程冲突
这些东西如果靠自己去翻代码，会很痛苦；Trae Solo 的总结能让你抓住重点风险点。
🛠 三、让它自动生成“真实场景模拟”
我会给它一句话：
请模拟一个完整的请假流程，从提交申请到最终审批完成，并用日志形式展示每个状态变化。
它会给：
09:00 用户 101 提交请假申请 type=事假 days=2
09:01 系统分配审批人 supervisor_id=301
09:02 主管 301 已审批 status=approved
09:03 系统更新状态 order_status=finished
09:04 通知用户：已审批
这简直比 PM 写的流程说明还清楚。
📦 四、把真实代码丢给它，让它基于代码反推出“隐藏流程”
例如我贴了一段 service：
if req.days > 3:
request.need_hr = True
我问它：
这段代码在流程中扮演什么角色？
它会推断：
- 3 天是一个分界点
- 超过 3 天后需要二次审批
- 这逻辑应该出现在“提交申请前置校验”阶段
- 建议把常量写成配置
它甚至会问：
是否还需要校验是否跨月份？
这是很多流程里常见但容易遗漏的点。
🎯 五、对“业务流老化”的系统特别有效
很多老项目的业务流已经：
- 经过无数临时 patch
- 表结构和业务逻辑已经脱节
- 老功能没人敢动
- 新功能全靠复制粘贴
用 Trae Solo 梳理出清晰流程，你会发现：
- 业务其实比想象中简单
- 真正复杂的是“历史债务”
- 只要拉出干净流程图，整个团队都能看懂
业务清晰之后，代码才有重构的可能。
✔️ 小结
Trae Solo 在“业务流程梳理”里能做：
- 根据描述生成流程图
- 根据代码推断真实流程
- 列出异常 & 边界情况
- 给出场景模拟
- 找出历史遗留点
- 对流程做拆解 & 整理
- 给出优化建议
这是传统 LLM 很难做好的事情，但 Trae Solo 的项目理解能力让它变成一把利器。
