AI提效20讲⑧：强约束条件下如何确保基于AI的敏捷开发质量？

作者：AI提效项目组组长 蒋云峰 校审：林德燊 排版：习丌

米多公司是一家产业互联网平台公司，从技术角度看，分为“平台、系统、应用、插件”四级结构，平台级软件强调“多边协同”、系统级软件注重“稳态管理”、应用级软件提倡“敏态响应”、插件级软件要求“被集成”。

系统级软件因为“源”于“平台”、“终”于“应用”，在具象的技术开发项目中，通常涉及跨部门、跨系统、跨应用等不同维度的协同，项目质量管理至关重要。

在基于AI提效的技术开发过程中，当我们把交付与质量放到“项目层面”去统筹考量时，最先撞到的不是“方法够不够先进”，而是一个很尴尬的现实：很多时候，我们并没有可以直接伸手去改的地方。

如何让 AI 帮我们把项目交付与质量方面模糊的问题拆成可验证的动作，让风险提前显形，把本该由“更强的人”完成的那部分分析与产出，以更低成本拉到团队里来，是我们必须要解决的问题。

一个必须先承认的现实

不是每个软件开发工程师都是一个“项目管理高手”，我们必须先承认三个现实前提：

1、绝大多数软件开发工程师都没有完整构建过一套公司级、长期运转的质量管控体系
至少不是那种从 0 到 1、再稳定运行数年的成熟体系。

2、AI工具在研发领域已经非常强大
它懂项目管理、懂质量体系、懂 CMMI、懂敏捷、懂 DevOps、懂行业最佳实践，它甚至"理论上"比大多数人都更全面。

3、如果我不会"指挥"它，它给我的只会是正确但无用的答案
这三句话看起来每一句都对，但一句都落实不到具象的“项目管理”内。因为在实际协作里，对 AI 提效的失望经常不是“AI 不行”，而是——我们在用“提问式聊天”的输入方式，却期待它输出“可以直接当作项目决策依据”的结果。

真正的核心不是 AI 强不强，而是你给了它什么现实

在项目质量这件事上，我们必须清醒的认识到（先限定适用范围：当你希望 AI 的输出能直接影响下一步的项目动作）：

AI 不会自动补齐“现实约束”，
你必须把约束拆开、写清楚、给到它。

换句话说（这是倾向性规律，不是绝对结论）：

• AI 默认工作在"理想世界"

• 而项目质量，永远发生在"不理想的现实里"

如果你对 AI 说的是：

"请帮我设计一套项目质量管理体系"

它大概率会给你一套教科书级正确的东西：
阶段划分、评审节点、指标体系、闭环机制……一个不少。

但问题是：
这些东西在类似“5 人、无专职测试、不能加人、要兼容存量系统”的强约束条件下，通常推不全、推不久（即便短期推动了，也容易在业务压力下回退）。

这不是“努力不努力”的问题，而是成本结构与角色结构决定的：

• 人力结构不匹配

• 角色职责并不清晰

• 节奏已经被业务压扁

• 质量成本没人真正愿意买单

AI 不知道这些，除非你告诉它。

我们在米多星球项目上就遇到过这种情况（以下内容都以“米多星球项目”的现实为边界，不外推到所有团队）。

当时我直接问 AI："米多星球项目如何控制质量？"

它给我列了一堆流程：需求评审、技术评审、代码审查、测试覆盖、上线检查……听起来都对。

但我一看就知道，这套东西在我们团队根本推不动。

为什么？

因为米多星球项目团队只有 5 个专职人员（其他人员需要共用相关团队成员）：

• 项目经理 1 人（Java 开发，负责项目交付效率）

• 产品经理 1 人（对接各使用部门，执行产品方案）

• 产品总监 1 人（负责资源调配，不负责具体业务）

• 架构师 1 人（总体架构设计，AI 提效赋能）

• 前端架构师 1 人（前端设计及 AI 组件化验证）

而且我们还有硬性约束：

• 不能增加人手

• 不能换技术栈（必须用 Java + Vue.js）

• 必须兼容现有系统

• AI 协作占比必须在 80% 以上

如果按照 AI 给的"标准流程"，我们需要：

• 需求评审会（需要产品、技术、测试都参加）

• 技术方案评审（需要架构师、前后端都参与）

• 代码审查（需要至少两个人审查）

• 测试覆盖（需要专门的测试人员）

但我们根本没有测试人员，也没有那么多时间开那么多会。

所以，我意识到：
不是 AI 的方案不对，而是它不知道我们的现实。

把 AI 当"参谋长"，而不是"答题机器"

我后来刻意改变了一个认知：

不再把 AI 当成"回答问题的人"，
而是当成一个需要充分理解战前简报的参谋长。

这意味着，我不再问它"怎么做"，而是先做三件事：

1. 把项目的真实约束讲清楚

