1. 项目缘起：当AI成为你的“实习生”

最近半年，我身边不少朋友和同事都开始尝试用AI来辅助开发。从写几行工具脚本，到生成整个模块的代码，AI确实像个不知疲倦的实习生，极大地提升了效率。但很快，一个普遍的问题浮出水面：AI生成的代码，在真实、复杂的App项目中，常常会“改坏”一些关键地方。

这里的“改坏”，不是指语法错误或无法运行——现在的AI模型在基础语法上已经相当可靠。它指的是那些看似能跑通，但会埋下性能隐患、安全漏洞、架构腐化或维护噩梦的代码。这些改动，往往发生在那些对上下文理解要求极高、或者需要权衡多种非功能性需求的场景中。

我自己也踩过不少坑。比如，让AI帮忙重构一个数据加载模块，它给出了一个看似优雅的异步方案，却忽略了App从后台唤醒时的数据一致性要求，导致UI状态错乱。又比如，让AI优化一个图片缓存逻辑，它引入了一个新的第三方库，却让App的包体积增加了好几兆，而且这个库的API设计与我们现有的架构格格不入。

于是，我开始有意识地收集和整理这些“AI最容易改坏真实App的地方”。这不仅仅是一个“避坑清单”，我更愿意称之为一套“Skills”——一套开发者需要掌握，并能有效“传授”给AI的高阶工程化思维和约束条件。它关乎的，是如何让AI从一个“代码打字员”，变成一个理解你项目上下文、尊重你工程规范的“靠谱搭档”。

2. 核心“Skills”框架：约束、理解与验证

在与AI协作开发真实App时，我们不能只给它一个模糊的需求（如“优化这个页面的加载速度”），而必须提供一套清晰的“作战规则”。这套规则，就是我整理的“Skills”的核心。它主要分为三个层面：约束性Skills、理解性Skills和验证性Skills。

2.1 约束性Skills：给AI划定的“红线”

这是最基础，也最重要的一层。它定义了AI绝对不能触碰或必须严格遵守的规则，通常与项目的硬性指标和长期健康度直接相关。

1. 架构与依赖约束这是AI最常“越界”的领域。一个典型的坏例子是，AI为了快速实现某个功能，随意引入新的第三方库或框架。

• Skill要点：在给AI的Prompt中，必须明确声明。

  • 架构模式：我们项目使用的是MVVM、Clean Architecture还是其他？新的代码必须符合现有的数据流（例如，ViewModel通过UseCase调用Repository）。
  • 依赖注入：我们使用Hilt、Koin还是手动注入？新创建的类必须能被正确注入。
  • 禁止/允许的库：列出项目已集成的核心库（如Retrofit、Room、Coil/Glide），并明确禁止引入某些类型的库（例如，为避免包冲突，禁止引入另一个网络库或图片加载库）。
  • 包体积敏感：强调对引入新依赖的警惕性，要求AI评估或选择轻量级的替代方案。

• 反面案例：“请实现一个图片高斯模糊效果。” AI可能直接回复：“使用Blurry库，在build.gradle中添加依赖implementation 'jp.wasabeef:blurry:4.0.1'。” 这增加了不必要的依赖和包大小。

• 正确“Skill”：“请在不引入新第三方库的前提下，使用Android SDK或我们已使用的Coil/Glide库，实现一个高效的图片高斯模糊效果。”

2. 性能与资源约束AI生成的代码有时会忽略移动端的资源限制。

• Skill要点：

  • 主线程规则：任何可能耗时超过16ms的操作（网络、数据库、复杂计算）必须明确在后台线程执行，并安全地切回UI线程更新。
  • 内存与生命周期：生成的代码必须正确处理Android组件的生命周期（如避免在onDestroy后更新View），注意避免内存泄漏（如持有Context或View的长期引用）。
  • 电池与网络优化：对于后台任务，需考虑使用WorkManager并设置合理的网络类型约束（如NETWORK_TYPE_CONNECTED）和充电状态约束。

