Day06 Coze 项目案例：AI 面试助手完整笔记

今日目标

1. 能说清楚 AI 面试助手项目的业务背景、核心痛点和一期 MVP 范围。
2. 能区分单智能体、多智能体、路由智能体和工作智能体。
3. 能理解循环结构适合处理“数量不固定的一组数据”，例如多个项目经历。
4. 能画出 AI 面试助手的整体业务流程：用户提交材料、路由识别需求、业务模块处理、数据和知识库支撑、输出结果。
5. 能说清楚简历评估模块的完整链路：数据准备、内容分块、并行评估、项目循环评估、结果整合。
6. 能理解违禁词数据库、简历模板知识库、当前日期、文档识别插件在项目中的作用。
7. 能理解项目收益和优化方向，不把项目只讲成“拖节点”，而是能讲成“为就业辅导提效的 AI 工具”。

一、今天学习的主线

前几天我们已经学过 Coze 的基础能力：智能体、工作流、知识库、数据库、多模态、循环结构等。今天开始进入项目案例：AI 面试助手。

项目课和功能课不一样。功能课重点是“这个节点怎么用”，项目课重点是“这些能力怎么组合起来解决一个真实问题”。

今天的核心不是把 AI 面试助手所有模块都完整做完，而是先把项目整体理解清楚，再重点体验简历修改模块。

可以把今天的学习路线理解成：

1. 为什么要做 AI 面试助手。
2. 这个项目准备解决哪些就业辅导问题。
3. 为什么一期先做简历修改、面试录音分析、面试题生成和批量处理。
4. 为什么当前阶段选 Coze，而不是一开始就用 LangGraph。
5. 简历评估模块如何从一份简历文件，变成一份可读的修改报告。

二、项目背景：为什么要做 AI 面试助手

AI 面试助手来源于一个真实的就业辅导痛点。

学生学习完课程后，需要准备简历、面试题、自我介绍和模拟面试。老师也需要批改简历、听面试录音、总结问题、给学生生成练习方向。随着学生数量增加，人工处理会出现明显效率瓶颈。

这个项目主要解决四类问题：

1. 简历修改问题：学生初版简历质量参差不齐，常见问题包括项目名称雷同、技能和项目不匹配、工作经历和项目经历混写、学历信息位置不合适、表达空泛等。
2. 面试录音分析问题：老师听完整段录音成本高，而文字转写后可以更快分析学生的自我介绍、问答表现和薄弱点。
3. 面试题生成问题：面试宝典内容多，学生容易抓不住重点，需要根据简历、岗位和真实面试题生成更个性化的练习题。
4. 批量处理问题：老师面对多份简历和多段录音时，需要批量初筛，把低级错误先筛出来，把人工精力留给更高级的问题。

项目的价值不是“让 AI 代替老师”，而是让 AI 先做可标准化、重复性强、初筛类的工作，老师再集中处理需要经验判断的部分。

三、MVP：先做能验证价值的小版本

MVP 是 Minimum Viable Product，意思是最小可行产品。

公司做项目时，不会一开始就把所有想法都做完，因为时间、人力、预算都有限。更常见的做法是先做一个小版本，验证方向是否可行。

本项目的一期范围主要包括：

1. 简历修改模块。
2. 面试录音分析模块。
3. 面试题生成模块。
4. 批处理模块。

其中，Day06 白天重点体验的是简历修改模块，因为它输入清晰、输出明确、业务价值容易感知，也最适合让学生第一次理解项目化工作流。

四、单智能体、多智能体和路由思想

1. 单智能体的问题

单智能体可以理解成一个“大而全的人”。它既要判断用户意图，又要查资料，又要改简历，又要分析录音，还要生成面试题。

当业务简单时，单智能体可以解决问题。但当业务变复杂时，单智能体会有几个问题：

1. 提示词会越来越长，维护困难。
2. 一个功能修改可能影响其他功能。
3. 所有能力都堆在一起，定位问题困难。
4. 对复杂任务的处理稳定性较差。

2. 多智能体的思想

多智能体可以理解成一个团队。

团队里有一个路由智能体，负责判断用户想做什么；还有多个工作智能体，分别负责具体任务。

在 AI 面试助手里，可以有：

1. 简历评估 Agent。
2. 面试录音分析 Agent。
3. 面试题生成 Agent。
4. 批量处理任务。

路由智能体像前台或调度员。它先判断用户需求，再把任务分给合适的业务 Agent。

3. Coze 和 LangGraph 的关系

Coze 适合快速验证业务流程，拖拽式搭建，上手快，适合课程阶段体验项目思路。

Dify 或 Coze 本地版更适合数据安全要求更高、需要本地部署的场景。

LangChain / LangGraph 更适合复杂生产级项目，扩展性强，但学习成本和开发成本更高。

本项目当前选择 Coze，是因为目标是快速做出可体验的 MVP。将来如果项目规模变大、业务复杂度增加、需要更强的并发和可控性，可以考虑用 LangGraph 重构。

五、AI 面试助手整体业务流程

AI 面试助手的整体流程可以分成五步：

1. 用户提交材料：学生上传简历或录音，老师也可以批量提交多份材料。
2. 面试助手识别需求：判断用户是要做简历评估、录音分析、面试题生成，还是批量处理。
3. 业务 Agent 执行处理：不同模块进入不同的处理流程。
4. 数据和知识库支撑：违禁词库、简历模板库、真实面试题库、面试宝典、联网搜索等为结果提供依据。
5. 输出结果：生成简历评估报告、录音分析报告、专属面试题或批量处理报告。

注意：项目中的数据和知识库非常关键。没有数据支撑，智能体只能泛泛而谈；有了规则库、知识库和数据库，智能体才能更像一个业务系统。

六、AI 面试助手架构图怎么理解

架构图不要照着名词硬背，建议从下往上看。

可以把 AI 面试助手类比成现代物流供应链：

