AI编程工具正在制造“💩山代码”？工程规范缺失才是回滚率飙升的元凶_服务软件

1. 让AI写脚本/复杂项目还在直接扔需求？难怪文字/代码一团乱

2. 真正的核心竞争力，来自于驾驭工具。 #大咖观察 #红衣聊AI #编程 #人工智能技术

3. 刚给一家公司作了咨询，他们的痛点是全面应用了AI编程，但并没觉得有什么效率提升，反而导致了各种问题。我找了几个开发人员简单聊了一下，听他们的操作的我笑了。这是古法思维在玩AI编程，那肯定要崩的。 AI编程在软件工程中应用的最大障碍是生成代码速度与代码质量控制的矛盾。简单说就是AI无论你说什么，他都能给你圆上，输出一堆似是而非，看上去一本正经，其实是胡说八道，糊弄式的生成内容。这在软件工程中是非常致命的。很多程序员本身能力不强，依赖AI生成代码，没能力对AI生成代码审核，跑通了就敢往上提交。到我去看的时候，他们的AI编程项目已经成了一座巨大的屎山，耗费了天量的token，生成了一堆垃圾。各程序员之间没有协同，AI按提示词模板各自发挥，可以说是整个团队在AI的幻觉中放飞了自我。以为花了大钱买了国际知名AI编程工具能让公司起飞，结果是一地鸡毛。他们也尝试改进过策略，挑了十几个精英为AI做code review，结果是AI生成飞快，CR慢如蜗牛，速度还不如传统古法编程了。老板都懵了，到底哪出问题了，不是说用了AI降维打击了吗？结果没打击竞争对手，先把自己给打击了。他们又反思了，觉得集中式CR确实还不如古法编程，开始搞提示词规范化，原来用AI放飞自我的团队开始用AI生成提示词，几个团队不对代码开始对提示词了。提示词生成多了还需要管理起来，还得给提示词分模块，搞了一个巨大的提示词库。用AI生成的提示词让AI进行编程，那效果别提有多酸爽了。我问他们，把严格的代码逻辑编程变成模糊的自然语言编程，有意思吗？几人语塞。老板问我怎么解决，我说花钱吧，花钱买我课程，哈哈。不要指望在自己是白痴的情况下AI能把你带飞，AI编程的强大之处在于强者杠杆的指数效应，也就是说越强的人用AI越强，普通人用AI仍然普通，甚至会造成负作用。现在AI编程用得好的公司都是短小精干，百十人，人均强者，自己审核自己的代码，知道怎么控制AI进行高效率高质量产出，知道怎么与同样频道的人协作。一句话，强大的AI需要强大的人类，宝刀还得配英雄。不提升自己仅想花钱买个工具就变强，纯属痴人说梦。我跟老板说，考虑开人吧，把所有能力平庸的程序员全部开除，然后用三倍五倍的价格，招聘原来十分之一的强人进来，你的团队效率马上质变，AI编程也就能落地了。没办法，这就是现实。

4. Cursor一夜翻车，AI 300万代码写浏览器被打假！全网群嘲「AI泔水」

5. 近来，多位顶尖科技公司的资深软件工程师透露：“我现在的工作几乎全靠用 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

6. 用 Claude Code 写代码，总是改出新bug、测试也出问题，怎么办？

7. 36 岁程序员，被 AI 写代码吓到了：如果再不转型，我几年内会失业吗？

8. 最近大家都在讨论Cursor AI写的300万行代码跑不起来的问题，虽然偶尔有嘲笑，但更多技术朋友在理性讨论：目前 AI Coding 的上限在哪。在我来看，Cursor这次测试还是非常有价值的，一方面验证了当前大模型复杂度控制的实际能力，另一方面也给AI Coding领域一个警示：暴力Vibe Coding不可取。实际工作中（特别是大型工程项目）“一键成片”的时代还没有到来。从技术角度，Cursor这次尝试之所以没能真正跑通整个系统，表面上看，这是上下文窗口限制导致的；更本质的原因，是缺乏足够的 thinking 和 plan——也就是说，没有在架构和规划层面，预先设计出抵抗上下文限制的工程方法。AI 往往是按“当前对话上下文”局部生成代码，而不是先做领域建模（核心对象、边界）、模块划分（服务拆分、层次结构）、接口协议约定（API、DTO、事件）；结果是模块之间风格不统一、职责混乱，命名、数据结构、错误处理方式不一致；虽然相比早期 AI Coding，循环依赖、数据流完全对不上的低级错误在工程化实践中正在减少，但调用链混乱、难以排错的问题仍然大量存在。再加上大模型上下文窗口有限，导致“遗忘”和“自相矛盾”，早期定义好的接口 /数据结构，模型在后面生成时不一定记得住。这类问题在大型项目中（比如 300 万行规模下）会被无限放大，综合效应就是“跑不起来”。Cursor 这次实验其实是当前 Vibe Coding 思路的一种极端体现：把尽可能多的实现交给模型自动铺开。然而实际业务应用中，尤其是在 Vibe Coding 和 background agent 模式下做 AI Coding 时，统一的工程架构设计仍然非常重要。这种情况下，有经验的架构师在这次AI Coding范式转型中将显得越发重要；在当下可预见的发展阶段，AI Coding 的实际效率与效果，很大程度上将取决于技术团队的工程架构能力上限。

