AI驱动需求梳理与Spec编写：让PRD自动变成技术方案

AI提效Android开发系列 · 第2/5篇

从需求到上线，用AI重塑Android开发全流程

第1篇：AI提效Android开发全景图：从需求到上线的AI工具链

第2篇：AI驱动需求梳理与Spec编写：让PRD自动变成技术方案（本篇）

⏳ 第3篇：AI编码提效实战：Skill、Rule与上下文工程

⏳ 第4篇：AI Code Review：让每一行代码都有AI审查员

⏳ 第5篇：AI Bug修复与测试生成：从崩溃日志到修复PR的自动化

你有没有数过，一个需求从开始编码到提测，中间要回去找产品确认多少次？

我数过。上个季度8个需求，平均每个需求中途确认9.6次。每次确认的原因几乎一样：PRD没写清楚某个边界case，开发写到一半发现了。

上一篇我们画了AI提效Android开发的全景图，这一篇聚焦到一个被严重低估的环节——需求梳理和Tech Spec编写。先讲个具体的故事。

上个季度，我们组接了一个"用户画像标签页"的需求。产品给了一份PRD，写了两页半，配了三张原型图。看起来很清楚——无非是一个列表页加个筛选器嘛。

结果写到一半才发现：PRD没说标签数据从哪来（是本地缓存还是实时拉？），没说标签冲突时的优先级（用户手动标签和算法标签冲突怎么办？），没说列表为空时展示什么。三个遗漏，砍掉了两天进度。

这不是产品经理的问题。PRD本来就不是写给编译器看的——它是用人话描述业务意图。而把业务意图翻译成技术可执行的Spec，这个"翻译"过程，才是Bug的第一温床。

AI恰好擅长这个"翻译"。

一、PRD到Tech Spec：传统方式的三个痛点

先别急着看AI怎么做，先想清楚没有AI的时候我们哪里痛。你才能判断AI有没有真的解决问题，而不是换了一种方式制造问题。

痛点一：信息遗漏——PRD里没写的，开发到一半才发现

最典型的场景：PRD描述了正常路径（happy path），但关于异常处理只写了一句"异常情况给出合适提示"。什么叫"合适"？网络超时弹Toast还是弹Dialog？连续失败三次要不要降级到缓存数据？这些都得开发自己补。

据我统计，一份中等复杂度的PRD，从需求评审到开发完成，期间平均要回去找产品确认8-12个未定义的边界case。每次确认都是一次上下文切换——你正在写代码，被拉去开会对齐一个"这里到底该怎么处理"，回来又得花20分钟找到刚才写到哪了。

痛点二：格式不统一——每个人的Tech Spec长得都不一样

你们团队的技术方案文档长什么样？我赌100块，打开Wiki搜"技术方案"，你会看到至少三种不同的模板。有人写接口定义，有人不写；有人画状态机，有人用文字描述；有人分析性能影响，有人一笔带过。

不统一的后果不只是"看着不整齐"。它导致Code Review时reviewer看的信息量不一样，导致测试写用例时没有确定性参照物，导致半年后接手的人完全不知道当初的设计意图。

痛点三：耗时——写Spec本身就是一项重脑力劳动

写一份高质量的Tech Spec通常需要4-8小时（中等复杂度需求）。它要求你同时思考业务逻辑、数据模型、接口设计、状态管理、异常处理、性能影响这六个维度。很多时候你写到接口定义的时候突然发现数据模型得改，改了数据模型又发现状态机转换条件变了——像拼一个六面都有约束的魔方。

所以很多开发者选择"不写Spec直接动手"。不是懒，是写Spec的成本太高了。但不写的代价更高——只是它发作在后面。

二、AI解析PRD：不是让AI写代码，是让AI帮你"查漏"

我第一次用AI分析PRD的时候，心态是"让它帮我写技术方案初稿"。试了之后发现，AI生成的Spec初稿大概能用60%，但它帮我发现的PRD遗漏，价值是那60%的三倍。

为什么？因为AI没有"默认假设"。你看到"用户画像标签页"这五个字，脑子里已经有了一个具象的模型——你之前做过类似的东西，你下意识会补全很多细节。但这些"补全"有一部分是对的，有一部分是你以为对但实际上PRD的意图不一样。

AI不会"脑补"。它严格按照PRD原文分析，结果就是——它会精准指出"这里缺信息了"。

2.1 我的PRD分析Prompt模板

经过几个月的迭代，我沉淀了一个效果比较好的PRD分析prompt。核心思路是让AI从三个角色出发去审视PRD：

# PRD 深度分析 prompt

你是一位资深 Android 架构师。请从三个角色视角
分析以下 PRD 文档：

## 角色一：挑剔的技术评审（找漏洞）
- 列出 PRD 中未明确定义的行为和边界case
- 每个遗漏标注优先级：P0（会阻塞开发）
  / P1（会导致线上Bug）/ P2（体验瑕疵）
