聊一下最近用AI写的一些工具

简单交代一下背景，本人不是一个代码程序猿，是从一个网络攻城狮逐渐进化成了一个四不像（攻城狮+运营鸡+测试喵+产品獭）。经常性的因为“工作需要”要使用到一些脚本或工具，之前都是网上找现成的脚本自己改，最近是直接AI输出工具了。

现在用 AI 写代码算是彻底养成习惯了。需求提给AI，把一堆重复、机械、易出错的事交给脚本，自己只管定方向、兜底脏数据。下面按时间线，把几个印象深的"代码任务"梳理一遍——它们都不算大工程，但每一个都真刀真枪地省了时间。

一、桑基图生成器：拖个表格进去就出图

痛点

做数据分析的时候，我经常需要画桑基图（Sankey Diagram）——就是那种展示数据从哪里来、流到哪里去的流向图。比如安全事件按类型分类，再看每种类型落在哪些部门。

市面上能画桑基图的工具有不少，但都各有各的别扭：

• Excel原生不支持桑基图，得装插件或者用Power BI，操作繁琐。
• 在线工具（如SankeyMATIC）：得手动一条一条填数据，数据量大了根本不现实。
• D3.js / ECharts代码功能强大，但得自己写JavaScript，门槛高。

我想要的东西很简单：扔一个Excel进去，选几列，自动出图，还能导出。就这么个需求，之前愣是没找到顺手的工具。

做法

AI给我写了一个纯前端的HTML应用，整个工具就一个文件。

技术栈很简单：ECharts 5.5做图表渲染，SheetJS解析Excel/CSV文件，PapaParse处理CSV。全部走CDN加载，不用装任何依赖，浏览器打开就能跑。

核心流程是：拖拽或点击上传文件 → 自动解析表头 → 下拉框选"来源字段""目标字段""数值字段" → 相同的来源→目标组合自动聚合求和 → ECharts渲染交互式桑基图。

后来我让它加了"中间字段"支持，可以做三层桑基图（来源→中间→目标）。中间字段留空就自动退化成两层。再后来扩展到最多4层，任意2-4层组合都能自动生成。

用法

• 浏览器打开那个HTML文件。
• 把Excel或CSV文件拖进去（或者点击上传）。
• 页面自动识别表头，下拉框里选哪列是来源、哪列是目标、哪列是数值。
• 需要三层的话，中间字段也选上。
• 点生成，桑基图就出来了，鼠标悬浮看明细，节点可以拖动调整位置。
• 6种配色方案随便切换（默认/海洋/森林/日落/浆果/午夜）。
• 满意了点导出，PNG（2倍像素高清）或SVG随便选。
• 底下一个数据预览表格，确认映射没选错再出图。

效果

之前用Excel画类似的东西得折腾半小时，还不好看。实测拿一份主机资产表（主机类型→部门→业务系统），拖进去三秒出图。

这个工具后来成了我做数据分析的标配。每次有新的表格数据要看流向，直接扔进去，比任何现成工具都快。而且因为是一个独立HTML文件，发给别人也方便，对方不用装任何东西。

唯一的小遗憾是目前不支持实时数据源，每次得手动上传文件。但对于日常分析来说已经够用了。

数据导入及预览

图片

生成效果

图片

二、发票批量 OCR → 从扫描件里抠出结构化字段

痛点

一摞增值税发票（以深圳供电局电费发票为代表，15 页 PDF），要把购买方、销售方、金额、发票号、日期等字段抽出来做台账。纯靠肉眼抄，15 页就是半小时起，还容易串行。

做法

用 Tesseract OCR + Python 解析，做成可打包成 EXE 的桌面工具 invoice_ocr_tool。核心是一个 invoice_parser.py 解析引擎，针对这类"双栏 + 标签易损"的发票做了大量针对性修复：

• 购买方 / 销售方名称提取先按 名称: 标签匹配；标签被 OCR 损坏时，退化为"广东省/深圳市开头 + 过滤区级地址（福田区/南山区等）+ 长度阈值"兜底；
• 分栏（**|**）行的销售方识别不再依赖被损坏的标签，直接搜 供电局有限公司 / 行内 供电 关键词；
• 边界处理税号残留字母清理、跨行 remark 提取、金额互锁校验等。
• 支持离线 当然有的朋友说直接扔给豆助理不久行啦，那肯定是最便捷的。但我写的这个版本是支持离线使用的，不用联网。

效果

（15 页电费发票实测准确率）

已知的边界

OCR 本身的字形误读（如 次圳→深圳）、跳字（整行无文本）、数字串识别不稳定——这些靠解析层修不了，只能换更强 OCR 或加校验位验证。这是"AI 代码工具"很真实的一面：能解决 90% 的机械活，但最后 10% 的脏数据得人兜底。

二开

后来又改成了专门对出库单进行识别。

图片

三、PDF护照号识别重命名工具

痛点

事情的起因很简单：手上有一堆护照扫描件PDF，文件名乱七八糟——有的是"扫描件001.pdf"，有的是"张三_2024.pdf"，还有的直接就是一堆数字。

