Vibe Coding只适合两类人：个人快速验证想法，或成熟团队的前期探索阶段_服务软件

1. 蚂蚁灵光，30秒生成专属程序，普通人也能手搓代码 #蚂蚁灵光 #AI #阿里

2. //@出版人周筠:#认知#//@程序员邹欣://@渔不鱼的生活日记:我现在大部分精力放在将过往的工作经验整理成具体的规范，不仅是为了保证代码质量，也为了让AI写出的代码符合“我的认知”，减少我了解AI开发的项目的成本，同时也在锻炼我的“Agent能力”和“元思维”能力。评论配图

3. 你是海盗和建筑师？最近 Dan Shipper（Every CEO）发了一条推，提出了 2026 年工程团队的新结构：只需要两个人，一个海盗，一个建筑师。以前我们默认一个好工程师要同时具备两种能力：动作快 + 架构好。但这两种能力天然矛盾——动得快的人容易留一堆技术债，架构严谨的人容易跑太慢。AI 编程工具出现后，这个矛盾可以用分工来解决。海盗（Pirate）干什么1）用 vibe coding 的方式快速开发功能，直接上线2）不纠结代码是否优雅，目标只有一个：找到真正有价值的产品方向3）本质上是产品探索者，负责在混乱中找到信号建筑师（Architect）/架构师干什么1）接过海盗探索出来的产品表面2）整理代码结构、设计系统架构、建立可维护性3）本质上是系统的守护者，负责让探索出来的东西能长期跑#HOW I AI# #程序员#

4. //@axb的自我修养:很难，从目前我的实践来看，目前“基于AI开发一个可维护的系统”还属于个人设计和架构能力的范畴，暂时没法把这个能力也通过AI大规模量产。程序员一段时间内应该还有饭吃……//@字节流:但是不同角色写另一个角色的代码，怎么保证可维护性，不成💩山

5. 有人说用“vibe coding”（凭感觉用AI写代码）能直接做出上线的生产级应用，这是不现实的。生产环境的软件必然复杂，需要大量代码的编写和维护，单靠写prompt根本撑不起。AI确实能帮你快速生成代码片段，甚至能做一些简单小工具、小项目，或者快速搭建原型，提升开发效率。但当涉及到真正的生产级应用，边界条件、集成、安全、性能和稳定性等问题，都需要工程师的严谨设计、测试和持续维护。那些说“vibe coding”能做出SAP、Salesforce这样的大型系统，显然是夸张了。相反，经验丰富的工程师利用AI辅助，能快速完成70%-80%的代码工作，但他们依然需要深入理解业务、规范开发流程、严格测试和持续重构。成功案例确实存在，比如一些小型APP或合规项目用AI辅助开发并上线，但这更多是建立在开发者本身具备扎实的基础和工程能力上。完全靠AI和prompt从零开始，几乎不可能保证产品质量和稳定性。AI是加速器，不是替代品。真正的生产级软件开发，离不开架构设计、代码审查、测试覆盖和持续迭代。那些只靠prompt写代码，却指望一劳永逸的人，注定会碰壁。生产级代码的核心，是对复杂性的掌控，而不是对AI的盲目信任。AI帮你写代码，工程师帮你撑起整个系统。原文：x.com/svpino/status/1993672597792518177

6. Anthropic官方报告：8大趋势说透AI编程未来，60%代码AI写的，老金实测项目带你看！

