对应版本：2026年10月10日确认的23页述职PPT。建议汇报12—15分钟。本稿是排练大纲，不是需要逐字朗读的全文稿。
汇报主线：试用期重点完成业务交付、性能降本和AI研发提效三方面工作。转正后继续做好需求交付，并承担更多风险预防与研发方法复用工作。
快速导航与时间安排
| 模块 | PPT页码 | 建议时间 |
|---|---|---|
| 开场与个人介绍 | 1—4 | 约1分钟 |
| 试用期成果 | 5—12 | 约7分钟 |
| 转正后工作规划 | 13—17 | 约4分钟 |
| 团队建设与建议 | 18—21 | 约1.5分钟 |
| 结束与点评 | 22—23 | 约20秒 |
分隔页直接过渡，不单独展开。时间为排练参考，可根据现场压缩。
一、开场与个人介绍
第1页｜转正述职报告
讲述重点：问好，说明汇报结构，不提前罗列全部成果。
开场参考：
各位领导、同事好，我是IT中心的周江斌。今天主要汇报试用期内的业务交付、性能降本和AI研发实践，以及转正后准备进一步推进的工作。
第2页｜个人介绍
- PHP开发工程师，总工作年限11年，2026年4月20日入职。
- 入职后逐步熟悉DGJ、SAAS、E站等项目与跨系统业务。
- 工作方式：结合代码、数据和日志理解业务，再推进开发与优化。
提醒：不讲经历流水账，也不将“熟悉多个项目”当作最终成果。
第3—4页｜目录与试用期回顾
简单交代结构，进入成果。目录和分隔页合计约15秒。
二、试用期核心成果
第5页｜达成的KPI与突出贡献
只概括三条主线，约40秒：
- 业务交付：三系统订单同步、主导秒杀活动功能。
- 性能降本：慢查询数量减少、日志治理、大表存储优化。
- AI提效：用于疑难排查、业务链路梳理、需求设计与开发。
下面我分别用具体项目和前后数据，说明这些工作带来的变化。
第6页｜三系统订单同步
约1分钟，按“背景、交付范围、业务价值”讲。
- 背景：订单与履约信息分布在E站、DGJ、SAAS，一个订单的变化需要在关联系统正确衔接。
- 范围：创建、修改、取消、出库、确认收货、结单六类核心事件。
- 实际工作：订单与明细匹配，商品、金额和地址同步，处理消息到达与订单就绪的先后关系。
重点是让订单变更与履约信息在关联系统正确衔接，减少状态不一致造成的履约阻碍。
讲图提醒：系统存在不同方向的事件交互，不代表所有事件或全部数据都双向同步。不逐一介绍接口与消费者。
第7页｜主导秒杀活动功能
约1分钟。
- 背景：仓库存在较多积压、滞销商品，通过秒杀促销推动服务站采购，促进商品消化。
- 工作：主导秒杀活动功能开发。必要时挑一个真实难点说明，不展开开发清单。
- 数据：统计期内秒杀商品累计出库37,383，日均约343，覆盖264家服务站。
- 图表：说明上线后的实际参与和商品流转。
相比只说明功能开发完成，我希望通过上线后的出库和参与数据，说明它实际支持了商品流转。
口径：2026年6月23日至10月9日，共109天；按商品销售单位汇总，未扣退货。不能说“净消化37,383件滞销库存”。
第8页｜MySQL慢查询优化
约1分钟，先讲结果，再讲方法。
- 背景：两次故障推动稳定性治理，慢查询优化是其中一项工作。
- 结果：日均约6万降至3.5万，每天减少约2.5万次，降幅约41.7%。
- 方法：调整业务查询范围、补充合适索引、改写查询方式，适合的重查询交由大数据侧处理。
通过减少高成本查询，降低数据库持续承压的程度。
提醒：不要逐条罗列SQL，不将慢查询数量下降等同页面响应时间下降41.7%，也不声称解决了所有事故原因。
第9页｜五项目日志治理
约50秒。
- 范围：DGJ-AI、dgj-robot、dgj、dgj-sale、dgj-vinaudit。
- 日均日志量690GB降至150GB，每天减少540GB，降幅78.3%。
- 流量费265元/日降至155元/日，每天减少110元。
- 例子选两个：DGJ 140GB/日降至30GB/日，dgj-vinaudit 50GB/日降至16GB/日。
主要压缩重复、低价值的日志，同时保留排查所需的关键业务信息，兼顾成本和排障需要。
提醒：不把现有日志降量直接归因于AI。
第10页｜站管家存储优化
约40秒，只讲存储。
- 大表数据清理降低存储占用。
- 容量3,700GB降至2,200GB，减少1,500GB。
- 月存储费用3,880元降至2,300元，每月节省1,580元。
日志治理减少持续产生的数据量，大表清理释放已有存储，两部分分别形成了可量化的降本结果。
第11页｜AI报价链路梳理与改造
约1分钟，从真实问题进入。
- 站管家报价故障排查需要理解多个项目、业务入口和后台处理之间的关系。
- AI结合源码、日志与任务配置，辅助梳理5个项目、6个HTTP入口及调用关系，形成入口清单与拓扑。
- 在理解链路后，相关销售限价处理统一到消息表，再由脚本处理，便于追踪处理记录。
AI帮助我更快建立跨项目的业务认识，梳理结果进一步支撑了实际改造，而不只是生成一份说明文档。
提醒：只讲具体改造范围，不扩大为整个报价系统全部改造完成。
第12页｜AI日常研发应用
约1分钟，围绕四类使用场景。
| 场景 | 实际用法与价值 |
|---|---|
| 疑难排查 | 关联代码、数据库、服务器及Kibana日志，减少反复查找 |
| 链路梳理 | 整理入口、调用关系和数据流向，更快了解业务与修改影响 |
| 需求开发 | 理解PRD、整理方案，确认后开发，并辅助整理测试点 |
| 性能优化 | 分析慢SQL、比较方案，减少无效尝试 |
AI承担资料整理、关联分析和方案辅助，我负责业务判断、方案确认和结果验证。
重要：PPT中的时间节省比例是估算、不是实测。不要按已验证成果讲；若被问起，明确尚未做统一耗时对照统计。
三、转正后工作规划
第13—14页｜工作规划总览
约40秒，三个方向：
- 高风险问题提前发现与保护。
- AI方法在真实任务中试点复用。
- 重查询分流，减少交易库压力。
转正后，我希望在继续做好日常交付的同时，把关注点进一步延伸到系统风险、跨项目业务理解和团队研发效率。
提醒：不作绝对月份承诺，不将计划讲成已经完成。
第15页｜高风险问题发现前移
约1分钟。
- 有些告警出现时，资源已经接近耗尽，需关注导出并发、重复点击、连接等待和PHP进程占满等风险。
- 从现有Kibana报错和历史故障整理风险，按业务影响确定优先级。
- 补齐日志、资源信号和任务异常信号。
- 对高风险任务增加防重复、排队和并发保护。
希望在局部任务拖垮整体系统之前发现异常并采取保护，减少服务站正常业务受到的影响。
第16页｜AI复用与业务服务提效
约1分钟，按三方面讲：
- 开发：复用需求设计和测试模板，减少重复准备。
- 服务站问题：辅助反馈归类、案例匹配，缩短查找时间，发现共性问题。
- 日常查询：将高频查询、检查整理成可复用工具，减少重复写SQL与找入口。
前面讲的是我已经在使用的方式，后续重点是把有效方法整理清楚，让同事也能在真实任务中复用。
提醒：不宣称已经完成四类标准工作流；结合同事已有排障能力推进，避免重复建设。
第17页｜重查询分流与交易稳定
约50秒。
- 核心交易需要及时处理，高耗时报表、大批量导出可能争抢资源。
- 筛选高消耗任务，核对统计口径和数据时效后，推进大数据查询或异步导出。
让重查询任务更可控，减少对下单、支付和履约等正常交易的干扰。
提醒：不说“彻底物理隔离”，异步本身不等于消除数据库压力。
四、团队建设与意见建议
第18—19页｜团队建设
约40秒。
- 定期分享真实排查、性能优化与AI案例。
- 沉淀跨项目链路和已确认规则。
- 复杂问题协作复盘，包括走不通的方案。
把个人摸索的方法变成团队可以参考的经验，通过实际问题交流，提升学习效率和协作。
语气：提出建设性动作，不讲成对团队的批评。
第20—21页｜意见与建议
约1分钟，四条各讲一句。
- 业务效果回看：上线后结合使用数据，判断效果和后续迭代方向。
- 服务站反馈改进：高频反馈用于功能与流程改进，减少同类问题反复处理。
- 跨系统规则对齐：开发前明确状态和数据口径，减少联调返工。
- 投入与收益评估：结合业务收益、使用频次和维护成本，辅助需求优先级取舍。
这些是结合实际工作提出的改进建议，可以从重点需求和高频场景小范围尝试。
五、结束
第22—23页｜请领导点评与感谢
约20秒，结束参考：
以上是我的试用期工作回顾和后续规划。转正后，我会继续做好业务交付，也希望在风险预防、性能降本和AI研发提效方面承担更多责任。请各位领导对我的不足和后续工作重点提出建议，谢谢。
排练前核对
- 让听众记住：具体交付、量化优化结果、基于实际工作的下一步思考。
- 数字与PPT保持一致，不将计划、推测、估算变成已完成成果。
- 成果总览只概括，技术细节只挑真实且必要的例子。
- 总时长12—15分钟；若超时，先压缩目录、分隔页与技术细节。
- 本稿依据已确认PPT和对话整理，未在本次发布中重新查询线上业务数据。