我们团队 AI 赋能需求迭代的落地情况

最近一段时间，AI 在团队里的存在感越来越强。

不管是评审、写代码，还是写文档、补用例，几乎都能看到它的身影。

网上也陆续出现了很多分享：

AI 如何重构流程、如何提升效率、如何改变研发模式。

但这篇文章还是和我之前的风格一样——

不谈那些高大上的名词，不讲“AI 驱动组织变革”，就单纯聊聊我们团队现在是怎么用 AI 的，以及它真实解决了什么问题，又没解决什么问题。

---

一、产品经理：想用，但还没形成“用法”

先说说产品经理。

他们其实挺羡慕开发和测试的：

评审会上，经常能看到开发和测试拿着 AI 生成的文档、用例、方案在讨论，甚至代码本身都是 AI 写的。

产品同学自然也会想：那需求是不是也能直接用 AI 来生成？

但根据我和他们的交流，目前主要卡在两点：

• 技术门槛：

产品经理大多不太愿意（也不太擅长）去折腾复杂的提示词、结构化输入、上下游链路。

• 公司基建还没到位：

没有成熟的需求模版、历史需求知识库、上下游自动联动能力。

所以现在的实际情况是：

AI 更多是一个“灵感提供者”，而不是“需求生成器”。

常见用法包括：

• 帮忙补充思路、拆分功能点

• 提供一些方案方向或边界提醒

• 偶尔改改措辞

但很少直接生成一整份可用的 PRD。

---

二、开发团队：中小需求几乎都会用 AI 写代码

再说开发团队。

目前我们看到的是：

中小规模需求，基本都会引入 AI 参与编码。

我在代码仓库里经常能看到一些 `spec` 文件，里面通常包含：

• 需求背景

• 实现约束

• 技术方案方向

• 一些编码规则

作为测试，我并没有深入研究他们的具体写法，但从结果来看，这套方式已经相当成熟。

大致流程是：

1. AI 生成技术方案文档 + API 文档

2. 人工 review、微调

3. AI 生成代码

4. 人工 review、修改

5. AI 生成单测并执行

从开发同学那边了解到：

• 人工改动的代码量通常不到 10%

• 技术方案和 API 文档的可靠度都很高

当然，进测之后我们还是会发现不少 bug——

这一点后面再说。

---

三、测试团队：用得最广，用得最“土”

重点说说我们测试团队。

不只是我们小团队，其实公司里：

• 基建团队

• 我们大团队下的其他测试团队

几乎都在做 AI 辅助测试的工具或流程。

不同团队：

• 用的模型不一样

• 提示词不一样

• 流程设计不一样

效果自然也会有差距。

1. 测试用例生成：已经是“标配”

在我们团队这边，不管需求大小，都会用 AI 生成测试用例。

我的实际做法是：

• 以自己团队的工具输出为主

• 参考其他工具的结果

• 再进行人工合并和补充

整体下来人工补充通常不超过 20%，时间节省是非常明显的。

2. 接口自动化：能跑的先跑

基于需求点、测试用例、技术方案、接口文档，我会让 AI 按我指定的规则生成一批接口自动化用例。

这里说实话，并不“完美”：

• 有些 UI 场景，本身就不适合做接口自动化

• AI 有时也会“强行生成”一些并不合理的接口用例

但我暂时并不打算优化这里，因为我对这件事的心态是：

先生成，执行时人工判断即可。

目前的真实效果是：

• 大约40% 的用例可以直接跑通

• 剩下的：

• 有些本来就不该跑

• 有些需要人工调整参数（AI 并不知道你的测试数据）

3. 进测后：AI 再帮忙“扫一遍”

在需求进入测试阶段后，我们还会做一件事：

让 AI 对代码和逻辑再做一次分析。

主要目标是：

• 技术类 bug

• 明显的业务逻辑问题

这一步不能代替测试，但确实能提前拦下一部分问题。

---

四、一个现实但重要的事实：大量 PPT 还没真正落地

这里也必须说点没那么好听的现实。

