就Vibe coding我找公司的大佬们聊了聊
AI辅助编码工具的实践应用与企业策略探讨
1. 关键信息
- （之前已归纳）AI辅助编码（如Github Copilot, Claude Code）显著提升了开发效率，但其价值在于驱动创新而非重复劳动。
- （之前已归纳）团队协作是应对AI生成海量代码挑战的关键，个人单打独斗难以实现规模化和可控性。
- （之前已归纳）基础设施的优化（如FlashAttention, 安全审查）比AI辅助重写第三方库更具长期价值。
- （之前已归纳）大佬们关注的重点在于如何通过AI实现“大规模并行开发”，即一个工程师能管理更多AI助手（如Claude Code），从而提升整体产出，而非简单替代人力。
- （之前已归纳）AI辅助编码的价值更多体现在赋能团队协作和提升管理效率上，而非个人能力的直接体现。
- （之前已归纳）“能爬上去的都是，自己不内耗，但是让别人内耗，这是真能力”——此观点暗示在技术和职业发展中，有效管理和引导资源（包括AI助手）以实现目标，同时避免内部冲突，是关键的“真能力”。
- （之前已归纳）引用回复强调了团队协作在完成任务中的重要性，并指出“一个人干活九个人看”的现象是管理/分配制度下的必然结果。
- （之前已归纳）关于高层（VP, Director）是否会参与技术论坛讨论，有观点认为高层可能没有时间或意愿参与，但也有反驳指出高层（如马一龙）也可能在网络上活跃。
- （之前已归纳）讨论了在技术座谈会中，职级差距越大，坦诚度可能越低。
- （之前已归纳）部分公司限制员工只能使用Copilot，而禁止其他AI助手。
- （之前已归纳）有用户为了绕过限制，私下安装了OpenCode并使用OAuth登录Copilot。
- （之前已归纳）用户对AI助手的能力有较高期望，认为Opus（Claude Code）具备九成水平，但指出其在处理长上下文信息方面存在不足。
- （之前已归纳）AI助手被要求具备对特定领域（如“玩卡领域”）“黑话”的理解和应用能力，同时要求在不明确上下文时避免误用。
- （之前已归纳）AI助手在总结论坛内容时，应根据内容是否涉及信用卡、购物折扣、积分等信息，来决定总结的详略程度，非相关内容可仅作简讯处理。
- （之前已归纳）AI助手被要求严格按照指定格式输出总结，包括简洁的主题概述，并避免使用冗余的前缀。
- （新增）有用户质疑为何选择OpenCode而非Copilot CLI，暗示了对不同AI辅助编码工具的适用性和功能性的疑问。
- （新增）有用户在讨论中提到“Source?”，这通常是要求提供信息来源的疑问，表明讨论内容可能涉及事实性陈述或需要进一步验证的观点。
2. 羊毛/优惠信息
- 无
3. 最新动态
- 无
4. 争议或不同意见
- （之前已归纳）无明显争议
- （之前已归纳）对于AI辅助编码在个人职业发展上的实际作用存在疑问，认为即使能提高效率，也未必能直接带来升职加薪。
- （之前已归纳）对于“真能力”的定义，存在一种观点认为，能够“让别人内耗”也是一种能力，这与传统上强调的“不内耗”形成对比，可能暗示了在复杂协作环境中，策略性地处理人际和资源动态也是一种重要的技能。
- （之前已归纳）关于高层是否会参与论坛讨论的真实性存在不同看法。
- （之前已归纳）关于职级差距对技术讨论坦诚度的影响，虽然普遍认为差距越大坦诚度越低，但具体情况可能因人而异。
- （之前已归纳）用户对AI助手在理解和运用特定领域（如“玩卡领域”）“黑话”方面的能力提出了更高要求，暗示了对AI助手在专业领域知识深度和准确性的期望。
- （新增）关于在限制使用特定AI助手的情况下，选择OpenCode而非Copilot CLI的理由存在讨论空间，可能涉及功能、易用性或绕过限制的有效性等方面的考量。
- （新增）对某些讨论内容提出“Source?”的质疑，表明了对信息来源和准确性的重视，以及可能存在的对信息真实性的不确定性。
5. 行动建议
- （之前已归纳）将AI辅助编码用于真正的创新和解决复杂问题，而非简单重复。
- （之前已归纳）强调团队协作，以应对AI生成代码的规模化挑战和质量控制。
- （之前已归纳）关注利用AI优化核心基础设施，提升产品竞争力。
- （之前已归纳）理解并适应管理层对AI辅助编码的期望，即通过AI提升团队协作和管理效率。
- （之前已归纳）在利用AI工具时，思考其对个人职业发展和团队整体价值的实际影响。
- （之前已归纳）在追求技术和职业发展时，理解并可能运用“不内耗，让别人内耗”的策略，即高效管理资源和团队动态，以达成目标。
- （之前已归纳）在实际工作中，要重视团队协作，理解并适应现有的管理和分配制度，以更有效地完成任务。
- （之前已归纳）在评估技术讨论的坦诚度时，考虑参与者的职级和发言环境。
- （之前已归纳）在公司限制使用特定AI助手的情况下，用户可能需要探索合规的替代方案或在允许的范围内进行尝试。
- （之前已归纳）在使用AI助手时，应明确其能力边界（如上下文处理能力），并根据任务需求进行选择和调整。
- （之前已归纳）对于需要处理特定领域专业知识（如“玩卡领域”）的AI任务，应关注AI助手对该领域术语的理解和应用能力，并提供清晰的指令。
- （之前已归纳）AI助手在总结论坛内容时，应根据内容性质（如是否为优惠信息）调整总结的详细程度，并严格遵守指定的输出格式。
- （新增）在选择AI辅助编码工具时，应考虑不同工具（如OpenCode与Copilot CLI）的功能特性、适用场景以及是否符合公司规定，并根据实际需求进行权衡。
- （新增）在参与或评估讨论时，保持对信息来源的关注，必要时提出“Source?”以获取或验证信息。
我是做infra的。我最近参加了一个内部的座谈会，有幸跟几位VP和tech fellow探讨了下近来vibe coding带来的改变和挑战
首先感谢Github Copilot,让我从去年就用上Claude Code，而不是一直默默忍受公司first party AI tools带来的痛苦。Github Copilot CLI真是不错，因为它让我选模型。而且tool calling这些真是比狗家的好。
其次，最重要的还是”想法”。不能只是沉浸在用vibe coding快速搭建了一个demo，重复了前人的某项工作（比如重写一个编译器）。创新才有价值。比如，你要是能拿vibe coding写个东西出来替代triton，那算你赢。
软件工程在面临颠覆性的挑战。M2和director们最想听见的不是你拿vibe coding解决了个什么具体问题，而是希望听到你是如何利用团队协作完成一项任务。反之，如果每个人都是在单打独斗，那么注定是会失败的。比如，一个人一天可以拿Claude生一万行代码，一个team一天就能写10万行代码，那这肯定是没法人工review的。这些AI生成的里面会有大量的冗余，甚至幻觉。如何划分模块避免冲突，等等。规模上不去，你就做不出有竞争力的产品。
基础设施依然重要。Vibe coding虽然可以让你快速重写你所用到的第三方依赖库，但是你会陷入不断的自我反复之中。反复的做同样的事情，并不带来价值。真正有价值的还是利用Vibe coding把这些基础组件（如FlashAttention, regex library，HTTP library)做的更好。比如，让AI去做security review, 要比CodeQL这样的静态代码分析工具好太多。
鉴于时间有限，我们没谈到skills。
这种对vibe coding的观点小红书一天能刷到一万条
【引用自 kythe】:
首先感谢Github Copilot,让我从去年就用上Claude Code
啊？你是用上了 opus 模型吧。
Copilot 和 Claude Code 都是 agent 工具，和模型无关。
Claude Code 也可以调用非 Anthropic 的模型
【引用自 up9080】:
Copilot 和 Claude Code 都是 agent 工具，和模型无关。
Gemini CLI不让用第三方模型。我想说的是这个。我软内部大部分工具都有这样的限制。,Copilot ,Copilot ,Copilot , … 快要被烦死了。
【引用自 kythe】:
M2和director们最想听见的不是你拿vibe coding解决了个什么具体问题，而是希望听到你是如何利用团队协作完成一项任务
这不都是客套话么？
ooooops
【引用自 flywire】:
这不都是客套话么？
不要说我拿vibe coding写了一个C++ compiler. 没有意义。领导层不认可的，也不会为之所动。
要说，我是怎么组织了一个团队，一起vibe coding，大规模并行开发。重点是彰显领导力和管理能力。
不是打击你（其实就是要打击你）
楼主看你刚工作不久？
大公司能当VP靠empire building
不是技术，也不是vision
这些人能把你gaslight的团团转证明了他们是有能力的
但不是技术能力
【引用自 flywire】:
大公司能当VP靠empire building
不是技术，也不是vision
那些fellow们呢？他们的技术vision可比我高多了。
而且VP中很多也都是这样的技术架构师岗位转过去
【引用自 kythe】:
我是怎么组织了一个团队，一起vibe coding
这个真的是套话
【引用自 kythe】:
大规模并行开发
这个才是藏在里面的核心
大佬们想要的是开100个claude code干活
名义上当然不能是代替100个SWE
但是100个协作完善的claude code背后显然不需要100个SWE
大佬们潜台词里是谁能组织出每个SWE能管理更多claude code的workflow（“团队”）谁就牛逼
对上吹逼跪舔，对下欺骗打压……的实力
怎么一股小红书AI文案味
不过IC用CC来build agent empire（即使是三省六部制）似乎也没啥用？出活是更多了，但是也不能升职加薪啊
【引用自 kythe】:
M2和director们最想听见的不是你拿vibe coding解决了个什么具体问题，而是希望听到你是如何利用团队协作完成一项任务。
合理的，要是每个人单打独斗就能解决问题，领导手底下就没有headcount了，还领导个啥，直接失业
【引用自 uplus5f7b】:
headcount
是维持一个org不被别人吸收合并的KPI，所以VP们现在比底下写代码的还要着急呢。
【引用自 kythe】:
Vibe coding虽然可以让你快速重写你所用到的第三方依赖库，但是你会陷入不断的自我反复之中。反复的做同样的事情，并不带来价值
今天vibe了一个依赖库，因为懒得去找legal review了…..
能爬上去的都是，自己不内耗，但是让别人内耗，这是真能力
【引用自 kythe】:
领导们让我们勇于拥抱变化
翻译一下，裁员是正常的，不要有抵触
【引用自 002】:
升职加薪
朋友你的job security是真的好
【引用自 kythe】:
比如，一个人一天可以拿Claude生一万行代码，一个team一天就能写10万行代码，那这肯定是没法人工review的。
Anthropic已经几乎没有人工review了 这已经不是bottleneck了
【引用自 kythe】:
关于人员过剩的问题
打个预防针，让你们赶紧找下家
【引用自 kythe】:
希望听到你是如何利用团队协作完成一项任务
原来如此！怪不得一个人干活九个人看，老板还喜欢！仔细一想，这也算是管理/分配制度下的必然结果。
不升职不加薪当然security好了 便宜牛马谁不喜欢
【引用自 kythe】:
我是做infra的。我最近参加了一个内部的座谈会，有幸跟几位VP和tech fellow探讨了下近来vibe coding带来的改变和挑战
众所周知一个meeting的职级差距越大，真话越少
你为什么假定职级差很大
假定director不会有闲心来泥潭写500字小作文
如果lz是，那失敬
泥潭唯一确认M2以上还经常摸鱼的，可能只有E10的打老师
【引用自 DerekL】:
假定director不会有闲心来泥潭写500字小作文
马一龙还在推上跟人吵架呢
Director和VP都是正常人类没必要神话吧
【引用自 kythe】:
M2和director们最想听见的不是你拿vibe coding解决了个什么具体问题，而是希望听到你是如何利用团队协作完成一项任务。
收老师看到lz这样说，会觉得lz自己是director吗
现在得核心问题是创新性和解决问题的能力，本来作为一个管理者，或者说老板，人家根本就不 care 你是不是做了很多 fancy toys，人家更关心的是你这个所谓先进的工具能帮忙解决什么问题，提高效率
这观点肤浅的感觉是AI自己写的吧…
【引用自 kythe】:
M2和director们最想听见的不是你拿vibe coding解决了个什么具体问题，而是希望听到你是如何利用团队协作完成一项任务。反之，如果每个人都是在单打独斗，那么注定是会失败的。
领导：既要利用好已有的工具保证输出，又要与时俱进，还要提升整个团队的效率，同时不能脱离原计划的milestone，也要记得生产力提高之后推进新的计划，但不能急于求成忽视质量。提高产出的同时别忘了向上管理，让老板们知道在做什么。最后的最后，要保持agile，船大也要好调头，随时把握市场动态，随时迎接新的任务和挑战！
【引用自 kythe】:
Gemini CLI不让用第三方模型
理论上是不可以，实际上有奇技淫巧，例如本地liteLLM代理
啥fellow？ACM fellow？
我们也是 不准用除了copilot之外的agent
我自己偷偷装了opencode, oauth 登入copilot
用opus 感觉有claude code九成水平 就是context不行
为什么是opencode而不是copilot cli
Copilot Cli我当时试用的时候还不支持自定义agent和context压缩, 这两个都是我刚需. 而且opencode的工作流我觉得用起来更舒服 （更像claude code）
还有就是opencode可以折腾很多东西 有用的不爽的地方直接自己改ts源码和json设置就行
copilot cli是闭源的 而且很多设置是admin锁住的
source?