上一期《班主任如何用 AI 搭建个人工作台》发出去以后，留言区有读者提了一个很具体的需求。

培训机构里，一个老师一天从早到晚四到五节课，每节课后的反馈参差不齐，有时候只能发一段语音，显得不专业；大班课顾不过来每一个学生，只能笼统地说个大概。

那条留言最后问：能不能做一个工具，把语音转成文字，再整理成每个孩子的个性化反馈，最后生成排版规整的报告。

 

读者在上一期文章留言区提出的真实需求

这条留言指出的难点不在评价能力上。老师对每个孩子都有印象，甚至每节课都会打分。卡住的地方是，这些印象没有在产生的那一刻被固定下来。

等到家长问「孩子最近到底怎么样」，老师手上只有分数，和散落在课堂记录、作业登记、一次次谈话里的碎片。

这篇文章完整拆解三件事：怎么把这类需求收敛成一个本机运行的学情工作台；语音转写这条链路怎么接，以及它在整条链路里为什么只是一个可替换的环节；跑通以后，怎么把版式、评分规则和操作流程固化成团队能复用的 Skill。

读完你可以带走一条可复现的技术路线，以及三个必须提前想清楚的边界：外部接口的免费额度够不够这个场景用、录音文件识别对公网音频地址的要求，以及哪些判断必须留在老师手里。

为什么一个分数讲不清一个孩子

同样是 80 分，背后可能是三种完全不同的情况。

一种是课上听懂了，课下作业没及时订正；一种是作业完成得不错，但每次测试都在同一类题上出错；还有一种是答案都知道，只是不愿意开口表达。

这三种情况需要的下一步安排完全不一样：补订正习惯、练同类题型、做表达训练。分数记录的是结果，没有记录过程，也没有留下下一步该做什么。

这些信息老师平时都接触过，只是它们散在课堂记录、作业登记和面谈里。等到要做阶段反馈，还得再翻一遍、想一遍、整理一遍。

真正的成本发生在把已经发生的观察重新捡起来这一步。

工作台的定位就是把这个动作前移到每节课之后：名单建好、档案立好、面谈结束就把重点存进去，报告只是这些记录的一次汇总输出。

 

把课堂、作业和面谈中的观察固定为学生档案

先看这次做出来的效果：

 

学情工作台总览与报告生成效果

 

学情工作台报告与历史版本效果

第一步：需求分析，把六件事写清楚再动手

需求阶段先不要提「给我做一个系统」。先把老师每天真正在做的事理顺。

这次的需求收敛成六件事：

1. 上传学生名单，为每个学生建立档案；
2. 持续记录课堂表现、课堂测试和课下作业；
3. 面谈时录音，或者上传已经录好的音频，并把音频保存在本地；
4. 调用语音转写接口把录音变成文字，再整理出重点；
5. 根据记录提出评分建议，由老师补充、修改和确认；
6. 为每个学生生成 PDF 报告，并保留历史版本。

 

学情工作台的六件事：评分建议由老师确认

第 5 条是整条链路里最容易被写歪的地方。评分建议必须能追回到记录，否则报告只是把套话换了个位置。所以「结合老师的背景给评价」这句话里，背景要写具体。

在提示词里补上一段老师的背景：教什么学科或培训什么内容、面向哪个年级和群体、这段时间的课程目标、评分标准、平时习惯怎么给家长反馈。可以给一个例子，让模型照着这个口径写。

这些内容决定评价标准和表达方式。孩子的具体表现仍然要来自实际记录，背景信息替代不了证据。

再定一个专门的项目文件夹，比如：

D:\教学工具\学情工作台

程序、录音、数据和报告都放在这个目录下，查找和备份都在一个地方。

这次和上一期做交互式 HTML 课件有一处关键差别：工作台要录音、要保存文件、还要调外部接口。界面仍然在浏览器里打开，但它背后需要一个本地服务。浏览器负责展示和交互，本地服务负责把录音和数据写进磁盘、再去调语音接口。数据默认存在项目目录的 data/ 目录下。

语音转写怎么接：先定标准，再挑服务

把语音转写当一个问题来解，它首先是选型问题，不是安装问题。

先看四条：

• 是否支持中文长音频；
• 提交音频时是否需要音频有公网可访问的地址，这一条直接决定要不要额外买对象存储；
• 免费额度够不够这个场景用，超了怎么算；
• 录音属于学生个人信息，数据存在哪里、谁能访问。

