试用期的评价标准不是"努力"，是"可交付"和"可预测"：交给你的东西能不能按时按质量出来，出了风险你会不会提前说。90 天刚好分三段——先建地图，再独立交付，最后优化沉淀。顺序颠倒的典型后果是：第一个月就想改架构，第二个月还在问基础问题，第三个月没有一件能写进转正材料的事。
1. 三个阶段
| 阶段 | 目标 | 产出物 | 自查信号 |
|---|---|---|---|
| 第 1–30 天 | 建立地图：知道系统怎么跑、人怎么转 | 一张自己的系统/流程笔记 | 能不看文档画出主链路，能说出改一个需求要碰哪几个服务 |
| 第 31–60 天 | 独立交付：从接需求到上线跑完一遍 | 至少一个完整上线的小需求 | 需求是你自己推完的，不是别人催着推的 |
| 第 61–90 天 | 优化与沉淀：解决一个别人也受益的问题 | 一次改进 + 一份可复用的文档/工具 | 有人主动用你写的东西，或引用你的结论 |
判断规则：每个阶段末尾问自己一句——"这 30 天我交出了什么别人能看见的东西？"答不上来，说明这一段在空转，下一段会更被动。
2. 第 1–30 天：搞清八件事
这段时间的主要动作是提问和记录，不是写代码。八件事可以在一到两周内问完，剩下的时间用来验证。
| 事项 | 怎么问 | 拿到什么 | 自检 |
|---|---|---|---|
| 代码结构 | 请人带你走一遍仓库目录，问"哪个模块最常改" | 模块边界与热点目录 | 能说出三个核心模块各自的职责 |
| 发布流程 | 要一次发布记录，跟着看一遍 | 分支策略、构建、灰度、回滚 | 能独立发一次到测试环境 |
| 监控入口 | 问"线上出问题先看哪个面板" | 面板地址、关键指标、告警群 | 能自己找到某个接口的错误率 |
| 值班机制 | 问"这周谁值班、什么情况会叫人" | 值班表、升级路径 | 知道出事第一步找谁 |
| 需求来源 | 问"需求从哪来、谁定优先级" | 需求池、决策人 | 能说清一个需求为什么排在这个位置 |
| 评审习惯 | 问"代码评审看什么、几个人过" | 评审标准、惯例 | 提交一次能一次过 |
| 文档位置 | 问"文档写在哪、谁维护" | Wiki/仓库路径、过期情况 | 找到的东西能判断新旧 |
| 找谁问什么 | 观察谁回答哪类问题 | 一张人物-领域对照 | 同一个问题不问第三遍 |
我的入职笔记（第一周就开始写，后面直接变成交接材料）
1 主链路：请求从网关到 DB 经过哪些服务，各自负责什么
2 环境：本地 / 测试 / 预发 / 生产的地址与差异
3 发布：分支 → 构建 → 灰度 → 回滚，每一步谁点
4 监控：面板地址、关键指标、告警群、值班表
5 人物：谁负责哪个域，什么问题找他
6 坑：同事口口相传的"别动这里"清单
第 6 条最值钱：每个团队都有一份没写进文档的禁区清单，早问早避雷。问法是"这块有没有什么坑是我不知道的"，比"这里能不能改"更容易得到真话。
3. 第一次交付：小而要完整
新人最常见的失败不是做得少，是做了个半成品：接口写了、没联调；功能上了、没监控；需求做完了、没人知道怎么验证。
| 维度 | "小"的做法 | "完整"的要求 |
|---|---|---|
| 范围 | 一个接口、一个页面、一个开关 | 从需求确认到上线全流程走完 |
| 时间 | 一到两周能收口 | 每周都有可看的东西 |
| 质量 | 不追求架构优雅 | 有测试、有日志、有回滚方案 |
| 可见度 | 一个人能做完 | 上线后有数据或反馈能说明它生效 |
切分规则：把需求按"能独立上线的最小单元"切，第一刀切出来的那块要在两周内能发。切不动就说明需求本身没想清，去找提需求的人对齐，而不是自己硬扛。
判断规则：交付前问三句——上线后怎么验证？出问题怎么回滚？别人接手要读什么？三句都能答，才算完整。
4. 主动汇报
汇报不是邀功，是降低对方的不确定性。试用期里，"他不知道你在干什么"比"你干得慢"更危险。
| 类型 | 频率 | 结构 | 目的 |
|---|---|---|---|
| 日报/站会 | 每天 1 分钟 | 昨天做完什么、今天做什么、有没有卡住 | 让别人能替你排优先级 |
| 周报 | 每周一次 | 本周交付、下周计划、风险与需要的支持 | 留证据，也让风险提前暴露 |
| 风险升级 | 一旦出现立即 | 现象、影响面、我已试过什么、需要谁决策 | 不让问题在你手里发酵 |
周报模板（四行就够）
交付：订单查询接口上线，灰度 20%，错误率与基线持平
下周：接入退款状态回调，预计周三联调
风险：退款侧的对账口径还没定，等 X 确认，可能影响排期
需要：请 Y 帮我约一次和支付组的对齐会
风险那行必须写具体到人和事。"可能有风险"这种写法等于没写，因为它不产生任何动作。
5. 别做的三件事
| 别做 | 为什么 | 替代做法 |
|---|---|---|
| 急于改造旧代码 | 你不知道它为什么长这样，改动会撞上历史约束 | 先把"想改的地方"记成清单，等第 61 天后再挑一个最小的动 |
| 过度承诺 | 试用期最贵的成本是"说了没做到"，比"做得慢"扣分更重 | 给区间不给点："这个需求周四能给联调版本，上线要看测试排期" |
| 隐藏问题 | 问题不会因为不说而消失，只会在你最不想它出现的时候出现 | 用第 4 节的风险升级格式，先说现象和影响面 |
第一条值得展开：旧代码里每一处怪异写法，通常对应一次真实的历史事故。判断规则：看到"这写得什么玩意"时先问"这里以前出过事吗"，有人能讲出故事就先别动，没人知道才进你的改造清单。
6. 考核看的维度
| 维度 | 具体在看什么 | 证据怎么留 |
|---|---|---|
| 交付 | 承诺的东西有没有按时按质出来 | 上线记录、需求单、周报 |
| 质量 | 返工率、线上问题数、评审意见类型 | 评审记录、故障单 |
| 主动性 | 是等安排还是自己发现问题 | 你主动提的改进项与结果 |
| 协作 | 跨团队推进时是否顺畅、有没有制造摩擦 | 对齐会记录、他人反馈 |
| 学习速度 | 同类问题问第二遍了吗，笔记有没有更新 | 自己的提问记录 |
不同公司权重不同，具体口径以你的直属上级在第一次一对一里说的为准，不要按网上流传的比例自查。可以直接问："这三个月您主要会看哪几点？"这句话不冒犯，反而显得你在对齐目标。
7. 转正自评材料
第 61 天开始准备，不要等到通知才写。材料的作用是让评审的人不用回忆，直接看到事实。
| 材料 | 来源 | 写法 |
|---|---|---|
| 交付清单 | 需求单、上线记录 | 一行一件：做了什么、什么时候上、结果如何 |
| 改进项 | 你自己的清单 | 问题、做法、效果，没效果也写，说明判断依据 |
| 协作案例 | 对齐会、跨团队需求 | 一件事：涉及谁、卡在哪、你怎么推动 |
| 遗留与计划 | 未完成项 | 明确哪些没做完、下一步怎么接 |
| 自评 | 以上四项归纳 | 三段：做到了什么、还差什么、下阶段重点 |
自评三段式
一 交付：列出 3–5 件已上线的事，每件一句结果
二 不足：写 1–2 个真实差距，附上你打算怎么补
三 下阶段：未来三个月最想拿下的那件事，以及需要什么支持
"不足"那段不要写成"我还要更努力"。写具体："跨团队对齐时我习惯先给方案再问意见，导致返工两次，后面改成先对齐目标再出方案。"这种句子比十句自我批评有说服力。
8. 汇报与沟通的改写对照
| 改写前 | 改写后 | 为什么 |
|---|---|---|
| 我在看这块代码 | 我在读订单状态机，今天能画出状态流转图，明天开始改退款回调 | 给出可验证的产出和时间点 |
| 这个需求有点难 | 这个需求要改三个服务的接口，我担心周四联调赶不上，能不能先定接口字段 | 把感受换成具体阻塞与请求 |
| 我已经在做了 | 接口写完，正在联调，今天下班前给你一个能点的测试地址 | 给状态不给态度 |
| 应该没问题 | 目前看没问题，风险在测试环境数据不全，我下午补一份 | 保留判断也暴露风险 |
| 这块不是我负责的 | 这块由 X 负责，我可以帮你确认他现在排到哪一步 | 不推事，给下一步 |
同一件事，改写后都能被追问、被验证、被安排。改写前的句子只能得到"哦，加油"。
9. 常见坑
| 坑 | 后果 | 处理 |
|---|---|---|
| 第一个月憋在知识盲区里不敢问 | 到第二个月还在问基础问题，评价直接定型 | 每天留 3 个问题，当天问掉，问完记进笔记 |
| 只做被安排的事 | 第 61 天没有可写的改进项 | 每周主动提一个观察到的问题，哪怕只是文档过期 |
| 把"忙"当产出 | 汇报里全是过程没有结果 | 汇报只写交付物与状态变化 |
| 转正前才第一次问考核标准 | 已经来不及补证据 | 第一个月的一对一里就问 |
| 出问题先自己扛三天 | 错过最佳处理窗口，还被认为不透明 | 超过半天没头绪就升级 |
10. 边界
| 场景 | 说明 | 做法 |
|---|---|---|
| 团队本身没有流程 | 八件事里有一半问不到答案 | 自己写一份，拿去和上级确认，这份东西本身就是加分项 |
| 直属上级很少沟通 | 一周说不上一句话 | 主动发起固定 15 分钟一对一，用第 4 节的结构汇报 |
| 岗位职责与 JD 不符 | 越干越偏 | 第一个月内提出，用"我想确认优先级"的说法，不要用"你们骗我" |
| 试用期被延长 | 说明有具体差距 | 要求对方给出可验证的改进目标与时间点，写进邮件 |
| 团队正在大改架构 | 地图天天变 | 把笔记做成活文档，每周更新一次差异 |
试用期不是考试，是双方确认长期合作的成本。你也在评估：如果第 90 天还有五件事问不到答案、风险也没人接，那也是一个有效结论。
11. 自测
- 你现在的阶段目标，能用一句话说出产出物吗？
- 八件事里，哪一件你还没拿到确定答案？
- 你第一次交付的东西，上线后怎么验证？
- 你最近一次汇报，有没有写清"需要谁做什么"？
- 你手上有没有一个"想改但还没动"的旧代码清单？
- 转正自评的三段，你现在能写出几段？