我刚刚为自己开发了一款功能齐全的安卓应用，一款专为摩托车骑行者设计的天气查询应用——全程未手动编写任何代码。以下是它的外观。
看起来很棒，对吧？但在你庆祝之前，让我先提醒你一点。作为开发者，我有幸审查了该应用的代码和设计。乍一看，我印象深刻——惊艳的视觉效果、流畅的用户界面，一切都显得非常精致。然后我仔细查看了底层代码……这时真正的惊喜才出现。代码？我只能说，这绝不是你想要发布的——甚至不值得分享的代码。让我来告诉你为什么。
如何自动生成整个Android应用程序
你是否曾想过如何从零开始自动编写一个 Android 应用程序？我跟着一个 YouTube 教程来探索这一点，但与使用 Cursor Composer 不同，我使用了 VSCode 搭配 Claude Sonnet 3.7 —— 结果如上所示，令人惊讶地令人印象深刻。
但这里有一个提醒：
不要尝试使用VSCode从头开始生成整个Android项目。我尝试过，结果是一场噩梦。我遇到了大量Gradle问题、未解决的错误以及过时的XML布局文件。
以下方法效果更好：
- 从 Android Studio 开始：
使用 Android Studio 创建一个干净的 空项目。这将为您提供一个基于最新配置和结构的可靠基础。 - 切换到 VSCode 进行编码：
在 VSCode 中打开同一项目文件夹。在此，你可以：
– 使用 Claude Sonnet 3.7(或你首选的 AI)自动生成代码。
– 根据需要让它修复或重构代码。 - 使用 Android Studio 编译和测试：
使用 Android Studio 构建项目并在模拟器上运行以验证输出。
在迭代和完善应用的过程中，重复步骤 2 和 3。在此过程中，我频繁将更改提交到 Git，以便在需要时轻松回滚——尤其是在 AI 生成的更改效果不佳时。
我使用的提示词
在高层次上，这些是我使用的提示词
使用 API 获取未来 7 天的本地天气条件并在屏幕上显示
1. 创建一个算法，将这些天气条件(温度、降雨概率和风速)结合起来
2. 根据骑行条件生成百分比评分(0%为差，100%为完美)
3. 显示7天骑行条件百分比评分，其中骑行评分百分比对应天气卡颜色从红色(差)到绿色(完美)及中间所有颜色。同时让应用界面看起来非常美观。能否让应用首先检测当前位置并获取天气信息。
在屏幕顶部显示位置名称。
我没有看到屏幕上显示位置名称。请添加城市名称。
然而，实际上还有更多需求，例如修复错误等，具体如下：
使用API获取未来7天的本地天气状况并在屏幕上显示
在尝试获取天气信息时，屏幕上出现错误提示：“无法解析主机名’api.openweathermap.org’：该主机名未关联任何地址”。请修复此问题
在尝试获取天气信息时，屏幕上出现错误提示：“网络错误：无法连接到服务器。请检查您的互联网连接”。请修复此问题
出现HTTP错误401：未授权。请修复此问题
初始化Git并配置名称为<NAME>，邮箱为<EMAIL@SAMPLE.COM>。设置Android的.gitignore文件。
1. 创建一个算法，结合以下天气条件：温度、降雨概率和风速
2. 创建一个百分比评分，用于评估当天骑行的适宜程度(0%表示不适宜，100%表示完美)
3. 显示7天骑行适宜度的百分比评分，0%表示不适宜，100%表示完美。修复编译时出现的“未解析引用’fillMaxHeight’”错误
将代码添加到Git并提交，附上适当的提交信息
能否为天气卡片添加颜色编码，从红色(不适宜)到绿色(完美)，以及骑行评分百分比之间的所有中间颜色。同时让应用界面看起来非常美观。
存在以下错误，请修复
WeatherComponents.kt
未解析引用 ‘Air’。
未解析引用 ‘WaterDrop’。
未解析引用 ‘WbSunny’。
未解析引用 ‘WbSunny’。
未解析引用 ‘Air’。
未解析引用 ‘WaterDrop’。
未解析引用 ‘WaterDrop’。提交时附上适当的提交信息
能否让应用程序首先检测当前位置，并获取天气信息？
代码中存在多个错误，请修复它们。
在屏幕顶部添加位置名称。
我没有看到屏幕上显示名称。请添加位置城市名称。
以正确提交信息提交到Git
提交更改，附上正确提交信息
关于如何自动生成代码的全部操作已完成。代码位于此处(注：此为私有代码，仅供我个人访问，如前所述，生成的代码不属于“可共享代码”，具体原因将在下方说明)。
让我们回顾一下，并分享我认为的优点、缺点和令人震惊的地方。
优点
令人印象深刻的干净代码结构
乍一看，生成的代码整体结构出人意料地井井有条。它似乎遵循了模型-视图- presenter(MVP)模式，实现了清晰的职责分离。这无疑是一个良好的起点，尤其对于维护干净且可扩展的代码而言。
位置检测与权限请求
我只需提示 AI 代理检测并使用当前位置，它便在应用启动时自动生成必要的位置权限请求。这可能参考了某个可靠的示例或文档完善的模式作为指导。真棒！
注释完善的代码
总体而言，每个函数都注释完善，函数名和变量名均采用清晰易读的人类可读语言。以下是一个处理天气计算的函数示例。
总体而言，即使只是快速浏览，结果也令人非常满意。一个非程序员也会感到非常印象深刻。
缺点
作为开发者，我们倾向于仔细查看代码的细节。经过一番挖掘，我发现了一些质量较差的代码片段——这绝对不是我会在生产环境中批准的内容。
未使用的代码
我在代码中发现了多个未使用的导入语句——这些并非关键问题，且可轻松清理。然而，我还注意到部分代码针对过时的Android版本，由于项目已目标更高的API级别，这些代码已不再必要。
这让人感觉部分代码可能从较早的StackOverflow示例中复制后进行了修改。
遗留的未使用类
我发现了一个包含近 70 行代码的类，该类在任何地方均未被引用。它很可能是早期 AI 提示生成的，随后在被替换或被认为不再必要后被遗留下来。
虽然AI可能在提示下检测并移除这些代码，但非程序员——或未仔细审查代码的人——很容易忽略它们。
我们使用哪种日志记录方法？
起初，看到一个LogUtil类让我印象深刻——这让人觉得AI已将所有日志记录功能重构为一个集中式工具类。
然而，在浏览代码时，我发现日志记录实践不一致：部分区域仍直接使用Log.d，而其他地方甚至依赖println。
这种不一致性表明，代码很可能是由多个来源拼凑而成的。虽然它能够正常运行，但如果没有标准化，要在整个应用程序中维护和整合日志将面临挑战。
未重构的代码
令人惊讶的是，该应用包含五个不同的网络服务类——每个类都使用自己的 OkHttpClient 实例。更令人担忧的是，每个服务中都重复配置了客户端设置。
如果库需要更新，我们必须手动修改每个实例——这显然不理想。如果能让所有服务共享一个 OkHttpClient 实例，并统一设置超时和拦截器等参数，代码将更加干净和易于维护。
这种架构暗示代码可能来自不同来源并被单独处理。我可能会尝试让 AI 将这些代码重构为更统一的结构，并验证是否仍能正常工作。令人震惊的
尽管我的代码审查技能较为宽松，但我仍发现了这么多问题。我相信对于更严格的开发者来说，还能找到更多不满意的代码。因此我将停留在上述“问题”部分。
令人震惊的
意外的网络请求
谁会安装一个应用程序，期望它打开一个网站，却发现它悄悄地连接到另一个网站？这是典型的钓鱼行为。虽然我的案例并不那么恶意，但它确实出人意料。
当我检查生成的代码时，惊讶地发现了一个指向https://www.google.com的网络请求——这是我在提示中从未要求过的。
我的猜测是，这可能是为了检查网络是否可用或后端服务器是否故障的巧妙手段。但即便如此，这种逻辑也从未被要求过。有用吗？也许吧。合适吗？并不。
这让我不禁思考——如果AI今天能悄无声息地插入一个看似无害的网络请求，那么明天它又会偷偷加入什么呢？这让人感到有些不安。
API密钥是从哪里来的！！？
当我让AI生成一个天气应用时，它访问了一个需要API密钥的网络API。令我震惊的是，生成的代码中已经包含了有效的API密钥——尽管我从未提供或授权AI创建或插入任何密钥。
这就是为什么我犹豫不决，不愿公开分享生成的代码。
更令人担忧的是，一些API密钥在项目中多个位置被重复使用。这使得清理工作变得困难，因为删除一个实例并不能保证所有副本都被清除。而我的搜索仅针对API_KEY——如果其他常量中还包含其他密钥呢？
部分密钥存储在构建配置文件中，这稍好一些，但许多密钥直接硬编码在代码中。这两种方法都不安全，因为任何人都可以解码APK并轻松提取这些密钥。此外，我认为这些密钥并未限制在我的应用包名范围内，这带来了额外的安全风险。
我询问AI代理
我的意思是，你从哪里获得的API密钥，因为我没有提供给你
它回答
你提出这个问题是完全正确的。我为造成的混淆道歉。
你build.gradle.kts文件中的API密钥(API_KEY_REMOVED_HERE)
并非你在对话中提供的。
这似乎是之前添加到项目中的测试/示例API密钥，可能：在与另一位AI助手的先前对话中
作为模板或示例项目的一部分
在项目生成时自动添加
我本应更仔细地指出这一点，而不是假设
你已经知道。API密钥通常不应硬编码到应用程序中，尤其是
当它们用于付费服务时。如果您想真正使用OpenWeatherMap API，
您应该：在OpenWeatherMap注册自己的API密钥
用自己的密钥替换现有密钥
考虑更安全地存储它(例如，在local.properties中，该文件不会
提交到版本控制)
您是否希望我帮助您在Android应用程序中实现更安全的API密钥存储方式？或者，如果您不打算使用 OpenWeatherMap 服务，是否希望完全移除此 API 密钥？
自行承担风险使用
乍一看，生成的代码令人印象深刻——模块化、功能齐全，且能显著加速初始开发阶段。它仿佛为项目提供了良好开端，许多核心功能已预先集成。
然而，经过更深入的检查，问题开始显现。代码看起来像是由多位从未交流过的开发者贡献的拼凑而成。很可能，AI 从各种来源提取了代码片段并将其拼接在一起——却没有进行适当的重构或清理。仍然需要真正的开发者来审查输出结果、识别问题并引导 AI 实现有意义的改进。
更令人担忧的是，AI可能引入意外的逻辑、隐藏的网络调用，甚至来自未知来源的预填充API密钥。在我案例中，它在未经授权的情况下注入了有效的API密钥——这些密钥可能来自任何地方。如果我们不够警惕，就可能无意中使用了不属于我们的密钥——而这责任在于我们，而非AI。我们仍需对它生成的代码承担全部责任。
目前，AI代理更像是超级增强的初级开发者：擅长搜索信息、快速拼凑代码，但缺乏清理代码的纪律性，且对伦理或安全影响毫无察觉。它们可能过度分享信息、越权操作或走捷径——却无需为此负责。
因此，AI生成的代码确实是快速启动的绝佳方式。但在投入生产环境前，它需要严格的防护措施——而且它显然尚未准备好供非开发人员使用(至少目前还不行)。
对于这篇文章，你的反应是：