社区开发者分享Vibe Coding定制开发经验

背景

文章源自 LINUX DO 社区的一场竞赛：佬友“星缘”发起“自创代码锦标赛”，要求参赛者为其开发一个“假期学习计划平台”，前三名瓜分 7000 LDC 奖励。作者为了锻炼自己的 Vibe Coding 能力（同时也想赢取奖励），决定参赛。开发过程中使用了 GPT-5.60-sol 和 GPT-5.6-terra 模型，以及 Codex 工具，并得到社区成员“黑与白”、“Lanln”、“any”的帮助。原文记录了从启动到最终上线的完整心路历程，并总结了在强定制化需求下进行 AI 辅助开发的经验教训。

核心内容

整个开发过程分为多个阶段，呈现了典型的“Vibe Coding”迭代节奏。

阶段一：使用 superpowers 全面覆盖需求（7月14日）
作者选择 React 相关技术栈，并通过 superpowers（一种全流程 AI 开发辅助工具）进行需求问询和开发。为控制 Token 消耗，作者没有将原始需求直接喂给 AI，而是逐步延伸需求，让 AI 依次处理。但该阶段暴露两个问题：一是公益站不稳定，单次开发周期长达 1～3 小时；二是 superpowers 内置的测试流程虽确保质量，但对于快速迭代的个性化项目而言过于繁琐——每个小改动都要走完整验证流程，效率低下。最终，一上午消耗了 $200 额度，作者决定放弃 superpowers。

阶段二：改用 ponytail + 自行拆解需求
作者发现比赛中其他项目存在“AI 自己造轮子”的问题——例如大转盘抽奖无法正常工作、无法实现真实翻页效果。实际上这些功能已有成熟库（如 react-pageflip 实现翻页、lucky-canvas 实现转盘抽奖）。因此作者移除 superpowers，引入 ponytail （另一种轻量辅助工具），将所有需求拆解后直接交由模型处理，手动测试，以提升效率。

阶段三：避免过度通用化，回归定制本质
项目初期作者试图为每个操作提供完整指引，但发现参赛用户已经清楚比赛规则，无需赘述。于是果断移除所有指示性词语，不再扩展通用功能，只按当前具体逻辑开发。

阶段四：看到竞品后的心态波动（7月14日晚）
作者发现其他参赛者已经完成了登录和云备份的全栈项目，UI 和功能远超自己的进度。他一度产生摆烂情绪，感觉前三无望，于 7月15日 0:30 遗憾入睡。

阶段五：投票开启后的紧迫感（7月15日）
佬友开放投票，已有 17 个项目参赛，较早提交的项目链接打开次数更高。作者意识到自己过于追求细节完美，耽误了时机。临时让 AI 将项目发布到 GitHub Page 展示，后续再按需优化。

最终总结
作者认为 Vibe Coding 开发个人项目容易失控，因为 AI 会持续提供“最优解”导致开发者贪多求全。对于他人需求，必须进行二次确认和需求拆解，不能完全交给 AI 自由发挥。AI 思考过多会使项目变得臃肿且令人厌恶。这次经历让作者明白：开发他人需求比开发自己的预想需求更能磨练 Vibe 技能，因为有明确的需求定义、思想碰撞和最终的项目验证。

关键要点

• 强定制化需求下，AI 容易过度思考：项目初期使用 superpowers 时，AI 为了提供通用最优解，自动增加了许多不必要的功能，导致 Token 消耗巨大（$200/上午）且开发周期拉长。
• 测试策略需要分层：superpowers 的每次小改动都走完整测试流程，不适合快速迭代。作者改为设定里程碑式整体测试，只在大版本完成后验证。
• AI 偏爱“造轮子”而忽略现有方案：直接让 AI 实现翻页和抽奖时，它选择了从零开发，结果出现 bug。改用成熟的 npm 库（react-pageflip、lucky-canvas）后问题解决。
• 需求拆解必须人工介入：作者没有将原始需求直接丢给 AI，而是逐步引导；同时根据用户实际认知水平（已知道规则）果断裁剪说明性内容，避免泛化。
• 心态管理是 Vibe Coding 的重要一环：看到竞品进度领先时，作者陷入沮丧和追求完美的怪圈，耽误了上线时机。尽早发布 MVP 比苛求细节更重要。
• Vibe Coding 不是完全放权：作者强调“摸透机理是关键”，开发者需要保持判断力，控制 AI 的作用范围，否则容易失控。

意义与影响

这篇文章真实还原了“Vibe Coding”在真实社区竞赛中的实践过程，对 AI 辅助开发的从业者具有以下启示：

1. 揭示了 AI 辅助开发的实际成本：不仅包括 Token 费用（$200/上午），还包括时间成本（反复测试、无意义的泛化）。提醒开发者合理选用工具和策略，避免被模型“带着跑”。

2. 强调了人工需求拆解不可替代：即使在最前沿的模型（如 GPT-5.60-sol）加持下，直接让 AI 自主拆解外部需求仍会产生偏离。开发者必须先理解需求本质，再分解为小块任务交给 AI，才能获得精准结果。

3. 提供了实用的替代方案：从 superpowers 切换到 ponytail，从 AI 自建轮子转为调用现有库，从全自动测试改为里程碑手动测试——这些具体操作对其他 Vibe Coding 学习者有直接参考价值。

4. 心理建设成为必要技能：竞争环境下，看到他人进展而产生的焦虑、完美主义导致的拖延，在 AI 快速迭代场景中被放大。作者的经历提醒开发者要管理预期，优先交付可用版本。

5. 社区竞赛的独特价值：LINUX DO 这种自发组织的有奖竞赛，为 Vibe Coding 提供了有约束条件、有同行压力、有验收标准的实战场景，比个人练习更能锻炼“需求理解-分解-交付”全链条能力。

总之，这篇文章不仅是个人参赛记录，更是对当前“AI 生成代码 + 人工把控”工作流的一次坦诚复盘，为社区提供了一线开发者视角下的最佳实践与避坑指南。