因为每次都被人问是不是道士、有无信仰。
所以反叛的我，不看道德经转头开始看心经，
用了两周时间，总算看完。

佛讲了苦集灭道，十二因缘法，
到了大乘后，可不要止步于此。

了解到有后，再破掉。
最终从破再到无破可破。

如果还有人问我是不是道士、有无信仰。
我还是会说，不是、没有。

肠胃检查一切正常，
可以安心喝一杯了。

Kimi的能力也很可以，
就这个使用场景和解决方法，
感觉可以拿公司内部做ppt了。

背景:
机械臂前往托盘夹取物体的过程，会存在碰撞，
所以同事，新增了一个安全区域的识别，
原理是录制x y的最大最小值，对抓取位置进行判断。

诱因:
昨天下午配置后，进行测试，总感觉不对劲，
判断是他没考虑托盘和机械臂之间的坐标问题。
导致我理解的范围和实际识别范围存在差距，具体效果可以参考图1，我理解录制的是正方形，实际是对新到机械臂判断是一个斜的正方形，
于是花了一晚上，就有这个工具。

思路:
先验证转换是否正确，误差是否可用，
验证能否提供ini文件，
能否图形化显示，
能否显示效果进行检验，
结果是否可逆。

结果:
首先可以通过拖拉拽设置安全区域，
生成对应的ini配置文件。
其次可以预览ini配置文件，
查看识别区域的示例。

过程:
# 坐标系旋转导致的安全区错位问题与算法迭代记录
## 问题根因
托盘坐标系 (l, w) 与机械臂坐标系 (x, y) 之间存在旋转（约 45°）。同事直接在 xy 中录制 x_min/x_max/y_min/y_max
作为安全区，这实际上是一个轴对齐包围盒（AABB）。由于旋转，这个 AABB 在托盘上的真实投影是一个倾斜的平行四边形，
四个角会多出或缺失一块区域，导致：
• 安全区边界外扩，把危险区域误判为安全；
• 或边界内缩，把正常抓取点误判为碰撞。
## 算法迭代过程
为生成不越界且覆盖完整的 INI 配置（仅支持 AABB 格式），经历了以下迭代：
阶段 1：外接 AABB 直接将倾斜四边形的 min/max(x) 和 min/max(y) 作为 [RANGE] 输出。
• 问题：四角越界，AABB 明显大于真实安全区。
阶段 2：最大内接 AABB 在倾斜四边形内部寻找面积最大的轴对齐矩形。
• 问题：覆盖率过低，中间出现大量未覆盖空白，机械臂会误拦截正常点。
阶段 3：均匀网格 + 内接 AABB 将安全区切成 8×8 网格，每个小格子取内接 AABB，再合并相邻矩形。
• 问题：块数过多（128 块），INI 冗长，视觉混乱，且小块之间存在缝隙。
阶段 4：四叉树保守栅格化 + 合并（最终版）
• 从 fragment 的外接矩形开始递归四分；
• 仅当一个 AABB 的四个角全部落在精确边界内部时才保留；
• 递归深度限制为 4，最后合并相邻矩形。
• 结果：块数约 20–40，不越界，覆盖紧凑。

真棒呢。

戒酒32天，圆满完成。
解封啦。

之前对李笑来完全没了解。
后来看了他的一个教程 自学是门手艺
当时我还推荐过很多人看看，私货确实挺多，看的让人很澎湃。

之前22年工作原因，加了一位妙人。

有个他朋友圈习惯，
一个剪切视频，配上三个🤔表情，
让我不由得产生了一些思索。

更好奇他周围领导、同事，有那些想法。

今天还和朋友聊到这个事情。

OpenClaw火爆的原因就是，是把很多原本需要明确确认、需要工程化处理的问题，全都丢给模型去“自己理解”。一句话帮你完成复杂操作。

但实际上是：
把原本需要确认来源、版本、依赖关系、执行路径的一整套流程，全都模糊化了。
最后的结果确实可能是条条大路通罗马，但整个过程和结果都变得非常不稳定。

