夜雨聆风2026年上半年，我们团队正在筹备一项集团级创新课题（已做脱敏处理），方向是“既有建筑检测鉴定报告半自动生成系统研究”。目前课题已获内部初步认可，正在完善申报材料。
课题的核心实践基础，就是我刚刚完成的一次重要推倒重来：从“依赖AI”到“驾驭AI”。这也是 「报告系统自研实录」系列的开篇，后续会持续拆解技术细节与底层思维。
01 格局托底：一份报告，两种服务
鉴定报告撰写——在国民经济统计口径中，属于“生产性服务业”中的检验检测领域，为产业延链增值提供支撑。它的服务对象不是普通消费者，而是工程结构安全，是城市更新的前置环节。
如果一份报告原本需要 4-6小时，加入一套“半自动生成系统”后可以压缩至 1小时 以内，会发生什么？
对生产者（鉴定工程师）：省下重复劳动的时间，回归专业判断
对产业链（城市更新项目）：鉴定周期大幅缩短，项目推进提速
对宏观目标：正是服务业“扩能提质”的最直接体现
服务业的本质，是用服务满足需求、创造价值。一套工具让“人的生产力”释放数倍，这不就是在“扩能提质”吗？
02 原来我太依赖AI了
然而最开始，我的方向并不是“释放生产力”，而是“让AI包办一切”。最初的想法很美好：图纸丢给大模型，自动提取参数；规范问AI，自动匹配条款；报告让AI写，自动生成结论。一切交给AI，我只需要按一个按钮。
跑了一段时间后，问题逐个暴露：
API费用随着调用量增加，成本压力很快显现
图纸稍微复杂一点，AI就开始“幻觉”：层数写成6层，实际只有3层
规范条款匹配不准，还得人工再查一遍
最关键的一点：所有数据都要上传云端，涉密项目根本不敢用
我陷入了一个困境：AI确实很强，但如果完全依赖它，系统就像建在沙滩上。 这套方案差点被人质疑“不接地气”——而课题立项，讲究的是“可落地、可推广、有效益”。全靠AI？显然不行。
03 逆向思维：先问“哪里会死”
我没有急着去思考“怎么把系统做得更强大”，反而是先反过来问：“这个系统最容易在哪里失败？”
依赖网络和API：断网就废、费用不可控
AI幻觉：关键数据出错，人工难以发现
数据安全：图纸上传云端，单位不敢用
不可维护：规范一更新，就得重新调Prompt
于是，我定下一个新原则：AI只做它最擅长的事——理解自然语言；其他所有事，全部交给确定性更强的本地工具。 这就是“混合架构”的起点——既不是“纯手工填表”，也不是“纯AI包办”，而是“组合最优解”。这恰好呼应了服务业发展强调的“既放得活又管得好”：AI是灵活的前端工具，本地SQL数据库是确定性的后端。
04 第一性原理：把系统拆到最细
我们回到最基础的问题：这个系统的本质是什么？ 答案是：从非结构化的输入（图纸、现场记录、规范条文）中，提取结构化信息，再装配成标准化的输出（报告）。
AI只占四分之一。 剩下的，全用本地工具搞定。这个拆解过程，就是芒格所说的 “第一性原理” 在工程上的具体应用。
在内部讨论中，大家最关心的是准确性如何保证。我的回答是：关键信息（规范条款、参数数据）由本地数据库做精确匹配，AI只处理非标准化的文字提取。经过多轮测试，准确率维持在较高水平，幻觉率可控。
05 从“依赖AI”到“混合架构”
重构后的系统：
图纸提取：AI理解文字 + 正则二次校验 → 写入SQLite
规范匹配：SQL查询 → 2秒出结果
现场数据：Excel一键导入SQLite
报告生成：python-docx自动填充
整个系统完全跑在本地，不需要GPU服务器，无持续大额API支出，数据不出单位。一份报告从4-6小时压缩到1小时以内。
06 干货：那2秒匹配“规范依据”是怎么做到的？
一、建立SQLite规范库
二、条件匹配，秒级响应
根据项目信息（建造年份、结构类型、设防烈度），用SQL查询快速筛选出适用的规范条文。
三、持续迭代，不重构代码
规范库随规范更新在SQLite里轻量增删改，规范变了，改数据，不重构代码。 完整思路后续会在内部社群分享。
07 这套思路，不止用于“写报告”
这次重构让我想通一件事：AI不会淘汰你，但“只会用AI”可能会。 真正有价值的能力，是能根据问题本质，组合不同工具，搭建出可靠、可控、可迭代的系统。
08 写在最后：你也能复用的方法论
✅ 先问“哪里会死”，主动规避失败风险✅ 拆到不能再拆，看清每个环节的合适解法✅ 混合方案，不要迷信单一工具：AI、SQL、脚本、模板……各取所长✅ 本地优先，数据可控
一步登天不现实，但只要开始组合，总能比昨天多省一点力。
💡 公众号每周四/日晚20:30持续更新职场底层思维与可复用方法论。
📦 未来我也会把更完整的工具模板、项目复盘等沉淀到一个安静的小地方（知识星球），随缘来，不强求。里面也会放一点随缘优惠券，留给真正想深入的朋友。
