AI 时代下程序员的价值：一些可能会过时的个人思考
TL;DR：AI 让代码不再稀缺，但程序员的价值并没有消失，而是更多体现在判断力上：定义真正的问题、用正确的方式把事情做对，并确认结果在真实世界中有效运行。本文从 Zig 和 Godot 的 AI Ban、学徒制与缄默知识出发，聊聊为什么这些能力很难被完整写进文档或者完全放手给 AI。
前言
现在 AI 能力越来越强了，特别是在程序员这一行，搁几年前还只是一些简单项目的快速原型，我们还可以自我安慰一下，这种只能骗骗外行人。但是到今天，当你看到 Codex 或者 Claude Code 在极短时间内，娴熟的使用各种排查工具和定制化的 Skill 获取项目独有的上下文，非常有理有据的定位出你原本可能要花数天时间才能解决的问题。你很难不陷入一种虚无主义的情绪里面： 研究技术到底还有什么用，程序员这一行还能持续多久。上一次我感受到类似的情绪，还是我十年前在肝 PS4 游戏白金全成就的时候，突然发现有奖杯存档作弊器的存在，这个发现让我彻底治愈了 PS 白金强迫症。
这种情绪并不是单一现象，不管是身边还是社交媒体，基本上已经成为了一股潮流，抛开 AI 时代之前就已经出现的技术无用论的观点不谈，现在大家普遍持有相对悲观的观点。甚至有的大聪明在去年已经开始预测，程序员这个职业的生命周期只有半年。在这样的焦虑氛围下，想坚持在技术领域深耕，难度无疑加大了很多。这种难度其实更多体现在心理方面，可以类比股市，当股价暴跌，所有人都在说这家公司完蛋了的时候，作为小散，价值投资早已经抛在脑后了，别说加仓了，就是能不能拿得住，都成了问题。嗯，我不是在为我最近半个月晚上回家都在玩 FIFA 和 《007: first light》而辩解 😂。
所以我还是想在下面聊一聊我的个人感悟：在 AI 现在这么厉害的情况下，作为一个程序员，我会把我主要的学习精力放在哪里。写这些内容，只是想给自己打打气，想坚定一下自己的信念，而信念说到底是源于认知。还是继续延续股市的例子，扎根在某个技术领域持续学习，可能有点像定投某个板块的 ETF，也许会产生复利，当然也可能亏光裤衩。面对前途未卜的未来，能够坚持“定投”，信念是必不可少的。好在对我来说，这更像是一个业余爱好，存在一定的难度，很杀时间，又可以与人交流产生正反馈，并且对自己的职业生涯有一些积极的影响。最最关键的是除了 AI 的订阅费用以外，还没什么经济上的开销，比打 FIFA 听起来正面很多，还可以大胆对家属说：嘘，你打扰到我学习了。
最后我想说，我自己总结的认知也必然受限于我的目前个人情况，一个只是大量使用 AI 工具、没有深度学习 AI 领域底层原理的 systems 工程师。不过我觉得这个倒也没有什么，错误的认知也是认知，分享和讨论也是有价值的。而且所有认知如果没有限定条件，在时间线拉长了看，十之八九都是非常脆弱的。以火鸡问题为例，火鸡在感恩节到来之前都认为饲养员是爱自己的。哈，说到这，我开始有一点担心美股了，希望我是杞人忧天。
从 AI Ban 说起
其实我想写这篇博客，很大程度上，是我最近几个月连续读到两个知名的开源社区都开始禁止贡献者使用 AI 的新闻。最早是 Zig 社区，我是从这篇博客了解到的（Contributor Poker and Zig's AI Ban），接着是 Godot 社区也开始声明不再接受 AI 生成代码贡献了（Changes to our Contribution Policies）。我刚看到这些新闻的时候，其实是有点吃惊的，毕竟现在 AI 的能力已经是非常强的，主动 ban 掉 AI，有点没苦硬吃的感觉。
但是我仔细阅读了两篇博客的内容，我觉得这个 AI Ban 的决定一点也不突兀，甚至有点顺理成章。Zig 的博客写的非常有意思，Zig 社区面临的问题是，社区希望能够招募和培养志同道合的贡献者，这些贡献者都是从新人中产生的，而维护者的精力无法覆盖每个新人的 pr。所以 Zig 选择了 Ban 掉 AI，提升社区首次贡献的门槛，来确保维护者的精力可以帮助到对 Zig 真正有兴趣的新人。Godot 社区也是类似，博客里面有一句话特别触动人心，当耗费 reviewer 精力的反馈是被机器处理掉的，那 reviewer 其实很难把业余时间花在审核别人代码上面了。特别是考虑到 LLM 没办法从维护者的反馈中学习和受益，本来可以用来培养新的贡献者的精力，都会被浪费。
除此之外，这两个知名的开源社区还都反映出了一个经典现象：review 带宽通常是开源项目的最大瓶颈。不管有没有 AI 工具，代码从来不是这些项目的瓶颈。关于这个，我就有亲身体会，aya 社区那边我还有两个 PR 嗷嗷待哺等待维护者的进一步反馈，另外我还有一些很想做的功能，但是考虑到 review 带宽问题，我就没好意思开新的 PR。所以，我现在机智的转变了思路，力所能及的去帮忙 review 一些 PR，尽量缓解一下 review 带宽的问题，希望自己的 PR 能更快得到审核😉。
但在这个经典现象的背后，其实还隐藏着一个更有意思的问题，为什么这些知名的开源社区都更关注对人的培养，嘿嘿，AI 都秒天秒地了，为什么还把宝贵的精力浪费在素不相识的人身上，并且期待着新人成为独当一面的维护者呢。我觉得这个问题背后的答案，可以回应本文的主线：相比较 AI，程序员有价值的能力还有哪些。换成市面上的流行语，为啥不把这些维护者都统统蒸馏成 skill，然后让 AI 发光发热呢😈？
聊聊学徒制
我们先不回答上面这个主线问题，再回过头看看 Zig 博客里面的理论，贡献者扑克：Zig 社区对于新的贡献者，更关心如何投资他们人本身，期待新人在和社区的互动中成长为核心贡献者。这个培养机制有点似曾相识，说白了就是学徒制。当然，这里的学徒制不是牺牲人格尊严，旧社会那种糟粕（郭德纲过来挨打）。而是达者为师，友好氛围下，大家一起共同进步的那种理想情况。更具体一点，我觉得学徒制的核心是言传身教，跟在大佬后面学习，观察大佬是怎么做的，为什么这么做。在开源社区中，学徒制更多的体现在 code review 的过程中，新人提交代码尝试解决问题，维护者给出反馈，在来来回回的过程中，整个社区的技术偏好、维护风格都得到传承。
这里我不由得回忆起当初我刚毕业时候，自己的学徒经历。和开源社区不同，在商业化的公司里是雇佣制，人与人之间交互更紧密一些，学徒制的途径包括 code review，但又不局限于此。我印象比较深刻的，更多是紧急问题的处理，我记得我毕业之前就早早过去实习了，我第一天被简单科普了一下业务和技术架构，大概是实习第二天就开始写真实的业务需求了，现在想想这个节奏确实有点快。可能我当年 copy&paste 技巧也是在这种快节奏的环境下被快速锻炼出来的。当时的 code review 的技术细节我忘记了，我唯一印象深刻的是，100 行不到的代码，我被给了几十条 review 建议，甚至其中有位大哥为了方便我，直接给我贴了最终的代码。我当时其实没太多感觉，除了有点略微羞愧，大哥们要我改啥就改啥，后来我才意识到，这是新手期的福利，在高强度的工作环境下，这么细致的 code review 其实是非常宝贵的资源。
紧接着，就是第二周功能上线，当时和运维一起灰度发布了第一个线上节点，我上去测试了一把，发现结果不符合预期。我纯萌新一下子就不知道该咋办了，我就和运维说了这个情况，我记得运维一下子脸就拉下来了，跟我说功能有问题，那我们就走回滚流程😈，然后直接在工作群里宣布了这个结果。然后一分钟之后，商务直接跑到我工位，猛敲了一下我的桌子，然后开始大声输出情绪，表达的内容我还记忆犹新：你知道这个功能有多重要吗，回滚延期会耽误一周时间，大客户业务少跑一周，这是多少钱，我要写邮件投诉你老板，以及你老板的老板，然后我们一起死。
我当时还是临时工位，离我组里的同事都比较远，我记得我当时立刻小步快跑去大哥工位上求助，因为我当时真的完全不熟悉线上的系统情况，基本没有线上问题排查能力。当时大哥其实已经正在排查这个问题了，我蹲在后面，看大哥在全神贯注的操作，很快定位出来是运维在灰度节点把配置发错了，并不是代码有问题，所以发布可以继续。我侥幸躲开了商务的“追杀”，当然运维也没有跟我说任何安慰或者道歉的话，不过我当时心思压根不在这上面。我飞快的记录了大哥排查过程中的所有操作，追着问这里面排查的思路。因为我的想法很简单，下次这么刺激的场景，我希望我能当场定位问题，而不是这样陷入窘境。
现在回想起来，很难相信实习生刚来就做大客户的高优需求，当时商务和运维的反应也展示了一个相对高压的职场环境，还好我在的小组内部氛围还挺好的，不然我当初真的很难坚持下来。不过我还是蛮感谢当时的老板的，至少真的被锻炼到了。我当时也受益于此，光速入门了如何排查组里的线上问题。紧接着，没过两三年的时间，组里大哥们纷纷出走（当年就业环境还挺好的，机会很多），我被迫中断新手期，提前出师。随后有新人来，就变成了我在展示应该如何处理各种问题或者我去负责 review 他们的代码。记得有几个校招的新人也很喜欢盯着我的屏幕看我处理问题，时不时问我为什么这么做。虽然我有时候被看的亚历山大，但是我并不反感这样的行为，毕竟我当初也是在我组里几个大哥身边问这问那，大哥们也从来都没嫌弃过我。
我之所以列举自己身上的这个例子，就是我想回答一个问题，就是为什么不能只通过文档或者 AI 来进行新人的培养。学徒制的好处，更多的是身处在一个场景里面，然后可以从周围人身上学到处理事情的手段甚至是方法论。而且这种教学方式，比从书本中来的快得多，毕竟事教人一遍就会。当然，我还想再补充一点，就是学徒制和 PUA 是完全不一样的，虽然看起来都是同样做事和被反馈的机制，这两者其实非常好分辨。学徒制是遇到事了，你解决不了或者做的不够好，大佬是会出手给做教学示范，告诉你啥是好的标准。而 PUA 就是只提要求以及贬低，从来不提供有效的办法给你解决，更别提亲自下场打教学局了。就跟九头蛇让奔波儿灞去把唐僧师徒给抓来，奔波儿灞心里只会想：九头蛇你这么牛掰，你自己咋不去呢。
我们言归正传，回到本文主线，想必大家都有疑问，做和被反馈，这种言传身教的学徒制，除了学的更深刻了，还有什么呢。为什么不记录到文档里面，或者干脆都交给 AI 来，毕竟 AI 的记忆力是完爆碳基生物的。我个人认为这里的核心原因是，这类知识很难被完整的写到文档里，更多的都是问题或者场景来了，我们才能展示出相关的知识积累以及进一步体现出的判断力。
缄默知识
这类知识已经有人给它取了名字，缄默知识，更具体的定义是：我们所知道的，多于我们能言说（We know more than we can tell）。这个概念肯定和克苏鲁小说里面的神秘知识不能混为一谈（什么外神不能直视 blablabla），哈，我还挺爱看克苏鲁背景的网络小说😂。举个我们程序员的例子，你一看到某些代码的实现，你眉头一皱，感觉后面八成要埋坑，这种感觉你很难穷举落到 AGENTS.md 里面，但是你当看到的时候，你就能知道不该这么做。或者线上发布经验比较多的兄弟们，看到有的线上应急操作，心都会直接提起来，后背发凉，仿佛故障 review 会已经近在咫尺，那也是挨打多了，产生的本能。
当然了，我们都知道：如果 AI 训练的资料里面覆盖了这些场景，那么哪怕是缄默知识也不应该成为 AI 的瓶颈。毕竟各种困难的场景以及里面的应对、判断、经验和教训都被记录了下来，AI 是完全有能力学习到，然后遇到类似的场景可以做的更好。甚至 AI 学习的还不是干巴巴的结论，而是在实际场景中完整的分析过程。而且我也赞同，AI 从现有信息里面汲取和推理的能力是无比强悍的，如果信息源足够的优质，AI 甚至可以超乎我们的想象。不过这一切的前提都是取决于给 AI 的数据以及反馈的质量，我个人觉得至少有三种情况是很难被数据化的。
第一，在变化的世界里面，问题场景是无穷无尽的。有一个大家耳熟能详的理论：知识圆圈，懂得东西在圈里，未知的东西在圈外，懂的东西越多，圆圈越大，那么能接触到未知的东西也就更多。突然想到之前看到过一个网络小说《带着豆包穿越古代》，名字有点辣眼睛，没点进去看，但这也反映了类似的观点。现代人如果穿越回古代，知识信息量肯定是吊锤古人，古人八成会以为神仙下凡。但现代人也依然有着知识局限，如果一年前有未来人穿越到我面前，跟我说美光、闪迪、海力士还有三星这些关键词，我也会把他当成神仙顶礼膜拜。
第二，我觉得还有很多低频但是关键的场景也是很难被 AI 训练到的，这里面比较鲜明的例子是，每家公司内部积累的业务场景和判断，很多信息只存在几个业务骨干的心里。我这里甚至可以举一个反面例子，屎山代码。当然，这里肯定有人会反驳我，现在 AI 来处理屎山代码是得心应手。那我的回答是，说明代码还不够屎山。这里，正好我想聊一下屎山的定义，我觉得各种 code smell，凌乱的代码风格，随意堆砌的架构划分，固然是屎山代码不可或缺的一部分。但我觉得，屎山代码最可怕的地方在于损失掉的信息量或者说是历史业务背景，比如说代码里面有很多莫名其妙的操作，但是已经完全无法考察它的用意，你甚至不知道有没有客户在使用这些功能。这个时候 AI 可以做局部正确性很高的重构，但是 AI 没办法知道可能遥远的地方，有一小撮核心用户还在高度依赖这个错误的实现。然后 AI 改完一上线就炸，直接终结你在这家公司的职业生涯。当然有人可能会问，为什么不提前通知客户以及发布灰度观测。嗯，首先不要指望你的客户通情达理，通知了也没有用，出事了才会找你算账。其次，不要指望屎山代码横行的地方能有好的线上灰度观测手段和严谨的线上发布流程。
最后，我觉得还有一些可意会不可言传的信息，都不会记录到纸面上，自然 AI 也根本无法学习。举个例子，这个人说的话我只信一半，这个知识你其实某种程度可以跟 AI 表达清楚，比如我对他在某些领域的专业判断不信任，或者我觉得他有可能在某些涉及自己利益的事情会偷奸耍滑。你当然可以把这套规则判断依据整理出来，然后 AI 也能根据这个来进行自主分析。但是，这种政治不正确的东西，其实是不太方便跟 AI 说清楚的。更何况，人是非常复杂的，有可能今天你不信任他，但是过段时间他的某个举动可能又赢回了你的信任，这种快速变化的规则，都是我们潜意识里面快速生成的。
所以，我觉得缄默知识可以被部分显化，但是很难被完整、无损的抽象成一套脱离具体场景的固定规则。这种直觉或者说判断力，是很难被规则化的，或者说我们固化出了一套高效的规则，但是什么时候使用这套规则，还是依赖判断力，如果再尝试去归纳总结，那么有点像是测试用例的测试用例，陷入死循环了。这也是我很多时候使用 AI 比较沮丧的地方，每次我对它倾囊相授，下一次它仍然会辜负我的期望，我甚至觉得这不是 AI 长期记忆力有效性的问题，哪怕我写了很多 AGENTS.md 以及各种详细的要求，AI 总是能在我意想不到的地方给我致命一击。
什么是判断力
写到这里，我想表达的观点就很清晰了：AI 时代下，程序员真正的核心价值是判断力。那什么是判断力，这个有点玄学，我以前一直是这么去理解的：比方说某个领域的技术专家，他的能力可以大致拆分成两层，一层是对该领域知识的积累（这也是正在被 AI 快速取代的部分），另外一层是他的方法论，或者说是判断力。但方法论具体是啥，我心里有很多想表达的内容，但是总是觉得不够清晰。直到我今年早些时候看了 Jon Gjengset 的 YouTube 视频 2026.1 Q&A，这里面有人问 Jon，当他在面试的时候，会问哪些问题。Jon 回答说，他一般会问的问题就是：How do you convince yourself you are building the right thing in the right way, and that it runs correctly? 我觉得这个问题，里面暗含三个关键点，分别是如何相信你做的事情是正确的，如果确保以正确的方式去做这件事情，以及最后如何确保事情是按照正确的方式运行。而这些问题就很好的定义了什么是判断力，我接下来想说一说自己对于这些问题的理解。
Build the Right Thing
做正确的事情，可谓是重中之重，正所谓方向错了，再怎么努力也没有用。我个人觉得这里分为两层，第一层是先定义问题，至少是看问题是否真的存在，这也是很多新手很容易犯的错误，拿到任务，直接埋头开搞，从来不尝试去挑战一下，这个任务是否合理。这个其实也是第一性原理的体现，所谓第一性原理，就是透过现象看本质，不要被表象惯例给唬住，回归最基础的目标、事实和约束，去看看问题到底是什么。除此之外，很出名的 Five Whys 方法，通过追问来分析根因。我又回想起当年出故障了，在 review 的过程中，都是被逼着要求一层一层去追问故障的根因是什么。
第二层就是，这件事情有价值吗，我们到底要不要去做这件事情。这里的价值，如果是在商业组织里面，那就是业务价值，我做的事情，能否为我所在的组织带来收益。如果是在个人项目里面，其实就更唯心一些，能不能带来个人成长，甚至能不能让自己感到快乐，这些都可以成为很重要的价值。不过，在价值的背后，是对应的投入成本，我们根据事情的严肃程度，或多或少，总是要思考一下，代价是什么。这就是 ROI，投入产出比，我觉得把这一层想明白了，接下来这件事情要做到什么地步，要不要拼尽全力，或者什么时候可以战略性放弃，都会心里有数。
最后，Jon 的问题里面还有一个很关键的地方，how to convince yourself。那么即便有了理论，又怎么相信自己做的事情是对的呢？我思来想去，感觉这个真的很难，就拿我自己最亲身体会的一个例子，在我不短不长的职业生涯里面，我开发的功能中大概有一半左右，上线之后，是没有或很少被用户使用的。既然没用户使用，那也就是没有真正产生价值，那就很难算是做正确的事情。很多时候，在刚启动的阶段，我都会和前线聊得热火朝天，前线商务都是疯狂拍胸脯，这个功能上线了，大客户马上就切进来，不说飞黄腾达，至少让你今晚食堂敢多加个菜。又或者是自己主导的成本或者质量为目的的架构优化项目，当时觉得想法碉堡很有前景，结果风云突变，本来火热的项目，瞬间成为沙滩城堡，被潮水给轻易的冲走了。所以，在动态的世界，想做正确的事情，其实需要不断调整，并且最后大概率只能靠时间来确认是否真的是正确的。
Build the Thing Right
紧接着，第二个问题是以正确的方式去做事。有一个很经典的说法，不管黑猫白猫，抓到老鼠的才是好猫，换句话说，就是以成败论英雄。但是我们都知道唯结果论的弊端，结果拿到了，但是手段太糙了，留下的隐患可能会吞噬掉最后的结果，得不偿失。另外还有一个典型的说法，就是手里是锤子，满世界都是钉子。具体到程序员我自己的视角，不能说因为我喜欢 Rust，而 Rust 内存安全又是零成本抽象性能好，那干什么都得用 Rust。肯定还是得针对不同场景和条件，选择合适的框架和语言来做事情。
抛开这些基础理论不谈，我们还是要面对终极问题：就是怎么来衡量我们是否在以正确的方式做事。不过，这个问题比上一小节去判断什么才是正确的事情，在难度上要小了很多。毕竟我们可以尝试去找到 source of truth 来帮助我们判断。那什么才是 source of truth，我觉得是面对分歧，可以一锤定音的东西。比如说，我可以自信的说，我用 Safe Rust 写的代码能够被成功编译，就是内存安全的，又或者哪怕我使用了 Unsafe Rust 去写代码，只要我的安全不变量是正确定义并且被我人工正确的保障了，那么成功被编译依然可以保证内存安全。
我觉得使用 source of truth 的灵魂在于，我们需要知道它的边界在哪里，而对这个边界的清晰掌控，往往是领域专家和普通人的区别所在。举个例子，用 AI 常见的痛点，莫过于去一个陌生的技术领域，看着 AI 横冲直撞，搞了一大堆代码，然后跟你说完美搞定了。这个时候，我们只能看到 AI 信誓旦旦拍胸脯的样子，但是我们通常只能通过功能性的测试，来对结果进行验收，很难真正的通过一些细节去挑战 AI。如果 AI 这个时候胡说八道了，更准确的说是和我们的理解有出入，我们往往事后暴雷的时候才能知道。马斯克好像说过身处高位的人，想建立一个长期可靠的反馈机制是非常困难的事情。对于 AI 而言，我们就是老板的角色了，当老板想不被手底下人糊弄，其实如果没两把刷子的话，还是蛮难的。
再以我自身为例，我当初写 nginx 模块的时候，遇到某些通用功能的编写，我会到处翻代码，照葫芦画瓢 四处求证，不断对比。一般来说 nginx 项目里面代码质量肯定是最好的，也是最权威的，第三方模块类似实现一般可以拿来参考。现在写 aya 里面的功能也是，cilium/ebpf 类似的实现我肯定会去瞄一眼，但是 libbpf 和内核里面的实现对我来说才是 source of truth。又或者排查网络问题，应用层的日志固然很有用，但是可靠性肯定比不上根据抓包的分析，而考虑到不少网络配置可能会影响抓包，所以真正有疑问的时候，翻阅内核协议栈代码，以及编写最小复现程序可能才是真正的一锤定音。
我记得我有一次用 AI 看一个 Coredump 问题，AI 很快帮我定位了 root cause，我仔细阅读 AI 的分析，里面说使用 GDB 看到了调用栈，以及分析了对应源码行号，才确认了根因。我当时的第一反应是，当前环境里面二进制都没有调试信息，你是怎么精准找到源码行号的，是不是又想糊弄我。AI 说，它是根据偏移找到二进制的汇编代码，然后根据汇编代码来确定源码在哪里的。我心里说了一句，算你 nb，但为了维护人类的尊严，我还是让 AI 把偏移、查看汇编的命令、汇编内容以及源码都贴出来，心想我高低还是得检查一下，不能听风就是雨。
当然还有一次 AI 的负面例子，我印象特别深刻。还是在屎山项目里面排查一个问题，AI 根据日志和源码信誓旦旦的跟我说，是某个功能引入。我当时有点懵逼，明明我们老项目里面都没有实现这个功能，难道是我记错了。于是我反问 AI，为什么断定说是这个功能引入的。AI 直接给我展示了日志，我仔细一看，原来当年的日志写的就是错的，AI 看到日志就停止排查，直接开始兴奋的生成结论了。这其实就是 source of truth 的边界没有把握好，日志也不是百分百石锤。接下来就是大家熟悉的 AI 道歉经典环节，这个道歉不仅没有实质性意义，甚至情绪价值都不能提供，反而让人更生气，毕竟我们没办法惩罚 AI。所以，我觉得很多时候，代码 review 或者项目技术负债的清理，还是有意义的，毕竟有时候 AI 还是比较 naive，还以为人类写的代码质量都和它自己写的一样好，保不齐就踩一个雷。
Run It Right
事情有没有被正确的运行，其实从我个人的理解上，我认为并不是软件测试工程，软件测试我觉得更多是上一节的范畴，即有没有以一种正确的方式去做事情。而这个话题，我觉得更多的是在真实世界里面，问题有没有按照我们预期的那样被我们解决。有句老话说得好，是骡子是马，拉出来溜溜。
这里，我不禁又回想起我刚毕业时候第一个我主导的项目：给当前核心业务系统依赖的日志降本。我当时还图样，只是初步理解了，实时日志是按照流量计费的，所以我们只要削减实时日志数据量就可以了。当时的技术方案也很朴实无华，一方面去上下游团队沟通各种陈年老日志的必要性，开始清理屎山日志，另外一方面对日志在源头进行预处理，来精简日志流量（当然还得调整各种监控报警大盘的脚本）。总而言之，都是体力活，还有跨团队的各种摩擦，唯一的好处就是我突然变成最理解节点日志的人之一，为成为团队骨干打下了坚实的基础。
可当项目最终上线的时候，我老板问我到底省了多少钱，我突然一下子卡了壳，我记得当时冷汗瞬间流了下来。忙前忙后，天天加班搞了好久，结果忘了最重要的一环，到底成本优化的效果具体是什么样的。这个还不能直接去拉部门的对外消费账单，因为我们所有实时计算服务都是使用公司内部产品。而且整套实时日志系统使用了五六个云计算服务，什么 Flink，SLS，ODPS 的， 虽然都是按照流量计费的，但各自账单口径都不一样。再一排查更是让人崩溃，原来我们平时成本统计的情况，也是口口相传，很多地方都是一笔糊涂账。
没办法，当初没思考到位的，在最后都得补回来。我开始疯狂去相关团队对账单，好话说尽，软磨硬泡，才把账单数据给对齐。事后，我一直在想为什么这件事情，要费这么大的周折。后来我突然发现，隔壁组的一个哥们在做一个质量优化的项目，他在项目启动阶段，就和中台那边确认好了新的质量监控大盘需求。然后他的优化功能一上线，监控大盘就有了数据，具体优化的效果一目了然。讲道理，在 run it right 这件事情上面，质量优化项目可是比成本项目难度更大的，结果别人做的却有条不紊，而我却狼狈不堪。
我这才明白，可观测的监控质量大盘或者清晰的账单，其实都是手段，本质上，是我们要回答我们如何确信自己做的事情在真实世界里面被正确的运行。换成牛马语言，就是在搞 KPI 的时候，先想好 KPI 怎么被量化和呈现，并且达成共识，这才是拿结果的关键。有意思的是，Jon 提问中，这个 run it right 问题放在了最后，但是实际上，关于这个问题的思考，应该是紧随 build the right thing 之后，得排在 build the thing right 前面。
尾声
回答完这三个问题，我其实有点不太满意，总感觉有些地方没有表达到位，也许这就是我的缄默知识吧。希望过几年之后，我能够通过不断的实践和总结，从而可以给出更好的答案。当然也可能未来 AI 真的接管一切，大家都不用干活了🤔。
就目前而言，我一般是把信息搜索分析、问题排查、代码生成这些工作交给 AI，不过在严肃的项目里，我依然会人肉 review AI 生成的每行代码。但是定义问题、判断是否值得投入、做的对不对、以及如何判断在真实世界运行情况，我还是坚持得自己来。如果这些关键判断都外包给 AI，我肯定会逐渐失去判断 AI 是否做对的能力，也无法保证最终产出的质量，更别奢望滚雪球般的“复利”了。有趣的是，这三个问题，其实不仅仅只属于程序员判断力的定义，各行各业可能都是用着类似的方法论，我无聊时候刷“勇哥说餐饮”的视频，里面很多点评和建议其实也都是围绕这三个问题。
最后，我还想额外聊一个点，就是某个领域专家的判断力是否可以迁移到其他领域。毕竟，大家都说了，方法论值钱，道比术值钱，但是我个人感觉还是挺难的。很多时候，方法论是需要很多个细节来支持的，这种对事情有没有在以一种正确方式进行的判断力，其实都是摸爬滚打出来的。一个领域专家想切换到某个新的赛道，哪怕有着自己的方法论，也需要在泥地里面蹒跚好久。这大概也是现在工作难找的原因，AI 在不断削减新人摸爬滚打的机会，而招聘需求却是某个垂直领域的技术专家，先有鸡还是先有蛋的故事在不断被重复。别的不多说，祝愿大家深耕的赛道不仅有趣有深度，而且还越来越火红吧😂。
附录参考
一些让我有收获的信息源：