Protobuf 3 和 gRPC 是 Google 开发并开源的一对“黄金搭档”，它们共同构成了现代高性能微服务通信的基石。简单来说，Protobuf 3 负责高效地“打包”数据，而 gRPC 则负责快速地“运输”这些数据。

📦 什么是 Protobuf 3？

Protobuf 3（Protocol Buffers 3）是 Google 开发的一种轻量级、高效的结构化数据存储格式，可以把它理解成一种数据序列化工具。

它的核心工作流程是：

1. 定义数据结构：你使用一种接口定义语言（IDL），在一个 .proto 文本文件中定义你的数据结构（称为“消息”）。
2. 生成代码：通过 protoc 编译器，根据 .proto 文件自动生成多种编程语言（如 Go, Java, Python, C++ 等）的数据访问类。
3. 序列化与反序列化：在你的代码中，使用生成的类来创建、填充数据对象，并将其序列化为紧凑的二进制格式进行传输或存储；接收方则能高效地将其反序列化回对象。

Protobuf 3 的核心优势

• 高性能：与 JSON 或 XML 等基于文本的格式相比，Protobuf 将数据序列化为二进制，因此消息体积更小（通常只有 JSON 的 1/3 到 1/2），解析和序列化速度也更快（可快 50% 以上）。
• 强类型与语言无关：通过 .proto 文件定义一份明确的数据契约，可以生成各种语言的代码，确保了不同服务间数据交互的强类型安全和一致性。
• 易于演进：Protobuf 3 的设计哲学强调简单和向后兼容。它移除了 required 字段，所有字段默认为 optional，并提供了 reserved 关键字来保护已删除字段的编号，这使得在不破坏现有客户端的情况下对数据结构进行升级变得非常容易。
• 标准化 JSON 支持：Protobuf 3 提供了标准化的 JSON 映射，方便在需要人类可读或与 Web API 交互的场景下进行调试和通信。

🚀 什么是 gRPC？

gRPC 是一个现代、开源、高性能且通用的远程过程调用（RPC）框架。它让一个应用程序能够像调用本地函数一样，去调用另一个远程服务器上的函数，极大地简化了分布式系统间的通信复杂性。

gRPC 的核心特性包括：

• 基于 HTTP/2：gRPC 默认使用 HTTP/2 作为传输协议，这带来了多路复用（在单个连接上并行处理多个请求）、头部压缩、双向流等高级功能，显著提升了网络效率。
• 以 Protobuf 为默认数据格式：gRPC 使用 Protobuf 作为其默认的接口定义语言（IDL）和消息序列化机制，继承了其高性能、强类型的优点。
• 代码生成：通过 .proto 文件定义服务接口（包括方法、参数和返回类型），gRPC 可以自动生成客户端和服务端的桩代码，开发者只需关注业务逻辑的实现，无需手动处理底层的网络通信、序列化等细节。

gRPC 的四种通信模式

gRPC 提供了灵活的通信模型，以满足不同场景的需求：

总而言之，Protobuf 3 和 gRPC 共同提供了一个完整的解决方案，用于构建高效、可靠且易于演进的分布式系统和微服务架构。

对AI MCP来说这还挺难得的。
https://mp.weixin.qq.com/s/o4cU4OXxMwL3MATpx99StQ

将目录中的所有图片按从名称从左到右合并到一张大的精灵图里。
新建： sprite_combine.py

#!/usr/bin/env python3
"""
Sprite Combine Tool
Combine all PNG images in a directory into a single horizontal strip.
"""

import argparse
import os
import sys
from pathlib import Path
from PIL import Image


