感觉事情时不时的会超出预料。本来打算 8 月初调下宿舍，后面说再等等会有低楼层。索性趁着这段空档期回家一段时间。最近又知道调宿舍的日期又要延后了。如果我改签下车票，在家多待几天也不是不可能。不过之前填的返校日期是这两天，继续待不太靠谱。懒得改签，明天回校。后面干什么？现在还不知道。

我感觉至少上交基本不会检查你是否按期到宿舍吧🤔

这倒不是学校层面的查，给导师交的是这个日期。虽然可能晚回几天也没啥事

没想到土塬的皮革兔竟然是动态的, 哈哈哈

土塬的表情太搞笑了哈哈哈哈

居然还有来自水源的门友 震惊（）

昨天本来想写开楼题记 结果写不出题记 但是写完了对首考后直至高考的经历的回忆

终章

不知不觉地，高三下的一百余天在日复一日的学习、问问题、找老师聊天等活动中度过了。我在一个个因学习重复内容而感到厌倦的瞬间希望快点到来的高考，也是真正到来了。

与首考相比，高考时的心态还是较为平稳的，没有出现因为焦躁恐惧而引发的失眠。高考和高中的其他考试，似乎也没有特别明显的区别，因此我对它也没有什么单独的、特别突出的印象。我现在只能记得数学考试前，和我的朋友一起遇到数学老师，然后老师说了一句“两个高手”，我们在去考场路上拼尽全力想要淡忘这四个字，不让它影响自己的心态；以及考完英语后，我认为自己续写内容毫无希望，在路上遇到英语老师后忍不住诉苦了好几分钟，老师只能无奈地安慰（虽然事后的分数表明，实际上续写肯定没有扣很多分🤣）。

6 月 10 日早上考完生物后去估分，我惊喜地发现自己数学小题都对，18（3）猜出了大致答案（后来才知道开闭区间错了）。要走的时候，遇到了一位认识的英语老师，他问我语法填空如何，我说全对，而后回答怎么做的时候只能说是凭语感。那位老师顺手递给我两个小桃子，很甜，我在走回家的路上 🐖完了。

由于估分花了一定时间，走出校门时，门外的人群已经散尽，我沿着熟悉的路线走回出租屋，和来时一样，独自一人。

我不怀念高中，接下来说出的话不包含任何意义上的 nostalgia，但我依旧很想说出来：

我直到现在，再也没吃过那么好吃的小桃子了。

前排留名

删除老师好🥰

西交有什么好玩的吗？
我没有同学在西交，所以有点好奇的
土塬里没有人吗？怎么感觉都是 SJTU 的！ 🫠

可以来虾饺东一楼做数电实验，贼有意思

西郊兴庆校区北门马路对面有一个兴庆宫公园，大小大概跟兴庆校区差不多 🐁

【現在公開可能な情報】

关于我：北方县城小镇做题家，老家在乡村，但只有过年会回去，基本没有乡村生活经验。

关于选调：考公的一种给部分大学（985+）优待的路径，相对省考/国考竞争相对较小；早期规模较小，考上的基本都成为了储备干部，随着规模增加，实质上除了两年基层锻炼外与正常考录没多大区别。（在省直和中央单位可能还有一定优势，因为提拔到处级需要硬性要求两年基层经验，刚录用时就先刷完可以避免科级提处级时下乡锻炼与单位脱节，不过近年来不满足基层条件破格提拔的也多了起来）

关于行政级别：我国实行省市县乡四级体制
省：自治区 直辖市 SAR
市：一般都叫市
县：市辖区 县级市 县
乡：乡 镇 街道
再往下就不是行政体制，而是自治机构，包括村（农业区）和社区（城区）

关于村里：旁边就是镇政府驻地，由于镇主要在做土地承包，所以村已经没有农业用地，所有集体土地均作为建厂用地承包给企业，村集体收入主要依赖土地租金收入。
村民人数在中 k 级别，村委会 10+ 人，村集体资产在千万级别。

厉害，感兴趣

优秀门友，我的榜样

今天早上又看见在招生了....
.

本科本校听说这个老师挺厉害的，人品也可以，上过他的体系结构课程，确实能感到思维清晰很熟悉硬件相关内容。
其他细节和科研不清楚

貌似任老师是大导，这个实验室实际上是下边的小导负责，毕竟任老师也不做 ai

现代软件工程实践：AI 编程智能体、代码质量与工程协作

基于 MIT The Missing Semester 三个主题的系统化教程

• 第一部分：Agentic Coding（AI 编程智能体）
• 第二部分：Beyond the Code（软件工程沟通与协作）
• 第三部分：Code Quality（代码质量与自动化工程实践）

导言：从编写代码到交付可靠的软件

传统计算机课程通常比较关注算法、数据结构、编程语言和操作系统。但是，在真实的软件开发工作中，仅仅掌握这些知识是不够的。

一个软件工程师还需要解决以下问题：

1. 如何快速理解一个陌生的软件项目？
2. 如何借助 AI 完成代码开发，同时保证代码正确？
3. 如何发现代码中的潜在错误？
4. 如何自动执行代码检查和测试？
5. 如何让其他开发者理解自己的代码？
6. 如何与团队成员协作开发？
7. 如何提交高质量的代码修改？
8. 如何确保软件能够长期维护？

这三个主题共同回答了这些问题。

1. 软件工程的三个层次

我们可以将现代软件工程划分为三个层次。

第一层：Software Development（软件开发）

核心问题：如何把需求转化为代码？

涉及：

• 需求理解
• 代码阅读
• 功能实现
• AI 辅助编程
• 代码重构

对应第一部分 Coding Agents。

第二层：Software Quality Assurance（软件质量保证）

核心问题：如何确保代码正确、稳定和可靠？

涉及：

• 代码格式化
• 静态分析
• 类型检查
• 自动化测试
• 持续集成

对应第三部分 Code Quality。

第三层：Software Engineering Collaboration（软件工程协作）

核心问题：如何让不同的人共同理解、开发和维护软件？

涉及：

• 技术文档
• 代码注释
• Git 提交记录
• Bug Report
• Pull Request
• Code Review
• 开源社区协作

对应第二部分 Beyond the Code。

三个层次不是独立的。

例如，当 AI 修改了一段代码后：

• Coding Agent 负责实现修改。
• Code Quality 工具负责验证修改。
• Code Review 负责判断修改是否值得合并。
• 技术文档负责记录修改背后的设计决策。

2. 本教程的贯穿案例

为了避免知识点彼此孤立，我们将围绕一个小型 Python 项目进行学习。

项目名称：Markdown Link Extractor

目标：开发一个命令行工具，从 Markdown 文件或网络资源中提取链接。

最终项目结构：

markdown-link-extractor/
│
├── AGENTS.md
├── README.md
├── pyproject.toml
├── uv.lock
├── .gitignore
├── .pre-commit-config.yaml
│
├── src/
│   └── link_extractor/
│       ├── __init__.py
│       └── cli.py
│
├── tests/
│   ├── test_extract.py
│   └── test_cli.py
│
└── .github/
    └── workflows/
        └── ci.yml

我们将逐步完成：

1. 使用 AI 编程智能体开发程序。
2. 为程序添加类型注解和自动化测试。
3. 配置 Formatter 和 Linter。
4. 配置 Git Pre-commit Hooks。
5. 配置 GitHub Actions。
6. 编写 README 和技术文档。
7. 创建 Git Commit 和 Pull Request。
8. 通过 Code Review 完成软件交付。

第一部分：Agentic Coding（AI 编程智能体）

第 1 章 理解 AI 编程智能体

1.1 从传统编程到 AI 辅助编程

传统软件开发通常遵循以下过程：

需求
 ↓
程序员分析问题
 ↓
编写代码
 ↓
运行程序
 ↓
发现错误
 ↓
修改代码
 ↓
重新测试

随着大语言模型的发展，程序员可以将部分开发任务交给 AI。

例如：

• 解释一个陌生项目。
• 根据需求生成函数。
• 修改已有代码。
• 编写单元测试。
• 修复类型检查错误。
• 重构大型模块。
• 分析 Git 修改记录。

但需要区分三种 AI 编程方式。

1.1.1 AI Autocomplete（智能代码补全）

这是最基础的 AI 编程辅助方式。

例如：

def calculate_average(numbers):

AI 根据上下文预测后续代码：

    return sum(numbers) / len(numbers)

特点：

• 以局部代码补全为主。
• 通常不需要复杂的任务规划。
• 适合减少重复编码。
• 程序员仍然主导整个开发过程。

1.1.2 Inline Chat（代码编辑器中的 AI 对话）

程序员可以选中一段代码，让 AI：

• 解释代码。
• 优化代码。
• 增加注释。
• 修改函数。
• 转换编程语言。

例如：

将这个函数重构为三个独立函数，
分别负责数据验证、数据处理和结果输出。

AI 根据要求生成修改建议或直接修改选中的代码。

1.1.3 Coding Agent（AI 编程智能体）

Coding Agent 的能力更进一步。

它不仅生成代码，还可以操作开发环境。

例如：

请分析这个项目。

找到处理用户登录的代码，
增加密码长度验证，
补充相应的单元测试，
运行测试和类型检查，
直到所有检查通过。

Agent 可以自主执行一系列操作：

1. 查找项目文件。
2. 阅读相关代码。
3. 确定需要修改的位置。
4. 修改代码。
5. 创建测试。
6. 执行测试。
7. 根据错误继续修改。
8. 总结最终结果。

这就是 Agentic Coding。

1.2 Coding Agent 的核心架构

要理解 Coding Agent，首先需要理解它不是一个单独的语言模型，而是由多个部分构成的系统。

1.2.1 LLM：大语言模型

LLM（Large Language Model）是 Coding Agent 的核心推理和文本生成组件。

从课程采用的高层模型来看：

给定输入字符串，模型根据训练得到的概率分布预测后续 Token。

可以写成：

[
P(y\mid x)
]

其中：

• (x)：输入 Prompt。
• (y)：模型生成的输出。
• (P(y\mid x))：给定输入时生成某个输出的概率。

在编程任务中：

输入可以是：

• 用户的需求。
• 项目源代码。
• 终端输出。
• 历史对话。
• 外部文档。

输出可以是：

• 解释。
• Python 代码。
• 修改建议。
• 工具调用请求。

需要注意，LLM 的输出是概率生成结果，并不意味着它已经通过程序运行验证。

1.2.2 Agent Harness：智能体运行框架

Agent Harness 是连接语言模型与外部工具的程序。

它负责：

• 将上下文发送给模型。
• 识别模型生成的工具调用请求。
• 执行对应工具。
• 将执行结果反馈给模型。
• 管理对话和工具调用过程。
• 根据权限策略决定是否需要用户确认。

例如，模型可能生成一个执行测试的工具调用请求：

Tool: Terminal

Command:
pytest tests/

Harness 负责执行命令，并将结果返回模型。

模型随后根据结果决定下一步。

1.2.3 Tools：外部工具

常见工具包括：

1.2.4 Agent Loop：智能体循环

Coding Agent 最重要的工作机制是反复执行：

Observe → Think → Act → Observe

即：

观察 → 分析 → 行动 → 再次观察。

例如：

用户提出需求
    ↓
Agent 阅读项目
    ↓
Agent 分析代码结构
    ↓
Agent 修改代码
    ↓
Agent 运行测试
    ↓
测试失败？
  ↙       ↘
 是         否
 ↓          ↓
分析错误    汇报结果
 ↓
重新修改
 ↓
重新测试

这就是为什么允许 Agent 运行测试工具特别重要。

如果 Agent 只能生成代码，却不能获得测试反馈，它就很难建立可靠的自动修正循环。

第 2 章 如何正确使用 Coding Agent

2.1 从模糊需求到明确任务

一个常见错误是只告诉 Agent：

帮我优化这个项目。

这个需求过于模糊。

Agent 不知道：

• 哪些地方需要优化？
• 是性能还是可维护性？
• 是否允许改变 API？
• 是否可以修改项目结构？
• 如何判断优化成功？

更好的方法是把需求拆分为五个部分。

任务描述模板

Task:
需要完成什么任务？

Context:
当前项目是什么情况？
涉及哪些文件和功能？

Constraints:
有哪些不能违反的限制？

Acceptance Criteria:
什么情况下认为任务完成？

Verification:
应该运行哪些检查？

例如：

Task:
将现有 Markdown 链接提取脚本改造成命令行程序。

Context:
当前程序通过 urllib 下载 Markdown 文件，
使用正则表达式提取链接。

Constraints:
1. 使用 Python 标准库。
2. 保留现有提取逻辑。
3. 不引入不必要的第三方依赖。
4. 使用类型注解。

Acceptance Criteria:
1. 支持通过命令行传入 URL。
2. 支持将结果输出到终端。
3. 支持将结果保存到文件。
4. 网络请求失败时给出清晰错误信息。

Verification:
运行 pytest。
运行 mypy。
运行 ruff。

这种任务描述比简单的自然语言要求更容易得到可靠结果。

2.2 实践：让 Agent 改造一个 Python 程序

原课程给出了一个示例。

首先有一个简单程序：

from urllib.request import urlopen
import re

def download_contents(url: str) -> str:
    with urlopen(url) as response:
        return response.read().decode("utf-8")

def extract(content: str) -> list[str]:
    pattern = r"\[.*?\]\((.*?)\)"
    return re.findall(pattern, content)

print(
    extract(
        download_contents(
            "https://example.com/document.md"
        )
    )
)

这个程序有几个问题：

1. URL 被写死在代码中。
2. 无法通过命令行传入不同 URL。
3. 缺少完善的错误处理。
4. 没有定义清晰的程序入口。
5. 还没有建立自动化测试。

现在让 Coding Agent 将其改造成命令行程序。

目标结构：

import argparse
import re

from urllib.request import urlopen


def download_contents(url: str) -> str:
    with urlopen(url, timeout=10) as response:
        return response.read().decode("utf-8")


def extract(content: str) -> list[str]:
    pattern = r"\[.*?\]\((.*?)\)"
    return re.findall(pattern, content)


def main() -> None:
    parser = argparse.ArgumentParser()

    parser.add_argument(
        "url",
        help="Markdown document URL"
    )

    args = parser.parse_args()

    content = download_contents(args.url)

    links = extract(content)

    for link in links:
        print(link)


if __name__ == "__main__":
    main()

运行：

python main.py https://example.com/document.md

这里使用了 Python 的 argparse 模块。

它负责解析命令行参数。

例如：

python main.py --help

可以显示程序使用说明。

进一步改进

可以继续要求 Agent：

请进一步改进这个程序：

1. 增加输出文件参数 --output。
2. 网络请求失败时返回非零退出状态。
3. 对输入 URL 进行基本检查。
4. 为 extract 编写单元测试。
5. 使用 mypy 检查类型。
6. 使用 Ruff 检查代码质量。

这里需要特别注意：

课程中的正则表达式是一个简单的 Markdown 链接提取示例，不是完整的 Markdown 解析器。对于包含嵌套括号、转义字符等复杂情况的 Markdown，需要更完善的解析方案。

2.3 让 Agent 形成闭环

最重要的不是让 AI 生成更多代码，而是让它能够验证自己的修改。

推荐工作方式：

明确需求
  ↓
阅读代码
  ↓
制定修改方案
  ↓
执行修改
  ↓
运行测试
  ↓
检查失败信息
  ↓
修改
  ↓
再次验证

可以使用如下 Prompt：

请不要只根据代码阅读结果判断任务完成。

你需要：

1. 修改相关文件。
2. 运行项目已有的测试。
3. 运行类型检查。
4. 运行 Linter。
5. 检查失败原因。
6. 修复你造成的问题。
7. 再次执行全部检查。

最后列出：
- 修改了哪些文件
- 解决了什么问题
- 执行了哪些检查
- 哪些检查通过
- 还有哪些未解决的问题

注意：Agent 声称检查通过，不等于检查确实通过。需要查看实际终端结果。

第 3 章 Coding Agent 的主要应用场景

3.1 Feature Implementation：新功能开发

任务：为一个已有程序增加功能。

例如：

为现有用户管理系统增加 CSV 导出功能。

要求：
- 支持选择导出字段。
- 支持 UTF-8 编码。
- 不修改原有查询 API。
- 为正常情况和异常情况增加测试。

适用场景：

• 增加功能。
• 编写重复代码。
• 扩展 API。
• 增加命令行参数。
• 实现数据处理逻辑。

3.2 Error Fixing：错误修复

当编译器、Linter、Type Checker 或测试出现错误时，可以将错误信息交给 Agent。

例如：

运行 mypy 后出现以下错误：

Incompatible return value type

请分析原因并修复。
不要通过简单关闭类型检查规则来消除错误。

为什么要避免只关闭规则？

因为这可能只是隐藏了问题，并没有真正修复问题。

3.3 Refactoring：代码重构

重构是改善代码内部结构，而尽量不改变外部行为。

例如：

原本有一个过长的函数：

def process_user(data):
    # 数据验证
    # 数据清洗
    # 数据保存
    # 日志记录
    pass

可以拆分为：

def validate_user(data):
    pass


def clean_user(data):
    pass


def save_user(data):
    pass


def process_user(data):
    validate_user(data)
    clean_user(data)
    save_user(data)

重构之后，应该使用测试验证原有功能没有被破坏。

3.4 Code Review：AI 辅助审查

可以让 Agent 检查最近一次 Commit 的修改：

Review all changes since the last commit.

Focus on:
1. Correctness bugs.
2. Security vulnerabilities.
3. Missing error handling.
4. Performance issues.
5. Missing tests.

For each finding, provide:
- File and line number.
- Explanation.
- Potential impact.
- Suggested fix.

Do not report purely stylistic preferences.

AI 的审查结果应作为候选问题，而不是最终结论。

3.5 Code Understanding：理解陌生项目

当你接触一个大型代码库时，可以让 Agent：

• 识别项目入口。
• 解释模块关系。
• 找出关键数据结构。
• 追踪函数调用关系。
• 解释一个功能的执行路径。

建议使用逐步追问，而不是一次要求它解释整个仓库。

例如：

第一步：

请识别项目的主要入口文件。

第二步：

请追踪用户登录请求的调用路径。

第三步：

请解释认证中间件的工作机制。

第四步：

请指出这一实现可能存在的安全风险。

3.6 Shell as an Interface：自然语言驱动终端

Agent 还可以将自然语言转换为 Shell 命令。

例如：

找到项目中所有超过 500 行的 Python 文件。

Agent 可能使用：

find . -name "*.py" -exec wc -l {} \;

但是，Shell 命令具有很强的操作能力。

涉及删除文件、修改权限、覆盖数据、访问网络和读取秘密信息的命令，必须谨慎审查。

3.7 Vibe Coding：自然语言驱动应用开发

Vibe Coding 适合：

• 小型原型。
• 概念验证。
• 个人工具。
• 快速试验。
• 交互界面草稿。

不适合直接将未经理解和验证的生成结果投入关键生产系统。

第 4 章 进阶智能体工程

4.1 Reusable Prompts：可复用提示词

如果你经常要求 Agent 做代码审查，可以把任务要求保存为模板。

例如：

你是一个 Python Code Review Agent。

请重点检查：
1. 逻辑正确性。
2. 异常处理。
3. 类型安全。
4. 资源管理。
5. 安全问题。
6. 测试覆盖。

请优先报告高风险问题。

不要仅仅为了个人风格提出修改建议。

这样可以减少重复编写 Prompt 的时间。

4.2 Parallel Agents：并行智能体

多个 Agent 可以同时完成不同任务。

例如：

但要避免多个 Agent 同时修改相同文件。

课程推荐使用 Git Worktree 隔离工作目录。

例如：

git worktree add ../project-api feature-api

git worktree add ../project-tests feature-tests

这样不同工作目录可以对应不同分支。

4.3 MCP：Model Context Protocol

MCP 是连接 AI 应用与外部工具、数据源的开放协议。

例如，一个支持 MCP 的 Coding Agent 可以通过相应服务：

• 读取项目文档。
• 查询数据库。
• 访问 Notion。
• 与其他工作系统交互。

MCP 解决的是模型如何通过标准化接口访问外部工具和上下文的问题。

它不是一个新的语言模型，也不是编程语言。

4.4 Context Management：上下文管理

课程重点介绍四种方式。

Clear Context

对于完全不同的任务，开始新的对话。

避免无关历史干扰当前任务。

Rewind

当 Agent 沿着错误方向执行时，回退到之前的状态。

比不断叠加修正 Prompt 更有效。

Compaction

将较长的历史压缩为摘要。

保留重要信息，减少上下文消耗。

llms.txt

教材介绍了 /llms.txt 这一提议标准。

它的目标是提供适合语言模型阅读的文档入口。

例如，一个工具的文档可能包含：

https://example.com/llms.txt

它可以帮助 Agent 更高效地获取相关文档，但具体是否提供以及内容质量取决于项目。

4.5 AGENTS.md

AGENTS.md 是项目级指导文件。

例如：

# AGENTS.md

## Project

Python 3.12 project.

## Coding Standards

- Use type annotations.
- Use Ruff for formatting.
- Use Ruff for linting.

## Testing

Run pytest before completing a task.

## Restrictions

- Do not modify generated files.
- Do not commit secrets.
- Preserve public APIs unless explicitly requested.

它可以帮助 Agent 在多个任务和会话中遵循统一项目规范。

4.6 Skills 与 Subagents

Skill 是专门工作流程的封装。

Subagent 是负责特定任务的子智能体。

例如：

Main Agent
   |
   +-- Research Subagent
   |
   +-- Testing Subagent
   |
   +-- Security Review Subagent

它们可以让主 Agent 将工作委派给专门的子流程。

但不同产品对 Skills 和 Subagents 的支持方式不完全相同。

第 5 章 AI 编程的局限与风险

5.1 概率生成不等于程序正确

AI 可能生成：

• 不存在的 API。
• 错误的依赖用法。
• 不符合需求的逻辑。
• 不安全的代码。
• 看似正确但实际失败的测试。

5.2 Debugging Spiral：调试循环

有时 Agent 会：

1. 修改代码。
2. 运行测试。
3. 发现错误。
4. 修改另一个位置。
5. 引入新的错误。
6. 再次尝试。

这种过程可能不断扩大修改范围。

解决方法：

• 要求先定位根因。
• 控制修改范围。
• 查看 Git Diff。
• 每次修改后运行相关测试。
• 必要时回退。
• 不要让 Agent 无限制地重复尝试。

5.3 Privacy：隐私风险

课程提醒，许多 AI 编程工具默认使用云端模型。

可能被发送到云端的信息包括：

• 源代码。
• 项目文件。
• 提示词。
• 终端输出。
• 交互历史。

因此，使用前应该检查工具的数据处理方式、企业政策和隐私要求。

5.4 Overreliance：过度依赖

如果程序员只负责提出需求，完全不理解生成的代码，就很难承担长期维护责任。

尤其在学习阶段，完全让 AI 代替自己思考，可能使你获得了一个程序，却没有获得相应的编程能力。

最终原则：AI 可以承担执行任务的工作，但程序员必须承担理解、验证和决策的责任。

第二部分：Beyond the Code（软件工程沟通与协作）

第 6 章 软件工程为什么不仅仅是编程？

软件工程师的工作不仅包括编写程序，还包括与其他工程师进行持续交流。

真实项目中，你需要：

• 解释系统如何工作。
• 了解其他团队的需求。
• 阅读他人的代码。
• 参与技术决策。
• 报告错误。
• 审查代码。
• 维护已有系统。

课程将工程沟通大致分成两类：

1. One-way Communication：单向沟通。
2. Two-way Communication：双向沟通。

单向沟通主要通过文档、注释和提交信息完成。

双向沟通主要通过讨论、Issue、PR、Review 和技术交流完成。

第 7 章 One-way Communication：单向技术沟通

7.1 为什么需要单向沟通？

假设你今天完成了一个复杂的功能。

六个月以后，另一位程序员接手这个项目。

他可能不知道：

• 为什么使用当前算法？
• 为什么选择这个数据结构？
• 为什么某个参数是 1492？
• 为什么没有采用另一种实现？
• 哪些部分存在尚未解决的限制？

如果没有记录，这些知识就会随着开发者离开项目而消失。

因此，技术文档的一个核心任务是保存决策背后的原因。

7.2 Code Comments：代码注释

课程强调：

好注释解释 Why，而不是重复 What。

错误示例：

# Add one to counter
counter += 1

正确性或设计理由示例：

# Preserve insertion order because the downstream
# serializer depends on deterministic field ordering.

后者记录了代码中不容易直接看出的约束。

值得记录的七类注释

1. TODO

标记尚未完成的工作。

不好的写法：

# TODO: optimize

更好的写法：

# TODO: Current lookup is O(n^2), which is acceptable
# for fewer than 100 records. Introduce an index if
# the dataset grows beyond this size.

2. References

记录算法、论文或外部规范的来源。

例如：

# Implements the retry policy described in:
# https://example.com/specification

正式项目中最好引用稳定的文档版本或永久链接。

3. Correctness Arguments

解释复杂代码为什么正确。

# The loop invariant guarantees that all elements
# before i have already been processed.

4. Hard-learned Lessons

记录不容易发现的问题。

例如：

# Flush the buffer before closing the stream.
# Otherwise the final partial batch may be lost.

5. Rationale for Constants

解释魔法数字。

# Maximum batch size is 128 to stay within the
# downstream service's request limit.
MAX_BATCH_SIZE = 128

6. Load-bearing Choices

解释为什么某个实现细节不能随便改变。

# Keep this collection ordered because output
# generation depends on deterministic iteration.

7. Why Not

解释为什么没有采用看起来更简单的方案。

# Avoid global mutable state because it prevents
# independent tests from running safely in parallel.

7.3 README：项目说明文档

README 是项目的入口。

推荐结构：

# Project Name

## What does this project do?

## Why should you use it?

## Usage

## Installation

## Configuration

## Development

## Testing

## License

核心顺序：

What → Why → Usage → Installation

先让读者理解项目价值，再让读者学习使用和安装。

README 的质量标准

一个好的 README 应当：

• 能快速说明项目目标。
• 有可以直接理解的使用示例。
• 给出清楚的安装步骤。
• 说明必要的配置。
• 指明项目限制。
• 给出开发和测试方法。
• 不用大量无关文字淹没核心信息。

7.4 Commit Messages：提交说明

Git Commit 不只是保存代码变化，也是记录项目演进历史。

不好的提交：

fix bug
update files
change code

这些内容无法帮助未来的开发者理解修改原因。

课程建议使用：

Problem → Solution → Implications

示例

Prevent duplicate payment processing

Problem:
Network retries may submit the same payment
request multiple times.

Solution:
Use an idempotency key to identify repeated
requests and reuse the existing result.

Implications:
Callers must now provide a stable idempotency key.

如何组织复杂 Commit？

一个 Commit 应当尽量代表一个逻辑完整的修改。

例如：

Commit 1: Add authentication validation
Commit 2: Add authentication unit tests
Commit 3: Update authentication documentation

不要把无关重构、格式化和功能开发混在一个提交中。

使用：

git add -p

可以交互式选择文件中的不同修改块。

这有利于：

• 审查。
• 回滚。
• 使用 git bisect 定位问题。
• 理解项目历史。

使用 LLM 生成 Commit Message

课程指出一个重要问题：

如果只给 LLM 一个 Git Diff，它通常只能知道 What，不知道 Why。

因此可以让模型：

根据当前 Diff 编写 Commit Message。

重点解释：
1. 修改所解决的问题。
2. 选择该方案的原因。
3. 考虑过哪些替代方案。
4. 修改带来的影响。

如果缺少必要背景，请先向我提问。

如果 Agent 本身参与了开发，它通常能够访问此前的需求和设计讨论，因此更容易生成准确的提交说明。

第 8 章 Collaboration：软件工程协作

8.1 软件开发中的参与者

开源项目中通常存在三类群体：

• Users：使用软件的人。
• Contributors：参与贡献的人。
• Maintainers：负责项目长期维护的人。

