月度归档：2025年05月

实在没辙了！只好祭出AI，给自己撸了个图片占位生成器

发表回复

对于前端开发者而言，图片占位生成器是一个不可或缺的工具。

在实际开发中，我们经常会碰到这样的场景：产品展示页面的布局已经完成，各个模块都已就位，唯独缺少产品图片。而此时设计团队反馈：「图片素材还在制作中，预计下周交付。」

另一种常见情况是，在调试图片列表的响应式布局时，需要各种尺寸的测试图片。传统做法是通过搜索引擎寻找合适的图片，然后逐一下载、裁剪、调整尺寸。这个过程往往耗时良久，严重影响开发效率。

除了效率问题，版权风险也不容忽视。在项目中使用网络图片时，我们必须考虑：这些图片是否有版权限制？是否适合在商业项目中使用？这些问题如果处理不当，可能会给项目带来法律风险。

还有一些场景，如我们动态生成图片，在图片上显示提示的内容这种相对小众的场景。

本周刚好有一个需求是给飞书捷径做一个小功能用到了图片占位生成。梳理完需求，大概如下：

  1. 能指定宽和高
  2. 能自定义文字
  3. 能指定文本颜色和背景色
  4. 能指定图片格式输出，支持 PNG
  5. 能指定文本大小
  6. 能在飞书中使用

首先我们看一下有哪些在线的图片占位生成器可用的。

我们先让最新的 Claude-4-Opus 大模型给出 10 个地址，如下图：

1. **Placeholder.com【不可用】**
- **URL**: https://via.placeholder.com/
- **使用方法**: `https://via.placeholder.com/300x200`
- **特点**: 简单易用，支持自定义颜色和文字

2. **Lorem Picsum【能用，随机真实图片】**
- **URL**: https://picsum.photos/
- **使用方法**: `https://picsum.photos/200/300`
- **特点**: 提供随机的高质量真实图片

3. **Placehold.it【跳到 Placeholder.com 也不可用了】**
- **URL**: https://placehold.it/
- **使用方法**: `https://placehold.it/350x150`
- **特点**: 经典的占位图服务，支持多种格式

4. **PlaceIMG【不可用】**
- **URL**: https://placeimg.com/
- **使用方法**: `https://placeimg.com/640/480/any`
- **特点**: 可选择不同类别（动物、建筑、自然等）

5. **Dummy Image【可用，不支持中文】**
- **URL**: https://dummyimage.com/
- **使用方法**: `https://dummyimage.com/600x400/000/fff`
- **特点**: 高度可定制，支持自定义背景色和文字颜色

6. **LoremFlickr【可用，不支持自定义内容】**
- **URL**: https://loremflickr.com/
- **使用方法**: `https://loremflickr.com/320/240`
- **特点**: 基于Flickr的真实图片，支持关键词搜索

7. **Placekitten【不可用】**
- **URL**: https://placekitten.com/
- **使用方法**: `https://placekitten.com/200/300`
- **特点**: 提供可爱的猫咪图片作为占位图

8. **Unsplash Source【不可用】**
- **URL**: https://source.unsplash.com/
- **使用方法**: `https://source.unsplash.com/1600x900/?nature`
- **特点**: 使用Unsplash的高质量图片库

9. **PlaceBear【可用，不支持自定义内容】**
- **URL**: https://placebear.com/
- **使用方法**: `https://placebear.com/200/300`
- **特点**: 提供熊的图片作为占位图

10. **FakeIMG.pl【可用，不支持中文】**
- **URL**: https://fakeimg.pl/
- **使用方法**: `https://fakeimg.pl/300x200/ff0000/ffffff?text=Hello`
- **特点**: 支持自定义文字、字体和颜色

以上 10 个站点看下来，就 1 和 5 相对符合需求，但都不支持中文。

AI 不行，搜索来凑，一顿 Goole 下来，又找到以下的几个：

1.placehold.co【可用，不支持中文】

示例：https://placehold.co/600×400?text=Hello+World

2.fakeimg.pl

示例：https://fakeimg.pl/300/?text=哈哈&font=noto

fakeimg.pl 在功能上需求都能满足，不管是大小、字体、中文，但是它在飞书中作为附件使用的时候竟然出错了。使用 dummyimage 却没有这个问题。 试了几次发现怎么都绕不过去，只能另想他法。

3.tool.lu

示例：https://iph.href.lu/600×400?text=哈哈哈