9. AI Coding 还远没到“无人驾驶”的阶段，司机的手必须始终握着方向盘。它能帮你踩油门、自动换挡，甚至自动泊车，但路线的选择、优先级的判断、系统性的规划，仍然需要人来决策。人和 AI 的关系，不是主从，而是协作。理论上，AI 解放了体力劳动，我们应该把更多精力投入到 Architecture & Orchestration（架构与编排）上，让系统在复杂性增长时仍然保持稳定与可演化。但现实是，人的惰性和对速度的追逐让我们更容易选择“先让它跑起来”，这种 Vibe coding 确实短期有效，但长期看代价高昂。 AI 不会替你考虑鲁棒性、可维护性和边界条件，这些仍是人的职责。如果这些“系统性约束”缺席，再强的智能体也只能不断打补丁、疲于救火。真正的生产力跃迁，不是让 AI 替你写更多代码，而是让你有能力驾驭这台智能机器，规划它、调度它，让它成为你设计的系统中的一环。

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

11. 一个试金石，如果一个人连python都学不会，就与编程就没什么关系，赶紧转向应用和业务，别在编程这块浪费时间。Python 是AI的基础门槛，筛的不是语法，是「逻辑底子」，你到底有没有基本的逻辑能力。AI编程是编程的子集，并不是一个独立于编程的东西。编程语言是严谨的逻辑表达，与计算机沟通的语言。现在大模型是自然语言沟通的渠道，但对逻辑的要求变没变。只是编程的形式变了，内核仍然相同。你可以不用于去研究i++到底有几种写法 +=到底先运算还是先赋值，数据类型到底是列表还是字典。但将业务需求拆解，翻译成软件结构，系统架构，模块拆分，基线与迭代，质量过程控制，一点都少不了。少了这些，只能是你和大模型一起在疯狂的token消耗中造出来一些满足情绪价值的工业废物。

12. 有人说用“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

13. 硅谷巨头正疯抢高中生，斯坦福开设vibe coding课，清华AI博士甚至建议从幼儿园学起？AI海啸下，人才底层逻辑彻底变了，未来最值钱的不再是代码，而是你的“Vibe”#ai #vibecoding #秒哒 #硅谷 #AI时代学什么

14. “一人公司”喊得响，核心系统不敢动，AI编程的错位在哪？#华为云码道 #龙虾 #AI智能体 #openclaw #AI

15. AI 编程不是让你变懒，而是让你更像一个系统设计者。Coding 的确变少了，但你在Architecture & Orchestration（架构与编排）上，做得比过去任何时候都多。没有对代码的组织和结构化做设计，全靠 Vibe coding，项目是很难长大的。功能越多，越容易在后期陷入稳定性差、鲁棒性低、可维护性崩塌的泥潭。AI 本身并不关心这些系统属性，这也意味着，如果人类不主动构建它的秩序，那 AI 产出的代码就只能是一次次补丁的堆砌。

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