课程指出，通常用户数量远大于贡献者数量，而贡献者数量又远大于维护者数量。

因此，维护者的时间是一种稀缺资源。

一个贡献是否值得被接受，不仅取决于它能否解决问题，还取决于它是否值得维护者投入时间。

这就是 High Signal-to-Noise Ratio（高信噪比）的重要性。

8.2 Bug Report：高质量错误报告

一个好的 Bug Report 应当包括：

示例：

# Bug: CSV export fails for empty input

## Environment

Python 3.12
Ubuntu 24.04
Application v1.2.0

## Expected Behavior

An empty CSV should produce a valid output file
containing the header row.

## Actual Behavior

The program raises IndexError.

## Steps to Reproduce

1. Create an empty input.csv.
2. Run the export command.
3. Observe the exception.

## What I Tried

The issue does not occur with non-empty CSV files.

8.3 Search Existing Issues

提交 Issue 前，先检查：

• 是否已经有人报告相同问题？
• 是否存在正在讨论的解决方案？
• 是否有相关的 Pull Request？
• 是否有项目文档解释该行为？

重复创建 Issue 会增加维护成本。

如果已经存在相关讨论，通常更好的方式是补充有价值的信息。

8.4 Minimal Reproducible Example

最小可复现示例是帮助维护者定位问题的重要工具。

例如，原本有一个大型应用：

10000 lines of code

你逐步删除不相关模块，最后得到：

def parse_value(value):
    return value[0]

然后发现输入空字符串时会引发问题。

这比提交整个大型项目更有助于分析根因。

8.5 Issue 的沟通礼仪

课程特别提醒：

• 不要频繁催促维护者。
• 不要反复发布没有新增信息的“me too”。
• 不要只复制终端输出。
• 应该先搜索已有问题。
• 如果等待一段时间没有回复，可以礼貌跟进。
• 如果能够复现问题，尽量提供最小示例。

维护者可能是志愿者，不能假设他们随时有时间响应。

8.6 CONTRIBUTING.md

参与开源项目之前，应阅读：

CONTRIBUTING.md

它通常规定：

• 如何创建开发分支。
• 如何运行测试。
• 代码风格要求。
• PR 格式。
• 提交信息要求。
• 项目开发流程。

还需要注意项目许可证。

例如，某些 Copyleft 许可证会对衍生作品的发布方式产生要求。贡献之前应该了解许可证对代码使用和分发的影响。

如果发现安全漏洞，不应直接公开发布详细利用信息。应该优先通过项目的安全披露渠道联系维护者，给予合理修复时间。

8.7 Pull Request：提交代码贡献

一个好的 PR 应当满足：

1. 修改范围明确。
2. 尽量避免无关变化。
3. 解释为什么需要修改。
4. 解释为什么采用当前实现。
5. 提供测试方式。
6. 指出需要审查的重点。

如果一个功能确实需要很多相关文件的修改，可以使用较大的 PR，但应该保持 Commit 组织清晰，使维护者能够逐步审查。

AI 生成的 PR

课程特别提醒：

AI 可以快速生成代码，但不能因此降低贡献者的责任。

如果提交者自己无法解释代码，维护者就需要承担额外的理解、审查和维护成本。

因此，提交 AI 生成的代码之前，必须：

• 理解主要实现。
• 检查功能正确性。
• 检查安全性。
• 验证测试。
• 删除无关修改。
• 补充必要文档。

维护者最终接受的是长期维护责任，而不是一次性的代码输出。

第 9 章 Code Review：代码审查

9.1 为什么需要 Code Review？

Code Review 不仅仅是寻找错误。

它还有以下价值：

• 提高代码质量。
• 发现设计缺陷。
• 传播项目知识。
• 统一开发规范。
• 帮助初级工程师学习。
• 减少错误进入生产环境的概率。

即使你不是高级工程师，也可以参与 Review。

新成员有时反而更容易发现项目中的隐含假设。

9.2 Code Review 的六项原则

原则一：Review the Code, Not the Person

不要针对个人。

不好的评论：

You wrote confusing code.

更好的评论：

This function is difficult to follow.
Could we separate validation and processing?

原则二：Prefer Actionable Comments

评论应该让作者知道下一步怎么做。

不好的评论：

Don't use globals.

更好的评论：

Could you replace these global variables
with a configuration dataclass?

This would allow tests to run independently
and safely in parallel.

原则三：Ask Questions Rather Than Making Demands

例如：

What happens if this value is null?

比直接命令：

Handle null values.

更容易展开有效讨论。

原则四：Explain the Why

建议：

Consider using a named constant here
so the timeout can be adjusted by environment.

而不是仅仅说：

Use a constant.

原则五：Distinguish Blocking Issues and Suggestions

可以在评论中区分：

• Blocking：必须修改的问题。
• Suggestion：改进建议。
• Nit：非阻塞的小问题。

原则六：Acknowledge Good Work

不要只指出问题。

如果某个实现很好，也应该告诉作者原因。

代码审查应该帮助团队建立更好的工程习惯，而不是让作者感到所有修改都在被否定。

9.3 Know When to Stop

不要把每个细节都变成必须修改的要求。

优先处理：

1. 正确性。
2. 安全性。
3. 兼容性。
4. 可维护性。
5. 重要的性能问题。

对于不影响整体质量的小型风格问题，应合理控制评论数量。

第 10 章 Education：如何提出有效的技术问题

程序员需要持续学习，也需要向其他人提问。

课程介绍了五个重要方法。

1. State Your Understanding First

先说明自己已经理解的内容。

例如：

我的理解是 LEFT JOIN 会保留左表的所有行，
即使右表没有匹配记录也会保留。

这个理解正确吗？

2. Ask Yes/No Questions

适当提出可以用是或否回答的问题。

这样更容易确认某个具体理解是否正确，避免无关讨论。

3. Be Specific

不要问：

How does SQL work?

可以问：

LEFT JOIN 是否会保留右表中没有匹配记录的左表行？

4. Admit When You Don't Understand

如果不理解一个概念，应直接说明。

我理解了前面的执行流程，
但不清楚这里为什么需要使用事务隔离级别。

这比假装理解更有助于学习。

5. Don't Accept Incomplete Answers

不要因为别人给出一个看起来专业的答案就停止思考。

应该继续追问，直到真正理解。

当然，也要尊重对方时间。

这些原则同样适用于与 LLM 对话。

第 11 章 AI Etiquette：AI 使用规范

AI 已经成为软件开发的重要工具，但使用方式仍然需要遵守工程伦理和团队规则。

11.1 Disclose AI Usage

当 AI 对工作产生实质性贡献时，应该按照团队和项目要求披露。

例如：

AI Assistance:

- AI helped generate the initial unit tests.
- The implementation was manually reviewed.
- All tests were executed by the contributor.

比简单写一句“Used AI”更有价值。

11.2 Follow Team Policies

不同团队可能对以下问题有不同要求：

• 哪些代码可以发送到云端模型？
• 是否允许使用第三方 AI 服务？
• 是否可以让 AI 生成核心业务代码？
• 是否需要记录 AI 参与情况？
• 是否涉及数据驻留和合规要求？

应该遵守组织的规则。

11.3 Interviews and Assessments

面试和考试通常是为了评估个人能力。

如果不确定是否允许使用 AI，应该事先询问。

不能假设所有考核都允许外部 AI 工具。

第三部分：Code Quality（代码质量）

第 12 章 代码质量体系概述

代码能够运行，并不代表代码质量足够好。

例如：

def process(data):
    result = []
    for x in data:
        if x > 0:
            if x < 100:
                result.append(x)
    return result

它可能运行正常，但仍然存在：

• 风格不统一。
• 条件嵌套不必要。
• 缺少类型注解。
• 缺少测试。
• 没有错误处理。
• 没有说明输入约束。

代码质量需要多种工具共同保障。

本课程介绍六项主要内容：

1. Formatting
2. Linting
3. Testing
4. Pre-commit Hooks
5. Continuous Integration
6. Command Runners

另外还介绍 Regular Expressions。

第 13 章 Formatting：自动格式化

13.1 什么是代码格式化？

Formatter 会自动调整代码的表面形式。

例如：

原始代码：

def calculate(a,b):
  return a+b

格式化后：

def calculate(a, b):
    return a + b

主要处理：

• 缩进。
• 空格。
• 引号。
• 换行。
• 行长度。
• 代码布局。

13.2 为什么需要统一格式？

如果每个人都按照自己的习惯编写代码，团队会在大量无关紧要的风格问题上浪费时间。

这类争论在软件工程中称为 Bike-shedding。

例如：

• 使用单引号还是双引号？
• 缩进使用两个空格还是四个空格？
• 一行代码最长多少字符？

如果 Formatter 能够自动统一这些选择，开发者就能将注意力放到逻辑和设计上。

13.3 常见工具

Python 项目可以执行：

ruff format .

如果只想检查、不修改：

ruff format --check .

13.4 Formatter 配置

一些工具支持较多配置。

建议将项目格式配置提交到版本控制中。

此外，还可以使用 EditorConfig。

例如：

root = true

<li>charset = utf-8</li>
end_of_line = lf
insert_final_newline = true

[*.py]
indent_style = space
indent_size = 4

它能够帮助不同 IDE 使用一致的编辑器设置。

第 14 章 Linting：静态代码分析

14.1 什么是 Linter？

Linter 在不运行程序的情况下分析代码，寻找可疑模式和潜在问题。

这叫 Static Analysis（静态分析）。

例如：

import os

def calculate():
    x = 10
    return 42

这里存在：

• 未使用的 import。
• 未使用的变量。

Linter 可以发现这些问题。

14.2 Formatter 与 Linter 的区别

14.3 使用 Ruff

安装：

pip install ruff

检查：

ruff check .

自动修复可修复的问题：

ruff check --fix .

检查格式：

ruff format --check .

14.4 Linter Rules

Linter 通常包含大量规则。

某些规则可能：

• 检查未使用变量。
• 检查未使用导入。
• 检查不合理的条件嵌套。
• 检查危险函数调用。
• 检查不合理的代码复杂度。

不同规则可以根据项目情况配置。

14.5 False Positives：误报

Linter 并不完美。

有些情况下，它可能认为某种写法有问题，但开发者实际上有合理理由。

因此可以通过配置或局部注释关闭某些规则。

例如：

# noqa: S602

这类抑制应该有明确理由，不应该把它当成解决真实安全问题的默认方式。

14.6 Semgrep：基于语法结构的代码搜索

普通 grep 主要根据字符进行搜索。

Semgrep 可以基于程序语法结构匹配代码模式。

例如，课程展示了对以下危险模式的检查：

subprocess.Popen(
    command,
    shell=True
)

命令：

semgrep -l python \
  -e "subprocess.Popen(..., shell=True, ...)"

这种方式能够比简单的文本匹配更准确地查找符合语法结构的代码。

适用场景：

• 安全规则。
• 自定义代码规范。
• 大型代码库检查。
• 危险 API 搜索。

第 15 章 Testing：自动化测试

15.1 为什么需要测试？

测试的基本思想：

编写程序之后，再编写一组程序来验证它的行为是否符合预期。

例如：

def add(a, b):
    return a + b

测试：

def test_add():
    assert add(2, 3) == 5

测试通过，说明在这个输入条件下，程序符合预期。

但一个测试无法证明函数在所有输入下都正确。

15.2 Unit Testing：单元测试

单元测试检查一个较小的功能单元。

Python 常用 pytest。

安装：

pip install pytest

项目结构：

project/
├── calculator.py
└── tests/
    └── test_calculator.py

calculator.py：

def add(a: int, b: int) -> int:
    return a + b


def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("b cannot be zero")

    return a / b

test_calculator.py：

import pytest

from calculator import add, divide


def test_add():
    assert add(2, 3) == 5


def test_divide():
    assert divide(10, 2) == 5


def test_divide_by_zero():
    with pytest.raises(ValueError):
        divide(10, 0)

执行：

pytest

15.3 Integration Testing：集成测试

集成测试验证多个模块之间能否正确协作。

例如：

API
 ↓
Service
 ↓
Database

需要验证：

• API 是否正确调用 Service。
• Service 是否正确访问数据库。
• 数据是否能够正确保存和读取。

15.4 Functional Testing：功能测试

功能测试主要从用户功能或完整业务流程出发。

例如：

用户注册
  ↓
用户登录
  ↓
创建订单
  ↓
支付订单
  ↓
查询订单

测试重点是整个流程是否满足预期需求。

15.5 Test-Driven Development：测试驱动开发

TDD 的基本循环：

Red → Green → Refactor

Red

先编写测试，让它因为功能尚未实现而失败。

Green

编写最少的代码，让测试通过。

Refactor

在测试保护下改进代码结构。

这种方法能够让开发者在编写实现之前就明确预期行为。

15.6 Regression Testing：回归测试

当程序发生 Bug 时，不仅应该修复 Bug，还应该增加相应测试。

例如：

某个函数曾经在空输入下崩溃。

修复后增加：

def test_empty_input():
    assert process([]) == []

以后每次修改程序时，都可以自动检查这个问题是否再次出现。

15.7 Mocking：模拟外部依赖

如果程序依赖第三方 API 或数据库，测试时不一定需要真的访问外部服务。

可以使用 Mock 替代真实依赖。

例如：

from unittest.mock import Mock

def fetch_user(client, user_id):
    return client.get_user(user_id)


def test_fetch_user():
    client = Mock()

    client.get_user.return_value = {
        "id": 1,
        "name": "Alice"
    }

    result = fetch_user(client, 1)

    assert result["name"] == "Alice"

这样可以：

• 避免真实网络请求。
• 避免依赖外部服务是否可用。
• 提高测试速度。
• 控制测试输入。

但 Mock 不应过度使用，否则测试可能只验证模拟对象，而没有验证真实系统的集成行为。

15.8 Property-Based Testing：基于性质的测试

普通单元测试通常使用手工指定的输入。

例如：

assert add(2, 3) == 5

Property-Based Testing 则通过描述程序应当满足的性质，让工具自动生成大量输入。

教材介绍了 Hypothesis。

安装：

pip install hypothesis

例如，假设我们有一个字符串填充函数：

def pad(text: str, length: int) -> str:
    return text.ljust(length)

我们希望满足：

[
|\operatorname{pad}(s,n)| \geq n
]

对于任意合法的字符串 (s) 和非负整数 (n)，填充后的长度不应该小于 (n)。

测试可以写成：

from hypothesis import given
from hypothesis import strategies as st


@given(
    text=st.text(max_size=20),
    length=st.integers(min_value=0, max_value=50)
)
def test_pad_length(text, length):
    result = pad(text, length)

    assert len(result) >= length

Hypothesis 会生成许多输入并检查性质。

但它不是数学证明。

它只是通过大量生成的测试样本寻找违反性质的情况。

测试数据的范围和性质仍然需要开发者合理设计。

第 16 章 Code Coverage：代码覆盖率

16.1 什么是覆盖率？

Code Coverage 衡量运行测试时有多少代码被执行。

例如：

def classify(x):
    if x > 0:
        return "positive"

    elif x < 0:
        return "negative"

    return "zero"

如果只测试：

classify(10)

那么负数和零的分支就没有被执行。

覆盖率报告可以帮助开发者发现未测试区域。

16.2 使用 pytest-cov

安装：

pip install pytest-cov

执行：

pytest --cov=src --cov-report=html

生成 HTML 报告。

查看：

htmlcov/index.html

可以看到：

• 哪些文件被测试。
• 哪些代码行被执行。
• 哪些分支没有覆盖。

16.3 为什么覆盖率不等于质量？

假设：

def divide(a, b):
    return a / b

测试：

def test_divide():
    divide(10, 2)

这个测试可能执行了函数的全部代码行。

但它没有验证结果是否正确。

所以：

高覆盖率不一定意味着测试有效。

课程建议：

关注高质量测试，而不是单纯追求覆盖率数字。

覆盖率的真正价值是帮助发现测试盲区。

第 17 章 Pre-commit Hooks：提交前自动检查

17.1 Git Hook 的概念

Git Hook 是 Git 提供的事件触发机制。

例如，在提交前执行脚本：

git commit
    ↓
pre-commit hook
    ↓
执行检查
    ↓
允许或阻止提交

17.2 Pre-commit Framework

教材介绍了 Pre-commit 工具。

首先安装：

pip install pre-commit

在项目根目录创建：

.pre-commit-config.yaml

示例：

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.9.0
    hooks:
      - id: ruff
      - id: ruff-format

注意：示例版本仅用于说明配置结构，真实项目应根据当前工具版本选择经过验证的版本。

安装 Hook：

pre-commit install

现在执行：

git commit -m "Add new feature"

Git 会在提交前执行配置的检查。

如果检查不通过，提交可能被阻止。

开发者修复问题后重新提交即可。

第 18 章 Continuous Integration：持续集成

18.1 什么是 CI？

CI 是 Continuous Integration 的缩写。

它指将代码集成到共享代码库时，自动运行构建和质量检查。

例如：

开发者修改代码
      ↓
git push
      ↓
GitHub Actions
      ↓
自动运行检查
      ↓
返回检查状态

CI 能够在代码进入主分支之前发现问题。

18.2 GitHub Actions

在项目中创建：

.github/workflows/ci.yml

示例：

name: Python CI

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m pip install pytest ruff

      - name: Check formatting
        run: ruff format --check .

      - name: Lint
        run: ruff check .

      - name: Test
        run: pytest

当代码 Push 或 PR 时，GitHub Actions 会自动运行。

18.3 为什么 CI 使用 Check-only Mode？

在开发者本地：

ruff format .

可以自动修改代码。

但是在 CI 中，通常使用：

ruff format --check .

原因是 CI 的任务应该是验证提交的代码，而不是悄悄修改代码。

如果格式不正确，就返回失败，让开发者修复后重新提交。

18.4 Matrix Testing：矩阵测试

有些项目需要同时支持：

• Linux
• macOS
• Windows

还可能支持：

• Python 3.11
• Python 3.12
• Python 3.13

可以通过 CI Matrix 让多个环境自动执行相同测试。

这样能发现本地开发环境中不容易暴露的兼容性问题。

18.5 Scheduled CI：定期检查

CI 不一定只在代码变化时运行。

也可以设置定时任务。

例如，每周重新检查依赖。

为什么？

因为即使你的代码没有变化，外部依赖也可能发布新版本，或者出现兼容性和安全问题。

定期 CI 可以帮助发现这些问题。

18.6 CI Status Badge

GitHub README 中经常出现：

Build: Passing

这类状态标记可以告诉使用者最近的自动化检查是否通过。

但它只能表示指定工作流的状态，不代表软件在所有环境中都没有问题。

第 19 章 Continuous Deployment：持续部署

CI 主要验证代码。

CD 则进一步将通过验证的修改部署到目标环境。

例如：

git push
   ↓
CI 检查
   ↓
构建网站
   ↓
部署到 GitHub Pages

教材以 Missing Semester 网站为例，说明代码更新后可以自动构建并发布网站。

CD 也可以用于：

• 发布 Docker 镜像。
• 部署 Web 服务。
• 发布二进制文件。
• 更新文档网站。

CI 和 CD 可以结合在同一个自动化流水线中。

第 20 章 Command Runners：项目命令管理

随着项目规模扩大，命令可能越来越复杂。

例如：

uv run ruff check .
uv run ruff format .
uv run pytest
uv run mypy .

Command Runner 可以将这些命令封装为简短入口。

课程介绍了 just。

例如创建：

lint:
    uv run ruff check .

format:
    uv run ruff format .

test:
    uv run pytest

typecheck:
    uv run mypy .

然后执行：

just lint
just format
just test
just typecheck

这样新加入项目的开发者不需要记住所有工具的完整参数。

类似能力也可以由：

• npm scripts
• Hatch scripts
• Make
• 其他项目管理工具

提供。

第 21 章 Regular Expressions：正则表达式

21.1 什么是正则表达式？

Regular Expression（Regex）是一种描述字符串集合和匹配模式的语言。

例如：

abc

匹配字符串中的 abc。

\d+

匹配一个或多个数字。

missing|semester

匹配 missing 或 semester。

正则表达式常用于：

• 文本搜索。
• 日志分析。
• 数据验证。
• 批量替换。
• 命令行工具。
• IDE 搜索。
• 测试筛选。

21.2 基础语法

21.3 日期匹配

\d{4}-\d{2}-\d{2}

匹配：

2026-01-14

但不验证日期是否合法。

例如：

2026-01-99

仍然能够匹配。

21.4 邮箱匹配

教材给出了简单示例：

.+@.+

它只表示：

• @ 前面至少有一个字符。
• @ 后面至少有一个字符。

这不是可靠的邮箱验证规则。

完整邮箱地址验证涉及更多语法和规范，通常应使用成熟的验证方案，而不是自己编写一个极其复杂的正则表达式。

21.5 Capture Groups：捕获组

例如：

import re

text = "2026-01-14"

match = re.match(
    r"\d{4}-(\d{2})-\d{2}",
    text
)

print(match.group(1))

输出：

01

括号：

(\d{2})

表示捕获一组两位数字。

21.6 Greedy and Non-greedy：贪婪与非贪婪

例如：

".*"

* 默认采用贪婪匹配，尽可能匹配更多内容。

而：

".*?"

使用非贪婪匹配，尽可能匹配较短内容。

这在文本提取中非常重要。

21.7 Regex 的局限性

正则表达式非常适合简单文本模式。

但不适合所有结构化数据解析。

例如：

• HTML。
• 嵌套 JSON。
• 复杂编程语言语法。
• 有任意层级嵌套结构的数据。

对于 JSON，应该使用 JSON Parser：

import json

data = '''
{
    "name": "Alyssa P. Hacker",
    "college": "MIT"
}
'''

obj = json.loads(data)

print(obj["name"])

对于复杂语法结构，应使用专门的 Parser。

选择工具的原则：简单文本模式使用 Regex，结构化数据使用对应解析器。

第四部分：综合实践项目

第 22 章 建立完整的软件工程工作流

现在将三个主题整合起来。

项目：Markdown Link Extractor。

22.1 项目需求

实现一个 Python 命令行程序：

link-extractor input.md

提取 Markdown 文件中的链接。

支持：

link-extractor input.md --output links.txt

将提取结果写入文件。

要求：

1. 使用类型注解。
2. 使用 argparse。
3. 有合理的异常处理。
4. 编写单元测试。
5. 使用 Ruff。
6. 使用 mypy。
7. 配置 Pre-commit。
8. 配置 GitHub Actions。
9. 编写 README。
10. 通过 Pull Request 完成代码审查。

22.2 创建项目

mkdir markdown-link-extractor
cd markdown-link-extractor

git init -b main

uv init --package

创建虚拟环境并安装开发工具：

uv add --dev pytest ruff mypy pre-commit

22.3 让 Coding Agent 实现功能

给 Agent 提供：

请在当前项目中实现 Markdown Link Extractor。

功能：
1. 接收 Markdown 文件路径。
2. 提取普通 Markdown 链接。
3. 支持 --output 指定输出文件。
4. 输入文件不存在时返回清晰错误。
5. 使用类型注解。
6. 为主要功能编写单元测试。

限制：
1. 不修改输入文件。
2. 优先使用 Python 标准库。
3. 不要为了通过测试而删除测试。
4. 不要关闭 Linter 规则来隐藏问题。

完成后：
运行 pytest、ruff 和 mypy，
并报告实际结果。

22.4 编写测试

至少测试：

• 有一个链接。
• 有多个链接。
• 没有链接。
• 空文件。
• 非法文件路径。
• 输出到指定文件。

例如：

def test_extract_single_link():
    text = "[Google](https://google.com)"

    assert extract(text) == [
        "https://google.com"
    ]


def test_extract_no_link():
    text = "No links here"

    assert extract(text) == []

这里的测试针对简单 Markdown 链接格式，不代表完整覆盖所有 Markdown 语法。

22.5 配置质量检查

执行：

uv run ruff format .
uv run ruff check .
uv run mypy src/
uv run pytest

确保所有检查通过。

22.6 配置 Pre-commit

添加 .pre-commit-config.yaml，让提交前自动执行格式和 Lint 检查。

安装：

uv run pre-commit install

22.7 配置 CI

创建：

.github/workflows/ci.yml

在每次 Push 和 PR 时运行：

• Ruff Format Check。
• Ruff Lint。
• Mypy。
• Pytest。

22.8 编写 README

README 至少应该包括：

# Markdown Link Extractor

## What

A command-line tool for extracting links
from Markdown documents.

## Why

It helps inspect and process links
without manually reading the document.

## Usage

link-extractor input.md

## Installation

...

## Development

...

## Testing

...

22.9 提交 Git Commit

git add -p

git commit -m "Add Markdown link extraction CLI"

复杂修改应该拆分为多个逻辑独立的 Commit。

22.10 创建 Pull Request

PR 应当说明：

• 解决了什么问题。
• 实现了什么功能。
• 为什么使用当前方案。
• 如何验证。
• 有哪些限制。

最后让其他开发者进行 Code Review。

第五部分：课程练习与考核

第 23 章 分阶段实践任务

建议不要一次完成所有练习，而是分阶段训练。

阶段一：Coding Agent

阶段二：Beyond the Code

阶段三：Code Quality

第 24 章 最终知识框架

三部分内容可以归纳为以下知识体系。

结语：真正的软件工程能力是什么？

这三份课程材料传达了一个共同的思想：

软件工程不仅仅是写代码。

一个成熟的工程师需要同时具备以下能力：

1. 开发能力：能够将需求转化为可运行的程序。
2. 工具能力：能够利用 AI、Shell、Git 和自动化工具提高效率。
3. 验证能力：能够使用测试、静态分析和 CI 验证程序质量。
4. 表达能力：能够通过注释、文档和提交记录解释设计决策。
5. 协作能力：能够参与 Issue、PR 和 Code Review。
6. 责任能力：能够对代码的正确性、安全性和长期维护负责。

尤其在 AI 编程时代，生成代码的成本正在降低，但理解代码、验证代码、判断设计取舍以及维护系统的能力依然重要。

最终的学习目标不是成为一个只会向 AI 提问的人，而是成为一个能够利用 AI、工程工具和团队协作机制，持续交付可靠软件的工程师。

如果版本控制也能变得更好用：Jujutsu 入门与实践

大家好，我是 Chris Krycho。今天我想和大家聊聊 Jujutsu 版本控制系统，简称 JJ。这个名字听起来可能有些特别。过去十年左右，对大多数开发者来说，版本控制几乎就意味着 Git。我认为，现在是时候改变这种局面了。

今年二月初，我发表了一篇很长的文章，深入讨论 Jujutsu。从去年九月前后开始，我基本上已经把它作为唯一的日常版本控制工具；在那之前，我也已经使用过一段时间。为什么我们应该考虑超越 Git？我先解释一下原因，然后会通过实际演示来说明。

为什么我想从 Git 向前迈一步

Git 在它诞生的时代，以及它所提供的能力范围内，是一款非常出色的工具。Git 出现时，我们确实需要它带来的那些能力。分布式版本控制相较于此前的非分布式版本控制，是一次巨大的进步。正在观看视频的各位中，有些人可能从未经历过 CVS，甚至 SVN 的时代，更不用说以 Polytron 版本控制系统为底层、再由 Serena 提供包装的那类工具了。我经历过那个时代，那确实是一段不太愉快的时期。

Git、Mercurial，以及 2000 年代中期出现的其他一些工具，都比此前的系统前进了一大步。突然之间，我可以在自己的机器上拥有一份完整的仓库副本，你也可以在自己的机器上拥有一份完整副本。即使我们恰好修改了同一部分内容，也没有关系；我们不必先锁定文件，再等到稍后才能提交。分支也成为了一等公民。对于过去十年才进入这个行业的人来说，这些事情可能已经理所当然了：当然可以随手创建一个分支。但在 Git、Mercurial 以及同一代版本控制系统出现之前，情况并不是这样。我绝不会想回到那个年代，不过，我确实希望继续向前发展。

