很多教程教你怎么「一句话让 AI 写代码」，但真实项目里，一句话得到的往往是跑不起来的玩具。阿文带团队用 DeepSeek 写过不少脚本和小型服务，踩坑之后总结出一套 五轮对话法：不是一轮梭哈，而是像和同事结对编程那样，一轮一轮把需求压实、把代码跑通、把坑填平。
下面以「写一个从 CSV 读数据、按条件过滤、导出 Excel 的 Python 脚本」为主线，演示每一轮该问什么、怎么让它自测、什么时候重构。最后再补一个 SQL 例子，证明这套方法能跨语言复用。
第一轮：需求澄清与范围界定
不要一上来就喊「帮我写个脚本」。先让模型帮你把需求想清楚，这一步能避免后面返工。新手最大的浪费，就是需求没想清就生成，生成完发现理解错了，全删重写。
你该问的：
我要处理一批销售 CSV，按「地区=华东 且 金额>1000」过滤，导出成 Excel。帮我列出实现前需要确认的点，以及推荐的技术栈。
为什么要这么做： 让模型反向向你提问，能逼出你忽略的边界——比如编码格式（UTF-8 还是 GBK）、缺失值怎么处理、表头是否固定、是否要保留原格式、金额列会不会带货币符号。DeepSeek 通常会列出：用 pandas 还是纯 csv 模块、Excel 用 openpyxl 还是 xlsxwriter、大文件要不要分块读取。
这一轮的输出标准： 你拿到一份「需求清单 + 技术选型」，并且对每一项的取舍做了决定。没决定就别进下一轮。阿文的经验是，第一轮多花五分钟，能省后面半小时返工。
第二轮：生成初版实现
澄清完再生成，代码质量立马上一个台阶。模糊需求喂出来的代码，十有八九要返工。
你该问的：
按上面确认的方案（pandas + openpyxl），写第一版脚本。要求：函数化、带命令行参数（输入路径、输出路径、地区、阈值）、有基础注释。先不要写测试。
节奏要点：
- 一次只给一个明确目标，别在这一轮塞进「顺便做个 GUI」「再加个邮件发送」。范围一散，代码就乱。
- 让它「先不写测试」是有意的——先把主路径跑出来，测试留到第三轮，避免早期接口还在变就绑死测试，改一次接口要改一堆测试。
- 拿到代码后，先肉眼扫一遍结构：入口函数、参数解析、核心逻辑、异常处理是否分层清晰。结构乱的代码，后面重构成本极高。
第三轮：让它自测
这是最容易被跳过、却最关键的一步。阿文的习惯是逼模型自己造数据和测试，而不是你手动测。
你该问的：
现在请为上面的脚本写测试。步骤：1）生成一份 10 行的样例 CSV（含正常数据、缺失值、非华东地区各几条）；2）用 pytest 写 3 个用例，覆盖正常过滤、阈值边界、空文件；3）给出运行命令并预测预期输出。
为什么有效： 让模型造样例数据，等于逼它把「自己代码期待什么输入」显式化。如果它造的数据结构和代码对不上，马上就会暴露。你拿到测试后本地跑一遍：
pip install pytest pandas openpyxl
pytest test_script.py -v如果测试红了，把报错贴回去让它修，比你自己猜快得多。
自测的进阶玩法——让模型当审查员：
假设你是严格的高级工程师，review 上面这份代码，只挑真问题：潜在 bug、边界遗漏、安全隐患（比如路径注入、eval 滥用）。不要夸它。
这种「角色翻转」能挖出第二轮埋下的雷，比如没处理文件不存在、没关文件句柄、用了危险写法。一个严格 reviewer 角色，往往比泛泛的「检查一下」更有用。
第四轮：重构与边界处理
初版能跑 ≠ 能用于生产。这一轮专门补健壮性，把玩具变成工具。
你该问的：
请重构，重点加这几块：1）输入文件不存在/不是 CSV 时给出清晰报错；2）金额列可能含「¥」符号或空值，要做清洗；3）导出时保留原 CSV 的列顺序；4）加一个
--dry-run参数只打印会导出几行。
重构节奏建议：
- 一次聚焦 2–4 个改进点，别一次性甩 10 个需求，容易改崩且难以定位哪次改动引入了问题。
- 每次重构后重跑第三轮的测试，确保没回归。回归测试是重构的安全网。
- 让模型解释「为什么这么改」，能帮你判断是否真有必要。有些「优化」只是花活，生产里反而增加复杂度。
常见误区：把重构当成加功能。重构的目标是「行为不变、结构更好」，不是顺手加需求。新功能请单独开一轮，否则你分不清是新功能带来的 bug 还是重构带来的。
第五轮：修 bug 与收尾
真机上跑，总会遇到测试覆盖不到的怪事。这一轮收尾，让代码真正能交付。
你该问的（贴报错）：
真实数据跑报这个错：
ValueError: could not convert string to float: '1,200'。帮我定位原因并修复，同时更新测试用例覆盖「千分位逗号」这个场景。
修 bug 的纪律：
- 贴完整报错和复现步骤，别只说「不行」。信息越全，修得越准。
- 让模型先给「根因分析」再给修复，根因错了修也白修。
- 修完要求它「补一个能复现该 bug 的测试」，防止复发。测试是 bug 的墓碑。
- 最后让它写一段使用说明（README 片段），把运行环境和命令固化下来，方便同事接手。
跨语言验证：SQL 例子
同样的方法用在写 SQL 上也成立。第一轮让它确认表结构和筛选逻辑，第二轮出查询，第三轮造样例数据验证，第四轮加索引和边界（NULL 处理），第五轮调性能。你会发现，五轮法的本质不是「写代码」，而是「用对话把模糊意图逐步收敛成可执行、可验证的规格」。
当模型固执己见或走偏怎么办
五轮法不是每次都顺。阿文遇到最多的两种卡点：一是模型坚持一个错误实现不肯改；二是它改着改着把之前对的也改坏了。处理不好，对话会越聊越乱，最后只得重开。
应对固执： 别和它空口争论，直接给它「证据」。把运行报错、测试用例的失败输出贴回去，说「你上一版在第 X 行报了这个错，请用不同思路重做」。用事实代替指令，模型比被命令更容易服从。如果它还嘴硬，换一种表述重述需求，或者明确要求「不要用你刚才的方案，改用 X 方法」，把路指死。
应对越改越坏： 这是重构轮最常见的。解决办法是小步提交——每改一个点就跑一次测试，发现回归立刻回退到上一轮版本。阿文的习惯是每轮结束让模型用 git 提交一个节点，真改崩了 git checkout 一下就回来了。把版本控制用起来，对话式编程才敢大胆试错，不然一次手滑全盘皆输。
应对过度工程： 有时模型会自作主张加一堆用不上的抽象、设计模式、配置文件，代码反而难读难维护。这时候要明确说「不要引入额外抽象，保持最直白的写法」，把克制也写进需求里。你让它「写得专业点」，它可能就给你整出一套用不上的工厂模式，徒增复杂度。
给模型的反馈要具体。 「不太好」这种评价模型没法用，要说「第三步的异常处理没覆盖文件被占用的情况」。反馈越具体，下一轮修正越准。把模型当成需要清晰需求的 junior，它才会表现得像 senior。
怎么算跑通了： 你拿到的最终代码能在本机直接跑、测试全绿、边界有处理、还有一份能交给同事的说明。这五条里缺一条，就还没真正完成，别急着收工。很多「差不多能跑」的代码，一上线就出事，差的正是这几步的较真。
五轮节奏一览
| 轮次 | 核心目标 | 关键动作 | 验收标准 |
|---|---|---|---|
| 1 需求 | 界定范围 | 反向提问、定技术栈 | 需求清单 + 选型 |
| 2 初版 | 跑通主路径 | 单目标生成、先不测试 | 结构清晰可运行 |
| 3 自测 | 暴露问题 | 造数据 + 写测试 + 角色翻转 review | 测试通过 |
| 4 重构 | 补健壮性 | 边界/异常/参数，小步改 | 测试仍通过 |
| 5 修 bug | 收尾固化 | 贴报错、补测试、写说明 | bug 修复且防复发 |
三个让成功率翻倍的习惯
第一，把上下文当资产。 五轮对话是连续的，别每轮开新窗口。DeepSeek 在多轮里能记住你前面的决定，中断重来反而丢信息。一个会话从头跑到尾，模型才知道你第二轮定的技术栈、第三轮加的约束。
第二，给代码贴「版本标签」。 每轮结束让模型用注释标一句 # v2: 加了异常处理，你回看时能快速定位哪轮引入了什么，回滚也方便。
第三，复杂任务拆子模块。 一个 500 行的单文件，不如让模型先画模块划分，再逐模块生成。一次生成太长，出错概率和修复成本都飙升。分而治之是工程常识，对话式编程也一样。
什么时候不该用五轮法
五轮法适合 50 行以上的、要长期维护的代码。如果是「就这一次要段正则」「临时处理一个 JSON」「改个错别字」，一轮搞定更划算。别为了方法论而方法论，判断标准是「这段代码值得被认真对待吗」。
给新手的三个心法
最后阿文送三句话，算是把五轮法的精神再压一遍。其一，先想清楚再生成，模糊需求养不出好代码，第一轮的需求澄清省不得；其二，让模型在自己眼前跑测试，比你自己猜 bug 快十倍，第三轮的自测是性价比最高的一步；其三，小步快跑、随时回退，对话式编程最怕一把梭、改崩了没法回头。把这三点刻进习惯，五轮对话法就真正成了你的肌肉记忆，而不是纸上的流程。
回到开头那句话：DeepSeek 写代码强，但强在「配合会提需求的你」。把需求压实、让它在你眼前自测、小步重构、贴报错修 bug——这套节奏跑顺了，你得到的不是一段一次性代码，而是一个经得起真机检验的小工具。方法不复杂，难的是每次都老老实实走完五轮，而不是图省事一轮梭哈。