# 239万人分不清的两个词：编程与敲码，到底差在哪 ## 概述 在程序员的世界里，有两个词被混用了几十年：programming（编程）和 coding（敲码）。它们听起来像同义词，招聘广告里也常常互换。但有一条播放量超过239万的视频告诉所有初学者：**这两个词背后，是两种完全不同的能力，而90%的“学不会编程”，恰恰卡在分不清这两件事上**。这条视频就是前优步软件工程师 Aaron Jack 的《Programming vs Coding - What's the difference?》。它没有炫酷动画，没有高深算法，却常年稳居程序员职业类内容的头部。在AI已经能替人“敲码”的2026年，这条视频的区分反而变得前所未有地重要——因为被AI接管的那一半，叫coding；升值的另一半，叫programming。本文带你把这条视频从头到尾拆开，看清这两个词的本质差异、背后的软件工程理论根基，以及它对今天每个学习者意味着什么。 ## 视频基本信息 | 项目 | 内容 | |------|------| | 视频标题 | Programming vs Coding - What's the difference?（《编程 vs 敲码：区别到底在哪？》） | | 频道 | Aaron Jack | | 频道主背景 | 前优步（Uber）软件工程师，后全职经营程序员职业类频道（据其频道自述） | | 播放量 | 超过239万次（据频道页面2026年9月底数据） | | 发布时间 | 上线已数年，长期是其频道播放量最高的视频之一（据频道页面） | | 时长 | 约10分钟 | --- ## 一、一条“反直觉”的老视频，为什么一直有人翻出来看 先说这条视频最反常的地方：它讲的不是一个技术点，而是一个**概念澄清**。 在YouTube的编程内容区，99%的视频在回答“怎么学”——怎么装环境、怎么写循环、怎么刷题。Aaron Jack这条视频问的却是一个更底层的问题：**你正在学的那个东西，到底是什么？** 视频的开场就很扎心。Aaron Jack说，大多数人想学编程时，脑子里想象的画面是“坐在电脑前噼里啪啦敲代码”，于是他们把“学会编程”等同于“背熟语法、记住API、熟练使用某个框架”。然后他们真的去背了——背了变量、背了循环、背了函数定义。三个月后，语法考试能过，可一旦让他们**独立面对一个空白编辑器和一道没见过的问题**，大脑就一片空白。 于是他们得出结论：“我大概没有编程天赋。” Aaron Jack的判断是：这些人不是没有天赋，而是**从头到尾只在练coding，从来没碰过programming**。就像一个人把英汉词典背得滚瓜烂熟，却从来没学会“用英语组织一个观点”——背词典和会表达，是两回事。 这条视频之所以常年有人翻出来重看，是因为它戳中的困惑在每一代初学者身上都会重新发作。而且，后文会讲到，2026年的AI浪潮让这条几十年前就存在的分界线，第一次变成了一条“职业生死线”。 ## 二、核心主张拆解：这条视频到底讲了什么 按视频的叙事顺序，可以把内容拆成五个要点。 ### 要点1：coding是“翻译”，programming是“求解” Aaron Jack给出的核心定义非常干净： - **Coding（敲码）**：把一个**已经想清楚的解决方案**，翻译成某种编程语言的语法。方案是确定的，你只是在做语言转换——好比把一份中文合同译成英文，译文质量取决于你对两种语言的熟练度。 - **Programming（编程）**：面对一个**模糊的、没有现成答案的现实问题**，分析它、拆解它、设计出解法，并验证解法确实有效。这才是“用计算机解决问题”的完整过程。 注意这个定义里最关键的词：**“已经想清楚的”**。Coding发生之前，必须先存在一个想清楚的方案。方案从哪来？从programming来。 ### 要点2：语法是有限集合，问题是无限集合 视频里有一个很锐利的观察：**任何一门编程语言的语法，本质上是一个有限的、封闭的知识集合**。Python的核心语法几天就能过一遍，JavaScript的常用特性也就几十个。你永远不需要“无限多”的语法知识——遇到忘了的，查文档，十秒钟回来。 但programming面对的问题是**开放且无限**的：用户需求会变，业务逻辑会缠成一团，系统会在你最想不到的地方崩掉。语法是有限游戏，问题求解是无限游戏。用背单词的方式去打一场无限游戏，当然会输。 这也是为什么很多初学者会有那种诡异体验：“教程我全看懂了，可我自己还是写不出来。”——看懂教程只需要coding层面的理解（每行语法都认识），写出来却需要programming层面的能力（把问题拆到能翻译的程度）。**这两层之间隔着一条鸿沟，而教程通常不负责搭桥。** ### 要点3：初学者的“卡点误诊” 视频里最有价值的一段，是对初学者痛苦根源的重新诊断。 一个典型场景：新手拿到题目“判断一个字符串是不是回文”。他的真实状态是什么？不是不知道`for`循环怎么写，不是不知道字符串怎么取下标——而是**脑子里没有一步步的解题路径**：先从两头往中间比？还是复制一份倒过来比对？空字符串算不算回文？大小写敏感吗？ 也就是说，他在coding层的知识是够的，缺的是programming层的**问题分解能力**：把“判断回文”这个模糊目标，拆解成“确定比较策略→处理边界情况→逐字符比较→给出结论”这样一条可翻译的路径。 Aaron Jack的结论是：所谓“我没有编程天赋”，绝大多数时候是把“我还没学会分解问题”误诊成了“我脑子不行”。前者是训练方法问题，可以练；后者是给人判死刑。这个误诊让无数人在错误的维度上放弃。 ### 要点4：为什么行业会把这两个词混为一谈 视频顺带解释了混淆的来源：在软件行业日常用语里，"coding"和"programming"经常互换，招聘职位写"coding test"，程序员自嘲叫“码农”（code monkey）。这种混用在日常闲聊里无害，但在**学习路径**上是有毒的——如果你以为编程=敲码，你就会用“背语法”的方式规划全部学习时间，把100%的精力投进那个有限集合，而回避那个真正决定上限的无限集合。 Aaron Jack打了个比方：这就像想成为作家的人，把全部时间用来练打字速度。打字当然要快，但打字快和会写小说，中间差着一整个作家的灵魂。 ### 要点5：训练重心应该放在哪 视频给出的方向性建议可以概括为一句话：**语法过一遍就够，把主要训练量投向问题分解**。拿到任何题目，先强迫自己在纸面上写出“人话版步骤”（伪代码），确认每一步都是可执行的、无歧义的，再坐到键盘前翻译成代码。翻译阶段越机械越好——如果翻译阶段还不断冒出“解法层面”的新决定，说明programming层没做完，应该回到纸上而不是在编辑器里边写边想。 这个建议朴素到不像“秘籍”，但它和后面要讲的严肃软件工程理论惊人地一致。 ## 三、知识与理论溯源：这不是一个人的直觉 这条视频看起来像个人经验谈，但它背后站着软件工程界几十年积累的经典理论。把它放回学术脉络，你会发现Aaron Jack说的“两个词的区别”，其实是几位大师反复论证过的同一件事。 ### Peter Naur：程序不是文本，是“理论” 丹麦计算机科学家、1985年，后来以“BNF范式”和2005年图灵奖闻名的彼得·诺尔（Peter Naur），发表过一篇软件工程史上被引用越来越多的论文：《Programming as Theory Building》（编程即理论构建，1985）。 Naur的核心论点震撼至今：**一个程序最核心的资产，不是源代码文本，而是开发团队脑中关于“这个程序如何解决问题”的那套理论**。代码只是理论的物化投影。他观察到：当一个系统的原班人马离开后，即使代码、文档完整保留，新团队也极难维护它——因为理论没了，剩下的只是“能跑的尸体”。 用这条视频的语言重述Naur：coding产出的是文本，programming构建的是理论。文本可以复制、可以丢给AI生成，理论不行。这直接解释了为什么“看懂教程”不等于“会编程”——你读到的只是别人的文本，你脑中并没有构建起那套理论。 ### Fred Brooks：本质复杂性与偶然复杂性 1986年，图灵奖得主、《人月神话》作者弗雷德·布鲁克斯（Fred Brooks）发表了另一篇传世檄文《No Silver Bullet》（没有银弹）。 Brooks把软件的困难切成两层： - **本质复杂性（essence）**：问题本身的复杂——业务逻辑的纠缠、需求之间的冲突、边界情况的爆炸。这部分**存在于问题里**，任何工具都消不掉。 - **偶然复杂性（accidents）**：用当前工具表达解法时额外产生的复杂——记语法、配环境、调试语言怪癖。这部分**存在于工具里**，会随着工具进步不断被削掉。 对应过来一目了然：**programming在打本质复杂性的仗，coding在处理偶然复杂性**。Brooks当年断言“没有银弹”，因为本质复杂性无法消除——工具再好，你也替客户想不清楚“到底要什么”。 ### Donald Knuth：程序是写给人的 高德纳（Donald Knuth）在1984年提出“文学编程”（Literate Programming）时说：程序首先应该是**写给人看的**，其次才是给机器执行的。这也是同一条思想脉络的延伸——把代码翻译出来（coding）只是末梢，向人类清晰地组织一个解法（programming）才是本体。 ### 三条线索，一个结论 把三个来源并排放在一起，会发现这条视频的“民间直觉”和学术界的严肃结论完全同构： | 视频用语 | Naur（1985） | Brooks（1986） | Knuth（1984） | |----------|--------------|----------------|---------------| | programming | 理论构建 | 与本质复杂性搏斗 | 组织给人读的解法 | | coding | 文本产出 | 处理偶然复杂性 | 打字与排版 | 一条十分钟的职业频道视频，无意间成了三篇经典论文的大众化转译。这正是它值得认真对待的原因。 ## 四、2026年重读：AI把这条分界线变成了职业分水岭 这条视频上线时还没有大语言模型。把它放到2026年重读，会发生奇妙的化学反应——**AI恰好只接管了coding那一半**。 ### 敲码正在被批量加速 2023年GitHub发布的一项对照实验研究（Peng et al., arXiv:2302.06590）显示：使用Copilot辅助的开发者，在标准化编程任务中的完成速度比对照组快约55.8%。注意这项任务的设计——实现一个明确规格的功能——正是纯coding任务：方案已经想清楚，只剩翻译。AI在这种任务上的表现，等于把“翻译环节”的成本砸向零。 ### 但“接近但不完全对”成了新痛点 另一边，Stack Overflow 2024年开发者调查（survey.stackoverflow.co/2024）捕捉到的最大挫败感，是AI给出的答案“**几乎正确，但不完全对**”（almost right, but not quite）。为什么这很致命？因为判断一个方案“哪里不对、为什么不对、该信到什么程度”，需要的恰恰是programming能力——你必须在脑中保有那套Naur所说的“理论”，才能校验别人的（或AI的）翻译。 这就形成了一个2026年的新格局：**翻译被自动化了，校验和定义问题的责任反而更重了**。AI把coding的价格打下来，同时把programming的溢价抬上去。Aaron Jack那条视频里的二分法，从“学习建议”升级成了“职业策略”：你的不可替代性，不取决于你能多快敲出代码，而取决于你能多准地定义问题、多深地理解系统、多硬地校验产出。 近两年爆火的“氛围编程”（vibe coding）现象——开发者全程用自然语言指挥AI生成代码、几乎不看内容——本质上是一次激进的社会实验：**把programming也外包出去，只留需求输入**。它在玩具项目上有效，在真实系统上的代价，正在被各团队用生产事故慢慢计价。 ## 五、批判性审查：哪些说法站得住，哪些要打折 认真对待一条视频，就要指出它哪里经得起推敲。 **站得住的部分**：coding与programming的区分，有Naur、Brooks、Knuth三条独立的理论脉络背书，也与Copilot研究和Stack Overflow调查的实证观察吻合。这是这条视频最坚实的部分——它不是鸡汤，是转述了硬结论。 **需要打折的部分**有三个。 第一，**视频本身没有给出研究证据**。Aaron Jack的论证方式是行业经验+类比，视频里没有引用任何论文或数据。它的结论碰巧与学术脉络一致，但观众应该知道：这两层的“相关性”是解读者的补充，不是视频的原始内容。 第二，**二分法有被夸大的风险**。现实中的programming和coding并非 cleanly 切开的两段——优秀的程序员常常在敲代码的过程中发现解法的问题，写代码本身是思考的一部分。Naur本人恰恰反对把“想”与“写”机械切分，因为理论是在动手过程中不断修正的。如果把这条视频理解成“先在纸上想清楚100%再碰键盘”，那就把一个有用的注意力矫正器，曲解成了僵硬的瀑布流程。更准确的用法是：**以纸面分解为默认起点，允许编码过程中的往返迭代**。 第三，**别用单份研究给AI时代下定论**。围绕AI辅助开发的实证结论仍在激烈摇摆——2025年7月，METR发布了一项引发大量讨论的随机对照研究：资深开源开发者使用AI工具后，实际完成速度反而慢了约19%（据METR公开报告），与GitHub那项“快55.8%”的研究结论方向相反。两者样本、任务类型、开发者水平完全不同，目前任何“AI一定让开发提速/降速”的断言都为时过早。但有趣的是，**无论AI让谁变快变慢，这两个词的区分都成立**：AI改变的是coding环节的成本结构，programming环节的价值锚点依然纹丝不动。 ## 六、认知提升与实用启示 把这条视频变成可操作的三个动作： **1. 给自己做一次“无键盘测试”。** 找一道你最近没做过的编程题，合上电脑，用纸笔写出分步骤解法（每步必须无歧义、可执行），处理至少三个边界情况。写得出来，说明你的programming在位，剩下的只是翻译熟练度；写不出来，你就精准找到了自己的卡点——接下来一个月的训练量，应该全部砸向纸面分解，而不是多背语法。这个测试五分钟就能做完，却能替你省下几个月的错误努力。 **2. 每周做一次“理论重建”练习。** 找一段比你水平高的开源代码（一个函数即可），读完第一遍后**合上屏幕**，用自己的话写下“它在解决什么问题、为什么这样解、换你会怎么解”，再对照原文核对。这是在按Naur的方式训练——代码只是文本，你要重建的是背后的理论。坚持八周，你读代码的深度会和周围人拉开肉眼可见的差距。 **3. 把AI当翻译官，别当架构师。** 使用AI生成代码前，强迫自己先写下两样东西：测试用例清单和边界条件清单。这两样东西就是programming的物化——写它们的过程，就是你保有那套“理论”的过程。然后放心把翻译交给AI，用你的清单校验它的产出。这个习惯让你成为AI的受益者而非替代品：AI负责coding，你守住programming。 --- ## Mermaid：一个需求的两层加工流水线 ```mermaid flowchart TD A[一个模糊的现实问题] --> B[Programming 层
分解 建模 权衡] B --> C{解法想清楚了吗} C -->|没有| B C -->|清楚了| D[伪代码与测试用例] D --> E[Coding 层
语法翻译 可交给AI] E --> F[可运行的代码] F --> G{验证 行为符合预期吗} G -->|不符| B G -->|符合| H[交付] ``` 这张图是整条视频的世界观：左侧的问题进入programming层被拆解成形，中间产物交给coding层翻译——这一段如今可以外包给AI——最后验证环节如果失败，回流的箭头永远指向programming层而不是coding层。**返工的钱，几乎总是花在想错了，而不是敲错了。** ## 延伸阅读 1. **Peter Naur, 《Programming as Theory Building》(1985)** —— 本文理论溯源的主轴，一篇比大多数畅销书更值得重读的软件工程论文。 2. **Fred Brooks, 《No Silver Bullet: Essence and Accidents of Software Engineering》(IEEE Computer, 1987)** —— “本质复杂性vs偶然复杂性”的原始出处，理解AI时代程序员价值的第一把钥匙。 ## 参考来源 1. [Programming vs Coding - What's the difference? | Aaron Jack](https://www.youtube.com/watch?v=CIRGjwYgdT4) — 本文解读对象，播放数据据频道页面 2. [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (Peng et al., 2023)](https://arxiv.org/abs/2302.06590) — AI加速纯coding任务约55.8%的对照实验 3. [Stack Overflow Developer Survey 2024](https://survey.stackoverflow.co/2024/) — “几乎正确但不完全对”成为AI工具最大痛点的调查数据 4. Peter Naur, *Programming as Theory Building*, Microprocessing and Microprogramming, 1985 — “程序即理论构建”原论文 5. Fred Brooks, *No Silver Bullet*, IEEE Computer, 1987 — 本质复杂性与偶然复杂性之分 --- > 本文由「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 等场景全覆盖。