本版不是删减真实工作内容，而是重新安排表达层级：页面先讲业务结果，讲稿补充具体动作，追问材料保留技术证据和状态边界。

一、这份述职要让高层形成的判断

听完后，希望波总能够明确四件事：

  1. 我承接了订单履约和活动交易两条跨系统核心业务链；
  2. 我不仅完成需求，也持续降低慢查询、日志、导出和消息异常带来的系统风险；
  3. 我已经把复杂问题的代码、日志、数据和消息排查过程沉淀为 AI 可辅助、可验证、可复用的研发方法；
  4. 转正后，我能够继续对最终业务结果负责，并把风险发现和研发提效进一步前移。

二、整份 PPT 的核心主线

试用期内，我承接了订单履约和活动交易两条核心业务链，推进性能与稳定性治理，并将复杂排查经验沉淀为 AI 研发工作流。转正后，继续围绕业务最终结果、风险前置和研发提效承担更大责任。

高层视角下的三类结果

结果一：业务交付

不是罗列接口，而是说明订单和活动能够沿着业务链路继续向下流转，关键字段、状态、库存、支付和售后边界得到收口。

结果二：系统稳定性与研发提效

不是只展示技术动作，而是说明慢查询、日志体量、大查询 OOM、消息异常和问题发现时间得到了改善或保护。

结果三：AI 研发复用基础

不是宣称公司已经全面复用，而是展示 AI 已在真实项目中参与业务梳理和故障排查，并已形成项目接入和后续试点的基础。

三、内容分层原则

PPT 页面主体

只放：

  • 业务链路；
  • 我承担的关键动作；
  • 最硬的数字或验证结果；
  • 对业务和系统的价值；
  • 当前状态。

讲稿补充

补充常规需求开发、问题排查、技术细节和项目时间线，包括客户导入、采购入库、销售明细、退款超时、重复出库、机器人下单、Consul 服务发现和空 SKU 查询等。

追问证据

保留 srcOrderEntryId、activityAmount、2 秒 TTL、MQ 重试、Mongo 写入入口、SQL 执行计划、统计窗口和提交号等内容，但不让这些细节取代页面主结论。

状态标签

正式 PPT 统一使用以下状态：

  • 已验证：有预发、隔离环境、只读生产或页面回读证据；
  • 已提交待回归：代码已形成，但仍缺真实联调、发布后回归或最终状态核对；
  • 方案已明确：完成分析和设计，但尚未实施；
  • 待发布/待验证：不能写成已上线或已完成。

01｜封面

建议标题

六个月试用期述职

建议副标题

核心业务交付、系统稳定性与研发提效

页面职责

只交代姓名、岗位、述职周期和主题，不放项目清单和技术名词。

02｜我的职责与业务范围

页面标题

主要承接订单履约、活动交易与系统稳定性

页面结论

我的工作不是单个接口开发，而是围绕 DGJ2、SAAS 和 E 站，持续承接业务链路、系统问题和研发提效工作。

页面内容

业务交付

  • 承接 E 站订单在 DGJ 与 SAAS 之间的创建、修改、取消、出库、确认收货和结单同步；
  • 承接秒杀和 E 站活动从后台配置、库存规则到购物车、下单、支付/OA 和关单的交易链路。

稳定性治理

  • 围绕慢查询、日志体量、大查询、导出 OOM、消息重试和线上报错进行定位与治理；
  • 通过订单号、RequestId、MQ 消息 ID、代码入口、数据库记录和最终页面状态追踪问题。

研发提效

  • 将复杂项目的代码、日志、表、Mongo、MQ 和定时任务入口整理成可检索、可验证的排查材料；
  • 用 AI 辅助理解影响范围、定位问题、整理验证和沉淀复用流程。

页面不放

  • 详细 Git 提交清单；
  • 全部零散问题；
  • 过多类名、表名和字段名；
  • “积极学习、快速成长”等不可验证的表达。

03｜六个月工作结果总览

页面标题

六个月工作主线与代表性结果

页面结构

