本文已经填入已核对的真实工作内容，仍不是最终 PPT 短文案。每项内容都保留“已实现、已验证、已上线、待回归”的状态边界。

一、这份述职要回答的问题

波总听完后，需要得到以下四个答案：

  1. 我承接了哪些重要业务，而不是只完成了哪些零散开发任务？
  2. 我带来了哪些可以验证的性能或研发效率改善？
  3. 我做的 AI 研发工作，如何从个人使用变成跨项目、面向公司的复用能力？
  4. 转正后，我准备在哪些方向继续承担更大的业务责任？

二、整份 PPT 的核心主线

围绕订单履约和活动交易，推进核心业务交付、系统稳定性与研发提效；转正后继续对最终业务结果负责，并扩大 AI 在真实项目中的复用。

三项核心成果

  1. 核心业务交付
    • 订单同步方案：围绕 E 站、DGJ、SAAS 设计并落地创建、修改、取消、出库、确认收货、结单 6 类事件同步。
    • 秒杀与 E 站活动：覆盖活动配置、库存、指定仓、效期、购物车、采购下单、支付、OA、关单和活动展示。
  1. 性能优化与系统稳定性治理
    • 客户应收聚合：预发真实回归约 564.891ms → 41.509ms，结果一致，约提升 13 倍。
    • 购物车与报价查询：购物车扫描行数约 53556 → 450，耗时约 13.465s → 0.221s；报价 64 张分表验证 create_time 索引执行计划。
    • 日志治理：DGJ /offer/search/list 生产字符量约 2,010,924 → 488,296，下降约 75.7%；AES 摘要日志约 30.9KB → 3.9KB。
  1. AI 研发工作流：已验证，具备跨项目复用基础
    • 已形成需求、Bug、线上排查、快速变更四类任务入口，以及项目 Skill、doc/ai、交付门禁和经验审计。
    • DGJ 业务文档已形成 416/416 子模块追踪矩阵；统一知识地图已覆盖 115 篇文档、17 个分类和 6 个项目空间。
    • 真实案例：AI 辅助站管家报价故障排查，梳理 Mongo 写入、MQ、定时任务和跨服务调用边界。

三、页面结构建议

建议按模板保留 13 页。本版保留必要的章节页，删除结束页，并将“意见与建议”章节页和正文合并。页面只放结论、代表性证据和业务价值，技术细节放到讲稿或追问素材。

13 页映射

  1. 封面
  2. 个人定位与工作范围
  3. 目录
  4. 试用期核心成果章节页
  5. 核心成果总览
  6. 订单同步方案
  7. 秒杀与 E 站活动
  8. 性能与系统稳定性治理
  9. 转正后的工作方向章节页
  10. 转正后重点目标
  11. AI 研发能力复用章节页
  12. AI 研发工作流与跨项目复用
  13. 意见与建议

01｜封面

建议标题

六个月试用期述职

建议副标题

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

本页职责

  • 交代述职主题、姓名、岗位和周期。
  • 不放具体项目、数字和技术名词。

02｜个人定位与工作范围

建议标题

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

本页回答的问题

我在团队中承担什么类型的工作？

内容结构

  • 核心业务：承接 E 站订单在 DGJ 与 SAAS 之间的履约同步，以及秒杀活动从运营配置到交易处理的业务链路。
  • 稳定性治理：围绕慢查询、日志体量、大查询 OOM、消息异常和线上报错，推进定位、优化和风险前置。
  • 研发提效：把跨系统代码、日志、数据和消息排查过程沉淀为 AI 可辅助执行、可验证和可复用的工作流。

本页不放

  • 详细项目清单和 Git 提交数量；
  • srcOrderEntryId、Mongo、ES、MQ 等追问级技术细节；
  • “积极学习、快速成长”等无法验证的描述。

讲稿补充

常规需求开发和问题排查作为覆盖面证明，在讲稿中补充活动统计、客户导入、采购入库、销售明细、退款超时、机器人下单、服务发现和空 SKU 等案例，不与两条核心业务链并列成新的成果。

03｜目录

建议章节

  1. 试用期核心成果
  2. 转正后的工作方向
  3. AI 研发能力复用
  4. 意见与建议

章节关系

  • 第一部分说明已经完成了什么；
  • 第二部分说明转正后准备继续承担什么；
  • 第三部分说明 AI 研发能力如何形成复用；
  • 第四部分说明对业务和研发协作的观察与建议。

04｜章节页：试用期核心成果

章节标题

试用期工作回顾

章节引导

