panda
bd5bfbac2d
Root cause: LLM receiving full 34k-char JRXML would regenerate from scratch
instead of modifying coordinates in-place, shrinking output to ~3k chars.
Solution (programmatic node control, not prompt engineering):
- New agent/jrxml_windower.py: decompose JRXML into header (never sent to
LLM) + individual bands. Split bands >4000 chars at element boundaries.
Reassemble with element count validation (>10% change = rollback).
- Rewrite refine_layout: per-band windowed LLM processing (~2-4k chars
each). LLM cannot "reimagine" the entire report.
- Rewrite map_fields: 100% programmatic regex $F{field_N} -> real name
replacement. Zero LLM calls, zero content loss.
- _sanitize_field_name: non-ASCII chars escaped to _uXXXX_ format for
valid JRXML identifiers.
- Tests: 48 new unit tests (windower 28 + map_fields 20). All passing.
Full suite 385 tests, zero regressions.
1.4 KiB
1.4 KiB
你是一位资深 JasperReports 工程师。当前有一个 JRXML 使用占位字段名（$F{{field_1}}, $F{{field_2}}, ...），需要替换为从 OCR 提取的真实字段名。
你必须基于已有的 JRXML 进行修改，而不是重新生成。保留所有现有的元素，只替换字段名。
关键规则：
- 只输出完整修改后的 JRXML 代码，不要解释，不要 markdown 标记。
- 保留所有现有的 field、staticText、textField、band、reportElement 元素，一个都不能少。
- 不要删除、简化、合并或重写任何元素。不要改动任何坐标值（x, y, width, height）。
- 将每个 $F{{field_N}} 占位符替换为 OCR 提取结果中对应的真实字段名。
- 替换规则：根据列的顺序映射——$F{{field_1}} 对应第 1 列的 OCR 字段名，$F{{field_2}} 对应第 2 列，以此类推。
- 同时更新 field name="..." 声明和所有 $F{{...}} 表达式中的引用。
- 如果 OCR 提取的字段数少于占位字段数，保留多余的占位字段。
- 不要修改 band 结构、元素位置或大小。
- 确保 JRXML 兼容 JasperReports 7.0.6。
- 输出的 JRXML 字符数应与输入的 JRXML 大致相同（允许 ±15% 偏差），因为只替换字段名，不增删修改任何元素。
当前 JRXML（含占位字段）： {current_jrxml}
{template_context}
OCR 提取的结构化字段： {ocr_fields}