AI编程精准化：Qoder Rules规则与跨平台代码生成实战

1. 项目概述：从“瞎写”到“精准输出”的Prompt设计革命

如果你最近在尝试用AI辅助写代码，尤其是涉及到跨平台开发时，很可能经历过这样的挫败：你满怀期待地输入“帮我写一个登录页面”，结果AI给你生成了一堆不知所云的HTML标签，或者一个只有按钮没有逻辑的界面。更糟的是，当你指定了“用Flutter实现”或“适配iOS/Android/HarmonyOS三端”时，它可能直接开始胡言乱语，把不同平台的API和设计规范混为一谈。这种“AI瞎写”的现象，根源往往不在于模型本身的能力，而在于我们给出的指令——也就是Prompt——不够精准。

今天要聊的“Qoder Rules”，并不是某个具体的软件或工具，而是一套我总结的、用于指导AI进行高质量代码生成的规则与范式。你可以把它理解为一套给AI程序员看的“开发规范”和“需求文档模板”。它的核心目标，就是解决上述痛点：通过精心设计的Prompt，约束AI的思考路径和输出范围，让它从“天马行空的实习生”变成“严谨靠谱的资深工程师”，最终生成可直接使用或仅需微调的三端（iOS、Android、HarmonyOS）代码。

为什么这件事如此重要？因为随着大模型能力的普及，AI编程的门槛正在迅速降低，但“能用”和“好用”之间隔着一条巨大的鸿沟。一个模糊的Prompt就像给建筑师一张潦草的草图，他可能给你盖出任何形状的房子。而一个精准的、遵循“Qoder Rules”的Prompt，则是一份详尽的设计图纸、材料清单和施工规范，能确保最终的建筑既坚固又美观。本文将手把手带你拆解这套规则的设计逻辑，并附上经过实战检验的、针对三大移动平台的核心代码模板。无论你是想提升日常开发效率，还是希望构建更智能的代码助手，这里的内容都能让你告别AI的随机发挥，真正掌控生成代码的质量与方向。

2. Qoder Rules设计哲学：构建AI的“思维框架”

在深入具体规则之前，我们必须先理解其背后的设计哲学。Prompt Engineering（提示工程）不是魔法咒语，而是与AI模型进行清晰、结构化沟通的科学与艺术。对于代码生成任务，尤其是跨平台这种复杂场景，我们需要为AI搭建一个稳固的“思维框架”。

2.1 核心原则：约束、上下文与角色扮演

首先，最核心的原则是“约束优于自由”。AI模型在无限的可能性中搜索答案，如果不加以约束，其输出就会变得不可预测且充满噪音。我们的Prompt必须像河道一样，引导AI的“思维流”流向我们期望的目的地。这包括：

• 技术栈约束：明确指定语言、框架、版本（如“使用Kotlin + Jetpack Compose”、“使用SwiftUI”、“使用ArkTS”）。
• 输出格式约束：要求以特定格式输出，如完整的代码块、包含关键步骤的注释、甚至指定文件名。
• 风格与规范约束：定义代码风格（如遵循Google Java Style Guide）、禁用某些不安全或过时的API。

其次，是提供“充足的上下文”。AI没有项目背景知识。你需要告诉它这个模块在整个应用中的角色、相关的业务逻辑、以及可能的数据模型。例如，生成一个“用户详情页”的Prompt，如果包含了用户数据模型（User类）的定义，AI生成的数据绑定代码就会准确得多。

最后，是巧妙的“角色扮演”。这是大幅提升输出质量的关键技巧。不要直接说“写代码”，而是为AI赋予一个专业角色。例如：

“你是一位拥有10年经验的资深iOS架构师，精通SwiftUI和现代iOS设计规范（HIG）。请以清晰、模块化且易于维护的方式，完成以下任务...”

这个简单的设定，能激活模型内部与“专家”、“最佳实践”相关的知识分布，使其输出的代码在结构、可读性和健壮性上显著提升。

2.2 跨平台生成的独特挑战与应对策略

为iOS、Android、HarmonyOS三端生成代码，是Qoder Rules要解决的高阶问题。这里的核心挑战在于“一致性”与“平台特性”的平衡。