def main():
    parser = argparse.ArgumentParser(
        description="Combine PNG images from a directory into a single horizontal image."
    )
    parser.add_argument(
        "directory",
        help="Directory containing PNG images to combine"
    )
    parser.add_argument(
        "-o", "--output",
        default="combined.png",
        help="Output filename (default: combined.png)"
    )
    parser.add_argument(
        "-s", "--spacing",
        type=int,
        default=0,
        help="Spacing between images in pixels (default: 0)"
    )
    parser.add_argument(
        "-b", "--background",
        default=None,
        help="Background color (hex format like #FFFFFF or transparent for none)"
    )

    args = parser.parse_args()

    dir_path = Path(args.directory)

    if not dir_path.exists():
        print(f"Error: Directory '{args.directory}' does not exist.", file=sys.stderr)
        sys.exit(1)

    if not dir_path.is_dir():
        print(f"Error: '{args.directory}' is not a directory.", file=sys.stderr)
        sys.exit(1)

    # Get all PNG files and sort by name
    png_files = sorted(dir_path.glob("*.png"), key=lambda x: x.name)

    if not png_files:
        print(f"Error: No PNG files found in '{args.directory}'.", file=sys.stderr)
        sys.exit(1)

    print(f"Found {len(png_files)} PNG image(s):")
    for f in png_files:
        print(f"  - {f.name}")

    # Load images
    images = []
    for filepath in png_files:
        try:
            img = Image.open(filepath)
            # Convert to RGBA to handle transparency properly
            img = img.convert("RGBA")
            images.append(img)
        except Exception as e:
            print(f"Warning: Could not load '{filepath}': {e}", file=sys.stderr)
            continue

    if not images:
        print("Error: No valid images could be loaded.", file=sys.stderr)
        sys.exit(1)

    # Calculate dimensions
    spacing = args.spacing
    max_height = max(img.height for img in images)
    total_width = sum(img.width for img in images) + spacing * (len(images) - 1)

    print(f"\nOutput dimensions: {total_width} x {max_height} pixels")

    # Parse background color
    bg_color = None
    if args.background:
        if args.background.lower() == "transparent":
            bg_color = None
        else:
            # Parse hex color
            hex_color = args.background.lstrip("#")
            if len(hex_color) == 6:
                bg_color = tuple(int(hex_color[i:i+2], 16) for i in (0, 2, 4)) + (255,)
            else:
                print(f"Warning: Invalid hex color '{args.background}', using transparent.", file=sys.stderr)

    # Create combined image
    if bg_color is not None:
        combined = Image.new("RGBA", (total_width, max_height), bg_color)
    else:
        combined = Image.new("RGBA", (total_width, max_height), (255, 255, 255, 0))

    # Paste images
    x_offset = 0
    for img in images:
        # Center vertically if different heights
        y_offset = (max_height - img.height) // 2
        combined.paste(img, (x_offset, y_offset), img)
        x_offset += img.width + spacing

    # Save result
    output_path = Path(args.output)
    combined.save(output_path, "PNG")
    print(f"\nSaved combined image to: {output_path.resolve()}")


if __name__ == "__main__":
    main()

依赖文件 requirements.txt

Pillow>=10.0.0

安装依赖:

pip install -r requirements.txt

运行方式：

python sprite_combine.py <folder_name>

可以改为bat文件spcomb.bat方便执行：

python sprite_combine.py %1

使用纯净css运行合并后的精灵图动画,可用于微信小程序：
wxml如下：

<view class="shutu-animation"></view>

wxss如下，假设精灵图为150x150px，合并后大小为9150x150px：

.shutu-animation {
  width: 150rpx;
  height: 150rpx;
  background-image: url('https://xxxxx/combine.png'); /* 单行图 */
  background-size: 9150rpx 150rpx; /* 总宽 x 高 */
  animation: play 6s steps(61) infinite; /* 30帧需要走29步 */
}

@keyframes play {
  100% {
    background-position: -9150rpx 0; 
  }
}

