从复制粘贴ChatGPT到发布真实应用：六个月的Vibe编码

六个月前，我还在为“真正的程序员”会如何看待我的方法而焦虑。但现在，我明白我们都只是想构建真正可用的东西。我精通R语言，涉猎过Laravel和前端技术，但要掌握所有现代网页框架？说实话，我有限的时间不值得。我更愿意专注于构建和推广真正对用户有用的产品。高效并不意味着降低质量，而是找到不同的实现路径。\n\n我想发布生产就绪的软件，而不必花费数年时间掌握每个新框架。随着时间推移，我发现了十个关键实践，帮助我加快高质量代码交付。首先，处理复杂工作时一定要制定计划。我使用Cursor的Plan模式配合Sonnet 4.5，因为它在写代码前会提出智能问题，帮助我确定合适的技术栈（Next.js 15、TypeScript、Tailwind CSS），避免后期昂贵的重写。我的流程是：在Chat模式思考，在Plan模式规划，然后在Composer执行。\n\n另一个改变游戏规则的是使用Claude Code保持自我审视。我安装它来从新角度审查项目——检查架构、安全、代码质量和测试覆盖率。请求评分和建议让我拥有清晰的改进路线图，保存为markdown文件，随后转成GitHub Issues。即使是AI的第二双眼睛也非常重要。\n\n实际编码时，我切换到Composer 1，因为它速度极快，且与Sonnet 4.5相比代码质量差异几乎无感。我用Sonnet 4.5进行深思熟虑的规划，但大部分工作在Composer完成以节省时间。我还从最熟悉的领域开始项目——比如我最新的应用Mindarin，先作为R包构建。这让我能基于数据分析背景给出非常具体的指令，快速达到最小可行产品（MVP），然后再转成Next.js。熟悉的起点帮助我更好地设计提示，快速迭代。\n\n测试从一开始就是必需的。我对每个功能采用测试驱动开发，运行数百个测试（单元、组件、钩子、端到端），大部分由Cursor编写。测试不是负担，而是活文档，防止AI破坏已工作的功能。快速发布时，测试就像护栏。\n\n仅有版本控制还不够，整个GitHub生态系统至关重要。GitHub Actions并行运行测试，及早捕捉回归。Issues成为优先级路线图，Cursor甚至能通过GitHub CLI在规划对话后生成它们。项目按优先级组织这些Issues，我总知道下一步该做什么。\n\n我学会了总是在Ask模式提问，而不是在Agent模式头脑风暴。Ask模式帮助我理清问题，而不会让AI过早编码。就像我是建筑师，工人还没开始工作。调试也不再拖慢我——我一天推送主分支数十次，大多数CI初次运行失败，但Cursor修复速度快，尤其当我提供实际失败日志而非随机网页复制时。\n\n我完全停止手动写文档。Cursor现在写我的提交信息、README文件和内联文档。这节省了大量时间，让我专注于构建用户真正想要的功能。最后，大声说出我的想法提升了提示质量。Cursor的语音模式不错，但我更喜欢superwhisper——它第一次就准确识别我的语音，过滤填充词，让我更好地解释上下文和边缘情况。\n\n这十个习惯让我从复制粘贴ChatGPT答案，走向真正发布应用。我仍在学习，期待听听那些从业更久的朋友，尤其是第一年后这种vibe编码方法带来的变化。