一、为什么新人入职清单不能只是一张 HR 表格

很多公司的新人入职清单只覆盖行政事项，比如电脑、账号、工牌、合同、考勤和办公软件。对新人真正困难的部分，往往没有被写清楚：项目怎么跑起来、核心业务是什么、哪些文件不能随便改、代码提交要走什么流程、设计规范在哪里、测试命令怎么执行、上线风险怎么判断。

这类信息如果只靠老员工口头讲，新人很容易漏掉关键细节。更现实的问题是，同一个团队里不同人说法不一致，导致新人第一周大量时间都浪费在问重复问题上。

Codex 的价值不是替 HR 写一份通用模板，而是把项目中的真实资料整理成一份可执行的 onboarding checklist。尤其是技术团队、产品团队、设计团队和内容运营团队，它可以基于仓库、文档、README、AGENTS.md、测试命令和页面结构生成更贴近实际工作的入职清单。

二、Codex 适合生成哪几类新人入职清单

新人入职清单可以分成两类：一类是公司级通用清单，另一类是项目级上手清单。Codex 更适合处理后者，也就是和具体项目、代码库、设计规范、内容流程、发布流程相关的部分。

三、生成前先让 Codex 读取哪些资料

入职清单质量主要取决于输入资料。资料越真实，清单越能落地。不要只给 Codex 一句话：“帮我生成新人入职清单”。这种结果通常会很空。更好的做法是先让它读取项目已有资料，再归纳出新人必须知道的事项。

• README.md：项目介绍、启动方式、依赖安装、基础命令。

• AGENTS.md：团队已经沉淀的编码规则、测试规则、禁止事项和完成标准。

• package.json / pnpm-lock.yaml / yarn.lock：项目依赖、脚本命令、构建方式。

• docs/ 或 wiki：业务说明、接口文档、部署流程、设计规范、内容规范。

• src/ 或 app/ 目录结构：核心模块、页面路由、组件分层。

• tests/ 或 e2e/：测试覆盖范围、回归检查方式。

• 设计稿说明或组件文档：按钮、表单、卡片、导航、空状态、错误提示等规范。

• 团队工作流：需求评审、代码审查、上线前检查、回滚方式。

四、推荐让 Codex 生成的入职清单结构

一份好用的新人入职清单，不应该只列事项，还要包含完成标准、负责人、资料入口和优先级。新人看完以后，应该知道今天做什么、本周做什么、遇到问题找谁、做到什么程度算完成。

五、第一段 Codex 指令：先扫描项目并生成资料地图

不要一开始就要求 Codex 直接生成最终清单。第一步应该让它先读项目资料，输出“新人需要知道的信息地图”。这样可以避免它凭空编造，也方便你检查遗漏。

请先不要修改任何文件。请阅读当前项目中的 README、AGENTS.md、package.json、docs 目录、src/app 或 src/pages 路由结构、components 目录、tests/e2e 目录。 请输出一份“新人入职资料地图”，包含： 1. 项目是什么，主要服务什么用户； 2. 新人第一天必须阅读的文件； 3. 本地启动、构建、测试、lint 的命令； 4. 核心页面、核心模块和关键组件； 5. 需要特别注意的设计规范、代码规范、权限和安全规则； 6. 当前项目中缺失或过期的入职资料； 7. 你建议后续生成哪些 onboarding 文档。 只输出分析结果，不要改代码。

六、第二段 Codex 指令：生成新人入职清单初稿

资料地图确认后，再让 Codex 生成正式清单。这里要明确岗位、时间范围、输出格式和完成标准。

基于刚才的资料地图，请为【前端开发新人】生成一份项目级新人入职清单。 要求： 1. 按“入职前、Day 1、Day 2-3、第一周、第二到四周、30 天评估”分组； 2. 每一项都包含：任务、目的、资料入口、负责人或协作对象、完成标准； 3. 区分必须完成、建议完成、后续了解三种优先级； 4. 明确本地环境、代码规范、组件规范、测试命令、提交流程和上线前检查； 5. 不要写泛泛的 HR 模板，要结合当前项目真实文件和目录； 6. 输出为 Markdown 表格，适合保存为 docs/onboarding/frontend-onboarding.md。

七、第三段 Codex 指令：把清单保存成项目文档

当你确认初稿方向正确后，可以让 Codex 创建文档文件。最好不要一次生成多个大文件，而是先生成一个清晰的主文档，再逐步补充角色清单。

