36氪「屎山 / AI 代码质量」专题收录

收录两篇 36 氪关于 AI 编程“屎山”问题的文章，并整理其核心观点、可引用论断与合并观察，聚焦 Vibe Coding 带来的质量危机，以及 AI 自审/工程护栏作为可能解法。

36氪「屎山 / AI 代码质量」专题收录

36氪「屎山 / AI 代码质量」专题收录

收录时间：2026-05-29 来源：36氪转载文章

1) AI代码的“屎山危机”才刚刚开始

• 链接：https://36kr.com/p/3747601311220228
• 原文标题：AI代码的“屎山危机”才刚刚开始
• 原始来源：腾讯科技
• 抓取方式：Jina Reader 转 Markdown

核心要点

• 文章主线：Vibe Coding 大幅降低了做出可运行软件的门槛，但同时把安全、测试、维护、代码审查的成本外部化给了平台、用户和开源维护者。
• 一个关键判断是：不会写代码不是最大问题，真正稀缺的是架构设计、安全审计、边界条件处理和长期维护能力。
• 文章引用多个案例说明 AI 生成应用存在严重安全问题，包括数据库裸奔、密钥泄露和隐私数据暴露。
• 它还指出 QA、审核和开源维护正在承受“垃圾代码洪水”：应用商店审核变慢，开源社区被低质量 PR 和假漏洞报告淹没。
• 对“AI 提升开发效率”的乐观叙事，文中保持怀疑：部分实验显示，资深开发者在真实仓库里使用 AI 后，完成任务反而更慢，但主观感受却误以为更快。
• 结论很硬：AI 可以替代打字，但替代不了判断；代码生成成本趋近于零后，人类审查成本反而变得更关键。

可引用观点

• “软件开发的难度从来不只在‘写出能运行的代码’。”
• “AI可以替代打字，但无法替代判断。”

2) AI可以自审代码了，Opus 4.7出手解决“屎山”

• 链接：https://36kr.com/p/3770168317358593
• 原文标题：AI可以自审代码了，Opus 4.7出手解决“屎山”
• 原始来源：字母AI
• 抓取方式：Jina Reader 转 Markdown

核心要点

• 文章把 Opus 4.7 定位成“更强但更克制”的模型：重点不只是性能提升，而是把安全护栏、权限管理和代码自审能力一起产品化。
• 性能叙事主要落在高级软件工程任务、指令遵循、多模态界面理解、跨任务整合和文件系统记忆上。
• 文中尤其强调两个和“屎山治理”直接相关的点：
  • auto mode：在“别烦我”和“别乱来”之间做权限平衡；
  • /ultrareview：让 AI 不只写代码，也开始参与审代码、挑 bug、看设计问题。
• 文章的核心态度是：AI 编程正在从“帮你生成代码”进入“参与完整工程流程”的第二阶段，真正稀缺的是验证、审查、纠错与风险控制。
• 另一条暗线是商业模型变化：表面单价不变，但因 tokenizer、思考强度、多轮 agent 执行等因素，真实总成本可能上升；不过如果首次正确率更高，总任务成本未必更贵。
• 文章认为 Anthropic 的差异化不只是“更强”，而是把“克制发布”“能力分级”“高风险能力限流”本身做成产品策略。

可引用观点

• “AI写代码已经不稀奇，真正稀缺的是AI能不能审自己的代码。”
• “有时候‘不做什么’比‘能做什么’更重要。”

合并观察

• 第一篇讲的是问题：AI 降低生成门槛后，垃圾代码、漏洞、低质量 PR、审核负担一起上升。
• 第二篇讲的是一类解法：让模型不只负责生成，还要负责审查、验证、权限控制和风险分级。
• 两篇放在一起看，能形成一个清晰框架：
  • 低门槛生成 = 屎山加速器；
  • 审查 / 验证 / 护栏 / 记忆 = 试图对冲屎山的工程化补丁；
  • 真正瓶颈仍然不是“会不会生成”，而是“谁来负责质量判断”。

备注

• 这两篇都适合归到“AI 编程 / Vibe Coding / 代码质量 / Agent 工程化”主题下。
• 如果你要，我下一步可以继续把 36氪 / 腾讯科技 / 字母AI 这一条线再扩成一个更完整的“AI 编程屎山观察”专题包。