真正会 AI 编程的人,都不急着写代码

大家好，我是 GNIY。

很多人第一次接触 AI 编程，最容易犯的错是：打开 Claude Code、Cursor 或者其他工具，直接说：“帮我做一个 XXX。”然后等它写代码。

代码确实会出来。页面也可能真的跑起来。但很快你会发现一个问题：它好像做了很多东西，又好像没有做出你真正想要的东西。

按钮位置不对。业务逻辑不对。API 接不上。改了 A 又坏了 B。你让它修，它继续补丁摞补丁。最后整个项目变成一团毛线。

这时候很多人会得出一个结论：“AI 编程还是不靠谱。”但我现在越来越觉得，问题不一定出在 AI。很多时候，是我们还没有学会怎么当“老板”。

AI 编程真正的分水岭，不是你会不会写代码。而是你能不能把一个模糊的想法，拆成 AI 能执行、你能检查、产品能上线的清晰任务。这件事，才是 AI 编程的核心能力。

一、AI 编程不是“让 AI 写代码”

先讲一个最重要的判断：AI 编程，不等于把开发外包给 AI。更准确地说，你像是在带一个能力很强、手速很快、但必须被管理的实习生。

你负责三件事：想清楚要做什么；把任务拆清楚；检查它交出来的东西。AI 负责三件事：写代码；查资料；处理细节。

这两个角色不能反过来。如果你自己还没想清楚产品要解决什么问题，只是把一个模糊愿望丢给 AI，它大概率会给你一个“看起来很完整”的东西。

看起来有首页。有登录。有按钮。有数据库。有一堆你也不确定需不需要的功能。但这不叫产品。这叫 AI 给你生成了一坨代码。

真正的 AI 编程，应该从 Vibe Coding 升级到 Agentic Engineering。Vibe Coding 是什么？靠感觉提需求，靠玄学抽代码，靠祈祷项目能跑，出了问题再让 AI 一轮轮修。

Agentic Engineering 是什么？目标清晰，任务拆解，人类判断，AI 执行。你会发现，后者听起来一点都不玄。它甚至有点像管理学。

不是你冲进厨房说“给我做一桌好吃的”，然后等厨师猜。而是你先想清楚：吃饭的人是谁？预算多少？忌口是什么？今天要的是家常菜，还是宴请菜？哪些菜必须有，哪些菜不做？

AI 编程也是一样。你越像一个清楚的老板，AI 越像一个厉害的员工。你越像一个混乱的老板，AI 就越像一个忙乱的实习生。

二、第一步不是开发，是验证

很多人有一个产品想法后，第一反应是：“能不能马上做出来？”但我现在会反过来。我会先问：“这个东西，技术上能不能用现成 API 做？”

这一步非常关键。因为做 AI 产品，本质上不是你从零发明一个模型。绝大多数个人开发者、小团队做的 AI Web SaaS，都是在调用现成能力。

大语言模型是一类积木。图像、语音、视频模型是一类积木。搜索、数据库、长期记忆、自动化工具，也是一类积木。你真正要做的，不是发明积木。而是知道有哪些积木，把它们组合成一个用户愿意使用，甚至愿意付费的体验。

所以，一个想法出现后，不要先写代码。先问 AI：我想做的产品使用当今的 AI 技术能不能实现？有没有现成的 API 可以让我调用？

如果有成熟 API，再继续。如果这个能力还停留在论文、实验室、少数大厂内部，那对普通个人开发者来说，就先别碰。不是这个方向不好，而是它暂时不适合你现在用 AI 编程快速做产品。

验证的时候，也不要只听 AI 一句话。可以交叉看三个地方：第一，直接测大模型能不能完成这件事；第二，去 Replicate、Fal、OpenRouter 这类 API 平台搜；第三，去 n8n、Coze、Vercel 模板、GitHub 开源项目里看有没有类似实现。

