设计调研：新增财报分析图片卡片输出流水线

[noho]

背景

用户希望在公司发财报后，可以提出类似：

请给出 2026Q1 META 季报分析图

系统最终以图片形式输出财报分析结果。用户也希望在分析公司基本面时，可以选择类似长图信息图的输出形态。

本 issue 记录目前的调查结论与推荐架构，后续可拆成实现任务。

第一性原理判断

这个需求真实存在，但核心不是“让 LLM 直接画图”，而是：

• 从财报、XBRL、公告、电话会等材料中提取可信事实；
• 形成可审计的分析结论；
• 将结论组织成稳定结构；
• 由确定性渲染器生成图片。

直接让 LLM 生成最终图片或自由生成 SVG/HTML，风险较高：

• 财务数字、同比/环比、单位、估值公式容易错；
• 长图文字密集，图片生成模型容易产生乱码或不可复核内容；
• 输出不可稳定复现，不利于买方研究场景的证据追踪；
• 与 Dayu 当前“Host 强治理下的 LLM in the loop”定位不一致。

因此更合适的方向是：LLM 负责结构化分析，代码负责校验、渲染和产物管理。

当前代码基础观察

当前项目已有一些可复用基础：

• dayu.fins 已提供财报下载、上传、processed 文档、财务数据读取等能力；
• dayu.fins.tools 已将财报读取能力暴露给 Agent；
• dayu.services.internal.write_pipeline 已有写作流水线、manifest、章节产物、审计/修复等经验；
• dayu-render 当前支持 Markdown 渲染到 .docx / .html / .pdf，但不承担结构化图卡或 PNG 长图输出；
• prompt 层已有工具使用指引，但不应把图片输出能力仅作为 prompt 规则硬塞进去。

推荐架构

推荐新增一条独立的“分析图片卡片流水线”：

UI / CLI / WeChat
  -> Service: visual_card_service
  -> Host: 运行 visual_card scene
  -> Agent: 调 fins/doc/web 工具取证并输出结构化 JSON
  -> Service: 校验 JSON、复核 evidence、归一单位
  -> Renderer: HTML/SVG/Canvas/Vega-Lite/Chart.js -> PNG
  -> Output: card.png + card.html + card_spec.json + evidence.json

分层上应继续遵守：UI -> Service -> Host -> Agent。

Agent 不应感知 UI 如何画图；Renderer 不应负责研究判断；财报存取仍必须通过 dayu.fins.storage 仓储协议与实现完成。

扩展性结论

该架构适合后续扩展更多分析图片输出。原因是它把变化点拆开：

分析意图 -> 数据/证据 -> 结构化 spec -> 模板/renderer -> 图片产物

新增图种时，通常只需要新增：

• 一个窄 card spec schema；
• 一个 task prompt；
• 一个 renderer 模板；
• 少量 CLI/UI 路由。

不需要修改财报工具本身，也不需要破坏 Host 生命周期和治理边界。

不建议的方案

不建议 1：让 LLM 直接输出图片

不适合财报分析场景。图片无法可靠审计，文字和数字错误难发现，也难复现。

不建议 2：设计一个万能 AnalysisImageSpec

这会变成 god schema，后续不断膨胀。更好的方式是：公共基类 + 多个窄 schema。

例如公共字段只放：

• company
• ticker
• period
• title
• subtitle
• sources
• disclaimer
• theme

具体指标、图表、业务模块由各图种自己的 schema 定义。

不建议 3：把布局细节交给 LLM

字号、颜色、网格、栏目位置、图表类型、换行策略应主要由 renderer/template 控制。LLM 只负责填内容、结论、数字和出处。

建议第一期范围

建议先做两个图种，避免一开始抽象过度：

1. quarterly_earnings_card

   • 对应“2026Q1 META 季报分析图”；
   • 重点展示季度业绩、同比/环比、业务分部、管理层指引、风险、关键判断。

2. fundamental_snapshot_card

   • 对应用户提供的长图风格；
   • 重点展示公司基本面、行业格局、竞争力、经营变化、风险与估值情景。

可能的模块落点

初步建议：

• dayu/services/visual_card_service.py
• dayu/services/internal/visual_card_pipeline/
• dayu/config/prompts/manifests/visual_card.json
• dayu/config/prompts/tasks/visual_card_*.md
• dayu/render/card/
• workspace/output/cards/{ticker}/{period}/

CLI 入口可考虑：

dayu-cli card --ticker META --fiscal-year 2026 --fiscal-period Q1 --style quarterly-long

产物建议

每次生成至少保留：

• card.png：最终图片；
• card.html：可复现渲染源；
• card_spec.json：LLM 结构化分析结果；
• evidence.json：关键事实与出处；
• render_report.json：渲染尺寸、模板版本、校验结果。

验收标准草案

• 用户可通过 CLI 或 UI 请求生成某个 ticker/period 的分析图片；
• 若本地缺少财报，系统能复用 ingestion 能力下载或提示缺口；
• LLM 输出必须通过 schema 校验；
• 关键数字和判断必须带 evidence；
• Renderer 能稳定输出 PNG；
• 同一 card_spec.json 重复渲染应得到稳定布局；
• 新增图种不要求改动 fins 工具和 Host 生命周期；
• 对应测试覆盖 schema 校验、路由选择、renderer 基础输出和错误路径。

后续拆分建议

后续可以拆成这些任务：

1. 定义 visual card domain model 和 schema；
2. 新增 visual_card scene 与 task prompt；
3. 新增 Service 层入口和 CLI 参数；
4. 实现 HTML/SVG 到 PNG 的 renderer；
5. 增加 quarterly_earnings_card MVP；
6. 增加 fundamental_snapshot_card MVP；
7. 补齐测试、pyright、README。