glaze https://glaze.cs.uchicago.edu/
nightshade https://nightshade.cs.uchicago.edu/whatis.html

现在有公账、私账、平台账。这些都是内部账.
这三种账户都可能直接和外部进行交易. 交易主要就分收入和支出.
这三个账户之间可以进行互转.

三种账户之间互转的类型，以及通常的称呼和方式

首先，三种账户之间互转都存在一种借款和还款的类型。除借还款之外，下面的是单向的，也就是转过之后不需要再还回来。
私账转公账可以称之为投资；
公账转私账可以称之为报销（需要票），或工资（不需要票）；
公司账转平台账可以称之为预存；
平台账转公司账称之为提现；

第一个问题是内部账之间的互转可以被视为一种交易吗?

如果内部账之间的互转被视为一种交易的话，那么从A账转B账的话，就需要同时记收入和支出，只记收入或者只记支出都会导致总资金的增加或者减少，那么帐肯定就不平了。
所以不能被视为一种交易，就是有专门的转账类型。

第二个问题是一笔采购交易，如何被看成私账支出还是公账支出？

如果有私账先采购没有开票的情况下，就是私账的支出，如果有开票的情况下，就变成公账支出，需要转给私人的报销款。所以一批私账采购交易是否要报销就看是否开票。

淘宝和支付宝该怎么说呢，就对商家非常的不厚道。把保证金管理入口藏得非常深。
位置如下：

电脑端登录 b.alipay.com 商家中心-对账中心-左侧资金账户-支付宝账户-保证金

以前保证金的入口跟支付宝账户同级，现在竟然把它隐藏在支付宝账户之下了。

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