客户端 Native AI使用探索
Context Engineering

本文记录 VAS 团队围绕 Native 开发 AI 辅助实践的完整演进路径：从 Rule 到 Code Graph，再到 Agent Skill + Rules 的协同方案，探索 AI 在复杂原生工程中的落地之道。

一、背景

1.1 行业 AI 趋势

AI 进入研发流程，带来的不只是一个新工具，更是一种新的协作方式。在 AI 时代下，学习使用 AI 不仅是应用新技术，更是一场需要主动拥抱的认知升级。

1.2 团队需求：从 Lua 走向 Native

VAS 业务目前已完成 AI 在 Lua 场景的使用探索，并应用在日常版本开发中（主要用于代码 Review 和 Lua 模块辅助开发）。

然而在实际研发结构里，原生需求与开发量占比约在 70% 左右，是团队研发的绝对主体。相比 Lua 脚本开发，原生开发涉及平台差异、架构历史、模块耦合、真机适配、联调链路等一系列更复杂的问题。因此，探索 AI 在原生场景的使用，是当前阶段最迫切的提效方向。

二、现状

2.1 Native 开发的 AI 使用困境

原生由于平台多样性、系统版本分散、设备繁多、代码复杂度高等问题，导致 AI 使用难度远高于 Lua 场景。具体困难来自三个维度：

技术栈层面

• 平台碎片化：不同 OS API 使用不同（UIKit / SwiftUI / LuaKit）
• 开发模式多样：MVC、MVP、MVVM 并存，架构不统一
• 构建复杂：编译时间长、真机适配成本高
• 代码复杂度高：所有功能集成在一个工程，调用链路错综复杂

模型层面

• 模型训练不足：开源的优质客户端代码较少，模型对大型原生工程的理解能力有限
• 上下文限制严重：实现一个功能往往需要理解多个文件甚至整个工程

业务层面

• 工程复杂：平台差异、历史架构、模块耦合
• 业务复杂：一个入口背后常挂着多套状态、分支逻辑和特殊房型规则
• 验证复杂：很多问题不是"能不能生成代码"，而是"生成后能不能稳定落地"

三、目标

探索适用团队的 AI 使用方式，重点解决以下关键问题：

1. 原生开发里，AI 适合在哪些场景使用？
2. 如何把项目上下文高效、准确地传递给 AI？
3. 如何在提升效率的同时，把风险控制在可接受范围内？
4. 如何规范团队使用方式，保证多人多次使用的一致性，完成团队技术沉淀？

四、方案演进

4.1 阶段一：Rule（通用规范约束）【2025.Q4】

Rule 是 AI 的持久约束，用于规范代码风格和编码习惯。

作用： 解决「怎么写代码」——安全、可维护性、异常处理等通用规范。

使用：

• 编码基础规范
• 代码 Review

局限： 无法解决「代码在哪、逻辑是什么」的上下文问题；有长度限制，需 alwaysApply 设置。

《codereview.mdc》 · 《聊天室Android 代码审查方案》 · 《聊天室iOS 代码审查方案》

4.2 阶段二：Code Graph（代码图谱）【2025.12–2026.01】

为了解决 Rules 无法解决的上下文问题，尝试把项目分模块构建 Code Graph，在需求迭代时，AI Agent 可参考相关模块的 Code Graph 快速理解架构。

使用：

• 用户在提问时明确提及模块名称或使用 @booster、@on-mic-list 等引用
• Agent 根据 Code Graph 理解架构后搜索代码
• Agent 生成代码实现

sequenceDiagram
    participant User as 用户
    participant Agent as AI Agent
    participant Graph as Code Graph 文档
    participant Code as 代码库
    
    User->>Agent: 提出需求："修改PK数值加成"
    Agent->>Graph: 识别相关模块 (@booster)
    Agent->>Graph: 读取模块文档
    Graph-->>Agent: 返回架构文档内容
    Agent->>Agent: 解析架构、组件、API
    Agent->>Code: 搜索相关代码文件
    Code-->>Agent: 返回代码内容
    Agent->>Agent: 结合 Code Graph 生成实现
    Agent->>User: 提交代码变更

优缺点：

《Code Graph 方案》

4.3 阶段三：Agent Skill（模块业务知识包）+ Rule【2026.02 开始】

为了解决 CodeGraph 方式遇到的问题，尝试在 Rule 的基础上，为每个核心模块构建 Agent Skill，该 Skill 可以理解为本地 CodeGraph。

Skill 的核心价值在于：把模块的 Code Graph 拆分为对应的 Skill + References，执行时按需分层加载，保证正确理解上下文、调用链路、历史信息等

Skill 渐进式加载机制：

1. 优先加载：name + description（约 100 词，用于语义匹配）
2. 触发时加载：SKILL.md 主体（建议 < 200 行）
3. 需要时加载：references/ 下的详细文档

使用 Skill 之后：

• Rule 保证：无论是否触发 Skill，生成的代码都符合团队通用规范
• Skill 加持：触发时 AI 可以了解业务上下文，不再每次从头探索文件结构，避免理解偏差和 Token 过大
• 开发者：不再重复解释业务背景，团队对同一模块的认知趋于统一

SKILLs + Rules 协同工作时序图：