我需要把这些文件统一用护照号命名。原因是后续要做批量归档和检索，护照号是唯一标识。

手动干的话，得逐个打开PDF，翻到护照信息页，肉眼找护照号，记下来，再重命名文件。一份PDF从打开到重命名少说一分钟，几百份就是几个小时。而且人眼读护照号容易看错，尤其是那些扫描质量一般的。

网上找了一圈，没有现成工具能干这个事。OCR工具能识别文字，但不会帮你提取特定字段再重命名文件。得自己写。

做法

AI用PyMuPDF（fitz）做PDF文本提取，设计了一个三层识别策略，按精度从高到低依次尝试：

第一层：MRZ机读区解析。

护照底部有两行机读码（TD3格式），是ICAO标准化的，位置和格式固定。这是最准的识别方式——机读码里护照号的位置是写死的，直接按位截取。中国护照、国际护照都支持。

第二层：标签匹配。

有些扫描件可能没有MRZ区，或者OCR识别质量差导致MRZ解析失败。这时候找"护照号:"、"Passport No."、"Passport Number"这类标签，取标签后面的字符串。

第三层：通用格式匹配。

前两层都找不到，就按护照号的常见格式做正则匹配——中国护照E+8位数字、G+8位数字，国际护照字母+数字组合。

三层策略的好处是容错：优先用最可靠的方式，失败了逐级降级，不会因为某一种识别方式失效就放弃整个文件。

做成了GUI版本，用Tkinter+ttk做了界面：选文件夹或选文件、预览模式开关（dry-run只看不改）、递归子文件夹开关、实时日志输出、进度条、统计卡片（成功/失败/跳过）、停止按钮。多线程处理，界面不卡顿。

最后用PyInstaller打包成独立exe，48MB，双击就能用，不装Python。

用法

GUI版：双击 PDF护照号识别工具.exe。点"选择文件夹"（或"选择文件"），选到PDF所在目录。勾上"预览模式"先看看识别结果。点"开始处理"，实时日志区显示每个文件的处理过程。进度条和统计卡片实时更新——成功几个、失败几个、跳过几个。确认预览结果无误后，取消勾选"预览模式"，再跑一次正式执行。重名冲突自动加序号后缀（如 E12345678_2.pdf），不会覆盖。已经是护照号命名的文件自动跳过，不重复处理。效果拿真实PDF测了——一份XX学院的录取通知书PDF（里面含护照号），护照号一次识别成功，文件秒改名。三层策略的容错性也验证了：中国护照（E/G开头）走MRZ解析，命中率最高；韩国护照等国际护照MRZ格式略有不同，第二层标签匹配兜住了；个别扫描质量极差的PDF，第三层格式匹配也能捞回来。整体识别率在测试样本上是100%。当然样本量不大（3份不同类型的护照），实际大批量处理时肯定会有边角情况——比如扫描歪了导致MRZ区识别失败的，可能需要人工兜底。但比纯手动快了不止一个数量级。GUI版打包成exe后，发给别人用也很方便——对方不需要会Python，双击就行。这种"造一个工具发给非技术人员用"的能力，是我之前完全没有的。

图片

四、牧安Shepherd：一个单机检测平台（还在进化中）

痛点

之前在做安全运营服务（MSS）时候，面向的是"正在出事"的小客户——传统制造业、地方企业这种。这些客户的安全基础很薄弱，很多人连自己有多少资产、开了哪些端口都不知道。

需要一个工具，能帮小客户快速做安全体检：扫一遍内网，看看有哪些风险，出一份报告。市面上的安全扫描工具要么太重（需要部署Agent、配数据库、搭管理后台），要么太贵（面向大企业的商业产品），没有一个是"双击就能用"的轻量方案。

具体来说，我的需求是：

• 能跑不装环境、不配数据库、不部署服务端，双击exe就能用。
• 能扫资产指纹、端口、进程、服务、敏感数据泄露（DLP）、日志异常，一次全扫。
• 能出报告扫完自动生成安全报告，能导出HTML发给客户看。
• 能管授权注册码控制谁能用、用什么功能、用到什么时候。
• 能上报扫描结果能自动上报到运营方的SOC平台。

做法

AI帮我从零搭了一个Python全栈平台，内部代号safety-net，对外名"牧安Shepherd"。五大检测模块：

• 资产指纹采集 主机名、OS、IP、MAC、开放端口、运行服务。
• 终端安全巡检 端口扫描、进程检查、服务清单、日志审计。
• DLP敏感数据扫描 九类敏感数据（身份证号、银行卡号、手机号、邮箱、地址等），扫描指定目录下的文件。
• 日志UEBA分析 异常登录、权限变更、时间异常等行为模式。
• 事件处置记录 风险汇总、评分、建议处置动作。

DLP防误报是最花心思的部分，踩了至少三个坑才磨好：

第一个坑：身份证号正则 \d{17}[\dXx] 会把Edge浏览器缓存里的18位数字串也匹配成身份证。AI加了GB 11643-1999标准校验——省份码前两位（34省+港澳台码）、真实出生日期校验、MOD 11-2校验位，三道关全过才算真身份证。

