非程序员用 AI 写软件，真正要补的不是语法

这段时间我越来越确定一件事：非程序员用 AI 写软件，真正要补的不是语法。

语法当然有用。知道一点 JavaScript、Python、HTTP、数据库、前后端结构，会让沟通顺很多。但如果只把问题理解成“我不会写代码，所以需要 AI 帮我写代码”，还是太浅了。

AI coding 真正改变的是：它把很多“写代码”的动作降价了。

但它没有替我承担判断。

AI 写代码很快，但它不知道我想要什么

一开始用 AI 写项目时，我很容易把需求说得很大。

比如：

做一个微信小程序，可以连接 OneDrive，上传文件，管理文件。

这种描述对人来说能理解，但对 AI 来说太宽。它可以马上写很多代码，也可以给出一套看起来合理的架构，但问题是：我自己还没把流程拆清楚。

后来我发现，真正有效的提问不是“帮我做一个系统”，而是把任务拆成更小的动作：

现在已有 device code 接口；
小程序连接页需要展示验证码和验证链接；
轮询成功后保存账号信息；
失败要提示授权超时；
不要改文件页逻辑。

这种任务 AI 才容易做对。

AI coding 不是把一句愿望变成产品。它更像一个很快的执行者，而我必须先把任务边界写出来。

验收比生成更重要

非程序员最容易忽略的是验收。

AI 给了代码以后，看起来没有报错，不代表功能对。页面能打开，不代表状态对。接口返回 200，不代表业务链路真的跑通。

我后来给自己定了一个很朴素的规则：每做完一个功能，必须能说清楚它怎么验收。

比如转存小云里，上传功能不是“按钮点了没报错”就算完成，而是要看：

• 能不能从微信聊天文件选择文件；
• 能不能创建 OneDrive 上传会话；
• 分片上传失败后有没有提示；
• 上传成功后 OneDrive 目录里能不能看到文件；
• 切换账号后会不会上传到错误账号；
• 弱网或后台切换会不会造成任务状态混乱。

这才是功能。

如果我只会让 AI 生成代码，却不会设计验收点，这个项目迟早会变成一堆“看起来已经做了”的半成品。

报错不是敌人，含糊才是

一开始我很怕报错。

终端一报错，页面一白屏，我就觉得是不是项目坏了。后来慢慢发现，报错反而是好东西。它至少告诉我哪里不对。

真正麻烦的是那些含糊的问题：

• 文件传了，但列表不刷新；
• 授权成功，但下次打开又失效；
• Excel 公式算出来了，但结果不像预期；
• 模板能生成，但打开提示 XML 错误；
• 页面看起来正常，但用户流程走不通。

这些问题不能靠“再让 AI 修一下”解决。

我必须把现象描述清楚，给 AI 提供最小复现：哪个文件、哪一步、期望是什么、实际是什么、日志是什么、刚才改过哪里。

这也是我后来觉得非程序员可以做软件，但不能逃避工程训练的原因。

工程训练不一定是会背框架 API，而是能把问题变成可定位、可验证、可修复的形式。

AI 让开发更像对话，但不是聊天

AI coding 很像对话，但它不是普通聊天。

普通聊天可以跳来跳去，想到哪说到哪。开发不行。你让 AI 改代码，就会改变文件；文件一变，后面的问题就会叠在前面。上下文乱了，结果也会乱。

所以我后来更重视几件事：

1. 先读项目结构，不要上来就改；
2. 一次只改一个目标，不要同时加三个功能；
3. 改完必须跑检查，哪怕只是 npm run build 或打开模板；
4. 保留文档，让下一次继续时知道现在边界；
5. 遇到不确定先问清楚，不要让 AI 自己猜业务规则。

这些东西听起来不像“技术能力”，但它们决定 AI coding 能不能持续。

我现在怎么理解自己的能力

我不会把自己包装成资深程序员。

这个不诚实，也没必要。

但我也不会说自己只是“让 AI 写代码的人”。因为真正的工作不只是写代码，而是把真实需求拆开，带着 AI 把它推进到能用、能测、能解释的状态。

如果一个企业有一个很具体的流程，比如文档整理、表格核对、报告初稿、旧软件数据流转、内部知识库问答，我现在有能力借助 AI 把它做成一个小范围原型。

但如果一上来就是完整 ERP、复杂权限、多部门系统、财务闭环，我也知道这不是一个人能随便承诺的。

AI 降低了开发门槛，但没有取消边界。

对我来说，接下来要补的不是“我要不要学某门语言到精通”，而是三件事：

• 更准确地拆需求；
• 更严格地验收结果；
• 更清楚地判断哪些项目该做，哪些不该接。

这三件事，比语法更重要。