如果三个地方都找不到，那就要谨慎。如果已经有人做过，反而是好事。说明这条路不是空气。AI 编程最怕的不是别人也能做，最怕的是你做了半个月，最后发现这事根本不能用现成能力实现。

三、找到 API 后，还是别急着写代码

很多人找到 API 后，会立刻让 AI 接入项目。这一步也容易翻车。因为你还没有“验货”。API 文档写得再好，也不等于实际效果满足你的产品。

所以第二步应该是：先用 Playground 或 Postman 测。不要接前端，不要建数据库，不要做登录。先把最核心的输入输出跑通。

比如你要做一个 AI 图片工具。那就先测：用户上传什么图？API 返回什么结果？速度能不能接受？价格能不能接受？失败率高不高？输出质量稳不稳定？

同类 API 最好测几个。对比五个维度：效果、成本、速度、稳定性、接入难度。这一步看起来很慢，其实是在省后面的大时间。因为如果 API 本身不行，你后面写再漂亮的界面都没用。

测通以后，把四个东西整理好：API Key、示例代码、示例输入、示例输出。这四个东西，就是你让 AI 接入代码时最重要的材料。

很多所谓“API 调不通”，根本不是代码能力问题。是你一开始没有把调用方式、参数、返回结构说清楚。AI 不怕任务难。它怕你给的信息又多又乱，还藏着关键缺口。

四、Spec 才是新的源代码

我现在越来越相信一句话：在 AI 编程里，Spec 就是新的源代码。以前写代码，是程序员把需求翻译成代码。现在很多代码可以由 AI 写。但问题没有消失。它只是往前移了。

以前最难的是“怎么写”。现在最难的是“到底要写什么”。一份好的 Spec，至少要讲清楚五件事。

第一，问题陈述。用户到底要什么体验？第二，解决方案。你准备给他什么功能？几个页面？几个步骤？交互是什么？第三，技术约束。用什么技术栈？有没有必须接的 API？有没有平台限制？第四，不做什么。哪些功能这版明确不做？哪些诱人的想法先砍掉？第五，成功标准。什么叫做完？手机端能用吗？流程闭环了吗？错误状态处理了吗？

很多人写 Spec 的时候，只写“我要一个 XX 工具”。这对 AI 来说太粗了。它会自己脑补。而 AI 最危险的地方就在这里：它脑补得很像那么回事。

所以你要主动让 AI 先别写代码，而是先帮你问问题，直到能够形成一份完整的 SPEC。

我建议这个动作最好就在你的 IDE 或 Coding Agent 里完成。因为你和 AI 磨完 Spec 后，可以直接让它开工。不用从 ChatGPT 复制到 Cursor，再从 Cursor 复制到 Claude Code，中间丢上下文。

AI 编程的关键，不是把信息塞得越多越好。是把关键上下文整理得少而准。歧义是最贵的 bug。

五、真正开始开发时，一次只改一件事

当 Spec 清楚、API 测过、技术栈定好后，才进入写代码阶段。如果是个人开发者，我会优先选 Next.js 全栈。

原因很简单：一个项目同时管前端和后端，全程 TypeScript，部署到 Vercel 很顺，前后端不用来回扯皮。对 AI 来说，这套结构也很友好。

page.tsx 管页面，route.ts 管后端接口，components/ 管可复用组件，layout.tsx 管共享外壳。文件越小，边界越清楚，AI 越不容易乱改。

但比技术栈更重要的是开发节奏。我建议记住三个习惯。

第一，一次只改一件事。不要同时让 AI 改首页、接 API、加登录、修样式。它真能做。但一旦坏了，你不知道是哪一步坏的。

第二，改完马上测试。每轮改动后，本地跑一下。不要连续让 AI 改五六轮，然后最后一起看。那时候问题已经叠起来了。

第三，看 diff，不要盲目回滚。GitHub 或本地 Git 的意义，不只是备份。更重要的是让你看到 AI 到底改了什么。

