这件事要从上个月底的财务结账说起。某位财务同事发来一张Excel透视表截图标题是“应收账款账龄分析表”旁边跟着一句抱怨这个月我做了整整一天。表格本身不难理解——按客户分组把每笔应收款项按账龄切成0-30天、31-60天、61-90天、90天以上的区间统计每个区间有多少钱。难点在于每月手工导数、手工分层、手工核对纯粹是重复劳动。我当时几乎不会改代码连Python环境报错都看不懂但也正因为这张截图我给自己立了个目标用14天在AI代码工具的辅助下做出一个能真正代替手工的账龄分析脚本。这14天里我一边正常上班一边用晚上和周末的时间推进。从第一天装Python都费劲到第14天能把几万行明细数据跑成一张可以直接交给领导的账龄报表中间踩了不少坑也总结出一套“不会写代码的人借助AI开发小工具”的完整打法。如果你也是业务岗、财务岗想用Python解放重复工作但又不知道怎么开头这篇记录应该能给你一个可以直接抄作业的路线图。1. 从Excel手工账到“让AI替我算”这个项目为什么值得做14天1.1 账龄分析到底难在哪不是逻辑而是重复劳动账龄分析在财务场景里是个典型的“逻辑简单、执行繁琐”的活。它要算清楚每笔应收款从业务发生日或到期日到当前基准日之间隔了多少天然后把这个天数映射到预先定义好的账龄区间里最后按客户维度汇总金额。逻辑一条线就能说清但实际做起来要处理大量明细行还要保证区间口径和财务确认的规则一模一样。难的是重复本身。数据每月更新格式偶尔调整客户名单不断变化手工筛选取数很容易漏行或重复计数。我那位财务同事每月都要花大半天在Excel里拉透视表再用SUMIFS手工核对几个重点客户的金额整个过程高度依赖注意力一个小数点错了得花更长时间反查。这也是我选账龄分析作为第一个Python项目的原因它本身有明确的校验基准——手工Excel结果——只要能跑出相同答案就证明代码写对了。另一个原因是数据形态合适。账龄分析的输入表通常是标准表格客户名称是文本业务日期和到期日是日期金额是数字。这种结构化数据恰好是Python里最成熟的数据分析库的主场几乎没有爬虫、接口、文本清洗这类不确定因素。对新学者来说项目失败的最大风险不是代码难而是业务规则模糊、数据格式混乱这类问题在账龄分析里都是可控的。1.2 为什么选AI辅助而不是先啃三个月Python语法很多人学Python的方式是买一本厚厚的语法书从数据类型学到函数学到类的时候基本就放弃了。我试过确实坚持不下来。这次反了过来不先学语法直接用AI辅助完成一个小而真的项目。你要做的不是自己写每一行代码而是让AI生成你需要的脚本然后逐行理解、修改、验证。我听一位做数据分析的朋友说过一句话“现在的AI编程工具就像给你配了一个随叫随到的代码实习生你只需要把需求描述清楚它替你打字。”这个比喻很贴切。账龄分析这种标准业务场景AI见过的样本足够多生成的代码质量比我自己写的高得多。我需要做的只是判断它写得对不对、改掉不合适的地方以及在它报错的时候能把问题说清楚。14天的时间安排也不是随便定的。前面几天摸索环境、熟悉工具中间集中写核心逻辑后面用真实数据反复验证和排错。我后文会整理一张完整的14天节奏表照着走就行不需要你额外设计计划。2. 把需求讲给AI听这套协作方式决定成败2.1 先描述Excel长什么样再谈代码刚开始用AI生成代码的人最容易犯的错是给AI一句特别笼统的需求比如“帮我写个程序处理应收账款”。AI不是神仙它不知道你的表在哪个路径、字段叫什么、日期格式是什么样只能凭想象给一个泛泛的模板跑起来问题一堆。我的做法是先把表格结构描述清楚。这里有个技巧直接把Excel文件的前几行字段名、字段含义、数据样例复制出来贴给AI。以我的应收明细表为例我这样描述文件路径D:\项目\应收明细.xlsxsheet名称明细表头在第1行字段列表客户名称文本、合同号文本、业务日期日期但部分单元格是文本、到期日日期、金额数字单位元需要做的事按业务日期计算账龄基准日默认为2024年11月30日区间为0-30天、31-60天、61-90天、90天以上把这些信息直接在对话里写给AI它生成的脚本命中率会高很多。这就好比你给一个新同事交代工作只告诉他“把表处理了”是不够的必须让他知道表长什么样、处理规则是什么、结果输出成什么样子。把AI当成这个新同事你的需求描述能力就是项目成败的第一道分水岭。2.2 每次只让AI写一小步跑通再往前我会在第一天就告诉所有想用AI学编程的人不要指望一条龙生成。一开始我也想一步到位让AI直接给一个完整脚本从读文件到输出账龄报表。结果报错信息一屏一屏地翻我看不懂报错在说什么也不确定是哪个环节出了问题整个人直接懵掉。后来我换了个策略把整个流程拆成几个小步骤每步都是一段可以独立运行的代码。具体拆分是读取Excel打印前5行确认数据能进来把业务日期列统一成日期格式检查有没有无法解析的值计算每行距离基准日的天数按天数区间打标签用透视表汇总每个客户在各区间的金额把结果写入新的Excel文件每完成一步我都会在对话里附上运行结果让AI确认是否符合预期再继续下一步。这种小步迭代的方式最大的好处是报错范围被控制在几步之内你不需要在一个200行的脚本里大海捞针你只需要把最近改的那一小段给AI看它很快就能找到问题。到第14天回看我真正写的代码其实不多但每一步都跑过、验证过。2.3 读懂AI代码的三个阶段模仿、校验、修改让AI写代码总有一个顾虑代码跑通了但是看不懂心里没底。尤其账龄分析要拿给财务用万一逻辑错了怎么办我解决这个问题的方式是分三个阶段走。第一阶段是“模仿式阅读”。我不要求自己理解每个函数的所有参数只要求能用大白话把代码做了什么事说一遍。比如pd.to_datetime(df[业务日期])就是“把这个列的文本变成日期格式”够了。第二阶段是“小样本校验”。我单独挑出10行数据自己拿计算器算一遍账龄再用脚本跑一遍两边对了说明逻辑没问题。第三阶段才是“边界修改”。这时候我会主动调整区间边界看看输出结果是不是跟着变用来验证我对代码的理解。实际测试下来这个方法比从头学语法快得多。你不需要先成为一个程序员再去写项目你可以先写出一个能用的项目过程中自然就把常用语法学了个七七八八。这段体验我一直记得因为它是这14天里最反差的结果让AI写代码并读懂它比自己硬背语法书快得多。3. 账龄计算的核心代码拆解从原始表到分层统计3.1 读文件与日期清洗最容易翻车的第一步账龄分析的第一步是读取原始表。如果表是Excel格式最简单的方案是用pandas.read_excel()如果数据量特别大可以换成polars的read_excel速度差异明显。我这里用pandas说明基本思路完整代码大概长这样import pandas as pd df pd.read_excel( D:/项目/应收明细.xlsx, sheet_name明细, dtype{客户名称: str} ) print(df.shape) print(df.head()) print(df.dtypes)读取之后第一步一定是检查字段类型。你可能觉得这一步无所谓但实际项目里大多数问题都出在这里。我的原始表里业务日期列显示的是object而不是datetime64说明有些单元格是文本格式还有的值是“2024/1/5 0:00:00”这种带时分秒的字符串。统一日期格式的代码是df[业务日期] pd.to_datetime(df[业务日期], errorscoerce)errorscoerce的意思是解析不了的日期值直接变NaN这样不会因为个别脏数据导致整个脚本报错。这一步跑完之后我会检查下缺失值print(df[业务日期].isna().sum())如果有缺失就要把那几行打出来看具体是什么格式再对症处理。这里要用到一个小技巧把字段名从业务日期换成到期日逻辑完全不一样所以第一步的字段确认千万不能省。3.2 账期基准与账龄区间划分账龄多少天绝对离不开基准日。基准日可以选今天、月末、或者报表截止日口径不同结果不同。我们公司财务确认下来常用的是“到期日相对于报表截止日超期多少天”来计算账龄所以基准日就设成报表日2024年11月30日。计算天数的代码如下base_date pd.Timestamp(2024-11-30) df[账龄天数] (base_date - df[到期日]).dt.days这里有个重要细节dt.days是直接取天数天数但对超过几十年的跨度要注意它取的是整数天没有考虑时间部分对账龄分析来说是没问题的。接下来就是区间划分最直接的方式是pd.cutbins [-1, 30, 60, 90, float(inf)] labels [0-30天, 31-60天, 61-90天, 90天以上] df[账龄区间] pd.cut( df[账龄天数], binsbins, labelslabels, rightTrue )pd.cut是左开右闭的分箱方法默认rightTrue。对于bins[-1,30]区间是(-1,30]也就是说30天整会被归到0-30天这个区间31天才进入31-60天。如果财务的手工逻辑是“超过30天才算31-60天”那这样是对的如果财务用的是“满30天就算下一个区间”你就需要把bins改成[-1, 29, 59, 89, float(inf)]。这个边界细节最容易引发跟手工表对不上的情况一定提前和财务确认口径。3.3 结果输出保格式回写Excel的技巧算完账龄区间之后需要用透视表按客户汇总result pd.pivot_table( df, index客户名称, columns账龄区间, values金额, aggfuncsum, fill_value0, marginsTrue, margins_name合计 ) result.to_excel(D:/项目/账龄分析结果.xlsx, sheet_name账龄汇总)这条代码不复杂但有一个大坑pandas直接to_excel写出来的新文件完全没有原来的格式同事拿到手以后肯定抱怨表头颜色没了、列宽乱了、字体变了。更稳妥的做法是用openpyxl加载一个事先设计好的模板工作簿把数据填进去保留原有格式。当时我让AI给我生成了一个用openpyxl写的回写脚本核心思路是先打开模板文件定位到目标工作表然后for循环把透视表的值写入指定单元格。这样文件格式是老板熟悉的模板内容自动更新这才算真正能用。到这一步一个核心流程算跑通了接下来真正的坑才开始浮出水面。4. 跑通Demo只是开始五个真实项目坑与排查链路4.1 日期全是字符串一个dtype引发的连锁问题第一个坑发生在我第一次用真实Excel跑脚本的时候。脚本报了个错具体是什么我记不太清大意是“字符串和datetime类型不能比较”。我的排查套路是先看报错最后十行找到具体是哪个操作报错打印相关列的dtype发现业务日期是object打印df[业务日期].head(20)看到两种格式混在一起有“2024/1/5”有“2024-01-05”也有“2024/1/5 0:00:00”把这些结果贴给AI问它怎么统一处理AI给的方案是先正则提取前面的日期部分再转成datetimeimport re def clean_date(x): if isinstance(x, str): match re.match(r(\d{4}[./-]\d{1,2}[./-]\d{1,2}), x.strip()) return match.group(1) if match else None return x df[业务日期] df[业务日期].apply(clean_date) df[业务日期] pd.to_datetime(df[业务日期], errorscoerce)这个过程让我明白一件事报错不是洪水猛兽它只是给了你一个线索。按“看报错尾部→查类型→看前几行样例→带着样例问AI”的顺序走多数问题十分钟内能解决。4.2 期初余额与本期发生的口径冲突第二个坑严重得多脚本跑出来的汇总数跟手工Excel差了十几万。排查过程是这样的——第一轮我只抽查三个客户发现差异不大第二轮我随机抽了10个发现其中两家差异明显第三轮我找到差异最大的客户把那个客户的明细一行行打印出来跟手工表对应位置比对。手工表里有“期初余额”和“本期发生”两个字段但我们的账龄分析应该基于每一笔业务明细的发生日期来算而不是基于余额汇总后再分摊。AI在第一版脚本里自以为聪明地把期初余额和本期发生做了个相加这完全不是账龄分析的正确逻辑。查明原因之后我的修复方案是重写一段逻辑df df[ ~( df[金额].isna() | df[业务日期].isna() ) ]这条删除缺失数据的代码本身很简单真正的教训是在做账龄分析之前必须和财务把业务口径对齐——什么字段代表业务发生时间、是含税金额还是不含税金额、是否包含已核销的收款记录。口径错了代码再漂亮也是白搭。后来我养成一个习惯开工前先列一个“业务规则确认清单”每个字段的含义和处理逻辑都写出来给财务或业务同事确认过再写代码。4.3 数据量一大就卡死换引擎与向量化数据的第三道坎出现在第10天。最初几万行明细跑一次要半分钟虽然能忍但当我把历史19个月的明细都导进来变成了60万行之后用老脚本一次流程要跑将近一刻钟。问题出在哪里我当时用的是pandas并且在一个自定义函数里用了apply逐行计算账龄区间。这是典型的“逐行Python循环”速度极其缓慢。排查思路是先找到瓶颈再想办法替换。我用%%timeit测了一段判断发现apply占了大部分时间。AI建议改用向量化的pd.cut因为它是底层C语言实现一次处理整列不需要Python逐行执行。效率对比大致是这样方案60万行耗时个人电脑实测自定义函数 apply逐行判段约8分钟改用pd.cut向量化分组约5秒换polars读取和分组约1.5秒这个提升非常直观。换完向量化后脚本基本不卡了。第二天我又把pandas换成了polars不是必须但在数据量大、内存有限的情况下差距确实存在。对普通账龄分析来说pd.cut已经足够polars属于锦上添花。4.4 回写Excel后格式全乱模板回写的补救方案第三个坑有关最后的输出文件。我最初开心地跑完脚本直接result.to_excel()生成结果然后发给财务同事。几分钟后对方回了一句“字体颜色怎么全没了表头的背景色呢”我才发现新的文件格式非常朴素跟原来的手工模板完全不像。排查链路是这样先确认问题是格式丢失还是数据错误——数据对得上只是格式丑然后我去看原始手工Excel的模板发现它有固定的列表头、列宽、合并单元格、表头底色最后我的方案是不直接覆盖原文件而是用openpyxl从模板复制一份工作簿把汇总结果填入特定单元格。核心思路是“保留模板格式只替换数据区”而不是重新生成一个文件。给同样遇到格式问题的读者一个建议模板文件最好单独备份一份干净版每次脚本运行时只操作副本这样即使填坏了也能从源模板恢复。这个小习惯后来帮我节省了不少返工时间。4.5 最隐蔽的坑账龄区间边界算错一天第五个坑是最隐蔽的因为它不报错输出也能跑出来数据乍一看都对。直到财务同事说“某客户的90天以上金额怎么比手工表多了XX元”我才回去检查区间边界。排查过程我找出差异客户打印他们每笔账龄的具体天数发现有一笔的账龄正好是60天整。手工的分档逻辑是“60天及以上归到61-90天”按这个口径60天整应该落在61-90天区间但我的代码里pd.cut默认左开右闭区间(30,60]包含了60天落到了31-60天区间。修复方式是把bins往前提bins [-1, 29, 59, 89, float(inf)] labels [0-30天, 31-60天, 61-90天, 90天以上] df[账龄区间] pd.cut(df[账龄天数], binsbins, labelslabels, rightTrue)改完之后60天整被分到61-90天跟手工口径一致。这个坑提醒我区间边界是账龄分析最容易出错、也最不容易自查的地方最好提前约定几张边界样例数据例如“正好30天”“正好60天”“正好90天”拿这些样例分别用脚本和手工算一遍两边一致才算通过。5. 这14天沉淀下来的工作流可以复制到其他场景的通用套路5.1 一个人快速上手AI编程的节奏设计如果你也想给自己一个14天的小目标可以直接参考我的节奏表工期任务完成标准DAY1安装Python、配置编辑器、建虚拟环境能在终端运行python --versionDAY2用AI读取Excel并打印前5行见到数据输出DAY3让AI讲解字段类型和缺失值能说出每列含义清洗日期列DAY4计算账龄天数用pd.cut分区间打印账龄分布DAY5做透视表输出汇总生成Excel结果DAY6小样本手工校验随机10行与手工计算一致DAY7完整数据试跑跑通不报错DAY8对照手工报表找差异定位所有不一致之处DAY9修复差异与手工报表逐客户核对一致DAY10性能优化大文件能在1分钟内跑完DAY11封装函数与参数传入路径和基准日即可运行DAY12模板回写格式输出文件格式与模板一致DAY13边界测试30/60/90天整边界结果正确DAY14正式跑批并写说明交付脚本 一页使用说明这套节奏的核心思想是每天只迈一小步但每一步都要有可验证的产出。这样即使中间某一两天确实很忙也不至于丢失进度因为每一步的完成标准写得很清楚回来之后知道从哪继续。5.2 能迁移到哪些任务自动化对账、科目分析、费用分析账龄分析跑通之后最大的收获不是这个脚本本身而是方法论可以复制。我把这套流程总结成五个步骤确认业务规则→让AI生成初版→小样本验证→真实数据核对→固化脚本。这套流程几乎适用于所有“表格进表格出”的重复工作。典型的包括银行余额调节表把银行流水与账面记录按日期、金额匹配固定资产折旧重算按资产卡片计算每月折旧金额费用报销分析按部门、费用类型、时间段汇总支出销售订单逾期统计按交付日期判断是否存在超期订单库存周转分析按入库日期和出库日期计算库龄每一类任务都可以按照账龄分析一样的思路去做。你不需要一开始就做一个大而全的系统先把最痛的那张手工表自动化就是巨大的胜利。5.3 后续进阶方向与工具扩展第14天交付之后脚本能用了但我很快发现还有几个可以优化的方向。一是参数化脚本。把输入路径、输出路径、基准日做成命令行参数这样每次跑数不需要改代码双击或执行一条命令就行。二是定时调度。如果你所在的环境允许可以用操作系统的计划任务把脚本安排在月初凌晨自动运行上班时结果已经放在桌面上。三是可视化看板。账龄分析的结果可以进一步生成图表比如按客户维度的金额分布柱状图方便汇报时直接展示。如果后续工作量更大还可以考虑把数据放到数据库里让Python脚本直接读取SQL查询结果然后让AI帮你封装成一个小工具给同事使用。不过这些都是下一步的话题对刚起步的人来说先把最核心的那张表跑顺比什么都强。最后再分享一个这14天里最值钱的小技巧运行Python脚本报错时永远先看最后十行英文提示然后原样复制给AI让它用中文解释给你听再让它给出修改建议。你在排查“日期全是字符串”这类问题时这一招会节省大量时间。别怕报错我直到今天照样会在AI对话里贴满报错信息这是解决问题最快的路径之一。