每次换工作，我都会被问同一个问题，你怎么总能在很短的时间里，把一条完全陌生的业务跑顺？

听上去好像是那种天赋型人物的故事，好像我天生就对新环境适应得快

但我自己很清楚真正起作用的，是一套我反复打磨出来的入职摸底习惯。表面上看只是习惯，往深里看更像是一份写给自己的小型业务手册

从新公司报到那天开始就不断补充，既是备忘录，也是认知校准工具。

最近这一份入职摸底文档，是在一条海外产品方向的业务线上写的，岗位是做Agent相关的产品。要和模型能力打交道，也要和模板、画布这些模块一起协作。那几天我几乎是边了解业务边往文档里写。

现在回头看这份文档已经能当作一个案例了，所以刚好借这个展开讲清楚入职摸底这件事。

个人定位

那天报道结束回到住的地方，我开了一个空白页，在最上面写了几行简单的信息：

业务线：xx｜团队：xx｜所负责产品：xx

这几个字看上去没什么技术含量却是整份文档的锚点，就好像给自己在一张巨大地图上点了一个小红点，在公司组织架构上你是处于什么位置？上下游是谁？你做的产品是什么？有的同学离职了都不知道"自己是谁"，不知道自己在公司中的定位，以及自己做的事情能给公司带来什么价值。这个非常关键，尤其是在你跳槽找下一份工作的时候，问到你的定位时，你只能含糊不清或者仅辐射到你的+1-1。

如果你作为一个产品，这肯定是不行的，说白了会让人觉得你就是一个闷头做事的执行者，如果是面试管理岗肯定是必挂。

 这一条业务给什么样的人用？
 用户真正想解决的问题是什么？
 我们提供的是工具还是完整解决方案？
 我所在的小组在这条链路里的位置在哪一段？

这些问题一开始没有标准答案，我就先按照自我理解写一个版本

第二天、第三天开会的时候，只要听到和这些问题相关的信息就回来改，有时删掉几句，有时把一句话拆成两三行。

等这部分文字不怎么需要改动时，说明我对业务的整体轮廓已经有比较稳定的认识

这个阶段文档还比较薄，但已经可以帮我过滤信息：

哪些是和岗位密切相关的

哪些是暂时可以放一放的

这样脑子里不会那么乱

产品信息架构图

整份文档里最醒目的区域，产品的整个架构，我把这个业务拆成了好几层，从用户一眼能看到的功能入口，一直画到最底下的基础模型能力。这里是拿KIMI这个产品做的一个架构Demo，并不是我公司产品，毕竟要脱敏的哈。

产品架构图是你最快了解公司产品全貌的，它的作用：

认知拉齐：对齐产品团队、对齐技术团队、对齐管理层

指导执行：规划开发节奏、开发规范化、评估可行性

排查问题：识别依赖风险、发现功能遗漏、预判扩展性瓶颈

沉淀经验：记录演进轨迹、新人快速上手

一般一个AI产品的架构，你可以从这四个层级去看：用户层、技术层、模型层、基础层。

但是刚入职，很多信息是很难获取到的，这个架构可以逐渐补充，而且公司产品架构各有不同，并不一定都是这四个层级，该架构也仅供参考，毕竟我并不是KIMI的内部员工，只能结合体验和一些官方信息来反推。

信息架构那一块，是整份文档里我最投入的一部分。我把产品拆成几层，画这张图的时候我一边翻产品一边看需求文档和能力列表。每多理解一点，就在图上补上一块。

有的模块暂时还搞不清就用一个比较模糊的描述先顶上，后续再慢慢替换。

这张图的意义有两个：

一是帮我在脑子里搭出骨架。面对复杂的业务如果没有骨架，所有功能都像散落一地的小零件；

二是方便沟通。很多同事讲需求的时候会直接说某个模型某个工具，我就把这些名词在图上找位置。一旦落在具体层级，我要问的问题也更清楚。

页面功能架构图 & 用户路径图

当然，作为产品经理，你肯定是要上手体验公司产品的。公司不会等你入职才开始做产品，所以肯定是有自己产品的，那你也可以去全方位体验现有产品的所有功能，顺便拆解一下页面功能架构 & 用户使用路径，还是以KIMI为例：

这个很关键，作为产品经理是一定要会发现问题并提需的，不能只等着业务或者用户推动，那会非常被动。而刚入职，从一个新人视角去看产品是非常容易发现问题的，所以一般刚入职的产品给出的建议，领导是非常重视的。

即便你之前用过公司产品，从外部用户转变成内部开发者，转变期你会看到很多老员工忽略掉的细节。我在刚入职时提到的很多建议和想法，老板都非常认可，所以千万不要想着自己刚入职什么都不懂，不敢发言，那你将错失很多机会。

而且这个阶段的想法和视角是不可复现的，等你作为开发者沉浸在产品中，你会一叶障目、会假设用户场景、会对自家产品产生滤镜。

团队路由

团队中你遇到什么事找什么人，找对人很关键。尤其是新人，最慌的就是谁也不认识，只认识+1，遇到什么问题让你去联系工程或者问一下算法，你都不知道找谁。

