前言
前阵子在公司里，为校招前端训练营分享了一节开营课，主要介绍了前端开发的过去和现状。由于时间关系，当时只是蜻蜓点水般地讲了一点学习前端的建议。
因此，这篇文章可以作为额外补充，分享一下我认为过去对我的成长有帮助，在 AI 时代可能还有用的一些感受和心得。
权当参考，或有启发。正文如下：
一、快速发展的 AI 与前端
AI 将改变前端，就像 AI 将改变其它领域一样。对 AI 改变前端的方式，不同的人心态不同。有人持乐观态度，认为 AI 将改善前端开发；有人持悲观态度，认为 AI 将消灭前端开发。
然而，重要的不是对 AI 的态度，而是我们的动作，特别是积极的动作。如果悲观态度能给你带来积极动作，悲观也不是坏事儿。如果乐观态度却带来消极动作，那么乐观也不算是好事儿。
今天想要和大家一起探讨，AI 时代的前端成长之路，包含哪些积极动作，可以让我们对快速发展的 AI ，有更好的适应力。这些积极动作需要满足以下期待：
- 若 AI 改善了前端开发，我们所提升的能力是有优势的；
- 若 AI 消灭了前端开发，我们所提升的能力是可迁移的；
我们不是在专项地提升所谓前端技能，而是面向更基础的知识与技能做提升，只是恰好首先应用于前端开发领域。但不仅仅适用于该领域，也可以在其它领域得以发展。
乒乓球大魔王张怡宁在一次解说乒乓球比赛时，评价日本乒乓球运动说："日本的小孩儿，他到一定年龄段以后他就不发展了。构不成威胁对中国队。"
所有技能，不管是运动的技能，还是知识的技能，都有类似的发展性问题。缺乏有效的成长方法论，很容易卡在特定瓶颈中，陷入停滞和收敛，长期得不到突破。
在技术领域有很多人嘲弄所谓10年经验的程序员，其实是1年经验用了10年；表面上看是学习意愿问题，实质上背后是过拟合和收敛性导致的不发展问题。不完全是他们不想学习了、不想进步了，这是结果，是后果，而非原因。
当我们投入了很多功夫，却一直难以实质地进步和发展，能得到的正反馈也在不断衰减，甚至陷入恶性循环；整个学习的奖惩回路，不再能支撑持续的学习动作。在这种处境中，任谁也不得不消极起来。
持续成长的关键，是不断地解决每个阶段的发展性问题。持续成长的过程，则是不断地、自觉地应用理论知识到实践的过程，也是不断地、自觉地从实践中提炼抽象理论的过程。
当你感觉不到这种在理论和实践之间来回穿梭的自觉性时，当你难以维持"用理论指导实践，在实践中总结理论"的自觉性时。过拟合就发生了。在成长过程中，我们将要有意识地反复经历下面两种体验：
- "从特殊到一般"的泛化过程，避免过拟合（懂理论/会抽象）
- "从一般到特殊"的特化过程，避免欠拟合（懂实践/会应用）
其中，泛化过程比较稀缺和重要，同时它也是突破瓶颈的关键路径。著名数学家香农1952年在贝尔实验室的内部分享[24]中，便提到:
"Another mental gimmick for aid in research work, I think, is the idea of generalization. This is very powerful in mathematical research. .....there, I think, in terms of engineering, the same thing should be kept in mind. As you see, if somebody comes along with a clever way of doing something, one should ask oneself, 'Can I apply the same principle in more general ways? Can I use this same clever idea represented here to solve a larger class of problems? Is there any place else that I can use this particular thing?'"
不管是数学、工程还是软件工程或其它领域，泛化(Generalization)都是强大的思考工具，需要我们自觉地运用，并培养这种思维习惯。正是一般化的过程，带领我们进入抽象理论的世界，让我们看到更广的景致，找到突破的捷径，从而一次次克服发展性问题。这种思维，在现代有了更时髦的叫法------第一性原理的思考(First-principles thinking)。
这篇文章的后续将包含丰富的泛化过程，尽可能将各个问题还原到它们的第一性原理表述，同时引入诸多不同的理论视角，以便让大家可以在更宏观的角度，理解 AI 时代的前端工程师的处境和应变策略。
二、善用 AI 解决问题
积极拥抱 AI，善用 AI。这些话看起来像正确的废话，但其实并不容易做到，甚至很容易误解自己已经做到。实际上，要做到善用 AI，是有要求的。
在 MIT 发布的 Artificial Intelligence, Scientific Discovery, and Product Innovation[19] 报告中显示：
"while the bottom third of scientists see little benefit, the output of top researchers nearly doubles.
Top scientists leverage their domain knowledge to prioritize promising AI suggestions, while others waste significant resources testing false positives."
在需要动用专业知识对 AI 输出内容做判断的任务中，拥有更强判断力的高水平科学家从中受益更大，而能力水平处于下游的研究人员，则浪费更多时间在假阳性案例中，从 AI 中受益更少。
因此，扎实的基础知识和技术功底，在 AI 时代仍然是重要的。能不能问对问题，要求具备扎实的领域知识；能不能识别 AI 答案里的谬误和幻觉，要求准确的专业判断力。否则容易在以下几种状态中打转：
- 不知道问什么问题
- 问得不够准确，AI 答非所问
- 不能判断真假，浪费时间逐个检验
- 难以充分检验，看似没问题的方案事后暴雷
- 不知道更高效准确的传统解法，硬上了 AI 解法，开销大、准确低、效率差。
归根结底，AI 目前仍是一种工具，工具的威力还是取决于使用者自身的能力。善用 AI，是去做到之前做不到的，去做好之前做不好的，不做之前能做好的。
积极拥抱 AI，既不是减少在领域知识和专业基础的投入，也不是优先用 AI，更不是只用 AI。其实还是在原来的基础上，将 AI 能力用在刀刃上，用在解决之前无法解决或难以解决的问题上。
因此，本文的重点，不在于测评当下流行的 AI 模型、AI编辑器、MCP、Agent 等工具取向的内容。网络上这方面的优秀内容已有很多。我们主要研究的是，在 AI 时代，前端开发乃至软件开发的革新方向。
使用 Cursor, GitHub Copilot, Windsurf 等 AI 代码编辑器，或许已让我们的开发效率提升了 n%，1倍，2 倍或几倍；但仍未改变我们开发软件的方式，我们还是像以前那样写代码，只是通过 AI 辅助编程加快了一些。那么，当 AI 把开发效率、代码量、软件复杂度增加到 10 倍、100 倍乃至更多，多到可以改变软件开发模式的程度时，前端开发或软件开发所面对的新的挑战是什么，主要应对策略是什么的，我们可以如何超前地储备这些知识和技能，以便更好地拥抱和适应 AI 时代的软件开发模式？
如果我们相信，AI 发展是快的，能带来持续不断的提升。那么从长期的角度，除了关注当下几个月的新模型或新工具，也要关心和预测 3年、 5 年乃至10年后的可能情况。特别是对于初入前端的新同学来说，长期角度尤为重要。
因此，这篇文章试图建立一种预测模型，预测 AI 时代的软件开发模式的变化，预测它对软件开发者新的要求，以指导我们学习的重点投入方向，引领我们持续的成长。
三、LLM-based AI 的能力特征
当下流行的 LLM-based AI 是一种程序，很少人能深入其技术细节，但在一定程度上理解它背后的原理和能力特征，对大部分开发者来说还是可以的，对善用 AI 也有很大的帮助。
正如香农在贝尔实验室做内部分享时，说：
"Almost every problem that you come across is befuddled with all kinds of extraneous data of one sort or another; and if you can bring this problem down into the main issues, you can see more clearly what you're trying to do and perhaps find a solution."
几乎所有问题的朴素表征中，都包含很多无关紧要且富有迷惑性的信息，需要我们动用自己的洞察力，把其中关键部分挑出来。所谓抽象，就是去掉不重要的部分，保留最重要的部分。有效的简化，反而更能抓住问题背后的主要矛盾的主要方面，让问题的表征更加具备一般性。
从这个角度，"LLM 是基于 Next-Token Prediction 模式所构建的程序"这个表述，还可以继续降解到更简单和一般的概念。比如 Probability 和 Program。
Next-Token Prediction 是预测下一个字词，那就是基于概率（Probability）的，就受到概率论揭示的性质的影响和约束。比如概率是 0~1 区间里的数值，它在计算上的一个特点是------对乘法敏感。越多的串联因素，越多的乘法，就乘越小。如果我们倾向于让概率值变大，那就要减少乘法的应用数量。
比如在服务器接口稳定性中，常常通过减少调用链长度来提升，越长的调用链，稳定性作为 0~1 之间的数值相乘起来，将使整体稳定性倾向于变小，即便任意一个接口的稳定性都很接近1。
如果我们倾向于让概率值变小，那就要增加乘法的应用数量。比如在错误检测中，通过 double check 可以多应用一次乘法。
概率计算对乘法敏感的这个性质，在接口稳定性里，在 LLM 里，在其它应用场景中，都是一样的。LLM 回答问题的准确率和幻觉率，或者 Workflow/Agent 架构里的整体成功率、准确率，都植根于概率在计算上的数值特征和乘法特征。
LLM 是代码写的一种程序(Program），就受到编程语言与计算机方面的约束，就包含计算上的一些固有特征。比如不同的程序在 verify 和 compute 的难易度方面，拥有不同的性质。
计算机领域著名的NP完全问题（假设P≠NP），在程序上就属于很难计算结果但很容易验证结果（Easy to verify & Hard to compute）。
而 LLM-based AI 作为一种程序，则属于容易输出结果但不容易或不负责验证结果（Easy to generate & Hard to verify）。在这里，generate 其实是 compute 的一种（权重计算）。
编程语言（如 TypeScript）的静态类型检查（Static type checking），作为一种程序，属于容易检查类型标注的正确性，但不容易或不负责输出结果（Easy to verify & Hard to generate）。
那么，在AI 辅助编程的应用场景中，我们就可以根据上述程序上的特征，从理论上推导出一种最佳实践------用 AI 生成 well-typed 的代码，达到容易生成且容易验证的目标（LLM + Static type checking -> Easy to generate & Easy to verify）。
为什么强调用 AI 生成 well-typed 的代码，而不是强调用 AI 生成测试用例？明明后者才是 AI 辅助编程时更普遍的做法。
这是因为，就像著名计算机科学家 Dijkstra 说的那句名言:
"program testing can be used to show the presence of bugs, but never to show their absence!"
程序测试可以用来表明 Bugs 存在，但不能用来表明 Bugs 不存在。
一位谷歌员工曾在问答网站，回答过谷歌开发者日均代码产出行数相关问题[9]。根据他的粗略估计，大概日均150行代码。考虑谷歌有4万名工程师，保守地按日均100行估算，整个谷歌公司日均代码产量为400万。谷歌投入大量技术资源去构建和维系软件交付的基础设施，反复优化各方面的性能，每天运行成千上万次自动化测试，也才达到每位工程师日均150的代码产能的水平。
AI 辅助编程时代，我们要考虑的不只是 2 倍开发效率的提升，而是将来10倍、100倍的提升。可能平均每位工程师日均1500行代码，乃至15000行代码产出，整个部门或公司将日产10亿代码。我们不能只看到十倍、百倍的代码产能提升，而忘记代码产能提升后，对后续代码验证和功能验收的影响。
光靠测试用例，或许能支持日均400万行代码，但测试用例的测试质量和效率，是随代码量的增加而不断下降。
测试用例本质上是一种面向代码的输入和输出所做的关键性采样，属于概率模型。类似蒙特卡罗方法[21]，提供在可接受的模拟成本范围内，得到有一定误差的统计解（代码在多大置信度上没 Bug，0~1区间），但不是精确的"解析解"（代码被证明没 Bug，100%）。
测试用例同时也是一种代码，只是服务于测试另一部分代码。由 LLM 生成的代码，都有大于 0 的错误率， 都需要再做一次检查，否则我们不知道这些测试用例测得到底是什么，是不是我们想要的。
考虑测试用例是发散的，常常比源代码的行数多很多。用 AI 生成更多测试用例，先别说，是不是能在新的代码数量级面前，提供足够的质量保证；光是开发者审阅测试用例的负担，都不容小觑。 测试用例的人工评审效率，将成为软件交付的新瓶颈。
类似的情况在多个行业中都存在，当 LLM 让专业材料的日均产量提升了十倍百倍，工作的瓶颈就转移到专业材料的验证成本和效率上。不管这个专业材料，是程序员的代码、数学家的定理证明，还是别的论文、小说、视频等。
特别是数学证明，早在 LLM 提升数学家的日均定理证明产量之前，他们已经遇上验证的成本和正确性问题了。菲尔兹奖得主、著名数学家 Voevodsky 在 2014 年的一场分享[3]中，提到：
"In October, 1998, Carlos Simpson submitted to the arXiv preprint server a paper called 'Homotopy types of strict 3-groupoids'. It claimed to provide an argument that implied that the main result of the '∞-groupoids' paper, which M. Kapranov and I had published in 1989, can not be true.However, Kapranov and I had considered a similar critique ourselves and had convinced each other that it did not apply. I was sure that we were right until the Fall of 2013 (!!)."
Voevodsky 坚信他和 M. Kapranov 一起做的证明是对的，即便别的数学家(Carlos Simpson)曾经指出反例（但未从证明过程角度指出问题），他们也坚信了20年。这个纠错周期，跨度实在太大了。
菲尔兹奖得主、著名数学家陶哲轩在去年年底的一个访谈中[20]，也提到：
"Math can be very fragile: If one step in a proof is wrong, the whole argument can collapse. If you make a collaborative project with 100 people, you break your proof in 100 pieces and everybody contributes one. But if they don't coordinate with one another, the pieces might not fit properly. Because of this, it's very rare to see more than five people on a single project."
过刚者易折。数学证明要求极致的严谨，就使得数学家们大型团队协作式证明变得脆弱。
计算机科学家和数学家 Samuel R. Buss 在他的书籍 An Introduction to Proof Theory[7] 里指出，数学证明有 Social proof 和 Formal proof 的分别，他这样说道：
"There are two distinct viewpoints of what a mathematical proof is. The first view is that proofs are social conventions by which mathematicians convince one another of the truth of theorems. That is to say, a proof is expressed in natural language plus possibly symbols and figures, and is sufficient to convince an expert of the correctness of a theorem. Examples of social proofs include the kinds of proofs that are presented in conversations or published in articles. Of course, it is impossible to precisely define what constitutes a valid proof in this social sense; and, the standards for valid proofs may vary with the audience and over time. The second view of proofs is more narrow in scope: in this view, a proof consists of a string of symbols which satisfy some precisely stated set of rules and which prove a theorem, which itself must also be expressed as a string of symbols. According to this view, mathematics can be regarded as a 'game' played with strings of symbols according to some precisely defined rules. Proofs of the latter kind are called "formal" proofs to distinguish them from "social" proofs."
简单地说，不能由计算机去机械地完成的数学证明，都可以视为服务于说服其他数学家的社交式证明(Social proof)，不能保证其精确意义；反之，可以由计算机完成的纯符号式规则推理，不需要在社交层面说服任何人，则是形式化证明(Formal proof)。
但社交式数学证明也是有规范要求的，有价值的，不能因为可能有瑕疵而被看低。正如 Samuel R. Buss 紧接着说：
"In practice, social proofs and formal proofs are very closely related. Firstly, a formal proof can serve as a social proof (although it may be very tedious and unintuitive) provided it is formalized in a proof system whose validity is trusted. Secondly, the standards for social proofs are sufficiently high that, in order for a proof to be socially accepted, it should be possible (in principle!) to generate a formal proof corresponding to the social proof. Indeed, this offers an explanation for the fact that there are generally accepted standards for social proofs; namely, the implicit requirement that proofs can be expressed, in principle, in a formal proof system enforces and determines the generally accepted standards for social proofs."
他指出 Social proofs 标准必须足够高，能够和 Formal Proofs 足够接近，以至于可以从 Social proofs 中生成 Formal proofs------"it should be possible (in principle!) to generate a formal proof corresponding to the social proof. "。
Samuel R. Buss 的 An Introduction to Proof Theory 发表于 1998年，当时还没有我们今天这么丰富的 AI 工具，只能从原则上、从概念上， 指出 Social proofs --in principle--> Formal proofs 的转化路径。
而 2024 年年底的陶哲轩的观点，则是将其中的 "in principle" 具现化：Social proofs --LLM--> Formal Proofs。不只是概念上、原则上、大体上可以转化，而是通过 LLM 去实际上完成这种转化。他说:
"...proof assistants are useful computer tools that check whether a mathematical argument is correct or not.
The dream is that you just have a conversation with a chatbot explaining your proof, and the chatbot would convert it into a proof-system language as you go."
陶哲轩认为 proof assistants 是数学家们大规模协作的重要支撑。通过跟 AI 对话去生成 Lean 等编程语言的代码去做形式化数学证明，其实也符合 LLM + Static type checking 的最佳实践。
因为 Lean 等编程语言背后，是通过Curry-Howard Isomoprhism 将数学里的命题和程序里的类型关联起来的------Propositions as types[6]，命题即类型。类型(Type)这一概念，不只是编程领域用来优化代码的辅助工具；它还有这深厚的数学渊源，是数学、逻辑学和计算机科学中的一个重要分支------类型论(Type Thoery)[25]里的核心研究对象。
陶哲轩近期便上传了几个视频演示这种转化过程，比如 Formalizing a proof in Lean using Github copilot and canonical[8]。
前文提到的数学家 Voevodsky 也早就决心拥抱 proof assistant。他再也不想在发表论文后，常年担惊受怕哪一天突然被证伪了；他后来因此提出了著名的 Homotopy Type Theory[2]，不仅是 Agda 等编程语言的理论基础，甚至与 Category Theory 一样有望替代 Set Theory 作为新的数学基础。Voevodsky 说:
"I now do my mathematics with a proof assistant and do not have to worry all the time about mistakes in my arguments or about how to convince others that my arguments are correct.But I think that the sense of urgency that pushed me to hurry with the program remains. Sooner or later computer proof assistants will become the norm, but the longer this process takes the more misery associated with mistakes and with unnecessary self-verification the practitioners of the field will have to endure."
软件开发和自动化定理证明是相近的，理念也是相通的。Samuel Mimram 在 2020 年发表的书 PROGRAM = PROOF 中，强调了程序代码和数学证明之间的同构关系。其中一节专门对比了 Proving 和 Testing 的差异；在书中，他提倡用证明替代测试(Proving instead of testing) 用类型作为论证(Typing as proving)。
"But how can we achieve this goal of applying techniques of proofs to programs?
It turns out that we do not even need to come up with some new ideas, thanks to the so-called proof-as-program correspondence discovered in the 1960s by Curry and Howard: a program is secretly the same as a proof! More precisely, in a typed functional programming language, the type of a program can be read as a formula, and the program itself contains exactly the information required to prove this formula. This is the one thing to remember from this course: PROGRAM = PROOF"
Samuel Mimram 指出，用证明替代测试的方式，并非引入额外的概念和工具，使用的还是编程语言里已有的类型概念，但引入一种新的解读，将类型视为命题，将程序视为证明，通过静态类型检查去保证证明或程序的正确性。Samuel Mimram 还列举了几个经典案例，摘录其中一个如下：
"in 2015, some researchers found out, using formal methods, that the default sorting algorithm (the one in the standard library, not some obscure library found on GitHub) in both Python and Java (not some obscure programming language) was flawed, and the bug had been there for more than a decade "
工业界主流编程语言 Python 和 Java 的标准库里的排序算法，尽管都经过千锤百炼的测试验证，但都被形式化方法找到了瑕疵。
Samuel Mimram 说的用证明替代测试，具体实践起来，其实就是在软件开发时，强化类型的重要性和优先性，增加类型表达的精细程度，以进一步发挥 Type checker 的作用。越强的 Type System，越精细的类型表达，越能保证程序的正确性。从 Test-Driven Development 的朴素实践，转向 Type-Driven Development 的新实践，用更多的证明(Typing)去替代测试（Testing)。
类型不是一个附加的、次要的、额外的事物，而是核心的、主要的、内在的事物。类型不只是对代码的事后补充，也可以是更优先的宏观设计，去约束代码编写或代码 AI 生成的可靠工具，提供比测试更多的正确性。
一篇论文 Type-Constrained Code Generation with Language Models[15] 中提供了一个统计数据：
"For instance, in our evaluation of state-of-the-art open-weight LLMs, syntactic errors make up on average 6% of all compilation errors in generated TypeScript code.
In our evaluation , 94% of the LLM-generated compilation errors result from failing type checks"
在一个 LLM 生成的 TypeScript 代码的数据集里，检查出来的编译错误中，语法错误占比 6%，类型错误占比 94%。那么，设想没有类型标注和检查，这 94% 的错误将难以静态地检查出来，则泄露到 runtime 中去报错，要额外写很多测试用例，或者人工测试去更大成本地捕捉出来。
同样都有类型标注，也有精确程度的高下之别。更加精确的类型标注，可以通过类型检查找到更多程序问题。所以，更好的 AI 辅助编程，将包含更精细的类型标注，甚至采用 Type-First Development 或 Type-Driven Development 开发模式。即先做类型设计，再写代码实现。有一些编程语言早就洞见了类型驱动开发的价值，在 AI 时代之前就开始这样倡导了。
比如 Idris 编程语言在其官网上这样介绍自己："Idris is a programming language designed to encourage Type-Driven Development.
In type-driven development, types are tools for constructing programs. We treat the type as the plan for a program, and use the compiler and type checker as our assistant, guiding us to a complete program that satisfies the type. The more expressive the type is that we give up front, the more confidence we can have that the resulting program will be correct."
Idris 提倡将类型视为程序代码的规划，在规划的指引下，编写满足类型约束的代码。这要求我们延迟写具体代码，先做类型设计。在 AI 时代，这种做法包含更大的助益，可以让开发者少写甚至不用亲自写代码实现。类型设计将指引 LLM 去自动生成具体代码实现。
因此，类型设计阶段做得越精细，包含的信息量越大，它作为 Prompt 的一部分对 LLM 的指引效果，和 Static-type-checking 效果，都有机会更好。
这对开发者的类型编程能力，提出了新的要求，也指引了新的竞争力所在------掌握更强的类型编程能力。已有很多高职级前端工程师因 TypeScript 技能不足而错失工作机会的案例；特别是前端基建相关工作，类型编程的能力和意识比较薄弱的开发者，写出的代码或设计的 API，对团队来说可能是不可信和不可接受的。
对代码的类型安全的更高要求，将首先发生于基建/框架团队，再逐渐蔓延和渗透到业务开发团队。AI 辅助编程则加速这一进程。
不只是对开发者的类型编程能力提出要求，同时也对开发框架的类型友好程度提出了新的要求。Well-typed 的程度，作为新的框架考察维度，将带来新的框架设计空间和竞争优势。
在原有的 JavaScript 框架上标注几个类型，常常不能充分发挥类型检查的价值。而用 Type-first 的思路重新审视和构建，很多时候可以带来全新的思路和面貌。比如在《Farrow 介绍：类型友好的函数式风格 Node.js Web 框架》中，我介绍了我的开源项目 Farrow，它便是以类型友好为设计目标，克服了 Express.js/Koa.js 中在类型方面未能解决的一些问题。
那么，是不是说，以后软件是 Lean/Agda/Idris 等 Formal Proofs 编程 语言开发的，而其它编程语言没有机会了？也不尽然。安全性只是其中一个竞争维度，还有其它竞争维度。
Haskell 的核心开发之一 Simon Peyton-Jones 在 2017 年的一个分享Escape from the ivory tower: the Haskell journey[59] 中，描绘了一个有趣的坐标图：
安全性和实用性坐标。有的语言（如 Haskell）是从安全性出发，在保证安全的情况下，增加 IO 能力，向实用性靠拢。而我们使用的大部分主流语言，则是从实用性出发，在保证足够的实用性的情况下，通过 Type System 等的约束方式，增加安全性。 安全但不实用 vs 实用但很危险。最终大家的目标都是，既安全又实用。
每个编程语言，都在安全性、易用性、社区繁荣程度等多个竞争维度所组成的坐标系的某个位置，它们都有机会面向 AI 不断迭代，去发挥自己的优势、弥补自己的短板，寻找更加有利的位置。并且，可能面向不同领域，AI-Oriented Programming Language 的设计不完全一样，术业有专攻，而非一赢通吃局面。
如上，我们通过挖掘 LLM-based AI 背后的基础理论要素------概率（Probability）和程序（Program），用它们的基本性质，更好地理解了 LLM 的行为特征（Easy to generate, Hard to verify），同时推导出了 AI 辅助编程的最佳实践（LLM + Static type checking），并且得到了相关论文和数学家使用案例的一些佐证。
LLM + Static type checking，这个表述其实也还不够对称，不够优雅，我们可以进一步提炼为------概率模型 + 演绎模型。LLM 是基于 Next-Token Prediction 工作模式的概率模型，而 Static type checking 则是基于"公理"和"推导规则"进行演绎推理的演绎模型。
用概率模型处理不确定性问题，用演绎模型去处理确定性问题。当一个问题可以或容易确定性地处理时，优先确定性处理。如此，LLM + Static type checking 背后，其实是从概率模型中衍生出演绎模型的输入，用演绎模型检查概率模型的生成产物，从不确定性中搜索和沉淀出确定性的过程。
有了上面这种理解，当你下一次看到有开发者表达"AI 让编程语言设计不再重要"、"AI 让框架设计不再重要"等观点时，就不容易被带歪了。在 AI 时代，编程语言设计和框架设计，不是更不重要，而是更重要；编程语言提供的静态检查能力，框架设计提供的领域知识表达上的约束能力，是 AI 辅助编程的质量保证所在。
上面是一种乐观的未来图景。尽管有更大代码量、更大软件复杂度的挑战，但开发者的开发工作仍然是被肯定的，甚至更加重要了。另一种悲观的未来图景是，每位开发者日均代码产能提升，不会带来显著的总代码产出和软件规模的增加，而是带来裁员，减少开发者数量。让更少的人去做更多的事情，但总的事情不变；而非用同样多的人或更多的人，去做更大的事情。查看全文>>>