no-progress-tracking

# SKILL.md - No Progress Tracking（缺少进度追踪） ## R (Reading) - 原文引用 > (README 中完全没有提到如何追踪学习进度或验证技能提升) ## I (Interpretation) - 方法论骨架 **核心问题**：App Ideas Collection 没有提供任何机制来追踪学习者的进度或验证技能是否真正提升。学习者可能完成了多个项目，但不知道自己是否真的进步了，缺乏反馈循环导致动力下降。 **反模式特征**： 1. **无法量化成长**：学习者不知道自己的技能提升了多少 2. **陷入"完成但不确定"状态**：完成了项目，但不确定是否真正掌握 3. **缺乏反馈循环**：没有明确的指标来判断是否需要继续当前层级或进入下一层级 4. **动力下降**：长期没有正向反馈导致学习动力减弱 **根本原因**：app-ideas 假设"完成项目就是进步"，但没有提供验证技能提升的机制。 ## A1 (Past Application) - 书中作者用过的案例 App Ideas Collection 的 89 个项目都没有提供任何进度追踪机制： - 没有技能评估标准 - 没有里程碑或成就系统 - 没有建议如何记录学习历程 这种缺失导致学习者可能完成了 Tier 1 的所有 35 个项目，但仍然不知道自己是否准备好进入 Tier 2。 ## A2 (Future Trigger) - 用户在什么情境下会需要这个 **适用场景**： - 用户完成多个项目但仍不知道自己是否真正进步 - 用户无法量化自己的技能成长 - 用户缺乏反馈循环导致动力下降 - 用户想知道自己是否准备好进入下一个难度层级 - 用户想建立系统的学习进度记录 **与相邻 skill 的区分**： - 与 `no-systematic-methodology` 的区别：no-progress-tracking 是**具体的反馈机制缺失**，而 no-systematic-methodology 是**整体学习框架的缺失**。前者更具体，后者更宏观。 - 与 `no-testing-guidance` 的区别：no-progress-tracking 关注**学习进度的量化**，而 no-testing-guidance 关注**代码质量的验证**。两者互补：一个确保技能提升可见，一个确保代码正确。 ## E (Execution) - 可执行步骤 1. **识别反模式症状** - 询问用户是否能清晰描述自己的技能成长 - 检查用户是否有记录学习历程的习惯 - 评估用户是否有明确的进步指标 - 完成标准：三项检查均已获得明确回答，并判定用户属于"无记录/无指标/无复盘"中的哪一类缺失组合 2. **建立进度追踪机制** - 为每个项目设定明确的学习目标（如"完成后应能独立完成 UI 应用"） - 记录已完成的项目和学到的技能 - 定期回顾并评估是否真正掌握了该层级的技能 - 完成标准：用户已建立至少包含"项目名/学习目标/掌握自评"三列的学习记录表，且当前所有已完成项目均已补录在案 3. **建立反馈循环** - 完成每个项目后自我评估：能否独立复现？能否解释核心逻辑？ - 寻求外部反馈：代码审查、同行评审、在线社区 - 根据反馈调整学习计划 - 完成标准：最近一个项目已完成一次含"独立复现/讲解核心逻辑/外部意见"的评估，并根据结论写出了下一步计划的调整项 4. **量化成长** - 使用技能矩阵记录掌握的技術栈 - 跟踪项目复杂度的提升（从简单计算器到全栈应用） - 记录解决问题的时间和效率提升 - 完成标准：技能矩阵中每项技术均标注了可判定的掌握等级，且能对照历史记录说出至少一处可验证的变化（如项目复杂度层级上升） ## B (Boundary) - 什么时候不适用 **不适用场景**： - 用户只是为了兴趣而练习，不追求系统性提升 - 用户已经有明确的评估标准（如学校课程、在线课程） - 用户只需要单个项目建议，不需要整体框架 **作者的盲点**： - Florin Pop 假设"完成项目就是进步"，但没有提供验证技能提升的机制 - app-ideas 缺少对学习进度、反馈循环和量化成长的任何设计 - 这种"内容优先于反馈"的思路可能导致学习者完成多个项目但仍感到迷茫，不知道自己的真实水平