胡彦斌用AI做了个App,也许你能做得更好?

歌手胡彦斌用 Claude Code + VSCode 开发了三个产品：公司运营系统、自己做音乐的系统，以及粉丝社区 App「彦火」。

「彦火」功能覆盖巡演信息展示、日常打卡、互动交流等，目前已开启内测。帖子发出后评论区迅速热闹起来——毕竟一位华语乐坛的唱作人开始苦修 Vibe Coding，本身就足够有话题性。

评论区两极分化：一半人兴奋——连歌手都能做 App 了，我是不是也行？另一半人已经打开工具，开始照猫画虎。

然后，大多数人撞墙了。

你撞的那堵墙叫”软件熵”

你一定经历过这条曲线：

第一天，你用中文描述了一个想法，AI 吐出一个完整页面，你兴奋得睡不着。第一周，功能越加越多，速度惊人，你觉得自己找到了捷径。第二周，你加了个新功能，某个旧功能神秘消失。你让 AI 修，修好了这个，另一个又崩了。第三周，你已经分不清哪里出了问题，AI 也分不清——因为你们两个都在看一坨没有任何结构的代码团。

你开始怀疑：是我的提示词不够好？是我选的工具不对？

都不是。

这个现象，软件工程领域几十年前就有了名字：软件熵（Software Entropy）。

事物总是自动走向混乱。代码也一样。如果你不主动管理系统的设计，它就会腐烂——而 AI 的出现，只是让腐烂的速度快了十倍。

一个失败的案例

Reddit 上有个帖子，一个独立开发者花了 7 个月，纯靠 Specs-to-Code 构建 SaaS 产品。从不读代码，只写需求，只改提示词，出错了就重新生成。

最终结果？

AI 把所有业务逻辑全塞进一个 1600 行的超级文件。没有模块，没有边界，没有测试。逻辑四处缠绕，改哪里都会崩。到后来，连 AI 自己都读不懂这个文件了——上下文窗口根本装不下这团乱麻。

7 个月，归零。

这不是个例。这是”只写需求让 AI 出代码、出错了继续生成”这条路的必然终点。

他和胡彦斌的差距在哪里？

早在 2024 年，胡彦斌就已经沉迷看软件教学类视频，甚至开始学怎么写代码——要知道，Karpathy 提出 Vibe Coding 的概念是 2025 年的事。

这是关键。他不是今天看了教程、明天就做出三个产品的人。他花了将近两年，先理解软件是怎么回事，再用 AI 来加速。

他做的是：先建立设计思维，再使用 AI 工具。

大多数人做的是：跳过设计思维，直接使用 AI 工具。

顺序不同，结局天差地别。

AI 工程师和教育者 Matt Pocock 说过一句话，应该印在每个 vibe coder 的屏幕上：

代码并不廉价。糟糕的代码，现在比任何时候都更昂贵。

AI 是一个放大器——给它一个好系统，它把你的效率放大 10 倍；给它一团乱麻，它把你制造混乱的速度放大 10 倍。

还有一件更可怕的事：AI 没有痛觉。

人类程序员看到乱代码会难受，这种不适会逼着人停下来整理。AI 不会。它唯一的目标是”让这次的需求实现”——哪怕要打三层补丁、绕过两个逻辑矛盾，它也面不改色。它在以令人窒息的速度帮你积累技术债。

五道墙，和真正翻过去的方法

以下是用 AI 编程最容易撞的五道墙，以及真正有用的解法。这些解法全部来自几十年的软件工程智慧——在 AI 时代，它们不是过时了，而是比任何时候都更管用。

第一道墙：AI 做的东西完全不是我想要的

你脑子里有个清晰的想法，但 AI 生成的东西总偏一截。改提示词，它改一点；再改，又偏向另一边。最后你们谁也不知道在做什么。

根本原因： 你和 AI 之间没有建立真正的共识。其实就连你自己，也不完全清楚自己想要什么——只有在被追问的过程中，想法才会变得清晰。《程序员修炼之道》里有句话说得直白：“没有人确切知道自己到底想要什么。”

解法：在动手之前，先让 AI 审问你。

把这段话发给 AI：

“在写任何代码之前，先无情地采访我关于这个计划的每一个细节，直到我们达成共识。沿着设计树的每一个分支向下走，逐一解决决策之间的依赖关系。”

AI 会变成审讯者，抛出几十个问题：这个功能给谁用？用户点这个按钮，期望发生什么？失败了怎么处理？这两个功能有没有先后依赖？

这个过程很烦，但它会帮你们建立起真正的共享设计蓝图——而不是你脑补一套、AI 脑补一套，各做各的。

第二道墙：AI 总搞错你的专业术语，每次都要重新解释

你的 App 里有很多特定词汇。比如”打卡”在你这里不是普通签到，而是一种触发积分的特殊行为。但 AI 每次都按普通逻辑处理，你要反复解释，耗尽耐心和上下文额度。

根本原因： 你和 AI 之间没有共享词汇表，就像两个来自不同公司的人，同一个词代表完全不同的东西。

解法：建一个项目术语文档，每次对话都带上它。

在项目里新建一个 CONTEXT.md，把所有重要概念定义清楚：

# 项目术语表**打卡（Check-in）**：用户在 App 内完成的特定互动行为，触发后自动获得 10 积分，每天最多执行 3 次。**彦值（Points）**：粉丝社区内的虚拟货币，可兑换周边。**巡演信息（Tour Info）**：包含城市、时间、票务链接的结构化数据，仅管理员账户可修改。

每次开始新对话，把这个文件发给 AI。从此以后，你们说的是同一种语言。这来自软件工程的领域驱动设计（DDD）里”统一语言”的概念——用来解决人与 AI 之间的沟通鸿沟，同样精准有效。