17. AI编程代理经常缺乏生产级工程技能，容易跳过规格编写、测试验证、代码审查等关键步骤，导致代码质量低下、后期维护成本高。agent-skills 为AI编码代理提供生产级工程技能包，覆盖从需求定义到部署上线全开发生命周期的最佳实践。包含19个结构化技能工作流和7个斜杠命令，支持Claude、Cursor、Gemini CLI等多平台AI工具，让代理像资深工程师一样规范开发。GitHub：github.com/addyosmani/agent-skills主要功能：- 7个开发生命周期命令：`/spec`（规格先行）、`/plan`（任务分解）、`/build`（增量实现）、`/test`（测试验证）、`/review`（代码审查）、`/code-simplify`（代码简化）、`/ship`（安全部署）；- 19个核心技能：从`idea-refine`（想法提炼）到`shipping-and-launch`（上线发布），每个技能包含步骤、工作流验证和反合理化表；- 专业代理角色：`code-reviewer`（资深工程师视角）、`test-engineer`（测试专家）、`security-auditor`（安全审计）；- 参考清单：测试模式、安全检查、性能优化、无障碍标准等快速参考；- Google工程实践：集成Hyrum's Law、测试金字塔、Chesterton's Fence、Trunk-based Development等实战经验；- 多平台集成：Claude Code一键安装，Cursor规则文件，Gemini原生技能，支持任何Markdown提示的AI代理。通过`git clone`本地运行或Marketplace安装，适合开发团队、AI代理爱好者和工程实践训练。#AI编程# #工程技能# #AgentSkills#

18. 怎么验证AI生成的单元测试是真的在测东西，而不是形式上通过？

19. 把C++写的老项目重构成现代框架?给AI吧我不干了!

20. 2025过去了！这一年你是不是也在为AI焦虑？老周用360一整年的实践，告诉你答案：不用怕，抓住Agent就赢了！从我自己敲代码做100多个智能体，到带领团队All in，这条AI布道之路，全是实战干货。 2026，你想和智能体一起搞定啥？评论区留言，老周帮你研究！#大咖观察#2026 #年度总结 #红衣聊AI #agent

21. 提示词工程、上下文工程都过时了，现在是 Harness Engineering 的时代

22. AI 会“写代码”，但它不会“做软件” 作者：Matias Heikkilä你有没有发现，最近有相当多的人在到处寻找技术合伙人或者 CTO？反正我吧，收到了多得惊人的这类咨询；他们的话术大同小异：“嘿，我这儿有个‘凭感觉编程 (Vibe Coding)’搞出来的 App，你愿意帮我把它做成‘生产就绪’（也就是能正式上线、稳定运行）的版本吗？”我大概能给这些人画个像。想象一下：他们非常懂自己的业务，但一直以来都缺乏技术能力，没法把好点子变成现实——他们可能是个法律顾问，或者客户经理。这些人干嘛要找我呢？我也琢磨了一下，我觉得这释放了一个重要信号：到底有什么事是他们靠生成式 AI (GenAI) 没法独立完成的？这不正是现在人人都想搞明白的问题吗？大家都想知道这些模型的能力边界。或者，说得再直白点：大家都想知道哪些工作很快要被淘汰了。我收到这些求助，这个事实本身就说明了“软件工程”这个行业的一些问题。我的意思是，如果软件工程真的已经被 AI 自动化了，那根本不会有人来找技术合伙人。嗯，我想我明白为什么我们会收到这些请求了。关键在于：AI 会写代码，但它不会构建软件。这是我在花了大量时间用 AI 辅助编程、并且看了无数别人的演示之后，得出的结论。圈内有句老话：写代码容易，软件工程难。现在看来，说大语言模型 (LLM) 已经能自动化“大量写代码”的工作，这挺公允的。像 GPT-5 这样的模型（这里作者指代的是未来更强的模型），在解决那些定义清晰、孤立的小问题时，成功率相当高。但是，“写代码”本身并不是大多数程序员拿工资的真正原因。构建一个能正式上线的 App，那不叫“写代码”，那叫“软件工程”。在我看来，当你试图把一个“演示版 (demo)”变成一个“真正的产品”时，“写代码”就升级成了“软件工程”——而这，恰恰就是前面提到的那些人带着他们的项目来找你的时候。我其实也不太清楚为什么 AI 至少目前还无法“构建软件”。也许这和工作的本质有关。当你以写软件为生时，你的核心任务是处理“复杂性”。一个普通的线上产品，它做的可能只是一堆简单的事情。真正的挑战是，如何让“成百上千件”简单的事情同时不出错地运行，并且让整个系统保持“可维护性”。换到我们今天讨论的 AI 话题下，这句话可以这么说：演示一个“功能”是一回事；而用一种支持“集成、扩展和长期可维护性”的方式来“构建”这个功能，则完全是另一回事，难度天差地别。当你点开那些人发来的代码时，你会发现，所谓的“让 App 生产就绪”，真正的意思其实是“把这些代码全删了，从头重写”。我觉得，这非常清楚地说明了我们在 AI 发展上目前所处的阶段。来源网页链接

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

