恰逢中秋十一假期，想到自己的个人博客已经很久没有做前端优化了，趁着这段时间决定借助AI Coding的力量，把博客的前端样式整体优化一下，调整到自己预期内的效果。不得不说现在即便是很廉价的模型，最终都能够达成这个目标，因此打算写这篇博客，记录一下自己优化的历程。
先说结果，新的博客前端，主要优化了下面一些事情：
具体执行时，还是踩了一些坑，最终也都得到解决。
笔者的这台老土机器，超频折腾从第一次上手到后来靠降压加Process Lasso的优化，最终发现只能给CPU上到4.5GHz比较稳定，再上去散热就扛不住了，烤鸡直接到90度。
最近两天索性把主机拆了开来排查，另买了一套帝王引擎重新组装了风扇水冷，最终终于解决了散热问题，把老土机器的性能拉满。特此写一篇文章，分享一些经验。
在先前治理后端稳定性的一些实战经验这篇文章里，笔者聊过稳定性治理的大致路径，先定指标，再保证可监控可观测，之后才是解决具体的技术问题。今天这篇文章就聚焦在可观测跟止损这两个环节，简单聊一下端到端的告警应该怎么梳理，以及严重告警的处理预案应该怎么做。这两块做扎实了，稳定性保障才算是有底子的，说到底目的还是稳定性本身，而不是把监控大盘做得多好看。
在SRE和稳定性工程领域，告警诊断Agent大概是当下AI落地最热门的场景之一了。对于告警应急场景，有一个迅速可靠的Agent做根因分析，通过透出问题链路关键的信息点，可以省掉很多前期的排查精力，帮助线上问题更迅速被解决。
从实现难度上看，写一个能跑的告警诊断Agent或者Skill，门槛其实不高。接几个Tool（查日志、查监控、查变更记录），写一段System Prompt描述诊断流程，大模型就能按照套路给出一个看似合理的分析结论。但如果要把它做到真正好用、能让大家都信赖程度，那难度就完全不一样了。
所以今天这篇文章就聊一下，如何用AI-Native的方式去研发一个高质量的告警诊断Agent。
在非常久远的文章中，我们提到python中实现并行执行程序的方式主要是通过multiprocessing实现的，而并非多线程（Threading）。机理层面，大致是会开一个新的子进程独立执行，主进程维护一个Sentinel（fd），默认通过pickle跟pipe方式和子进程通信。
而现在，python也到了3.14版本，除了multiprocessing与Threading之外，对于多解释器的支持也比较完善。多解释器的机理可以参考concurrent.interpreters官方文档，简单来讲就是这类并发不像多线程受GIL的约束，一个进程里执行多套解释器，每个解释器有自己的GIL，有点类似于Golang的机制。以下是一些典型用法：
近两天最火爆的事情莫过于《置身钉内》了，一篇离职复盘写了7万多字，熟稔的笔锋之间也夹杂了很多深度的思考，堪比互联网行业里头的《活着》。
笔者也有幸拜读了全篇文章，从作者的文风可以稍微推断其人物画像，某些特征也和笔者刚毕业那会儿比较相似，稍有一些学生思维，但不失理性的思考。不仅如此，作为同行业的工作者，同时也是一名坚持手写个人博客的作者，笔者对这篇文章里想要真实表达的情绪跟内容，也是比较有感触的。所以今天这篇文章，也简单写一下自己的感想。
AI Native是大势所趋，AI Coding的技能必不可少。鉴于此，笔者决定新开一个AI Native系列，记录自己后续在All-In-AI路程上的点滴，分享自己通过AI提升日常工作跟研发效率的思考和经验。
先前的文章也讨论到，因为工作的原因，笔者已经开始在做ToB稳定性治理的事情，所以近期也一直在通过Vibe Coding的方式，设计相关平台能力要做些什么，产品形式上需要如何呈现。从效果上看，AI写前端原型的能力还是比较OK的，能够很快速满足笔者的工作需要。今天这篇文章，就简单聊一下这个过程中的经验。
笔者用的工具是Qoder，通过Quest模式去快速搭建前端原型，整一个过程是这样的：