7. 【AI写代码像实习生：能跑但丑，管不住但离不开】快速阅读：Karpathy在播客后的互动中坦言，AI Agent写的代码质量糟糕——抽象臃肿、复制粘贴成瘾、完全不理会AGENTS.md里的规范要求。但他已经放弃抵抗，因为“耸耸肩比折腾容易”。开发者们分享了各种应对策略：TDD、双Agent审查、后置清理流程，但核心矛盾未解：我们还需要在意代码美学吗？---Karpathy最近上了Sarah的播客，聊完继续在推特答疑。有人问他对Agent生成代码质量的看法。他的回答很直接：不满意。Agent会把抽象写得臃肿不堪，代码审美一塌糊涂，疯狂复制粘贴，搞得一团乱。最让他头疼的是Agent根本不听AGENTS.md里的指令。比如他反复强调“每行代码只做一件事，用中间变量作为文档”，结果Agent照样写出一行调两个函数再索引数组的复杂结构。他知道可以用hooks或slash命令清理，但后来发现耸耸肩更省事。这段话引发了大量讨论。有人建议用TDD，在markdown里写测试再实现。有人用第二个Agent（Codex）审查第一个的代码，专门抓臃肿和复制粘贴。还有人分享了一个“review风格的提示词”，在PR前运行一次，能删掉20%的代码——提示词核心是“让代码看起来像一开始就设计好的最优解，而不是迭代出来的意大利面”。Karpathy承认，用LLM作为“软奖励”的评判者长期看有问题（Goodhart定律），但短期内低垂的果实还没摘完。有个有意思的观点：我们试图把个人设计偏好和风格强加给代码，但这些代码未来可能只需要被Agent理解和维护。大多数技术负责人在人类团队里早就学会了这一课——在护栏内给执行者一定自主权。另一个角度更激进：代码能跑就行，丑就丑吧。这个取舍会定义未来五年的软件开发。就像我们不会去审查编程语言编译出的汇编或字节码质量。也有人发现Agent特别啰嗦——长变量名、重复代码、普遍低效。怀疑训练时有某种激励机制让模型倾向于冗长，毕竟那意味着更多token。但AGENTS.md为什么不起作用？有人认为这是记忆架构问题。人类开发者不需要2200字符的提醒文件，因为偏好编码在长期认知记忆中，是内化的模式而非显式指令。建议参考神经科学的互补学习系统，让Agent从交互中把偏好、风格、模式巩固成语义理解。另一个解释：Agent更擅长遵循结构化的机器可读上下文，而非散文式规则。有人做了operate.txt，用YAML格式定义规范，效果比markdown好。还有一种思路：把它当两阶段过程。第一阶段让Agent随便写，目标是跑起来；第二阶段切换到重构模式，让Agent写LLD（低层设计），再从那里改进结构和质量。但最激进的声音可能来自这条：一旦你接受“测试通过就是反馈循环”，代码审美的争论就死了。讨论的另一端是警告。有人说糟糕代码会影响LLM进一步扩展或修改的能力吗？还是说对LLM来说，代码质量根本不重要？有职业生涯大部分时间在维护复杂代码库的老开发者表示，想到要在AI生成的臃肿代码里找bug就感到恐惧，庆幸自己快退休了。也有人建议用提交钩子，配合严格评分的审查Agent，或者让Agent访问编译、延迟等可验证环境来关闭反馈循环。Karpathy没有给出答案。他只是停止了对抗。ref: x.com/karpathy/status/2035173492447224237#AI创造营##人工智能#

8. 过去十年，大家一直在说AI会改变编程。但现在看，真正被改变的，可能不是“写代码”，而是“审代码”。如果未来AI写代码、审代码都变成了常态，程序员最核心的能力到底是什么呢？#大有学问 #红衣聊AI #anthropic #人工智能 #程序员

9. 阿里开源 Qwen3.5-Plus！三千行代码一次生！超强性能超低价格

10. 现在AI写程序很强，把一个需求告诉它，它三下五除二，可轻轻松松地弄出上千行代码，往往还真可以跑~~~但怎么用它，还得看具体的应用场景。如果是演示用的程序，用AI生成80%甚至更多的代码，看一看，需要时调一调，能跑就行了，没问题。如果是需要长期维护的程序，或者是代码出了问题，会造成真实的损失，自己要背锅的场景，那就不能这么干了，要限制AI一次生成的代码规模，个人感觉，最好控制在一个类甚至一个函数的级别，并且需要人工地过一眼生成的代码，必要时，还得配上测试代码，对其进行多次的单元测试和集成测试。记住：AI写代码，通常是“管杀不管埋”的，它从不背锅，背锅的只能是人。

11. AI 正在迫使我们编写优质代码 bits.logic.inc/p/ai-is-forcing-us-to-write-good-code 这篇文章提出了一个反直觉的观点：与其说 AI 会导致代码质量下降（充满垃圾代码），不如说为了有效利用 AI，开发者必须被迫采用更好的软件工程实践。作者认为，如果你的代码库混乱、耦合度高、缺乏文档，AI 辅助工具（如 Cursor, Copilot 等）的效果就会大打折扣。反之，为了让 AI 发挥最大效用，你需要编写模块化、清晰且易于理解的代码。这种需求实际上倒逼开发者去遵循经典的“优质代码”标准。 #科技先锋官#

