1.1 从重复任务到自动化脚本：需求识别、场景筛选与目标拆解
我第一次认真思考"要不要把这件事交给脚本"的时候，其实是被一堆每周都要重复处理的表格逼出来的。那会儿我每周一早上都要花两个小时，把七八个部门发来的Excel合并、去重、改格式，再截图发群。做第三周的时候我突然意识到，这套动作我闭着眼睛都能背出来——这就是最典型的自动化信号。重复、规则固定、输入输出清晰，三个条件同时满足，基本就可以考虑用脚本解决了。
后来我慢慢总结出一套自己的识别方法。先问自己三个问题：这件事一周做几次？每次做的步骤是不是几乎一样？出错以后重做的成本高不高？三个答案都指向"是"的时候，我就会把它列进候选清单。反过来，只做一次的任务、每次判断标准都在变的任务、需要大量主观审美判断的任务，我基本不会碰自动化，写了也是白写。
场景筛完还不算完，目标拆解这一步很多人会跳过。我吃过亏——最开始我总想"一步到位写个万能脚本"，结果写到一半发现需求自己都没想清楚。现在的做法是把大目标切成小动作：读文件、清洗字段、匹配规则、输出结果、发通知。每个小动作单独验证通过，再拼起来。这样即使中间某个环节AI给的代码不对，我也能快速定位是哪一块出了问题，不至于整段推倒重来。
1.2 AI辅助编写自动化脚本的工具定位：ChatGPT等模型在代码生成、解释和排错中的边界
我对ChatGPT这类工具的心态经历过一个明显的变化。刚开始觉得它是万能钥匙，什么代码都敢直接复制粘贴运行。被坑过几次之后，我把它重新定位成一个"反应很快但需要复核的搭档"。它擅长的是把自然语言描述翻译成结构化的代码骨架，擅长解释一段陌生代码在干什么，也擅长根据报错信息给出排查方向。这三件事它做得确实比我自己查文档快很多。
它的边界同样清楚。模型不知道我本地装了什么版本的库，不知道我公司内网的接口长什么样，更不知道我那份Excel里第37行藏着一个合并单元格。凡是依赖具体环境、具体数据、具体业务规则的部分，它给出的代码都需要我亲手核对。我现在养成一个习惯：AI生成的代码，先看import了什么，再看循环和异常处理，最后拿一小份真实数据跑一遍。
排错环节我尤其谨慎。模型有时候会"自信地编造"——给出一个看起来很像那么回事的函数名或者参数，实际根本不存在。我的应对办法是把完整报错贴给它，同时告诉它我的Python版本和关键库版本。信息给得越具体，它瞎猜的空间就越小。这个工具用得好不好，很大程度上取决于我愿不愿意把上下文交代清楚。
1.3 用ChatGPT生成自动化脚本提示词模板：角色设定、输入输出约束、运行环境与验收标准
提示词这件事，我一开始写得很随意，基本就是"帮我写个Python脚本合并Excel"。得到的结果时好时坏，完全看运气。后来我摸索出一个相对稳定的模板结构，效果明显提升。核心就四块：角色、输入输出、运行环境、验收标准。角色设定不是走过场，我会明确告诉它"你是一个熟悉pandas和openpyxl的Python工程师，代码要考虑异常处理"，这样它输出的风格会往工程化方向靠。
输入输出约束我会写得非常具体。比如"输入是同一目录下的所有.xlsx文件，每个文件第一个sheet，包含姓名、部门、金额三列；输出是一个合并后的result.xlsx，金额列保留两位小数，按部门分组汇总"。这种颗粒度它才能生成可直接用的代码。运行环境我也会交代：Python 3.9，只能用标准库加pandas，不能联网。这一条特别重要，不然它可能给你引入一堆你根本没装的依赖。
验收标准是我后来才加进去的，加了以后返工率降了不少。我会写"脚本要能处理空文件、能跳过表头不一致的文件并打印警告、运行结束输出处理了多少个文件"。把这些写进去，模型生成的代码天然就带上了基本的健壮性。说白了，提示词写得像一份简短的开发需求文档，产出质量就稳定得多。
1.4 提示词模板的复用与迭代：任务描述、示例代码、错误反馈和追问策略
我现在电脑里存着一个自己的提示词模板库，按场景分类：文件批处理、网页抓取、定时任务、数据校验。每次遇到新任务，先翻模板库找一个最接近的改，比从零写快太多了。模板里我固定保留了几个占位符，比如{任务描述}、{输入格式}、{输出要求}，用的时候填进去就行。这个习惯让我的起步时间从十几分钟压缩到两三分钟。
示例代码是我模板里很关键的一块。如果手头有一段类似的老脚本，我会贴一小段给模型参考，告诉它"保持这个代码风格和日志格式"。模型对示例的跟随能力挺强，给个好样例，输出就贴近我的习惯。没有样例的时候，我会在追问里让它先给一个最小可运行版本，跑通以后再逐步加功能，这样每一步都可控。
错误反馈和追问策略我觉得是最能拉开差距的地方。报错的时候我不会只说"报错了"，而是把完整traceback、我执行的命令、期望的结果一起给它，然后追问"这个错误最可能的原因是什么，给我两个修改方案"。让它给方案而不是给答案，我再自己挑，这个互动方式我用下来最踏实。有时候它第一版不对，我会接着问"如果输入文件是空的，这段代码会怎样"，用连续追问把边界情况逼出来。
1.5 安全合规与质量底线：数据脱敏、权限控制、依赖管理和生成代码审查
自动化脚本一旦跑起来，往往会接触到真实业务数据，这条线我从来不敢松。我的基本操作是：给AI看的数据一律脱敏，姓名换成"张三"，金额换成随机数，文件路径改掉。真实数据只在本地跑脚本的时候出现，绝不往对话框里贴。这个习惯看起来麻烦，但真出过一次同事把客户名单贴进去的事之后，我就彻底养成条件反射了。
权限控制也是同理。脚本里涉及数据库连接、API密钥、邮箱密码的部分，我一律用环境变量或者本地配置文件，提示词里只写"从环境变量读取"，绝不让密钥出现在对话记录或者代码注释里。依赖管理我会要求模型明确列出需要安装的包和版本，自己再核对一遍有没有多余或者有风险的库。生成代码审查这一步不能省，哪怕代码再短，我也会逐行看一遍，重点看文件写入路径、删除操作和网络请求这几个地方。
质量底线说白了就是一句话：AI可以帮我写，但责任在我。脚本删错文件、发错邮件、泄露数据，最后背锅的是跑脚本的人。所以我的原则是生成、审查、小范围试跑、再放开，四步一步都不能跳。这套流程走顺了，AI带来的效率提升才是真正落袋的，而不是埋了个雷等着以后爆。
2.1 Python自动化脚本教程框架：环境准备、库选择、脚本结构和小步验证
我拿到AI给的第一段自动化代码时，干过一件特别蠢的事——直接在系统Python环境里pip install了一堆东西。结果没到半个月，本地环境就乱成一锅粥，某个库升级之后把另一个老脚本跑崩了。后来我老老实实养成了习惯：每个自动化项目单独建虚拟环境，python -m venv venv一行命令的事，省掉后面无数麻烦。虚拟环境建好以后，我会先在提示词里把环境约束写死，告诉模型"只能用这些库的这几个版本"，免得它天马行空。
库的选择我一般遵循够用就行的原则。文件批处理离不开pandas和openpyxl，网页采集用requests加BeautifulSoup基本能覆盖八成场景，需要处理动态页面再上playwright。我会让AI在生成代码前先列一个依赖清单和用途说明，自己扫一眼，看看有没有杀鸡用牛刀的情况。有些场景明明标准库的csv和pathlib就能搞定，模型有时候会习惯性拉pandas进来，这种我会手动砍掉。
脚本结构上我慢慢摸索出一个固定骨架：开头是导入区和配置区，中间按功能拆成几个小函数，末尾一个main函数串流程加上if __name__ == "__main__"。这个结构看着简单，真正让我受益的是小步验证的习惯。AI给的代码不管多长，我都会拆成几段分别跑——先验证文件读取对不对，再验证清洗逻辑，最后验证输出。每段跑通再往下走。有一次一个合并脚本死活跑不出结果，我就是靠分段验证发现是日期格式转换那一步把整列变成了NaT，后面全跟着错。
2.2 典型场景一：文件批处理与数据整理脚本的AI生成流程
文件批处理是我用得最多的场景，也是我觉得最适合新手拿AI练手的场景。上个月我接了个活：一个文件夹里躺着六十多份销售日报，格式一模一样，但要合并成一张总表，按区域汇总，还要把缺失日期的行标出来。这种需求放在以前我得写小半天，那次我把需求整理成一段话丢给ChatGPT，第一版代码十分钟就出来了。
我的提示词大概是这么写的：读取指定目录下所有xlsx文件，每个文件只取名为"明细"的sheet，统一列名后纵向拼接，按区域和日期双条件汇总销售额，缺失日期的行单独输出到warnings.csv。我还特意加了一句"用pathlib处理路径，不要用字符串拼接"。模型生成的代码整体框架是对的，但我一跑就发现问题——它默认所有文件sheet名都一样，实际有两份文件sheet名多了个空格。这个坑它想不到，我也没在提示词里交代，只能自己补一个sheet_name.strip()的处理。
这次之后我学乖了，再写文件批处理的提示词，一定加上异常文件处理的要求：读不了的文件跳过并记录文件名，列名对不上的打印警告，空文件直接忽略。这几句话加进去，生成出来的代码直接带上了try-except和日志输出。我现在的流程基本固定了：写清目录结构、文件格式、目标输出，再补三句容错要求，AI给的代码改改就能用。六十多份文件那次，从写提示词到跑通结果，前后不到四十分钟。
2.3 典型场景二：办公流程与网页数据采集自动化的AI生成流程
办公流程自动化这块，我踩过的坑比文件处理多得多。有一回我想让脚本自动登录公司内部系统导出报表，把登录页面的HTML片段贴给AI让它生成登录代码，结果它给的方案是直接post表单。我拿去一试，返回403。后来才搞明白那个系统登录走的是前端加密加token验证，不是简单的表单提交。这件事让我记住一个教训：涉及登录、验证码、加密参数的场景，AI看不到真实请求细节，给的建议只能当参考方向，具体实现得自己抓包分析。
网页数据采集相对顺一些，但也有讲究。我常做的采集任务是抓公开的行业数据列表页，结构稳定、不需要登录。这种场景我会把页面的HTML结构（去掉敏感内容）贴给模型，告诉它要提取的字段和翻页规则，让它用requests加BeautifulSoup写。生成出来的解析逻辑一般没问题，容易出岔子的是翻页和限速。模型默认写的循环往往没有延时，我会手动加time.sleep，顺便加上失败重试和User-Agent设置。有一次采集到第三页突然被封IP，就是因为没加延时，那次之后我把"每请求间隔不低于2秒、失败重试三次"直接写进了提示词模板里。
办公流程里还有一类是操作Excel生成固定格式的周报。这种我一般用openpyxl配合模板文件来做，让AI写填充逻辑和格式设置。需要注意的是合并单元格和条件格式这些细节，模型经常写得似是而非，我会让它先把操作步骤一条条列出来，我确认没问题再让它落成代码。这个"先列步骤再写代码"的追问习惯，帮我省掉了很多来回调试的时间。
2.4 从生成到可运行：代码审查、调试、测试和异常处理
AI给的代码能直接跑通当然最好，但我现在的默认心态是"它大概率有坑，我得找出来"。代码审查我重点看四个地方：文件路径是相对还是绝对、有没有硬编码的账号密码、循环里有没有可能死循环、异常处理是不是真的兜住了。有一次模型生成的脚本里写了个while True等待文件出现，没设超时，我要是直接跑，文件没来它能挂一晚上。这个习惯救过我好几次。
调试环节我的做法是把报错信息完整贴回给AI，同时补上我的运行环境和输入数据的大致情况。光贴traceback不够，我会再加一句"这段代码的意图是XXX，现在卡在YYY"。这样它给修改方案的时候方向更准。测试方面我没搞得太复杂，就是准备三份测试数据：一份正常数据、一份空文件、一份列名错乱的文件。三份都跑过，我才认为脚本基本可靠。异常处理我会专门检查有没有把错误吞掉的情况，比如except后面跟个pass，这种写法看着省事，出了问题根本不知道哪一步挂的，我会改成打印具体错误再继续。
2.5 提示词模板到脚本模板：沉淀可复用自动化脚本模板库
用AI写脚本写到第三个月的时候，我发现自己每次都在重复描述类似的需求。于是我干了一件事：建了一个自己的模板文件夹，里面分门别类放着提示词模板和脚本骨架。提示词模板按场景分，文件批处理一个、网页采集一个、定时任务一个、数据校验一个。每个模板里固定有几块内容：任务描述占位、输入输出格式说明、环境约束、容错要求。用的时候填空就行，比每次从零想要快得多。
脚本模板这边，我把几个常用骨架存了下来：带日志配置的主脚本骨架、带重试机制的请求函数、标准的文件读写工具函数。AI生成新代码以后，我会把里面通用的部分抽出来放进模板库，下次直接让模型"基于这个骨架补充业务逻辑"。这个做法让生成代码的风格越来越统一，我自己维护起来也轻松。模板库我大概每个月整理一次，把用得少的删掉，把新踩的坑补进去。
2.6 迭代优化与效果评估：日志、性能、可维护性和持续改进
脚本能跑通只是起点，跑得好不好得看后面。我现在写任何自动化脚本，第一件事就是加日志。AI生成代码的时候我会明确要求"用logging模块，INFO级别记录关键步骤，ERROR级别记录异常，日志同时输出到文件和控制台"。加上日志以后，脚本半夜跑挂了，我第二天早上翻日志就知道挂在哪一步，不用靠猜。
性能方面我不会过度优化，但会关注几个基本指标：处理一百份文件要多久、内存占用有没有异常飙升、网络请求有没有不合理的串行。有一次一个采集脚本跑了两小时，我一看日志发现九成时间耗在等待响应上，改成加并发之后缩短到二十分钟。可维护性我也慢慢在意的，函数命名让AI写清楚一点，关键逻辑加注释，配置项统一放到文件开头。这些小事当时多花五分钟，三个月后回头看脚本的时候能省两小时。
效果评估我一般跑一段时间再看。脚本上线第一个月，我会记录它省了多少人工时间、出过几次错、每次错的原因是什么。这些记录反过来又能优化提示词模板——哪类错误反复出现，我就在模板里加上对应的约束条件。这套循环走下来，AI辅助写脚本这件事才真正变成了一个越用越顺的流程，而不是每次都在碰运气。