第三道墙：AI 一口气写了 500 行，一运行全是错

AI 很自信地生成了完整功能，你满怀期待地运行，红色报错铺满屏幕。让它修，修好了一个，冒出两个。你们陷入无尽的打地鼠循环。

根本原因：《程序员修炼之道》里有一个完美的比喻：“车速超过了车头灯的照明范围”——没有反馈机制，AI 会一路猛冲，冲进黑暗里。反馈的速度，就是你的限速标志。

解法：强制使用测试驱动开发（TDD），让 AI 小步快跑。

告诉 AI：

“我们用 TDD 的方式来做。你先写一个会失败的测试，我确认测试逻辑正确后，你再写刚好能让测试通过的最小代码量，然后我们再重构优化。”

流程：

1. AI 先写测试：test('用户打卡后应获得 10 积分')
2. 你确认这个测试逻辑是否正确
3. AI 写代码让这个测试通过
4. 绿灯之后，再加下一个功能

每一步都有验证，AI 永远在”车头灯照明范围”之内。这不是把事情复杂化，这是让 AI 始终在最佳状态工作的唯一方式。

第四道墙：代码越来越难改，加任何功能都提心吊胆

你发现改一个地方，另一个地方莫名其妙出问题。整个代码库像一张网，牵一发动全身。AI 的每次修改也越来越保守，补丁摞补丁。

根本原因： 代码库里充满了”浅模块”——逻辑碎片散落四处，没有清晰边界。AI 在这样的代码库里就像在乱线团里找线头，越找越乱，最终进入”愚蠢区”：开始忘记上下文、产生幻觉、自相矛盾。

解法：重构为”深模块”架构。

这个概念来自 John Ousterhout 的《软件设计的哲学》。深模块就是把复杂的内部逻辑，藏在一个极其简单的对外接口背后。

以积分系统为例，不要把积分计算逻辑散落在每个功能里，而是建一个统一的模块，对外只暴露三个方法：

interface PointsSystem {award(userId:string, action:string):Promise<void>;// 给积分deduct(userId:string, amount:number):Promise<void>;// 扣积分getBalance(userId:string):Promise<number>;// 查余额}

内部如何计算、如何防刷分、如何记录日志——全部藏在模块里面，外部任何功能只能通过这三个方法交互。

之后要加”连续打卡奖励”？只改积分模块内部，其他功能完全不受影响。AI 也会因为接口清晰而写出更好的代码——因为它的”注意力预算”始终集中在一个小范围里，保持在”聪明区”。

第五道墙：AI 产出太快，我的大脑跟不上，越做越焦虑

AI 每次生成几百行代码，你知道应该 review，但根本看不完。勉强看，又读不懂内部逻辑。你开始恐慌：万一有 bug 我发现不了怎么办？这种焦虑会让你的判断力越来越差，陷入恶性循环。

根本原因： 代码没有清晰边界，你必须读懂每一行才能确认它是安全的。

解法：用”灰盒原则”管理复杂度——你设计边界，AI 填充内部。

如果你已经把代码组织成了深模块，你就可以把它们当作灰盒来对待。

你不需要读积分模块内部的每一行逻辑。你只需要确认：对外的接口设计是否正确，测试是否覆盖了所有关键情况。 只要接口外的测试通过，内部的实现就值得信任。

你是战略层，AI 是战术层。你设计地图，AI 填砖头。

胡彦斌能做出三个产品而不是一个，很可能正是因为他从一开始就在做这件事——为每个系统设计清晰的边界，而不是逐行跟踪 AI 的输出。

现在给你看成功案例的具体全貌

同样是做一个带积分的粉丝 App，一个用架构思维的人是这样做的：

第一天，他没有写一行代码。他让 AI 对他进行了两小时的”审讯”，把所有业务逻辑问清楚，整理成一份设计文档。

第二天，他设计了三个深模块的接口边界：积分系统、内容系统、通知系统。每个接口只有三四个对外方法，内部可以处理所有复杂逻辑。

接下来的每一天，他让 AI 一个模块一个模块地实现，每次先写测试，再写实现，每次只处理一个完整的端到端功能切片。

三周后，产品上线。六周后，他加了连续签到的 streak 奖励功能——只需改动积分模块内部，其他功能完全不受影响，一个下午搞定。

这不是因为他写代码更厉害。这是因为他懂得如何指挥 AI，而不是祈求 AI。

那些永远不会被 AI 替代的东西

AI 领域先驱 Andrej Karpathy 有句话说得很准：

你可以外包打字，但不能外包理解。

AI 永远无法替你做的判断：

• 这个架构五年后还能用吗？
• 这两个模块该合并还是该拆分？
• 现在该重构，还是该继续往前冲？
• 用户真正需要的，是这个功能还是另一个东西？

这些判断，正是你学习传统软件思维时真正训练的能力——不是语法，不是框架，而是如何分解复杂问题，如何设计边界，如何管理变化。

这些能力在 AI 时代的价值，不是变低了，而是变得比任何时候都更稀缺、更值钱。因为现在只有真正懂这些的人，才能驾驭 AI 这头猛兽，而不是被它拖着跑。

三个重要问题

把你现在正在做的项目打开，问自己三个问题：

1. 如果要加一个完全不同的功能，我知道应该改哪里吗？
2. 我的代码里，有没有哪个模块可以被独立替换，而不影响其他部分？
3. 我有没有任何方式，能验证 AI 写的代码是否正确？

如果这三个问题你都答不上来，你的项目就已经走在了那 7 个月归零的路上。

希望这篇文章帮你及时调头。