坦白说，在这件事之前，我对“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(window=5).mean() df["ma20"] = df["close"].rolling(window=20).mean() print(df)我盯着这段代码看了二十秒，然后沉默了。它确实“写对了”——移动平均线的核心逻辑rolling(window=5).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_win=5, long_win=20)，输入一个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(window=short_win).mean() result["ma_long"] = result["close"].rolling(window=long_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_win=5, long_win=20) 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给你改坏一个文件，你连退回去都做不到，只能手动Ctrl+Z，那体验真是灾难。
所以我把自己的规矩定为：每跑通一个版本，立刻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就能帮你把剩下的活干得飞快；讲不清楚，它只会用非常标准的错误答案，来非常礼貌地敷衍你。
