1
月
在社区成长 1 月
LEVEL 1
1 XP
一、背景
很多开发者使用 AI 编程 IDE 时，仍停留在“写一个函数”或“解释这段代码”的阶段。代码补全确实能节省输入时间，但真正影响工程效率的，是 AI 能否理解项目边界、遵守架构约束、生成可验证的修改，并进入调试、测试和代码审查闭环。
以 Android 工程为例，项目通常同时包含 Kotlin、Java、Gradle、Manifest、资源文件、网络接口和本地存储。若直接让 AI 自由修改整个仓库，它可能生成能够编译但不符合现有架构的代码，也可能引入明文日志、错误的组件导出配置、宽松的网络安全策略等问题。因此，一个成熟的 AI IDE 工作流不能只关注“生成速度”，还要同时控制上下文、变更范围和验证成本。
本文以本地 Android 示例工程为对象，介绍一套可落地的 AI 编程 IDE 工作流。所有调试与安全检查均限定在自有工程、本地模拟器或明确授权的测试环境中。
二、核心原理：让 AI 在约束中完成小步修改
AI IDE 的主要能力通常可以拆成四层：
1. 行级补全：根据当前文件和光标附近代码预测后续内容，适合样板代码、数据映射和重复分支。
2. 对话式问答：读取选定文件后解释调用链、异常原因或模块职责。
3. 多文件编辑：根据任务同时修改 ViewModel、Repository、测试和配置文件。
4. Agent 工作流：执行搜索、编辑、构建和测试，再根据结果继续修复。
这里最重要的不是一次性提供尽可能多的文件，而是提供“足够且可信”的上下文。上下文过少，AI 会猜测接口；上下文过多，则可能忽略关键约束，并增加不相关修改。
比较稳妥的任务单位是：一个明确问题、一个主要模块、一组验收命令。例如，不要直接要求“优化登录模块”，而应写成：
“仅修改 app/src/main/java/com/example/login 与对应测试。将登录请求结果封装为 LoginResult，不改变后端字段，不新增第三方依赖。完成后运行 login 模块单元测试，并列出修改文件及失败风险。”
三、前置条件
1. 一个可以独立构建的 Android 工程，建议先确保人工执行构建能够成功。
2. 已安装与项目匹配的 JDK、Android SDK 和 Gradle 环境。
3. AI IDE 支持项目索引、文件引用或仓库级规则；不同产品名称可能不同，但原则相同。
4. 工程已纳入 Git，开始任务前工作区应尽量保持干净。
5. 准备本地模拟器或测试设备。涉及接口时，优先使用 MockWebServer、本地 Mock 服务或测试环境。
6. 不要把生产密钥、签名文件密码、访问令牌和真实用户数据提交给 IDE 上下文。若所用工具会把代码发送到远端模型，还应先确认团队的数据处理政策。
开始前执行：
./gradlew --version
./gradlew clean assembleDebug
./gradlew testDebugUnitTest
git status --short
如果基线本身失败，应先记录失败项，否则后面无法判断错误是历史问题还是 AI 修改引入的问题。
四、第一步：建立工程级规则
在 IDE 支持的规则文件或项目指令中写入稳定约束。规则不要堆砌空泛口号，应写成可执行要求。例如：
项目使用 Kotlin 与 MVVM；UI 层不得直接访问网络；网络调用统一经过 Repository；协程必须使用结构化并发；禁止在日志中输出 Token、Cookie、手机号和完整响应体；不得自行升级 Gradle、AGP 或依赖版本；修改公共接口前必须先列出调用方；新增逻辑必须补充测试；每次任务结束后输出修改文件、验证命令和残余风险。
还可以加入 Android 安全边界：
新增 Activity、Service、Receiver 或 Provider 时，必须显式评估 android:exported；内部组件默认不导出；WebView 默认不启用不需要的 JavaScript 接口；敏感配置不得硬编码到 BuildConfig 或源码；调试日志不得进入 release 构建。
这些规则无法替代审查，但能减少模型在多轮任务中反复偏离项目习惯。
五、第二步：先让 AI 建立最小上下文
不要一开始就要求修改。先让 AI 阅读入口文件和关键接口，并输出理解结果。以登录功能为例，可依次提供：
LoginActivity 或 LoginFragment
LoginViewModel
AuthRepository
AuthApi
LoginRequest 与 LoginResponse
对应测试文件
提示词可以写为：
“先不要修改代码。请按 UI 入口、状态管理、数据层、网络层的顺序描述登录调用链；指出线程切换、异常映射和敏感信息处理位置；如果信息不足，只列出需要继续读取的文件，不要猜测不存在的类。”
这一步能暴露 AI 是否真的理解当前工程。若它提到仓库中不存在的方法，应先纠正上下文，而不是让它继续生成代码。
六、第三步：把需求拆成可验证的小补丁
假设要解决的问题是登录失败时 UI 只显示通用错误，同时调试日志打印了完整响应体。可以拆成三个补丁：
补丁一：在数据层定义明确的错误类型，不改 UI。
补丁二：ViewModel 将错误映射为稳定的界面状态。
补丁三：移除敏感日志并增加测试。
给 AI 的任务描述应包含修改范围与禁止事项：
“仅修改 AuthRepository、LoginViewModel 及其单元测试。将网络超时、凭据错误和未知错误映射为不同状态。不得记录请求头、Token、密码或完整响应体；不得新增依赖；不得修改 API 字段。先给出计划和预计修改文件，确认后再编辑。”
要求先给计划非常实用。若计划中出现升级依赖、重构整个网络层等无关动作，可以在代码产生前及时制止。
七、第四步：让生成代码具备可测试结构
例如，登录错误映射可以保持为纯函数，方便快速验证：
sealed interface LoginResult {
data object Success : LoginResult
data object InvalidCredential : LoginResult
data object Timeout : LoginResult
data class Unknown(val cause: Throwable) : LoginResult
}
fun mapLoginError(error: Throwable): LoginResult = when (error) {
is java.net.SocketTimeoutException -> LoginResult.Timeout
is InvalidCredentialException -> LoginResult.InvalidCredential
else -> LoginResult.Unknown(error)
}
生成后不要只检查语法，还要追问：
“请列出该实现依赖的前提、没有覆盖的异常类型，以及哪些分支需要单元测试。不要继续修改。”
这能迫使 AI 区分已知事实与假设。随后补充测试时，至少覆盖成功、超时、凭据错误和未知异常，并避免测试依赖真实网络。
执行定向测试：
./gradlew testDebugUnitTest --tests '*LoginViewModelTest*'
./gradlew testDebugUnitTest --tests '*AuthRepositoryTest*'
定向测试通过后再运行模块级测试：
./gradlew testDebugUnitTest
./gradlew lintDebug
八、第五步：利用 AI 辅助调试，而不是盲目改错
当构建失败时，应把“命令、完整错误、相关代码、最近变更”一起交给 AI。只粘贴最后一行异常，往往会得到猜测性答案。
一个有效的调试提示词是：
“以下错误来自执行 ./gradlew testDebugUnitTest。请先区分编译错误、测试断言失败和环境问题；给出最可能的三个原因，并引用日志中的证据。只提出最小修复，不要修改无关文件。”
如果是运行期问题，可在自有模拟器上收集过滤后的日志：
adb devices
adb logcat -c
adb logcat AndroidRuntime:E MyApp
'*:S'
粘贴日志前先检查是否包含账号、Token、设备标识或接口返回内容。更好的做法是在应用日志层统一脱敏，而不是每次手工删除。
AI 适合协助阅读堆栈、比较状态变化和定位空指针来源，但它无法自动证明某个修复不会产生回归。每次修复后都应重新运行触发步骤和相关测试。
九、第六步：加入防御性安全审查
AI 生成 Android 代码时，常见风险集中在组件、网络、存储和日志四个攻击面。可以让 IDE 对当前差异进行一次限定范围的审查：
“仅审查 git diff 中的 Android 变更。检查导出组件、Intent 输入校验、WebView 配置、明文流量、证书校验、敏感日志和本地存储。每项必须引用具体文件与代码；无法确认时标记为待人工验证，不要假设漏洞成立。”
然后人工执行：
git diff --check
git diff -- app/src/main/AndroidManifest.xml
git grep -n 'Log.*token'
git grep -n 'setJavaScriptEnabled'
git grep -n 'usesCleartextTraffic'
需要注意，搜索命中不等于存在漏洞。例如测试代码可能故意构造假 Token，开发环境也可能需要访问本地 HTTP Mock 服务。应结合构建变体、调用路径和数据来源判断。
若 AI 新增了导出组件，至少检查：
1. 是否确实需要被其他应用调用。
2. 是否设置了合适权限。
3. 是否校验外部 Intent、URI 和 Bundle 输入。
4. 是否可能返回敏感数据。
5. 是否存在仅为调试而添加、却进入 release 的入口。
十、第七步：建立提交前闭环
AI 完成任务后，不要直接提交。建议按以下顺序收尾：
1. 查看文件范围：git status --short。
2. 查看实际差异：git diff --stat 与 git diff。
3. 检查是否误改锁文件、构建配置或资源。
4. 运行格式化、静态检查、单元测试和构建。
5. 在模拟器上完成一次关键路径回归。
6. 让 AI 根据最终 diff 生成审查清单，而不是根据聊天记录总结。
常用命令如下：
./gradlew lintDebug
./gradlew testDebugUnitTest
./gradlew assembleDebug
git diff --check
若项目较大，可先运行受影响模块，再在提交前运行完整流水线。提交信息应描述行为变化，例如“区分登录超时与凭据错误并移除敏感响应日志”，而不是简单写“AI 修复登录”。
十一、代码补全的效率实践
代码补全适合低风险、重复性高的内容，例如 DTO 映射、测试数据构造器、when 分支和简单 UI 状态。对于权限处理、加密、证书校验、支付、账号恢复等高风险逻辑，不应连续接受大段补全。
可以采用三行原则：先写函数签名、输入约束和失败行为，再触发补全。例如先写注释：
输入可能来自外部 Intent；只接受 https；Host 必须属于允许列表；解析失败返回 null，不抛出异常。
随后检查补全是否真正实现了协议与 Host 双重限制，是否错误使用字符串前缀判断。AI 的价值是加速实现，不是替代边界条件设计。
十二、风险与注意事项
1. 幻觉风险：AI 可能引用不存在的类、Gradle 任务或 API。所有命令必须在当前工程验证。
2. 过度修改：多文件 Agent 容易顺手重构无关代码，应限定目录、文件和依赖变化。
3. 隐私与代码泄露：不要提交密钥、签名材料、生产日志和真实用户数据到模型上下文。
4. 测试假阳性：AI 生成的测试可能只是复述实现，甚至通过 Mock 掩盖真实错误。关键逻辑应验证行为和边界。
5. 安全误判：静态片段无法完整证明漏洞，应结合 Manifest 合并结果、构建变体和运行路径。
6. 自动执行风险：启用终端 Agent 时，建议对删除文件、安装依赖、修改 Git 历史和访问网络的命令保持人工确认。
7. 大范围格式化：可能淹没真正的业务差异。要求 AI 只格式化修改区域，并在提交前查看 diff。
十三、常见问题
问：为什么 AI 已经索引整个仓库，仍会理解错调用链？
答：索引不代表每次对话都会使用所有相关文件。应明确指定入口、接口、实现和测试，并让 AI 先复述调用链。
问：应该一次让 AI 完成代码、测试和文档吗？
答：小功能可以，但建议分为计划、实现、测试、审查四轮。这样更容易发现错误发生在哪一步，也方便回退。
问：AI 生成的测试全部通过，是否可以直接合并？
答：不可以。还要确认测试是否覆盖失败路径、是否使用了合理断言、是否意外 Mock 掉核心逻辑，并运行现有回归测试。
问：如何避免 AI 每次都建议升级依赖？
答：在工程规则和任务提示中明确写入“未经要求不得修改版本、仓库源和插件”，并在最终 diff 中单独检查 Gradle 文件。
问：日志太长，如何交给 AI 分析？
答：先保留首次异常、完整堆栈、相关线程和触发步骤，删除重复输出并进行脱敏。不要只截取最后一行，也不要上传生产日志原文。
问：是否应该允许 Agent 自动执行所有命令？
答：建议从只读搜索、构建和测试开始。涉及文件删除、系统配置、凭据、网络下载和 Git 历史修改时保留人工确认。
十四、总结
高质量的 AI 编程 IDE 工作流，不是让模型一次写出更多代码，而是把任务变成可控的小补丁：先建立规则，再提供最小上下文；先解释和计划，再修改；每次修改都绑定测试、构建和差异审查；对组件、接口、日志和存储同步进行防御性检查。
在 Android 工程中，推荐固定采用“基线验证—上下文确认—小步编辑—定向测试—模块测试—安全审查—人工回归”的顺序。这样既能发挥 AI 在代码补全、调用链分析和测试生成方面的效率优势，也能避免把不确定性直接带入主分支。真正可靠的 AI IDE，不应只是更快的代码生成器，而应成为一个受工程规范约束、输出可以被命令验证的协作工具。
很多开发者使用 AI 编程 IDE 时，仍停留在“写一个函数”或“解释这段代码”的阶段。代码补全确实能节省输入时间，但真正影响工程效率的，是 AI 能否理解项目边界、遵守架构约束、生成可验证的修改，并进入调试、测试和代码审查闭环。
以 Android 工程为例，项目通常同时包含 Kotlin、Java、Gradle、Manifest、资源文件、网络接口和本地存储。若直接让 AI 自由修改整个仓库，它可能生成能够编译但不符合现有架构的代码，也可能引入明文日志、错误的组件导出配置、宽松的网络安全策略等问题。因此，一个成熟的 AI IDE 工作流不能只关注“生成速度”，还要同时控制上下文、变更范围和验证成本。
本文以本地 Android 示例工程为对象，介绍一套可落地的 AI 编程 IDE 工作流。所有调试与安全检查均限定在自有工程、本地模拟器或明确授权的测试环境中。
二、核心原理：让 AI 在约束中完成小步修改
AI IDE 的主要能力通常可以拆成四层：
1. 行级补全：根据当前文件和光标附近代码预测后续内容，适合样板代码、数据映射和重复分支。
2. 对话式问答：读取选定文件后解释调用链、异常原因或模块职责。
3. 多文件编辑：根据任务同时修改 ViewModel、Repository、测试和配置文件。
4. Agent 工作流：执行搜索、编辑、构建和测试，再根据结果继续修复。
这里最重要的不是一次性提供尽可能多的文件，而是提供“足够且可信”的上下文。上下文过少，AI 会猜测接口；上下文过多，则可能忽略关键约束，并增加不相关修改。
比较稳妥的任务单位是：一个明确问题、一个主要模块、一组验收命令。例如，不要直接要求“优化登录模块”，而应写成：
“仅修改 app/src/main/java/com/example/login 与对应测试。将登录请求结果封装为 LoginResult，不改变后端字段，不新增第三方依赖。完成后运行 login 模块单元测试，并列出修改文件及失败风险。”
三、前置条件
1. 一个可以独立构建的 Android 工程，建议先确保人工执行构建能够成功。
2. 已安装与项目匹配的 JDK、Android SDK 和 Gradle 环境。
3. AI IDE 支持项目索引、文件引用或仓库级规则；不同产品名称可能不同，但原则相同。
4. 工程已纳入 Git，开始任务前工作区应尽量保持干净。
5. 准备本地模拟器或测试设备。涉及接口时，优先使用 MockWebServer、本地 Mock 服务或测试环境。
6. 不要把生产密钥、签名文件密码、访问令牌和真实用户数据提交给 IDE 上下文。若所用工具会把代码发送到远端模型，还应先确认团队的数据处理政策。
开始前执行：
./gradlew --version
./gradlew clean assembleDebug
./gradlew testDebugUnitTest
git status --short
如果基线本身失败，应先记录失败项，否则后面无法判断错误是历史问题还是 AI 修改引入的问题。
四、第一步：建立工程级规则
在 IDE 支持的规则文件或项目指令中写入稳定约束。规则不要堆砌空泛口号，应写成可执行要求。例如：
项目使用 Kotlin 与 MVVM；UI 层不得直接访问网络；网络调用统一经过 Repository；协程必须使用结构化并发；禁止在日志中输出 Token、Cookie、手机号和完整响应体；不得自行升级 Gradle、AGP 或依赖版本；修改公共接口前必须先列出调用方；新增逻辑必须补充测试；每次任务结束后输出修改文件、验证命令和残余风险。
还可以加入 Android 安全边界：
新增 Activity、Service、Receiver 或 Provider 时，必须显式评估 android:exported；内部组件默认不导出；WebView 默认不启用不需要的 JavaScript 接口；敏感配置不得硬编码到 BuildConfig 或源码；调试日志不得进入 release 构建。
这些规则无法替代审查，但能减少模型在多轮任务中反复偏离项目习惯。
五、第二步：先让 AI 建立最小上下文
不要一开始就要求修改。先让 AI 阅读入口文件和关键接口，并输出理解结果。以登录功能为例，可依次提供：
LoginActivity 或 LoginFragment
LoginViewModel
AuthRepository
AuthApi
LoginRequest 与 LoginResponse
对应测试文件
提示词可以写为：
“先不要修改代码。请按 UI 入口、状态管理、数据层、网络层的顺序描述登录调用链；指出线程切换、异常映射和敏感信息处理位置；如果信息不足，只列出需要继续读取的文件，不要猜测不存在的类。”
这一步能暴露 AI 是否真的理解当前工程。若它提到仓库中不存在的方法，应先纠正上下文，而不是让它继续生成代码。
六、第三步：把需求拆成可验证的小补丁
假设要解决的问题是登录失败时 UI 只显示通用错误，同时调试日志打印了完整响应体。可以拆成三个补丁：
补丁一：在数据层定义明确的错误类型，不改 UI。
补丁二：ViewModel 将错误映射为稳定的界面状态。
补丁三：移除敏感日志并增加测试。
给 AI 的任务描述应包含修改范围与禁止事项：
“仅修改 AuthRepository、LoginViewModel 及其单元测试。将网络超时、凭据错误和未知错误映射为不同状态。不得记录请求头、Token、密码或完整响应体；不得新增依赖；不得修改 API 字段。先给出计划和预计修改文件，确认后再编辑。”
要求先给计划非常实用。若计划中出现升级依赖、重构整个网络层等无关动作，可以在代码产生前及时制止。
七、第四步：让生成代码具备可测试结构
例如，登录错误映射可以保持为纯函数，方便快速验证：
sealed interface LoginResult {
data object Success : LoginResult
data object InvalidCredential : LoginResult
data object Timeout : LoginResult
data class Unknown(val cause: Throwable) : LoginResult
}
fun mapLoginError(error: Throwable): LoginResult = when (error) {
is java.net.SocketTimeoutException -> LoginResult.Timeout
is InvalidCredentialException -> LoginResult.InvalidCredential
else -> LoginResult.Unknown(error)
}
生成后不要只检查语法，还要追问：
“请列出该实现依赖的前提、没有覆盖的异常类型，以及哪些分支需要单元测试。不要继续修改。”
这能迫使 AI 区分已知事实与假设。随后补充测试时，至少覆盖成功、超时、凭据错误和未知异常，并避免测试依赖真实网络。
执行定向测试：
./gradlew testDebugUnitTest --tests '*LoginViewModelTest*'
./gradlew testDebugUnitTest --tests '*AuthRepositoryTest*'
定向测试通过后再运行模块级测试：
./gradlew testDebugUnitTest
./gradlew lintDebug
八、第五步：利用 AI 辅助调试，而不是盲目改错
当构建失败时，应把“命令、完整错误、相关代码、最近变更”一起交给 AI。只粘贴最后一行异常，往往会得到猜测性答案。
一个有效的调试提示词是：
“以下错误来自执行 ./gradlew testDebugUnitTest。请先区分编译错误、测试断言失败和环境问题；给出最可能的三个原因，并引用日志中的证据。只提出最小修复，不要修改无关文件。”
如果是运行期问题，可在自有模拟器上收集过滤后的日志：
adb devices
adb logcat -c
adb logcat AndroidRuntime:E MyApp
'*:S'粘贴日志前先检查是否包含账号、Token、设备标识或接口返回内容。更好的做法是在应用日志层统一脱敏，而不是每次手工删除。
AI 适合协助阅读堆栈、比较状态变化和定位空指针来源，但它无法自动证明某个修复不会产生回归。每次修复后都应重新运行触发步骤和相关测试。
九、第六步：加入防御性安全审查
AI 生成 Android 代码时，常见风险集中在组件、网络、存储和日志四个攻击面。可以让 IDE 对当前差异进行一次限定范围的审查：
“仅审查 git diff 中的 Android 变更。检查导出组件、Intent 输入校验、WebView 配置、明文流量、证书校验、敏感日志和本地存储。每项必须引用具体文件与代码；无法确认时标记为待人工验证，不要假设漏洞成立。”
然后人工执行：
git diff --check
git diff -- app/src/main/AndroidManifest.xml
git grep -n 'Log.*token'
git grep -n 'setJavaScriptEnabled'
git grep -n 'usesCleartextTraffic'
需要注意，搜索命中不等于存在漏洞。例如测试代码可能故意构造假 Token，开发环境也可能需要访问本地 HTTP Mock 服务。应结合构建变体、调用路径和数据来源判断。
若 AI 新增了导出组件，至少检查：
1. 是否确实需要被其他应用调用。
2. 是否设置了合适权限。
3. 是否校验外部 Intent、URI 和 Bundle 输入。
4. 是否可能返回敏感数据。
5. 是否存在仅为调试而添加、却进入 release 的入口。
十、第七步：建立提交前闭环
AI 完成任务后，不要直接提交。建议按以下顺序收尾：
1. 查看文件范围：git status --short。
2. 查看实际差异：git diff --stat 与 git diff。
3. 检查是否误改锁文件、构建配置或资源。
4. 运行格式化、静态检查、单元测试和构建。
5. 在模拟器上完成一次关键路径回归。
6. 让 AI 根据最终 diff 生成审查清单，而不是根据聊天记录总结。
常用命令如下：
./gradlew lintDebug
./gradlew testDebugUnitTest
./gradlew assembleDebug
git diff --check
若项目较大，可先运行受影响模块，再在提交前运行完整流水线。提交信息应描述行为变化，例如“区分登录超时与凭据错误并移除敏感响应日志”，而不是简单写“AI 修复登录”。
十一、代码补全的效率实践
代码补全适合低风险、重复性高的内容，例如 DTO 映射、测试数据构造器、when 分支和简单 UI 状态。对于权限处理、加密、证书校验、支付、账号恢复等高风险逻辑，不应连续接受大段补全。
可以采用三行原则：先写函数签名、输入约束和失败行为，再触发补全。例如先写注释：
输入可能来自外部 Intent；只接受 https；Host 必须属于允许列表；解析失败返回 null，不抛出异常。
随后检查补全是否真正实现了协议与 Host 双重限制，是否错误使用字符串前缀判断。AI 的价值是加速实现，不是替代边界条件设计。
十二、风险与注意事项
1. 幻觉风险：AI 可能引用不存在的类、Gradle 任务或 API。所有命令必须在当前工程验证。
2. 过度修改：多文件 Agent 容易顺手重构无关代码，应限定目录、文件和依赖变化。
3. 隐私与代码泄露：不要提交密钥、签名材料、生产日志和真实用户数据到模型上下文。
4. 测试假阳性：AI 生成的测试可能只是复述实现，甚至通过 Mock 掩盖真实错误。关键逻辑应验证行为和边界。
5. 安全误判：静态片段无法完整证明漏洞，应结合 Manifest 合并结果、构建变体和运行路径。
6. 自动执行风险：启用终端 Agent 时，建议对删除文件、安装依赖、修改 Git 历史和访问网络的命令保持人工确认。
7. 大范围格式化：可能淹没真正的业务差异。要求 AI 只格式化修改区域，并在提交前查看 diff。
十三、常见问题
问：为什么 AI 已经索引整个仓库，仍会理解错调用链？
答：索引不代表每次对话都会使用所有相关文件。应明确指定入口、接口、实现和测试，并让 AI 先复述调用链。
问：应该一次让 AI 完成代码、测试和文档吗？
答：小功能可以，但建议分为计划、实现、测试、审查四轮。这样更容易发现错误发生在哪一步，也方便回退。
问：AI 生成的测试全部通过，是否可以直接合并？
答：不可以。还要确认测试是否覆盖失败路径、是否使用了合理断言、是否意外 Mock 掉核心逻辑，并运行现有回归测试。
问：如何避免 AI 每次都建议升级依赖？
答：在工程规则和任务提示中明确写入“未经要求不得修改版本、仓库源和插件”，并在最终 diff 中单独检查 Gradle 文件。
问：日志太长，如何交给 AI 分析？
答：先保留首次异常、完整堆栈、相关线程和触发步骤，删除重复输出并进行脱敏。不要只截取最后一行，也不要上传生产日志原文。
问：是否应该允许 Agent 自动执行所有命令？
答：建议从只读搜索、构建和测试开始。涉及文件删除、系统配置、凭据、网络下载和 Git 历史修改时保留人工确认。
十四、总结
高质量的 AI 编程 IDE 工作流，不是让模型一次写出更多代码，而是把任务变成可控的小补丁：先建立规则，再提供最小上下文；先解释和计划，再修改；每次修改都绑定测试、构建和差异审查；对组件、接口、日志和存储同步进行防御性检查。
在 Android 工程中，推荐固定采用“基线验证—上下文确认—小步编辑—定向测试—模块测试—安全审查—人工回归”的顺序。这样既能发挥 AI 在代码补全、调用链分析和测试生成方面的效率优势，也能避免把不确定性直接带入主分支。真正可靠的 AI IDE，不应只是更快的代码生成器，而应成为一个受工程规范约束、输出可以被命令验证的协作工具。