我接到的任务只有一个代号【TJXT】DAY1。没有需求文档没有会议纪要甚至连这个项目到底要做什么都只存在于某次聊天记录的一句话里。很多开发者应该都遇到过这种开局——领导丢过来一个缩写邮件里写着新项目启动你准备一下然后就没有然后了。这篇内容就是我整理的实际DAY1流程把从早到晚做的事完整复盘了一遍重点不是教你怎么写某个功能而是教你在信息几乎为零的情况下怎么把项目稳稳地推上正轨。适合刚独立带项目的新人、小团队里的技术负责人以及所有想把开发流程补完整的个人开发者。你能收获的不只是清单和步骤还有每一步背后的判断逻辑。1. 第一天上午别急着敲代码先把“TJXT到底要做什么”逼问清楚听到新项目开工很多人的第一反应是打开IDE、新建工程、把依赖装上。这个直觉本身没错但绝大多数返工恰恰就发生在这一步之后——你骨架搭得越起劲下午发现方向跑偏时白白扔掉的时间就越多。我第一天上午基本不碰键盘全部精力用来做一件事把TJXT从一个代号逼问成一个可以被理解和执行的需求。1.1 我只准备了一份问题清单用一上午把需求聊透了去开会之前我通常只带一份问题清单总共六类问题不求数量但每一个都必须当场拿到答案真正的使用方是谁这里说的不是付钱的部门而是每天打开系统完成工作的人。很多时候你以为在给A团队做实际上核心需求全由B团队提供项目一开始找错了对话对象后面几乎必然返工。计划上线时间是什么时候这个决定了技术栈可以多激进也决定了设计上要不要预留扩展位。三个月交付和一年交付架构策略完全不一样。核心使用路径是什么也就是用户进入系统后必须完成的那一到两个关键动作。其余需求都可以往后放但关键路径必须第一天就明确。数据从哪里来、到哪里去数据源、数据量级、数据质量直接决定架构里最重的部分长什么样。数据都说不清的项目连技术方案都谈不上。和现有系统的关系是什么是替代老系统、并行过渡还是从零做一个全新领域这个决定是接管数据还是对接接口实现方式天差地别。失败的标准是什么如果系统上线了但没人用算成功还是算失败这个问题听起来有点抬杠但业务方一旦认真回答你就能知道这个项目的真实分量。这六个问题逐条聊完一上午差不多就消耗掉了。别觉得慢这一天里最值得投资的就是这段时间。另外我特别提醒一句对方如果说这个你看着办你千万不要暗自高兴反而要追问到底。因为看着办通常意味着他也没想清楚而你后面做出的每一个决策都会在某个深夜被翻出来重新讨论。1.2 需求文档没写全用验收标准倒推功能边界会议室里容易吹牛业务方总是兴致勃勃地说以后可能还要加X功能这里先做个通用的后面会扩展。这句话几乎是需求蔓延的源头。我的对策是第一天就把验收标准列出来一版哪怕是粗糙的也能把功能边界暂时钉死避免后续无休止地增加工作量。具体操作是把要做什么翻译成做到什么样子才算完。比如业务方说要能查看统计报表我不会直接记下开发报表页面而是把它拆成可验证的判断句如果用户进入统计页那么10秒内必须展示出今日核心指标如果查询结果为空那么页面要给出空状态说明文案而不是白屏或者乱七八糟的表格如果报表链接失效那么用户应看到明确的错误提示而不是默认浏览器的404页。把这类句子整理成一张表给业务方过目他会立刻意识到自己说的需求到底意味着什么也会开始认真思考优先级。DAY1做不了特别精细的验收标准但至少要能回答首版做出来长什么样、哪些情况算异常。有了这版粗糙标准后续写设计文档会顺手非常多因为边界和预期已经在纸面上对齐过而不是靠每个人脑补。1.3 判断技术栈该不该在第一天确定我的原则是常规业务系统第一天可以定大方向但不急着锁死具体版本。为什么因为第一天的信息量太少团队又还没真正动过手此时锁死版本后一旦踩坑推翻重来的成本很高。比较稳妥的做法是分三个层级来处理决策对象DAY1是否敲死理由语言和主框架定范围不定版本按团队熟悉度圈定两三个候选写代码前一天再定细节版本数据库与部署环境必须敲死牵涉数据迁移和运维配置返工成本最高越早定越好第三方工具库一律后置用到对应功能的前一天再选型保证能选到当下最新稳定版本我见过太多团队第一天就围在一起争论用框架A还是框架B然后吵了整整一个星期业务需求纹丝不动这是典型的无效讨论。与其这样不如先按团队最熟的方案跑通一条链路等技术债真的出现再集中偿还——大多数项目的技术债根本轮不到偿还就已经迭代换代了这个话题根本不值得消耗第一天的热情。2. 环境搭建与最小链路从“空目录”到“能请求到数据”上午把需求边界和技术方向聊明白下午就要动手了。动手的第一件事不是写业务逻辑而是把环境收拾利索。这一步我踩过的坑比写过的功能还多所以现在养成了固定的套路基本不会因为环境问题浪费整个团队的联调时间。2.1 容器化开发环境专治“在我电脑上是好的”只要是两个人以上的团队我强烈建议第一天就上容器化这里说的不是只有生产环境容器化开发环境同样需要。最常见的翻车场景是A同事的电脑装的是某语言的新版本B同事还是旧版本联调的时候接口行为不一致排查半天发现是版本差异。这种损耗看起来很不起眼累积起来却非常吓人而且完全可以通过一份声明式的环境配置文件在DAY1就杜绝掉。以一套典型的Web工程举例后端服务、前端服务、数据库、缓存中间件至少需要配置四个容器。我的做法是维护两份编排文件一份用于日常开发把源码目录挂载进容器、开放调试端口、开启热更新另一份用于测试验收不挂载源码直接运行构建后的镜像。两套场景切换时只需要指定不同文件不需要改动配置内容。# docker-compose.dev.yml 的开发场景示意 services: backend: build: ./backend volumes: - ./backend:/app ports: - 8080:8080 environment: - DB_HOSTdb db: image: postgres:16 environment: - POSTGRES_DBtjxt ports: - 5432:5432有人觉得容器化有学习成本但DAY1不做的代价是第二周开始团队会花大量时间在为什么你那边跑不起来上。这笔账怎么算都不划算。如果你只是一个人维护玩具项目跳过这步完全没问题直接本机装环境最省事但只要有协作容器化就是性价比最高的第一笔投资。2.2 最小可行链路——先让一行数据从数据库走到浏览器环境准备好之后我会立刻做一次最小链路验证写一个最简单的接口从数据库里取一行数据返回给前端页面展示出来。这个动作看起来毫无含金量但它真正的价值是把项目里最长的那条串联路径提前引爆一次数据库连接配置是否真的正确后端服务能不能正常启动并读取配置容器网络中前端能否访问后端接口前后端联调时是否遇到跨域或网关问题本地代码修改后热更新是否生效。如果你等到写第一个真实业务功能时才验证这些那么一旦出错你根本分不清问题出在业务代码还是基础设施排错难度直接翻好几倍。而最小链路跑通之后后面每个功能开发都有了稳定的地基。我通常还会在这个最小示例里顺手把日志打印和请求ID带上请求ID特别关键因为前端发起一个请求后端处理过程中报错如果没有一个统一标识贯穿链路日志根本对应不上联调阶段会非常痛苦。2.3 第一天就定日志和配置规则后面省大事很多项目到后期日志一团糟核心原因就是没在第一天约定规则。日志这种东西一旦各写各的后面统一格式比杀掉重写还难。我一般只定三条硬性规则关键请求必须打印请求ID、处理耗时和一个业务结论字段禁止把整个响应体刷进日志否则日志文件几天就爆错误日志必须包含上下文至少要有堆栈、参数快照和服务名光给一个空异常根本没法定位敏感信息一律脱敏密码、令牌、身份证号这类内容绝对不允许出现在日志文件里这既是安全底线也是审计要求。配置管理有个类似的坑有人喜欢把数据库密码写在一个地方然后随手提交进仓库这个失误到后期清理历史记录时简直要命。DAY1就应该立下配置与代码分离的规矩开发、测试、生产各一套配置仓库里只放模板真正的密文走环境变量或专门的密钥管理服务注入。这一步做晚了后期光是洗历史提交就能折腾一整夜而且谁也不敢保证有没有人已经拿这套密码在奇怪的地方注册过。3. 工程化骨架让未来的自己少熬夜的DAY1投资下午的第二块内容是把工程化底子打好。这块属于典型的投入在第一天、收益在后面每一天的投资也是最容易被新手跳过的部分。我不会建议你一次性把所有工具都铺上来那只会让团队还没开始写功能就被工具规则淹没。以下四个动作是性价比最高的缺哪个后面都会多花几倍时间补。3.1 仓库初始化、分支模型和提交规范新建代码仓库没有争议有争议的是仓库里那些看不见的规则。我推荐一套最不容易出错的组合适合绝大多数中小型项目主分支设保护任何人不允许直接推代码必须走合并请求且至少一人评审通过。这条规则第一天就要在仓库端配置好因为项目初始阶段大家还没形成习惯一旦放开前几个星期后面再收紧会遇到强烈的抵触。功能分支从主分支拉出命名统一用类型/简述格式比如feat/report-page、fix/login-timeout。类型就那几种写不清类型的时间久了光看分支名完全不知道要干嘛。提交信息至少包含做了什么和为什么两部分。我见过特别多提交信息只写修改两个字一周之后连提交者自己都想不起来当时改了什么这种情况复制代码回滚都无从下手。第一天就把这些规则写进说明文档并配置到仓库端后续就靠机制约束而不是靠自觉。有一个小技巧是把分支名格式和提交信息模板做成命令别名写进开发机的配置里想违反规范都费劲心智负担会小很多。3.2 自动化检查与CI第一天接入好过第30天迁移有人觉得持续集成是团队规模大了之后才需要考虑的事但实际上越早期的项目越需要它因为代码量小、规则可以随便改发现不适用的检查项顺手就能调整。第一天就接入持续集成至少包含三项代码风格检查统一格式化标准消灭你改我格式、我改你逻辑这种毫无意义的冲突静态错误分析在人工审查之前先让工具扫描一遍把明显的隐患标记出来避免低级错误被带到测试环节最小冒烟测试不是全量单测而是对最小链路、核心登录、核心功能各写一个端到端用例保证主干永远可用。这三项接入自动化流水线之后每次合并请求都会自动跑一遍有红就修修好再合团队慢慢就会形成主干永远健康的惯性。配置阶段不要被吓到现在主流托管平台的持续集成配置大多有现成模板可以抄十分钟就能跑通。真正要警惕的是等代码多了再接入这个想法——历史代码全是风格违规和告警机器一跑全红你的选择只剩花几天清理旧债或者让红着变成默认状态而后者基本等于这套设施完全作废。3.3 项目目录结构与模块划分怎么才算“不返工”目录结构这类话题最容易引发无休止的争论但第一天又必须拿出一个可执行的版本。我的建议是按业务模块分而不是按技术类型分。举个例子如果系统按控制器、服务、工具类来分目录那么每接一个新需求代码都会横穿所有目录牵一发动全身。如果按用户模块、报表模块、通知模块来分大部分需求只落在某一两个模块内新增功能时心智负担小得多代码找起来也快。第一天不需要把目录设计得非常完美但有一条底线必须守住模块依赖方向是单向的从底层工具走向业务层不允许出现循环引用。另外公共代码抽到共享位置很正常但不要为了抽而抽我见过有人第一天就把公共工具类整理得跟一本百科全书似的翻到最后全是没被用过的废方法维护成本反而更高。这里有一个非常实用的检验方法把一份新需求描述拿过来对着目录结构口述一遍这个功能要改哪些地方。如果说出来只涉及一个模块那划分基本合格如果说出来要横跨四五个模块赶紧停下来重新想想模块边界。这个检验法不花什么成本每次划分完试一下准确率非常高。4. 收官动作任务拆解、风险登记和第二天入口DAY1最后两个小时我通常会刻意停止写代码。前面该搭的骨架都搭完了剩余时间更值得用来做三件事把需求切成可交付的块、把风险摆到桌面上、给第二天一个清晰的开工入口。很多人第一天结束时觉得好像啥都干了但不知道明天从哪开始根源就是缺了这三步。4.1 把首月需求拆成可验收的迭代需求聊完、技术栈定了、环境通了现在要把那一大坨需求切成一段段能执行的增量。习惯做法是先找出一周内能完成的第一个里程碑把它切成三到五个任务每个任务都有明确验收条件。比如第一个里程碑是用户能通过登录页进入系统任务可以切成搭建登录页面和表单校验逻辑实现后端认证接口和令牌颁发逻辑完成前端令牌存储与路由守卫补齐登录链路的自动化冒烟测试整理登录环节异常提示文案覆盖密码错误、账号锁定、网络超时三种情况。每个任务尽量控制在半天到一天的工作量拆完放进项目管理工具里排版成看板。我不建议第一天就把整个月的任务全部拆细因为需求随时会变拆得越细返工越痛。保持近期短任务、远期粗规划的粒度就够了让团队始终知道未来一周的主方向同时保留响应变化的弹性。4.2 风险清单我现在就知道哪些地方会延期这不是在贩卖焦虑而是我对自己的硬性要求DAY1结束前至少列出三个可能让项目延期的点。风险从来不会因为你不看它而消失早点列出来反而能早点想办法绕开。常见风险可以从三个方向去挖掘我把自己的登记表结构贴出来参考风险描述影响程度发生概率应对动作业务方对未来功能的描述太含混高中一周内约第二次需求澄清会先锁定核心路径新引入的数据组件团队不熟悉中中第一周安排一次技术预研跑通性能压测再上生产对接的老系统接口文档缺失高高提前联系负责人员申请接口说明或抓包样例不用等到风险真的爆了才痛心疾首把风险记下来并标注应对动作哪怕只是加了尽快确认四个字也都比一切都闷在脑子里强。怕的不是风险本身而是没有任何人看见风险。4.3 DAY1复盘今天合格的标准是什么最后半小时我会问自己四个问题逐一在笔记里写下答案是否已经知道这个项目为什么存在、给谁用、核心价值是什么如果答案模糊说明上午的需求没有聊透明天要继续约谈。是否已经跑通最小链路团队成员的开发环境是否一致如果有人今天还没把环境装好明天第一任务就是陪他把环境弄完不然他的代码只能靠猜。是否已经把首周任务拆出来并保证每个人都有明确且不重叠的认领这一步直接决定工作关系是否顺畅。是否已经把已知风险变成一张可跟随项目更新的清单哪怕只有三条也够了后面的工作是定期刷新它。这四问全部答是DAY1才算合格。如果哪条答否就别急着宣布开工大吉先把缺口补上。我自己不太认可那种我们第一天把仓库建好了所以进度很快的说法因为仓库建不建从来不是重点重点是整个团队对项目的理解是否一致、执行路径是否清晰可见、风险是否有人盯着。这个系列我会继续往下写DAY2的主角大概率是登录模块和第一个报表页面的完整落地。如果你也刚接手一个只有代号的新项目可以试着把我这套流程原样走一遍哪怕只能做其中一两步也会比直接埋头写第一行代码稳得多。第一个小时用来提问往往比一个星期的埋头编码更能改变项目的走向。