AI生成的PDF代码能用,但为什么不适合长期迭代?

🔶 先讲个真实的场景。

上个月，业务要一份销售月报PDF。

你把需求丢给AI："帮我用Java写一段代码，生成销售月报PDF，包含标题、表格、合计行。"

AI十秒输出了一段代码。你复制、跑一下、调两个坐标，出PDF了。

业务说："不错，就这个。"

第二个月，业务说："报表加一列'环比'。"

你把原来的代码复制给AI："加一列环比。"

AI又十秒改好了。你跑一下，又出PDF了。

第三个月，业务说："环比那一列要标红，正数绿负数红。"

你再把代码丢给AI："环比列条件格式标色。"

AI又十秒改好了。

第四个月，你把那段两年前写的代码打开——

你不记得那个360是怎么算出来的了。
你不记得为什么表格宽度是500而不是520。
你不记得那个坐标偏移是为了避开什么。

AI改出来的代码，能跑。
但你已经不敢动它了。

问题还原

🟨 AI写PDF代码，第一次为什么那么爽？

因为PDF的"第一段代码"是最好写的。你只要告诉AI：

• 页面大小A4
• 标题在顶部居中
• 表格五列
• 底部加个日期

AI就能输出一段能跑的代码。里面有坐标、有字体、有表格。你跑一下，差不多，微调两个数字就上线了。

第一次写代码的成本，从半天变成了十分钟。这就是AI对PDF开发的第一个冲击——它把"从零到一"的成本打下来了。

// AI生成的第一段代码，看起来很标准public byte[] generateReport(ReportData data) throws IOException {    PDDocument doc = new PDDocument();    PDPage page = new PDPage(PDRectangle.A4);    doc.addPage(page);    PDPageContentStream cs = new PDPageContentStream(doc, page);    // 标题    PDType0Font font = PDType0Font.load(doc,        new File(”fonts/simsun.ttf”));    cs.beginText();    cs.setFont(font, 18);    cs.newLineAtOffset(150, 780);    cs.showText(”销售月报”);    cs.endText();    // 表格...    // 省略两百行}

这段代码有没有问题？第一次跑，没问题。能出PDF，能看，业务满意。

问题出在第二个月、第三个月、半年后。

隐性成本放大

🟨 我们看看这段代码"养"了半年之后变成什么样。

第一次：加一列环比。

• AI在表格里加了一列。
• 表格总宽度从500变成560。
• 但原来的列宽分布是按500算的，现在挤了。
• 你没注意，跑出来PDF勉强能看。

第二次：环比列条件标色。

• AI在每行后面加了if判断，正数画绿色负数画红色。但它用了 setNonStrokingColor，没注意这会影响后面所有文字颜色。结果合计行也变绿了。你调了半天挪到循环外修好。

第三次：表头要重复到第二页。

• AI不知道你原来的表格是手动算坐标的，它加了分页逻辑。但它不知道你第一页底部还要放签名区，结果第二页表头和签名区重叠了。你花了半天调坐标。

第四次：业务说字体要换成微软雅黑。

• AI改了字体加载那行。但微软雅黑字宽和宋体不一样，原来算好的列宽全错了。表格文字溢出行高全乱。你花了两天重新调坐标。

半年后，这段代码里：四个魔法数字（每次临时调试留下的）、三处if判断（AI不知道业务逻辑瞎写的）、两个try-catch（吞了异常）。你不敢删任何一行，因为不知道删了会影响什么。

这段代码，能跑。但它是一坨你不敢碰的屎山。

核心冲突思辨

🔸 为什么AI写CRUD代码没事，写PDF代码就出问题？

因为CRUD和PDF，对"可维护性"的要求完全不同。

CRUD代码的特点：

• 逻辑是线性的：查数据库、组装DTO、返回JSON。
• 没有"视觉状态"。字段对错，接口测试一眼能看出来。
• 改一个字段，影响范围清晰——就是那一个字段。
• AI生成的CRUD，你改完跑个单测，过了就过了。

PDF代码的特点：

• 逻辑是"视觉状态"的叠加：这行字在y=780，那个表格从x=50开始，下面留了50pt给签名。
• 每个坐标都是和其他坐标耦合的。你把表格往下挪20pt，签名区就要跟着挪。
• 改一个地方，视觉上影响一片。
• AI不知道你原来那个y=780是为什么定的——可能是为了避开页眉logo，可能是上次调过五次才对齐。

AI生成代码的本质是：根据上下文，输出一段"看起来合理"的代码。

• 对于CRUD，"看起来合理"就等于"能跑且对"。
• 对于PDF，"看起来合理"只等于"能跑"。至于那个坐标为什么是这个数、改了会不会影响旁边的元素，AI不知道，你也忘了。

工程两难分析

🟨 那问题到底出在哪？

我觉得有三层。

第一层：AI不掌握"视觉上下文"

• AI知道你要一个表格，但不知道你页面上还有页眉、logo、签名区、页码。它生成的表格代码是孤立的，你塞进整个页面，坐标就撞了。这个调的过程就是隐性成本。

第二层：AI不维护"历史决策"

• 第一个月你调坐标五轮定了y=780，这个"为什么是780"没写在注释里。第二个月AI改代码时看到的只是一个数字，它可能随手改成760，然后你发现页眉和标题重叠了。

第三层：AI生成的代码没有"结构"