我开始把米多星球项目的真实情况一条一条地告诉 AI：

团队结构：

• 研发项目经理（Java 开发，负责项目交付效率）

• 产品经理（对接各使用部门，执行产品方案）

• 产品总监（负责资源调配，不负责具体业务）

• 架构师（总体架构设计，AI 提效赋能）

• 前端架构师（前端设计及 AI 组件化验证）

业务背景：

• 米多星球项目是一个米多公司内部使用的B2B管理系统

• 核心功能：SSO 登录、各部门工具整合、财务流程在线化、人力系统打通、客户成功系统整合

• 技术栈：Java（Spring Boot）+ MySQL + Vue.js

• 研发模式：基于插旗法的敏捷开发，AI 协作占比要求 80% 以上

项目规模：

• 开发团队 5 人，涉及对接财务、人力、客成等多个部门

• 项目周期：分三个阶段，总计 4-6 个月

• 目标：把所有分散的小系统集中归母到米多星球，实现一个账号登录所有系统

这些信息，往往比"目标"本身更重要。

2. 明确"哪些东西现在不能要"

这是一个非常反直觉但极其重要的动作。

我会直接告诉 AI：

• 不要给我完整的企业级体系

• 不要假设我能新招人

• 不要引入复杂的审批或工具

• 不要要求全员一次性改变工作习惯

可用资源：

• 人力：5 人团队，不能增加人手

• 时间：每周 5 个工作日，不能加班

• 预算：使用现有工具，不采购新系统

限制条件：

• 必须兼容现有企业微信 SSO 登录

• 必须使用现有技术栈（Java + Vue.js），不能换框架

• 必须对接现有财务、人力、客成系统，不能推倒重来

• AI 协作占比必须达到 80% 以上（这是硬性要求）

本质上是在告诉它：

请在"残酷现实"里设计方案，而不是在 PPT 世界里。

3. 把"质量"拆成可被干预的具体问题

而不是一句空泛的“提高质量”。

我开始梳理米多星球项目真实存在的问题：

1.进度不可控：项目经理经常被临时需求打断，原计划的功能延期

2.质量波动大：有些模块质量很好，有些模块上线就出问题，没有统一标准

3.需求频繁变更：各部门提需求时说不清楚，开发到一半又要改

4.部门沟通不畅：财务部、人力资源部、审计部、客户成功部、业务拓展部、市场赋能部等各自提需求，没有统一入口，经常冲突

5.缺乏透明度：产品总监不知道项目具体进度，产品经理不知道技术实现难度，项目经理不知道需求优先级

问题优先级（按影响交付程度排序）：

1.质量波动大（最影响交付，上线就出问题）

2.进度不可控（第二影响，计划总是被打乱）

3.需求频繁变更（第三影响，导致返工）

只有当问题被拆到"可操作层级"，AI 的价值才会开始显现。

补一条我后面反复验证过的约束：“质量”必须被写成可度量的目标，否则所有动作都无法判断“做了是否有效”。例如（按我们项目可拿到的数据口径）：

• 线上质量：上线后 7 天内 P0/P1 缺陷数；数据不一致事件数（财务/人力/客成对账问题）

• 交付稳定性：计划 vs 实际延期天数、延期率；返工次数/模块

• 需求稳定性：开发过程中需求变更率；变更导致的返工比例

这些指标不要求一次性很完美，但至少要能在团队例会上被复核、被追踪。

再补一个经常被忽略、但决定“后面到底怎么做”的问题：当指标之间互相冲突时，我们优先保什么。

在米多星球这种系统里，我的经验是先把“不可承受的坏结果”定义清楚，再谈动作，否则每个人都会在自己关心的指标上用力：

• 优先级 1：不可回滚/不可补救的风险（例如财务数据一致性、关键权限缺陷）

• 优先级 2：上线后立刻影响大范围用户的 P0/P1（能回滚也要尽量避免）

• 优先级 3：可通过灰度/回滚/补丁快速修复的问题

• 优先级 4：进度偏差与效率损耗（但不以牺牲前 3 类为代价）

这不是“道理”，而是统筹者必须先做的取舍：先把“不能输的地方”写出来，后面的门禁、清单、自动化才有统一方向。

我们正在摸索中的一套"实战做法"

在这样的前提下，我和 AI 之间的协作方式，逐渐变成了下面这种结构：

在进入步骤之前，我先把“统筹者的抓手”写清楚，因为如果抓手不存在，后面再好的方案也只能停留在讨论层面。

我把抓手分成三类（对应“什么时候能拒绝、什么时候能卡住、什么时候能追溯”）：

• 入口抓手（不满足就不排期）：需求输入最小完备（字段、流程、异常分支、权限、对账口径、对接人确认）；对接系统最小信息（接口清单、鉴权方式、错误码、限流、数据口径）。

