AI 工具入门：把大模型当结对搭档，而不是答案机器

先说一个常见误区

刚开始用大模型写代码的人，常把它当成搜索引擎的高级版：贴一段报错，等一个现成答案，复制回来能跑就过关。这样用几次就会发现两个问题：一是答案看着能跑，换个数据就出问题；二是自己越用越不会写，离开工具反而手生。问题不在工具，而在用法：大模型最适合的角色不是答案机器，而是一个随时在场的结对搭档——你负责判断，它负责帮你把想法快速变成可验证的东西。

习惯一：先说清楚你要什么，再让它写

模糊的提问只能得到模糊的答案。同样是“帮我写个函数”，加上三句话，结果会完全不一样：输入是什么、输出应该是什么、边界情况有哪些。比如“写一个解析日志的函数，输入是按行切分的文本，输出是按小时统计的错误次数，空行要跳过，格式不对的行要记下来而不是直接崩掉”。把约束写进提问里，模型就不用猜，你也不用在它的猜测上返工。提问前多花一分钟，调试时往往能省下半小时。

习惯二：让它先解释，再动手改

拿到一段生成的代码，先别急着粘贴运行。让它用一句话说清这段代码的思路，再指出最可能出错的地方：比如“这个循环在空列表时会怎样”“这里的正则会不会把正常日志也过滤掉”。这个步骤有两个好处：第一，你能快速判断它有没有理解错需求；第二，解释的过程本身就是一次复习，时间久了，那些模式会变成你自己的直觉。真正学到东西的时刻，往往不是代码跑通的那一刻，而是你发现它哪里想错了的那一刻。

习惯三：小步验证，不要一次摊大饼

不要让模型一次性生成一个完整项目，再花一下午调试。正确的做法是拆成小步：先让它生成一个最小可运行的版本，跑通；再加一个功能，再跑通；每一步都有测试或打印结果佐证。中间任何一步出问题，范围都小到一眼能定位。这个习惯在没有大模型时同样重要，工具只是把“小步快跑”的收益放大了：每一步的反馈来得更快，你也更容易保持对代码的掌控感。

一个能直接用的工作流

以“写一个处理 CSV 的小脚本”为例，结对式的工作流大概是这样：第一步，你先写下需求和三条测试用例，包括一个空文件、一个带异常行的文件；第二步，让模型按用例生成第一版；第三步，跑测试，哪里失败就把失败信息原样贴回去，让它只修那一处；第四步，跑通后让它把容易踩坑的地方写成注释，方便以后的自己。整个过程里，测试用例是你写的，判断是你做的，模型只是帮你省掉了从零敲代码的时间。主导权一直在你手里，这一点不要让渡。

检查清单：用完问自己四个问题

每次用大模型辅助写完代码，不妨停下来问四个问题：我能说清这段代码在做什么吗？边界情况处理了吗？有没有我看不懂、却直接放进项目的部分？如果明天模型不在，我还能独立改动它吗？只要有一个答案是否定的，就说明这一步还不能算完成，回去补上解释或测试，再继续。清单很短，但坚持用一个月，代码质量和自己的手感都会明显不一样。

小结

大模型不会替你成为更好的程序员，但它能让你练习的密度变高：更多的尝试、更快的反馈、更具体的错误。把提问当成设计，把验证当成习惯，把主导权留在自己手里，工具就从“替你写代码的东西”变成了“陪你写代码的搭档”。先从下一个小任务开始试试：写清楚需求、准备好测试用例、小步验证，跑通一次，结对的感觉就有了。