新手第一次用 AI 写代码：先学会说清需求，再谈选模型

第一次打开 AI 编程工具时，很多人做的第一件事，是到处打听哪个模型最强、哪个工具最火。可是真正上手之后才会发现，模型换了几个，写出来的东西还是不对味：要么功能跑偏，要么界面和想象完全不同，要么代码能跑却没法改。这往往不是模型的问题，而是需求没有说清楚。AI 写代码更像和一位能力很强、但对你的业务一无所知的新同事合作，你说得越含糊，它猜得就越多，而猜测的结果很少正好是你想要的。

先说清需求，是一种更省时间的写代码方式。把需求讲清楚，并不是要写一份几十页的文档，而是要在动手之前回答几个关键问题：你要解决的是谁的什么问题，输入是什么，输出应该长什么样，有哪些不能碰的边界，最后怎么判断它做对了。把这些想清楚，AI 才有办法沿着你的思路走；想不清楚就直接开写，后面改起来只会更花时间。

一个好用的需求描述，通常包含五个要素。第一是背景，也就是这个功能用在什么场景里，是给自己练手的小工具，还是给团队用的内部页面，是临时验证想法，还是要长期维护的产品。第二是目标，用一句话说清这次要交付什么，比如做一个可以添加、删除和标记完成的待办清单，而不是笼统地说做一个好用的应用。第三是输入和输出，例如用户输入任务标题和截止日期，页面要按未完成和已完成分组展示，完成后可以一键归档。第四是约束，包括技术栈、数据来源、界面风格、性能要求和安全边界，比如只能用本地存储、不调用外部接口、不展示真实用户数据。第五是验收标准，也就是你会怎么测试它，例如添加十条任务后刷新页面数据还在，删除后不再出现，空标题时给出提示而不是直接保存。

举一个对比就更直观了。模糊的说法是：帮我写一个待办应用，要好看一点。AI 只能凭经验猜测你要什么风格、要不要登录、数据存在哪里。清楚的说法是：用网页做一个单页待办清单，支持添加任务、勾选完成、删除任务和按状态筛选；任务保存在浏览器本地存储中，刷新后不丢失；界面简洁，手机上也能正常操作；空标题时提示用户先输入内容。两种说法的工作量差不多，但第二种几乎不需要来回解释，第一次生成的结果就更接近预期。

说清需求还有一个好处，就是帮你发现自己思路里的漏洞。很多时候写着写着才意识到，原来自己也没想好排序规则、异常情况怎么处理、数据量大了怎么办。把这些问题提前写下来，等于先给自己做了一次需求评审。AI 在这个阶段也可以帮忙：你可以先让它根据你的描述列出疑问清单，逐一确认后再让它写代码。这个顺序反过来，就容易变成边写边改、越改越乱。

接下来谈谈怎么和 AI 一轮一轮地磨合。第一次生成之后，不要急着让它大改，先跑起来看看，再用具体语言反馈问题。说它不好用没有用，要说清楚哪里不好：按钮点下去没有反应，列表排序和预期相反，删除后刷新又出现了。把现象、操作步骤和期望结果一起告诉它，它才知道改哪里。同时一次只改一个问题，改完验证通过再谈下一个，这样出了问题也容易定位。如果一次提出五六个改动，最后很难说清是哪一个改动引入了新问题。

新手还容易犯的一个错误，是把 AI 当成不用看代码的工具。哪怕代码是 AI 生成的，你仍然需要读懂关键部分：数据存在哪里，函数做了什么，异常分支有没有处理。看不懂的地方可以直接问它，让它逐段解释，或者请它把复杂逻辑拆成更小的函数。读代码不是为了挑刺，而是为了在后面维护时不被动。真正能长期用的代码，一定是你自己也敢改的代码。

等到需求表达顺手了，再谈选模型才有意义。不同模型各有侧重，有的擅长快速生成原型，有的对长上下文和复杂重构更稳，有的在特定语言或框架上表现更好。但对新手来说，更重要的不是追逐排行榜，而是先固定一个顺手的工具，把需求模板、调试方法和验收习惯练熟。换模型之前，先问自己：现在的问题是模型能力不够，还是我的描述不够清楚、验证不够充分？多数情况下，答案是后者。

给新手一个可以照着做的流程。第一步，用三句话写清背景、目标和使用者。第二步，列出输入、输出和至少三条验收标准。第三步，写明约束，比如技术栈、存储方式和不能做的事情。第四步，让 AI 先给出实现思路和文件结构，确认无误后再写代码。第五步，逐项验收，记录没有通过的项，用具体现象反馈修改。第六步，完成后请 AI 总结改动点和遗留风险，自己再通读一遍核心代码。这个流程看起来多了一步，实际上省掉了很多返工。

最后要提醒的是，AI 写代码的速度很容易让人产生已经学会了的错觉。真正的能力增长，来自你提出好问题、判断结果对不对、把模糊想法变成清晰需求的过程。模型会不断换代，工具也会不断变化，但说清需求、拆解问题、逐项验证这些基本功不会过时。先学会说清需求，再谈选模型，你的第一次 AI 编程体验，才会从碰运气变成可重复的方法。