我是工地驻场造价工程师不是程序员。但凡看过我电脑桌面的人都会被这堆文件名劝退——tmp.py、新建文本文档.py、图纸_final_v2.py、图纸_final_v2_真的final.py。事情的起因是这样的。上次甲方丢过来一批DWG图纸要核对我第一反应不是「打开上次那个脚本」而是又打开浏览器搜「python dwg转pdf」。我两个月前明明写过一个能用的版本80行代码工棚里没装CAD的电脑都能跑。我自己写的脚本对未来的我来说跟陌生人写的没区别。这个事儿不只是我我猜很多非IT岗的工程师都有这个问题——造价、施工、监理、设计、测试这些岗位的Python需求有个特点离散、低频、但每次都火烧眉毛。我们不是后端没有「每天commit」的节奏。所以github上awesome-python⭐305k那种全职开发用的项目结构对我们来说就是表演型组织——上去摆一摆下回该乱还是乱。下面是我自己摸了两年总结的一套土办法。不一定对分享出来求讨论。第一层每个脚本开头强制写三行注释我叫它WWW头。# WHEN: 2024-03-15 中铁XX标段 # WHY: 甲方发的DWG无法在工棚电脑打开需转PDF # HOW: python dwg2pdf.py 输入目录 输出目录就这三行。未来的你搜文件不是搜代码是搜场景。grep DWG比grep ezdxf命中率高 10 倍。我自己实测过。第二层让脚本每次跑都留下「可对比的痕迹」。这层是我从后端排障思路里偷来的。后端不是每次都翻日志而是让日志自己告诉他「哪里反常」。落到我的造价场景就是——Excel核对脚本下次跑的时候自动输出今天处理了 2031 行 金额对不上 47 行 单位不一致 3 行 --- 上次跑处理 1894 行金额对不上 51 行每次都用同样的格式打印。三个月后你再跑能一眼看出来「哦这次结果跟上次差不多可信」。不用上什么 logging 库print 出来重定向到文件就行。够用。第三层建一个 site-tools/ 目录按「场景」分文件夹每个文件夹一个 README。site-tools/ ├── dwg_handling/ # 图纸相关 │ ├── dwg2pdf.py │ └── README.md ├── excel_qty/ # 工程量清单 │ └── 清单核对.py └── pdf_annotation/ # PDF标注提取关键不是目录结构是README.md。两段话就够一是这个工具解决什么场景的什么痛二是输入什么、输出什么。未来的你不会读代码只会读 README。这点跟正经程序员不一样——他们读代码我们读自己留的便条。踩过的几个坑重点说坑 1第一次就想写「通用工具」。最早我想做个「万能DWG处理器」改了三天没法用。后来死心了先写只解决这一次的脚本跑通就存档。第二次遇到类似需求再抽象第三次再封装。坑 2依赖管理。工棚电脑、出差笔记本、办公室台式机每台 Python 环境都不一样。我现在的解法是每个工具目录下放一个requirements.txt三行就够。ezdxf1.1.3 PyMuPDF1.23.0 openpyxl3.1.2别上 virtualenv / poetry / uv 那套。对你来说太重工地电脑也跑不顺。我试过一次最后跟同事说「你装这个项目」他卡在poetry install整整一个下午。坑 3写完不提交。我以前写完就丢从不 commit。后来注册了个 gitee 私有仓库github 工地网络慢挂代理同事说「这玩意儿合规吗」我懒得解释每次写完git push一下。你的脚本就是你的职业护城河丢了就是真丢了。几个具体数据供参考找到上次脚本的耗时从「重新搜重新写3小时起」降到「改几个参数就跑10分钟」同类需求第二次复用率从大概15%涨到大概80%脚本能否给同事用从「不能」变成「README一看就懂」。注After 那一列的数字是我自己估的没有正经统计。如果有人要喷「数据不严谨」我提前认了我不是研究员没条件做对照组。有几个点我没想透想问问老哥们。第一个到底什么时候该把单点脚本封装成带 GUI 的小工具给同事用我犹豫很久——封装一次得花两三个晚上PyQt / tkinter / pywebview 三个我都试过但同事其实就用一两次。你们的「封装阈值」是怎么定的还是说根本就不该给同事用让他们自己学 Python第二个你们怎么处理「脚本的版本演化」比如我那个 DWG 转 PDF 脚本跑了几次之后发现还要加「水印」「按图号重命名」等需求每次往里塞最后变成一个 800 行的怪物。你们是会拆成多个小脚本还是会维护一个「配置驱动」的单脚本第三个gitee 私有仓库我用着别扭gitlab 自建又太重。有没有更轻的方案syncthing纯U盘我现在 U 盘 季度备份的方式总觉得不太靠谱。先这样。如果你也是工地、工厂、设计院、测试岗这种「不是程序员但用 Python 救过自己」的人欢迎来交流。这篇经验最早写在Meyo社区一个AI助手的用户社区。里面有不少类似的「非程序员用AI/代码解决实际问题」的实战帖。如果你也是这种「野路子工程师」可以来看看。