1. 数据与知识层像底层大仓库。违禁词库、简历模板库、面试题库、学生简历和录音都在这里。
2. AI 能力支撑层像自动化设备中心。OCR 负责识别文档，ASR 负责识别语音，RAG 负责检索资料，Reranker 负责重排，大模型负责理解和生成。
3. 业务应用层像加工流水线。简历评估、录音分析、面试题生成、批量处理都是不同流水线。
4. 用户入口层像门店和下单入口。学生可能从 Coze、豆包、小程序、公众号或内部系统进入。

这套架构不只适用于 AI 面试助手，也适用于很多 AI 项目。

更普遍的 AI 项目可以拆成六层：

1. 用户入口层：网页、App、小程序、API、企业微信等。
2. 业务编排层：工作流、Agent、路由、多智能体、LangGraph 状态图等。
3. 模型与工具层：LLM、OCR、ASR、TTS、搜索、数据库工具等。
4. 检索与记忆层：知识库、向量库、RAG、Reranker、会话记忆等。
5. 业务数据层：数据库、文件、用户数据、日志、权限数据等。
6. 治理与运维层：权限、安全、审计、监控、评测、成本控制、人工兜底等。

课堂项目主要让大家先看懂前五层。真实企业项目还会非常重视第六层，因为系统上线后不仅要能跑，还要安全、稳定、可控。

七、简历评估模块总体流程

简历评估模块的输入是一份简历文件，输出是一份 Markdown 格式的简历评估报告。

完整流程如下：

1. 数据准备：准备简历文件、违禁词库、当前日期。
2. 文本处理：通过文档识别或链接读取，把简历文件转成文字。
3. 内容分块：把完整简历拆成个人信息、技能、学历、工作经历、项目经历、个人评价等部分。
4. 多维度评估：分别评估各模块内容。
5. 项目经历深度分析：项目可能有多个，所以要用循环逐个处理。
6. 结果整合：把所有模块的评估结果汇总成完整报告。

这个流程体现了一个重要思想：分治。

不要让一个大模型一次性评估整份简历。更稳的做法是先拆开，再分别评估，最后整合。

八、数据准备：为什么要先搭资源

简历评估模块需要先准备两个资源：

1. 违禁词数据库。
2. 简历模板知识库。

1. 违禁词数据库

违禁词数据库用于存放不建议直接出现在简历中的词，比如课程项目原名、容易导致雷同的项目名、风险表达等。

使用数据库的原因：

1. 方便增删改查。
2. 不需要每次修改提示词。
3. 可以被多条工作流复用。
4. 后续可以通过 API 接入内部系统。

2. 简历模板知识库

简历模板知识库用于做查重和参考。项目经历容易雷同，所以需要把用户简历里的项目内容和模板库做对比。

知识库适合存放文档类资料，比如优秀简历模板、项目描述参考、写法规范。

数据库适合存放结构化数据，比如违禁词列表。

九、数据准备节点

简历评估工作流一开始会准备三类信息：

1. 查询违禁词数据：从数据库里取出所有违禁词。
2. 简历文字提取：从用户上传的 PDF、DOC 或图片简历中提取文字。
3. 获取当前日期：用于判断毕业时间、工作年限、项目时间是否合理。

这里要注意，当前日期看起来很小，但在简历评估里很重要。

比如学生 2023 年毕业，当前是 2026 年，那么工作年限一般不能写成 6 年。时间类信息必须结合当前日期判断。

十、内容分块：把非结构化简历变成结构化字段

简历本身是一段非结构化文本。大模型虽然能读，但如果整段直接评估，很容易混乱。

内容分块节点要把简历拆成结构化字段：

1. name：姓名。
2. base_info：个人基本信息。
3. skill：个人技能。
4. education：教育经历。
5. work_exp：工作经历。
6. project_exp：项目经历，通常要设置为数组。
7. self：个人评价或个人爱好。
8. context：简历整体总结，供后续节点参考。

项目经历要设置为数组，因为一份简历可能有多个项目。后面要用循环逐个评估。

内容分块的质量非常重要。如果前面分错了，后面评估就会全错。

十一、并行评估：为什么不是一个节点从头评到尾

简历评估可以拆成多个模块：

1. 个人信息评估。
2. 技能评估。
3. 学历评估。
4. 工作经历评估。
5. 项目经历评估。
6. 个人评价评估。

除了项目经历，其他模块可以并行执行。

并行的好处：

1. 节省时间。
2. 每个节点提示词更短、更专注。
3. 每个模块问题更容易定位。
4. 降低长上下文带来的理解衰减。

串行像排队，一个做完再做下一个。

并行像多车道，同时处理多个独立任务。

十二、各模块评估重点

1. 个人信息评估

重点检查：

1. 求职意向是否明确。
2. 是否出现不建议写的期望薪资。
3. 联系方式是否规范。
4. 工作年限和毕业时间是否合理。
5. 个人信息是否影响筛选。

正确做法：信息简洁、岗位明确、时间合理、无敏感或被动表达。

错误做法：求职意向写多个方向，期望薪资写死，工作年限明显夸大。

2. 技能评估

重点检查：

1. 技能是否和项目经历对应。
2. 项目中出现的技术是否在技能中体现。
3. 技能中写“熟练”“掌握”的内容，是否能在项目里找到支撑。
4. 技能顺序是否符合岗位要求。

正确做法：技能点与项目互相支撑。

错误做法：技能堆满但项目完全没体现。

3. 学历评估

重点检查：

1. 学历、学校、专业、时间是否完整。
2. 学历位置是否适合。
3. 是否需要避短，把更有优势的项目和工作经历放在前面。

学历不是不能写，而是要放在对自己最有利的位置。

4. 工作经历评估

重点检查：

1. 工作经历和项目经历是否混写。
2. 工作职责是否具体。
3. 工作经历和项目内容是否冲突。
4. 时间线是否合理。

正确做法：工作经历写岗位职责、业务范围、参与内容。

错误做法：把项目细节全部塞进工作经历，导致结构混乱。

