"我要学完 Spring Boot""这个月把算法补上""读完这三本书"——这类目标的问题不在不够努力，而在不可验证。学没学完由谁说？读到第几章算数？没人能回答，于是进度只能靠感觉，感觉好的时候以为在进步，感觉差的时候直接放弃。
可验证的目标不是把目标定小，而是给它装上验收。这篇给四要素、三层目标、三种验收方式、反馈来源与复盘格式，以及连续失败时该怎么调。
1. 为什么"学完了"不可验证
不可验证的目标有三个共同特征，任何一个出现，这个目标就无法驱动行为。
| 目标写法 | 缺什么 | 结果 |
|---|---|---|
| "学完 XX 技术" | 没有可观察的输出 | 永远处于"还在学" |
| "深入掌握 XX" | 没有判定标准 | 无法判断是否达标 |
| "多花时间在 XX 上" | 没有时间窗与产出 | 时长变成唯一指标，与能力无关 |
| "看懂 XX 源码" | 没有验收动作 | 看懂与否只由自己声称 |
判别方法一句话：把目标念给一个不了解你的人听，他能判断你做没做到吗？ 不能判断，就是不可验证。
2. 可验证目标的四要素
四要素缺一不可，缺哪个就会在某个环节退化。
| 要素 | 要回答的问题 | 反例 | 正例 |
|---|---|---|---|
| 可观察的输出 | 做完之后别人能看到什么 | 理解了依赖注入 | 写出一个三种作用域的示例仓库，附 README |
| 时间窗 | 什么时候要看到 | 有空就学 | 两周内的周末两天 |
| 判定标准 | 怎么算做到，怎么算没做到 | 掌握得差不多 | 能不看文档讲清作用域失效的两种场景 |
| 失败后的下一步 | 没做到做什么 | （没想过） | 拆成"只做前两个作用域"再试一轮 |
四要素的书写模板，一次写好一个目标，不超过五行：
【输出】我将在 ______ 产出 ______（可被他人在十分钟内验证）
【时间窗】截止 ______，单次投入 ______
【判定】通过条件：______；不通过条件：______
【失败分支】若未通过，下一轮改为 ______（缩小范围/换验收方式）
【记录位置】结果写在 ______，便于下轮对照
注意"不通过条件"这一栏。只写通过条件的目标容易被自我解释通过，写上不通过条件才能逼出诚实的判定。
3. 三层目标：今天、两周、三个月
能力增长发生在不同时间尺度上，用一个尺度描述会失真。三层同时存在，各管各的。
| 层级 | 时间窗 | 粒度 | 验收方式 | 典型写法 |
|---|---|---|---|---|
| 今天 | 1–3 小时 | 一个动作 | 做出来 | "今天把连接池参数改一遍，观察指标变化并记一行结论" |
| 两周 | 10–20 小时 | 一个小产出 | 做出来 + 写出来 | "两周内写出一个可跑的压测脚本，并写清参数含义" |
| 三个月 | 60–120 小时 | 一个能交付的东西 | 讲出来 + 他人使用 | "三个月内给团队做一次分享，并让一个人照做成功" |
三层之间的关系是下层的产出构成上层的素材。今天的三行结论，两周后拼成一节文章，三个月后成为分享里的一页。反过来，只有三个月目标没有今天动作，目标会一直悬着。
同一个技能的三层写法示例（以"看懂线程池"为例）：
今天 ：把核心线程数从 4 改成 8，观察队列堆积变化，记三行结论
两周 ：写出一个最小线程池示例，覆盖"队列满 + 拒绝策略"两种分支，
并能说清每种拒绝策略的代价
三个月：在团队内讲一次"线程池参数怎么定"，讲完有同事按这套方法改对了配置
4. 验收方式：做出来、讲出来、写出来
同一个人对同一个知识，三种验收的严格程度完全不同，选错验收方式会得到虚假的通过。
| 验收方式 | 门槛 | 能暴露什么 | 适用于 |
|---|---|---|---|
| 做出来 | 低 | 会不会用 | 工具、命令、API、配置 |
| 写出来 | 中 | 有没有结构、有没有边界 | 方法、设计、选型取舍 |
| 讲出来 | 高 | 有没有真懂（会被追问） | 原理、因果链、复杂系统 |
严格程度递增，成本也递增。建议顺序：先做出来，再写出来，最后讲出来。 直接跳到"讲出来"，容易在准备阶段就卡住；只停在"做出来"，则可能一直会照着抄而不知所以然。
三种验收的最小标准：
[做出来] 有一个能重复跑通的步骤序列，换一台机器也能跑
[写出来] 有边界段：什么情况下这个方法不适用
[讲出来] 被追问两层仍能回答，回答里不出现"大概""应该是"
5. 反馈来源：别只靠自己
自我评估是最不可靠的反馈来源，因为判断标准掌握在被评估者手里。至少接一个外部反馈。
| 来源 | 强度 | 成本 | 能纠正什么 |
|---|---|---|---|
| 自测题 | 弱 | 低 | 记忆漏洞 |
| 代码评审 / 作品被使用 | 强 | 中 | 假设错误、边界遗漏 |
| 真实任务（有后果） | 最强 | 高 | 全面，但代价真实 |
| 他人提问 | 强 | 低 | 表达不清、理解断层 |
低成本高收益的是最后一条：把学到的东西讲给一个会提问的人，他的第一个"为什么"就能定位你的断层。 没有听众时，用自测题代替，但要按"能不能自己回答"来判，不按"看着眼熟"来判。
6. 记录与复盘的最小格式
复盘不需要长篇。三行就能支撑下一轮决策，超过三行就会懒得写。
[日期] 做了什么：______
[卡点] 卡在：______（具体到某一步、某个概念）
[下次] 改：______（换方法 / 缩范围 / 补前提）
| 字段 | 常见写法错误 | 正确写法 |
|---|---|---|
| 做了什么 | "学习 Spring" | "跑通了三种作用域的示例，第三种失败两次" |
| 卡在哪 | "不太懂" | "搞不清 prototype 在单例里为什么还是同一个实例" |
| 下次改什么 | "再多看看" | "下次先画对象生命周期图，再改代码" |
复盘的价值全在第三行。只记前两行，你会重复踩同一个坑；只有把"改什么"写具体，下一轮才真的不同。
7. 连续失败时先降粒度
连续两三次没完成，多数人的反应是加把劲，正确的反应是拆小。
| 失败次数 | 诊断 | 动作 |
|---|---|---|
| 1 次 | 偶然，环境或状态问题 | 不调整，直接重试 |
| 2 次 | 粒度可能偏大 | 把两周目标拆成两次"今天"级动作 |
| 3 次以上 | 目标设定有问题，不是执行力问题 | 换验收方式，或把范围砍到三分之一重开 |
降粒度的具体做法，按优先级试：
1. 缩范围：从"三种作用域"缩到"只做 singleton vs prototype"
2. 换验收：从"写出来"降到"做出来"，先跑通再总结
3. 缩短时间窗：从两周改成三天，逼出可见产出
4. 换切入角度：从读文档改为先写一个故意报错的例子
5. 换反馈源：自己判断不准，找一个会提问的人
注意：降粒度不是降低标准，是让标准在更短时间内可判定。 判定标准可以不变，范围变小即可。
8. 常见坑
| 现象 | 原因 | 处理 |
|---|---|---|
| 目标写成"学习 XX 技术" | 没有输出与判定标准 | 用四要素模板重写一行 |
| 只投入不产出 | 用输入量替代产出量 | 每个两周目标必须有一个能被别人看到的产物 |
| 把读书时长当进度 | 时长与能力无因果 | 改为记录"能回答的问题数"或"能跑通的示例数" |
| 目标一直不验收 | 没有时间窗，也没有判定标准 | 每两周固定一次验收，写在日程里 |
| 验收方式过软 | 只做出来就宣布学会 | 加一次"写出来"或一次对外讲解 |
| 失败就放弃 | 没有失败分支 | 四要素里预先写好"未通过则改为……" |
| 复盘只写感受 | 缺"下次改什么" | 强制写第三行，且必须具体到动作 |
| 目标太多同时并行 | 注意力分散，全部变成长期挂起 | 同层级最多两个，多出的排队 |
9. 边界：什么情况不该用这套
| 场景 | 更合适的做法 | 理由 |
|---|---|---|
| 探索性、还不知道要什么 | 先定投入时长，不定产出 | 过早定验收会锁死方向 |
| 长期基础能力（如英语阅读） | 用习惯型目标，配低强度日验收 | 与项目型目标节奏不同 |
| 情绪状态差、身体疲惫 | 先恢复，目标降级到"最低维持" | 此时加码只会中断 |
| 与他人协作的学习 | 以协作产出为验收 | 个人口径的验收无法衡量协作 |
| 已有大量同类经验 | 直接接真实任务 | 中间层目标纯属浪费 |
一句话选择：目标是给自己装上验收，不是给自己施压。判定不了的目标改到能判定，做不到的目标改到能做完。
10. 自测
- 用什么方法能快速判断一个学习目标是否可验证？
- 四要素里哪一项最常被漏掉，漏掉的后果是什么？
- 三层目标之间是什么关系，只有最上面一层会发生什么？
- 三种验收方式的门槛与暴露的问题有什么不同？
- 复盘格式的三行里，哪一行决定下一轮是否真的不同？
- 连续三次没完成时，第一件该做的事是什么？