《让 AI 帮你写代码之前，先把这三件事说清楚》

AI 编程助手已经能写出能跑的代码，但"能跑"和"能用"之间，往往差在你给它的那几句话上。同样一个需求，描述清楚的人一次拿到可用的结果，描述含糊的人改五轮还在修边角。下面三件事，是我用 AI 写代码时固定先说清楚的，缺一不可。

第一件事：说清楚上下文，而不是只说功能。只说"写一个登录接口"，AI 只能按最常见的套路拼：它不知道你的项目用的是什么框架、数据库字段叫什么、密码存在哪张表、返回格式有没有统一约定。正确的做法是先给边界：技术栈是什么、相关文件在哪、已有约定是什么。比如"项目是 Node + Express，用户表字段是 email 和 password_hash，返回统一包成 {code, data, message}"——有了这些，AI 生成的代码才能直接落进你的项目，而不是一段看起来漂亮、接不上的孤岛代码。上下文给得越具体，返工越少；反过来，上下文全靠 AI 猜，猜错的部分最后都由你买单。

第二件事：说清楚验收标准，而不是只说"帮我实现"。人写需求时常犯的毛病是只描述"做什么"，不描述"做到什么程度算对"。对 AI 尤其要补上这一条：正常流程走通是什么样、异常情况怎么处理、边界值有哪些。还是以登录为例：密码错误返回什么、连续输错几次要锁定、Token 有效期多久、要不要记登录日志——这些不写，AI 就会按默认值替你选，而默认值未必符合你的业务。把验收标准写成清单，生成完按清单逐条核对，比"看起来没问题"可靠得多。清单也是你评审 AI 代码的标尺，没有它，评审只能凭感觉。

第三件事：说清楚不要什么，而不是只说要什么。AI 很擅长"多给"：你让它写一个工具函数，它可能顺手引入一个新依赖、改掉你现有的函数签名、顺带重构了半个文件。这些"好意"常常是后续 bug 的来源。所以需求里要明确划红线：不要新增依赖、不要改动已有接口、不要把配置写死在代码里、复杂逻辑先拆函数再实现。红线写在前面，AI 的输出范围就收得住；事后一句"别改我的代码"再去修，成本比事前一句话高得多。

最后还有一条总原则：AI 给的代码，永远按"别人提交的 PR"来审。跑一遍测试、看一眼边界、确认没有硬编码的密钥和多余依赖，再合入。AI 负责把从零到一的体力活干掉，人负责把关"对不对、合不合规、能不能维护"——分工清楚了，AI 才是提效工具，否则它只是把写 bug 的速度也提上去了。