1. Vibe Coding 导入的挑战、文化与建议 [0]

thumbnail

1.1. Vibe Coding 简介与嘉宾介绍 [0]

  1. Vibe Coding 的定义和背景 [4]

    1. Vibe Coding 是通过与 AI 对话，让 AI 根据对话直接实现程序。
    2. 这种方式听起来很梦幻，但其效果需要实际验证。

  2. 嘉宾介绍 [6]

    1. Derek：Shopback 的 EM，Shopback 提供购物现金回馈服务。
    2. Shopback 已在十几个国家提供服务。
    3. 团队工作内容有趣且富有挑战性。
    4. 目前正在招聘 BE、FE 正职和实习，强调跨国合作。
    5. 文化适合真正想做事的 Engineer。
    6. Zen：KKTV BE 的 Team Lead。
    7. 主要负责 BE 开发和技术架构设计。
    8. 对敏捷和 AI 领域有浓厚兴趣，积极推动团队发展。

  3. 讨论主题 [7]

    1. 讨论 Vibe Coding 导入团队时会遇到的问题和注意事项。
    2. 核心总结：可以充满好奇，但是不要跟风。

1.2. 导入 Vibe Coding 过程中遇到的“坑” [14]

  1. 工具滥用和选择困难 (MCP) [14]

    1. 市场上流派和工具众多，几乎每周都有新东西出现。
    2. 如果不清楚目标，盲目使用会导致乱用。
    3. MCP (Multi-Context Prompting) 爆炸式出现，质量参差不齐。
    4. 许多 MCP 都要接入 Jira。
    5. 不同的 MCP 提供的工具数量不同，选择困难。
    6. 安全问题 (Security)：MCP 的安全问题令人担忧。
    7. 团队与 InfoSec 合作，建立了 review 流程。
    8. 将想试用的 MCP 集中到 Confluence page。
    9. Info Sec 定期进行 Run Sandbox，确保没有明显的 Security 问题。
    10. 确保 Credential 不会被放到外部。
    11. 使用上限问题：Cursor 等工具的 MCP 有使用上限。
    12. 用户可能因达到上限而无法调用想用的 Tool。
    13. 取舍非常重要。
    14. Cursor Rule 滥用导致角色错乱：
    15. Cursor Rule 用于事先规范 AI 的理解和互动方式（类似 ChatGPT 的 Context/角色设定）。
    16. Rule 的 Apply 情境有四种模式，但为方便常设为 always enable。
    17. 塞入过多 Rule 会导致 AI 角色错乱，产出四不像或不符合预期。
    18. 建议工具选用要有意识，知道自己在做什么。

  2. 缺乏基本知识导致的问题 [22]

    1. 团队成员可能不了解 Agent 背后的运作原理。
    2. MCP 或 Cursor Rule 的原理是将其变成 System Prompt 的一部分。
    3. System Prompt 污染：装太多 MCP 会污染 System Prompt，或迅速烧光 TOKEN。
    4. 导入前需要建立基本知识：System Prompt 原理和 Agent 能力提升的面向。
    5. 如果没有建立 LLM 基本知识，且账单额度未设好，费用可能会被烧光。

  3. 产出不符合需求 [27]

    1. 业务需求不符：AI 产出与脑海中的画面不一致。
    2. AI 确实能做出来，但不是用户想要的。
    3. 原因在于一开始没有讲清楚。
    4. 软件架构需求不符：AI 产出的 Codebase 脏乱。
    5. AI 没有 Follow Clean Architecture 或 Solid 原则。
    6. Coding Convention 不符：产出不符合团队的 Coding Convention。
    7. 重复造轮子：对于既有的 Code Base，AI 没有 Reuse 已有的 Function，而是自己重造。

1.3. 进阶 AI 协作模式：CBA 原则与颗粒化控制 [34]

  1. 教育 AI 的重要性 [34]

    1. 初阶使用者拿到强大工具后，容易忽略既有基础，自己又建一套。
    2. CBA (Context, Behavior, Action) 中的 Context 和 Behavior 很重要。
    3. 必须教育 AI 哪些部分可以 leverage（利用）。
    4. 每次开发都需要不断调整，与 AI 对齐可用的旧东西，避免重造。
    5. 进阶使用者理解原理，知道要有意识地合作。
    6. 必须要求 AI 参考特定内容，缩小其决策范围，使其更精准。
    7. 坊间 Demo 多为从 0 到 1，但实际产品是多年叠加的产物。
    8. AI 应该在既有实践上加速，而不是推翻或忽略原有内容。

  2. 保持既有实践的重要性 [39]

    1. 即使导入 Vibe Coding，也不能忘记应遵守的规范。
    2. 不应因为 Vibe Coding 而忽略 Code 的 Coding Convention。
    3. 不应因为 Vibe Coding 而不做 Code Review。
    4. 好的 practice 不应被抛弃，应思考如何 leverage AI 使其更好。
    5. 团队应将 Convention 和 Best Practice 转化为 AI 可以 Follow 的 Context 和原则。

  3. 控制 AI 修改幅度（颗粒化） [47]

    1. 工程师仍需一行一行判断 AI 的修改是否正确，因为有时修改幅度很大。
    2. 提交 3000 行代码进行 Code Review 是不现实的。
    3. 解决方案：回归到 CBA 里的 Action。
    4. 必须让 AI 控制修改幅度，实现颗粒化，不要一次改太多。
    5. 要求 AI 将要做的事情切成 sub-task，每个 task 只改特定 Scope。
    6. 这样可以见树又见林，了解整个改动范围。
    7. 惨痛经验分享：
    8. 曾要求 AI 增加 .git ignore 设定，但修改了上千行。
    9. 懒得 Review，在 local 测试 OK 后提交。
    10. CI/CD Build 到测试环境后持续 Fail。
    11. 发现 AI 在 .gitignore 中加入了一段会忽略实作程序的设定（幻觉）。
    12. 花了一个多小时 Debug。
    13. 建议：要求 AI 一步一步思考，一步一步做，做完要确认。

