原文标题：《感谢胡彦斌老师的亲身示范，让更多人看到了 Vibe Coding 的能力边界》，题图来自：AI 生成

前几天，歌手胡彦斌亲自用AI“手搓”了一个粉丝社区App，这件事直接把Vibe Coding这个概念炸出了圈，在全网火得一塌糊涂。

说实话，如果少了“亲自”、“AI”、“手搓”这几个关键字，这事儿顶多在内娱板块有点水花，想上微博热搜免费位，基本没戏。

粉丝社区本身不是什么新鲜玩意。早在本世纪初，周杰伦、王力宏那会儿，就已经有歌迷俱乐部了——Web 1.0时代的私域流量池，粉丝运营的雏形。四分之一个世纪过去了，中外明星轮番下场试水，所以单看“建粉丝社区”这个动作，话题热度大概率是“有点，但不多”。

但现实就是这么有趣——任何事儿只要沾上AI，就像打了性能加成一样。“明星+AI+软件开发”这个极其罕见的组合，一下子让整件事双向出圈。两边的人都懵了：啊？搞编曲的跑来写代码了？

有流量的地方，阴谋论从不缺席。核心说法基本围绕“明星蹭AI热度”，比如“肯定是外包团队做的，自己挂个名”。平心而论，这种先把人往坏里想的思维逻辑也不是全无来由——在普遍认知里，演艺圈明星在计算机方面的技能树，基本点在了产品使用上，而不是开发。

不过，凡事总有例外，这个逻辑套在胡彦斌身上，恐怕不太适用。

翻翻B站UP主“雨哥到处跑”在2024年6月放出的采访视频，彼时的胡彦斌已经开始通过网上视频自学写代码了，语气里还带着点稀松平常的小自豪。要知道，两年前那个时间点，大语言模型虽然已经能辅助开发，但距离如今这种“自然语言直接构建完整应用”的Vibe Coding体验，差距还很明显。从这个角度看，当时他应该是真的在系统性学编程。

有意思的是，这个采访的时间点，恰好也是AI Coding领域的一个重要节点。

2024年6月20日，Anthropic发布了Claude 3.5 Sonnet，编码能力有了质的飞跃。当时不少程序员同行的评价是：“坏了坏了，这回可能真要失业了……”当然，按照正常逻辑推演，胡彦斌不太可能当时就已经玩上AI编程，大概率还是从HelloWorld起步的——否则今天上综艺，名字后面的头衔除了“歌手、创作人”，恐怕还得加上“当代Harness大师”。

另一个有力的证据是：这次上线的粉丝社区并不是iOS一端的孤岛，而是Web、Android、iOS三端齐发，一个相当完整的社区体系。不管你下班休息还是上班摸鱼，都能随时随地徜徉在与偶像互动的沉浸感里。

根据苹果应用商店的商详页信息，“彦火”这款App的开发商是上海沄镔文化传媒有限公司。再利用这家由胡彦斌本人控股99%的企业去工信部备案系统里查一下，会发现早在今年4月15日，这家公司已经完成了一个网站的备案审核工作。域名是 hybfansclub.com——毫无疑问，这就是胡彦斌粉丝社区的Web版。

扯远了，还是回到产品本身。互联网这行，终究是The product speaks for itself。

粉丝社区在今天已经是一个形态和功能都非常成熟的产品类型。从功能模块来看，无非是首页动态流、账户体系、成长体系、投票、用户社区、站内信、AI助手，以及简单的视频点播。

这些基本上都是互联网产品中最成熟的通用功能——成熟模块、开源代码俯拾皆是，而且后端逻辑不复杂，也不涉及需要强风控的订单和支付系统。

所以，粉丝社区几乎可以说是Vibe Coding最理想的落地对象，也恰好成为观察Vibe Coding能力边界的绝佳样本。

通过对三端产品的初步观察，发现了一些问题，值得拿出来，供所有对个人软件开发感兴趣的跨界创业者参考。

隐形功能缺失

有网友体验了iOS版本的“彦火”App后，提出了两个很核心的问题：用户手机号注册环节缺少风控，以及内容发布功能没有审核机制。

简单来说，手机号注册环节如果没有用户校验等风控措施，很容易被有心人用来做信息轰炸攻击，或者恶意消耗掉你的信息服务预存款。而内容发布时如果没有敏感词过滤和相关的内容机审乃至人审流程，运营方很可能面临法律风险——按照国内相关法规，平台有责任对内容进行审核并承担责任。

问题出在哪里？原因其实并不复杂。

胡彦斌老师在规划产品功能时，更多是从用户体验需求和平台运营需求出发：用户怎么注册、社区怎么互动、内容怎么展示、粉丝怎么成长。这些都是用户能直接感知到的功能，也是创作者功能层面的第一优先级。

但风控、合规、审核、性能优化这类能力，属于互联网产品里的“隐形功能”。它们在用户端几乎不存在感，可一旦缺失，问题立刻暴露。而这些功能存在的必要性，往往需要经历过完整的互联网项目从0到1、从规划到运营的全过程，才能建立起足够全面的认知——也就是我们常说的Know How。

