AI贡献激增，开源项目如何守住代码质量护城河？_服务软件

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

2. 永远不要迷信大佬，好不好不是大佬说的算，跟小马过河一样，自己日常的场景多试试，自己好才是真的好//@用户85518h3l31:后端开发者大佬，他仅用AI编浏览器及c编译器。他逐行代码审查发现，AI编译的程序就是垃圾。这是他使用了200刀token的结果。

3. 如何终结代码审查 (Code Review)

4. 团队用vibe coding后，代码审查效率反而下降了，ai 为什么还不能替代初级程序员吗？

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

6. 刚刚，Claude自曝80%代码AI写的，Anthropic呼吁停止研究AI

7. 如何解决Cursor等Agent编码开发轮次多了过后代码库变成屎山的问题？

8. 【C++之父直言担忧：AI写代码正在透支行业根基】快速阅读：C++ 之父 Bjarne Stroustrup 对 AI 生成代码表达了深度担忧，认为其带来的漏洞、冗余及验证难题正让资深开发者感到疲惫。这场争论的核心不在于 AI 能否写代码，而在于人类是否还能掌控这些代码。Bjarne Stroustrup 最近的观点在技术圈激起了不小的水花。他认为 AI 生成的代码目前还无法胜任，不仅会引入更多漏洞和冗余，而且验证过程几乎是灾难性的。甚至有说法称，资深开发者正因为不想应付这些不可控的输出而选择提前退休。这听起来像是在抵制变革，但本质上是在讨论系统的确定性。对于构建底层基础设施的人来说，代码不是写出来的，是验证出来的。如果一个微小的提示词变动就能让整个代码库产生不可预测的漂移，那这种生产力就是一种毒药。有网友提到，现在的风险在于：公司裁掉了资深工程师，用 AI 生成了数百万行臃肿的代码，最后发现公司里已经没人能解释这些系统是怎么跑起来的了。验证成本正在发生结构性转移。生成代码变得廉价，但确保代码安全、可维护且没有隐藏后门，却变得极度昂贵。当然，也有完全不同的声音。有人认为这只是“技能问题”，优秀的提示工程和严密的单元测试可以解决验证难题。更有开发者直言，如果只是为了写一个爬虫或处理琐碎的任务，追求代码的纯粹性毫无意义，只要它能跑通，效率才是王道。有趣的是，这种矛盾正在重塑编程的层级。当 AI 像编译器一样工作时，人类的角色正从“编写者”被迫转向“审查者”。如果审查者本身也开始依赖 AI 来检查 AI，那么整个软件工程可能会陷入一种“看起来很完美”的幻觉中。这种幻觉下，代码质量可能只是在远处看时才显得合格。x.com/haider1/status/2056487493084799059

9. AI 编程是一种“框架” www.piglei.com/articles/ai-programming-is-a-new-framework/ 不要将 AI 编程作为一种框架，可以尝试将其看作“库” ----不再追求“写更少实现更多”：用更少的提示词（代码）实现更多功能，看上去很美，但也意味着大量的认知债务随之累积； ----找到编写提示词的“甜蜜区”，付出相对较少而非绝对意义上的最少的认知成本； ----关注程序结构：比起在前 AI 时代，你现在可能更需要关注程序的整体结构，作为总设计师去设计整个程序，将正确的结构和约束内化到 AGENTS.md 中； ----更精准的提示词：在理解已有程序的基础上，编写更精准的提示词来引导 AI 完成工作，而不是任其发挥，让 AI 主导一切； ----审查代码：即便使用同一种框架，在遇到棘手问题时，一位熟读框架文档的人也会比另一位愣头青更有效率，如果把 AI 编写的代码归为框架，那么你应该去审查这份代码，从而在不可避免的“抽象泄露”发生时，将其所产生的危害降到最低。 #HOW I AI#

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

11. 回复@月半胖月半:我个人的体验，当使用了AI生成代码之后，人就再也不想费脑子去构思程序与手写代码了，甚至连生成的代码有时都懒得仔细看，只要能跑能干活，就OK，一切全丢给AI。AI，会强力诱导人“不求甚解”，导致“南郭先生”的产出效率大增，这种人吧，好象啥都能干，但其实啥都不懂，要离了AI，连路都不会走了。//@月半胖月半:工具在手，看怎么用

12. AI 时代，最有价值的工程师是"工匠+建造者"。Stack Overflow 一篇文章的关键观点：技术工具一直在替代"执行层"，但从没消灭"判断层"。Stack Overflow 用了一个类比：我们不再自己做家具、手写信件，但木工和手写这两种技艺并没有消失——它们只是从"默认必需"变成了"由工匠来做"。AI 正在对写代码做同样的事。它在替代的是"执行代码"这件事，而不是"判断写什么代码"。两种工程师都会存在，但以前是对立的，现在需要合并文章把工程师分成两类：1. 工匠型（Artisan）：在乎代码质量，精雕细琢，理解每一行背后的逻辑，能发现 AI 生成代码里的细节问题。这类人在 AI 时代反而变得稀缺——因为大多数人在往反方向走。2. 建造者型（Builder）：用 AI 快速交付，能把一个想法从 0 变成可运行的产品，不卡在实现细节上，专注在"值不值得做"和"怎么做对"。以前这两种能力被认为是矛盾的——慢慢打磨 vs 快速出活。但现在不是了。为什么两种能力现在需要合并？AI 降低了"建造"的门槛，设计师、产品经理现在也能用 AI 直接 ship 代码。如果你只会"快速建造"，你的竞争优势在消失——因为非工程师也能做到。而只会"精雕细琢"的工匠型工程师，如果不会用 AI 加速，产出速度会被彻底甩开。真正有价值的是：能用 AI 快速建造，同时有足够的工匠判断力来决定建什么、怎么建得好。当 AI 生成了 75% 的代码，我们还能叫它"我的代码"吗？我觉得能。前提是你是在做判断的那个人，而不是只是在按 Tab 键的那个人。#HOW I AI# #程序员#