- 对每个遗漏给出你的建议方案（不只是指
  出问题，要给答案）

## 角色二：数据模型设计师（建结构）
- 从 PRD 中提取所有实体和关系
- 为每个实体定义字段、类型、约束
- 标注哪些字段是 PRD 显式提到的，
  哪些是你推断补充的

## 角色三：状态机工程师（理流程）
- 提取核心业务流程的状态转换
- 每个状态标注：触发条件、执行动作、
  目标状态
- 标注哪些转换路径 PRD 没有覆盖

## 输出要求
- 使用结构化 Markdown
- 遗漏清单按优先级排序
- 每个模块给出你的置信度
  （高/中/低），标注需要和产品确认的点

注意几个设计要点：

• 三角色设计不是花架子——单一视角容易漏。"找漏洞"角色解决痛点一，"建结构"角色解决痛点二的数据模型统一，"理流程"角色解决状态机遗漏

• 要求给建议方案而不只是指出问题——这很关键。AI说"PRD没定义空状态的展示"没什么用，但如果它接着说"建议显示引导文案+创建按钮，参考Material Design空状态规范"，你就有了一个可以直接和产品确认的具体方案

• 置信度标注是给自己的提醒——AI高置信度的推断你可以直接采纳，低置信度的就拉上产品确认

2.2 实战：一个真实PRD的AI分析结果

回到"用户画像标签页"那个需求。我把PRD原文（大概800字+3张原型图描述）丢给Claude Code，用上面的prompt分析。AI返回了以下关键发现：

AI 发现的 PRD 遗漏清单（节选）

[P0] 标签数据源未定义 — PRD提到"展示用户标签"但未说明数据来自本地缓存、远端接口还是两者混合**。建议**：采用远端优先+本地缓存降级策略，缓存有效期建议15分钟。

[P0] 标签冲突策略缺失 — PRD未定义当算法标签和用户手动标签值矛盾时的处理**。建议**：用户手动标签优先，展示时标注来源（"手动"/"算法推断"），置信度降低时UI弱化显示。

[P1] 筛选器组合逻辑未定义 — 多标签筛选是AND还是OR**？建议**：默认AND（取交集），提供切换开关。

[P1] 列表分页策略缺失 — 标签数量超过一屏时的加载方式**。建议**：LazyColumn + Paging3 按需加载，每页20条。

[P2] 空状态展示未定义 — 无标签数据 / 筛选结果为空两种空状态的区分**。建议**：无数据显示"暂无标签"+引导按钮，筛选为空显示"无匹配结果"+清除筛选按钮。

5个遗漏里有2个P0。如果不是AI帮我在动手之前就发现，这两个P0大概率会在编码到第三天的时候爆出来——那时候改的成本是现在的五倍。

而且注意——每个遗漏后面都跟了建议方案。这意味着我去找产品确认的时候，不是问"这里怎么办？"，而是说"这里有个遗漏，我建议这样处理，你觉得OK吗？"。前者需要产品思考一遍再回答，后者只需要点头或摇头。效率差了一个量级。

三、Spec模板设计：让AI生成结构化技术方案

查漏只是第一步。接下来要把PRD翻译成结构化的Tech Spec。这里的关键是你得给AI一个模板，否则它生成的东西格式随机、粒度不一。

经过半年迭代，我固定了一个6模块Spec模板，每个模块对应一个AI生成prompt。

3.1 六模块Spec模板

Tech Spec 六模块结构

Module 1: 接口定义

API endpoint、请求/响应体、错误码定义、限流策略

Module 2: 数据模型

Room Entity定义、字段类型与约束、Migration策略、索引

Module 3: 状态机

页面状态枚举、转换条件、对应UI表现、副作用（Side Effects）

Module 4: 异常处理

网络异常、数据异常、权限异常的降级方案与用户提示文案

Module 5: 性能约束

首屏加载目标、内存预算、列表滚动流畅度指标

Module 6: 测试契约

核心路径测试用例、边界条件清单、Mock数据定义

为什么是这六个模块？因为它们恰好覆盖了开发中最常回头修改的六个维度。你可能没在Spec里定义异常处理策略，但你一定会在编码的时候遇到网络超时——到时候要么临时拍脑袋，要么回去翻PRD发现PRD也没写，要么跑去找产品确认。不如一开始就让AI帮你把这六个维度都过一遍。

3.2 接口定义的自动化生成

以"用户画像标签页"为例，AI基于PRD分析结果自动生成的Retrofit接口定义：

interface UserTagApi {

