审计师学编程的第三年，我悟了什么
三年前的现在，我在项目上第一次打开 VBA 编辑器，想录一个”把 40 个工作簿汇总成一个”的宏。三年过去，我写的工具在这个部门里轮着用，我也从”会录宏的审计师”变成了”会做审计的写代码的”。这个节点上，把三年的感悟写下来，给同样在学编程的同行。
悟了的第一件事：编程不是技能，是视角
刚入门时我以为学编程就是学语法——VBA 怎么写循环，Python 怎么定义函数。三年后回头看，语法是最不重要的部分。真正改变的是看工作的方式。
以前拿到一份 300 行的往来表，我看到的是”数据”；现在我看到的是”结构”——主键是什么、哪些列是维度、哪些列是度量、这份表能和哪份表通过什么字段勾稽。以前发现两张表对不上，第一反应是”逐行找”；现在的第一反应是”这个匹配逻辑能不能交给机器”。
这个视角的转换有个准确的描述：把每一次重复劳动都看作一个需求文档。你抱怨着做完的每一件重复小事，都是一个工具的 MVP。
悟了的第二件事：审计思维和工程思维是同一种思维
有一天我意识到一件事：代码评审（code review）和底稿复核，根本就是同一个程序。
| 审计 | 编程 | | --- | --- | --- | | 内控测试 | 单元测试 | | 底稿复核 | Code Review | | 重要性水平 | 容错阈值 / 尾差忽略 | | 函证（向第三方求证） | 集成测试（向真实系统求证） | | 复核轨迹 | Git 历史 |
两者共同的核心都是：不信任任何未经验证的断言。变量说是 100，你要断言它真的是 100；对方说余额一致，你要向独立来源求证。学编程之后我的底稿反而做得更好了——因为”这段处理不可复现”在我眼里变成了不可接受的缺陷。
反过来，审计背景也让我的代码更稳：自动化的脚本必须有”复核轨迹”（日志、中间文件），就像底稿必须留痕。你的职业训练就是你的工程优势，别把两者对立起来。
悟了的第三件事：工具的价值 = 使用次数 × 单次节省
我写过十几个工具，大部分死了，活下来的有共同点：高频、规则稳定、输入格式可控。死掉的工具也有共同点：一年用一次、规则老变、输入全靠现场临时发挥。
所以现在评估一个工具需求，我只问两个问题：这个月会用到几次？输入格式我能控制吗？两个都不行，再炫的需求也不做。
这也是为什么我的工具几乎都长着一张”朴素的脸”——命令行、CSV 进 CSV 出、单文件。审计现场最贵的不是功能，是确定性：同事双击 exe，三秒后出结果，中间不弹任何需要理解的东西。
悟了的第四件事：学会写”给别人用”的东西
第三年最大的进步不是代码量，是终于开始为”用户”写程序：
- 报错信息写人话：不说
IndexError，说”第 37 行日期格式不正确：‘2026/13/01’，请检查月份”； - 所有路径让用户选，不写死任何绝对路径；
- 输出文件命名带时间戳，永远不覆盖任何人的文件。
这些不是代码技巧，是换位思考。审计师对”会动的东西”天然警惕，你每一个不体面的报错，都会让一个潜在用户回到手工操作。
悟了的第五件事：保持”审计师”这个主体
见过不少同行学会编程后恨不得把所有环节都自动化，最后工具维护本身变成了加班项。我的底线是：工具是为判断服务的，不是替代判断的。
账龄重算可以自动，但”3 年以上应收为什么还在挂账”必须人来回答；核对工具能找出差异，但差异背后是错报风险还是流程缺陷，是审计师的判断。自动化把体力活拿走，剩下的全是脑力活——这才是这个行业正确的分工。
给同行的三条建议
如果重来一遍，我会这样走：
- 从当下最烦的那件事开始，而不是从教程第一课开始。需求驱动，语法现查；
- 尽早让真实用户用上。工具被人用的那一刻，才会暴露真问题；
- 把过程写下来。这个博客本身就是我的”工作底稿”——记录需求、方案、踩坑，未来回看时，它就是你个人的知识资产。
三年前那个对着 VBA 编辑器发呆的审计师，大概想不到今天。但路径其实就是：每解决一个让自己烦躁的小问题，就走了一步。路不快，但每一步都算数。