AI高手团队产品质量下滑？深度解析五大关键原因
为什么团队里都是用 AI 的高手，产品质量还是没有飞跃，甚至还出现下滑
先限定讨论范围。
我们做的是大型 SaaS 软件——模块众多、业务链长、客户场景复杂，很多客户对稳定性、安全性、权限管控、审计追踪、数据隔离都有刚性需求。对这类产品而言，质量不是“锦上添花”，而是生存底线。
如果你做的是小而美产品，团队小、试错成本低，那后面大部分内容可以先跳过。怎么高效怎么来，先让产品跑起来验证市场价值，别过早把自己捆在流程里。
但对我们来说，不行。
我们不是那种“明天出问题后天修”的产品形态。一个权限漏洞、一次数据隔离失误、一条老客户业务链路被意外破坏，都可能直接触发客户信任危机。现在产品又在全面 AI 化转型，质量红线只会更紧。
这篇文章想复盘的是：我们团队引入 AI 研发后，实际经历了哪些阶段，每个阶段质量为何波动，我们又落地了哪些补救措施。这不是最佳实践指南，更多是一份踩坑实录。
第一阶段：Copilot 阶段，仅优化了编码流畅度
最初引入 AI 编程时，团队主力使用的是 Copilot。
这一阶段的体感很直接：它更像一个智能化的代码补全工具。写表单、写 DTO、补一些局部逻辑，确实顺手很多。但它并未真正参与需求理解、方案设计、任务拆解、跨文件修改、单元测试生成以及代码审查。
因此团队整体效率没有质的提升，质量也无明显变化。
好处是风险可控。人仍然完整掌控研发过程，AI 只是减少了重复敲击键盘的动作。坏处是，它也没有改变团队核心能力，只是让个人编码体验更舒适。
现在回头看，这更像一个过渡阶段。今天才开始引入 AI 的团队，基本不会完整经历这一阶段，可以直接跳过。
真正的拐点，是从 Agent 能独立执行任务开始的。
第二阶段：个体效率显著提升，质量开始出现裂缝
在我们团队，真正的分水岭是大家开始熟练使用 Claude Code、Codex 之后。
此时 AI 不再只是代码补全，而是能参与完整的开发任务。
典型工作流变成这样：
- 先让 AI 阅读需求、分析代码库，输出执行计划；
- 人快速审阅，确认方向没问题；
- 让 AI 自己修改代码、补充测试、更新文档；
- 人再做一轮快速 Review；
- 测试通过后，合并代码。
同时，SDD、Superpowers 这类方法论和工具也开始普及。对于复杂任务，先明确目标、边界、涉及模块、验收标准，再交给 AI 执行。
一个显著变化是：个体效率被拉了起来。
过去需要半天一天的任务，现在一两个小时就能推进。过去没人愿意补的测试用例和文档，也开始有人顺手补齐。那段时间团队氛围确实很热，大家都在尝试新工具，也都在刷新自己的产出上限。
但问题也在这里暴露。
最先扛不住的是代码审查环节。
以前一天几个 PR，Reviewer 还能细致审阅。现在每个人都能借助 AI 更快地产出改动，PR 数量和改动范围都急剧增加。很多 PR 结构清晰、代码规范，但真正需要判断的关键点反而更多了：
- 需求理解是否准确；
- 是否破坏了历史兼容性；
- 是否绕过了原有的架构边界；
- 测试是在验证业务规则，还是仅仅在验证当前实现；
- 是否把临时假设写入了长期代码。
我们团队之前就有一些积弊：自动化测试覆盖不足，测试人员配比偏低，很多质量保障靠产品经理多确认几轮、测试多跑主流程、我和几位研发负责人多盯几个关键 PR。
在传统研发速度下，这套办法虽然土，但勉强能撑住。
AI 进来以后，研发产出开始快速喷涌，这套办法就不够用了。测试跟不上，Review 看不细，产品验收也不可能每个边界都重新跑一遍。
质量松动不是那种大面积崩盘，而是更隐蔽的小问题开始增多：
- 一个小功能上线后，发现与老客户场景冲突；
- AI 补了测试，但遗漏了真正的业务边界；
- 某些代码短期能跑，但模块依赖关系变得混乱；
- 文档更完整了，但其中混杂着未经确认的假设。
坦诚说，这个阶段我们并没有主动做太多系统性的质量措施，更多依赖成员自觉性，以及 Superpowers 这类工具自带的 Review 机制。
后来才意识到：对于大型 SaaS 团队，个体效率提升越明显，团队级质量风险越大。
刀变快了，但盾还没更新。
第三阶段：引入 Harness Engineering，质量勉强稳住
第二阶段后，我们开始系统性落地 Harness Engineering。
这里说的 Harness Engineering，不是某个单一工具，而是围绕 AI Agent 构建的一套工程支架：任务规约、上下文供给、工具调用、权限控制、验证反馈和流程编排。
这个阶段，主要做了几件事。
第一，收敛大家的 Skill 和 Agent。
第二阶段大家用得很野。每个人都有自己的 prompt、自己的工具链、自己的小技巧。短期看很热闹，长期看问题很多：同一个需求，不同人喂给 AI 的上下文不一致；同一个模块，不同 Agent 遵循的规则不同；同一个 Review，有人跑，有人不跑。
所以开始提供官方工具集合。能用优秀开源的就用开源，比如 Superpowers 这类；需要结合内部规约的，就由团队自己补充 Skill。
第二，建设公共知识底座。
这一项尤其关键。我们不是一个单仓库小项目，而是上千个 git 仓库，任何一个人的工作空间里信息都不完整。
产品规则、技术规约、模块边界、历史决策、常见陷阱，如果不进入可检索、可引用的知识底座，Agent 只能基于局部代码做判断。局部代码经常能跑，但未必代表系统真正的约束。
第三，强推质量保障 Skill。
比如需求 Review、架构 Review、代码 Review、测试 Review。这些 Skill 会读取团队规约和知识库，先帮人扫一遍明显问题。
它们替代不了人，但能将一些低级且重复的问题提前拦截。
这个阶段，研发效率进一步提升。体感是，在一些边界清晰、上下文完整的任务上，个体效率大约有 3 到 5 倍提升。
更重要的是，大家的行为开始收敛，不再那么随意。
质量算是勉强稳住了。
但必须强调是“勉强”。
因为人仍然是流程主导。什么时候跑哪个 Skill，哪个节点需要补 Review，哪些风险需要升级，很多时候还是靠人记住、靠人加班、靠几个负责人紧盯。
换句话说，Harness Engineering 把质量往前推了一步，但还没有将质量真正固化进流程。
这个阶段的重点措施可以概括为一句话：
建设知识底座，收敛工具花活，官方团队接管并加固质量 Skill。
第四阶段：现在，重心从 AI 提效转向流程重构
现在进入了一个新阶段。
前面几步，重心其实还是 AI 提效。让大家学会工具、学会写 SDD、学会用 Agent、学会用 Harness。
但说实话，一个研发同学只要思维转变过来，掌握这些技能并不需要太久。
真正棘手的是后面的问题：当大家都会用 AI 以后，我们如何保证产出质量？
所以现在的重心，开始从“AI 赋能个体”转向“流程与质量体系的重构”。
这个阶段的核心，不是再多教几个工具技巧，而是改造研发流程本身。
现在正在尝试几件事。
第一，用固定流程保障质量，而不是依赖人。
比如需求不再是产品经理写完就丢给研发，而是要经过信息提取、产品规划、需求输出、需求自动评审、人工确认等多个节点。
架构设计也一样，不是技术负责人觉得差不多就开干，而是要生成影响面分析、模块依赖关系、数据模型变化、回滚方案，再进入 Review。
第二，Agent 主导部分核心流程执行。
过去是人想起来了，去跑一个 Review Skill。现在要反过来，流程推进到某个节点，自动触发对应 Agent。
需求进入研发前，自动触发需求 Review。
架构方案生成后，自动触发架构 Review。
代码完成后，自动触发代码 Review、测试 Review、代码规约检查。
第三，关键节点强控。
这一点非常坚持。质量不能只靠建议，必须有强制管控。
比如涉及权限、数据迁移、核心链路、G 端客户、AI 生成内容的变更，必须经过对应 Agent 审查和人工确认，否则不能继续推进。
第四，全流程记录与审计。
这和前面用 git 做知识仓、做 trace 的思路一致。需要知道每个环节是否执行，输出是什么，人参与了什么，AI 做了什么，最终为什么通过。
这个阶段其实已经在改变研发工作的本质。
一个越来越强烈的感觉是：人的角色变了。
过去人是流程执行者：人拆任务、人跑工具、人做检查、人推进下一步。
现在人更像目标制定者、关键判断者和责任承担者。很多流程动作应由 Agent 自动发起，由系统记录，由质量节点卡住。
这也是我们开始试点调整研发团队组成和协作模式的原因。
这个阶段还在试行中，不敢说已经跑顺。
但方向很明确：
流程重构，角色重新定位，关键质量节点由 Agent 强控。
第五阶段：下一步，补齐大型 SaaS 的质量兜底
再往下一步，必须补齐 SaaS 的质量兜底体系。
我猜会有人问：为什么不是一开始就补？
硬要说的话，只能说以前有太多客户诉求、太多历史包袱、太多“先上线再说”。现在 AI 把效率拉起来，质量问题被放大，这个债必须还。
必须做这个事情，其他团队未必需要。
如果是小团队、小产品，基本 Harness Engineering 加上少量核心链路测试可能就够了。关键模块单独处理，比如支付、权限、计费。
但我们不一样。
产品是大型 SaaS，现在产品本身也在向 AI 转型。未来客户使用的不只是传统功能，还会使用更多 AI 能力。同时，客户群体中包含很多 G 端客户，对稳定性、安全性、权限、审计、数据隔离、可追溯性的要求更高。
质量是生死线，这句话越来越有切身体感。
出一次事故，对外可能丢客户，对内一大票人要被处罚、降级，甚至离开。打工人不容易，质量红线真的不能靠运气。
这个阶段要补的东西很多，比如：
- 核心业务契约测试；
- 关键链路 E2E 回归测试；
- AI 功能自己的评测集；
- 高风险变更发布门禁；
- 灰度和回滚机制；
- 可观测性与审计能力；
- 更贴近真实客户场景的测试数据和沙箱环境。
这些东西看起来没有“再接一个新 Agent”那么有吸引力，但它们才是真正的盾牌。
没有这些兜底，AI 研发效率越高，风险扩散越快。
总结成几句话
如果是中小团队，建议先优先推进核心功能验证，但至少要有基础的 Harness Engineering 和关键模块兜底。别还没验证价值，就先给自己套上复杂流程。
但我们这种大型研发团队不一样。
效率不会成为最大问题，质量才会是瓶颈。不解决质量，效率再高也等于零，甚至会让问题更快进入产品。
一个越来越清晰的判断是：AI 研发的后半程，不是继续比谁更会用工具，而是重构流程、重新定义角色、补齐质量兜底。
刀已经够快了。
盾也要跟上。
下一篇聊聊，我们是如何结合 CLAUDE.md、AGENTS.md 以及我们的 dir-graph 来用好知识库，并减少需求、架构、代码等偏差的。
