/*
免责声明：
本文不包含、不支持、也不意图传播任何形式的歧视、偏见、污名化、刻板印象或排斥性表达，包括但不限于基于以下因素的歧视：年龄、出生年份、代际身份、性别、性别特征、性别认同、性别表达、性取向、性身份、婚恋状态、婚姻状况、生育状况、孕产状态、家庭结构、亲属关系、照护责任、种族、人种、民族、族裔、部落、血统、出身、姓氏、种姓、肤色、国籍、公民身份、移民身份、难民身份、户籍、籍贯、地域、城乡背景、语言、方言、口音、宗教、信仰、无宗教信仰、哲学观点、政治立场、思想观念、文化背景、教育程度、学校背景、专业背景、学历、学位、经验水平、职业、职级、就业状态、收入水平、财产状况、社会阶层、社会经济地位、家庭背景、体型、身高、体重、外貌、容貌、发型、穿着、身体特征、有形或无形残疾、身体能力、精神健康状况、神经多样性、认知能力、学习能力、疾病史、遗传特征、医疗状况、成瘾康复经历、服役身份、退役身份、犯罪记录、司法经历、居住状况、住房状态、生活方式、饮食习惯、技术能力、表达能力、社交能力、个人身份、个人经历或任何其他先天、后天、真实、被认为具有或被错误归因的身份与特征。
本文中出现的所有人物、组织、机构、项目、产品、代码、对话、观点、案例、情节、事件、场景、地点、时间线、因果关系及相关细节均为虚构或经抽象化、改写化处理，不指向任何特定现实个人、团体、单位、项目或事件。如与现实中的人物、经历、组织、事件或其他事实存在相似之处，均属巧合，不构成影射、评价、指控或事实陈述。
本文尽可能避免情绪化表达、价值预设、立场先行、道德审判、主观臆断、标签化归因及煽动性措辞，力求以事实描述、逻辑分析、条件限定和可核查信息为基础进行客观陈述。文中如涉及评价、判断或推论，均仅限于基于已明示前提和文本语境所作的分析性表达，不构成对任何现实个人、组织、群体、项目、事件或观点的最终定性。
*/本文并不反对 AI 编程。恰恰相反，AI 是目前最强大的工程辅助工具之一。问题在于，工具越强，对使用者的判断力要求越高。锤子不会让人变成木匠，Claude Code 也不会让一个不理解架构、不理解依赖、不理解测试、不理解回滚的人突然变成工程师。
真正危险的不是 AI 会写代码，而是有人以为“AI 会写代码”就等于“我会写代码”。
先说观点：任何一个会 coding 的人不需要你教他使用 AI，任何一个只接受过“Vibe coding 教学”的人一定不是一个真正会 coding 的人，反而更可能是个祸害！
任何一个真正会 coding 的人，都不需要别人教他“怎么用 AI 写代码”。他天然知道如何拆需求、读代码、定位文件、控制影响面、审查 diff、设计测试、回滚变更。反过来，任何一个只接受过所谓“Vibe Coding 教学”的人，也不会因此变成程序员。他最多只是学会了如何把 prompt 写得更像需求，如何把自己看不懂的代码更快地塞进项目里。
很久之前，我就想写一篇这样的文章，完整地说清楚现在 AI 对软件工程领域的影响到底是什么样的，纠正很多常见误解，并明确表达自己的立场观点，方便以后复用。但是由于我行动力太弱，一直没有动手。然而今天又发生了一些事情，让我年轻的身体血压飙升，并再次确认了一个朴素事实：如果不把这些话讲清楚，类似的工程灾难只会以更加抽象的形式反复发生。故认为，很有必要动笔了。
作为一篇略带批判性的文章，我们当然要先来品尝一下一些新鲜的shit（素材来自网络，侵删）。
先从前段时间流行的 Openclaw 吃起：
这个事件的笑点在于两方面：一是这个项目本身呈现出极高的 AI 编码痕迹，工程结构、代码质量和长期可维护性都很难支撑它在传播中被赋予的宏大叙事；二是它的推广话术精准击中了非专业人士对“AI 造物神话”的从众心理、奇观心理和技术崇拜心理。一个工程质量尚且存疑的项目，能够在短时间内被包装成某种“普通人指挥 AI 改变世界”的标志性事件，本身就充分说明了基础科学素养、工程常识和技术媒介识读能力的普及仍然任重而道远。
更有意思的是，在这个项目之后，又迅速诞生了大量衍生叙事和二次包装。且不谈那种“文科生 72 小时杀入 GitHub 全球榜：没写一行代码，指挥了一支 AI 军队”的 JiangPing 艺术——这类叙事的核心价值本来就不在工程，而在流量——就连一些 Professor 也开始把为其开发扩展、参与生态建设之类的事情包装成个人名片。如果这只是出于传播压力、资源交换、履历修饰或某种现实语境下的策略性选择，那当然可以理解；毕竟人在江湖，有时不得不配合时代的荒诞。
但是，如果这是真心相信一个高 AI 含量、低工程约束、强传播包装的项目代表了软件工程的未来，那问题就严重得多了。这已经不是“拥抱新工具”，而是把工具崇拜误认为技术判断，把流行度误认为工程价值，把 GitHub 榜单误认为项目质量，把 AI 生成能力误认为开发能力。一个项目能不能火，取决于传播机制；一个项目值不值得信任，取决于架构、代码、测试、安全性、可维护性和实际长期治理。把前者当成后者，是这个时代最典型的技术错觉之一。
更讽刺的是，OpenClaw 这类项目真正暴露出来的问题，恰恰不是“AI 太强了”，而是“人太容易被 AI 表演说服了”。只要 README 足够热血、Demo 足够丝滑、叙事足够反差、标题足够违反常识，就总有人愿意主动替它补全合理性。至于代码到底能不能维护、架构到底是否稳定、意外状况是否可控、真实场景是否可用、后续责任由谁承担，这些真正属于工程的问题，反而在狂欢中被系统性地忽略了。
所以，OpenClaw 不是一个单纯的开源项目事件，而是一面镜子：它照出了 AI 时代技术传播的劣化，也照出了很多人对“会编程”的理解已经退化到了何等程度。不会写代码的人以为自己终于可以绕过代码，不懂工程的人以为自己终于可以绕过工程，不具备技术判断力的人以为自己终于可以靠模型获得技术判断力。结果不是软件工程被民主化，而是工程责任被娱乐化、项目质量被流量化、技术能力被表演化。
对于某些素材，直接评价反而显得多余。这里仅补充一点基础的化学知识：二氧化硫（SO₂）是一种具有刺激性气味的酸性气体，氨气（NH₃）则是一种具有刺激性气味的碱性气体。二者在干燥条件下反应较慢，但在有水存在时，会迅速发生酸碱中和反应，生成亚硫酸铵或亚硫酸氢铵等盐类物质。当氨气相对充足时，主要反应可表示为：SO₂ + 2NH₃ + H₂O → (NH₄)₂SO₃；当二氧化硫相对过量时，则更容易生成亚硫酸氢铵：SO₂ + NH₃ + H₂O → NH₄HSO₃；在空气或氧化剂存在的条件下，亚硫酸铵还可能进一步被氧化，生成更稳定的硫酸铵：2(NH₄)₂SO₃ + O₂ → 2(NH₄)₂SO₄。这一反应体系常见于烟气脱硫、尾气吸收和含硫废气治理等场景。其核心原理是利用碱性物质吸收酸性气体，将原本具有刺激性和污染性的气体转化为相对稳定、可处理的盐类物质。从化学角度看，这是一个非常典型的例子：两种各自都很有存在感、且单独释放出来都容易让周围环境变得不适的气体，在合适条件下相遇后，会迅速发生反应，并生成一种新的、沉重的、难以挥发的产物。
上图来自某个“人工智能知识竞赛”。
类似的shit还有很多，有些过于敏感，在此不予展示了。
品尝完了之后，是时候回到正题了。现在的问题不是“能不能用 AI 写代码”，也不是“用 AI 写代码算不算会编程”。这些问题本身就问得很外行。真正的问题是：你有没有能力判断 AI 写出来的代码到底对不对，以及你有没有资格把它合入一个真实项目。
用 AI 的前提：
- 你非常清楚地了解这个项目的架构。精确到每个文件承担哪些功能、在什么时机被调用、与哪些模块存在依赖关系，以及改动其中一处可能牵连到哪些地方。
- 基于上一前提，你也非常清楚地知道自己的需求及技术架构上大致的实现方式（采用什么样的语言和算法、调用哪些库或底层软件、遵循项目中已有的哪些设计约束）。
- 你知道主要是哪些文件的哪些部分需要被改动，（不知道的情况下可以询问 AI 并了解，但在 AI 直接开始写代码之前必须自己先搞清楚！）。
- 你知道可能需要额外关心并避免的方面（性能损失、功能牺牲、交互破坏、兼容性倒退），事前要进行规避、事后要进行核查。
用 AI 的过程中：
- 确保自己能看懂 AI 写的每一行代码，清晰地知道：为什么要写这行、不写这行会怎么样、改用别的写法是否可行、这行代码是否具备该有的鲁棒性、对非你自己负责的部分造成了什么影响、它可能会带来什么副作用、它的实现是否违背了本项目的设计哲学。
- 时刻监视或至少在 AI 完成后逐行阅读、完整审查。不要把“能运行”“没报错”“看起来像那么回事”当成正确性证明。
- 不让 AI 直接执行任何高危操作，尤其是
rm、mv和git push --force。 - 在不具备快照快速回滚的或有多人共同使用的环境中，永远不要让 AI 直接登录并执行任何命令。尤其不要让它在生产环境或共享开发环境的机器上自由发挥。
- 进行完整的测试后再合入主线。（对于某些连版本管理意识都没有的人，这句话说了也没用）这个测试包括所有你的代码可能影响到的功能，而绝不只是你想要实现的那个 feat 或者待修复的 bug。你可以使用 CI 减少工作量，但在 workflow 用例不满足绝对完备的情况下，应当避免写代码的 AI 直接接触用例相关目录，更不应该让它为了“修测试”去改测试本身。
- 使用 AI 代码审查。我知道很多人其实根本就不会严格按照我上面的要求来做，他们宁愿多花时间拿自己刚拉出来的东西吹牛皮，也不愿意多花十分钟看一眼 diff。可谓朽木不可雕也，粪土之墙不可圬也！但是如果哪个项目非常不幸地让您加入了，烦请您至少使用一个 AI 代码审查工具，在您自己代码提交之前进行一次完整的审查流程，解决所有 P3 级以上的问题并严肃关注 P4 级问题。至少不要让别人替您的“灵感编程”收拾尸体。
记住：
- 没有任何一个真正的专业人士会认为一个项目的 AI 率高是件好事，除非你是在展示你自己的 LLM/Agent 的编码能力的强大。
- 坚持 100% 手搓已经不是一件好事了，因为你的耗时会增加、考虑周全性一般也不如 AI（除非你对比的是 ** 模型），但是这不意味着你可以在不熟悉相关技术栈的情况下开工。
- AI 可以帮你更快地写代码，但不能替你理解代码。AI 可以帮你减少重复劳动，但不能替你承担工程责任。AI 可以是一个很强的助手，但如果你把它当成架构师、审查者、测试负责人和最终责任人，那项目出事只是时间问题。
所以，AI 编程真正的问题从来不是“能不能让 AI 写代码”，而是“你是否有资格判断 AI 写得对不对”。
如果你看不懂它写的代码，就没有资格合入。
如果你不知道它影响了什么，就没有资格上线。
如果你无法解释它的副作用，就没有资格把风险交给别人承担。
您说您会 Vibe Coding？那请先解释一下：您的 diff 为什么是对的。