一、核心业务交付

  • 订单同步方案：覆盖 DGJ、SAAS、E 站 3 个系统和创建、修改、取消、出库、确认收货、结单 6 类事件；重点收口事件时序、明细映射、金额口径和最终状态。
  • 活动交易链路：覆盖活动配置、库存、指定仓、效期、购物车、采购下单、支付/OA、关单和 E 站展示；折扣订单关单已在预发核验主单、明细、库存释放和售后记录一致。

二、性能与系统稳定性

  • 慢查询按现有统计口径约 6 万 → 3.5 万；
  • 客户应收代表性预发样本约 564.891ms → 41.509ms，7/7 组结果一致；
  • 独立日志治理页呈现 DGJ 140G → 30G、DGJ-VinAudit 约50G/日 → 9.2G/日，以及日志流量费用变化；
  • 对销售明细、成本查询和导出增加最多 6 个月限制，前置拦截 256MB OOM 风险，并开展每日错误日志巡检。

三、AI 研发工作流与复用基础

  • 形成需求、Bug、线上排查、快速变更四类任务入口；
  • 在站管家报价故障中，用 AI 辅助梳理 Mongo 写入、MQ、定时任务和跨服务调用边界；
  • 已形成项目说明、验证清单、交付门禁、业务文档和知识地图等复用资产，暂不虚构公司级收益。

页面主结论

我交付的不是一组孤立功能，而是两条核心业务链、一套稳定性治理方法和一套具备复用基础的 AI 研发工作流。

04｜核心业务交付一：订单同步方案

页面标题

DGJ/SAAS/E 站订单同步方案

页面主结论

承接 E 站订单进入 DGJ、同步到 SAAS，再到出库、收货和结单的跨系统履约链路，重点解决事件时序、明细映射、金额口径和最终状态一致性问题。

业务链路

E 站下单 → DGJ 销售单 → SAAS 订单 → 出库 → 确认收货 → 结单

链路下方标注：创建 / 修改 / 取消 / 出库 / 确认收货 / 结单 6 类事件，涉及 DGJ、SAAS、E 站 3 个系统。

我承担的关键工作

订单生命周期和基础口径

  • 推进 6 类订单事件的发送与消费；
  • 统一来源单号、SKU、金额、地址、活动优惠和订单状态；
  • 增加销售单存在性、出库条件和订单暂时不可见时的有限重试。

消息可靠性

  • 收口漏发补发、重复消费、延迟队列、重试次数、合并消息和取消状态混用；
  • 形成订单快照补偿、单条消费和受控重投方案，减少下游未落库先处理的风险。

明细和金额边界

  • 同物料、同 isGift 多行场景使用 srcOrderEntryId → entryId 精确回写，避免只按 SKU 匹配；
  • GRS activityAmount=0 时回退有效 disAmount，非零值仍优先；
  • 针对创建事务未提交而完成消息先到的问题，形成 2 秒 TTL、最多 10 次重投的方案，发布和跨项目回归状态单独标注。

业务价值

  • 减少订单未落库先出库；
  • 减少重复消息导致的出库数量累计；
  • 降低活动明细错配和优惠金额丢失风险；
  • 让订单状态从接口成功进一步落到下游数据和最终履约状态。

状态边界

  • 3 个系统、6 类事件和主要字段/状态主链已经梳理；
  • 部分明细映射、金额回退和完成消息方案已有代码或预发证据；
  • 跨项目真实回归、正式发布和消费者最终状态验证，按实际进度标记为待完成；
  • 67/67 出库恢复作为稳定性追问案例，不作为订单同步方案的核心业务规模收益。

05｜核心业务交付二：秒杀与 E 站活动

页面标题

秒杀与 E 站活动交易链路

页面主结论

完成从活动配置、库存规则到下单、支付/OA 和关单的活动交易链路建设，重点收口库存、支付、取消和售后边界。

业务链路

活动创建/审批 → 商品与规则 → 库存/指定仓/效期 → 购物车 → 采购下单 → 支付/OA → 关单/取消 → E 站展示