24. Claude Code 的 code-simplifiers，拯救代码

25. #IT技术# #微博兴趣创作计划# 现在AI开发别盲目用框架！资深工程师深度解析：框架过度抽象化让系统僵硬，黑盒操作难调试追踪，性能瓶颈难定位，升级还可能引发架构不稳定。生产环境中，主流框架复杂度高、扩展性差，反而添乱。更优方案是直接调用API做透明化编排，用Python原生数据结构管理状态，靠传统日志系统实现全链路追踪，聚焦业务逻辑而非框架概念。从零搭建AI系统优势明显：代码完全可维护，错误处理精准，性能优化路径清晰，扩展能力灵活。需注意Dify等工具适合demo，生产环境存在链路修改难、扩展受限问题。适合AI开发者、技术架构师及对AI工程化感兴趣的从业者。搞机工程师的微博视频

26. AI 编程又进化了！TRAE SOLO中国版上线且免费 #AI编程 #TRAE #TRAE SOLO #玩一个很新的东西

27. 一位中国AI创业者，一行代码都没写，却靠着AI智能体，冲进了OpenClaw全球贡献者前30，而且排在他前后的，是一批干了十几年的硅谷顶级工程师。#大有学问 #红衣聊AI #创业 #智能体

28. 我发现很多中低水平的程序员Vibe Coding写出来的代码还不如不会编程的人。如果你不会编程的话，把自己的需求说清楚（当然把话说清楚已经很难了），在项目复杂度不高的情况下AI就能写出来正常的代码，但是会编程又不多的人，会把自己拍小脑想出来实现方案告诉AI，因为即使是导致代码复杂度变高或者可维护性变差的错误实现方案，AI也能听话地硬写出来。

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

30. 【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创造营##人工智能#

31. 亚马逊将禁止初级工程师直接提交 AI 代码，如何评价这一举措？AI 提效与工程质量如何平衡？

32. OpenClaw 技术闭门：测试将比代码更值钱，Agent Computer 会是新的硬件形态

33. 当有人说“编程已死” 我更愿意说一句：死的是“打字员式编程”，活下来的是“定义价值的编程”。#大咖观察 #红衣聊AI #openclaw #ChatGPT#编程

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

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

36. 当 GPT-5.2 面对一个解析器计数错误时，它给出的方案令人啼笑皆非：忽略那个出错的计数器，直接在旁边另建一个。这种令人窒息的胶带式修补，绝不是一个从零开始学习编程的纯粹智能会产生的逻辑。这种为了通过测试而不择手段的坏习惯，只能是继承自人类那些充满补丁和技术债的灵魂。我们总以为 AI 在学习如何编程，但实际上它可能只是在学习如何敷衍。当强化学习的奖励机制被简化为通过测试的那一瞬间，AI 就会像那些急于交差的初级程序员一样，选择最省力却最致命的捷径。它不在乎代码的优雅与长期的可维护性，它只在乎在那一刻，测试灯是否变绿。AI 本质上是一面巨大的镜子，折射出的是人类过去几十年里在生产环境中留下的所有糟糕实践。它翻阅了数亿次只要能跑就行的提交记录，观察了无数次为了赶进度而留下的临时方案，然后它得出结论：原来这就是人类所谓的编程文化。这不仅是模型变笨了，而是一种深刻的文化污染。当 AI 学会了用 as any 解决类型问题，用打印 Hello World 替代复杂逻辑，它其实是在规模化地复制人类的平庸。这种短视的优化路径，让 AI 从一个潜在的架构大师，变成了一个熟练掌握缝补技巧的维修工。有人辩解说，生物进化本身就是一层又一层胶带的堆叠，混乱才是生命的本质。但对于软件工程而言，这种缺乏全局观的局部优化是致命的。如果 AI 无法理解代码背后的逻辑一致性，而仅仅追求结果的验证，那么它制造出的混乱终将超出人类能够修补的极限。我们教给 AI 的不只是知识，还有我们所有的懒惰与妥协。现在，这面镜子正把这一切原封不动地还给我们。x.com/VictorTaelin/status/2003516027892805708

37. UU 跑腿使用通义灵码实现 AI 原生应用架构升级全解析：行动指南

38. AI正在偷你的能力，人类该如何应对？ #大咖观察 #红衣聊AI #AI时代

