自我介绍与教材项目讲稿

这些是参考口述稿，不是替本人补充经历。历史部分只使用最新版简历已记载内容；关于本次学习系统的实验，应在本人实际完成并能解释后使用。没有历史量化证据，不加入“效率提升几倍”“准确率多少”等数字。

60–90 秒自我介绍

我叫黄健科，有十余年软件研发经验，做过全栈开发、跨端架构设计和技术团队管理，最近的工作重点是 AI 应用开发。

在 HanLink 国际中文教育平台，我负责相关 AI 功能及所负责功能的全栈开发。其中教材生成与审校是我这次希望重点介绍的项目：用 LangGraph 编排生成和评审两个角色，通过结构化数据、RAG、地区规则和配套素材流程，把模型能力接入教研制作过程。教材通常由系统生成和评审，再由教研复核，审核通过后用于学校教学。

另外，我做过口语对话、拍照学习和 MQTT 多端互动课堂。更早的经验包括 Web 架构、Flutter 混合架构、组件化和持续集成，也维护过 Flutter 组件与开发工具等开源项目。

我希望应聘资深 AI 应用研发岗位。我的优势是能够把模型调用与业务状态、异常处理和交付流程结合起来；对于 Agent 相关原理，我也在通过独立的学习复现与实验补齐理解，可以结合具体代码和故障场景展开交流。

**使用说明：**最后一句可以在完成学习后改成自己已经验证的具体能力，但不要把正在学习说成已经精通。若岗位更重后端，减少跨端名词；若更重全栈 AI，保留端到端交付说明。

**STAR 骨架：**S 是海外中文教学平台；T 是相关功能的全栈与 AI 研发责任；A 是教材、学习与课堂功能的实现方法；R 只使用简历明确描述的交付状态。

教材项目两分钟版本

这个项目解决的是海外中文教材的内容生产问题，范围包括课文、词汇、练习和配套素材，不是学校管理系统。

我在 HanLink 负责教材生成与审校系统研发。核心思路是把“生成内容”和“检查内容”分开：生成角色负责初稿与局部修改，评审角色独立检查，两者分别构建上下文并配置工具权限。LangGraph 负责组织生成、评审、修订和复审，教材与评审报告通过 JSON Schema 约束结构。

生成前会按教学等级、语言和地区检索资料，保留来源；同时加载术语和地区文化规则。这里检索资料提供参考依据，必须遵守的规则不能只依赖相似度检索。内容通过审核后，再通过受控工具调用制作图片、配音和视频，异步任务处理依赖与失败恢复，并在内容变化后更新受影响素材。

历史项目的结果是，教研通常从系统生成、评审后的内容开始复核，审核通过的教材供学校教学使用。我没有准确的历史降本或质量提升比例，所以不会补造数字。

为了深入解释实现，我会把历史项目与本次学习复现分开。复现重点验证局部修订、人工处理、状态恢复和旧素材不能覆盖新版本。我可以从一份任务记录出发，说明每个数据怎样流转，以及异常时为什么这样处理。

**面试官最可能接着问：**Agent 的代码形态 → Q01；规则与 RAG → Q07；恢复与旧结果 → Q11、Q15。

**STAR 对照：**前两段说明 S/T；第三、四段展开 A；最后两段分别给出有依据的历史 R 和学习复现的验证范围。实际语速不同，可删去一种素材类型以控制在两分钟左右。

教材项目五分钟版本

我先说明业务背景和事实范围。HanLink 是面向海外中文教学的平台，我负责其中教材生成与审校系统研发。系统关注教材内容本身，包括课文、词汇、练习及配套素材。历史项目已经提供了这些能力；我另外使用本次学习复现系统研究实现机制，后面引用的实验会明确属于复现，不会当成过去的生产指标。

业务上最重要的不是让模型写出一篇通顺文章，而是让内容符合教学等级、地区和语言要求，问题可定位，修改有范围，最终由教研确认。输入除了主题，还需要等级、目标语言、地区和内容要求。生成之前先检索资料并加载规则：检索结果保存来源和版本，术语、人物设定与地区要求作为显式约束。这样既能回答“根据什么写的”，也能回答“必须遵守什么”。

