从 PRD 到 MR：企业级 Android 项目的 AI 编码工作流设计
引言
本文介绍我在 Cursor 中构建的一套工作流：从 PRD 和设计稿输入开始，到技术方案生成、结构化任务拆解、逐任务编码、真机验证，最终自动提交 MR。整条链路被拆分为 7 个阶段，每个阶段设有门控和人工确认点，并通过分层加载、按需引入技能（Skills）和跨会话知识持久化，解决了 AI 在长链决策中质量衰减、每次需求“从零开始”两大核心痛点。
注：本文内容基于一个具体的企业 Android 项目定制（MVP 架构、RxJava 规范、自有 UI 组件库），但底层设计思路——分阶段门控 + 知识持久化 + Token 分层 + 按需加载——可推广至任何技术栈。
整体架构
下图展示了从输入到交付的完整信息流：
submodule update"] end S0 --> S1 subgraph S1 ["阶段1: 需求分析"] A1["读取跨需求知识"] --> A2["获取 PRD/接口文档
（钉钉MCP）"] A2 --> A3["提取功能点 & 列出不清项"] A3 --> A4["输出分析文档.md"] end S1 -->|人工确认| S2 subgraph S2 ["阶段2: 设计稿分析"] B1["读取 Figma / 截图"] --> B2["px→dp/sp 转换
布局结构推导"] B2 --> B3["追加到分析文档"] end S2 -->|人工确认| S3 subgraph S3 ["阶段3: 技术方案"] C1["生成技术方案.md/.html"] --> C2["结构化任务表"] C2 --> C3["服务端联调.md"] end S3 -->|方案确认| S4 subgraph S4 ["阶段4: 逐任务编码"] direction LR D1["读取学习笔记"] --> D2["搜索同类实现"] D2 --> D3["加载对应 Skill"] D3 --> D4["编码 + 模块编译"] D4 -->|人工确认| D5["更新任务表"] D5 -->|循环| D1 end S4 -->|全部完成+自审| S5 subgraph S5 ["阶段5: 整包验证"] E1["编译安装"] --> E2["启动 App"] E2 --> E3["Android MCP 真机验证"] E3 --> E4["输出验证报告.html"] end S5 -->|验证通过| S6 subgraph S6 ["阶段6: 提交 MR"] F1["创建分支"] --> F2["提交代码 & 子模块"] F2 --> F3["创建 MR"] F3 --> F4["沉淀项目经验"] end S6 --> MR["MR 链接 + 验证报告"]
整个流程由 Cursor Agent 驱动，底层依赖以下机制：
| 层级 | 机制 | 作用 |
|---|---|---|
| Rules | .cursor/rules/*.mdc | 编码约束，按场景自动注入 |
| Skills | .cursor/skills/*/SKILL.md | 专项能力（API、DB、UI 生成等），按需加载 |
| Commands | .cursor/commands/*.md | 用户显式触发的快捷任务 |
| MCP Servers | .cursor/mcp.json | 外部工具桥接（文档、设计稿、真机、Git 平台） |
核心设计原理
1. 门控机制：防止决策质量衰减
AI 在长链路中的决策质量随步骤数指数衰减。若让 AI 从 PRD 直通 MR 而不设中间校准，后期产物质量必然严重退化。这与人类开发同理——需求未理清就编码，必然返工。
因此，我们在每个阶段结束时强制设置门控：AI 必须通过 Ask Question 等待人工确认，方可进入下一阶段。关键门控点包括：
- 阶段 3 → 4：技术方案须经确认。方案若偏离需求，后续所有编码皆为无效。
- 阶段 4 → 5：全部任务完成 + 末次编译通过 + 编码规范自审通过。
- 阶段 5 → 6：真机验证完成，PRD 功能点全部勾选。
阶段 4 内部更细：每完成一个任务即确认一次。越早发现实现偏差，修复成本越低。
2. Token 分层控制：降低上下文开销
Cursor 每轮对话会注入 alwaysApply: true 的 Rules。注入内容越多，可用的上下文窗口越小，留给代码分析的空间就越窄。我们将约束拆分为三层：
| 层 | 触发方式 | 内容示例 | Token 量级 |
|---|---|---|---|
| L0 核心层 | 每轮对话 | 16 条禁止项 + 11 条必须项 | ~500 |
| L1 编码层 | 编辑 .java/.kt/.xml 时 | 生命周期、UI 组件规范、常见错误 | ~800 |
| L2 领域层 | 编辑 API/DB 文件时 | 核心约束精简版 + 指向对应 Skill | 各 ~200 |
核心层体积小（约 40 行）且几乎不变，对 Anthropic 的 prompt caching 非常友好——前缀越稳定，缓存命中率越高，API 调用成本越低。非编码阶段（如 git 操作、PRD 分析）仅加载 L0，Token 消耗控制在 500 以内。
3. Skills 按需加载：避免知识全量注入
Cursor Skills 通过 YAML frontmatter 中的 description 让 AI 判断是否需要加载完整内容。AI 每轮对话开始时只读取所有 Skill 的 description（约 50 token/个），匹配当前任务时才加载完整正文。
我们定义了 19 个专项 Skill，覆盖以下能力域：
- 核心开发：API 网络层、数据库操作、数据模型、埋点
- UI 相关：布局 XML 生成、设计稿转布局（含 Figma 智能学习）、MVP 页面生成
- 质量保障：模块编译验证、编码规范自审、脚本化代码审查
- 辅助工具：Android SO/AAR 依赖分析、AB 实验下线、Wiki 生成/转换/同步检查
- 流程控制：需求开发全流程（阶段 0→6）
全部 Skill description 合计约 1000 token，完整内容超过 25000 token——按需加载节省了 95% 以上的无关上下文。
例如，“API 网络层开发” Skill 的 description 为“API 网络层开发规范”。当 AI 在阶段 4 需要编写网络请求时，自动匹配并加载 Skill 内的完整模板（API 类选择指南、请求模板、URL 构建方式、错误处理）。若任务与 API 无关，则该知识从不进入上下文。
4. 结构化任务表：突破上下文长度限制
Cursor 单会话上下文有上限。一个需求若包含 10+ 编码任务，执行到第 7、8 个时，AI 可能已遗忘前面完成了哪些任务。单纯依赖上下文记忆不可靠。
我们在阶段 3 产出的技术方案中嵌入结构化任务表（Markdown 表格）：
| # | 任务名 | 类型 | Skill | 涉及文件 | 状态 |
|---|---|---|---|---|---|
| 1 | 添加 xxx 字段 | 数据 | data-model | parsers.xml | ⬜ 待开始 |
| 2 | 新增 xxx 接口 | 逻辑 | api-development | CoreXxx.java | ⬜ 待开始 |
状态枚举：⬜ 待开始 → 🔄 进行中 → ✅ 已完成 → ⏭️ 已跳过。
该表写入磁盘文件，AI 可随时重新读取最新状态，不依赖上下文窗口的“记忆力”。评估过 JSON 格式的追踪方案，最终选择 MD 表格——因为人类也能直接读写，AI 解析 MD 表格毫无困难，多维护一个 JSON 只会增加同步负担。
5. 自学习循环：经验跨需求沉淀
每次需求开发中，AI 需要搜索项目内的同类实现来理解编码习惯。第一次做某类需求时需搜索 3-5 个文件；第二次同类需求若仍从头搜索，即为效率损耗。
解决方案是维护一个附属学习笔记文件 convention-learnings.md。阶段 4 编码前，AI 读取该文件，跳过已记录的模式；编码完成后的自审阶段，将新发现的模式追加到笔记中。下一个需求的阶段 4 直接读取笔记，跳过重复搜索。
关键约束：AI 从不修改 Skill 文件本身，只维护附属笔记。原因是——若 AI 将错误模式写入 Skill（核心指令），后续所有需求将受污染；笔记文件出错，删除即可，影响可控。这一设计借鉴了 Hermes Agent 的 Closed Learning Loop，并增加了安全边界。
6. 跨需求知识持久化
另一个持久化文件 project-memory.md 解决跨需求的“背景知识”传递问题：当前数据库版本、哪些接口已废弃、特殊的技术决策、踩过的坑。需求 A 结束后（阶段 6），AI 追加这些信息；需求 B 开始（阶段 1）自动加载，无需重新 grep 或翻阅历史提交。
设定了淘汰机制：文件超过 80 行时清理过时条目，避免无限膨胀导致加载开销。
阶段详解
阶段 0：代码同步
git fetch origin && git checkout origin/main && \git submodule foreach 'git fetch origin && git checkout origin/master'确保基于最新代码基线。完成后直接进入阶段 1，无需人工确认。
阶段 1：需求分析
- 加载
project-memory.md，获得跨需求背景。 - 读取 PRD + 接口文档。支持三种输入：钉钉文档链接（通过钉钉 MCP 直接拉取 Markdown）、本地文件、用户粘贴文本。
- 提取客户端功能点，列出不清项和边界遗漏；核对接口文档与 PRD 是否矛盾。
- 输出
docs/[需求名]/分析.md并请求确认。
阶段 2：设计稿分析
有 Figma 链接时通过 Framelink MCP 读取图层/样式/布局，否则使用 PRD 截图。调用设计稿转换 Skill 执行 px→dp/sp 转换、颜色格式映射、布局结构推导。产出追加至分析文档。
阶段 3：技术方案
产出三个文件：
技术方案.md（含任务表）及其.html可视化版本服务端联调.md
技术方案中的任务表是后续编码的唯一依据。每个任务标注了类型（数据/逻辑/UI）、应调用的 Skill、涉及文件列表。该表同时作为进度追踪看板。
阶段 4：逐任务编码
每个任务执行固定流水线：
（仅新场景）"] B --> C["加载对应 Skill"] C --> D["编码"] D --> E["模块编译"] E --> F{"Ask Question 确认"} F -->|通过| G["更新任务表状态"] F -->|驳回| D G --> H["下一任务"]
全部任务完成后，执行编码规范自审（5 项 Checklist）：
- 禁止项检查（如
context.getColor()、SharedPreferences直接调用） - 常量一致性
- 仓库特有约束
- Import 完整性（禁止正文中全限定类名）
- Android 安全自审（
android:exported声明、硬编码 Token、新权限、Debug 代码隔离）
自审通过后，将新发现的编码模式追加到 convention-learnings.md。
阶段 5：整包验证
这里执行的是真机 UI 验证，而非单元测试。流程如下：
逐屏验证"} D --> E["功能点全部勾选?"] E -->|否| F["定位问题"] F --> C E -->|是| G["产出验证报告.html"]
Android MCP 可执行 dump_ui_hierarchy、点击操作、截屏。AI 获取 UI 树后逐个功能点对照 PRD 检查。验证报告为单文件 HTML（内联样式，不入 git），包含功能点卡片、状态过滤、环境信息。
阶段 6：提交 MR
- 变更范围确认（主工程 + Git 子模块）。
- 创建分支，更新
.gitmodules。 - 提交并推送。
- 创建子模块 MR → 主工程 MR。
- 沉淀项目经验：将本次需求的接口变化、数据库版本变更、踩坑记录等追加到
project-memory.md。
MCP 集成与工具链
| MCP Server | 功能 | 应用阶段 |
|---|---|---|
| 钉钉文档 MCP | 读取钉钉在线文档（PRD/接口文档），返回 Markdown | 阶段 1 |
| Framelink MCP for Figma | 读取 Figma 设计稿图层/样式/布局 | 阶段 2、5 |
| Android MCP | 真机 UI dump、点击、截屏 | 阶段 5 |
| Code Review MCP | 远程 MR diff 读取 + 评论提交 | 可选（阶段 5.5） |
| Context7 | 查询第三方库文档（Fresco、RxJava 等） | 按需 |
| Sequential Thinking | 复杂问题的分步推理 | 按需 |
设计思考与感悟
1. 为什么不用并行 Agent？
需求开发本质上是串行链路：技术方案决定编码方向，编码决定验证内容，验证决定 MR 范围。并行 Agent 在此场景下没有独立的工作单元可以分配，反而会导致代码冲突和上下文割裂。Cursor 的 /multitask 适合真正独立的并行任务（如同时运行 lint 和 test），不适合有依赖关系的流水线。
2. 为什么每个阶段都要门控？
两个原因：一是质量校准——AI 在长链中的决策质量随步骤数衰减，每次确认是一次“重新对齐”；二是责任边界——用户确认后继续，若出现问题可精确定位到哪个阶段的决策有误。
3. 为什么 Skills 学习只写附属文件？
直接让 AI 修改 Skill 文件存在两个风险：第一，prompt injection——若 AI 将错误的模式写入 Skill，后续所有需求都会受影响；第二，知识退化——累积的“学习成果”可能覆盖人工精心设计的规范。附属文件 convention-learnings.md 允许人随时审阅、删除错误条目，且清空即可“重置学习”，风险远低于修改 Skill 本身。
4. Token 经济学带来的设计约束
Claude Code 社区的实测数据表明：alwaysApply 内容从 800 token 减到 500 token，prompt cache hit 率可从 12% 跃升至 61%。这是因为 Anthropic 的 prompt caching 对前缀匹配敏感——系统 prompt 越稳定，缓存命中越高，成本越低。这解释了我们将核心约束层拆得极薄且保持不变的决策。
5. 终极思考：流程自动化 vs 通用智能
当前工作流并非“AI 替代人类”，而是人类定义流程、AI 执行任务的混合模式。门控点由人决策，AI 负责重复性高、规则明确的执行环节（读文档、写代码、跑验证）。这种分工在现阶段最为务实——AI 的生成能力和推理能力仍有边界，但流程化编排可以最大化其确定性收益。
如果你的团队也在尝试 AI 辅助开发，建议从最薄弱的环节切入：在关键决策点让 AI 停下来等你确认，而不是让它一口气跑到底。这一改动往往能带来最直接的产出质量提升。在此基础上，再逐步引入知识持久化、分层加载等机制，构建适合自身项目的全流程自动化体系。