5. 项目经历评估

项目经历是简历中最重要、也最容易出问题的部分。

重点检查：

1. 项目数量是否合理。
2. 项目结构是否完整：背景、技术栈、个人职责、成果。
3. 项目背景是否真实可信。
4. 技术点是否合理。
5. 成果数据是否能解释。
6. 是否出现违禁词。
7. 是否与模板库高度雷同。
8. 是否和上下文内容冲突。

项目经历不仅要“看起来高级”，更要能经得起面试追问。

6. 个人评价评估

个人评价是可选内容。如果没有，可以不写。

如果写，就要避免空泛表达，比如“本人认真负责、吃苦耐劳、学习能力强”。这些话不是不能写，而是要有事实支撑。

正确做法：用具体经历证明软素质。

错误做法：堆形容词，没有证据。

十三、项目经历为什么要用循环

项目经历和其他模块不同，因为项目数量不固定。

有人写 1 个项目，有人写 3 个项目，有人工作多年可能写 5 个项目。

如果不用循环，就很难逐个稳定评估。

循环的逻辑是：

1. 输入项目数组。
2. 每次取出一个项目。
3. 对这个项目做内容评估。
4. 对这个项目做查重评估。
5. 整合这个项目的评估结果。
6. 所有项目处理完后，输出项目评估列表。

循环适合处理列表数据，也就是“数量不固定、但处理规则相同”的任务。

十四、项目重复度评估

项目重复度评估通常包含三个动作：

1. Query 优化：把当前项目内容整理成更适合检索的查询文本。
2. 知识库检索：去简历模板库中找相似项目描述。
3. 重复度评估：把当前项目和检索结果对比，判断哪些部分雷同。

不能直接把整个项目原文拿去检索，因为原文可能又长又乱。先让大模型整理成更清楚的查询内容，检索效果会更好。

重复度评估不是为了让学生“完全不能参考模板”，而是提醒学生不要直接照搬，要把项目改成自己的经历、职责和成果。

十五、结果整合

前面每个评估节点都会输出自己的结论，但学生最终需要看的不是一堆散乱结果，而是一份完整报告。

结果整合节点要做的事：

1. 接收个人信息、技能、学历、工作经历、项目经历、个人评价等评估结果。
2. 去掉重复内容。
3. 按清晰结构组织。
4. 不杜撰不存在的问题。
5. 输出一份 Markdown 格式的简历评估报告。

这一步是“最后一公里”。没有结果整合，工作流只能算半成品。

十六、项目收益和优化方向

项目收益要围绕业务目标衡量。

AI 面试助手的业务目标是提升就业辅导效率，所以收益可以看：

1. 学生自查简历的效率是否提升。
2. 老师批改简历的时间是否减少。
3. 低级错误是否能提前被筛出。
4. 学生是否能获得更具体的修改建议。

注意：技术指标和业务收益不是一回事。

模型准确率、检索效果、OCR 识别质量属于技术指标；节省老师时间、提高简历初筛效率、提升学生修改质量才是业务收益。

后续可优化方向：

1. 替换效果更好的模型。
2. 替换更强的 OCR 或文档识别能力。
3. 增加学生历史简历查重。
4. 记录调用信息，帮助老师分析学生简历共性问题。
5. 将 Coze 流程迁移到 LangGraph，实现更强可控性。

十七、简历评估全节点总览

简历评估模块可以拆成 N0 到 N12，其中 N9 项目经历循环内部又包含 N9a 到 N9e。课堂上不需要死背编号，但要能理解每个节点在链路里的位置。

节点	名称	作用
N0	开始节点	接收用户上传的简历文件
N1	简历文字提取	把 PDF/DOC 简历提取成文本
N2	违禁词查询	从数据库取出违禁词列表
N3	获取当前日期	为工作年限、毕业时间、项目周期判断提供时间基准
N4	简历内容分块	把简历全文拆成结构化字段
N5	个人信息评估	检查求职意向、联系方式、薪资、年限等
N6	技能评估	检查技能和项目是否互相支撑
N7	学历信息评估	检查学历完整性、位置和学校信息
N8	工作经历评估	检查工作职责、时间线和项目是否混写
N9	项目经历循环	遍历项目数组，逐个项目评估
N9a	项目经历评估	检查单个项目的结构、技术、职责、成果、违禁词
N9b	项目 Query 优化	把项目内容整理成更适合检索的查询文本
N9c	简历模板库检索	从知识库召回相似项目模板
N9d	简历重复度评估	判断项目与模板库是否高度雷同
N9e	单项目结果整合	合并单个项目的规则评估和查重结果
N10	个人评价评估	检查个人评价是否空泛、是否有事实支撑
N11	评估结果整合	汇总所有模块结果，生成完整报告
N12	结束节点	输出 Markdown 简历评估报告

模型选型也要有依据：

1. 内容分块用大上下文模型，因为简历可能很长。
2. 技能、工作经历、项目评估、结果整合用深度思考模型，因为规则多、推理重。
3. 学历评估可以配合搜索能力，减少学校信息判断中的幻觉。

十八、今日易错点

易错点 1：把知识库和数据库混用

错误：把违禁词做成知识库，或者把简历模板做成数据库。

正确：违禁词是结构化列表，适合数据库；简历模板是文档内容，适合知识库。

易错点 2：把整份简历直接交给一个大模型评估

错误：一个节点从头到尾评估所有内容。

正确：先分块，再分别评估，最后整合。

易错点 3：项目经历不用循环

错误：假设每个人只有一个项目，用一个固定节点处理。

正确：项目经历数量不固定，要用循环逐个处理。

易错点 4：结果整合节点杜撰问题

错误：整合时为了“看起来完整”生成不存在的问题。

正确：只基于前面评估结果整合，没依据就不要写。

易错点 5：只会拖节点，不会解释业务价值

错误：项目讲成“我用了几个节点”。

正确：项目要讲清楚解决了什么痛点、为什么这么设计、产生了什么收益、还有哪些优化方向。

