2026 年6月17日 14:00-17:00，第122期方班学术演武堂（复盘课）在广州大学黄埔校区B1博学楼成功举办，广州大学网络空间安全学院颛孙晨露老师、何郁郁老师以及冯琦颖老师全程参与了课堂教学，并对演武堂教学情况进行了指导点评。同时参与的还有广州大学方班八期的全体学生。

本次演武堂复盘课程分三组进行。第一组的复盘老师是颛孙晨露老师；第二组的复盘老师是何郁郁老师；第三组的复盘老师是冯琦颖老师。

第一组

复盘老师：颛孙晨露老师

颛孙晨露老师主要围绕“如何打造一个优秀的演武堂项目汇报”，通过对优秀学生案例的拆解，从选题、逻辑、架构、实战到总结进行了全流程的指导。

一、选得准：恰当选题与问题导向

1. 选题来源应契合自身研究方向、技术热点或选择高关注度（高Star）的开源项目。若进行自主选题开发，需在首页清晰界定工作量边界（如明确文件数与代码行数）。

2. 坚持问题导向，汇报需清晰说明该项目的行业痛点是什么、现有方案在工程上存在哪些不足，并提供详实的功能性与非功能性需求分析。

二、理得清：背景梳理与逻辑呈现

1. 汇报需建立受众意识，对专业背景与关键技术概念（如 C2 机制）进行通俗且清晰的解释，确保所有听众都能快速理解项目的核心目标。

2. 详细阐明研究动机，包括应用场景与实际意义。同时，必须包含同类竞品分析，明确现有方案的短板与局限性，以此凸显自身项目的价值。

三、拆得细：系统架构与源码剖析

1. 需构建清晰的系统整体架构图。强烈建议个人手绘架构图以加深对系统层级（如四层、六层架构）的深度理解；若使用 AI辅助绘图，必须严格校验其层级逻辑的准确性。

2. 清晰展示项目运行的完整流程。精准说明各个环节的输入输出、用户命令的参数配置、日志生成以及解析过程。

3.进阶要求（源码与算法拆解）：精准定位核心代码与主函数，不仅要理清执行流程，更要求代码与算法模块具备高可维护性与可替换性。需思考若抽离或替换核心算法（如评分机制），系统是否依然能够运转。

四、跑得通：实战复现与结果验证

1. 确保运行环境与数据源的高透明度与可追溯性。需详细说明软硬件配置（如 GPU、内存、大模型架构），且数据集必须有明确的来源，绝不可使用随机生成的数据。

2. 演示过程需具备高度的可验证性。从系统部署到核心功能的交互演示，需详细记录每一步的输入、输出、模式选择，以及成功与失败的具体条件。

3. 重视运行结果的深度分析。不仅要展示系统输出，更要对产出结果（如拦截测试是否成功）进行二次剖析。

五、想得深：项目复盘与高质量互动

1. 具备工程化视角与项目管理意识。鼓励复盘项目的全生命周期，量化各阶段的时间投入与工作量，总结个人在核心算法验证及工程落地中的具体收获。

2. 倡导横向对比与同侪学习。当多人选择同一 Topic 时，应主动对比他人汇报的逻辑结构、切入视角与实战导向，从中汲取经验。

3.提问环节需具备强针对性。建议结合企业导师的背景（如启明星辰的实际业务），针对真实业务环境（如隔离区探针部署、海量数据处理）或后续职业发展需求，提出高质量的工程化问题。

第二组

复盘老师：何郁郁老师

何郁郁老师主要从反面案例（“避坑指南”）的角度，针对同学们在项目汇报中出现的典型问题，从选题、结构、演示、总结反思及排版细节等维度进行了深度剖析。

一、选得偏：选题定位与背景信息的缺失

1.题目表意不清或范围过大：项目名称信息量过少（如仅用缩写），无法让人直观了解项目的核心技术与亮点；或题目宏大空泛（如“僵尸网络探索研究”），未聚焦到具体的样本分析或功能实现上。

2. 缺乏研究动机与竞品对比：未交代为什么选择该项目进行分析，缺失对传统方案局限性的探讨，且在垂直领域内缺乏同类产品的竞品分析，导致项目定位不清晰。

3.项目来源不明与类型不当：未在封面或PPT中注明项目的原始出处（如开源项目或复现论文的来源）；此外，不建议选择偏向纯底层理论而难以进行代码级拆解与工程化呈现的算法类项目。

二、搭得乱：逻辑框架与核心代码的脱节

1. 内容与架构不匹配：汇报的具体内容（如章节拆解）与前期展示的整体架构图严重脱节，未能按照系统的真实运转逻辑进行层层递进的讲解。

2.核心代码解析缺失或呈现粗糙：大篇幅讲解需求与环境部署，却缺失最核心功能的源码分析；或在展示代码时，仅粗暴截取大段代码堆砌，未将具体功能步骤与代码行进行精准的对照解释。