依旧脱敏处理，我只写角色和对应。例如业务负责人、团队负责人、前端后端等等。

每个公司的团队构成和你的职位需要对接的人肯定都不一样，所以看具体情况去进行记录，这个路由对于你入职第一个月帮助最大，慢慢都认识了，其实就不需要这个表了。

问题清单

刚入职肯定是有很多问题的，不要等着同事、老板来主动找你说、不要被动

主动去了解公司产品，并且整理出你的问题清单，形式不定，我习惯用表格形式（常规表格/飞书多维表格）

一般来说入职会有老人带你，点给人家买个咖啡、甜点什么的

主动发起会邀，在此之前预估下这些问题的解释成本，估算一个合适的时间，提前告知同事：

"xx点-xx点什么时候有空？预计占用您xx时间，请教一些问题"，确定大致时间后主动约好会议室并告知同事

这一圈下来你的问题解决了，同事对你的评价也会非常高

文档汇总

包括所有能拿到的文档整理，我会把各类资料按主题归到一张表里，什么周报、需求池、评测标准、能力列表、用户调研全部丢进去。

每一条旁边都写上自己的理解，避免找文档时找不到。很多人入职会遇到一种体验，资料多到看不完。邮件、群消息、云文档到处都是链接。每天都在打开新页面，却很难记住哪一个地方写了什么

我对这种状态很不安心，于是习惯建一张文档底库表：

不同岗位如何套用同一份模板

虽然我是以AI产品经理的视角来写这份文档，不过这套方法稍微改一改。运营、设计、工程、数据同学都能用

如果你是做运营的，信息架构那块可以换一种切法：

把产品层换成活动类型
把工具层换成你可以调动的资源
把底层能力换成渠道和预算约束
团队路由就重点写清楚
和商务、内容、投放之间的配合方式

如果你是做设计的：

可以多记一些关于视觉规范、交互约束、各端适配规则的内容
文档底库里把不同风格的优秀案例整理起来
同时记录这些案例背后的业务目标
而不是只停留在好看这一层

如果你是做工程或算法的：

 可以把架构图拆成系统视角
 写清楚哪些模块是核心
 哪些模块是第三方服务
 数据从哪里来
 如何流动
 在什么环节被加工
 问题清单里就可以多关注技术债和潜在风险

同样一份模板，每个人套进去的内容会不一样，但那种“心里有数”的感觉是共通的！整个入职摸底文档我抽象出来整理了一个结构放在了最后，需要自取。

写给正在准备换工作的你

写这篇文章的时候，我会不时回想自己刚入行的那几年。那时完全没有什么入职摸底的概念，拿到电脑，建好各种账号，就开始在各种会议里晃。别人聊什么就跟着点头，到了需要自己负责东西的时候才发现很多前提根本没弄懂。

后来吃了几次亏，我才开始给自己设一个小小的要求。

每换一次环境，至少要留下一个可以回看的东西。无论是简单的时间线，还是像现在这样比较完整的文档。只要能让我在几个月之后还能清楚地回忆起那段时间自己是怎么理解这份工作的，就值。

如果你刚好也在准备入职新团队，或者刚刚入职不久，不妨给自己也开一份入职摸底文档。刚开始不需要追求格式多漂亮，先把那几个关键问题写下来，慢慢添砖加瓦，过一阵子回头看你可能会发现，这一份文档不仅帮你适应了新环境，也顺便记录了自己作为职场人的一次升级！

# 入职摸底文档

## 基本信息
岗位方向  
所在业务线和团队简称  
当前负责范围和核心目标  

## 业务概览
这一条业务面向的用户群体  
用户最核心的诉求  
业务目前的阶段与整体方向  
与你岗位直接相关的结果指标  

## 产品与能力信息架构
用分层方式描述当前产品或系统  
建议包含这些层级  
用户入口与场景  
主要流程与关键路径  
核心工具与服务模块  
底层能力与资源约束  
必要时补充简要说明  

可以在这一节下方放架构示意图  
留一个占位文本  
配一张产品信息架构图  

## 团队协作与路由
列出主要角色及职责简述  
需求从出现到落地的大致流转链路  
日常高频协作对象  
决策相关角色与节奏  
风险或异常出现时的处理路径  

## 文档与资料底库
建立一张表格  
建议包含这些字段  
文档名称  
大致内容或主题  
链接或存放位置  
重要程度分级  
与你岗位的相关程度  
你的理解与关键信息摘录  
后续需要追问或确认的点  

## 问题清单
按主题整理问题  
业务方向相关  
用户与场景相关  
流程与协作相关  
技术或实现相关  
自我定位与成长相关  
在每个问题后预留空间  
补充已获得的信息与结论  

## 入职阶段行动计划
近期目标  
例如试用期内需要完成的成果  
本周要推进的具体事项  
需要哪些同事支持  
可能遇到的阻力与应对方案  

## 阶段复盘
在入职一段时间后补充  
当前对业务的理解是否发生变化  
哪些假设被证实  
哪些假设被推翻  
下一阶段准备调整的行动方向