分类：聊复尔耳

推荐个 VPS 呗？这个问题经常听到，现在统一推荐一下。其实这个问题很宽泛，所以每次都需要先反问：你的用途是什么？然后在脑中过滤一遍，再继续问：预算多少？对位置有要求吗？需要什么配置？像挤牙膏似的一点点问，最终也很难得到答案。一家厂商的 VPS 怎么样，本质上都得自己买来实际用了才知道。光看一次跑分并不能下结论，因为无法知道晚高峰会不会丢包、工单有没有人回、故障以后怎么处理。踩坑了可能只能认栽，因为不是所有厂商的退款协议都比较友好。这些年用过不少大大小小的 VPS 和物理机，

你怎么给你的电脑安装软件的？是不是缺什么装什么，图形软件去官网下载，命令行工具用 Homebrew，Node.js 交给 nvm，Python 再装一个 pyenv。可能刚装完都挺好的，过上一年，~/.zshrc 里就会长出好几段初始化脚本。此时再问一句「现在运行的 node 到底从哪里来」，往往要先查半天 PATH。这种环境平时看不出问题。一旦同时维护新旧项目，事情马上多起来：一个项目还在 Node.js 20，另一个已经用了 Node.js 24；Python 版本不同，

上一篇《博客重构》里，我把目标写得很明确：完成基础设施，把精力转回内容。博客确实能用了，修改却没有停。搜索框里的状态、手机上的目录、切换页面时的代码高亮，每个地方单看都不大，连起来却足够再折腾一轮。这也不完全是闲不下来。有些问题只有放进真正的阅读过程才会出现：输入拼音时要不要立刻搜索，点完目录后面板要不要收起，页面开始切换了，代码高亮却还没准备好。组件单独看都能用，放在同一页里，仍然有不少地方需要磨合。这一轮基本没有改变博客的用途，更多是在整理前一次重构留下的细节。先列一下范

「你们现在用哪个模型？」这个问题我不太敢直接回答了。因为答案听起来像在敷衍：有的活给便宜模型，有的活给推理能力更强的模型，代码审查还要按风险升级，需求文档也有自己的分工。听的人多半觉得这是折腾，但真正跑过一段时间的人知道，这不是收藏模型，而是在控制账单和返工。团队刚把 AI 引入研发流程时，最容易走向两个极端：「哪个最强用哪个」，或者「哪个便宜用哪个」。前者会撞上账单，后者会撞上返工。更麻烦的是，模型价格不能只看输入单价：输出 token、上下文重复发送、缓存命中、工具调用、

一个产品怎样才算「打磨好了」？这个问题听起来像是在问圆角该用 8px 还是 12px，动画该持续 200ms 还是 300ms。可真正使用一个产品时，让人放弃的通常不是圆角不够圆，而是另一批更朴素的问题：不知道下一步该点哪里，表单填错后内容全部消失，弱网下按钮毫无反应，服务出了故障却没人说话，想导出自己的数据还得给客服写小作文。精致的视觉当然有价值，但它只是产品质量露在水面上的一小部分。水面下面还有需求边界、交互反馈、性能、可靠性、可访问性、技术债和发布机制。只抛光水面，产品

写代码的人，十有八九都干过一件事：把 PR 往群里一丢，然后祈祷「这次能一次过」。但代码审查 (Code Review) 从来不是走个过场。它是一套让代码库整体健康随时间改善的机制，Google 用它来维护代码和产品的质量。说到底，代码审查就是除作者之外的其他人，来检查这段代码的过程。为什么需要代码审查？先把它的价值说清楚，不然谁都懒得去做：尽早发现问题：在合并前抓住 Bug 和设计缺陷，此时修改成本最低知识共享：让至少另一个人熟悉这段代码，消除「巴士因子」提升代码质量：当人