会议记录这种内容有一个特点：它既包含已经形成结论的决策，也包含大量讨论过程的中间态信息。如果直接把整篇记录复制到待办清单里，清单就会变成另一份冗长文档；如果逐条手动提取，又很难保证不同人、不同会议之间的分类标准一致。DeepSeek在这一步可以充当一个稳定的转换层，把自然语言中隐含的行动项识别出来，并以固定格式返回。下面先介绍它的处理逻辑，再给出可直接落地的提示词和脚本。
一、为什么手动整理会议记录容易产生遗漏
会议记录通常在三个地方丢失有效信息。一是行动项常常隐藏在口语化表达中，例如“后面可以看看能不能把问卷发到两个班级”，这句话既包含任务，也包含不确定性，人工整理时可能直接忽略。二是责任人不明确，很多会议只是说“我们得做一下”，但并没有指明到底谁来做，等真正执行时又需要回看记录重新分配。三是时间信息分散，有的截止日期写在开头，有的写在结论附近，手工筛选很容易漏掉其中一条。
如果使用DeepSeek处理，就可以把这些判断规则写进提示词里，让模型根据上下文自动识别任务、负责人、时间点。比如同样一句“阿哲说周三前把问卷初稿发群里”，模型能够同时提取出任务“完成问卷初稿”、负责人“阿哲”和截止时间“周三前”。这种能力来自大语言模型对自然语言的理解，而不是简单的关键词匹配。更重要的是，它可以按照固定JSON结构输出，保证后续处理流程稳定。
二、设计一个可复用的会议记录转待办提示词
提示词的核心是限制输出格式，而不是泛泛地说“帮我提取待办”。如果只给一个开放指令，模型可能会输出一大段总结文字，而不是结构化的待办列表。更合适的做法是在提示词中明确字段名称、允许的取值以及处理模糊信息的方式。下面是一段完整提示词模板。
你是一名学习项目助理。请从下面的会议记录中提取所有待办事项。要求： 1. 每条任务必须有清晰的动词开头。 2. 如果能识别负责人，写入owner字段；不能识别就写“待认领”。 3. 如果能识别截止时间，写入deadline字段；不能识别就写“未明确”。 4. 优先级根据紧急程度判断，只允许high、medium、low。 5. 以JSON数组输出，每个元素包含task、owner、deadline、priority、source五个字段。
其中source字段用于保留原文依据，方便后续回溯。这种设计比只输出任务名称更实用，因为学生在执行时如果对任务有疑问，可以直接定位到会议记录中的原句。比如团队项目中，一条“待认领”任务可能需要回到原文确认为什么没有分配到人。
以一段课程项目会议记录为例，原始内容可能像下面这样，讨论里混杂着任务和背景信息。
会议记录： 我们讨论了问卷设计。阿哲说周三前把问卷初稿发群里，小敏负责找去年的问卷模板。另外老师建议加上一个开放式问题，大家觉得可以，但没有定谁改。下次开会前最好把测试版做出来。
使用上面的提示词后，DeepSeek会输出类似下面的JSON数组。可以看到，模型把“老师建议加上一个开放式问题”识别为一条待办，并且因为没有明确负责人，owner字段被写成了“待认领”。这正是后续需要人工确认或在下一次会议中分配的任务。
[
{
"task": "完成问卷初稿",
"owner": "阿哲",
"deadline": "周三前",
"priority": "high",
"source": "阿哲说周三前把问卷初稿发群里"
},
{
"task": "查找去年的问卷模板",
"owner": "小敏",
"deadline": "未明确",
"priority": "medium",
"source": "小敏负责找去年的问卷模板"
},
{
"task": "补充开放式问题",
"owner": "待认领",
"deadline": "未明确",
"priority": "low",
"source": "老师建议加上一个开放式问题"
}
]
三、用Python调用DeepSeek API自动转换
如果需要批量处理多条会议记录，或者在笔记软件中一键转换，可以直接调用DeepSeek API。DeepSeek的接口兼容OpenAI SDK，接入成本很低。以下示例使用Python读取一段会议纪要文本，并返回结构化JSON。
import json
from openai import OpenAI
client = OpenAI(
api_key="你的DeepSeek密钥",
base_url="https://api.deepseek.com"
)
def meeting_to_todos(meeting_text):
system_prompt = (
"你是一名学习项目助理。请从会议记录中提取待办事项，"
"返回JSON数组，字段包括task、owner、deadline、priority、source。"
"无法识别的信息写入待认领或未明确。"
)
response = client.chat.completions.create(
model="deepseek-chat",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": meeting_text}
],
temperature=0.1,
response_format={"type": "json_object"}
)
content = response.choices[0].message.content
return json.loads(content)
if __name__ == "__main__":
notes = "阿哲说周三前把问卷初稿发群里，小敏负责找去年的问卷模板。"
todos = meeting_to_todos(notes)
print(json.dumps(todos, ensure_ascii=False, indent=2))
设置temperature=0.1是为了降低随机性，让输出更贴近既定格式。使用response_format参数可以要求模型只输出JSON，避免在前后附加解释文字。需要注意的是，模型偶尔会把输出包在Markdown代码围栏中，实际工程里可以加一层正则或字符串清洗逻辑。
如果不想维护本地Python环境，也可以使用DeepSeek网页版或移动端，把同一段提示词粘贴进去。但对于需要长期重复执行的任务，API方式更稳定，也更容易和后续的笔记处理脚本串联。
四、把结果写回学习笔记工具
得到JSON后，下一步是把它渲染成笔记软件中的待办格式。以Obsidian为例，可以把每条任务转成带复选框的Markdown列表。下面是一个简单的转换函数，把优先级字段改为纯文本标签，避免样式依赖。
def todos_to_markdown(todos):
lines = ["## 待办清单", ""]
for item in todos:
priority_label = {"high": "[高]", "medium": "[中]", "low": "[低]"}[item["priority"]]
line = f'- [ ] {priority_label} {item["task"]}'
if item["owner"] and item["owner"] != "待认领":
line += f' — 负责人：{item["owner"]}'
if item["deadline"] and item["deadline"] != "未明确":
line += f'（截止：{item["deadline"]}）'
lines.append(line)
return "\n".join(lines)
这个函数生成的Markdown可以直接粘贴进Obsidian、Logseq或Notion的代码块中，也可以保存为.md文件。对于使用Notion的用户，可以把JSON字段映射到数据库属性，例如owner对应人员属性，deadline对应日期属性。这样待办清单就不再是静态文本，而是一个可以筛选、排序和提醒的轻量任务看板。
如果你习惯在手机或平板端阅读学习笔记，可以考虑让DeepSeek输出纯Markdown，然后配合笔记软件的同步功能。整个链路可以总结为：会议记录文本进入脚本，脚本调用API获取JSON，再渲染为Markdown或导入Notion。一次配置之后，后续只需要粘贴记录即可。
五、常见问题与优化策略
第一类问题是负责人识别错误。会议记录中经常出现“我们可以让张老师确认一下”这样的表述，模型可能会把“张老师”识别为负责人，但事实上这只是建议。此时可以在提示词中增加规则：只提取明确指派的任务，例如出现“谁负责”“谁来做”“由谁完成”等句式时才填入owner，否则一律写“待认领”。
第二类问题是时间信息缺失。很多课堂讨论只说“下次开会前完成”，并没有具体日期。如果会议记录顶部有日期信息，可以把日期一并传入，并让模型根据相对时间计算截止日期。例如提示词可以补充：如果出现“下次开会前”“下周三”等表述，请结合当前会议日期计算具体日期。
第三类问题是任务颗粒度过粗或过细。模型有时会把一个完整任务拆成多个动作，有时又只输出一条笼统的“推进项目”。解决方式是给出一到两个标准示例，让模型参照示例的粒度。提示词中加入少样本示例，通常比反复修改参数更有效。
最后，建议保留source字段。待办清单不是最终目的，能够回到原始会议记录中查看上下文，是学习笔记场景下非常重要的能力。尤其在团队项目中，任务之间可能存在依赖关系，某一条“待认领”任务可能需要在下次讨论中重新分配。把记录、提取、执行三个环节串起来，才能让学习笔记真正服务于行动，而不是只停留在记录本身。