最新

我是一名程序员，大约有七年经验，但我觉得我比这里很多程序员都差，而且我做的大部分工作都相当简单。我主要负责开发 WPF 和 WinForms 应用程序，这些应用程序充当工业现场基于梯形图系统的用户界面层。<p>由于这项工作的性质，它非常耗时。需要频繁出差去工厂，体力消耗很大，而且相对于投入的精力，薪水也不高。这就是我想成为一名更注重产品导向的程序员的原因。为了朝着这个方向发展，我一直在尝试尽可能积极地使用人工智能。但在我目前的工作中，这很困难，因为工厂的安保通常是封闭的，而且人工智能工具实际上无法在那里连接。<p>我一直在阅读关于提示工程、Harness 风格的文档以及类似的话题。我也使用 OpenClaw，老实说，我觉得我几乎尝试了所有能接触到的东西。我把它与 Obsidian 连接起来，并在工作时记下我认为我的代理需要的知识。<p>尽管如此，十倍生产力的说法对我来说还是有些夸张。我想知道人们实际上是如何提高人工智能的使用水平的，以及他们如何学习底层方法。人工智能周围有太多炒作，很难分辨什么是真的，而且学习这些东西比我预期的要困难。<p>我应该如何正确地学习这个？<p>现在我特别想学习如何管理多代理系统。到目前为止，我构建或尝试过的每一个人工智能多代理框架都失败了。起初，我试图以类似 TDD 的方式控制它，但认真使用过 TDD 的人可能知道我说测试可能变得过于局部化是什么意思。有时架构开始崩溃，然后代理不断地反复修复那些小区域，而 token 成本却不断上升。<p>与此同时，在韩国，有大量关于如果你不使用人工智能，你就会落后的说法。因此，我一直在努力学习它，以免被落下。老实说，自从我开始使用人工智能以来，编程对我来说变得更有趣了。<p>一个原因是编程感觉与英语思维方式紧密相连，这在韩国一直让我感到不自在。即使是编写代码的行为，过去对我来说也感觉很费脑力。但有了人工智能，我可以用韩语思考，仍然可以有效地编写代码。<p>你是否知道当你从头开始编写代码时，最初会感到巨大的疲惫？<p>当我编写一个接口时，我立刻开始看到实现的数量。 当我看到实现时，我开始看到生命周期的冲突。 当我看到生命周期问题时，我开始考虑所有权和处置。 当我考虑所有权时，我开始考虑池化的可能性和重置契约。 当我考虑 DI 时，我开始看到组合根和测试接缝。 当我考虑契约本身时，我开始担心未来的扩展成本。<p>所有这些曾经让编码对我来说感觉非常沉重。<p>但人工智能只是写了一个草稿，而不会陷入所有这些问题，我真的很喜欢拿着那个草稿，并根据我自己的想法来重塑它。<p>我想在这方面更好地使用人工智能。<p>提高这方面的最佳方法是什么，以及如何在不被炒作淹没的情况下跟上有效的趋势？

我这几个月一直在大量使用 Claude Code，并且持续添加了 MCP、技能、钩子和 CLAUDE.md 文件。最近做了一次测量，发现在输入任何消息之前，我消耗了 16000 个 token 的上下文。<p>我为此构建了 unclog 工具来解决这个问题。它会扫描 ~/.claude 目录，显示哪些内容占用了你的上下文窗口，以及占用了多少，然后让你有选择性地删除这些内容。每次更改都是可逆的——它会在修改任何内容之前进行快照。<p><pre><code> uv tool install unclog unclog </code></pre> 欢迎提供反馈——特别是针对比我更复杂设置的边缘情况。

我一直在开发一款安卓应用，当你用手机指向天空时，它可以识别头顶的飞机。这款应用获取实时的 ADS-B 数据，并在相机画面上叠加飞机标签，但把数学计算弄对花了我比预想更长的时间，所以我写下了这篇文章。 这个问题听起来很简单，你有一个天空中的 GPS 坐标，以及你手中的 GPS 坐标。你需要一个像素。但在两者之间有四个不同的坐标空间，它们之间的转换具有隐式失效的符号约定，输出错误但没有错误提示。 流程如下： ``` 大地坐标 (纬度, 经度, 高度) ↓ 平面地球近似 — 有效范围 &lt;100 公里，在 50 海里范围内的误差 &lt;2 像素 ENU — 东，北，上 (米) ↓ 来自安卓 TYPE_ROTATION_VECTOR 传感器的 R⊤ 设备坐标系 (dX, dY, dZ) ↓ 一个符号翻转：Cz = −dZ 相机坐标系 (Cx, Cy, Cz) ↓ 透视除法 + FOV 归一化 屏幕像素 (Xpx, Ypx) ``` 每个转换都难以理解的原因： 大地坐标 → ENU。东方向有一个余弦因子，大多数实现都忽略了它：E = Δλ × (π·RE/180) × cos(φ_user)。子午线向两极收敛，在纬度 25° 时，一度经度的米数比在赤道上少。如果没有它，东西方向的位置在赤道附近看起来是正确的，但随着纬度的增加，会悄悄地发散。 ENU → 设备坐标系。安卓的旋转矩阵 R 将设备轴映射到 ENU 世界轴。要反过来，你需要使用 R⊤。在安卓的行主序 FloatArray(9) 中，这意味着列索引，而不是行索引： ``` R (正向): dX = R[0]·E + R[1]·N + R[2]·U R⊤ (逆向): dX = R[0]·E + R[3]·N + R[6]·U ``` 这会产生完全不同的结果。两者都能编译通过，不会报错。 设备 → 相机坐标系。安卓的传感器定义 +Zd 指向屏幕外朝向你的脸。相机约定要求 +Cz 指向场景内。所以 Cz = −dZ，永远成立。这是纵向模式下唯一需要的修正。 相机 → 屏幕。在透视除法和 FOV 归一化之后，Y 轴翻转：Ypx = (1 − NDCy) × H/2。相机 +Cy 向上；屏幕 y=0 在顶部。如果我们错过了这一点，地平线上方的飞机将出现在屏幕中心下方。 实际捕获的值 (ATR72, 18,000 英尺)： ``` 用户：24.8600°N, 80.9813°E 飞机：24.9321°N, 81.0353°E ENU：E=6,010 米 N=8,014 米 U=5,486 米 方位角 34.2° (北偏东)，仰角 29.5°，距离 11.1 公里 相机坐标系 (在 R⊤ + 符号修正后)：(729, 4692, 10077) 大小：11,140 米 ≈ 11,138 米 (ENU 距离) 屏幕 (1080×1997, θH=66°, θV=50°)：(600 像素, 1 像素) ``` 手机方位角 33.0°，飞机方位角 34.2° → 偏右 1.2°。 手机俯仰角 −4.3°，仰角 29.5° → 向上 33.8°，刚好在视锥体的上边缘内。物理上始终一致。 很乐意回答关于流程的任何阶段或任何其他感兴趣的问题。