LDC开发
什么是LDC开发，这是我自己定义的，意思是：语言到文档到代码-Language to Doc to Coding。就是在开始ai coding之前，先把语言在txt或者文本编译器中，写出来提示词，然后在自己审核一边，最终在粘贴到ai里。
下面说说提示词：
Android AI Coding 提示词工程（Prompt Engineering）
适用于：Cursor / GitHub Copilot / Trae / Claude Code / Windsurf 等 AI 编程助手
一、为什么安卓开发需要专门的 Prompt 工程？
安卓开发的特殊性：
- 上下文庞大：Gradle、Kotlin/Java、XML、Compose、资源文件、Manifest 多文件联动
- 生命周期复杂：Activity/Fragment/Service 生命周期、配置变更、后台限制
- 版本碎片化：API Level 差异、权限模型演进（如通知权限、存储权限）
- 架构多样：MVP/MVVM/MVI、协程/RxJava、Jetpack 组件组合
核心原则：AI 不是全知全能的，你需要像给资深但失忆的安卓工程师布置任务一样提供上下文。
二、Prompt 设计核心框架：RICE-C 模型
| 维度 | 含义 | 安卓场景示例 |
|---|---|---|
| Role | 角色定义 | "你是一位有8年经验的安卓架构师，精通 Kotlin 协程和 Jetpack Compose" |
| Intent | 明确意图 | "帮我重构这段代码，使其符合 MVI 架构并支持配置变更" |
| Context | 完整上下文 | 提供相关类代码、build.gradle 依赖、minSdk 版本 |
| Expectation | 输出期望 | "只输出修改后的代码块和关键改动说明，不要解释基础概念" |
| Constraints | 约束条件 | "不要使用反射，保持向后兼容到 API 26，避免引入新依赖" |
三、安卓开发专用 Prompt 模板与实战
3.1 代码重构/架构迁移
❌ 差示例：
帮我优化这段代码
✅ 优秀示例：
## 角色
你是一位资深 Android 架构师，精通 Kotlin、Jetpack Compose 和 Clean Architecture。
## 任务
将以下基于 MVC 的 Activity 代码重构为 MVI 架构。
## 上下文
- 项目使用 Kotlin 1.9 + Compose 1.5
- minSdk=26, targetSdk=34
- 已引入依赖：ViewModel, Lifecycle, Compose Runtime
- 当前代码存在的问题：UI 逻辑与业务逻辑耦合，难以单元测试，配置变更后状态丢失
## 代码片段
[粘贴原代码]
## 期望输出
1. 分离为：State 定义、Event 定义、ViewModel、Composable UI 四层
2. 使用 StateFlow 管理状态，支持配置变更恢复
3. 保留原有业务逻辑，不得改变功能行为
4. 添加必要的单元测试示例（使用 Turbine 测试 StateFlow）
5. 在关键处添加中文注释说明架构意图
## 约束
- 不引入 Koin/Hilt 等 DI 框架（项目尚未接入）
- 不修改数据层接口定义
- 避免使用 `rememberSaveable` 处理复杂对象
3.2 生成新功能模块
场景：实现一个带分页和缓存的用户列表
## 角色
Android 开发专家，熟悉 Paging 3 和 Room 数据库。
## 需求
为用户列表页面实现分页加载功能，要求：
1. 下拉刷新 + 上拉加载更多
2. 无网络时展示本地缓存（Room）
3. 空状态、错误状态、加载状态 UI 完整
4. 支持搜索过滤（本地过滤已加载数据）
## 技术栈上下文
- UI: Jetpack Compose + Material3
- 架构: MVVM + Repository 模式
- 异步: Kotlin Coroutines + Flow
- 网络: Retrofit + OkHttp
- 本地: Room
- 图片加载: Coil
## 已有接口
[粘贴 Retrofit Service 接口和 Room Entity 定义]
## 期望输出
1. 完整的 Repository 实现（RemoteMediator 或自定义分页策略）
2. ViewModel 状态管理
3. Compose UI 页面（包含 Shimmer 加载效果）
4. 异常处理策略（网络异常、空数据、服务端错误）
5. 关键逻辑的单元测试
## 格式要求
- 使用 Kotlin 语言
- 遵循官方 Kotlin 编码规范
- 对复杂逻辑添加中文注释
- 标注需要添加的 Gradle 依赖
3.3 Bug 诊断与修复
场景：应用崩溃或异常行为
## 角色
Android 崩溃分析专家。
## 问题描述
应用在后台返回前台时偶现崩溃，崩溃日志如下：
[粘贴完整 stack trace]
## 上下文信息
- 发生场景：从后台恢复（onResume）
- 复现频率：约 30%
- 相关代码：
[粘贴 onResume 及关联代码]
- 设备信息：Android 12/13/14 均有报告，非特定厂商
## 已尝试方案
- 已检查并移除 onResume 中的网络请求主线程调用
- 已添加 null 检查，问题仍存在
## 期望
1. 分析根因（不要只停留在表面堆栈）
2. 提供修复代码
3. 解释为什么这样修复能避免问题
4. 提供预防此类问题的编码建议
3.4 Gradle/构建问题
## 角色
Android 构建系统专家，精通 Gradle 和 AGP。
## 问题
升级 AGP 8.2 后编译失败，错误信息：
[粘贴错误日志]
## 环境
- AGP: 8.2.0
- Gradle: 8.4
- Kotlin: 1.9.20
- 项目结构：多模块（app, domain, data, feature-login）
## 当前关键配置
[粘贴项目级 build.gradle / gradle.properties / 模块 build.gradle 关键部分]
## 期望
1. 指出具体不兼容的配置项
2. 提供迁移后的配置代码
3. 说明 AGP 8.x 的破坏性变更影响
4. 如果涉及 namespace / buildConfig 变更，给出完整迁移方案
3.5 性能优化专项
## 角色
Android 性能优化专家，擅长 Compose 渲染性能分析和内存优化。
## 任务
分析并优化以下 Compose 代码的滚动性能。
## 代码
[粘贴 LazyColumn 实现代码]
## 已知症状
- 列表滚动时帧率下降（Profiler 显示 Compose Recomposition 计数异常高）
- 快速滑动时内存抖动明显
## 约束
- 保持现有 UI 视觉效果不变
- 列表项包含异步加载的图片（Coil）
- 支持点击展开/收起详情（状态变化）
## 期望输出
1. 性能瓶颈分析（具体到代码行）
2. 优化后的代码（使用 remember, derivedStateOf, key 等优化手段）
3. 解释每项优化背后的原理
4. 提供 Profiler 验证指标的建议
四、Prompt 编写最佳实践
4.1 上下文管理策略
| 策略 | 说明 |
|---|---|
| 分块投喂 | 不要一次性粘贴 10 个文件。先给接口定义，再给实现，最后给调用方 |
| 差异标记 | 使用 // [新增] // [修改] // [删除] 标注变更点 |
| 依赖清单 | 始终声明 minSdk, targetSdk, 关键库版本，避免 AI 推荐过时 API |
| 反例约束 | 明确说"不要使用 AsyncTask"比说"用现代方案"更有效 |
4.2 输出控制技巧
## 输出格式控制示例
- **代码优先**：先给完整可运行代码，再在代码块后用引用符号 > 补充说明
- **逐步生成**："第一步只生成数据层，我确认后再生成 UI 层"
- **对比模式**："请用 diff 格式展示修改，标注行号"
- **安全检查**："在输出前，检查是否包含硬编码密钥或敏感信息，如果有请用 <PLACEHOLDER> 替代"
4.3 多轮对话优化
第一轮：需求 + 角色 + 约束（不给代码，让 AI 输出方案设计） 第二轮：确认方案后，提供代码上下文，要求实现 第三轮：对输出进行 Review，要求补充边界情况处理
技巧：让 AI 先输出设计思路/伪代码，确认方向正确后再输出完整实现，避免大段代码返工。
五、安卓开发常见 AI 陷阱与规避
| 陷阱 | 表现 | 规避 Prompt |
|---|---|---|
| 过时 API | 推荐 AsyncTask, Loader, FragmentPagerAdapter | "只使用 Android API 30+ 推荐的方案，如果涉及已废弃 API 请明确标注" |
| 缺失权限处理 | 生成代码未处理运行时权限 | "必须包含 Android 6.0+ 运行时权限申请逻辑，并处理用户拒绝场景" |
| 生命周期泄漏 | 在 Activity 中直接持有协程 Job 或 Callback | "确保所有异步操作都在 LifecycleScope 或 ViewModelScope 内，避免内存泄漏" |
| 硬编码字符串/尺寸 | 直接写 "确定" 或 16.dp | "字符串提取到 strings.xml，尺寸使用 dimens 或 MaterialTheme 规范" |
| 忽略配置变更 | 旋转屏幕后状态丢失 | "必须处理配置变更（configChanges 或 ViewModel + SavedStateHandle），状态持久化" |
| 主线程 IO | Room/网络操作未切换线程 | "所有数据库和网络操作必须在 IO/Dispatcher.IO 线程执行，主线程只做 UI 更新" |
| 过度绘制 | Compose 嵌套 Box/Column 导致多层背景 | "优化布局层级，避免不必要的背景绘制，遵循 Compose 性能最佳实践" |
六、高阶技巧：构建你的 Prompt 库
建议在你的项目中维护一个 prompts/ 目录：
prompts/
├── 01-code-review.md # 代码审查 Prompt
├── 02-unit-test.md # 单测生成 Prompt
├── 03-compose-ui.md # UI 组件生成
├── 04-refactor-mvi.md # 架构重构
├── 05-bug-analyze.md # 崩溃分析
└── 06-gradle-fix.md # 构建修复
代码审查专用 Prompt 示例：
## 角色
严格的 Android Code Reviewer，遵循 Google 官方 Kotlin 规范。
## 审查重点
1. 空安全（?. / ?: / let 的合理使用，避免 !!）
2. 协程异常处理（CoroutineExceptionHandler / supervisorScope）
3. 生命周期安全（是否使用 repeatOnLifecycle）
4. 资源泄漏（Bitmap, Cursor, Flow 收集是否及时取消）
5. 性能隐患（不必要的对象创建、remember 缺失）
6. 安全性（Intent 暴露、WebView 配置、日志敏感信息）
## 输出格式
对每个问题：
- [严重/警告/建议] 文件:行号 - 问题描述 - 修复建议代码片段
七、总结：Prompt 质量检查清单
在发送 Prompt 前，确认是否包含：
- 角色定义：明确技术栈和经验年限
- 版本约束：minSdk, targetSdk, 关键库版本
- 完整上下文：相关代码、错误日志、配置文件
- 具体任务：重构/生成/修复/优化，明确动作
- 输出格式：代码块、diff、分步骤、中文注释
- 否定约束：明确禁止的方案（如"不要用反射"）
- 边界情况：空状态、错误处理、权限、配置变更
最后建议：AI Coding 的效率不取决于 AI 有多强，而取决于你描述问题的精确度。在安卓开发这种强上下文、强约束的领域，多花 2 分钟写 Prompt，能节省 30 分钟的调试时间。
如果你需要，我可以针对你当前的具体项目技术栈（Compose/ViewSystem、协程/RxJava、Hilt/Koin 等）定制一套更精准的 Prompt 模板。
