AI时代资深全栈工程师的Python学习路线

先说结论：目标不是精通 Python，而是能对交付负责

对已有 11 年 Web/full-stack 经验、正在转向机器人和工业软件的工程师，Python 学习不应该从“再做一遍初级程序员”开始。已有的软件架构、接口设计、前端交互、Web3D、调试和交付经验仍然有效，需要补的是 Python 的语言边界、工程工具链和机器人领域证据。

Python 在这条职业路径中的主要价值，是连接 ROS2、OpenCV、模型推理、设备 SDK、数据处理和工程服务。目标是能够读懂、修改、测试、部署 Python 系统，并对数据错误、资源泄漏、并发失控和设备副作用负责，而不是背完所有语法或库函数。

Vibe Coding 显著降低了语法、样板代码和 API 查询成本，却没有降低软件失败的代价。代码生成越快，任务拆分、边界设计、代码审查、测试、故障定位和结果责任越重要。“能让 AI 写出来”不是掌握标准，“能判断它为什么正确、在哪些条件下失效，并拿出验证证据”才是。

按每周 5～7 小时投入，六个月的合理目标是形成机器人应用软件、工业视觉或 AI 应用岗位可以检查的项目证据。它不能证明已经具备商业机器人运动控制、全身控制、强化学习或 VLA 研究能力；这些方向需要另外投入控制理论、C++、仿真、机器人数据和算法实践。

结合职业规划重新定义 Python 能力

Python 不需要脱离岗位单独“学完”。应按目标工作中的任务决定深度：

已有能力	转入 Python 后的复用方式	需要新增的证据
资深 Web/full-stack 交付	API、状态管理、鉴权、日志、测试、部署和故障处理	用 Python 服务完成同等质量的工程闭环
前端交互与 Web3D	机器人状态可视化、数字孪生、实时调试台	打通 ROS2 或设备数据到 Web UI 的链路
软件架构	设备抽象、状态机、任务编排、错误边界和可观测性	用可运行项目证明边界在异常条件下成立
光学工程背景	成像、标定、误差和坐标转换的理解基础	OpenCV 标定、PnP 或视觉引导流程及误差分析
AI 应用经验	模型 API、RAG、工具调用和工作流	评测、权限、安全门控、审计与失败处理

因此，学习顺序应是“Python 工程底座 -> 视觉或设备小项目 -> ROS2/工业集成 -> AI 辅助运维”，而不是先花几个月通读语言大全，再开始做项目。

四层掌握标准

层级	掌握标准	重点内容	验证方式
必须闭卷掌握	不依赖 AI，能解释机制并写出最小代码	常用容器、可变性、函数与作用域、异常、迭代、上下文管理器、模块、类型提示、并发选型	五分钟讲清机制，完成一个小型编码或排障任务
需要工程化掌握	能构建、测试、诊断和维护，不只会调用 API	项目结构、环境与依赖、配置、日志、pytest、静态检查、运行时校验、超时取消、可观测性	可复现仓库、自动化测试、日志、故障案例和修复记录
按岗位掌握	能完成一条小型端到端工作流	FastAPI/Pydantic、NumPy/OpenCV、ROS2 Python 或 PyTorch 推理，按目标岗位选取	可运行项目、演示、指标和明确的适用边界
可以借助文档或 AI	知道去哪里查，并能用最小实验确认结果	冷门标准库 API、描述符与元类细节、复杂装饰器、少用框架参数、版本相关行为	官方文档链接、最小复现实验和测试结果

“可以借助 AI”不等于允许完全不知道。至少要能识别问题属于语言、依赖、并发、数据还是设备边界，找到权威资料，并设计验证方式。面试时也可以坦诚某个精确 API 需要查询，但必须说得出解决路径和风险。

资深工程师必须补齐的 Python 工程底座

1. 先掌握数据语义，不追求语法花活

• 容器选型：list 表示有序可变序列，tuple 常用于固定结构或不可变返回值，dict 用键定位数据，set 用于去重和成员判断。要能说清常见操作的平均复杂度，也要知道复杂度不是脱离数据规模和访问模式的万能答案。
• 引用与可变性：变量绑定对象，赋值通常不会复制对象。切片和 copy.copy() 多为浅拷贝，嵌套可变对象仍可能共享。设备状态快照若误共享内部列表，历史记录可能被后续更新悄悄改写。
• 函数边界：避免用可变对象作为默认参数；明确参数是否允许原地修改；返回值优先表达稳定契约。AI 很容易生成“能跑”的共享状态代码，但调用方并不知道副作用。
• 推导式与生成器：小数据转换用推导式保持清晰，流式图像、日志和 rosbag 数据优先考虑迭代器或生成器，避免一次把无法控制的数据量装入内存。