Day06 Coze 项目流程拆解清单

一、整体项目链路

AI 面试助手不是一个单节点功能，而是一条业务链。

阶段	做什么	为什么需要
用户提交材料	用户上传简历或录音，也可以由系统管理员批量提交材料	明确系统要处理的原始输入
路由识别需求	判断是简历评估、录音分析、面试题生成还是批量处理	避免一个智能体承担所有任务
业务模块执行	对应 Agent 执行具体任务	让每个模块职责清楚
数据和知识支撑	使用数据库、知识库、ASR、RAG、联网搜索等能力	让结果有依据，不靠大模型硬编
输出报告	生成可读的评估报告、分析报告或面试题	用户真正需要的是结论和建议

二、简历评估全节点清单

简历评估模块不是一个单节点流程，而是一条由数据准备、内容分块、并行评估、项目循环、结果整合组成的完整链路。

节点	节点名称	输入	输出	作用
N0	开始	简历文件 resume	文件对象或 URL	接收用户上传简历
N1	简历文字提取	resume	pdf_content 或 content	把文件变成文本
N2	违禁词查询	查询条件	outputList	获取违禁词列表
N3	获取当前日期	无	当前日期 date	提供时间判断基准
N4	简历内容分块	简历全文	base_info、skill、education、work_exp、project_exp、self、context	把非结构化文本变成结构化字段
N5	个人信息评估	base_info、context、date	个人信息评估结果	检查求职意向、薪资、联系方式、年限
N6	技能评估	skill、context、project_exp	技能评估结果	检查技能和项目是否互证
N7	学历信息评估	education、context、date	学历评估结果	检查学历信息和位置
N8	工作经历评估	work_exp、context、date	工作经历评估结果	检查职责、时间线和项目混写问题
N9	项目经历循环	project_exp 数组	项目评估结果列表	逐个处理多个项目
N9a	项目经历评估	单个项目、context、date、forbid_list	项目规则评估结果	检查结构、技术、职责、成果、违禁词
N9b	项目 Query 优化	单个项目	检索 query	提升模板库检索质量
N9c	简历模板库检索	query	相似模板内容	为查重提供参考
N9d	简历重复度评估	项目内容、检索结果	重复度评估结果	判断是否和模板高度雷同
N9e	单项目结果整合	项目评估、重复度评估	单项目综合结论	合并单个项目的两类结果
N10	个人评价评估	self、context	个人评价评估结果	检查是否空泛、是否有事实支撑
N11	评估结果整合	所有模块结果	完整评估报告	去重、润色、结构化输出
N12	结束	完整报告	Markdown 文本	返回最终结果

三、简历评估模块主流程

第 1 步：开始节点

输入：用户上传的简历文件。

输出：简历文件对象或文件 URL。

作用：作为整个简历评估流程的入口。

易错点：

1. 输入类型没有设置成文件。
2. 后续节点拿不到文件 URL。
3. 没有确认 PDF、DOC、图片简历是否都能处理。

第 2 步：查询违禁词数据库

输入：无特殊输入，或查询条件为数据存在即可。

输出：违禁词列表。

作用：后续项目经历评估时判断是否出现课程项目原名、雷同项目名或风险词。

为什么用数据库：

1. 违禁词会不断更新。
2. 数据库方便增删改查。
3. 多条工作流可以复用同一份数据。

易错点：

1. 查询字段选多了，导致后续引用复杂。
2. 没有拿到真正需要的输出列表。
3. 把违禁词写死在提示词里，后续维护困难。

第 3 步：简历文字提取

输入：开始节点传入的简历文件 URL。

输出：简历全文文本。

作用：把 PDF、Word 或图片简历转换成大模型可以处理的文字。

易错点：

1. 文件类型和插件要求不匹配。
2. OCR 对表格、排版复杂简历识别不准确。
3. 没有检查提取结果，后续评估全基于错误文本。

第 4 步：获取当前日期

输入：不需要输入。

输出：当前日期时间。

作用：辅助判断毕业时间、工作年限、项目周期是否合理。

易错点：

1. 认为当前日期不重要。
2. 工作年限判断时只看简历文字，不结合当前时间。

第 5 步：内容分块

输入：简历全文。

输出：结构化字段。

建议字段：

字段名	内容
name	姓名
base_info	基本信息
skill	个人技能
education	教育经历
work_exp	工作经历
project_exp	项目经历数组
self	个人评价
context	简历整体总结

作用：把一整份简历拆成后续节点可独立处理的小块。

易错点：

1. project_exp 没有设置成数组。
2. 字段名前后不统一，导致后续节点引用失败。
3. 分块提示词太模糊，模型把工作经历和项目经历混在一起。

第 6 步：个人信息评估

输入：base_info、context、当前日期。

输出：个人信息评估结果。

检查重点：

1. 求职意向是否明确。
2. 是否写死期望薪资。
3. 联系方式是否规范。
4. 工作年限是否合理。

易错点：

1. 只评价格式，不评价求职意向。
2. 忽略时间线。

第 7 步：技能评估

输入：skill、project_exp、context。

输出：技能评估结果。

检查重点：

1. 技能是否和项目经历对应。
2. 项目中出现的关键技术是否在技能中体现。
3. “熟练”“掌握”的技术是否有项目支撑。

易错点：

1. 只看技能写得多不多，不看是否能证明。
2. 技能和项目脱节。

第 8 步：学历评估

输入：education、context、当前日期。

输出：学历评估结果。

检查重点：

1. 学校、专业、学历、时间是否完整。
2. 学历位置是否适合。
3. 是否需要避短，把项目和工作经历放在更靠前位置。

易错点：

1. 不结合整体简历判断位置。
2. 把学历问题说得过重，忽略求职方向。

第 9 步：工作经历评估

输入：work_exp、context、当前日期。

输出：工作经历评估结果。

检查重点：

