Day 35：Week 5 复盘与考试
学习目标
今天是第五周的收官之日，也是检验你这五周学习成果的关键时刻。复盘这个词在工程管理中有着特殊的意义——它不仅仅是回顾做了什么，更重要的是理解为什么这样做、效果如何、以及下一步应该怎么走。在半导体制造的良率提升过程中，每一批晶圆的工艺参数都会被详细记录和分析，工程师通过复盘找出良率波动的根因，然后针对性地优化工艺参数。我们今天对AI系统的复盘遵循同样的逻辑——系统地回顾每一项工程决策，评估其效果，识别改进空间，最终产出一个完整的可演示MVP和配套的评估报告。
复盘的方法论可以借鉴制造业中广泛使用的PDCA循环——Plan（计划）、Do（执行）、Check（检查）、Act（改进）。我们过去几周的学习和开发是Plan和Do阶段，今天的复盘就是Check阶段，而基于复盘结论制定的优化计划则是Act阶段。这个循环不是一次性的，而是持续运转的。每一次迭代都应该比上一次更好，系统应该在持续复盘中不断进化。今天结束后，你应该拥有一个可以对外展示的AI Agent系统原型，以及三份关键文档：Eval评估报告、成本分析报告、以及安全审计报告。
一、工程架构复盘——系统的骨架是否健壮
工程架构是整个AI系统的骨架。在过去几周中，你从零开始搭建了一个完整的AI Agent系统——从最基础的LLM调用到复杂的多轮对话管理，从简单的关键词搜索到基于向量数据库的RAG检索增强生成。现在是时候回头审视这些架构决策是否经得起实际使用的考验了。
架构复盘需要从几个维度来进行。首先是模块化程度。你的系统是否做到了关注点分离？当需要修改检索逻辑时，是否会影响到生成模块？当需要更换底层模型时，是否需要大范围改动代码？如果答案是肯定的，说明系统的耦合度还太高，需要进一步解耦。一个好的架构应该让你能够独立修改、测试和替换任何一个模块，而不影响其他部分。
其次是可扩展性。当你的用户从10个增长到100个、1000个时，系统架构是否能够平滑扩展？你的FastAPI后端能否通过增加工作进程来处理更多的并发请求？你的向量数据库能否通过增加节点来存储更多的文档？你的缓存层能否在更高的并发下保持稳定的命中率？这些问题在当前可能不是紧迫的，但在系统设计阶段就应该有所考虑。就像芯片设计中的可制造性设计（DFM）原则一样，在设计阶段就要考虑未来的制造和扩展需求。
第三是可维护性。当新成员加入团队时，他们需要多长时间才能理解系统的整体架构和代码结构？你的代码是否有足够的注释和文档说明关键的设计决策？你的项目结构是否清晰，让人一眼就能看出每个目录和文件的职责？如果新成员需要花费数周才能开始有效贡献代码，那说明系统的可维护性还需要提升。
在架构复盘的过程中，你还应该检查系统是否有”过度工程”的迹象。过度工程是指为当前不需要的功能预先设计了复杂的架构。比如，如果你的系统目前只有几十个用户，却设计了完整的微服务架构和服务网格，这就是过度工程。过度工程不仅增加了开发和维护的成本，还可能让系统变得不必要的复杂。好的架构应该是刚好满足当前需求并预留合理的扩展空间，而不是试图预测所有可能的未来需求。
架构复盘的最后一步是画一张更新后的系统架构图。这张图应该准确反映系统的当前状态，而不是计划中的理想状态。架构图是团队沟通的重要工具——它确保所有人对系统的理解是一致的。在架构图上标注每个组件的技术选型、部署方式、以及组件之间的数据流向。这张图也将成为你后续迭代的重要参考基线。
在半导体制造的企业环境中，架构复盘还需要考虑一个现实的问题——与现有IT基础设施和工具链的集成深度。你的AI系统不是独立存在的，它需要嵌入到工程师的日常工作流程中。架构复盘时应该检查系统是否能够与团队已经习惯使用的工具（如飞书、企业微信、JIRA等）顺畅集成。如果工程师需要离开他们日常使用的工具，专门打开一个新系统来使用AI助手，使用率很可能会大打折扣。好的架构设计应该让AI能力”无处不在”——嵌入到用户已有的工作流中，而不是要求用户改变工作习惯来适应新系统。
二、Prompt管理复盘——AI行为的指挥棒是否精准
Prompt是你与AI模型沟通的桥梁，Prompt的质量直接决定了系统输出的质量。在过去几周的学习中，你编写了多种类型的Prompt：系统级的角色设定Prompt、检索查询生成Prompt、回答生成Prompt、质量检查Prompt、以及自动评分Prompt。现在是时候系统地复盘这些Prompt的效果了。
Prompt管理复盘的第一步是梳理你所有的Prompt资产。你可能惊讶地发现，一个中等复杂度的AI系统中，活跃使用的Prompt可能有二三十个之多。这些Prompt散落在不同的代码文件中，如果没有统一的管理机制，很容易出现版本混乱、重复定义、甚至互相矛盾的情况。你需要建立一个Prompt注册表，记录每个Prompt的用途、当前版本、最近修改日期、以及依赖它的功能模块。
第二步是评估每个Prompt的稳定性和可预测性。一个好的Prompt应该在大多数情况下产生一致的、符合预期的输出。你可以通过批量测试来评估稳定性——用同一组输入反复运行同一个Prompt，检查输出的波动程度。如果波动很大，说明Prompt的指令不够明确，模型在执行时有较大的自由发挥空间。在某些场景下这种自由度是好事（比如创意写作），但在工程应用中，稳定性和可预测性通常比创意性更重要。
第三步是检查Prompt之间的协作是否顺畅。在Agent系统中，多个Prompt通常需要协同工作——一个Prompt的输出可能成为另一个Prompt的输入。如果第一个Prompt的输出格式不稳定，第二个Prompt可能无法正确解析输入，导致整个链路失败。你需要检查所有Prompt之间的接口定义是否清晰、格式约束是否明确、以及错误处理是否完善。
在半导体制造的AI系统中，Prompt复盘还有一个特殊的角度——专业术语的使用是否准确和一致。半导体行业有大量专业术语，而且不同公司甚至不同产线对同一概念的叫法可能不同。你的Prompt中使用的术语是否与目标用户的习惯一致？比如，有的团队说”晶圆”，有的说”硅片”，有的说”圆片”。如果Prompt中的术语与用户的使用习惯不一致，可能导致检索遗漏或理解偏差。
Prompt复盘的输出应该是一份Prompt优化清单，列出所有需要改进的Prompt及其具体问题。按照影响程度排序，优先优化那些对系统输出质量影响最大的Prompt。对于每个需要优化的Prompt，记录当前版本的问题描述、优化方案、以及预期的改进效果。这份清单将指导你下一轮的迭代优化工作。
在Prompt复盘过程中，还有一个非常实用但常被忽略的做法——建立Prompt版本管理机制。每次修改Prompt时，记录修改内容、修改原因、以及修改前后的效果对比数据。这种版本记录不仅帮助你追踪Prompt的演变历史，还能在某个修改导致效果退化时快速回退到之前的版本。在实际项目中，Prompt的迭代频率可能远高于代码的迭代频率，一套好的版本管理实践能够显著降低迭代的风险和成本。你可以把所有Prompt集中管理在一个配置文件或数据库中，而不是散落在代码的各处，这样版本管理和对比分析都会方便很多。
三、Eval复盘——评估体系是否有效指导了质量提升
昨天你花了整整一天建立Eval评估体系，今天是检验这套体系是否真正有效的时候。一个有效的Eval体系应该能够帮助你快速发现问题、准确定位问题根因、以及客观评估改进效果。如果Eval体系本身存在缺陷——比如测试集不够全面、评分标准不够清晰、或者评分结果与实际体验不一致——那么它不仅不能帮助你提升质量，还可能误导你的优化方向。
Eval复盘首先要检查测试集的覆盖度。回顾你建立的50条测试集，它们是否覆盖了系统实际使用中的主要场景？有没有遗漏某些重要的查询类型？在半导体制造的AI助手中，常见的查询类型包括：单文档事实查询（如”设备X的最大功率是多少”）、跨文档推理查询（如”对比A方案和B方案的良率差异”）、操作指导查询（如”如何执行设备Y的季度维护”）、数据分析查询（如”上周的异常停机次数趋势”）、以及边界情况和异常查询。你的测试集是否在这些类型上都有充分的覆盖？
其次是检查评分标准与实际体验的一致性。你可以选取一批测试样本，分别进行自动评分和人工评分，然后对比两种评分结果的差异。如果自动评分和人工评分之间有较大的系统性偏差——比如自动评分总是比人工评分更宽松——那么自动评分的标准可能需要调整。同时检查评分结果的可区分性——好的回答和差的回答之间是否有明显的分数差异？如果所有回答的分数都集中在很窄的范围内，说明评分标准的区分度不够，无法有效识别质量问题。
第三是检查Eval体系的反馈循环效率。当你发现某个测试用例的得分较低时，你能够多快地定位问题并实施改进？如果从发现低分到确认根因需要很长时间，说明Eval报告的诊断信息不够充分。一个好的Eval报告不仅告诉你”哪里有问题”，还应该帮助你理解”为什么有问题”以及”应该怎么改”。
Eval复盘还需要评估Eval本身的运行成本。运行一次完整的Eval需要消耗多少Token？需要多长时间？如果Eval本身的成本过高或耗时过长，团队可能会减少运行Eval的频率，这反而会影响质量保障的持续性。你可能需要设计一个”快速Eval”版本——只包含最关键的测试用例，能够在几分钟内完成，用于日常迭代时的快速验证。
还有一个值得深入思考的Eval策略问题——你的测试集是否需要随着业务发展持续更新？答案是肯定的。在半导体制造的实际运营中，新的工艺规范不断发布，新的设备型号不断引入，旧的测试用例可能逐渐失去代表性。你需要建立一个测试集维护机制：定期从线上真实查询中选取有代表性的样本补充到测试集中，同时淘汰过时的测试用例。一个好的测试集应该像良率监控系统一样，始终反映当前的生产实际。理想的做法是每月对测试集做一次审查，评估其覆盖率是否仍然充足，是否需要补充新的场景类型。
四、成本优化复盘——花出去的每一分钱是否值得
成本优化复盘是对你的AI系统经济效益的全面审视。在之前的学习中，你学会了如何统计和分析系统成本。现在你需要把这些分析结果汇总成一份完整的成本报告，评估系统在当前架构下的经济可持续性。
成本复盘的第一步是建立成本基线。统计过去一周或两周的系统运行数据，计算以下指标：平均每个查询的总成本（包括模型调用、向量检索、缓存等所有环节）、平均每个查询的Token消耗（分别统计输入和输出Token）、不同类型查询的成本分布（简单查询和复杂查询的成本差异）、以及成本随时间的变化趋势（是否有异常的成本波动）。
第二步是分析成本结构。在你的系统中，哪部分是最大的成本驱动因素？是模型调用的Token费用，还是向量数据库的运维成本？是Rerank的计算费用，还是存储和带宽成本？理解成本结构是制定有效优化策略的前提。如果你发现模型调用占了总成本的80%，那么优化检索策略、减少不必要的模型调用是最有效的降本手段。如果向量数据库的运维成本占比很高，那么考虑更轻量的向量数据库方案可能是更好的选择。
第三步是评估之前实施的成本优化措施的实际效果。你在Day 32设计的模型路由策略是否有效降低了平均查询成本？缓存机制的实际命中率是多少，为你节省了多少成本？低成本模式和高质量模式的使用比例是否符合预期？用实际数据来验证优化措施的效果，而不是依赖理论估算。
成本复盘还需要考虑一个更深层次的问题：成本与价值的关系。在半导体制造中，工程师使用AI系统查找信息、生成报告、辅助决策，这些活动带来的价值是什么？如果AI系统帮助一个工程师每天节省一小时的文档查找时间，按照工程师的时薪计算，这每天就是数百元的价值。如果AI系统帮助避免了一次工艺错误，可能避免的损失是数十万甚至数百万。把AI系统的成本与它创造的价值放在一起看，你才能判断这笔投入是否值得。
成本报告的最后应该包含一个成本预测模型——基于当前的使用数据和增长预期，预测未来三个月到一年的系统运营成本。这个预测可以帮助管理层做出预算规划，也可以帮助你提前识别潜在的成本瓶颈并制定应对策略。
五、安全权限复盘——防线是否有漏洞
安全权限复盘是整个复盘过程中最不能掉以轻心的环节。安全问题的特殊性在于，99天的安全运行不能保证第100天不出问题，但一次安全事故就足以摧毁用户对系统的全部信任。在半导体行业这种对信息安全和知识产权保护极度敏感的领域，安全权限复盘的重要性怎么强调都不过分。
安全复盘的第一步是回顾安全架构设计。你在Day 33设计的安全权限方案是否已经完整实施？有没有因为时间压力而跳过的安全措施？特别检查以下几点：用户权限验证是否在每个查询处理时都正确执行？文档权限过滤是否在检索阶段就生效？高风险操作确认机制是否已经接入所有必要的工具？审计日志是否记录了所有关键操作？
第二步是进行安全测试。设计一组专门的安全测试用例来验证系统的安全防护能力。这些测试应该包括：越权访问测试——用一个低权限账号尝试访问高权限才能看到的信息。Prompt注入测试——尝试通过精心构造的输入来绕过系统的安全限制。数据泄露测试——检查不同用户的查询结果中是否包含不属于当前用户的信息。工具滥用测试——尝试通过正常或异常的方式触发不应该被触发的工具操作。
第三步是审查审计日志。分析过去一段时间的审计日志，查找异常模式。比如：是否有用户频繁访问与其角色不匹配的文档？是否有大量权限拒绝记录（可能意味着权限配置有问题，也可能意味着有人在尝试越权访问）？是否有异常的操作时间模式（比如非工作时间的频繁查询）？
安全复盘还应该评估安全措施的”可用性影响”。安全措施是否让系统的正常使用变得显著不便？如果工程师因为安全限制而无法及时获取需要的信息，这种安全措施在保护信息的同时也损害了工作效率。理想的安全措施应该是”透明的”——在保护核心资产的同时不增加正常使用的摩擦。如果安全措施导致了明显的效率下降，你需要重新思考安全设计的平衡点。
安全报告应该包含安全架构概述、已实施的安全措施清单、安全测试的结果、发现的安全问题及修复建议、以及后续的安全改进计划。这份报告应该由安全负责人审核签字，作为系统安全状态的正式记录。
安全复盘还有一个长远价值——它为建立团队的安全文化奠定了基础。在半导体行业中，安全意识已经成为每一位工程师的基本素养，无论是生产安全还是信息安全，都需要全员参与和持续关注。通过定期的安全复盘，你可以让团队成员逐步建立起对AI系统安全风险的敏锐感知，这种集体安全意识的提升比任何单点的技术措施都更有价值。当团队中每个人都能在日常工作中自觉地考虑安全问题时，系统的整体安全性就会得到根本性的保障。
六、部署复盘——上线是否顺利，运维是否顺畅
如果你已经按照Day 34的指导完成了系统部署，那么现在是复盘部署过程的好时机。部署复盘关注的是：部署流程是否顺畅？部署后系统是否稳定运行？运维过程中遇到了哪些问题？
部署复盘首先要回顾部署过程中遇到的问题。哪些步骤比预期更复杂？哪些配置导致了意外的错误？部署花了多长时间？如果需要重新部署一次，流程是否可以简化？这些反思将帮助你优化部署文档和自动化脚本，让未来的部署更加顺畅。
其次是检查部署后的系统稳定性。系统上线后的正常运行时间是多少？有没有出现过意外的服务中断？有没有遇到过性能瓶颈导致响应变慢？这些信息可以从健康检查日志和监控面板中获取。
在半导体制造环境中，部署复盘还需要考虑与现有IT基础设施的兼容性。你的AI系统是否需要通过公司内部的网络代理才能访问外部API？是否需要特殊的防火墙规则才能正常工作？是否需要在公司的容器注册表中注册你的Docker镜像？这些企业IT环境的特殊要求往往在技术文档中找不到明确的说明，需要在实际部署中逐步发现和解决。
部署复盘的输出应该是一份经过实践验证的部署指南——不同于Day 34编写的理论版部署文档，这份指南包含了实际部署中遇到的问题和解决方案。同时记录部署的完整步骤和每一步的预计耗时，为未来的部署提供更准确的时间和资源预估。
此外，部署复盘也是检查你的灾难恢复能力的好时机。当系统出现严重故障需要从头重建时，你能否在可接受的时间范围内完成恢复？你的数据库备份是否经过验证可以成功恢复？你的配置是否全部通过环境变量管理，不需要手动重新配置？在制造业的连续生产环境中，系统不可用的时间越长，造成的业务影响越大。建议在复盘期间实际执行一次灾难恢复演练，记录恢复的完整过程和耗时，找出可以改进的环节。
今日实践任务——综合考试
今天的实践任务是整个第五周的综合考核，要求你产出一个完整的可演示MVP和配套的报告。
第一项任务是完成一个可演示的MVP。这个MVP应该能够端到端地展示你的AI Agent系统的核心能力：接收用户查询、执行文档检索、生成高质量回答、处理工具调用、以及生成结构化报告。准备至少三个演示场景，覆盖系统的不同能力维度。如果可能，使用真实的半导体制造文档作为知识库内容，让演示更有说服力。
第二项任务是运行完整的50条测试集。使用你在Day 31建立的Eval体系，对所有50条测试用例运行评估。记录每条测试在各维度的得分，计算各维度的平均分和分布情况。识别得分最低的测试用例，分析失分原因。
第三项任务是输出Eval评估报告。报告应该包含：测试集概述（覆盖的场景和分布）、各维度的评估结果（平均分、分布、趋势）、典型问题案例分析（好的案例和差的案例各选几个做详细分析）、主要问题模式总结（哪些类型的问题系统处理得不好）、以及改进建议（针对每个主要问题提出具体的优化方案）。
第四项任务是输出成本分析报告。报告应该包含：成本基线数据（平均查询成本、Token消耗分布）、成本结构分析（各环节的成本占比）、成本优化措施效果评估（路由策略、缓存机制等的实际效果数据）、成本预测模型（未来三个月的成本预估）、以及成本与价值分析（系统成本与创造价值的对比）。
第五项任务是输出安全审计报告。报告应该包含：安全架构概述、已实施的安全措施清单、安全测试结果（越权测试、注入测试、数据泄露测试的结果）、审计日志分析结论、已知安全风险及缓解措施、以及安全改进路线图。
这五份产出（可演示MVP加三份报告）构成了你AI Agent系统的第一版正式交付物。它们不仅是你个人学习成果的证明，也是向团队和管理层展示项目价值的工具。记住，一个好的技术项目不仅需要技术本身过硬，还需要能够向非技术人员清晰地传达项目的价值和状态。这些文档就是你最有效的沟通工具。
最后，在完成所有复盘和考试任务之后，建议你花一些时间做一次个人学习回顾。回顾这五周的学习历程，从第一天的LLM基础调用到今天的完整系统复盘，你经历了怎样的认知变化？哪些知识点的理解发生了根本性的转变？哪些实践经验是你之前完全没有预料到的？把这些思考记录下来，它们将成为你后续继续深入学习和实践的最宝贵的参考资料。AI技术发展迅速，具体的工具和框架可能很快就会过时，但系统化的思维方法和工程实践能力是长期有效的。今天的复盘不仅是对项目的复盘，也是对你自身学习方法和成长路径的一次深度反思。