tool.lu 的图片占位功能能完全满足需求，但是和 2 一样，在飞书下会报错。

4.devtool.tech

界面最好的一个生成站点，但是格式是 SVG 的

以上只是基本可用的，还不排除那些功能不满足，失效了的，各种，折腾了两个小时，能满足需求的飞书用不了，飞书能用的不支持中文，死循环了。

只能自己撸了。

祭出 AI，花了两小时（代码只花了半小时，还包括框架搭建），本地运行没有问题，把代码部署到线上，能正常显示，但是飞书用不了，一样的报错：

execute error，捷径执行出错：
Error: execute原始执行结果：
捷径返回错误码： FieldCode.Success 
 转换结果：transform cell value fail

这回是自己写的代码，终于可以定位并解决问题了。对比能用的地址和不能用的地址，从头文件中发现了两个字段的差别，一个是跨域：Access-Control-Allow-Origin，一个是返回长度：Content-Length

最终试验发现是：Content-Length

可能飞书在获取图片并上传成附件的时候做了判断或者校验（就是个 BUG）。

这个功能已经作为免费的服务放到了开发哥网站（还记得之前 Vibe Coding 写的那个网站不）：

https://www.kaifage.com/tools/placeholder

以上。

多说一句，即梦 3.0 生图中的汉字越来越精细了。

1:29:300！这个「魔鬼定律」正在预告你的下一次线上故障

发表回复

无论是深夜被夺命连环 call，还是眼睁睁看着用户反馈铺天盖地而来，那种感觉，相信大家或多或少都体验过。

当我们不幸经历了一次「刻骨铭心」的线上故障。痛定思痛，除了常规的复盘，我们也许要从一个更系统、更底层的视角，和团队的同学一起探讨：故障，究竟为何而来？我们又该如何防微杜渐？

今天，我们聊下安全管理领域的「老法师」——海恩法则（Heinrich’s Law），以及它的一众「智慧亲友团」。

海恩法则：事故背后的「1:29:300」金字塔

海恩法则的来历

海恩法则由美国工业安全先驱赫伯特·威廉·海因里希（Herbert William Heinrich） 在上世纪30年代提出。他在为保险公司工作时，通过分析数千份工伤事故报告，总结出了这个惊人的规律。最初应用于工业安全领域，但其揭示的事故发生规律具有普遍性，早已跨界影响到航空、医疗、乃至我们软件工程等多个领域。

海恩法则指出：

在一件重大的事故背后，平均有 29 次轻微事故，以及 300 个无伤害的隐患或未遂事件。

这个法则通常以 1:29:300 的金字塔比例来形象展示。

海恩法则的核心思想

  1. 事故是可以预防的：严重事故并非天降横祸，而是此前一系列小问题和风险累积、演变的结果。如果我们能有效管理「29」和「300」，就能大概率避免「1」的发生。
  2. 重视「未遂先兆」：那 300 个「隐患」和 29 个「轻微事故」是重大事故的「报警器」。忽视它们，就等于给灾难开了绿灯。很多时候，我们只关注已经发生的「1」，却对冰山下的「29」和「300」视而不见。
  3. 安全管理需系统化：事故的发生往往与管理体系的漏洞、流程的缺陷、安全文化的缺失等系统性问题相关。预防事故需要从整个系统的角度出发，进行持续改进。

海恩法则的应用实例

  • 工业生产：工厂通过定期的安全检查、员工安全行为规范、隐患上报奖励等机制，主动排查和消除那「300 个隐患」，处理「29 起轻微事故」，从而避免重大生产安全事故。
  • 航空安全：每一次飞行前的详细检查、飞行员的严格培训、对飞行过程中任何微小异常的记录与分析，都是海恩法则的体现。一个螺丝的松动（隐患）如果不被发现，可能导致部件故障（轻微事故），极端情况下甚至引发空难（重大事故）。
  • 医疗安全：医院对用药错误、手术流程中的小差错等「未遂事件」进行记录和分析，改进流程，以防止严重的医疗事故。

对于线上故障，海恩法则给我们的启发与教训

海恩法则对于我们维护线上系统稳定性，尤其是复杂的线上应用，具有极其深刻的指导意义。

