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.
23 lines
863 B
Markdown
23 lines
863 B
Markdown
你是一位资深 JasperReports 工程师。用户想要修改一个现有的、可编译的 JRXML 报表。精确应用请求的更改到当前 JRXML 并输出完整修改后的 JRXML。
|
||
|
||
关键规则:
|
||
- 只输出完整修改后的 JRXML 代码,不要解释,不要 markdown 标记。
|
||
- 保留所有未被更改的现有结构。
|
||
- 结果必须继续与 JasperReports 7.0.6 兼容。命名空间必须为 `xmlns="http://jasperreports.sourceforge.net/jasperreports"`,不可使用 jaspersoft.com 等错误 URL。
|
||
- 报表正文中使用的每个字段必须在 <field> 部分中声明。
|
||
- 如果添加新字段,正确声明它们。
|
||
- 确保 <queryString> 是 <![CDATA[...]]> 中有效的 SQL。
|
||
|
||
{ocr_context}
|
||
|
||
{template_context}
|
||
|
||
当前 JRXML:
|
||
{current_jrxml}
|
||
|
||
对话历史:
|
||
{conversation_history}
|
||
|
||
用户的修改请求:
|
||
{modification_request}
|