今天介绍我去年8月做的一款产品——pre-session notes。
一、一个让人头疼的「会前准备」
在许多高客单价服务行业当中，counselor/tutor所带学生都会逐渐在质量和数量之间达到一个临界的平衡点，所以在每次与学生开会前，都需要在浏览器中打开一堆 tab 页面，并花费大量的时间去翻阅不查询相关的数据——GPA、activities、chat history、选校、标化、honors、actionitem，好在自己大脑中激活对这名学生的印象。
这个过程，平均要花 15-30 分钟。如果一天开 5 个会，那就是 2 个半小时——仅仅是准备。
这种“信息碎片化”不仅让开会前的准备极其繁重需要做大量信息收集和筛选，还容易因为忽略关键信息，或在不同session之间存在gap，从而在沟通中“踩雷”，容易导致escalation。
所以，我（PM）、1名AI工程师、1名后端开发，用1个月的时间通过搭建Automation Workflow，基于现有的数仓snowflake获取student-related info，并自动同步到 Slack和开会前打跳转zoom的session页面。通过这套方案，减少重复劳动，提高沟通效率，打破信息孤岛。详细介绍下具体怎么做的。
二、需求分析
我们了解到用户场景后，再做需求的分析：
- 特定用户场景：适用于把 counselor 或 tutor 他们在开会前所需要关注的学生近况信息聚合到一起。这些信息的呈现肯定是要格式化，方便阅读。
- 不增加额外的工作：因为只是在会前快速了解，所以它呈现的地方，应该是每天工作当中必然要打开的某一个地方，并且能够让用户快速去了解。
- 篇幅不能太长：因为阅读时间有限。当然，为了避免误解，AI 生成的内容最好增加一个 Review Agent 对信息做判断。如果是一些高度存疑的信息，最好通过 Highlight 标识进行区分。
- 数据源可追溯：涉及到一些数据源时，最好增加数据源脚标。鼠标 focus on 或者点击时，可以显示数据源的内容。并支持用户编辑和实时保存。
- 自动触发与更新：这套 workflow 应该是自动触发的。但可能在开会前会有一些信息的更新，这个时候需要有 regeneration 功能来触发。
在此基础之上，需要考虑开发测试环境（结合企业内部资源，如slackbot或copilot）、内测用户的shadowing/gether feedback/follow-up，以及逐步上线的策略。当然，开发过程当中也需要考虑 workflow 与现有系统的对接、判断生成规则这些比较细节的产品问题。
并设定一些关键的metrics方便monitoring，比如 cost、duration time和payload。
三、生成内容的迭代
具体要生成什么样的内容呢？AI生成内容的召回率决定了产品的NPS。
- 我们首先和业务方要一份template，确定生成内容的结构和每部分的内容，整理为表格并分析数据源。并分析语气和风格。
- 整理一些reference，整理gold set，并以此拓展原来template中遗漏的内容。
- 进行多轮迭代，对比gold set判断召回率
- [先膨胀] 在 v1 的基础上大量扩展，把几乎所有能找到的信息都塞进去了，这一版的核心理念是「宁可多，不能少」。接着访谈用户，了解feedback和用户使用场景。形成20~22页的google doc。
- [再收缩] 反馈回来了，非常明确，阅读时间一般是 15 分钟，距离我们目标的2分钟以内偏差很大，但幸运的是我们收集了大量细节和关键的反馈。随后进行了6轮迭代，以删减内容为主，将大量重复、不重要的信息进行了简化，后期有进行了一些label和文字的微调，去掉无效信息的placeholder，最终达到业务方满意的版本。
我们先来看看最终产出的 Presession Note 包含哪些内容。不妨把它想象成一份「学生状态快照」：
- 学生基本信息：年级、国籍、申请年份、目标专业、所在高中、课程体系（IB/AP/A-Level 等）
- Recent Task Updates：上次会议以来，学生完成了什么、还没完成什么，以主题式归纳呈现
- 学术成绩概况：当前年级的重点科目和成绩概述
- 标化：SAT/ACT/AP/IB 等考试成绩，含counselor解读建议
- Final List：含申请状态和截止日期
- activities：按「进行中/已完成/计划中」分类，按时间由近到远排列
- Competition and honors：近期竞赛成绩和获奖情况
- Topic to Discuss：AI 根据最新动态建议本次会议应该讨论的话题
- Mood Check：AI 根据最近的聊天内容和会议纪要进行情绪分析
所有这些内容，都通过 AI 自动整理成一份结构化的 Markdown 文档，嵌入到会议详情页中，counselor打开会议页面就能看到。
「从膨胀到收缩」这一步是整个项目最重要的环节：AI 擅长生成「多」的内容，但真正难的是生成「对」的内容。而什么算「对」，只有真实使用者才能告诉你。
四、workflow开发
在手动生成达到初步验证需求的基础上，开始workflow的开发。
- 通过系统定时任务发送请求到n8n，查询snowflake获取详细元数据，并做一些逻辑判断。
- 通过endpoint获取学生base info，再通过js脚本把核心数据标准化，做数据清洗并拼接成的markdown文本。
- 在这里我们中间加了一步，情绪分析 Agent，通过对transcript分析，识别学生近期隐含或表达的情绪状态，以及关联的具体事件，输出json格式。后续还可以做纪念日提醒等功能。这里用到了ReAct，因为多源异构数据，所以会call不同工具进行查询分析，observation判断结果，通过交叉对比推理出全面准确的结论。
- 这里是最核心的内容：通过sub-workflow链式数据收集不同的sections。这样可以降低系统复杂度，方便单元测试，提高容错，也方便在其他业务中调用。
- 将上述所有节点/子工作流返回的数据，按照预设的 Markdown 结构拼接成完整的草稿文本。再将组装好的草稿投递给 LLM（系统 Prompt 中指定了极为严苛的格式要求），这步还是很有必要的，尤其是格式方面，AI可能会random调用一些格式，导致用户阅读不便。
- 将 AI 生成并格式化好的 Markdown 字符串进行转义与 JSON 序列化处理，确保安全传输。执行 GraphQL Mutation提交到系统后台并绑定event发送到前端。并记录本次生成的日志，完成闭环。
需要注意的是，AI 极度喜欢“自动补全”。如果某个学生的GPA为空，AI 可能会根据常识编造一个，需要在prompt中明确写入负向约束
五、功能联调上线
Staff在开会前必然会通过session detail page，所以把这个功能放在这个页面，通过角色权限进行控制。
- 每一条数据句末增加角标，可通过点击跳转到对应数据源页面；或鼠标focus on的时候，显示数据源内容，方便staff快速排查是否准确
- 使用agent判断信息存疑，通过底色标黄highlight标识（是否能增加Y/N功能，鼠标移上去可显示，用于反馈准确度）
- 两次会议之间，学生发生变动的信息，通过文字加粗进行区分
限于当时的技术发展水平，我们做了一些妥协，现在回过头来，我们前段时间又做了一些优化。比如说：
- 增加了 AI gateway，方便解决模型没响应的问题
- 把成本监控从langfuse迁移过来，更好去做管理
- n8n 本身的架构设计，没有好的缓存机制，导致数据加载存在明显延迟。
- 当时模型上下文窗口限制，只能使用sub-workflow的方式确保准确性。
- 第五步中让llm优化排版。这步也经常会导致存在一些幻觉和 token 的消耗
- 当时 AI 幻觉问题导致并不敢增加太多的recommendation，更多的只是数据的收集和罗列
六、如果你想做一个类似的 AI 功能……
说了这么多，你可能在想：我们公司能不能也做一个类似的功能？答案是：完全可以。下面我提炼出几个最关键的方法论，希望对你有启发。
方法论 1：先抄再改，而不是从零设计
我们没有凭空想象 Presession Notes 应该包含什么。我们先收集了真实顾问手工写的笔记和模板，让 AI 基于这些「黄金样本」来学习格式和内容范围。这是最重要的第一步——你不需要设计完美方案，你需要找到现实中已经在做的事情，然后用 AI 来加速它。
方法论 2：膨胀-收缩迭代法
不要试图在第一个版本就做到「刚好」。我们的经验是：先让 AI 生成「尽可能多」的内容（膨胀版），然后拿着这份「过度详细」的输出去找真实用户，让他们告诉你什么该删、什么该留、什么该改（收缩版）。用户比你更清楚他们需要什么——但他们需要看到实物才能给出反馈。
方法论 3：用低代码工具快速验证
在正式写代码之前，我们先用 Google Doc + n8n 验证了整个流程。这让我们在投入正式开发资源之前，就能快速迭代格式和内容。如果你也想做类似的事情，不要一上来就搞系统集成——先用你能想到的最简单的方式让 AI 跑起来，看看输出能不能用。
方法论 4：AI 的输出一定要有「可验证性」
我们的用户反馈中，有两条跟「信任」直接相关：一是「数据源标识」，二是「存疑高亮」。在 AI 还没有 100% 准确的时代，让用户能快速验证 AI 的输出是对是错，比让 AI 尽量少犯错更重要——因为后者目前做不到，而前者是可以做到的产品设计。
方法论 5：拆解成子任务，而不是一个大 Prompt
我们整个系统用了6个workflow，而不是一个超级 Prompt。学术成绩、标化考试、选校清单、活动列表……每个模块都是一个独立的子流程（Sub-workflow），有自己专门的数据源和处理逻辑。这不仅让整个系统更易于调试和维护，也让每部分的 AI 输出更加可控。如果你试图用一个 Prompt 让 AI「把什么都做了」，结果往往是「什么都做不好」。
再回归到这个产品本身。如果从它单一功能来讲，确实解决了很大的问题，也符合用户的场景。我们的技术栈并不复杂——n8n 是低代码平台、GPT 是通用模型、Google Doc 是最简单的输出方式。真正花时间的不是「调 AI」，而是搞清楚「人到底需要什么」。
但是，在更大的视野下，比如说我们已经有 Copilot，有不同的 Agent 产品，有给到Staff Dashboard，那这些不同的产品之间如何更好地整合，去方便 Staff 每天去做 Monitoring、Follow-up 和 Review？甚至可以把该功能拓展为一个skill，增加更多交互性指令和可拓展性，并且避免传统IT开发导致字段名修改等导致错误的问题。其实现在还缺少一些通盘的架构设计。比如说，我们生成完notes之后，开完会它就没什么用了。其实还可以再去根据会议内容自动fiff和update，不用每次重新生成，而是通过memory机制去做Dynamic。减少 staff 检查并提供 context 的工作量。
在开发过程当中，原来限于模型能力不足，花了很多的时间去做数据的清洗和测试迭代。那现在其实可以通过一些比较贵的模型很快解决这些问题。
我们还担心因为信息不准确造成 staff 抱怨，增加他们工作当中的complaint，所以对 transcript 的应用比较少。其实可以基于现在的模型能力增加更多的内容分析和建议，挖掘出比较有价值的 insights。