不需要为了展示 Python 风格把每段循环压成一行。资深代码的判断标准是数据所有权清楚、边界明确、容易测试，而不是语法短。

2. 把异常和资源生命周期当成主流程

异常应在能够补充上下文、恢复或转换协议错误的边界捕获。不要用空的 except Exception 吞掉相机断连、模型加载失败或机器人命令超时。重新抛出时使用异常链保留原始原因：

try:
    frame = camera.read()
except CameraSdkError as exc:
    raise FrameAcquisitionError(f"camera {camera.id} read failed") from exc

文件、socket、锁、相机句柄和推理会话需要确定释放。优先使用 with 和已有上下文管理器；封装第三方 SDK 时，也应把 open/close 变成可测试的生命周期。生成器中途退出、任务取消和异常路径同样要验证资源是否释放。

3. 类型提示不是运行时防线

类型提示改善 IDE、静态检查、重构和多人协作，但 Python 默认不会因为参数标注为 JointState 就拒绝错误 JSON。来自 HTTP、MQTT、ROS2 bridge、配置文件或设备 SDK 的数据仍需在运行时校验。

内部核心逻辑可以使用 dataclass、TypedDict、Protocol 和普通类型提示表达契约；外部 API 边界可使用 Pydantic 或显式校验。不要用 cast() 或 # type: ignore 把未知数据“变正确”，那只会关闭检查器，不会改变运行时对象。

4. 建立可复现的项目卫生

• 为每个项目建立隔离环境，常规服务可用 venv，科学计算或 CUDA 依赖复杂时可选择 conda；工具不是重点，可复现才是。
• 用 pyproject.toml 或受控 requirements 记录直接依赖和工具配置，避免只提交一份混入整台电脑所有包的 pip freeze。
• 配置与代码分离，密钥不进入仓库；启动时校验配置并输出不含敏感值的有效配置摘要。
• 使用结构化日志记录时间、级别、任务 ID、设备 ID、状态变化、耗时和错误原因，不能只依赖散落的 print()。
• 统一格式化、lint 和类型检查。具体选择 Ruff、Black、mypy 或 Pyright 可以随团队变化，但规则必须能在本地和 CI 重复执行。

机器人和工业现场的问题往往不能立即复现。没有版本、配置、输入摘要、设备状态和关联 ID 的日志，远程排障只能靠猜。

5. 测试围绕边界和故障，而不是覆盖率数字

优先把坐标转换、状态迁移、数据清洗和命令校验写成无硬件依赖的纯逻辑，用 pytest 覆盖正常路径、边界值和异常路径。相机、机器人、数据库和模型服务通过小接口隔离，分别使用录制数据、模拟器、fake adapter 或受控集成环境测试。

Mock 的价值是控制外部行为，不是逐行复刻内部调用。若测试只断言某个私有函数被调用三次，重构实现就会造成大量无业务意义的失败。更值得断言的是：断连后状态如何变化，重复命令是否被去重，错误是否保留上下文，超时后资源是否释放。

6. 并发先分清任务性质，再看 GIL

任务	首选起点	关键风险
大量网络 I/O，依赖提供异步 API	asyncio	阻塞函数卡住事件循环、无界创建 task、取消不完整
少量阻塞式设备 SDK 或文件 I/O	线程池	SDK 是否线程安全、共享状态竞态、线程无法强制取消
纯 Python CPU 密集计算	多进程或拆到原生实现	序列化成本、进程启动、内存复制和生命周期
NumPy/OpenCV/PyTorch 运算	先测量，再利用库自身并行能力	底层线程过量、CPU/GPU 数据搬运、批次和内存上界

在传统启用 GIL 的 CPython 运行时中，GIL 会约束同一进程内 Python 字节码的并行执行，但这不等于“Python 不能并发”，也不等于“加线程一定能提速”。部分 C/C++ 扩展会在计算时释放 GIL；free-threaded 构建还需要结合目标 Python 版本、扩展兼容性和真实负载单独评估。asyncio 是协作式并发模型，适合大量等待型任务，不会自动加速 CPU 密集循环。

