去年还是自己装插件、自己登录，今年公司把 Coding Agent 统一换成公司账号，走网关。限流、审计、会话留痕都有了，用起来倒是省事，绩效季一来就别扭：网关日志里能看到你天天在敲，领导问这段时间干了啥，总不能甩一句「我补全点得多」。
同事聊过几轮，比较靠谱的说法是别看用了多少次 AI，看交付物。PR 合入数量、从开到合的周期、评审轮次和返工次数，这些本来就在仓库里，网关有没有都不影响。有人把同一类需求按走网关前后各看了几周：周期是不是缩短了，是不是因为 PR 变大了反而卡在评审。行业里常提的 DORA 指标（部署频率、变更前置时间、失败率和恢复时间）可以用来统一团队的说法；落到个人，更管用的还是 PR 吞吐和周期，别硬套组织级数字。采纳次数、建议行数只能说明工具在被用，说明不了交付质量。
AI 辅助占比这块最容易吵。网关如果有采纳率、会话次数，那是工具使用数据，不是产出。有人会在 commit 或 PR 描述里标一下哪些改动是辅助生成再改过的，方便复盘，不是为了刷 AI 占比。占比高本身也不加分：生成一堆没人看的 diff，评审负担全压给别人，谈话里反而被动。反过来，完全不写辅助痕迹，复盘时又说不清哪些坑是模型带出来的。
跟绩效沟通时，带合入的 PR 列表和大致周期，再带上实际扛的需求或线上问题，别只报行数；顺带说清楚你怎么用网关：写测试骨架、对照方案，还是直接甩大段生成代码。把辅助具体说成做了什么，比一句效率提升了更好往下聊。领导要是盯着面板上的调用次数，可以把话题引到交付和返工上：调用多不代表合入多，合入多也不代表线上稳。
统一账号之后，以前自己摸索出来的那些用法，也不好再当独门绝活说了。大家配额差不多，差别更多在会不会拆问题、会不会把生成的代码整理干净再提审。网关限流的时候有人抱怨点不动，这时候更别拿调用量证明自己勤快，队列堵着大家一样慢，不如把卡点记下来，看是模型侧还是评审侧。
公司把流量统一收到网关，本来就是为了合规和成本，没必要想着绕开审计。绩效谈话时拿得出能核对的交付，说得清自己是怎么用的，基本就够了。你们公司上了网关之后是怎么评的？