12. 大家在使用AI编程时，更倾向于让AI一次次生成短小易读的代码，还是直接放手让AI写一大片？

13. With AI, building is easy; maintaining is hard.AI让“vibe coding”成了新潮流——几句话搭出原型，功能一夜成型。但当项目从Demo走向Production，复杂度非线性飙升：依赖增多、边界扩展、需求迭代、等等，那些为“快”而生的代码，开始暴露脆弱性。真实项目中，真正拉开差距的，不是生成速度，而是工程化体系：代码规范与架构边界、测试策略与CI/CD、监控告警与变更治理、等等。把流程固化，把风险前置，把维护成本压进系统里——这正是Harness一直在做的事。我觉得，能搭出一个东西不算什么，能让它健康地活下去，才是硬实力。#AI编程##vibeCoding##软件工程##DevOps##技术思考##微博AI创作季#

14. 告别数据库“膨胀”：Dify x SLS 构建高可用生产级 AI 架构

15. 最近半年高强度使用Codex和Claude Code，感觉我的编程能力反而提高得更快了。刚开始让AI实现一个复杂功能，如果实际效果和预期不符，AI写的一堆代码我也很难读懂，那么更快的方式就只能回退代码再调整提示词不断重试，像抽卡一样。后面用speckit、gsd和superpower这些工具，逐渐可以让AI在复杂项目里一次就实现可用的完整功能了，但为了让项目质量可控，那就不得不把AI写了两三天的代码硬着头皮全部读完。后面逐渐发现直接用Codex和Claude Code，让它写一堆代码也能很快看懂了，于是就不需要反复抽卡了，它一边写我一边看，追加提示词让它接着改，甚至有时候它写的速度跟不上我看的速度，就给完修改意见以后预判它接着写的代码可能有什么问题，让它一块一块检查，也能一把梭出可用的高质量实现。

16. Simon Willison开始连载自己的新书Guides: Agentic Engineering Patterns了地址： simonwillison.net/guides/agentic-engineering-patterns/一本系统的总结“如何用编码代理（如 Claude Code、OpenAI Codex）写出高质量代码”的实践模式。目前发布了前两章：《Writing code is cheap now》——代码初始成本趋零，对个体与团队协作直觉的冲击。《Red/green TDD》——测试先行可让代理用最少提示写出更简洁可靠的代码。#HOW I AI#

17. 为什么在生产环境部署多智能体系统（Multi-Agent）容易出现成本失控，有哪些常见的踩坑场景？

18. 【Slop Code时代：当人人都能写代码，真正的门槛在哪里？】Naval一句话爆了科技圈："我们现在进入了slop code时代。"什么是slop code？就是那些AI批量生成的、能跑但谈不上优雅的代码。有人嘲讽，有人辩护，但这场讨论本身就说明了一切。有意思的是，评论区形成了几个鲜明的阵营：乐观派认为，slop code虽然粗糙，但它能跑。有人用Claude Code一天完成了原本需要两个月的项目。当创造的门槛降到零，更多想法得以落地。现实派指出，slop code早就存在，只不过以前叫"企业级软件"。人写的代码也未必高明多少，只是现在AI让问题更显眼了。最深刻的观察来自一条评论：编程已经从"写作"变成了"编辑"。入门门槛降到了零，但质量门槛提高了十倍。这才是关键。当生成代码变得廉价，真正稀缺的能力变成了：判断什么该写、什么不该写；在一堆能跑的代码里识别出真正好的设计；以及调试别人"氛围编程"产物的耐心。每个技术民主化的时代都伴随着质量的短暂下滑，然后是新标准的建立。智能手机让人人都能拍照，但好照片依然稀缺。AI让人人都能写代码，但好软件的定义正在被重新书写。slop code不是终点，是起点。问题是：你站在哪一边？x.com/naval/status/2008184012456751333

19. AI编程大战正式开打！ Claude vs GPT同一天放大招，不是比谁代码写得好，而是AI开始自己组队当项目经理了。#大咖观察 #红衣聊AI #编程 #ChatGPT

