name: math-progress-monitor description: 解题过程中的元认知检查——检测何时调整或坚持
数学进度监控
何时使用
触发短语如：
- “我是不是走对路了”
- “这个方法有效吗”
- “我卡住了”
- “我应该尝试其他方法吗”
- “验证我的进度”
- “检查我的推理”
- “这变得太复杂了吗”
在工作过程中使用，以评估是否应该继续、调整或分解策略（Schoenfeld的元认知控制）。
过程
运行结构化的进度评估：
1. 清单尝试
问： “到目前为止你尝试了什么？”
- 列出每种方法
- 按尝试时间排序
- 记录花费时间
2. 提取学习
问： “每次尝试告诉了你什么？”
- 即使是失败也提供了信息
- 排除了什么？
- 出现了什么模式？
3. 复杂度检查
问： “复杂度增长得比预期快吗？”
- 警告标志：
- 比开始时更多项
- 出现新变量
- 计算变得越来越乱
- 正常：复杂度保持平稳或减少
4. 抽查验证
问： “你能验证任何中间结果吗？”
- 运行数值例子
- 检查极限情况
- 维度分析
5. 分解检查
问： “有没有更简单的子问题可以先解决？”
- 识别依赖关系
- 找到垫脚石
- 缩小范围
6. 沉没成本评估
问： “放弃这种方法会带来什么代价？”
- 已经花费的时间（不相关）
- 可以转移的见解（相关）
- 如果继续成功的概率
要问的关键问题
- 你尝试了什么？（清单）
- 你学到了什么？（提取）
- 是变得更简单还是更困难？（复杂度）
- 你能检查一部分吗？（验证）
- 最小的步骤是什么？（分解）
- 你应该调整吗？（决定）
输出格式
进度评估：
状态：[正轨 / 遇到阻力 / 应该调整]
尝试摘要：
1. [方法] -> [结果/学习]
2. [方法] -> [结果/学习]
复杂度检查：
- 预期：[应该看起来像什么]
- 实际：[它实际上看起来像什么]
- 裁决：[正常 / 警告 / 放弃]
验证点：
- [要检查的中间结果]
- [数值测试案例]
推荐：
[继续 / 修改方法 / 切换策略 / 分解 / 获取更多信息]
如果调整：
- 替代方案：[具体的新方法]
- 为什么它可能有效：[推理]
示例互动
用户：我一直在尝试评估这个积分一小时了
Claude：让我们做一个进度检查。
Q1：你尝试了什么？
> 使用 u 替换，u = sin(x)，然后两次积分 by parts。
Q2：每次告诉了你什么？
> 替换让问题变长。分部创建了一个循环。
Q3：现在的复杂度与开始相比？
> 更糟了。开始时有 3 项，现在有 8 项。
复杂度检查：
- 预期：应该简化或保持相似
- 实际：3 项 -> 8 项，经过两种技术
- 裁决：警告 - 可能错误的方法
让我验证一个中间步骤...
[在原始积分上运行 sympy]
这个积分有闭合形式，使用：
- Beta 函数（特殊函数）
- 或围线积分
推荐：调整
你的代数方法无法简化这个模式。
替代方法：
1. 识别：sin^m(x) * cos^n(x) 的积分
2. 使用 Beta 函数恒等式
3. 或转换为复数指数
相关技能：
- complex-analysis/contour-integrals
- numerical-methods/numerical-integration
你想要 Beta 函数方法，还是先获取数值答案来验证？
协同激活
当用户卡住时，建议：
- math-intuition-builder - 重置理解
- math-model-selector - 如果框架错了
- math-mode - 用于验证计算
- Relevant domain skill - 用于替代方法