入职第七天的晚上，我在笔记软件里敲下四个字：第一星期所学。那时候我刚跳到一个全新的技术团队，语言、框架、业务流程几乎全是陌生的，白天扎在环境配置和代码阅读里，晚上回家把零零散散的东西记下来。一周过去，把这些笔记整理成文，才发现这七天的信息密度抵得上过去一个月的量。这篇内容写给两类人看：一类是即将入职新公司、想提前知道第一周该怎么过的同学；另一类是正处在自己“第一星期”里、项目没跑通、代码看不懂、需求接不住，想看看别人怎么挣扎过来的人。
先说个结论：第一周最重要的不是写出多少功能，而是把“环境跑通、链路走通、规范听懂、自记录习惯建立”这四件事做完。做到这四件事，第二周开始接需求才有底气；做不到，后面几周都在还第一周的债。接下来我把这一周拆开来讲，从目标设定、环境搭建、代码阅读、需求实操、复盘沉淀到踩坑排查，全是我亲身实践过并且能直接复用的方法。
1. 第一星期真正该学什么：目标拆解与学习地图
1.1 别一上来就啃代码，先把“学习地图”画出来
我见过太多新人入职第一天就打开项目仓库，从 README 开始逐字看，看到 controllers 目录就昏睡过去。这个方式不是不对，而是没有顺序。第一周的核心矛盾是：知识量巨大，时间极短。你不可能在五天里理解整个系统，但你可以用第一天把“地图”画出来。
所谓地图，就是四份清单：
- 系统清单：这个项目对外提供哪些服务、面向哪些用户、解决什么问题。
- 技术栈清单：语言、框架、中间件、存储、消息队列、部署方式各是什么。
- 模块清单：仓库里有哪些子项目/模块，模块之间怎么调用，依赖方向是什么。
- 团队清单：代码谁负责、接口谁维护、需求找谁确认、风险找谁同步。
这四份清单不用写得多详细，每项一两行就行。但一定不要跳过，因为它们是后续所有学习的坐标。我第一周第一天上午就在做这件事，下午才打开代码编辑器。事实证明，先有地图再看路，效率远比漫无目的地乱翻高得多。
1.2 第一周的能力目标不是“会写”，而是“敢跑”
很多新人给自己定的第一周目标是“学会框架”“写出完整功能”，这其实是第二三周的事情。第一周的目标应该更低、更具体：能在本地把项目跑起来，能顺着一条业务请求从前端走到数据库，能在别人指导下改一个小需求。
这三个目标有一个共同点——它们都强调“跑通流程”而不是“理解原理”。为什么？
打个比方，你搬进一个新城市，第一周最重要的是知道超市在哪、地铁怎么坐、公司几点打卡，而不是研究这座城市的城市规划史。代码也是一样，第一周你要建立的是“我能在哪儿改代码、改了之后怎么验证、出了问题找谁问”的肌肉记忆。原理可以后面补，但手感必须在第一周就有了。
所以我给自己的量化指标是：第一天跑通项目，第二至第三天读完一条核心业务链路，第四至第五天完成一个被明确指派的微小需求。五项全完成，第一周就算及格。
1.3 时间预算怎么分：五天的黄金配比
有人问，五天时间到底怎么分？我提供一个经过验证的配比，不是死板地平均分配，而是根据认知规律做了先后安排：
| 时间段 | 核心任务 | 预计占比 |
|---|---|---|
| 第一天上午 | 熟悉团队、账号权限、文档入口、画地图 | 10% |
| 第一天下午至第二天全天 | 环境搭建、项目跑通、依赖安装 | 25% |
| 第三至第四天 | 阅读核心链路代码、配合调试走通请求 | 30% |
| 第四至第五天 | 接手第一个小需求、完成开发与自测 | 25% |
| 第五天下午 | 整理笔记、写周报、向导师汇报 | 10% |
这个配比的核心思想是：环境问题必须集中攻克，不要拖到后面。代码阅读和需求开发可以交叉进行，因为读代码的最终目的就是为改代码做准备。第五天一定要留出时间做复盘，不做的同学第一周等于白过一半。
2. 环境搭建与技术栈摸底：把“能跑”变成“跑通”
2.1 环境坑位清单：从语言版本到包管理
第一周的麻烦，一半出在环境。我自己的经验是：不要信 README 上的“一键安装”，要信自己手上跑出来的结果。新团队的环境大概率和你以前习惯的不一样，语言版本、包管理器、镜像源、数据库账号、Redis 地址，每一项都可能给你“惊喜”。
这里给出一份通用的环境检查清单，照着逐项核：
- 语言运行时版本（比如 JDK 11 还是 17，Node 16 还是 20，Go 1.21 还是 1.22）
- 包管理器版本及镜像源配置（npm/pnpm/yarn、Maven/Gradle、pip/poetry）
- 本地数据库版本和连接串（MySQL、PostgreSQL、MongoDB 等）
- 缓存/中间件（Redis、RabbitMQ、Kafka 等）是否本地启动
- 代码仓库权限、Git 用户信息是否配置正确
- IDE 插件：是否有团队统一的基础插件（如 Lombok、ESLint、Prettier）
- 编译/启动是否依赖内网私有仓库或特殊 DNS 配置
每一项花不了十分钟，但漏掉任何一项都可能卡住半天。我第一周就栽在数据库版本上：项目代码用的是 MySQL 8.0 的窗口函数，本地装的是 5.7，一启动就跑 SQL 报错。排查了整整一个下午才发现是这个原因，气得不行。
2.2 跑通“Hello World”和跑通“真实项目”是两码事
很多同学以前自己写练习项目，npm install 一下，npm start 就完事了。真实项目和练习项目最大的区别在于：真实项目有外部依赖、有配置中心、有团队统一规范，还可能有别人正在改的代码。
所以跑通真实项目的完整标志是：项目能启动，能连上所有依赖，能通过接口或页面完成一次真实数据的前后打通。你可以在本地启动后用接口测试工具请求一个只读接口，看到返回正常数据，才算真正的“跑通”。
我第一次跑项目时，项目启动成功，但登录接口一直报 401。查了大半天，后来发现是本地 Redis 缓存里存了一份旧 token，而 token 的密钥和当前代码不一致。清掉缓存重新启动就好了。所以后来我给自己定了一条规矩：环境问题排查顺序永远是“缓存 > 配置 > 依赖版本 > 代码”，先怀疑环境，再怀疑代码。
2.3 快速摸清技术栈的三个入口
项目跑通之后，就要开始试探技术栈了。我不建议去读框架官方文档从头学，那太慢了。第一周你只需要知道三个入口：
- 项目启动入口：看 main 函数、启动类、入口配置文件，搞清楚“程序是从哪里开始执行”的。
- 路由/控制器入口：找到所有 HTTP 接口的注册位置，理解“外部请求从哪里进入系统”。
- 数据库/存储入口：看数据库连接配置、ORM 或 SQL 文件、数据表结构，理解“数据落在哪里”。
这三个入口组成一条线：请求进来 → 入口处理 → 数据落库。把这条线理顺，你就已经比 50% 的新人强了。我记得自己第一周第二天晚上，就在文档里画了这三层的关系图，线条画完的一瞬间，整个项目的骨架一下就清晰了。
3. 从阅读代码到独立改造：第一次接需求的全流程
3.1 读代码的正确姿势：按请求链路走，而不是按目录走
新手读代码最大的误区是打开目录树，从第一个文件夹开始，用看小说的方式往下读。真实项目动辄几十万行，你这样读下去，第三天就开始怀疑人生了。
我的方法是挑一条最简单的业务请求，比如“查询某用户的订单列表”或“获取某个页面的配置信息”，沿着它走完整条链路：
- 用全局搜索找到对应的 Controller 方法
- 看方法参数和注解，搞清楚请求是什么格式
- 跟踪 Service 层的调用，看业务逻辑分了几步
- 看 DAO/Mapper 层的 SQL 或查询条件，知道数据怎么取
- 回到 Controller 看返回结构，知道响应是什么样
每一步都用 IDE 的“Find Usages”或“跳到定义”功能追踪，不要凭眼睛猜。如果你觉得跳来跳去容易迷失，那就在 IDEA 或 VS Code 里打断点，用 Debug 模式走一遍请求，盯着调用栈看数据怎么流动。
我第一次这样做的时候，惊讶地发现一条“简单”的订单列表接口，居然经过了三次外部服务调用、两次本地缓存检查、一次数据库查询。不看调用栈，我这辈子都想不到系统是这样设计的。
3.2 第一次接需求：先画影响面，再动手
第五天我被指派了第一个需求：给某个详情页增加一个字段展示。听起来很简单，但真正动手前，要先画“影响面”——也就是这个改动会波及哪些地方。
我是这样做的：
- 先确认这个字段来自哪个上游接口的数据
- 再找到详情页对应的响应 DTO（数据传输对象）
- 然后找到前端渲染这个页面的模板或组件
- 最后检查这个 DTO 是否被其他接口复用，有没有“改一个字段，炸了另一个页面”的风险
这一步很多人会忽略，觉得“改这么一点，直接写就完了”。但踩过的坑告诉我，真实项目里最可怕的不是功能复杂，而是“低层改动被高层多处复用，你只改了一处”。所以第一周接需求，宁可多问三句，也不要少想一步。
3.3 提交代码之前要做的四件事
第一次提代码之前，我花了整整一晚上看团队同事最近的提交记录，总结出一套“提交前四查”：
- 查变更范围：用
git status和git diff看自己改了哪些文件，确保没有顺手改到无关代码。 - 查格式规范：团队如果有代码格式化配置（如 Prettier、ESLint、Checkstyle），提交前跑一遍，别让格式问题拖累 Code Review。
- 查自测结果：自己的改动至少跑通一次本地接口测试，别把“我猜应该没问题”当成结论。
- 查提交信息：提交信息要写清楚“改了什么事，为什么改”，不要写 “fix bug” 这种让人想打人的信息。
我见过一个同事，改了三行代码，提交信息写“update”。结果三个月后查责任归属，谁都想不起来这条提交是干嘛的。提交信息是写给未来同事看的，也是写给未来的自己看的，多写一句“增加订单详情页的库存显示字段，数据来自库存中心的 api”，以后回溯成本直接归零。
4. 每天的复盘闭环：让“所学”变成“所得”
4.1 每日三问：今天解决了什么问题，卡在哪儿，明天做什么
第一周信息量太大，如果不做当日复盘，周五晚上你会发现自己什么细节都想不起来。我的方法是下班前十分钟，打开笔记软件回答三个问题：
- 今天解决了什么问题？
- 今天卡在哪儿，花了多久，最终怎么解决的？
- 如果明天继续做手上的事，第一步是什么？
这三个问题各有用途。解决什么问题，是在记录你的产出；卡在哪儿，是在暴露你的薄弱点；明天第一步是什么，是为了让第二天不用重新“热启动”。
我第一周发现，真正值钱的记录不是“我今天学了 Spring Cloud 网关”，而是“网关的 api 前缀走了三次重试才成功，原因是本地 host 没配置网关域名”。后者才是你自己踩出来的经验，换成任何别的地方都用得上。
4.2 用 KPT 复盘模板沉淀第一周
每日三问是过程记录，周末还需要一次结构化的收敛。我用的工具是 KPT 复盘模板，总共三列：
| K（Keep 保留） | P（Problem 问题） | T（Try 尝试） |
|---|---|---|
| 每日写笔记的方法有效 | 环境排查耗时太长 | 下次先统一确认版本再开工 |
| 按请求链路读代码效率高 | 提问不够精准 | 提问前先写出自己的排查过程 |
| 提交前自查四查很好用 | 上午容易陷入杂事 | 每天上午先安排两小时深度工作 |
这个模板的好处是：记录不是终点，改进才是终点。T 列里写的每一个“尝试”，都应该成为下一周第一天的动作清单。我第一周 wrote 三条 T，第二周执行了两条，立刻感觉效率上了一个台阶。
4.3 个人学习笔记的规范：可检索、可回溯
最后聊聊笔记本身。第一周你会记很多东西，如果没有规范，周五翻笔记就像翻垃圾堆。我自己的笔记规范很朴素，只有三点：
- 按日期归档：每天一个文件，命名格式
日期-主题.md，比如20250607-环境搭建.md。 - 每个文件开头写“今天关键词”：三五个词就行，以后搜索时有索引。
- 遇到错误，记录“报错信息 + 解决步骤”：不要只写结论，把操作命令和截图都放进去，因为下次你可能还会遇到。
我当时把 Redis 缓存导致 401 的排查过程完整记了下来，两周后同事遇到相同问题，我直接把笔记甩过去，他十分钟就搞定了。这就是笔记的杠杆价值。
5. 第一周常见的坑与排查经验实录
5.1 环境配好却没配好：本地跑通，别人跑不通
“在我电脑上是好的”这句话，是程序员之间最著名的谎言。第一周最容易出现的情况是：你千辛万苦把环境跑通了，但同样的步骤别人走不通，或者你换一台电脑就废了。
原因通常是环境变量写在终端会话里、包是全局安装的、依赖版本没有锁定。所以第一周一定要做一次“从零到一”的验证：把笔记里的操作步骤重新在干净的终端里跑一遍，看能不能复现。能够复现，你的环境才算真正的“配置完成”，而不是“碰巧能跑”。
5.2 面对大量陌生代码时的心态崩盘
第三天傍晚，我看着屏幕上跳来跳去的调用栈，内心一度接近崩溃：这个项目怎么这么大？我怎么连一个方法都看不懂？
后来我想明白一个道理：看不懂是正常的，因为代码是别人几个月甚至几年的经验积累，你看懂才奇怪。你需要的不是“全部看懂”，而是“局部看懂，够用就行”。
我把心态调整为“先接受自己的看不懂”，然后给自己设定了小目标：每天只要搞懂一条链路就收工。第三天弄懂订单列表接口，第四天弄懂详情页接口，第五天能改一个字段，够了。降低目标之后，焦虑感立刻消退了。
5.3 提问的姿势：把“怎么搞”换成“我卡在哪儿”
第一周提问在所难免，但提问方式直接影响你得到的帮助质量。最差的问题是：“这个功能怎么实现？”——这不是在提问，是在要求别人做白工。
比较好的问题是：
- “我在调用 XX 接口时出现 401，我已经确认 token 能拿到，debug 进到拦截器里发现请求头是空的，下一步该查什么？”
- “订单详情页的 A 字段数据来源我找到了，是订单服务返回的，但我没找到库存服务是在哪里被调用的，能否提示一下入口类？”
这两种问法的差别是：前者已经做了排查、暴露了自己卡住的精确位置，导师三句话就能帮你定位；后者低效且容易让人不耐烦。第一周你要建立的不仅是技术能力，还有让团队愿意帮你的沟通能力。
6. 我的第一周复盘示例：内容与节奏长什么样
6.1 第一至第三天：环境、地图、链路
我的第一天上午用来办账号权限和画系统地图，下午安装工具链。晚上笔记里记的问题包括“网关地址在哪配的”“日志平台怎么搜关键字”。
第二天是环境攻坚，Maven 依赖下载慢、数据库版本不兼容，两件事挤满了白天。晚上我补跑了 Redis 排查笔记，顺手把启动命令整理成了脚本。
第三天开始读链路，从“查询用户信息接口”入手。白天跟了一遍 Controller → Service → Mapper → MySQL 全流程，晚上在笔记里画了一条竖线图，标注每一层的作用。那天的关键词是：网关、拦截器、用户上下文。
6.2 第四至第五天：接需求、提代码、周报
第四天上午看需求文档，下午动手改详情页字段。第一次在真实项目里用调试器定位到目标类，成就感还是有的。但提交之前被导师逮住三个问题：没跑格式化、没加注释、没更新接口文档。那一刻我意识到，写代码只是完成了一半。
第五天上午把代码补完，下午花一个小时整理周报结构。周报里我没有写“熟悉了某某框架”，而是写了三件能验证的事：跑通项目并整理了环境搭建笔记、梳理了订单详情完整链路、完成详情页字段展示需求。能验证，才算真的会了。
6.3 周末复盘：给自己定三条改进
周六早上我做了 KPT 复盘，T 列写了三条：每天上午开始 coding 之前，先花 15 分钟读一条链路代码再动手；提问前必须自带排查步骤；提交代码前必须自测完三条用例再提 Review。这三条成为我第二周的行动纲领。现在回头看，第一周真正的收获不是我学会了多少工具，而是我知道了自己该怎么学——后者才是在任何团队都能活下来的能力。
最后再分享一点个人体会。很多人以为入职第一周是“被考察”的时间，其实它更是你积累信任的起点。导师和同事对你的第一印象，取决于你提问的质量和交付的可靠性，而不是你“看起来多努力”。第一周结束，我没有给自己打高分，因为踩坑无数；但我最庆幸的是养成了每天写笔记的习惯，它让每一天的混乱都变成了可追溯的资产。如果你也正在经历自己的第一个星期，我建议你今晚就打开笔记，写下今天卡住你的那个问题，然后按上面的方法继续走下去。一个月后你会感谢这份记录。