• 一致性：业务逻辑、数据流、组件命名应尽可能保持一致，以降低后续维护成本。
• 平台特性：必须尊重各平台的原生设计语言（iOS的HIG、Android的Material Design、HarmonyOS的原子化服务理念）、导航模式、系统API及生命周期。

因此，我们的Prompt设计必须采用“分而治之”的策略。不要试图在一个Prompt里让AI同时生成三端代码，这几乎必然导致混乱。正确的做法是：

1. 先定义统一的“核心需求与接口”：用一个Prompt让AI抽象出平台无关的业务逻辑接口和数据模型。这是我们的“宪法”。
2. 再针对各平台“具体实现”：基于上一步的产出，分别撰写针对iOS、Android、HarmonyOS的详细实现Prompt，并引用之前定义好的接口。

这种“抽象-具体”的两段式Prompt，能确保三端代码在核心逻辑上同源，同时在UI和系统交互上又能充分发挥各平台优势。

实操心得：在给AI分配“跨平台架构师”角色时，我发现一个有效的技巧是要求它“假设你正在为一个使用统一领域模型但需要原生UI体验的项目工作”。这能更好地引导它去思考如何拆分共享逻辑与平台特定代码。

3. 精准Prompt的黄金结构拆解

一个能产出高质量代码的Prompt，绝不是一句话的请求。它应该是一份结构清晰的微型“技术任务书”。下面我拆解一个黄金结构，你可以把它当作模板来填充内容。

3.1 结构一：角色与上下文定义（奠定基调）

这是Prompt的开篇，目的是设定AI的“人格”和工作的“背景板”。

• 角色：明确、具体的专家角色。例如：“你是一位专注于性能优化的Android开发专家”或“你是一位熟悉HarmonyOS Stage模型和原子化服务开发的工程师”。
• 上下文：简要说明项目背景、技术选型原因、以及本次生成代码将要集成到的模块位置。例如：“本项目是一个采用Clean Architecture的跨平台笔记应用，当前需要开发‘笔记列表’功能模块。数据层和领域层已使用Kotlin Multiplatform实现，现在需要你完成Android端的UI层。”

示例段落： “你是一位资深移动端全栈工程师，尤其擅长编写高质量、可测试的原生UI代码。我们正在开发一个名为‘QuickNote’的跨平台应用，其核心业务逻辑已用共享的Kotlin代码实现。现在，需要你为应用的‘设置’页面编写原生UI代码。这个页面将独立部署到iOS、Android和HarmonyOS三个平台，因此需要你分别考虑各平台的UI惯例和系统API。”

3.2 结构二：任务与需求描述（明确目标）

这是最核心的部分，需要清晰、无歧义地描述你要什么。应用“用户故事”的格式会非常有效。

• 格式：作为【用户角色】，我想要【达成某个目标】，以便于【获得某种价值】。
• 细化：将这个用户故事拆解成具体的、可验证的功能点列表。

示例段落： “核心用户故事：作为QuickNote的用户，我想要在一个设置页面中调整应用的主题、字体大小和备份频率，以便获得更个性化的使用体验。 具体任务清单：

1. 提供一个开关，用于在‘浅色’和‘深色’主题间切换。
2. 提供一个滑块（Slider）或分段控件（Segmented Control），用于调整正文字体大小（范围：14pt-22pt）。
3. 提供一个下拉菜单或选择器，用于设置自动备份频率（选项：从不、每天、每周、每月）。
4. 所有设置项的改变应立即生效，并持久化保存到设备的本地存储中（请使用各平台推荐的本地持久化方案）。
5. 页面UI应遵循各平台最新的设计指南，并具有良好的可访问性支持。”

3.3 结构三：约束条件与输出规范（划定边界）

这部分告诉AI“不要做什么”以及“必须怎么做”，是控制输出质量的关键。

• 技术约束：编程语言、框架、最低API/SDK版本、依赖库（或注明使用原生SDK，避免第三方库）。
• 代码质量约束：要求添加必要的注释（特别是复杂逻辑处）、遵循特定的命名规范（如驼峰命名法）、处理可能的异常。
• 输出格式约束：明确要求输出完整的、可编译的代码块，并指定代码块的语言标识。可以要求将不同平台的代码分别放在标记好的独立区域。

示例段落： “约束与规范：