请根据上面的新人入职清单，在项目中创建 docs/onboarding/frontend-onboarding.md。 要求： 1. 文件开头包含适用角色、更新时间、维护人和使用说明； 2. 正文包含入职前、第一天、第一周、30 天上手目标； 3. 所有命令必须引用项目中真实存在的 scripts； 4. 所有文件路径必须真实存在，如果不存在请标记为“待补充”； 5. 不要加入账号密码、密钥、客户隐私或薪资信息； 6. 最后增加“新人常见问题”和“主管验收清单”； 7. 创建文件后，输出本次新增文件路径和主要内容摘要。

八、第四段 Codex 指令：生成不同岗位版本

同一个项目里，开发、设计、产品、运营的入职清单不应该完全一样。你可以让 Codex 用同一套项目资料，分别生成不同岗位的上手路径。

请基于当前项目资料，为以下 4 类新人分别生成入职清单： 1. 前端开发新人 2. UI/UX 设计新人 3. 产品经理新人 4. 内容运营新人 每份清单都要包含： - 第一周必须读懂的项目资料； - 第一周必须跑通或完成的任务； - 本岗位最容易踩坑的地方； - 与其他岗位协作时需要注意的交付边界； - 30 天内应该达到的上手标准。 请先输出差异分析表，再分别生成 4 份 Markdown 清单。不要修改文件，等我确认后再落地到 docs/onboarding/。

九、第五段 Codex 指令：生成权限与账号申请清单

新人入职最容易卡住的地方是权限。权限清单不能只写“开通账号”，而要说明申请什么、为什么需要、找谁审批、是否有最小权限要求。

请根据当前项目和团队协作方式，生成一份新人权限与账号申请清单。 请按以下字段输出表格： - 工具或系统名称 - 用途 - 适用角色 - 权限级别建议 - 申请人 - 审批人 - 是否必须在 Day 1 完成 - 安全注意事项 请特别注意： 1. 不要输出任何真实密码、token、secret、私钥； 2. 对生产环境、数据库、支付后台、客户数据后台使用最小权限原则； 3. 如果项目资料中没有明确审批人，请标记为“待团队确认”； 4. 最后列出当前项目缺失的权限说明文档。

十、第六段 Codex 指令：生成 7 天上手计划

相比一份很长的总清单，新人更需要每天知道自己要完成什么。7 天计划适合交给直属负责人使用，也适合放进 onboarding 文档开头。

请为【前端开发新人】生成一个 7 天上手计划。 要求： - Day 1：了解项目、配置环境、跑通本地服务； - Day 2：阅读路由、组件、状态管理和数据请求方式； - Day 3：阅读设计系统、样式规范和组件复用规则； - Day 4：完成一个低风险 UI 或文档任务； - Day 5：提交第一次 PR，并完成 code review 修改； - Day 6：补充或修复一个测试； - Day 7：做一次入职复盘，列出问题、风险和下一步计划。 每一天都要包含：目标、具体任务、参考文件、完成标准、需要向谁确认。请结合当前项目真实结构，不要写通用套话。

十一、第七段 Codex 指令：生成 30 天验收标准

新人入职清单如果没有验收标准，最后只能变成形式化打勾。30 天验收标准要从业务理解、协作习惯、交付质量、问题处理四个维度判断新人是否上手。

请基于当前项目，为【前端开发新人】生成 30 天上手验收标准。 请按以下维度输出： 1. 项目理解：是否能说明核心用户、核心页面、主要业务路径； 2. 技术理解：是否能说明项目结构、组件分层、数据流、测试方式； 3. 交付能力：是否能独立完成低到中等复杂度任务； 4. 代码质量：是否遵守项目规范、能通过 lint/typecheck/test； 5. 协作能力：是否能清晰提问、及时同步、理解 review 意见； 6. 风险意识：是否知道哪些文件、权限、数据和流程不能随便改。 每个维度请给出“合格表现、不合格表现、主管检查方式”。

十二、第八段 Codex 指令：检查入职文档是否过时

入职清单最常见的问题是生成后没人维护。项目结构、命令、部署方式、组件目录一变，旧清单就会误导新人。可以定期让 Codex 检查 onboarding 文档和真实项目是否一致。

请检查 docs/onboarding 目录下的新人入职文档是否已经过时。 请对照当前项目真实情况检查： 1. 文档里提到的文件路径是否存在； 2. 文档里提到的 npm/pnpm/yarn 命令是否存在于 package.json； 3. 文档里提到的组件目录、路由目录、测试目录是否准确； 4. 文档里的提交流程、测试流程、构建流程是否和 AGENTS.md/README 一致； 5. 是否出现了不应写入文档的敏感信息； 6. 哪些内容需要删除、更新或补充。 先输出审计报告和修改建议，不要直接修改文件。

十三、可以放进 AGENTS.md 的入职文档规则

