--- area: "tech-engineering" author: JUGG’s Agile category: technology channel: null companies_orgs: [] date: 2025-08-04 draft: true file_name: Vibe_Coding_Implementation_Challenges_Team_Culture.md guest: '' insight: 好奇怪，这期竟然推荐给我，我也同样的感受。我提交一个AI 生成的代码（自己先review），但是同事看到500-600代码，都审核的很慢，5天还没有完成，我代码才写1天，AI倾向于大改。AI也倾向于重新造轮子，我们的codebase也有很多现存的方法，它不用。这点，我可能要用一些context来提示，我要多研究一下，MCP。 layout: post.njk people: - Derek products_models: [] project: [] series: Vibe Coding source: https://www.youtube.com/watch?v=eZWVzTd3mkU&t speaker: '' summary: 本期 JUGG 聊敏捷邀请了开发一线的 Derek 和 Zen，深入探讨 Vibe Coding 在团队中的实际应用。内容涵盖导入过程中的常见陷阱、如何应对AI 生成的大量程式码、以及 Vibe Coding 对敏捷开发流程和团队文化的深远影响与挑战。 tags: - code - llm - vibe-coding - 团队协作 title: Vibe Coding 实战对谈：从导入挑战到团队文化转型 --- ## 开场与嘉宾介绍 JUGG: Hello 大家好，欢迎大家来到 JUGG 聊敏捷，我是 JUGG。最近有一个词非常的火红：**Vibe Coding**。**Vibe Coding** 是透过和 **AI** 的对话，让 **AI** 根据这些对话直接实作程式。听起来很梦幻，但他真的这么神吗？今天我们邀请到两位来自开发第一线的实战者，他们已经在团队里实际导入了 **Vibe Coding**，然后也是我的朋友。所以我们今天就要来聊聊，**Vibe Coding** 虽然强大，但是导入团队里会遇到什么问题？要注意什么？那大家一定一定要听到最后，我们会跟大家分享我们各自的秘密武器跟实战心法。那我们就来邀请我的两位好朋友，Derek 跟 Zen。 Derek: Hi Derek Zen，大家好我是 Derek。那我目前是在 Shopback 当 EM。快速的广告一下，Shopback 是专门提供购物现金回馈服务的公司，目前已经在十几个国家有这样子的服务。在我们这边的团队呢，其实日常工作有很多很有趣，然后也很富有挑战性的工作。我目前招募 BE FE 的正职还有实习。我们也很强调跨国的合作，我们这样的文化非常适合真的想要做事情的 Engineer。欢迎大家加入我们。 Zen: 嗨，大家好我是 Zen。现在是在 KKTV 担任 BE 的 Team Lead。那平常主要除了 BE 开发、技术架构的设计之外，自己本身也是很有兴趣在敏捷，最近这两年就在 **AI**。所以因为自己有兴趣，所以很常在团队里面去积极推动这方面的一些发展。 JUGG: 我们今天邀请到两位，而且都是在有实战经验的导入者，我们今天就来聊聊几个问题。 ## 导入 Vibe Coding 踩过的坑 JUGG: 导入的过程当中，大家踩过哪些坑呢？ Derek: 其实我想要先分享一个小总给这一题，这个坑的总结就是：可以充满好奇，但是不要跟风。其实我刚才讲那个 CBA (Context Behavior Action)，或者是 Zen 讲到了前中后，你会发现现在有各式各样的流派、各式各样的工具。其实如果你很常关注这些消息的话，几乎每周你都可以看到新东西。如果你对你自己到底要做什么没有掌握好，这都是在乱用。举个例子，就是我们遇到过的坑。 Derek: 其实 **MCP**（即 Marketplace，通常指插件或应用的商店）爆炸式的出现，大家可以理解，其实还有很多参差不齐的。一样要去接 Jira 的 **MCP** 其实有好几个，那他的差别是里面提供了三、四十个 tool，有一个里面只有五个 tool，对你来说怎么选择？那时候我就在想着，我们要怎么处理 Security？现在 **MCP** 的 Security 其实也是一个问题。其实包括这个东西一出来，我有点忧心。大家一直在用，然后一直说我们想装什么、想装什么。后来找了我们 InfoSec 跟他们一起看，然后拜托他们一定要帮忙去建一个 Pipeline。后来我们确实是建立了一个算是 review 的流程，但我们也没有算做这么到位，我们只是把我们想要的东西集中放到一个 Confluence page，说我们有哪一些 **MCP** 大家目前想试或正在试。然后我们的 InfoSec 他其实就会去定期去做那个 Run Sandbox，然后去确定这没有很明显的 Security 的问题，那或者是他不会真的去把 Credential 放到外面去。 Derek: 对，**MCP** 是一个坑。那另外就是比如说像大家知道在 Cursor 里面，**MCP** 是有使用上限。所以有些人很开心的装一装之后就发现，哇塞他怎么不调用我想用的 Tool，因为他达到上限了。所以取舍很重要。 Derek: 那讲一下取舍，刚才我们前面有聊到 **Cursor Rule**。事实上，他简单来说如果还不知道的同学，**Cursor Rule** 是一个让你先事先规范你的 **AI** 他会怎么样子理解、怎么互动。所以任何你希望，就有點像是去 ChatGPT 你要用的时候，可以先去设定就是你要对话的这个 ChatGPT，他的 Context、他的角色是什么、他熟悉的领域是什么。**Cursor Rule** 是一个这样的工具。如果他本身怎么样子被 trigger，就是在什么情境底下他会 apply 这个 rule，事实上是有四种不同的模式。那大部分都为了方便，就 always enable，塞了一堆的 **Cursor Rule** 的时候，其实你会让他角色错乱。所以会变成说你产出的东西会变成四不像，或是根本就没照你想要的来走。大家如果太跟风或求方便，什么东西都装、什么东西都用，出来的东西是你无法掌握的。所以我建议大家就是，真的要做导入过程中工具的选用，其实是要有意识的，知道你在做什麽事情。 Zen: 跟风啊或者是没有搞懂就用，这些害处就是，我发现过去在跟团队介绍这些时候，其实有些人他是连这个 Agent 背后怎么运作的不太晓得。像刚讲的这些 **MCP** 或者是 **Cursor Rule**，对应到的原理就是把它变成 **System Prompt**（系统提示：给AI设定的背景指令和角色，以引导其行为和回应风格） 的一部分。如果他装了一堆 **MCP**，但他要注意你现在这个情境有没有用到，他反而把他的原本要做事情污染掉，因为他是 **System Prompt** 长了一堆，或是把 TOKEN 迅速烧光。所以在导入前还需要做一些基本知识的建立，**System Prompt** 的原理是什么，我们的 Agent 的能力会变强是有哪几个面向可以去做，需要有一些前期的教育训练。 Zen: 回应一下刚刚 Derek 讲这一段，要导入前如果没有先有一些 Agent 或者是 **LLM** 的这些基本的知识建立的话，然后如果你的账单又没有设定好额度的话，像 Cursor 好像都是点数制还好，但如果你是用其他 solution 的话，那他肯定会被烧光。 Zen: 我自己遇到的一个经验，可能是写出来东西不符合需求。前期在使用的时候很常遇到，这部分要分两大块。第一个是业务的需求，你发现你脑海里面已经有很明显的一个画面，但是他写出来就是跟你不一样。他做的出来没错，但是不是我讲的那个东西。这个第一个是业务需求，他误会了，是我们一开始没有讲得更清楚。 Zen: 第二个是软体架构的需求。他写出来东西，本来 Codebase 就脏，然后他就继续髒下去。然后我们希望他期待符合一些 Clean Architecture 或是 Solid 原则，这些他都没有 Follow。第二个是可能写出来的东西不符合本身团队的 coding convention 的一些需求。如果是既有的 Code Base 的话，蛮多已经可以用的 Function 他都没有去 Reuse，他就自己造一个轮子。前期在用的时候蛮容易遇到一些坑的状况。 Derek: 我蛮同意 Zen 讲这个。其实我觉得多数的同学一拿到这个强大的武器之后，会觉得很酷，可是当开始要拿到现实 project 里面用，很容易就踩到这个问题，就是他也很快做了一个完全忽略我以前建的那个基础，然后自己又建了一套。那这些问题其实会发生，所以这才是为什么我们讲说 CBA 里面的 context 跟 behavior 很重要，以及你规划怎么阐述，你一定要去教育你的 **AI**，哪一个部分是你希望可以 leverage 的。每一次你都需要去重新去跟他去对齐，这个 feature 可能有什么过去的东西可以用，不要再重造，不要懒惰。这个不是放著一次，在那边跟他设一个固定的 Rule 就好，其实会在你的开发过程中需要不断地去调整的。 Derek: 我觉得这个虽然说他有点麻烦，但我觉得真的大家就是初阶使用者跟进阶使用者最大的差异。就是进阶使用者理解了，就刚才讲的原理很重要。他绝对不是一堆东西他读的很快，一万本书丢给他，然后就都交给他来决定。要有意识的去瞭解怎么跟他合作，有意识的丢给他说，你必须得参考什么，让他从那1万本里面先，我们已经先缩小范围了，这样他就比较精準。 Derek: 因为我们现在坊间看到什么 **Vibe Coding** 很多其实做的 demo 都是从0到1，从无到有的。但当真的我们导入到团队里面，我们现在开发的产品都是好几年前一直叠加上来的产物，有一些以前的叠床架屋的一些技术债。你从0到1造这个是很简单的，但要让 **AI** 读得懂现在 Code Base，应该建立在我们既有的 practice 上面，帮助我们加速，帮助我们可以有进展，而不是推翻甚至忽略我们原有的东西。 Derek: 我觉得就算是导入 **Vibe Coding** 之后，不要因为他很 powerful 很快，然后就忘记了我们自己应该要遵守的。所以有有时候我会看到大家在讲一件事情，说我做 **Vibe Coding**，那我是不是就是可能会变成产出更难控制，我要来更重视我怎么测试。其实我觉得不是，难道你做 **Vibe Coding**，你的 Code 的 coding convention 不是你原本期待的，就不理他吗？难道你做 **Vibe Coding** 就不做 Code Review 吗？这些其实是不现实的。所以当我们原本有什么好的 practice，千万不要因为這樣子把他拋棄，应该是想著怎么 leverage 这个，把它做的更好，而不是把原本东西全部都丢掉，然后就期待所有东西被自动化。想办法把这些原本我们的 convention，我们的 Best Practice 变成 **AI** 可以 follow 的一些 context 跟一些原则。 JUGG: 其实我很有感，其实软体开发就是这样啊，我们本来在没有 **AI** 的时候，其实他的基本架构在。我觉得有 **Vibe Coding**，有 **AI** 的辅助是 leverage 他们的强大。好像确实要跟团队里面有一个更深度的一个讨论，到底 Agent 加进来了，就像刚刚讲的，其实如果大家只是用了，但不去规范他，反而制造了更多问题，或者是产生了更多矛盾。 ## AI 生成代码的挑战与应对 JUGG: 我想问一个也很实际我自己很常碰到的问题。像我現在都不會 auto approval，其实我也很怕。所以其实 **AI** 给我的一些建议，一样 Agent mode 他会帮我改，但我还是会一样，一行一行去判断说他改的正不正确。其实大部分都对的，可是有一些东西我还是觉得跟我想像的不太一样。说实话，有时改的幅度也算很大。我不晓得这算不算一个坑，他是对的哦，然后他可能改法可能也是对的，但是幅度很大，这个时候我们要怎么面对？ Derek: 问题是说，做出来是你要的，但你不喜欢那个做法是吗？ JUGG: 也不是，应该说我会有点怕。应该说我不知道这个落在团队的 Code Review，明明可能改一件事情，可是因为我觉得 **AI** 有他的想法，他的逻辑去改，那他可能改了蛮大一块的东西。那可是我们在做 Code Review 就会变成有很多东西要看。Code Review 如果提交给我30行，我会觉得OK，那一次提给我3,000行，这个我要怎么看？不想看。这个是很现实的问题。 Derek: 我就回归到刚才在讲那个 CBA 里面的 action，就是我自己学到的这个经验是我得要让 **AI** 去控制，把他要修改的幅度要能够颗粒化，不要一次改太多。在我在做那个，不管是他叫 Taskmaster 或者是叫 plan.md，我其实都会要求 **AI** 其实每次要改的幅度，其实把他的要做的事情切成 sub-task，每一个 task 就是改特定的 Scope 就好，那他不要一次把全部都改完。这我觉得会让我们自己见树又见林，知道说他整个改动预计他会改到哪一些地方，然后他每一次都先改一段，然后先确定没问题再往下走。不然真的一整个改下去，我觉得应该如果大家用一阵子，都会有这种经验，一次讲完之后，他就会突然那个发飙，本来只是改一行，然后改一大段，就会很难控制。那也许他是对的，如果变成我们自己就没信心。 Zen: 这边我有个惨痛经验分享一下。其中也有一个命令是叫他去帮我增加 git ignore 里面的一些设定，就是有一些东西我要忽略掉，不要上到 git 那边。然后因为那次修改完就可能是上千行，然后我也懒得 Review，我这在我 local 测过是OK的。然后送到上面去 CICD Build 到测试环境就发现一直丢 Fail，就想说怎么一直丢 Fail，我 local 测都可以啊。后来就是发现，他在我的 git ignore 里面加了一段是会忽略我的实作的程式码，就是有一些幻觉。我 Review 的时候没有看到这一段，我就一起 Commit 上去时候，大概花了一个多小时在 Debug。我就一直问他为什么他跳这个错误啊，他都说我是因为怎么怎么怎么，我们这一直卡着，原以为是 library 的设定没有设定好。惨痛的经验。 Zen: 确实像 Derek 讲的，跟他说要 breakdown sub-tasks，然后再做的时候也会特别会下一个命令，请你一个一个进行，或者是一步一步思考一步一步做，然后做完要跟我确认这样。他就算是会连续做，但他中间也是会 break，然后跟你确认，你要确认完你这个OK，再叫他做下一个。经验是蛮相似的。 ## Vibe Coding 对团队文化与协作的影响 JUGG: 那我们接下来进下一个问题。接下来可能不是只是讨论整个工程师技术导入的问题，我们全公司啊，或者是公司的其他团队，我们会有什么建议？ Zen: 我先好不好。等一下想多听一下 Derek 那边这个磨合的过程。我自己有些疑问或思考，真的导入进来之后会发现，个人来说，他整个就是工作模式的一个转变啊。不确定其他工程师跟我是不是一样，但我自己确确实实看到的，因为日後可能更多的守备范围就不会只是在实作上面，可能前后怎么验证商业需求，或者前面更多怎么确认业务上面的需求或者瞭解会变成这些守备范围会更多。或从原本后端的架构，延伸到整个是 End to End 的架构，就是有点不再是 component 导向，而是 product End to End 的 Solution 导向，这样那个角度去发展。 Zen: 日後的工作定位，当然这个一定是奠基在良好的基本功底下。深度的内容是交给 Agent 去负责，那我是负责广度的。但这样就会看到工作分配上就会看到这样一个矛盾了。因为原本在跑 **Agile** 或者是 **Scrum** 这样的团队，我们每个 Sprint 会有 Sprint Goal 嘛。那可能这个 Sprint Goal 有3个 story，但我们如果 **Agile** 的做法应该还是追求团队会共同按照 value 去依最高价值的 story 先解决掉，而不是独立你做第一个、我做第二个、他做第三个。我们应该是1、2、3，三个人都先同时针对第一个 story 先解决掉。过去的做法是这样，保证我们第一个 story 最有价值，一定会被先交付，不会交出半成品。 Zen: 现在有了这个 Agent 之后，我们发现有个趋势，如果我一个 story 拆成 sub-tasks，有足够的 context 给予 **AI** 情况下，或许我一个人下个 prompt 就可以搞定了。就是我刚刚讲的，架构图画好，那请 **AI** 去读完架构图，请 **AI** 切好 sub-task，明确这个 sub-task 是要改什么，是不是真的可以想像一个人下这个 prompt 就可以把整个 story 搞定了。那我的疑问就是变成，那分工的意义在哪里？ JUGG: 其实这也是我最近在思考的问题。我也觉得因为我现在一直在把 **AI** 融合在过去的 **Agile**，但我会觉得有一个不可逆或者是即将来临的趋势，一條龍越來越多了。那可能也会代表团队会越来越分心，那我们要怎么协同合作这件事情？ Derek: 自己针对这一题，我自己的想法，到底 **AI** 导入是技术还是文化的部分，我会觉得这两种其实都是。在讨论的这么多过程当中，大家可以发现一件事情，我们讲了很多因为 **AI** 这些 **Vibe Coding** 进来的时候，他的工具、他的知识，这些是你的技术。另外就是开发了很多东西，刚 Zen 有提到，他帮我们建立了很多技术的深度，他所帮我们开发的东西，对我们来说我们不可能完全他讲的我们照单全收。所以我们在他建议以及帮我们实作的技术本身，我们还是得要去查证他这样的做法到底好不好，这已经很肯定在技术导入方面绝对是。 Derek: 另外一个方面是文化转型的部分。如果有经验在推动任何大型的改变，到你自己身上也许容易一点，到 Team 稍微有一点点阻力，那全公司你可以想像那个阻力很大。很多人会说：OK啊，我用 ChatGPT，很容易啊，不就进阶一点的 Google 吗？其实他会觉得很容易的，可是知易行难啊。我们怎么样子去让大家体验这东西的好处，并且让大家逐渐的愿意真的认可这样子的方式，然后逐渐的去 On Board。这个是今日推动上面的文化转型。 Derek: 包括像是我们如何去建立一个比较是 **AI** friendly 的环境。包括我们如何沟通的，我们是怎么样子用文件，不止给人看也给 **AI** 看。那最终会成为我们跟 **AI** 之间，其实互相在提供好处给对方。提供他更容易消化的资讯给 **AI**，**AI** 反应给我们更省时间的技术传承、知识传承，这个是文化的部分。 Derek: 在这样子的前提底下我们就要讲到说到底自己进来容易，那怎么帮助团队进来？甚至我们讲的团队可能更扩大一点，我们往上或往下，PM 在需求的更前端，甚至是 PM 在更前面的 stakeholder。那我做出来之后其实往后传递会交给 QA，甚至後面的 customer service，大家怎么在这一条共同的价值链上面能够互相的合作。 Derek: 我大概从年初开始讲这件事情，那当然其实在我们的公司里面，领导层也非常的支持这件事情的发展。所以我们看到现在其实是一个，也许大家都不进阶，可是大家已经开始从有 awareness 的阶段，开始进入到「对，我应该要开始先想，我要 **AI** first」。没办法去透过 **AI** 做的事情，我才自己用手做。让大家先开始去尝试并且愿意分享。那我们现在越来越看到的是，PM 所提供的 **PRD** (产品需求文档) ，他甚至有一些比较复杂的内容，他其实可以自己先用，其实有很多工具啊，Lovable 啊，或者是 Bolt，他只先建一个是真的可以动的 prototype 然后跟你讨论。 Derek: 我不是看一个死板板的，是非常简单的 Design，他甚至连 exception 怎么处理都已经帮你想进去了。其实他会让大家的沟通很快的。最近听到很有趣的例子就是 designer，过去我们会很多的 animation，designer 要怎么跟工程师沟通动画怎么做，其实过去超级痛。可是现在有 **AI**，其实会然这个变得很容易。就是喔，原来 **AI** 的旋转是这个意思啊。不然过去就是看静态图，然后静态图下面去加说明，然后可能或者是画白板用讲的。这些变得更容易了，其实我觉得让不只是开发容易，其实整个合作上面的那个摩擦在降低当中。 JUGG: 其实我有个有趣的观察，我记得前几月，大家如果说 ChatGPT 帮我生成的这件事情，还有点难以启齿，还说「哎这是 ChatGPT 生成的」。但现在应该是变理所当然了。大家生成出来的内容，很基本上你也不会太嫌弃这是 **AI** 做的东西。 Derek: 对，应该说已经，那我们现在要反过来问说，为什么这个东西不能用 **AI** 帮你做？ ## 给团队的最终建议 JUGG: 因为时间的关系，所以我们最后，就一句话，如果要给那些即将来临的要导入 **Vibe Coding** 的团队，或者还沒导入的团队，建议是什么？ Zen: 从自己的经验出发，有意识然后就可以先试着开始。那试着开始就是一个刻意练习。自己的想法是，其实在团队里面还是有那种小地方是有改善空间的。像是一些小小的 operation 的改进，或者是促进某些人合作的一些方式，或是某些文件交付的方式。像对团队本身有帮助，但他又不会太大，你就可以去试试看，用这小工具来先练练手。那从里面去归纳出你踩到什么样的坑，知道你痛点在哪里，才会知道哪边要突破，这些问题要怎么解。 Derek: 坦白讲我觉得很难一句话。这样子讲，是因为我自己把大家对 **Vibe Coding** 的成熟度分成四个阶段，我觉得各阶段需要做的事情不一样。 * **Level 1: 只闻楼梯响**。然后有听过的，我就建议不要想那么多，去玩然后去感受一下。 * **Level 2: 开始有一些玩过的人**。要开始去了解 **Vibe Coding** 的 CBA 到底他的用意是什么，以及在你的复杂底下有什么工具是适合的。 * **Level 3: 当你已经开始很了解**。除了个人用的好之外，你就要开始去想说，怎么样建立一个可长可久的，你们团队大家都愿意一起配合的顺畅的合作模式。 * **Level 4: 你们自己团队都已非常的流畅的在使用这些跟 AI 合作**。你要开始想的是垂直跟横向的扩展。垂直就是你们自己团队以外，你的自己工程师之外，那你的 PM、QA，再更往外，你的资讯的来源，最后你递交去帮你维运的这些人，他们是不是可以一起被拉进来。再来就是横向，除了自己团队以外，也开始去感染给其他团队。最终你整个组织自然发生有意义巨大的影响跟变化。 我觉得四个 Level 各自有一些不一样要做的事情。 JUGG: 那这边也帮 Derek 宣传一下，如果大家不知道那4个 level 是什么，我们会在我们的资讯栏会贴 Derek 的 Blog 文章，里面应该就会详细的说明那4个 level 是什么。 ## 结尾 JUGG: 那我们最后就真的非常感谢两位好朋友 Derek 跟 Zen。我们今天呢一起讨论 **Vibe Coding**，两位在百忙之中呢还参加经验对谈。今天非常精彩，而且我们也聊的很深入。如果你对 **Vibe Coding** 有实战经验，团队导入 **AI** 开发流程感兴趣，请记得订阅我们 JUGG 聊敏捷。我们接下来可能都会有些陆续的一些影片会上架，不会错过之后的精彩内容。JUGG 聊敏捷，我们下次见，Bye Bye。