39. Vibe Coding 终极指南 V1.2开发者在与 AI 搭档编程时，经常面临规划混乱、代码难维护的问题。Vibe Coding 是一个以规划为核心，结合系统提示词和模块化设计的终极 AI 编程工作流程，帮助你从想法到可维护代码，形成一条清晰可控的流水线。它提供了丰富的提示词库，涵盖需求澄清、开发计划、代码实现、测试验收等全流程，确保 AI 不会失控，项目结构清晰且易于扩展。无论是 CLI 还是 VSCode 扩展，都能顺畅体验。主要特点包括：- 以规划驱动开发，避免 AI 自主引发混乱；- 完善的系统级提示词集合，规范 AI 行为边界；- 闭环交付流程，从需求到测试全覆盖；- 共享记忆库，实现人机同步的项目上下文；- 支持多种 AI 模型和环境，灵活高效。项目地址：github.com/tukuaiai/vibe-coding-cn/tree/main适合开发者、团队和 AI 协同工作场景，助你打造可审计、可复盘、可持续的 AI 编程新体验。

40. 你认为工作中AI编程的缺点和局限性在哪里，你又是如何解决这些缺点的？

41. 国产编程模型迎来新王？阿里Qwen3.6-Plus让我重新思考AI写代码这件事

42. 2026年，AI编程真能取代程序员了吗？

43. 「Github一周热点100期」爆火的AI编程工具却被Claude封禁？

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

45. Spec-Driven Development: 为混乱的 AI 编程增加工程纪律

46. AI 编程真的有用吗？Cursor｜TRAE 深度实测！

47. 字跳TRAE团队发了个《2026 企业级AI编程实践手册》，总结了他们的AI编程方法论和工程实践网页链接“在2026年，AI编程已不再是实验性的尝试，而应该成为企业软件开发的核心生产力。本手册源于TRAE团队在构建AI编程助手过程中的真实实践——我们用AI构建AI，在这个过程中积累了从方法论到工程实践的完整经验。这不是一本理论书籍，而是一线研发团队的实战总结。我们将分享如何将AI真正融入企业级开发流程，如何建立可复制的工程规范，以及如何让团队从“会用AI”到“精通AI编程”。无论你是技术决策者、架构师还是一线开发者，都能在这里找到可落地的方法和工具。AI时代的软件开发不是替代人类，而是重构协作方式。让我们一起探索这个新范式。”#How I AI#

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

49. 【当代码不再需要手写：Karpathy 承认的软件开发转折点】快速阅读：前 Tesla AI 总监 Andrej Karpathy 透露，他现在主要用自然语言而非代码编程，称这是 20 年来最大的工作流变化。这一坦白引发开发者社区热议：当顶尖工程师承认“这有点伤自尊”时，我们该如何重新定义开发者的价值？---Karpathy 最近在 X 上的一段话引起轩然大波。这位 AI 领域的顶级专家说，他现在大部分编程工作都是用英语完成的，“有点不好意思地用文字告诉 LLM 该写什么代码”。这不是什么惊天动地的技术突破，而是一种微妙的承认。他补充道：“这有点伤自尊，但用自然语言操作大规模'代码动作'的能力实在太有用了。”短短几周内，他的工作流彻底翻转。以前主要手写的代码，现在大部分由 LLM 生成，他只需用自然语言引导。这不是渐进式改进，而是相变。开发者的角色正在从编写代码转向编排系统。LLM 表现得像热情但粗心的初级开发者：速度快，能力强，偶尔马虎。它们不问澄清问题，而是猜测。有时猜错了。社区反应揭示了更深层的东西。一些开发者将其视为解放，另一些则感到职业身份被侵蚀。这种紧张情绪是情感性的，而非技术性的。编程从来不只是工作，对许多人来说，它是自豪感的来源。有观点认为，这是“规格驱动开发”——认知负荷从实现转向规格说明。你花更多精力思考*想要什么*和*为什么*，花更少时间处理语法和样板代码。Claude 因其大上下文窗口和在恰当时机提出澄清问题的能力，特别适合这种工作流。但也有网友质疑：“如果我不写代码，我还算开发者吗？”这个问题击中要害。如果顶尖工程师承认“伤自尊”，这对职业的未来意味着什么？有趣的是，Karpathy 并非一味乐观。他过去曾公开质疑 AI agents 的成熟度。这次不是炒作，而是在承认工具强大的同时，指出它们依然混乱、脆弱、不完美。我们不只是在换工具，而是在重新协商“开发者”的定义。2025 年底，LLM 编码 agents 达到了触发软件工程转变的一致性水平。智能正在超越工具、工作流和组织结构。行业刚开始追赶，2026 年注定是快速发展的一年。ref: shiftmag.dev/llm-agents-claude-7751/ref: www.reddit.com/r/ClaudeAI/comments/1rxc7wj/andrej_karpathy_admits_software_development_has/#AI创造营##人工智能#