国内常见的就是腾讯、阿里、火山这几家。这次用的是腾讯云语音识别，原因是账户里已经有现成资源，接起来最快。换成另一家，改的只是配置层，后面所有步骤都不用动。

这四条标准比最后选了哪一家更值得记住。

开通这块，把动作压到最少就是三步：开通语音识别服务、创建子用户、取 API 密钥。控制台每一步都有提示，照着点下去就行，只有两个地方容易踩。

一是额度。本文走的是录音文件识别，这个账户免费额度 10 小时/月。按一次面谈十分钟算，够六十次，月度面谈用不完；如果打算每节课都录，一天四五节就会超。用超了才按量扣费，想彻底不产生费用，就在控制台把后付费关掉，额度用尽即停服。

 

确定使用界面：免费额度与欠费提示

二是创建密钥时选子用户，不要用主账号密钥。子用户的密钥权限有限，但它等同于调用额度，仍然不能外泄：放在本机配置文件里，或者本地服务的后端配置里，不要贴进公开内容，也不要提交到代码仓库。

 

创建密钥时选择子用户，密钥入口在子用户详情页

最后说一句以后。纳米 Work 这边有一个录音卡产品，计划本月底上线，录音和转写这类动作会收进产品内部，像总结会议这种需要大量录音转写的场景，能在纳米 Work 里直接跑完，不用再单独配一家云服务。这套接法到时候就变成替补方案：换机器、离线环境，或者机构本来就有云资源，仍然可以用它。

这里顺便区分一件事。把面谈、会议的材料存进一个地方、需要的时候再调取，和把实时转写直接接进工作台的档案结构，是两条不同的路。这篇做的是后者——录音一结束，文本就落到具体学生的档案里，评分建议才有依据可追。

产品还没上线，具体能力以官方发布为准。

在纳米 Work 里选入口

在纳米 Work 里选择适合开发网页应用的入口。这次先用「个人工作台」这个技能，把要用到的工具提前配好；任务模式选「边想边做」；模型选 DeepSeek-V4-Flash。

 

选择个人工作台技能、边想边做模式与 DeepSeek-V4-Flash

三个任务模式的差别在于检查点放在哪：「边想边做」不设中间检查点；「先规划，再执行」把检查点放在动手前；「盯住目标做到底」只在最终交付时确认，后两个会消耗更多 Token。这次的任务链路不算长，也没有不能返工的动作，先用「边想边做」推进。

 

三种任务模式的说明与 Token 消耗提示

 

三种任务模式的检查点位置

第一次把下面这段需求复制进去：

项目路径：D:\教学工具\学情工作台我想给培训机构老师做一个本地使用的学情工作台，默认单教师使用，示例课程是小学英语。需求：1. 上传 CSV 或 Excel 学生名单，包含学生编号、姓名、班级、年级、课程。同名学生用编号区分，重复导入不重复建档。2. 每名学生有独立档案，能按日期记录课堂表现、测试原始分与满分、作业完成次数和质量描述。3. 选择学生后能录音或上传音频，本地保存并回听；录音结束后调用语音 API 转写，再整理面谈重点。4. 结合教师配置的学科、学段、课程目标和评分量表给出有依据的评分建议；缺失分数留空，由老师补充确认。5. 面谈是否完成、报告是否待补充或待审核分别显示。6. 老师确认后，为每名学生生成可查看和下载的 PDF 学情报告，保留历史版本。7. 页面清楚易用，浅色背景，适配笔记本屏幕。给我 3 个风格方向选择。8. 数据和录音持久保存在本地。请先检查当前环境是否支持完整实现，先和我对齐需求，再分阶段开发：先用虚构数据和手动面谈文本跑通，再接真实录音 API。

 

在输入框里粘贴项目路径与第一段需求

第二步：需求对齐，把开放问题收成明确口径

提交之后先看它对任务的理解，不用急着让它一次做完。这一步重点确认四件事。

① 教什么课，面对什么年龄的孩子？

小学英语和美术培训关注的表现不一样。写清楚学科和学段，评价才不会落到「学习认真，继续努力」这类套话上。

② 这份报告覆盖什么时间？

一次面谈、本周记录和一个月的表现是完全不同的范围。这次按月生成，报告里写明时间范围。

③ 分数从哪里来？

课堂表现按老师设定的量表；测试保留原始分和满分；作业记录完成次数，质量另外写。第一版先把三个维度讲清楚，不急着揉成一个总分。

④ 报告最后给谁看？

