“写代码”和“编程”在中文里几乎可以互换，在英文里 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？
视频留下的问题，值得用真实的历史和理论来补全。这一部分是本文的“多懂一层”——这些溯源材料都能独立查证。
这不是现代人的发明。1947–1948年，冯·诺依曼与赫尔曼·戈尔德斯汀（Herman Goldstine）在普林斯顿高等研究院（IAS）发布了著名的三部曲报告《Planning and Coding of Problems for an Electronic Computing Instrument》（《电子计算装置问题的规划与编码》）。标题本身就说明了一切：在计算学科的黎明时刻，奠基者们就把工作分成两个阶段——先有对问题的数学规划（planning），再有把它落成机器指令的编码（coding）。两者是两道工序、两种技能。今天“coding vs programming”之争，本质上是七十七年前那份报告标题的世俗化重演。
1945–1946年，六位女性数学家——Kay McNulty、Betty Jennings、Betty Snyder、Marlyn Wescoff、Fran Bilas、Ruth Lichterman——被军方雇来给ENIAC“编程”。当时她们的职位名称是“computers”（计算员），工作方式是推导弹道方程、手工制作打孔卡片、拨动数千个开关、重新插接线缆。她们没有编程语言可用，“写程序”意味着把数学规划物理化到机器上。这段历史常被简化为“最早的程序员是女性”的励志故事，但更准确的读法是：从第一天起，“想清楚问题的人”和“把方案装进机器的人”就是同一个岗位的两副面孔——而历史记录只留下了“computer/coder”这个偏重机械侧的名字。这为后来两个词的语义竞争埋下了伏笔。
1952年，格蕾丝·霍珀（Grace Hopper）团队完成了A-0编译器，让程序可以用类英语的语句编写、再由机器自动翻译成指令。她晚年反复讲一个细节：当年几乎没人相信“计算机会自己写程序”，同行坚持认为机器只该做算术。编译器普及之后，“coding”的含义发生了第一次漂移——从“直接操纵机器”变成“用高级语言书写”。每一次抽象层级的提升（机器码→汇编→FORTRAN/LISP→结构化语言→带垃圾回收的语言→今天的AI代码生成），都在重复同一个动作：把旧日的“coding”自动化，把人类的职责推向更上游的“programming”。理解了这个模式，就能理解为什么2026年围绕AI编程的争论并不新鲜——它是这个七十年模式的最新一轮。
丹麦计算科学家彼得·瑙尔（Peter Naur，2005年图灵奖得主）在1985年发表了《Programming as Theory Building》（《作为理论构建的编程》），这是计算机科学文献里被引用最多的“哲学论文”之一。他的核心论断：一个程序真正的本体，不是源代码，而是开发团队头脑中那套“关于世界如何运转、程序为何如此设计的理论”。代码只是理论的外化产物。因此他给出一个惊人的推论：团队解散、理论消亡之后，即使代码和文档完整保留，这个程序在严格意义上已经“死”了——后来的维护者改一行代码，就像在不懂得钟表原理的情况下修理钟表。用瑙尔的框架看 coding/programming 之争：coding产出的是文本，programming构建的是理论。AI能生成前者，但“理论”目前仍然住在人脑里。
1986年，弗雷德里克·布鲁克斯（Frederick Brooks，《人月神话》作者）发表《No Silver Bullet》，把软件的困难分成两层：本质性（essence）——概念结构的构建，即搞清楚要对现实中的什么对象建模、它们如何交互；偶然性（accident）——把概念结构映射到某种语言和工具上的麻烦。他说过一个常被引用的判断：如果本质复杂度占软件困难的五分之四，那么再怎么消灭偶然部分（更好的语言、工具、AI），进展上限也只有百分之二十。这个1986年的论断在今天有了新的检验场景：AI代码生成消灭的恰恰是“偶然”侧的苦工——语法、样板代码、API记忆——而“本质”侧的问题定义与设计决策，一个都没少。
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约束之间做了什么权衡、带来什么可度量的变化”。前者把自己定位成打字员，后者定位成问题解决者——这正是市场中头衔溢价的来源，也是这条视频对个人最直接的实用价值。
flowchart TD
A[日常语言混用<br>coding = programming ?] --> B[切开始于定义]
B --> C[coding: 把想清楚的方案<br>翻译成语言语句]
B --> D[programming: 问题分析/设计/<br>拆解/验证 的完整活动]
C --> E[职业头衔光谱<br>coder → developer → engineer]
D --> E
E --> F{历史验证:这是新问题吗?}
F --> G[1947 IAS报告:<br>Planning and Coding 分两道工序]
F --> H[1952 霍珀编译器:<br>自动化旧的coding层]
F --> I[1985 瑙尔:<br>程序=团队头脑中的理论]
F --> J[1986 布鲁克斯:<br>本质复杂度无法被工具消除]
G & H & I & J --> K[模式: 每次抽象升级<br>都把人类职责推向规划层]
K --> L[2025 vibe coding 走红<br>= 新一轮价值划界]
L --> M[个人策略: 守住问题定义/设计/<br>验收,把AI当作新的自动编码层]
本文由「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 等场景全覆盖。