把长期学习路线做成证据驱动的反馈闭环

本文结论

用可重复恢复的每日计划、证据门禁、间隔复习和有边界的负载调整，把长期路线变成可执行的学习系统。

一份长期学习路线可以排得很完整，却无法说明学习者今天真正会做什么。日历能够列出未来十八个月的 Linux、容器、云基础设施和可靠性工程，但它通常回答不了几个实际问题：

为了解决这些问题，我把学习路线实现成了一个带状态的反馈闭环。课程表负责定义预期顺序，每日计划从中选择有限任务，提交的证据推动进度状态变化，周复盘再按明确边界调整后续负载。

日历为什么不够

最初设计是一条按周排列的长期主题序列。它能说明范围，却不能可靠处理学习中断、调度器重复运行、理解薄弱或漏学一天。重新生成计划可能覆盖未完成任务；仅凭聊天中的一句“做完了”更新状态，可能让学习者在没有证据时继续前进；困难的一周结束后仍保持原负载，则会把后续路线逐步变成积压清单。

根因在于，日历同时承担了“计划意图”和“实际进展”两类职责。两者需要分开保存：

职责拆开后，漏学不再要求重写整条路线，也不需要把原计划日期解释成已经具备相应能力。

定时教练可能在同一天重复运行。计划器因此把日期作为稳定身份，并遵循“先恢复，再创建”的顺序：

这样，重试不会覆盖未完成任务，也不会生成第二组当天作业。工作日和周末可以使用不同时间预算，但预算只参与首次创建，不能成为静默改写既有计划的理由。

这个设计也让错过定时运行变得容易处理。学习者手动启动教练时，可以恢复同一份持久计划，无需猜测应该补哪一天，也不会产生新的计划分支。

任务状态只有在含义稳定时才有价值。完成命令要求提交证据路径；证据形式由任务决定，可以是命令输出、代码、测试、运行手册或演示记录。聊天中的口头声明不能单独把任务改成完成。

掌握度与完成状态分开记录，范围为零到五分。命令成功可以证明操作已经执行，但高分还要求学习者独立解释或完成一个变化后的任务。这样可以避免把执行证据直接当作理解证据。

分数还会生成下一次复习日期：

具体间隔属于可调整策略。可复用的机制是把下次复习日期写入结构化状态，让薄弱内容重新竞争未来计划的时间，而不是消失在一段复盘文字里。

周复盘会比较计划任务和已记录结果。当前策略规定：完成率低于百分之七十时，下周负载减少百分之二十；完成率高于百分之九十时，只有平均掌握度至少为四分且没有阻塞，才允许最多增加百分之十。

这些边界让调整过程可以解释，也把学习速度与能力门槛分开。困难的一周可以减少任务量，但不能降低前置知识分数或取消作品集要求。证据不足时，应延长时间线。

修改计划前还要先分类阻塞。知识缺口需要重新教学，环境故障需要排障，时间不足需要缩小当天工作量，任务过大则需要拆分。如果四类问题都用“延后计划”处理，真实限制就会被隐藏。

学习记录可能包含求职信息、本机路径、账号或云资源细节。公开进度因此需要独立的发布门禁和隐私扫描。日常教练可以更新本地状态，但提交或推送当日记录需要当前任务中的明确指令，并且只暂存计划内路径。

可能产生费用的云实验还要经过另一道边界：先估算费用、确认预算告警、取得批准并准备销毁命令，再创建资源。学习调度器不能把一条学习提醒直接变成无人值守的付费决策。

公开参考实现把课程表、JSON Schema（用于校验文件结构的机器可读规则）、计划器、复盘逻辑、隐私检查和测试放在同一个仓库中。带标签的版本覆盖七十八周，并在准确的发布提交上通过了 CI。自动化检查验证了以下行为：

证据驱动的教练仍然不能通过任务数量证明求职能力。它能够把路径变得可审计：计划了什么、证明了什么、哪里仍然薄弱，以及下一次负载为何改变。招聘结果、课程是否仍符合市场需求、提交证据的质量，仍需要人工判断和定期外部复核。

这套设计可以概括为一个小型控制闭环：保留课程意图，确定性恢复每日任务，证据通过后再推进状态，让薄弱知识重新进入计划，并在不降低能力门槛的前提下调整工作量。