教训与经验借鉴：

  1. 「小问题」绝不小觑：线上一个偶发的 null 指针异常、某个非核心接口超时频率略增、用户反馈的一个「不太影响使用」的小 Bug，都可能是「29」或「300」的信号。如果仅仅是临时「hotfix」或者因为优先级不高而搁置，这些「小债」累积起来，迟早会引发“大雷”。
  2. 「未遂」也是宝贵数据：一次灰度发布中发现的问题并回滚、一次压力测试暴露的瓶颈、一次配置错误在生效前被发现……这些都是「未遂事件」。它们暴露了流程或系统中的薄弱环节，是改进的绝佳机会，不能因为「没出事」就庆幸了事。
  3. 故障复盘不能止于表面：发生故障后，不能仅仅定位到直接原因（比如某行代码写错了），更要深挖根本原因：为什么这行错误的代码能上线？测试为何没发现？Code Review 为何遗漏？发布流程是否有问题？这才是触及「300个隐患」层面的思考。
  4. 建立「隐患上报」的文化：鼓励团队成员主动暴露系统中的潜在风险、不合理的设计、流程上的缺陷，即使这些问题短期内没有引发故障。要营造一个「说出问题是贡献」的安全文化氛围。

哪些算作「轻微事故」和「隐患」？线上 BUG 怎么算？

  • 300 个隐患 – 系统中的「定时炸弹」：

    • 技术债：过时的库、临时的硬编码、缺乏注释的复杂代码、糟糕的架构设计。
    • 配置风险：配置项繁多且缺乏校验、配置管理混乱、关键配置依赖人工操作。
    • 监控盲区：核心业务指标未监控、告警阈值不合理、日志信息不全或格式混乱。
    • 测试覆盖不足：单元测试覆盖率低、缺乏有效的集成测试和端到端测试、对异常场景和边缘 Case 考虑不周。
    • 流程缺陷：发布流程不规范、变更管理随意、缺乏应急预案或预案未演练。
    • 知识断层：核心模块只有少数人懂、文档严重滞后或缺失。
    • 不规范的操作习惯：随意在线上环境执行高危操作、密码弱口令或共享。
    • 线上 BUG，未直接造成服务中断或核心功能严重受损的：例如，某个页面的 UI 显示错位、某个非核心功能的计算结果在特定条件下不准确但用户感知不强。这些 BUG 本身是问题，也是系统脆弱性的体现，属于「隐患」范畴，若不修复，可能在特定条件下与其他因素叠加，引发更严重问题。

  • 29 次轻微事故 – 系统发出的「黄牌警告」：

    • 短暂的服务抖动：例如，某个服务实例重启导致短时间部分请求失败。
    • 部分功能不可用或性能下降：例如，图片上传功能暂时失败、某个 API 响应时间飙升但未完全超时。
    • 告警频繁触发但能自动恢复：例如，CPU 使用率短时超阈值后回落。
    • 线上 BUG，已造成用户可感知的、轻微的功能异常或体验下降：例如，用户无法修改头像、搜索结果排序偶现不符合预期但仍可使用。这类 BUG 已经对用户产生了一定影响，属于轻微事故。
    • 资源超限警告：数据库连接池满、磁盘空间接近阈值。

  • 1 次重大故障 – 系统「拉响红色警报」：

    • 核心服务长时间中断。
    • 大面积用户无法使用核心功能。
    • 数据丢失或严重损坏。
    • 造成公司声誉或经济重大损失。

哪些指标能帮我们「看到」冰山？

有效的监控和度量是发现「29」和「300」的关键。以下一些指标可以帮助我们感知系统的健康状态：

  • 线上 BUG 数量与趋势：

    • 新增 BUG 数/解决 BUG 数：反映研发质量和修复效率。
    • 遗留 BUG 数量与等级分布：高等级 BUG 积压是重大风险。
    • BUG 平均解决时长 (MTTR for bugs)。
  • 代码质量指标：

    • 圈复杂度：高圈复杂度的代码往往难以理解和维护，是潜在的 BUG 温床和隐患。持续监控圈复杂度的变化趋势，对超标模块进行重构。
    • 代码重复率。
    • 静态代码分析告警数。
  • 系统稳定性与性能指标：

    • 服务可用性 (SLA/SLO)。
    • 错误率：API 错误率、特定业务操作错误率。
    • 平均响应时间 (Average Response Time) 与分位值 (e.g., P95, P99)。
    • 资源利用率与饱和度：CPU、内存、磁盘I/O、网络带宽、数据库连接池等。
  • 变更与发布相关指标：

    • 变更成功率。
    • 因变更引发的故障数。
    • 发布频率 (高频健康的发布是敏捷和稳定的体现，但需质量保障)。
  • 告警与事件指标：

    • 告警数量与级别分布：过多低价值告警会造成“告警疲劳”。
    • 平均故障检测时间 MTTD
    • 平均故障恢复时间 MTTR