我承担的关键工作

运营配置与商品规则

  • 完成活动提交、商品配置、黑白名单、OA 审批、活动导入导出和商品失效原因；
  • 补活动菜单权限、复制活动不复制黑白名单、套包范围和批量查询边界；
  • 收口指定仓、生产日期、有效期、库存释放和底层结算价规则。

库存和交易处理

  • 覆盖可售、在途、套包、已使用、释放、购物车、采购下单、订单类型、收银台、OA 和关单；
  • 区分挂账与在线支付路径，补订单确认、取消人、取消状态和活动次数返还；
  • 处理实时限售、跨类型生产日期冲突和无底层结算价商品不展示等边界。

E 站展示和接口契约

  • 交付活动列表、详情、商品、分享、订单确认、支付边界、取消接口和游客访问；
  • 活动统计固定 source=2/platform=dgj；
  • 游客访问按登录态 SID、合法分享 SID 和 Apollo 默认站点兜底；
  • 非效期库存的 PHP/OPS 参数口径已收口，Java 接入和页面回归仍需验证。

业务价值

  • 支撑运营从活动配置进入真实交易处理；
  • 降低超卖、错仓、效期误购、活动订单误取消和无价商品进入活动的风险；
  • 将活动库存、订单、支付、关单和售后放在一条可验证链路上。

状态边界

  • 折扣订单关单预发主流程中，主订单、关闭明细、秒杀数量释放和订单中心售后记录一致；
  • 暂无可靠的活动订单量、支付率和业务增长数据，不写成活动带来经营增长；
  • 游客真实请求、仓码导入校验、非效期 Java 联调和退款最终回调仍需回归。

06｜常规研发交付与复杂问题排查

页面标题

常规需求持续交付，复杂问题按业务结果排查

页面定位

这一页不与订单同步、活动交易并列为新的核心战果，而是证明我能够持续承接日常需求、线上问题和跨服务排查。

常规需求开发

  • 活动统计接口：完成 DGJ2/SAAS 参数契约校验；
  • 客户资料批量导入：补齐 Excel 客户名称写回兼容，形成提交 d0d43489f0；
  • 采购入库列表与导出：统一筛选条件、主单/明细范围、雪花 ID 字符串精度和错误展示，完成 18/18 隔离测试，真实下载和发布回归仍待完成；
  • 销售明细、成本查询和导出：增加最多 6 个月限制，处理 256MB OOM 风险。

复杂问题排查

  • 出库重复：确认旧 APP_SA_ORDER_OUT 与新 garage_repair_outbound_created 同时发送，造成 SAAS 出库数量重复累计；
  • 退款超时：确认同步超时不等于支付失败，需继续核对支付通道最终回调；
  • 机器人下单：定位重复消费和迁移后错误 Consul 集群视图等跨服务问题；
  • ZGJ 最近采购：定位纯赠品过滤后空 SKU 集合仍进入 IN () 查询；
  • 站管家报价：跨 DGJ2、Sale、Basedata、Purchase、VinAudit、价格中心和 Mongo/MQ 链路进行排查。

我的排查方法

从订单号、RequestId、接口或消息 ID 出发，依次核对代码入口、日志时间线、数据库数据、MQ 消费、下游服务和最终页面/业务状态，不把 HTTP 200、MQ ACK 或单服务落库直接当成业务成功。

页面价值

证明我既能承接核心业务方案，也能持续处理日常研发和复杂线上问题，能够从“修一个报错”进一步定位到业务规则、跨服务责任边界和最终状态。

07｜数据库查询性能与风险前置治理

页面标题

数据库查询性能已有改善，大查询风险开始前置治理

页面主结论

围绕高频慢查询和大范围查询风险，结合业务查询规则调整、索引补充与查询方式优化，并对高风险导出增加范围限制；同时通过每日错误巡检，把问题发现从业务反馈后逐步前移。

量化结果

