Gemini 几分钟做出院子 App，但麻烦也从这里开始

The Verge 高级评测作者 Allison Johnson 最近做了一个很典型的小实验：院子快失控了，于是让 Gemini 帮她做一个庭院养护 Android 应用。

她在 Google AI Studio 里写下一段自然语言提示词。需求包括任务管理、养护建议、天气参考、图片识别诊断植物问题。几分钟后，一个可运行的预览出现了。旁边还有一个 bug 提示，以及一个“修复”按钮。

这个画面很反常，也很有代表性。AI 已经能把“我想要一个 App”变成一个能点开的东西。但真正的问题随后才来：这个 App 能不能帮人少干活，而不是多添一个要维护的东西。

我的判断很简单：AI 降低了做软件的起步门槛，但没有降低定义问题和验证现实的成本。院子不会因为界面生成得快，就变得更好打理。

发生了什么：一个院子问题，被做成了软件问题

这个项目的起点很普通。作者搬进房子八年后，院子里的杂草、灌木和花坛逐渐失控。她想要一个随身工具，把庭院分区、植物档案、一次性任务、周期任务和植物诊断放在一起。

Google AI Studio 是 Google 提供的生成式 AI 工具入口。Gemini 可以根据提示生成代码，也能直接给出应用预览。这类用自然语言“氛围编程”的体验，过去一年在 Cursor、Replit、GitHub Copilot、Bolt 等工具里都很常见。

它最迷人的地方，是把第一步变得很轻。不会写代码的人，也能得到一个像模像样的原型。

但原型不等于可用产品。作者的庭院 App 很快暴露出几个问题：

这张表能说明一个常见错觉：AI 很擅长做出“完成感”。页面有了，按钮有了，栏目也有了。

但现实会追问更细的事：太阳底下看不看得清？任务能不能改？日期能不能选？天气数据是不是当天的？这些不是装饰，它们决定工具能不能真的用。

对普通用户来说，这里最该停一下。不是每个生活问题都需要做成 App。很多时候，一个聊天窗口、一组建议、一个 Google Keep 待办清单，反而更稳。

为什么重要：AI 最有用的地方，未必是生成完整 App

作者最认可的功能，是 AI plant doctor。她上传了一张状态不佳的杜鹃花照片，Gemini 给出一份植物健康报告。

报告把问题指向景观布和河石。景观布可能因为积土和堵塞，让根系缺氧、干燥；河石在阳光下升温，可能让根部受热。

这不能被当成专业园艺结论。原文只说明，作者认为这个建议有用。她清理河石、剪开景观布、除草和修剪后，几天内看到枝条上有新叶。

但这个细节很关键。真正帮上忙的，不是那个完整 App，而是一次具体诊断和一组行动建议。

这也给 AI 工具划出了一条边界。AI 很适合做“临时顾问”：看一张图，解释可能原因，列出下一步。它把知识、图片和行动建议揉在一起，门槛低，反馈快。

可一旦用户要求它做成一套软件，事情就变了。用户同时变成产品经理、设计师、测试员和维护者。需求没想清楚，AI 只会更快地把模糊需求固化成界面。

对想用 AI 解决个人生活问题的人，比较现实的做法是先分两步：

这不是给 AI 泼冷水。恰恰相反，它说明 AI 编程已经有实用价值。只是价值不一定出现在“做了一个 App”这个瞬间，而是在它能不能减少人的判断成本和行动成本。

如果工具让人花掉一下午好天气反复提示、修 bug、换版本，那它至少在这个场景里没有省下最稀缺的东西：时间和体力。

谁最受影响：非专业用户和小团队都要学会收口

这篇体验最相关的读者有两类。

一类是普通用户。你可能不会写代码，但现在已经能让 AI 帮你做预算表、读书追踪器、健身记录器、家庭库存工具。入口变低后，最容易犯的错是把小问题系统化。

更稳的动作是延后“做 App”。先问三个问题：这个问题是不是会反复出现？现成工具是不是已经够用？如果 AI 生成的东西坏了，我愿不愿意继续修？

另一类是小团队和产品人员。AI 原型可以加快试错，但不能跳过验收。尤其是任务管理、数据来源、权限、异常处理、可访问性这些地方，不能只看页面是否生成。

接下来要看的，不是这个庭院 App 会不会进 Play Store。作者已经表示大概率不会。

更该看的，是 Google、OpenAI、Anthropic 这类工具提供方能不能把“生成代码”和“现实校验”接起来。比如自动提醒文字对比度太低，检查任务是否可编辑，提示天气功能缺少实时数据源，或者在生成后给出可用性清单。

如果这些校验跟不上，AI 编程会继续制造大量“能跑但不好用”的个人软件。它们看起来像工具，实际是新的家务。

回到开头那个院子。AI 确实把一个想法变成了应用，也确实给出了一条有用的植物建议。但院子里还有泥、太阳、杂草和河石。软件能不能帮忙，要看它有没有贴住这些东西，而不是看它生成得有多快。