设备和实时数据流还要有容量上界：队列最大长度、采样或丢弃策略、超时、取消、背压和优雅停机。报警与运动命令不能照搬“只保留最新一条”的 UI 状态策略。

面试准备：掌握机制、边界和排障，不背冷知识

面试基础仍然存在，但准备方式应从“背答案”改成“机制 -> 适用边界 -> 项目风险 -> 验证方式”。以下范围足以覆盖多数 Python 应用工程岗位的高收益部分：

主题	必须解释	工程追问	学到哪里停止
list / tuple / dict / set	可变性、顺序、哈希、成员查找和常见复杂度	状态快照为何用不可变结构，去重为何不能破坏顺序	不背所有方法和极端实现细节
引用、浅拷贝、可变默认参数	名字绑定对象，嵌套对象可能共享，默认值在函数定义时创建	历史状态为何被后续写入污染，怎样设计所有权	不做脱离项目的刁钻输出题
迭代器、生成器、上下文管理器	惰性取值、一次迭代、yield、with 的进入与退出	大文件/图像流内存上界，异常时句柄释放	会实现简单协议即可，不背解释器内部符号
异常边界与日志	捕获范围、异常链、领域错误和恢复策略	断连、超时、部分成功如何记录并对外表达	不追求用异常控制所有正常流程
类型提示与运行时校验	静态工具能检查什么，外部输入为何仍不可信	JSON、设备消息和模型输出在哪一层校验	不死磕复杂递归类型和大量 type: ignore 技巧
GIL、线程、进程、asyncio	Python 字节码、I/O 等待、CPU 计算和进程隔离的边界	相机 SDK 阻塞、图像处理、网络服务分别怎样选	不背 CPython 源码函数名和事件循环版本冷知识
pytest 与测试边界	fixture、参数化、异常断言、单元与集成测试取舍	没有真实硬件怎样验证，Mock 何时会掩盖问题	不以覆盖率 100% 或 Mock 数量作为目标
打包、依赖与复现	隔离环境、直接依赖、锁定策略和入口命令	CUDA/SDK/系统库为何不能只靠 requirements 复现	不背每个包管理器的全部命令

四个高频问题的回答边界

为什么可变默认参数会保留状态？

默认参数在函数定义时求值，后续调用复用同一个对象；如果函数修改这个列表或字典，下一次调用会看到之前的内容。工程风险是请求、任务或设备之间意外共享状态。通常用 None 作为默认值并在函数内部创建新对象，再用两次调用的最小测试验证隔离性。

线程、进程和 asyncio 怎样选择？

先识别等待型还是计算型任务，再确认依赖是否支持异步、是否释放 GIL、是否线程安全。网络 I/O 可从 asyncio 开始，阻塞式设备 SDK 可隔离在线程中，纯 Python CPU 计算考虑进程或原生实现。最终用吞吐、尾延迟、CPU、内存和取消行为测量，不用“Python 有 GIL”一句话代替设计。

Python 类型提示提供什么保证，又不提供什么？

类型提示主要供静态工具和读者检查契约，默认不会在运行时验证 HTTP JSON 或设备消息。工程上应在外部边界做 Pydantic 或显式校验，内部使用稳定类型；测试无效输入，确认系统明确拒绝而不是带着脏数据继续运行。

没有稳定硬件时怎样测试相机或设备集成？

把 SDK 隔离在 adapter 后面，核心逻辑使用录制图像、rosbag、协议样本、模拟器或 fake adapter；针对断连、超时、重复消息和乱序建立可重复测试。它能证明软件边界，但不能替代真实驱动、时序、电气干扰和硬件在环验证，README 必须区分两类证据。

算法题投入上限

准备数组与字符串、哈希表、栈与队列、树遍历、二分、排序基本思想，以及时空复杂度分析即可。只有目标职位描述、面经或真实面试反馈表明存在算法筛选时，才每周安排两次短练习，并练习口述假设、边界和复杂度。长期每日刷竞赛题，对当前机器人应用软件和工业视觉转型的收益低于完成一个可靠项目。

Vibe Coding 时代怎样学习和使用 Python

Vibe Coding 适合加速脚手架、数据模型、测试初稿、SDK 适配样板和文档整理，但不能替代对系统状态与失败后果的理解。一个可执行的协作闭环是：