查询性能

  • 慢查询按现有统计口径约 6 万 → 3.5 万；
  • 客户应收预发真实样本约 564.891ms → 41.509ms，7/7 组结果一致；
  • 购物车代表性查询扫描约 53556 → 450 行，耗时约 13.465s → 0.221s；
  • 报价 _0—_63 共 64 张分表完成 create_time 索引执行计划验证。

大查询风险前置与巡检

  • 销售明细、成本查询、普通导出和成本导出统一限制最多 6 个月；
  • 针对长日期全量结果在 json_encode 阶段触发 256MB OOM 的风险提前保护；
  • 每日检查 DGJ、SAAS、Robot 的新增报错、超时、连接失败、消息消费失败和重试异常；
  • 结合服务、接口、RequestId、订单号或消息 ID 判断是否影响订单、库存、支付或报价。

对业务的价值

  • 降低客户应收、购物车和报价等关键页面的查询压力；
  • 避免长范围导出拖垮 PHP 或数据库；
  • 将问题从业务反馈后才排查，逐步前移到日志巡检和风险监控阶段。

当前不足与转正后方向

现有巡检主要发现已经写入日志的错误，对风险扩大前的行为和资源信号覆盖不足。转正后将从导出保护和订单履约两个场景推进监控试点，具体路径见“转正后重点目标”。

数据边界

正式 PPT 需要为 6 万 → 3.5 万 补充统计周期、环境和数据来源；客户应收与购物车结果属于具体样本验证，不能直接写成页面整体 SLA 或所有查询的普遍收益。

08｜日志治理与采集成本优化

页面标题

日志治理降低采集量与持续费用

页面主结论

对 DGJ、DGJ-VinAudit 等服务开展日志治理，降低日志体量和采集流量；在减少冗余输出的同时保留必要的异常信息与排障线索。此项与数据库查询优化分开呈现，突出资源和费用收益。

量化结果

  • DGJ 日志体量：140G → 30G，下降约 79%；
  • DGJ-VinAudit 日均日志量：约 50G/日 → 9.2G/日；按截图中的 50G/日 计算下降约 81.6%，四舍五入为 82%。若 81% 来自未取整基数，正式页按原始统计值重算；
  • 日志流量费用：265元/日 → 155元/日，下降约 41.5%；
  • 按 30 天估算，流量费用减少约 3,300元/月；扣除 AI 日志服务器 1,100元/月 后，月净节省约 2,200元。

治理动作与业务价值

  • 精简高频、重复或排障价值较低的日志输出，降低日志采集和存储压力；
  • 保留异常上下文及 request_id/msg_id/trace_id 等关键定位信息，兼顾费用控制与后续排障；
  • 费用下降来自日志流量费用变化，展示净节省时同时扣除新增 AI 日志服务器成本。

页面呈现建议

  • 主视觉突出“月净节省约 2,200元”；
  • 用两组前后对比呈现 DGJ 与 DGJ-VinAudit 的日志量，再补一行流量费用变化；
  • 不展示服务器 IP；将截图中的“每日日志大小”和“当前日志大小”改为同口径的“优化前日均量 / 优化后日均量”；
  • 其他服务数据只有在统计周期和单位确认一致后再加入本页，避免把日均生成量与当前磁盘占用量混为一谈。

数据边界

  • DGJ 140G → 30G 的统计周期和是否为日均量，正式制作前补充确认；
  • DGJ-VinAudit 的约 50G/日 → 9.2G/日 需统一统计窗口，并按未取整原始值计算降幅；
  • 2,200元/月 为按 30 天折算并扣除 AI 日志服务器月成本后的估算值，正式页注明计费口径和统计周期；
  • 截图中的旧数值需按最新统计更新，不把不同口径的列直接作为优化前后对比。

09｜AI 真实案例：站管家报价故障排查

页面标题

AI 辅助复杂业务排查：从现象追到 Mongo、MQ 和服务恢复边界

页面主结论

AI 的价值不只是生成代码，而是帮助把多个项目、多个日志源、Mongo 写入、MQ、定时任务和人工修复入口放到一条可验证的业务证据链上。

