1. 第一次尝试前的准备与工具选型思路

1.1 为什么突然想用AI写代码

先交代一下背景。我写代码的年头不算短，平时主要做数据清洗、自动化脚本和一部分后端接口开发。按理说，日常需求自己动手敲几行也就搞定了，但最近手头项目排得满，重复性的胶水代码越来越多——比如把A系统的导出表格转成B系统要的格式、批量处理几百个文件、写一次性爬虫脚本之类的。这类活儿说难不难，但真的很耗时，尤其是一边开会一边还要赶工时，脑子里全是“这破代码怎么还不写完”的焦躁感。

所以就动了用AI写代码的念头。其实“AI写代码”这几个字这两年听得耳朵都快起茧了，从GitHub Copilot到各种国产编程助手，再到ChatGPT这种通用大模型，大家都在说能帮你写代码。但我一直持保留态度，总觉得AI生成的代码“能跑但不敢用”，直到一个周末被一个临时需求逼急了，决定认认真真试一回，不搞花活，就用最朴素的思路，看它到底能不能顶上一个初级开发者的活儿。

这篇文章就是那次完整尝试的记录，从选工具开始，到提示词怎么写、代码怎么调、坑怎么踩，全部摊开来讲。如果你也想试试AI写代码，但不知道从哪下手，或者试过几次觉得“也就那样”，那这篇应该能帮你少走点弯路。

1.2 主流AI编程工具怎么选

打开搜索引擎一查，AI编程工具五花八门，光是我看到的就有：

• GitHub Copilot：背靠GitHub海量代码库，IDE内联补全体验最好，插件市场占有率第一。
• Cursor：基于VSCode的AI原生编辑器，主打“整个文件对话式生成”，可以框选代码直接让AI改。
• OpenAI Codex：ChatGPT背后的代码引擎，能理解自然语言描述生成代码，也支持对话式调试。
• 通义灵码、Fitten Code：国内团队做的IDE插件，免费额度友好，中文理解更强，尤其Fitten Code在PyCharm里用的人不少。
• Claude、Gemini这类通用大模型：不集成IDE，但对话式生成能力强，适合写完整脚本或解释复杂逻辑。

怎么选？我给自己定了个标准：不做重度改造、能快速上手、有不俗的免费额度。因为我这次只是“尝试”，不想一上来就付费订阅。所以我选了“VSCode + Fitten Code”的组合，再用ChatGPT网页版做备选。Fitten Code既能续写又有对话功能，ChatGPT则适合我这种喜欢先在对话里把逻辑捋清楚再动手的人。

这里有个小提醒：选工具别看广告，看你要做什么。如果你是长期写工程代码、重度依赖IDE调试，那Copilot或Cursor更合适；如果你只是偶尔写脚本、处理数据，那免费的插件加通用大模型就够了。我在PyCharm里也试过Fitten，体验不错，主要胜在免费、轻量、对中文需求理解比较准。

1.3 环境准备与项目规划

选了个什么项目来试水？太简单的不行，瞧不出能力；太复杂的又容易失控，最后变成我来给它擦屁股。我最后定了一个“Excel报表自动整理脚本”——需求很明确：读取指定文件夹里的多张Excel表，按文件名里的日期字段排序，合并成一个总表，再按“部门”分组生成汇总统计，最后输出一个新的Excel文件。

为什么选这个？因为它至少有四个特点：

1. 需求边界清晰，不需要AI发挥想象力去猜业务规则；
2. 涉及文件操作、日期解析、pandas数据处理、openpyxl写入，技术栈常见；
3. 可独立运行，不需要连数据库、起服务，调试成本低；
4. 结果可验证，我拿真实的表一跑就知道对不对。

环境方面我提前装好了Python 3.10、VSCode、Fitten Code插件，还pip安装了pandas和openpyxl。准备工作做完，我正式开始第一轮“人机结对编程”。这一试，才发现原来让AI写代码，关键根本不是在“写”，而是在“说”。

2. 核心实操：提示词工程与需求拆解

2.1 需求描述怎么写才有效

第一次用AI写代码的人，最常见的错误是上来就一句：“帮我写个Python脚本处理Excel。”这种描述扔给谁都没法干活——处理什么？怎么处理？输出成什么样？全都没说。AI再聪明，也不可能读心。

我第一版提示词也犯了这个毛病，给Fitten的描述是：“读取Excel文件并按部门汇总。”结果它给我返回了一个只读取单张表、用硬编码列名、完全没有文件名排序逻辑的脚本。能用，但离我的真实需求差了十万八千里。

后来我学乖了，按照“输入-处理-输出-约束”四段式重写提示词。这里我放一个改进后的模板，你直接抄就行：