第二个坑：银行卡号 \b\d{16,19}\b 同样会误报长数字串。加了Luhn算法校验（ISO/IEC 7812），从右起隔位翻倍求和取模。

第三个坑：手机号正则 1[3-9]\d{9} 没有字母边界，会从hex哈希串里截出11位数字误报（比如 ...E17956081727F... 里的 17956081727 被当成手机号）。统一改成字母数字边界 (?<![0-9A-Za-z])...(?![0-9A-Za-z])。

后来还发现一个漏报bug：同行有多个匹配时，代码只取第一个候选，如果第一个校验失败就跳过整行——后面的真号被漏掉。改成finditer遍历所有候选取第一个过校验的。

注册码机制用Ed25519非对称验签：私钥只在运营签发工具里，客户端只持公钥，逆向也拿不到签发能力。四档权益包（试用/基础/标准/旗舰），注册码里编码了客户ID、权益列表、过期时间、机器指纹。单客户模型——一台机器一个码一套权益，首启三字段激活（客户名称+联系人+注册码）。

打包用PyInstaller打成单文件exe，32MB。踩的坑能列一页纸：跨盘路径拼接失败、UPX压缩DLL报错、沙箱safe-delete拦截PyInstaller清理临时文件、windowed模式无控制台输出改写boot log、--collect-all pystray确保托盘后端进exe。最终做到无窗口后台运行+系统托盘图标点击退出+单实例锁防重复启动+开机自启询问。

Webhook上报设计了一套完整协议：

统一信封（schema_version/event/event_id/agent/sent_at/payload），四种事件类型（scan/incident/alert/heartbeat），Bearer Token + HMAC-SHA256双认证（含时间戳防重放300秒窗口），PII脱敏（身份证/银行卡/手机号只传sha256哈希），本地outbox队列+指数退避重传。

用法

• 双击 Shepherd.exe，后台启动，自动打开浏览器。
• 首次使用：输入客户名称、联系人、注册码，点激活。
• 进入主界面，看到安全评分仪表盘和检测面板。
• 选择检测模块（资产/终端/DLP/日志），点"全面体检"。
• 扫描过程中实时显示进度，完成后自动生成安全报告。
• 点导出，生成HTML报告，可直接发给客户。
• 设置里可配置Webhook上报地址，填入运营方SOC平台的接收端点和凭据。
• 系统托盘有牧安图标，右键可"打开管理页面"或"退出牧安"。
• 首次启动会问是否开机自启，设置里也能随时开关。

对于运营方（我）来说，还有配套的 license_gen.py 签发工具，一行命令生成注册码。

效果

从第一行代码到打包成exe交付，前后三四天。实测在干净环境下双击exe，服务8秒内就绪，健康检查200，DB自动在exe同级目录生成。

DLP扫描的误报率从最初的"几乎全是误报"降到了接近零。拿真实数据测：Edge缓存里的18位数字串、hex哈希串里的11位片段、16位内部ID——全部被正确过滤；真实的身份证号、银行卡号、手机号全部正确识别。

Webhook上报最终跟真实的WN101安全平台打通：Agent ID/Token/Secret三件套认证，scan/incident/alert/heartbeat四种事件全通，HMAC签名验证通过，数据正确落库。

整个平台目前是我创业交付的核心工具。客户拿到exe双击就能用，不需要IT基础。扫描报告直接HTML导出，附在服务交付物里。注册码控制了试用期限和功能范围，商业上可控。

最大的体感是：如果要我自己写这个平台，光DLP那几个校验算法（GB 11643省份码+MOD 11-2、Luhn算法、正则边界）就得查好几天标准文档，更别说打包exe踩的那一堆坑了。AI把这些全包了。

项目尚未公开，就不贴图了。

写在最后

痛点必须自己定义。 AI不会替你发现"这里需要一个工具"。它擅长的是执行——你告诉它要什么，它给你做出来。但"要什么"这个判断，得你自己来。我做了十几年安全运营，知道小客户需要什么样的体检工具，这个认知是AI给不了的。

做法交给AI，但你得盯着。 牧安那个DLP误报的问题，AI前两版正则写得太宽，是我拿真实数据测出问题它才改的。它不会主动想到"Edge缓存里的18位数字串会被误匹配成身份证"——这种业务场景的坑，得在实际使用中发现，然后反馈给它修。

用法要在设计阶段就想清楚。 谁来用、怎么用、在什么环境用——这些约束决定了技术选型。牧安之所以用http.server而不是Flask，就是为了减少依赖、方便打包。护照号工具之所以做GUI版，是因为用这个工具的人可能完全不懂命令行。这些决策AI会帮你实现，但最初的约束得你提。

效果是跑出来的，不是吹出来的。 每个工具都拿真实数据测过。桑基图扔真实表格进去，牧安跑真实DLP扫描，护照号工具用真实PDF。AI写的代码能不能用，跑了才知道——不要信任，要验证。

这大概就是AI代码工具的意义：它不替代你的专业判断，但它把"从想法到工具"的距离压缩到了以前不敢想的程度。

一个思考：

处于当前的AI代码时代，一个刚毕业的程序员如何在AI的辅助下成长为一个合格的软件架构师呢？