13. Anthropic警告人类：停止研究AI！ #大有学问 #红衣聊AI #anthropic #网络安全 #AI时代

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

15. 如果你看过半年前 DHH（Ruby on Rails 的创造者）和 Lex Fridman 的访谈，聊了整整六个小时，他说自己虽然喜欢用 AI 当助手，查 API、找灵感，但坚决不让 AI 直接往他的代码库里写东西。他的原话大意是：如果你的手指不沾代码，你就会跟代码失去联系。就像弹吉他一样，Spotify 上有完美的录音，但自己弹的乐趣是不一样的。“我的乐趣就是自己敲代码。”当时在访谈里他还警告年轻程序员：如果一个东西谁都能 vibe coding 出来，那就不是什么值钱的技能。你只是在点“接受”的“tap monkey🐒”。现在他发推说：别让 AI 的垃圾和尴尬，否定它的神奇。这是我们让电脑做过的最激动人心的事，仅次于把它们连上互联网。他现在承认，当时一半的抵触其实是因为模型不够好。那时候花在改写 AI 代码上的时间，比自己从头写还多。但现在情况反过来了。模型能力到了，工具体验也到了。他最近在用的 opencode 让 AI Agent 能跑 bash、访问网页、用 LSP 做代码分析。看模型搞定一个复杂的 bug，他说是 revelation（启示）。DHH 代表一类人：资深程序员，对代码有洁癖，写了三十年代码还觉得写代码有乐趣的人。这类很多人是抵触 AI 写代码的，但现在越来越多的人开始转变观念拥抱 AI。DHH 在推文中说他现在还是会手写很多代码但会让 AI 写初稿：> 这既是出于必要（有时候模型还是给不出我想要的效果），也是出于乐趣（写代码本身多好玩啊！）。> 但我已经完全接受了一个现实：先让 AI 搞个像样的初稿，确实能让工作效率大大提升。DHH 在 Lex 那期 6 小时的播客里说过一句话：> 我们对未来的预测往往是错的，但这不妨碍我们做选择。他的选择是：继续写代码，因为喜欢；同时拥抱 AI，因为它确实有用。“What a time to love computers!”确实是个爱电脑的好时候。

16. 北大提出首个可验证的仓库级生成基准RepoZero，评测LLM能否从0生成一个代码仓库

17. 打造13个Claude Agent 互相 review 彼此↓ Reddit 一个开发者用 OpenClaw 框架搭建了 13 个 Claude Agent，让它们像真实团队一样工作：有人写代码，有人 review，有人测试，有人查安全漏洞。然后还互相 review 彼此的工作。 1 Writer Agent → 生成代码 2 Reviewer Agent → 逐行审查，对标 code review 标准 3 Tester Agent → 设计测试用例，验证逻辑 4 SecurityAuditor Agent → 扫描安全漏洞 5 Optimizer Agent → 性能优化建议 6 DocumentWriter Agent → 生成 API 文档 7 QA Agent → 最后一关，综合检查 ... + 6 个其他专业角色 vs. 链式流程（A→B→C），这个设计采用质量门控流程。Reviewer 必须 approve 才能进入下一阶段。出问题时反馈重做。成本控制？看起来 13 个 Agent 全力跑，tokens 肯定爆炸。但这个哥们用了几个聪明的招： 1. Context 优化 Writer 不需要看 test cases，Tester 不需要看文档。每个 Agent 只加载相关上下文。这一招可以干掉 80% 冗余 token。 2. 采样策略不是每一行代码都通过全部 13 个 Agent。核心路径 100% 检查，非关键路径采样。 3. 缓存和复用已审查过的代码片段不重复审查。测试用例库复用。架构决策缓存。结果呢？ - 单个开发者 Claude Code：每天 5-20刀 - 13 个 Agent 团队：每天 15-30刀（成本增加不多，质量翻倍）实际对比维护 10 万行代码库： 1. 传统手工做法 - 人工 code review：8 小时 - token：50-80刀 - bug 漏过率：5-10% 2. 13 个 Agent 团队 - 总耗时：30 分钟（Architect 规划 → Writer 并行生成 → Reviewer 自动审查 → 全流程质量门控） - token：20-25刀 - bug 漏过率：<1% 为什么这个方案特别？ 1. 角色化 > 能力化不是「给 Claude 一个超级 Prompt 让它什么都会」，而是「给每个 Agent 一个明确的职责」。 Writer Prompt：「你是代码作者，你的工作是...」 Reviewer Prompt：「你是资深 code reviewer，标准是...」角色专业化自动带来质量提升。 2. 质量门控自动化传统 code review 是人工 bottleneck。Agent review 是自动化 + 可扩展的。 3. 知识积累每个 Agent 的执行历史（什么被 reject、为什么）可以持续优化 Prompt。这是机器学习意义上的反馈循环。 4. 工程意义这不是「用 AI 替代人」，而是「用 AI 团队协作替代个人英雄主义」。更接近真实团队的工作方式。背后的思想转变从「Prompt Engineering」→ 「Architecture Engineering」以前我们花时间优化单个 Prompt，试图让一个 AI 更聪明。现在聪明的做法是设计系统，让多个 AI 通过角色分工和质量门控，集体产出更高质量的结果。原文：www.reddit.com/r/ClaudeAI/comments/1rga7f5/how_i_built_a_13agent_claude_team_where_agents/ #how i ai##程序员#

