底是好事还是坏事。我觉得这是一个值得每个管理者思考的新问。
反思二：功能正确≠工程可用
Vibe Coding 的理想状态是就像聊天一样，用自然语言表达自己的需求，最后做出来想要的产品。
如果哪里不对，再用自然语言和 AI 沟通，让它修改。这是过去一年 Vibe Coding 风靡的思路。
对于不太复杂的应用，这种方式完全没问。我自己做的一些项目基本上就是这个流程跑下来的。
但只要是做生产级的软件，无论公司大小，流程肯定不是这样。
因为公司里必然有老代码，有一套约束。怎么复用已有的组件，安全和权限怎么处理，性能怎么保证，还有兼容性、可维护性。
正经写过工程代码的人都清楚，Vibe Coding 描述的那个状态是比较理想化的，更适合做小项目和验证想法。
真正的程序员虽然也在 Vibe Coding，但流程跟理想状态不一样。
字节内部做了一个实验来验证这个判断：三个模型，三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。
结果发现，AI 在功能正确率上表现还不错，所有组合都超过了 80%，也就是说，AI 把功能写对的能力已经过了及格线。
但无论哪个组合，生成代码的工程质量都不太好。比如 UI 不对，没有复用组件，性能有问，结构不符合规范。
这些问大家在用 AI 写代码的时候应该都碰到过。
现在所有上了牌桌的 Coding 模型，都已经过了 Opus 4.6 这个级别的临界点，模型可以自主写代码了。
这个时候影响 AI Coding 成败的绝对不是裸模型，而是裸模型加上 Harness 的能力。
这个判断本身不算新鲜。
但我最受触动的是字节对 Harness 的理解。
他们的反思是，整个行业好像还是把 Harness 等同于 Agent 框架，诸如用 single agent 还是 multi agent，包含哪些角色，角色之间怎么配合。
这些当然重要，但字节在实践中发现，真正决定 AI Coding 能不能落地的，反而是更基础、更工程化的东西。
洪定坤把它叫做基建。
比如上下文工程有没有做好，架构的约束够不够清晰，团队的知识能不能有效沉淀下来，过去的技术债有没有梳理清楚。
这些看起来不那么性感的工作，反而直接影响 AI Coding 的效果。
实验数据也验证了这一点。同样的模型和框架组合，把这些基建结合进去之后，功能正确率直接从 80% 提升到了接近 90%，工程质量得分，也从之前 40 到 60 分的不及格水平，普遍提升到了 80 分左右。
基建做不好的，可能的后果是，Vibe Coding 感觉快了，但实际整体可能更慢。工程的债，迟早得还。
反思三：代码门槛下降之后，团队怎么协同
洪定坤分享里有一个例子让我印象很深刻。
产品经理有个需求，发现还得等研发排期，就说那我自己来吧，用 AI 三下五除二就把功能给实现了。
确实这个功能不复杂。做完之后产品经理把代码给到研发，说我已经把代码写完了，现在你只需要帮忙把功能上线就行。
研发一看，不行。你这代码能跑，但不符合上线的规范，有权限问、安全问。
产品经理就很委屈，你们没时间做这个需求，现在我都做完了又不让上线。可研发看到的其实是代码质量的问。
所以这里面就有一个需要所有人正视的事情，虽然代码的生成门槛虽然下降了，这并不代表系统的复杂度也下降了。
真实的业务系统里，代码要放到已有的架构里，要跟已有的模块配合，还要考虑各种各样的问。
绝对不是谁写出来就能直接上线的。不然肯定会出问。
怎么让不同角色的人用同一套工具和规范做出符合要求的代码，这是接下来大家需要去解决的。
字节的思路是在内部尝试工具化。比如把内部实践直接产品化，沉淀到 TRAE 里面，开放给所有人。
其实说白了就是工具化。
我看朋友圈有好多大佬也都在转这篇文章，应该还是有挺多共鸣的。
我感觉这一次分享多少也是一些拨乱反正吧。因为过去一段时间确实有很多听起来很离谱的言论，有些人会疯狂地炫耀自己使用了多少 Token，会认为这就代表着 AI Native......
强烈推荐大家看看原文。字节跳动的公众号就有。
@aigc1024
反思二：功能正确≠工程可用
Vibe Coding 的理想状态是就像聊天一样，用自然语言表达自己的需求，最后做出来想要的产品。
如果哪里不对，再用自然语言和 AI 沟通，让它修改。这是过去一年 Vibe Coding 风靡的思路。
对于不太复杂的应用，这种方式完全没问。我自己做的一些项目基本上就是这个流程跑下来的。
但只要是做生产级的软件，无论公司大小，流程肯定不是这样。
因为公司里必然有老代码，有一套约束。怎么复用已有的组件，安全和权限怎么处理，性能怎么保证，还有兼容性、可维护性。
正经写过工程代码的人都清楚，Vibe Coding 描述的那个状态是比较理想化的，更适合做小项目和验证想法。
真正的程序员虽然也在 Vibe Coding，但流程跟理想状态不一样。
字节内部做了一个实验来验证这个判断：三个模型，三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。
结果发现，AI 在功能正确率上表现还不错，所有组合都超过了 80%，也就是说，AI 把功能写对的能力已经过了及格线。
但无论哪个组合，生成代码的工程质量都不太好。比如 UI 不对，没有复用组件，性能有问，结构不符合规范。
这些问大家在用 AI 写代码的时候应该都碰到过。
现在所有上了牌桌的 Coding 模型，都已经过了 Opus 4.6 这个级别的临界点，模型可以自主写代码了。
这个时候影响 AI Coding 成败的绝对不是裸模型，而是裸模型加上 Harness 的能力。
这个判断本身不算新鲜。
但我最受触动的是字节对 Harness 的理解。
他们的反思是，整个行业好像还是把 Harness 等同于 Agent 框架，诸如用 single agent 还是 multi agent，包含哪些角色，角色之间怎么配合。
这些当然重要，但字节在实践中发现，真正决定 AI Coding 能不能落地的，反而是更基础、更工程化的东西。
洪定坤把它叫做基建。
比如上下文工程有没有做好，架构的约束够不够清晰，团队的知识能不能有效沉淀下来，过去的技术债有没有梳理清楚。
这些看起来不那么性感的工作，反而直接影响 AI Coding 的效果。
实验数据也验证了这一点。同样的模型和框架组合，把这些基建结合进去之后，功能正确率直接从 80% 提升到了接近 90%，工程质量得分，也从之前 40 到 60 分的不及格水平，普遍提升到了 80 分左右。
基建做不好的，可能的后果是，Vibe Coding 感觉快了，但实际整体可能更慢。工程的债，迟早得还。
反思三：代码门槛下降之后，团队怎么协同
洪定坤分享里有一个例子让我印象很深刻。
产品经理有个需求，发现还得等研发排期，就说那我自己来吧，用 AI 三下五除二就把功能给实现了。
确实这个功能不复杂。做完之后产品经理把代码给到研发，说我已经把代码写完了，现在你只需要帮忙把功能上线就行。
研发一看，不行。你这代码能跑，但不符合上线的规范，有权限问、安全问。
产品经理就很委屈，你们没时间做这个需求，现在我都做完了又不让上线。可研发看到的其实是代码质量的问。
所以这里面就有一个需要所有人正视的事情，虽然代码的生成门槛虽然下降了，这并不代表系统的复杂度也下降了。
真实的业务系统里，代码要放到已有的架构里，要跟已有的模块配合，还要考虑各种各样的问。
绝对不是谁写出来就能直接上线的。不然肯定会出问。
怎么让不同角色的人用同一套工具和规范做出符合要求的代码，这是接下来大家需要去解决的。
字节的思路是在内部尝试工具化。比如把内部实践直接产品化，沉淀到 TRAE 里面，开放给所有人。
其实说白了就是工具化。
我看朋友圈有好多大佬也都在转这篇文章，应该还是有挺多共鸣的。
我感觉这一次分享多少也是一些拨乱反正吧。因为过去一段时间确实有很多听起来很离谱的言论，有些人会疯狂地炫耀自己使用了多少 Token，会认为这就代表着 AI Native......
强烈推荐大家看看原文。字节跳动的公众号就有。
@aigc1024
