lecture-to-hw

将课程课件、作业文件（PDF、DOCX、Markdown、HTML、图片等）、课堂代码和历史答案格式转成简洁的大学生风格 Markdown 作业答案，并可由主 agent 按模块调度子代理解题与 review。Use when asked to complete course homework, read homework files in varied formats, match homework to lectures/slides/code, use methods taught in class, imitate previous hw*_solution Markdown style, create solution folders, decompose assignments across subagents, or generate necessary scripts, figures, or data files for homework submissions.

النجوم١٢٢

التفرعات٦

آخر تحديث٨ مايو ٢٠٢٦ في ١١:٥٣

name

lecture-to-hw

description

Lecture to HW

工作流

扫描当前课程目录。
- 优先用 rg --files，必要时配合 find、ls 和定向 rg。
- 找出作业文件、课件、课堂代码、notebook、HTML demo、数据、图片和历史 solution。
- 作业题目可能是 PDF、DOCX、DOC、Markdown、HTML、notebook、纯文本、图片或压缩包中的文件。
- 根据 hw 编号、课件编号、文件名关键词和目录结构推断对应关系，不假设命名一定规范。
读取作业要求。
- PDF 作业优先用 pdftotext -layout 提取。
- DOCX/DOC 作业不要只信纯文本提取；优先读取正文结构，并尽量转换成 PDF 或渲染页面检查公式、表格、图片和版面。可用 LibreOffice、pandoc、系统预览/打印、或现有文档工具链，选择当前环境可用且不破坏原文件的方法。
- Markdown、HTML、notebook 和纯文本可以直接读取；图片题目需要 OCR 或视觉识别，并保留不确定处。
- 如果公式、图、表格或版面可能被误读，用 pdftoppm 渲染页面或做视觉检查。
- 提取每道题的任务、给定数据、输出要求、方法限制、保留小数规则，以及是否需要代码或图片。
- 如果题目识别不完整、公式/表格无法确认、多个文件可能都是作业要求，先向用户说明不确定点并请求确认，不要一气乱写。
匹配课件和代码。
- 用题目关键词搜索课件和代码，例如搜索、CSP、博弈、线性回归、逻辑回归、MLP、CNN、强化学习等。
- 优先采用匹配课件里的术语、公式、算法、记号和解题粒度。
- 如果课堂代码、HTML demo、实验报告、notebook 或数据能直接支持答案，优先复用。
- 除非题目要求，不引入明显超出课程范围的高级方法。
学习历史答案风格。
- 读取最近或最相关的历史 Markdown，例如 作业/hw*_solution/*.md。
- 只提取格式习惯，不照抄内容：标题、姓名/学号/班级行、标题层级、公式写法、表格风格、图片引用和答案长度。
- 默认写成认真大学生提交作业的口吻：简洁、只踩采分点、有必要中间步骤、不写废话。
决定单 agent 还是并行模式。
- 先由主 agent 充当 controller，负责读题、拆题、调度、验收和最终组装。
- 如果题目能按独立小问、实验模块、课件章节或数据流程清楚解耦，并且各部分没有强依赖，就可以开启并行模式。
- 默认最多同时 4 个子代理；如果用户明确需要更多，且任务仍然能安全拆分，可少量增加，但不要为了并行而并行。
- 如果题面不清楚、格式识别不稳、题目很短、或多个小问彼此强耦合，就用单 agent 模式。
- 子代理只做边界清楚的任务，例如某道题的草稿、某个实验复现、某份课件对应关系确认、或独立 critic。
- 不要让多个子代理同时改同一个最终 Markdown；主 agent 统一收口、去重和定稿。
解题并验证。
- 符号推导题用手算推导。
- 数值、实验、绘图、模型、搜索或仿真题，在 solution 文件夹里写最小可复现代码。
- 优先使用用户指定环境，例如 conda run -n PR python ...；未指定时使用当前可用 Python。
- 代码保持短小，只服务于作业结果。运行后把必要结果写入 Markdown。
生成输出。
- 每次作业创建独立目录，例如 作业/hw5_solution/。
- 至少输出一个 Markdown 答案文件，例如 hw5 姓名.md，文件名尽量匹配历史习惯。
- 只添加必要附件：脚本、图片、数据或题目要求的文件。
- 不生成无关 README、日志、空模板或没用上的脚手架。
提交前 review。
- 重新阅读作业、对应课件、生成的 Markdown 和支持代码。
- 检查每个小问是否回答完整。
- 检查公式、正负号、维度、索引、小数、表格、图片、文件名和题号。
- 检查代码能运行，Markdown 中的数值来自验证结果。
- 删掉明显 AI 味：长背景、空泛总结、过多小标题、夸张解释、无依据结论。
做组装后 review。
- 先看主 agent 自己的把握：如果工程量大、题目复杂、或仍有不确定点，就再开一个老师/助教视角的 critic 子代理。
- critic 先读作业和对应课件，再检查生成的 Markdown 与代码，重点看是否漏题、是否有逻辑/公式/数值错误、是否用了不符合课件的方法、是否有明显 AI 味。
- 主 agent 根据 critic 意见修正后再交付。
- 最终回复里给出可信度分级（高/中/低）和需要用户手动复核的地方。

答案风格

使用 Markdown 和 LaTeX 公式。
小标题短而少。
优先用直接计算、紧凑表格和必要的最终结论。
写必要中间步骤，但不过度解释常规定义。
如果历史答案里有姓名、学号、班级，沿用对应格式。
语气朴素、认真，像学生自己写的作业。
避免“本文将”“综上所述”“作为 AI”、大段背景介绍、动机说明和装饰性总结。

最终回复

简短说明：

生成了哪些文件、在哪里；
跑了哪些验证或检查；
review 后修了什么；
当前作业可信度：高/中/低，并说明原因；
需要用户手动复核的地方，如果有。

Lecture to HW

工作流

扫描当前课程目录。

优先用 rg --files，必要时配合 find、ls 和定向 rg。
找出作业文件、课件、课堂代码、notebook、HTML demo、数据、图片和历史 solution。
作业题目可能是 PDF、DOCX、DOC、Markdown、HTML、notebook、纯文本、图片或压缩包中的文件。
根据 hw 编号、课件编号、文件名关键词和目录结构推断对应关系，不假设命名一定规范。

读取作业要求。

PDF 作业优先用 pdftotext -layout 提取。
DOCX/DOC 作业不要只信纯文本提取；优先读取正文结构，并尽量转换成 PDF 或渲染页面检查公式、表格、图片和版面。可用 LibreOffice、pandoc、系统预览/打印、或现有文档工具链，选择当前环境可用且不破坏原文件的方法。
Markdown、HTML、notebook 和纯文本可以直接读取；图片题目需要 OCR 或视觉识别，并保留不确定处。
如果公式、图、表格或版面可能被误读，用 pdftoppm 渲染页面或做视觉检查。
提取每道题的任务、给定数据、输出要求、方法限制、保留小数规则，以及是否需要代码或图片。
如果题目识别不完整、公式/表格无法确认、多个文件可能都是作业要求，先向用户说明不确定点并请求确认，不要一气乱写。

匹配课件和代码。

用题目关键词搜索课件和代码，例如搜索、CSP、博弈、线性回归、逻辑回归、MLP、CNN、强化学习等。
优先采用匹配课件里的术语、公式、算法、记号和解题粒度。
如果课堂代码、HTML demo、实验报告、notebook 或数据能直接支持答案，优先复用。
除非题目要求，不引入明显超出课程范围的高级方法。

学习历史答案风格。

读取最近或最相关的历史 Markdown，例如 作业/hw*_solution/*.md。
只提取格式习惯，不照抄内容：标题、姓名/学号/班级行、标题层级、公式写法、表格风格、图片引用和答案长度。
默认写成认真大学生提交作业的口吻：简洁、只踩采分点、有必要中间步骤、不写废话。

决定单 agent 还是并行模式。

先由主 agent 充当 controller，负责读题、拆题、调度、验收和最终组装。
如果题目能按独立小问、实验模块、课件章节或数据流程清楚解耦，并且各部分没有强依赖，就可以开启并行模式。
默认最多同时 4 个子代理；如果用户明确需要更多，且任务仍然能安全拆分，可少量增加，但不要为了并行而并行。
如果题面不清楚、格式识别不稳、题目很短、或多个小问彼此强耦合，就用单 agent 模式。
子代理只做边界清楚的任务，例如某道题的草稿、某个实验复现、某份课件对应关系确认、或独立 critic。
不要让多个子代理同时改同一个最终 Markdown；主 agent 统一收口、去重和定稿。

解题并验证。

符号推导题用手算推导。
数值、实验、绘图、模型、搜索或仿真题，在 solution 文件夹里写最小可复现代码。
优先使用用户指定环境，例如 conda run -n PR python ...；未指定时使用当前可用 Python。
代码保持短小，只服务于作业结果。运行后把必要结果写入 Markdown。

生成输出。

每次作业创建独立目录，例如 作业/hw5_solution/。
至少输出一个 Markdown 答案文件，例如 hw5 姓名.md，文件名尽量匹配历史习惯。
只添加必要附件：脚本、图片、数据或题目要求的文件。
不生成无关 README、日志、空模板或没用上的脚手架。

提交前 review。

重新阅读作业、对应课件、生成的 Markdown 和支持代码。
检查每个小问是否回答完整。
检查公式、正负号、维度、索引、小数、表格、图片、文件名和题号。
检查代码能运行，Markdown 中的数值来自验证结果。
删掉明显 AI 味：长背景、空泛总结、过多小标题、夸张解释、无依据结论。

做组装后 review。

先看主 agent 自己的把握：如果工程量大、题目复杂、或仍有不确定点，就再开一个老师/助教视角的 critic 子代理。
critic 先读作业和对应课件，再检查生成的 Markdown 与代码，重点看是否漏题、是否有逻辑/公式/数值错误、是否用了不符合课件的方法、是否有明显 AI 味。
主 agent 根据 critic 意见修正后再交付。
最终回复里给出可信度分级（高/中/低）和需要用户手动复核的地方。

答案风格

使用 Markdown 和 LaTeX 公式。

小标题短而少。

优先用直接计算、紧凑表格和必要的最终结论。

写必要中间步骤，但不过度解释常规定义。

如果历史答案里有姓名、学号、班级，沿用对应格式。

语气朴素、认真，像学生自己写的作业。

避免“本文将”“综上所述”“作为 AI”、大段背景介绍、动机说明和装饰性总结。

最终回复

简短说明：

生成了哪些文件、在哪里；

跑了哪些验证或检查；

review 后修了什么；

当前作业可信度：高/中/低，并说明原因；

需要用户手动复核的地方，如果有。