AI Coding领域的真问题

七月份，我写过一篇文章《AI Coding领域的伪问题和真问题》。五个月实践过来，我重读旧文，发现我的认知已经提升一个层次了。

我现在认为ai coding的核心问题是
1.怎么确保ai coding出来的东西是你想要的？
2.怎么确保ai coding交付物的质量是可信赖的？
3.怎么构建一个超音速人/LLM混合团队？

怎么确保ai coding交付物的质量是可信赖的？

我们先从第二个问题开始。我的朋友胥克谦指出:

这个观点是实践中买单买出来的。我的读者朋友们，如果你碰到有人吹嘘ai agent连续工作48小时之类的，直接把他当水变油的骗子就好了，都不用继续分析了。

有的人说，context engineering把所有的上下文都喂给llm，就能解决这个问题。实践证明，context太长，llm的输出质量其实是下降的，相当于你领导唠叨太多会降低你的生产力。 而精选 context，最佳的办法就是人类直接prompt。

有的人会说:我用多智能体检查验证，不就相当于human in the loop了吗？不就解决了这个问题？实践证明，交叉验证有一定的提升，但是由于未知的原因，LLM的常识和人类的常识就是不同，多个LLM坐在一起，仍然会犯同样的低级错误。

幸运的是，交付物质量不靠谱，并非llm的特有问题，人类一样不靠谱。软件工程已经有比较好的应对方案。我现在用到了的方法有如下技巧: 

1.拆分任务，避免给ai一个不可验收的大任务

2.platform engineering，人类主导框架，让ai 聚焦繁琐的业务逻辑

3.高密度测试，针对一个微服务，开发了五个层次的测试，单元测试，组件测试，API测试，集成测试，和E2E测试

4.和devops结合，开发完就部署，灰度发布

5.迭代开发，没想清楚的就不做，想清楚了就不畏惧重写。

6.建立observability和runbook，避免ai瞎猜故障原因。

可以看出，这些技巧并没有任何新东西，但是以前在人类团队中要推行这一套，成本巨大，耗时冗长，在工程上几乎不可能，ai让这一切成为可能了。

但是如胥克谦所言

我的这一套效果也是有限的，还在继续探索中。

怎么构建一个超音速人/LLM混合团队？

这是一个价值被低估的问题。我看到大量的大厂研发效能部在推动这个工具那个流程，但是他们都以工具覆率为指标，追求98%的工具采用率。这就引出了一个悖论: 如果你的工具如此有效，让一个人可以干五个人的活，为什么你需要每个人都用你的工具？如果你公司业务没有突然增长，工作量却增长了五倍，这难道不是个坏消息吗？

还有一个更奇葩的指标是代码采用率。这个指标的荒谬性和以前外包公司用来考核员工产出的LoC是一致的。现在即使最落后的外包公司也不用LoC指标了，而一些ai coding团队却捡起了这块裹脚布戴在头上说是巴黎世家新潮流。

从实践看，人-人沟通的成本远远大于人-AI沟通成本，并且失真度更高。一个比较实际的方案是放弃全员推广AI Coding工具，而是聚焦于打造几个AI-人类混合团队，把他们当特种部队使用。

我和我的朋友王津银提出了一个小笼包理论:你的团队聚餐食量不应该超一份小笼包。直白的说，就是三个人。我现在的团队结构就是一个lead engineer，一个test engineer，然后根据不同的项目，和不同的product owner协作。目前进展非常快，损耗非常低，反响出人意料的好。

怎么确保ai coding出来的东西是你想要的？

这是一个非常难，也最有价值的问题。且待下回讨论。