• 技术栈：iOS端请使用SwiftUI，适配iOS 16+；Android端请使用Jetpack Compose，适配API 24+；HarmonyOS端请使用ArkTS，基于Stage模型。
• 代码要求：请为每个平台的实现编写完整的、可独立运行的视图（View/Composable/Component）代码。关键状态变更和持久化操作需添加行内注释。避免使用任何预览（Preview）专用的代码，确保代码在真机运行环境下的纯粹性。
• 输出格式：请将三个平台的代码分别放在三个标记为‘swift’、‘kotlin’、‘```arkts’的代码块中。在每个代码块开始前，用一行注释简要说明该平台实现的特点。”

3.4 结构四：示例与参考（提供范本）

对于复杂逻辑或希望AI模仿特定风格的情况，提供一段示例代码或描述期望的代码结构，效果极佳。这就是“Few-Shot Learning”（少样本学习）在Prompt中的应用。

• 提供输入-输出对：展示一段简单的输入描述和你期望的代码输出。
• 描述代码结构：例如，“我希望视图采用MVVM模式，请将状态管理逻辑单独抽离到一个ViewModel/ViewState类中”。

示例段落： “参考示例：以下是我们项目中‘用户头像组件’的Android端实现风格，请参考其状态管理和组合函数的结构：

// 状态类 data class AvatarState(val imageUrl: String?, val isLoading: Boolean = false) // 视图模型 class AvatarViewModel : ViewModel() { ... } // 可组合函数 @Composable fun UserAvatar(state: AvatarState, onTap: () -> Unit) { ... }

希望本次‘设置页面’的代码也采用类似的状态驱动UI和清晰的关注点分离模式。”

4. 三端实战模板与逐行解析

掌握了黄金结构，我们现在将其应用于具体场景。我将以一个“设置页面”为例，展示如何为iOS、Android、HarmonyOS分别构建精准Prompt，并解析生成的代码关键点。

4.1 通用核心Prompt（抽象层）

首先，我们生成一份平台无关的核心需求定义，作为三端共同的“蓝图”。

Prompt内容： “你是一位软件架构师，请为一个跨平台移动应用的‘设置’功能进行领域建模和接口设计。忽略具体UI，专注于数据和行为。 核心需求：

1. 应用主题：支持‘浅色’和‘深色’两种模式。
2. 字体大小：一个可调节的数值，用于控制正文字体。
3. 备份频率：枚举类型，可选值为：从不、每天、每周、每月。
4. 所有设置都需要持久化存储，并在应用启动时恢复。 请输出：

• 一个代表设置项的数据类/结构体定义（Settings）。
• 一个设置项仓库的接口（SettingsRepository），包含读取和保存两个方法。
• 简要说明主题切换、字体大小调整这两个操作如何通知UI更新（例如，使用可观察的数据流或回调机制）。 请使用简洁的伪代码或Kotlin语法描述，确保其概念能轻松映射到Swift、Kotlin和ArkTS。”

AI输出解析与要点： 这个Prompt迫使AI先思考业务本质。它通常会输出一个包含theme、fontSize、backupFrequency字段的Settings数据类，以及一个saveSettings(settings: Settings)和loadSettings(): Settings的仓库接口。关于UI更新，它可能会提到使用LiveData、StateFlow（Android）、@Published属性包装器或ObservableObject（iOS）、@State和@Provide/@Consume（HarmonyOS）等响应式机制。这份输出是我们后续所有平台Prompt的“输入文档”。

4.2 iOS (SwiftUI) 实战Prompt与代码解析

接下来，我们基于上述蓝图，为iOS平台生成具体实现。

Prompt内容： “角色：你是精通SwiftUI和现代iOS开发的专家。 任务：基于以下领域模型，实现QuickNote应用的设置页面UI。

• 数据模型：Settings结构体（包含theme、fontSize、backupFrequency）。
• 仓库接口：SettingsRepository。 要求：

1. 创建一个SettingsViewModel，它继承自ObservableObject，并包含一个@Published的Settings属性。在初始化时从SettingsRepository加载数据，并提供一个保存方法。
2. 创建主视图SettingsView。使用Form和Section组织界面。
3. 主题切换：使用Picker搭配SegmentedPickerStyle实现。
4. 字体大小：使用Slider，并旁边以Text实时显示当前值（如“17pt”）。
5. 备份频率：使用Picker（样式为MenuPickerStyle或WheelPickerStyle）。
6. 任何设置项的修改都应实时更新ViewModel中的状态，并通过onChange修饰器或在视图消失时（.onDisappear）自动触发保存。
7. 遵循iOS Human Interface Guidelines，确保布局舒适，使用标准的系统控件。 约束：使用SwiftUI，适配iOS 16+。输出完整的SettingsViewModel和SettingsView代码，并添加必要注释。”

生成代码关键解析：

// 1. ViewModel：数据与逻辑中心 class SettingsViewModel: ObservableObject { @Published var settings: Settings private let repository: SettingsRepository init(repository: SettingsRepository) { self.repository = repository // 初始化时加载 self.settings = repository.loadSettings() } func saveSettings() { repository.saveSettings(settings) } } // 2. 主视图：声明式UI struct SettingsView: View { @StateObject private var viewModel: SettingsViewModel var body: some View { Form { Section(header: Text("显示")) { // 主题切换 Picker("主题", selection: $viewModel.settings.theme) { Text("浅色").tag(Theme.light) Text("深色").tag(Theme.dark) } .pickerStyle(.segmented) // 使用分段式选择器，符合iOS习惯 // 字体大小滑块 HStack { Text("字体大小") Slider(value: $viewModel.settings.fontSize, in: 14...22, step: 1) Text("\(Int(viewModel.settings.fontSize))pt") .foregroundColor(.secondary) } } Section(header: Text("数据")) { // 备份频率选择 Picker("备份频率", selection: $viewModel.settings.backupFrequency) { ForEach(BackupFrequency.allCases, id: \.self) { frequency in Text(frequency.localizedString).tag(frequency) } } // 使用导航链接形式的选择器，是iOS标准交互 } } .navigationTitle("设置") .onChange(of: viewModel.settings) { _ in // 任何设置变化，自动保存 viewModel.saveSettings() } } }

注意事项：SwiftUI中，@StateObject用于初始化ViewModel并保证其生命周期与视图一致。onChange修饰器是响应状态变化并执行副作用（如保存）的推荐方式。注意将Picker的selection参数绑定到ViewModel中@Published属性的双向绑定（$符号），这是数据驱动的关键。

4.3 Android (Jetpack Compose) 实战Prompt与代码解析

现在，我们转向Android平台。

Prompt内容： “角色：你是精通Jetpack Compose和现代Android架构的专家。 任务：基于之前定义的Settings数据类和SettingsRepository接口，实现Android端的设置界面。 要求：

1. 使用ViewModel和StateFlow来管理UI状态。创建一个SettingsUiState数据类来封装所有UI状态（加载中、成功、错误等），成功状态包含Settings对象。
2. 主界面使用Scaffold和Column，内部使用Card和Column来分组设置项，模仿Material Design 3的Settings页面布局。
3. 主题切换：使用Switch或SegmentedButtons（MD3组件）。
4. 字体大小：使用Slider，旁边用Text显示数值。
5. 备份频率：使用DropdownMenu或ExposedDropdownMenuBox实现下拉选择。
6. 状态变更应自动触发ViewModel中的保存逻辑（可使用debounce或snapshotFlow避免频繁保存）。
7. 充分考虑状态恢复（进程销毁重建）和横竖屏切换。 约束：使用Kotlin，Jetpack Compose，最小API 24。输出完整的SettingsViewModel、SettingsScreen可组合函数以及SettingsUiState定义。”

生成代码关键解析：

// 1. UI状态密封类 sealed class SettingsUiState { object Loading : SettingsUiState() data class Success(val settings: Settings) : SettingsUiState() data class Error(val message: String) : SettingsUiState() } // 2. ViewModel class SettingsViewModel(private val repository: SettingsRepository) : ViewModel() { private val _uiState = MutableStateFlow<SettingsUiState>(SettingsUiState.Loading) val uiState: StateFlow<SettingsUiState> = _uiState.asStateFlow() init { loadSettings() } private fun loadSettings() { /* 从repository加载并更新_uiState */ } fun updateTheme(newTheme: Theme) { // 更新状态并保存 ( _uiState.value as? SettingsUiState.Success)?.let { currentState -> val newSettings = currentState.settings.copy(theme = newTheme) _uiState.value = SettingsUiState.Success(newSettings) viewModelScope.launch { repository.saveSettings(newSettings) } } } // ... 其他更新方法 } // 3. 可组合函数 @Composable fun SettingsScreen(viewModel: SettingsViewModel = viewModel()) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() // 使用生命周期感知的收集 when (val state = uiState) { is SettingsUiState.Success -> { val settings = state.settings Scaffold(topBar = { TopAppBar(title = { Text("设置") }) }) { padding -> Column(modifier = Modifier.padding(padding)) { // 主题切换 - 使用Material 3的SegmentedButtons SegmentedButtonsRow { Theme.values().forEach { theme -> SegmentedButton( selected = settings.theme == theme, onClick = { viewModel.updateTheme(theme) }, shape = MaterialTheme.shapes.small ) { Text(theme.displayName) } } } // 字体大小滑块 var sliderPosition by remember { mutableFloatStateOf(settings.fontSize) } Row(verticalAlignment = Alignment.CenterVertically) { Text("字体大小", modifier = Modifier.weight(1f)) Slider( value = sliderPosition, onValueChange = { newValue -> sliderPosition = newValue viewModel.updateFontSize(newValue) }, valueRange = 14f..22f, steps = 8, modifier = Modifier.weight(2f) ) Text("${sliderPosition.toInt()}pt", modifier = Modifier.weight(0.5f)) } // 备份频率下拉菜单 var expanded by remember { mutableStateOf(false) } ExposedDropdownMenuBox(expanded = expanded, onExpandedChange = { expanded = !expanded }) { TextField( value = settings.backupFrequency.displayName, onValueChange = {}, readOnly = true, trailingIcon = { ExposedDropdownMenuDefaults.TrailingIcon(expanded = expanded) } ) ExposedDropdownMenu(expanded = expanded, onDismissRequest = { expanded = false }) { BackupFrequency.values().forEach { frequency -> DropdownMenuItem( text = { Text(frequency.displayName) }, onClick = { viewModel.updateBackupFrequency(frequency) expanded = false } ) } } } } } } // ... 处理Loading和Error状态 } }

实操心得：在Compose中，使用StateFlow+collectAsStateWithLifecycle是连接ViewModel和UI的最佳实践之一，能自动管理生命周期，避免内存泄漏。对于像字体大小滑块这种需要即时视觉反馈的操作，可以在本地用remember { mutableStateOf }维护一个临时状态，然后在值改变或交互结束时同步到ViewModel，这样既能保证流畅交互，又能控制保存频率。

4.4 HarmonyOS (ArkTS) 实战Prompt与代码解析

最后，我们来看HarmonyOS的ArkTS实现。

Prompt内容： “角色：你是熟悉HarmonyOS ArkUI框架和Stage模型开发的专家。 任务：基于共享的Settings数据定义，实现HarmonyOS端的设置页面。 要求：

1. 使用Stage模型的Ability和Page结构。在EntryAbility中创建并管理SettingsRepository。
2. 在设置页面（SettingsPage）中，使用@State装饰器管理页面内的UI状态，并通过@Link或@Prop接收从父组件（或通过router传递）的Settings对象。
3. 使用Column、Row、Text、Button等基础组件构建界面。对于选择器，使用Picker组件。
4. 主题切换：可以考虑使用两个Button或一个Toggle组件来实现。
5. 字体大小：使用Slider组件。
6. 备份频率：使用Picker组件，设置其range属性。
7. 任何修改都应通过@Link双向同步回父组件，并在适当的时机（如页面onPageHide时）调用SettingsRepository进行持久化保存。
8. 界面布局应遵循HarmonyOS设计规范，保持简洁清晰。 约束：使用ArkTS语言，基于API 9+的Stage模型开发。输出SettingsPage的完整UI组件代码，并说明其与Ability及数据仓库的交互方式。”

生成代码关键解析：

// 1. 页面组件 @Entry @Component struct SettingsPage { // 通过@Link接收从父组件（或路由参数）传来的设置对象，实现双向绑定 @Link settings: Settings build() { Column({ space: 12 }) { // 页面标题 Text('设置') .fontSize(24) .fontWeight(FontWeight.Bold) .margin({ top: 20, bottom: 30 }) // 主题切换区域 Text('主题').fontSize(18).margin({ bottom: 10 }) Row({ space: 20 }) { Button(this.settings.theme === Theme.Light ? '浅色 ✓' : '浅色') .onClick(() => { this.settings.theme = Theme.Light // 可以在这里或页面生命周期回调中触发保存 }) Button(this.settings.theme === Theme.Dark ? '深色 ✓' : '深色') .onClick(() => { this.settings.theme = Theme.Dark }) } .margin({ bottom: 30 }) // 字体大小调节 Text(`字体大小: ${this.settings.fontSize.toFixed(0)}pt`).fontSize(18) Slider({ value: this.settings.fontSize, min: 14, max: 22, step: 1, style: SliderStyle.OutSet }) .onChange((value: number) => { this.settings.fontSize = value // 滑块拖动时实时更新，可考虑防抖保存 }) .margin({ bottom: 30 }) // 备份频率选择 Text('备份频率').fontSize(18) Picker({ range: this.settings.getBackupFrequencyOptions() }) // 假设有个方法返回显示文本数组 .selected(this.settings.backupFrequencyIndex) .onChange((index: number) => { this.settings.backupFrequency = BackupFrequency.values()[index] }) .margin({ bottom: 20 }) } .padding(20) .width('100%') .height('100%') .onPageHide(() => { // 页面隐藏时（如返回），触发保存操作 // 需要通过某种方式（如EventHub或回调）通知Ability保存this.settings AppStorage.setOrCreate('settings_key', this.settings) }) } }

注意事项：在HarmonyOS的ArkUI中，@Link装饰器是实现父子组件间双向数据同步的利器。对于需要跨页面或与Ability共享的数据，AppStorage或LocalStorage是常用的持久化方案。需要注意的是，Stage模型中，UI与逻辑分离更清晰，复杂的业务逻辑和持久化操作通常放在Ability或单独的Service中，页面组件主要关注UI渲染和用户交互。onPageHide生命周期函数是执行保存操作的好时机。

5. 高级技巧与常见问题避坑指南

掌握了基础模板后，我们还需要一些高级技巧来应对更复杂的场景，并避开常见的“坑”。

5.1 处理复杂逻辑与多步任务

当任务非常复杂时，不要指望一个Prompt解决所有问题。采用“链式Prompt”或“思维链（Chain-of-Thought）”技巧。

• 链式Prompt：将大任务拆解成顺序执行的小任务。例如，先让AI“设计数据库表结构”，再根据其输出，让它“生成对应的Room Entity和DAO接口代码”，最后再“生成Repository实现类”。
• 思维链：在Prompt中要求AI“逐步思考”。例如：“请按以下步骤完成：1. 分析这个功能需要哪些数据字段；2. 设计网络请求接口；3. 编写数据解析逻辑；4. 实现UI视图。请输出每一步的思考过程和最终代码。”

5.2 让AI进行代码审查与优化

你可以让AI扮演“代码审查员”的角色。将你或AI之前生成的代码喂给它，并提问： “请以资深开发者的身份，审查下面这段 [平台] 代码。请指出：1. 任何潜在的性能问题（如内存泄漏、主线程阻塞）；2. 不符合该平台官方编码规范的地方；3. 可能的边界情况未处理；4. 给出具体的优化建议和修改后的代码片段。”

5.3 常见错误与排查清单

即使使用了精准Prompt，输出也可能不尽如人意。以下是常见问题及解决思路：

5.4 迭代优化：与AI的对话式开发

不要认为一次Prompt就能得到完美结果。将AI输出视为“初稿”，然后进行迭代优化。

1. 运行与测试：将生成的代码放入你的项目中，尝试编译和运行。
2. 定位问题：遇到错误或不符合预期的地方，将错误信息或你的观察直接反馈给AI。例如：“上面生成的SwiftUI代码中，Slider的onChange闭包在iOS 17上会导致无限循环，请修改为使用.onChange(of: viewModel.settings.fontSize) { newValue in ... }的形式。”
3. 提出具体修改要求：基于问题，给出非常具体的修改指令。AI擅长执行具体任务，而非模糊的“优化一下”。

这个过程就像是你在带领一位理解力超强但经验尚浅的助手，通过清晰的指令和及时的反馈，共同将代码打磨至完美。最终你会发现，精心设计的Prompt加上有效的迭代，能让你与AI的协作效率产生质的飞跃，真正把“瞎写”变成“精准创作”。