我发现一个问题，要AI使用框架的话，一定要让AI用最流行的框架，而不要用所谓AI自己觉得最合适你项目的框架。原因是最流行的框架有最丰富的文档，AI在前期训练的时候会对该框架有更多的了解。流行程度不佳的框架文档缺失，AI自己在编程的时候也会遇到更多的阻力，踩更多的坑。
刚刚让AI去编写一个贪吃蛇的游戏，当然我使用了superpowers这个插件来去编写，意图让他长时间的去运行编码任务并且可以编写一个比较复杂的程序。贪吃蛇游戏本身逻辑很简单，然后superpowers在进行问答的过程中，我有意采取了一些更加复杂的游戏设计，看它是否能够实现。
然后我用的是GLM4.7，它就开始提示我用框架的事情，我让他给了几个选择，他说phaser和kaboom都可以用，但是前者的框架太复杂，学习曲线太陡峭了，而后者也就是Kaboom这种轻量级的框架更适合我这种轻量级的小游戏。
phaser我之前是用过的，但是既然他说kaboom可以就让他用吧。没想到后面编码的时候竟然出现将API完全用错的情况。他自己发现错误之后就回过头去重构，然后还要再去理解到底这个API该怎么用。
其中还出现了一个问题，就是它总是要使用8000端口启动游戏的网页服务器。然而，8000端口已经被我的其他内部服务占用了，他对此毫不知情，弃而不舍的去启动这个服务。我只好中断它的运行，让它更换为其他端口。这就不适合用作长期自主运行的agent了。

kokoro

https://github.com/hexgrad/kokoro
https://huggingface.co/hexgrad/Kokoro-82M-v1.1-zh#usage
这个只有82兆支持中文，听起来效果还是不错的

chatTTS

https://github.com/2noise/ChatTTS
https://huggingface.co/2Noise/ChatTTS
这个模型比较大，需要较高算力，也支持中文。

找了很多软件，发现还是用dvr-scan比较好。
网址： https://www.dvr-scan.com/download/
下载方式：

pipx install dvr-scan

或者

python3 -m pip install dvr-scan

GUI运行： dvr-scan-app
CLI运行： dvr-scan

安装pipx，在windows上使用

scoop install pipx
pipx ensurepath

遇到 ESP32-C2 系统崩溃，最核心的 debug 手段是解析 Backtrace（回溯栈）。

1. 快速定位工具：idf.py monitor (首选)
   如果你是在开发环境下，直接使用 idf.py monitor 烧录并观察串口。当崩溃发生时，它会自动调用底层的 addr2line 工具，将 十六进制地址直接转换成文件名和行号。
2. menuconfig 中开启gdb调试(量产不要开启,否则会卡在gdb界面要手动重启)
   开启 GDB Stub：在 menuconfig 中将 Component config -> ESP System Settings -> Panic handler behaviour 改为 Invoke GDBStub。崩溃时会自动进入 GDB 模式，你可以输入 bt 查看完整的调用栈。
3. 内存检测：在 menuconfig 中开启 Heap sentinel (堆哨兵) 或 Lightweight scan，排查是否有内存越界。
   3.1 开启 Heap Sentinel (堆哨兵)
   堆哨兵会在分配的内存块前后加入“魔数”，如果代码写越界了，释放内存时会触发报错。
   路径： Component config -> Heap memory debugging -> Heap corruption detection
   设置项： 选择 Comprehensive (综合模式) 或 Light impact (轻量模式)。
   Comprehensive：每次 malloc/free 都会检查，性能损耗稍大，但最精准。
   Light impact：仅在某些特定操作下检查，性能损耗小。
   3.2. 开启 Heap Trace (内存追踪)
   如果你怀疑有内存泄漏或者异常分配，可以开启追踪。
   路径： Component config -> Heap memory debugging -> Enable heap tracing
   注意： 开启后需在代码中调用 heap_trace_start() 才会真正开始记录。
   3.3 开启 Stack Overflow Check (栈溢出检测)
   针对任务（Task）栈空间的监控，防止函数嵌套太深导致崩溃。
   路径： Component config -> ESP System Settings -> Check for stack overflow
   设置项： 建议选择 Internal watchdog
   3.4 Canary bytes
   Canary bytes：在栈末尾放置特殊字节，任务切换时检查，最常用。
   选择路径: Component config->FreeRTOS->Kernel->Check for stack overflow (在此處選擇 Check using canary bytes)

YD/T2583.14-2013;GB 4943.1-2022

