夜雨聆风我必须先承认，那 15 分钟很爽。
一个原本不值得排期的小需求，被 AI 做成了一个能跑的小工具。它能处理文件，整理结果，把重复动作自动跑完。没有复杂架构，也没有高深算法，但它确实让一个人以后少做很多机械活。
这就是 AI 编程最让人上头的地方。
很多过去只会停在嘴边的需求——“要是有个工具就好了”——现在真的可以变成一个工具。它不完美，不漂亮，甚至可能很粗糙，但它能跑。
对一个被重复劳动折磨的人来说，这已经很有价值了。
真正让我警惕的，是小工具跑通之后的那个瞬间。
屏幕上显示“处理完成”。
人很容易在这里松一口气，觉得事情结束了。
但我当时停了一下。
因为我知道，这个工具只证明了一件事：它在刚才那条正常路径上成功了。
文件格式正常，路径正常，命名正常，权限正常，输入也正常。
可软件真正麻烦的地方，往往不是正常时会怎样。
而是第一次不正常时，它会怎样。
这也是 AI 编程最容易骗过人的地方。它的问题不只是会犯错，更在于它会把一个还没有被认真验证过的东西，包装成“看起来已经完成了”。
AI 降低的是第一步，不是全部
现在的 AI 编程，已经不只是帮人补几行代码。
你把需求说出来，它能生成页面，写脚本，装依赖，改报错，连数据库，做预览，甚至告诉你怎么部署。对普通人来说，这种体验很强：原来做一个小应用，要知道前端、后端、数据库、命令行、服务器；现在很多东西被压进了一个对话框。
这也是 Vibe Coding 这个词会火的原因。
你可以先把 Vibe Coding 理解成一种“跟着感觉让 AI 写代码”的方式：需求交给 AI，报错交给 AI，修改也交给 AI。人主要负责描述、试跑、继续提要求。目标不是一开始就把工程结构设计得很完整，而是先让东西跑起来。
这个说法最早由 Andrej Karpathy 在 2025 年初带火，原话里甚至有一种“忘掉代码本身存在”的味道。它吸引人的地方，不是代码写得多优雅，而是让人感觉自己绕过了很多原本复杂的技术门槛。(X (formerly Twitter))
所以我不想把这篇文章写成“别用 AI 写代码”。
那太粗暴，也不真实。
AI 编程确实能释放很多小需求。老师可以做排课工具，运营可以做活动数据整理脚本，财务可以做凭证辅助检查，小团队可以快速验证一个产品想法。
问题不在“普通人能不能做软件”。
问题在于，很多人会把“做出第一版”，误认为“已经可以放心使用”。
这中间差了一整段路。
◆ ◆ ◆
能跑起来，只证明正常路通了
一个程序跑通，只说明刚才那一次尝试没有出错。
至于异常文件、权限边界、数据流向、成本曲线，还有半年后谁来维护，这些都还没被证明。
更直白一点说，第一次跑通只是一张很窄的通行证。
它让你通过了眼前这道门。
但软件后面还有很多门。
这句话看起来有点像技术人员挑刺，但其实不难理解。
一辆车能发动，不代表它能合法上路。它还要有刹车、车灯、保险、年检。你在院子里开两圈没问题，不等于能开上高速。
一道菜能炒出来，也不代表你能开餐馆。餐馆要管食材、卫生、出餐速度、过敏原、消防和投诉。
写代码更像“把菜炒出来”。
做软件更像“开一家不轻易把客人吃坏肚子的餐馆”。
Google 的《Software Engineering at Google》里有一个很好的区分：软件工程和编程的差别，来自时间、规模和权衡。书里甚至把软件工程说成“随时间展开的编程”。代码不是今天能用就结束，它会被更多人使用，会被修改，会接入更多系统，也会在变化里暴露问题。(Abseil)
AI 编程容易让人跳过这一步。
因为它把“正常路径”做得太顺了。
你上传一个格式正常的文件，它处理成功。你打开一个刚生成的网页，页面显示出来。你问 Agent 一个标准问题，它马上给你一个像样的回答。
这些瞬间都会让人产生一种错觉：好了，已经完成了。
可真正的软件风险，通常就藏在“标准情况”之外。
文件名里多了一个奇怪符号，程序可能就挂了。
一个没有权限的人，可能看到了本不该看到的数据。
API Key 如果被写进代码，就等于把钥匙放在门口。
批量处理 100 份报告时，系统可能不是变慢，而是直接把上游服务打崩。
Stack Overflow 2025 年开发者调查里有一个很有意思的对照：84% 的受访者已经在使用或计划使用 AI 工具参与开发，但最多人提到的挫败感，是 AI 给出的方案“差不多对，但又差一点”。大家都在用，不代表大家真的放心。(Stack Overflow Insights)
最危险的，往往不是报错
报错其实不一定最可怕。
报错至少会提醒你：这里坏了。
更麻烦的是那些“不报错，但已经埋雷”的东西。
比如 API Key。
API Key 可以理解成一把钥匙。程序拿着这把钥匙，才能调用模型、数据库、云服务或公司系统。
很多人让 AI 写代码时，只关心“能不能连上”。AI 也很配合，帮你把 Key 填进去，代码一跑，通了。
但如果这把钥匙被写进代码，甚至被上传到公开仓库，就像把钥匙贴在门口。你确实进屋方便了，别人也方便了。
安全漏洞也是这样。
攻击者输入的不是正常数据，而是精心设计过的内容。他可能让系统执行不该执行的动作，看到不该看的数据，绕过不该绕过的限制。
在安全领域，这些问题有很多专门名字。普通读者不需要记住它们。你只需要知道：页面能打开，不代表这个页面安全。
Veracode 2025 年对 AI 生成代码的研究显示，45% 的 AI 生成代码包含安全缺陷。这个数字不需要夸张解读，它只提醒一件事：代码能工作，不等于代码安全。(Veracode)
合规风险也很容易被忽略。
AI 写代码时，经常会推荐它觉得常见、顺手的工具。装 Docker，装 Anaconda，拉一个开源库，复制一段示例代码。用户一路点“继续”，工具也确实跑起来了。
但“能下载”不等于“能在公司随便用”。
Docker Desktop 官方说明里写得很清楚：个人、教育、非商业开源项目，以及员工少于 250 人且年收入低于 1000 万美元的小企业，可以免费使用；更大的组织进行专业使用，需要付费订阅。(Docker)
Anaconda 的服务条款也规定，如果代表超过 200 人的营利组织使用 Anaconda Platform，需要购买 Business Plan。(Anaconda)
开源软件也不是没有规则。MIT、Apache、GPL、AGPL 这些许可证，不是页面底部的装饰。它们规定了署名、分发、修改、公开源代码等义务。
很多人在 AI 编程里不会主动问这些。
AI 也不一定会主动提醒。
这就像导航只告诉你“这条路最快”，但没有自动判断你的车能不能进限行区、有没有通行证、货物能不能走这条路。
路能走，不代表你有权走。
还有性能和成本。
一个 AI 工具处理一份文件，看起来很聪明。文件多一点，也许还行。可如果有人把 100 份报告一次性丢进去，问题就变了。
这时候要考虑队列、限流、并发、超时、重试、缓存、预算告警。
可以把它想成餐厅后厨。
来了 100 单，不代表厨房能同时炒 100 份。厨师、灶台、备菜、服务员都有上限。靠谱的餐厅会排队，会控制节奏，会告诉客人预计等待，会在忙不过来时暂停接单。
API 也一样。
OpenAI 的开发者文档建议，遇到速率限制时使用指数退避重试，也就是失败后等待一段时间再试，等待时间逐步拉长，而不是继续猛打请求。(OpenAI 开发者)
没有队列和限流的 AI 应用，平时很顺，高峰时可能把自己和上游服务一起拖垮。
还有一种风险叫“以后没人敢改”
很多 AI 小工具第一天看起来都很轻。
代码生成了，能跑，界面还不错。
一个月后，麻烦开始出现。
依赖升级了，接口变了，文件格式也可能变了。原来写工具的人忘了当时怎么问 AI，其他人打开代码，发现变量名看不懂，日志没有，配置项没有，错误提示也没有。
这时候，一个“提高效率的小工具”，就会变成没人敢碰的盒子。
硬编码就是最典型的例子。
硬编码，就是把执行时间、文件路径、命名规则、接口地址、密钥这些东西直接写死在程序里。
它像把家具焊死在房间里。
今天看起来很稳，明天想换个位置，只能砸墙。
有经验的人一开始就会问：哪些东西以后可能变化？哪些东西应该做成配置？哪些错误要提示用户？哪些日志要留下？哪些行为要可追踪？
这些问题不酷，也不显得智能。
但它们决定一个工具能活一天，还是能活一年。
软件工程里有很多这样的隐性知识。
隐性知识就像做菜的火候。菜谱可以写“中火翻炒三分钟”，但老厨师知道什么时候该关火，什么时候该加水，什么时候锅气不对。
软件里也有这种火候。
哪些输入不能直接相信，哪些权限必须收紧，哪些参数不能写死，哪些失败可以重试，哪些失败必须立刻停下来。
还有日志。
有些日志能帮你救命，有些日志会把敏感信息泄出去。
AI 可以给步骤，但不会自动替你承担判断。
这不是第一次发生
AI 编程看起来很新，但“非程序员自己做工具”这件事，历史上已经发生过很多次。
Excel 宏、Access、小型数据库、低代码平台，都曾经让业务人员获得新的创造力。
很多一线人员最懂自己的工作。他们知道哪张表最烦，哪个流程最慢，哪个字段根本没人看。正式开发流程太慢时，他们会自己做一个表、一个宏、一个小系统。
这不是什么坏事。
很多自建工具，最初都来自真实痛点。
问题从来不在创新本身，而在缺少边界和护栏。
Excel 宏能提升效率，也可能让错误公式扩散。
Access 小系统能解决部门需求，也可能没人备份、没人维护、权限混乱。
低代码能让业务更快做流程，也可能出现版本失控、数据重复、审计不清。
AI 编程只是把这条老路又往前推了一大步。
以前做一个小系统，还要懂一点公式、数据库、表单和逻辑。
现在只要会描述需求，AI 就能把代码写出来，把页面搭出来，把接口接上，把部署说明列出来。
速度更快。
门槛更低。
也更容易连接外部世界。
以前一个 Excel 宏坏了，可能影响一张表。
现在一个随手搭出来的网页、应用或 Agent，如果接了公司域名、API、模型和数据，影响范围就不一样了。
别把原型当成软件
普通人当然可以用 AI 编程。
低风险场景甚至应该大胆用。
自己本机处理一批文件，做一个一次性脚本，写一个学习项目，搭一个小原型，只要别放敏感数据，别把密钥乱贴，完全可以边试边改。
这种场景里，AI 的价值非常大。
它能把很多枯燥的重复劳动消掉，也能让很多想法更快被验证。
但有些变化会悄悄发生。
一开始，只是你自己用。
后来，你觉得挺方便，就把工具发给旁边两个人。
再后来，大家都来找你要链接。
某一天你忽然发现，这个东西已经不是“我自己用的小脚本”了。它在处理团队数据，很多人依赖它做判断。可它没有权限设计，没有日志，没有备份，也没人知道如果它错了该找谁。
这时候，问题已经变了。
工具一旦从本机走向群聊，从临时脚本走向公司数据，性质就变了。
再往外一步，接域名、API、客户或付费模型，讨论的就不只是“好不好用”，还包括攻击、滥用、账单和责任。
普通人不是不能做软件，而是要知道自己做的是玩具、工具、系统，还是基础设施。
玩具可以坏。
个人工具可以粗糙一点。
团队系统需要有人维护。
基础设施不能靠兴奋上线。
这个分界，比“是不是程序员”更重要。
跑起来以后，才真正开始
我依然觉得，那个 15 分钟小工具值得做。
它解决了真实问题，也节省了真实时间。
我也相信，未来会有越来越多普通人，用 AI 做出自己的工具、网页、自动化流程和小应用。
这是一件好事。
AI 编程最好的未来，不是人人假装自己成了程序员。
而是更多人能把真实需求更快变成可验证的原型。
但从原型到软件，中间仍然有一段路。
这段路不能被一个运行成功的截图省掉。
所以，下一次你用 AI 写出一个工具，看到它真的跑起来了，可以高兴。
但别急着放心。
先问一句：
它只是一个玩具，一个个人工具，一个团队系统，还是已经变成了基础设施？
这几个东西，看起来都叫“软件”。
但它们要承担的后果，完全不同。
代码能跑起来，只是故事开始。
真正考验人的，是跑起来以后。
◆ ◆ ◆
参考资料 / 延伸阅读
- 1.Andrej Karpathy 关于 “Vibe Coding” 的公开表述。文中关于 Vibe Coding 说法来源的说明，参考该公开发言。(X (formerly Twitter))
- 2.Stack Overflow, 2025 Developer Survey。文中关于 AI 工具使用率，以及开发者对“差不多对，但又差一点”的 AI 方案感到挫败的数据，来自该调查。(Stack Overflow Insights)
- 3.Titus Winters, Tom Manshreck, Hyrum Wright, Software Engineering at Google, Chapter 1: What Is Software Engineering? 文中关于软件工程与编程的区别，以及“时间、规模、权衡”的说法，来自这一章。(Abseil)
- 4.Veracode, AI-Generated Code: A Double-Edged Sword for Developers 及 GenAI Code Security Report。文中关于 AI 生成代码安全缺陷比例的数据，来自该报告相关公开介绍。(Veracode)
- 5.Docker, Docker Personal / Docker Desktop license information。文中关于 Docker Desktop 免费使用边界和大型组织专业使用需付费订阅的说法，来自 Docker 官方说明。(Docker)
- 6.Anaconda, Terms of Service。文中关于超过 200 人的营利组织使用 Anaconda Platform 需要 Business Plan 的说法，来自 Anaconda 官方服务条款。(Anaconda)
- 7.OpenAI, How to handle rate limits。文中关于速率限制和指数退避重试的说明，来自 OpenAI 开发者文档。(OpenAI 开发者)
- 8.GitGuardian, The State of Secrets Sprawl 2026。可作为 API Key、密钥泄露和 AI 辅助提交风险的延伸阅读。(gitguardian.com)
◆ ◆ ◆
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。
