坦白说在这件事之前我对“AI写代码”的态度一直是“看看热闹可以真把工作交出去免谈”。直到上个月接到一个浑身都是重复劳动的活把七八个字段对不齐的Excel表清洗成统一格式再给每组行情数据算好均线和金叉死叉信号两天内要交。这活不难但脏每一行代码都写得出每一行都不想来第二遍。于是我决定认认真真试一次AI辅助写代码并且给自己定下原则所有AI生成的代码我必须逐行看懂、跑通、再提交。这篇文章就是这次“尝试1号”的完整复盘记录了我怎么提问、怎么翻车、怎么补救最后还沉淀出一套适合普通开发者的提问套路和工具组合。如果你和我一样有Python基础但不想被重复劳动耗死这篇文章至少能帮你少走两天的弯路。1. 这次需求很小但AI写代码的尝试机会正好1.1 需求拆分一句话能说清的活写起来却要半天先把需求说清楚大家才能理解我为什么说它“脏”。一句话版把多个Excel文件里的行情数据统一成同一种格式然后计算双均线信号输出一份汇总Excel。拆开之后就有点烦人了每个Excel文件的列名都不一样有的叫date有的叫日期价格列有的叫close有的叫收盘价。日期格式不统一有“2024-01-01”这种标准格式也有“20240101”这种无分隔符格式。部分文件里有缺失值有的还带表头注释直接pd.read_excel读进来根本没法用。最终交付物不是一屏终端输出而是一份规范化的新Excel要有文件名、统一日期、统一列名、均线值、金叉死叉标记。我粗算了一下纯手工写这套脚本至少要三个小时。这三个小时不是“不会写”而是“写的时候一直在查pandas文档、试错、处理边界情况”。这种情况恰恰是AI工具最擅长插一脚的地方——模板逻辑多、业务规则少、主要靠经验堆。1.2 给自己定的三条实验规则我决定试AI但不想被它带沟里。所以在开始之前我给自己定了三条硬性规则后来事实证明这三条规则帮我避免了不少灾难。第一条AI生成的代码必须逐行审查看不懂的不用。AI给你一段“看起来合理”的代码很容易但“看起来合理”和“实际正确”是两回事。我不能接受一段我无法解释的代码出现在交付里。第二条必须先在样例数据上跑通再放到全部数据上跑。让我直接对全部真实文件执行AI生成的代码心理负担太大。先拿两个文件试跑能跑通再放开。第三条每一版能跑的代码立刻提交到码云。这个习惯后面会细讲简单说就是版本控制是让AI写代码变得可逆、可控的前提。三条规则定完我打开了聊天框开始了第一次尝试。2. 第一次提问有多天真AI给了我“能跑但不能用”的代码2.1 原封不动的提问长什么样我现在把第一次提问原文贴出来大家别笑帮我用Python写一个计算移动平均线的代码没了真就这一句。我没说数据是什么格式没说文件在哪没说读Excel还是CSV没说输出什么没说金叉死叉怎么算什么都没说。我当时的心态是AI不是号称很能写代码吗我把需求说个大概它应该能“意会”吧。结果证明这个“大概”害死人。2.2 它生成的代码和我的“差评”AI当时返回的代码去掉各种解释之后核心长这样import pandas as pd df pd.read_csv(data.csv) df[ma5] df[close].rolling(window5).mean() df[ma20] df[close].rolling(window20).mean() print(df)我盯着这段代码看了二十秒然后沉默了。它确实“写对了”——移动平均线的核心逻辑rolling(window5).mean()就是标准答案。但它对我这次的实际任务几乎没有任何帮助。我的数据是Excel文件列名不是英文而是中文日期格式乱得一批我要的不是打印而是输出一个新Excel我要的不只是均线还有金叉死叉标记我还得保留文件名维度方便后续核对。我如果不改这段代码跑在我数据上第一步就会因为找不到close列直接报错。就算我手动改列名它也解决不了日期统一和输出格式的问题。最后我统计了一下它给出的代码里只有rolling和mean两个词被我留在了终稿里。2.3 差点放弃之前我换了一个类比当时我差不多想放弃了心里想的是“AI写代码就是个噱头还是我自己来吧”。但冷静下来之后我换了个角度想问题如果团队里新来了一个实习生我让他做这个活他只跟我说“帮我写个计算移动平均线的代码”我能满意吗当然不会。我会告诉他数据在哪、列名是什么、输出长什么样、什么时候该算金叉。AI和这个实习生没有本质区别——它是一个知识量巨大、但对我这次任务一无所知的“新同事”。问题不在AI在我给的上下文太少了。想通这一点我决定不放弃而是换一种提问方式重新来一遍。这一遍就有了后面那些“能直接用”的代码。3. 翻车现场解析大模型写代码的底层逻辑和我踩中的三个坑3.1 大模型是怎么“写”出代码的在讲我的“四步提问法”之前我觉得有必要先花一点篇幅讲清楚大模型写代码的底层逻辑。理解了这个你就知道为什么有些AI代码看起来那么“对”用起来那么“废”。大模型写代码本质上是在做“下一段文本的接龙”。它的底层结构是Transformer靠自注意力机制去衡量你输入文本里每一个词和其他词之间的关系。训练阶段它看过GitHub等公开仓库里海量代码学到的是统计规律出现df之后后面跟着.rolling的概率很高.rolling(后面跟着window的概率很高再往后mean()出现的概率也很高。于是当你把问题发过去它生成的内容其实是它认为“接下来最合理的延续”而不是从某个知识库里“检索”出来的现成答案。这里有两个关键概念会影响你后续的使用体验上下文窗口和温度参数。上下文窗口就是模型一次能“看到”的文本量。窗口内能塞进去的信息越多它接龙的条件就越明确。如果你的问题只有一句话它就只能凭训练数据里最常见的情况去续写写出来就是一篇标准答案而不是针对你数据的定制方案。温度参数则控制生成结果的随机性。写代码这种事需要的是确定性和稳定所以温度调低一点更好让AI尽量输出概率最高的答案而不是发挥“创意”。明白了这一点你再看第一次翻车就会非常清楚我的问题描述太短等于给了一个极窄的“接龙条件”AI能写对rolling已经算它及格了。3.2 坑一把AI当搜索引擎用第一个坑也是最普遍的坑把AI当成搜索引擎用。搜索引擎的逻辑是你输入关键词它从亿万个网页里挑现成答案给你。大模型的逻辑是你输入一段话它根据这段话生成一段新的话。这两种逻辑看起来都是“我问你答”但本质完全不同。搜索引擎适合查“移动平均线的公式是什么”AI适合回答“根据我这批数据的列名和缺失情况帮我写一段能算移动平均线的代码”。如果你让AI写代码却不给它和你任务相关的任何细节它就只能假装自己是搜索引擎给你一段教科书式的示例。我后来把这个问题想明白了AI写代码的输入是一份“需求上下文”而不是一串关键词。上下文越接近你真实的工作环境出来的代码越接近能直接跑的版本。3.3 坑二没给它验收标准第二个坑是我没给出“什么叫做完”的判断标准。人跟人协作说一句“帮我做个统计报表”对方会基于经验脑补出报表的字段、格式、口径。但AI没有和我共同工作的历史它脑补出来的“统计报表”和我脑子里的“统计报表”大概率不是同一个东西。拿我这个需求为例我脑子里其实装着一份很具体的验收清单列顺序必须是open、high、low、close、volume日期格式必须统一成YYYY-MM-DD均线在数据不足窗口长度时保留NaN金叉死叉输出布尔值最终数据必须写回Excel且带上文件名来源。这些标准在我脑子里但我一句都没告诉AI。它当然不知道于是就把自己理解的“输出”定义成了print(df)。这不是AI偷懒是它没有默认值可猜。所以说验收标准不是可选项而是写代码提示词的必填项。3.4 坑三忽略了运行环境和库版本第三个坑是运行环境和第三方库版本。AI训练数据里什么年代的代码都有有可能给你一段依赖Python 3.10新语法match的代码而你的环境还是Python 3.8有可能它给你一个df.append()而在pandas 1.4以后这个API已经没了有可能它默认你已经装好了某个冷门第三方库可你连听都没听过。这种问题有个共同特征代码本身在作者的环境里确实是对的但它没考虑你的运行环境。应对办法很土但很有效先问AI一句“这个代码兼容Python 3.8和pandas 1.3吗”或者直接把报错信息原样发过去。很多环境问题AI看一眼就知道是不是版本造成的。另外还有一个Windows环境常见的坑也顺便提一嘴有些Python底层库是用C编译的在Windows上运行时会提示“由于找不到msvcp140.dll无法继续执行代码”。这个报错一出来很多人以为是AI代码写错了其实绝大多数情况下是机器上缺微软的VC运行库去官方渠道下载最新版Redistributable装上就好比回炉改造AI代码快得多。4. 我总结的AI写代码四步提问法附完整示例4.1 四步法其实就一句话踩完三个坑之后我重新整理了思路总结出一套提问模板。一句话概括把AI当成一个来接手你工作、但是有健忘症的实习生你得把需求文档写到它不需要追问就能直接干活的程度。再拆细一点就是四步给背景与角色你是谁、你面对的是什么项目、你用什么技术栈。给目标与样例任务是什么、输入长什么样、输出要什么格式、最好贴三五行真实样例。给约束条件只能用哪些库、兼容什么版本、不允许怎么做、性能有什么要求。给验收标准什么样的结果算“完成了”哪些边界情况必须处理。这四步不全是为了让AI更懂你有很大一部分是为了逼你自己把需求想清楚。很多时候你发现问不清楚AI其实是自己还没想明白需求。4.2 一个能直接复用的完整示例均线信号函数下面这段话是我在我的第二次尝试里实际使用的提示词。我把它原样贴出来你可以直接复制改一改就能用角色你是一位Python数据分析工程师擅长用pandas处理行情数据。 任务写一个函数 add_ma_signal(df, short_win5, long_win20)输入一个OHLCV格式的DataFrame列名必须为open、high、low、close、volume索引为日期输出在原数据基础上增加以下四列的新DataFrame - ma_short短期均线 - ma_long长期均线 - golden_cross金叉信号布尔值 - death_cross死叉信号布尔值 输入样例三行 date,open,high,low,close,volume 2024-01-01,10,11,9.5,10.5,1000 2024-01-02,10.5,12,10,11.5,1500 2024-01-03,11,11.8,10.2,10.8,1200 约束 - 只允许使用pandas不要引入numpy或第三方库 - 均线从第 long_win 行开始才有有效值NaN保留不要丢弃或填充 - 金叉定义为当日 ma_short 大于 ma_long且前一日 ma_short 小于等于 ma_long或前一日为NaN - 函数要有完整docstring不要写main调用 - 兼容pandas 1.3以上版本 验收标准 - 函数返回的DataFrame列顺序为 open,high,low,close,volume,ma_short,ma_long,golden_cross,death_cross - 金叉和死叉列只允许出现 True 或 False前 long_win 行为空值不受此限制可以填NaN这一次AI返回的代码就完全不是第一版那个“玩具代码”了。我迭代到第三版之后最终用的是下面这版import pandas as pd def add_ma_signal(df: pd.DataFrame, short_win: int 5, long_win: int 20) - pd.DataFrame: 为OHLCV行情数据添加短期/长期均线及金叉死叉信号。 参数 ---------- df : pd.DataFrame 必须包含 open/high/low/close/volume 五列索引为日期。 short_win : int, optional 短期均线窗口默认5。 long_win : int, optional 长期均线窗口默认20。 返回 ------- pd.DataFrame 新增 ma_short, ma_long, golden_cross, death_cross 四列。 result df.copy() result[ma_short] result[close].rolling(windowshort_win).mean() result[ma_long] result[close].rolling(windowlong_win).mean() diff result[ma_short] - result[ma_long] # 金叉短均线从下往上穿过长均线 result[golden_cross] (diff 0) (diff.shift(1).fillna(0) 0) # 死叉短均线从上往下穿过长均线 result[death_cross] (diff 0) (diff.shift(1).fillna(0) 0) # 均线形成之前信号列置空 valid_start long_win - 1 result.loc[: valid_start - 1, [golden_cross, death_cross]] None return result调用方式也很简单new_df add_ma_signal(df, short_win5, long_win20) new_df.to_excel(output.xlsx)这段代码不是我手写的也不是AI第一次给出的答案。它是我们俩来回改了三轮之后的产物。第一版没有处理均线未形成区域的信号置空问题金叉条件也写得不够严谨第二版把金叉方向搞反了直到第三版才真正符合我在验收标准里写的所有要求。我想特别强调“来回改了三轮”这件事。很多人用AI写代码希望一次到位但现实是一次到位更像意外迭代才是常态。你把验收标准写得越清晰AI每一次迭代就越接近正确答案而不是原地打转。4.3 当AI答错了怎么追问而不是重问用AI写代码最浪费时间的方式是看到答案不对回一句“不对重写”。这句话没有任何信息量AI只能重新顺着你的四步法再生成一遍大概率还是生成和上一版差不多的问题代码。我试出来比较好用的追问姿势是让AI先当“代码审查员”而不是“代码生成者”。具体做法分三步第一步把报错信息或异常行为完整粘贴过去不要自己转述。转述会丢信息AI看原始报错文本才能抓到真正的keyword。第二步说明“我期望的行为”和“实际发生的行为”之间的差异。比如“我期望这个函数返回带四列的信号数据但实际调用的结果是前20行golden_cross列全是False而不是NaN。”第三步请求AI“先列出至少三种可能原因不要急着改代码”。这个步骤特别有用它能逼着AI从不同角度看待问题也给了你一次低成本学习的机会。它列出的原因里经常有一个就是你从来没考虑过的。举个例子我在另一个项目里遇到过KeyError: close但我的DataFrame里明明有这个列。我把报错贴给AI让它列原因它给出了一个我之前真没想过的可能列名可能在读取Excel时被pandas加了不可见空格导致实际列名是close 。一查果然是。这个靠我肉眼排查可能得折腾一小时。5. 从对话框到IDE工具选型与日常写码工作流5.1 三种使用姿势我实测后的感受跑通第一个函数之后我开始成规模地在真实工作流里使用AI写代码。用了一个月我把AI写代码的使用方式分成三种分别体验了一遍。下表是我个人的实测结论使用姿势适合场景效率感受上手成本网页对话框快速搞定单个函数、解释报错、问概念中等来回粘贴代码有点烦最低IDE插件边写边补全、改本文件范围内的代码高上下文就在当前编辑器里低AI原生IDE跨文件重构、理解整个项目结构高但需要适应和学习中网页对话框最适合“一次性问题”。比如你只需要一个清洗函数或者在调试时想快速确认某个pandas API的用法。它的缺点也明显上下文要靠你手动粘贴长代码容易超出上下文窗口来回切换窗口很打断思路。IDE插件的好处是它直接读得到你当前文件的内容补全会自动适配你已有的变量名和代码风格。对写Python的人来说这比网页对话框顺手得多因为你不需要反复描述“前面已经定义了一个df”。AI原生IDE比如Cursor这一类则是把聊天框嵌入到整个编辑器里你可以在对话里引用具体文件、函数让AI跨多个文件去理解和修改代码。有人问我Cursor能不能像Source Insight一样跳转代码块。如果你说的是最常见的“跳到定义、查找引用、查看调用链”那用Cursor自带的Go to Definition和Find All References在Python、Go这些LSP成熟的语言上体验已经相当接近了有些场景甚至更顺。但如果是那种几十万行、靠宏定义和头文件套娃的老C/C项目它和Source Insight二十多年的索引沉淀还是有差距——AI能帮你从一个函数跳到另一个相关的函数但不代表它理解了你项目的全部历史包袱。5.2 PyCharm免费插件我的日常组合我日常主力是PyCharm所以额外尝试了一个JetBrains插件Fitten Code。这类AI插件的定位不是“替你把整个项目写完”而是“在你写代码时提供补全、解释、重构建议”。实测下来补全速度不错能根据你当前文件的上下文给出下一步的代码片段写重复性高的模板代码特别省事。选中一段代码右键发送给它说“给我解释这段逻辑”或“帮我重构得更短”它会基于当前文件内容直接回答不用我粘贴上下文。免费档对我这种中轻度用户已经够用不用一上来就开付费。我的日常流程已经固定成一套组合拳第一步把大任务拆成一个个函数粒度的小任务每个函数只做一件事。 第二步用网页对话框快速生成每个函数的初版提示词用上面说的四步法。 第三步把初版粘贴进PyCharm用Fitten Code这类插件做补全、注释和局部重构。 第四步在样例数据上跑通跑不通就把报错扔回给AI追问。 第五步跑通的版本立刻提交到码云然后才开始下一个函数。这套流程走下来我最大的感受是AI写代码不是为了“少打字”而是为了“少切换上下文”。你把一个个小函数交给AI自己专注在任务拆解和验收上效率是真的能翻倍的。5.3 关于AI Agent我暂时看到的边界用了一段时间之后我自然也会看到“AI Agent”这个概念。简单说Agent就是把“我发一句、你写一段”的对话协作升级成“我给你一个目标你自主规划步骤、调用工具、完成整个流程”。从技术趋势看Agent确实是把AI写代码推向更高层次的方向。但我在实际尝试后对它的边界也有了更实的感知现阶段让AI全自动操作整个IDE、自动跨文件改代码、自动跑测试然后自动提交风险还是偏高。它可能在某个小环节一路顺利但一旦遇到项目里那些写在文档外、全靠人脑记住的隐性约定它会非常自信地把代码“改坏”而毫无察觉。所以我现在对Agent的态度是可以拿来探索但不会把核心业务链路完全交给它自动操作。人在回路里负责定方向和做验收AI负责干活和写初稿这是我觉得目前最稳的分工。6. 代码写出来只是第一步调试、环境与版本管理6.1 把报错扔回给AI效率反而更高AI生成代码之后真正的战场才开始。有一段时间我调试时遇到报错第一反应还是自己盯着代码发呆这其实是浪费了AI最擅长的一个能力——解释报错。大模型见过的人类报错文本比绝大多数程序员一辈子见到的都多。一个Traceback扔过去它能快速指出是类型错误、空值问题、API变更还是缩进错误。关键是你要把完整的报错粘贴过去而不是只发一句“它报错了”。我常用的追问句式是这样这段代码运行时报错完整的traceback如下 粘贴报错全文 我期望达到的效果是给一个包含close列的DataFrame函数正常返回带均线和信号列的新DataFrame。 实际表现是直接抛出KeyError。 请你先帮我分析可能的原因列出至少三种不要急着给我改代码。这种“先列原因再给方案”的追问方式让AI从“一个盲目改代码的生成器”变成了“一个帮你梳理思路的同事”。有时候它列出的原因里会包含对业务逻辑的误解这时候你就可以及时纠正它而不是让它带着误解一路改下去。还有一个好用的技巧让AI生成断言。写完一个函数后我会追加一句“给我写两个断言一个测正常输入一个测窗口大于数据长度的边界情况”。AI生成的测试代码虽然不一定全面但它能帮你把最容易出错的边界条件至少覆盖到。测试通过一次代码的可信度就上一个台阶。6.2 环境问题AI代码最常见的“假报错”我第一次用AI生成的pandas代码在Windows上跑就遇到了一个经典的环境报错由于找不到msvcp140.dll无法继续执行代码是什么原因这个报错标题很长看着非常吓人但实际上跟我的代码逻辑一点关系都没有。原因很简单Windows系统上缺少微软的VC运行库而不少Python底层科学计算库是C编译的运行它们必须有这个运行库支持。处理方式也很直接去微软官网搜索VC Redistributable下载最新的x64版本安装然后重启终端再跑同样的代码通常就好了。这里提醒一句网上那些所谓的“运行库修复工具”很多都捆绑广告甚至恶意软件千万别图省事去下载。我见过不止一个人因为这个走了弯路。环境问题里还有两类高频坑也值得记录一下。一类是Python版本语法不兼容。AI训练数据里什么年代的内容都有它给你写一个match语句你本地Python还是3.8直接SyntaxError。这种时候不要自己硬改把报错扔给AI加一句“这段代码需要兼容Python 3.8”它改起来很快。另一类是pandas版本API变化。比如df.append()在pandas 1.4.0之后被移除了早期教程里的代码拿到新版本直接报AttributeError。AI写的代码有时会因为训练数据包含旧版本而踩这个坑。报错之后先问AI一句“这个API在较新版本里是不是废弃了”比自己去搜资料要快。6.3 把生成代码纳入版本管理别让AI帮你“开盲盒”版本管理这件事我觉得是“敢不敢用AI写代码”的分水岭。AI生成的代码我默认把它当成“盲盒”看待表面看着对里面可能是惊吓。如果没有版本控制AI给你改坏一个文件你连退回去都做不到只能手动CtrlZ那体验真是灾难。所以我把自己的规矩定为每跑通一个版本立刻git commit。AI在哪个方向上折腾我把它限制在分支里。实验代码开一个ai-experiment分支随便折腾折腾出能用的再合并回主分支折腾不出来直接删掉分支完全不心疼。我用的代码托管平台是码云好处是私有仓库免费国内访问速度也快。对一个普通人来说把自己的历史代码推到云端等于给自己上了份“后悔药保险”。哪怕本地硬盘突然报废重新拉一份代码就能继续。另外还有一个安全习惯必须养成不要把真实业务数据里的敏感信息发给AI不要在提示词里放账号密码、密钥、个人隐私。AI写代码的时候你把字段名、数据类型、样例值给它就够了没必要把整张真实数据表喂进去。关于红线后面我会再展开说。7. 试了一个月后我对“AI写代码”的真实评价7.1 它擅长什么不擅长什么用了一个月踩过坑也吃到甜头我给AI写代码的能力画了一条比较清晰的边界。它擅长的是这些数据处理脚本清洗、转换、合并、统计这类“输入输出明确、逻辑不复杂”的活它能写得又快又全。单元测试和断言让它给一个函数补测试它往往能覆盖到你自己会漏掉的边界。概念验证原型遇到不熟悉的技术栈先让AI生成一版能跑通的最小Demo用来理解技术路线特别有效。解释代码和改bug把一段读不懂的代码扔给它它给出的解释通常比网上的教程更贴合你的具体上下文。它不擅长的是这些依赖大量隐性业务规则的逻辑比如资金对账、交易撮合、权限控制这类“做错了就会出大事”的场景。你完全不懂的技术栈你如果连这段代码要在什么环境下跑、依赖什么协议都不清楚AI写出来你也无法判断对错这就是纯赌。安全与合规敏感的功能凡是涉及绕过机制、对抗性行为的我建议碰都不要碰。AI工具的使用条款不允许职业操守也不允许。一句话总结AI擅长的是“能把标准答案写得很漂亮”的部分不擅长的是“只有你知道正确答案”的部分。7.2 我给自己画的红线随着使用越来越熟练我给自己定了四条红线这四条红线保证我在提高效率的同时不翻车。第一条不看不懂不提交。AI生成的代码我必须能逐行解释清楚。如果它用了某个我不理解的API或技巧我先让它解释或者自己去查文档绝不直接“相信”。这条红线帮我避免了很多隐蔽的逻辑错误。第二条不直接用于生产环境的现金链路。AI代码可以用于数据处理、原型验证、测试脚本但凡是直接跟真实金钱、真实用户信息相关的功能必须经过人工审查和完整的测试流程再上。AI能帮你写初稿但背锅的一定是你。第三条不给AI喂敏感数据。前面对话里只给字段结构、样例数据、非敏感的值。需要真实数据验证时脱敏之后再发。第四条不利用AI写恶意内容。不管是什么样的技术热情底线都是要用在正道上。靠AI提升生产力是一件很酷的事但把它用在绕过规则、攻击系统上既是对工具的滥用也是在给自己挖坑。7.3 接下来我打算怎么用这个组合这次“尝试1号”跑通之后我已经把“四步提问法IDE插件版本管理”这套组合复制到了更多场景。除了写数据处理代码我还用它来快速生成技术文档、写测试数据构造器甚至整理需求清单和专利交底书的初稿结构。AI辅助的不只是“写代码”这一件事而是整个研发环节里所有“从零到一”的草稿工作。接下来我准备再开一个“尝试2号”让AI在更复杂的项目里做跨文件重构看看它怎么处理多模块之间的依赖关系。也打算更认真地研究一下Agent方向比如让AI结合命令行工具做一些多步骤的验证操作。不过就像前面说的核心业务链路上我依然保留“人在回路”这一道闸门。最后说一句掏心窝的话AI写代码这事儿与其纠结“它会不会取代程序员”不如先想清楚“它最难替代的是什么”。我试下来的最大感受是它替代的不是思考而是重复。真正值钱的还是你脑子里那个“要做什么、怎么算对”的业务判断。把这些判断讲清楚AI就能帮你把剩下的活干得飞快讲不清楚它只会用非常标准的错误答案来非常礼貌地敷衍你。 
长河君 · 2026/10/28 7:24:47 · 阅读 1.2k AI辅助写代码实战复盘：从翻车到沉淀出四步提问法
坦白说在这件事之前我对“AI写代码”的态度一直是“看看热闹可以真把工作交出去免谈”。直到上个月接到一个浑身都是重复劳动的活把七八个字段对不齐的Excel表清洗成统一格式再给每组行情数据算好均线和金叉死叉信号两天内要交。这活不难但脏每一行代码都写得出每一行都不想来第二遍。于是我决定认认真真试一次AI辅助写代码并且给自己定下原则所有AI生成的代码我必须逐行看懂、跑通、再提交。这篇文章就是这次“尝试1号”的完整复盘记录了我怎么提问、怎么翻车、怎么补救最后还沉淀出一套适合普通开发者的提问套路和工具组合。如果你和我一样有Python基础但不想被重复劳动耗死这篇文章至少能帮你少走两天的弯路。1. 这次需求很小但AI写代码的尝试机会正好1.1 需求拆分一句话能说清的活写起来却要半天先把需求说清楚大家才能理解我为什么说它“脏”。一句话版把多个Excel文件里的行情数据统一成同一种格式然后计算双均线信号输出一份汇总Excel。拆开之后就有点烦人了每个Excel文件的列名都不一样有的叫date有的叫日期价格列有的叫close有的叫收盘价。日期格式不统一有“2024-01-01”这种标准格式也有“20240101”这种无分隔符格式。部分文件里有缺失值有的还带表头注释直接pd.read_excel读进来根本没法用。最终交付物不是一屏终端输出而是一份规范化的新Excel要有文件名、统一日期、统一列名、均线值、金叉死叉标记。我粗算了一下纯手工写这套脚本至少要三个小时。这三个小时不是“不会写”而是“写的时候一直在查pandas文档、试错、处理边界情况”。这种情况恰恰是AI工具最擅长插一脚的地方——模板逻辑多、业务规则少、主要靠经验堆。1.2 给自己定的三条实验规则我决定试AI但不想被它带沟里。所以在开始之前我给自己定了三条硬性规则后来事实证明这三条规则帮我避免了不少灾难。第一条AI生成的代码必须逐行审查看不懂的不用。AI给你一段“看起来合理”的代码很容易但“看起来合理”和“实际正确”是两回事。我不能接受一段我无法解释的代码出现在交付里。第二条必须先在样例数据上跑通再放到全部数据上跑。让我直接对全部真实文件执行AI生成的代码心理负担太大。先拿两个文件试跑能跑通再放开。第三条每一版能跑的代码立刻提交到码云。这个习惯后面会细讲简单说就是版本控制是让AI写代码变得可逆、可控的前提。三条规则定完我打开了聊天框开始了第一次尝试。2. 第一次提问有多天真AI给了我“能跑但不能用”的代码2.1 原封不动的提问长什么样我现在把第一次提问原文贴出来大家别笑帮我用Python写一个计算移动平均线的代码没了真就这一句。我没说数据是什么格式没说文件在哪没说读Excel还是CSV没说输出什么没说金叉死叉怎么算什么都没说。我当时的心态是AI不是号称很能写代码吗我把需求说个大概它应该能“意会”吧。结果证明这个“大概”害死人。2.2 它生成的代码和我的“差评”AI当时返回的代码去掉各种解释之后核心长这样import pandas as pd df pd.read_csv(data.csv) df[ma5] df[close].rolling(window5).mean() df[ma20] df[close].rolling(window20).mean() print(df)我盯着这段代码看了二十秒然后沉默了。它确实“写对了”——移动平均线的核心逻辑rolling(window5).mean()就是标准答案。但它对我这次的实际任务几乎没有任何帮助。我的数据是Excel文件列名不是英文而是中文日期格式乱得一批我要的不是打印而是输出一个新Excel我要的不只是均线还有金叉死叉标记我还得保留文件名维度方便后续核对。我如果不改这段代码跑在我数据上第一步就会因为找不到close列直接报错。就算我手动改列名它也解决不了日期统一和输出格式的问题。最后我统计了一下它给出的代码里只有rolling和mean两个词被我留在了终稿里。2.3 差点放弃之前我换了一个类比当时我差不多想放弃了心里想的是“AI写代码就是个噱头还是我自己来吧”。但冷静下来之后我换了个角度想问题如果团队里新来了一个实习生我让他做这个活他只跟我说“帮我写个计算移动平均线的代码”我能满意吗当然不会。我会告诉他数据在哪、列名是什么、输出长什么样、什么时候该算金叉。AI和这个实习生没有本质区别——它是一个知识量巨大、但对我这次任务一无所知的“新同事”。问题不在AI在我给的上下文太少了。想通这一点我决定不放弃而是换一种提问方式重新来一遍。这一遍就有了后面那些“能直接用”的代码。3. 翻车现场解析大模型写代码的底层逻辑和我踩中的三个坑3.1 大模型是怎么“写”出代码的在讲我的“四步提问法”之前我觉得有必要先花一点篇幅讲清楚大模型写代码的底层逻辑。理解了这个你就知道为什么有些AI代码看起来那么“对”用起来那么“废”。大模型写代码本质上是在做“下一段文本的接龙”。它的底层结构是Transformer靠自注意力机制去衡量你输入文本里每一个词和其他词之间的关系。训练阶段它看过GitHub等公开仓库里海量代码学到的是统计规律出现df之后后面跟着.rolling的概率很高.rolling(后面跟着window的概率很高再往后mean()出现的概率也很高。于是当你把问题发过去它生成的内容其实是它认为“接下来最合理的延续”而不是从某个知识库里“检索”出来的现成答案。这里有两个关键概念会影响你后续的使用体验上下文窗口和温度参数。上下文窗口就是模型一次能“看到”的文本量。窗口内能塞进去的信息越多它接龙的条件就越明确。如果你的问题只有一句话它就只能凭训练数据里最常见的情况去续写写出来就是一篇标准答案而不是针对你数据的定制方案。温度参数则控制生成结果的随机性。写代码这种事需要的是确定性和稳定所以温度调低一点更好让AI尽量输出概率最高的答案而不是发挥“创意”。明白了这一点你再看第一次翻车就会非常清楚我的问题描述太短等于给了一个极窄的“接龙条件”AI能写对rolling已经算它及格了。3.2 坑一把AI当搜索引擎用第一个坑也是最普遍的坑把AI当成搜索引擎用。搜索引擎的逻辑是你输入关键词它从亿万个网页里挑现成答案给你。大模型的逻辑是你输入一段话它根据这段话生成一段新的话。这两种逻辑看起来都是“我问你答”但本质完全不同。搜索引擎适合查“移动平均线的公式是什么”AI适合回答“根据我这批数据的列名和缺失情况帮我写一段能算移动平均线的代码”。如果你让AI写代码却不给它和你任务相关的任何细节它就只能假装自己是搜索引擎给你一段教科书式的示例。我后来把这个问题想明白了AI写代码的输入是一份“需求上下文”而不是一串关键词。上下文越接近你真实的工作环境出来的代码越接近能直接跑的版本。3.3 坑二没给它验收标准第二个坑是我没给出“什么叫做完”的判断标准。人跟人协作说一句“帮我做个统计报表”对方会基于经验脑补出报表的字段、格式、口径。但AI没有和我共同工作的历史它脑补出来的“统计报表”和我脑子里的“统计报表”大概率不是同一个东西。拿我这个需求为例我脑子里其实装着一份很具体的验收清单列顺序必须是open、high、low、close、volume日期格式必须统一成YYYY-MM-DD均线在数据不足窗口长度时保留NaN金叉死叉输出布尔值最终数据必须写回Excel且带上文件名来源。这些标准在我脑子里但我一句都没告诉AI。它当然不知道于是就把自己理解的“输出”定义成了print(df)。这不是AI偷懒是它没有默认值可猜。所以说验收标准不是可选项而是写代码提示词的必填项。3.4 坑三忽略了运行环境和库版本第三个坑是运行环境和第三方库版本。AI训练数据里什么年代的代码都有有可能给你一段依赖Python 3.10新语法match的代码而你的环境还是Python 3.8有可能它给你一个df.append()而在pandas 1.4以后这个API已经没了有可能它默认你已经装好了某个冷门第三方库可你连听都没听过。这种问题有个共同特征代码本身在作者的环境里确实是对的但它没考虑你的运行环境。应对办法很土但很有效先问AI一句“这个代码兼容Python 3.8和pandas 1.3吗”或者直接把报错信息原样发过去。很多环境问题AI看一眼就知道是不是版本造成的。另外还有一个Windows环境常见的坑也顺便提一嘴有些Python底层库是用C编译的在Windows上运行时会提示“由于找不到msvcp140.dll无法继续执行代码”。这个报错一出来很多人以为是AI代码写错了其实绝大多数情况下是机器上缺微软的VC运行库去官方渠道下载最新版Redistributable装上就好比回炉改造AI代码快得多。4. 我总结的AI写代码四步提问法附完整示例4.1 四步法其实就一句话踩完三个坑之后我重新整理了思路总结出一套提问模板。一句话概括把AI当成一个来接手你工作、但是有健忘症的实习生你得把需求文档写到它不需要追问就能直接干活的程度。再拆细一点就是四步给背景与角色你是谁、你面对的是什么项目、你用什么技术栈。给目标与样例任务是什么、输入长什么样、输出要什么格式、最好贴三五行真实样例。给约束条件只能用哪些库、兼容什么版本、不允许怎么做、性能有什么要求。给验收标准什么样的结果算“完成了”哪些边界情况必须处理。这四步不全是为了让AI更懂你有很大一部分是为了逼你自己把需求想清楚。很多时候你发现问不清楚AI其实是自己还没想明白需求。4.2 一个能直接复用的完整示例均线信号函数下面这段话是我在我的第二次尝试里实际使用的提示词。我把它原样贴出来你可以直接复制改一改就能用角色你是一位Python数据分析工程师擅长用pandas处理行情数据。 任务写一个函数 add_ma_signal(df, short_win5, long_win20)输入一个OHLCV格式的DataFrame列名必须为open、high、low、close、volume索引为日期输出在原数据基础上增加以下四列的新DataFrame - ma_short短期均线 - ma_long长期均线 - golden_cross金叉信号布尔值 - death_cross死叉信号布尔值 输入样例三行 date,open,high,low,close,volume 2024-01-01,10,11,9.5,10.5,1000 2024-01-02,10.5,12,10,11.5,1500 2024-01-03,11,11.8,10.2,10.8,1200 约束 - 只允许使用pandas不要引入numpy或第三方库 - 均线从第 long_win 行开始才有有效值NaN保留不要丢弃或填充 - 金叉定义为当日 ma_short 大于 ma_long且前一日 ma_short 小于等于 ma_long或前一日为NaN - 函数要有完整docstring不要写main调用 - 兼容pandas 1.3以上版本 验收标准 - 函数返回的DataFrame列顺序为 open,high,low,close,volume,ma_short,ma_long,golden_cross,death_cross - 金叉和死叉列只允许出现 True 或 False前 long_win 行为空值不受此限制可以填NaN这一次AI返回的代码就完全不是第一版那个“玩具代码”了。我迭代到第三版之后最终用的是下面这版import pandas as pd def add_ma_signal(df: pd.DataFrame, short_win: int 5, long_win: int 20) - pd.DataFrame: 为OHLCV行情数据添加短期/长期均线及金叉死叉信号。 参数 ---------- df : pd.DataFrame 必须包含 open/high/low/close/volume 五列索引为日期。 short_win : int, optional 短期均线窗口默认5。 long_win : int, optional 长期均线窗口默认20。 返回 ------- pd.DataFrame 新增 ma_short, ma_long, golden_cross, death_cross 四列。 result df.copy() result[ma_short] result[close].rolling(windowshort_win).mean() result[ma_long] result[close].rolling(windowlong_win).mean() diff result[ma_short] - result[ma_long] # 金叉短均线从下往上穿过长均线 result[golden_cross] (diff 0) (diff.shift(1).fillna(0) 0) # 死叉短均线从上往下穿过长均线 result[death_cross] (diff 0) (diff.shift(1).fillna(0) 0) # 均线形成之前信号列置空 valid_start long_win - 1 result.loc[: valid_start - 1, [golden_cross, death_cross]] None return result调用方式也很简单new_df add_ma_signal(df, short_win5, long_win20) new_df.to_excel(output.xlsx)这段代码不是我手写的也不是AI第一次给出的答案。它是我们俩来回改了三轮之后的产物。第一版没有处理均线未形成区域的信号置空问题金叉条件也写得不够严谨第二版把金叉方向搞反了直到第三版才真正符合我在验收标准里写的所有要求。我想特别强调“来回改了三轮”这件事。很多人用AI写代码希望一次到位但现实是一次到位更像意外迭代才是常态。你把验收标准写得越清晰AI每一次迭代就越接近正确答案而不是原地打转。4.3 当AI答错了怎么追问而不是重问用AI写代码最浪费时间的方式是看到答案不对回一句“不对重写”。这句话没有任何信息量AI只能重新顺着你的四步法再生成一遍大概率还是生成和上一版差不多的问题代码。我试出来比较好用的追问姿势是让AI先当“代码审查员”而不是“代码生成者”。具体做法分三步第一步把报错信息或异常行为完整粘贴过去不要自己转述。转述会丢信息AI看原始报错文本才能抓到真正的keyword。第二步说明“我期望的行为”和“实际发生的行为”之间的差异。比如“我期望这个函数返回带四列的信号数据但实际调用的结果是前20行golden_cross列全是False而不是NaN。”第三步请求AI“先列出至少三种可能原因不要急着改代码”。这个步骤特别有用它能逼着AI从不同角度看待问题也给了你一次低成本学习的机会。它列出的原因里经常有一个就是你从来没考虑过的。举个例子我在另一个项目里遇到过KeyError: close但我的DataFrame里明明有这个列。我把报错贴给AI让它列原因它给出了一个我之前真没想过的可能列名可能在读取Excel时被pandas加了不可见空格导致实际列名是close 。一查果然是。这个靠我肉眼排查可能得折腾一小时。5. 从对话框到IDE工具选型与日常写码工作流5.1 三种使用姿势我实测后的感受跑通第一个函数之后我开始成规模地在真实工作流里使用AI写代码。用了一个月我把AI写代码的使用方式分成三种分别体验了一遍。下表是我个人的实测结论使用姿势适合场景效率感受上手成本网页对话框快速搞定单个函数、解释报错、问概念中等来回粘贴代码有点烦最低IDE插件边写边补全、改本文件范围内的代码高上下文就在当前编辑器里低AI原生IDE跨文件重构、理解整个项目结构高但需要适应和学习中网页对话框最适合“一次性问题”。比如你只需要一个清洗函数或者在调试时想快速确认某个pandas API的用法。它的缺点也明显上下文要靠你手动粘贴长代码容易超出上下文窗口来回切换窗口很打断思路。IDE插件的好处是它直接读得到你当前文件的内容补全会自动适配你已有的变量名和代码风格。对写Python的人来说这比网页对话框顺手得多因为你不需要反复描述“前面已经定义了一个df”。AI原生IDE比如Cursor这一类则是把聊天框嵌入到整个编辑器里你可以在对话里引用具体文件、函数让AI跨多个文件去理解和修改代码。有人问我Cursor能不能像Source Insight一样跳转代码块。如果你说的是最常见的“跳到定义、查找引用、查看调用链”那用Cursor自带的Go to Definition和Find All References在Python、Go这些LSP成熟的语言上体验已经相当接近了有些场景甚至更顺。但如果是那种几十万行、靠宏定义和头文件套娃的老C/C项目它和Source Insight二十多年的索引沉淀还是有差距——AI能帮你从一个函数跳到另一个相关的函数但不代表它理解了你项目的全部历史包袱。5.2 PyCharm免费插件我的日常组合我日常主力是PyCharm所以额外尝试了一个JetBrains插件Fitten Code。这类AI插件的定位不是“替你把整个项目写完”而是“在你写代码时提供补全、解释、重构建议”。实测下来补全速度不错能根据你当前文件的上下文给出下一步的代码片段写重复性高的模板代码特别省事。选中一段代码右键发送给它说“给我解释这段逻辑”或“帮我重构得更短”它会基于当前文件内容直接回答不用我粘贴上下文。免费档对我这种中轻度用户已经够用不用一上来就开付费。我的日常流程已经固定成一套组合拳第一步把大任务拆成一个个函数粒度的小任务每个函数只做一件事。 第二步用网页对话框快速生成每个函数的初版提示词用上面说的四步法。 第三步把初版粘贴进PyCharm用Fitten Code这类插件做补全、注释和局部重构。 第四步在样例数据上跑通跑不通就把报错扔回给AI追问。 第五步跑通的版本立刻提交到码云然后才开始下一个函数。这套流程走下来我最大的感受是AI写代码不是为了“少打字”而是为了“少切换上下文”。你把一个个小函数交给AI自己专注在任务拆解和验收上效率是真的能翻倍的。5.3 关于AI Agent我暂时看到的边界用了一段时间之后我自然也会看到“AI Agent”这个概念。简单说Agent就是把“我发一句、你写一段”的对话协作升级成“我给你一个目标你自主规划步骤、调用工具、完成整个流程”。从技术趋势看Agent确实是把AI写代码推向更高层次的方向。但我在实际尝试后对它的边界也有了更实的感知现阶段让AI全自动操作整个IDE、自动跨文件改代码、自动跑测试然后自动提交风险还是偏高。它可能在某个小环节一路顺利但一旦遇到项目里那些写在文档外、全靠人脑记住的隐性约定它会非常自信地把代码“改坏”而毫无察觉。所以我现在对Agent的态度是可以拿来探索但不会把核心业务链路完全交给它自动操作。人在回路里负责定方向和做验收AI负责干活和写初稿这是我觉得目前最稳的分工。6. 代码写出来只是第一步调试、环境与版本管理6.1 把报错扔回给AI效率反而更高AI生成代码之后真正的战场才开始。有一段时间我调试时遇到报错第一反应还是自己盯着代码发呆这其实是浪费了AI最擅长的一个能力——解释报错。大模型见过的人类报错文本比绝大多数程序员一辈子见到的都多。一个Traceback扔过去它能快速指出是类型错误、空值问题、API变更还是缩进错误。关键是你要把完整的报错粘贴过去而不是只发一句“它报错了”。我常用的追问句式是这样这段代码运行时报错完整的traceback如下 粘贴报错全文 我期望达到的效果是给一个包含close列的DataFrame函数正常返回带均线和信号列的新DataFrame。 实际表现是直接抛出KeyError。 请你先帮我分析可能的原因列出至少三种不要急着给我改代码。这种“先列原因再给方案”的追问方式让AI从“一个盲目改代码的生成器”变成了“一个帮你梳理思路的同事”。有时候它列出的原因里会包含对业务逻辑的误解这时候你就可以及时纠正它而不是让它带着误解一路改下去。还有一个好用的技巧让AI生成断言。写完一个函数后我会追加一句“给我写两个断言一个测正常输入一个测窗口大于数据长度的边界情况”。AI生成的测试代码虽然不一定全面但它能帮你把最容易出错的边界条件至少覆盖到。测试通过一次代码的可信度就上一个台阶。6.2 环境问题AI代码最常见的“假报错”我第一次用AI生成的pandas代码在Windows上跑就遇到了一个经典的环境报错由于找不到msvcp140.dll无法继续执行代码是什么原因这个报错标题很长看着非常吓人但实际上跟我的代码逻辑一点关系都没有。原因很简单Windows系统上缺少微软的VC运行库而不少Python底层科学计算库是C编译的运行它们必须有这个运行库支持。处理方式也很直接去微软官网搜索VC Redistributable下载最新的x64版本安装然后重启终端再跑同样的代码通常就好了。这里提醒一句网上那些所谓的“运行库修复工具”很多都捆绑广告甚至恶意软件千万别图省事去下载。我见过不止一个人因为这个走了弯路。环境问题里还有两类高频坑也值得记录一下。一类是Python版本语法不兼容。AI训练数据里什么年代的内容都有它给你写一个match语句你本地Python还是3.8直接SyntaxError。这种时候不要自己硬改把报错扔给AI加一句“这段代码需要兼容Python 3.8”它改起来很快。另一类是pandas版本API变化。比如df.append()在pandas 1.4.0之后被移除了早期教程里的代码拿到新版本直接报AttributeError。AI写的代码有时会因为训练数据包含旧版本而踩这个坑。报错之后先问AI一句“这个API在较新版本里是不是废弃了”比自己去搜资料要快。6.3 把生成代码纳入版本管理别让AI帮你“开盲盒”版本管理这件事我觉得是“敢不敢用AI写代码”的分水岭。AI生成的代码我默认把它当成“盲盒”看待表面看着对里面可能是惊吓。如果没有版本控制AI给你改坏一个文件你连退回去都做不到只能手动CtrlZ那体验真是灾难。所以我把自己的规矩定为每跑通一个版本立刻git commit。AI在哪个方向上折腾我把它限制在分支里。实验代码开一个ai-experiment分支随便折腾折腾出能用的再合并回主分支折腾不出来直接删掉分支完全不心疼。我用的代码托管平台是码云好处是私有仓库免费国内访问速度也快。对一个普通人来说把自己的历史代码推到云端等于给自己上了份“后悔药保险”。哪怕本地硬盘突然报废重新拉一份代码就能继续。另外还有一个安全习惯必须养成不要把真实业务数据里的敏感信息发给AI不要在提示词里放账号密码、密钥、个人隐私。AI写代码的时候你把字段名、数据类型、样例值给它就够了没必要把整张真实数据表喂进去。关于红线后面我会再展开说。7. 试了一个月后我对“AI写代码”的真实评价7.1 它擅长什么不擅长什么用了一个月踩过坑也吃到甜头我给AI写代码的能力画了一条比较清晰的边界。它擅长的是这些数据处理脚本清洗、转换、合并、统计这类“输入输出明确、逻辑不复杂”的活它能写得又快又全。单元测试和断言让它给一个函数补测试它往往能覆盖到你自己会漏掉的边界。概念验证原型遇到不熟悉的技术栈先让AI生成一版能跑通的最小Demo用来理解技术路线特别有效。解释代码和改bug把一段读不懂的代码扔给它它给出的解释通常比网上的教程更贴合你的具体上下文。它不擅长的是这些依赖大量隐性业务规则的逻辑比如资金对账、交易撮合、权限控制这类“做错了就会出大事”的场景。你完全不懂的技术栈你如果连这段代码要在什么环境下跑、依赖什么协议都不清楚AI写出来你也无法判断对错这就是纯赌。安全与合规敏感的功能凡是涉及绕过机制、对抗性行为的我建议碰都不要碰。AI工具的使用条款不允许职业操守也不允许。一句话总结AI擅长的是“能把标准答案写得很漂亮”的部分不擅长的是“只有你知道正确答案”的部分。7.2 我给自己画的红线随着使用越来越熟练我给自己定了四条红线这四条红线保证我在提高效率的同时不翻车。第一条不看不懂不提交。AI生成的代码我必须能逐行解释清楚。如果它用了某个我不理解的API或技巧我先让它解释或者自己去查文档绝不直接“相信”。这条红线帮我避免了很多隐蔽的逻辑错误。第二条不直接用于生产环境的现金链路。AI代码可以用于数据处理、原型验证、测试脚本但凡是直接跟真实金钱、真实用户信息相关的功能必须经过人工审查和完整的测试流程再上。AI能帮你写初稿但背锅的一定是你。第三条不给AI喂敏感数据。前面对话里只给字段结构、样例数据、非敏感的值。需要真实数据验证时脱敏之后再发。第四条不利用AI写恶意内容。不管是什么样的技术热情底线都是要用在正道上。靠AI提升生产力是一件很酷的事但把它用在绕过规则、攻击系统上既是对工具的滥用也是在给自己挖坑。7.3 接下来我打算怎么用这个组合这次“尝试1号”跑通之后我已经把“四步提问法IDE插件版本管理”这套组合复制到了更多场景。除了写数据处理代码我还用它来快速生成技术文档、写测试数据构造器甚至整理需求清单和专利交底书的初稿结构。AI辅助的不只是“写代码”这一件事而是整个研发环节里所有“从零到一”的草稿工作。接下来我准备再开一个“尝试2号”让AI在更复杂的项目里做跨文件重构看看它怎么处理多模块之间的依赖关系。也打算更认真地研究一下Agent方向比如让AI结合命令行工具做一些多步骤的验证操作。不过就像前面说的核心业务链路上我依然保留“人在回路”这一道闸门。最后说一句掏心窝的话AI写代码这事儿与其纠结“它会不会取代程序员”不如先想清楚“它最难替代的是什么”。我试下来的最大感受是它替代的不是思考而是重复。真正值钱的还是你脑子里那个“要做什么、怎么算对”的业务判断。把这些判断讲清楚AI就能帮你把剩下的活干得飞快讲不清楚它只会用非常标准的错误答案来非常礼貌地敷衍你。