周江斌｜转正述职完整演讲稿

对应23页述职PPT，每一段先列大纲，再给出可直接讲述的正文。建议按12—15分钟排练，最终时长以实际语速和停顿为准。大纲、页码与文末备答不用朗读。

原始提纲：转正述职PPT演讲大纲。

开场与个人介绍

第1页｜转正述职报告

大纲：问好；说明汇报内容。

各位领导、同事好，我是IT中心的周江斌。今天主要汇报试用期内的业务交付、性能降本和AI研发提效三方面工作，以及转正后的工作规划、团队建设和几点建议。

第2页｜个人介绍

大纲：11年工作经验；4月20日入职；从理解业务到实际交付。

我目前担任PHP开发工程师，有11年工作经验，今年4月20日入职。入职后，我的工作涉及DGJ、SAAS、E站等项目。面对跨系统需求和线上问题，我会先结合代码、数据和日志，了解实际的业务关系，再推进开发或优化。下面重点汇报几项有代表性的成果。

第3页｜目录

大纲：交代四个模块，快速过渡。

这次汇报分为工作回顾、转正后规划、团队建设和意见建议四部分。

第4页｜试用期间工作回顾

大纲：进入成果部分。

先汇报试用期内的主要工作。

试用期核心成果

第5页｜达成的KPI与突出贡献

大纲：业务交付；性能降本；AI提效。总览只概括。

试用期的工作，我归纳为三个方面。业务交付上，重点是三系统订单同步和主导秒杀活动功能。性能与降本上，完成了慢查询、五个项目日志和站管家大表存储的优化。AI使用上，已经融入疑难排查、业务链路梳理和需求开发。下面结合具体项目和前后数据展开说明。

第6页｜三系统订单同步

大纲：订单分布在三个系统，变化需要正确衔接。

订单同步这项工作，涉及E站、DGJ和SAAS三个系统。订单、销售单和履约信息分别在不同系统处理，一个系统发生变化后，其他关联系统也需要按对应规则更新。否则，即使某个接口处理成功，后续业务仍可能因为状态或明细不一致受到影响。

大纲：覆盖六类事件；匹配订单明细；处理消息与订单就绪的先后关系。

这次交付覆盖创建、修改、取消、出库、确认收货和结单六类核心事件。实现中，需要对齐来源订单和明细关系，正确同步商品、金额、地址等信息，也要处理消息已经到达、订单还没有准备好的情况。图中的双向连接表示不同方向的业务交互，并不代表每一类事件都在三个系统之间双向同步。

大纲：价值落在订单与履约衔接。

这项工作的价值，是支持订单从变更到履约的跨系统衔接，减少状态不一致带来的履约阻碍。它也让我进一步理解了不同项目在同一业务中的职责，后续处理相关需求和问题时，能更快找到需要关注的环节。

第7页｜主导秒杀活动功能

大纲：仓库积压商品；通过促销推动采购。

秒杀活动的业务背景，是仓库有较多积压和滞销商品，希望通过促销推动服务站采购，促进这部分商品消化。我主导了秒杀活动功能开发，让活动能够通过系统承接和执行。

大纲：累计出库37,383；日均343；264家服务站；说明统计口径。

从6月23日首笔出库到10月9日，共109天，秒杀商品累计出库量按销售单位汇总为37,383，日均约343，覆盖264家服务站。这里统计的是秒杀商品出库，没有扣除退货，也不能直接等同滞销品的净库存减少。通过这些数据，可以看到功能上线后已经有实际使用，并支持了相关商品流转。

第8页｜MySQL慢查询优化

大纲：两次故障是治理背景；慢查询是其中一项工作。

性能优化方面，7月28日和8月2日，站管家连续出现两次故障。在稳定性治理过程中，我重点参与了慢查询优化，希望减少日常高成本查询给数据库带来的压力。

大纲：6万降至3.5万；减少约41.7%；三类优化方法。

目前日均慢查询数量从约6万降到了3.5万，每天减少约2.5万次，降幅约41.7%。优化主要从三个方向入手：对不合理的查询范围调整业务处理方式；对适合的查询补充索引；对部分重查询改写查询方式，或交由大数据侧处理。不同场景分别选择合适的方案。

