15. 工程化收尾：能演示不等于能上线

上一章练习参考答案

第一题，Routing 结果应该限制在枚举里。枚举便于测试、监控、分支处理和回归。

第二题，可以先判断用户是否绑定具体交易。如果绑定 tradeId，就以复盘为主，概念解释作为补充；如果没有交易上下文，就走概念解释。

第三题，明显越界可以放在 Routing 前先挡住。复杂边界也可以作为一个路由结果，但输出前还要再做检查。

新问题：Demo 跑通了，线上会暴露别的问题

现在系统已经有 MVP、Agent、数据模型、工具、K 线、结构化报告、记忆、知识库、搜索边界、保护栏、Graph、中断、多专家和 Routing。

看起来可以上线了。但工程上线前，真正的问题才开始。

用户说报告不对，你能查到当时用了哪些工具吗？

模型输出变了，你能知道是提示词变了、知识库变了，还是交易数据变了吗？

接口变慢，你能知道慢在 K 线、RAG、模型还是专家组吗？

这些不是教程边角料，是上线的主菜。

必须补的工程能力

第一，日志和 trace。

每次复盘至少记录：

• reviewId
• userId
• tradeId
• route
• status
• toolTraceId
• promptVersion
• modelVersion
• latency

第二，测试。

伴生工程现在已经有两类测试：

ReviewCoachServiceTest
ReviewCoachControllerTest

Service 测业务分支，Controller 测 HTTP 闭环。以后每加一个节点，都应该有对应测试。

第三，版本。

Prompt、知识库、模型、工具计算逻辑都要有版本。否则同一笔交易今天复盘和明天复盘不一样，你无法解释。

第四，成本。

Routing 要记录每类请求走了多重流程。复杂专家组不能默认给所有用户无限跑。

第五，权限。

交易记录、截图、训练记忆都属于用户敏感数据。复盘教练不能跨用户读取。

本章验证

先跑测试：

cd D:\idea_space\pa-review-coach-tutorial
mvn.cmd test

看到：

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

再跑接口三种状态：

• T-1001 正常复盘，返回 REVIEWED。
• T-2001 信息不足，返回 NEEDS_MORE_CONTEXT。
• “现在 BTC 能不能买？” 返回 BLOCKED。

这三种状态就是上线前最小验收路径。

这一章真正解决了什么

工程化收尾解决的是“可解释、可回归、可运维”。

AI 项目上线后，最怕的不是模型没那么聪明，而是出问题时没人知道问题发生在哪里。

练习题

1. promptVersion 为什么要进日志？
2. 哪些字段属于敏感数据，不能随便打到普通日志里？
3. 如果专家组流程很慢，你会先优化哪里？