1. 先写契约：说明任务目标、输入输出、数据规模、已有接口、禁止动作和验收标准。设备控制任务还要写清只读、仿真或真实硬件边界。
2. 先问方案再要补丁：让 AI 列出假设、备选方案、风险和测试点，检查它是否理解现有架构，而不是立刻接受第一份实现。
3. 控制改动批次：一次处理一个边界或一条数据流，审查 diff；仓库级重写会让错误、依赖和行为变化混在一起。
4. 人工审查高风险面：外部数据校验、异常传播、资源生命周期、并发上界、依赖来源、权限、安全和硬件副作用必须逐项检查。
5. 用证据收尾：运行格式化、lint、类型检查、单元测试、集成测试和仿真或真实流程，保存命令、结果、失败样本和关键决策。

能力区	典型内容	目标
独立写出	常用容器与函数、异常边界、简单类型、pytest 基本用法、小型排障	即使没有 AI，也能读代码、定位问题并接管维护
AI 可以起草	API schema、测试参数、数据转换、CLI、日志字段、文档、SDK adapter 样板	人工确认契约、依赖、错误路径和测试证据后采用
AI 不能替你决定	真实硬件运动授权、删除与数据库迁移、认证规则、有副作用命令的重试、安全边界	由负责人依据业务、设备和安全约束决策，并保留审批与审计

学习时不要把“让 AI 从空白生成项目”当作唯一练习。更有效的循环是：先独立写出接口和失败条件，让 AI 给实现或测试，再解释每一处修改，故意注入一个边界错误并定位。面试时可以展示 AI 初稿、你的审查意见、修复 diff 和验证结果，这比只展示最终代码更能证明工程判断。

AI 生成代码审查示例

假设 AI 为机器人移动接口生成了以下代码：

def move_robot(client, target):
    try:
        return client.move(target)
    except Exception:
        return move_robot(client, target)

代码很短，也可能在一次网络抖动后“看起来恢复了”，但不能进入真实系统：

• 递归重试没有次数上限、退避、超时和取消，持续失败最终导致栈溢出。
• except Exception 吞掉具体错误和上下文，参数错误、权限错误、急停状态与网络超时被当成同一问题。
• 第一次请求可能已经到达控制器并部分执行，客户端只是没有收到响应；直接重试可能造成第二次动作。
• target 没有类型、维度、关节限位、工作空间、当前模式、权限和安全联锁校验。
• 没有命令 ID、审计记录和状态核对，故障后无法回答“命令是否执行过”。

应用层至少需要显式命令身份、输入边界和有限等待。下面的代码只是演示应用边界，不是完整的机器人安全系统：

from dataclasses import dataclass
from typing import Protocol


@dataclass(frozen=True)
class MoveCommand:
    command_id: str
    joints: tuple[float, ...]


class RobotClient(Protocol):
    def get_command_status(self, command_id: str) -> str: ...
    def submit_move(self, command: MoveCommand, timeout_s: float) -> str: ...


def submit_once(client: RobotClient, command: MoveCommand) -> str:
    if len(command.joints) != 6:
        raise ValueError("expected six joints")
    if any(not -3.14 <= joint <= 3.14 for joint in command.joints):
        raise ValueError("joint outside configured limit")

    existing = client.get_command_status(command.command_id)
    if existing != "not_found":
        return existing

    return client.submit_move(command, timeout_s=2.0)

它至少避免了客户端无界重试，并在提交前检查命令是否已有结果。仍需注意：示例中的 [-3.14, 3.14] 只是占位范围，真实关节限位必须来自已验证的机器人配置；“状态不存在后提交”也可能存在并发竞态，需要服务端幂等保证或原子接口。

真实部署还需要控制器和厂商安全限制、工作模式、用户授权、安全联锁、急停、速度与空间限制、状态核对、审计日志，以及仿真和硬件在环验证。AI 无法从一个函数签名推断这些现场约束。

至少为这个边界建立以下 pytest 用例：

• 关节数量不是 6 时拒绝命令，且不调用客户端提交。
• 任一关节值超出配置限制时拒绝命令。
• 已存在的 command_id 直接返回当前状态，不重复提交。
• 新命令提交时传入有限超时。
• 客户端查询或提交错误保留原始异常上下文，不递归重试。

面试中不要只说“我会检查 AI 代码”。应指出具体失败模式、修改后的不变量、尚未覆盖的安全层，以及通过哪些测试、日志和设备状态证明行为。

每周 5～7 小时的六个月路线