如果团队希望 Codex 后续持续维护 onboarding 文档，可以把稳定规则写进 AGENTS.md。这样每次让 Codex 更新入职清单时，它都能按同一套标准执行。

新人入职文档规则

创建或更新入职文档时，必须使用真实项目文件、命令、目录和工作流，不要编造路径。不要写入密码、令牌、API key、客户隐私数据、薪资数据或个人 HR 记录。缺少信息时标注 TODO，不要猜。每个清单项都要包含目的、负责人、优先级和完成标准。公司级入职和项目级入职要分开；必要时为开发、设计、产品和运营提供不同版本。涉及项目验证时，要包含 lint、类型检查、测试、构建等命令。文档要足够简洁，让新人第一天可以完成基础设置，减少重复提问。更新文档时，要对照 README、package.json、docs、src、tests 和部署说明。每份入职文档结尾都应包含 7 天计划和 30 天验收清单。

十四、新人入职清单模板示例

下面是一份可以让 Codex 生成并落地到 docs/onboarding/ 的清单结构。实际项目中，最好让 Codex 根据真实文件路径和命令自动替换。

十五、不同岗位的清单差异

同一个项目可以共用“项目介绍”和“协作规则”，但岗位任务必须拆开。否则新人会看到很多与自己无关的内容，真正重要的内容反而被淹没。

十六、让 Codex 生成清单时要避免的错误

• 不要只写“生成新人入职清单”，否则结果会变成通用 HR 模板。

• 不要让 Codex 编造不存在的文件路径、命令、负责人和权限流程。缺失信息应该标记为待确认。

• 不要把账号密码、密钥、客户数据、员工个人信息写进入职文档。

• 不要把所有岗位混在一份清单里。通用部分可以共用，执行任务必须按岗位拆分。

• 不要让新人第一周承担高风险任务，比如支付、权限、生产数据库、核心交易链路。

• 不要只生成清单，不写完成标准。没有完成标准，清单无法验收。

• 不要让入职文档长期不更新。项目命令、目录和流程变化后，要让 Codex 定期对照真实代码检查。

十七、人工验收清单

Codex 可以快速整理项目资料，但最后必须有人审核。特别是权限、安全、客户数据、内部流程这些内容，不能完全依赖自动生成。

十八、常见问题

1. Codex 能不能直接替 HR 写完整入职流程？

可以生成通用结构，但不建议完全替代 HR 流程。劳动合同、薪资、社保、隐私材料、绩效制度等内容必须由公司负责人或 HR 审核。Codex 更适合生成项目级、岗位级、知识交接级入职清单。

2. 没有 AGENTS.md，还能生成清单吗？

可以。没有 AGENTS.md 时，可以先让 Codex 读取 README、package.json、docs 和目录结构，生成资料地图。后续再把稳定规则沉淀进 AGENTS.md。

3. 新人入职清单应该放在哪里？

技术项目建议放在 docs/onboarding/，并在 README 里链接。设计或运营项目也可以放在 Notion、飞书、Confluence 等文档系统，但最好保留一个项目内入口。

4. 清单应该多长？

不要追求长。第一天清单要短，保证新人能完成。详细资料可以作为链接放在后面。真正好用的清单应该让新人知道优先级，而不是把所有资料一次性堆给新人。

5. 多久更新一次入职清单？

项目结构、启动命令、部署流程、权限流程、设计系统发生变化时必须更新。即使没有明显变化，也建议每月或每次版本大迭代后让 Codex 对照真实项目检查一次。

十九、总结

用 Codex 生成新人入职清单，核心不是让 AI 写一份漂亮文档，而是把项目真实规则转成新人能执行的上手路径。正确流程应该是：先扫描项目资料，再生成资料地图，然后按岗位生成清单，最后把清单落地为 docs/onboarding 文档，并定期对照真实代码和流程更新。

对研发、设计、产品和运营团队来说，这类清单能明显减少重复沟通，也能让新人第一周从“到处问人”变成“按路径上手”。但所有涉及权限、安全、客户数据和人事信息的内容，必须人工审核，不能让 Codex 自行决定。

参考依据： - OpenAI Codex 官方资料：Codex 用于软件开发工作流，包括代码理解、重构、测试、代码审查和项目自动化。 - OpenAI Codex Best Practices：复杂任务应提供上下文、先计划、把稳定规则沉淀进 AGENTS.md。 - OpenAI AGENTS.md 文档：Codex 会在开始工作前读取 AGENTS.md，并可按全局、仓库、子目录层级应用规则。 - OpenAI Codex 指令ing 文档：提示词应包含相关文件、上下文、验证步骤，并把复杂任务拆成更小步骤。