AI 能轻松解需求，却将迭代的坑留给了人

AI 可以接管越来越多研发步骤，但如果流程只奖励“尽快把需求做出来”，它也会更快地把局部最优写进系统。

最近几个月，我在代码 Review 里反复看到一种情况。

我们的历史项目正在做 AI 化改造，新项目也已经大量使用 AI。随着信任增加，AI 不再只是补几行代码，而是开始直接理解需求、设计方案、开发并集成。

功能确实更快上线了。可当我们回头审查完整代码时，却发现不少需求是以补丁方式接进去的：AI 尽可能让当前功能跑通，却很少主动考虑产品能力是否重复、模块边界是否被破坏，以及下一次修改要付出什么代价。

这些局部正确的代码不断累积，最后变成技术债。继续让 AI 在上面开发，项目只会越来越臃肿。

这让我重新思考一个问题：AI 会写代码，甚至能独立交付需求，是否就等于它会做产品？

从一个需求到一个产品，中间还隔着什么？

如果只是做一次性脚本、个人工具或者概念验证，补丁未必是问题。代码完成任务后就结束使命，快速得到结果比长期维护更重要。

但这篇文章讨论的是另一类软件：它有真实用户，承载真实业务数据，需要长期响应需求。

用户提出的通常是一个具体问题，甚至已经带着他设想的解决方案。产品不能机械地把每句话变成功能，而要继续判断：

• 这个问题是否具有持续价值？
• 现有能力能否解决，只是用户没有找到？
• 新需求应该扩展哪个能力，还是建立新的能力？
• 它与其他用户、流程和数据是什么关系？

开发也不只是把方案翻译成代码。它还要保证今天的实现不会封死明天的变化，并在结构开始阻碍业务时进行调整。

所以，AI 降低的是当前需求的实现成本，没有自动消除判断、整合、验证和维护成本。

AI 为什么容易变成“需求外包”？

这不完全是 AI 的问题，而是我们给它的目标造成的。

大多数研发任务只描述“要增加什么”，验收标准也集中在“功能能否运行”。在这样的目标下，AI 选择改动最少、最容易通过当前验收的路径非常合理。

它看到的是一个局部任务，人却要承担整个系统的未来。

如果 AI 不知道产品为什么采用当前流程，不知道某个模块不能反向依赖另一个模块，也不知道一段看似多余的抽象正在保护数据边界，那么复制一套相似逻辑、增加一个条件分支或者绕过原有接口，往往是完成任务的最快办法。

“像外包”只是一个比喻。优秀的外包团队同样可以做出可维护系统，AI 也能参与架构设计和重构。真正的问题是：我们是否只购买了交付结果，却没有把长期目标和质量反馈交给它。

真正缺的不是三个职位，而是三套反馈

过去我们习惯说，一个完整团队需要产品、设计和开发。现在我更愿意把它们理解成三套不能缺席的反馈，而不是三个固定职位。

第一套是用户价值反馈。它负责判断问题是否真实，结果是否有用，而不是把用户提出的方案原样实现。

第二套是产品一致性反馈。它把点状需求放回完整产品，判断应该复用、扩展、合并还是拒绝，避免每个需求都长出自己的入口、概念和流程。

第三套是工程可持续反馈。它检查模块边界、数据所有权、兼容性、测试和回滚，控制每一次变化带来的复杂度。

这三种能力可以由一个人承担，也可以由多个 Agent 辅助。关键不在团队里有多少角色，而在于三种目标是否真正进入研发与验收流程。

同时也要警惕另一个极端。产品能力矩阵不是越完整越好，架构也不是越面向未来越好。为尚未出现的需求提前抽象，同样可能制造昂贵的复杂度。重构应该回应已经出现的结构性阻力，而不是猜测所有未来。

AI 加速的不只是开发，也可能是复杂度

软件工程对这件事早有观察。软件演化研究指出，持续使用的软件必须不断适应环境；如果没有专门投入控制复杂度，其结构会在持续修改中逐渐恶化。

AI 没有创造这条规律，但它显著提高了变化的速度。

一项覆盖近 5000 名技术从业者的软件研发调查发现，AI 使用与交付吞吐量正相关，但仍与交付稳定性负相关。自动化测试、成熟的版本控制和快速反馈，决定了更快的代码产出会变成生产力，还是变成更多不稳定变更。