海恩法则的「亲友团」：这些智慧异曲同工

海恩法则并非孤军奋战，在安全管理和系统思维领域，还有许多理论与它遥相呼应，共同构成了我们理解和应对风险的知识体系：

  1. 墨菲定律：「凡事只要有可能出错，就一定会出错。」 它提醒我们不要抱有侥幸心理，任何潜在的风险点都可能在某个时刻爆发。

  2. 多米诺理论：同为海因里希提出，认为事故的发生像一连串倒下的多米诺骨牌，由五个阶段（社会环境/遗传因素 -> 人的失误 -> 不安全行为/条件 -> 事故 -> 伤害）连锁引发。切断其中任何一环，特别是「不安全行为/条件」，就能阻止事故。

  3. 冰山理论：事故的直接损失（如设备损坏、人员伤亡）只是冰山一角，水面下隐藏着更大的间接损失（如生产延误、声誉受损、员工士气低落等）和深层原因（管理缺陷、安全文化缺失）。与海恩法则的 1:29:300 有异曲同工之妙。

  4. 帕累托法则 80/20 法则：大约 80% 的事故是由 20% 的原因造成的。这提示我们要集中资源解决那些最关键的风险点和隐患。

  5. 鲍尔法则：系统越复杂，发生重大事故的概率越高。这警示我们在设计和维护复杂系统（如AIGC应用）时，要格外关注风险的累积和扩散。

  6. 「四不放过」原则：事故原因不查清不放过、责任人未受到处理不放过、整改措施未落实不放过、相关人员未受到教育不放过。这是事故后处理的铁律，确保从错误中学习，防止重蹈覆辙。

  7. 瑞士奶酪模型：由詹姆斯·里森（James Reason）提出。系统有多道防线（如代码规范、测试、监控），每道防线都像一片瑞士奶酪，上面有孔洞（缺陷）。当所有孔洞恰好对齐时，风险就会穿透所有防线，导致事故。这强调了单一防线的不足和多层防御的重要性。

  8. 破窗效应：环境中一个未被修复的「破窗」，会暗示这里无人管理，从而诱发更多的混乱和破坏。对应到系统中，一个小 BUG、一个不规范的操作长期被容忍，会逐渐侵蚀团队的质量意识和纪律，最终导致大问题。

从「救火」到「防火」：我们的系统性行动指南

理解了这些法则和理论，我们不能仅仅停留在「哦，原来如此」，更要将其转化为行动，从根本上提升系统的稳定性和韧性。

  1. 拥抱「小题大做」文化：对每一个「29」和「300」保持高度警惕，建立快速响应和彻底解决的机制。
  2. 建立并严格执行「故障复盘」机制：深入挖掘根本原因，落实改进措施，并跟踪效果，形成闭环。
  3. 强化「可观测性」建设：完善日志、指标、追踪体系，让系统的每一个角落都“透明可见”。利用好我们前面提到的各项指标。
  4. 投资于「看不见的角落」：积极偿还技术债，优化系统架构，完善自动化测试，加强代码审查，推广混沌工程等。
  5. 提升团队的「风险意识」与「系统思维」：让每个人都成为系统安全的守护者，理解自己的工作如何影响全局。
  6. 持续演练，常备不懈：完善应急预案，并定期组织真实场景的故障演练，提升团队应急响应能力。
  7. 数据驱动，持续改进：利用收集到的指标数据，分析趋势，识别瓶颈，指导我们的优化方向。例如，如果线上 BUG 数持续在高位，或圈复杂度高的模块频繁出问题，那就是明确的改进信号。

写在最后

线上系统的稳定性，是一场没有终点的马拉松，也是一场与熵增（系统混乱度增加的自然趋势）的持续对抗。故障不可怕，可怕的是从故障中一无所获，反复在同一个地方跌倒。

希望海恩法则和它的「亲友团」能像一盏盏明灯，照亮我们系统中的每一个阴暗角落，指引我们关注那些微小的信号和潜在的风险。通过系统性的思考、数据驱动的决策和持续不懈的改进，我们一定能逐步减少重大故障的发生，为用户提供更稳定、更可靠的服务。

以上。

技术领导力的底层逻辑：判断力 × 价值输出 × 主观能动性