• 反面案例：“请定时每5分钟同步一次用户数据。” AI可能生成一个简单的Handler或Timer循环，这会在App进入后台后可能无法正常工作，且不遵守系统后台执行限制，耗电严重。

• 正确“Skill”：“请使用WorkManager实现一个每5分钟执行一次的数据同步后台任务。任务需要仅在设备充电且连接Wi-Fi时执行，并且要兼容Android不同版本的后台限制。”

3. 安全与合规约束这是红线中的红线，AI目前对此几乎毫无概念。

• Skill要点：

  • 敏感信息：绝对禁止在代码中硬编码API密钥、密码、服务器地址。必须使用BuildConfig、本地属性文件或安全的远程配置。
  • 数据存储：用户隐私数据必须加密存储（使用EncryptedSharedPreferences或SQLCipher），而非简单的SharedPreferences或明文数据库。
  • 输入验证与输出编码：对所有用户输入和网络返回的数据进行严格的验证和清理，防止注入攻击。
  • 网络通信：必须使用HTTPS，并考虑证书锁定（Certificate Pinning）以增强安全性。

• 反面案例：“请添加一个功能，将用户反馈发送到我们的服务器http://api.ourserver.com/feedback。” AI生成的代码可能使用不安全的HTTP协议，并在代码中暴露服务器地址。

• 正确“Skill”：“请实现一个用户反馈功能。使用我们项目中已配置的Retrofit实例（Base URL已安全配置），通过HTTPS POST请求将加密后的反馈内容发送到/feedback端点。反馈内容在发送前需进行URL编码。”

2.2 理解性Skills：让AI读懂你的“业务上下文”

即使划定了红线，AI仍可能写出“正确但无用”的代码，因为它不理解你的业务逻辑和现有代码的“潜规则”。

1. 状态与数据流管理现代App的核心是状态管理。AI很容易破坏一致的数据流。

• Skill要点：在Prompt中描述状态变化时，要像定义状态机一样清晰。

  • 数据源：数据来自哪里？（本地数据库、网络、缓存）
  • 状态定义：页面有哪几种状态？（Loading, Success, Error, Empty）
  • 状态转换：什么操作会导致状态变化？（下拉刷新、上拉加载、用户操作）
  • UI响应：每种状态对应的UI是什么？（显示加载框、列表、错误提示、空页面）

• 反面案例：“在用户列表页面，添加一个下拉刷新功能。” AI可能只生成一个SwipeRefreshLayout的监听器，在里面直接调用网络请求，然后更新列表。这忽略了“刷新时是否保留旧数据”、“刷新失败如何回退”、“同时存在加载更多和刷新如何处理冲突”等问题。

• 正确“Skill”：“在我们的用户列表ViewModel中，我们有一个userListState（类型为StateFlow<UserListState>）来管理状态。请添加一个refresh方法。触发刷新时：1. 如果当前状态不是Loading，则将其设置为Loading（但保留旧的Success数据用于显示）。2. 调用userRepository.fetchLatestUsers()。3. 成功则用新数据更新为Success状态；失败则更新为Error状态，并保留旧数据。请确保refresh与已有的loadMore方法在并发调用时不会产生数据竞争。”

2. 用户体验与交互细节AI对“流畅”和“友好”缺乏感知。

• Skill要点：必须明确指定交互细节。

  • 防抖与节流：搜索框输入、按钮点击是否需要防抖？
  • 加载态与骨架屏：加载数据时，是显示一个全局加载弹窗，还是局部骨架屏？
  • 错误恢复：网络错误后，是显示一个重试按钮，还是自动重试？
  • 动画与过渡：页面跳转、数据更新是否需要动画？

• 反面案例：“实现一个搜索框，输入时实时显示结果。” AI可能直接在EditText的TextWatcher里为每次输入发起网络请求，导致请求风暴，消耗流量和性能。

• 正确“Skill”：“实现一个搜索框，使用debounce操作符，在用户停止输入300毫秒后才发起搜索请求。在请求发出后，显示一个加载指示器（在搜索框附近）。如果请求失败，在结果区域显示友好的错误提示和一个‘重试’按钮。”