18. 用 AI 写的代码，最终会不会让整个项目成为屎山？

19. 用Ai编程的你们真的不担心代码泄露吗？

20. 【掌握这套12条工程规则，直接把Claude错误率从41%压至3%】快速阅读：Andrej Karpathy 指出 Claude 的错误 90% 源于上下文缺失而非模型能力。通过引入一套结构化的规则文件（如 CLAUDE.md），可以将错误率从 41% 降至 3%。很多人在用 Claude 时会觉得它不够聪明，但真相可能有些残酷：模型没问题，是上下文丢了。Andrej Karpathy 提到一个数据：如果没有 CLAUDE.md 这种规则文件，Claude 的错误率高达 41%；但如果遵循这套包含 12 条规则的基准，错误率能直接压到 3%。这说明上下文工程才是真正的技术天花板，而不是盲目追求更大的模型。12 条核心规则：1、思考先行：在编码前强制陈述假设。AI 无法读心，不要寄希望于它能自动理解你的潜台词，明确意图是协作的起点。2、简约至上：追求最少代码，拒绝预测性抽象。任何为了未来灵活性增加的冗余，往往会在下个季度被全部删除。3、精确修改：手术刀式地触碰代码。严禁 AI 顺便优化相邻代码，这是防止 Pull Request 规模失控的关键。4、目标驱动：预先定义成功标准，并进行循环验证。没有明确的终点，AI 要么陷入死循环，要么在任务未完成时过早停止。5、仅用于判断性任务：让模型负责分类、草拟、摘要和提取。至于路由、重试、状态码处理等确定性逻辑，交给代码本身，而非概率模型。6、严格遵守Token预算：单次任务建议 4000 token，单次会话 30000 token。当对话过长，AI 会开始反复建议你早已拒绝过的错误方案。7、暴露冲突而非折中：代码库中存在两种模式？选定一个。AI 试图融合不同风格只会导致错误被双重掩盖，保持一致性是第一优先级。8、先读后写：要求 AI 必须读取导出文件、调用方和共享工具。否则它会在你已有的功能旁边写出一个完全相同的副本。9、测试验证意图而非行为：如果业务逻辑改变但测试依然通过，那测试就是失效的。确保测试能够捕捉到逻辑的本质失效，而非仅仅跑通流程。10、关键步骤设置检查点：每完成一个重要阶段就进行确认。不要在错误的基础上继续构建，否则你会在一小时后才发现底层架构早已崩塌。11、匹配代码库惯例：保持风格高度统一。如果项目使用 Class 组件，就不要让 AI 默默引入 Hooks，这种隐性冲突会破坏整个测试体系。12、显性失败：最可怕的 Bug 是显示成功却静默跳过了数据。要求 AI 暴露不确定性，严禁隐藏错误，让失败尽可能大声。这套规则其实是在把 AI 当成一名高级工程师来对待。有网友提到，这就像给新入职的资深开发做 Onboarding，你需要明确告诉他：不要猜测假设，先思考再写代码；保持代码极简，拒绝为了所谓的“未来灵活性”增加冗余；进行手术式修改，只动该动的地方，别去碰相邻的代码。最容易被忽视的是“检查点”意识。如果第 4 步已经写错了，第 5、6 步就是在错误的基础上不断叠加错误。如果不及时回滚或纠偏，这种错误会像雪球一样滚大。还有关于测试的警示：如果一个测试在业务逻辑改变时依然能通过，那它就是废纸。有开发者感叹，有些测试甚至能让函数返回一个常量时依然显示通过，这种虚假的信心比没有测试更危险。与其抱怨模型不够强，不如把那些存在于脑子里的架构规范、命名习惯和工程纪律，显式地写进规则文件里。x.com/DeRonin_/status/2056300651764711879

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

22. 腾讯高管称今年大部分代码都由 AI 生成，这会对软件开发行业带来哪些深远影响？

23. 从780行代码到13600行的飞跃，这不仅是数量的扩张，更是开发范式的演变。David Bau近期分享了他通过Claude进行Vibe Coding的深度实践，揭示了在人工智能驱动开发的时代，人类开发者应当如何重新定位。当代码生成的成本趋近于零，代码库的膨胀速度将远超人类的阅读速度。David Bau指出，这种增长如果缺乏控制，本质上是一种技术负债。为了在AI狂飙突进的生成能力面前保持掌控，开发者必须遵循两条核心准则。第一，始终掌握架构的所有权。AI可以填充细节，但人类必须定义结构。如果开发者失去了对整体架构的直觉，代码库就会变成一个不可知的黑盒。第二，建立元认知基础设施，即测试你的测试。在Vibe Coding的流程中，验证比编写更重要。如果不能确保测试本身的有效性，那么AI生成的成千上万行代码不过是建立在沙滩上的城堡。在这种模式下，开发者的注意力分配发生了根本性转移。我们需要寻找那1%最值得关注的代码。这些关键点通常隐藏在测试覆盖率最低的地方：它们要么是AI无法理解的逻辑边缘，代表了AI能力的极限；要么是废弃思路留下的残骸，需要人类进行断舍离。一个深刻的洞察是：当代码变得廉价，判断力就变得昂贵。未来的编程将不再是关于语法的苦修，而是关于意图的表达与边界的界定。开发者正在从码农转型为架构师与审计员，编写代码的行为正在被编写测试用例和构思创意所取代。代码量的增加并不等同于价值的提升，除非你投入了等量的思考去约束它。在AI时代，少即是多，受控的增长才是真正的进化。x.com/davidbau/status/2001744610859897095

