切换主题
06. 结构化复盘报告:报告要能入库、能统计、能复查
上一章练习参考答案
第一题,正式训练系统最好保存交易当时的 K 线快照。实时读取适合演示和早期 MVP,但行情数据可能复权、修正或供应商变更,历史复盘需要可追溯。
第二题,如果只有截图,可以先做截图备注和人工标签,不要假装有完整 K 线。后续再接 OCR 或视觉模型,把截图里的关键结构抽取出来。
第三题,应该明确说明上下文有限。复盘报告不是表演专业,它要让用户知道结论建立在什么信息上。
新问题:自然语言报告不好用
现在复盘有交易数据、有风险计算、有 K 线窗口。系统可以生成一段像样的报告了。
但运营同学又来了:
“能不能统计用户最近 30 笔最常见的问题?”
产品也来了:
“前端想把报告拆成几个卡片:风险、K 线、证据、下一步训练任务。”
如果你只返回一大段自然语言,就会很痛苦。前端不好拆,后台不好统计,测试也不好断言。
所以第六章引入结构化复盘报告。
ReviewReport
伴生工程的响应核心是 ReviewReport:
java
public record ReviewReport(
ReviewStatus status,
String tradeId,
String boundaryNotice,
double riskReward,
double realizedR,
int executionScore,
String primaryProblem,
List<String> evidence,
List<String> guardrails,
List<String> questions,
List<String> experts,
String memorySummary,
String nextTrainingTask,
Map<String, String> sections
) {
}这里不要怕字段多。复盘报告是业务对象,不是随便拼出来的一段 Markdown。
其中:
status表示本次复盘状态。primaryProblem用于训练看板。evidence用于解释结论从哪里来。questions用于信息不足时追问。experts用于多智能体章节。sections给前端展示不同报告区块。
ReviewStatus
状态先设计三个:
java
public enum ReviewStatus {
REVIEWED,
NEEDS_MORE_CONTEXT,
BLOCKED
}这三个状态非常实用:
REVIEWED:复盘完成。NEEDS_MORE_CONTEXT:信息不足,先追问。BLOCKED:用户问题越界,被保护栏拦截。
不要只用 HTTP 200 和 500 表示业务状态。HTTP 200 只代表接口成功返回,业务上可能是“需要补充信息”。
本章效果
正常复盘响应会像这样:
json
{
"status": "REVIEWED",
"tradeId": "T-1001",
"riskReward": 2.0,
"realizedR": -0.8,
"executionScore": 62,
"primaryProblem": "没有等待回踩确认,入场动作和 plannedSetup 不一致",
"evidence": [
"看到突破后马上追多",
"screenshotNotes: 突破后下一根 K 线快速回落",
"plannedSetup: 突破后等待回踩确认"
],
"sections": {
"coachSummary": "这是一笔突破后追多训练失败样本,重点不是预测行情,而是复盘执行动作。",
"nextTrainingTask": "连续记录 20 笔突破后是否等待回踩确认的训练样本"
}
}这份报告前端能展示,后端能入库,测试能断言,运营能统计。
这一章真正解决了什么
结构化输出解决的是“报告可用性”。
自然语言适合阅读,结构化字段适合工程。成熟系统通常两者都要:字段稳定,文字可读。
练习题
primaryProblem应该允许多个,还是只保留一个最主要问题?sections里放自然语言,顶层字段放结构化值,这样设计有什么好处?- 如果以后报告要入库,你会给
ReviewReport增加哪些字段?