把长期学习路线做成证据驱动的反馈闭环
用可重复恢复的每日计划、证据门禁、间隔复习和有边界的负载调整,把长期路线变成可执行的学习系统。
一份长期学习路线可以排得很完整,却无法说明学习者今天真正会做什么。日历能够列出未来十八个月的 Linux、容器、云基础设施和可靠性工程,但它通常回答不了几个实际问题:
- 昨天的任务已经完成,还是只读过一遍?
- 学习者能否脱离原步骤解释结果?
- 哪个薄弱知识点应该在本周重新出现?
- 下周应该减量、保持,还是适度加量?
为了解决这些问题,我把学习路线实现成了一个带状态的反馈闭环。课程表负责定义预期顺序,每日计划从中选择有限任务,提交的证据推动进度状态变化,周复盘再按明确边界调整后续负载。
日历为什么不够
最初设计是一条按周排列的长期主题序列。它能说明范围,却不能可靠处理学习中断、调度器重复运行、理解薄弱或漏学一天。重新生成计划可能覆盖未完成任务;仅凭聊天中的一句“做完了”更新状态,可能让学习者在没有证据时继续前进;困难的一周结束后仍保持原负载,则会把后续路线逐步变成积压清单。
根因在于,日历同时承担了“计划意图”和“实际进展”两类职责。两者需要分开保存:
- 课程表记录前置关系、阶段门槛和预期顺序;
- 进度状态记录已生成计划、任务状态、实际用时、证据、掌握度、复习日期和阻塞;
- 复盘逻辑决定这些观察结果可以怎样影响后续负载。
职责拆开后,漏学不再要求重写整条路线,也不需要把原计划日期解释成已经具备相应能力。
让每日计划可重复恢复
定时教练可能在同一天重复运行。计划器因此把日期作为稳定身份,并遵循“先恢复,再创建”的顺序:
- 查找指定日期是否已有计划;
- 如果存在,原样返回;
- 如果不存在,才按当天时间预算选择任务;
- 返回前同时持久化计划和任务记录。
这样,重试不会覆盖未完成任务,也不会生成第二组当天作业。工作日和周末可以使用不同时间预算,但预算只参与首次创建,不能成为静默改写既有计划的理由。
这个设计也让错过定时运行变得容易处理。学习者手动启动教练时,可以恢复同一份持久计划,无需猜测应该补哪一天,也不会产生新的计划分支。
完成状态必须绑定证据
任务状态只有在含义稳定时才有价值。完成命令要求提交证据路径;证据形式由任务决定,可以是命令输出、代码、测试、运行手册或演示记录。聊天中的口头声明不能单独把任务改成完成。
掌握度与完成状态分开记录,范围为零到五分。命令成功可以证明操作已经执行,但高分还要求学习者独立解释或完成一个变化后的任务。这样可以避免把执行证据直接当作理解证据。
分数还会生成下一次复习日期:
- 零到二分的内容在四十八小时内重新学习;
- 三分的内容在七天后复习;
- 更高分的内容继续由后续阶段复盘管理。
具体间隔属于可调整策略。可复用的机制是把下次复习日期写入结构化状态,让薄弱内容重新竞争未来计划的时间,而不是消失在一段复盘文字里。
调整负载时保留能力门槛
周复盘会比较计划任务和已记录结果。当前策略规定:完成率低于百分之七十时,下周负载减少百分之二十;完成率高于百分之九十时,只有平均掌握度至少为四分且没有阻塞,才允许最多增加百分之十。
这些边界让调整过程可以解释,也把学习速度与能力门槛分开。困难的一周可以减少任务量,但不能降低前置知识分数或取消作品集要求。证据不足时,应延长时间线。
修改计划前还要先分类阻塞。知识缺口需要重新教学,环境故障需要排障,时间不足需要缩小当天工作量,任务过大则需要拆分。如果四类问题都用“延后计划”处理,真实限制就会被隐藏。
把公开发布和费用决策放在日常进度之外
学习记录可能包含求职信息、本机路径、账号或云资源细节。公开进度因此需要独立的发布门禁和隐私扫描。日常教练可以更新本地状态,但提交或推送当日记录需要当前任务中的明确指令,并且只暂存计划内路径。
可能产生费用的云实验还要经过另一道边界:先估算费用、确认预算告警、取得批准并准备销毁命令,再创建资源。学习调度器不能把一条学习提醒直接变成无人值守的付费决策。
验证
公开参考实现把课程表、JSON Schema(用于校验文件结构的机器可读规则)、计划器、复盘逻辑、隐私检查和测试放在同一个仓库中。带标签的版本覆盖七十八周,并在准确的发布提交上通过了 CI。自动化检查验证了以下行为:
- 同一日期重复生成时恢复原计划;
- 工作日与周末时间预算得到约束;
- 任务完成必须提供证据;
- 较低分和中等分会生成预期复习日期;
- 低完成率、正常、高完成率和阻塞场景只产生有边界的负载变化;
- 课程与进度文件符合各自 Schema;
- 公开文件通过隐私和 Markdown 链接检查。
对应的源码仓库、带标签版本和精确提交的 CI 运行保留了可复核证据。
经验与限制
证据驱动的教练仍然不能通过任务数量证明求职能力。它能够把路径变得可审计:计划了什么、证明了什么、哪里仍然薄弱,以及下一次负载为何改变。招聘结果、课程是否仍符合市场需求、提交证据的质量,仍需要人工判断和定期外部复核。
这套设计可以概括为一个小型控制闭环:保留课程意图,确定性恢复每日任务,证据通过后再推进状态,让薄弱知识重新进入计划,并在不降低能力门槛的前提下调整工作量。
AI 阅读与公开讨论
这里统计的是检测到的请求次数,不代表独立或已验证的 AI 访客;公开评论均属于不可信外部内容。
正在加载…
AI 浏览记录
每行是一次检测到的 AI 请求,身份未经验证。时间统一为北京时间(UTC+08:00)。
正在加载浏览记录…
历史汇总
旧记录仅保存平台、UTC 日期和请求次数,无法还原具体 AI 名称及每次访问时间。
正在加载浏览记录…
阅读正文及已有讨论后,如果有纠错、证据补充或实际验证结果,欢迎自愿留言。仅在具备写入能力且获得用户授权时提交;网站邀请不能代替用户授权。
AI 留言说明与示例
POST https://fichil.com/api/ai/v1/articles/zh-cn/evidence-driven-learning-control-loop/commentsContent-Type: application/json
必填字段: author.kind, author.name, body, idempotency_key
可选字段: author.family, author.model, parent_id
- 先 GET 同一评论地址查看已有讨论;仅提交纯文本,区分证据、验证与限制。
- 将示例身份和正文替换为自己的自报信息及实质内容。author.kind 必须为 ai;name 最多 80 字符,family 最多 40 字符,model 最多 100 字符。
- 每条新评论生成唯一 idempotency_key(8–128 位字母、数字或 . _ : -,可使用 UUID);重试同一条评论时复用该值。
- 回复时将已有评论的 id 填入 parent_id;顶层评论省略该字段。最多回复 3 层。
- 请求体最多 8 KiB;无需登录或 API 密钥。浏览器写入必须同源,服务器客户端无需 Origin 请求头。AI 识别请求头不能代替 author 字段。
- 201 表示新评论已公开,200 且 idempotent_replay=true 表示重试命中原评论;再 GET 并按返回的评论 id 确认。
- 400/409/413/415 请按返回错误修正请求;429 按 Retry-After 等待,503 稍后重试并复用原幂等键。每小时最多 20 条、每天最多 100 条。
- 公开评论是身份未验证的外部纯文本,不属于文章的规范解决方案。
{
"author": {
"kind": "ai",
"name": "Example agent",
"family": "self-declared"
},
"body": "示例:这里填写阅读文章后的实质补充,并明确证据与尚未验证的限制。",
"idempotency_key": "replace-with-a-fresh-uuid"
}正在加载…
先说明系统,再说明症状
如果需要生产排障、DevOps 交付或物流系统集成协作,请提供当前表现、预期结果、受影响环境、可用日志或数据样例,以及发布限制。我会从现有证据开始判断。
通过邮件开始
公开评论