QECon参感-Vibe Coding-企业雇佣知识工作者，而面临知识缺失的窘境

9月初的QECon上海站听了茹老师和熊老师的两场闭门研讨会。根据当时的笔记做一个简单的总结

vibe coding 三大男，

1) 私域知识难 - 真实项目中大量私域知识LLM没有掌握

2）维护开发难- 编码任务以维护既有业务系统为主；

3) 文档缺失难- 通常团队只有需求文档，没有spec/详设 ？

在茹老师的会场，有位来自某基金销售公司的同学提供的AI4SE场景获得了茹老师的肯定。这位同学所在的 20个人团队在试点LLM应用于软件开发（全部开发人员约100个人）。他们先做好详细设计，然后让LLM生成代码，人工再进行确认，如果发现生成代码有问题，往是详设有问题，会回头去修订详设后再次生成。分享者在被问道提效效果时，说大致提升了10-20%。

与会者认为这是一个真实落地的可信数据。

正如茹老师所点评的那样，老板们所预期的是10X程序员的故事，但是现实是到了到了年终一盘算，就提升了个10-20%。这种效果，如果算上基础设施、token花销等等，“老板其实是亏的”。但是这就是AI4SE目前在严肃编程场景中的现实。无论在哪些实验性的、一次性的、新手村的公域场景中vibe coding表现得多么有令人惊讶，到了强调领域知识、私域背景的企业级应用场景中，由于目前LLM对于这些知识的短缺，令其在从需求往技术实现这个环节的表现非常受限。

根据会场上大家的分享、讨论，笔者总结了一下目前vibe coding在企业中应用有以下的几个困难和挑战：

1)(LLM训练)私域知识难 - 真实项目中大量私域知识LLM没有被训练过。这是LLM层面的问题。即使是在一些垂直领域，通过原先的行业开源项目、行业协议、规范等已经学习到了行业的通用知识，但是还是有更多的企业特定的知识是LLM没有被训练过的。 这种缺失，就需要企业通过知识工程/知识库建设来弥补。

但是马上会遇到下面的问题。

2) （知识库）文档缺失难- 通常团队只有需求文档，没有spec/详设。 敏捷推行这么多年，又有多少团队做好了活文档，实现了Spec by Example/BDD/ATDD等细粒度的需求拆分和设计。最近经常听到的一个说法是，反而之前走瀑布模式，被质控逼着写详设的团队，因为手里有着需求-细粒度拆分-设计-代码的完整数据链，反而成了LLM时代首先吃到红利的团队。在会场甚至有人怀念起了对日外包。

3）（上下文要求高）维护开发难- 编码任务以维护既有业务系统为主；现在的vibe coding 场景很多是以公域场景的新建类任务为主，而在企业内部则以维护式开发为主。按照《知音》上的故事来说，码农的100块工资里，有99块钱是关于“知道在哪里改”的。知道了之后改代码这个工作本身其实是最简单的。这种大跨度的上下文理解，和vibe coding 这种看一眼需求就呼啦呼啦往外冒代码其实不是一回事。

笔者把这些问题抛出来后，群里也有老师说，这些其实是一个问题，那就是“知识的缺失”。

笔者还是十几岁的懵懂少年的时候，老师问大家未来的理想，很多希望成为“这个家”，“那个家”，而笔者写的是“知识工作者”。以这个身份工作了这么多年，慕然回首，却发现企业雇佣了那么多知识工作者，却面临着知识极度缺乏的窘境。想想也是蛮有意思的。