六个月试用期述职持续精进方法

时间口径

本次述职是六个月，不是从现在开始计算的三个月：

自然月报继续保留，用于团队汇报和证据归并；述职工作台以以上六个入职阶段为主，二者不能混用。

统一入口：六个月试用期述职工作台。

前三个月回溯规则

1. 以 Git 非合并提交、日报、发布记录、接口验证和文档为事实来源。
2. 按订单同步、秒杀活动、稳定性与效能归并，不按提交时间流水罗列。
3. 提交数量只证明证据覆盖，不代表业务价值。
4. 没有上线或验证证据的内容明确标注“待验证”“待落地”。
5. 每个阶段固定写阶段主题、阶段成果、业务价值、问题与改进、验证与证据、下一阶段计划。

后三个月自动精进

工作日 09:40 自动任务处理最近需要归档的 Codex 对话：周一处理上周五至周日，周二至周五处理前一个自然日。

每次执行依次维护：

1. 当天工作日报，保留成果、风险、证据和下一步。
2. 对应自然月月报，合并同一业务主题。
3. 当前述职阶段文档，只加入真实新增结果，不重写前三阶段基线。
4. 季度成果台账，同一成果跨天推进时更新原条目。
5. 六个月总述职稿，把强证据补到三条核心故事，保留未完成状态。

网页数据库里的人工编辑优先展示；自动任务只维护 Markdown，不覆盖人工版本。

每周与每阶段节奏

• 每周选 1 至 3 个值得留下的结果，补业务影响和证据，不把所有任务都放入述职。
• 每周检查一次量化缺口：订单量、异常率、恢复耗时、性能变化、业务反馈或前后对比。
• 每个阶段结束时冻结一版阶段文档，并将强成果合并到总述职稿。
• 第 5 个月开始每两周试讲一次；第 6 个月完成 5 分钟和 10 分钟两个版本。

三条核心故事

1. 跨系统订单同步与一致性：状态事件、顺序、幂等、重试、补偿和历史兼容。
2. 秒杀活动与 E站活动专区：活动、库存、购物车、订单、支付、OA、关单和运营能力闭环。
3. 稳定性治理与研发效能：MQ、库存、日志、发布、知识地图和可复用排查能力。

质量检查

• 是否准确区分已讨论、已实现、已验证和已上线。
• 是否先说明业务问题与结果，再说明代码和技术动作。
• 是否体现本人判断、关键取舍和跨团队推进，而不只是“参与了”。
• 是否有至少两类可验证证据。
• 是否保留遗留风险和明确下一步。
• 是否能在 2 分钟内讲清每条核心故事。

维护位置

• 六阶段和总述职稿：16_工作总结与述职/2026/述职/
• 日报：16_工作总结与述职/YYYY/日报/
• 自然月报：16_工作总结与述职/YYYY/YYYY-MM_月报.md
• 季度台账：16_工作总结与述职/YYYY/YYYY-QN_季度成果台账.md
• 页面：app/templates/user/probation_review.html
• 文档解析：app/review_content.py
• 接口：app/routes/user.py
• 自动任务：~/.codex/automations/codex/automation.toml