• 过程抓手（不过就不合并/不上线）：流水线门禁（基础编译/静态检查/最小冒烟用例/变更影响说明）；关键接口契约（请求/响应示例、幂等与重试策略）。

• 出口抓手（无记录就不发布）：上线核对清单、灰度/回滚方案、关键链路可观测（日志/指标/告警），以及可审计的发布记录。

在 AI 的使用上，我也刻意把输出分成两类，避免“写了很多字但没有抓手”：

• 参谋输出（降低认知成本）：风险清单、检查清单、备选路径、对标资料、决策模板。

• 武器输出（降低执行成本）：用例、脚手架、流水线门禁、对账脚本、告警规则、上线核对表单。

后面所有步骤，必须至少落到一类“武器输出”，否则只能算建议，不算治理。

第一步：我给它现实，它给我"可选路径"

我开始把米多星球项目的历史数据也整理出来，喂给 AI：

历史项目数据（基于总后台前几个模块的统计）：

• 计划 vs 实际交付：平均延期 3-5 天，延期率 40%

• 缺陷分布：前端问题占 30%，后端接口问题占 40%，数据问题占 20%，其他 10%

• 返工次数：平均每个功能模块返工 1.5 次

• 需求变更：开发过程中需求变更率 60%

成功案例（按时高质量完成的模块）：

• 用户权限管理模块：按时交付，上线后零缺陷

• 成功原因：需求明确（前端架构师提前画出原型），技术方案清晰（架构师提前评审），前后端接口设计完整（项目经理和前端架构师提前对接）

• SSO 登录模块：提前 2 天交付，质量稳定

• 成功原因：需求清晰，技术方案成熟

失败案例（延期或质量问题的模块）：

• 财务流程模块：延期 1 周，上线后出现数据不一致问题

• 失败原因：需求不清晰（财务对接人提供的流程有遗漏），开发过程中需求变更 3 次，测试不充分

• 客成系统整合模块：延期 2 周，上线后功能不完整

• 失败原因：对接的系统接口文档不完整，开发过程中才发现接口不兼容，需要重新设计

根本原因分析：

1.需求阶段信息不完整，导致开发过程中频繁变更

2.技术方案评审不充分，前后端接口设计不完整

3.测试阶段覆盖不全面，上线后才发现问题

4.缺乏统一的质量标准和检查清单

然后，我给 AI 的提示词变成了这样：

这样，AI 给出的方案，就不会是空泛的"教科书答案"，而是针对我们团队实际情况的可落地建议。

第二步：我做"现实筛选"，再反向喂给 AI

AI 给出方案后，我会直接告诉它：

• 这个我们做不到（比如需要专门的测试人员）

• 这个现在不现实（比如需要全员培训新流程）

• 这个团队会强烈反弹（比如需要改变现有工作习惯）

• 这个可以试点，但只能在一个小范围

然后让它在被砍掉一半假设的情况下重新设计。

（新增）第三步：对 AI 产出做“验真筛选”，避免“看起来对”

仅做“现实筛选”还不够。AI 的建议即便满足约束，也可能在以下地方出错：

• 关键事实不成立：对接系统的接口能力、数据口径、权限边界被高估或误判

• 因果链不成立：把“数据不一致”简单归因到“测试不足”，忽略幂等、补偿、对账

• 成本被低估：某条措施看似轻量，实际需要大量跨部门配合才跑得起来

所以我加了一道很小但很关键的门槛：每条建议都要回答“如何验证它有效”，并且有负责人能在一周内给出结论。

在米多星球项目内，这个“验真”通常由以下角色完成：

• （产品经理）：验证需求输入是否完整（字段、流程、异常分支、权限、对账口径）

• （Java 开发）：验证接口/数据链路是否能支持建议（幂等、事务边界、补偿、性能）

• （前端架构师）：验证前端联调与交互路径是否覆盖关键异常（权限、边界态、可观测点）

• （架构师）：验证系统级风险与兼容性（存量系统影响、灰度策略、回滚方案）

这一步的目标不是“证明 AI 对”，而是尽快发现“它哪里不对、哪里不适用”。

第四步：只保留"能在下一个月真实发生的动作"

这是我给自己的硬性约束：

如果一条质量措施，在未来一个月内无法启动、无法被验证（看不到任何可复核的迹象），那它在当前阶段就不该被作为主方案。

AI 非常擅长“长期完美方案”，但项目质量常见的失败方式是：第一步没有人能把动作变成日常例行，或者没有任何可复核的数据反馈，导致一个月后看起来“都做了”，但质量并没有变。

补充一句容易被误解的点：我强调“把现实喂给 AI”“把方案筛到能发生”，不是为了把现实合理化，更不是为了优雅地接受“人手少所以别做验证”。

