认知框架

本模块收录理解 LLM 所需的关键心智模型，帮助你建立对 LLM 的系统性认知，避免常见误区。

1 Software 1.0 / 2.0 / 3.0 范式

它是什么

Andrej Karpathy 提出的软件演进范式（2017 年提出 Software 2.0，2025-2026 年演化为三范式框架）：

Karpathy 在 2026 年 Sequoia Ascent 演讲中给出了 Software 3.0 的核心类比：

Context Window = RAM（工作内存）
Model Weights  = CPU（固定处理基底）
Prompting      = Programming（编程行为）

Software 3.0 的本质不是"更快的编码"，而是一类"以前根本不可能"的事。Karpathy 提出的 Founder 问题是：不是"什么能做得更快？"，而是"什么软件应该彻底消失，不再以软件形式存在？"

为什么重要

它帮助你定位 LLM 在技术谱系中的位置：

• 不是对 Software 2.0 的替代，而是对特定任务的补充

• 不是对 Software 1.0 的替代，传统代码在可预测性、性能、安全上仍有优势

• 编程范式的迁移：从"写逻辑"（how）到"写目标"（what）再到"写意图"（intent）

实践含义

Agent-Native 产品设计：随着 Software 3.0 的普及，数字信息的消费者从两类变为三类——GUI（人类）、API（程序）、自然语言（Agent）。这意味着产品需要同时面向三类消费者设计：Markdown 文档替代 PDF、CLI/API 替代 Dashboard、MCP 服务器提供结构化数据访问。

2 LLM 是 Ghost 不是 Animal — 锯齿状智能

它是什么

Karpathy 的比喻：LLM 像 Ghost（数字拟像），不像 Animal（有生存本能的生物）。

Karpathy 将预训练比作"低配版进化"：从随机权重开始，在互联网文档上做模式补全，同时获取知识和启动"智能电路"。但知识部分可能反而拖累模型，使其过度依赖记忆而非推理。

信息密度差异是理解"幽灵"本质的核心数据：

3500 万倍的信息密度差异，解释了为什么上下文学习比权重记忆更"智能"。

锯齿状智能（Jagged Intelligence） 是这一认知框架的直接推论：同一模型可以重构 10 万行代码库（高可验证性领域有强 RL 信号），却在"开车去洗车"这种常识判断上不及格（低可验证性领域无 RL 信号）。

为什么重要

这个框架帮助你避免"泛化能力错觉"：

• 不要因为 LLM 在代码领域表现好，就假设它在医疗领域同样可靠

• 不要因为 LLM 能写文章，就假设它能做精确的信息提取

• 不要因为某次效果好，就假设所有场景都可靠

• 不存在"通用智能"——只有特定训练范围内的能力涌现

实践含义

3 Vibe Coding vs Agentic Engineering

它是什么

Karpathy 在 2025 年提出的两种开发模式：

Agentic Engineering 的核心工作流（Karpathy，2025 YC Talk）：

1. 写设计文档（可由 AI 辅助）
2. 将工作分解为定义良好的任务
3. 给 AI Agent 指定任务
4. 以与人类 PR 相同的严谨度审查代码
5. 测试、测试、测试
6. 拥有整个系统

Karpathy 的关键洞察：

为什么重要

它帮助你理解 LLM 应用的两个阶段：

• 不要在原型期过度工程化：会浪费时间和精力

• 不要在生产期继续 Vibe Coding：会引入不可预测性和风险

• 两种模式需要不同的工具和流程

适用边界

社区实践中形成的共识：

Vibe Coding 适合：快速原型和 Hackathon、一次性脚本和内部工具、Greenfield 开发（谨慎使用）、学习探索和头脑风暴。

Vibe Coding 不适合：精品赛道（支付、风控、医疗、基础设施）、长期维护项目、安全敏感系统。

判断标准：如果你只是让 AI 一气写几千行，自己也读不太懂，那不是生产力提升，是技术债分期付款。今天省的两小时，上线后变成二十小时复盘。

实践含义

Vibe Coding 阶段（推荐用于原型）：

• 直接与 LLM 对话，手动验证效果

• 快速迭代 Prompt，不追求完美

• 关注"这方向对不对"，而非"这代码完美吗"

• 目标是验证假设，而非交付产品

Agentic Engineering 阶段（生产必需）：

• 建立 Prompt 版本管理（Git 或工具）

• 建立自动化测试（单元测试、集成测试）

• 建立 A/B 测试框架

• 建立监控和告警

• 目标是稳定、可维护、可扩展

对资深工程师 vs 初级工程师的差异：Agentic Engineering 对资深工程师的收益远大于初级工程师。资深工程师的系统设计知识、安全模式理解和性能权衡经验，使其能有效 review AI 输出；初级工程师可能产生自己无法理解的代码。

4 可验证性框架

它是什么

Karpathy 的可验证性框架（2025）：

核心命题：任务的可验证性决定了 AI 能力的边界。可验证性不是二元划分，而是一个谱系：

Jason Wei 的验证者定律（Verifier's Law）提供了更精确的表述：

可验证任务需满足的五大特性：

验证的不对称性是核心机制：AI 能力的进化速度取决于"生成→检验→改进"迭代循环的效率，而循环效率完全取决于验证器的质量和成本。这就是为什么代码、数学等高可验证领域 AI 进步飞速，而战略规划、心理咨询等低可验证领域 AI 难以突破。

验证者溢价

Yu's Space 的 TVI（Task Verifiability Index）研究将 923 个职业按可验证性和 AI 暴露度分为四个象限：

一个值得注意的区分："Computer Programmers"（TVI=3.66）落在替代区，"Software Developers"（TVI=3.23）落在溢价区——差别在于软件开发包含架构设计、需求分析等验证成本更高的环节。

核心洞察：当生成变得廉价后，能够判断产出质量好坏的人类判断力反而变得更加稀缺和有价值。这被称为验证者溢价（Verifier Premium）。

为什么重要

它帮助你决策哪些任务适合用 LLM 自动化：

• 高可验证性任务：可以大胆自动化，错误会被立即发现

• 中可验证性任务：可以半自动化，需要人工抽查

• 低可验证性任务：谨慎自动化，或者设计人工验证机制

实践含义

通过前置工作提升可验证性：在解题前准备标准答案、在编程前编写测试用例，可以显著扩展 AI 能有效处理的任务范围。