这次只做老师管理和导出 PDF，由老师把文件发给学生或家长。学生登录、家长端、自动推送这些功能留到后面。

需求对齐会以选择题的形式把开放问题收住，末尾留了「其它」，用来补选项里没有的内容：

 

需求对齐以单选卡片的形式确认口径

口径越具体，后面抠细节越省事。

第三步：先用浏览器跑通，再接入语音 API

纳米 Work 会先给三个页面方向：

• A 教研档案室：暖白纸感底色 + 墨蓝主色 + 衬线标题，信息密度高，像老师的纸质教案夹；
• B 清爽数据台：浅灰蓝底 + 靛蓝主色，大卡片、进度条和环形图，看数据最快；
• C 校园手账：浅米底 + 薄荷绿和珊瑚橙点缀，圆角柔和，适合小学低龄段。

 

三个风格方向对比，选定后再补细节要求

选定方向后再提页面模块的修改意见。先把功能跑通，UI 优化放到后面，否则页面改得越精细，功能改动带来的返工越贵。

得到的第一版工作台，左边是目录栏，右边是内容区：

 

第一版学情工作台：左侧目录栏与内容区

拿一份虚构名单先验收几个动作：名单能不能导入、点学生能不能进档案、记录保存后刷新还在不在、报告能不能打开。

 

导入学生名单：支持 CSV 或 Excel，表头包含学生编号、姓名、班级、年级、课程

 

导入后在档案列表核对信息

再核对学生档案、学生详情、课堂表现这些模块：

 

学生档案到课堂表现的完整操作

基础流程跑通以后再接语音。这里有两件事容易混在一起：语音转写是把录音变成文字；内容整理是从文字和课堂记录里提取重点，形成总结和评分建议。它们可以由同一家服务商提供，也可能来自不同接口，按你实际选的接口配置。另外，不要因为 Agent 说「接口已接入」就默认成功了，自己录一段检查一下。

复制这段继续做：

现在接入真实录音和语音转写，采用录音停止后提交识别的方式。请根据我选择的语音及文本服务商的官方文档接入，不编造 API 地址、模型名或返回结果。缺配置时告诉我在本机哪里填写，不要让我把密钥贴到公开内容里。要求：选择学生→开始录音→停止→先把音频保存本地并确认成功→提交转写→老师校对→生成总结和评分建议。支持回听和上传已有音频。转写失败保留录音，可重试或手动输入。原始转写和修改后的文本分别保存。无法可靠区分说话人时提示老师核实。请用真实测试录音验证，不用模拟文字冒充识别成功。告诉我本地音频保存位置和当前还未实现的部分。

第一次提交以后，录音保存在本地这一步能做，转写没有跑通。报错指向的不是密钥，而是授权：语音识别服务没开通，或者子账号缺 ASR 权限。

排查一次就清楚了：用主账号登录控制台，进入「访问管理 CAM」→ 左侧「用户」→「用户列表」，找到对应的子账号，在「更多」里点「授权」，勾上 QcloudASRFullAccess（语音识别）和 QcloudOCRFullAccess（文字识别），确定后立即生效，不需要重启服务。

 

子账号授权后重新验证转写

这条链路底层走的是什么

授权修好，只解决了「能不能调」。紧接着会遇到第二个卡点：录音文件识别要求音频有一个公网可访问的地址，本地保存的录音文件不能直接提交。这一步需要额外的存储配置。

决定能不能稳定复现的，是接口形态本身，不是选了哪一家服务商。

录音文件识别是异步任务。音频先上传到对象存储（这次用的是腾讯云 COS），拿到一个公网可访问的地址，再提交识别任务（CreateRecTask），然后轮询任务状态，最后把返回结果格式化成文本。这条路线需要额外的存储桶，音频地址也必须能被公网访问。

一句话识别是同步接口，不需要对象存储，但只适合 60 秒以内的短音频。

面谈录音通常几分钟到十几分钟，走的是第一条路线。

真正的难点不在调用，而在把一次调用接进一个能持续用的工作台。三个地方必须自己兜住。

第一，本地服务不能省。 浏览器页面拿不到写盘权限，存不住密钥，也没法替你盯着一个可能跑几十秒的异步任务。录音落盘、任务提交和状态查询都要放在本机服务里，页面只负责展示和交互。这就是为什么这类工作台做不成一个单文件 HTML。

