# 写代码和编程，真不是一回事：240万人看过的概念之争深读 ## 概述 “写代码”和“编程”在中文里几乎可以互换，在英文里 coding 和 programming 也常年被混着用。但前软件工程师、职业频道主理人 Aaron Jack 的这条视频《Programming vs Coding - What's the difference?》，正是拿这对“同义词”开刀：它们到底是不是一回事？如果是一回事，为什么行业要用两个词？如果不是，区别又在哪里、值多少钱？这条播放量超过239万的视频把一个看似咬文嚼字的问题，掰成了程序员职业身份、抽象层级演进和AI时代价值重估的入口。在“氛围编程”（vibe coding）盛行的2026年，这个七十年前就被计算机先驱们区分过的概念，突然变成了每个写代码的人都要回答的生存问题。本文带你把这条视频的论证完整走一遍，再往前多走几步：回到1947年的第一代计算机报告，看看“规划”与“编码”是如何从一开始就被写成了两道工序。 ## 视频基本信息 | 项目 | 内容 | |---|---| | 视频标题 | Programming vs Coding - What's the difference? | | 中文译名 | 编程 vs 写代码——区别到底是什么？ | | 频道 | Aaron Jack | | 频道定位 | 前优步软件工程师创办的职业向频道，聚焦软件工程师求职、技能与行业认知 | | 播放量 | 2,389,684 次（据YouTube页面，采集于2026-09-05） | | 发布时间 | 本次数据采集未包含发布日期（据频道页面） | | 观看链接 | https://www.youtube.com/watch?v=CIRGjwYgdT4 | 需要说明的是，这是一条“常青型”视频：它讨论的不是某个框架版本，而是一个行业级概念问题，因此多年来持续有自然播放。而在2025–2026年AI编程工具全面铺开之后，这条视频讨论的问题被重新点燃——“如果AI负责coding，人负责什么”成了技术社区的高频争论，也让这条老视频的价值不降反升。 ## 核心主张拆解 围绕标题抛出的问题，这条视频的论证脉络大致可以还原为四步（叙事顺序按概念递进排列）： **第一步：承认语言现实——大家都在混用。** 视频从最直观的现象切入：招聘帖里写"coding skills"，媒体喊“learn to code”，朋友问你“会不会编程”，两个词在99%的场合被当作同义词。频道主理人并不装作这个问题有多学术，而是先承认：日常语言里，这对词早就融合了。 **第二步：指出落差——两个词的落点其实不同。** “coding”更像是“把一个已经想清楚的东西翻译成某种编程语言的语句”；而“programming”指的更完整的活动：分析问题、设计方案、拆解结构、处理边界情况、验证正确性，最后才轮到“写语句”这一步。用一个类比：coding接近“打字”，programming接近“写作”。会打字不等于会写小说，这句话就是整条视频的题眼。 **第三步：映射到职业头衔光谱。** 行业头衔其实悄悄记录了这个区别：coder（编码员）、developer（开发者）、software engineer（软件工程师）并不只是叫法花哨，它们隐含着市场对“你做的是翻译还是设计”的定价。工程师的溢价，恰恰来自coding之外那部分能力——把模糊的真实问题变成可运行、可维护的系统结构。 **第四步：落到职业建议。** 作为职业频道的内容，视频最终的落点是个人策略：不要把自己训练成“更快的打字员”，而要往问题定义、系统设计、技术判断这些“翻译上游”走。这个建议在2020年前后是锦上添花，在AI代码生成普及的今天，几乎是雪中送炭。 值得注意的是，这条视频最有价值的地方不在结论，而在它把一个被日常语言抹平的区别重新切开，逼你回答：**你每天的工作里，有多少是programming，有多少只是coding？** ## 知识与理论溯源 视频留下的问题，值得用真实的历史和理论来补全。这一部分是本文的“多懂一层”——这些溯源材料都能独立查证。 ### 1. “规划”与“编码”的分离，写在第一代计算机的报告里 这不是现代人的发明。1947–1948年，冯·诺依曼与赫尔曼·戈尔德斯汀（Herman Goldstine）在普林斯顿高等研究院（IAS）发布了著名的三部曲报告《Planning and Coding of Problems for an Electronic Computing Instrument》（《电子计算装置问题的规划与编码》）。标题本身就说明了一切：在计算学科的黎明时刻，奠基者们就把工作分成两个阶段——先有对问题的数学规划（planning），再有把它落成机器指令的编码（coding）。两者是两道工序、两种技能。今天“coding vs programming”之争，本质上是七十七年前那份报告标题的世俗化重演。 ### 2. ENIAC的“computers”：被历史叫错了名字的最早程序员 1945–1946年，六位女性数学家——Kay McNulty、Betty Jennings、Betty Snyder、Marlyn Wescoff、Fran Bilas、Ruth Lichterman——被军方雇来给ENIAC“编程”。当时她们的职位名称是“computers”（计算员），工作方式是推导弹道方程、手工制作打孔卡片、拨动数千个开关、重新插接线缆。她们没有编程语言可用，“写程序”意味着把数学规划物理化到机器上。这段历史常被简化为“最早的程序员是女性”的励志故事，但更准确的读法是：**从第一天起，“想清楚问题的人”和“把方案装进机器的人”就是同一个岗位的两副面孔**——而历史记录只留下了“computer/coder”这个偏重机械侧的名字。这为后来两个词的语义竞争埋下了伏笔。 ### 3. 格蕾丝·霍珀与编译器：让“coding”第一次离开机器 1952年，格蕾丝·霍珀（Grace Hopper）团队完成了A-0编译器，让程序可以用类英语的语句编写、再由机器自动翻译成指令。她晚年反复讲一个细节：当年几乎没人相信“计算机会自己写程序”，同行坚持认为机器只该做算术。编译器普及之后，“coding”的含义发生了第一次漂移——从“直接操纵机器”变成“用高级语言书写”。每一次抽象层级的提升（机器码→汇编→FORTRAN/LISP→结构化语言→带垃圾回收的语言→今天的AI代码生成），都在重复同一个动作：**把旧日的“coding”自动化，把人类的职责推向更上游的“programming”**。理解了这个模式，就能理解为什么2026年围绕AI编程的争论并不新鲜——它是这个七十年模式的最新一轮。 ### 4. 彼得·瑙尔《Programming as Theory Building》：程序是理论，代码只是外化 丹麦计算科学家彼得·瑙尔（Peter Naur，2005年图灵奖得主）在1985年发表了《Programming as Theory Building》（《作为理论构建的编程》），这是计算机科学文献里被引用最多的“哲学论文”之一。他的核心论断：一个程序真正的本体，不是源代码，而是开发团队头脑中那套“关于世界如何运转、程序为何如此设计的理论”。代码只是理论的外化产物。因此他给出一个惊人的推论：**团队解散、理论消亡之后，即使代码和文档完整保留，这个程序在严格意义上已经“死”了**——后来的维护者改一行代码，就像在不懂得钟表原理的情况下修理钟表。用瑙尔的框架看 coding/programming 之争：coding产出的是文本，programming构建的是理论。AI能生成前者，但“理论”目前仍然住在人脑里。 ### 5. 布鲁克斯《没有银弹》：本质复杂度 vs 偶然复杂度 1986年，弗雷德里克·布鲁克斯（Frederick Brooks，《人月神话》作者）发表《No Silver Bullet》，把软件的困难分成两层：**本质性（essence）**——概念结构的构建，即搞清楚要对现实中的什么对象建模、它们如何交互；**偶然性（accident）**——把概念结构映射到某种语言和工具上的麻烦。他说过一个常被引用的判断：如果本质复杂度占软件困难的五分之四，那么再怎么消灭偶然部分（更好的语言、工具、AI），进展上限也只有百分之二十。这个1986年的论断在今天有了新的检验场景：AI代码生成消灭的恰恰是“偶然”侧的苦工——语法、样板代码、API记忆——而“本质”侧的问题定义与设计决策，一个都没少。 ### 6. “氛围编程”：2025年的语义漂移现场 2025年2月，OpenAI联合创始人、前特斯拉AI总监安德烈·卡帕西（Andrej Karpathy）发了一条推文，描述自己“完全顺应氛围、拥抱指数增长、几乎忘记代码的存在”地用AI写项目，并造词“vibe coding”。据当时多家科技媒体报道，这个词迅速出圈，甚至被《韦氏词典》等辞书机构收录追踪。这个词的走红本身就是一个语言学标本：当“coding”的门槛被AI压到“动嘴”级别，行业立刻造出一个新词把它和“正经编程”区分开——**用词的分化，从来都是行业在给价值重新划界**。 ## 批判性审查 **证据充分的部分。** 历史脉络扎实：从IAS报告的标题，到ENIAC操作员的职位名称，再到编译器带来的语义漂移，“规划/设计”与“编码/翻译”的分工贯穿了整个计算史，这些都有原始文献和当事人回忆录可查。瑙尔与布鲁克斯的两篇经典也是学界公认的严肃理论，不是营销话术。 **被夸大或有争议的部分。** 第一，“两个词有本质区别”这个命题本身，语言学界不会全盘认账。从描写语言学（descriptivism）的立场看，coding和programming的混用就是正常的语义演化，规定“你必须用编程而不是写代码”是一种语言规范主义，类似长期纠缠程序员社群的“hack vs engineer”头衔之争——它的驱动力有一大半是**职业身份建构和护城河心理**，而非客观的语言边界。第二，视频的美国就业市场视角有局限：在不同语言文化里（比如中文技术圈），“码农”“程序员”“工程师”的自嘲与分层逻辑并不和英文一一对应，直接套用会失真。第三，需要提醒一个程序员圈的经典陷阱——名言归属。那句流传极广的“计算机科学之于计算机，就像天文学之于望远镜”，通常被归给迪杰斯特拉（Edsger Dijkstra），但其真实出处长期存疑，Dijkstra本人文稿中并无此句的可靠记录。这恰好是个隐喻：**这个行业的很多“共识”，是转述中长出来的 folklore，值得每个读者养成核查习惯**。 **这条视频本身的局限。** 它是职业向内容而非学术论述，没有引用IAS报告或瑙尔原文，论证依赖个人行业经验的归纳；观点的有效性高度依赖“AI只能做翻译层”这个前提——而这个前提在2026年正被快速侵蚀：从2026年9月仍在技术社区热议的“Rust版React编译器原生进入Vite”（ Hacker News 当前讨论，106分）这类进展就能看出，连“设计”的相当一部分也在被工具化。视频给出的答案需要读者根据最新形势打一个折扣。 ## 认知提升与实用启示 **1. 用“瑙尔测试”体检你的日常工作。** 问自己一个问题：如果我明天离职，我脑子里带走的、而代码库里查不到的东西有多少？如果答案是“几乎没有”——你做的可能只是coding。可操作的对策：每接一个需求，先用三五句话写下“为什么这样设计、放弃了哪些方案”，把它发给同事或存进团队文档。这个动作把你的工作从“翻译”升级为“理论构建”，也是AI时代最难被替代的部分。 **2. 把AI当成“自动编译器”，自己守住规划层。** 借用1947年报告的两段式：先写清楚问题的定义、输入输出、边界条件和验收标准（planning），再让AI生成代码（coding），然后像review人类同事的代码一样逐行读diff。一个立竿见影的习惯：禁止自己对AI生成的代码说“能跑就行”——能跑只是coding的及格线，不是programming的。 **3. 简历和述职里，把语言词汇换成结构词汇。** 描述经历时，少写“用X语言实现了Y功能”，多写“把Y问题建模为X结构、在A与B约束之间做了什么权衡、带来什么可度量的变化”。前者把自己定位成打字员，后者定位成问题解决者——这正是市场中头衔溢价的来源，也是这条视频对个人最直接的实用价值。 ## 视频论证结构图 ```mermaid flowchart TD A[日常语言混用
coding = programming ?] --> B[切开始于定义] B --> C[coding: 把想清楚的方案
翻译成语言语句] B --> D[programming: 问题分析/设计/
拆解/验证 的完整活动] C --> E[职业头衔光谱
coder → developer → engineer] D --> E E --> F{历史验证:这是新问题吗?} F --> G[1947 IAS报告:
Planning and Coding 分两道工序] F --> H[1952 霍珀编译器:
自动化旧的coding层] F --> I[1985 瑙尔:
程序=团队头脑中的理论] F --> J[1986 布鲁克斯:
本质复杂度无法被工具消除] G & H & I & J --> K[模式: 每次抽象升级
都把人类职责推向规划层] K --> L[2025 vibe coding 走红
= 新一轮价值划界] L --> M[个人策略: 守住问题定义/设计/
验收,把AI当作新的自动编码层] ``` ## 延伸阅读 1. [Solving the Jane Street reverse engineering challenge（Hacker News，390分热议）](https://news.ycombinator.com/item?id=49562657) — 逆向工程解谜挑战的解题实录讨论，是“编程远不止写语句”的最佳活体标本：真正的较量全在分析和推理侧。 2. ["Next-token predictor" is the wrong mental model for LLMs（Hacker News讨论）](https://news.ycombinator.com/item?id=49567310) — 关于该给AI时代程序员装上什么心智模型的争论，与本文“守住规划层”的结论互为补充。 ## 参考来源 1. [Programming vs Coding - What's the difference? | Aaron Jack](https://www.youtube.com/watch?v=CIRGjwYgdT4) — 本文解读的主视频，播放量2,389,684次（据YouTube页面，2026-09-05采集） 2. [The Rust React Compiler is now native in Vite（Hacker News）](https://news.ycombinator.com/item?id=49567873) — 2026年9月“设计层持续被工具化”的最新例证 3. [Goldstine & von Neumann, Planning and Coding of Problems for an Electronic Computing Instrument (1947–48), IAS] — “规划与编码”两段式分工的原始文献，据普林斯顿高等研究院出版记录 4. [Peter Naur, Programming as Theory Building (1985), Microprocessing and Microprogramming] — “程序即理论构建”的原始论文 5. [Frederick Brooks, No Silver Bullet (1986), IFIP] — 本质性/偶然性复杂度划分的原始出处 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。