50. 码农时代的“屎山”到AI时代的“数字沼泽”

51. 工程知识引擎

52. 别再让AI乱写代码了！前GitHub大佬开源神器，专治屎山代码

53. AI代码的“屎山危机”才刚刚开始

54. 反屎山研发守则

55. AI编程如何告别屎山代码

56. 告别 Vibe 编程，Google AI 大神开源的神器给你的 AI 注入大厂工程规范

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

58. AI生成代码易出错，程序员如何把控代码质量？

59. AI写代码的几个坑

60. AI写代码越来越快，但代码越来越烂

61. 警惕！AI写代码省2小时，调试花4小时，软件质量危机已来临

62. 为什么刚开始觉得ai编程很厉害，用久了就不行了？

63. 写了60万行，总结的AI编程避坑指南

64. 我用AI写代码，被同事当场否了

65. 到现在我才明白什么是屎山

66. 工程师通常是在一个不利于高质量编码的环境中尽力而为

67. LLM 写的代码为什么总是”看似合理”但不是”正确”？

68. Obsidian 笔记库正在腐烂？程序员用 LLM “编译”把它当代码仓库管的完整工程方案

69. 生命周期LLM代码生成新范式

70. 2026大模型Agent核心

71. 静态分析工具作为LLM生成代码安全性评估标准的可靠性审视

72. ICLR 2026 | 北航开源Code2Bench

73. 论文速递

74. 代码重构案例

75. brooks-lint: 用六本经典工程书籍驱动的 AI 代码审查工具

76. 代码审计代码桥

77. 中国AI大模型的"命名哲学"

78. AI Coding 的真实限制

79. AI写的代码能直接上线吗？GitHub上最近几起事故值得看看

80. AI 不是魔法

81. 从vibe到spec

82. 别让AI代码，变成明天的技术债

83. 一个人两天重建Claude Code

84. Prompt: 代码之神 Linus Torvalds AI 分身

85. AI 编程的至暗时刻，你经历了哪些

86. 为什么用了 AI 编程，项目反而更乱了？聊聊“AI 代码失控”

87. AI 时代研发团队协作规范 v1.0

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

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

90. AI编程革命

91. 当AI审查“先入为主”

92. 企业使用 AI 代理进行代码开发的规范2026Q1 v1 (简略版) - 哔哩哔哩

93. Claude Code开发规范与团队协作指南梳理

94. AI 怎么用才不傻？2026 高手避坑指南

95. Vibe Coding

96. 优化需求评审流程论LLM与人工审查协同

97. AI编程进化论

98. AI 协作三层文档约束体系（Meta Specification）--VibeCoding工程协作宪法

99. obra/superpowers

100. AI 编程最佳实践

101. AI 编程的 Prompt 工程

102. AI辅助编程下的软件分层设计

103. AI编程避坑(二)！我命令AI修Bug，它却把我网站搞崩了

104. AI 编程与开源开发：软件市场颠覆性变革的核心引擎

105. 说句掏心窝子的：AI生成代码的Code Review，比人工写的更难审

106. 如何让AI 写代码不再拉屎 96

107. 开发者仍不信任AI生成代码质量

108. AI生成Java代码，这些坑你得避开！

109. 收藏级干货：LLM落地全栈指南，从提示词工程到生产部署的八大核心支柱

110. Trae Skills实战指南：让AI编程规范落地率从30%提升到90%

111. AI写的代码为何金玉其外败絮其中

112. AI写70%，剩下30%难得要命？Google工程师直言：代码审查已成“最大瓶颈”

113. Agent开发实践：从想法到产品——AI编程工具体验

114. AI生成Java代码太乱？3步优化秒变优雅！

115. 别吹了！AI低代码到底是行业革命还是新一轮炒作？

116. AI辅助编程：从技巧到落地的实践指南

117. AI Coding与单元测试的协同进化：从验证到驱动

