——从水量平衡计算到 80 页报告交付的全流程经验
作者：一位水利工程师 ｜ 发布于腾讯云开发者社区
**写在前面**
我是长沙一家小型水利设计公司的普通工程师，平时主要编水资源论证、水土保持方案、洪水影响评价这类报告。2026 年上半年接了一个灌区水资源论证项目：一个灌区三座水源水库，正文 80 多页，还配一套逐月水量平衡计算表（12 个月、多座水库长系列兴利调节）。
项目全程用 AI 辅助，从水量平衡重算到报告逐章改，再到画附图、落实审查意见，坑踩了不少。有的坑让整表数据作废重来，有的坑差点让审查意见的页码全部错位，还有一个坑让我以为改完的报告被专家一眼看出是表面功夫。按踩坑的先后顺序，我分四类讲，代码贴在对应的坑里，同行可以直接抄。
**一、Excel 数据层的坑**
**坑 1：openpyxl 读不到"自己写的公式"的结果**
第一次踩坑是读 Excel。我用 Python 把水量平衡表算完存盘，回头用 openpyxl 的 data_only=True 去读，公式列全是 None，下游计算直接缺数据。
查了下原因：openpyxl 存 xlsx 的时候不算公式、也不写结果缓存。data_only=True 读的是 Excel 打开时留下的缓存，Python 自己写的文件根本没缓存，自然读成 None。只有文件被 Excel 或 WPS 打开保存过一次，缓存才会出现。
处理办法两个：要么不读公式列，改读它引用的组件列自己求和；要么先拿 Excel 打开存一次盘再读。
# 错误写法：公式列读出来是 None（Python 写的文件无缓存） wb = openpyxl.load_workbook(f, data_only=True) v = ws.cell(r, 26).value   # Z 列是 =SUM(T25:Y25) → 返回 None  # 正确写法：读组件列（T~Y）自己求和 total = sum(ws.cell(r, c).value or 0 for c in range(20, 26))
教训：写脚本读 Excel 前，先搞清楚文件是谁生成的。"自己写的文件"和"Excel 存过的文件"，读取行为完全不一样，两边都得测一遍。
**坑 2：月份映射错位——水文年从 11 月开始**
这个坑最隐蔽。重算水量平衡时，12 个月数据填进去了，合计也对得上，可逐月一核对，全错位。
原因是两个表的月份序列不一样：灌溉需水量工作表按日历月排（1~12 月），水量平衡审定稿按水文年排（11 月到次年 10 月）。我直接按行号对位，等于把 1 月的数据塞进了 11 月。更要命的是，12 个数换个顺序求和，结果竟然一样，错位完全被合计盖住，逐月打印比对才暴露。
后来凡是跨表搬数，我先打印两边前三行的表头和首列，确认行序的语义起点再动手。
教训一句话：合计对得上 ≠ 数据对。这是整个项目里最坑的一个。
**坑 3：表间数据不一致——手工录入的锅**
水量平衡审定稿的Ⅰ区月毛灌溉需水量，和独立的灌溉需水量计算表对不上：水稻生长期（5~8 月）完全一致，枯水小月系统性偏低 13% 左右，合计差了 13.93 万 m³。
根子在审定稿那张表是手工抄的旧值，跟计算表没有任何公式关联。高峰月被精确抄过所以一致，小月抄的是旧版数据，于是"部分一致、部分偏低"。
改法：把审定稿的 B 列直接改成引用计算表单元格（=灌溉需水量!Z35 这种），一处改全部动，以后不再手抄。
这个教训最重：报告里凡是从计算表来的数，一律公式引用，别手敲。手敲就是埋雷，哪天源头一变，报告里的数就成了"看着对、其实错"。
**坑 4：多库联合供水的"W来-W需"不是简单相减**
这个坑是理解问题。Ⅰ区是两座水库联合供水，我一开始用"W来-W需 = 来水量 − 需水量"直接算，怎么都对不上表：0.72 − 4.22 = −3.50，表里却是 −2.83。
原因：联合供水按灌溉面积分摊供水任务，本项目大约 8:2。所以主库的 W来-W需 = 主库来水 −（总需水 × 80%），副库同理乘 20%。只有单库独立供水的Ⅱ区才是直接相减。
# 两库联合供水（Ⅰ区） W来-W需(主库) = 主库来水 − (总需水 × 80%) W来-W需(副库) = 副库来水 − (总需水 × 20%)  # 单库独立供水（Ⅱ区）才是直接相减 W来-W需 = 来水量 − 需水量
动手算水库调节之前，先把供水关系图画出来：哪座库供哪片田、分摊比例多少、有没有山塘补充。供水格局没搞清，后面联动列全是错的。
**二、Word 操作层的坑（win32com 三铁律）**
**坑 5：Find/Replace 循环只替换第一次**
用 win32com 批量替换旧数据，跑完发现每处只替换了一次，旧值残留一大片。
原因是 Range.Text = 新值之后，Range 会自动缩成新文本的范围。while 循环里复用一个 Range 继续 Find，范围越缩越小，永远找不到下一处。
正确做法两个：每次循环重新取 doc.Content 再 Find；或者干脆用 wdReplaceAll（=2）一次全换。
# 错误写法：复用同一 rng，只替换第一条 rng = doc.Content while rng.Find.Execute(old):     rng.Text = new          # rng 缩成新文本，循环第二次就找不到  # 正确写法一：每次迭代重新取全文 while True:     rng = doc.Content     if not rng.Find.Execute(old): break     rng.Text = new  # 正确写法二：一次全换（推荐） rng = doc.Content rng.Find.Execute(old, ReplaceWith=new, Replace=2)
**坑 6：段落替换吞掉换行符**
替换某段文字后，它跟下一段合并成了一个段落，整个标准列表结构全毁了。
原因很简单：Range.Text = "新文本" 如果不带段落标记 \r，等于把段落标记也覆盖了。本项目因此毁过一整张标准列表，只能重建。
改法：段落级替换末尾必须补 \r。
paras(i).Range.Text = "新内容\r"   # 必须带 \r，否则吞换行
**坑 7：表格单元格里的 \x07 控制符**
在 Word 表格单元格里做长串 Find 替换，死活匹配不上；强行替换又出数字粘连（349.49 变成 349.495 这种）。
原因是 Word 表格单元格文本用 \x07（bell 控制符）分隔，长串里隐含控制符，Find 当然匹配失败；整串替换时又把相邻单元格内容带了进来。
处理：用短子串定位，按偏移量逐段替换；改完通读上下文，确认没粘连。
**坑 8：整文替换的状态残留——一处冒出 10 个句号**
拿一个短语当锚点做循环替换，结果某一段落冒出 10 个连续句号。
整文 Find/Replace 有状态残留，重复命中同一位置后不断叠加。
后来凡是多实例替换，一律逐段落处理，不用整文循环；替换完用正则兜底（折叠重复标点、补齐缺失标点），再跑全文扫描确认干净。
**三、AI 生成层的坑**
**坑 9：一次性要全本=只出骨架**
让 AI 一次生成 80 页报告，输出全是章节骨架，每节两三行，表格截断、格式破碎。
原因很现实：单次输出 token 上限约 8000，折合 6000 汉字左右，80 页报告 8~10 万字，单次只够覆盖 6%。让 AI 一次写完，等于逼它交骨架。
改法：一轮一章。报告拆成 9 章，逐章生成、逐章写回 docx，每章控制在 3000~6000 字加表格，把单次输出用到头。
长文档让 AI 一次出全本，就别指望了，拆章是唯一的出路。
**坑 10：拿旧报告当模板=地名残留**
拿另一个灌区的旧报告当模板，成品里冒出别的水库名、别项目的工程描述段落，内部校核抓到 2 处残留。
大模型会死死锚定模板里的旧文本旧数据，结构一错配，地名残留、替换错误、重复论述全来了。这个项目最严重的时候产生过上百处清洗、多轮返工。
后来我改成"模板包"：① 标准骨架（来自规范附录大纲，不是旧报告）；② 分章要求（每章写什么、算什么、出什么表）；③ 本项目数据表（唯一数据源）；④ 少量风格范例（旧报告挑几段，不是全本）；⑤ 排除指令（明说旧报告里哪些是别项目的信息，必须替换成自己的数据）。
旧报告只能当参考，不能当模板。数据只从本项目数据表来，别让 AI 从旧报告里"继承"任何数字。
**四、数据同步与核对的坑**
**坑 11：改一半——脚本只刷了联动列**
这个坑是自个儿坑自个儿。重算脚本只更新了库容调节那些联动列（I~X 列），没回写 B/F 输入列，用户打开文件发现输入列是空的，整张表没法用。
脚本只算了"要改的部分"，没通读全表校验，典型的改一半。
后来总结成六步：确认计算表终版是唯一数据源 → 正确循环全文档替换 → 跑数值扫描（旧值清零 + 新值都在）→ 手工核对三项一致性（供需平衡、面积自洽、系数自洽）→ 含控制符的表格单元格二次人工核对 → 转 PDF 按页脚页码填修改说明。
**坑 12：Excel 文件被占用**
很小的坑：原 xlsx 正被 Excel 打开，脚本覆盖保存直接失败。
改法：另存 v2/v3/v4，最后手动合并 sheet。意外收获是养成了版本管理的习惯，每次重算留一个版本号，回退有据。
**五、图表与页码的坑**
**坑 13：matplotlib 中文乱码 & DWG 底图读不了**
画配水直线分布图，matplotlib 的中文标签全是方框；想直接读用户的 DWG 工程图，本机又没有可用的 CAD 转换环境。
中文必须显式指定字体；附图用 SVG 矢量输出，方便后续进 CAD 二次加工；DWG 读不了，就用计算表数据重绘一张示意配图，说明里标注"渠线位置以实测地形及初设图纸为准"，不跟工程图混。
plt.rcParams['font.sans-serif'] = ['SimHei'] plt.rcParams['axes.unicode_minus'] = False
**坑 14：PDF 物理页 ≠ 页脚页码**
填审查意见修改说明时，按 PDF 物理页序号写的"详见 pXX"全部偏大 8 页。
原因是 PDF 前 8 页是封面和目录，正文从物理第 9 页重新从 1 编号，页脚页码 = 物理页 − 8；目录区还会提前匹配章节号，把定位搅得更乱。
后来固定三步：① 用 PyMuPDF 提取每页底部页脚数字，确认偏移量；② 用正文特有短语（避开目录重复项）逐章搜正文真实页码；③ 每条意见写成"详见 pXX，X.X 节《节标题》+ 关键句"，方便在 Word 里直接跳。
**六、经验总结：三层东西，下个项目直接复用**
项目收尾时，我把这些经验整理成三层，下个项目直接套：
第一层，铁律。win32com 三铁律（Find/Replace 循环、段落 \r、表格 \x07）、PDF 页码定位法、数据同步六步法，全写进项目指令，每条都是吃过亏的。
第二层，技能。逐章编制工作流（分章策略表 + 每章 prompt 模板 + 排除指令模板），新项目只要填"分章要求 + 项目数据 + 排除指令"三样就能开工。
第三层，校核脚本。全文档扫描脚本 + 页码定位检查清单，编完一章审一章，审查意见改完逐条核对落实。
现在的流程：建项目 → 挂技能 → 逐章编制 → 编一章审一章 → 六步法收尾 → 转 PDF 定位页码填说明。基本不返工。
**结语**
最后说句实在话：AI 辅助做工程报告，生成只占一小半功夫，校核才是大头。所有自动化的前提，是先想清楚计算逻辑（供水格局、月份序列、公式联动、输出长度限制），再让 AI 动手，最后用脚本把"改了没改全"兜住。
这四个顺序，数据、操作、生成、核对，是我这个项目踩坑踩出来的，希望你下一个项目能提前绕开。

