一个非程序员用codex写脚本的真实记录

周一早上九点半，我对着屏幕上47个Excel文件发呆。运营周报里需要把这47个分公司的销售数据汇总到一个母表里，打开、复制、粘贴、关掉，再打开下一个。这套流程我做了三个月，每周雷打不动，耗掉我整整一上午。

那天我破防了。不是因为累，是因为无聊。我坐在工位上，突然冒出一个念头：听说现在AI能写代码了，我能让它帮我干这个吗？

我不会写代码。我大学学的是市场营销，职业生涯里离代码最近的一次，是十年前在网页上右键点击“检查元素”。但这周一上午，我真的用Codex让一个Python脚本跑了起来，把这47个文件的汇总从4小时压到了11秒。

这篇文章不是教程，不是成功学，是一个文科生和AI对话写脚本的真实记录，包括我差点放弃的那三个小时。

01 脚本跑通之后，我坐在椅子上愣了很久

先说结论：Codex确实能让非程序员写出能用的脚本，但“能用”和“会用”之间，隔着一整个下午的自我怀疑。

跑通之后我最直观的感受不是兴奋，是恍惚。我看着屏幕上那些我完全看不懂的代码，脑海里只有一个想法：这玩意儿居然是我“写”出来的？

准确地说，这是我和AI一起“聊”出来的。我负责描述需求、描述错误、描述我想要的最终结果；它负责生成那些我看不懂的英文和符号。我从头到尾没有写一行代码，但我得学会怎么和它说话，怎么说清楚一件“人类觉得很正常、机器觉得很抽象”的事。

所以如果你问我，非程序员到底能不能用Codex写脚本？答案是能，但有条件。条件是你得愿意花一两个小时去跟它“磨合”，去接受“这东西不是魔法”的现实。

02 我为什么要遭这个罪

回到那个Excel的场景。每周一我的工作流程是这样的：

1. 打开钉钉，从七个群里把各省负责人发过来的Excel下载下来
2. 逐个打开文件，复制“本周销售数据”那个sheet里的第三行到倒数第二行
3. 粘贴到一个叫“全国汇总”的母表里，注意列要对齐
4. 关掉文件，下一个，重复46次
5. 最后检查一遍有没有粘贴错位

四十七个文件，四十七次重复。这种活儿的特点是：规则极其明确，步骤极其稳定，但对于人来说极其折磨。 它不需要判断力，不需要创造力，只需要耐心，而人最缺的就是耐心。

我知道这种活可以写脚本解决，但“写脚本”这三个字对我来说跟“造火箭”差不多。直到有次刷到一个视频，有人说Codex可以“用自然语言写代码”，就是你说人话，它帮你生成Python。

我决定试一下。大不了浪费一个下午。

03 第一道坎：我连“环境”是什么都不知道

如果你和我一样是纯小白，有个事实你得先知道：Codex不会帮你装Python。 它生成的是代码，但你能不能跑得起来，取决于你的电脑有没有“能跑代码的环境”。

我当时的认知水平是：我以为双击Python文件就能运行。结果下载完Python之后，对着一个黑色的命令行窗口发了十分钟呆。我不知道什么叫环境变量Path，不知道pip是什么，不知道什么叫“在终端里运行脚本”。

最后我是怎么解决的？我打开浏览器，搜“Python装好之后怎么运行代码”，然后照着教程在命令行里打出了人生第一个python --version。

这条命令运行成功的瞬间，我松了口气，觉得最难的部分过去了。

想多了。

04 第二道坎：我的问题AI它听不懂

环境勉强搞定之后，我打开Codex，在输入框里打了第一句话：“帮我写一个合并Excel文件的脚本。”

AI给了我一段代码。我复制下来，运行，报错。

回头看那段代码，它确实在处理Excel合并，但它处理的逻辑是，把所有文件里的所有sheet合并。而我的需求是：只提取每个文件里叫“本周销售数据”的那个sheet，并且只取第三行到倒数第二行。 我没说清楚，AI当然不知道。

这是非程序员用Codex最容易踩的坑：你以为你说清楚了，但你其实没说清楚。 写代码这件事要求你把需求拆到“傻瓜级”的粒度。人类之间的沟通可以靠共识和默契来补全，但AI补不了你没有说出口的信息。

