24小时AI编程实录：蜜月期何时结束？

如果AI真能替代程序员，为什么用AI写代码的人还在熬夜改bug？

一位有Flutter经验的开发者决定用24小时纯AI驱动开发一款习惯追踪App。他没有选择炫耀成品截图，而是记录了整个过程中AI到底帮了什么、在哪里掉链子——这份诚实的记录，可能比那些"3小时上线"的帖子更值得看。

起点：一个被验证过的需求缺口

作者想做的不是新概念。习惯追踪App满大街都是，但他想要一个特定组合：按生活领域分组（健康、工作、人际关系、个人成长），且支持周节奏而非日节奏。

"每周习惯，不是每天。"

这个需求听起来简单，但他找遍现有产品，没有一款完全符合心意。这是典型的"痒点创业"——不是做没人做过的事，是把已有品类往自己的使用场景再切一刀。

工具组合：Claude负责架构规划和代码生成，Cursor作为编辑环境，FlutterFlow快速搭建UI框架。作者特意注明："我懂Flutter，这很重要。后面会解释。"

周二晚上9点开工。事后看，这个起步时间是个坏主意。

前4小时：AI的高光时刻

与Claude的架构对话" genuinely useful（真正有用）"。作者描述需求后，Claude推荐了状态管理方案（Riverpod）、数据模型和文件夹结构。

作者的原话是："质量大概比我自己的方案好20%，因为它捕捉到了一个数据建模的边界情况，我自己很可能会后期才撞上。"

基础数据层的代码生成速度很快。模型、提供者、本地持久化配置——Claude写了大部分，而且"actually correct（真的正确）"，不是"正确但藏了三个bug等你找"那种正确。

凌晨1点，数据层跑通了。时间表看起来还hold得住。

转折点：蜜月期结束的标志

UI代码的质量开始暴露问题。Claude生成的代码"fine（还行）"——能渲染、能交互，但"感觉不对"。

具体麻烦：

• 间距错误
• 颜色实现技术上正确，视觉上偏差
• 导航逻辑有隐蔽bug：从嵌套页面返回时，滚动位置无法正确恢复

最后一个bug花了40分钟。Claude"自信地"推荐了三个方案，全部无效，第四个才解决。

作者在这里点出了一个关键认知成本：

「当你自己写代码，你心里有它的模型。当AI写代码，它工作直到不工作，然后你得在时间压力下反向工程别人的逻辑。」

FlutterFlow的部分更快，但导出代码"messy（混乱）"，与手写部分难以干净集成。

上午10点，比心理预期落后6小时。

AI的舒适区与舒适区外

作者总结了AI真正擅长的领域：

• 写样板代码
• 生成测试数据
• 解释文档（"Riverpod的ConsumerStatefulWidget怎么工作"）
• 调试时提供假设（"可能是X，检查Y"）

以及AI搞不定的事：

• 需要产品判断的决策（"这个按钮应该放这里还是那里"）
• 跨系统的复杂集成（FlutterFlow导出代码与手写代码的接缝）
• 需要理解完整上下文的bug（那个滚动位置问题）

下午6点，App基本功能可用，但"polish（打磨）"为零。作者做了取舍：砍掉社交分享、数据导出、通知提醒，只保留核心习惯追踪。

晚上9点，24小时截止。App在作者自己的手机上运行，但还没上应用商店。

真实产出核算

作者算了一笔诚实账：

纯手写预估时间：40-60小时
AI辅助实际用时：24小时（其中约8小时在修AI生成的代码）

净节省时间：约50%，但"不是那些帖子让你相信的90%"。

代码质量：数据层" surprisingly good（出奇地好）"，UI层"需要大量手工调整"，整体架构" solid（扎实）"但"不是我想要的优雅"。

一个反直觉的发现：AI让开始变容易了，但让完成变难了。因为起点太低，你会低估后期的摩擦成本。

那"懂Flutter"为什么重要？

作者回到开头埋的伏笔。没有Flutter经验，他无法：

• 判断Claude的Riverpod建议是否合理
• 识别FlutterFlow导出代码的问题
• 在AI的四个方案里快速排除三个
• 决定哪些bug必须修、哪些可以砍功能绕过

「AI是加速器，不是替代品。它放大你的能力，但也放大你的盲区。」

作者观察到一个现象：AI生成的代码"看起来对"，这种表面正确性会延迟你发现真正问题的时间。有经验的人能更快嗅出"哪里不对"，新手可能在错误方向上走得更远。

给想尝试的人的具体建议

基于这次24小时的压力测试，作者提炼了几条可操作建议：

1. 从小功能验证开始，别直接上完整App。先用AI做一个数据流闭环，确认工具链跑通再扩展。

2. 保留手工调整的心理预算。AI生成的UI代码 expect 需要30-50%的重写时间，不是即插即用。

3. 混合工具要谨慎。FlutterFlow+手写代码的组合在接缝处消耗了大量时间，单一工具链可能更省。

4. 晚上9点别开工。疲劳会放大AI的"自信错误"带来的挫败感。

这件事到底改变了什么？

作者没有给出"AI编程已死"或"程序员末日"的极端判断。他的结论是务实的：

AI把个人开发者的可行性边界往外推了一步。以前需要40小时的MVP，现在24小时能摸到。但"摸到"和"做好"之间，仍然有陡峭的悬崖。

对于习惯追踪这类成熟品类，AI让"做自己的版本"成本骤降。但代价是：你会在AI的决策和自己的品味之间反复拉扯，这种拉扯本身是一种新型劳动。

最有趣的暗示在结尾：作者提到这个App他"还在继续用"，但"还没决定要不要上架"。24小时能造出一个可用的私人工具，却未必能造出一个经得起陌生用户审视的产品——这个差距，AI暂时没有填上。

当AI让"做出来"变得廉价，"为什么做"和"为谁做"的判断会不会变成更稀缺的能力？如果每个人都能24小时搓一个App，什么样的产品决策才能让你从噪音里浮出来？