对于一个刚刚跨界到产品负责人角色的创作者来说，要求他在第一次做产品时就把这些事考虑得滴水不漏，完全是Mission Impossible。

作为提供Vibe Coding能力的工具，不管是Cursor还是Claude Code，其核心价值的本质都是在回答问题，而不是定义并扩展问题。它们能很好地完成你明确提出的需求，却很难主动发现那些从未被用户提出的问题。你让它开发社区，它就开发社区；你让它实现签到，它就实现签到。但它不会突然停下来问你一句：“这个社区需要内容审核吗？”或者“你的信息验证码接口有考虑防刷吗？”

从这个角度看，“彦火”暴露出的这些问题，与其说是开发能力的问题，不如说是产品规划能力的问题。而这恰恰是今天AI最难替代、也是Vibe Coding最容易被忽视的一环。

视觉效果体验未被充分验证

再看粉丝社区的Web端主页。视觉效果和配色很有沉浸感，但同时也让人惊异地存在一些肉眼直接可见的小问题。

这些问题在测试环节大概都属于P3以下的重要程度，却明晃晃地挂在首页上：

一眼扫过去，页面布局存在诸多小问题：错误的折行、导航栏没有向上对齐、导航栏文字中英文间距不一致、新闻模块中新消息标签向侧方挤压标题正文内容等等。

这些问题的背后，揭示了Vibe Coding的另一个短板：不使用正向开发流程，容易出现必要工作环节的缺失。

查看首页的源代码，呈现出的代码风格确实很有AI风味。样式里存在大量直接写死的尺寸、间距和定位值，布局更多依赖具体像素，而不是通过更稳健的响应式约束去适配不同设备。代码看起来像是为了让当前页面“先长得对”，而不是围绕多分辨率、多浏览器、多内容长度去做系统性的边界处理。

原因也不难理解：AI在写代码这块向来是贴着需求底线走，主打一个绿色省电节约Token，更倾向于优先满足当前需求，而不是预先考虑各种边界条件。所以，不考虑分辨率因素、直接将数字写死的情况时有发生。这导致页面很可能在胡彦斌自己的开发和测试环境上是正常的，但切换到其他人的主力设备上，比如1080P分辨率下的Chrome，页面就直接变形了。

AI的问题可以通过增加更详细的要求来尝试修正，但关键工作环节的缺失，才是这个问题到了上线还依然存在的根因。

传统的正向开发模式中，产品经理完成功能定义后，交互人员会根据需求进行版式设计并制作效果图。开发人员按效果图开发，先自测，自测通过后提测到测试部门；测试人员再撰写test case，进行有针对性的测试工作。但在胡彦斌老师一个人完成从产品定义到上线全流程的情况下，AI并没有起到结合视觉设计要求进行测试的能力。视觉验收和多端测试这两部分工作量的缺失，才导致了页面的带病上线。

页面直接静态挂载MP4文件

这一点其实在和小伙伴讨论时有些分歧，不一定算是Vibe Coding的短板，可能只是一种工程取舍。

支持当前实现方式的声音认为：这几个视频本身是免费内容，初期用户量有限，暂时不上完整的点播系统也无伤大雅，等后期VV数据起来了再替换也来得及。这个逻辑本身没什么问题。

但另一方的声音聚焦在一个新问题上：这个取舍，到底是主动思考后做出的决定，还是一个从来没有被提出过的问题？以胡彦斌的粉丝量级，一旦三端产品全面推广，这个模块大概率很快就要迭代。而现在开源或可商用的视频点播方案已经相当成熟，接入的开发成本并不算高。既然早做晚做都要做，而且也不难做，为什么不现在就做好呢？

对于一个目标是商用的产品来说，1.0上线时宁可砍掉部分非核心功能，也应该保证已有模块的成熟度。这个优先级的判断，恰恰是Vibe Coding流程里最容易缺席的一环。

最后，还是要认真感谢一下胡彦斌老师，为Vibe Coding走向更广阔受众群体做出了杰出贡献。

作为一个音乐人，仅凭借AI的加持就能将一个跨三端的互联网产品交付上线，这本身就是一种实实在在的成功。如果回到两年前他接受采访、坦言正在学习编程的那一刻，恐怕连他自己都不会相信，AI的能力能在这么短的时间内突飞猛进到这个程度。

但这个案例同样清楚地展示了今天Vibe Coding最真实的能力边界：AI可以写代码、生成页面、搭建数据库，但它没办法站在项目全局，帮你把该问的问题都问一遍。它本质上还是一个在回答问题、而不是在定义问题的系统。

局部任务里，它已经相当能打；但主动发现问题、提出问题，并为这个判断承担责任，这件事今天还轮不到它来做。

说白了就是：AI目前还没有掌握提问的艺术。

这就意味着，在AI Coding时代，真正昂贵的能力不再是写出好代码，而是知道该问什么问题。代码越来越便宜，好问题越来越值钱。软件开发链条上每一个角色的价值，也正在向这个方向重新聚拢。

最后，忍不住想问问胡彦斌老师：您那还缺产品经理么？待遇要求不高，管个演唱会门票就行……后排，后排的就行：)