过去十年我一直在使用 Git，在此之前使用的是 Mercurial。简单来说，Git 本身也值得受到一些批评。它的命令行界面以复杂难用而闻名，而且这种复杂性并不总是因为它所处理的问题本身足够复杂。对于从未使用过 Mercurial 的人来说，我们有时会把它称为一个“存在性证明”：它证明版本控制系统的命令行界面完全可以设计得很好。Mercurial 的版本控制命令行体验确实不错。

然而，大多数人最终还是使用 Git，因为 GitHub 的规模和影响力非常大，Linux 项目也极具影响力，而且大量工具都默认你会使用 Git。Git 逐渐成为了整个生态系统所预期的版本控制工具。与此同时，Git 内部也积累了很多复杂性，这些复杂性来自它的历史，以及项目背后的人所做出的选择和偏好，而这些选择和偏好并不一定符合我的想法。

这时，Jujutsu 出现了。当然，这一代还有其他值得关注的版本控制系统，例如 Meta 的 Sapling，以及作为独立项目发展的 Pijul 等。不过，在这些选择中，我最喜欢的是 Jujutsu。

Jujutsu 与 Git 兼容。这意味着，正如接下来会看到的那样，我们可以直接在现有 Git 仓库上使用它。这是它推广和采用方面的一项巨大优势。事实上，Git 当年能够成功，很大程度上也是因为它能够与 SVN（Subversion）仓库互操作。Jujutsu 的命令行界面则更多受到 Mercurial 的启发，也更符合我所认同的通用界面设计原则，而不是沿袭 Git 的设计。这一点非常好。

Jujutsu 还有一些很有意思的能力。它把冲突作为一等概念来理解，也把移动提交作为一等操作来处理，并且提供了比 Git 的交互式 rebase 更好的体验。Git 的交互式 rebase 我当然会用，也用过很多次，但它本来可以做得更好。Jujutsu 对合并提交有清晰的理解，也知道合并冲突是如何工作的。由于它能够把冲突作为日常工作流程中的一等部分来处理，所以冲突不会让整个工作停摆，也不会阻止你继续前进。你完全可以先说“这个问题稍后再解决”，然后继续做其他工作。

总的来说，Jujutsu 的使用体验在很多方面都比 Git 前进了一大步。有些差异很难在真正使用之前用语言说清楚。我现在每次因为某些原因不得不回到 Git 时——而过去六个月里，这种情况已经越来越少——都会觉得自己像是在泥地里游泳，或者像是在躲避一连串障碍物。无论用什么比喻，体验都不太好。

关于这些问题，我可以讲上一整天；你也可以去读我那篇一万字的文章。不过，我们不如直接看一些例子。接下来几分钟，我会带大家了解 Jujutsu 的基本工作方式。最后，我还会提到社区中另一位成员制作的一个视频：他正在开发一个基于 Web 的用户界面，并计划把它放进一个轻量级的包装应用中，从而能够分发到 Windows、Linux 和 macOS。它的用户界面是基于 Web 技术构建的，使用了一项叫作 Tauri 的技术。关于这些内容，之后可以再去了解更多。虽然我接下来展示的终端演示已经很不错，但那个界面在某些方面甚至更好。不过先别离开，我们现在就开始。

在现有 Git 仓库中使用 Jujutsu

我现在使用的是 iTerm2。先从一个实际例子开始：克隆一个我知道很适合演示的仓库。我把它简称为 tm。True Myth 是一个我经常使用的包，也是我大约七年半前编写的项目。这里使用 GitHub 自己提供的命令行工具 gh 来克隆仓库。gh 有时会在这里卡住，不过这次没有问题。克隆完成后，我进入 true-myth 目录。

现在可以看到，这是一个有着较长 Git 历史的仓库。最近的提交大多是 Dependabot 自动生成的依赖版本更新，因此单看这段历史并没有太多值得说明的内容。我已经安装了 Jujutsu，而且安装的是最新公开版本。接下来展示的内容，都可以通过 Homebrew 安装，也可以从 Nix 软件包获取；当然，也可以使用 Cargo 安装，因为 Jujutsu 是用 Rust 编写的工具。它运行很快，也相当稳定，我很喜欢使用它。

假设我正在开发 True Myth，并且想做一些修改。首先，我可以在这个 Git 仓库里运行：

jj git init

这条命令会让 Jujutsu 接入当前已有的 Git 仓库，并导入底层 Git 仓库中的变更。此时，我还没有在本地关联任何远程分支，因此接下来可以设置跟踪关系：

jj branch track main@origin

这样就建立了一个跟踪分支，和在其他版本控制工作流中设置跟踪分支的方式差不多。

现在先看看仓库状态：

jj status

输出告诉我，工作副本（working copy）是干净的。这符合预期。不过，有意思的是，Jujutsu 会明确标识工作副本。在 Git 中，工作副本的状态与暂存区（index）密切相关；而在 Jujutsu 中，工作副本本身有明确的身份，并且对应着一个提交和一个变更。稍后我会详细解释这一点。

再运行：

jj log

可以看到一份提交历史。乍看之下，它和 git log --oneline --graph 之类的输出差不多，还没有什么特别之处。但请注意，我只是运行了 jj git init，就已经可以在这个仓库里使用 Jujutsu 了。如果查看仓库根目录，原来的 .git 目录、GitHub 相关文件以及其他内容都还在，只是多出了一个 .jj 目录。进入 .jj 后，可以看到其中有仓库数据和工作副本相关目录，这些内容保存着 Jujutsu 自己的内部状态，作用类似于 Git 的 .git 目录。

关键在于，Jujutsu 理解 Git，并且能够与 Git 协同工作。每当我们通过 Git 做了一些操作，Jujutsu 都可以导入这些变化；反过来，当我们通过 Jujutsu 修改一个由 Git 仓库作为底层存储的项目时，这些变更也会提交到底层 Git 仓库中。

例如，我创建一个文件：

touch hello.txt

然后查看状态：

jj status

Jujutsu 会告诉我，工作副本发生了变化，并且新增了一个名为 hello.txt 的文件。这和 Git 的状态信息类似。接下来，我可以给这次变更添加描述：

jj describe -m "whoa"

再运行 jj log，就能看到一个新的提交。它位于 Git 提交历史之上，提交说明是 whoa。这正是我们预期的结果。与此同时，我也可以运行：

git log

会看到同样的提交，因为刚才的操作已经同步写入底层 Git 仓库。

不过，Jujutsu 并不只是一个更好用的 Git 命令行界面。首先，Jujutsu 未来会拥有自己的底层存储后端。这意味着，它可以与 Google 的大型单体仓库（monorepo）协同工作——Jujutsu 正是在 Google 开发的；也可以使用自定义后端，例如通过网络与 FUSE 文件系统协作。它还可以使用自己的原生后端，从而支持 Git 本身并不具备的功能。

即使仍然使用 Git 作为底层存储，我们也能做一些普通 Git 工作流中不容易实现的事情。这是因为 Jujutsu 对版本控制有着不同的理解。尤其重要的一点是：它区分“提交”（commit）和“变更”（change）。

提交与变更：Jujutsu 的核心模型

在 Git 中，我们通常主要考虑提交。Git 的底层当然还有其他概念，如果你是 Git 高手，可能也了解这些内部细节，但对日常操作来说，提交通常就是最基本的工作对象。

Jujutsu 不仅有提交的概念，还有变更的概念。下面通过一个全新的演示仓库来看看它们在实践中意味着什么。

我先创建一个演示目录，进入其中，并初始化一个仓库。这里先尝试指定 Git 后端：

jj git init

如果当前目录还不是 Git 仓库，这样做就会失败，因为它并不是一个现有的 Git 仓库。那么，如果我并不在意底层是不是 Git 仓库，只想直接使用 Jujutsu 呢？当然可以：

jj init

现在，我得到的是一个原生的 Jujutsu 仓库。如果查看它的内部目录结构，会发现它和刚才的仓库大体相似。不过，如果进入存储目录，就会看到其中有一个 Git 文件夹。刚才我没有展示这一点，因为当时还不重要。这里的确存在一个 Git 仓库，它与把 .git 目录直接放在项目根目录下所得到的仓库是一样的。

Jujutsu 允许你采用这种布局，但并不要求你这么做。在与已有仓库互操作时，这种能力很有用。以后我也许会用另一段视频更深入地展示这些内容；今天我只想说明，在需要的时候，Jujutsu 可以创建一个 Git 仓库作为底层存储，但它不必把这个实现细节直接暴露给你，也不必要求 .git 目录出现在项目根目录中。

接下来创建文件 a.txt，写入内容 hello Jujutsu。然后查看状态：

jj status

可以看到工作副本发生了变化。首先介绍一个命令：

jj describe

describe 的简写是 desc。现在我给当前工作副本添加说明：

jj describe -m "add a.txt"

注意，工作副本仍然对应着同一个变更 ID（change ID）。之前我提到过变更 ID，现在看到的就是它。与此同时，它也有一个提交 ID（commit ID）。此时，我们有了一个代表工作副本状态的新 Git 提交。换句话说，工作副本既是一个提交，也是一个变更。这个设计非常巧妙，因为它意味着我们可以直接在原地持续修改同一个变更。

在 Git 中，要实现类似效果，通常需要借助暂存区，或者通过 amend 等方式修改已有提交。Jujutsu 不需要我们采用这种方式。比如，在继续做其他事情之前，我再创建一个文件 b.txt，写入 hey JJ，然后再次查看状态：

jj status

这时，工作副本的变更 ID 仍然和之前相同，但由于底层 Git 仓库中对应的提交发生了变化，所以提交 ID 已经更新。它仍然只是同一个变更。

现在我可以意识到，之前设置的提交说明不够准确：这次变更并不只是添加 a.txt，还添加了 b.txt。因此，我可以直接修改说明：

jj describe -m "add a.txt and b.txt"

由于 Git 的工作方式，底层 Git 仓库现在又有了一个不同的提交，但 Jujutsu 中的变更 ID 仍然保持不变。

这正是 Jujutsu 强大之处的一部分：一个变更的历史可以不断演化，而不必把底层 Git 提交视为不可更改的最终记录。Jujutsu 可以持续更新这个变更的状态，并在需要时把旧版本保留下来供追溯。

追踪变更的演化与恢复操作

如果我想看看这个变更是如何随时间演化的，可以运行：

jj obs log

这里的 obs 是 observation 的缩写。这个命令也许将来会改成类似“evolution log”的名字；社区目前还在讨论这件事。命令输出中有一处高亮内容，它表示识别这个对象所需的最短标识符。在 Jujutsu 的很多操作中，这个标识符甚至只需要一个字母。

例如，我可以用变更 ID 对应的修订来查看演化历史：

jj obs log -r <change-id>

这样就能看到这个变更随时间发生过的变化。输出中的一些版本会被标记为隐藏，因为它们已经不再属于当前有效的变更状态。最初，这个变更只是一个空提交，没有任何文件内容，也没有设置描述；它对应着一个早期标识符。随后，在同一个变更 ID 下，它演化到了后续版本。

每当我们运行 jj status 或其他 Jujutsu 命令时，Jujutsu 都会对工作副本进行快照。如果底层使用 Git 存储，它也会创建相应的 Git 提交，同时保留同一个变更。因此，你实际上会看到多个 Git 提交，它们分别对应同一变更在不同时间的状态。之后，这些不再需要的提交可以由 Git 的常规垃圾回收机制处理。

更重要的是，如果我们想恢复其中某一个旧版本，也可以做到。我们能够看到一个变更如何通过这些 Git 提交逐步演化，并且可以在需要时恢复某个历史状态。当你想弄清楚“我刚才到底做了什么”时，这会非常有用。在 Git 中，虽然可以通过 reflog 在一定程度上做到类似的事情，但操作起来并不轻松；而在 Jujutsu 中，这种能力是直接提供的。

仓库整体也有类似的历史记录。运行：

jj op log

这里的 op 是 operation，也就是操作。它会展示整个仓库中发生过的每一次操作。这比 Git 的 reflog 更完整一些。请注意，其中不仅包括提交相关操作，也包括诸如“因为你运行了 jj status，所以对工作副本做了一次快照”，或者“因为你运行了 jj describe，所以更新了这个提交”这样的记录。你所做的每一项操作，都会出现在操作日志中。

如果想回到操作历史中的某个时间点，可以取得对应的操作修订 ID，然后运行：

jj op restore <operation-id>

这样就能恢复到那个操作发生时的仓库状态。我现在不打算这样做，因为我想保留 a.txt 和 b.txt，但这确实是一项非常强大的能力：你可以直接查看仓库的操作历史，并且回到历史中的任意一个时间点，轻松恢复当时的状态。

这也意味着，Jujutsu 自带一个非常方便的撤销命令：

jj undo

它相当于找到最近的一次操作，并恢复到这次操作发生之前的状态。任何操作都可以撤销，包括修改提交说明这样的操作。

例如，我再运行一次 jj op log，可以看到刚才修改了描述。如果我想撤销这个描述修改，只需输入：

jj undo

工作副本就回到了之前的状态：它的描述又变回只添加 a.txt。值得注意的是，这里恢复的是我们之前使用的同一个 Git 提交 ID。底层并没有在这段时间内把它垃圾回收掉，因此我们能够直接回到那个状态。

再查看操作日志，会发现刚才多了一条 undo 操作。如果我又想撤销这次撤销，因为我希望回到同时包含 a.txt 和 b.txt 的描述状态，也可以像刚才一样使用 jj op restore，恢复到撤销操作之前的那个操作状态。这样，我们就回到了原来的位置。整个操作日志也会相应地显示这次恢复。

这些能力主要体现在底层机制上。不过，大多数时候，我只是在仓库里提交代码、修改文件，并把工作推进下去。接下来看看更日常的操作。

拆分变更，创建新的提交

我再创建一个文件 c.txt，写入 neat JJ is cool，然后运行：

jj status

这时我意识到，我并不想让 c.txt 成为当前这个提交的一部分，而是希望把它放进一个新的提交里。

在 Git 中，我需要使用暂存区来控制哪些内容属于某个提交、哪些内容不属于它。而在 Jujutsu 中，我只需要运行：

jj split

这里我使用的是一位贡献者提供的、内置的语义化 diff 编辑器（semantic diff editor）。在编辑器中，我可以把 a.txt 和 b.txt 保留在第一个部分。这个部分的提交说明可以是 add a and b，这和之前的内容一致。然后，我可以为第二个部分添加说明：add c.txt。

现在，我就得到了两个部分。第一个部分仍然是原来的那个变更，变更 ID 没有变化，但提交 ID 更新了；第二个部分则是一个新的变更。运行 jj log，就可以看到它们之间的关系。

我经常需要做这种事情。过去，我通常使用 Git 暂存区来完成；而在 Jujutsu 中，我可以一直修改工作副本，直到它达到自己满意的状态，然后输入：

jj new

这样就会创建一个新的提交。

前面我展示过 jj describe。Jujutsu 也有 jj commit 命令，可以像之前那样直接使用一条消息提交。但 jj commit 实际上只是 jj describe 和 jj new 的简写组合。也就是说，我可以在任何时候创建新的提交，也可以在之后单独修改它们的描述。

例如，假设我现在位于一个新的空提交上，准备继续做一些工作，但我不喜欢当前的描述。我可以运行：

jj describe -r <revision> -m "add c.txt to the history"

这里需要指定要描述的修订。只要给出对应的修订标识符，就可以修改那个提交的说明。完成后，Jujutsu 会提示它对一个后代提交进行了 rebase。原因是，我修改了这个提交的父提交。记住，在 Jujutsu 中，@ 符号始终表示当前所在的位置，也就是当前工作副本在仓库历史中的位置。

再看一下日志，整体结构仍然和之前一样。我现在位于一个空提交上，但它的父提交说明已经被修改为 add c.txt to the history。我还可以给更早的那个提交换一个完全不同的描述，例如把它改成 start it up with a and b。执行后，Jujutsu 会对两个后代提交进行 rebase。也就是说，我只是在提交图中修改了一个较早提交的描述，位于它上方的提交也会随之重新定位。这种操作在 Jujutsu 中很自然；如果使用 Git，通常需要执行 git rebase --interactive，而且过程会更繁琐。

在历史中移动，并在原地修改提交

现在我再创建一个文件 d.txt，写入 D，然后运行：

jj status
jj commit -m "add D"

这里没有什么特别之处。

不过，如果我想回到之前的某个提交，并对它进行修改呢？在 Git 中也能做到，但通常需要使用交互式 rebase，再配合 amend、squash 等操作。在 Jujutsu 中，我只需要移动到想编辑的修订：

jj edit <revision>

例如，我想给 c.txt 增加一些内容，就可以切换到对应的提交。此时再看仓库状态，@ 表示我当前所在的位置。我只是向后移动到了历史中的一个提交，这并不是什么问题。刚才创建的 D 就不再处于当前工作副本的位置了。

Jujutsu 会自动把后代提交 rebase 到更新后的工作副本上，因为我们正在原地修改这个变更。它会提示有一个后代提交被重新应用到工作副本上。我们现在编辑的是同一个变更，而不是必须创建一个全新的提交，再手动处理后续历史。这种方式很不一样：在 Git 中，你并不能轻易获得这样的自动 rebase 行为。

如果我想在两个提交之间再插入一个提交，也同样很简单。我可以运行：

jj new <revision>

例如，指定某个提交作为新提交的父提交，就能在它和后续提交之间创建一个新的空提交。Jujutsu 会自动对后代提交进行 rebase。现在我位于这个新创建的空提交上，可以做一些不同的事情：再次创建 d.txt，写入 different way to get D in the repo，然后给这个提交添加描述。

这样就可能产生一个冲突。问题在于，之前的自动 rebase 已经把一个后代提交重新应用到当前工作副本上，但我们现在又在另一条历史路径中添加了 D。于是，同一个文件在两个提交中都发生了变化。

我们可以切换到另一个提交查看状态：

jj edit <revision>
jj status

这里会出现冲突，因为这个提交也添加了 D。文件中会出现冲突标记。从外观上看，它与 Git 中常见的冲突标记没有太大区别。但有意思的是，Jujutsu 允许我们带着这个冲突继续工作，并不会因此陷入停顿，也不会强迫我们立即解决冲突。

我完全可以说：“这个问题稍后再处理，我现在还有其他事情要做。”即使当前存在冲突，也可以继续创建新的文件、修改其他内容。例如，我再创建一个 e.txt，然后继续工作。Jujutsu 对这种情况完全没有问题。即使 d.txt 仍然处于冲突状态，我也可以继续向前推进。

甚至在冲突之后，我仍然可以继续修改这个文件。Jujutsu 不会因此阻止我。查看状态时，d.txt 依然显示为冲突，但我仍然可以继续创建新的提交。之后，我们再回来处理这个冲突即可。

在不停止工作的情况下解决冲突

现在我们来解决刚才留下的冲突。大致有两种方式：第一种是直接编辑冲突文件，就像刚才看到的那样；第二种是基于冲突所在的提交创建一个新的提交，在这个新提交中完成修复。

到目前为止，我运行 jj new 时都没有带参数。实际上，可以给它传入一个修订标识符，这个修订就会成为新提交的父提交。例如，我可以基于之前那个存在冲突的提交创建一个新提交。这样，我就创建了一条分支。

从 Jujutsu 的角度来看，分支并不是什么特别复杂的东西：我只是创建了一个以某个提交为父提交的新提交，它自然就与原来的提交分开了。现在我已经切换到这个新提交，可以在这里解决冲突。

最简单的方式就是直接编辑文件，保留冲突两侧都需要的内容，并调整相应的标点。完成后，合并冲突就解决了。再查看状态，这个提交已经没有冲突。

接下来，我希望把这个解决冲突的提交合并到它的父提交中。如果从 Git 的思路考虑，我可能需要先 squash，再执行 rebase，才能让最终历史变成自己想要的样子。但在 Jujutsu 中，我不需要这么做，只需运行：

jj squash

这会把当前提交的内容压入父提交。输出会告诉我，有一个冲突得到了解决。再看提交图，原来那个冲突已经消失了，不过另一条分支或变更中仍然存在冲突。这是因为我之前还在那条路径上给文件添加过一些内容。

因此，我可以再创建一个基于那条变更的新提交，检查文件内容。这里的状态也是合理的：我们之前确实把一个带有冲突的变更提交了，所以现在仍然能看到一些额外的冲突内容。不过，我可以检查文件，发现实际上只需要保留其中一部分。使用能够理解差异的工具处理这类内容也完全没有问题。现在，我再次解决冲突。

运行：

jj status

可以确认冲突已经解决。接下来仍然可以把当前提交 squash 到父提交中。之前存在的冲突已经得到解决，或者被放弃；如果某些冲突内容不再重要，也可以直接丢弃。现在，仓库里已经没有冲突了。之前为了修复冲突而创建的额外分支也消失了，因为我们把那个额外的空分支提交合并掉了。于是，我们可以继续正常工作。

这其实很有意思。在 Git 中，这样的操作可能会非常痛苦，也很难处理；而在这里，我们刚刚完成了整个过程。我甚至是用比较困难的方式完成的，因为我直接在 d.txt 里用普通文本编辑器处理了冲突。如果愿意，我也可以使用：

jj resolve

配合 diff 编辑器来解决冲突。以后的视频中，我会展示这种方式，也会进一步说明 Jujutsu 在 rebase 场景下还能如何发挥作用。

总结：版本控制可以更自然

今天的演示已经差不多有三十分钟了，先讲到这里。最重要的是，希望大家看到：Jujutsu 很有意思，它能够完成一些在 Git 中比较困难的操作，而且整个过程又显得相当自然。它的界面设计不错，创建分支也很容易，之后我们还会继续讨论这些内容。

总体而言，使用 Jujutsu 的感觉就是很多事情本来就应该如此。等你再回到 Git 时，可能会突然意识到：“等等，我这些年来一直都是这样工作的？”是的，过去确实如此，但其实我们不必一直这样。

希望这次对 Jujutsu 的深入入门介绍对你有所帮助。之后我还会在某个时候继续制作相关内容。如果你想知道后续视频什么时候发布，可以订阅频道。如果你喜欢这期视频，也请点个赞，并把它分享给其他人，帮助更多人发现这项内容。

感谢观看。

Sundar Pichai：AI 的无限可能、算力短缺与下一代产品形态

我们仍处在这项重大技术变革的早期

为什么 Google 必须继续站在 AI 前沿？

我认为，我们现在仍处在有史以来最具深远影响的技术变革的早期阶段。这不是一项尚未真正落地、还停留在实验室里的技术；人们已经在使用它，而且它正在改变工作与生活。对 Google 来说，站在 AI 技术前沿不是阶段性的战略选择，而是公司的基因和长期承诺。我们一直在推动技术边界，从 Transformer 研究一路走到今天，我们不会选择一条只满足于“够用”的道路。

外界曾经有一种看法，认为 Google 已经放弃了前沿模型，只打算开发速度更快、能力达到一定标准的模型，再把它们整合进产品。这种判断是完全错误的。前沿领域竞争非常激烈，也在快速变化；这恰恰令人兴奋。我对 Argon 的研发成果感到满意。我们没有急于发布，而是花时间进行安全测试，并谨慎部署。考虑到它的能力，我们的发布节奏比其他模型稍慢，但我认为这是值得的。

Argon 在智能体任务、知识工作、编程和创意任务等多个方面都属于非常优秀的前沿模型。发布后的最初 72 小时内，它的使用量接近 25 万亿 tokens，约为 Gemini 3.0 在发布后最初 72 小时使用量的 3 倍。需求非常旺盛，我们在提供服务时也受到算力容量限制。与此同时，前沿模型没有一个可以一劳永逸的终点：即使一个模型相较两个月前的水平已经全面进步，仍然会有需要改进的局部领域。例如在编程方面，我们已经从用户反馈中看到一些具体问题，也知道哪些地方需要继续提升。

我并不认为所有产品都必须使用规模最大、能力最强的模型。不同尺寸、不同能力和不同成本结构的模型都有存在价值。我们推出 Flash 等模型，就是因为产品体验需要在能力、速度和成本之间取得平衡。前沿模型往往更慢、成本也更高，因此一些很好的产品体验完全可以由非最前沿模型提供。但 Google 仍会同时追求高能力模型和不同层级的模型，并关注能力与成本之间的 Pareto 最优边界。

站在前沿的价值，不只是让我们在基准测试中领先，更重要的是能更早看到新能力的出现，从而提前为未来做好准备。我们在消费者业务和企业业务中都有广泛的应用场景；一些云客户明确希望获得前沿模型。前沿模型也可能更擅长开发下一代模型。在递归式自我改进逐渐成为研究方向的时代，这一点尤其重要。我们在内部把前沿模型部署给开发者后，已经看到明显的能力跃迁：它能处理此前模型无法解决的问题。处于前沿，意味着处于创新前沿，也能推动组织自身的创新。

多智能体、自我改进与 AI 安全

AI 会如何从单个模型走向多个智能体协同？

我认为，接下来一个令人兴奋的方向，是多个智能体能够协同完成复杂任务。整个行业一直在研究具有长期执行能力的智能体，但未来的系统不会只是一个模型独自完成所有事情，而会是多个智能体共同工作。无论是消费者还是企业用户，都将能够使用某种多智能体框架，让多个智能体持续运行、分工协作，并在需要时完成任务。这就是为什么我会把当下形容为一个充满无限可能的时刻。

我们离真正的递归式自我改进还有多远？

Argon 的研发确实使用了模型帮助开发模型的方式，这也是其中一项重要创新。但需要准确描述我们今天所处的位置：我们距离完全自主、达到最终形态的递归式自我改进仍然很远。现在更恰当的说法是，在模型开发的不同环节中，AI 研究人员与 RSI 循环共同工作；智能体以一定程度的自动化方式帮助研究人员协作构建模型。它不是一个已经脱离人类、能够无限自我迭代的系统。这个方向非常令人兴奋，我预计这种人机协作的连续进展还会在未来一段时间持续发生。

当模型并不总是完全按照人类意图行动时，安全如何保障？

我认为，安全与网络安全一样，需要采用纵深防御，而不能只依赖单一措施。模型对齐当然重要，我们投入了大量工作，尽可能让模型的行为与人类意图保持一致。但对齐仍然是一个活跃的研究领域，存在明确的不足和差距。我们不能假设只要完成对齐训练，风险就会自然消失。

除了对齐，我们还投入大量资源进行实时监控。在模型执行任务的过程中，我们需要获得足够好的遥测信息，理解系统正在做什么；一旦发现意外行为，就能够及时介入。监控本身的架构也很重要：模型应当在沙箱和隔离环境中运行，同时监控机制必须能够实时发挥作用，而不妨碍系统完成合理任务。这些都是我们持续投资的方向。

部署到企业环境时，客户也必须拥有控制权，包括实时监控能力、决定模型部署位置的权利，以及明确限定模型能够访问哪些数据。我们需要让企业客户决定模型可以接触什么信息、在哪些环境中运行，以及如何监督其行为。安全部署还需要专门分配算力资源，不能把所有计算资源都用于提升模型能力，而忽略测试、监控和安全保障。

我认为，整个行业需要不断提高标准，投入足够时间把这些工作做好。对风险保持担忧是合理的，关键在于尽早思考还能采取哪些措施。行业已经在增加模型对齐、安全测试等方面的工作；下一步应当推动跨行业标准，建立更一致的评估方式，并引入独立评估机构。我们可以参考金融控制体系：金融行业有会计准则，也有独立审计机构。AI 行业同样需要逐步建立标准和独立评估机制。监管也会在这个过程中发挥作用。

世界模型、物理理解与通向通用智能的路径

为什么 Google 同时研究语言模型和世界模型？

人类并不是只通过语言理解世界。我们会感知周围环境，接收各种输入，并理解物理世界如何运行。因此，我认为让模型理解物理定律、以高保真度模拟世界，是构建智能的重要基础能力。Google 同时推进语言模型和世界模型研究，是因为我们希望探索所有可能推动智能发展的路径，而不是过早地认定只有一种技术路线。

