让学习路线留下可验证的作品

课程目录之外，还需要能力关系#

整理 Become Engineer 时，我希望解决一种熟悉的学习困境：材料越来越多，却不知道下一步该做什么。按语言和框架排列课程很容易，解释每项能力为何出现、依赖什么、最终留下什么作品更难。

课程登记目前包含 39 个模块、153 节课程。这个数字来自正式登记，不把导航页和 README 算成课程。工程基础、编程、计算机系统、Web 与 AI 共用能力关系，学习入口可以不同，但不能跳过作品实际需要的前置。

主线以课程和连续作品共同组织。比如进入 LLM/Agent 前，需要具备 Python 工程化与 Web/API 基础；检索、评估与数据库在后续阶段逐步加入。这样学习者面对的是能解释的依赖，而不是一长串热门工具。

同一作品，逐步增加工程能力#

智能学习助手从可替换模型边界开始，先处理结构化输出、超时和不完整结果，再加入语料、检索与引用验证，之后才进入受控工具、持久状态和恢复。每次增加能力，都保留一个可检查的产物。

早期固定 Adapter 让示例可以离线复现。后续课程加入真实 PostgreSQL/pgvector、迁移、恢复和容器边界。教学中的确定性结果用于解释机制，不能直接称为真实模型或线上生产质量。

// 阶段交付记录的最小思路const milestone = {  capability: "有来源的回答",  artifact: "引用校验器",  acceptance: "错引与未知问题被明确拒绝"};

学习助手不能替代验收#

课程内容有语义助教数据，也有对应检索测试 fixture。助教可以帮助定位概念和课程，真正掌握一项能力仍需要学习者运行作品、解释失败并留下证据。

一个能启动的服务不等于一个可恢复的服务。一个返回正确答案的示例不等于一个来源可信的系统。把验收放进学习路线，才能让“学过”逐步变成“可以解释并交付”。框架对照和微调也应放在评估基线之后，避免工具先于问题。

每一步学会什么，也要说清楚每一步留下什么。

资料说明¹