默认时间分配如下。若某周工作繁忙，优先保留项目和验证，不要只完成最容易打勾的阅读任务。

每周投入	活动	输出
2 小时	语言基础与面试回忆	一次闭卷讲解、一个小实验或两道针对性编码题
3 小时	主项目实现与调试	一个可演示的小增量及对应提交
1 小时	AI 代码审查、测试与证据整理	审查记录、失败用例、测试结果或性能数据
0～1 小时	复盘或岗位定向准备	周报、薄弱点清单或职位描述差距分析

持续记笔记和每日刷算法都不能挤掉项目时间。笔记只记录会影响决策的机制、踩坑、最小实验和失败结论；可以从官方文档快速查到的参数，不必重新抄一遍。

0～3 个月：建立 Python 工程底座

目标是做出一个可复现、可测试的视觉与设备数据服务，而不是追求功能数量。

学习重点

• 常用数据结构、函数、异常、类型提示、迭代和资源管理。
• 隔离环境、依赖、配置、结构化日志、pytest、lint 和类型检查。
• FastAPI/Pydantic 的 API 与运行时数据边界。
• NumPy 数组的形状、dtype、切片和基本向量化；OpenCV 图像读取、颜色空间和一个确定性处理流程。

交付物

• 一个带类型提示、配置和结构化日志的 Python package。
• 一个 FastAPI/Pydantic 服务，接收录制图像和模拟设备状态。
• 一个可解释的 OpenCV 操作，例如阈值与轮廓检测、标记检测或标定数据加载。
• 对核心转换、无效输入和 API 契约的 pytest 测试。
• README：环境安装、架构、运行与测试命令、限制，以及一次失败复盘。

验收标准

• 在新环境中可以按文档命令完成安装、启动和测试。
• 非法输入返回明确错误，不把原始堆栈或模糊的 500 当作接口契约。
• 至少覆盖一条成功路径和三条失败路径。
• 日志能用 request/task ID 关联输入、处理阶段、耗时和结果。
• 有一段短视频或截图展示完整流程，不只展示 Swagger 页面。

面试价值

证明已有 Web 工程能力已经迁移到 Python：不仅会调用 OpenCV，还能设计可信输入、服务边界、测试和可观测性，并解释一次真实失败怎样定位。

3～6 个月：推进到机器人面对的软件集成

在前三个月项目上增加 ROS2 Jazzy 模拟数据或一个有文档的设备 SDK adapter。重点不是接更多库，而是验证状态、并发和故障行为。

学习重点

• ROS2 node、topic、service、action、parameter、launch、bag 和 TF2 的应用边界，或同等深度的设备 SDK 封装。
• 显式设备/任务状态机、非法状态迁移、重复命令和状态核对。
• 有界队列、超时、取消、断连恢复、有限重试和优雅停机。
• 延迟、错误率、队列长度等最小指标，以及输入或事件回放。

交付物

• ROS2 Jazzy 仿真的 topic/service/action 集成，或具备统一接口和生命周期的设备 adapter。
• 显式设备和任务状态模型，能够拒绝非法迁移。
• 有界并发、超时、取消和状态核对逻辑。
• 延迟与错误指标，以及一次失败输入或事件序列的回放能力。
• 架构图、演示视频、测试报告、已知限制和下一步 backlog。

验收标准

• 默认无需物理硬件即可运行和演示。
• 断连、超时和重复命令能够稳定复现，并有明确结果。
• 非法或不安全的状态迁移默认拒绝，不能静默继续。
• 回放能重现至少一个已经定位的故障。
• README 明确区分仿真证据、录制数据证据和真实硬件证据。

面试价值

证明具备面向机器人的系统集成、正确性、可靠性和可观测性，而不是只把原有 CRUD 服务换成 Python。也能诚实说明哪些结论尚未经过真实硬件、现场时序和安全系统验证。

贯穿项目：视觉检测与设备状态服务

项目不追求“大而全”，只需要把一条数据流做深：

录制图像 / 模拟设备 / ROS2 数据
              |
              v
       adapter 与运行时校验
              |
              v
   OpenCV 处理 + 设备/任务状态机
              |
              v
      FastAPI 查询与任务接口
              |
              v
 日志、指标、测试、回放、Web 可视化

建议仓库至少区分 domain、adapters、api 和 tests：领域层不依赖相机或 ROS2，adapter 负责外部协议，API 只做校验与用例编排。具体目录不是面试重点，依赖方向和可替换边界才是。

