6.0
关注
AI SCORE
观点评论2026-07-28 17:36
理解优于溯源：重新思考 AI 代码的价值
DEV Community · Adam - The Developer ✨#AI代码#最佳实践
Editor brief · 编辑速览
反思开发社区对 AI 生成代码的过度关注来源问题，强调深入理解代码逻辑比纠结出处更实用。
反思开发社区对 AI 生成代码的过度关注来源问题，强调深入理解代码逻辑比纠结出处更实用。
把关行为正在伤害 AI 辅助创作者
许多开发者社区都问错了问题。
这并不是说他们不该担心低投入、低质量的作品，而是他们采用的筛选标准，根本无法区分持续维护的工程项目与批量生成的垃圾。它只能按照创作过程中使用了哪些工具来划分项目。
想象一下：你想分享一项真正引以为傲的作品，AI 在其中提供了协助，但创意属于你。结果，你的作品却被标记、拒绝或埋没，评论区充斥着“这根本不是你做的”和“我讨厌现在到处都是 AI 项目”之类的话。说这些话的人肯定觉得自己正义凛然，相信自己是在抵御低投入的垃圾内容。
但实际上，他们抵制的根本不是这种东西。他们抵制的只是一个标签。
我读了 @madsendev 关于 Open Vectorizer 的文章。Madsen 希望把这个项目分享给更多人，也期待有人愿意参与贡献。
显然，在那些把筛选标准简化成一个二元问题的把关者眼中，“AI-generated”与“持续维护的工程项目”之间的差别已经消失了。
“用了 AI，还是没用 AI？”（他们没有真的这么问，但实际采用的就是这种筛选标准。）
原因在这里：想象两个项目。
项目 A：有人花了两年时间重新设计一套矢量化算法，研究 machine learning 能否改进它，最后决定不使用 machine learning，转而实现确定性方案。他发现自己的 benchmark 数据被高估了，仍然修复了问题；随后发布了可复现的结果，并持续积极维护代码。
项目 B：有人在 AI prompt 中输入“帮我做一个音乐流媒体应用”，不经测试就把生成出来的东西直接发布，然后从此消失。
两个项目都使用了 AI，也都被贴上了“AI-generated”的标签。其中一个理应出现在开发者社区里，另一个才是社区真正应该过滤掉的东西。
猜猜哪个会被拒绝？没错，两个都会被拒绝。最幸运的情况，也不过是晚一点被拒绝，因为把关者正忙着和你争论，并把自己的社区名称改成：“我怀念那个用穿孔卡片编程、嘴里叼着烟的年代。”啊，没错，身份认同危机。
乍看之下，把关者的论点似乎很合理，但它存在一些实际问题：
直接否定：“不，这不是你做的”（来自 @deammer）。要给出这种回应，就必须无视真正发生过的技术工作。Madsen 重写了整套算法 pipeline，用成熟工具进行对比测试，还发现了一个让自己 benchmark 看起来更漂亮的 bug，并修复了它，最终如实发布了更差的数据。这可不是有人随手给 Claude 扔了一个 prompt，然后就宣布大功告成。
更广泛的担忧：@blakebeckcoding 指出了一个真实存在的问题——未经审查的 AI-generated code 已经引入过安全漏洞。这确实是对可维护性与责任归属的合理担忧。但问题在于，有人把这种担忧当成充分理由，在评估技术价值之前，就拒绝所有 AI-assisted 项目。对低质量代码的担忧是合理的，但“根据工具选择直接拒绝”这种启发式标准，并不能真正解决问题。
换个角度想：我们不会因为 Rust 更容易实现 memory safety，就拒绝所有 Rust package；也不会因为 C 可能产生 memory error，就认定所有 C 项目都不安全。编程语言的选择会影响出现问题的概率，却不能决定项目质量。AI 也是如此。
怀旧叙事：“Dev.to 以前多好啊”（还是同一个人，你知道是谁，这哥们儿纯粹是在怀旧）。这种说法假设，在 AI 工具出现之前，开发者社区的质量更高。但从 20 世纪 80 年代起，人类就在发布糟糕的代码。垃圾内容泛滥一直都是问题，并不新鲜；AI 只是让制造垃圾内容变得更容易、更便宜了。
开发者社区正在被大量内容淹没，但问题并不特指 AI-generated 项目，而是一切低投入的项目。正如我前面所说，由于 AI 降低了制造这类项目的成本，洪水正在以惊人的速度上涨。
那么，解决办法是什么？
不是“封禁所有使用 AI 的项目”。
真正的解决办法，是理解究竟什么因素能够区分信号与噪声：
维护者能解释系统架构吗？还是听起来像在照念 Stack Overflow？
项目是否具备有意义的测试？
项目声称的结果能否由他人独立复现？
benchmark 是否透明？
是否公开披露了项目的弱点？
维护者是否真的会审查变更并承担责任？
六个月后，这个项目还会有人维护吗？还是说，它只是一次性的实验室试验？
这些问题同样适用于完全由人类编写的代码。而验证这些问题的成本很高，需要真正去阅读、思考和判断。
“使用 AI 了吗？”这个问题很便宜。只需勾选一个复选框，看起来还很有原则，moderator 也能迅速处理下一个项目。
“这是一个持续维护的工程项目吗？”则要求你真正深入了解这项工作。
在评论区中，@unitbuilds 对这一切给出了最明智的看法：
“软件开发是一种编排过程，最终价值来自能够运行、经过审计并接受测试的软件，而不只是人类花在敲键盘上的时间。”
“如果你只会留下这种评论，那就去 X 加入那里的粪坑吧，或者去 Reddit，他们会喜欢你的。请让 Dev.to 继续成为一个对所有开发者都安全的空间。”
听起来很痛快，对吧？这并不是在抽象地为 AI 辩护，而是在捍卫社区之所以为社区的根本：这里应该是人们能够分享作品、获得反馈的地方，而不是根据使用了什么工具来接受纯洁性审查的地方。
那个在全职工作之余，使用 99% AI 发布了一款 3,000 行代码游戏的人，有资格分享自己的成果。使用 GitHub Copilot 完成常规代码补全的人也一样。Open Vectorizer 的作者借助 AI 做出架构决策，但绝不会发布自己无法解释的东西，他当然同样有资格分享。
他们都不应该仅仅因为一个完全无法反映作品质量的标签而遭到否定。
这件事看似与主题无关，其实并非如此：软件开发一直都是这样演进的。
我们从 assembly 走向 C 时，没有人说：“你使用 compiler，所以不算真正写过代码。”我们从手动内存管理走向 garbage collection，从原始 SQL 走向 ORM，从手写 Dockerfile 走向使用模板，从复制粘贴 Stack Overflow 的答案，走向 IDE refactoring，再走向 GitHub Copilot autocomplete。
每一步都提高了抽象层级。每一步也都引发了担忧：开发者是不是变懒了？标准是不是降低了？这门手艺是不是被稀释了？
但每一次，真正重要的问题都不是“你使用了什么抽象层级”，而是：“你理解生成出来的东西吗？你能为它辩护吗？你会维护它吗？”
这一直都是真正的标准。
AI 只是这条演进路线上的下一步。它更激进、更显眼，也能以更快的速度生成更多平庸内容。但从根本上说，它与其他工具并无不同：开发者可以把重复性的机械劳动交给工具，把精力集中在真正重要的决策上。
问题并不在于是否应该接受 AI。
简而言之，自第一门 high-level programming language 诞生以来，就一直有人宣称软件开发已经死了……只不过是同一种焦虑循环，一遍又一遍地重复上演。
不，这并不是要“彻底打开闸门”，而是要弄清楚你真正想过滤的是什么。
良好的内容审核应该：
糟糕的内容审核，正是现在发生的这些事情：
DEV 转向要求披露 AI 使用情况，而不是禁止 AI-assisted 内容，这是很好的变化。它要求创作者承担诚实披露的责任，然后让社区根据实际作品做出判断。
@unitbuilds 说得没错：开发者社区的职责，是让人们分享作品并获得有实质内容的反馈，而不是审查他们采用了什么方法。
区分优秀工程与垃圾项目的问题其实很直接：
你能解释自己的架构决策吗？
什么东西出过问题？你是怎么修复的？
benchmark 可以复现吗？
你会继续维护这个项目吗？
你愿意接受纠正吗？
无论代码是由人类输入、Claude 生成，还是二者混合完成，这些问题都同样有效。因为它们关注的是理解与责任，而这两点一直都是决定质量的关键。
工程项目应该根据理解程度、正确性、可维护性、测试和责任担当来评估，而不是根据敲了多少次键盘。
部分评论可能只有登录后的访客才能看到。请登录以查看全部评论。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。