sequenceDiagram
    participant U as 用户
    participant C as Cursor
    participant R as Rules
    participant S as 场景 SKILL

    U->>C: 发起请求（CCD描述文档+Prompt）
    C->>R: 加载 全局rules（始终生效）
    R-->>C: 规范要点 + 检查清单 + 完整规范引用
    C->>C: 按描述/关键词/@ 匹配场景
    C->>S: 加载对应 SKILL（如 on-mic-list、运营位、booster 等）
    S-->>C: 模块架构、数据流、关键类、何时用
    C->>C: 综合 Rules 约束 + SKILL 上下文
    C->>U: 生成/修改代码（符合规范且贴合模块设计）

《Agent Skills》

五、聊天室新旧需求上的 AI 使用

按照日常版本开发，场景分为两大类：新需求开发 和 旧需求迭代。

5.1 新需求场景（以 PK 暴击时刻功能为例）

新需求场景下，AI 的使用路径如下：

1. 需求整理：AI 辅助梳理业务背景，输出层级分明、分类规划的需求文档
2. AI 技术分析：输出系统架构（含 Mermaid 流程图）、模块划分、业务逻辑详解
3. 需求重塑：结合设计稿，将需求转化为 AI 可直接执行的结构化编码指令（类型枚举、宽高、布局库指定等）
4. AI Coding：基于重塑后的需求，生成符合项目规范的代码【遵循全局 Rules】
5. 人工确认 + 联调验证：工程师验收业务逻辑、边界场景与真机表现

5.2 旧需求迭代场景

旧需求迭代下，AI 的使用路径如下：

1. 需求整理：AI 辅助梳理业务背景，输出层级分明、分类规划的需求文档
2. AI 技术分析：输出系统架构（含 Mermaid 流程图）、模块划分、业务逻辑详解
3. 需求重塑：结合设计稿，将需求转化为 AI 可直接执行的结构化编码指令（类型枚举、宽高、布局库指定等）
4. 使用 Agent Skill：加载对应模块 Skill，让 AI 具备业务上下文
5. 生成代码：AI 基于 Skill 精准定位改动位置，生成符合现有架构的修改代码【遵循全局 Rules】
6. 人工确认 + 联调验证：确认改动范围、回归影响面，真机验证

不同场景下 AI 的前置成本与编码增效对比（以单次需求为基准估算）：

《Native 使用AI探索》

六、Skill + Rules 方案规范

6.1 Skill + Rules 在项目中的使用流程

6.1.1 构建 Code Config Document（CCD）

技术根据 PRD 文档 + 设计稿，在需求宣讲过后，结合自己对需求的理解，整理需求，编写 Code Config Document（CCD 文档）。

要求：人工或者借助 AI 整理 PRD 文档。

6.1.2 补充 Prompt

在 CCD 的基础上，按需补充指令：

用 OC/Swift 实现、使用 Masonry 布局、自定义初始化方法传入枚举、新建数据模型...

• 按需补充 UI 说明指令，比如在 xx 目录下新建继承 UIView 的视图
• 按需补充架构设计指令，比如要求使用抽象工厂方式实现
• 按需补充逻辑指导指令，比如事件使用代理/通知方式传递

6.1.3 使用 Rule + Skill 生成代码

Rule 始终生效保证代码规范；触发对应模块的 Skill 后，AI 基于业务知识直接定位代码位置、生成符合架构规范的实现代码，无需每次重新建立上下文。

6.1.4 验证

真机联调验证 + 回归测试，确认生成代码在复杂场景下的稳定性。

• 验证链路相同：AI 生成代码后，验证流程与人工编码完全一致（编译→真机联调→跑 Case），不因"AI生成"而省略任何环节，需提前纳入排期。
• 问题定位难度略高：AI 生成的是全新代码，出错后需要人工逐段 check。应对方式：AI 编码前做好方案拆解，代码生成后人工一定要 check 代码，读懂代码。
• 成本随需求和方案而定：需求无大改→验证额外成本趋近于 0；需求大改→AI 生成代码整体回滚，重新生成即可。

分工不是"AI 负责开发，人负责验收"，而是让 AI 在最适合的位置提效，人工始终保留业务判断和质量控制权。

6.2 Skill 知识沉淀成果

SKILL 按场景/模块划分，目标是：独立、完整、稳定，并降低 SKILL 的长期维护成本。

围绕聊天室核心模块，已逐步完成一批 Skill 沉淀：

6.3 总结

探索出一套团队在 Native 使用 AI 的方式，完成了既定目标：

1. 原生开发里，AI 适合在哪些场景使用？【新需求开发、旧需求迭代都可以】
2. 如何把项目上下文高效、准确地传递给 AI？【按模块构建 SKILL】
3. 如何在提升效率的同时，把风险控制在可接受范围内？【SKILL + RULES + 人工在各个环节协同】
4. 如何规范团队使用方式，保证多人多次使用的一致性，完成团队技术沉淀？【沉淀项目 RULES、SKILLS】

核心结论： Rule 兜底通用规范，Skill 补模块上下文，人工始终保留业务判断与最终验收权。这套组合拳，是当前阶段原生 AI 协作最可落地的方式。

七、问题与挑战