20. 虽然我自己已经完全切换到Claude Code，但是了解一下为啥还会有那么多人Cursor也能有更全面的观点，评论区说说你都怎么用的？Reddit上有个帖子：r/vibecoding社区问"为什么有人还在用Cursor而不是Claude Code？"去年Claude Code发布后，社区普遍认为它会压倒Cursor。但现实是，Cursor仍然有大量用户。从评论区大家的回答可以看出Cursor的强项：1）开箱即用 — 安装后不需要额外配置，能立即开始编码2）IDE集成最好 — 所有传统IDE功能都有，快捷键熟悉3）上手快 — 工程师5分钟内就能适应，没有学习曲线4）成本低 — 月费$10，功能够日常用5）代码补全 — 行级补全做得很好，快速迭代时很顺手而Claude Code的强项：1）推理深度 — 能理解整个项目的逻辑，不只是当前文件2）自主修复 — 出错时能自动分析和修复，不需要人工干预3）全局追踪 — 跨文件改动时能保持一致性4）测试生成 — 能自动生成高质量的单元测试5）学习成本 — 需要学会用Prompt和Agent思维Reddit的共识是：根据场景不同，选择不同。Cursor适合：✅ 日常编码和快速迭代（原型开发、功能添加）✅ 简单的脚本和工具（几百行代码）✅ 新手或想快速上手的工程师✅ 团队需要"开箱即用"的工具Claude Code适合：✅ 大型遗留代码重构（1000行+，逻辑复杂）✅ 跨文件的系统性改动✅ 自动化测试补全✅ 需要"深度思考"的复杂问题「Cursor像是IDE的助手，Claude Code像是一个高级的工程师助手。前者帮你更快地打字，后者帮你思考怎么改架构。」原文讨论：www.reddit.com/r/vibecoding/comments/1pu1g9b/people_still_using_cursor_over_claude_code_can/#HOW I AI##程序员#

21. AI生成的代码你们会去一行行检查吗？