机器人是一个很直观的例子。Argon 在具身推理基准测试上处于领先水平，这并非偶然，也与我们长期构建世界模型的经验有关。模型如果要在真实世界中行动，就需要理解环境、物体和物理规律，而不仅仅是生成文本。我预计未来会出现能够把这些能力融合起来的架构。但在现阶段，我们希望在智能发展的这条“崎岖前沿”上，尽可能站在各种可能方法的前沿。多条研究路线能够相互促进，帮助我们获得更好的研究成果和洞见，也有助于最终构建更强大的通用人工智能模型。

算力：长期战略、资源约束与投资取舍

为什么算力成为 AI 竞争中最稀缺的资源？

算力是当前 AI 研发中最重要、也最稀缺的资源之一。研究人员通常会认为，计算机越大，能够训练和运行的 AI 就越强。如果把最大的计算资源交给研究人员，即使这会在短期内牺牲云业务等业务的利润，他们也会希望获得尽可能大的计算能力。这种取舍并不容易，因为算力既要支持前沿研究，也要服务客户和现有业务。

今天我们拥有的算力，很大程度上取决于我在 2024 年作出的决策。回头看，现在不只是 Google，其他公司也都面临算力短缺；每家公司都希望自己当初规划的算力能够再多一倍。AI 技术能力提升得很快，需求也在迅速增长，因此算力规划不可能完全准确。我们需要综合考虑需求信号、底层技术能力、供应情况和长期发展趋势，同时避免仅仅因为眼前需求强烈就做出不负责任的投资。

我把算力看作长期战略资源。Google 的不同业务有各自独立的经营目标和责任，但公司必须为它们规划长期算力发展路径。云业务团队需要为客户提供服务，也需要有明确的长期算力轨迹；与此同时，前沿 AI 研究需要足够的资源。我们必须在这些目标之间作出安排，而不能只看某个季度的财务结果。对支持前沿 AI 发展所需的投资而言，这是一项长期承诺。

我也认为，AI 产业正在经历一个非常特殊的建设周期。有人担心数据中心和基础设施会不会过度建设，历史上技术产业确实出现过过度投资的情况，例如光纤建设周期。但我们不能简单地把过去的经验机械套用到今天。当前这项技术已经被广泛使用，技术能力仍在快速提升，需求也在扩张。判断是否建设更多基础设施，需要同时观察需求信号、技术进步和实际利用情况。我们必须保持纪律，既不能因为害怕过度建设而错失长期机会，也不能忽略投资可能带来的成本与社会影响。

Google 如何在研究、云业务和商业回报之间作出平衡？

我不会把问题理解为“要么支持研究，要么保护云业务”。Google 必须同时做好这些事情。我们需要让研究人员拥有足够强大的计算资源，也需要为云客户提供可靠的服务，并对不同业务的长期算力需求作出规划。算力分配和投资决策会影响未来数年的竞争位置，因此不能只以短期利润作为唯一标准。

我知道外界会关注我们是否把算力优先用于自家模型，是否愿意以更高成本向外部购买算力，以及云业务是否因此受到影响。我的基本判断是，算力投资必须围绕长期能力建设展开。我们需要持续投资基础设施，也需要理解市场供需变化，不能假设任何时候都能轻易获得额外算力。今天出现的短缺，正是过去数年规划与当前需求共同作用的结果。

AI 将如何改变人与计算机的交互界面

未来的界面还会是搜索框、应用和菜单吗？

我认为，未来的交互方式会变得更加自然。今天人们使用计算机时，往往必须先知道应该打开哪个应用、点击哪个按钮、输入什么指令。AI 可以改变这种模式。用户不一定要把需求整理成结构化、精确的命令，而是可以像与人交谈一样表达自己的意图，甚至可以先随意描述、边想边说，再由系统理解真正想完成的事情。

我自己使用这类系统时，也会直接说出尚未整理好的想法，甚至只是把思路讲出来。系统应当能够理解上下文，不要求用户每次都以非常正式的方式提出请求。比如，用户可能希望观看一段视频，也可能希望完成某项工作；系统需要理解用户当下的目标，并在适当的时候提供帮助。理想的体验应当无缝、自然，而不是让用户不断在不同工具和界面之间切换。

未来的 AI 助手可能会持续在后台工作，并在合适的时机采取行动。用户仍然需要知道系统正在做什么，也需要能够介入、调整和控制任务。我们正在从“人主动操作软件”走向“人表达目标、AI 协助执行”的交互方式。多智能体系统将使这种变化更加明显：不同智能体可以在后台处理不同任务，而用户通过统一的界面了解进度并作出决定。

Google 的既有产品能否适应 AI 原生的交互方式？

这是 Google 必须认真面对的问题。OpenAI 等 AI 原生公司给整个行业带来了很大的推动，也迫使 Google 作为一家公司加快思考和行动。关键不只是把一个聊天框放进现有产品，而是重新思考用户如何完成任务，以及搜索、Gmail、地图和其他产品表面如何协同工作。

我不认为传统产品和 AI 原生产品之间只能二选一。Google 拥有广泛的产品组合、用户基础和服务场景，这些产品可以成为 AI 能力触达用户的重要入口。但我们也必须适应智能体时代，重新设计产品体验。某些功能会以独立服务的方式存在，某些能力则会融入现有产品；重要的是让用户在不同场景中获得连贯、统一的体验，而不是被迫理解 Google 内部不同产品和系统之间的边界。

从软件开发者的使用方式可以看到这种变化。今天，开发者已经不再希望完全按照过去的方式逐行编写所有代码；AI 能够参与复杂任务，帮助人们提高效率。类似的变化也会发生在普通消费者的工作流中。AI 界面会创造新的价值，但这并不意味着现有产品的价值会立刻消失。未来一段时间，市场会同时存在新的 AI 原生体验，以及对既有产品的持续改造。

我们希望 Gemini 成为跨产品体验的重要组成部分。用户会在 Gemini 应用中使用这些能力，也会在 Google 的不同产品和服务中接触到它们。我们的目标是让 Gemini 能够处理更复杂的智能体任务，并在不同界面之间提供一致的体验。相关能力会由更先进的模型提供支持，而不是局限于单一聊天窗口。

Gemini、Muse、Dots 与未来的智能体产品

用户未来会怎样使用持续工作的 AI 智能体？

我认为，消费者和企业用户最终都会获得某种多智能体框架。多个智能体可以持续工作、分工处理任务，并在需要时与用户沟通。它们不是只在用户输入一句话后给出一次回答，而是能够围绕一个目标持续推进工作。用户可以在适当的时候介入，检查任务状态、修改方向或批准下一步行动。

这也意味着产品形态不会只由单一应用决定。Gemini 可以成为用户接触智能体能力的重要入口，但不同能力也可能分布在其他产品和服务中。我们要做的是把这些体验组织起来，使它们能够在用户需要的地方发挥作用，而不是要求用户自己理解背后的模型、智能体和基础设施。

访谈中主持人询问 Google 的 Muse 或 Dots 产品进展。我的回答重点是，未来用户——无论消费者还是企业——将能够使用多智能体框架，让智能体持续执行任务。这一方向体现了 AI 产品从单轮问答走向长期任务执行的变化。字幕没有提供 Muse 或 Dots 的具体发布日期、功能清单或商业化细节，因此不能据此推断尚未公布的产品安排。

与 Apple 的合作及 AI 生态

Google 如何看待与 Apple 的 AI 合作？

访谈谈到 Google 与 Apple 的合作，以及 Apple 如何把外部 AI 能力整合进自己的产品。我的态度是，这类合作对双方都有意义。Apple 在产品体验和生态整合方面做得很好；通过合作，相关模型和技术可以帮助 Apple 改善 Siri 等体验。主持人进一步询问双方是否会开展更多合作，但这段字幕没有给出明确的新增合作承诺，也没有披露具体合作范围之外的安排。

从行业角度看，AI 能力不会只存在于某一家公司的应用中。不同平台和产品会以不同方式整合模型、智能体和云端服务。对用户而言，重要的是这些能力能否真正改善产品体验，而不是用户必须关心背后由哪家公司提供了哪一层技术。

太空数据中心与长期基础设施布局

为什么 Google 会考虑把数据中心送入太空？

我认为，很多技术在刚开始时看起来像科幻，但经过十年到二十年的持续投入，就可能变成有实际意义的技术。Waymo 就是一个例子：从早期看起来非常超前的技术探索，到后来逐步成为能够在现实世界运行的系统。量子计算也是类似的长期投入方向。我们在量子领域已经投入了很长时间，访谈中我提到这段旅程大约已经持续近二十年。

太空数据中心是另一个长期方向。我们在这方面的探索大约开始了两到三年。我认为，未来把计算基础设施部署在太阳同步轨道上可能具有合理性，因为这样能够持续获得太阳能，也就是我们能够利用的最丰富能源之一。随着 AI 对算力的需求呈指数级增长，长期来看，能够 24 小时持续获得能源的轨道环境可能会变得有吸引力。

当然，这是一项非常有挑战性的工程。团队为项目设定了有纪律的阶段性里程碑。把 TPU 送入太空是其中一个令人兴奋的重要节点。访谈录制时，我们预计这些 TPU 即将迎来一个类似“Hello, World”的首次成功运行时刻。我期待看到这一进展，也会继续在这一方向投入。

这并不意味着太空数据中心会立刻替代地面数据中心。它是面向长期算力需求的多项探索之一。我们需要评估工程可行性、能源优势、部署成本和运行可靠性，并按阶段推进。

AI 对 Google 内部软件开发的影响

AI 已经在多大程度上参与 Google 的代码开发？

此前我曾提到，Google 内部约有 25% 的代码由 AI 编写。现在，单纯用这个比例衡量 AI 的影响已经没有太大意义，因为我们触及的几乎每一部分代码，都已经深度受到 AI 的影响。更值得关注的是，AI 是否让工程师能够承担过去难以完成的复杂项目，以及最终的软件质量是否得到改善。

以 Argon 为例，我们观察到一个明显的拐点：工程师开始使用它处理复杂项目，其中包括影响数百万行代码的项目。Argon 发布后的四周内，我们看到销售额提高了 30%；更重要的是，回滚数量也出现了幅度接近三分之一的下降。也就是说，工程师不仅能够更高效地编写代码，而且产出的代码质量也在改善。

因此，我们正在使用更新的指标来跟踪 AI 对工程工作的影响，而不是只统计有多少代码由 AI 生成。生产效率、项目复杂度、代码质量和回滚情况，能够更全面地反映 AI 工具是否真正改善了软件开发。

数据中心建设、社区责任与能源成本

面对数据中心建设引发的社区担忧，Google 应当怎么做？

我们非常重视以负责任的方式建设数据中心。我走访过一些 Google 长期运营大型数据中心的社区，也会与当地居民交流。有些居民会告诉我们，他们的孩子因为 Google 在当地的投资而有机会上大学。我们与这些社区共同成长，这说明数据中心投资能够带来就业、教育和其他长期收益。但这并不意味着建设项目可以忽略当地居民的担忧。

我认为，关键是从项目早期就与社区沟通，保持透明，并认真理解项目对周边地区的影响。对于这些项目，我们承诺带来新增电力，并承担项目所需电力的 100% 成本。我们还需要尽早了解社区和邻里受到的影响，与当地居民合作解决问题，而不是等到数据中心建成、争议出现后才开始回应。

如果能够以正确的方式推进，数据中心建设与社区发展并不必然冲突。但行业不能假设所有企业都会采取相同做法。居民突然发现大型数据中心建在自家后院附近，感到惊讶或担忧，是完全可以理解的。整个行业都应当在沟通、透明度和责任落实方面做得更好。

从长期角度看，太空数据中心等探索也与基础设施选址有关。未来我们需要更多数据中心，而把它们放在不同环境中，可能会带来不同的成本、能源和社区影响权衡。但这类长期探索不能成为今天忽视社区责任的理由。

AI 研究中的其他关键突破方向

除了更大的模型，Google 还在押注哪些研究方向？

我们并不是只押注一种技术路线，而是在多个方向同时投入。Argon 支持一百万个输出 tokens，是其中一个值得注意的进展。早期 Gemini 模型在输入侧实现了一百万 token 的上下文窗口，也体现了我们持续推进长上下文能力的努力。

除此之外，我们还在研究合成数据、持续学习和更高效的模型架构。持续学习关注的是模型发布后能否继续更新和学习，而不是每次会话结束后就失去此前积累的能力。更高效的架构则有助于在有限算力条件下提升模型能力和运行效率。世界模型也是我们持续投入的方向之一。

我们会把有意义的一部分算力专门用于这些研究押注。它们与主线模型开发并不是彼此割裂的：研究过程中出现的想法，有时会逐渐成熟，并最终进入主线模型。因此，即使某些探索尚未成为公开产品，也可能对后续模型能力产生重要影响。我们会在这些方向上同时进行多项尝试。

技术乐观主义：创新必须服务于人类

如何在承认风险的同时，继续对技术进步保持乐观？

我对技术进步抱有深刻的信念，因为从我个人的人生经历来看，技术进步以及技术可及性的提升，确实能够改善人们的生活。这种亲身经验构成了我乐观态度的基础。但我从来不认为，技术乐观主义意味着想做什么就做什么，也不意味着只要建造出某种技术，社会就一定会自动从中受益。

人类始终需要努力驾驭技术，让技术以正确的方式服务社会。我们必须把技术建设放在人类福祉的框架下，努力让人的处境变得更好。这应当成为我们开发和部署技术时最重要的目标。真正的乐观主义不是盲目乐观，而是在认识风险、认真解决问题的同时，相信技术能够带来进步。

主持人以萨尔瓦多的一个城镇为例：五年前，当地曾经对比特币和区块链充满热情，建设活动一度十分繁荣，但后来发展没有达到人们的预期。再次访问时，那里已经像一座鬼城，留下许多未完工的建设项目。这个例子说明，创新需要下注，也需要乐观，但投资并不总会按预期兑现，失败还可能给社区带来真实后果。对此，我的看法是，技术发展需要承担风险，但更需要明确我们究竟在为谁建设、希望解决什么问题，以及如何让技术真正改善社会。

我认为，我们现在仍处于未来进步的非常早期阶段。人们经常谈到医疗保健等领域，但大量影响可能还在前方。技术有机会从根本上降低许多事物的成本，尤其是那些长期以来持续变得越来越昂贵的领域；它也有机会帮助人类发现新材料，并从根本上改变某些行业的发展曲线。今天我们很难完全理解这些变化最终会有多深远，但我相信它们会产生非常重大的影响。

与此同时，我们必须正当地担忧技术可能出错的各种方式。正是认真对待这些担忧，才能推动我们找到解决办法。乐观与谨慎并不矛盾，而是必须同时存在：我们要相信技术能够改善人类生活，也要对潜在风险保持清醒，并投入足够的工作来处理它们。

结语：无限可能伴随着责任

我对 AI 的未来非常乐观，因为我们才刚刚开始看到这项技术能够带来的变化。前沿模型、多智能体协作、世界模型、持续学习、更加自然的交互界面，以及新的计算基础设施，都可能推动下一阶段的进步。但这些进步不会仅凭模型能力增长而自动变成社会价值。我们必须同步做好安全研究、独立评估、企业控制、基础设施建设和社区沟通。

对 Google 来说，真正重要的不是单纯追求更大的模型或更多的算力，而是持续推动技术前沿，并把技术转化为能够改善人类处境的产品和服务。我们需要保持创新的雄心，也需要承担与之相匹配的责任。技术乐观主义只有在服务于人类、认真面对风险并努力让社会从中受益时，才具有真正的意义。

P1P2 科学方法

物理定律的特征：物理学与数学的关系，以及科学的方法

面对听众的挑战

今晚我能看到观众席了，所以我也能从人数上判断出来——上一次我眼前只是一片黑压压的影子——今晚一定有许多在座的朋友对物理学并不十分熟悉，也有不少对数学不太精通，我毫不怀疑，其中还有一些人既不懂物理也不懂数学。这对一个要讲"物理学与数学的关系"的演讲者来说，确实构成了相当大的挑战。不过，这个挑战我并不会接受。我发表这个演讲的题目时，用的是清晰明确的语言，我没有把它包装成它并不是的东西。题目就是"物理学与数学的关系"，如果你发现在某些地方需要一点物理学或数学的基础知识，我也没办法。

数学在复杂情境中的应用

在思考数学对物理学的应用时，我们很自然地会想到：当涉及大量数字和复杂情况时，数学就会非常有用。举例来说，如果我们去看生物学，一个病毒对一个细菌的作用，如果你在显微镜下观察，那完全是非数学的、杂乱无章的抖动。病毒在这个奇形怪状的细菌上找到某个位置——每个细菌的形状都不一样——找到某个点，也许它把 DNA 推进去了，也许没有，诸如此类。然而，如果我们对数以百万计、数十亿计的细菌和病毒做实验，那么通过取平均值、处理大量数据，我们就能学到很多关于病毒的知识。我们可以利用求平均过程中涉及的数学，看看病毒是否在细菌体内发育出了新的菌株，比例是多少，由此我们可以研究遗传学、突变等等。

再举一个更简单的例子。你想象一块巨大的棋盘，用来下跳棋或者西洋跳棋。如果棋盘非常大，那么任何一步的实际操作并不是数学性的，它非常简单。如果是数学性的话，棋子要么往这边走，要么往那边走，沿着对角线走，或者到达底线变成王，然后可以往后走。换句话说，规则的表述非常简单，并不真正涉及任何数学。但是你可以想象，在一块巨大的棋盘上，有非常多的棋子，对最佳走法、好走法或坏走法的某种分析，也许可以通过一种深层的推理来完成，需要有人先离开去深入思考一番——那就变成了数学，那种抽象的推理。

再举一个例子，计算机中的开关。如果你只有一个开关，它要么是开的，要么是关的，这没什么数学可言，尽管数学家喜欢从这里开始他们的数学。但是，当所有的互连和线路都考虑进来，要弄清楚一个非常大的系统会怎样运作，那就需要数学了。

我想立刻说明一点：数学在物理学中有一个最主要的应用——当然它的应用非常广泛——那就是在讨论复杂情况中的详细现象时。给定游戏的基本规则，数学在复杂情境中有着巨大的应用。如果我只谈数学与物理的关系，我会把大部分时间花在这上面。但既然这是一个关于物理定律特征的系列讲座，我没有时间去讨论数学在物理学中用于计算复杂情况的应用。我们直接转向另一个问题——基本定律的特征。

基本定律中的数学

如果我们回到跳棋的比喻，基本定律就是棋子移动的规则。数学可以被应用于复杂的情况，以弄清楚下一步该怎么走、在复杂局面中什么是好棋。但基本定律的简单特征只需要非常少的数学。

然而，物理学中奇怪的事情是：对于基本定律，我们仍然需要数学。我举两个例子，一个其实不太需要数学，另一个则需要。

物理学中有一个叫做法拉第定律的规律，它说的是：在电解中，沉积的物质量与电流以及电流作用的时间成正比。也就是说，物质量与通过系统的电荷量成正比。这听起来很数学化，但实际上发生的事情是：通过导线的每个电子都携带一个单位的电荷。举一个具体的例子，也许沉积一个原子需要一个电子过来，那么沉积的原子数就必然与流过的电子数成正比，也就是与通过导线的电荷量成正比。所以，这个看起来具有数学形式的定律，其基础并不需要真正深刻的数学知识——只不过是一个电子对应一个原子，使它能够沉积下来。这并不深刻。这确实是数学，我不得不说"数字一"，但这不是我今晚要谈的那种数学。

牛顿引力定律的数学性

另一方面，如果我们看牛顿的万有引力定律，它有这样一些特征，我上次已经写下来了，只是为了让你们感受数学符号传达信息的速度。我们说过，力与两个物体质量的乘积成正比，与它们之间距离的平方成反比。物体受到力的作用后，会改变速度或改变运动方向，改变的量与力成正比，与质量成反比。好了，用文字说出来也没问题，我并没有写方程。但它仍然是某种数学性的东西。我们会疑惑：这怎么能是基本定律呢？那边那颗行星是怎么做的？它看着太阳，看看有多远，然后决定用它内部的计算器算出距离平方的倒数，然后据此决定自己该移动多少？这当然不是对引力机制的解释。

所以你也许会想进一步探究，确实有各种人尝试过进一步探究。牛顿最初被质疑说：这没有任何意义，它什么也没告诉我们。他回答说：它告诉你天体是怎么运动的，这就够了。我告诉了你它怎么运动，而不是为什么。但人们往往不满足于没有机制的解释。

粒子轰击模型的尝试与失败

我想描述一种理论，它是人们发明的众多解释之一，也许你自己也想过。每隔一段时间，就会有某个学生兴冲冲地跑进来，突然解释了引力。他说：假设世界上到处都有大量粒子以极高的速度飞过我们，它们从各个方向均匀地射来，不断地穿过我们，偶尔会撞击我们，对我们进行轰击。但我们和太阳对它们来说几乎是透明的——几乎透明，但总有一些会撞上来，所以并不是完全透明的。

看看会发生什么。如果太阳在这里，地球在那里，那么如果太阳不存在，粒子就会从四面八方轰击地球，给予微小的冲量——那些少数撞上的粒子噼里啪啦地撞击——但不会使地球朝任何特定方向移动，因为从一边来的和从另一边来的、从上面来的和从下面来的，数量一样多。然而，当太阳在这里的时候，从这个方向来的粒子有一部分被太阳吸收了，因为有些粒子撞上了太阳，穿不过去。因此，从这个方向朝地球来的粒子数量，比从另一边来的要少，因为那边没有太阳阻挡。经过一番思考，你很容易看出：太阳越远，在所有粒子可能来的方向中，被挡住的粒子所占的比例就越小——也就是说，太阳的视尺寸越小，实际上与距离的平方成反比。因此，地球会受到一个朝向太阳的冲量，这个冲量与距离的平方成反比，而且是大量非常简单的操作的结果——只是一个接一个地从各个方向撞击。这样一来，数学关系的奇怪性就会大大减弱，因为基本操作比计算距离平方的倒数要简单得多。这台"机器"做了计算——这些粒子只是在那里弹跳。

唯一的麻烦是，它行不通。由于其他原因，它行不通。你编造的每一个理论都必须对照所有可能的后果来分析，看看它是否还预测了别的什么。这个理论确实预测了别的东西：如果地球在朝这个方向运动，那么从前面撞击它的粒子就会比从后面撞击它的多。就像你在雨中奔跑，雨从前面打在你脸上的比打在后脑勺的多，因为你是在迎着雨跑。所以当地球朝这个方向运动时，它是在迎着粒子跑，而逃离从后面追上来的粒子，因此从前面撞击它的粒子比从后面的多。而且只要有任何运动，就会有一个横向的力。这个横向力会使地球在轨道上减速，地球肯定不可能持续围绕太阳运转至少三四十亿年。所以，这个理论到此为止了。

你会说："这倒是个好理论，它暂时摆脱了数学。也许我能发明一个更好的。"也许你能，因为没有人知道最终答案。但直到今天，从牛顿时代起，没有人发明出另一种关于这个定律背后的数学机制的理论描述，它要么只是在用不同的方式说同样的事情，要么让数学变得更复杂，同时还不会预测出错误的现象。我的意思是，有些理论确实做到了，但就像这个模型一样，它预测了不真实的东西。所以，到今天为止，除了数学形式之外，没有引力理论的其他模型。

数学在物理定律中不可避免

如果只有这一个定律具有这种特征，那会很有趣，也有点恼人。但事实是，我们研究得越多，发现的定律越多，对自然挖掘得越深，这种"病"就越严重——我们的每一个定律都是一个纯粹的数学陈述，而且是用相当复杂和深奥的数学来表达的。牛顿引力定律是相对简单的数学，随着我们深入，数学变得越来越深奥、越来越困难。为什么会这样，我一点头绪都没有。我在这个讲座中的目的只是告诉你们这个事实。换句话说，我这个讲座的目的实际上是解释为什么我无法让你们满意——如果你们不太懂数学的话，我没办法用任何其他方式来解释自然。这个讲座的重担就在于此：告诉你们一个事实，即不可能真正诚实地迎接这个挑战——用一种让人能感受到自然定律之美的方式来解释，而听众却没有对数学的深刻理解。很遗憾，情况似乎就是如此。

数学不仅仅是语言

你也许会说："好吧，那就不解释定律了，至少告诉我定律是什么。为什么不用文字而用符号来告诉我？数学只是一种语言，我想翻译这种语言。"事实上，我可以翻译，而且凭借耐心，我想我部分地做到了。我可以再进一步，解释更多细节，比如"如果距离是两倍远，力就是四分之一"等等，可以把所有这些都转换成文字。换句话说，我会对外行很友好，他们满怀希望地坐在那里，期待你能解释些什么。不同的人因为向外行解释这些深奥主题的技巧不同而获得不同的声誉。外行然后一本又一本地寻找书，希望避开即使最好的阐述者最终也无法避免的复杂性。他读着读着，发现越来越混乱，一个复杂的陈述接着另一个，一个难以理解的东西接着另一个，所有这些东西显然彼此之间毫无关联，变得越来越晦涩。他希望也许在另一本书里会有某种解释。"那个人几乎快说清楚了，也许另一个人能说清楚。"我不认为这是可能的，因为还有另一个特征：数学不仅仅是一种语言。数学是语言加上推理，就像语言加上逻辑。数学是一种推理工具，它实际上是一大堆某个人仔细思考和推理的结果。通过数学，可以把一个陈述与另一个陈述联系起来。

例如，我可以说力是朝向太阳的。我也可以告诉你，正如我之前所说的，行星的运动方式是：如果我画一条从太阳到行星的线，然后在某个固定的时间间隔后——比如三周后——再画一条，行星扫过的面积与下一个三周扫过的面积完全相同，再下一个三周也一样，如此循环。现在，我可以仔细地向你解释这两个陈述，但我无法解释为什么它们是同一回事。所以，如果你不欣赏数学，你就无法看到：自然中大量看似极其复杂的事实，以及所有那些奇怪的定律和规则——每一个都已经仔细地向你解释过了——实际上是紧密交织在一起的，逻辑允许你从一个推出另一个。

等面积定律的几何证明

也许难以置信，我能证明如果力朝向太阳，那么相等的时间就会扫出相等的面积。如果我可以的话，让我来展示一个证明，让你们看到这两件事确实是等价的，这样你们就能体会到，仅仅陈述两个定律是不够的——两个定律是相互关联的，仅凭推理就能从一个推出另一个。数学是有组织的推理，知道如何做这件事是好的，这样才能欣赏陈述之间关系的美。

好，我来证明：如果力朝向太阳，那么相等的面积在相等的时间内被扫出。我们开始。这是太阳，我们想象在某个时刻，比如行星在这里，它以某种方式运动，比方说一秒后——或者一个小时，随便选什么时间——比方说一秒后，它移动到了位置二。如果太阳不对它施加任何力，那么根据伽利略的原理，它会继续沿直线运动。所以在下一个相同的时间间隔内，下一个一秒，它将移动完全相同的距离，沿同一条直线，到达位置三——如果没有力的话。

好了，首先我们要证明，如果没有力，相等的面积在相等的时间内被扫出。我提醒你们，三角形的面积是底乘以高的一半，高是到底边的垂直距离。如果三角形是歪的——有个名字，我忘了——钝角三角形——那么高就是这个垂直高度。

现在让我们画到这两个点的连线。在没有力的情况下，问题是：这两个面积相等吗？考虑由太阳和点一、点二构成的三角形，就是这个。它的面积是这个底边乘以这个高。那么另一个三角形呢？就是从二到三的运动三角形，是这个底边乘以同一个高。两个三角形有相同的高，而且正如我所指出的，有相同的底边，因此有相同的面积。到目前为止很好：如果太阳没有施加力，相等的面积在相等的时间内被扫出。