很多问题不是整个项目坏了。可能就是一行变量名错了。你把那一行指出来，AI 就能修。但如果你不知道它改了哪里，你就只能恐慌式回滚。

这也是为什么 AI 编程看起来像开发，其实更像管理。你不是在和代码搏斗。你是在管理任务粒度、检查节奏和反馈回路。

六、密钥安全是红线，不是细节

如果你只记一个安全规则，请记这个：API Key 绝不能写进前端。前端代码对用户是透明的。你把 Key 写进去，就相当于把银行卡密码印在名片上。

标准做法是：密钥放在 .env.local；变量名不要带 NEXT_PUBLIC_；前端不直接请求第三方 API；前端请求自己的 /api/xxx；后端读取密钥，再去调第三方 API。

这个结构听起来多绕一层，但它是保命线。因为 AI 产品一旦上线，API 调用就是钱。如果 Key 泄露，别人可以直接薅你的额度。

更麻烦的是，如果你把 Key 提交进 Git 历史，删除当前代码还不够。旧提交里仍然可能有。

泄露后正确顺序是：立刻吊销旧 Key，生成新 Key，更新本地和 Vercel 环境变量，重新部署，再处理代码和 Git 历史。顺序不能反。不要先慢悠悠修代码。Key 每多活一秒，都可能在扣费。

七、上线之后，才是真正开始

很多人以为产品上线就是结束。但对 AI Web 产品来说，上线只是第一天。因为你之前所有判断，本质上都是假设。

用户真的会点吗？真的会注册吗？真的会用核心功能吗？真的愿意留下反馈吗？真的愿意付费吗？这些不是靠想象回答的。要靠数据。

最基础的，你至少要装一个数据分析工具。看跳出率，看停留时长，看页面访问路径，看用户在哪一步离开。

这很重要。因为数字告诉你“发生了什么”。录屏告诉你“为什么发生”。比如你看到某个页面跳出率很高，你以为是功能不行。结果一看录屏，发现用户根本没看到按钮。

又比如你发现注册完成率很低，你以为是产品没有价值。结果一看流程，发现验证码邮件进垃圾箱了。这就是数据反馈的意义。它把你的猜，变成可验证的判断。

同时，你还要给用户留反馈入口。邮箱、在线聊天、Discord 社群、表单，都可以。入口要放在用户最想吐槽的地方：报错页、取消订阅页、结果生成失败后、产品内的反馈按钮。

收到反馈后，不要试图满足所有人。听所有人，但自己做决定。AI 编程的终点不是“做出一个东西”。而是进入一条反馈链路：想法 → 验证 → 开发 → 上线 → 数据 → 反馈 → 迭代。

这条链路跑起来，你才真的开始拥有产品能力。

八、如果只记一条线，就记这条

最后，把整件事压缩成一条最小路径：有想法后，先问 AI 验证技术可行性；找到现成 API 后，用 Playground 或 Postman 测效果；测通后，整理 API 四要素；再和 AI 磨 Spec，不要急着写代码；Spec 清楚后，用 Next.js 起项目；第一时间接 GitHub；密钥只走服务端环境变量；一次只让 AI 改一件事；改完就测试，看 diff 再继续；本地 build 通过后再部署 Vercel；上线后装数据分析和反馈入口；最后根据真实行为迭代。

这就是我理解的 AI 编程。它不是魔法，也不是一句 Prompt 生成一个商业项目。它更像一种新的工作方式：人类把混乱拆成秩序，AI 把秩序执行成代码，真实用户再把代码变成反馈，反馈继续倒逼你修正判断。

所以，真正会 AI 编程的人，不会一上来就急着写代码。他会先问：这件事该不该做？有没有现成积木？用户路径是什么？不做什么？怎么判断做完？怎么上线验证？出了问题怎么回滚？

这些问题想清楚之后，代码反而是最不神秘的部分。因为 AI 已经很会写代码了。真正稀缺的，是你能不能指挥它，把一个模糊念头，变成一个可运行、可验证、可迭代的小系统。