我最近刚好也折腾了几天类似的东西，体验其实和这个情况挺接近的。

一开始看，确实会觉得很魔法（对经常Ai写代码的摸鱼的我，也还好）：
“只要发一句话，人工智能就能自己去干活，比如生成文档、操作工具。”

但真的用起来之后会发现几个问题。
一是：很多原本应该明确、确定、可追踪的工程流程，现在变成了模型猜测 + 自动执行。
刚提到的 skill 问题，其实就是这样。
同一个名字的 skill，在不同地方可能会有好几个。
有些甚至名字差不多，但功能又不一样，这种情况会更坑，经常会调错工具，我自己就遇到过。

用技术一点的说法，以前至少还能看到依赖关系，现在很多步骤直接被模型吞掉了。
比如我自己在接飞书工具的时候，就遇到过一个很典型的情况：
一开始有一个 飞书聊天工具，后来需要写表格，又接了一个 飞书多维表格工具。
结果发现表格工具又不支持文件上传，于是自己又单独补了一个 上传文件的工具。
最后就变成了三个能力：
飞书聊天、飞书表格、飞书文件上传、名字看起来都叫“飞书”，但实际能力完全不一样、存储位置也不一样。

模型在调用的时候，很容易就混用或者调错。
这种问题本质上不是模型聪不聪明，而是系统结构本身就没有被严格定义。

二是：过度依赖模型本身。
如果模型能力不稳定，那整个系统就会变得非常不稳定。
尤其是我这几天用下来很明显能感觉到：
有些高峰期的时候，模型是会出现“降智”的情况。
同样一套流程：
平时能正常执行，
高峰期就开始各种理解错误。
如果这个时候把太多决策权交给模型，其实就很危险。
因为模型一旦变傻，你就会被拖到同一个水平线上。
最早两天做各种配置，深陷其中，
很多步骤你已经不再理解系统到底在干什么，
只能跟着它的错误一起跑。

三是：现在很多人推崇用对话去“驯化”模型，当然这也是最吸引人的点。

比如：
用聊天教会模型怎么用工具、用聊天建立处理流程workflow、用聊天慢慢形成技能 skill、用聊天让它形成记忆 memory。

听起来很自然，但实际操作起来其实非常费神。

因为对话本身是：
模糊的、不稳定的、不可复现的、还存在幻觉。

今天模型记住了，明天可能就忘了。
哪怕已经生成了 skill，或者写进 memory，
很多行为依然还是依赖模型的临时理解。

所以很多东西表面上看起来已经“配置好了”，但实际上运行起来还是会飘。

所以相比这种方式，我现在反而更倾向另一种思路：
不是简单用 md 写说明，而是像 dify 一样把每个节点拆清楚：

输入是什么
输出是什么
中间调用什么工具

每一步都是明确的。
模型只负责其中一小部分能力，比如：

解析自然语言
整理内容
生成结构化数据

而不是让模型去控制整个流程。

不过话说回来，这一波 AI Agent 的东西也确实有它很有价值的一面。

我自己这几天折腾下来，其实也做出了一个还算顺手的小流程。

比如：
我现在可以直接用对话说：
“记个问题：某某模块在什么情况下会出现什么问题。”

模型会帮我整理内容，然后写进飞书的多维表格里。

基本不用我自己再去手动整理。

像这种 输入 → 整理 → 结构化记录 的场景，效率确实比以前高很多（前提是模型返回快）。

但也正因为自己折腾过一轮，现在反而更明显的一点是：

AI 这东西确实很好用。

但如果系统结构本身不清晰，最后很容易变成一堆“看起来很智能，但其实谁也说不清在干嘛”的东西。

Ps：其实那个表格玩意，没我说的好用，看了下日志。
有工具相关的，调取错接口、各种接口调取（获取接口鉴权、上传文件），哦，还有这些玩意超时重做。
模型识别（真喵喵喵大笨蛋）。
特定时间模型返回慢。
说快了，几条数据一起处理，agent 卡死。
不计其数，最慢15分钟返回，再慢直接卡死不回。