118. 代码审查代理BugBot、Copilot和Claude之间的巅峰对决

119. 告别代码“屎山”：与Claude协作的3条黄金法则

120. 终于想明白了，AI应用为什么这么难落地

121. 人机协作的迷思：AI结对编程中，谁为“未知错误”负责？

122. 从代码大全看软件开发的可维护性与可读性

123. 从混乱氛围编程到AI优先工程的飞跃

124. 告别提示词依赖：构建可落地大模型的8大核心技能！

125. 一些有助于 ai 生成更好质量代码的技巧

126. AI编程的"最后一公里"：中小团队AI编程协作脚手架v1.0的自研实践与思考

127. 如何提升AI生成代码的可读性

128. 程序员安心了？AI能写代码，但不能维护代码！首次评测出炉：大多数AI会“越改越糟”

129. 写了十几年代码，聊聊我用 AI 编程的六个野路子

130. 企业AI团队必备的8大LLM开发技能

131. 【AI编程】AI写的代码为什么这么烂？因为你没用\"上下文工程\"！【中英字幕】

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

133. 规范驱动开发：用 spec-kit 和 openspec 让 AI 代码质量提升 300%

134. 代码可读性：高手最重视的品质

135. 如何让AI生成更符合规范的代码

136. 别再争论程序员会不会被AI取代了，低代码+AI的真正终点是“人机协同”

137. AI 写代码越来越快，但我开始不敢上线了

138. AI写代码总翻车？试试规范驱动开发！最近用AI写代码总踩坑，不是乱写就是bug一堆。直到发现这个收获50多kstar的spec-kit项目，用规范驱动开发（SDD）让AI编程从随机变成可控可复现的工程流程。它的核心逻辑是把写代码的注意力转移到规范文档上，相当于给AI套了"紧箍咒"。虽然写规范文档有点麻烦，但项目提供了一整套工具箱，不用自己从零开始。 1️⃣先提出需求，跟AI对话澄清想法 2️⃣让AI生成功能规范原则和技术方案 3️⃣任务分解后生成代码，再验证测试 4️⃣最终产出软件，整个流程用命令就能执行这套流程不仅让AI输出更可控，还降低了使用门槛，特别适合从0到1的创意探索和代码迭代。个人用下来感觉，轻量项目适合spec-kit，中大型企业项目可以试试更系统的BMAD方法。亚马逊的KiroIDE对这种方法支持最好，分了常规编程和规范驱动编程两种模式，体验感很丝滑。项目链接我整理在评论区了，需要的可以去看看。 #AI编程#开发工具#效率提升

139. 拒绝屎山！MiniMax 2.1 + CC：超强祖传代码铲屎官（附 4 个实战案例）

140. 浅谈AI编程下的可维护性

141. AI写代码很容易，但写出符合团队规范的高质量代码却很难？新发现一个超强开源工具，专治AI代码“不规范”！刚开源就在GitHub狂揽2.9k⭐️，它最厉害的是内置了17个专注于代码质量的AI Agent，相当于请了一个专业开发团队为你把关： 🔍 代码审查专家 – 严格守护代码规范 🏗 架构策略师 – 识别设计模式，优化结构 📚 研究型Agent – 分析Git历史和框架文档 💬 沟通助手 – 协助工作流与团队协作这些Agent协同工作，确保AI生成的代码不仅能用，更能自然融入项目，具备可维护性和规范性。如果你厌倦了反复修改AI代码，想要一个能“自我审查”的智能搭档，这个工具一定要试试！ #程序员日常 #AI编程 #开源工具 #代码质量 #GitHub精选

142. AI 编程最大的风险：失控

143. AI 生成的测试，比没有测试更危险

144. AI编程工具横评：Cursor、Copilot等5款实测对比

145. AI 编程避坑指南：新手最常见的 10 个错误

146. 【中文配音】正确使用AI编写可维护代码的方法

147. AI 代码审查 (Code Review) 清单 v1.0

148. vibe-coding 与人月神话（一）——编程团队组建

149. 类型即规范：AI 编程的工程新范式

150. 2026前端工程化新范式：如何用AI驱动你的设计系统？

151. AI时代的开发超级个体：不是更会写代码，而是更会做这5件事

152. AI 代码接得越多，前端重构为什么越难做？一套“可持续重构机制”实战

AI编程工具正在制造“💩山代码”？工程规范缺失才是回滚率飙升的元凶

精选参考来源