但太阳确实施加了力。在从一到二到三的这个间隔中，太阳在拉扯，改变运动方向——这个方向、那个方向。为了对此做一个好的近似，我们取中间位置或平均位置，说在整个间隔中，全部效果是使运动在朝向太阳的方向上改变了某个量。这意味着，虽然粒子本来在朝这个方向运动，本来会在下一秒朝这个方向运动，但由于太阳的影响，运动被改变了一个量，这个改变朝着这个方向——平行于从位置二到太阳的连线。这些线是平行的。新的运动是我本来要做的运动和太阳作用引起的变化的合成。所以它实际上并没有到达位置三，而是到了位置四。

现在我们要比较三角形二 - 四-太阳和二 - 三-太阳。我要证明它们是相等的，因为它们有相同的底边。这两个三角形——没有力的那个和有力的那个——有相同的底边。它们有相同的高吗？当然有，因为它们被包含在平行线之间。所以它们有相同的高，因此我最后画的那个三角形的面积和我画的第二个三角形——二、三、太阳——的面积相同，而我之前已经证明了那个面积等于第一个。所以在行星的实际轨道运动中，第一秒和第二秒扫过的面积是相等的。通过推理，我们可以看到力朝向太阳这个事实与面积相等之间的联系。

不巧妙吗？不，这是我从牛顿那里借来的，直接出自《自然哲学的数学原理》，图都是一样的，只是字母不同，因为他用拉丁文写，这些是阿拉伯数字。

从几何推理到解析方法

顺便说一下，牛顿把他的证明做成像这样的几何形式，他书中的所有证明都是这种几何类型的。今天我们不再使用那种推理方式了，我们使用一种带有符号的解析推理。这种几何推理需要一种灵巧性——要画出正确的三角形，注意到面积，想出怎么做，你必须聪明。但分析方法已经有了改进，所以你可以更"笨"一些，写得快得多，效率高得多。我只想展示一下用更现代的数学符号写出来是什么样子，你只需要写很多符号就行了。

首先，我们想讨论面积变化的速度，我们用 dA/dt 来表示。面积变化是因为——当半径在扫动时——是速度在垂直于半径方向上的分量乘以半径，告诉我们面积变化的速度。这就是径向距离乘以速度（即距离的变化率）的垂直分量。现在的问题是，面积变化率本身是否变化。原则上它不应该变化，面积的变化率不应该变化。所以我们对它再求一次导数。那些点不是关于把点放在正确位置的小技巧——那只是你必须学的一些规则，是人们发现的一系列非常强大的规则。这个表达式说的是：速度在垂直于速度方向上的分量——没有这样的分量，因为速度在自身方向上——而加速度，即速度的导数，等于力除以质量。所以这个表达式说的是：面积变化率的变化率等于力在垂直于半径方向上的分量。但如果力在半径方向上——正如牛顿所说——那么垂直于半径方向就没有力，这意味着面积变化率不变化。

我只是想展示不同符号系统的区别。牛顿或多或少知道怎么做这些，用的是稍微不同的符号，但他把所有东西都写成几何形式，因为他试图让人们能读他的论文。他发明了微积分，也就是这种数学，这是数学与物理关系的一个很好的例证。当物理学中的问题变得困难时，我们常常可以求助于数学家，他们已经研究了这样的问题，已经对这样的项目进行了推理，为我们准备好了一条推理的路线可以遵循。另一方面，他们也许没有准备好，那样我们就必须发明自己的推理路线，然后它会传回数学家那里。因为任何对任何事物进行仔细推理的人，都是在为"当你思考某件事时会发生什么"的知识做出贡献。如果你把它抽象出来，送到数学系，他们会把它放进书里，作为一个数学分支。

数学作为连接各种陈述的工具

数学是从一组陈述走向另一组陈述的方式。它在物理学中显然是有用的，因为我们有所有这些不同的谈论事物的方式，它允许我们推导结果、分析情况、以不同方式重新表述定律，并把各种陈述联系起来。事实上，一个物理学家所知道的总量其实很少，他只需要记住从一个地方到另一个地方的规则，他就能做到。换句话说，关于等面积、力在半径方向等等的各种陈述，都通过推理相互联系着。

巴比伦传统与希腊传统

现在出现了一个有趣的问题：是否有某种模式？是否有一个起点——基本原理——可以推导出整个体系？或者说，自然中是否有某种特定的模式或秩序，使我们能理解哪些是更基本的陈述，哪些是更派生的陈述？

有两种看待数学的方式，为了这个讲座的目的，我称之为"巴比伦传统"和"希腊传统"。在巴比伦的学校里，学生学习数学的方式是做大量的例子，直到他领悟了一般规则。大量的几何知识也被掌握了——圆的很多性质、毕达哥拉斯定理、立方体和三角形的面积公式等等——也有一些推理可以从一个东西到另一个东西。数值量的表格也是可用的，所以你可以解复杂的方程。一切都为计算准备好了。但欧几里得发现了一种方法，可以把所有几何定理从一组特别简单的公理中排列出来，你们肯定都熟悉那种几何。

巴比伦的态度是——我所说的"巴比伦数学"的方式是——你知道所有这些不同的定理以及它们之间的许多联系，但你从未真正意识到它们都可以从一堆公理中推导出来。现代数学——最现代的数学——集中于公理和在非常明确的框架内的证明，有关于什么可以接受为公理、什么不可以接受的惯例。例如，在几何中，取欧几里得公理的某种修正版本使之更完善，然后展示系统的推导。例如，毕达哥拉斯定理——三角形各边上的正方形面积之和等于斜边上的正方形面积——不应该是一条公理。另一方面，从笛卡尔的几何观点来看，毕达哥拉斯定理就是一条公理。所以我们要担心的第一件事是：即使在数学中，你也可以从不同的地方开始，因为所有这些不同的定理都通过推理相互联系着。

没有真正的方法说"这些在最底下是基础，这些通过逻辑连接在上面"，因为如果你被告知的是这一个而不是那一个，你也可以把逻辑反过来推。这就像一座有很多构件的桥，它是过度连接的——如果有几块掉出来了，你可以用另一种方式重新连接。今天的数学传统是从某些特定的公理开始，这些公理由某种惯例选定，然后从那里构建起整个结构。巴比伦的方式——我说的并不真的是巴比伦的——是说：我碰巧知道这个，碰巧知道那个，也许还知道那个，我从那里开始推导出一切。明天我忘了这个是对的，但我记得那个是对的，然后我重新构建。我从来不确定该从哪里开始、在哪里结束。我只是始终记住足够多的东西，这样当记忆消退、碎片掉落时，我就把东西重新拼凑起来。每一天都是如此。

从公理出发的方法在获取定理方面并不是高效的。在几何中解决问题时，如果你每次都要回到公理，效率就不高。但如果你记得几何中的几样东西，你总是可以到达别的地方，用另一种方式效率要高得多。最好的公理与最有效的周游方式从来不完全相同，事实上从来都不相同。

在物理学中，我们需要巴比伦方法，而不是欧几里得或希腊方法。让我说说为什么。欧几里得方法的问题是要使公理变得更有趣或更重要。但我们的问题是：在引力的情况下，说力朝向太阳是更好的公理，还是说相等的面积在相等的时间内被扫出是更好的公理？从一个角度看，力更好，因为如果我陈述力是什么，我就可以处理一个有许多粒子的系统，其中轨道不再是椭圆——因为粒子之间的相互拉扯——等面积定理就失效了。因此我倾向于把力定律作为公理而不是另一个。

角动量守恒

另一方面，等面积原理可以被推广。当有大量粒子的系统时，它变成另一个定理。我本来准备解释的，但我看到时间快不够了。不过有一个陈述比等面积等时间更一般一些。让我说说它是什么。说起来相当复杂，也不像等面积那么漂亮，但它显然是等面积原理的"后代"。

如果你看着所有这些粒子——木星、土星、太阳和所有这些东西——围绕许多恒星运转或者不管它们是什么，全部相互作用的。从远处看，投影在一个平面上，就像这张图片一样。然后一切都在运动，这个朝这个方向动，那个朝那个方向动，等等。然后取任何一个点——比方说这个点——然后计算每一个粒子扫出多少面积，到每个粒子的半径扫出多少面积，然后把它们全部加起来。但是等等——那些质量更重的粒子贡献更大。如果这个的质量是那个的两倍，那么这个面积就算两倍多。

这就是在"扫动"，所有这些的总和在时间中不变化。这就是另一个定律的显然推广。顺便说一下，这个总和叫做角动量，这叫做角动量守恒定律。"守恒"只是意味着它不变化。

这个定律的一个结果——只是为了展示它有什么用——想象许多恒星落在一起形成一个星云、一个星系。当它们靠近时，如果它们原来在很远的地方，运动很慢，所以只有很少的面积在很长的臂上被产生——到中心的距离很长。然后如果这些东西落进来，到中心的距离变短了。如果所有恒星现在都靠近了，这些半径变小了，为了扫出相同的面积，它们必须运动得更快。所以当这些东西落进来时，它们会旋转起来，这样我们就能大致理解旋涡星云的定性形状。也可以用完全相同的方式理解滑冰运动员的旋转——当你开始时腿伸出去，转得慢，当你把腿收进来，转得更快。因为当腿伸出去时，它在缓慢运动中每秒贡献一定面积，然后当它收进来时，为了获得相同的面积，你必须转得更快。但我没有为滑冰运动员证明这一点——滑冰运动员用的是肌肉力量，引力是不同的力——但这对滑冰运动员也是对的。

定律超越其推导

我们现在有一个问题：我们常常可以从物理学的一部分——比如万有引力定律——推导出一个原理，而这个原理被证明比推导本身要广泛得多。这在数学中不会发生——定理不会出现在它们不该出现的地方。换句话说，如果我们说物理学的公设是万有引力定律，我们可以推导出角动量守恒，但只限于引力。然而我们通过实验发现，角动量守恒是一个范围大得多的事情。牛顿有其他公设，从中可以得到更一般的角动量守恒定律，但牛顿定律是错的——没有力，那都是一堆胡说，粒子没有轨道，等等。然而，这个关于面积的原理的精确推广——角动量守恒——在量子力学中的原子运动中是对的，据我们今天所知，它仍然是精确的。

所以我们拥有这些宽泛的原理，它们横扫所有不同的定律。如果一个人太认真地对待他的推导，觉得这个原理只在那个定律有效时才有效，他就无法理解物理学不同分支之间的相互联系。也许有一天，当物理学完备了，也许通过这种论证，我们知道了所有的定律，然后我们可以从某些公理开始——毫无疑问，会有人想出一种特定的方式来做这件事，然后所有的推导都会被完成。但在我们还不知道所有定律的时候，我们可以用一些定律来猜测超越证明范围的定理。

所以，为了理解物理学，一个人必须始终在头脑中保持所有各种命题及其相互关系的精妙平衡，因为定律常常超越其推导的范围。只有当所有定律都被知道之后，这才不再重要。

引力定律的三种等价表述

数学与物理之间另一个有趣的事情是——一件非常奇怪的事情——通过数学论证，你可以证明你可以从许多不同的看似不同的起点出发，得到同样的结果。如果你有公理，这很清楚，你可以用一些定理。但实际上，物理定律是如此精妙地构造的，它们的陈述具有如此定性上不同的特征，这非常有趣。

如果你们允许的话，我要用三种不同的方式来陈述万有引力定律，它们结果是完全等价的，但听起来完全不同。

第一种是物体之间的力，如前所述。每个物体感受到作用在它上面的力，然后加速或改变运动，以每秒某个量变化。这就是我所说的通常方式，我称之为牛顿定律。这是一种描述方式。

这种定律有一个完全不同的特点：力依赖于有限距离之外的某个东西。它有一种我们称为"非定域"的性质——这个物体上的力取决于那边那个物体在哪里。你也许不喜欢超距作用的想法，但它就是能知道那边发生了什么。

然后还有另一种陈述定律的方式，非常奇怪，叫做"场"的表述方式。这很难解释，但我只想给你们一个粗略的概念。它说的是一件完全不同的事情：空间中每一点都有一个数。我知道它是一个数，不是一个机制——这就是整个物理学的麻烦，它必须是数学的。空间中每一点都有一个数，这里一个数，那里一个数，以此类推。当你从一个地方走到另一个地方时，这个数会变化。如果一个物体被放在空间中的某一点，作用在它上面的力指向那个数——它的名字叫"势"——变化最快的方向，力的大小与势在你移动时的变化率成正比。这是第一个陈述。但这还不够，因为我必须告诉你如何确定势如何变化。我可以说势随每个物体的距离的倒数变化，但那又回到了超距作用的想法。然而你可以用另一种方式陈述这个定律：你不需要知道任何小区域之外发生的事情。如果你想知道这里某一点的势是什么，你告诉我以那个点为球心的任何球面——不管多小——上的势是什么就行了。你不需要看外面，你只需要告诉我邻域内发生了什么，以及球内有多少质量。规则是这样的：球心处的势等于小球面上的势的平均值，减去那个常数除以球的半径的两倍。假设球的半径叫做 a，然后乘以球内的质量——如果球足够小的话。

现在你看，这个定律和另一个不同，因为它只告诉你一个点发生的事情与非常近处发生的事情的关系。牛顿定律告诉你某一时刻发生的事情取决于更远处的事情——它从一个瞬间到下一个瞬间给出如何计算，但在空间中它从一个地方跳到另一个地方。但这个东西在时间上是定域的，在空间上也是定域的，因为它只取决于邻域。这是另一种表述方式。

现在还有另一种完全不同的方式。你看到这些不同表述中哲学和定性思想的差异。你不喜欢超距作用？你可以不用它。现在我要给你们看一种哲学上完全相反的方式，其中完全不讨论事物如何从一个地方传到另一个地方，整个事情是一个总体性的陈述。

当你周围有其他粒子，你想知道这个粒子如何从一个地方运动到另一个地方时，你这样做：你计算一个量。你发明一个可能的运动，从给定的一个地方到另一个你感兴趣的地方，在给定的时间内——比如它想在一小时内从这里到那里，你想知道它走什么路线能在一小时内到达。所以你计算一个量，猜测一条曲线。如果你尝试这条曲线，你计算某个数；如果你尝试另一条路线，你当然会得到不同的数。但有一条路线给出那个量的最小可能值，那就是粒子实际走的路线。

现在我们在用关于整条曲线的某种陈述来描述实际运动——椭圆。我们失去了因果性的概念：粒子在这里，它感受到拉力，它移动到这里。取而代之的是，它以某种宏伟的方式"嗅"遍了所有可能的曲线，所有可能的路线，然后决定走哪一条。

等价表述的深远意义

这是一个例子，说明描述自然的美丽方式有如此广泛的范围。当人们说自然必须有因果性——好吧，你可以用那种方式谈论。自然必须用最小原理来表述——好吧，你也可以用这种方式谈论。自然必须有定域场——你也可以那样做。问题是：哪一个是正确的？

如果这些不同的选择在数学上不完全等价，如果某些选择会有不同于其他的后果，那就很好，因为我们只需要做实验来找出自然实际上选择了哪种方式。大多数人是带着哲学观点来的，他们喜欢这个不喜欢那个。但我们从大量经验中学到，所有关于自然将如何运作的哲学直觉都是失败的。从来就不管用。一个人只需要把所有可能性都算出来，尝试所有选择。

在我谈的这个特定情况下，这些理论是完全等价的。三种表述——牛顿定律、定域场方法和最小作用量原理——的数学后果在每一种情况下都完全相同。那我们怎么办？你在所有书中都会读到：因此我们无法在科学上决定哪个是对的。这是对的——它们在科学上是等价的，不可能做出决定，因为没有实验或方法可以区分它们，如果所有后果都相同的话。

但在心理上，它们非常不同，有两个原因。第一，在哲学上，你喜欢或不喜欢它们，训练是唯一能克服这种"病"的方法。第二，在心理上它们不同，因为当你去猜测新定律时，它们完全不等价。只要物理学是不完备的，我们还在试图发现和理解其他定律，那么不同的可能表述就会提供线索，暗示在其他情况下可能会发生什么。它们在我们心理上变得不等价，因为它们暗示我们对更广泛情况下定律可能是什么样子的猜测。

爱因斯坦的启示

例如，爱因斯坦注意到——他说他意识到信号不能以超过光速的速度传播。对于电，他猜测这是一个普遍原理——同样的猜测游戏，就像把角动量从你证明它的那个情形推广到整个宇宙一样。他猜测它对所有东西都是对的，他猜测它对引力也是对的。如果信号不能比光速更快，那么瞬时描述力的方法就变得非常糟糕。在爱因斯坦对引力的推广中，这种描述物理学的方法是无望地不充分的，极其复杂的，而定域场方法和最小原理方法则是简洁而优美的。所以我们还没有在那两者之间做出决定。

事实上，量子力学说，就我陈述它们的方式而言，两者都不完全正确，但最小原理的存在被证明是一个后果——在微观尺度上粒子遵循量子力学。事实是，目前理解的最佳定律实际上是两者的结合，我们使用最小原理加上定域的力、定域的定律。今天的信念是，物理定律必须具有定域特征，同时也具有最小原理。但我们并不真正知道。

为什么我们必须保留所有表述

所以情况是这样的：如果你有一个只是部分精确的结构，某些东西将会失败。如果你用恰好正确的公理来写它，也许只有一个公理失败，其余的保留，你只需要改变一小点。但如果你用另一组公理来写，它们全部崩溃，因为它们都依赖于那个失败的东西。但我们无法事先判断哪种写法最好，除非凭借某种直觉和猜测，直到我们发现新的情况。所以我们必须始终把所有看问题的替代方式保存在头脑中。物理学家做的是巴比伦数学，很少注意从固定公理出发的精确推理。

自然的一个惊人特征就是这种解释方案的多样性。事实证明，这之所以可能，只是因为定律是如此的独特和精妙。例如，定律是平方反比这一点，使得它可以变成定域的——如果是立方反比就做不到。方程的另一端——力与速度的变化率相关——这个结果允许最小原理这种写法。因为如果力与位置的变化率而不是速度的变化率成正比，你就不能那样写。如果你试图哪怕稍微修改定律，你就发现只能用少得多的方式来写它们。我总是觉得这很神秘，我不理解为什么物理定律似乎总是可以用如此多的方式来表达。它们似乎能同时穿过好几个"门"。

数学家与物理学家的不同

现在我想对数学与物理的关系做一些更一般的评论。第一点是，数学家只处理推理的结构，他们并不真正关心他们在谈论什么。他们甚至不需要知道自己在说什么，或者用他们自己的话说，他们也不需要知道他们说的是否正确。让我解释一下：如果你陈述公理，你说"某个如此如此的东西和某个如此如此的东西"，那么逻辑就可以在不理解这些词的含义的情况下进行。如果公理的陈述是真实的——我的意思是仔细表述的、足够完整的——那么做推理的人不需要对这些词的含义有任何知识，你就能用同样的语言推导出新的结论。如果我在一条公理中用了"三角形"这个词，结论中就会有关于三角形的某些陈述，而做推理的人可能根本不知道三角形是什么。但然后我可以把他的东西读回来，说："哦，三角形，就是那个有三条边的东西。"然后我就知道了这个新的事实。换句话说，数学家准备了抽象的推理，只要你有关于真实世界的公理，就可以使用。

但物理学家赋予所有短语以意义。这是一件非常重要的事情，很多从数学转来学物理的人并不欣赏这一点：物理学不是数学，数学也不是物理学。一个帮助另一个，但你必须理解这些词与真实世界的联系。在最后，你必须把你算出来的东西翻译成英语、翻译成世界、翻译成你将要用来做实验的铜块和玻璃，以发现后果是否真实。这是一个问题，而这个问题根本不是数学的问题。

物理学家的特殊需求

我已经提到了另一个关系——当然很明显，数学推理的发展对物理学家有巨大的力量和用处。另一方面，物理学家的推理有时对数学家也有用。数学家也喜欢让他们的推理尽可能一般化。如果你说"我有一个三维空间，普通空间，我想谈论普通空间"——你知道你在里面，你测量距离，需要三个数来告诉你某样东西在哪里：宽、长、高，三维空间——你开始问他们定理，然后他们说："听着，如果你有一个 n 维空间，那么这些定理是这样的。"好吧，但我只想要三维的情况。"那就代入 n 等于三。"然后你会发现，很多复杂的定理在特殊情况下要简单得多。

物理学家总是对特殊情况感兴趣，他从来不对一般情况感兴趣。他在谈论某个具体的东西，他不是在抽象地谈论任何一般的东西。他知道他在谈论什么。他想讨论引力定律，他不要任意力的情况，他要引力定律。所以需要一定量的简化，因为数学家为广泛范围的问题准备了这些东西，这非常有用。后来总是那个可怜的物理学家回来说："对不起，你本来要告诉我四维空间的事情的时候……"

物理直觉与数学严格性

另一个有趣的事情是：当你知道你在谈论什么——这些是力，这些是质量，这是惯性，等等——你可以使用大量的常识，一种坐在裤子上的对世界的感觉。你见过各种各样的事情，你或多或少知道现象会怎样表现。而可怜的数学家把它翻译成方程，那些符号对他来说没有任何意义，他唯一的指南就是精确的数学严格性和论证中的仔细。而物理学家或多或少知道答案大概会怎样，可以猜出一半，然后相当快地继续推进。数学的严格精确性在物理学中并不是非常有用，现代数学中关注公理的态度也不是。数学家可以做他们想做的事。一个人不应该批评他们，因为他们不是物理学的奴隶。不必仅仅因为这对你们有用，他们就必须那样做。他们可以做他们想做的事，那是他们自己的工作。如果你想要别的东西，那你自己去算。

猜测新定律

下一个问题是：当我们试图获得新定律时，我们是否应该使用直觉的"坐在裤子上的感觉"和哲学原则？我不喜欢最小原理，或者我喜欢最小原理；我不喜欢超距作用，或者我喜欢超距作用。问题是模型在多大程度上有帮助。这是一件非常有趣的事情：模型常常有帮助，大多数物理教师试图教学生如何使用这些模型，获得对事物如何运作的良好物理感觉。但最伟大的发现总是证明，抽象远离模型才是对的。模型从来没有任何好处。麦克斯韦对电动力学的发现最初是用大量想象中的轮子和惰轮以及空间中的一切其他东西做出来的。如果你去掉了空间中所有的惰轮和其他一切，那个东西就好了。狄拉克发现了量子力学的正确定律——对于相对论量子力学——只是通过猜方程。猜方程的方法似乎是猜测新定律的一种相当有效的方式。这再次表明数学是表达自然的深刻方式，而试图用哲学原则或"坐在裤子上的机械感觉"来表达自然，并不是一种有效的方式。

我必须说，这是可能的，而且我知道我经常做出这样的假设：物理学最终将不需要数学陈述，机制最终会被揭示——就像其他偏见一样，只是一种偏见。总是让我困扰的是，尽管有所有这些定域性的讨论，在无论多么小的空间区域和无论多么小的时间区域内，根据我们今天理解的定律，发生的事情需要一台计算机进行无穷多步逻辑运算才能弄清楚。那么，在那个微小的空间里，所有那些怎么可能在发生？为什么需要无穷多的逻辑才能弄清楚一个微小的时空点会做什么？所以我经常做出这样的假设：定律最终会像跳棋一样简单，所有的复杂性都来自规模。但这与其他人做出的其他猜测具有相同的性质——我喜欢它，你不喜欢它。对这件事不要太有偏见是好的。

总结：大自然的数学语言

总结一下，我会引用金斯的话，他说："伟大的建筑师似乎是一位数学家。"对于不懂数学的人来说，要真正传达自然最深层的美，确实非常困难。C.P.斯诺谈到了两种文化。我真的认为那两种文化是：拥有这种体验的人和从未拥有这种体验的人——理解数学到足以欣赏自然之美的人，和没有达到这个程度的人。

很遗憾，它必须是数学的，而且对某些人来说数学是困难的。据说——我不知道是不是真的——当一位国王试图跟欧几里得学几何学时，他抱怨说太难了，欧几里得说："几何学没有皇家大道。"没有皇家大道。这不是我们的错。我们作为物理学家，不能把这个东西转换成任何其他语言。如果你想讨论自然，想了解自然，想欣赏自然，就必须学会她所说的语言。她只以一种形式提供她的信息。我们不会如此不谦虚地要求她改变，然后我们才肯关注。

在我看来，所有的智识论证——无论你做出怎样的论证——都不会以任何方式，或者以非常非常少的方式，向聋人的耳朵传达音乐体验真正是什么。世界上所有的智识论证都不会说服另一种文化的人——那些哲学家试图通过定性地告诉你来教你，我试图向你们描述——这传达不了，因为这是不可能的。我们是在对聋人的耳朵说话。也许正是因为视野的局限，才使得这样的人能够想象宇宙兴趣的中心是人。谢谢你们。

科学方法：我们如何寻找新定律

现在我要讨论我们如何寻找新定律。一般来说，我们通过以下过程来寻找新定律：首先，我们猜一个。然后——别笑，这是真的——我们计算这个猜测的后果，看看如果这个我们猜的定律是对的，它会意味着什么。然后我们把计算结果与自然比较，或者说与实验或经验比较，直接与观察比较，看看它是否有效。如果它与实验不符，那就是错的。这个简单的陈述就是科学的关键。不管你的猜测有多美，不管你有多聪明，不管是谁做出的猜测，不管他叫什么名字——如果它与实验不符，那就是错的。就这么简单。

猜测是科学的

因此，做出猜测并不是不科学的，尽管许多不在科学领域的人认为是这样。例如，几年前我和一个外行讨论飞碟——因为我在科学上对飞行物了如指掌——所以我说："我不认为有飞碟。"我的对手说："飞碟不可能存在吗？你能证明它是不可能的吗？""不，我不能证明它是不可能的，只是非常不可能。"他说："如果你不能证明它是不可能的，那你就非常不科学。你怎么能说它不太可能呢？"好吧，这就是科学的方式。科学的做法是说什么更可能、什么不太可能，而不是一直在证明可能和不可能。

为了界定我的意思，我最终对他说："听着，我的意思是，根据我对周围世界的了解，我认为飞碟的报告更可能是地球上已知的非理性特征的结果，而不是来自外太空的未知的理性努力的结果。只是更可能而已。"这就是一个好的猜测，我们总是试图猜出最可能的解释，同时在脑子里保留一个想法：如果它不行，我们就必须讨论其他可能性。

超导、超感官知觉与占星术

例如，曾经有一段时间有一个叫做超导的现象——现在仍然有这个现象——就是金属在低温下没有电阻地导电。起初并不明显这是已知定律的结果，是这些粒子的结果。但事实证明，它已经被足够仔细地思考过了，事实上被确定为已知定律的结果。还有其他现象，比如超感官知觉，不能用已知的物理学知识来解释。有趣的是，那个现象并没有被很好地确立，我们不能保证它存在。如果它确实能被证明存在，那当然会证明物理学是不完备的，因此它对物理学家来说极其有趣——不管它是对是错。许多许多实验表明它不起作用。

占星术的影响也是如此。如果星星真的能影响某天是否适合去看牙医——在美国我们有那种占星术——那物理理论就是错的，因为从这些东西中可以理解的基本原理中，没有任何机制能使它成立。这就是科学家对那些想法持有一些怀疑态度的原因。

理论可以被证伪但永远不能被证实

当然，你们看到，用这种方法我们可以推翻任何确定的理论。你有一个确定的理论——一个真正的猜测，从中你可以明确地计算后果，可以与实验比较。原则上我们可以摆脱任何理论，我们总是可以证明任何确定的理论是错的。但请注意，我们永远不能证明它是对的。假设你发明了一个好的猜测，计算了后果，发现你计算的每一个后果都与实验一致。那这个理论是对的吗？不，它只是没有被证明是错的。因为在未来，可能有更广泛的实验范围，你可以计算更广泛的后果，然后你可能发现它是错的。这就是为什么像牛顿行星运动定律这样的定律能持续这么长时间。他猜出了万有引力定律，计算了太阳系的各种后果，与实验比较，过了好几百年，水星运动的微小偏差才被发现。在那么长的时间里，这个理论一直没有被证明是错的，可以暂时被认为是对的。但它永远不能被证明是对的，因为明天的实验可能会成功地证明你认为是对的东西是错的。所以我们永远不能确定我们是对的，我们只能确定我们是错的。然而，我们能持续这么久是相当了不起的。我有些想法为什么能持续这么久。