刚才想到这个问题，突然有一个洞见。
企业的核心竞争力就是对客户需求的深刻理解和独特实现。
微软的纳德拉说，未来企业要有竞争力，就必须将企业的独特内在知识沉淀为AI大模型的独特能力。这里说到了AI数据主权。只有自己的模型沉淀了自己的企业能力，才可以说是有自己的数据主权。
我刚刚有一个洞察，这么多年居然都没有想到的一件事情。一个人对需求的理解，是与其他人不同的。我很惊讶，我到现在居然才深刻认识到这一点。我曾经以为，如果大家看到了同一个需求，经过正确的推理，一定能获得相同的理解。就好像大家看到一个数学题，经过相同的推理，一定能获得同一个答案一样。然而现实却完全不是这回事。如果还用数学题来比喻。那一个需求其实是多道数学题，而且每道数学题可能都有多种不同的解。然后现实是一个有限资源的决策。需要在有限的资源下，决定到底要解决哪道数学题，用哪种方式，获得哪种解才是最高效的。同样的，由于每个人都是一个有限资源体，他所能发现的，要解决的问题，也是和其他人不同的。再加上每个人的背景、经验和能力不同，他看待每一道题的可解性上面也有很大不同。同样对于同一道数学题，可以用代数、几何等等不同的方式来去解决。这就会造成最终解题思路和形态的不同。另外一些数学题可能只能用专用的知识，比如微积分来解决。而不懂微积分的人可能认为这道题是无解的，或者说是给出一种特别复杂的、极耗资源的方案。
所谓对客户需求的深刻理解，就是找出所有的数学题，了解哪些数学题需要通过哪些知识可以最高效地解决，并且用最高效的路径实现。企业为客户提供的价值，就是客户旧的解决方案所需代价与企业提供的新的解决方案所需代价之间的差额。企业的利润就是最高效路径的耗费成本与收到客户的新方案费用之间的差额。
这一切当然都可以转化为成本、利润与销售额的简单算式。但是成本加利润等于销售额的算式里面，掩盖了不同公司成本为何会不同，销售额和利润为何不同的原因。归根结底就是能不能提供新的解题思路。
所谓一个行业是否成熟，就是这个行业的所有企业是否最终都不约而同地采用了相同的、最高效的解题思路。这就解释了一个行业的发展周期。早期阶段，只有少数公司能发现少量的解题思路。行业快速发展阶段，有众多公司发现了众多不同的新的思路。行业成熟期，解题思路变得更加的单一、高效、节约资源，企业也逐渐淘汰，向少数头部集中。衰退期是行业的单一思路被新的知识所提供的新思路替代，或者是原本的算术题，也就是需求消失了。
一个需求可能是一个树状结构。子需求是父需求的解决方案。从这个角度来说，需求（问题）和解决方案的定义是相对的。一个需求，它到底是需求还是方案，在需求树中，就看它是相对于父需求，还是相对于子需求来说了。
从业者经常会混淆需求、问题和解决方案这三个名词。为了明确，我需要对这三名词进行重新的关系定义。需求既是问题，也是解决方案，相对于其父需求，它就是解决方案。相对于其子需求，它就是问题。所有的需求向前追溯，也许都有一个根需求。那这个根需求可以称之为终极问题。
举个例子，人对计算的需求自古至今一直是有的。其解决方案有算筹、有算盘、有计算机。那如何制造算筹、算盘和计算机？这又变成了一个新的问题。算筹的解决方案可能有竹签、有象牙、有对应的不同工艺。计算机，那就更复杂了，解决方案包括硬件和软件，如何实现硬件和软件？这两个问题又有极其复杂多变的子需求。计算的需求往计算机这个子需求上面走，就会形成一个极其庞大、枝繁叶茂的树。需求向后生长，最终的需求可以说是最终交付的解决方案。
从计算机的这个需求上来说，软件的需求为什么最终会超过硬件？这是因为软件的这棵树可以开得更加枝繁叶茂。从软件上实现计算，有不同的编程语言，有Excel、有前端、后端、数据库…简直无法穷尽呢。
现在AI又带来了一个新需求。它既能成为现在计算这个终极问题的新方案，又提出了更多该如何实现AI的新问题。
一个解决方案的成本并不是固定不变的。它会随着整个环境和时代的不同而改变。原因是一个解决方案需要依赖的上下游供应链关系是不同的。在不同的环境和时代中，是否能提供这个上下游供应关系，就不一定了。或者简单来说，解决方案是最终产品，需要供应链来解决。供应链要能提供解决方案所需要的原材料，解决方案才可以最终实现。在不同的时期，能否提供原材料的可能性不同，能否提供这些原材料的能力也不同，所以其价格也不同。这就是所谓一个解决方案的供应链是否成熟的问题。为什么早20年或者更早的时间就有很多企业觉得电动车是未来，并且付诸于实践并解决其问题。然而并不能成功的原因，就是因为在那个时候，其上游供应链并不能提供成熟的、丰富的、有价格竞争力的原材料。
当一个需求的解决从一种解决方案往一种新的解决方案上面迁移的时候，旧的解决方案的上游供应链也会被逐渐抛弃，从而带来旧方案的涨价。这种涨价进一步推进了旧方案走向衰亡。