2.3 验证性Skills：如何验收AI的“作业”

给出清晰的约束和上下文后，我们还需要一套方法来验证AI的输出是否真的符合预期，而不仅仅是“没有报错”。

1. 单元测试与集成测试引导要求AI为其生成的代码提供测试用例，是检验其逻辑正确性的绝佳方式。

• Skill要点：在Prompt的结尾加上：“请为上述实现编写相应的单元测试，覆盖主要成功路径和关键异常情况（如网络异常、空数据）。”
• 好处：
  • 澄清逻辑：AI在编写测试时，会反过来审视自己的实现逻辑是否可测、是否清晰。
  • 暴露边界情况：你会发现AI可能忽略的边界条件，比如空列表、超时、权限被拒绝等。
  • 生成测试样板：即使AI生成的测试不完美，它也为你提供了测试结构和思路，节省了你从头开始编写测试的时间。

2. 代码审查清单（Checklist）将上述Skills转化为一个简短的清单，在接收AI代码后快速扫描。

• 清单示例：
  • [ ] 是否引入了新的、不必要的依赖？
  • [ ] 耗时操作是否在后台线程？
  • [ ] 是否持有可能造成内存泄漏的引用（如View、Context）？
  • [ ] 敏感信息是否硬编码？
  • [ ] 数据流是否符合项目架构（如MVVM的LiveData/StateFlow更新是否在UI线程）？
  • [ ] 交互是否有防抖/节流？
  • [ ] 错误状态是否被妥善处理？

3. 实战演练：用“Skills”指导AI重构一个危险函数

让我们看一个具体的例子。假设我们有一个古老的UserProfileActivity，里面有一个loadUserData函数，它问题很多，我们想让AI帮忙重构。

原始Prompt（糟糕的版本）： “帮我重构这个loadUserData函数，让它更现代、更高效。”

这种Prompt注定会得到一份灾难性的代码。AI可能会把函数拆碎，用上最新的协程和Flow，但完全破坏原有的（可能脆弱的）逻辑顺序，或者引入不兼容的库。

运用“Skills”后的Prompt（精良的版本）：