故障排查范围

DGJ2 → Sale → Basedata / Purchase / VinAudit / 价格中心

我用 AI 辅助完成的工作

  • 对齐 sale / basedata / VinAudit 的日志、代码调用和服务重启时间线；
  • 梳理报价查询、商品数据、Mongo 写入、MQ 消费、定时任务和人工修复的关系；
  • 确认报价 searchList 本身不直接写 Mongo；
  • 将 Mongo 写入入口收敛为 DGJ2 定时脚本、MQ 消费/后置 Job 和人工修复入口；
  • 补齐 MQ、后置 Job 和字段入口文档，形成后续排查可复用的材料。

得到的业务判断

  • 首发异常早于 VinAudit 硬超时；
  • 恢复依赖先解除 Basedata 阻塞，再清理 Sale 侧坏连接池；
  • 不能只根据单条错误日志或单个服务状态判断根因；
  • Mongo 平台历史慢日志已经滚动，当前证据不足以宣称 Mongo 平台根因完全闭环。

这一页要体现的能力

  • 能跨项目理解业务调用关系；
  • 能区分现象、直接原因、恢复动作和根因证据；
  • 能把一次排查整理成团队后续可复用的业务地图和验证入口。

10｜转正后重点目标

页面标题

转正后重点：把 AI 用到业务理解、研发交付和运行治理

我的判断

试用期已在站管家报价故障中用 AI 辅助梳理 Mongo、MQ 和定时任务链路，也已开展每日报错巡检、日志与慢查询治理、导出风险保护。转正后要把 AI 从个案使用扩展到业务链路理解、研发提效、线上问题快查和风险预防，并沉淀为可复用的项目流程。

目标一：让 AI 参与业务理解和研发交付

  • 梳理业务链路：遇到跨系统需求或复杂模块时，让 AI 基于代码、接口、表结构、Mongo、MQ 和日志，整理调用关系、数据流向、关键状态、待核实问题和回归点；研发核对后形成链路说明和检查清单。站管家报价故障中梳理 Mongo 写入、MQ、定时任务和人工修复入口，可作为已验证案例。
  • 提高研发效率：把需求拆解、变更影响分析、测试点整理和验证记录纳入固定工作流，优先用于重复出现的需求或问题类型；对比试点前后的分析/验证耗时和返工情况，确认哪些步骤确实节省时间。
  • 跨项目复用：以 DGJ2、SAAS 已有任务入口和交付校验为基础，整理项目上下文、接口/数据/MQ/日志入口、人工确认点和验证要求；先在一个新的真实项目或模块试用，记录实际复用次数和效果，再决定扩展范围。

目标二：用 AI 辅助线上快查、风险预防和降本

  • 线上问题快速定位：发生线上问题时，让 AI 辅助关联 RequestId、订单号/业务单号、消息 ID、日志、代码调用和数据状态，整理事件时间线、可能卡点、影响范围及还缺哪些证据；由研发核实结论，减少跨服务人工翻查时间。
  • 问题预防与成本治理：结合每日报错、慢查询、日志量，以及导出任务的查询范围、重复触发、耗时和资源占用，让 AI 归并重复信号、按发生频次和业务/资源影响排序，提出告警、查询限制或日志治理候选；研发确认后再落成监控或保护措施，避免等到 OOM、服务异常或业务反馈后才处理。
  • 验证实际收益：先为试点场景建立现状基线，再记录问题定位耗时、有效告警率与提前量、重复问题变化、实际复用次数，以及落地治理前后的日志/查询资源成本；依据误报、漏报和处理结果调整规则，不预设未经验证的节省比例。

阶段性落点

先选择一个导出或大查询风险场景和一个复杂业务链路，分别验证 AI 辅助分析、人工确认、告警/保护动作及结果回读；形成可复用的流程后，再扩展到订单履约和其他项目。

11｜AI 研发能力与公司复用

页面标题

AI 研发工作流：已在项目中验证，具备跨项目复用基础

页面主结论