Blender做渲染和动画设计的时候有很多要求, 在设计产品用于3D打印的时候,却似乎减少了很多要求.
比如: 不能用N-gon(超过5个顶点的多边形, 默认生成圆柱体的顶面底面都是N-gon), 不要内藏面, 但是用于3D打印似乎都不重要了. 即便是有N-gon, 有内藏面, 以bambu studio为例, 都能正确形成打印路径, 不会把内藏面打印出来.
要能3D打印, 物体必须是封闭的. 如果不封闭, 则这个物体即便可以在bambu studio中显示也无法打印出来. 不封闭的物体A靠在封闭物体B上, 视觉上封闭了A, 但A仍然不能被打印.
另外,STL文件导出后, 在Windows 3D builder中和bambu中都是把米变为了毫米. 在3D builder中, 还可以切换单位, 但是默认是毫米. 我以为是blender导出过程中丢失了单位, 但是将此文件重新导入blender,单位仍然是米. 查询了stl的定义, 原来这个文件本身是不带有单位的.

很久没有动ESP32和IDF这套东西了，这里记录一下过程

1. 环境安装。可以使用乐心最新推出的EIM ESPIDF环境安装工具来安装，选择版本5.4.3。不要用国内的仓库来下载，还是要用GitHub。Python仓库可以用国内镜像。下载完毕后在EIM中打开5.4.3的环境。这一步必须非常小心，因为可能会由于网络的问题导致部分IDF的仓库或者说子模块没有下载完整，最终导致编译失败。
2. 首先从GitHub上下载DOIT_AI，并解压缩，而不是通过git clone命令来克隆它。因为项目作者不小心上传了一些NTFS的流文件，其中含有冒号，会导致git clone的时候这些文件无法在Windows上创建，进而导致整个目录中的文件全部创建失败而消失不见。
3. 进入 DOIT_AI目录，运行：

   idf.py set-target esp32c2
   idf.py menuconfig

   配置board为doit-ai-01， 保存退出。

4. 使用idf.py build进行编译。
5. 使用idf.py merge-bin合并为一个从0x0开始的bin文件merged-binary.bin

有时候在远程仓库的页面上看到文件内容都有, 也不存在分支不对的问题, 然而windows下使用git clone之后进入目录却是空的.
一种情况是远程仓库中存在部分文件以:Zone.Identifier结尾。因为文件中含有:, 无法在windows中正常创建文件, 导致所有的文件都没有被创建.
这类文件通常是因为在 Windows 系统下从互联网下载了文件。
机制：Windows 的“附件管理器”会自动在下载的文件中添加一个名为 :Zone.Identifier 的隐藏流。
内容：该流记录了文件的来源区域（例如 ZoneId=3 代表 Internet）。这也就是为什么运行下载的 .exe 时会提示“此文件来自其他计算机，可能被锁定”的原因。
为何进入 Git：如果在 Linux 或 macOS 环境下将这些带有 NTFS 流属性的文件提交到了 Git 仓库，而这些系统并不强制处理 NTFS 特性，它们会被当作普通文件（或文件名的一部分）存储 .
我觉得有可能是在windows的linux子系统中做了git commit导致的.
解决方式: 不要通过git clone, 改用下载zip包的方式, 通过7-zip解压缩后, 会发现7-zip自动将:转换成了., 如果不解压缩直接查看压缩文件, 还能看到这些文件名中含有:

今天在思考常规的产品塑胶外壳，开模贵、周期长的这件事情。由此又想到之前各种专家总是提，未来的产品需要DIY个性化。那按照这种开模的思路，那肯定是不可能的。并且一般的产品如果要盈利，或者说至少把模具费赚出来的话，至少得2000个以上吧。开模的话，一套模具几万，一个产品会有好几套模具。那随随便便都会有十几万甚至几十万的一个费用。除非你做非常小的产品，并且它的塑胶件数非常少。我们为了减少开模的费用，曾经甚至用了铝型材来做。铝型材的模具费用很低，一两千或两三千块钱就可以，但是材料费用比较高。
除了塑胶模具之外，还能做出塑胶壳的这种质感的，一个就是3D打印，另外一个就是硅胶模具。硅胶模具比塑胶模具的价格便宜，但据说能制作的塑胶成品大概只有几百套而已，几百套之后模具就变形严重，不太好去做了。
3D打印需要预先设计好产品，设计这一步还是略有门槛，可能专业的需要考虑用Solidworks之类的产品3D建模设计软件来去做。免费的就只有Blender和FreeCAD这两个产品。我自己没有3D打印机，需要外发打印，中间也会需要有个好几天的来回的时间。所以门槛还是略高一些的。一方面是软件的学习门槛，另外一方面就是这个时间，以及3D打印的费用或者是软件购买费用。
今天看到一个产品还是挺惊讶的，叫做拼豆。就是把很小的圆柱形管子拼在一起，然后用熨斗压实，就成一个连接在一起的片材。从视频上看，这个东西似乎有点软，并且不太好去做立体造型。如果有办法去拼上加强筋，或者做一些立体造型，可能就更加有趣了。假如说还能拼上去螺丝柱，或者拼上去卡扣，那真的就可以做一些产品了。
其他一些产品，包括热塑片，也是主要做平面的产品。超轻粘土，做出来东西比较脆弱，不好做结构件。3D打印笔不好做外观光滑的东西，而且形状比较难控制。软陶、石塑粘土、树脂粘土，这些都需要一定的塑型雕刻能力。其中软陶的质感可能最好，通过在烤箱加热，最后质感会比较接近陶瓷表面。石塑粘土、树脂粘土和超轻粘土，都是需要自然条件下经过一两天的风干。
回到拼豆上面。拼豆之所以只能做平面的，大概是因为它需要用熨斗正反面压平。如果有高温器件可以给它压成弧面，那应该也可以做弧形的产品。

Windows 10电脑上出现了用鼠标选择任意文本就会自动复制的问题。这个很头痛，因为我很习惯选择后进行一些其他操作，而不是复制。尤其是选择后直接粘贴，预期的结果是用剪切板的内容覆盖掉选择的内容，然而这个神秘的自动复制，让这个操作就失效了。并且是在任意窗口都会这样。
先是让AI写了一个自动的Python脚本去检测按键输入。很顺利的检测到了，在鼠标选择文本之后，会有一个虚拟按键输入，左Ctrl加Insert。
接下来就要去找到底是哪个程序输入的，这个过程千难万阻，最终也没有成功。依次尝试了Process Monitor、Spy++、API Monitor、Inside clipboard等等这些方法。但是由于Windows它不会记录虚拟按键发送者的名称，所以找起来真是大海捞针。Spy++ 和API Monitor可能更接近于成功，但是这两者都只能监控一个控件或者一个窗口，无法做全系统的监控，这也可以理解，因为全系统的这种消息实在是太多了。
最后想到一个办法，是不是可以拦截左Ctrl加Insert键，让它不再复制？发现微软官方的PowerToys就可以做到。在它的键盘管理器里面可以去重新映射快捷键。将左Ctrl加Insert键映射为Disable就解决了。
郁闷的是，一直不知道这个在背后捣鬼的程序是谁。AI都猜测是某个类似于画词翻译的程序。