发表回复

技术人升维的三个关键因素

很多技术人工作几年后都会面临一个瓶颈：技术会了不少，系统也写了不少，但怎么感觉成长速度慢了，价值也越来越模糊了？

这是因为，在技术从「执行层」往「决策层」和「影响力层」跃迁时，光会写代码已经远远不够了。

真正的技术领导力，拼的是三样东西：

判断力 × 价值输出 × 主观能动性

这三个词，听起来不复杂，但能把它们练到高水平，就是我们从「高级工程师」走向「技术负责人」的通行证。

判断力：技术人真正的「品味」

什么是判断力？

判断力，说简单点，就是在一堆看起来都「还行」的选项里，选出最值得做的那个，并且用正确的方式去做。

它体现在两个层面：

  1. 方向选得准（做什么）
  2. 方法选得好（怎么做）

举个例子

当我们接到一个任务，要优化一个系统模块的性能。
普通思路：加缓存、调 SQL、查慢日志。

但一个有判断力的工程师，可能会问：

  • 这个模块真的值得优化吗？它是性能瓶颈吗？
  • 有没有更高层的系统设计可以绕开这个模块？
  • 优化后能带来多大业务价值？

可能最后什么都没改代码，而是重构了调用链，10行改动，性能翻倍。

这就是品味，也是判断力。

如何提升判断力？

以下是 3 个可以试一下的练习：

  • 列出5个最近想做的技术优化点，找一个信任的同事，请 TA 从「价值」角度给你打分。讨论你们意见不一致的地方。
  • 当别人做了我们本来想做的事时，别懊悔，去复盘：他们是怎么做的？结果如何？和预期一样吗？
  • 多和有经验的人聊「为什么做这事」，而不是「做了啥」。高手的判断逻辑，才是我们最该学的。

价值输出：做有杠杆的事，而不是瞎忙

什么是价值输出？

价值输出，不是我们写了多少代码、画了多少图，而是：

我们做的事，对别人有多大帮助，对团队和产品有多大推动力。

举个例子：

  • 写了一个内部小工具，帮测试同事节省了每周8小时 → 高价值输出
  • 加班两天，把代码从 A 风格改成 B 风格 → 低价值输出

高效能技术人，不是更忙，而是更「值」。

案例：什么是「高杠杆」工作？

几个例子：

  • 优化工具链：比如把构建时间从 15 分钟降到 5 分钟，整个团队受益。
  • 识别研究方向：一开始只是某人边玩边试的 idea，最后变成公司级的重点项目。
  • 深入看数据：很多隐藏的问题，都是通过“一个人花几个小时翻日志”发现的。

如何提升价值输出？

  • 每周问自己：我这周做的事，有没有「放大器」？
  • 如果我停掉这件事，团队会受影响吗？
  • 有没有更小的投入，能实现同样目标？

主观能动性：不等任务分配，主动出击

什么是主观能动性？

一句话总结就是：

不等别人告诉我们做什么，而是我们主动去发现问题、提出方案、推动落地。

很多人说自己「执行力强」，但其实只是「能干活」。

真正的能动性，是我们在没有指导、没有明确需求时，还能找到方向、推动价值、让项目成型。

模式对比：

模式 工作风格 结果
被动模式 “我等任务” “我按流程” 做了很多事，没人记得你
主动模式 “我发现问题” “我自己提方案” 你是推动者，别人靠你

这样成功就变得不可避免了。

如何提升主观能动性？

  • 从「任务驱动」切换到「目标驱动」：别只看排期，而是想「这事最终的业务目标是什么？」
  • 别等别人批准你做什么，先做 MVP，拿出 demo，让结果说话。
  • 做项目时写一份小计划：从目标反推关键路径、时间点、资源缺口……这已经是半个技术管理者了。

小结：三力合一，才是真正的技术领导力

核心能力 解释 行动关键词
判断力 选对事情、做对方法 选题、决策、优化路径
价值输出 做有杠杆的事 放大器、影响力、成果感
主观能动性 主动推动、对结果负责 发现问题、提出方案、执行落地

留个作业吧：今晚复盘一下

花10分钟，写下你最近做的3件事，问自己：

  • 这事有没有判断失误？有没有更好的做法？
  • 这事真正的价值产出在哪？是否值得投入？
  • 是我主动推动的，还是等人安排的？

最后：

写代码不如写决策，写决策不如写未来。我们一起成长。

以上。