一周啥代码都没写 这家技术公司用一整周试出了AI代理的真问题

这种场景挺少见的。Thoughtworks（注，一家全球性的技术咨询公司）欧洲区的首席技术官Giles Alexander把高级工程师、基础设施顾问和产品的人凑到一起，搞了一整周，规矩只有一条，谁都不许写代码，所有东西都交给AI代理去建。一周下来一个航空相关的应用做到了八成。这件事的重点不是那八成，重点是这一周里人们到底在干什么。有人后来写了一段复盘，Rachel Laycock（注，这家公司的首席技术官）把它转述了出来。

复盘里最意外的一句是，大家花了很多时间在白板前。不是在写代码，是在那儿理业务领域、画边界、决定下一步该发生什么，然后写出代理能执行的计划。与此同时，代理在机器上持续产出代码，产出量超过了团队的工作时长。人做的另一半是围绕这份产出设计反馈机制，测试、契约、架构检查、交付流水线，一样一样搭起来。这一周真正的工作内容是定义边界和设计校验，而不是写实现。

Laycock自己给出了资深开发者谨慎的那层原因，她说这来自知道构建出来和在生产环境跑起来不是一回事。Thoughtworks这家公司一向在意把东西做对，在持续集成、结对编程、自动化测试、持续交付、微服务这些实践上他们算是最早的一批玩家，也深知这些实践的价值在于让人对线上运行的软件有把握。早期的编码代理让写出代码变得非常容易，包括那些根本不该进生产线的代码，而且这些代码出自没有经历过构建与生产之间那道鸿沟的人。工具这些年进步很大，但有经验的开发者心里那串问题还在，行为对不对，边界划得对不对，将来能不能演进，团队里其他人接手了能不能一起维护。

她把这个问题说得更直接，几乎所有还在生产环境运行的系统都是老办法手工做出来的，由值得信任的人来做。现在做出来的东西全是新办法，而大家还没有跟新办法长期共处过。她在技术圈干了25年多，越来越看重人通过经验积累出来的那种判断力，她经常拿同样的问题去问模型和公司里的资深技术同事，碰到难的问题，从人那里拿到的答案依然更有用，有人能挑战前提，能认出十年前某个失败项目留下的模式，也能看出藏在技术问题里的组织问题。信息量确实爆炸了，但她还是需要有人帮她想清楚什么才重要，需要那种洞察力。

这套说法对国内做AI应用的团队未必好使。Thoughtworks是咨询公司，交付的是方法和代码，客户愿意为确定性付钱。国内做产品的团队面对的是留存和收入，AI代理多写的那部分代码能不能省下真金白银，通常要过一两个月才知道。但有一个判断可以照搬，就是先想清楚要验证什么，再决定让代理做多少。航空应用一周做到八成这个数字，放在一个三个月要上线的产品里，八成是不合格的，所以这类实验的价值在于把边界和校验先做出来，而不是把产出量做出来。另外那句资深开发者的谨慎也不是保守，是25年积累下来的判断力在起作用，因为生产事故的账总是由团队自己付。做AI应用的团队如果只招会写提示词的人，团队会缺一样东西，那就是能在旧系统和新代码之间认出模式的那种经验。这件事没办法用工具补齐，只能靠让做决策的人参与进来。

创业找资源，上乌鸦部落。