1. 项目拷打 问的非常细 , 聊了30min2. GRPO 里的 reward 一般怎么设计，怎么避免模型学歪GRPO 的 reward 设计关键不是“打分越多维越好”，而是要保证相对排序真的有意义。常见做法是把 reward 拆成几部分，比如正确性、格式遵循、长度惩罚、拒答合理性、安全性这些，再做加权组合。对于推理任务，最核心的一般还是结果正确性和过程可验证性；对于开放式生成，还得控制风格漂移和模板化输出。真正难的是 reward hacking。模型很容易学会一些表面上拿高分、实际上没解决问题的套路，比如故意写很长、固定套模板、强行迎合裁判模型。所以 reward 设计通常不能只靠单一 ...

鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐

给时间时间 终会梦想成真的🥺那就努力努力再努力🤲

第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...