另一项分析约 30 万次 AI 提交的2026 年预印本研究发现，不同工具均有超过 15% 的提交引入至少一个静态分析问题，约四分之一的问题在后续版本中仍然存在。这项研究依赖静态分析，且尚未完成正式同行评审，不能证明 AI 必然制造技术债，但它至少提醒我们：功能被合并，不代表维护成本已经消失。

AI 更像一个放大器。好的产品与工程系统会被放大，只追求局部交付的流程也会被放大。

怎样让 AI 从“需求外包”变成研发系统？

我的答案不是收回 AI 的权限，而是把约束、独立审查和人的责任一起放进自动化流程。

先建立项目的“演化说明书”

在仓库中维护少量长期文档：产品原则说明目标用户和明确不做的事；能力地图记录现有能力与边界；架构文档约束模块职责、依赖方向和数据所有权；决策记录解释重要方案为何被采用或放弃。

AI 接需求前先读这些文档。它们不需要写成百科全书，只保留会影响未来决策的约束，并随项目变化更新。

复杂需求先交方案，不要立刻交代码

编码前要求 AI 回答：真实问题是什么，应该复用或扩展哪项能力，会影响哪些模块和数据，是否引入新概念，怎样迁移、测试和回滚。

人在这里做第一次 Review。方向错了，代码生成得越快，返工和技术债增长得越快。

用多 Agent 形成制衡

复杂需求可以让不同 Agent 分别负责需求分析、产品能力判断、架构影响、开发和测试。最后再用一个没有参与实现的 Review Agent，对照原始需求、架构约束和完整代码差异独立审查。

重点不是 Agent 数量，而是不要让同一个 Agent 既实现方案，又为自己的方案做最终背书。低风险修改无需启动完整流程，跨模块、改数据或影响公共接口时再升级审查。

建立“架构师 Rule + Review Skill”

Rule 保存长期硬约束，例如模块依赖方向、数据归属、禁止绕过的公共接口、新增能力前必须搜索已有实现，以及数据模型变更必须附带迁移和回滚方案。

Skill 则定义每次审查的流程：读取产品与架构文档，检查完整变更集，搜索重复能力，分析模块边界、依赖方向、新状态和新接口，最后按严重程度输出阻断问题、改进建议和待偿还技术债。

逐次 Commit 可以做轻量检查，但合并前必须再看完整变更集。很多架构问题并不存在于某一行代码，而是出现在多个正确修改组合之后。

在自动化 Pipeline 中插入人工闸门

一套更稳妥的流程是：

需求分析 → 方案生成 → 人审方案 → AI 实现 → 自动测试与架构检查 → 独立 Agent Review → 高风险变更人审 → 发布

修改核心数据、权限、跨模块依赖、公共接口和不可逆操作时，必须由人确认。低风险、测试充分且容易回滚的变更，才适合自动集成。

AI 的权限不应统一放开，而应由失败成本和可验证性决定。

定时检查系统有没有偏航

局部 Review 看不到系统正在缓慢变形。可以每周或每两周让架构 Agent 检查重复能力、循环依赖、相似字段、不断扩大的条件分支、长期未删除的临时代码，以及修改频率超过测试能力的模块。

巡检结果必须进入技术债清单，写明风险、影响范围、处理时机和验收标准。核心模型变化、同一模块连续被修改或线上事故发生时，还应立即触发额外审查。

当同一规则第三次重复、一个需求必须修改多个不相关模块，或者测试准备时间已经超过功能实现时间，就该考虑重构。这样，重构回应的是已经出现的演化方向，而不是对未来的想象。

AI 可以接管执行，但不能凭空获得所有权

过去我认为，当 AI 掌握代码能力，每个人都会拥有自己的“私人程序员”。现在我仍然相信它会让更多人创造出自己的工具，但我要给这个判断补上一个边界：

造出一个能用的工具，和维护一个持续演化的产品，不是同一件事。

AI 可以参与需求分析、产品设计、架构决策、编码、测试和 Review，甚至承担其中大部分执行工作。但产品最终要长成什么，哪些代价可以接受，什么时候应该停下来偿还复杂度，仍然需要明确的责任主体。

当写代码越来越廉价，真正稀缺的就不再是实现，而是知道产品应该怎样生长，并愿意为它的长期演化负责。