从复杂业务交付、性能与研发提效、AI 研发能力复用三个方面回顾试用期工作。

05｜核心成果总览

建议标题

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

页面结构

产出一：核心业务交付

  • 订单同步方案：围绕 DGJ、SAAS、E 站 3 个系统，覆盖创建、修改、取消、出库、确认收货、结单 6 类事件，重点收口明细映射、重复消费和消息时序边界。
  • 活动交易链路：覆盖活动配置、库存、购物车、采购下单、支付/OA 和关单；折扣订单关单已在预发核验主单、明细、库存释放和售后记录一致。

产出二：性能优化与系统稳定性治理

  • 量化改善：慢查询按现有统计口径约 6 万 → 3.5 万；Robot 日志约 150G → 40G；客户应收代表性样本约 564.891ms → 41.509ms，7/7 组结果一致。
  • 风险前置：销售明细、成本查询和导出增加最多 6 个月限制，针对 256MB OOM 风险提前拦截；每日巡检新增报错、超时、连接失败和消息异常。

产出三：AI 研发工作流与复用基础

  • 已验证基础：需求、Bug、线上排查、快速变更四类入口，以及项目说明、验证清单、交付门禁和经验审计。
  • 真实案例：在站管家报价故障中，用 AI 辅助梳理 DGJ2 → Sale → Basedata / Purchase / VinAudit / 价格中心，对齐 Mongo 写入、MQ 和定时任务入口。

本页只保留的证据边界

  • 所有数字都要在 PPT 图表旁标注统计周期、环境和口径。
  • AI 页只展示已形成的资产和真实案例，不把文档覆盖量写成公司级收益。

讲稿补充

常规需求开发、问题排查和代码优化作为覆盖面证明，不在总览页展开。重点案例包括客户导入、采购入库、销售明细 OOM、重复出库、退款超时、机器人下单、Consul 服务发现和空 SKU 查询。

06｜核心成果一（1/2）：订单同步方案

建议标题

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

页面主结论

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

中部业务链路

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

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

页面上写的真实交付

  1. 生命周期与基础口径
    • 覆盖创建、修改、取消、出库、确认收货、结单 6 类事件；
    • 统一来源单号、SKU、金额、地址、活动优惠和订单状态；
    • 增加销售单存在性、出库条件和订单暂时不可见时的有限重试。
  1. 消息可靠性
    • 收口漏发补发、重复消费、延迟队列、重试次数和取消状态混用；
    • 形成订单快照补偿、单条消费和受控重投方案，减少下游未落库先处理的风险。
  1. 明细与金额边界
    • 同物料、同 isGift 多行场景使用 srcOrderEntryId → entryId 精确回写，避免仅按 SKU 匹配；
    • GRS activityAmount=0 时回退有效 disAmount，非零值仍优先。

页脚：业务价值与状态

  • 价值：减少订单未落库先出库、重复累计出库、活动明细错配、优惠金额丢失和完成状态漏更新。
  • 已形成：3 个系统、6 类事件和主要字段/状态主链已梳理，部分边界已有代码或预发证据。
  • 状态边界：明细行级映射、金额回退和完成消息重投仍需跨项目回归或正式发布验证；没有订单总量、异常率和人工恢复耗时数据，不写业务规模收益。
  • 追问案例：67/67 出库恢复只作为稳定性案例，不作为订单同步方案的核心业务收益。

07｜核心成果一（2/2）：秒杀与 E 站活动交易链路建设

建议标题

秒杀与 E 站活动交易链路

页面主结论

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

中部业务链路

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

页面上写的真实交付

  1. 运营配置与商品规则
    • 完成活动提交、商品配置、黑白名单、OA 审批、导入导出和失效原因；
    • 收口权限、套包范围、指定仓、生产日期、有效期和底层结算价规则。
  1. 库存与交易处理
    • 覆盖库存查询、释放、购物车、采购下单、订单类型、收银台、OA 和关单；
    • 区分挂账与在线支付路径，补订单确认、取消状态和活动次数返还。
  1. E 站展示与接口契约
    • 交付活动列表、详情、商品、分享、订单确认、取消和游客访问；
    • 活动统计固定 source=2/platform=dgj，游客访问按登录态、合法分享 SID、Apollo 默认站点兜底。

