零基础用Python和AI辅助完成账龄分析的全过程记录

今天是14天实战计划的第2天。昨天我连“改一个Excel公式”都心里发虚今天却在AI辅助下用Python独立做完了一张账龄分析表并且顺手核对了三个客户的手工小计全部对上。这篇记录不是教程更不是炫耀而是把一个零基础的人第2天怎么完成“从不会改代码到独立做账龄分析”的全过程摊开给你看。如果你也正在被数据报表折磨每天手动拉数、筛客户、贴Excel这篇内容值得花十分钟读一遍。不需要你有编程基础我第2天会的就是“照着AI写的代码改路径、改字段名、跑起来然后自己验证结果”。听起来很简单但这里面有坑也有通用方法。文里从为什么选中账龄分析、怎么搭环境、三版代码演进、高频报错排查一直讲到第2天复盘和下一步计划。看完你至少能判断像我们这样没学过代码的人想用Python解决手头的实际工作到底应该怎么开始。1. 为什么第2天就敢碰账龄分析1.1 账龄分析到底在解决什么问题账龄分析是财务、销售、运营里特别常见的需求。它的核心逻辑一句话就能说清按“发生日期距离今天”的间隔把业务金额分到几个时间区间里再统计每个区间有多少钱。最常见的场景是应收账款也就是客户欠了多少钱分别欠了多久也可以是库存一批货在仓库里躺了多少天甚至可以是合同本身一份合同从签署到现在过去了多久。为什么要做这件事因为金额的大小不能单独说明风险。一笔5万块的欠款如果刚发生可能很正常同样是5万块如果已经拖了200天那就得换一种态度去催收。账龄分析的意义就是把“什么时候发生”和“金额多少”两个维度叠加起来让业务方一眼看出问题在哪儿。第2天的我选它不是因为它业务上有多高级而是因为它结构足够简单一张流水表每行是一笔业务有日期、有客户、有金额。这样的数据天然适合用表格处理也天然适合用Python跑。更关键的是每一步都能用肉眼验证——算完以后我拿Excel手工筛选几个客户加一遍数字能不能对上立刻就知道。对零基础的人来说这种“能验证”的特质太重要了否则代码跑出一个结果你根本不知道它是真对还是碰巧。1.2 我把目标拆成了三个不用慌的小任务刚开始看到“账龄分析”四个字我脑子里是懵的。分析怎么分析后来我用最笨的办法把它拆成了三件事。第一件事把Excel读进来搞清楚每一列是什么。这叫和数据“打个照面”。第二件事给每一行流水算出一个“账龄天数”再根据天数归入对应的区间比如0到30天、31到60天。第三件事按客户加上区间把金额汇总成一张透视表最后导出成新的Excel。这三个动作对应到Python里分别是pandas的read_excel、日期计算加cut分箱、groupby汇总加unstack透视。它们恰好是数据分析最常见的骨架。也就是说这次练手做的账龄分析本身只是载体真正练的是读文件、改字段、做日期运算、分组汇总这一套通用动作。学会了以后做销售日报、库存周转、回款统计全是同一套思路。这么一拆我心里踏实很多。因为这不等于是“从零写一个分析系统”而是“把三件小事情逐个跑通”。每一件单独拎出来在AI的帮助下都不算大但它们合在一起就刚好构成了一个完整的实用分析流程。1.3 零基础学编程的正确姿势先跑通再理解这个观点是我昨天临时决定的今天验证下来觉得特别重要。过去总觉得“学代码”应该先懂语法再会写最后才能干活。按这个进度我这种平时还要上班的普通人一个月后大概还在背列表和字典。但实际操作下来路其实可以反着走先让AI根据我的描述生成代码我改掉那些必须改的部分让脚本跑通跑通以后再针对每一行去问AI“这句话在干什么”最后再尝试自己改一点参数看看结果怎么变。今天我就是这么干的。效率高得离谱。你不用担心“这算不算真的会编程”——对我来说第2天的目标本来就不是成为程序员而是能独立完成一个业务分析。只要结果可以验证、过程有人把关代码是AI写的还是我背下来的在实操里没有那么重要。重要的是我能不能说清楚需求、能不能发现结果不对、能不能把报错喂回去得到修正方案。这些能力今天全都练到了。2. 开工前的准备环境、样板数据、工作目录2.1 第2天最省事的Python环境搭建作为一个完全没基础的人第一天我把环境折腾了半天今天学乖了用了最省事的方式直接装带Python的发行版把常用的数据分析库一并装好。具体来说我装的是Anaconda它自带Python、Jupyter Notebook和pandas、openpyxl这些库。装的过程就是一路下一步中间没有任何需要手写配置的地方。如果你不想装那么大的东西也可以只装官方Python然后在命令行里执行两条命令pip install pandas pip install openpyxlpandas负责数据处理openpyxl负责读写Excel的xlsx格式。我这里特别提一下openpyxl是因为只装pandas的话read_excel和to_excel遇到“xlsx”文件会报错很多人卡在这里半天。配套装好后面就顺了。我写代码的入口用的是Jupyter Notebook因为单元格可以分段跑读进来以后马上看head()输出错到哪里自己心里有数。这点对新手太重要了。如果是那种整段脚本、出错以后从头再来一遍的方式零基础的人很容易崩。Notebook的好处是先读文件看到结果再算日期看到结果再汇总看到结果。每一步都可视化安全感强很多。2.2 一张能练手的模拟流水表怎么造没有真实业务数据怎么办自己造。我用Excel随手生成了一个叫“流水明细.xlsx”的文件字段用了五个客户名称、单据号、业务日期、应收金额、已收金额。客户就写了三家A公司、B公司和C公司日期从2025年1月到2025年6月各放了几笔金额随意填总共20行。你别小看造数据这一步。它其实是对“字段设计”的训练——你得先想清楚账龄分析需要哪些信息才能造出合适的表。比如我要算“剩余应收”就得同时有应收金额和已收金额两个字段我要按业务日期算账龄天数就得有业务日期这个字段。这些字段一个都不能少少了后续代码就没法算。造数据的时候我特意埋了三种情况一种是有部分回款的即已收金额小于应收金额一种是有多收的已收金额大于应收金额还有一种预留了空白日期。这样做的目的是测试代码的健壮性。真实数据从来不会干干净净如果只拿漂亮的表练手第一次处理脏数据就会手足无措。2.3 目录规划和“原始表不动”原则开工前我用10分钟定了一个简单目录后来证明这个决定直接挽救了我好几次。项目根目录下建两个子文件夹一个叫input一个叫output。原始数据文件永远放在input里并且约定好不管后面怎么改原始表一律不动每次处理都从复制一份新文件开始。所有跑出来的结果放到output里脚本本身放在根目录。第2天的代码不多但等以后脚本多起来这种划分能让你少走很多弯路。这看起来像个洁癖问题实际是安全底线。零基础的人最容易犯的错就是直接修改原始表改错了就再也找不回来。哪怕只是在单元格里误删了一列对账时都会被坑得很惨。所以我在桌面角落贴了一句备忘数据是原料代码是菜谱output是餐桌input是仓库。仓库的货只能取用不能改。另外写路径的时候新手我建议先用绝对路径。比如C:/Users/你的电脑名/Desktop/账龄实战/input/流水明细.xlsx。等跑通一段以后再改成相对路径。第一次用相对路径的人八成会遇到FileNotFoundError不是文件不存在而是程序在哪里跑和你以为它在哪跑不是一回事。这个坑我当天就踩了后面专门讲。3. 三版代码从描述需求到跑出结果3.1 第一版完全用大白话给AI提需求第2天我没有一上来就写代码而是先打开一个普通浏览器找了一个自己用得顺手的AI对话窗口把我的需求用大白话打了一遍。原话大概是这样我有一张Excel表路径是input/流水明细.xlsx字段有客户名称、单据号、业务日期、应收金额、已收金额。请帮我写一段Python代码使用pandas库先计算出每张单据的剩余应收剩余应收等于应收金额减已收金额再按照业务日期距离基准日2025年6月30日的天数将数据分成账龄区间未到期、0到30天、31到60天、61到90天、90天以上最后按客户名称和账龄区间汇总剩余应收金额保存为Excel输出。请给每行代码加注释告诉我每一步在做什么。没用任何专业术语就是说话。AI很快给了我一整套代码。第一版代码我基本没怎么看懂但我知道必须改两处一个是电脑里的路径另一个是字段名要对上我的表。改完以后运行居然真的输出了结果。当时特别兴奋一兴奋就开始犯险想直接拿着这个结果去交差。还好我多留了个心眼又回到Excel里手工验证了两个客户结果发现小计对不上。这一版的价值在于验证了“用自然语言驱动AI写程序”这件事是可行的。但第一版也只是能跑离“可靠”还很远更别说理解它在算什么。于是我开始第二版。3.2 第二版看懂账龄区间的核心计算第二版我不再满足于“能跑”而是让AI把每一行代码讲给我听尤其是核心的日期分箱部分。我不要求自己立刻全懂但至少要能回答一个问题一个具体日期是怎么被分到某个区间的。账龄天数本质上就是基准日减去业务日期得到一个天数。比如基准日是2025年6月30日一笔业务发生在2025年6月10日那账龄就是20天落在“0到30天”这个区间。如果业务发生在2025年5月20日账龄是41天就落在“31到60天”。这个逻辑很清楚。剩下的问题是代码怎么写。下面这段是第二版的核心代码我把它贴出来并且把当时AI解释给我的要点转述一遍import pandas as pd df pd.read_excel(input/流水明细.xlsx) # 日期列转成pandas的日期类型方便做减法 df[业务日期] pd.to_datetime(df[业务日期]) # 计算剩余应收 df[剩余应收] df[应收金额] - df[已收金额] # 设定账龄计算的基准日期 base_date pd.Timestamp(2025-06-30) # 基准日减去业务日期得到账龄天数 df[账龄天数] (base_date - df[业务日期]).dt.days # 分箱边界左开右闭 bins [-0.5, 0, 30, 60, 90, 999999] labels [未到期, 0-30天, 31-60天, 61-90天, 90天以上] df[账龄区间] pd.cut(df[账龄天数], binsbins, labelslabels) # 按客户和账龄区间汇总剩余应收 result df.groupby([客户名称, 账龄区间], observedFalse)[剩余应收].sum().unstack(fill_value0) # 保存结果 result.to_excel(output/账龄分析结果.xlsx)这小段代码里的关键是bins和labels的配合。pandas的cut方法默认把数据按“左开右闭”区间切分也就是说区间是(a, b]的形态。理解这个以后bins为什么是[-0.5, 0, 30, 60, 90, 999999]就很好解释了账龄等于0天或者为负数的会被分到(-0.5, 0]这个区间对应的标签是“未到期”账龄在1到30天之间的分到(0, 30]就是“0-30天”。后面的30、60、90是依次的逻辑边界。最后一个999999是一个很大的数保证“90天以上”能把所有极端情况兜住。我一开始没注意到“左开右闭”差点把所有数都分错。如果bins直接写[-1, 0, 30, 60, 90, 999999]账龄0天会落入(-1, 0]还能行但账龄1天会落入(0, 30]也还行。真正容易出问题的是负数——如果业务日期晚于基准日账龄天数是负数分箱时必须给它留一个区间否则会被标记为NaN。我用的-0.5就是给这些“未到期”的负数留的位置。当时为了验证理解到位我手动拿一个日期推算了一遍再打印df.head()看了新生成的“账龄天数”和“账龄区间”两列确认无误以后才继续。3.3 第三版补上数据体检和边界情况第二版跑通以后我以为已经大功告成。但我把处理逻辑重新看了一遍发现至少有三个隐患没解决日期为空怎么办、金额里有非数字怎么办、剩余应收为负数怎么办。真实数据里这些情况都会出现不处理分析结论会有水分。于是我把第三版的目标定为“不慌”遇到脏数据先筛出来、看清再决定是剔除还是修正而不是让代码默默把错误吃掉。于是我让AI帮我写了三段“体检代码”。第一段是日期体检# 查看是否有空日期 print(df[业务日期].isna().sum()) # 删除日期为空的记录或用fillna填充一个默认日期 df df.dropna(subset[业务日期]) df[业务日期] pd.to_datetime(df[业务日期], errorscoerce) df df.dropna(subset[业务日期])第二段是金额体检# 强制转换成数值转不了的会变成NaN df[应收金额] pd.to_numeric(df[应收金额], errorscoerce) df[已收金额] pd.to_numeric(df[已收金额], errorscoerce) # 查看金额为空的记录 print(df[df[应收金额].isna() | df[已收金额].isna()]) # 删除无法计算金额的记录 df df.dropna(subset[应收金额, 已收金额]) df[剩余应收] df[应收金额] - df[已收金额]第三段是多收与负数处理# 查出剩余应收为负的记录 print(df[df[剩余应收] 0]) # 做账龄分析时对负数要单独决策 # 如果只是分析欠款可以把剩余应收小于0的金额按0计入 df.loc[df[剩余应收] 0, 剩余应收] 0这个“负数按0计”是需要业务判断的不是所有场景都适用。但我今天为了完成一个干净的账龄表先采用保守做法多收部分的金额不参与到欠款账龄金额中同时把它单独打印出来留给业务同事去看。经过第三版的处理代码和第一版相比多了很多“防守动作”。跑出来的结果我再拿去和手工验证终于全部对上了。那一刻我才理解写代码真正的门槛不在语法在于把所有异常情况想到并处置掉。这个思维方式是以前用Excel的时候完全没有意识到的。3.4 结果怎么验证闭上眼睛也能核对的方法代码跑完结果最怕的是什么是自己骗自己。所以我每次跑完都会做三道验证题。第一道总额核对。原始表里的剩余应收总和应该等于透视表里所有格子加起来的总额。如果不等必然有问题。我自己写了两行代码做这件事total_raw df[剩余应收].sum() total_result result.sum().sum() print(f原始表合计: {total_raw:.2f}) print(f透视表合计: {total_result:.2f})如果两个合计不相等通常意味着在分箱过程中有NaN被漏掉了或者有日期缺失导致某些行没进入任何区间。第二道区间分布抽查。我会用value_counts看每个区间的记录数是否合理比如“0-30天”的记录数不会为零如果为零要看是不是基准日写错了。第三道客户级抽查。随便挑一两个客户把Excel原始数据里对应客户的行筛出来手工加一遍区间金额再和透视表里那格比对。这个方法笨但最可靠。今天我就是靠它抓住了第一版代码里小计对不上的问题。你可能会问为什么写了代码还要手工验证那不是多此一举吗其实不然。第2天我还没有能力从代码逻辑上判断结果正确性唯一能信的只有原始业务数据本身。用业务常识去验证技术输出是零基础的人最应该学会的防守手段。4. 第2天遇到的高频报错与排查清单4.1 三个当场解决的报错第一个报错是FileNotFoundError。它出现在我运行第一版代码的时候系统提示找不到“input/流水明细.xlsx”。我确认了文件存在还是报错。后来我打印出当前工作目录才明白程序是在项目根目录跑的但我把代码文件放在了子文件夹里它默认找的是代码文件所在的目录。解决方法是把路径改成绝对路径或者用os.chdir()把工作目录切换过去。从那以后我学乖了只要涉及文件读取先打印当前目录和文件列表确认这一步再做下一步。第二个报错是KeyError: 客户名称。明明我的Excel里有这一列却提示找不到。排查下来发现我表里的列名是“客户 名称”中间多了一个空格。手动录入的数据特别容易出这种问题列名看着一样实际上字符串不完全一致。解决方法是打印df.columns.tolist()把真实的列名拿到手再复制进代码千万不要靠眼睛看。第三个报错是ValueError发生在日期转换那一步。原始表里有一行的日期格式是“2025年6月”跟其他行的“2025-06-10”不一致pd.to_datetime直接罢工。我按3.3节的方式加了errorscoerce无效值变成NaT再配合dropna处理问题就解决了。这个处理方式不完美但至少让程序不会整体崩溃同时把问题行暴露出来。4.2 金额对不上时怎么查比报错更让人头疼的是代码没有报错但结果和手工核对时对不上。今天我就遇到了原因是第一版代码在计算“剩余应收”之前没有处理“已收金额”列里的空白单元格。空白被pandas当成了NaN一个数字减去NaN得到NaN然后在汇总时NaN会被自动跳过导致总额变小。排查这类问题我的顺序是这样先看df.head()和df.dtypes确认各列类型是否符合预期再查df.isna().sum()看清空白和缺失分布在哪里接着逐列打印“总数、非空数、空数”判断有没有该有数据的地方被当成空值处理。这一套流程走完通常问题就暴露了。今天的问题最终就锁定在“已收金额”列的空值上我把它fillna(0)再重新跑总额就对上了。这里还有一个小细节pandas在groupby汇总时默认会跳过NaN。这个特性平时方便但如果你没发现NaN存在它就会让结果“凭空小掉一块”。所以不管代码报不报错养成看isna().sum()的习惯能省掉很多对账时间。4.3 把报错丢回给AI的正确姿势零基础的人用AI排查报错最常见的错误是只丢一句“报错了”。AI又没有超能力看不到你的数据和目录结构能给出的建议大多是猜。我今天试出来的正确姿势是把完整的报错信息原样复制过去紧跟着说明自己那一步想做什么再加上数据表的字段列表和两行脱敏样例。也就是说要给AI足够上下文它才能给到有用建议。比如我遇到KeyError时是这样提的“我读了一张Excel表columns的列表是[客户 名称, 单据号, ...]我想选‘客户名称’这一列但程序报KeyError: 客户名称。我想做的是按客户分组统计金额。”AI立刻指出了列名里的空格问题。如果我只发“KeyError怎么办”大概率得到的回答是泛泛的不会命中我的问题。另外我提醒自己不要盲目接受AI给的修改。每次它给一个新方案我就追问一句“这行代码是在解决什么问题为什么会解决”只要对方解释得通我才放心粘贴运行。这个习惯让我的每一次修改都有据可循而不是陷入“报错——瞎改——再报错”的循环。下面把第2天遇到的问题整理成一张速查表供同起点的朋友直接对照现象可能原因检查动作处理方式文件读不到路径相对位置不对打印当前工作目录和文件是否存在改用绝对路径或切换工作目录提示找不到列列名有空格或大小写不一致打印df.columns.tolist()把真实列名复制进代码日期列报错日期格式不统一检查df.dtypes和异常值用errorscoerce加dropna金额列是文本Excel里存了带符号的数字打印df.head看首行内容用pd.to_numeric(errorscoerce)分组多出NaN行日期或金额有空值查看df.isna().sum()剔除或fillna处理汇总对不上NaN被自动忽略对比原始总额和透视总额补上空白值后重跑5. 复盘与下一步AI辅助学习的实用心得5.1 两天下来我对“会代码”的理解变了第1天晚上我还在焦虑觉得“不会改代码”是一道跨不过去的坎。第2天晚上再看我发现这个问题本身问错了。真正需要的能力不是“把代码背下来”而是“用代码完成一项业务任务”的闭环描述需求、生成代码、调整路径字段、运行验证、修正异常。这个闭环里编程只是其中一环而且是可以被AI承担的一环。更费心力、更需要人类判断的其实是前面和后面把业务逻辑想清楚把结果验证做扎实。这个理解对我来说意义很大。以前我用Excel做账龄每个月底把几万行数据下载下来用数据透视表一个个手动调整位数对齐、日期格式、空值处理全都要自己在表格里找出问题。今天用Python跑完一遍后不敢说一劳永逸但至少流程是敲在代码里的下个月只要换一下数据和基准日就能复用。这种“沉淀感”是手工Excel给不了的。5.2 给同起点的人三条实用建议如果你和我一样从前一行代码没写过今天想过要开始我有三条第2天才悟到的建议。第一不要跟着教程写“Hello World”直接拿自己业务里最头疼的一张表动手。教程的东西和自己工作碰到的问题之间隔着一层“为什么我要学这个”的障碍一旦是真实需求你会主动想方设法跑通。账龄分析就是我的真实需求所以我才会一遍一遍验证遇到报错也不烦躁。第二把“跑通”当成第一目标不要追求自己从头写。我第2天的代码没有几行是我自己敲出来的但每行我都让AI解释过我也都动手改过路径、字段名和参数。这个过程就是我逐渐理解代码的过程。你不需要为自己用了AI而觉得心虚。用AI辅助就像查字典正经办法。第三所有原始数据先备份所有代码脚本留版本。今天我用到的代码前后经历了三个版本如果没留版本最后对照时会不知道哪一次改动导致了什么结果。我给文件命名用的是“账龄分析_v1.py”“账龄分析_v2.py”这样的规则简单但有效。加上每一版跑完都要打印一次性验证结果后期复盘才有据可查。5.3 第3天安排从一张表走向一张图第2天的成果是一张静态的账龄透视表客户在行、区间在列每个格子是金额。接下来我最想做的是把这张表和可视化结合起来。具体计划是给透视表加一行“合计占比”算出每个账龄区间占整体金额的百分比再用柱状图把各客户的账龄区间分布画出来最后拼成一个简单的回款健康度看板。这样到第3天结束时我不仅能算账龄还能把结论直接展示给业务同事看。对应到技术上会用到matplotlib或者pandas自带的plot方法。但我预计会遇到新坑比如中文显示成方块、柱状图颜色、图例位置这些。这些都是经典问题真遇上了我再逐个拆解记录。最后分享一个今天最有感触的瞬间代码第一次跑通的时候我没有急着开心而是先拿纸笔把客户A在“31到60天”区间应该有多少钱算了一遍拿小票验证程序输出发现真的能对上才敢放手去做下一个客户。一个零基础的人第2天就能独立产出一个经得起核对的分析结果这件事的底气不是你多快学会了语法而是你愿意多花三分钟做验证。这个习惯比任何代码技巧都值钱。剩下的12天就按这个节奏走不求快求每一步都扎实。