请遵循以下规则，重构 `UserProfileActivity` 中的 `loadUserData` 函数： 【约束性Skills】 1. 架构：必须保持现有的 MVP 架构。请不要将逻辑移到 ViewModel 或 UseCase 中，本次只重构这个 Presenter 内的函数。 2. 依赖：允许使用项目已引入的 `kotlinx.coroutines` 和 `Retrofit`。禁止引入任何新库。 3. 线程：所有网络和数据库操作必须在后台线程执行，结果必须通过 `runOnUiThread` 或 `Handler` 返回主线程更新UI（因为当前项目尚未迁移到 LiveData/Flow）。 4. 安全：确保 `userId` 在拼接 URL 前进行了 URL 编码。 【理解性Skills】 1. 当前函数顺序：原函数依次执行：a) 从本地数据库加载缓存用户；b) 如果缓存过期或不存在，则从网络获取；c) 网络获取后，更新缓存；d) 无论 a 或 b/c 哪条路径成功，都调用 `displayUser`。这个‘缓存优先，网络更新’的逻辑必须保留。 2. 状态管理：在‘从网络获取’这个步骤中，需要显示一个全屏加载遮罩（调用 `showFullscreenLoading()`），获取完成后（无论成功失败）隐藏遮罩（调用 `hideFullscreenLoading()`）。如果网络获取失败，不要清空已显示的缓存数据，而是显示一个 Toast 提示“网络更新失败，显示的是缓存数据”。 3. 性能：网络请求需要设置 10 秒超时。如果本地缓存存在且未过期（假设过期时间是 5 分钟），则跳过网络请求。 【验证性Skills】 请为重构后的函数编写一个单元测试大纲，描述你会测试哪些场景（例如：有未过期缓存时、无缓存时网络成功、无缓存时网络失败等）。 这是原函数代码片段： ```kotlin fun loadUserData(userId: String) { // ... 混乱的异步和数据库逻辑 }

通过这样的Prompt，你相当于把一位高级工程师的审查意见和开发规范直接“喂”给了AI。它生成代码的破坏性和不可预测性会大大降低，产出的结果更可能是一个可以直接融入现有项目的、高质量的改进。 ## 4. 进阶应用：将“Skills”产品化与自动化 对于团队或大型项目，我们可以将这些“Skills”更进一步，从个人经验转化为团队资产和开发流程的一部分。 **1. 创建团队共享的“AI协作规范”文档** 将本章程讨论的Skills，结合你们团队特有的技术栈（如特定的状态管理库、网络层封装、设计系统）、业务逻辑（如统一的错误处理机制、埋点规范）和代码风格指南，整理成一份活的文档。这份文档应该： * **按场景分类**：例如“网络请求场景”、“数据库操作场景”、“UI组件生成场景”、“性能优化场景”。 * **提供正面和反面案例**：就像本文所做的那样，让开发者一目了然。 * **包含标准Prompt模板**：为常见任务提供“开箱即用”的Prompt开头，开发者只需填充具体参数。 **2. 探索“AI Agent”与自定义指令（Custom Instructions）** 一些先进的AI编程助手或平台（如Cursor、Claude for Developer）支持更复杂的交互模式。 * **构建项目专属Agent**：你可以尝试配置一个AI Agent，将你的“Skills”文档、项目架构图、核心接口文档作为其知识库。当你向它提问时，它会自动引用这些约束来生成代码。 * **利用Custom Instructions**：在ChatGPT或Claude中，你可以设置详细的Custom Instructions，例如：“你是一位资深的Android工程师，擅长构建可维护、高性能的移动应用。你严格遵守以下原则：1. 优先使用Kotlin协程处理异步...2. 极其注重内存泄漏预防...3. 所有建议必须基于Android官方最佳实践...” 这相当于为所有对话预设了背景和规则。 **3. 将验证流程纳入CI/CD（持续集成/持续部署）** 这是最高阶的用法。AI生成的代码，最终必须通过人类和自动化工具的双重检验。 * **静态代码分析**：确保AI生成的代码能通过Lint检查（如`ktlint`、`detekt`）、编译时依赖检查等。 * **自动化测试**：如果AI按照要求提供了测试用例，将这些测试纳入项目的测试套件，并在CI流水线中运行，确保重构没有破坏任何功能。 * **安全扫描**：使用像`MobSF`这样的移动端安全扫描工具，对包含AI生成代码的版本进行自动化扫描，检查是否有新的安全漏洞被引入。 ## 5. 心态转变：从“向AI提问”到“对AI编程” 整理和运用这些“Skills”的过程，本质上是一种开发者心态的转变。我们不再是把AI当作一个神秘的“答案盒子”，问一个模糊的问题然后祈祷好运。而是将其视为一个**能力极强但缺乏背景知识和工程纪律的初级工程师**。 我们的角色，因此从一个提问者，转变为一个**架构师、导师和审查者**。 1. **架构师**：负责定义系统的边界、规则和通信协议（约束性Skills）。 2. **导师**：负责讲解业务上下文、用户故事和现有代码的“潜规则”（理解性Skills）。 3. **审查者**：负责定义验收标准，并通过工具和流程确保质量（验证性Skills）。 这个过程，反过来也在倒逼我们开发者自己更深入地思考：我的项目架构清晰吗？我们的编码规范明确吗？我们的异常处理完备吗？当我们能清晰地向AI阐述这些时，意味着我们自己对项目的理解也达到了一个新的高度。 所以，这套“AI最容易改坏真实App的地方”的Skills，最终受益的不仅是与AI协作的效率，更是整个项目的代码质量和团队的工程素养。它是一套用于人机协作的“设计模式”和“最佳实践”。开始有意识地整理和运用你的“Skills”吧，你会发现，AI这个“实习生”会变得越来越靠谱，而你，也将成为一名更出色的“导师”和“架构师”。