项目级代码能力，指的是在真实业务代码库里，把需求变成可上线、可维护代码的能力。它和刷算法题最大的区别在于：你写的代码要跟别人协作、要读旧代码、要在线上跑半年不出乱子。
核心就四点：
1. 能读懂现有代码
接到需求先别写，先翻代码。看之前类似功能怎么实现的，数据从哪来、落到哪去，接口命名有什么惯例。大部分 Bug 不是因为不会写，而是因为没看懂旧逻辑就动手。
2. 能写好局部代码
命名让人一眼看懂（userStatus 比 us 强），异常要处理（别光 try-catch 然后打印 e.printStackTrace()），日志要够用（出问题能定位，而不是满屏 “enter method”）。核心原则：半年后你自己来看，不骂娘。
3. 能放对代码位置
知道新功能该写在 Service 还是 Manager，该新建文件还是复用旧模块，不该为了凑设计模式硬抽象三层接口。保持代码库原有的风格和结构，比展示个人技术偏好更重要。
4. 能跑通全流程
本地能调通，单元测试能补就补，PR 描述写清楚“改了什么、为什么改、有没有风险”。上线后知道看监控、查日志，出问题能根据报错快速锁到代码行，而不是说“我本地是好的”。
一个简单自检标准：
如果你现在能独立接手一个中等复杂度的需求（比如“给订单列表加一个筛选项并导出 Excel”），从读代码、开发、自测、Code Review 到上线告警处理，全程不需要人兜底，那就是具备项目级代码能力了。
新人常见的Gap：
- 只写不读：上来就新建文件，结果旧系统里已经有现成工具类。
- 过度设计：一上来就考虑“如果以后有100种类型怎么办”，结果现在只有两种，代码反而难懂。
- 不留痕迹：不写注释、不打印关键日志、PR 只有标题没有描述，一个月后谁也记不清当时为什么这么改。
怎么提升：
- 多参与 Code Review，先看资深工程师怎么命名、怎么拆函数、怎么处理边界。
- 主动跟一次完整需求，从需求评审到上线后的 on-call，体验一次代码在线上的真实生命周期。
- 三个月回头看看自己写的代码，如果还能顺畅读懂，说明写得够干净；如果看不懂，下次就知道哪里该多写两行注释了。