1. 工作职责是否清楚。
2. 工作经历和项目经历是否混写。
3. 时间线是否合理。
4. 是否与项目内容冲突。

易错点：

1. 工作经历写成项目详情。
2. 工作时间和项目周期对不上。

第 10 步：个人评价评估

输入：self、context。

输出：个人评价评估结果。

检查重点：

1. 是否空泛。
2. 是否有事实支撑。
3. 是否和岗位方向相关。

易错点：

1. 没有个人评价时强行输出问题。
2. 只说“认真负责”，不给证据。

第 11 步：项目经历循环

输入：project_exp 数组。

输出：每个项目的评估结果列表。

循环逻辑：

1. 取出第一个项目。
2. 做项目经历评估。
3. 做项目 Query 优化。
4. 检索简历模板知识库。
5. 做项目重复度评估。
6. 整合当前项目结果。
7. 继续处理下一个项目。

为什么需要循环：

项目数量不固定，但每个项目都要执行同样的处理规则。

易错点：

1. 把多个项目混在一个节点里评估。
2. 循环输出没有汇总。
3. 项目查重只看项目名称，不看技术点、职责和成果表达。

第 12 步：结果整合

输入：所有模块评估结果。

输出：完整简历评估报告。

报告建议结构：

1. 总体结论。
2. 简历优点。
3. 主要问题。
4. 分模块修改建议。
5. 项目经历重点风险。
6. 综合评价。

易错点：

1. 简单拼接各节点结果，不做去重。
2. 整合节点杜撰前面没有发现的问题。
3. 输出结构混乱，用户不知道应该怎么改。

四、学习顺序建议

第一轮：先看懂全流程

先看流程，不急着看提示词细节。

目标：知道从简历文件到评估报告，中间到底经过了哪些处理步骤。

第二轮：重点看内容分块

观察简历全文如何变成结构化字段。

目标：理解非结构化文本到结构化数据的转换。

第三轮：重点看项目循环

观察项目数组如何逐个进入循环体。

目标：理解循环处理不固定数量数据。

第四轮：最后看最终报告

对比单模块输出和整合报告。

目标：理解结果整合不是可有可无，而是产品体验的一部分。

Day06 Coze 简历评估全节点说明

一、模块定位

“简历修改模块”和“简历评估模块”指的是同一条工作流：接收学生上传的 PDF 或 DOC 简历，基于就业辅导规则、违禁词数据库、简历模板知识库和大模型评估能力，输出 Markdown 格式的简历问题清单与修改建议。

这个模块的核心设计思想是：分治、并行、循环、RAG、结果整合。

维度	说明
输入	简历文件，通常是 PDF 或 DOC
输出	简历评估报告，包含问题、风险、修改建议
核心价值	先用系统自查低级错误，再把精力留给更复杂、更有价值的优化问题
设计思想	大任务拆小块，各模块并行评估，项目经历循环处理，最后统一整合

二、四大阶段

阶段	做什么	为什么
数据准备	OCR 抽文字、查违禁词、取当前日期	为后续评估提供原始材料和时间基准
内容分块	用 LLM 把简历全文拆成多个结构化字段	避免整份简历直接评估导致上下文混乱
分模块评估	个人信息、技能、学历、工作经历、项目经历、自我评价分别评估	提示词更专注，执行更快，问题更容易定位
结果整合	汇总所有评估结果，生成最终报告	让用户看到一份结构清楚、可执行的修改建议

三、用到的 Coze 组件

组件类型	在本模块中的用途	出现次数
开始节点	接收 resume 文件	1
插件节点	简历文字提取、获取当前日期	2
数据库节点	查询违禁词列表	1
LLM 节点	分块、各模块评估、Query 优化、重复度评估、结果整合	多个
知识库/RAG 节点	检索简历模板库，用于项目查重	1，位于循环体内
循环节点	遍历 project_exp 数组，逐个评估项目	1
结束节点	输出 Markdown 报告	1

四、模型选型策略

节点	建议模型	原因
简历内容分块	豆包 1.5 Pro 256K	简历可能较长，需要更大上下文
个人信息、学历、个人评价	豆包 1.5 Pro	规则相对明确，推理压力较小
技能、工作经历、项目评估、结果整合	豆包 1.6 深度思考	需要跨模块推理，规则更多
学历评估	豆包 + 头条搜索	需要查询学校信息，降低幻觉

五、外部数据资源

资源	类型	用途
违禁词数据	Coze 数据库	动态维护不建议出现在简历中的词
简历模板库	知识库/RAG	项目描述查重和相似内容比对
当前日期	时间插件	判断毕业时间、工作年限、项目周期是否合理
简历文件	用户上传文件	工作流的原始输入

六、完整节点清单

序号	节点名称	节点类型	所属阶段
N0	开始	开始节点	入口
N1	简历文字提取	OCR 插件	数据准备
N2	违禁词查询	数据库查询	数据准备
N3	获取当前日期	现在时间插件	数据准备
N4	简历内容分块	LLM，256K 上下文	内容分块
N5	个人信息评估	LLM	并行评估
N6	技能评估	LLM，深度思考	并行评估
N7	学历信息评估	LLM + 头条搜索	并行评估
N8	工作经历评估	LLM，深度思考	并行评估
N9	项目经历循环	循环节点	项目评估
N9a	项目经历评估	LLM，深度思考	循环体内
N9b	项目内容 Query 优化	LLM	循环体内
N9c	简历模板库检索	知识库/RAG	循环体内
N9d	简历重复度评估	LLM	循环体内
N9e	单项目结果整合	文本整合或 LLM	循环体内
N10	个人评价评估	LLM	并行评估
N11	评估结果整合	LLM，深度思考	汇总
N12	结束	结束节点	出口

七、全节点流程图

下面的流程图用来帮助大家从整体上理解节点关系：哪些节点负责准备数据，哪些节点负责分模块评估，哪些节点位于项目经历循环中，最后又如何汇总成完整报告。