虽然大家都在谈 AI 赋能、效率提升，但客观来说，有不少看起来很美的能力，目前还停留在 PPT 或设想阶段。

1. 需求文档质量分析：重要，但还没真正跑起来

需求文档质量分析这件事，我们并不是没意识到它的重要性。

目前这块主要由项管团队在推进，但一直还没有形成可用的结果，我们作为测试也不太方便“僭越”。

但问题是客观存在的：

• 不同产品经理之间，需求文档质量差异非常大

• 有的需求结构清晰、约束明确

• 有的需求描述松散、边界模糊

而这件事会被 AI 明确放大 ——

需求文档写得不好，后续的代码生成、用例生成质量一定会受影响。

在缺少统一质量评估和约束的情况下，我们只能通过：

• 人工补充理解

• 人工兜底测试

来弥补前置环节的不足。

2. 运行态能力：日志分析、报警分析基本还没落地

日志分析、报警分析这类偏运维 / 运行态的 AI 能力，目前在我们团队几乎没有真正落地。

原因其实非常现实，也很“工程化”：

• 日志格式不统一

• 历史日志数据质量一般

• 报警规则本身就不够成熟

在这样的基础之上，直接引入 AI，

效果往往并不会比人工排查好多少，甚至可能更混乱。

所以目前的真实状态是：

• 日志问题更多还是靠人工定位

• 报警更多是“先响了，再去看为什么响”

至少在我们团队，AI 的主要使用场景仍然集中在「需求 → 开发 → 测试」这条链路上，

还远没有自然延伸到运行态和稳定性治理阶段。

3. AI 执行测试用例：尝试过，但适用面非常有限

现在市面上已经有不少方案在尝试让 AI 直接执行测试用例，

包括：

• 基于页面结构树（DOM / 控件树）的

• 直接基于视觉识别操作浏览器或手机的

我自己也实际尝试过其中一些方案，但结论比较明确：

至少在我们团队的场景下，这类方案目前并不好用。

主要问题集中在几个方面。

第一，单步执行成本太高。

对人来说点一下按钮是瞬间完成的事，

但 AI 往往需要进行较长时间的分析和推理，

一步操作可能就要消耗几秒甚至更久。

第二，测试链路长，对测试数据依赖极重。

我们很多场景需要复杂造数、依赖上下游状态。

AI 并不真正理解业务上下文，经常卡在数据准备阶段，

反而需要测试频繁人工介入。

第三，整体成功率不稳定。

页面微小变动、加载慢一点、弹窗顺序变化，

都可能导致执行失败。

如果要花大量精力去调优成功率，投入产出比会迅速失衡。

综合来看，如果要把 AI 执行测试这件事真正做到可用：

• 需要持续的工程投入

• 需要针对业务场景深度定制

• 维护成本并不低

而这些投入，往往还不如直接人工测试来得高效可靠。

所以我的判断是：

• 长期稳定、核心链路功能：更适合人工设计并维护传统 UI 自动化

• 快速迭代、变化频繁的功能：AI 执行得慢，成功率又不高，反而拖慢节奏

至少在现阶段，AI 更适合“帮我们生成”和“帮我们分析”，而不是直接替我们跑完整测试流程。

---

五、一些测试视角下的真实感受

站在测试的角度，我对 AI 的看法其实挺简单的：

• 它不是银弹

• 但它确实是一个稳定的效率放大器

它最有价值的地方，不是“全自动”，而是：

• 帮你把80分的基础工作快速完成

• 让人把时间花在真正需要判断和经验的地方

很多看起来“很低端”的用法：

• 生成用例

• 扫一遍代码

• 补接口自动化骨架

在实际工作中，反而是最有用、最容易落地的。

至于那些听起来很炫的：AI 自动分析日志、预测故障、全链路自愈

至少在我们团队，目前还停留在 PPT 和分享阶段。

欢迎大家私信或者评论交流～

下一篇文章我想分享一下AI在写代码、写用例中容易出现的问题以及我们是如何去“vibe testing”的。