入职第七天的晚上我在笔记软件里敲下四个字第一星期所学。那时候我刚跳到一个全新的技术团队语言、框架、业务流程几乎全是陌生的白天扎在环境配置和代码阅读里晚上回家把零零散散的东西记下来。一周过去把这些笔记整理成文才发现这七天的信息密度抵得上过去一个月的量。这篇内容写给两类人看一类是即将入职新公司、想提前知道第一周该怎么过的同学另一类是正处在自己“第一星期”里、项目没跑通、代码看不懂、需求接不住想看看别人怎么挣扎过来的人。先说个结论第一周最重要的不是写出多少功能而是把“环境跑通、链路走通、规范听懂、自记录习惯建立”这四件事做完。做到这四件事第二周开始接需求才有底气做不到后面几周都在还第一周的债。接下来我把这一周拆开来讲从目标设定、环境搭建、代码阅读、需求实操、复盘沉淀到踩坑排查全是我亲身实践过并且能直接复用的方法。1. 第一星期真正该学什么目标拆解与学习地图1.1 别一上来就啃代码先把“学习地图”画出来我见过太多新人入职第一天就打开项目仓库从 README 开始逐字看看到 controllers 目录就昏睡过去。这个方式不是不对而是没有顺序。第一周的核心矛盾是知识量巨大时间极短。你不可能在五天里理解整个系统但你可以用第一天把“地图”画出来。所谓地图就是四份清单系统清单这个项目对外提供哪些服务、面向哪些用户、解决什么问题。技术栈清单语言、框架、中间件、存储、消息队列、部署方式各是什么。模块清单仓库里有哪些子项目/模块模块之间怎么调用依赖方向是什么。团队清单代码谁负责、接口谁维护、需求找谁确认、风险找谁同步。这四份清单不用写得多详细每项一两行就行。但一定不要跳过因为它们是后续所有学习的坐标。我第一周第一天上午就在做这件事下午才打开代码编辑器。事实证明先有地图再看路效率远比漫无目的地乱翻高得多。1.2 第一周的能力目标不是“会写”而是“敢跑”很多新人给自己定的第一周目标是“学会框架”“写出完整功能”这其实是第二三周的事情。第一周的目标应该更低、更具体能在本地把项目跑起来能顺着一条业务请求从前端走到数据库能在别人指导下改一个小需求。这三个目标有一个共同点——它们都强调“跑通流程”而不是“理解原理”。为什么打个比方你搬进一个新城市第一周最重要的是知道超市在哪、地铁怎么坐、公司几点打卡而不是研究这座城市的城市规划史。代码也是一样第一周你要建立的是“我能在哪儿改代码、改了之后怎么验证、出了问题找谁问”的肌肉记忆。原理可以后面补但手感必须在第一周就有了。所以我给自己的量化指标是第一天跑通项目第二至第三天读完一条核心业务链路第四至第五天完成一个被明确指派的微小需求。五项全完成第一周就算及格。1.3 时间预算怎么分五天的黄金配比有人问五天时间到底怎么分我提供一个经过验证的配比不是死板地平均分配而是根据认知规律做了先后安排时间段核心任务预计占比第一天上午熟悉团队、账号权限、文档入口、画地图10%第一天下午至第二天全天环境搭建、项目跑通、依赖安装25%第三至第四天阅读核心链路代码、配合调试走通请求30%第四至第五天接手第一个小需求、完成开发与自测25%第五天下午整理笔记、写周报、向导师汇报10%这个配比的核心思想是环境问题必须集中攻克不要拖到后面。代码阅读和需求开发可以交叉进行因为读代码的最终目的就是为改代码做准备。第五天一定要留出时间做复盘不做的同学第一周等于白过一半。2. 环境搭建与技术栈摸底把“能跑”变成“跑通”2.1 环境坑位清单从语言版本到包管理第一周的麻烦一半出在环境。我自己的经验是不要信 README 上的“一键安装”要信自己手上跑出来的结果。新团队的环境大概率和你以前习惯的不一样语言版本、包管理器、镜像源、数据库账号、Redis 地址每一项都可能给你“惊喜”。这里给出一份通用的环境检查清单照着逐项核语言运行时版本比如 JDK 11 还是 17Node 16 还是 20Go 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 复盘模板总共三列KKeep 保留PProblem 问题TTry 尝试每日写笔记的方法有效环境排查耗时太长下次先统一确认版本再开工按请求链路读代码效率高提问不够精准提问前先写出自己的排查过程提交前自查四查很好用上午容易陷入杂事每天上午先安排两小时深度工作这个模板的好处是记录不是终点改进才是终点。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。这三条成为我第二周的行动纲领。现在回头看第一周真正的收获不是我学会了多少工具而是我知道了自己该怎么学——后者才是在任何团队都能活下来的能力。最后再分享一点个人体会。很多人以为入职第一周是“被考察”的时间其实它更是你积累信任的起点。导师和同事对你的第一印象取决于你提问的质量和交付的可靠性而不是你“看起来多努力”。第一周结束我没有给自己打高分因为踩坑无数但我最庆幸的是养成了每天写笔记的习惯它让每一天的混乱都变成了可追溯的资产。如果你也正在经历自己的第一个星期我建议你今晚就打开笔记写下今天卡住你的那个问题然后按上面的方法继续走下去。一个月后你会感谢这份记录。