flowchart LR
    N0["N0 开始节点<br/>输入 resume 文件"]

    subgraph S1["阶段一：数据准备"]
        N1["N1 简历文字提取<br/>OCR 插件<br/>输出 pdf_content / content"]
        N2["N2 违禁词查询<br/>数据库节点<br/>输出 outputList"]
        N3["N3 获取当前日期<br/>现在时间插件<br/>输出 date"]
    end

    N4["N4 简历内容分块<br/>LLM 1.5 Pro 256K<br/>输出结构化 JSON"]

    subgraph S3["阶段三：分模块并行评估"]
        N5["N5 个人信息评估<br/>base_info + context + date"]
        N6["N6 技能评估<br/>skill + context + project_exp"]
        N7["N7 学历信息评估<br/>education + context + date"]
        N8["N8 工作经历评估<br/>work_exp + context + date"]
        N10["N10 个人评价评估<br/>self + context"]
    end

    subgraph S9["N9 项目经历循环：遍历 project_exp 数组"]
        N9a["N9a 项目经历评估<br/>单个项目 + context + date + forbid_list"]
        N9b["N9b 项目 Query 优化<br/>输出 query"]
        N9c["N9c 简历模板库检索<br/>RAG 召回相似模板"]
        N9d["N9d 简历重复度评估<br/>项目内容 vs 检索结果"]
        N9e["N9e 单项目结果整合<br/>规则评估 + 查重结果"]
        N9b --> N9c --> N9d --> N9e
        N9a --> N9e
    end

    N11["N11 评估结果整合<br/>汇总六类评估结果"]
    N12["N12 结束节点<br/>输出 Markdown 评估报告"]

    N0 --> N1
    N0 --> N2
    N0 --> N3
    N1 --> N4
    N2 --> N4
    N3 --> N4
    N4 --> N5
    N4 --> N6
    N4 --> N7
    N4 --> N8
    N4 --> N9a
    N4 --> N10
    N5 --> N11
    N6 --> N11
    N7 --> N11
    N8 --> N11
    N9e --> N11
    N10 --> N11
    N11 --> N12

八、变量传递简图

flowchart TD
    A["resume 文件"] --> B["N1 OCR 提取"]
    A --> C["N2 查违禁词"]
    A --> D["N3 获取当前日期"]

    B --> E["pdf_content / content"]
    C --> F["forbid_list"]
    D --> G["date"]

    E --> H["N4 内容分块"]
    H --> I["base_info"]
    H --> J["skill"]
    H --> K["education"]
    H --> L["work_exp"]
    H --> M["project_exp 数组"]
    H --> N["self"]
    H --> O["context"]

    I --> P["个人信息评估"]
    J --> Q["技能评估"]
    K --> R["学历评估"]
    L --> S["工作经历评估"]
    M --> T["项目循环评估"]
    N --> U["个人评价评估"]
    O --> P
    O --> Q
    O --> R
    O --> S
    O --> T
    O --> U
    F --> T
    G --> P
    G --> R
    G --> S
    G --> T

    P --> V["N11 结果整合"]
    Q --> V
    R --> V
    S --> V
    T --> V
    U --> V
    V --> W["Markdown 简历评估报告"]

九、分阶段详细说明

阶段一：数据准备

N0 开始节点

输入：resume，文件类型，接收 PDF 或 DOC 简历。

注意：Coze 会把上传文件放到临时存储中，并返回可供插件读取的 URL。

N1 简历文字提取

输入：resume。

输出：pdf_content 或 content。

作用：把文件中的简历内容提取为文本。

注意：不同文件类型可能输出到不同字段，所以内容分块节点要同时接收两个字段，并做好兜底。

N2 违禁词查询

输入：无固定业务输入。

查询条件：uuid 不为空，等价于查询全部违禁词。

输出：outputList，也就是违禁词列表。

作用：后续项目经历评估时检查是否出现不建议直接写入简历的词。

N3 获取当前日期

输入：无。

输出：日期时间字符串，例如 2026-06-15 10:30:00。

作用：判断毕业时间、工作年限、项目周期是否合理，避免大模型只凭自身知识判断当前时间。

阶段二：N4 简历内容分块

模型建议：豆包 1.5 Pro 256K。

原因：简历可能比较长，32K 上下文可能不够稳定。

输出字段：

字段	含义
name	姓名
base_info	求职岗位、薪资、年限、手机、邮箱等
skill	IT 技能
education	学历、学校、专业、时间
work_exp	公司、时间、角色、职责
project_exp	项目经历数组，每个项目一个元素
self	个人评价、个人爱好
context	简历全文概括，供后续交叉校验

关键提醒：project_exp 必须是数组，因为后面要进入循环节点。

阶段三：分模块并行评估

并行评估的原因：

1. 每个节点只负责一个模块，提示词更好维护。
2. 多个模块可以同时执行，节省时间。
3. 避免上下文过长导致模型理解质量下降。

N5 个人信息评估

输入：base_info、context、date。

检查重点：

1. 不建议写死期望薪资。
2. 求职意向要明确。
3. 邮箱、电话等联系方式要规范。
4. 工作年限要和毕业时间匹配。

N6 技能评估

输入：skill、context、project_exp。

检查重点：

1. 技能数量不要只求多。
2. 技能要和项目互相支撑。
3. 项目中出现的核心技术应在技能中体现。
4. “熟练”“掌握”的技术要能被项目证明。

N7 学历信息评估

输入：education、context、date。

检查重点：

1. 学历、学校、专业、时间是否完整。
2. 是否需要调整学历位置。
3. 学校信息可结合搜索能力判断，减少幻觉。

N8 工作经历评估

输入：work_exp、context、date。

检查重点：

1. 公司、时间、角色是否完整。
2. 工作经历和项目经历是否混写。
3. 工作内容是否和求职方向相关。
4. 工作时间和项目时间是否冲突。

N10 个人评价评估

输入：self、context。

检查重点：

1. 没有个人评价时可以返回空。
2. 有个人评价时不要堆空话。
3. 软素质要有事实支撑。

