编程学习的数据与指标准备用编程助手学习时很容易把“答案跑通了”当成“已经掌握”。如果题目来源、测试条件和评价方式都不固定今天生成的代码看起来比昨天好可能只是题目更熟、提示更详细或者测试漏掉了边界情况。我的做法是先做一组自己能独立核对的小题。题目不追求数量先覆盖正在学习的知识点例如日期解析、空集合处理、错误传播、所有权转换和简单异步控制。每题都写清输入、预期结果和禁止事项不从公司仓库、聊天记录或付费题库里复制材料。case: empty_list expect: Ok([]) forbid: network access这段描述比一句“处理空列表”更有用。它说明返回值是什么也排除了通过网络查询答案的做法。若题目涉及文件还要指定临时目录和允许访问的范围涉及时间则固定时区或注入时钟。只有输入条件稳定失败结果才有比较价值。题集按错误类型组织我不会只收集顺利通过的例子。解析失败、缺少字段、无效 UTF-8、取消任务和依赖超时都可以成为学习材料。每当自己在真实练习中犯过一次错误就把能够公开的最小复现加入题集并写一句为什么会错。这样题集记录的是认知盲点而不是一份为了提高通过率而挑选的简单题单。同一道题可以保留基础版本和扩展版本。基础版本只检查正确性扩展版本再加入错误处理、资源释放或复杂度约束。版本之间的差别要明确避免工具因为看过旧答案而显得突然进步。若题目已经放进提示词示例就不再把它作为独立评测样本。指标要能帮助调整学习方式我先看三个结果代码能否编译测试能否通过人工审阅后是否愿意保留。编译失败能暴露语法和依赖问题测试失败说明行为不符合约定审阅则关注命名、错误边界和是否真正理解。三项不能互相替代尤其不能因为测试通过就跳过代码解释。工具生成的答案和手写答案必须走同一套测试。记录时区分“独立完成”“查看提示后完成”“直接采用候选代码”否则通过率会把学习过程抹平。对我来说提示次数、修复耗时和能否解释关键语句比单纯累计完成题数更能反映下一步该练什么。复查一次通过背后的原因评测后我会抽看通过的代码尝试删除一行保护逻辑、替换一个边界输入确认测试确实能抓到问题。还会要求自己说明为什么选择这个数据结构、错误会沿哪条路径返回。如果只能复述生成结果却无法预测改动后的行为这道题就仍算需要复习。这套题集很小也带有明显的个人偏好所以只用于跟踪自己的学习不拿它做模型或产品排名。每次记录都附上语言版本、依赖和题目版本条件变了就重新建立基线。目标不是得到一个好看的分数而是让下一轮练习能准确落在还没掌握的地方。