zhaojiaqi

Articles and Tutorials

Josh 风格内容块：一篇 MDX 展示样例

使用 Callout、InfoCard、MediaPanel 三类组件，验证内容型个人站的组件化写作能力。

这篇文章不是为了讲复杂技术实现，而是展示内容站的“表达单元”可以如何组合。纯 Markdown 适合记录，但不总适合表达复杂观点。通过可复用组件，可以把关键信息、视觉节奏和阅读路径设计出来。正文仍然可以保持 Markdown 的自然写作体验，同时通过少量组件增强结构化表达与阅读引导。

本地构建、预提交检查与可复现环境，省下的是每天的等待。

值得投资的地方 - 更快的本地构建：增量编译、缓存，缩短"改一行等很久"； - 预提交检查：把 lint 与类型检查前移，少在 CI 里来回； - 可复现环境：一条命令拉起，减少"在我机器上没问题"。反馈越快，犯错的代价越小，迭代就越敢。

把意图、约束和验收标准讲清楚，AI 改代码才靠谱。

习惯 - 先给约束：哪些文件能改、哪些不能动、要保持的行为； - 给验收标准：构建通过、测试通过、无新增依赖； - 小步快跑：一次只让它做一类改动，便于审阅。 AI 不是替你思考，而是帮你更快执行已经想清楚的事。

用幂等键让重试安全，避免重复下单、重复扣款这类经典问题。

问题网络会超时，客户端会重试。如果写接口不是幂等的，重试就可能造成重复副作用。做法 - 客户端为每次写操作生成幂等键（如 UUID）； - 服务端首次处理后，将结果与键一起持久化； - 同键再次到达时，直接返回上次结果，而不重复执行。幂等是分布式系统里少数"加一点点成本，省很多麻烦"的设计。

在选型之前，延迟、正确性与运维成本往往比"技术新不新"更关键。

三个问题 1. 业务能接受多大延迟？小时级用批，秒级才需要流。 2. 正确性如何保证？流处理要直面乱序与重复，需要 watermark 与幂等写。 3. 谁来运维？流式管道的长期运维成本通常被低估。先回答这三个，再谈框架。

一段关于早起、散步与不带手机喝咖啡的生活笔记。

慢下来的一小时最近试着把早晨的第一个小时留给自己：不看消息，泡一杯咖啡，走到窗边看天色变化。变化很小，却让一整天都更稳。原来"高效"有时只是给自己一点不被打扰的余地。

异步协作不等于失去连接，几个低成本但有效的团队仪式。

为什么需要仪式远程工作把"顺便聊两句"的成本变高了。刻意设计的小仪式，能把零散的连接重新补回来。 - 每周一次的无议程闲聊，只聊近况； - 评审里先肯定再建议； - 上线后写一段"发生了什么"，不追责，只复盘。仪式不在多，而在稳定。坚持比完美更重要。

关于专注力作为稀缺技能，以及如何刻意训练它的几点摘录与思考。

核心观点作者把"深度工作"定义为在无干扰状态下进行的高认知强度活动，并认为它正变得越来越稀缺，因此越来越值钱。我的实践 - 给深度工作排"专属时段"，像开会一样保护它； - 把浅层事务集中处理，不让它们切碎整块时间； - 用"日终关机"仪式，给大脑一个明确的停止信号。