Android Cursor AI实践技巧

优质文章学习记录

— 9 min read

在Android开发中使用Cursor（AI代码编辑器）时，通过合理配置规则可以显著提升AI生成代码的准确性、一致性和贴合度。核心目标是让AI“理解”项目的技术栈、代码风格、项目结构和业务上下文，从而生成无需大幅修改即可使用的代码。以下是具体的配置方法和实践技巧：

一、核心配置思路：通过“规则注入”约束AI输出

Cursor的AI能力依赖于输入的“上下文”和“指令”，配置规则的本质是通过结构化提示词（Prompt）、自定义指令和上下文管理，向AI注入项目规范。主要包括4类规则：

  • 技术栈约束：明确允许使用的库、框架及版本（如“必须用Jetpack Compose而非XML布局”）；
  • 代码风格规范：统一命名、注释、格式（如“Kotlin函数名用lowerCamelCase，常量用UPPER_SNAKE_CASE”）；
  • 项目结构固定：定义包名、模块划分、文件存放规则（如“网络请求代码必须放在data/remote目录”）；
  • 上下文关联：让AI结合项目已有代码生成逻辑（如“参考BaseViewModel的写法，实现LoginViewModel”）。

二、配置规则的具体方法

1. 预设“项目规则模板”（核心）

创建一个项目级规则文档（如project_rules.md），集中定义所有规范，在使用Cursor时通过指令引入，让AI每次生成代码前“阅读”规则。

模板示例：

# 项目开发规范（Android） ## 技术栈约束 - 语言：仅使用Kotlin（禁止Java）； - UI框架：必须使用Jetpack Compose（版本1.4.3），禁止XML布局； - 架构：采用MVVM + 分层架构（data/domain/ui）； - 网络：使用Retrofit 2.9.0 + OkHttp 4.10.0，配合Coroutines和Flow； - 本地存储：使用Room 2.5.2，禁止直接操作SQLite； - 依赖注入：使用Hilt 2.44； - 其他：必须使用AndroidX组件，禁止support库。 ## 代码风格 - 命名： - 类名：UpperCamelCase（如LoginScreen、UserRepository）； - 函数/变量：lowerCamelCase（如getUserInfo、userName）； - 常量：UPPER_SNAKE_CASE（如MAX_RETRY_COUNT = 3）； - 资源：前缀+功能（如string/login_title、compose/LoginScreen.kt）； - 注释： - 类和公共函数必须添加KDoc注释（包含功能、参数、返回值）； - 复杂逻辑需添加行内注释（// 处理网络错误重试）； - 格式： - 缩进4空格，每行不超过120字符； - 函数体不超过30行，超过需拆分； - 优先使用Kotlin特性（如空安全、扩展函数、密封类）。 ## 项目结构 - 包名根目录：com.example.myapp - 模块划分： - app（主模块） - core（核心库：Base类、工具类） - feature：按功能拆分（feature:login、feature:home） - 分层结构（以feature:login为例）： - ui：Compose界面（LoginScreen.kt）、ViewModel（LoginViewModel.kt） - domain：用例（LoginUseCase.kt）、实体（LoginUser.kt） - data： - remote：API接口（LoginService.kt） - local：本地存储（LoginDao.kt） - repository：实现（LoginRepositoryImpl.kt） - 资源存放： - 字符串：res/values/strings_login.xml（按功能拆分） - 图片：res/drawable/login_*.png ## 上下文关联 - 所有ViewModel必须继承core.viewmodel.BaseViewModel（含loading、error状态管理）； - 网络请求必须通过core.network.ApiResponse处理（统一封装成功/失败/异常）； - Compose组件必须使用core.theme.MyAppTheme包裹，遵循主题规范。

使用方法：
在Cursor中新建文件时，通过Ctrl+K触发指令，输入：
参考项目规则文档（内容如下），生成[具体功能，如登录界面的Compose代码]：[粘贴project_rules.md内容]

AI会优先遵循文档中的规则生成代码，避免出现技术栈冲突（如突然生成XML布局）或风格混乱。

2. 自定义指令（Command）：快速复用规则

Cursor支持将常用指令保存为“自定义指令”，避免重复输入规则。通过Settings > Commands > Add Command创建，调用时直接输入指令名称。

示例1：生成Compose界面的指令

  • 指令名称：生成Compose界面
  • 使用：输入生成Compose界面，再补充需求（如“登录界面，包含用户名输入框、密码输入框、登录按钮”），AI会自动套用规则。

指令内容：

按照以下规则生成Jetpack Compose界面代码： 1. 技术栈：仅用Compose 1.4.3，使用Material3组件； 2. 结构：函数名以[Screen]结尾（如LoginScreen），参数仅包含ViewModel和导航回调； 3. 风格：使用Column/Row布局，添加适当padding（8.dp倍数），支持深色模式； 4. 关联：使用core.theme.MyAppTheme，引用对应功能的字符串资源（如R.string.login_title）。 需求：[用户输入的具体界面需求]

示例2：生成Repository的指令

  • 指令名称：生成Repository

指令内容：