页脚：业务价值与状态

  • 价值：把运营配置、库存限制、下单支付和售后处理放到同一条可验证链路里，减少超卖、错仓、效期误购、活动单误取消和无价商品进入活动的风险。
  • 已验证：折扣订单关单预发主流程中，主订单、关闭明细、秒杀数量释放和订单中心售后记录一致。
  • 状态边界：暂无活动订单量、支付率等经营数据；游客真实请求、仓码导入校验、非效期 Java 联调和退款最终回调仍需回归。非效期库存的 PHP/OPS 参数口径已收口，Java 接入仍待验证。
  • 表达方式：没有经营数据时，页面表达为“交易链路建设和规则收口”，不写成活动带来业务增长。

08｜核心成果二：性能优化与系统稳定性治理

建议标题

性能与系统稳定性治理：已有量化改善，风险继续前移

页面主结论

这一页只讲已经产生量化改善或已经形成保护机制的工作，重点是数据库、日志和大查询风险；业务级预警作为转正后的延伸方向单独讲。

页面上写的真实结果

  1. 数据库与查询性能
    • 慢查询按现有统计口径约 6 万 → 3.5 万；
    • 客户应收预发真实样本约 564.891ms → 41.509ms，7/7 组结果一致；
    • 购物车代表性查询扫描约 53556 → 450 行，耗时约 13.465s → 0.221s。
  1. 日志体量与排障信息治理
    • Robot 日志约 150G → 40G；DGJ /offer/search/list 生产窗口字符量约 2,010,924 → 488,296，下降约 75.7%；
    • 采用成功日志摘要化、异常保留原文、保留 request_id/msg_id/trace_id 的方式，降低采集压力并保留排障证据。
  1. 大查询保护与日常巡检
    • 销售明细、成本查询和导出统一限制最多 6 个月，前置拦截 256MB OOM 风险；
    • 每日检查 DGJ、SAAS、Robot 的新增报错、超时、连接失败、消息消费失败和重试异常，并按业务影响跟踪。

页脚：验证状态

  • 慢查询总量需要在正式 PPT 补统计周期和数据来源；SQL 优化来自预发真实样本、执行计划和结果集对账；日志来自 Robot 台账及 DGJ 生产窗口观察；大查询保护来自预发/隔离测试。
  • 64 张报价分表索引验证、18/18 采购入库隔离测试和 AES 单条日志 30.9KB → 3.9KB 作为讲稿或追问证据，不全部放在页面主体。
  • 这页表达“已有量化改善和已建立保护”，不写成所有慢 SQL、所有日志和所有大查询风险都已解决。

09｜章节页：转正后的工作方向

章节标题

转正后的工作规划

章节引导

从完成研发任务，进一步走向对核心业务链路、系统指标和研发复用结果负责。

10｜转正后重点目标

建议标题

转正后：继续对核心业务结果负责，进一步提升研发效率

我的判断

这半年已经验证了 AI 在复杂业务梳理、线上排查和资料沉淀上的价值。转正后，AI 作为研发提效和业务风险识别的手段，服务于核心业务交付、系统稳定性和跨项目复用，不把 AI 使用本身当成结果。

目标一：继续对核心业务交付和最终状态负责

  • 重点方向：继续围绕订单同步、秒杀/E 站活动和报价等跨系统链路，关注主单、明细、金额、库存、消息和页面最终状态。
  • 具体动作：开发前梳理影响范围和异常分支，联调时共同核对关键数据，发布后回读最终结果；将接口契约、状态矩阵和回归用例沉淀下来。
  • 业务价值：减少“接口成功但业务结果不一致”的问题，让研发交付从单点功能完成延伸到业务结果确认。

目标二：从错误日志巡检推进到业务风险预警

  • 当前问题：导出大查询、重复点击、慢查询突增、消息积压和下游超时等风险，可能在服务报错或不可用之后才被发现。
  • 具体动作：优先选择导出、订单提交和消息消费等入口，建立查询范围、重复提交、耗时、内存、重试、队列积压和最终状态缺失等指标，并明确阈值、责任人和处理动作。
  • AI 参与方式：辅助聚合同类异常、关联 RequestId/订单号/消息 ID，输出影响范围和核查建议，发布或数据处理仍由研发确认。
  • 业务价值：把问题发现从“已经报错”前移到“风险正在扩大”，减少故障影响范围和人工恢复成本。

目标三：把 AI 研发工作流沉淀为跨项目复用能力

  • 当前基础：已经形成需求、Bug、线上排查、快速变更四类入口，以及项目说明、代码/接口/表/MQ/日志入口、验证样例和交付门禁等方法。
  • 具体动作：选择真实项目试点，让 AI 参与需求影响分析、问题定位、测试整理、日志巡检和发布后回读，并把有效流程沉淀成接入包。
  • 衡量方式：记录接入项目数、真实复用次数、定位耗时、方案通过率和发布后回读完成率，不用“推广完成”代替实际结果。
  • 研发价值：减少重复理解项目、查代码和查日志的成本，让个人经验变成团队可检索、可验证的研发资产。