22. 我们最近还在继续探索AI时代下，新的研发范式，几个想法：1. 在AI研发范式下，解决“协作”的问题，权重越来越高于解决“研发”的问题，这中间既有各角色因为AI加持带来的工种边界模糊问题，也有因为AI带来的“跟你说不如跟AI说”的沟通成本问题，还有打破既有研发流程以后带来的管理滞后性问题。2. 对于团队来说，开发工具的标准化，重要性开始低于模型和Skill（提示词）的标准化。3. 研发人员对于项目可维护性的把控能力对研发效率有明显的影响，目前我review代码的时间主要用于观察代码结构和设计是否被破坏，基本不看功能。4. 按我目前的认知，如果按能力阶段大致划分纯研发团队的AI应用水平的话：AI代码占比(AI开发代码/总代码量）低于90%的研发团队属于还没入门阶段AI开发时间占比（AI开发的时间/AI&研发人员参与的时间）<80%的研发团队属于中级阶段剩下的一小撮属于高级阶段国内目前绝大部分研发团队还在初级阶段徘徊：习惯了靠堆人，突然要转向高度自动化的方式提升效率，免不了还是有个难受的过程。

23. 我刚才和一个朋友聊天，他用所谓的 VibeCoding 做了一个软件产品。我当时就跟他说：你的代码其实已经是一团烂摊子了。我以为我快说服他了。结果他一脸茫然地看着我。然后他说了一句：“所以呢？”就在那一刻，我突然明白了。这些 VibeCoder，根本不在乎代码本身。他们不理解代码的结构，也不去维护代码，以后更不会亲自处理代码带来的问题。所以，代码对他们来说不是重点。他们只关心一件事：把脑子里的想法做出来。除此之外，别的都不重要。他们完全没有被我们这些“传统程序员”认为是致命问题的东西拖住。对他们来说，那些根本不算什么问题。这挺有意思的。#科技先锋官##微博年度新知博主##微博兴趣创作计划#

24. 现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗？

25. 有网友问 Claude Code 作者 Boris：如何有效审查 AI 生成的代码？Boris 给了 3 条经验技巧：1. 默认使用 Plan 模式。2. 给 Claude 提供一种验证其输出结果的方法，比如单元测试、Claude Chrome 扩展程序，或者 iOS/Android 模拟器。3. 使用 /code-review 来自动化大部分的代码审查工作。对 Claude 生成的代码保持与人类写的代码相同的标准。

26. GPT-5.2七天生成 300 万行代码造出 Chrome 级浏览器，这意味着什么？

27. Claude Security开放公测：Opus 4.7加持，一键实现代码漏洞扫描与补丁生成

28. 德国萨尔布吕肯计算机科学团队的最新研究显示，软件开发者在使用 AI 编码助手时，往往比与人类搭档协作时更难保持批判性思考。这种变化不仅影响代码质量，也削弱了知识共享的效果。相关成果已于 11 月 16 日在首尔召开的第 40 届 IEEE / ACM 自动化软件工程国际会议上发布。该研究由萨尔大学计算机科学教授斯文・阿佩尔（Sven Apel）团队开展，研究者将参与者分为两组：6 组采用传统两人协作，7 组使用 AI 助手协作（采用 GitHub Copilot）。任务涉及算法开发与项目集成，通过尼科拉斯・施耐德（Niklas Schneider）设计的测量方法评估知识传递效果。实验显示：与人类搭档协作的开发者更倾向质疑讨论，而使用 AI 助手的组别普遍持有“代码大概能正常工作”的态度，79% 的人直接接受 AI 生成的代码建议，很少进行深入审查。据介绍，在传统“双人协作编程”中，两名程序员通过持续讨论和合作，可以避免错误并互相学习，使团队中更多人熟悉代码库。然而，这种优势在与 AI 协作时显著减弱。虽然人机团队也会交流问题和解决方案，但内容更集中于代码本身，讨论范围明显更窄。Apel 认为，这种更容易信任 AI 的倾向可能会在其他领域同样出现，也可能导致更多“技术债务”积累，即未来为修复隐藏问题所需的成本。研究团队表示，目前的 AI 工具在处理简单重复性任务时具有实用价值，但尚无法替代人类间在复杂问题上的深度交流。

29. 你觉得 AI 写 90% 代码这件事，是夸张宣传，还是已经快成现实了？

30. 在 AI 一键生成代码的时代，程序员还有必要坚持手写「古法编程」吗？

31. 关于 VibeCoding 时代的思考，未来程序员的工作到底是什么么样的？需要什么样能力的程序员呢？1、现在的瓶颈不是写代码了以前做技术活，项目管理、需求文档、测试流程这些都很成熟，但写代码本身通常还是最花时间的部分。现在不一样了。AI 让写代码变得特别快，有时候几分钟就能生成一大段。真正拖时间的反而是代码之外的那些流程。所以当开发者，不只是会写代码和会用 AI，还得搞懂整个开发相关的工作。2、对齐（沟通）AI 写出来的代码看上去可能很专业，但不一定是你真正要的东西。为什么？因为整个流程像玩“传话游戏”：业务的人脑子里有个想法，他们告诉你，你再把这个想法变成指令告诉 AI，AI 根据你的指令写代码。中间每一步都可能“跑偏”。所以现在最重要的是：沟通清楚，让大家都对同一件事有同样的理解。3、质量保证（测试）以前写代码的过程就是不断遇到 bug、不断修 bug，顺便就把质量保证做了。现在 AI 一次能给你生成一个完整的后端或前端，看起来就像“直接能用”。但问题来了：你现在要花更多时间在测试上，确保各种情况都能跑得通。这比以前写代码本身更花时间。4、代码审查AI 写代码快，那审代码的人要看的东西当然就更多。人工看还是有必要的。但 AI 审代码也挺厉害的，能抓一些你没注意到的小问题。比如像 Coderabbit 这种工具，我自己就经常用。在提交代码前，我会在 Cursor 里让 AI 帮我审一遍。一次不够就多来几次，总能找到点问题。5、文档现在节奏快，没时间拉着几个人开半天会对齐。以前大家还会说“写自解释的代码”，不写文档也行。但现在 Claude、ChatGPT 这种工具，随便一句话就能帮你生成清晰的架构图和说明书。所以没理由再不写文档。你的每个项目都应该有：一份别人能看懂的说明和一份能让未来 AI 参与开发的背景资料。6、交付（迭代开发）传统项目管理都假设你是“做完 → 交付”。但现在 AI 让你一天能迭代五次。你跟产品经理在 v0 里画个初版，立刻就能改、能试、能看效果。所以，你需要一个真正的开发环境，随便试、随便改，快速看到结果。不是那种要等审批的预发布环境，是你可以随意玩的那种。7、总结未来厉害的开发者，不是那些“会提示 AI 写代码”的人。而是那些能：- 把别人模糊的需求讲清楚- 能测试得很全面- 能认真审查生成的代码- 能写清楚文档- 能快速做出新版本的人。因为代码已经快能自己写了，真正的工作都发生在代码之外。#科技先锋官##AI创造营##微博兴趣创作计划#

32. 不是「Vibe Coding」不行,而是你根本就不会写代码!