AI 写代码越来越快，小团队真正要守住什么？

本文目录

AI 能写功能、补测试、处理审查意见之后，很多企业会算一笔账：原来需要十个人的项目，现在几个人够用？

但项目里还有另一笔账。功能做得越快，待确认的需求、待审查的改动和待上线的版本也越多。如果这些工作没人接住，省下的编码时间，就会消耗在返工和排错上。

因此，看一个小团队有没有因为 AI 变得更强，除了看实现速度，还要看团队能否判断哪些需求值得做、哪些规则不能绕过，以及出了问题能不能处理。

七个人、五个月，值得看的是他们怎样做判断

Anthropic 在 10 月 13 日发布、15 日更新的工程复盘中介绍，七人团队用五个月建设了 Scion 源码管理系统、Antique 代码审查工具及若干相关系统，并完成迁移。文中还写到，工程师的一项重要工作，是纠正 AI 不合适的实现路径，避免系统变得过于复杂。

这个案例很容易被读成一条人效新闻。不过，这是 Anthropic 对自家项目的复盘，模型资源、基础设施和工程积累都有特殊性，七个人的成果不能直接换算成其他公司的人员配置。

更值得讨论的是，当编码能力增强后，工程师的判断具体落在哪里。下面借一个假设的询盘整理项目来展开。

这家企业的初始需求很简单：从客户来信中提取产品、数量和期望交期，交给销售确认，再录入 CRM。

原型很快做出来了。讨论过程中，又有人提出自动报价、客户评级和营销跟进。这些功能都能找到用途，但加在一起，项目已经从整理信息，变成了替企业做商业判断。

能生成报价单，不代表产品价格、折扣权限和合同条件已经理清。原本负责核对信息的销售，也未必有权确认系统给出的全部承诺。

这时，需要有人把变化说清楚：第一版究竟做到哪里，新功能还缺哪些条件，谁来确认。实现成本下降了，增加功能仍然会带来新的业务责任和维护工作。

参与实现的工程师越了解业务，就越容易识别这种变化。这也是 FDE 直接参与需求讨论的意义。把工作交给小团队，沟通链条可以缩短；需求取舍仍要认真做。

询盘整理继续往下做，接入 CRM 时又可能遇到一个选择：调用既有业务接口比较麻烦，直接写数据库更快。

如果业务接口原本负责检查客户归属、重复记录和审批状态，直接写入就可能绕过这些检查。页面看起来能用，数据也进去了，问题却留在系统里。

类似约束最好落实在程序中，而不是只写进给 AI 的提示里。例如，读取数据时按用户权限过滤；创建任务时识别重复提交；修改关键状态前校验条件；写入后保留操作记录。工程师审查实现时，也需要沿着这些约束检查。

当然，各类改动不必花同样的力气。改一处文案，与修改价格计算、客户权限，错误后果不同。

把精力放在后果严重的地方，并不等于其余代码可以不看。关键是清楚自己在检查什么。审查工具提出的建议也一样：如果一项改动只增加了层层校验，却说不出防的是什么问题，就值得停下来重新判断。

开发结束，AI 报告“测试全部通过”。对于询盘整理，这句话能说明多少问题，取决于测了什么。

只检查产品、数量、日期三个字段是否存在，很容易通过。真正需要拿来试的，是数量没写、正文与附件冲突、客户简称对应多家公司，以及同一封邮件被重复提交的情况。

这些预期结果要由熟悉业务的人确认，再拿来检验程序。AI 当然可以帮助编写测试；需要避免的是，实现和测试都沿用了同一个未经核实的假设。例如，程序把缺失数量默认成一，测试也期待得到一，测试通过了，业务仍然是错的。

所以，一组依据真实规则整理的历史样例，往往比一份漂亮的完成报告更有用。销售确认前，记录是否仍处于待确认状态；写入失败后重试，会不会多建一条；这些都可以逐项验证。关于质量、时效和人工介入的具体口径，见 AI 工作流上线前要验收什么。

开发速度快了，发布也容易变得密集。如果一次同时改了提取规则、客户匹配和 CRM 写入，出错时就很难判断是哪处变化造成的。每次发布的范围清楚一些，验证和排错都会容易一些。

以询盘流程为例，发布前可以记录这次改了哪些规则、用哪些样例验证、由谁确认。上线后再观察销售修正了什么，重复记录有没有增加。异常达到约定条件时，由明确的负责人暂停自动写入或恢复上一版本。

恢复也不总是重新部署旧代码那么简单。已经误写进 CRM 的记录，可能需要单独核对和修正。这部分工作要事先有人负责。更详细的方法可以看 AI 工作流怎样安全发布更新。

这些安排可以很轻：一份版本说明、一组回归样例、一个能处理问题的负责人。小团队不必照搬大公司的流程，但不能让发布后的责任空着。

如果你的企业正在选择交付团队，可以请对方讲一次具体的版本变化：为什么改，用什么确认效果，上线后发现过什么问题，又是怎样处理的。回答里有没有清楚的业务判断和验证过程，比“用了多少 AI、写了多少代码”更能说明交付水平。

专题：组织与价值#AI 交付#FDE#企业 AI#工作流实施