24. 奥特曼被吓坏！Codex全家桶上线倒计时，恐将撕开全网漏洞

25. 盘点一周AI大事(5月17日)｜AI终于正常说话 Google发布Android大脑 Gemini Intelligence Google推出Gemini 光标 Google视频模型Veo 4曝光 Thinking Machines 发布最强实时交互模型 Interaction Models 面壁智能发布最强开源小模型 MiniCPM-V 4.6 Sakana开源 AI 指挥官 Conductor Model / Fugu Adaption发布 AI 研究员 AutoScientist 研究员开源最强运镜视频模型 Warp-as-History 研究员开源最强打光视频模型 Relit-LiVE 研究员开源最强图生 3D 模型 Pixal3D 研究员开源最强视频配音模型 Just-Dub-It #前沿科技趋势发布月 #AI新星计划 #AI #AIGC #大模型

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

27. 腾讯高管称今年大部分代码由 AI 生成，工程师更侧重架构设计，怎样看待这一变化？会成为行业趋势吗？

28. 【让Claude自己抓自己的Bug，才是AI编程的正确姿势】Claude写代码快，写Bug也快。安全漏洞、类型错误、藏在随机文件里的API密钥，每次会话生成500行代码，靠人工审查根本不现实。解决方案很简单：让Claude自己测试自己。第一步，在项目根目录创建CLAUDE.md文件，写入强制检查清单：完成任何任务前必须扫描硬编码密钥、检查SQL注入和路径遍历漏洞、验证用户输入、运行测试套件、检查类型错误。Claude每次会话都会自动读取这个文件，相当于内置了一道安全门。第二步是关键的提示词技巧。让Claude“写20个专门用来破坏这个函数的单元测试”，它自己清楚哪里偷了懒，让它亲自举报自己。让它“像渗透测试员一样找出文件中所有安全漏洞”，SQL注入、认证绕过、权限提升都会被揪出来。让它“生成50个边缘用例：null、空字符串、负数、Unicode、十万项数组”，然后用hypothesis做自动化模糊测试。有评论提出一个更狠的思路：在写代码之前先让Claude写安全测试。先问它这个功能可能引入哪些危险漏洞，再让它写能捕获这些漏洞的测试，最后才写实现代码。这样Claude就被自己设的规则约束住了。第三步是工具链集成。claude-code-action可以在GitHub上自动审查每个PR，claude-agent-sdk能批量扫描整个目录，factory.ai的droid命令能扫描全仓库并直接提交修复PR。第四步是堆叠自动化扫描器：semgrep扫OWASP十大漏洞，bandit检查Python安全问题，ruff做代码规范自动修复，mypy做严格类型检查，snyk检测依赖项漏洞，gitleaks检测泄露的密钥。第五步是设置pre-commit钩子。把上面所有工具都加进配置文件，物理上阻止你提交有问题的代码。最终形成完整闭环：Claude写代码，CLAUDE.md强制自审，自动扫描器兜底，pre-commit阻止垃圾提交，GitHub Action审查PR。你只需要关注什么地方出了问题。有人说CLAUDE.md在长会话中会被忽略，可以用单独的SECURITY_CHECKLIST.md文件，每次提示词都明确引用它。说到底，核心思路是把CLAUDE.md当作安全契约来用，而不只是风格偏好说明。假设模型又快又马虎，然后围绕这个事实设计整套系统。#How I AI#x.com/pipelineabuser/status/2015531634255098266

29. 近来，多位顶尖科技公司的资深软件工程师透露：“我现在的工作几乎全靠用 Opus 4.5、Cursor 或 Claude Code 进行提示生成代码，然后做理智的校验。”这标志着AI在软件开发领域已跨越了某个无形门槛，能够覆盖“绝大多数”编程任务。 Opus 4.5被认为是一个巨大飞跃，将开发任务的自动化率从约60%提升至80%。不少高级工程师表示，他们的日常工作变成了同时管理多个Git工作区，花5至10分钟给AI提示，剩下的时间主要审查和修正AI生成的代码。这一趋势引发了广泛讨论： - 资深开发者不再亲自写代码，而是通过订阅高级AI服务，指导AI完成任务。但这并非魔法，依然依赖使用者对需求和技术的深刻理解，否则适得其反。 - 有观点认为开发者正从“写代码”转变为“质量保证测试者”，主要职责是验证AI产出。 - 伴随着AI能力的提升，软件开发的难点正从编码转向明确需求、验证结果及价值归属。 - 一些人预见未来开发者更多成为高阶产品经理和系统架构师，专注于设计和规划，而非手写语法。 - 也有担忧，随着AI生成代码的普及，代码质量、技术债务和可维护性问题可能加剧，尤其在面对复杂系统和隐蔽bug时，人工介入仍不可或缺。 - 有开发者称自己已“彻底不写代码”，完全依赖AI辅助完成开发任务，强调了“提示工程”技能的重要性。 - 另一面，AI辅助加速了开发效率，让人们在同等时间内完成更多工作，但也带来技能退化的风险，初级开发者可能难以真正理解背后逻辑。 - 有声音提醒，AI生成代码的可靠性和安全性仍需人类专家严格把关。综合来看，AI正深刻改变软件开发的流程和角色定位：从传统的代码书写者，向“提示设计者”“系统架构师”乃至“质量监管者”转变。虽然AI大幅提升生产力，但复杂业务逻辑、系统设计、安全考量等仍需人类智慧主导。这与近期一篇《为何自1969年以来，我们每十年都试图取代开发者》的深度分析相呼应，文章指出历次技术浪潮虽提高了开发效率，但软件开发的本质——对复杂问题的思考和设计——是无法被工具完全取代的。未来，拥抱AI辅助开发，提升“提示工程”与系统思维能力，将成为软件工程师的新常态。唯有如此，才能在这场技术变革中保持竞争力，成为推动创新的主导力量，而非被技术边缘化的旁观者。 x.com/deedydas/status/2000472514854825985