    /**
     * 获取用户标签列表
     * 支持分页 + 筛选
     * 缓存策略: Cache-Control max-age=900
     */
    @GET("api/v1/user/{uid}/tags")
    suspend fun getUserTags(
        @Path("uid") uid: String,
        @Query("page") page: Int = 1,
        @Query("size") size: Int = 20,
        @Query("source") source: TagSource? = null,
        @Query("category") category: String? = null
    ): ApiResponse<PagedResult<UserTag>>

    /**
     * 手动添加/修改用户标签
     * 幂等设计：相同 tagKey 重复调用为更新
     */
    @PUT("api/v1/user/{uid}/tags/{tagKey}")
    suspend fun upsertTag(
        @Path("uid") uid: String,
        @Path("tagKey") tagKey: String,
        @Body body: UpsertTagRequest
    ): ApiResponse<UserTag>
}

// AI 同时生成了错误码定义
enum class TagErrorCode(val code: Int) {
    TAG_NOT_FOUND(40401),
    TAG_CONFLICT(40901),  // 标签冲突
    RATE_LIMITED(42901),  // 写入限流
    INVALID_TAG_VALUE(40001)
}

几个值得注意的细节：

• AI自动加了缓存策略注释——因为在PRD分析阶段它已经识别到"数据源"是个P0遗漏，并建议了15分钟缓存

• upsert接口用了PUT + 幂等设计——这不是PRD写的，是AI根据"用户手动标签优先级高于算法标签"这个业务规则推断出的设计

• 错误码设计已经预留了标签冲突的枚举——和PRD遗漏清单联动

这就是"AI不只是生成代码，它在做设计推理"的体现。

3.3 状态机的自动化生成

状态机是Android开发里最容易忘记画、但出Bug时最后悔没画的东西。AI生成的状态定义：

sealed interface TagScreenState {

    /** 首次加载中 */
    data object Loading : TagScreenState

    /** 数据加载成功 */
    data class Content(
        val tags: List<UserTag>,
        val activeFilters: Set<TagFilter>,
        val isRefreshing: Boolean = false
    ) : TagScreenState

    /** 空状态（无标签 or 筛选无结果）*/
    data class Empty(
        val reason: EmptyReason
    ) : TagScreenState

    /** 加载失败 */
    data class Error(
        val error: TagError,
        val cachedTags: List<UserTag>? = null
    ) : TagScreenState
}

enum class EmptyReason {
    NO_TAGS,       // 用户确实没有标签
    FILTER_NO_MATCH // 有标签但筛选条件无匹配
}

这里有一个设计细节值得单独说：Error 状态里带了一个 cachedTags 字段。为什么？因为AI在分析PRD时识别到了"缓存降级"的需求——当网络失败时，如果本地有缓存数据，应该展示缓存数据+一个错误提示条，而不是直接显示全屏错误。

PRD原文完全没提这个需求。但它是一个正确的设计决策。如果没有AI提前识别并在状态定义里预留这个字段，你在实现网络错误处理的时候大概率会发现状态模型不够用，要么追加字段（改ViewModel + UI），要么临时糊一个全局变量——后者是典型的技术债。

四、AI辅助方案评审：给你的Spec再加一层保险

Spec初稿生成后，别急着开工。我会让AI再做一次"方案评审"——但这次用的是一个完全不同的prompt，而且最好在一个新的对话session里做。

为什么要新session？因为在同一个对话里，AI对自己刚生成的Spec有"认同偏差"——它倾向于觉得自己的方案是对的。换一个新的session，AI会更客观地审视这份Spec。

4.1 评审Prompt设计

# Tech Spec 评审 prompt

你是一位在大厂带过10人以上团队的 Android
技术负责人。请严格评审以下 Tech Spec，重点
检查：

## 1. 一致性检查
- 接口定义的字段 与 数据模型的字段 是否对齐
- 状态机的每个状态 是否都有对应的 UI 描述
- 异常处理的每种错误 是否都有对应的错误码

## 2. 遗漏检查
- 并发场景：快速点击、页面切换中的竞态
- 数据一致性：乐观更新失败后的回滚策略
- 生命周期：configuration change 后的状态恢复

## 3. 过度设计检查
- 有没有为 MVP 阶段不需要的功能做了设计？
- 有没有可以用更简单方案替代的复杂设计？

输出格式：问题列表，每个问题标注
[严重/一般/建议] + 具体修改方案

第三点"过度设计检查"非常重要。AI生成Spec时有一个通病——倾向于过度设计。它会给你加一堆你还不需要的抽象层、预留一堆可能永远用不到的扩展点。评审prompt需要明确让它检查这一点。

4.2 评审发现的典型问题

上面那份标签页Spec经过评审后，AI发现了三个问题：

[严重] 缺少乐观更新的回滚策略：用户手动修改标签时，如果先更新UI再调接口，接口失败后需要回滚UI状态。当前Spec没有定义回滚机制**。修改方案**：在ViewModel中维护pending操作队列，接口成功后清除，失败后重放最后一次确认状态。