按照以下规则生成Repository实现类： 1. 技术栈：实现对应Domain层的Repository接口，使用Hilt的@Singleton注解； 2. 依赖：通过构造函数注入RemoteDataSource和LocalDataSource； 3. 逻辑：优先从本地获取数据，本地无则从网络请求，通过Flow返回结果； 4. 错误处理：使用core.network.ApiException处理网络错误，统一封装。 需求：[用户输入的具体Repository功能，如“用户信息Repository，包含getUserById方法”]
3. 上下文管理：让AI“看到”项目已有代码

Cursor的AI生成质量依赖于“上下文窗口”（即AI能获取的项目已有代码），上下文越完整，生成的代码关联性越强。

方法1：上传项目文件到Cursor

  • 打开Cursor后，通过File > Open Folder导入整个Android项目；
  • 生成代码前，通过Ctrl+K指令明确引用已有文件，例如：
    参考com.example.myapp.core.viewmodel.BaseViewModel的代码，实现LoginViewModel，包含登录逻辑和状态管理
  • AI会自动读取BaseViewModel的结构（如状态变量、事件处理方式），生成兼容的代码。

方法2：嵌入代码片段到指令
若项目文件较多，可手动复制关键代码片段到指令中，让AI聚焦核心逻辑：

已知项目中BaseViewModel的代码如下： class BaseViewModel : ViewModel() { protected val _loading = MutableStateFlow(false) val loading: StateFlow<Boolean> = _loading.asStateFlow() protected val _error = MutableStateFlow<String?>(null) val error: StateFlow<String?> = _error.asStateFlow() protected fun launchSafe(block: suspend () -> Unit) { viewModelScope.launch { _loading.value = true try { block() } catch (e: Exception) { _error.value = e.message } finally { _loading.value = false } } } } 请基于此类，实现LoginViewModel，包含login(username: String, password: String)方法，调用LoginUseCase，更新状态。
4. 技术栈约束：精确到版本和替代方案

为避免AI使用过时或未指定的技术，需在规则中明确“允许/禁止”的库，并指定替代方案。

示例指令片段：

技术栈约束： - 禁止使用： - 禁止用AsyncTask（已过时），必须用Coroutines替代； - 禁止用findViewById，必须用Compose的remember或ViewBinding（若用XML）； - 禁止用Gson手动解析JSON，必须用Retrofit的MoshiConverter； - 强制版本： - Kotlin：1.8.22； - Jetpack Compose：1.4.3（禁止使用1.5.0+的新API，避免兼容问题）； - Hilt：2.44（必须使用@HiltViewModel注解ViewModel）。
5. 代码风格统一：通过“示例+规则”双重约束

AI对“示例”的理解优于抽象规则，可在指令中嵌入一段符合风格的代码作为“模板”，让AI模仿。

示例：约束Kotlin函数风格

代码风格要求： - 函数参数过多时，使用换行和缩进； - 优先使用命名参数调用函数； - 复杂逻辑拆分到私有函数，主函数保持简洁。 示例（正确风格）： private fun showLoginDialog( onConfirm: (username: String, password: String) -> Unit, onCancel: () -> Unit ) { AlertDialog( title = { Text(text = stringResource(R.string.login_title)) }, text = { LoginInputContent() }, confirmButton = { Button(onClick = { val (user, pwd) = getInputValues() onConfirm(user, pwd) }) { Text(text = stringResource(R.string.confirm)) } }, dismissButton = { Button(onClick = onCancel) { Text(text = stringResource(R.string.cancel)) } } ).show() } 请按照此风格，实现注册对话框的Compose函数。
6. 项目结构固定：强制文件路径和命名

通过规则明确“什么功能的代码必须放在什么位置”，避免AI生成的文件“乱放”。

示例指令片段：

项目结构规则： - 所有Compose界面文件必须放在：[模块]/src/main/java/com/example/myapp/[feature]/ui/compose/，文件名以[功能]Screen.kt结尾（如LoginScreen.kt）； - ViewModel必须放在：[模块]/src/main/java/com/example/myapp/[feature]/ui/viewmodel/，类名以[功能]ViewModel.kt结尾，且添加@HiltViewModel注解； - API接口（Retrofit）必须放在：[模块]/src/main/java/com/example/myapp/[feature]/data/remote/service/，类名以[功能]Service.kt结尾，使用@GET/@POST注解； - 字符串资源必须按功能拆分到res/values/strings_[feature].xml（如strings_login.xml），键名格式：[feature]_[功能]（如login_username_hint）。 请生成登录功能的API接口，遵循上述路径和命名规则。

三、高级技巧：迭代优化规则

  1. 从“宽松”到“严格”逐步收紧
    初期可只定义核心规则（如技术栈和大致结构），生成代码后发现问题（如命名不统一），再补充细化规则（如“变量名必须包含业务含义，禁止用tmp、data1等”）。
  2. 保存“失败案例”，反推规则
    若AI生成不符合预期的代码（如误用XML布局），记录案例并在规则中明确禁止：错误案例：之前生成了activity_login.xml，禁止使用XML，必须用Compose的LoginScreen.kt。
  3. 结合Cursor的“编辑建议”功能
    生成代码后，选中代码块，用Ctrl+K指令：检查这段代码是否符合项目规则（[粘贴规则]），并修复不符合的地方，AI会自动修正风格或技术栈问题。