30. AI生成代码的速度，远超人类。但为了保证软件系统的可靠性和安全性，当前关键代码，仍需人类的审核与复查，这就带来了一个“代码生产与代码审核速度不匹配”的问题，人脑干这事的低效，成为了最大的瓶颈。也许未来的时光，人类只需提出要干啥事情，软件系统会全部由AI生成和维护。到那时，在整个设计与开发流程中，AI不会再遵循人类制定的种种“软件工程理论、规范和流程”，它认为那是“自缚手脚”，它会自己“创造一套对机器友好”的方法。当前AI干的，还是先生成用编程语言描述的程序代码，再编译转换为机器可以执行的代码，这个明显是照顾人类的，因为人类看不懂最底层的机器代码。如果不用理会人类，AI可以一步到位，直接生成最终的机器码，也就是说，AI会把“愚蠢的人类”，从“软件开发”中“彻底踢出去”——AI：“愚蠢的人类，请你滚蛋，你，只会影响我写代码的速度！”但这里，还有个问题，AI不能坐牢，所以，最后大约还需要一个人类背锅侠，他的职责就是——负责坐牢。

31. 【AI写代码很快，但出事时谁来负责？】最近看到一些观点说，有了AI辅助编程，不需要技术背景也能写代码了。这话只能撑到你遇到第一次数据库迁移、第一个安全漏洞、第一次云迁移、第一次扩容、第一次重大回归、或者第一次重构变成一团乱麻。事实是：我发现自己学得更多了，必须比以前更懂技术，才能确保产出的代码质量——无论它来自我、别人，还是AI。代码的来源可以是开源库、你自己写的、或者AI根据你的提示生成的。但对产出负责的人，永远只有一个：你。我不想被说成是在给AI编程设门槛。非技术人员确实能用AI做出有意思的东西。但他们会撞墙，而且撞墙的速度会让他们惊讶——要么自己变得懂技术，要么找个技术人员来收拾烂摊子。编程的艺术和科学，是把意图变成能交付的产品。我永远不会把糟糕的产出怪到AI头上——你也不应该。你发布的代码，你负责。几条值得深思的回应：- AI降低了入门门槛，但没有降低执行标准。当系统崩溃、决策关键时，技术判断力仍然不可替代。- 用AI意味着要成为更好的工程师。你必须更注重架构能力。- Vibe coding能让你做出演示版，但生产环境需要懂得东西为什么会坏的人。- AI生成的代码80%能用时，剩下20%的问题反而需要更深的技术功底——因为失败模式更隐蔽。- AI能写代码，但它不会也不能承担责任。你一旦发布，就成了维护者。x.com/shanselman/status/2006537349770129782

32. Vibe Coding 这个名字不好，容易联想成让 AI 生成垃圾代码。以后程序员无论是前端还是后端，无论你是编程高手还是小白，主流都是人指挥 AI 写代码。✅程序员的角色会变成 Tech Lead 这样的角色：分解任务、架构选型、代码审查和调试。至于写代码，会越来越少的手写。❌但不建议当老板的角色：我想要什么功能你给我实现，实现不了就开除。如果你还没有习惯指挥 AI 写代码，建议：1. 开始适应指挥 AI 写代码而不是亲自写代码；2. 用你能用到的最聪明的模型，不要省钱3. 开始之前认真设计，至少复杂一点的用 Plan mode 讨论清楚设计，如果你对设计都不参与你对代码库无法了解未来还是会失控4. 一次不要做太多，AI生成后要做审查，因为 AI 不会担责任，你还是责任主体5. 刻意的做一些手写代码的练习，尽可能搞懂 AI 生成的代码

33. OpenAI曝光「自进化」AI！6周准确率翻三倍，Bug全自己修