[一般] 筛选器状态未纳入SavedStateHandle：configuration change（如屏幕旋转）后筛选条件会丢失**。修改方案**：筛选状态序列化存入SavedStateHandle。

[建议] 接口定义中的source枚举过度设计：当前只需要区分"手动/算法"两种来源，但Spec中定义了5种TagSource枚举值**。修改方案**：MVP阶段精简为MANUAL和ALGORITHM两个值，后续按需扩展。

第一个问题是真实存在的严重问题——乐观更新在Android Compose开发中非常常见，但回滚策略确实容易被忽略。第三个问题则证明了"过度设计检查"的必要性——AI确实在第一轮生成时多加了东西。

五、实战全流程：从拿到PRD到输出可执行Spec

把前面的内容串起来，我现在的完整工作流是这样的：

PRD → Tech Spec AI辅助工作流

Step 1: PRD 查漏（AI）

三角色prompt分析 → 遗漏清单 + 建议方案 → 找产品确认P0/P1

⏱ 约30分钟（含产品确认）← 原来2小时

↓

Step 2: Spec 生成（AI）

六模块模板 → AI生成初稿 → 人工Review&调整

⏱ 约1小时（含人工调整）← 原来4-6小时

↓

Step 3: Spec 评审（AI，新session）

一致性 + 遗漏 + 过度设计检查 → 修改Spec → 定稿

⏱ 约30分钟 ← 原来1-2小时（或直接跳过）

↓

Step 4: 同步 & 开工

Spec归档到Wiki → 同步给QA写测试用例 → 开始编码

⏱ 不变

整个流程从原来的6-10小时压缩到2-2.5小时。而且——这可能比时间节省更重要——Spec的质量明显变好了。因为AI帮你做了系统性的检查，你不再依赖"有经验的开发者能想到更多边界case"这种不可复制的能力。

六、2026年的新变量：Spec-Driven Development

最后聊一个正在发生的行业趋势。2026年开始，"Spec-Driven Development"（SDD）正在从概念变成工具链。

最典型的代表是 AWS 刚发布的 Kiro——一个AI IDE，它的核心工作流就是"先写Spec再写代码"。你给它一个需求描述，它先生成一份结构化的Spec，你确认后它再基于Spec生成代码。如果中途要改，你改Spec而不是直接改代码——代码自动重新生成。

Google本月也推出了 Android CLI + Agent Skills，其中 Agent Skills 本质上就是给AI编码代理定义的"任务规范"——换句话说，一种更精确的Spec。Google的数据显示，使用Agent Skills后，AI代理的token消耗降低了70%，任务完成速度提升3倍。

这背后的逻辑是一样的：AI越来越擅长把Spec变成代码，但"Spec本身的质量"成了瓶颈。如果Spec写得好，AI几乎可以自动完成从Spec到可运行代码的全过程；如果Spec模糊或矛盾，AI生成的代码就会有各种问题。

所以这篇文章讲的PRD→Spec流程，实际上是在解决一个更底层的问题：在AI时代，写好Spec可能比写好代码更重要。

因为代码AI可以帮你写。但Spec——它是你对需求的理解、对架构的判断、对边界的预判——这是AI目前只能辅助、不能替代的环节。而恰恰是这个环节，决定了后面所有环节的上限。

本篇小结

• AI分析PRD最大的价值不是生成文档，而是系统性查漏——找出你默认忽略的边界case

• 结构化的Spec模板（接口/数据/状态/异常/性能/测试）让AI输出可控、可Review

• Spec评审要在新session里做，避免AI对自己的输出产生认同偏差

• 2026年SDD范式兴起，写好Spec的能力正在成为AI时代的核心竞争力

常见误区：别踩这三个坑

最后分享三个我踩过的坑，希望你能跳过：

误区一：把整个PRD一次性丢给AI。如果PRD超过2000字，先分模块拆解再逐模块分析，效果远好于一股脑塞进去。AI的注意力和人一样——信息量太大时细节会被淹没。

误区二：直接用AI生成的Spec不做验证。AI生成的接口定义可能和后端实际提供的不一致。Spec里的每个API endpoint都要和后端对齐确认，AI只是帮你生成初稿，不是替你确认事实。

误区三：让AI做Spec和评审用同一个session。前面已经说过原因——认同偏差。我曾经图省事，在同一个对话里先生成再评审，结果AI评审时给自己的方案打了5颗星。换了个新session，同样的Spec被挑出了三个严重问题。这个差异很真实。

下一篇是系列第3篇《AI编码提效实战：Skill、Rule与上下文工程》——聊怎么让AI真正理解你的10万行级Android项目，而不是每次都从零猜你的代码规范。Cursor Rules、Claude Code CLAUDE.md、GitHub Copilot Instructions三套规范系统的深度对比和实战技巧。

—— 全文完 ——