大纲：降低数据库压力，不扩大结论。

这项成果反映的是慢查询数量减少。它有助于降低数据库持续承压的程度，但不能直接换算成页面速度提升41.7%，也不代表所有稳定性问题已经解决。

第9页｜五项目日志治理

大纲：五项目治理；日均减少540GB；流量费每天减少110元。

日志治理覆盖DGJ-AI、dgj-robot、dgj、dgj-sale和dgj-vinaudit五个项目。按同样的日均口径，日志量从690GB降到150GB，每天减少540GB，降幅78.3%。对应的流量费从每天265元降到155元，每天减少110元。

大纲：举两个对比；减少低价值日志，保留排障信息。

其中，DGJ从每天140GB降到30GB，dgj-vinaudit从50GB降到16GB。优化时主要减少重复和低价值输出，同时保留排障所需的关键字段。这部分既减少了采集和存储压力，也形成了直接的费用下降。

第10页｜站管家存储优化

大纲：大表清理；释放1,500GB；每月节省1,580元。

除了减少新增日志，我也进行了站管家大表数据清理。治理后，存储容量从3,700GB降到2,200GB，减少1,500GB。月存储费用从3,880元降到2,300元，每月节省1,580元。前面的日志治理是减少持续产生的数据，这项工作则释放已有存储，两部分分别带来了可以量化的降本结果。

第11页｜AI报价链路梳理与改造

大纲：从报价故障进入；AI辅助理解多个入口和完整链路。

AI实践中，比较有代表性的是站管家报价业务梳理。当时排查报价故障，需要了解多个项目的入口，以及Mongo数据更新、消息和任务之间的关系。我结合源码、线上日志和任务配置，让AI辅助梳理，整理了5个项目、6个HTTP入口及对应调用关系，形成入口清单和拓扑。

大纲：梳理结果支撑改造；相关处理统一消息表，再由脚本处理。

理解链路后，对相关销售限价处理进行了统一：原来由MQ回调直接更新的相关处理，调整为先进入统一消息表，再由脚本处理，使记录和处理进度更便于追踪。这说明AI的价值不仅在于帮助阅读代码，也在于加快建立业务认识，并让梳理结果支撑具体改造。

第12页｜AI日常研发应用

大纲：四种场景；减少资料查找与重复分析。

这类用法也融入了日常工作。疑难排查时，我会结合代码、数据库、服务器和Kibana日志分析问题。理解陌生业务时，借助AI梳理入口、调用关系和数据流向。需求开发时，从理解PRD、整理设计方案，到辅助开发和测试点检查，都可以使用。慢查询优化时，也用它辅助分析SQL和比较方案。

大纲：人工负责判断与验证；百分比是估算。

这些场景的共同价值，是减少反复找资料和重复分析，让我更快进入业务判断与实施。AI给出的结论仍需要我结合实际业务核对。页面上的时间节省比例属于估算，目前没有统一的耗时对照统计，所以我不把它当作已经实测的提效成果。后续也希望通过真实任务记录，把效果验证得更清楚。

转正后工作规划

第13页｜转正后工作规划

大纲：由已有成果转入后续方向。

接下来汇报转正后的工作规划。

第14页｜近期目标简述

大纲：风险前置；AI复用；交易库减负；承担更多责任。

转正后，我会继续做好日常业务交付，同时重点推进三个方向：高风险问题提前发现与保护、AI研发方法试点复用、重查询分流与交易库减负。我希望把关注点进一步延伸到系统风险和团队效率，在这些工作中承担更多责任。

第15页｜高风险问题发现前移

大纲：现有告警可能偏晚；先从已出现的问题排优先级。

第一个方向是让高风险问题更早被发现。有些问题告警出现时，连接或进程已经接近耗尽，影响的不只是一个导出任务，还可能是整个系统。因此，我准备先从现有Kibana报错和历史故障着手，结合影响范围和发生频次，优先处理可能影响整体可用性的问题。