请写一个Python脚本，实现以下功能： 【输入】 扫描指定目录 D:/work/report/ 下的所有.xlsx和.xls文件， 每个文件的文件名格式为“20240105_销售部_周报.xlsx”， 其中第一部分是日期（YYYYMMDD），第二部分是部门名称。 【处理】 1. 按文件名中的日期从早到晚排序所有文件； 2. 读取每个文件的内容，跳过前两行表头，保留表头为 [日期, 部门, 销售额, 订单数] 的数据； 3. 将所有文件的数据合并到一个DataFrame中； 4. 按“部门”分组，对“销售额”和“订单数”求和，并计算销售额占比（保留两位小数）。 【输出】 生成一个新的Excel文件 D:/work/report/汇总统计.xlsx， 包含两个Sheet： - Sheet1"明细数据"：所有合并后的原始数据； - Sheet2"部门汇总"：分组统计结果。 【约束】 - 使用pandas和openpyxl库； - 代码要处理表头大小写不一致的情况（统一转为小写再匹配）； - 文件读取要加异常处理，跳过损坏文件并打印日志； - 最后打印处理了多少个文件、每个部门的总销售额。

看出差别了吗？我把我脑子里的规则全部“翻译”成了AI能理解的语言。文件名格式、表头内容、排序规则、输出结构、异常处理——每一个细节都写清楚。AI不是神仙，它只是把你给的约束条件翻译成代码，你给的信息越充分，它生成的代码就越贴近需求。

2.2 逐步引导AI生成代码的会话技巧

第一次对话直接把上面那段长提示词丢进去，AI返回了一个接近80行的脚本。我通读了一遍，整体逻辑是对的，但有三个问题：

1. 日期排序那一步，它用了字符串切片转datetime，逻辑没问题但没做异常处理，万一文件名格式不规范就崩。
2. 表头统一转小写那部分，它只处理了“销售额”和“订单数”，没有处理“日期”和“部门”的大小写变体。
3. 它自作主张加了一个“业绩排名”列，我根本没要求。

这就是用AI写代码的核心心法：你不是在“下令”，而是在“对话”。第一版拿到手后，我继续发指令：

逻辑基本正确，但需要修改： 1. 日期排序如果遇到格式不匹配的文件，跳过并打印警告，不要中断； 2. 表头匹配时允许"销售总额""销售额（元）"这类变体，统一映射到"销售额"； 3. 去掉自动加的排名列，我只需要规定的两个Sheet； 4. 输出文件时如果目标文件已存在，自动加时间戳后缀，不要覆盖。

这种“一轮一轮改”的方式非常关键。指望一次对话生成完美代码不现实，但AI的可怕之处在于它每次都能准确理解你的追加指令并修改对应部分。我大概改了四轮，每轮间隔几分钟，最终生成的脚本从“能看”变成了“能用”。整个过程下来，我最大的感受是：和AI协作写代码，像极了带实习生——你交代得越清楚，他返工就越少；他初稿越离谱，你的批注就越要具体。

2.3 代码集成与真实环境调试

AI把脚本生成完，是不是就万事大吉了？天真。我把代码copy到VSCode里一跑，立刻遇到两个问题。

第一个是路径硬编码。AI生成的代码里写的路径是D:/work/report/，但我实际测试环境用的是macOS，路径压根不存在。小问题，但暴露了一个事实：AI不知道你的运行环境。所以提示词里应该明确“当前系统为Windows/macOS/Linux，路径分隔符用os.path.join”——这又是一条经验。

第二个是依赖版本问题。AI用的是pandas的新版API，但我环境里装的pandas版本偏老，to_excel的时候写engine参数的方式不一样。报错信息一大堆，我直接复制报错发给AI，问它“这个错误是什么原因、怎么改”。它秒回：把engine='openpyxl'显式传入即可。一改，通了。

到这里，脚本已经能跑通，输出结果也验证无误。整个“AI写代码”的第一次尝试，从写提示词到脚本跑通，前后花了大概一个半小时。要是按照我自己平时的速度，这些琐碎的活至少得半天，光是在各种Excel格式差异上磨就能磨到怀疑人生。

3. 过程中踩过的坑与问题排查实录

3.1 特征性失败：AI代码看着能用但一跑就跪

说句公道话，AI写代码能力确实在线，但“看着能用”和“真正能用”之间隔着一条鸿沟。我这次实操中至少碰上了四类典型问题，整理了个速查表，你以后肯定用得上：

这四类问题里，“幻觉API”最坑。有一次它生成了一段用pd.read_excel(..., dtype=...)的代码，参数本身没问题，但我那版pandas不认。我把报错丢给AI，它立刻换成了converters参数，还补充说明了两者区别。这件事给我的启发是：**你的调试能力就是AI的上限。**你越能看懂报错、越能描述偏差，AI修正得就越快。

3.2 边界关键：AI不知道你的业务上下文

还有一类坑特别隐蔽——AI没有业务常识。比如我的报表文件名是“20240105_销售部_周报.xlsx”，但实际文件夹里混着一个“20240105_销售部_周报_最终版.xlsx”。AI按“第二部分是部门名称”去切分，把“销售部_周报_最终版”整个当成了部门名，分组统计自然全乱了。