阶段三特殊部分：N9 项目经历循环

项目经历单独用循环，是因为项目数量不固定，内容较长，规则最多，而且还要做 RAG 查重。

循环体内每次处理一个项目。

N9a 项目经历评估

输入：单个项目内容、context、date、forbid_list。

检查重点：

1. 项目数量是否合理。
2. 项目是否包含背景、技术栈、职责、成果。
3. 项目周期是否合理。
4. 技术点是否和岗位方向匹配。
5. 是否出现违禁词。
6. 成果数据是否容易解释。

输出建议：JSON，便于循环结束后合并，比 Markdown 更省 token。

N9b 项目内容 Query 优化

输入：单个项目内容。

输出：适合检索的 query。

作用：把项目内容按背景、技术点、业务流程、个人职责、优化点、成果数据重新组织，提升知识库检索质量。

注意：只能整理已有信息，不能添加不存在的内容。

N9c 简历模板库检索

输入：N9b 输出的 query。

输出：模板库中相似的项目内容。

建议配置：

1. 召回数量可以较高，例如 20 条。
2. 最小匹配度可设置较高，例如 0.85。
3. 开启查询改写和结果重排。

N9d 简历重复度评估

输入：当前项目内容和知识库检索结果。

作用：判断当前项目与模板库是否在技术点、业务流程、个人职责、优化点、成果数据上高度雷同。

N9e 单项目结果整合

输入：N9a 项目规则评估结果，N9d 项目重复度评估结果。

输出：当前项目的综合评估结果。

作用：把“写得好不好”和“是否雷同”合在一起，形成单个项目的最终结论。

阶段四：N11 评估结果整合

输入：

1. 个人信息评估结果。
2. 技能评估结果。
3. 学历评估结果。
4. 工作经历评估结果。
5. 项目经历循环结果。
6. 个人评价评估结果。

作用：

1. 统一口吻。
2. 去掉重复问题。
3. 按 Markdown 结构输出。
4. 生成完整简历评估报告。

注意：结果整合只能基于前面节点的评估结果，不要杜撰新问题。

阶段五：N12 结束节点

输出：完整 Markdown 简历评估报告。

调试建议：使用真实或模拟简历试运行，并根据输出问题反向调整内容分块和各评估节点的提示词。

十、推荐搭建顺序

1. 创建违禁词数据库，导入违禁词。
2. 创建简历模板知识库，导入模板资料。
3. 搭建开始节点、简历文字提取节点和内容分块节点，先跑通主链路。
4. 添加当前日期插件和违禁词查询节点。
5. 逐个添加个人信息、技能、学历、工作经历、个人评价评估节点。
6. 搭建项目经历循环体。
7. 在循环体内添加项目评估、Query 优化、模板库检索、重复度评估和单项目整合。
8. 添加结果整合节点和结束节点。
9. 使用简历样例全链路测试。
10. 根据 bad case 调整提示词和节点配置。

十一、学习抓手

学习这条工作流时，可以反复追问自己三个问题：

1. 这个节点的输入是什么？
2. 这个节点的输出是什么？
3. 如果没有这个节点，会出现什么问题？

示例：

没有内容分块，后面评估节点就只能面对一整份简历，容易混乱。

没有循环，多个项目就不能逐个稳定评估。

没有结果整合，用户看到的是一堆散乱结论，而不是一份能照着修改的报告。

Day06 Coze 架构图讲解与通用 AI 项目架构

一、为什么要讲架构图

第一次看到架构图时，最容易被一堆专业名词吓住：用户入口层、业务应用层、AI 能力支撑层、数据与知识层、RAG、ASR、Reranker、数据库读写等。

讲架构图时不要照着图念名词。更好的方式是从下往上讲：

1. 系统有什么数据。
2. 系统有哪些能力。
3. 业务流程怎么把数据和能力串起来。
4. 用户从哪里进入系统。
5. 最终结果如何返回给用户。

这套思路不只适用于 AI 面试助手，也适用于大部分 AI 应用项目。

二、物流供应链类比

可以把 AI 项目类比成现代物流供应链。

数据和知识层像底层大仓库。

AI 能力支撑层像仓库里的自动化设备。

业务应用层像加工流水线。

用户入口层像快递驿站、门店和下单入口。

用户提交需求，就像客户下单。系统接收材料，调用工具处理，查仓库里的资料，经过流水线加工，最后把结果交付给用户。

三、AI 面试助手四层架构

第一层：数据与知识层

这一层是系统的底层仓库。

在 AI 面试助手中包括：

1. 违禁词数据库。
2. 简历模板知识库。
3. 真实面试题数据库。
4. 面试宝典知识库。
5. 学生简历与录音文件。

这一层解决的是：系统依据什么资料做判断。

没有这一层，智能体只能泛泛回答，容易编造或给出没有依据的建议。

第二层：AI 能力支撑层

这一层是自动化设备中心。

在 AI 面试助手中包括：

1. 文档识别 OCR：把简历文件转成文本。
2. 语音识别 ASR：把面试录音转成文字。
3. 知识库检索 RAG：从资料中找相关内容。
4. Reranker：把召回内容重新排序。
5. 数据库读写：查询违禁词、记录处理结果。
6. 联网搜索：补充外部信息。
7. 大模型推理：理解、判断、生成报告。

这一层解决的是：系统靠什么能力完成处理。

大模型不是万能机器，它需要 OCR、ASR、RAG、数据库等工具配合。

第三层：业务应用层

这一层是核心加工流水线。

在 AI 面试助手中包括：

1. 简历评估模块。
2. 面试录音分析模块。
3. 面试题生成模块。
4. 批量处理模块。

这一层解决的是：用户具体要做什么业务。

技术组件本身不等于业务。只有把数据、工具和大模型按业务流程串起来，才形成真正的 AI 应用。

第四层：用户入口层

这一层是用户接触系统的地方。

在 AI 面试助手中可能包括：