1.4. AI 导入带来的工作模式与文化转变 [54]

  1. 个人工作模式的转变 [55]

    1. 工程师的守备范围不再局限于实作。
    2. 更多关注商业需求验证和业务理解。
    3. 工作定位从 Component 导向转变为 Product End to End Solution 导向。
    4. 奠基于良好的基本功，将深度内容交给 Agent，自己负责广度。
    5. Agile/Scrum 团队的矛盾：
    6. 过去 Agile 追求团队共同解决最高价值的 Story，确保先交付。
    7. 现在有了 Agent，一个人下 Prompt 就可以完成整个 Story。
    8. 疑问：分工的意义在哪里？
    9. 趋势：一条龙模式越来越多，可能导致团队分心，协同合作成为挑战。
    10. 现实：AI 出现后，软件工程师被裁员速度加快（美国和中国）。

  2. 技术与文化转型 [62]

    1. AI 导入既是技术问题，也是文化问题。
    2. 技术导入：AI 产出的工具和知识需要查证，确认做法是否良好。
    3. 文化转型：推动大型改变阻力很大。
    4. 许多人认为使用 ChatGPT 很容易，但知易行难。
    5. 需让大家体验好处，逐渐认可并 On Board。
    6. 建立 AI friendly 的环境，包括沟通方式和文件编写。
    7. 文件不仅给人看，也要给 AI 看。
    8. 最终实现人与 AI 互相提供好处，加速技术和知识传承。

  3. 跨团队合作与 AI First [66]

    1. 需思考如何帮助团队（PM、QA、Customer Service）在共同价值链上合作。
    2. 领导层非常支持 AI 发展。
    3. 趋势：从有 awareness 阶段进入 AI first 阶段。
    4. 优先考虑通过 AI 完成，无法通过 AI 完成的才手动做。
    5. PMD (Product Requirement Document) 的变化：
    6. PM 甚至可以使用工具（如 Lovable, Bolt）先建立可动的 prototype 进行讨论。
    7. Prototype 甚至考虑到 exception 处理，加速沟通。
    8. Designer 与 Engineer 的沟通：
    9. 过去 Designer 沟通动画制作非常困难。
    10. 现在 AI 使沟通更容易，例如理解 AI 旋转的含义。
    11. 合作上的摩擦逐渐降低。
    12. 社会观感变化：
    13. 过去提到内容是 ChatGPT 生成的可能难以启齿。
    14. 现在已变成理所当然，大家不会嫌弃 AI 做的东西。
    15. 反而会问：为什么这个东西不能用 AI 帮你做？

1.5. 导入 Vibe Coding 的建议与成熟度分级 [76]

  1. 给团队的建议 [75]

    1. 要有意识，然后可以先试着开始，这是一个刻意练习。
    2. 从团队中小地方的改善空间开始尝试。
    3. 例如小的 operation 改进，或促进合作的方式。
    4. 选用对团队有帮助但不会太大的小工具练手。
    5. 从中归纳踩到的坑和痛点，才能知道如何突破和解决问题。

  2. Vibe Coding 成熟度的四个阶段 (Derek) [78]

    1. Level 1 (只闻楼梯响)：
    2. 建议不要想太多，去玩，去感受一下。
    3. Level 2 (开始玩过的人)：
    4. 开始了解 Vibe Coding 的 CBA 用意。
    5. 了解在自己的复杂度下，有什么工具是适合的。
    6. Level 3 (个人用得好)：
    7. 开始思考如何建立一个可长可久的、团队都愿意配合的顺畅合作模式。
    8. Level 4 (团队流畅使用)：
    9. 开始思考垂直和横向的扩展。
    10. 垂直扩展：将 PM、QA、信息来源、维运人员拉进来。
    11. 横向扩展：感染给其他团队，最终对整个组织产生巨大影响。

  3. 总结 [84]

    1. 感谢 Derek 和 Zen 的经验分享。
    2. 讨论非常精彩深入，持续了一个多小时。
    3. 鼓励对 Vibe Coding 有兴趣的团队订阅 JUGG 聊敏捷。