我已经把 AI 从个人临时使用，沉淀为有入口、有上下文、有验证、有交付门禁的研发工作流。下一步面向公司复用，但先从真实项目试点开始。

已形成的资产

四类任务入口

  • 需求开发；
  • Bug 修复；
  • 线上问题排查；
  • 快速变更。

每类任务明确输入材料、检查范围、输出物和停止条件，轻量任务不再套用完整需求流程。

项目接入和交付约束

  • 项目说明和代码边界；
  • 接口、表、MQ、日志入口；
  • 项目 Skill 和业务链路文档；
  • 验证样例、最终状态回读和交付门禁；
  • 经验审计和可复用知识沉淀。

当前覆盖证据

  • DGJ2 已形成 416/416 子模块请求—日志—数据变更追踪矩阵；
  • 统一知识地图已覆盖 115+ 篇文档、17 个分类和 6 个项目空间；
  • DGJ2/SAAS 已建立隔离验证仓、项目注册和索引重建基础。

公司复用方式

选择订单或活动等真实项目试点，提供一份标准接入包：

  • 项目说明；
  • 代码边界；
  • 接口、表、MQ、日志入口；
  • 常见业务链路；
  • 只读验证样例；
  • 交付门禁和发布后回读规则。

复用效果怎么衡量

  • 接入项目数；
  • 真实复用次数；
  • 定位耗时；
  • 方案通过率；
  • 发布后回读完成率。

表达边界

当前能证明的是：AI 工作流已经在个人工作、DGJ2、SAAS 和站管家排查场景中验证，并具备跨项目试点基础。实际复用人数、节省工时和公司级收益尚未形成统计，不在述职中虚构。

12｜意见与建议

页面标题

基于实际项目的三点研发协作建议

页面主结论

建议核心业务研发同时关注交付结果、风险发现和经验复用。

建议一：核心链路增加业务级告警

  • 观察：告警要真正降低业务风险，除了指标本身，还需要明确谁接收、触发后如何处理，以及怎样确认业务恢复；
  • 建议：对订单履约、导出等重点链路，由研发与业务共同确定指标口径、分级阈值、责任人、处置动作和恢复标准；
  • 价值：减少告警无人跟进或同一异常反复升级，让风险发现后能进入明确的处理闭环。

建议二：跨系统需求按最终结果验收

  • 观察：接口成功、MQ ACK 或单服务落库，都不能单独证明订单、活动和库存结果正确；
  • 建议：评审时明确字段转换、幂等、重试和状态变化，联调时共同回读主单、明细、金额、库存、消息和最终页面/状态；
  • 价值：减少接口能通但业务结果不一致造成的返工和人工修数。

建议三：AI 复用先从真实项目接入

  • 观察：站管家故障中，AI 能辅助梳理 Mongo、MQ、定时任务和人工修复入口，但效果依赖项目上下文和验证样例；
  • 建议：选择订单或活动项目试点，提供代码边界、接口/表/MQ/日志入口、验证样例和交付门禁，要求 AI 输出对应证据和最终状态回读；
  • 价值：把个人排查经验变成可复用流程，用接入项目数、复用次数和定位耗时衡量效果。

13｜我已经形成的能力与下一步承担

页面标题

从完成研发任务，走向对业务结果和系统风险负责

已形成的三项能力

  1. 业务承接能力：能够理解订单、活动、库存、支付、消息和售后之间的业务关系，并承接跨系统交付；
  2. 系统治理能力：能够从慢查询、日志、消息和数据状态中判断影响范围，推动问题从现象处理走向风险治理；
  3. 研发复用能力：能够将代码、日志、数据、MQ 和验证过程沉淀为团队可检索、可复用的 AI 辅助研发资产。

转正后的承诺

  • 继续深耕订单履约和活动交易等核心业务；
  • 从导出/大查询和订单履约场景开始，补充资源前兆、消息积压和业务状态监控，再根据试点效果扩展；
  • 将 AI 用于业务链路梳理、需求影响分析、研发验证和线上问题快查，并结合日志、慢查询及资源信号寻找可验证的降本与预防机会；
  • 把确认有效的做法沉淀成跨项目可复用流程，以真实任务中的耗时、返工、告警和资源变化检验效果。