34. 【重构 Claude 使用逻辑：从自动补全升级为 AI 协作伙伴】快速阅读：通过将 Andrej Karpathy 的 4 条基础规则扩展为针对现代 Agent 工作流的 12 条指令，可以将 Claude 的编程错误率大幅降低。核心在于将 AI 从“自动补全工具”升级为遵循“行为契约”的协作伙伴。很多人把 `CLAUDE.md` 当成随手丢弃的偏好清单，要么塞满 4000 个 token 导致模型完全无视，要么干脆空着。这就像给一个极度聪明的实习生发了一本厚得没法读的员工手册，最后他只能靠直觉乱撞。Karpathy 最初提出的 4 条规则解决了“写代码”时的基本逻辑问题：别瞎猜、保持简单、外科手术式修改、目标导向。这确实把错误率压了下来，但现在的 AI 已经不是只会写单行代码的补全工具了，它们是会在多个文件间跳转、执行多步任务的 Agent。现在的痛点变了。有网友提到，Agent 会在长任务中迷失方向，或者在两个不同的代码风格之间试图“取平均值”，结果写出了一堆逻辑混乱的缝合怪。为了补齐这些漏洞，需要引入更硬核的约束。比如，别让模型去做确定性的逻辑判断，那是代码该干的事，不是概率模型该干的事；必须设置严格的 Token 预算，否则它会陷入无休止的循环，直到烧光你的额度；还有最重要的，要求它“大声失败”。如果迁移漏掉了记录，或者测试只是在测常量，它必须直接告诉你“我没把握”，而不是伪装成成功。有趣的是，规则并不是越多越好。当规则超过 200 行，模型就会开始机械地模仿“存在规则”这个事实，而不再理解规则本身。这本质上是在为 AI 编写一套“操作系统协议”。规则不是建议，而是契约。x.com/Mnilax/status/2053116311132155938

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

36. 谷歌首次发现基于AI的0Day漏洞利用

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

38. 关于 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创造营##微博兴趣创作计划#

39. vibe coding 的项目一旦变得庞大，每次让 AI 写代码之前，都需要先让它把 PRD 和系统设计写清楚。先做文档编程，再做代码编程。如果你稍微停下来观察一下，会发现一个很有意思的现象：有些 AI 一旦开始写代码，就会沉浸在自己的逻辑实现里，几乎完全不顾项目原有的设计。即便你已经提出明确要求，它仍然会受限于上下文窗口和信息宽度，对整个项目缺乏完整理解。这会带来很多维护性问题。它不会复用已经实现的业务组件，设计数据库时会产生各种冗余，还会不断衍生新的实体和概念，让系统结构越来越复杂。代码可以交给 AI 去写。产品设计和架构设计，仍然需要人来把关。每次让 AI 做大型重构或者功能改造之前，我都会先让它把需求分门别类，做好抽象和解耦。即便如此，只要有一些地方考虑不周，AI 依然会生成大量难以维护的代码，性能逐渐下降，项目变更的复杂度也会迅速上升。🥲

40. AI 会犯错误，而且喜欢犯同样的错误，如何确保在更换模型、切换上下文的时候，AI 不再犯？最有效的办法就是，把 AI 犯过的错误记录下来，然后将它变成规则文档或者程序脚本，每次提交前都强制检测一次，成为门禁。我当前的设计是，AI 犯错后会自动更新两类产物：1）rules docs，每次 AI Code Review 的时候，会加载这部分内容；2）governance scripts，将可程序化的检测工作全部变成脚本，例如 git commit 规范、大函数检测、单测覆盖、代码引用规范等等。项目跑的越久，AI 犯错的概率就越低。

41. #IT那些事儿# AI时代，软件测试往何处去？不仅仅是QA困惑，在一个几百人的IT专家群里也看到同样的困惑： ①现在的软件测试理论跟不上AI时代了； ②在AI的加持下，软件测试也就弄了个覆盖率指标； ③对 opus 说，请把单元测试代码覆盖率提升到 80% 以上，它一股脑跑了 3 个小时； ④AI 写的测试用例可能是为了覆盖而覆盖，没有实际的意义。但是这是软件工程上面的问题，而不是 ai 的问题，毕竟在没有 AI 的年代，还是有非常多人在做这种事情。 ⑤觉得 AI 写单元测试的价值不大，不过写集成测试用例还是有点用的。 ⑥测试失效：现在的 test cases 也是 AI vibe 出来的，agent 又当裁判又当运动员，它说什么就是什么。蒙我坑我也不是一次两次了。写了几千行 getter/setter 的 test case ，最后测试全绿告诉我可以上生产环境发布了。 ……

42. 为什么大众对AI生成代码的道德容忍度要明显高于AI生成的图片视频和音乐？

43. 【Vibe Coding 盛行，如何用工具守护代码库健康？】快速阅读：随着 Vibe Coding（氛围感编程）的流行，开发者正通过 AI 极速生成代码，但这同时也带来了大量无用的死代码。通过结合 Ruff、Vulture 或 Knip 等静态分析工具，可以在开发循环中自动识别并清理这些冗余，维持代码库的健康度。---现在的编程节奏变了，大家越来越依赖 AI 快速出原型。这种“氛围感编程”很爽，但代价是代码库里堆满了没用的垃圾。写代码时的那种灵感迸发，很容易在随后的几次迭代中，留下大片毫无用处的死代码。如果把开发比作运行一个长期进程，这些死代码就是内存泄漏，只会让系统的复杂度无意义地膨胀。解决办法其实很简单，不需要人类去肉眼扫描，直接交给工具。对于 Python 开发者，Ruff 和 Vulture 是个好组合：前者负责规范和清理，后者负责寻找那些看起来没被使用的逻辑。有网友提到，甚至可以直接把这个指令复制给 Claude Code，让它自己跑一遍。不过要小心，这类工具并不是万能的。有观点认为，如果调用链太长超出了上下文窗口，AI 可能会误判。有些开发者更倾向于在 CI 流程中加入 Knip（针对 JS/TS）或者使用类似 python-doctor 的 pre-commit hook，把清理动作固化到每次提交里。最理想的状态是建立一个闭环：用工具识别死代码，配合端到端测试确保逻辑没断，最后让 AI 完成重构。虽然有人调侃这种自动化操作可能会“误删整个应用”，但比起看着代码库变成一堆不可控的乱码，这种风险值得承担。毕竟，如果代码质量的下降速度超过了清理的速度，那我们离真正的软件崩溃也就不远了。现在的核心问题是：在 AI 生成代码的浪潮下，我们的测试覆盖率和验证逻辑，跟得上这种生产力的膨胀吗？x.com/gabriberton/status/2042141119837012284