大纲：补齐信号；导出并发、重复点击和资源占满的保护。

随后核对哪些风险缺少日志和告警，例如任务超时、执行后没有产出、连接等待和PHP进程占用。对于批量导出、重复点击等场景，联合相关同事推进防重复、任务排队和并发限制。目标是在资源耗尽之前发现异常并采取保护，减少局部问题扩散，保护服务站的正常业务。

第16页｜AI复用与业务服务提效

大纲：需求流程复用；经过确认再开发；沉淀有效方法。

第二个方向是把已经验证有效的AI使用方式整理出来，在小组真实任务中试点。常规需求可以从PRD理解和设计方案开始，包括表设计、各项目修改范围和测试点，经过确认和调整后再开发。临时需求保留必要的方案确认，不强求完整的大文档。遇到执行不下去的情况，也把原因和替代路径留下，方便后续续接。

大纲：服务站反馈分类；案例匹配；减少重复查询。

服务站每天反馈的问题较多，可以尝试用AI辅助分类、匹配已有案例，让研发更快找到相关业务和排查依据，并从重复反馈中发现共性问题。同时，把高频查询和检查整理成工具，减少重复写SQL、找日志和准备环境。这里的重点，是让其他同事也能复用已有方法，逐步验证是否真的节省时间，而不是单纯增加文档数量。

第17页｜重查询分流与交易稳定

大纲：重任务争抢资源；筛选、核对、分流；保护正常交易。

第三个方向是重查询分流。高耗时报表和大批量导出，可能与在线交易争抢资源。我准备优先筛选消耗较高、影响较大的任务，核对业务口径和数据时效，再推进适合的大数据查询或异步导出。异步并不自动消除数据库压力，还需要结合查询优化与并发控制。希望让报表和导出更可控，减少对下单、支付和履约的干扰。

团队建设与意见建议

第18页｜团队建设

大纲：进入团队建设。

除了个人工作，我也希望把已有经验更好地用于团队协作。

第19页｜团队建设

大纲：定期分享；链路沉淀；真实难题协作复盘。

可以定期开展内部分享，围绕真实的问题排查、性能优化和AI案例交流；对跨项目业务，留下关键入口、规则和验证依据；对复杂问题，共同复盘有效方案和走不通的路径。这样同事遇到类似问题时有可参考的经验，也能通过实际问题交流，提升学习效率和团队凝聚力。

第20页｜意见与建议

大纲：基于实际工作的建设性建议。

最后，结合实际工作，我有四点建议。

第21页｜意见与建议

大纲：上线后的业务效果回看。

第一，重点需求可以增加上线后的效果回看。开发前明确希望改善什么业务指标，上线后结合使用数据判断效果。例如秒杀活动，可以看商品出库和服务站参与情况，再决定后续如何迭代。

大纲：服务站反馈推动功能与流程改进。

第二，汇总高频服务站反馈，区分系统缺陷、操作理解和流程问题。除了及时处理单次反馈，也可以和产品、业务一起确定哪些功能或流程值得改进，减少同类问题反复出现。

大纲：跨系统规则提前对齐，减少返工。

第三，涉及多个系统的需求，在开发前对齐状态、数据来源和异常处理口径，减少联调阶段才发现规则不一致造成的返工。

大纲：需求取舍考虑业务收益与维护成本。

第四，评估需求时，除了开发工期，也考虑使用频次、业务收益和维护成本，为优先级取舍提供依据。这些建议可以先从重点需求和高频场景尝试，再根据实际效果调整。

结束与点评

第22页｜请领导点评

大纲：总结；承担更多责任；邀请建议。

以上是我的试用期工作回顾和后续规划。转正后，我会继续做好业务交付，也希望在风险预防、性能降本和AI研发提效方面承担更多责任。请各位领导对我的不足和后续工作重点提出建议。

第23页｜感谢

大纲：简短致谢。

谢谢各位领导和同事。

排练备注与可能的追问

以下内容不纳入正常朗读，只用于准备问答。

数字和成果口径依据已确认PPT及对话。本次编稿未重新查询线上数据，也未调整PPT。原有大纲页继续保留。