生成和评审是两个职责不同的角色，不一定是两个不同模型，也不等于必须部署两个服务。生成角色拿到任务、资料和规则，输出结构化教材。评审角色重新构建上下文，以候选教材和证据为基础检查，不能直接继承生成者的自我评价。服务端分别限制工具权限，避免仅凭 prompt 约束行为。

评审报告需要包含问题位置、类别、严重程度、依据和修订要求。比如某一道练习答案错误，要定位到那道题，而不是只给一句“请优化内容”。局部修订基于确定版本和允许修改范围，由程序校验并生成新版本，保留未受影响部分，再进行复审。如果问题无法自动解决，或者达到修订上限，就进入人工处理。人工通过、退回、终止和恢复是不同操作，都应绑定明确的内容版本。

我用 LangGraph 组织这些状态、分支和循环。这里需要特别区分三件事：Checkpoint 保存流程恢复所需状态，业务数据保存教材与审核版本，后台任务管理素材执行。Checkpoint 不能替代数据库里的版本，也不能保证外部服务只执行一次。比如图片服务实际成功，但本地收到超时，系统不能简单认为“没执行”然后无限重试；需要看供应商是否提供幂等和结果查询，无法确认时保留结果不明状态。

素材阶段也是相同思路：模型提出工具调用请求，服务器校验并安排任务，图片和 TTS 服务真正执行，视频可以由图片、配音和字幕通过 FFmpeg 本地合成。图片、音频和视频之间有依赖。文本修改后按输入指纹判断哪些素材受影响；任务结果写回时检查版本与执行身份，防止旧任务覆盖新内容。交付前还要核对文件和清单，不能只有数据库状态写“成功”。

历史结果可以确定的是，教材通常由系统生成、评审后交给教研复核，审核通过用于学校教学。至于模型质量、延迟和成本，本次学习系统通过固定样本和验收场景记录，不新增历史数字。演示模式用于验证流程和异常控制；真实模式还需验证服务接口和输出质量。我的学习验收是能打开代码，修改规则，复现故障并解释结果，而不是只演示一次顺利生成。

**练习方法：**把这份稿压缩成六个提示词：业务、证据、双角色、修订、恢复、交付。第二遍只看提示词讲，不背逐字稿。若面试官在第三段打断，直接进入题库，不必坚持讲完整篇。

**STAR 对照：**S 是内容生产与教研复核背景；T 是可控的生成审校与素材交付；A 是证据、角色、版本和任务四条设计主线；R 分开使用历史交付事实与实际复现记录。

深入讲解版本：10–15 分钟带证据演示

这个版本不是更长的术语清单。围绕一份具体任务逐步打开数据，建议只选择一章，包含一次可解释的局部修订。没有跑过的步骤明确说设计目标，不展示预造“成功日志”。

时段	展示对象	核心讲解	对应追问
0–1 分钟	输入与范围	为什么教材不是自由作文；语言和地区分开	Q01、Q07
1–3 分钟	检索结果和规则	来源、片段、版本；参考资料与强制规则	Q05、Q06、Q07
3–5 分钟	初稿和两个角色上下文	结构校验、独立评审和权限	Q02、Q03、Q09
5–7 分钟	评审问题与修订差异	稳定 ID、允许路径、基线版本	Q10
7–9 分钟	人工决定与流程状态	上限、暂停、恢复与三类持久化	Q11、Q12
9–12 分钟	素材任务及交付清单	依赖、输入指纹、超时、迟到结果	Q13、Q14、Q15
12–15 分钟	验收与评测报告	哪些已验证、证据范围、哪些仍未知	Q16、Q24

1. 输入与证据：先解释模型知道什么