模糊理论不可证伪

我还必须向你们指出，你不能证明一个模糊的理论是错的。如果你做出的猜测表达得很差、相当模糊，你用来计算后果的方法也相当模糊——你不确定——你说"我认为一切都是因为格格巫，格格巫做这个做那个，所以我大致可以解释这是怎么运作的"——那么你就会看到那个理论是好的，因为它不能被证明是错的。如果计算后果的过程是不确定的，那么凭借一点技巧，任何实验结果都可以看起来像是预期的后果。

你们可能在其他领域也熟悉这种情况。例如，一个人恨他的母亲，原因当然是她在他小时候没有足够地抚摸他或爱他。实际上如果你去调查，你会发现她确实非常爱他，一切都很好。那么就是因为她在他小时候过度溺爱他。所以通过有一个模糊的理论，你可以得到任何一种结果。

这个问题的解决方法是：如果有可能事先准确地说明多少爱是不够的、多少爱是过度溺爱的，那么就会有一个完全合理的理论，你可以对它进行检验。通常当有人指出这一点时，他们会说："哦，你是在处理心理学的事情，那些东西不能那么精确定义。"是的，但那样你就不能声称知道任何关于它的事情。

猜测不是随机的工作

因为我是理论物理学家，我更乐于讨论问题的这一端：如何进行猜测？正如我之前说的，猜测来自哪里完全不重要，重要的是它应该与实验一致，并且应该尽可能明确。但你会说："那很简单，我们设置一台机器，一台伟大的计算机，里面有一个随机轮子，产生一系列猜测，每次它猜一个关于自然如何运作的假设，立即计算后果，与另一端的实验结果列表进行比较。换句话说，猜测是笨人的工作。"实际上恰恰相反，让我试着解释为什么。

保险箱的比喻

第一个问题是如何开始。你想开始，我要从所有已知原理开始。但所有已知原理彼此之间是不一致的，所以必须去掉一些东西。我们收到很多信，总是有人写信来坚持认为我们应该在我们的猜测中打洞。你看，你打一个洞是为了给新的猜测腾出空间。有人对你说："你们这些人总是说空间是连续的，但你怎么知道当你到达足够小的尺度时，真的有足够多的点？也许它只是一堆由小距离分隔的点。"或者他们说："你知道那些你告诉我的量子力学振幅，它们太复杂太荒谬了，你怎么知道它们是对的？也许它们不对。"我收到很多这样的信。

但我必须说，这样的评论是完全显而易见的，对于任何在这个问题上工作的人来说都是完全清楚的，指出这些没有任何好处。问题不是什么东西可能是错的，而是什么可以精确地替代它。如果你说了任何精确的东西——例如，在连续空间的情况下，假设精确的命题是空间实际上由一系列点组成，点之间的空间没有任何意义，而且这些点排列在一个立方阵列中——我们可以立即证明那是错的，那行不通。你看，问题不是去改变或说某样东西可能是错的，而是用某样东西来替代它。那并不那么容易。一旦任何真正明确的想法被替代进去，几乎立刻就会变得明显它行不通。

其次，在这些简单类型的东西上有无穷多的可能性。情况有点像这样：你坐在那里非常努力地工作，工作了很长时间试图打开一个保险箱。某个乔走过来，他不知道你在做什么，什么都不知道，只知道你在试图打开它，然后他说："嘿，你为什么不试试组合 10-20-30？"因为你很忙，你在尝试很多东西，也许你已经试过 10-20-30 了，也许你知道中间那个数已经是 32 而不是 20 了，也许你知道事实上这是一个五位数的组合。所以这些信没有任何好处。所以请不要给我寄信告诉我这个东西要怎么运作。我读它们是为了确保我还没有想到那个，但回复它们太花时间了，因为它们通常在尝试 10-20-30。

某种意义上讲人类社会就是个 Ponzi scheme，前面的人靠后面的人工作挣钱来养老

