<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>Paweł Dubiel Tech Blog</title>
  <link>https://paweldubiel.com</link>
  <atom:link href="https://paweldubiel.com/zh/rss.xml" rel="self" type="application/rss+xml" />
  <description>A public digital garden about AI, software engineering, books, and learning.</description>
  <language>zh</language>
  <lastBuildDate>Mon, 12 Oct 2026 00:00:00 GMT</lastBuildDate>
<item>
  <title>我把 Amiga 软盘交给了 AI 智能体，一个晚上之后 Pirates! 就在 Unity 里跑起来了</title>
  <link>https://paweldubiel.com/zh/notes/42he%E2%81%9D%20Port%20Pirates!%20z%20Amigi%20do%20Unity%20sprawdzony%20na%20oryginalnym%20kodzie%2068000</link>
  <guid>https://paweldubiel.com/zh/notes/42he%E2%81%9D%20Port%20Pirates!%20z%20Amigi%20do%20Unity%20sprawdzony%20na%20oryginalnym%20kodzie%2068000</guid>
  <pubDate>Mon, 12 Oct 2026 00:00:00 GMT</pubDate>
  <description>我把 1990 年 Amiga 版 Sid Meier&apos;s Pirates! 的四张软盘镜像交给一个编码智能体，请它把游戏移植到 Unity。干活的是 Claude Code 里的 Claude Opus 5.5。一个晚上之后，游戏已经可以从标题画面一路玩下去：决斗、城镇、在地图上航行，直到海战，用的都是原版的图像和声音。比速度更重要的是结果的检验方式：同一套决策脚本分别在 C 移植版和运行于处理器模拟器中的原始机器码上执行。在 802</description>
</item>
<item>
  <title>Overfitting</title>
  <link>https://paweldubiel.com/zh/notes/42hc%E2%81%9D%20Overfitting</link>
  <guid>https://paweldubiel.com/zh/notes/42hc%E2%81%9D%20Overfitting</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>你经营着一个冰淇淋摊。10 天里，你在账本上记下了中午的气温和卖出的冰淇淋球数。你想把这些记录变成一条规则：明天预计 24°C，该准备多少冰淇淋？ 最简单的规则是一条直线：“每高一度，就多卖几个球”。在这篇笔记的例子里，它在记下的这些天上的典型误差是 27.5 个球，因为它看不到最热的时候销量反而下降。于是可以给规则更多的自由，允许曲线拐弯。试过的曲线中最灵活的那条，恰好穿过全部 10 个点。它在账本里这些天上的误差是 0。 这看起来是</description>
</item>
<item>
  <title>METR 时间跨度变长，并不意味着任务按比例变难</title>
  <link>https://paweldubiel.com/zh/notes/42ha%E2%81%9D%20D%C5%82u%C5%BCszy%20horyzont%20METR%20nie%20oznacza%20proporcjonalnie%20trudniejszych%20zada%C5%84</link>
  <guid>https://paweldubiel.com/zh/notes/42ha%E2%81%9D%20D%C5%82u%C5%BCszy%20horyzont%20METR%20nie%20oznacza%20proporcjonalnie%20trudniejszych%20zada%C5%84</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>一个团队想弄清楚，能不能把更长的编程任务交给智能体的下一个版本。于是他们比较基准测试的结果，而这些结果是用人类完成这项工作所需的时间来描述的。这样的结果很容易被当成一种提示：现在已经可以把多少工作交给智能体了。 不过，这种解读需要先检验一点：人类工作的时间更长，是否真的意味着任务对 AI 也相应地更难。如果在某个区间里，各项任务对智能体的难度相近，那么它的成功率稍有提高，结果就可能跨过一大段分钟数。 这时，在挑选智能体时我们还需要一项额</description>
</item>
<item>
  <title>Time horizon</title>
  <link>https://paweldubiel.com/zh/notes/42ha1%E2%81%9D%20Time%20horizon</link>
  <guid>https://paweldubiel.com/zh/notes/42ha1%E2%81%9D%20Time%20horizon</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>在智能体评估中， Time horizon 描述的是智能体达到选定成功率水平时所对应的任务长度。长度用人类所需的时间来衡量，而不是 AI 的运行时间。 以 50% 的版本为例：我们收集智能体在人类耗时各不相同的任务上成功和失败的尝试，拟合出一条成功几率曲线，再读出它与 50% 相交处的时间。这是针对某一耗时的任务分布所作的预测；它并不表示其中每一项任务被完成的几率都相同。 METR：定义与方法 horizons/ 。 一个教学示例：如果</description>
</item>
<item>
  <title>Item response theory</title>
  <link>https://paweldubiel.com/zh/notes/42ha2%E2%81%9D%20Item%20response%20theory</link>
  <guid>https://paweldubiel.com/zh/notes/42ha2%E2%81%9D%20Item%20response%20theory</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>Item response theory IRT 是一类方法，它根据对各个任务的作答，同时估计作答者的能力和任务的难度。在 AI 评估中，作答者是智能体，而作答可以是一次完整尝试的成功或失败。 假设两个智能体解同样的三项任务。第一个通常能完成 A 和 B，第二个还能完成 C。单看成功的百分比，可以得到一个排名。IRT 还试图进一步估计 C 相对于其余任务有多难，以及多大的能力差异能够解释这样的作答模式。这是一个教学示例；这么小的表格不足</description>