3.章节编排逻辑混乱：目录与正文结构割裂，逻辑跳转突兀（如在架构介绍与日志输出之间生硬插入毫无关联的“策略分析”），导致听众无法理清项目各模块间的逻辑关联。

三、跑得虚：实验演示的敷衍与不完整

1. 前置环境配置缺失：在进入实际演示前，未交代实验环境、系统配置及初始化条件，直接展示运行效果，导致结果缺乏可信度。

2. 演示过程被过度省略或完全缺失：目录中承诺有演示环节但实际内容空缺；或演示过程仅有一句“得出结论”，完全省略了关键的中间交互环节与测试过程。

3.实操避重就轻与测试数据单一：为了逃避复杂环境的搭建（如回避Linux虚拟机），采用替代工具走捷径（如用现成抓包工具替代项目本身的抓包功能）；此外，仅使用开源项目自带的“玩具”数据集跑通流程，未结合自身研究领域引入其他数据集进行深度测试。

四、想得浅：反思缺乏深度与互动准备不足

1. 总结流于表面：反思环节仅停留在“搭环境遇到了什么bug”或“作为初学者学到了很多”的浅层流水账，缺乏对项目本身优缺点及底层机制的深度批判与思考。

2.与企业导师互动缺乏针对性：提问环节未做充分准备，未提前了解企业导师的业务背景与行业现状。提出的问题过于空泛，错失了获取高价值工程化指导及前沿信息的互动机会。

五、做得糙：排版细节与学术严谨性的缺失

1. PPT制作与校对极其不严谨：存在大量明显的“复制粘贴”痕迹，如目录标题与正文页标题不一致、排版比例失调等，反映出演示文稿缺乏打磨。

2. 生搬硬套 AI 生成内容：未经过个人思考与消化，直接照搬大模型生成的结构与套话，导致汇报内容存在明显的“AI感”和逻辑断层，失去了学术汇报应有的严谨态度。

第三组

复盘老师：冯琦颖老师

冯琦颖老师主要针对项目总结与复盘报告的撰写，从“评分维度”切入，通过正反面案例的对比，详细阐述了如何提升学术报告的专业度、逻辑性与“含金量”。

一、写得实：提升报告的“含码量”与技术颗粒度

1. 摒弃空泛表述：在总结项目时，坚决避免使用“实现了数据分类”、“完成了模块检测”等缺乏实质信息的概括性话语。

2. 精准定位核心细节：报告必须具备较高的“含码量”，要求将问题和实现过程精准映射到具体的代码文件、关键类、核心函数以及算法名称（例如明确指出使用了 v5模型）。

3. 确保文档复用价值：技术表达的颗粒度要足够细致，使得任何查阅该报告的人员，都能迅速且精确地 Get 到核心技术点与模块的实际作用关系。

二、盘得严：构建科学严谨的逻辑链路

1. 对标科研报告标准：复盘报告的行文应向严肃的科学报告看齐，避免过于口语化的简略表达，也忌讳毫无重点的冗长论述，强调文字背后的“干货”含量。

2.展现闭环的解题思维：在描述项目难点与改进时，必须呈现完整的逻辑链路：从“发现痛点/提出问题”，到“递归搜索与报错追溯分析”，再到最终落实的“具体解决方案”（如明确说明调整了哪个具体的超参数或迭代次数）。

三、评得准：指标细化与企业反馈的深度转化

1. 评价指标精确量化：不能笼统地描述项目效果，必须将指标细化、具象化（例如明确写出 FT 增速的具体数值、推理效率的提升比例或吞吐量变化）。

2.深挖源码与直击痛点：优秀的报告能够展现对源码的深度挖掘。在实战演练中，能够针对真实的攻防场景（如策略绕过）进行定点剖析与闭环验证（如运用逻辑回归进行二次验证）。

3.高价值的指导转化：能够将企业导师的宏观指导，切实转化为具体的工程优化动作。例如，将指导意见真正落实到垂直领域大模型（LLM）的轻量化改造与性能提升上。

四、避得开：反面案例的表述通病与避坑指南

1. 警惕“假大空”与“无记忆点”：严重缺乏干货，通篇停留在模块表层或堆砌 AI 生成的套话，导致听众或读者看完后完全记不住项目针对的具体痛点。

2.杜绝无根基的“延伸扩展”：在描述后续展望时，诸如“扩展到了其他方向”或“进行了二次开发”等表述，如果没有落实到具体的文件或明确的应用场景，则属于毫无意义的无效表达。

3.建议需具备强“动作指导性”：在分析项目短板或提出改进建议时，不能仅停留在理论层面，给出的建议必须包含具体的执行动作或明确的修改方向，确保后续的项目打磨与迭代有迹可循。

整理：卫凯峰 杨翊

校对：王乐老师 鲁辉老师

责任编辑：鲁辉老师