严谨地说，reward 不是距离当前 timestep 越近越高。reward 是 MDP 中当前状态下采取某动作转移到另一个状态时获得的值， $ r(s, a, s') $ ，和 timestep 无关。

只是在计算 return (expected sum of reward) 的时候，可以在 reward 前面加个折扣 $\gamma$ 。这个折扣还可以理解为：MDP 有 $1-\gamma$ 的概率转移到死亡状态，从而后面什么奖励都没有。

搞到一万亿以上的钱可能没区别了，所以可以想象一万亿以上都是一万亿封顶，则可能期望是 40 元左右

真的假的

https://cdn.prod.website-files.com/5ef3c7300432b40ed865991a/67a4f8e8160103c8a74017a7_%E5%85%A8%E7%90%83%E4%BB%B7%E5%80%BC%E6%8A%95%E8%B5%84%E4%B8%8E%E6%97%B6%E4%BB%A32024%E5%B9%B412%E6%9C%88.pdf

举个例子，在农业文明时代，财富就是土地和人口。那么，今天土地还是不是财
富？回顾整个世界历史，尤其是在欧洲，封建体系持续了数百上千年，很多国家的封建制
度都因革命而瓦解了，除了一个例外——英国。这几百年来，英国没有发生大的革命，许
多原本拥有土地的贵族至今还保留着很多土地和宏伟的城堡。在过去，他们是最富有的人。
然而，今天这些贵族还富有吗？答案是否定的。大多数仅拥有土地和城堡的贵族已经不再
富有，甚至变得相对贫穷。只有少数贵族依然富裕，是因为他们有其他投资，而不是仅仅
依赖原有的土地和城堡。
为什么会这样？因为维持土地和城堡需要大量人力。一个大型城堡动辄需要几十甚
至上百的佣人来维持运转。然而，过去几百年间，人的价值发生了巨大的变化，导致今天
的贵族已无法负担如此多的佣人。同样地，土地也需要雇人耕作，人的价值增加了，土地
本身的产出增加相对比较少，乡间房子价值的增加也很少，维修成本反而很高。所以，这
些没有转化成工业商业用途的土地城堡成了贵族们的负担，而没有成为财产。今天，仍能
维持土地和城堡的英国贵族，大多是通过将城堡开放给公众参观来获取收入。例如，将城
堡当作公园开放，收取每人五英镑的门票费用。我相信在座有很多人到英国旅游，参观过
类似的城堡，甚至还有人租用城堡举办生日宴会、公司晚会、婚礼等等。这是一个土地和
人口的相对价值变化的例子。

我们来回顾一下价值投资的起源。价值投资正
是诞生于整个经济和宏观环境极度动荡、充满困惑的时期。最早完整阐述价值投资理念的
人是本·格雷厄姆（Ben Graham），也就是巴菲特的老师。那么格雷厄姆是什么时候开始
理解和实践价值投资的？他最早从 1926 年开始投资，前三年中，他与很多投资者一样，
经历了“咆哮的二十年代”（Roaring Twenties），期间也做了很多投机操作。然而，
1929 至 1932 年的大萧条时期，他的投资合伙企业的帐面价值损失高达 70%。痛定思痛，
他才开始真正实践价值投资，并于 1932-1935 年成功弥补了之前的亏损。1936 年，他创
立了一个新的封闭式基金（closed fund），运营至 1956 年结束，二十年间实现了非凡的
回报。期间，他于 1949 年出版了《聪明的投资者》，首次完整地阐述了价值投资的最重
要的三个理念

价值投资的奠基人格雷厄姆，正是在宏观经济面临巨大挑战时发现了价值投资的方
法论。他在那个时代所经历的比我们今天面对的挑战要困难得多。当时，美国的失业率高
达 25%，整个经济体萎缩了约三分之一到一半，具体比例取决于不同的评估方法。人们普
遍感到前途渺茫，世界仿佛快走向末日。等他终于回本，开始新的基金时，世界又迅速陷
入一场法西斯发动的全球性战争，这场战争最终导致上亿人死亡，数亿人受伤，世界上大
部分的工业体系被彻底摧毁。在这样的时代背景下，他创造了卓越的投资业绩。

另一位对价值投资的理论和实践做出巨大贡献的是经济学家凯恩斯。很多人都熟悉
凯恩斯的宏观经济理论，以及他对战后布雷顿森林体系和全球金融体系设计的贡献，但是
很少有人知道凯恩斯也是一位优秀的价值投资人。从 1921 年到他 1946 年离世，凯恩斯管
理着剑桥大学最重要的国王学院的捐赠基金，25 年间积累了卓越的投资业绩。凯恩斯早
期也曾有过很多投机，但是在不断的经验教训中，他开始总结出价值投资的核心理念。凯
恩斯与格雷厄姆的事业轨迹高度重合，都经历了“咆哮的二十年代”、大萧条和世界大
战。不过，与格雷厄姆不同的是，凯恩斯所在的英国在二战期间处于战火前线，而格雷厄
姆所在的美国则处于战争的大后方，因此凯恩斯在这样的背景下创造出的业绩更具意义。

还有一位约翰·邓普顿（John Templeton），他对价值投资以及把价值投资推广到
其他国家起到了重要作用。1939 年，正值战争期间，许多美国股票跌破一美元，邓普顿
秉持“便宜就是硬道理”的原则，将当时在美国股市中所有低于一美元的股票各买 100 股，
共投入一万美元。四年后，当他卖出时，104 只股票中有 100 只都取得了大幅上涨。1954
年，他创建了邓普顿基金（Templeton Fund），开始将价值投资理念推广到很多其他国家。
1992，这只基金经过 38 年的发展，历经市场的各种变化，取得了十几倍的收益

我（李录）在 1997 年创建了喜马拉雅基金。在此之前，我在 1993 年买了第一只股票，就是
从买便宜的公司开始。在投资便宜公司的过程中，逐步建立起自己的能力圈，并从寻找便
宜的公司慢慢过渡到寻找优质且便宜的公司。1997 年，基金成立之初，我就经历了亚洲
金融危机。过去这几年中国市场经历了资本与资产的大幅回撤，许多人都遭遇了房地产、
股票和其他证券价格的下跌。然而这轮下跌的程度与当年的亚洲金融危机相比，依然不可
同日而语。1997-1998 年亚洲金融危机期间，亚洲主要国家的市场普遍下跌 70% 以上，最
惨烈的甚至跌了 90% 以上。我们的基金也同样面临了巨大的挑战，出现了比较大的波动，
但那几年的业绩总和恰恰是我们收益很高的一段时期，那时的市场可谓遍地黄金。

在不确定的世界里领导：Jamie Dimon 谈职业韧性、商业决策、风险管理、家庭与人生

职业韧性：被解雇不等于失去自我价值

在花旗被解雇，是我职业生涯中最重要的一次挫折

如果谈到职业韧性，我确实有一些亲身经历可以分享。我曾经为同一个人工作了 15 年，最后却被解雇了。这个人就是 Sandy Weill，我们一起经历了美国运通、Travelers，以及后来花旗集团的发展阶段。虽然事后回想起来，我本来不应该那么惊讶，因为在那之前，我们已经有好几年相处得不太融洽，但事情真正发生时，我仍然非常震惊。

那天，我们先开了一场管理层会议，随后 Sandy 叫我过去，John Reed 也在场。他们让我坐下来，告诉我公司准备进行一些调整。当天晚上，我就回家了。对一个长期投入同一家公司、参与了许多重大业务发展和收购的人来说，这种经历显然非常难受。但我后来逐渐想明白一件事：受到影响的是我在那家公司的职业价值，而不是我作为一个人的自我价值。 我失去了那个职位，也失去了原来在公司的角色，但我仍然是我自己。我告诉孩子们，我没有问题，我会好起来。

这并不是说被解雇不应该让人痛苦。被拒绝、失去职位或者遭遇重大失败，都会让人受伤。我认为，人完全可以允许自己难过一段时间，可以沮丧，甚至可以暂时责怪这个世界。但是，总有一个时刻，你必须重新站起来，继续往前走。

还有一件事情同样重要，那就是诚实地审视自己到底做错了什么。类似的关系破裂，通常不完全是某一方的问题。即使你认为自己受到了不公平的对待，也应该尝试理解自己的责任。你不需要把所有错误都归咎于自己，但如果完全拒绝反思，就会失去从失败中学习的机会。

失业后的一年，我没有急着寻找下一个头衔

很多人记得，我当时被解雇之后，差不多过了一年才开始下一份重要工作。实际上，那段时间并不像外界想象的那么令人焦虑。

我记得自己是在 11 月被解雇的，之后花了几个月处理离职协议和其他相关安排。期间，公司甚至收回了原来提供给我的办公室，我不得不自己重新安排办公地点。我认为那是一个不太友善的举动，不过也没有必要一直纠结。

到了第二年的 3 月或 4 月，我决定干脆享受一下那个夏天。我带着家人去欧洲进行了一次相当悠闲的旅行。直到 9 月回到纽约，办公室也安排好了，我才开始认真考虑下一步到底要做什么。

当时确实有很多人联系我，而我几乎接听了每一个电话，即使有些机会从一开始就不在我的考虑范围内。我认为认真回应别人是一种基本的尊重。

我考虑过成立一家商人银行，也有人希望与我合作开展投资业务。我接到过一家大型国际投资银行的邀请，还专门去伦敦见了管理团队，但最终判断自己不适合在那里工作。也有一些规模较小的公司向我提供职位。此外，我完全可以写一本书、到学校教学，甚至直接退休。这些都是合理的选择，其中一些事情我后来仍然希望去做。

但当时我很清楚，自己还没有准备结束职业生涯。我仍然年轻，仍然希望尝试经营一家大型企业，并证明自己有能力让它取得成功。

为什么最终选择了 Bank One，而不是亚马逊或家得宝

在寻找新机会的过程中，我还与 Jeff Bezos 见过面。当时他正在为亚马逊寻找一位总裁。我们谈过，但我没有继续推进这个机会。对那时的我来说，跨入互联网和电子商务领域，跨度可能有点太大。不过，我非常欣赏 Jeff，从那以后我们一直保持着友谊。

真正进入最后考虑范围的两个重要机会，是 Home Depot 和 Bank One。

我非常喜欢 Home Depot 的创始团队以及公司的文化，也一直很欣赏 Arthur Blank、Ken Langone 和 Bernie Marcus。前不久我还见到了 Arthur Blank，而 Bernie Marcus 已经去世了。当年我去亚特兰大与他们见面，三个人一起吃饭时，我不得不坦白一件很有意思的事情：在他们联系我之前，我竟然从来没有走进过一家 Home Depot 门店。

这当然不意味着我不能学习零售业，但从职业背景来看，我在金融行业积累了几十年的经验。我从小就在金融环境中成长，父亲和祖父都是股票经纪人，后来又在 American Express、Travelers 和花旗工作。

如果一个人一辈子都在打网球，现在突然让他去打长曲棍球，当然也可能学会，但他必须重新适应一套完全不同的规则、技能和环境。我对零售业非常尊重，但银行和金融服务是我更熟悉的领域。

Bank One 当时是一家遇到严重困难的公司，但这反而没有让我太过担心。我对它的业务不是每一个细节都了解，但大部分东西是我熟悉的。我觉得自己可以利用过去积累的经验，帮助它走出困境。

我一直有一种非常朴素的想法：不要像个孩子一样不断抱怨。接受你手里已经拥有的东西，然后尽可能把它做好。

因此，我最终选择了 Bank One，而且不是以一种随时准备离开的态度加入。我带着家人搬去了芝加哥，在那里买房子，把孩子送进当地学校，并且在刚到公司的时候，就把大约一半的个人资金投入了 Bank One 的股票。

我希望员工、投资者和董事会都知道，我的利益与这家企业真正联系在一起。此后我所做的决策，不只是一个受雇的职业经理人所做的决策，也包含了作为股东的责任感。大家知道，如果公司的未来出现问题，我本人也会承担很大一部分经济后果。

从 Bank One 到摩根大通：真正投入意味着什么

在芝加哥重新开始，并不轻松

虽然我最终非常喜欢在芝加哥工作的经历，但刚到 Bank One 时，我确实感觉相当孤立。我原来是一个典型的纽约人，很多人甚至不相信我真的会搬到芝加哥。

当时媒体经常问我是否真正承诺留在当地。我反复解释，我已经搬过来了，家人住在这里，孩子也在这里上学。有些人甚至会开车经过我在芝加哥的房子，确认我是不是真的住在那里。

我后来经常开玩笑说，如果有一天我在芝加哥去世，而家人把我的骨灰运回纽约，芝加哥的人可能还会说：“看吧，我们早就知道他没有真正打算留在芝加哥。”这个玩笑虽然有些夸张，但也反映了当时外界对我的怀疑。

刚加入公司的第一场重要会议就是董事会会议。在此之前，我只见过大概六位董事，那天才认识了其他十几位董事。Bank One 的董事人数很多。会议结束后，董事们陆续离开，人力资源主管带我去参观办公室。

他们为我准备了一间角落里的办公室，但我不想坐在那里。我希望自己的办公室就在业务活动最密集的地方，而不是远离其他管理人员。我喜欢能够随时观察团队、与员工交谈，也希望大家知道可以直接来找我。

随后，我提出想见见管理团队。大家进入会议室，我与他们握手、打招呼，手里还端着一杯咖啡。有人很认真地告诉我：“Jamie，我们不在这个房间里喝咖啡，因为这里有一块非常漂亮的白色地毯。”

我看看手中的咖啡，再看看他们，又看看咖啡，然后说：“从现在开始，可以喝了。”

这就成了我在 Bank One 做出的第一个高管决定：允许大家在铺着白色地毯的会议室喝咖啡。

这件事听上去很小，但它反映了我对管理文化的看法。企业不应该把一些形式上的规矩看得比人与人之间的交流更重要。我希望管理团队把注意力放在业务、客户、风险、执行和沟通上，而不是担心一杯咖啡会不会破坏地毯。

Bank One 的转型，以及与摩根大通的合并

后来，Bank One 的经营状况明显改善。有人把那段经历描述为我们取得了巨大成功，我的说法会稍微谨慎一些：我们确实成功扭转了公司的局面，让一家陷入困境的企业重新成为一家经营状况不错的公司，但它还远远不是一家完美的公司。

在那段时期，Bank One 的市值大约从 210 亿美元上升到了 500 亿美元。与此同时，摩根大通也经历了比较艰难的阶段，最终双方选择合并。尽管 Bank One 在交易中获得了一定溢价，但从实质上讲，这是一场双方参与程度都很高的合并。

我在交易结构和未来管理安排上拥有相当大的话语权。合并之后，董事会席位采取了双方各八人的安排，而协议规定，我将在 18 个月或 24 个月后成为 CEO，除非董事会有 75% 的成员反对。

从实际效果看，这几乎意味着我肯定会成为 CEO。因为要形成那么高比例的反对票，并不是一件容易的事情。

这次合并最终让我有机会领导摩根大通，但在我看来，最重要的并不是职位本身，而是能够在一个更大的平台上，运用我们过去积累的经营能力、风险管理经验和组织管理方法。

大型企业领导者应该如何管理公众影响力

我不会为了发表意见而发表意见

领导摩根大通这样一家规模巨大的公司，意味着我的一些公开讲话会受到媒体、投资者、监管机构和政策制定者的关注。主持人 Monica McNutt 提到，甚至特朗普总统也表示会关注我的看法。

但我不认为自己说的每一句话都具有外界想象的那种分量，也不希望不断出现在电视上，对所有事情发表意见。事实上，我自己也会认真听其他人的看法，因为我希望了解他们如何理解这个世界、正在做什么，以及他们观察到了哪些我可能忽略的变化。

公开讲话时，我会努力做到诚实而谨慎。我希望自己说的是经过思考、含义明确的话。话说得越多，未必越能把问题解释清楚，有时反而可能制造误解。

如果仔细观察我的公开活动，就会发现我通常都有一个具体的理由。我可能是在某个城市宣布新的业务扩张计划，可能是在介绍帮助当地社区的新项目，也可能是推出新的投资计划。

我并不喜欢单纯为了上 CNBC 而谈论经济。如果没有具体目的，我宁愿把时间花在经营公司和学习上。

当然，还有一个我非常重视的领域，就是美国公共政策。我认为，一些政策问题与国家长期竞争力、社会稳定以及经济增长密切相关。只要我们确实拥有相关专业知识，并且能够提供有价值的建议，我愿意更积极地参与讨论。这并不是为了增加个人曝光度，而是因为我希望为国家做一些有益的事情。

公共政策参与必须建立在专业能力之上

摩根大通不会对所有公共政策都发表意见。我们会认真讨论哪些议题真正与公司有关、哪些领域我们具有专业知识，以及我们能够发挥什么作用。

例如，我通常不会深入评论各种具体医疗政策，但像医疗服务价格透明度这样的议题，涉及市场运作、信息透明和消费者利益，我们可能有一些有价值的观点。

同样，国际贸易和地缘政治正在变得越来越重要。我们成立了亚太战略小组，因为我们知道，与亚洲尤其是中国的经济关系，将长期影响全球贸易和金融市场。

我们还设立了国防相关的行动论坛，研究美国需要建立哪些能力、供应链和资源储备，才能在潜在战争或重大安全危机中保持充分准备。除此之外，我们还组建了地缘政治战略团队，因为越来越多客户希望我们帮助他们理解不断变化的国际环境，并评估这些变化对企业经营和投资的影响。

我们会花大量时间讨论，究竟应该参与哪些议题，以及如何参与。与此同时，有些问题不是我们主动选择的，例如国会调查、传票或者其他监管程序，也会迫使公司投入资源去处理。

这种公众关注并没有从根本上改变我的日常管理方式，却确实影响了我们愿意参与的议题范围。我的原则始终是：如果我们有专业能力，而且确实能够帮助社会解决问题，就应该认真考虑发挥作用。

从 Sandy Weill 身上学到的经营与风险管理

大规模并购让我学会经营复杂企业

我在 Sandy Weill 身边工作多年，参与了大量收购和整合，这对我的管理能力影响非常深远。

我们最早从 Commercial Credit 开始，随后收购了其他消费金融公司，又收购了包含多家保险公司的 Primerica，之后加入了 Smith Barney、Travelers 的部分业务及其全部业务，还涉及 Shearson、Salomon Brothers 等不同金融机构。

从外部看，那是一台非常有名的并购机器。我们不断寻找机会，完成交易，再把不同类型的金融业务纳入同一个组织。

但如果从战略一致性的角度看，这些业务并不总是具有非常清晰的协同关系。有的公司经营保险，有的做消费金融，有的做证券经纪，有的从事投资银行业务。它们的商业模式、资产结构和风险敞口都不相同。

我当时就知道，并不是所有业务都存在完美的战略契合。然而，一家多元化的金融集团仍然可以通过把每项业务经营好，为股东创造大量价值。

这种经营方式要求管理者真正理解不同业务，而不能只关心收购价格或者交易是否完成。我们必须学习如何管理系统、员工、运营、市场营销和产品，同时理解每一家子公司实际承担了什么风险。

例如，保险业务可能涉及非常复杂的长期风险，有些风险甚至与卫星等特殊资产有关。我一直非常关注风险究竟藏在哪里，最坏的情况可能有多严重，如果问题真的出现，公司能否承受，以及需要提前做好什么准备。

我处理了大量日常经营事务，对数字、风险和运营细节都非常着迷。我希望知道公司到底发生了什么，而不是只听取一些经过包装的高层汇报。

今天我依然非常重视这些细节，但并不需要像年轻时那样亲自参与每一项工作。因为现在我已经非常了解管理团队，也相信他们具有足够能力。我没有必要重复他们已经做得很好的事情。

我很早就学会了用事实挑战权威

我第一次得到与 Sandy Weill 工作的机会，也和一件相当偶然的事情有关。

年轻时，我写过一份关于金融机构合并的分析报告，涉及 Shearson、Hammill 和 Hayden Stone 等业务背景。母亲认识 Sandy，就把我的文章拿给了他。

Sandy 看完之后非常喜欢，还送回一些意见，问我是否愿意让他使用和传阅这份材料。

我的回答非常直接：当然可以，不过你们那里有没有暑期实习工作？

这可能有些大胆，但我确实因此得到了机会。起初，我做的主要是非常基础的数据工作，例如录入预算数字，并不是什么高级岗位。

那年夏天，我有机会参加一些会议。记得有一次，有人讨论公司的大约 450 家分支机构，并表示所有分支机构都在盈利。我当场提出不同意见，说并非如此，其中有四家没有盈利，还能指出具体是哪些机构，包括位于 Portland 的一家，以及其他几家。

我当时只是一个暑期实习生，却敢于在会议上纠正这种说法。不是因为我想让别人难堪，而是因为我知道相关数字，也认为事实比职位高低更重要。

这种工作习惯一直保留到今天。无论职位多高，管理者都应该愿意了解细节；无论职位多低，员工也应该能够在掌握事实的情况下提出不同意见。

好的领导力：智商、情商、好奇心与尊重

真正的倾听，是把全部注意力交给别人

随着职业生涯的发展，我越来越意识到，领导力并不只是制定战略、阅读财务报表或者做出投资决策。

倾听非常重要。我经常告诉团队，如果我要参加一场会议，我会提前阅读材料，也就是完成所谓的 pre-read。会议开始后，我会把百分之百的注意力放在讨论上，而不是一边开会一边处理其他事情。

我会认真听别人说什么，不断提问，尝试更深入地理解他们的逻辑、假设和担忧。提问不是为了证明自己更聪明，而是为了把事情弄清楚，知道我们究竟面对什么问题，以及下一步应该怎么做。

我也非常重视尊重、关怀和好奇心。员工不愿意为自己不尊重的人工作，也不愿意为自己不信任的人工作。如果领导者根本不关心他们，员工通常能够感受到。

所谓有爱心或有人情味，并不只是对高级管理人员友善。你怎样对待清洁工、服务员、出租车司机，和怎样对待其他公司的 CEO 一样重要。一个人真正的品格，往往体现在这些日常互动中。

我还认为，好奇心是一种谦逊。一个始终保持好奇心的人，承认自己不可能知道所有事情，因此愿意不断学习。

即使我管理着一家大型银行，也不意味着我比柜员或分行经理更懂得每一项零售银行业务。很多时候，他们对某家分行的日常经营、客户真正需要什么、流程哪里存在问题，比我了解得多。

因此，我不仅应该倾听他们，还应该主动创造机会向他们学习。

认可员工，不只是说一句“干得不错”

我和 David Novak 讨论过员工认可的问题。他长期强调 recognition，也就是在组织中认真看见和肯定他人的贡献。

真正的认可，不应该只是简单说一句“你做得很好”。它还应该包含具体的内容，例如你准确指出员工究竟解决了什么问题、发现了什么别人没有看到的风险，或者通过什么努力推动了结果。

有时，认可也意味着承认自己原先的判断不够好，而其他人找到了更好的方法。

如果一个领导者能够认真理解员工的工作细节，并准确描述他们的贡献，员工就会知道自己的努力被真正看见了。

这种尊重、倾听和认可，不是企业文化的装饰，而是企业文化得以建立的基础。如果管理者不愿意理解别人，不愿意承认别人的贡献，也不愿意学习，那么再多关于企业文化的口号都没有意义。

情商和沟通能力，是管理能力的重要组成部分

年轻的时候，我可能低估了良好沟通的价值。随着管理的组织越来越大，我才真正意识到，能把复杂问题讲清楚，是一种非常重要的能力。

写作尤其如此。我很喜欢那句经典的话：“抱歉给你写了这么长一封信，因为我没有时间把它写短。”

把话写短，往往需要更多思考。你必须真正理解问题，区分重要与不重要的部分，再用清晰的语言让别人理解。这也是对阅读者时间的尊重。

Jeff Bezos 采用过六页备忘录的工作方式，我认为那是一种很好的管理实践。我们在摩根大通内部也使用很多类似的书面材料，因为它们能够迫使人们充分思考，再进行讨论。

但情商不仅是写作和表达。它还包括赢得信任、兑现承诺、愿意出现在员工身边，以及理解不同的人需要不同的沟通方式。

有些员工能够接受非常直接、强硬的反馈，甚至觉得这种方式有助于迅速解决问题。另一些员工面对同样的语言，可能会感到恐惧、羞辱或情绪受到严重影响。

领导者需要识别这些差异，并调整自己的行为。

同样一句严厉的话，对不同人的影响完全不同

我记得在 2007 年前后的金融危机时期，有一个星期六，我在家里接听工作电话，语气相当严厉。我的三个女儿都听到了电话内容。

其中两个女儿并不觉得有什么特别，她们已经习惯我在工作中有时会非常直接。但另一个女儿突然哭了起来。她问我，为什么要那么生气，是不是准备解雇电话另一端的人。

这件事让我非常深刻地意识到，同样一种行为，在不同人眼里可能代表完全不同的东西。

一个人听到严厉的批评，可能觉得这不过是正常的工作讨论；另一个人却可能觉得自己正面临极大的威胁。

领导者的责任，不是回避困难的议题，而是以适合对方的方式把困难的议题讨论清楚。

一个团队里可能有内向的人、外向的人，以及具有不同神经认知特征的人。我们希望他们都能发挥自己的能力，就必须创造一个让不同类型的人都敢于表达意见的环境。

这不意味着降低标准，而是要求领导者提高自己的沟通水平，理解人的差异，并帮助每个人在组织中贡献最大的价值。

深入基层：为什么我坚持亲自走访分行和客户

巴士巡访不是公关活动，而是一种学习方式

我一直有到各地实地走访业务的习惯。过去很多出差通过飞机完成，往往集中在纽约、洛杉矶、旧金山等主要市场。但后来我们决定采取一种不同的方法：乘坐巴士，沿着一条路线深入较少被高层访问的城市和社区。

在收购华盛顿互惠银行 WaMu 后，我们进一步扩大了西海岸业务。2012 年前后，我们组织过一条从西雅图到圣迭戈的巴士路线，希望真正了解沿途不同市场的情况。

我们没有只停留在西雅图、旧金山或洛杉矶，也去了 Sacramento 以及一些内陆小城。行程最后到达圣迭戈，还访问了当地军事基地，与受伤的退伍军人交流。

最近，我们也继续在美国南部等地区开展类似的巡访。

这种旅行最大的价值，是能够看到总部会议室里很难看到的真实情况。

我们会让分行经理、柜员以及其他基层员工上车，与管理层直接交流。我经常开玩笑告诉他们，上了巴士就能得到两样东西：啤酒和豁免权。

所谓豁免权，就是希望他们放心地告诉我们真实情况，不用担心因为批评管理层或者公司政策而受到惩罚。

巴士上会放音乐，气氛相对轻松。我们鼓励大家坦率表达意见：哪些流程不合理，哪些产品存在缺陷，哪些规定妨碍了服务客户，哪些事情是总部完全没有意识到的。

这些批评对我来说不是麻烦，而是礼物。

我们会认真记录发现的问题，整理成清单，回到总部后继续推动改进。

客户的抱怨，也是最有价值的经营信息

实地巡访不仅包括员工。我们也会与消费者、小企业客户、大企业 CEO、机构客户以及地方社区负责人见面，举办客户晚宴、员工大会和其他交流活动，有时还会参观大型呼叫中心。

客户经常会直接告诉我们，某些产品或服务不如竞争对手。有些人甚至会非常明确地指出，别的银行做得更好，而我们的流程太慢、太复杂，或者没有满足他们真正的需求。

听到这种反馈时，我希望团队的反应不是辩解，而是把问题写下来，然后想办法修复。

一家大型企业很容易形成自己的信息过滤系统。客户抱怨经过多层汇报之后，可能变成一份语气温和、问题不那么尖锐的材料。长期如此，管理层就会误以为业务运行良好。

面对面交流能够减少这种信息失真。

此外，我发现，无论到美国哪个小城，当地的人们都非常重视大型企业领导者愿意真正花时间到访。

我们会与当地媒体交流，了解社区需要，讨论慈善项目，观察就业机会，研究是否能够增加招聘或投资。这些举动能够让当地居民感受到，我们不仅仅是把他们当作一组业务数字。

对他们来说，企业领导者亲自到场、认真倾听，本身就是一种尊重。

地缘政治、美国经济与长期战略

经济冲击往往具有滞后性，不能只看眼前的数据

现在的商业环境确实变得更加复杂。关税、移民政策、财政政策和地缘政治都在发生变化，但美国经济的表现，有时候似乎没有受到大家预期的那么严重的冲击。

我认为，观察这些问题时必须有耐心，因为很多经济变化都有很长的传导周期。

例如，即使新的关税政策从今天开始实施，也不意味着所有影响会立刻反映在消费者价格和企业利润中。如果一艘货船今天装货，它可能一个月后才抵达美国港口，相关成本变化还需要进一步传递到企业供应链和最终消费者。

移民政策变化对劳动力供应和经济增长的影响，同样需要时间才能观察清楚。

对于当时正在推进的所谓“大而美法案”，我们也不能在所有细节和效果尚未明确之前，就简单断言它一定会产生什么结果。

因此，我不愿意根据几周或者几个月的经济数据，就认定某项政策已经成功或者失败。

我们需要更长的观察周期，同时研究不同政策之间可能相互强化或抵消的影响。

不过，相比这些短期经济变量，我更加关注地缘政治。

我的风险管理原则，是为所有合理情景做好准备

摩根大通必须能够应对不同类型的经济环境，包括正常增长、经济衰退、严重衰退、通货膨胀，以及增长停滞但物价仍然上涨的滞胀环境。

我不会因为某种情景的发生概率看起来不高，就完全忽视它。

即使我们认为某一种结果不太可能发生，也应该问自己：如果它真的发生，公司是否有足够的资本、流动性、运营能力和管理能力来应对？

一家具有长期竞争力的金融机构，不能只在经济形势良好时表现优秀。

我们应该能够承受好的、坏的，甚至非常糟糕的结果。

但从全球视角来看，真正重大的问题是如何维持一个安全、稳定、开放并且有利于自由社会发展的国际环境。

这也是为什么我们加大了对一些美国公共政策问题的投入。我们希望推动更好的经济增长政策、更高效的住房供给、更合理的教育体系以及更有效的基础设施建设。

如果政府长期无法解决民众关心的问题，人们对政府和公共机构的信任就可能下降。

这些问题不仅涉及经济，还涉及国家治理能力。

从住房、教育到航空管理，美国需要解决大量结构性问题

有人会觉得，一家银行的 CEO 为什么会关心美国联邦航空管理局 FAA 的运作方式。

原因很简单：这些基础设施和公共管理能力会影响整个经济的生产率、安全性和成本。

我认为 FAA 的很多工作人员非常敬业，但美国航空管理系统的一些技术和流程已经过时。现代化水平不足，可能让航班无法采用更加直接、高效的航线，也可能增加运营成本、造成安全方面的挑战，甚至带来更多二氧化碳排放。

这不是员工是否努力的问题，而是整个系统是否具备现代化能力的问题。

类似的情况也存在于美国其他领域。我们的建设许可制度需要改革，教育体系需要改善，医疗制度仍然存在大量可以提高效率的地方。

我们还需要解决住房负担能力、劳动力技能、经济增长和基础设施等问题。

我在年度董事长致股东信中也讨论过这些议题，并提出了一些具体建议。

我并不认为这些问题无法解决。恰恰相反，我认为美国仍然拥有非常强大的资源、人才、创新能力和制度基础。

面对中国，最重要的是提升美国自身的竞争力

我不一定会把中国简单称作敌人，但中国显然是一个非常强大的竞争对手，同时也是一个重要的军事力量。

中国既有自己的优势，也有弱点。我们可以花很多时间讨论这些问题，但对我来说，更重要的不是不断表达对中国的恐惧，而是把美国自己的事情做好。

美国需要提高经济增长能力，确保拥有世界上最强大的军事力量，持续推动创新，保持技术领先和长期竞争力。

只有做到这些，我们才能更有信心地维持美元的国际储备货币地位，并继续吸引全球投资。

这些目标并不是遥不可及，但如果我们不改革许可审批制度、不改善学校教育、不提升医疗体系效率，也不解决其他长期存在的结构性问题，就会逐渐削弱自己的优势。

因此，摩根大通现在比过去更加积极地参与这些与国家长期竞争力相关的议题。

为什么我们不会因为经济不确定性而停止扩张

长期投资不应该被短期周期左右

尽管外部环境存在大量不确定性，摩根大通并没有因此暂停既定扩张计划。

我们仍然希望在海外扩大业务，招聘更多银行家，在美国建设新的分行，并持续投资技术。

即使出现经济衰退，我也不会因为这一点就从根本上改变公司的长期战略。

当然，我们会根据风险状况作出一些调整。例如，某些业务可能需要适度降低销售扩张速度，或者减少特定领域的风险敞口。但整体投资方向不会轻易改变。

假设美国出现滞胀，那会是一个具有挑战性的环境，但我们也应该有能力承受。

而且，无论经济短期发生什么变化，美国仍然是一个拥有巨大财富创造能力的国家，也是全球投资者非常重要的投资目的地。

我不希望公司因为害怕下一次衰退，就放弃那些需要十年甚至更长时间才能形成竞争优势的机会。

美国银行业的未来：整合、规模优势与社区银行

为什么美国有几千家银行，而很多国家只有少数大型银行

美国银行体系非常独特。这里大约有 4000 到 5000 家银行，而其他一些国家的银行业集中度明显更高，可能主要由五到十家大型银行构成。

如果观察加拿大、澳大利亚、日本、法国和英国等市场，就会发现它们的银行体系通常比美国更加集中。德国在某些方面是一个例外，因为它保留了相当多具有地方特色的银行机构。

美国形成这种结构，有很深的历史原因。

过去很长时间，美国银行不能自由地跨州经营。直到 20 世纪后期，相关限制才逐步放松。更早的时候，有些州甚至对同一城市内的银行网点数量作出严格限制。

例如，历史上的 First Chicago 曾经只能在芝加哥拥有一家分行，所以那家分行的规模非常大。

当这些法律和监管限制逐渐变化之后，美国银行才开始更大规模地进行跨地区合并。

银行业本身具有非常显著的规模经济。技术系统、网络安全、合规管理、风险管理、支付处理以及其他基础设施，都需要大量固定投入。

从这个角度看，银行之间进行整合具有经济逻辑，因此我预计美国银行业仍然会继续发生一定程度的整合。

但是，这绝不意味着所有并购都会成功。

我亲身经历了大量银行合并，知道真正的整合非常困难。企业文化可能不兼容，财务结构可能出现问题，系统和技术平台可能难以统一，员工和客户也需要重新适应。

很多银行并购最终并没有实现原先承诺的价值。

所以，并购存在经济逻辑，不代表每一笔并购都是好交易。

小型社区银行有独特的竞争优势

我也不认为所有小银行最终都必须被大型银行收购。

实际上，美国有很多经营得非常好的社区银行。它们了解当地客户，拥有不错的资本回报，而且能够提供大型银行不一定能够复制的服务。

举一个例子：一家位于小镇的社区银行，可能没有使用 Salesforce 那样复杂的客户关系管理系统，也没有世界级的大型数据平台。

但你知道它们最好的 CRM 系统是什么吗？就是分行经理自己的大脑。

当地银行经理可能认识客户的全家，知道他们的孩子在哪里上学，知道他们经营什么生意，也了解他们遇到了什么困难。

如果你的孩子需要一张信用卡，银行经理甚至可能在下班回家的路上，顺便把卡送到你家。

他们还可能非常了解当地房地产市场，知道某条街的商业物业值多少钱，知道一份当地租约的真实价值，以及哪些小企业经营稳健。

这些知识和服务关系，很难完全通过一个集中化的软件平台替代。

所以，不能简单认为大型银行一定经营良好，而小型银行一定经营不佳。事实上，有很多小银行拥有优秀的财务表现，因为它们在自己的细分市场中真正做到了专业而高效。

摩根大通的增长主要依靠有机扩张

摩根大通已经非常大了。主持人提到，我们的规模甚至接近几家主要竞争对手的总和，因此很多人自然会问，我们是否还能继续收购美国银行。

答案是，我们目前受到美国相关限制，不能像普通银行那样继续通过收购其他美国银行来扩张。

理论上，我们可能在海外收购银行，但我也不认为那是最值得优先考虑的增长方式。

我们已经拥有足够大的业务平台，可以通过有机增长持续发展。

例如，在美国，我们能够一个州、一个州地拓展市场，一家分行、一家分行地增加覆盖，继续扩大消费者金融、信用卡和商业银行业务。

在海外，我们也拥有很多机会，包括 Chase UK 等新业务。

全球经济仍然在增长，企业的金融需求越来越复杂。越来越多美国跨国公司在秘鲁、哥伦比亚以及欧洲各地开展业务，而这些企业在进入新市场时，也需要银行提供支付、融资、现金管理、风险管理和其他服务。

我们能够陪伴这些客户在不同国家开展业务，这是一种非常重要的规模优势。

大型银行能够承担小银行无法完成的全球性任务

摩根大通在大约 100 个国家开展业务，每天处理的资金流转规模大约达到 10 万亿美元。

要实现这种能力，需要极其复杂的技术系统、支付网络、运营基础设施和网络安全体系。

我们在美国拥有大约 8700 万消费者客户。有人认为这个数字包括全球消费者，但我通常会特别说明，这主要指美国消费者。

此外，我们还服务大约 1.2 万家企业客户以及 6000 家投资机构，业务对象包括城市、州政府、学校、医院、主权财富基金和其他政府机构。

我们不仅仅为企业提供银行服务，也会协助不同国家的政府和公共机构开展融资活动。

例如，我们参与过巴基斯坦政府相关债券交易，并为政府提供信用评级、融资安排等方面的建议。

主权财富基金在全球金融体系中的资产规模也非常庞大，它们需要投资、托管、风险管理和其他专业金融服务。

小型社区银行可以非常擅长服务当地客户，但不可能单独建设支持 100 个国家业务、每天处理 10 万亿美元资金流动的系统。

两种银行具有不同的竞争优势，也满足不同类型的客户需求。

为什么我不希望竞争对手陷入危机

健康的竞争，比竞争对手被削弱更有价值

Wells Fargo 的 CEO Charles Scharf 是我非常熟悉的人。我在他 21 岁时就聘用了他，后来也一直非常关注他的职业发展。

他是一位朋友，也曾经与我共事。我对他在 Wells Fargo 取得的工作成果感到骄傲，尤其是在公司经历困难时期之后，他带领团队进行了大量修复和改善工作。

我曾经向他表示祝贺。

但这并不意味着我们之间没有竞争。摩根大通和 Wells Fargo 当然仍然是竞争对手。

问题在于，我不认为一家银行竞争对手遭遇严重困难，就一定对我们有利。

例如，当 Credit Suisse、Silicon Valley Bank 和 First Republic 出现严重问题甚至倒闭时，有些人认为，对其他大型银行来说，这是一件好事，因为它们可能因此获得客户和业务机会。

我并不同意这种看法。

银行出现大规模失败，会让公众质疑整个银行体系的稳定性。如果某家银行的治理、风险控制或经营存在问题，人们不一定只怀疑那一家机构，也可能开始怀疑其他银行。

整个行业的信任基础可能因此受到伤害。

Wells Fargo 之前也受到一些非常严格的监管限制。我认为其中部分限制并不公平。这些措施或许在某些时期让摩根大通获得了一点竞争上的便利，但长期来看，我并不觉得这对银行体系有好处。

我更希望看到的是一家健康的 Wells Fargo 与我们公平竞争，而不是一家受到严重限制、无法充分发挥能力的银行。

一个健康的银行体系，需要健康的竞争者，而不是依赖竞争对手不断失败。

两次接近死亡：癌症、心脏手术与人生观的变化

被诊断出癌症时，我第一次真正面对死亡

我曾经经历过晚期咽喉癌的治疗。主持人 Monica 也经历过晚期乳腺癌，我们都曾在 Memorial Sloan Kettering Cancer Center 接受治疗，因此对彼此的经历有一定理解。

当医生告诉你患了癌症时，那种感觉几乎像被人迎面打了一拳。

癌症在社会上并不罕见，我们都知道有很多人会患癌。但在自己被诊断之前，人们心里常常会隐隐觉得，这件事大概不会发生在自己身上。

真正面对诊断时，我的思维很快发生了变化。

最开始你可能会想：“为什么是我？”

但没过多久，你又会意识到：“为什么不能是我？我又有什么特别的理由能够完全避开这种事情？”

接下来就是漫长而令人疲惫的检查和治疗过程。

你可能需要接受活检、不同类型的影像检查和其他测试，医生也需要时间判断疾病发展到了什么程度。

在所有结果明确之前，你常常不知道情况究竟有多严重，而这种等待本身就非常难受。

对我而言，咽喉癌治疗的过程非常痛苦，绝不是一件容易承受的事情。

但最困难的部分，仍然是告诉自己的孩子。

告诉三个女儿的那一刻，比治疗本身更难忘

我不想让女儿们受到过度惊吓，所以一开始很难找到合适的表达方式。

我把她们叫到一起，想告诉她们发生了什么。起初她们还在正常聊天，彼此说个不停。

但当我开始认真讲话时，她们突然安静下来，因为她们看出我确实有一件重要的事情要说。

我先告诉她们：“在告诉你们具体发生了什么之前，我希望你们先知道，我会好起来的。”

这句话说完之后，房间里完全安静了。

然后，我才告诉她们自己患了癌症。

我一直记得那个时刻。对一个父亲来说，面对自己的疾病是一回事，而面对孩子可能产生的恐惧和不安，是另一回事。

你希望保护她们，希望让她们安心，但又必须诚实地告诉她们正在发生什么。

主动脉夹层让我再次面对生死

几年之后，我又经历了一次危及生命的心脏急症。

那次情况非常严重，我当时认为自己活着走出手术室的概率可能只有 50%。

事情发生在清晨，大约五点的时候，我突然感到胸口剧痛，就像有人把一把刀直接刺进我的胸膛一样。

那种疼痛极其强烈，我甚至觉得身体内部有什么东西被撕裂了。

我非常幸运，第一时间联系了自己的医生。他很快判断事情可能非常严重，直接告诉我带上妻子、坐出租车去指定医院，并安排心脏科医生在那里等候。

医院的医生迅速作出了正确诊断：主动脉夹层。

这种情况有时可能被误诊，而快速、准确的诊断对患者生存非常重要。

更幸运的是，当天早上，世界上非常优秀的相关外科医生之一 Leonard Girardi 恰好能够为我做手术。

那场手术持续了大约七到八个小时。

我知道自己面临极高的风险，也知道手术结果有很大的不确定性。

即使生命垂危，也必须确保公司能够正常运作

在被推进手术室之前，我首先想到的是家人。那时她们还没有全部赶到医院，因为整个事件发展得非常突然。

但我也意识到，作为摩根大通 CEO，我必须确保董事会能够及时了解我的情况。

我让妻子联系公司相关人员，并要求他们准确传达我的诊断，而不是使用一些模糊的说法。

我特别要求通知总法律顾问和首席董事，让董事会知道究竟发生了什么，以及我可能在一段时间内完全无法履行工作职责。

这不是我应该替董事会作决定的时候。我的责任是把真实情况告诉他们，让他们能够采取必要措施。

后来，董事会任命 Gordon Smith 和 Daniel Pinto 作为临时代理 CEO，确保公司在我接受治疗和恢复期间继续正常运作。

这件事反映了大型企业治理的一项基本要求：无论 CEO 多么重要，公司都不能完全依赖某一个人的身体状况或个人能力。

被推进手术室时，我没有太多人生遗憾

很多人问我，当你认为自己可能只有一半机会活着出来时，会不会突然想起大量人生遗憾。

我的真实感受是，没有那么多。

当然，我会想到家人，也会思考自己还有哪些事情没有做完。但我并没有在被推进手术室的时候，突然觉得整个一生充满遗憾。

我记得自己当时还没有完全失去意识。手术室非常大，里面可能有 20 位医护人员。

我看着那些准备为我手术的人，对他们说，无论最后发生什么，我都想先感谢大家。

后来我见到医生时，还专门问过他是否记得这件事。

我非常感激那些医生和护士。经历过重症监护病房的人，会知道护理人员有多么专业、耐心和重要。

手术之后，我曾想给照顾我的护士们送礼物，但医院有自己的规定，不允许接受某些礼品。

最后，我想办法给他们添置了一台新的冰箱，用来存放食物。因为当时正值新冠疫情开始的阶段，我还送了一台能够为手机等设备充电并进行消毒的机器。

这些事情当然无法真正回报他们挽救我生命所付出的努力，但至少是我能够表达感谢的一种方式。

重症监护病房是一种非常深刻的谦逊教育

我平时是一个非常习惯掌控工作节奏的人，习惯了解信息、作出决定、推动团队行动。

但在重症监护病房醒来之后，我发现自己身上连接着大量医疗设备和管线，很多事情都无法独立完成。

那种感觉非常令人谦卑。

你突然变得像一个需要他人全天照料的孩子，甚至一些最基本的事情都需要依赖护士帮助。

但与此同时，这种经历也让我感受到人的善意。照顾我的医护人员不仅非常专业，也充满耐心和同情心。

即使手术已经结束，医生仍然提醒我，危险期还没有完全过去，需要继续观察。

面对这样的处境，你会更加深刻地理解生命的脆弱。

每个人都知道自己有一天会死亡，但真正经历过接近死亡的人，会以一种完全不同的方式理解这件事。

我曾经读到一位澳大利亚作家 Julia Baird 关于患癌经历的文字，其中有一个观点给我留下了很深的印象：经历严重疾病之后，一个人会更加有意识地生活。

我觉得这个说法非常准确。

我的疾病没有让我突然厌恶工作，也没有让我决定完全改变职业方向。我仍然热爱自己做的事情。

但我确实更加明白，时间不是无限的，不能理所当然地假设自己会永远活着。

工作与家庭：我如何理解父亲的责任

我始终把工作和家庭作为生活中最重要的两件事

人们经常讨论职业女性如何平衡工作和育儿，但我认为，男性同样需要认真承担家庭责任。

我有三个女儿，过去多年一直努力参与她们的成长。不过，我并不想假装自己所有事情都做得很完美。很多方法也是我在实践中逐渐学习到的。

首先，如果没有我的妻子 Judith 的支持，我不可能完成这些事情。

她承担了大量家庭责任，我们一起为孩子创造了稳定的生活环境。这一点必须首先说明。

我个人的做法相对简单：我把时间主要分配给工作和家庭。

你很少看到我出现在各种需要穿晚礼服的社交活动上。我没有花很多时间打高尔夫球，也减少了看电视体育比赛的时间。

如果星期六去打网球，我通常会带着孩子们一起去，甚至在她们只有六岁的时候也是如此。

我希望工作之外的重要活动能够尽量与家人共享。

当然，我并不是没有个人兴趣。我喜欢历史、葡萄酒、烧烤和徒步旅行，也喜欢和家人一起度假。

只是这些事情中的很多，都可以成为家庭共同经历的一部分。

家庭时间不会自动出现，必须主动安排

有一次，我向女儿们讲述自己如何平衡工作和家庭，其中一个女儿提醒我，我总是漏掉一些重要的事情。

她说，我应该承认自己确实作出了牺牲。

我回答说，我并不觉得自己牺牲了什么，因为那本来就是我想要的生活。

但她指出，我确实减少了与朋友相处的时间，也放弃了一些其他活动和机会。

我后来承认，她说得有道理。

即使我主观上不认为那些选择是牺牲，它们客观上也意味着我把某些事情放在了其他事情之前。

这就是生活中的优先次序。

如果你真的希望陪伴家人，就必须像安排重要工作会议一样安排家庭活动。

把孩子的比赛、家庭聚会或者其他重要事情写进日历，认真对待，而不是假设工作结束后自然会有空闲时间。

真正优秀的员工，不应该因为照顾家庭而受到惩罚

我也希望管理者理解，员工的工作表现不应该只用他们每天坐在办公室里的时间来衡量。

如果一个员工工作非常出色，而某天下午需要去参加孩子的足球比赛，我不认为这应该构成问题。

在我看来，他去看孩子比赛，与他出去拜访客户，并不必然存在谁更值得尊重的问题。

关键在于他有没有履行自己的职责、有没有为公司创造价值。

新冠疫情是一场非常糟糕的公共卫生事件，但它至少提醒了企业一件重要的事情：很多照顾家庭成员的人，需要更大的工作安排灵活性。

这和长期在家办公不是同一个概念。

如果员工的父亲生病了、母亲需要照顾、孩子遇到健康问题，或者家庭中发生了其他必须处理的情况，企业应该给予适当支持。

只要他们仍然能够完成工作，管理者就不应该机械地计算这些事情占用了几天办公室时间。

我们也在相关制度上提供了更多灵活性。

例如，我们不只是讨论传统意义上的产假或陪产假，而是为第二照护者提供同样长达 16 周的相关假期。

我认为这种支持非常重要，因为照顾孩子和家庭，本来就不应该只是某一方的责任。

人生的价值排序：家庭、国家、摩根大通

家庭始终是我最重要的遗产

如果有人问我，摩根大通和家庭哪一个更能代表我最终留下的遗产，我的答案是家庭。

我的孩子们将拥有自己的职业道路，也可能通过她们的工作，以我无法预见的方式改变世界。

我一直把自己的价值排序概括为：家庭、国家、摩根大通。

这不意味着摩根大通不重要。恰恰相反，它是我参与社会、创造价值和帮助他人的主要方式之一。

如果我把摩根大通经营好，就能够帮助员工、客户、个人消费者、企业、社区乃至整个国家。

因此，我的社会贡献既来自家庭，也来自自己的职业工作。

但在生命结束的时候，家庭仍然是最重要的部分。

现在公司大楼里有很多来自 J. P. Morgan 的经典名言。主持人曾开玩笑说，也许未来可以把我的一些话放在墙上。我觉得那并不是最值得在意的事情。

我确实考虑过写一本书，而且已经保留了不少平时写的材料。因为我经常写作，所以未来真正开始写书时，可能已经有相当多基础内容可以使用。

不过，当我曾经提出要写书时，董事会告诉我，既然公司还在支付我的薪酬，我就应该专注于 CEO 的工作。

我认为这个要求有道理。等到适当的时候，我再把那些经验整理出来。

家庭背景如何塑造我的价值观

在一个被坚强女性包围的家庭里成长

我的妻子 Judith 是我在哈佛商学院认识的。我们有三个女儿，后来又有了孙辈。

很长一段时间，我们家里几乎到处都是女性：我的妻子、三个女儿、孙女，甚至连家里的狗都是母的。后来终于有了一个男孙。

不过，如果谈到对我影响很大的女性，就不能漏掉我的母亲和祖母。

我的母亲是一位非常坚强的人，也是一位充满关爱的母亲。她接受过弗洛伊德式心理分析理论的影响，因此特别喜欢追问人们行为背后的动机。

当别人做出某种行为时，她经常问：“他们为什么这样做？”

而年轻时的我常常回答：“我不在乎他们为什么这样做。”

但随着年龄增长，我越来越理解她关注人的心理和动机的原因。

我的祖母同样非常坚强。她们给我的影响，不只是要努力工作，还包括如何尊重他人、如何面对困难，以及怎样在必要时坚持原则。

希腊移民家庭教会了我最基本的做人准则

我有四位祖父母，其中三位是希腊移民，另一位出生在美国，具有一部分意大利血统。他们都没有接受过高中教育。

我的那位祖母非常擅长烹饪，小时候我经常吃到她做的希腊菜和意大利菜。

但比食物更重要的，是他们和我的父母共同传递的价值观。

这些价值观并不复杂，也不是什么高深的管理理论。

首先，要正确对待别人。

如果我小时候对服务员、出租车司机或者其他人态度不好，家里一定会非常严厉地教育我。

其次，要在别人受到欺负时挺身而出。

如果看到一个孩子被霸凌，他们会期待我帮助那个受欺负的人，即使这意味着自己可能承担一些风险。

第三，一个人应该有生活目标，而这个目标不必与金钱和商业成就直接相关。

我有一个哥哥是物理学家，另一个哥哥从事教育工作。我的三个女儿也走上了不同道路，有人从事新闻报道，有人进入医疗领域，也有人选择银行业。

我从不认为所有孩子都应该像我一样从事金融。

重要的是，他们能够找到有意义的事情，成为对社会有贡献的人，并努力让世界变得更好。

最后，就是无论做什么，都应该尽自己最大的努力。

不要偷懒，不要满足于表面完成任务，而要不断学习、保持好奇心，并认真对待自己承担的责任。

父母去世之后，我才真正理解家族传承

非常有意思的是，在父母去世之前，如果有人问我，作为希腊移民的孙子对我的性格究竟有什么影响，我可能不知道怎么回答。

我的父母是在同一天去世的，当时他们都在家中，而且相互陪伴。

那是一件非常令人难过的事情，但从另一个角度看，能够在彼此身边走完人生最后一段路，也是非常特别的经历。

他们去世之后，随着时间推移，我才开始更加认真地回顾家族历史，思考祖父母和父母究竟把什么东西传给了我。

我后来发现，那些从小听到的朴素原则，已经深深影响了自己对商业、领导力和人生的判断。

选拔管理者：聪明只是起点，品格和执行力更重要

我希望高管具备怎样的能力

当我选拔最重要的管理团队成员时，当然希望他们聪明、善于分析。

现代金融业务非常复杂，没有足够的智力和分析能力，很难理解其中的风险和机会。

但聪明不能只意味着能够快速完成数学计算或者解读财务报表。

我希望管理者始终能够观察外部世界，了解竞争对手、技术变化、客户需求和行业趋势。

这种能力与好奇心密切相关。

有一次，我要求消费银行业务团队派一批人去中国学习。

一些员工一开始不理解，认为这趟旅行可能是浪费时间。我告诉他们，去了之后自然会发现值得学习的东西。

他们到中国之后，看到了微信、支付宝、腾讯以及当地企业在数字支付和金融科技领域采用的不同方法，才真正理解其他市场正在发生多么有意思的创新。

这就是我希望管理者拥有的开放心态。

不要因为某种商业模式不是自己发明的，或者某种技术出现在不同国家，就认为它没有学习价值。

有判断力，还必须有作出决定的勇气

在专业能力和好奇心之外，我非常重视品格、企业文化、关怀他人的能力以及执行力。

我会把诚实、勤奋、尊重他人等因素视为基本条件，而不是可有可无的附加项。

然后，我还会特别观察一个人有没有韧性和决断力。

一个人可能非常善良，也非常聪明，但真正面对压力时，他可能不愿意做决定。

有些管理者不断分析问题，却迟迟无法采取行动。这种情况有时让我很惊讶，因为他们看起来具备很多优秀特质，最终却无法把事情完成。

还有一些人可能不是团队里分析能力最强的，却特别擅长综合各种意见，抓住关键，最后推动事情落地。

因此，每个人的能力组合不同。有的人擅长分析，有的人擅长观察，有的人擅长综合判断，有的人擅长执行。

优秀团队的价值，就在于把这些不同能力组合起来。

但如果一个人想负责一家大型企业，他至少需要在分析、判断、学习、执行、品格和人际管理等方面具备比较完整的能力。

我们当然需要技术专家，但不能只因为某人非常懂技术，就认定他一定能够成为一名优秀的业务负责人。

面试高管时，我首先想了解他是怎样的人

很多人以为，高级管理者参加我的面试时一定会非常紧张。

我通常会尽量让他们放松，因为我真正想了解的是面试者本人，而不是让他们感到自己正在接受一位大型银行 CEO 的审问。

我经常从一些很普通的话题开始。

例如，你在哪里长大？父母做什么工作？你有几个兄弟姐妹？小时候喜欢什么活动？在哪里上学？什么事情对你影响很大？

我希望先知道这是一个怎样的人，然后再深入讨论他的职业经历。

当然，面试只是人才评估的一部分。

对于真正重要的岗位，我们通常安排不同的人参与面试，因为每位面试官可能观察到不同的特点。

有些人非常擅长面试，能够真正理解候选人的思维方式和品格。

但有些面试官太忙于向候选人展示自己有多么优秀，以至于忘记了深入了解对方。

一个候选人的真实表现，不能只靠一场面试判断

对于高级管理岗位，我们通常已经掌握了大量与候选人有关的信息。

例如，他是否努力工作，是否诚实，是否能够把复杂问题写清楚，是否按时完成承诺。

他的同级同事怎么看待他？下属是否愿意为他工作？他犯错时会不会主动承担责任？

他是否尊重别人？是否经常对员工大喊大叫？在困难时期是否表现可靠？

这些问题往往可以通过长期工作记录、推荐意见和不同来源的反馈进行了解，并不需要等到面对面见到候选人才开始判断。

因此，面试不应该是孤立的仪式，而应当是对一个人长期行为和职业经历的深入验证。

我真正想找的是既有能力又有品格，既愿意学习又能够做出决定，并且能够帮助其他人取得成功的领导者。

人才无处不在：名校并不是唯一的人才来源

我非常重视州立大学和不同地区的人才

主持人曾提到田纳西大学 Knoxville 校区的 Haslam College of Business，并告诉我，那里大约三分之一的本科生对商业教育表现出兴趣。

我认识 Haslam 家族，也非常尊重他们帮助学校发展所做的努力。

我认为，这种商业教育需求非常积极。

很多人习惯把顶尖人才与常春藤盟校联系起来，但我长期以来发现，优秀人才其实分布在美国各个地方。

很多人拥有能力、抱负和工作热情，只是没有获得同样的机会，或者没有被传统招聘体系充分发现。

因此，我不会简单认为来自哈佛或其他名校的毕业生，就天然优于州立大学的学生。

教育背景当然可能提供一些信息，但它不能替代对一个人真实能力、品格和努力程度的判断。

美国很多城市仍然充满创业与发展活力

我很喜欢 James Fallows 关于美国不同城镇的研究与写作。他和妻子曾走访美国许多城市，记录当地社区如何发展经济、教育和社会组织。

我自己在全国出差时，也经常看到类似的情况。

无论是在 Birmingham、Jackson、Huntsville，还是美国其他地方，我都会遇到大量希望发展事业、建立企业、获得好工作的人。

我去过很多历史上黑人高校 HBCU，与那里的学生交流。

这些年轻人希望得到工作机会，希望发展自己的能力，希望进入优秀企业。他们并不像一些媒体描述的那样，只会抱怨或者缺乏工作热情。

我还观察到，在田纳西、佐治亚、北卡罗来纳、南卡罗来纳和得克萨斯等州，一些地区具有非常强烈的创业和发展动力。

从某些角度看，这些地区的经济活力可能比加利福尼亚、密歇根或纽约的一些地方更加明显。

当然，这并不意味着所有人都相同，但这种地区发展趋势值得认真观察。

我希望更多年轻人理解商业和自由企业制度是如何运作的，也希望学校更好地教授公民教育、经济制度和企业经营的基本知识。

这些能力对于一个社会保持长期繁荣非常重要。

Haslam 家族就是一个很好的创业案例。Jim Haslam 建立了 Pilot Flying J，后来这项业务被 Berkshire Hathaway 收购。这种从创业、经营到建立大型企业的经历，本身就值得年轻人研究。

重返办公室：为什么我不认同把远程办公作为普遍标准

我关注的是实际效果，而不是迎合流行观点

我曾经因为支持员工重返办公室而受到很多关注，有些人把我的一次讲话称为“怒斥”或者“激烈批评”。

我知道自己讲话时有时会表现得非常有情绪和力量，但我认为，那次讨论其实是在认真回应一个非常具体的问题。

我并不是为了反对某种流行趋势而故意提出相反意见。

我的原则是先努力找出事实，然后根据事实行动。

如果某种做法确实更好，我愿意接受；如果某种做法看似受欢迎，但实际上正在伤害企业、客户或者员工发展，我也愿意指出问题。

我一直认为，做正确的事，比做眼前方便的事更加重要。

年轻员工需要在真实工作环境中学习

我反对某些远程办公安排，一个非常重要的原因，是它们可能损害年轻员工的培养过程。

大多数人的职业能力，并不是只靠阅读教材或者参加线上培训获得的。

很多技能来自学徒式学习。

你坐在资深同事旁边，观察他如何与客户沟通，如何参加销售会议，如何进行演示，如何处理反对意见，甚至观察他怎样犯错、怎样修正错误。

这些日常细节会逐渐形成个人的职业判断和沟通能力。

如果年轻员工长期不在办公室，他们可能无法获得同样的观察和参与机会。

我们已经发现，一些不经常到办公室的年轻人，在参与客户项目、建立内部人际网络和提升工作能力方面落后了。

他们可能不会被安排到重要客户账户上，也没有机会自然地认识更多同事。

这种损失不仅是工作技能上的，还可能涉及社交能力和职业发展机会。

我甚至担心，长期减少面对面社交可能影响年轻人建立亲密关系的机会，包括认识未来伴侣。

工作场所往往比个人居住社区更加多样化，能够让人接触不同背景、不同想法的人。

如果一代年轻人长期缺少这些经历，其中一些损失可能很难完全弥补。

视频会议无法完全复制面对面管理

我有时把远程会议管理称为“好莱坞方格游戏式管理”，因为屏幕上排列着一格一格的人脸。

但这种沟通与真实坐在同一个会议室里存在明显差异。

假设我不同意 Monica 的某个观点，如果我们面对面交流，我可以通过语气、眼神和身体语言，让她知道我是在认真提出问题，而不是攻击她。

她也可以立即观察我的反应，继续解释自己的想法。

但在一个同时有 12 个人的视频会议中，这种互动容易变得僵硬。

你对某一个人提出的问题，似乎成了对所有人公开发表的评论。

我也注意到，有些人在视频会议期间会查看手机、平板电脑或者处理其他事情，实际上并没有认真参与讨论。

这并不意味着所有远程会议都没有价值，而是说明它们无法完全替代某些面对面管理活动。

远程办公会削弱许多自然发生的后续沟通

我们在办公室开完一整天的管理会议之后，通常不会立即停止讨论。

大家会在走廊里继续交流，有人可能过来告诉我，上午提到的问题已经解决了，也有人可能提出新的风险。

我会让某位高管去找另一位同事讨论，或者直接走到他们的办公室继续推进。

这些自发发生的后续沟通，构成了企业执行效率中非常重要的一部分。

在线上会议里，大家更容易说：“这个问题我们下周再讨论。”

如果星期五很多人不在办公室，团队也可能决定推迟讨论，因为关键人员没有到场。

结果是，原本当天能够解决的问题，被拖延到下一周。

我不希望大型组织因为不断等待下一次正式会议而降低执行速度。

弹性工作与长期远程办公不是同一回事

在推进办公室政策之前，我们实际上认真分析过工作安排的效果。

我们曾经允许部分员工每周在办公室工作三天、在家工作两天。

但实际执行中，有些人变成每周只到办公室两天，在家工作三天，甚至没有遵守原本已经相对宽松的规定。

我认为，这种情况必须被正视。

有些人会说：“远程办公对我来说很有效。”

但这只说明个人感受，并不是关于组织效率的充分分析。

还有人会说：“反正我的团队很多会议都是通过 Zoom 进行的。”

这同样不能自动证明远程办公是最佳安排。

我们应该分析的是，它对客户服务、员工成长、团队协作、管理效率和长期经营结果究竟产生了什么影响。

同时，摩根大通并不是完全反对远程工作。我们有大约 10% 的岗位可以长期在家办公，因为这些岗位的工作性质允许这样做，而且这种安排能够满足业务和客户需要。

我反对的是，在某些岗位明显不适合长期远程工作的情况下，仍然把它当作所有人都应该享有的普遍安排。

工作模式是一项商业选择，不是道德判断

我完全接受不同企业采用不同的经营模式。

有些公司可能选择高度远程化，另一些公司可能要求更多面对面协作。

如果两种方式都符合法律和商业要求，它们完全可以在市场中竞争。

我相信自己的公司因为重视办公室协作而具有优势。其他企业可以不同意，也可以建立完全不同的组织方式。

最终，竞争结果会告诉我们哪些方法更有效。

但这不应该被理解为一个道德问题。

我并不是说选择远程办公的人在道德上有什么错误，也不是说所有企业都必须模仿摩根大通。

我觉得奇怪的是，有些人因为自己希望在家办公，就认为应该要求摩根大通采用同样的制度。

他们完全可以选择其他工作模式不同的企业。

但当我们根据自身业务、员工发展和客户需求作出管理决定时，这项决定应该得到基本尊重。

社会分歧、公共讨论与企业的责任

美国社会并不像媒体画面中那样处处对立

现在美国确实存在很多政治和社会分歧，一些人甚至不敢公开表达不同意见。

但我认为，必须区分媒体呈现的全国性政治争论，与大量普通社区的真实生活。

当我们乘坐巴士走访 Huntsville、Greenville、Raleigh、Durham、Austin、Spokane、Boise 和 Bozeman 等城市时，经常看到的是人们正在积极合作。

当地政府、企业和居民共同讨论怎样改善学校，怎样帮助贫困社区，怎样为少数族裔创造机会，怎样建设步道和河滨公共空间，以及怎样吸引企业和增加就业。

很多地方仍然在增长、创新和改善居民生活。

如果一个人每天主要通过华盛顿、纽约以及 CNN、Fox News 等媒体观察美国，他可能会觉得整个社会始终处于激烈冲突中。

但当你真正走进这些城市，就会发现很多普通人仍然在努力工作、照顾家庭、经营企业和建设社区。

这并不意味着社会分裂不存在，而是说，现实比高度政治化的媒体叙事更加复杂。

面对争议，企业应该坚持原则，也应该根据法律调整政策

摩根大通会认真分析社会争议，并形成自己的立场。

我们长期关注气候、人才多样性以及其他公共议题。

当法律发生变化时，我们当然需要检查自己的政策是否符合新的要求，并在必要时作出调整。

例如，在多样性相关政策方面，法院对种族配额以及某些依据种族作出决定的做法提出了明确限制。

我们一直强调，公司没有采用招聘配额，也不会简单依据肤色决定一个人的录用、薪酬或者晋升。

面对新的法律环境，我们修改了一些政策措辞和具体项目，但这并不意味着停止接触不同背景的人才。

我们依然会到历史上黑人高校招聘，也会继续与西班牙语社区交流，为需要西班牙语服务的客户提供支持。

我认为这些活动本身具有商业价值，也能够帮助公司发现人才、服务客户。

与此同时，我们确实取消了一些原来的项目。

其中一部分原因是，它们已经变得过度官僚化，或者不能实现预期目标。

我们在合规、审计和财务部门也经常做类似的事情：某些流程随着时间不断增加复杂度，却没有带来实际价值，那就应该取消或者重新设计。

我不认为任何项目只要被赋予了一个好的名称，就自动值得永久保留。

我们应该持续检查它究竟有没有效果。

我的办公室管理方式：保持开放，而不是把日历排满

我尽量让员工随时能够找到我

虽然我经常出差，在总部办公室的时间大约只有一半，但只要人在公司，我都会努力保持开放和可接触。

我几乎每天都会回复大多数电话和电子邮件。

如果有人打电话说需要和我讨论 30 分钟，我通常愿意安排。

但对直接向我汇报的高级管理人员，我并不总是设置固定的周期性一对一会议。

原因是我们已经非常熟悉彼此，也建立了充分信任。

他们知道如果遇到问题，可以直接来找我；如果我认为某件事情需要讨论，也会直接联系他们。

我在日历上有意保留一些空白时间。

当然，我也需要参加正式会议、经营评审和其他重要活动，但我不希望一天的每一分钟都被预约占满。

留出空白时间，意味着我可以在办公室里走动，观察团队正在发生什么，也可以随时加入重要讨论。

我更喜欢真实、直接的交流

我经常在办公室楼层走动，走进某位同事的办公室，问问正在处理的问题，或者在走廊里继续讨论上午会议提出的事项。

有时，我会直接走进一个正在进行的会议，加入讨论。

如果某个问题需要更长时间，我可能约相关人员一起吃午饭，或者在下班后喝一杯，继续谈上 45 分钟甚至更久。

我并不认为所有重要交流都必须通过提前两周预约的正式会议完成。

真正重要的是，相关人员是否能够充分表达观点、及时解决问题，以及把后续行动落实下去。

对于已经非常成熟、工作表现优秀的高管，我也没有必要频繁干预。

他们知道什么时候需要找我，我也知道什么时候应该提出自己的意见。

如果能够与历史人物进行一次私人谈话

我最想见的人是 Abraham Lincoln

如果能够与历史上任何一个人进行一次深入交流，无论对方是否还活着，我大概会选择 Abraham Lincoln。

我读过很多关于林肯的书，越了解他，就越欣赏他的智慧和品格。

他既有很高的智力，也有很强的情商。他能够思考极其复杂的问题，同时理解不同人的动机和情绪。

他也是一位非常善于运用语言的人，能够用简洁、有力量的表达解释重大问题，而且还非常幽默。

更重要的是，他在美国历史上极其困难的时期承担了领导责任。

在国家面临分裂、战争和巨大压力的时候，他仍然努力维持国家统一，并作出很多极其艰难的决定。

我很想了解，他究竟怎样思考问题，怎样处理不同意见，怎样在高压环境中保持判断能力。

我一直喜欢历史，特别是在休假时，经常阅读大量历史书籍。因为历史能够让我们理解，许多今天看起来全新的问题，其实都有过去的经验可以参考。

最有价值的私人讨论，往往涉及艰难的人事决定

如果回顾自己职业生涯中最重要的一些私人讨论，我很难只选择某一次会议。

真正重要的交流，很多都与艰难的人事决定有关。

例如，我们需要判断某个人是否适合某个岗位，是否应该调整管理团队，或者怎样处理复杂的组织关系。

我通常不会只听取一个人的意见，就立即作出决定。

有时，我会先见三个人，听取不同观点，然后思考一段时间，再见另外三个人。

新的信息可能让我重新理解原来的问题，于是我又会回头找到最早交流过的人，继续追问。

这个过程很像一层一层剥洋葱。

你原本以为自己已经理解了选择，后来却发现还有其他因素没有考虑。

你需要不断深入，才能弄清楚真正可行的选项是什么，以及相关人员是否真的具备承担责任的能力。

对我而言，这些看似普通的谈话，往往比一次公开演讲更能影响公司的未来。

继任与退休：什么时候应该离开 CEO 岗位

我没有设定一个绝对明确的退休日期

外界一直关心我什么时候会卸任摩根大通 CEO，以及谁会成为下一任领导者。

我目前没有给出一个确定的时间表。

在我看来，继任应该同时满足两个条件：继任者已经做好准备，而且确实到了我应该离开的时候。

这两个因素需要结合起来考虑。

如果未来我不再担任 CEO，董事会可能希望我继续担任董事长一段时间，也许是几年，但具体安排仍然需要由董事会决定。

而且，新任 CEO 上任之后，他或她也应该对未来的治理安排拥有适当的话语权。

我的目标不是无限期地保留权力，而是确保公司能够顺利完成领导层过渡。

下一任 CEO 不一定是最聪明的人，而应该是最好的领导者

我认为下一任 CEO 需要具备很多我们已经讨论过的品质。

他或她必须聪明，但仅仅聪明远远不够。

更重要的是品格、责任心、好奇心、工作投入程度、尊重他人的能力，以及让整个团队发挥最大潜力的能力。

我见过许多非常聪明的人，但他们不一定能够有效管理组织。

有些人可能在专业技术上远远超过我，我也会非常愿意承认这一点。

但领导者的工作，不是证明自己在每个领域都比下属优秀。

更好的比喻是体育教练。

一位优秀教练不一定是球场上技术最强的人，却可以通过合理安排、指导、激励和组织，让整支球队打出远超个人能力简单相加的表现。

有时，一个不合适的球员可能破坏整个团队的表现；而一位优秀教练能够让不同类型的人形成真正的协作。

因此，最聪明的领导者，未必是智商最高的人，而可能是最善于释放他人能力的人。

我预计未来的 CEO 很可能来自公司内部，因为我们拥有非常优秀的人才梯队。

但作为一项管理纪律，我们也会认真考虑外部候选人。

真正重要的是找到最适合公司的人，而不是事先把所有可能性排除掉。

离开 CEO 岗位之后，我还想做什么

写书、教学，以及继续学习

我并不认为退休意味着从此什么都不做。

我很可能会写一本书，把职业生涯中积累的经验、判断和教训整理下来。

我平时写了很多东西，因此已经拥有不少材料。等到真正有时间时，我希望能够认真完成它。

我也希望参与教学。

主持人曾邀请我到田纳西大学的 Haslam College of Business 授课，我对此很感兴趣。

我不一定能长期住在那里，但完全愿意去上一些课，和学生讨论商业案例、领导力、风险管理以及企业经营。

我很喜欢案例教学，因为真实商业案例没有那么多简单、标准化的答案。学生必须理解背景、分析不同选择，再考虑决策后果。

我认为，这是一种很好的学习方法。

至于主持人提议的高尔夫球或者麻将，我没有特别大的兴趣，也不打算因为退休就突然培养这些爱好。

我希望帮助真正需要改善的企业和慈善机构

目前，我没有在其他上市公司董事会任职，因为这可能带来利益冲突，也需要投入大量时间。

但未来，如果我非常喜欢某家公司的业务和团队，也许愿意加入它的董事会。

我同样有兴趣帮助一些慈善机构改善治理和经营。

世界上有不少优秀的慈善组织，拥有很有意义的使命，却可能因为管理不善、战略不清晰或者治理结构存在问题而陷入困境。

如果我能够担任董事长，帮助它们寻找合适的董事、调整战略、改善组织结构，并让机构重新发挥作用，我会觉得这是一件非常值得做的事情。

我不希望只是挂名坐在董事会里，定期开会，却不产生任何实际贡献。

此外，我也可能与朋友一起投资或者经营企业。

也许未来会租一间办公室，研究收购机会，投资一些公司，参与实际经营。

如果我的女儿或者女婿愿意一起做，我也会很高兴。

但我绝不会强迫他们参与我的事业。他们应该有自己的选择。

事实上，我已经有一些朋友在开展类似活动，只是因为目前的职位和利益冲突限制，我不能参与。

等到适当的时候，这些可能都会成为人生下一阶段的一部分。

新闻业的价值：让公众真正理解复杂世界

我非常尊重新闻工作者，但希望新闻业减少标题党

我对新闻业一直很有兴趣，也非常尊重记者的工作。

我认为，记者不仅仅是向普通公众传递信息，他们也在教育那些真正影响社会决策的人。

参议员、众议员、州长以及他们的工作人员，都会通过新闻报道了解经济、企业和公共政策。

这些人的判断可能影响大量人的生活，因此新闻质量非常重要。

当然，我也经常批评媒体行业的一些问题。

现在有太多为了吸引点击量而设计的内容，也有太多未经充分验证的信息被反复传播。

但这些问题并不改变新闻业本身的重要性。

我希望新闻机构能够投入更多资源，帮助读者深入理解复杂问题，而不是只提供一些快速、情绪化或者缺乏背景的判断。

与 Jeff Bezos 的友谊，让我更关注《华盛顿邮报》

我和 Jeff Bezos 认识很多年了。最早我们曾经讨论过亚马逊总裁的机会，后来一直保持友谊。

我非常欣赏他，也逐渐认识了他的妻子 Lauren。前不久我和 Judith 还参加了他们的婚礼。

Jeff 现在不仅是一位企业家，也是《华盛顿邮报》的所有者。

我偶尔会与《华盛顿邮报》的编辑们交流，也向 Jeff 提出过一些关于报纸运营和报道方向的想法。

在我看来，全球真正具有国际影响力的几家英语新闻机构，包括《纽约时报》、《华尔街日报》、《金融时报》和《华盛顿邮报》。

它们都非常重要，也都还有继续改善的空间。

例如，美国主流报纸对国际事务，特别是国际企业和金融商业活动的报道，我认为仍然不够充分。

全球经济正在发生大量复杂变化，但美国普通读者未必能够通过日常新闻充分理解这些变化。

我希望主要新闻机构能够提供更多有深度的国际商业报道。

长篇深度报道不能被快速新闻完全取代

我一直很喜欢真正深入的新闻调查和长篇报道。

过去，我有时会组织小型沙龙式晚宴，让不同背景的人围绕某个重要问题进行深入讨论。

这种交流的价值在于，大家不需要在几分钟内形成结论，也不用把复杂问题压缩成几个适合传播的观点。

同样，新闻机构应该给记者足够时间，让他们真正研究一个主题，理解背景，寻找证据，并向公众解释复杂问题的结构。

我认为，优秀新闻机构不仅要告诉公众发生了什么，还应该尽可能解释为什么会发生、哪些因素导致了问题，以及真正的解决方案可能是什么。

例如，学生贷款问题不应该只停留在“是否应该减免贷款”这样的简单争论上。

我们需要理解学生贷款制度究竟在哪些地方出了问题，哪些政策需要修复，哪些规则应该改变，什么样的人应该得到债务减免，以及为什么。

这些问题都需要严肃分析，而不能只给出一句政治口号。

住房负担能力同样如此。

关于经济增长和住房供给的讨论，例如《Abundance》一书所涉及的问题，值得通过深入研究来理解。

教育改革也一样。

我们知道某些高中教育模式有效，也知道有些做法长期没有取得理想结果。

但如果我们只是反复说“学校存在问题，必须改革”，却不愿意具体研究哪些方法有效、哪些没有效果、为什么有效，以及怎样真正实施，就不可能获得持续改善。

我希望未来有机会参与推动这类深入的公共讨论。

至于是否会与 Jeff Bezos 在新闻领域开展某种合作，我并没有确定计划，但确实有不少想法。

无论通过写作、支持深度报道、参与讨论，还是帮助新闻机构提高经营能力，我都希望能够让公众获得更准确、更完整、更有价值的信息。

结语：人生真正重要的是持续学习、承担责任，并让他人变得更好

回顾我的职业生涯，我经历过被解雇，也经历过重新开始；参与过大量并购与企业整合，也领导过复杂的组织转型；面对过金融危机、监管压力、全球经济变化，以及两次直接威胁生命的疾病。

这些经历让我越来越清楚，职业生涯并不是一条始终向上的直线。

一个人可能在某个阶段获得巨大的成功，也可能在下一阶段遭遇非常严重的挫折。

真正重要的是，遇到困难之后，能否承认现实，保持理性，认真检视自己的错误，并继续行动。

在企业管理上，我始终相信几项基本原则：认真研究事实，理解风险，尊重员工和客户，持续保持好奇心，并且在必要时作出艰难决定。

我不希望成为一个只会发表观点，却不愿承担结果的领导者。

我希望公司里每个人都能有机会表达真实想法，能够在自己的岗位上不断学习，也能够得到应有的尊重。

优秀的管理不应该让员工依赖某一位特别聪明的领导者，而应该帮助整个组织形成判断、学习和执行的能力。

在个人生活上，我始终认为，家庭不能被当作职业成功之后才有时间照顾的事情。

工作当然重要，我也一直热爱工作。但如果一个人希望陪伴家人，就应该主动为他们安排时间，并接受这种选择所需要付出的机会成本。

两次严重疾病还让我意识到，我们无法假设自己拥有无限的时间。

如果有一天我离开摩根大通，我仍然希望继续写作、教学、投资、帮助企业和慈善机构解决问题，也希望把自己的经验传递给年轻人。

最终，我并不认为人生最值得追求的是一个头衔、一份财富，或者别人是否把你的名言挂在墙上。

我更在乎自己有没有努力做好应该做的事情，有没有尊重和帮助身边的人，有没有为家庭尽到责任，以及有没有通过工作让企业、社区和国家变得更好。

我希望始终保持好奇心，诚实面对问题，尽最大努力完成自己承担的责任，并让身边的人有机会发挥他们最好的能力。