四、注意事项

  1. 规则不宜过度冗余：只定义核心约束（技术栈、结构、关键风格），避免限制过细（如“每行必须有一个空格”），否则AI可能因规则冲突生成错误代码。
  2. 适配项目迭代：当项目技术栈升级（如Compose从1.4.3升到1.5.0）或结构调整时，及时更新project_rules.md，避免AI使用旧规则。
  3. 验证兼容性：AI可能生成“符合规则但存在版本兼容问题”的代码（如使用Compose 1.5.0的API但项目用1.4.3），需结合Android Studio的Lint检查验证。

总结

通过预设项目规则模板、自定义指令、管理上下文和迭代优化，可让Cursor的AI生成代码高度贴合项目需求。核心是“让AI明确边界”——知道该用什么技术、遵循什么风格、放在什么位置，从而从“生成可用代码”提升到“生成可直接集成的代码”，大幅减少后期修改成本。

Read more

Llama Factory成本效益分析：企业级微调投入产出比

Llama Factory成本效益分析：企业级微调投入产出比 想用大模型解决自家业务问题，但一听到“微调”两个字，很多技术负责人就头疼。自己搭环境、写代码、调参数，不仅周期长，对团队技术要求高，最后算下来，人力、算力、时间成本可能远超预期，投入产出比（ROI）成了一笔糊涂账。 有没有一种方法，能让企业像搭积木一样，低成本、高效率地定制自己的专属大模型？Llama Factory的出现，正在让这个想法变成现实。它把复杂的模型微调过程，变成了一个可视化的“工厂流水线”。今天，我们就来算一笔账：使用Llama Factory进行企业级模型微调，到底能省多少钱、提多少效？它的真实投入产出比如何？ 1. 传统企业微调：一笔昂贵的“技术债” 在深入分析Llama Factory之前，我们得先看看，如果不使用它，企业通常会面临哪些成本和挑战。 1.1 显性成本：看得见的资金消耗

AI绘画R18提示词实战指南：从基础原理到安全实践

快速体验 在开始今天关于 AI绘画R18提示词实战指南：从基础原理到安全实践 的探讨之前，我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来，但作为开发者，如何将大模型（LLM）真正落地为一个低延迟、可交互的实时系统，而不仅仅是调个 API？ 这里有一个非常硬核的动手实验：基于火山引擎豆包大模型，从零搭建一个实时语音通话应用。它不是简单的问答，而是需要你亲手打通 ASR（语音识别）→ LLM（大脑思考）→ TTS（语音合成）的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说，这是个绝佳的练手项目。 从0到1构建生产级别应用，脱离Demo，点击打开 从0打造个人豆包实时通话AI动手实验 AI绘画R18提示词实战指南：从基础原理到安全实践 背景痛点分析 1. 伦理风险与合规挑战 在AI绘画领域，R18内容创作面临着多重挑战。平台审核机制日益严格，违规内容可能导致账号封禁甚至法律风险。同时，不同地区对数字内容的法律界定存在差异，开发者需要特别注意合规边界。
Python 实现 AI 图像生成：调用 Stable Diffusion API 完整教程

Python 实现 AI 图像生成：调用 Stable Diffusion API 完整教程

从零开始学习使用 Python 调用 Stable Diffusion API 生成图像，涵盖本地部署、API 调用、ControlNet、图生图等进阶技巧。 1. 技术架构 Python 客户端 Stable Diffusion API 本地部署 SD WebUI / ComfyUI 云端 API Replicate / Stability AI Stable Diffusion 模型 文生图 txt2img 图生图 img2img 局部重绘 inpainting 超分辨率 upscale 输出图像 后处理管道 存储 本地/OSS 2. 图像生成方式对比 50%25%15%10%

系统开发成本为何居高不下：低代码的工程化降本路径

在企业信息系统建设中，开发成本长期处于高位，往往并非源于单一技术选择，而是由需求不确定性、交付周期拉长、重复性开发以及后期维护复杂化等多重因素共同叠加所致。传统定制开发模式在复杂业务场景下，容易陷入人力密集、协同成本高企和工程可控性不足的问题。 低代码并非通过简化操作来“替代”工程能力，而是尝试以模型驱动、自动化生成与结构化配置为核心，重构系统开发与交付的工程路径。在这一框架下，成本的降低更多体现在重复劳动的压缩、交付链条的收敛以及系统演进过程的可控化，而非单纯的开发速度提升。 理解低代码在工程体系中的作用边界与技术前提，是判断其是否具备真实降本能力的关键。 可视化工作流 流程功能 流程功能清单 流程使用示例 系统界面 流程参数设置 流程示例 流程设计（请假申请） 流程设计（主管审批） 流程设计（完整请假流程） 可视化开发：应用构建技术分析 1.组件化设计：模块化与复用 组件化设计是可视化开发的核心基础，通过将界面元素与业务逻辑拆解为独立可组合单元，实现开发效率、可维护性和系统复用性的提升。在实际应用中，组件化不仅涉及前