35岁光谷老码农的自救指南：我是如何用AI和“运营”搞定代码规范的？

上周五晚上10点半，武汉光谷软件园E3栋的空调已经停了。我揉了揉发酸的脖子，看着屏幕上00后新同事提交的PR（Pull Request），血压瞬间飙到了180。变量名全是a、b、c，嵌套了八层的if-else，连个注释都没有，简直是一座散发着恶臭的“屎山”。

我今年35了，每个月房贷3500，老婆天天念叨着要换光谷二小的学区房，我哪有时间天天给他擦屁股？当时真的很焦虑，感觉这代码质量再这么烂下去，我离被优化就不远了。

说实话，推行代码规范这事儿，在团队里简直是吃力不讨好。上个月初，我雄心勃勃地搞了个代码规范分享会，PPT做了五十多页，从命名规范讲到设计模式。结果呢？台下的小年轻们表面点头，回头提交的代码依然我行我素。有个哥们甚至私下跟人说：“老李就是喜欢搞形式主义，代码能跑不就行了？”

听到这话，我差点没忍住把键盘砸他脸上。35岁，还在一线写代码，体力拼不过年轻人，如果连代码质量都把控不住，我的核心竞争力在哪？那几天我整宿整宿睡不着，头发掉得更厉害了，甚至跟老婆商量，要不回老家找个国企躺平算了，差点想放弃。

但房贷不答应啊！冷静下来后，我意识到，靠人盯人是防不住“屎山”的，必须上工具。新手友好地给大家科普一下，我首先搞了一套基础的自动化防线。在工程里引入了ESLint和Prettier，配合Husky和lint-staged。这套组合拳的意思就是，前端在git commit的时候，自动检查代码格式和规范，不达标直接拦截，连本地都提交不上去。后端Java那边，我配了SonarQube和Checkstyle。这套纯静态检查的工具链搭好后，确实挡住了一部分低级错误。

但是，静态工具是死的，它看不懂业务逻辑，也抓不出那些“能跑但极其反人类”的烂代码。这时候，我想到了最近爆火的大模型。作为老程序员，不能固步自封啊。我开始研究怎么用AI来做Code Review。我选了Anthropic家的Claude，因为它的长文本理解能力确实强，而且代码逻辑推理能力很顶。

但是，直接让大模型看代码，它往往会给你一堆“正确的废话”，比如“代码写得不错，建议增加注释”。这不行，我得让它精准地按照我们的规范来。于是，我引入了Function Calling（函数调用）技术。这玩意儿简直是神器！我定义了几个自定义的函数，比如check_variable_naming（检查变量命名）、check_cyclomatic_complexity（检查圈复杂度）。当大模型分析代码时，它会通过Function Calling主动调用这些函数，把具体的代码片段传进去，然后返回结构化的违规数据。这样一来，AI就不再是泛泛而谈，而是变成了一个严格执行我们规范的“铁面判官”。

工具是有了，但怎么让大家心甘情愿地用？这就不得不提到运营手段了。技术人往往鄙视运营，觉得那是忽悠人的。但我发现，推行规范本质上就是一场内部运营。我搞了个“代码质量红黑榜”，每周五下午在部门群里发周报。这个周报是综合了SonarQube的静态扫描数据、lint-staged的拦截次数，以及我写的AI Review脚本的评分。

红榜前三名，我自掏腰包请喝瑞幸；黑榜后三名，不好意思，直接在周会上做代码“公开处刑”，并且跟当月的绩效考核挂钩。这招一出，效果立竿见影。那个私下吐槽我的00后，连续两周上了黑榜，被主管约谈后，现在提交的代码规规矩矩，连变量名都起得漂漂亮亮的。

看着现在清爽的Git提交记录，我长舒了一口气。回想这几个月的折腾，我最大的感悟是：35岁的程序员，真的不能只靠“写代码”来证明自己了。我们得学会“借力”。

以前我觉得，代码规范就是技术事，只要我技术牛，就能镇住场子。后来发现，技术只是基础，还得懂点人性，懂点运营。把冷冰冰的规则，变成大家能接受、甚至能带来正向反馈的机制，这才是高级的解法。

另外，拥抱AI绝对不是年轻人的专利。当我用Anthropic的API和Function Calling把AI接入到日常工程流的时候，那种成就感，比我自己写出一个牛逼的算法还要爽。AI不是来抢我们饭碗的，它是来帮我们这些老骨头减轻负担的。

现在，我每周五晚上终于能准时下班，去光谷步行街吃个烤虾，喝两瓶啤酒。代码规范工具解决方案的落地，不仅拯救了团队的代码质量，也拯救了我的发际线和家庭和睦。

未来，我打算把这套综合方案做成一个内部开源工具，分享给其他团队。35岁不是终点，而是用经验和工具去解决更复杂问题的起点。共勉！