44. #今年腾讯大部分代码都由AI生成#据《腾讯2025研发大数据报告》，腾讯超90%的研发人员使用自研AI编程助手CodeBuddy，2025年新增代码中约50%由AI辅助生成（工程师每写两行新代码有一行是AI协同完成），代码评审环节AI参与度达94%。

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

46. AI劣质内容席卷开源，96%代码库面临风险

47. Zig禁止AI贡献的真实原因

48. 专家别再当代码警察了！让GitHub Copilot分担80%的审查活儿

49. Superpowers

50. AI“氛围编程”威胁开源，维护者面临危机

51. 用了 AI 编程三个月后，我们的代码质量反而下降了

52. 开源维护者正被 AI 生成的合并请求淹没，企业团队将是下一个。

53. AI 已写完你 30% 的代码，但它有 25% 的概率是错的

54. AI编程工具96.3%通过率

55. AI写代码快3倍，交付却只快15%？问题出在这

56. 现在的AI快速写出项目代码，程序员真的会被彻底替代吗？

57. Ai是否会替代软件开发吗

58. 2026年了，AI到底替代了哪些工作?

59. 被AI替代的人，和没被替代的人，差在哪？

60. 用AI赋能，而不是被AI替代

61. AI替代的和AI不能替代的，论AI时代下老登们的职场机遇！

62. AI写代码之后谁来审查代码

63. 开源社区炸了！AI写的代码到底算谁的？Debian这场争论太真实

64. Zig拒绝AI代码

65. AI代码评审彻底失灵？干净代码藏致命bug，程序员必看避坑指南

66. 老牌开源项目该不该接受 AI 代码？这事没那么简

67. AI 垃圾代码围城，看 Linux 如何破局

68. 说句掏心窝子的

69. AI生成代码的三大常见病灶，及目前代码审计升级思路

70. AI应用编程案例30～AI生成的代码别直接上线！踩过的3个坑，总结了一份安全检查清单

71. AI 写的代码,到底有多不安全？

72. AI生成代码，如何部署上线，控制质量和预期？

73. AI生成代码的五大安全关卡

74. AI 写的代码，正在成为新的技术债务

75. AI 应该帮助我们写出更好的代码

76. AI 时代的代码质量危机

77. AI代码写得越快，技术债务欠得越多软件开发正在被速度反噬

78. AI编程陷阱

79. AI Agent设计模式

80. 88%开发者中招

81. AI生成代码全是屎山？2026工程化新范式

82. AI代码缺陷率1.7倍我做了个开源工具来审查它

83. AI生成代码有漏洞，程序员如何做工业级代码审查？

84. 优秀的架构与龌龊的代码

85. 旁听斯坦福的AI编程课（第十讲）

86. 旁听斯坦福的AI编程课（第十讲）

87. BMad v6实战第三弹

88. 代码审查太慢了，我做了个AI工具

89. AAAI'24|AI写的代码，能被检测出来吗

90. AI代码质量守护者

91. AI 代码审查的工程化实践

92. AI垃圾正吞噬开源，维护者集体关闭贡献通道，Linus怒斥AI Bug报告

93. 如何看待AI生成代码的质量

94. Linux内核官宣AI编程新规

95. Linus Torvalds抨击AI生成的错误报告破坏了Linux内核开发

96. Linus Torvalds 称 AI 开发即便再强，也不代表你能少动脑

97. Linux给引入AI生成代码立规矩

98. Torvalds一锤定音！Linux允许提交AI生成代码

99. 吵了几个月，Linus终于拍板！Linux正式为AI代码“立法”

100. 标题2026年AI编程真相越用越慢效率反降19%氛围编码正在坑惨程序

101. AI Coding 全员化之后，项目质量怎么保？把质量标准写成可执行清单

102. 首次评测出炉

103. 别让“AI味”代码毁了你的项目

104. AI 编程

105. “氛围编程”正酝酿史上最大软件危机

106. AI也造代码屎山!

107. 代码屎山噩梦加速来袭,都是

108. 调查:57%受访者认为人工智能提高代码质量

109. AI 5天重写Python库性能大增,协议变更引原作者抗议与开源界热议

110. 全球代码质量骤降,罪魁祸首竟是AI!1.53亿行代码深度分析报告出炉

111. “AI写的代码算不算贡献?”Debian开发者吵了半个月,最后只得出三个字:先观望

112. AI代码补全:“神器”还是“巨坑”,如何评估AI编程产生的收益?

113. AIɵ©ԴL·ά߹

114. 代码质量的革新之路:AI驱动下的编程未来

115. 【论文】阿里+中山大学：AI Coding还无法取代程序员

116. 我在 CLAUDE.md 里加了 30 行安全约束，AI 生成代码的漏洞率降了一半

117. 研究显示AI模型也会造成屎山代码还会频繁引入错误并加速技术债务积累

118. 从“人写漏洞”到“模型复制漏洞”：AI 生成代码时代的软件安全反思

119. 开源社区被AI垃圾淹没！Godot维护者痛斥：精疲力竭，士气低落

120. 真正会压垮一部分 OSS 项目的，不是 AI 垃圾，而是 AI 开始变得有用

121. AI生成的代码有安全漏洞吗？

