入职摸底 SOP
新人进入陌生业务后的系统化摸底流程：用一份持续更新的文档，把个人定位、产品架构、页面路径、团队路由、问题清单、文档底库和阶段复盘串成完整 onboarding 操作系统。
简介
入职摸底 SOP 是一种面向新岗位、新团队、新业务线的个人工作方法论。它的核心不是“入职培训 checklist”，而是让新人从第一天开始主动构建一份小型业务手册：我在组织里的位置是什么、这条业务给谁用、用户真正要解决什么问题、产品当前由哪些能力层组成、团队协作找谁、已有资料在哪里、还有哪些问题需要追问。
这套方法来自小普在海外 Agent 产品方向岗位上的入职实践。作者所处业务要同时理解模型能力、模板、画布和团队协作模块，因此如果只靠会议和口头介绍，很容易陷入“每天打开很多页面、听到很多名词，但没有骨架”的状态。入职摸底文档的作用，就是把陌生信息持续落到结构化页面上，让零散信息逐渐形成可复用的业务地图。
入职摸底 SOP 与 工作SOP 的关系是“场景特化”。工作 SOP 解决的是执行、复盘、沟通、时间管理等高频工作环节；入职摸底 SOP 解决的是“换环境后如何快速建立业务认知和协作网络”。它也与 业务架构师 的“驻场局外人”姿态相关：新人刚进入组织时，既不完全懂内部惯性，又还保留外部用户视角，最适合用架构图、用户路径图和问题清单捕捉老员工已经习以为常的问题。
关键信息
- 类型：个人工作方法论 / 新人上手流程
- 适用对象：AI 产品经理、普通产品经理、运营、设计、工程、算法、数据等进入新团队的人
- 核心产物：一份持续更新的“入职摸底文档”
- 核心模块：个人定位、产品与能力信息架构、页面功能架构与用户路径、团队路由、问题清单、文档资料底库、阶段行动计划、阶段复盘
- 核心目标：把入职期的陌生信息变成可回看、可追问、可复盘、可迁移的业务认知资产
- 相关概念：工作SOP、AI产品经理工作流、业务架构师、Product Manager Skills、自我产品化
核心特性
1. 从“个人定位”开始，而不是从任务列表开始
入职摸底 SOP 的第一步是写清楚自己在组织地图上的位置：业务线、团队、负责产品、上下游、用户群体、用户核心诉求、小组在链路中的位置。很多新人上手慢，并不是因为不会执行，而是没有先弄清楚“自己做的事情给公司带来什么价值”。如果只能说出直属上级和当前任务，却说不清自己在业务链路中的位置，后续做需求、评审、汇报和面试都会停留在执行者视角。
这一步没有一次性标准答案。正确做法是先写一个基于当前理解的版本，然后在第二天、第三天的会议和沟通中不断修改。当基础定位不再频繁变化，说明新人对业务轮廓已经形成稳定理解；当定位仍频繁改写，说明还需要继续追问上下游和价值指标。
2. 用产品信息架构图建立脑内骨架
复杂 AI 产品通常同时包含用户入口、工作流、模板、插件、模型能力、底层资源和多个协作团队。如果没有信息架构图，每个功能都像散落的小零件。入职摸底 SOP 要求新人把产品按层级画出来：用户入口与场景、主要流程与关键路径、核心工具与服务模块、底层能力与资源约束。
作者以 KIMI 作为脱敏 Demo，提出 AI 产品可先参考“用户层、技术层、模型层、基础层”四层结构，但不应机械套用。每家公司产品架构不同，刚入职时也不可能一次拿到全部信息，所以图可以先用模糊描述占位，再在后续会议、文档阅读和产品体验中逐渐替换。它的价值不是“第一版画得多漂亮”，而是让每个新听到的名词都能落到某个层级上，从而让问题问得更准。
3. 把新人视角转化为页面功能架构和用户路径图
刚入职阶段有一个不可复制的优势：你既接触了内部信息，又还没有完全被组织惯性同化。即使过去用过公司产品，从外部用户转为内部开发者的过渡期，也最容易看到老员工忽略的细节。入职摸底 SOP 因此要求新人上手体验现有产品，拆解页面功能架构和用户路径，而不是只等业务方或用户推动需求。
这个动作对产品经理尤其重要。它能帮助新人发现“看起来合理但用户走不通”的路径、“内部术语理解但外部用户不懂”的页面、“老员工已习惯但新用户卡住”的细节。等新人作为内部角色沉浸太久，就会开始假设用户场景、对自家产品产生滤镜，那时这类观察窗口就会消失。
4. 团队路由降低协作摩擦
团队路由解决的是“遇到什么事找谁”。新人最慌的不是不会做事，而是不知道工程、算法、设计、运营、业务负责人、项目负责人各自承担什么职责。入职摸底文档不需要写真实敏感人名，可以记录角色和职责：业务负责人负责方向，前后端负责实现链路，算法负责模型能力，设计负责交互规范，运营负责活动或内容策略。
团队路由在第一个月价值最大。随着人逐渐认识，它可能不再需要高频查看，但前期能显著减少错误沟通和重复转问。更重要的是，它让新人从“所有问题都找直属上级”转为“根据问题类型找到正确节点”，这本身就是从执行者向系统协作者转变。
5. 问题清单必须主动闭环
入职问题清单不是把疑惑写下来等别人回答，而是按主题整理后主动约人闭环。作者建议新人预估问题解释成本，提前告知同事：“xx 点到 xx 点什么时候有空？预计占用您 xx 时间，请教一些问题。”确定后主动约会议室。这种做法有两个价值：一是提升问题解决效率，二是让同事感受到新人尊重时间、做过准备、不是临时抓人。
问题清单可以按业务方向、用户与场景、流程与协作、技术或实现、自我定位与成长分类。每个问题后都应预留空间记录已获得的信息和结论。久而久之，它会从“疑问表”变成“业务 FAQ”和“个人知识库入口”。
6. 文档底库把资料转成可用知识
新人常见痛点是资料太多：邮件、群消息、云文档、周报、需求池、评测标准、能力列表、用户调研散落各处。入职摸底 SOP 要求建立一张文档底库表，包含文档名称、主题、链接或存放位置、重要程度、岗位相关度、个人理解、关键信息摘录和待追问点。
这一步的本质是从“收藏链接”升级为“索引知识”。如果只保存链接，几天后仍然不知道哪个文档写了什么；如果每条资料旁边都写自己的理解和相关度，它就变成后续写 PRD、做评审、问问题、复盘业务时可直接调用的底层资料库。
不同素材中的观点
- 2026-05-25-woshipm-ai-pm-onboarding-sop：小普把“快速跑顺陌生业务”的经验拆成六个可执行模块：个人定位、产品信息架构图、页面功能架构与用户路径图、团队路由、问题清单、文档汇总。文章的关键贡献是把入职期的混乱信息处理过程 SOP 化：先给自己在组织地图上定位，再给产品建立分层骨架，随后用新人视角拆页面和路径，用团队路由降低协作成本，用问题清单主动闭环，用文档底库把资料变成可回看的业务知识。它还补充了一套跨岗位迁移方式：运营按活动/资源/渠道预算分层，设计按规范/约束/案例目标分层，工程和算法按系统模块/第三方服务/数据流/技术债分层。本文让 工作SOP 从“日常执行效率”扩展到“新团队适应”，也为 AI产品经理工作流 补上了 AI PM 入职初期的业务摸底方法。
实用信息
快速上手步骤
- 开一个入职摸底文档：第一天就建，不要等完全理解业务后再写。
- 写个人定位：业务线、团队、负责产品、上下游、用户群体、核心目标、岗位相关指标。
- 画第一版架构图：先粗糙画出用户入口、主要流程、工具模块、底层能力；不清楚的地方用占位描述。
- 拆页面和用户路径：以新人视角体验产品，记录卡点、疑惑、可能的功能遗漏和术语不清。
- 建团队路由：只写角色和职责即可，记录什么问题找什么角色、需求如何流转、异常如何升级。
- 整理问题清单：按主题归类，预估解释成本，主动约同事闭环，并把回答写回文档。
- 建文档底库：把周报、需求池、评测标准、用户调研、能力列表等资料统一索引，并写自己的理解。
- 做阶段复盘：入职一段时间后回看哪些假设被证实、哪些被推翻、下一阶段如何调整行动方向。
常用模板
| 模块 | 核心问题 | 输出物 |
|---|---|---|
| 个人定位 | 我在业务和组织链路中的位置是什么？ | 业务线、团队、负责范围、核心目标 |
| 业务概览 | 用户是谁、诉求是什么、业务处于什么阶段？ | 业务描述、用户群体、岗位相关指标 |
| 产品信息架构 | 产品由哪些层级和能力组成？ | 产品/能力架构图 |
| 页面与路径 | 用户如何完成关键任务，哪里可能卡住？ | 页面功能架构图、用户路径图 |
| 团队路由 | 遇到不同问题应找谁？ | 角色职责表、协作链路图 |
| 文档底库 | 资料在哪里，各自解决什么问题？ | 文档索引表、个人理解、待追问点 |
| 问题清单 | 当前最大不确定性是什么？ | 分主题问题表和已获得结论 |
| 阶段复盘 | 哪些理解变了，下一步怎么调？ | 假设验证记录和行动调整 |
与相似概念的区别
- 入职培训 checklist：通常由公司提供，强调账号、权限、制度、流程；入职摸底 SOP 由个人主动维护，强调业务理解、产品架构、协作网络和问题闭环。
- 工作SOP：覆盖执行、沟通、复盘、时间管理等通用场景；入职摸底 SOP 是工作 SOP 的入职场景版本，重点在“陌生信息结构化”。
- Product Manager Skills：把 PM 工作拆成可由 AI Agent 调用的技能库；入职摸底 SOP 是个人手动维护的 onboarding 方法论，未来可被进一步编译成 Skill。
- 业务架构师：强调在企业 AI 项目中抽象隐性 SOP、编译给 Agent；入职摸底 SOP 是业务架构师能力的起步训练，用文档和架构图先建立业务地图。
注意事项 / 避坑指南
- 不要等懂了再写：入职摸底文档的价值恰恰在于记录“从不懂到懂”的过程。
- 不要只收藏资料：每条资料旁边必须写自己的理解、岗位相关度和待追问点，否则底库只是链接仓库。
- 不要把新人视角浪费掉：刚入职时的困惑往往就是用户也会困惑的地方，过了这个阶段就很难再看见。
- 不要所有问题都找直属上级：团队路由的目标是让问题找到正确节点，减少协作摩擦。
- 不要追求架构图一次画准：先用模糊占位搭骨架，再随着资料和沟通逐步替换。
- 不要把模板机械套给所有岗位：运营、设计、工程、算法、产品的分层逻辑不同，模板必须按岗位目标重写。