Ask HN：为什么 HN 群体如此反对 AI？
文章摘要
发问者是一位有 20 多年经验的软件工程师，他困惑于 HN 上为何频繁出现对 AI 生成代码的批评声音。他的核心论点是：用户在意的是产品能否正常工作，而不是代码是否优雅。
他进一步主张，AI 辅助开发的交付速度可以比手写代码快上 10 倍，而从长远看，执行速度最终比代码质量更重要。他以 Claude Code 为例，认为这类工具能让开发者基于真实世界的反馈快速迭代。
这个略带挑衅意味的提问，引出了 HN 社区（包括版主在内）对「AI 是否真的不受欢迎」以及「代码质量到底有多重要」的多角度讨论。
HN 评论精华
dang（版主）：指出社区只是单纯地存在分歧，这一点在所有争议性话题上都是一致的。HN 并非特别反 AI——支持派和反对派都觉得对方占了上风。当前首页上那个「oh shit 时刻」的帖子正体现了对 AI 的正面情绪。社会本身就对 AI 充满分歧，HN 不过是反映了这一宏观趋势。
_0ffh：认为个体内部本身就是矛盾的。他支持机器学习，但也认识到 LLM 在业余项目之外常常写出有问题的代码。恰当的引导有助于隔离模块，但失败仍时有发生。在生产环境中搞「氛围编程」（vibe coding）潜在地是不道德的，因为存在数据泄露的风险。
thierrydamiba：点出了一个令人不适的现实——许多人花了多年学习的技能，如今任何人都能通过一句提示词获得，这给相关讨论带来了无法回避的张力。
rootusrootus：不认同「学会语法是革命性的」这一观点。一个有动力的高中生也能写出还过得去的代码。这恰恰说明开发者做的远不止写代码——真正的价值在于语法之外的技能深度。
majormajor：每天使用 Claude 确实带来了约 20%-40% 的生产力提升，但代码混乱的代码库会越来越难被 agent 改进。结构良好的代码配合得更好；而设计糟糕的项目积累技术债的速度更快。
josephg：一位资深用户发现，Claude 在处理独立、自包含的任务时表现出色，但在大规模系统设计上很弱。项目会随时间积累糟糕的设计选择。模型在「小处」表现优异，却缺乏构建可维护系统所需的宏观架构推理能力。