恰恰相反，AI 在这里应该承担的是“把不可能变得没那么不可能”的那部分工作：用自动化把验证成本打下来，把原本依赖“加人/加班/专职测试”的环节，改造成团队可持续运行的门禁。

在类似米多星球这样的项目里，我更期待 AI 以“产能工具”的形式出现，而不仅仅是“建议输出”：

• 自动化验证：基于接口文档/示例数据生成基础的接口冒烟用例；对关键链路补最小回归集；把“数据一致性”落到可执行的对账脚本与异常告警。

• 工程门禁：把代码检查、依赖安全、基础测试、构建与部署串成流水线；把“上线核对”固化成可复用的 checklist 与可审计记录。

• 代码与脚手架产出：生成重复性代码、测试桩、mock、日志埋点模板，让“写验证”的边际成本不断下降。

如果团队把 AI 协作占比当成一个漂亮指标，但不把它绑定到“可验证产出”（例如测试用例、流水线门禁、对账与告警、上线核对记录），那 AI 带来的只会是更快的交付速度，而不是更稳的质量。

第五步：用周复盘把“策略”变成“学习”

我不把“复盘”当成会议文化，而是当成一个非常具体的止损机制：我们需要一套规则，能在一两周内判断“这条措施是在起作用，还是在消耗大家”。

我目前使用的最小规则是：

• 只看少量信号：每周固定看 3 个数（例如：上线后 7 天 P0/P1、延期率、需求变更率），并和过去 2-4 周的移动平均做对比。

• 先看趋势再看归因：趋势不变，先调整动作；趋势变差，先收缩范围（只保关键链路）；趋势改善，再扩大覆盖面。

• 两周无改善就换方案：连续两周看不到任何改善迹象，就把该措施降级为“可选项”，重新设计更小动作或换成“武器输出”。

• 任何新增动作必须可追踪：新增的门禁/清单/脚本必须能留下记录，否则下周无法判断“到底做没做、做得怎么样”。

质量之上，其实是"指挥能力"的问题

写到这里，我反而更清楚一件事：

这一章真正讨论的，不是“AI 是否聪明”，也不是“质量体系是否先进”，
而是我们有没有能力把“战场信息”整理成可执行、可验证的项目动作。

当你还在一线写代码时，你的主要约束是“自己能不能写出来”；而当你站在项目层面，你需要同时管理的变量至少包括：

• 人（分工与责任边界）

• 输入（需求与对接系统信息的完整性）

• 流程（最小门禁与检查清单）

• 决策节奏（优先级、变更控制、复盘频率）

• 质量成本（哪些风险必须花钱/花时间买单）

• 以及——AI（作为工具与参谋，而不是责任主体）

AI 不会替你承担责任，但它可以成为一个高频的“清单生成器 / 对标资料库 / 风险枚举器 / 方案备选库”，并在你给足约束与验真机制时，参与到决策加速里。

前提是：
你必须先学会把真实战场描述清楚。

适用边界：这套做法什么时候会失效

这套做法并不是“只要照做就一定有效”。在这种场景里，我见过几个很典型的失效条件：

• 入口抓手形同虚设：需求/对接信息不完整也照样排期，后面所有门禁都会被“赶进度”冲掉。

• 对接系统没有承诺：接口文档长期不更新、错误码随意变、数据口径不稳定，这时再多清单也只是记录混乱，必须先把“对接承诺”作为项目风险抬到桌面上。

• 流水线没人维护：门禁变成红灯但没人修，久而久之大家会选择绕过，最后“有门禁等于没有门禁”。

• 只追指标不追产出：把 AI 协作占比当成目标，却不要求产出落到“用例/门禁/对账/告警/核对记录”，结果是交付更快、问题也更快出现。

识别到这些边界时，我的处理方式通常不是“再加流程”，而是回到最开始的元问题：我们到底要先避免哪一种坏结果，然后把抓手集中在那条关键链路上。

结语

所以，“强约束条件下如何确保基于AI的敏捷开发质量”往往不是：

我们有没有先进的方法？我们用没用 AI？

而是：

我们是否真的理解自己项目的约束、风险与关键链路，并且有能力把这些信息整理成：目标（可度量）+ 约束（可复核）+ 动作（可执行）+ 验证（可追踪），再交给“参谋”输出备选方案。

当这一点成立时，AI 才不再是"看起来很对的废话生成器"，而会开始真正参与到——项目质量的现实决策之中。

点击下方关键字，查看原创热文

行业案例：| | | | | | |

业务场景：| | | | | | | | | | |

系统应用：| | | | | |

数智科普：| | | |

米多是国内领先的营销数字化整体解决方案提供商，为企业提供顶层设计（营销数字化蓝图/架构/体系等）、系统规划（一物一码/智能营销/渠道管理）及运营落地（扫码发红包/一元换购/五码合一等）提供服务，用数字化驱动业务增长。