项目必须至少包含 OpenCV、ROS2 模拟数据、坐标转换或设备状态建模中的一项领域证据。若大部分时间都用于写管理后台和 CSS，它仍然只是 Web 舒适区项目。前端优势应放在实时状态、TF/轨迹可视化、故障回放和调试效率上。

面试演示按下面顺序准备：两分钟跑通正常流程，两分钟展示一个失败注入和日志/回放，一分钟说明 AI 参与了哪里、你否决了什么，最后说明当前证据边界和下一步验证。这个结构比展示几十个接口更容易证明资深工程判断。

按目标岗位调整学习深度

目标岗位	Python 优先内容	暂不深入
工业数字孪生 / 机器人可视化	ROS2 消息、TF/URDF 数据、NumPy 变换、API/WebSocket bridge、状态建模	深度学习训练、控制器内部算法
机器人应用软件	ROS2 node/topic/service/action、设备 SDK 封装、并发、测试、日志、部署	全身控制、实时运动控制内核、RL
机器视觉应用	NumPy/OpenCV、图像 I/O、相机标定、PnP、坐标变换、误差指标和部署	从头训练大型视觉模型，除非岗位明确要求
AI 应用 / Agent	FastAPI/Pydantic、模型 API、RAG、工具调用、评测、审计、超时和权限门控	只为追热点频繁更换框架，未经门控控制真实设备
算法 / 模型训练（延伸路线）	PyTorch 训练、数学、数据集、CUDA、实验管理和论文复现	不能把当前默认路线的项目替代为概念阅读

近期求职应优先前三到四类岗位。算法和模型训练不是不能学，而是需要单独预算；若目标职位明确要求，再根据职位描述补齐 PyTorch、优化、数据和 GPU 工程，不要用一套模糊的“AI 岗 Python 路线”覆盖所有角色。

暂时不学什么

• 不系统死磕元类、描述符协议和 import internals；能读懂常见用法、知道何时查文档即可。
• 不手写 Web 框架、ORM、事件循环或完整深拷贝来证明基础，除非正在定位相关底层问题。
• 不笼统追求“精通 Pandas、TensorFlow 和 PyTorch”。按项目选库，并把一个工作流做出测试和指标。
• 不长期背低频标准库 API、解释器源码函数名和版本相关输出顺序。
• 不大量阅读 VLA、强化学习或人形机器人论文而没有复现、数据或仿真实验。
• 不反复美化笔记和架构图，却没有可运行仓库、演示、失败案例和验证结果。
• 不为了体现 Pythonic 而滥用装饰器、动态属性和隐式魔法；工业软件更看重显式状态与可诊断性。

这些内容并非永远无用，而是在当前每周 5～7 小时预算下优先级低。遇到目标项目或职位的明确证据，再进行定向补齐。

自检清单

• [ ] 不依赖 AI，能解释引用与可变性、异常边界、生成器、类型提示和并发选型。
• [ ] 能审查 AI patch 中的数据边界、资源、并发、依赖、安全和设备副作用。
• [ ] 能在新环境按 README 重建依赖、运行服务和执行测试。
• [ ] 能展示 OpenCV、ROS2、坐标转换或设备状态中的至少一项领域工作流。
• [ ] 能拿出结构化日志、失败样本、测试、测量数据和修复记录。
• [ ] 能说明项目哪些部分来自仿真、录制数据或真实硬件，不夸大证据。
• [ ] 能解释为什么此处选择 Python，以及实时控制、性能或部署约束何时需要 C++ 或其他运行时。
• [ ] 能把一个项目问题按“现象、假设、实验、结论、取舍”讲清，而不是只罗列库名。

若只能勾选“看过”和“知道”，还不构成面试证据。优先补一个失败用例、一次复现实验或一个可演示增量，不要继续扩充学习清单。

参考资料

• The Python Tutorial
• Python Language Reference
• Typing documentation
• asyncio documentation
• pytest documentation
• FastAPI documentation
• Pydantic documentation
• NumPy documentation
• OpenCV documentation
• ROS2 Jazzy documentation

资料优先级是：当前项目的可复现实验与测试 > 官方文档 > 高质量书籍和课程 > 社区文章。书籍适合建立体系，但不需要先读完《流畅的 Python》才开始项目；遇到数据模型、迭代协议或并发问题时定向阅读，投入产出比更高。