让AI写代码？先划清边界再让它上手

用 AI 写代码最容易出现的场景是：你说一句“帮我写一个工具”，它给出一段能跑但完全不符合预期的代码，于是你开始逐个字段纠正——参数不对、风格不对、异步处理不对。来回改几次之后，你花的精力比自己写还多。问题不在模型能力，而在于你用一句话替代了本该由人完成的设计阶段。

为什么“描述—生成—修改”会变成消耗

AI 不是读心术。它只能根据你输入的文字生成“最可能”的版本，而你脑子里那个尚未成型的图景并不在输入里。传统开发里，需求到代码之间要经过需求分析、架构设计、接口定义等环节，这些文档是把模糊想法逐步细化的过程。跳过它们直接要代码，就等于把设计阶段的补课作业挪到了修改阶段，而且是以最昂贵的顺序支付。

让人负责设计与验证，让 AI 负责实现

一个清晰的分工边界是：人负责需求判断、架构决策、接口定义与结果验证；AI 负责按规格生成实现与提供备选建议。这个边界之所以重要，是因为 AI 生成的代码虽然结构规整，但在边界条件、异常处理、资源释放、并发安全这些地方仍需人工把关。而它擅长的部分——样板代码、测试用例骨架、文档草稿、跨文件的批量改写——恰好是人类最不擅长的重复劳动。

写一份“够用”的规格说明

规格不必写成完整的设计文档，但应包含五件事：

• 模块划分与职责边界：系统由哪几块组成，每块负责什么，依赖关系是什么。
• 接口定义：函数签名、参数类型与含义、返回值、异步接口的回调或事件方式。接口写清楚，生成的协作代码才稳定。
• 数据结构与核心流程：关键对象有哪些字段，主流程的状态如何转换。
• 技术选型与约束：语言、框架、分层规范、性能与安全上的硬性要求。
• 明确的不做清单：这一步最容易漏，却最能减少返工——不引入新依赖、不改动某些目录、不动某些配置。

验证环节不能省

生成的代码必须过三关：人工评审（评审者不应是提出生成需求的那个人）、自动化测试与安全扫描、以及在真实环境中的行为验证。凡是涉及鉴权、资金、数据迁移的改动，应提高评审门槛，例如双人评审或专人签核。把这几道关口写进流程，AI 就只是一个更快的实现者，而不是一个不可控的风险源。

一个对照案例

一个团队需要做内部数据导出工具。第一次尝试时只用一句话描述需求，前后改了十几轮，两周才勉强可用。第二次做同类工具时，先用半天写清字段定义、导出格式、失败重试逻辑和不做清单，再让 AI 生成代码，半天完成主体，一天走完测试与评审。两次的差别只有一个：设计是在纸上完成的，还是在修改循环里完成的。

常见误区

• 用一句话代替设计。省下的时间会在返工里加倍偿还。
• 让 AI 评审自己生成的代码。缺少职责分离，错误会被系统性地放过。
• 不做运行验证。编译通过、单测通过，不等于业务行为正确。
• 规格写得过细。写到“写文档比写代码还累”就过头了，规格的目标是消除歧义，不是替代实现。
• 用它处理自己不熟悉的技术栈且不加验证。不熟悉意味着你无法判断输出对不对。

行动建议

下一次让 AI 写代码前，先花二十分钟写一页规格：五件事加上不做清单。生成后不要立刻改，先逐条对照规格检查缺了什么——多数问题会在这一步暴露，而这比你事后调试要便宜得多。