本页验收方式

  • 业务交付：回读订单、库存、金额、消息和页面最终状态；
  • 稳定性：观察慢查询日均量、扫描量、日志字符量、错误率和发布后窗口；
  • AI 提效：记录实际接入项目、复用次数、定位耗时、方案通过率和回读完成率。

阶段性落点

先选择订单、导出或消息消费中的一条跨系统链路建立基线和验证规则，再根据实际效果扩展到更多项目；不提前把计划描述成公司级收益。

11｜章节页：AI 研发能力复用

章节标题

AI 研发工作流落地与跨项目复用

章节定位

本章节用于说明 AI 研发能力如何从个人使用沉淀为具备跨项目试点基础、可验证的研发资产。

12｜核心成果三：AI 研发工作流与跨项目复用

建议标题

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

页面主结论

AI 在我的工作中主要承担整理复杂业务证据、辅助定位和固化流程，最终结果仍以代码、日志、数据库、消息和页面回读为准。

页面上写的真实产物

  1. 已经形成的研发入口
    • 覆盖需求、Bug、线上排查和快速变更四类任务；
    • 每类任务明确输入材料、检查范围、输出物和停止条件，并配套项目说明、验证清单和交付门禁。
  1. 真实案例：站管家报价故障排查
    • 用 AI 辅助把 sale / basedata / VinAudit 日志、代码调用、Mongo 写入、MQ 和定时任务放到同一条证据链上；
    • 梳理 DGJ2 → Sale → Basedata / Purchase / VinAudit / 价格中心 主链，确认报价 searchList 本身不直接写 Mongo；
    • 进一步对齐 DGJ2 定时脚本、MQ 消费/后置 Job 和人工修复入口，形成可复用的排查文档；
    • 证据只支持“完成链路梳理和恢复边界定位”，不写成 Mongo 平台根因完全闭环。
  1. 复用基础与边界
    • DGJ2 已形成 416/416 子模块请求—日志—数据变更追踪矩阵，知识地图已覆盖 115+ 篇文档、17 个分类和 6 个项目空间；这些是资产覆盖，不等于公司级复用收益；
    • 实际复用次数、使用人数、定位耗时和节省工时尚未形成统计，正式述职中不虚构。

本页结论

AI 工作流已经在个人工作、DGJ2 和 SAAS 场景中验证，当前具备跨项目试点基础；实际复用次数和节省工时尚未形成统计，不宣称公司级收益。

13｜意见与建议

页面定位

不重复个人工作规划，基于订单、活动、性能优化和线上排查中的实际观察，提出三点研发协作建议。

建议标题

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

页面主结论

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

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

  • 观察：导出大查询、重复点击、慢查询突增、消息积压和下游超时，往往在接口报错或资源耗尽后才暴露。
  • 建议：在订单、支付、库存、导出和消息消费入口补充重复提交、查询范围、耗时、内存、重试、积压和最终状态缺失等指标，并明确阈值和责任人。
  • 价值：在风险扩大前介入，减少服务不可用后的人工恢复。

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

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

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

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

讲稿收束（不单独成页）

三条建议先在订单、活动等跨系统核心链路试点，用实际数据验证后再推广。转正后，我会继续深耕核心业务，同时把已验证的 AI 研发工作流转化为可复用的提效能力。

四、本版大纲的事实边界

  • 核心业务页只讲订单同步方案和秒杀/E 站活动交易闭环，不把零散问题修复包装成业务成果。
  • 性能页只使用已经记录前后值、样本数、验证环境和结果一致性的数字；没有可靠业务量的地方明确写“暂无统计”。
  • AI 页写真实资产和站管家 Mongo/MQ 案例，明确 Mongo 平台历史证据缺口，不把梳理文档写成平台改造完成。
  • 所有“待回归/待发布/方案已明确”都是当前真实状态，不在 PPT 口头表达中升级成“已上线”。
  • 正式述职前按实际日期更新试用期周期，并重新核对第六个月内容的完成状态，避免把进行中的工作写成已完成。

五、建议下一步

先按本版大纲确认每页保留的内容，再把每页压缩成模板能承载的短句、链路图和数字卡片；不再重新发明成果分类。