——从水量平衡计算到 80 页报告交付的全流程经验作者：一位水利工程师 ｜ 发布于腾讯云开发者社区写在前面我是长沙一家小型水利设计公司的普通工程师，平时主要编水资源论证、水土保持方案、洪水影响评价这类报告。2026 年上半年接了一个灌区水资源论证项目：一个灌区三座水源水库，正文 80 多页，还配一套逐月水量平衡计算表（12 个月、多座水库长系列兴利调节）。项目全程用 AI 辅助，从水量平衡重算到报告逐章改，再到画附图、落实审查意见，坑踩了不少。有的坑让整表数据作废重来，有的坑差点让审查意见的页码全部错位，还有一个坑让我以为改完的报告被专家一眼看出是表面功夫。按踩坑的先后顺序，我分四类讲，代码贴在对应的坑里，同行可以直接抄。一、Excel 数据层的坑坑 1：openpyxl 读不到"自己写的公式"的结果第一次踩坑是读 Excel。我用 Python 把水量平衡表算完存盘，回头用 openpyxl 的 data_only=True 去读，公式列全是 None，下游计算直接缺数据。查了下原因：openpyxl 存 xlsx 的时候不算公式、也不写结果缓存。data_only=True 读的是 Excel 打开时留下的缓存，Python 自己写的文件根本没缓存，自然读成 None。只有文件被 Excel 或 WPS 打开保存过一次，缓存才会出现。处理办法两个：要么不读公式列，改读它引用的组件列自己求和；要么先拿 Excel 打开存一次盘再读。

**AI 辅助水利报告编制实战：一个灌区项目的 14 个踩坑复盘**

*AI 辅助灌区水资源论证报告编制， 14 个踩坑复盘

人工智能

职业发展

新闻资讯

从水量平衡计算到80页报告交付，本文总结水利工程师用AI辅助完成灌区水资源论证的全流程经验。涵盖Excel数据层、Word操作层、AI生成层及数据同步四大类12个坑，提供openpyxl读取、win32com替换、逐章生成等实用代码与铁律，助你绕开同类项目中的隐蔽陷阱。

数据同步

Python

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

**AI 辅助水利报告编制实战：一个灌区项目的 14 个踩坑复盘**-腾讯云开发者社区-腾讯云

AI 辅助水利报告编制实战：一个灌区项目的 14 个踩坑复盘

AI 辅助水利报告编制实战：一个灌区项目的 14 个踩坑复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