页面结束语

转正后，我会继续把复杂业务做深，把系统风险看早，把已经验证的研发方法沉淀成团队可以复用的能力。

14｜结束页

页面标题

谢谢

讲稿补充

如果模板需要压缩页数，结束语可并入第 13 页；日志治理页建议保留独立呈现，以免和数据库查询性能混在一起。

四、正式制作 PPT 前必须补齐的证据

业务规模证据

  • 订单同步涉及的订单量或真实案例规模；
  • 活动配置数量、活动商品数量或活动订单数据；
  • 如果没有可靠经营数据，明确写“暂无统计”，使用工程验证结果代替，不虚构业务增长。

性能与稳定性证据

  • 慢查询 6 万 → 3.5 万 的统计周期和查询口径；
  • DGJ 140G → 30G 的统计窗口、单位和统计对象；
  • DGJ-VinAudit 日志优化前后使用同一统计窗口的原始日均量；
  • 日流量费用 265元 → 155元 的账单区间及 AI 日志服务器月费用；
  • SQL 优化的环境、样本数量、结果一致性和是否已发布；
  • 每日巡检发现的问题数量和确认影响范围，如没有统计则不填写数字。

AI 复用证据

  • 实际接入项目数；
  • 真实复用次数；
  • 其他人员是否使用过；
  • 定位耗时是否有前后对比；
  • 方案通过率和发布后回读完成率。

五、正式述职的表达边界

  • 订单同步和活动交易讲业务链路，不讲成零散问题修复；
  • 常规需求和问题排查讲覆盖面，不与核心业务成果争夺主标题；
  • 性能治理讲量化改善和风险保护，不把局部 SQL 结果写成全系统 SLA；
  • AI 讲真实案例、已有资产和复用方式，不把文档覆盖量写成公司级收益；
  • 明确区分已验证、已提交待回归、方案已明确和待发布；
  • 不把 HTTP 200、MQ ACK、服务启动或单服务落库当成最终业务成功；
  • 正式述职前按实际日期更新试用期周期，并重新核对第六个月内容的完成状态。

六、5 分钟讲述顺序

  1. 开场 20 秒：我主要承接订单履约、活动交易和系统稳定性；
  2. 业务交付 2 分钟：订单同步和秒杀/E 站活动两条核心链路；
  3. 量化改善 1 分钟：慢查询、日志、SQL、大查询保护和每日巡检；
  4. AI 案例 50 秒：站管家报价故障如何用 AI 梳理 Mongo、MQ 和跨服务边界；
  5. 转正目标 40 秒：最终状态验收、业务风险预警、AI 研发复用；
  6. 收束 10 秒：继续对业务结果负责，把风险发现和研发提效前移。

七、10 分钟讲述时的追问准备

  • 订单同步方案哪些已经上线，哪些仍待回归？
  • 活动链路有没有真实订单量和运营反馈？
  • 6 万 → 3.5 万 的统计周期和口径是什么？
  • SQL 优化是单次样本还是整体 SLA？
  • 日志减少后，异常排查信息是否保留？
  • AI 相比普通排查具体节省了什么？
  • AI 公司复用如何避免变成口号？
  • 业务告警第一阶段准备从哪个入口开始？

八、与原大纲的关系

本版保留原大纲的全部核心内容，只做以下调整：

  • 将订单同步和活动交易继续作为核心业务成果；
  • 将常规需求开发和复杂问题排查保留为支撑项；
  • 将慢查询、日志治理、每日巡检、大查询保护和风险预警放在同一条稳定性主线上；
  • 将站管家 Mongo/MQ 排查作为 AI 真实案例；
  • 将 AI 公司复用拆成“已验证资产”和“转正后试点方式”；
  • 将意见与建议保留为团队协作机制；
  • 用高层关心的业务结果、系统风险和可复制能力重新组织页面顺序。