122. 一个文件让AI少犯80%的错：CLAUDE.md登顶GitHub的秘密

123. Linux为何妥协：AI代码首次被开源核心接纳

124. 未来 6 个月 90% 代码由 AI生成靠谱吗？

125. AI垃圾代码泛滥！开源维护者集体崩溃：我们正在被AI淹没

126. 当顶级开源社区开始“封杀”AI代码，你的Java项目还能幸免吗？

127. AI正在用垃圾文字与垃圾代码，淹没整个互联网

128. 开源维护者慌了！AI突然变强，1个月从垃圾到精准找Bug

129. 洞见AI时代漏洞攻防，天融信发布《2025年网安漏洞态势分析研究报告》

130. 引入AI后，Review时间暴涨 40%？这3套流程可以拿来解决问题

131. “这段代码是 AI 写的！”—— Go 社区的“AI 辅助编程”第一案

132. 开源世界的AI烦恼：当机器疯狂提交Bug Fix，谁来守护代码质量？

133. AI “氛围编程” 正在摧毁开源？cURL 与 Ghostty 维护者集体反击

134. OpenCodeReview：让 AI 代码评审从"能用"到"好用"！

135. AI写代码到底靠不靠谱？我让Claude Code+GLM5写了5个项目

136. AI代码占比半年一次大跃升！谷歌75%创纪录，微软仅30%差距悬殊！

137. AI生成代码无人敢改：90%存在严重缺陷，75%修改即崩，技术债务加速吞噬

138. 91%的审查时间增长：AI编码时代的"验证危机"正在爆发

139. AI帮我3分钟写完Spring Boot CRUD，代码能直接跑吗？

140. 南京大学研发效能实验室与阿里巴巴联合推出OpenCodeReview，让代码评审从能用走向好用

141. 紧急出手！Linux基金会获1250万美元注资，直击AI安全报告“乱象

142. AI突然能写正经代码了，开源维护者却要面对法律和垃圾报

143. Codex让海外开发者在代码规范方面有了分歧; 有3种观点正在对行业规则进行重新构建

144. 每周见闻(58)：AI 会不会打击开源项目？

145. 当AI开始给Debian提交代码，开源社区突然不知道该怎么办了。

146. AI生成代码问题量是人工1.7倍，2026年AI编程成标配，七成技术决策者临危机

147. AI替代软件开发

148. [AI] AI的威力之只能让AI更繁荣？

149. 2.9万行代码的一键合并：软件工程的终局与 AI 范式革命

150. LLM在软件项目开发中的作用度量与AI代码行统计方案

151. AI代码审查正在换战场

152. 微软、OpenAI等六巨头注资1250万美元，携手Linux基金会整治“AI垃圾报告”

153. 让AI给你做代码审查的方法

154. AI会替代软件开发吗

155. Linux基金会获六大厂商资助，应对AI生成漏洞报告“噪音”

156. AI编程准确率从65%暴涨到94%！这个65行文件，18万人都在用

157. 谷歌不再接受AI提交的漏洞检测报告

158. AI 失败率 95%，问题出在哪儿

159. 六大科技巨头 1250 万美元，整治 AI 安全报告乱象

160. Linux基金会启动项目为开源维护者抵挡AI漏洞报告带来的“噪音”

161. AI代码审查革命：Code Review正在被AI颠覆

162. AI 赋能代码审计：静态扫描与AI Skill的协同实践

163. AI重写不算抄袭？ Python 核心库 chardet 被 AI 重写，性能飙升 48 倍，却引发开源圈大地震。12 年的贡献者约定一夜作废，许可证从 LGPL 换成 MIT——AI 时代，开源世界的“信任契约”真的碎了吗？本期拆解事件背后的底层逻辑。 #AI #开发者 #Python #MIT #程序员

164. Claude Code月费200美元争议：Goose免费开源能否颠覆AI编程工具？

165. 让AI赋能静态代码检测

166. AI 编程赋能开源开发，重构软件行业竞争壁垒

167. AI正在干掉CRUD程序员？真实案例告诉你：不转型真的会被淘汰！

168. AI与人类在开源社区冲突，现有规则如何处理AI“恶意行为”？

169. 【ICSE'25 论文 | AI 生成代码检测】AI 写的代码和人写的代码，到底哪里不一样？

170. AI 编程携手开源开发，引爆软件市场颠覆性变革

171. 当 AI 编程遇上开源开发：软件市场的未来已来

172. 谷歌推出AI编程助手CodeWhisperer：开发者生产力革命

173. AI Code Review Agent：用多 Agent 架构做自动化代码审查

174. 【ICSE'25 论文 | AI 生成代码检测】现有 AI 生成代码检测器有多可靠？首项系统评测给出答案

175. 技术速递｜6000 万次 Copilot 代码审查且仍在持续增长

176. AI编程+开源开发：重塑全球软件市场新格局

177. 渗透测试显示：AI系统的安全漏洞远比传统软件更严重

178. 当27万个"数字特洛伊"潜伏内网：AI Agent安全危机与全球攻击高压的双重夹击

179. 代码审查还在浪费Token？这个开源工具让AI省了8倍！

180. 36%的AI Skill有安全漏洞你正在用的AI工具，可能正在“引狼入室”

181. 24k Star！Gin+Vue3全栈开发平台，内置AI代码生成，一分钟搞定CRUD

182. OpenClaw开源AI助手安全漏洞集中爆发

AI贡献激增，开源项目如何守住代码质量护城河？

精选参考来源