</item>
<item>
  <title>Elastic Weight Consolidation</title>
  <link>https://paweldubiel.com/zh/notes/42hd%E2%81%9D%20Elastic%20Weight%20Consolidation</link>
  <guid>https://paweldubiel.com/zh/notes/42hd%E2%81%9D%20Elastic%20Weight%20Consolidation</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>一个模型负责把客户的提问分派给“配送”和“退货”两个部门。现在它要学会识别投诉，可旧的消息已经不允许再保存了。所以学习时没法回放它们。旧任务留下的唯一东西就是模型本身：在早先的训练中调好的数以百万计的数字，称为权重。 可以不加任何限制地让模型学习投诉。那样，权重会朝着对新任务有利的方向移动，其中也包括识别配送和退货所依赖的那些权重。也可以对每一处改动施以同样的惩罚，但那样模型会死死守住旧的设置，新东西学不好。我们需要回答的问题是： 哪些</description>
</item>
<item>
  <title>Reservoir Sampling</title>
  <link>https://paweldubiel.com/zh/notes/42hb%E2%81%9D%20Reservoir%20Sampling</link>
  <guid>https://paweldubiel.com/zh/notes/42hb%E2%81%9D%20Reservoir%20Sampling</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>一个客服模型在一条接一条到来的消息上学习。你想留下其中几条供以后回放，但记忆里只有四个位置。你也不知道还会来多少条消息：二十条，还是两百万条。 留下最先的四条？那样记忆只认识开头。永远保留最后四条？那样它只认识结尾。公平地“从全体中抽四条”，则需要把所有消息都存下来，或者事先知道消息的数量。问题是： 在位置数量固定、数据流长度未知的情况下，怎样让每条消息都有同样的机会？ Reservoir Sampling 是一种在对数据的一次遍历中维</description>
</item>
<item>
  <title>Experience Replay</title>
  <link>https://paweldubiel.com/zh/notes/42gz%E2%81%9D%20Experience%20Replay</link>
  <guid>https://paweldubiel.com/zh/notes/42gz%E2%81%9D%20Experience%20Replay</guid>
  <pubDate>Sun, 11 Oct 2026 00:00:00 GMT</pubDate>
  <description>模型已经学会把客户的提问分派给“配送”和“退货”两个部门。现在你要继续训练它识别投诉，比如“商品送到时已经损坏”。如果在接下来的练习里它只看到投诉，那么对从前熟悉的“包裹在哪里？”，它可能会处理得更差。完整的旧存档已经无法取得。那么，能不能至少回头用上留存下来的几条消息呢？ Experience Replay ER 的做法是保存一部分早先的样本，并在训练中重新使用它们。在简单的版本里，我们往一批新数据中掺入来自记忆的样本，这块记忆称为 </description>
</item>
<item>
  <title>Continual Learning</title>
  <link>https://paweldubiel.com/zh/notes/42gy%E2%81%9D%20Continual%20Learning</link>
  <guid>https://paweldubiel.com/zh/notes/42gy%E2%81%9D%20Continual%20Learning</guid>
  <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
  <description>一个模型负责把客户消息分派给“订单”和“退货”两个部门。它认得出“我的包裹在哪里？”这样的消息。现在公司新设了投诉部门。你用有关商品损坏的消息继续训练模型。投诉分派得越来越准，可一部分询问配送的消息也开始落到新部门去了。如果只检查投诉，就会产生进步的错觉。 你需要的是 教模型学会新的东西，同时保住原有的能力 。这正是 Continual Learning 的目标：在依次到来的数据或任务上学习，并顾及模型此前已经学会的内容。这个名称指的是</description>
</item>
<item>
  <title>SemiAnalysis 比较 AI 订阅的用量限额</title>
  <link>https://paweldubiel.com/zh/notes/42gx%E2%81%9D%20SemiAnalysis%20por%C3%B3wnuje%20limity%20abonament%C3%B3w%20AI</link>
  <guid>https://paweldubiel.com/zh/notes/42gx%E2%81%9D%20SemiAnalysis%20por%C3%B3wnuje%20limity%20abonament%C3%B3w%20AI</guid>
  <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
  <description>SemiAnalysis 在 2026 年 10 月 5 日的分析 subscriptions offer 5x 中比较了各家 AI 订阅的实际限额。作者考察了不同类型的 token 会让用量指示器走多少，再把可用的额度折算成通过 API 完成同样用量所需的费用。 按照他们的测量，在所假定的智能体工作 token 比例下，搭配 Opus 5.5 的 Claude 按 API 价目表计算所提供的价值，大约是所比较的、搭配 GPT 6.1 </description>
</item>
</channel>
</rss>