• 好的PDF代码应该分模块：页眉、正文、表格、页脚各自独立。AI生成的往往是一长串顺序执行，全在一个方法里。你想改表格样式，要在两百行里找表格那段。

没有结构的代码，第一次写快，每次改都慢。

方案效果演示

🟧 我们来算一笔账。

场景：一份销售月报PDF，要维护一年，每月改一次需求。

方式一：每次找AI重新生成

• 第一次生成：10分钟
• 每次修改：把旧代码贴给AI改，平均20分钟（含调坐标、试错、跑测试）
• 一年12次修改：240分钟
• 总成本：约250分钟
• 但代码质量：每次改完魔法数字更多、耦合更严重。第十二次改的时候，你已经不敢动了。

方式二：一开始就用模板化方式

• 第一次做模板：1天（写HTML模板，配CSS）
• 每次修改：改模板里一个CSS属性或加一个字段，平均10分钟
• 一年12次修改：120分钟
• 总成本：约2天+
• 代码质量：模板是声明式的，坐标引擎帮你算，你不需要维护魔法数字。

表面上看，方式一第一次快很多。但一年下来，方式二总成本反而更低。更关键的是：方式二的代码你敢改，方式一的你不想碰。

这就是"AI生成代码适合一次性，不适合长期迭代"的核心原因。

多方案横向评估

🟨 那是不是说AI写PDF代码一无是处？

不是。

AI在PDF开发里，有它适合的位置：

适合AI做的：

• 一次性脚本：导出个临时报表，跑完就扔，不会再改。
• 样板代码：字体加载、文档创建、保存关闭这些重复模板。
• 探索阶段：你想快速看看某个排版效果，让AI写段代码试试。
• 学习用途：看不懂PDFBox的某个API，让AI解释一下。

不适合AI做的：

• 要长期维护的正式报表模板、多模板共享样式的企业项目、业务方反复改版式的合同对账单、对坐标精度要求高的票据证书。

判断标准很简单：这段PDF代码，你下个月还会改吗？不会→AI写，快。会→别让AI直接写最终代码，让AI帮你理解API、生成样板，但结构要自己设计。

边界与取舍

🔸 这里要特别说一句：我不是反对用AI。

AI是个好工具。它把"查API文档"的时间从半小时降到了十秒。
它把"从零开始写一段能跑的代码"的时间从半天降到了十分钟。

但工具擅长的是"一次性产出"。
工程要解决的是"长期维护"。

你用AI写第一版代码很爽。
但那版代码的结构、命名、模块划分，决定了未来半年你每次修改的成本。

AI不替你做架构决策。
它只会根据你给的上下文，输出一段最常见的写法。
最常见的写法，往往是"一个方法写到底"的写法。
那种写法，第一次跑起来快，第二次改起来就开始疼，第三次改起来就想重写。

所以真正的问题不是"AI能不能写PDF代码"。而是"你拿AI写的代码，是当一次性脚本用，还是当长期资产养"。

当一次性脚本用，AI很香。当长期资产养，AI写的代码会让你每年还技术债。

底层设计思考

🟧 这个问题其实触及了一个更深的话题。

AI擅长的是"代码生成"——把需求翻译成一段可运行的代码。
但软件开发的成本，从来不在"写第一版代码"，而在"之后几百次的修改"。

第一版代码的成本AI帮你降了90%。但未来修改的成本，AI一点没帮你降——甚至因为代码结构差反而升高了。

PDF尤其如此。修改不是改逻辑，是调视觉。视觉是耦合的，一个坐标动全身。CRUD加个字段就是加个getter，PDF加一列可能要重排整个表格。

这就是为什么"AI写CRUD很香，AI写PDF养着养着就成屎山"。不是AI不行，是PDF这个领域代码修改成本本来就远高于生成成本。AI降低了生成成本，但没有降低修改成本。而修改成本，才是长期项目的大头。

总结与开放讨论

🟠 AI生成的PDF代码能用，但为什么不适合长期迭代？

因为AI擅长的是"第一次写出来"，而PDF项目的大头是"之后改几百次"。

AI不知道你那个坐标是为什么定的。
AI不知道两个视觉元素之间的隐性耦合。
AI生成的代码没有模块结构，改一处动全身。

第一次跑起来十分钟很爽。
半年后改一个列宽，你要重新理解两百行代码，再花半天调坐标。

这不是AI的错。这是PDF这种"视觉状态密集型"代码，和AI这种"一次性生成"工具之间的错配。

一次性脚本，放心用AI。
长期维护的模板，别让AI直接写最终代码。

你有没有那种"AI写的代码，三个月后自己都看不懂"的经历？评论区聊聊。

下一篇预告：每天用AI写报表代码的开发者，正在埋下隐形技术债务。我们来算算，那些"十秒生成"的代码，未来要还多少利息。

---

如果这篇教程对你有帮助，欢迎给项目点一个 **Star** ⭐，也欢迎关注微信公众号 **「JQuick 声明式编程」**，后续会持续更新模板语法、表单元素与实战案例。你的关注和 Star，是项目持续迭代的最大动力

GitHub：<https://github.com/paohaijiao>

官网：<http://www.jquick.org>

微信公众号：微信搜一搜 `JQuick声明式编程`

> 扫码关注更方便 👇

>

> ![微信公众号：JQuick声明式编程]