口述示例：“这里的主题、等级、语言和地区组成任务约束。检索结果不是一个无来源字符串，而是可以追到文档和片段版本的证据。规则单独加载，所以不会因为 top-k 没命中就忘记术语要求。此处只证明来源可追溯，内容是否支持最终结论还需评审。”

**STAR｜学习复现：**S：候选教材需要特定资料范围；T：可追溯地构建上下文；A：展示检索与规则记录；R：以能回查原文和版本作为本次证据。若检索为空，展示人工处理原因，不换成另一个成功样例掩盖问题。

2. 初稿与评审：展示数据契约，而不是只展示文字

口述示例：“初稿先满足结构契约，再接受内容检查。评审角色看到教材和证据，生成角色的自评不会成为评审依据。这条问题报告定位到具体练习，有类别、严重程度、依据与修订要求，所以后续可以局部处理。”

**STAR｜学习复现：**S：故意加入一处业务错误；T：验证评审能定位；A：展示问题条目及其依据；R：如果检测失败，报告漏检并分析，不能把手动修好的结果冒充模型发现。

3. 修订与版本：解释程序为何仍然重要

口述示例：“模型负责提出修改，程序负责限制修改范围并验证基线。这里旧版本仍保留，新版本只改变允许位置。若人工已经改过同一版本，自动修订不能最后写入覆盖。”

**STAR｜学习复现：**S：单点错误需要修复；T：保持其他内容不变；A：比较版本差异与受控修改范围；R：以差异和复审结果为证据。不要仅说‘prompt 已要求只改一处’。

4. 人工处理与恢复：先给失败窗口

口述示例：“我把图恢复、业务版本和任务恢复分开。等待人工时重启，与外部请求已执行但本地未保存，是不同故障。前者依赖持久 checkpoint 和线程身份，后者还需要业务幂等和外部结果核对。”

**STAR｜学习复现或假设：**S：选择报告中实际验证过的一个中断窗口；T：保持版本与任务状态可解释；A：展示重启前后记录；R：只说观察到的恢复行为。未测窗口作为限制，不能笼统说“支持所有失败恢复”。

5. 素材与交付：检查“成功”是否有真实文件

口述示例：“这个视频依赖明确的图片和音频结果。修改文本会使部分输入指纹变化，只有受影响任务需要更新。迟到结果必须检查任务执行身份和内容版本；最后的交付清单说明实际用了哪些文件，而不是只标一个成功状态。”

**STAR｜学习复现：**S：内容更新期间旧任务返回；T：防止旧结果覆盖新版本；A：展示拒绝旧提交或保留为历史资源的记录；R：以当前清单保持正确关联为证据。演示素材明显标注模拟来源。

6. 验证与局限：把结论收在证据范围内

口述示例：“这份报告区分了演示流程、真实基础设施、真实外部服务和未验证项。固定评测样本用于比较方案，并不代表生产用户分布。我最确定的结论是报告中实际验证的不变量；仍需进一步确认的是真实服务能力和目标部署环境表现。”

**STAR｜学习复现：**S：需要评估系统是否可学习和复现；T：让每条主张有证据；A：对照覆盖矩阵与验收记录；R：明确哪些完成、哪些失败或未测。若自己尚未亲自复验，要说“交付报告记录”，而不是“我测得”。

面试前需要本人补充的历史证据

这些信息不在当前简历中，不影响理解复现系统，但会影响历史项目追问的准确性：

• 实际使用过的模型/供应商、版本和使用时期，以及自己负责的适配范围。
• 历史项目中持久化、重试、素材失效和一致性检查的具体实现，是否与复现方案相同。
• 一次能够核实的困难、本人决策、验证方式及结果；没有就使用假设分析，不编事故。
• 可公开说明的协作分工、教研审核方式和交付流程，不泄露公司资料。
• 开源项目中本人能深入解释的提交、API 设计和维护案例。

补充时按证据改写讲稿，不按“听起来更资深”增加经历。遇到尚未核对的追问，可以说：“这个历史细节我需要核对；如果讨论我现在的复现设计，我可以具体说明。”