过去几个月，我深度体验了一轮 AI 编程，也就是现在很多人说的 vibe coding。
一开始，我和很多人一样兴奋。
以前做一个功能，要查文档、搭环境、写代码、修 bug。现在只要把想法告诉 AI，它就能生成页面、接口、组件、数据库结构，甚至还能自己解释报错、修改代码、继续迭代。那种感觉很像突然获得了一个不知疲倦的程序员助手。
尤其在小任务上，AI 的表现确实很惊艳。
让它写一个脚本，改一个样式，生成一个表单，补一个 API，写一段 SQL，做一个简单的后台页面，它经常能很快给出结果。很多时候，我只需要复制、运行、报错、再复制报错给它，它就能继续修。
这也是 vibe coding 最迷人的地方：你不需要一开始就懂全部技术细节，只要有一个想法，就能让软件“看起来”慢慢长出来。
但真正做了几个月之后，我最大的感受反而不是兴奋，而是清醒：
AI 能帮你写代码，但它不能替你做产品。
更准确地说：
你无法 AI 编程出一个你认知以外的产品。
这句话听起来有点狠，但这是我这几个月最真实的体会。
一、AI 最强的地方，是明确的小任务
我并不反 AI 编程。恰恰相反，我认为 AI 编程是个人开发者历史级别的机会。
在过去，一个人想做一个软件产品，门槛非常高。你要会前端、后端、数据库、部署、接口、安全、运维，还要懂一点产品、设计、增长和商业化。任何一个环节卡住，项目就可能停下来。
现在 AI 把很多“执行型门槛”降低了。
- 你不会写某个框架？它可以教你。
- 你不知道某个 API 怎么调用？它可以给示例。
- 你要快速验证一个想法？它可以帮你搭出原型。
- 你遇到报错？它可以陪你一点点定位。
这部分价值是真实的。
Merriam-Webster 对 vibe coding 的解释，本质上就是用 AI 系统生成代码；它还提到这个词来自 Andrej Karpathy 在 2025 年 2 月提出的那种“让 AI 写代码，人跟着感觉推进”的开发方式。
所以，vibe coding 并不是骗局。
它确实让很多非专业开发者第一次有机会把想法变成可以运行的软件。它也确实让个人开发者的原型速度变快了。
但问题在于：原型不等于产品，能跑不等于能用，能用不等于成熟，成熟不等于能商业化。
很多人，包括我自己，一开始很容易把这几件事混在一起。
二、项目越复杂，AI 越容易把你带进迷雾
刚开始做一个项目时，AI 编程非常爽。
你给它一个需求，它生成代码。页面出来了，按钮能点了，接口能返回数据了，你会觉得：“这不就成了吗？”
但项目一旦变复杂，问题就开始出现。
你会发现功能越来越多，文件越来越多，依赖越来越多，状态越来越乱。AI 今天写一套逻辑，明天又补一套逻辑。它为了修一个 bug，可能绕开原来的设计；为了满足一个新需求，可能引入一个新的分支；为了让代码能跑，它可能在你看不见的地方堆了很多临时方案。
最可怕的是，很多时候它写出来的东西并不是完全错的。
它能跑。
页面也能打开。
功能好像也完成了。
但你不知道它为什么这么写，不知道哪些地方是硬编码，不知道哪些地方没有异常处理，不知道数据库结构以后还能不能扩展，不知道权限边界有没有问题，不知道某个改动会不会影响其他模块。
这时候，你会慢慢失去对项目的掌控。
不是 AI 不努力，而是你自己没有一套足够强的判断系统。
它给你代码，你判断不了好坏。
它给你架构，你判断不了长期代价。
它给你设计，你判断不了审美层级。
它给你产品建议，你判断不了市场定位。
它给你一条路线图，你判断不了战略取舍。
最后项目会变成一种“AI 堆出来的半成品”：看起来什么都有，但哪里都不够稳。
三、专业软件产品最难的部分，不是写代码
这几个月我越来越意识到，软件产品真正难的地方，不是“写出代码”。
代码只是产品的表达形式。
一个成熟软件背后，至少有几层能力：
- 第一层是产品定位。你到底服务谁？解决什么高频问题？为什么用户要选你，而不是继续用 Excel、Notion、WordPress 插件、人工流程，或者竞品？
- 第二层是产品心智。用户一看到你，就能不能明白你是什么？它在用户脑子里占据哪个位置？是效率工具、自动化工具、内容中台、数据助手，还是工作流平台？
- 第三层是架构设计。现在的功能怎么拆？哪些是核心域？哪些是插件？哪些配置要成为真源？哪些流程必须可回滚、可审计、可重跑？
- 第四层是工程质量。有没有测试？有没有日志？有没有错误恢复？有没有权限边界？有没有数据隔离？有没有发布前校验和发布后审计？
- 第五层是前端审美和交互体验。页面不是能显示就行。信息层级、留白、动效、路径、反馈、空状态、错误提示，都会影响用户对产品专业度的判断。
- 第六层是商业交付能力。客户怎么部署？怎么迁移？怎么配置？出了问题怎么定位？版本升级怎么保证不炸？能不能复制交付给第二个、第三个客户？
这些东西，AI 都能“参与”，但很难“负责”。
它可以给你建议，但它不会真正承担后果。
它可以生成方案，但它不知道你产品的长期取舍。
它可以补代码，但它不会替你为架构债买单。
DORA 2025 对 AI 辅助软件开发的一个判断很关键：AI 的主要角色是“放大器”，它会放大一个组织既有的优势和弱点，真正的回报不只来自工具本身，而来自底层组织系统。
这句话放到个人开发者身上也一样：
AI 会放大你的认知，而不是替代你的认知。
你懂产品，它就帮你更快验证产品。
你懂架构，它就帮你更快落地架构。
你懂审美，它就帮你更快生成界面。
你懂测试，它就帮你更快补齐测试。
但如果你什么都不懂，它也会更快地帮你堆出一个你无法维护的复杂系统。
四、为什么新手更容易被 AI 编程误导？
我觉得新手用 AI 编程最大的问题，不是写不出东西，而是太容易“过早成功”。
过去不会编程的人，做不出来就是做不出来，卡住了会意识到自己需要学习。
现在不一样。
AI 可以让你很快看到一个页面，很快跑通一个 Demo，很快部署一个项目。于是你会误以为自己已经掌握了开发。
但很多东西在早期是不会暴露的。
架构问题，往往在功能变多之后暴露。
权限问题，往往在真实用户进来之后暴露。
数据问题，往往在规模变大之后暴露。
维护问题，往往在你隔了一个月回来改代码时暴露。
产品定位问题，往往在你发布之后没人用时暴露。
这就是 AI 编程的陷阱：它降低了启动成本，但没有消除复杂度。
更麻烦的是，它还可能制造一种“虚假的安全感”。
有研究发现，使用 AI 编程助手的人在安全相关任务中写出了更不安全的代码，并且更容易相信自己写出的代码是安全的。
这和我的体感很接近。
AI 生成的代码经常语气很自信，结构也很像专业代码。但像不像专业，和是不是专业，是两回事。
五、我后来才明白：AI 编程真正需要的是 Harness Engineering
以前我以为 AI 编程的核心是 Prompt。
后来发现不是。
Prompt 当然重要，但它只是入口。真正决定 AI 能不能稳定产出的，是你有没有给它建立一套约束系统。
现在行业里有一个词叫 Harness Engineering。Martin Fowler 的文章里提到，harness 可以理解为 AI agent 中除了模型之外的一切，也就是围绕模型的系统、工具、上下文、约束和流程。
我用更直白的话说：
Prompt 是你怎么跟 AI 说话，Harness 是你怎么让 AI 不乱来。
比如：
- 你不能只让 AI “帮我做一个功能”。
你要让它先读需求、再列计划、再小步实现、再写测试、再运行检查、再输出变更说明。 - 你不能只让 AI “修一下 bug”。
你要让它先复现问题、定位原因、说明影响范围、提出最小修改方案，再动代码。 - 你不能只让 AI “优化架构”。
你要让它基于现有目录、数据流、模块边界、长期路线和约束条件来判断，而不是凭空生成一套看起来高级的架构图。 - 你不能只让 AI “写个产品方案”。
你要给它用户画像、使用场景、竞品边界、商业目标、核心约束和你不做什么。
这就是我现在越来越重视的东西：
不是让 AI 更自由，而是给 AI 更清晰的轨道。
六、个人开发者真正要升级的，不是工具，而是认知栈
这几个月我最大的变化，是不再幻想靠 vibe coding 一路“蒙”出一个成熟产品。
我现在更相信一件事：
- 个人开发者在 AI 时代的竞争力，不是会不会用 AI，而是有没有自己的认知栈。
这个认知栈至少包括：
- 你要懂一点产品定位，知道自己到底在做什么、不做什么。
- 你要懂一点架构设计，知道系统未来会怎么长。
- 你要懂一点工程方法，知道怎么测试、回滚、观测、审计。
- 你要懂一点设计审美，知道什么叫专业、清爽、可信。
- 你要懂一点商业交付，知道产品怎么从自用工具变成别人愿意付费的解决方案。
- 你还要懂一点 AI 协作方法，知道什么时候让 AI 写，什么时候让 AI 停，什么时候必须自己判断。
这也是我做产品过程中越来越深的体会。
当一个产品从“脚本”走向“系统”，从“能跑”走向“可交付”，就不能只靠 AI 一段一段生成代码。比如我自己在做内容自动化流水线时，真正重要的并不是“AI 帮我写了多少代码”，而是能不能把采集、处理、质检、发布、审计这些环节做成稳定闭环，能不能多站点管理，能不能失败恢复，能不能可追踪、可回滚、可审计。
这类问题，不是一个“帮我做个自动发布工具”的 Prompt 能解决的。
它需要产品定义，需要架构边界，需要流程标准化，需要交付思维。
七、AI 编程不是捷径，而是杠杆
所以，我现在对 AI 编程的态度变了。
我不再把它当成“替我完成产品的魔法”。
我把它当成杠杆。
杠杆的意思是：你本来就要有一个支点。
- 你的产品判断是支点。
- 你的技术理解是支点。
- 你的审美标准是支点。
- 你的用户洞察是支点。
- 你的工程方法论是支点。
没有支点，杠杆再长也没用。
AI 能让强的人更强，也能让混乱的人更混乱。它能让清晰的产品更快成型，也能让模糊的想法更快变成一堆技术债。
这就是我这几个月用 AI 编程后，最想提醒个人开发者的一句话：
不要以为 AI 让编程没有门槛了。它只是把门槛从“会不会写代码”，转移到了“会不会判断”。
以前不会写代码，你做不出来。
现在不会判断，你可能做得出来，但做不成熟。
更可怕的是，你可能做着做着，连自己做了什么都不知道。
八、最后：你无法 AI 编程出一个你认知以外的产品
很多人喜欢说一句话：你赚不到认知以外的钱。
我现在觉得，在 AI 编程时代，还有一句话同样重要：
你做不出认知以外的产品。
AI 可以帮你补执行力，但不能替你补产品心智。
AI 可以帮你写功能，但不能替你承担架构后果。
AI 可以帮你生成界面，但不能替你建立审美标准。
AI 可以帮你快速试错，但不能替你选择正确方向。
所以，对个人开发者来说，真正值得做的不是盲目追最新模型、最新工具、最新编辑器，而是建立自己的底层能力：
- 产品定位能力。
- 架构判断能力。
- 工程质量意识。
- 用户体验审美。
- 商业化思维。
- AI 协作方法论。
当你具备这些能力，AI 就是超级助手。
当你缺少这些能力，AI 可能只是一个更快帮你制造混乱的机器。
这不是否定 AI 编程。
恰恰相反，我仍然认为 AI 编程会改变个人开发者的命运。
但前提是，我们不能把 AI 当成逃避学习的借口。
AI 编程真正释放的，不是“什么都不懂的人也能做出专业产品”。
而是：
有判断力的人，可以用更低成本、更快速度，把自己的认知变成产品。
评论