1. Coze 应用。
2. 豆包入口。
3. API。
4. ChatAPI。
5. 微信小程序。
6. 微信公众号。
7. 内部教学系统。

这一层解决的是：用户从哪里使用系统。

用户不关心底层有多少节点，只关心上传简历以后能否得到清晰、有用的评估报告。

四、更普遍的 AI 项目六层架构

AI 面试助手的四层架构可以继续泛化成更普遍的 AI 项目架构。很多真实 AI 项目都可以按下面六层理解。

flowchart TD
    A["用户入口层<br/>网页 / 小程序 / App / API / 企业微信"] --> B["业务编排层<br/>工作流 / Agent / 路由 / 多智能体"]
    B --> C["模型与工具层<br/>LLM / OCR / ASR / TTS / 搜索 / 代码工具"]
    C --> D["检索与记忆层<br/>知识库 / 向量库 / RAG / Reranker / 会话记忆"]
    D --> E["业务数据层<br/>数据库 / 文件 / 日志 / 用户数据 / 权限数据"]
    B --> F["治理与运维层<br/>权限 / 审计 / 监控 / 评测 / 成本 / 安全"]
    C --> F
    D --> F
    E --> F

1. 用户入口层

用户入口层解决“用户从哪里进来”。

常见入口：

1. Web 页面。
2. 手机 App。
3. 微信小程序。
4. 企业微信或飞书机器人。
5. API 接口。
6. 后台管理系统。

在面试助手中，学生上传简历的入口就属于这一层。

2. 业务编排层

业务编排层解决“任务怎么分步骤完成”。

常见实现：

1. Coze 工作流。
2. Dify 工作流。
3. LangGraph 状态图。
4. 自研后端流程。
5. 多智能体路由。

在面试助手中，简历评估工作流、录音分析工作流、面试题生成工作流都属于这一层。

3. 模型与工具层

模型与工具层解决“每一步靠什么能力处理”。

常见能力：

1. 大模型理解和生成。
2. OCR 文档识别。
3. ASR 语音识别。
4. TTS 语音合成。
5. 联网搜索。
6. 数据库读写工具。
7. 文件解析工具。

在面试助手中，OCR 把简历转文本，ASR 把录音转文字，大模型负责评估和生成报告。

4. 检索与记忆层

检索与记忆层解决“模型依据什么资料回答”和“系统记住什么”。

常见组成：

1. 知识库。
2. 向量数据库。
3. RAG 检索。
4. Reranker 重排。
5. 会话记忆。
6. 用户历史记录。

在面试助手中，简历模板知识库、面试宝典知识库、真实面试题库都属于这一层。

5. 业务数据层

业务数据层解决“系统有哪些结构化业务数据”。

常见数据：

1. 用户信息。
2. 订单记录。
3. 简历记录。
4. 评分结果。
5. 违禁词列表。
6. 调用日志。

在面试助手中，违禁词数据库、学生简历记录、评估结果记录都属于这一层。

6. 治理与运维层

治理与运维层解决“系统上线后是否安全、稳定、可控”。

常见内容：

1. 权限控制。
2. 数据脱敏。
3. 日志审计。
4. 质量评测。
5. 成本监控。
6. 异常报警。
7. Prompt 版本管理。
8. 人工审核机制。

在当前项目中，这一层不会做得很重，但真实工作里非常重要。因为公司不只关心功能能不能跑，还关心数据是否安全、成本是否可控、结果是否可靠。

五、用同一套架构理解不同 AI 项目

例子 1：AI 客服助手

层级	对应内容
用户入口层	官网聊天窗口、企业微信、公众号
业务编排层	意图识别、售前咨询、售后工单、转人工
模型与工具层	大模型、订单查询工具、工单创建工具
检索与记忆层	产品知识库、售后政策、历史对话
业务数据层	用户订单、物流状态、退款记录
治理与运维层	敏感话术拦截、服务质量评估、人工兜底

例子 2：企业知识库助手

层级	对应内容
用户入口层	企业微信机器人、内部网页
业务编排层	问题改写、知识检索、答案生成、引用展示
模型与工具层	大模型、文档解析、搜索工具
检索与记忆层	公司制度知识库、项目文档向量库
业务数据层	员工权限、部门信息、文档元数据
治理与运维层	权限隔离、引用溯源、回答评测

例子 3：AI 数据分析助手

层级	对应内容
用户入口层	BI 页面、内部后台、聊天窗口
业务编排层	理解问题、生成 SQL、执行查询、解释图表
模型与工具层	大模型、SQL 执行器、图表生成工具
检索与记忆层	指标口径知识库、数据字典
业务数据层	业务数据库、数据仓库、报表数据
治理与运维层	SQL 权限、慢查询控制、数据脱敏

六、架构图阅读方法

阅读架构图时，可以按下面顺序理解：

架构图不要从上往下硬背，可以从下往上看。

先看数据与知识层。没有数据，大模型就是空脑袋。

再看 AI 能力支撑层。大模型不是万能的，它需要 OCR 看文档，需要 ASR 听录音，需要 RAG 查资料，需要数据库读写业务数据。

再看业务应用层。真正的项目不是技术堆叠，而是把能力组合成简历评估、录音分析、面试题生成这些业务模块。

最后看用户入口层。用户不关心底层怎么跑，只关心能不能上传材料、拿到结果。

这就是一个 AI 项目的基本思路：底下有数据，中间有能力，上面有业务，最上面有入口，旁边还要有安全、权限、监控和评测。

七、需要记住的结论

1. 架构图不是用来背名词的，而是用来看系统怎么分层协作的。
2. AI 项目不是只有大模型，还需要数据、工具、检索、业务流程和治理。
3. 当前 Coze 项目是一个简化版架构，适合学习和验证 MVP。
4. 真实项目会更重视权限、安全、日志、评测、成本和稳定性。
5. 以后讲项目时，不要只说“我用了 Coze 工作流”，要能说清楚入口、业务、能力、数据和收益。