第二，失败态要提前设计。 异步任务意味着中途失败是常态：网络断了、额度用尽、音频格式不对，都会走到一半停下。转写失败不能丢录音——音频保留在本地，可以重试，也可以直接手动输入重点。原始转写和老师修改后的文本要分开保存，校对留痕，后面出争议时有据可查。

第三，不确定的地方交回给人。 面谈里如果有第三方在场，转写文本不能直接当成学生本人说的话。说话人分不清的时候，提示老师核实。

把这三件事做完，才能说这条链路真正跑通了。

 

语音转写链路的工程结构：页面、本机服务、对象存储、识别任务与学生档案

这里的验收标准不是界面显示「识别成功」，而是播放录音能对上文字。

 

录音保存、转写失败处理与老师校对确认

第四步：细节打磨，把「有报告」调成「报告能用」

第一版看着完整，沿着真实操作走一遍就会发现缺口。这次补了两处。

一是成绩和学习单元原本要老师手动录入，改成上传表格后自动识别学生成绩和学习内容；二是多次面谈的重点散在几条记录里，补上「一键整理多次对话，给出具体结论」。直接在对话框里说清楚要改什么就行。

 

打磨阶段：成绩表格自动识别与多次对话整理

再看语音识别这条链路的实际使用：

 

录音、转写、校对、生成总结的完整操作

报告会汇总日常成绩、课堂表现和面谈内容。下面是这次生成的报告框架，示例数据是虚构的，实际使用时还要按课程和学段调整评分口径。

 

按日常成绩、课堂表现和面谈内容生成的学情报告

最后关掉再重启一次工作台，确认录音、记录和报告都还在。这个动作看着普通，它决定的是明天还能不能接着用。数据默认保存在项目目录的 data/ 目录里；如果重启后打不开，把现象直接发回对话框让它排查。

评分建议由模型给出，最终分数和结论文案由老师确认。这一条不是流程上的客气：报告要发给家长，责任在老师这边。

第五步：把满意的流程固化成 Skill

确认功能和效果以后，再把这次成果固化下来。

这里和上一期做交互式 HTML 课件有同一个前提：只说「记住这次风格」，下次复现并不稳定。页面布局、评分规则、报告模板和已经跑通的代码要一起留下来。

在当前对话里复制：

请把本次已经验证可运行的学情工作台做成可复用 skill，名称 student-learning-workbench。如果当前环境提供 skill-creator，请使用它，并按当前平台的规范创建。触发场景：当我说「制作一个学情工作台」或明确调用本 skill 时，按此流程执行。必须固化：完整可运行代码模板、页面布局、数据库结构、录音与本地保存流程、可配置 API 接入、事实和评分规则、教师确认流程、PDF 模板、启动方式及验收步骤。输入参数：项目路径、名单文件、课程和学段；教师信息、报告周期、目标和量表提供默认值，可按需修改。API 从运行环境配置读取。支持新目录创建，也支持继续使用旧项目；继续使用时保留原数据库和历史记录。技能包包含规范的 SKILL.md、模板、必要脚本、依赖说明、虚构样例和验收清单。不带真实学生资料、录音、数据库、API 密钥或个人固定路径。请在新测试目录验证复现，最后说明技能位置、调用方式，以及哪些功能需要重新配置才能使用。

这样固化的意义在于，留下来的是可复用的规则和代码，而不是一段描述。提示词只解决这一次对话，Skill 解决的是下一次换班、换学生时的启动成本。

 

可复用 Skill 的资产、配置输入和数据边界

第六步：资产复用、成本和边界

做完这一个工作台，老师平时留下的课堂观察、测试记录和面谈重点，就有了一个持续积累的地方。要跟家长反馈的时候，打开对应孩子的报告，把表现、依据和下一步安排一起讲清楚。

换一个班、换一批学生，也不用重新描述一遍需求：改名单，改课程和学段，改量表，已有的历史和数据库保留。

值不值得做，要看使用频率。一个老师只带一个班、一学期只出一次报告，把标准和流程调到位的时间可能收不回来。带多个班、每周都要跟家长沟通的机构老师，数据会一直留在自己手上，后面每一次记录都能接着用。

小结

这套流程里，AI 承担的是页面搭建、本地服务、接口调用和文字整理；老师承担的是课程目标、评分口径、评分建议的确认，以及最终发给家长的那份结论。

接口会换，产品会更新，链路结构不会变。先把标准和流程调好，后面的每一次记录都能接着用。老师那些原本会随手散掉的观察，终于有了一个不会丢的地方。

#纳米#Work#教师#AI#培训#工作台#学情#教育