这种问题AI自己发现不了，因为我也没有在提示词里说清楚文件名的“严格格式”和“可能出现的变体”。解决办法就是我在2.1的模板里加的“约束”部分：明确异常情况下应该跳过该文件。但更根本的经验是：不要把AI当成了解你业务的同事，它只是个没有业务语境的代码翻译器。你脑子里那些“大家都知道”的潜规则，AI一概不知，把它喂成明确文字，它才能规避这些坑。

3.3 排查思路：一个实战调试现场回放

我把这次调试过程中最典型的“崩溃现场”完整还原一下。

最初跑脚本，报错信息是：

KeyError: '销售额'

我一看就知道是列名没匹配上，但懒得自己查，直接把报错丢给AI，并补充了一句：“读一下原始Excel的头几行，打印列名看看实际是什么。”AI加了一段调试代码：

df = pd.read_excel(file_path, skiprows=2) print(df.columns.tolist())

一打印，原来真实表头是“销售金额（元）”，不是“销售额”。我把这个发现回贴给AI，它随即修改了映射逻辑，加了一个统一映射字典："销售金额（元）": "销售额", "sales": "销售额"。再跑，通了。

这个调试过程看着平平无奇，但它说明了AI写代码的最佳实践范式：**你做人脑判断，它做代码修改；你喂它真实反馈，它帮你快速迭代。**人和AI不是替代关系，而是结对关系——你负责“知道什么是对的”，它负责“把对的表达成代码”。

4. 从单次尝试到可复用流程：经验沉淀与工具扩展

4.1 把提示词模板沉淀成自己的“需求翻译器”

试完这一次，我最大的收获不是多了一个能用的脚本，而是打通了一套可复用的“AI写代码工作流”。下次再遇到类似需求，我不会从零开始组织语言，而是直接套用这个模板：

1. 输入：文件从哪来，命名规则是什么，字段有哪些；
2. 处理：按什么逻辑加工、排序、汇总、转换；
3. 输出：生成什么格式，sheet结构，连命名都写清楚；
4. 约束：异常处理、版本兼容、边界情况、性能要求；
5. 验证：用什么测试数据验证结果是否正确。

前四项是第一轮对话用，第五项是调试阶段用。这套模板现在被我存在一个笔记文件里，每次要用AI写代码就复制一份填内容，效率和成功率都上来了。

4.2 人和AI的分工清单

试过一次之后，我整理了一份“哪些事该让AI干、哪些事必须自己干”的分工：

说白了，AI写代码最适合的是“需求已经清楚、实现没有惊喜”的场景——批量处理、格式转换、爬虫、报表、接口mock等。它不擅长的是“需求含混、需要业务判断”的场景——比如“帮我写个能提升业绩的算法”这种，AI只会给你一堆正确的废话。

4.3 后续还能怎么玩：多AI协作与Agent化

这次尝试还让我看到了几个可能的方向。

第一个是多AI协作。比如用ChatGPT做整体方案，用Claude写复杂算法片段，再用Fitten在IDE里做即时补全。每个模型有自己的强项，搭配合适反而比单打独斗更稳。第二个是AI Agent，我最近在一些开源社区看到有人用“Agent”方式跑代码生成任务——你告诉它最终目标，它会自己拆解子任务、自己调用工具一步步完成，还会在你反馈报错后自动修正，这类工具正在把“提示词工程”变成“目标管理”。

还有一个方向是AI写代码 + AI测试。脚本生成后，直接用另一个AI来审查代码、写测试用例，甚至模拟输入输出验证。相当于组了一个“AI开发小队”，一个负责写，一个负责测，人只做最后的验收。我在这次尝试后半段已经用了这个思路——把AI生成的脚本发给另一个模型做code review，确实指出了几处我没注意到的问题。

我个人非常看好这种协作模式：你更像项目经理而不是程序员。你做需求分析、进度管理、验收测试，AI负责具体实现。这也许就是未来一个人干一个团队活的底层逻辑。

4.4 个人体会：AI写代码的真正门槛

说句实在话，试完之后我对“AI写代码”这件事的态度有了转变。以前觉得它是个玩具，现在觉得它是个效率放大器。但前提是，你自己得懂代码。你越懂，越能精准描述需求、越能看懂结果、越能快速调试返工——AI的效率就越高。反而是一点代码基础都没有的人，拿着AI生成的一堆代码，报错时完全手足无措。

所以如果你问我“不懂编程能不能用AI写代码”，我的回答是：能生成，但驾驭不了。如果你真想用这个技能，至少得先会读代码、懂基础的调试方法，这部分没有捷径。

这次尝试只是一个开始。我后续打算把更多以前拖着的自动化脚本需求都扔给它试试，再多试几条赛道：写SQL、写正则、写shell脚本。到时候有新的心得再写一篇分享。

最后一个小建议：如果你也想试，别拿重要项目练手。找个周末，挑一个不紧急、边界清晰的自动化小任务，按上面那套流程走一遍。跑通了，你对“AI写代码”的认知会完全不一样。跑不通，那正好花点时间研究提示词和调试，这本身就是最值钱的经验积累。