我花了将近四十分钟，反复修改我的描述，从“合并Excel”细化成：

• 文件都在桌面的“分公司报表”文件夹里
• 只处理.xlsx格式的文件
• 每个文件里都有一个叫“本周销售数据”的sheet
• 从这个sheet的第三行开始取，取到不含表尾的最后一行
• 所有数据追加到同一个汇总表里，表头保持一致

当我终于把这些条件一条条写清楚的时候，AI给出的那段代码，跑通了。

这里有个关键认知：Codex不是在“理解你的意图”，它是在“匹配你的描述”。 你描述得越精确，它匹配得越准。你指望它“聪明地猜到你在想什么”，那大概率会失望。

05 第三道坎：AI也会写bug，而且是理直气壮的那种

跑通是跑通了，但只跑通了第一次。当我换了一批新文件再跑的时候，脚本又报错了。报错信息是英文的，我只看懂了一个词：KeyError。

当时的心情是：我已经投入了两个多小时，距离成功只差临门一脚，然后一脚踩空了。

但我做了个正确的决定：我把报错信息复制下来，直接贴回给Codex，然后说“你刚才给我的代码运行到这里报这个错，你看看怎么改”。

这个操作的本质，就是让AI自己给自己debug。

它很快回复我，说错误可能是因为有些文件里没有名为“本周销售数据”的sheet，或者sheet名多了空格。它修改了代码，加了一行处理异常的逻辑，如果找不到对应sheet就跳过并提示我。

我重新运行。这次没报错，终端里跳出了三行提示：“文件‘华北大区-副本.xlsx’未找到目标sheet，已跳过”。

我笑了。这就是真实世界的场景：数据是脏的，格式是不统一的，总有人交上来的文件跟要求不一样。 AI给我的不是一个完美的脚本，是一个“遇到问题知道跳过去继续走”的脚本。

06 成果对比：我到底省了什么

脚本最终稳定运行之后，我做了个粗略的时间对比：

开头三次运行脚本花了我三个多小时，包括环境配置、反复改描述、和AI来回对话纠错。但三小时的投入换来的是每周至少省下三四个小时的重复劳动。

这个投入产出比，我个人觉得值。但如果你的重复性工作量本身就没那么大，一个月可能就那么一两次的话，坦白说，不一定值得专门折腾一次。

07 真相：它不能替代程序员，也不该替代你

写完之后，我回头看这段经历，最深的感受是：Codex没有让我变成程序员，它让我变成了一个“会提需求的甲方”。

我需要具备的能力不是写代码，而是能把完整的需求描述清楚、能把报错信息准确地反哺给AI、能接受“第一次生成的可能不太行”这个现实。

这不是“零门槛副业”，这是需要花时间去磨合的协作。我的角色更像是导演，AI是那个技术很强但理解力有限的演员，我说戏，它演，演砸了我得说清楚哪里砸了，它才能调整。

还有一个需要正视的问题：什么任务值得写脚本？ 我给自己定的判断标准很简单：如果一件事每个月要做超过三次，步骤固定且机械化，每次耗时超过半小时，就值得让AI帮我去写脚本。如果是临时性的、一次性的需求，或者中间需要大量主观判断，那我宁愿自己手动做。

写在最后

那个周一下午，脚本跑完最后一行的时候，窗外还是办公楼林立的天际线，和三个小时前一模一样。什么都没变，除了我心里对“自动化”这三个字的理解。

如果你也是一个被重复劳动折磨的非程序员，我建议你直接试试。不需要先学Python，不需要先看几十页教程，就带着一个你最想解决的问题去，把需求写清楚，把报错贴回去，做好第一次大概率失败的心理准备。

最坏的结果就是你浪费了一个下午，证明了这玩意儿暂时不适合你。最好的结果，你发现未来很长一段时间，你都不用再做那件你不想做的事了。

你想让AI帮你解决的第一个重复性工作是什么？先把它写下来，写清楚，比“谁能帮我写个脚本”这句话，至少要多出十倍的细节才行。