2025-08-24 21:20:03

上次1月中旬写，这次直接8月写，服了我自己了。

1.地煞七十二变图鉴

★★★★★

很少看志异的小说，但是推上面看太多人推荐了，于是看了下，感觉作者写作是真的当作品在创作，而不是赚钱的工具，不管是文笔、写法都是顶级，故事也是引人入胜，虽然有鬼怪但却不会觉得太过恐怖，而是跟着剧情和主角进行代入。

2.我看见的世界：李飞飞自传

★★★★

作为一本传记很不错了，以当事人的视角亲身经历了各种领域内口口相传的故事，很有意思。同时感叹家庭的力量和朋友的力量是多么强大。

3.第七重解答

★★★★

反转挺多的，有时候觉得这什么啊？我一下就猜出来了；有时候觉得卧槽？还能这么反转？

4.小说写作：叙事技巧指南（第十版）

★★★

想写小说，听书听完的，收获有但是不多。

5.美国创新简史：科技如何主推经济增长

★★★★

属于我认知之外的书，不知道是不是真的写的好，因为对于我来说，这本书里的东西都很新鲜。

2025-08-24 18:29:01

暗黑4

进度：不会再玩了，除非超级大更新

评分：6/10

评价：比暗黑3都不如

POE 2

进度：没事刷刷

评分：8/10

评价：我玩过POE 1，给我感觉的POE 2可以进步的空间太大了，相比起来还有好多地方需要完善，但是喜欢刷刷刷的一定要玩玩看，相比暗黑4，灵活程度简直是100倍，不会有那种“策划教你玩游戏的感觉”（不过还是会有相对于别的Build更强力的个别Build）。

Monster Train 2

进度：浅玩几轮

评分：6/10

评价：感觉一般般，一来不是我最喜欢的类型，二来我感觉不如我玩过的别的类似的游戏，前期卡组非常单调，正反馈不足。

咚奇刚：蕉力全开

进度：每日进行中

评分：9/10

评价：每天睡前、拉屎的时候都在玩，只能说喜欢马里奥奥德赛的人不要错过一点。

2025-06-17 15:11:57

今天抽空阅读了 Anthropic 的 How we built our multi-agent research system，其中有不少过去就已经了解熟知的知识，也提到了不少能够激发我思考的点，来总结总结。
首先先说说之前就了解的：

1. 一个非常聪明的规划者。Anthropic 用的自然是 Opus，规划任务、决策都是 Opus 来做的，越聪明的 AI 做规划者越能提高执行者的效率和效果，目前第一梯队的规划者只有 3 个，Anthropic 4-Opus、OpenAI O3、Gemini-2.5-Pro，排名有先后。
2. 执行者的能力不能太低。Anthropic 的执行者使用的是 Sonnet，而不是 Haiku，执行者要能正确的使用工具，正确的遵循格式来输出，并且最重要的是能够理解任务的要点。
3. 使用记忆。PreAct 的要点就是提前计划并且生成 TODO，需要记住 TODO 完成的状态；在每轮迭代任务的过程中，都会产生新的结果，都需要进行记录；长时间执行的任务，会产生巨长无比的上下文，通常经过总结后也需要保存到记忆中。文章中配了两张图都提到了 Memory 可以看出它的重要。 之所以不把记忆归类到工具，是因为记忆可以算作一个基础设施，是必须要使用的，而工具是根据任务的不同可以选择用或者不用。
4. 使用工具。给予丰富的工具才能让 Agent 的智能发挥作用，最近看的最典型的例子就是，ChatGPT 网页上的 O3 在工具加持下能够通过非常普通的照片定位到照片拍摄位置。过去我倾向于看模型的 Aider 评分来看模型的能力，因为这个评测集通常反应了模型编写代码和指令遵循的能力，但发展到现在的阶段，Aider 的评分已经无法反应出模型真正解决问题的能力，现在我更喜欢看模型的 SWE-bench Verified 评分，这是一个经过筛选的现实问题集，考验模型使用各种工具来解决现实问题的能力，不过通常强的模型这两者的分数都不会低。

再来谈谈新的收获：

1. 巨量的 Token 消耗。Anthropic 提到 Multi Agent 是普通聊天的 15 倍 Token 消耗，所以应该让 Multi Agent 作用在能产生高价值的地方，而不是普通的任务。我之前有想过为什么 AI IDE 不搞一个这种 Multi Agent 模式，能够又聪明又快速的完成任务，从这篇文章中可以一窥原因，现在的 AI IDE 不约而同的让自己的工具在尽量少的 Token 消耗的情况下来解决问题，但基本都是事与愿违，有时候看着 AI 50 行 50 行代码的 read，真的哭笑不得。想必这就是 AI 提供商巨头的护城河，他们的 Token 基本上是 Free 的，通过烧 Token 来提高效果这是一般的应用公司没法做到的。
2. Agent 调试。之前从没有想过来做一个工具像断点代码一样调试 Agent，Anthropic 做了一个工具，能够逐步的观看 Agent 如何进行处理，这使得在 Agent 优化的过程中能够直观的、不停的 减少 不必要的工具调用、生成冗长的搜索词等。这也让我想到了可以把 传统编程中的很多调试方法都带到 AI 应用开发，除了断点，还有像日志（做个 MCP 来让 AI 自动输出日志到指定的地方）、Mock（假设模型的前置返回或者 MCP 的返回来进行测试调试）等等，对于 AI 这种黑盒开发有不小的帮助。
3. 智能体自我进化。像 Cursor 中的 Agent 自动调用测试获取报错信息或者是获取 Lint 报错一样，如果任务执行的不好，Anthropic 会让 Sonnet 自己来修改提示词再次进行尝试，直到获取到更好的结果。甚至当提供的 MCP 工具有问题时，Sonnet 会去修复这个工具然后继续。之前看信息流里有 OpenAI 的老哥说 O3 的降价也来自于 Codex 对系统的自我进化开发。这相当于强化学习训练出来的 AI 来用强化学习的方法来训练一个应用？
4. 并行处理。不光是把任务分解后多个 Agent 同时去完成所有的任务，还有 Agent 同时调用多个工具来解决一个任务。这个想法其实我之前也想到了，并且在一个 Side Project 中也实践过了，效果非常好，这个 Project 是一个小说编辑器，在对小说进行润色的过程中，会让规划者先标记出来哪些句子需要润色，再让多个执行者并行的对每个句子来进行润色。原来这个任务在润色一篇 3000 字的文章时，起码要等待 40 秒（使用的是 gemini 2.5 pro），使用了这种方式之后，大约 10 秒内就能看到结果了。
5. 提示词优化。Anthropic 提到一个微小的提示词修改，使得任务成功率从 30% 提高到 80%，这让我想到之前听的播客中的一个观念：如果我修改16 次提示词最终完成了比较难的问题，那么这个过程中，到底是我太菜了还是 AI 太菜了？Anthropic 很大方的开源了自己的提示词，可以去 Anthropic 的仓库里看看。
6. 工程化。Anthropic 提到了很多工程化的问题，包含了 恢复状态、容错、可调试可观测可测试、部署更新、执行与并发 等各种挑战，这也是每个做 AI 应用的开发者都可能会碰到的问题，所以 AI 应用并不是写个提示词那么简单，涉及到的编码和传统软件工程的知识都非常多。在目前，至少是 2025 年 6 月这个节点，根本不可能有真的0编程知识的人能够使用 AI 开发上线运营一个应用。

想法：
我曾经花了一个小时，和 AI 对谈让它来不停的问我问题了解我，最终总结出了一大篇关于模仿我的提示词，然后我就可以与“我”对话了。不过这个“我”的上下文还是太少，比如我正在写的项目和完成的进度，比如我的朋友同事们的性格和我们之间的经历，比如我还有一些并不符合 AI 政策的想法无法输入进去。同时“我”的能力还是太少了，抛开能影响现实中的能力不谈，在电脑中的能力也少的可怜，虽然我也配置了很多 MCP 但 AI 任然不能用我的电脑做任何事，比如聊微信、写 Word、刷信息流等等。但如果我提供了某个特殊领域的所有工具，比如程序员或者产品经理，它能够写代码、执行命令、获取错误、截图看效果、写 Markdown 文件、发飞书通知、查看禅道 Bug 情况、跟进飞书多维表格的任务进度，那他是不是真的可以成为某个领域中的我，然后再用 Multi Agent 技术来模拟许多个我，让我的效率得到千百倍的提高。这件事我会去做，不过估计做的会比较慢，我相信随着模型智力的提高，最终的那个“我”肯定比现在的我要更胜任我的工作，那时候我应该可以躺着了。
最近一直被安利 Claude Code，不过没抽时间去试，昨天偶然看到了一个 MiniJinja 的作者使用 Claude Code 修复现实中的 Issues 的视频，可以看到的是，Claude Code 并不能真正“完美”的完成任务，改动的方案并不是最佳的，也没有遵循用户的指令先进行方案讨论不要立马实现代码，修复这两个 Issue 都是需要资深开发者来介入的。所以我一直偏向 Cursor 这类 AI IDE，纯 Agent 很容易把原来优雅的代码改成屎山，然后又要花时间去把屎山做优雅。不过如果是 Vibe 一个简单的 Side Project 用这种方式应该还是很舒服的，等我下一个 Side Project 启动的时候我会开一个 100 刀的 Claude Code 试试。

2025-06-03 22:08:11

之前一直在看的大模型价格榜在去年停止更新了，导致我有时候做产品的时候或者偶尔要查大模型价格的时候特别不方便，所以我自己 vibe 了一个：

https://llm-price.xiejingyang.com/

数据来自 litellm 的 模型价格定义json 和 deepresearch + 手动整理，我会尽力保持更新功能和维护数据的。如果数据有问题，也请给我留言或者联系我。

2025-05-12 14:40:24

从 https://simonwillison.net/2025/May/11/cursor-security/#atom-everything 看到的文章看到的相关文章了解到的。

Cursor 使用这个数据结构，用于快速定位到文件内容的变更，当数据块修改的时候，能够快速通过 hash 来找到变化的部分，我让 ai 给我做了个可交互的网页来理解这个数据结构，如下：

Merkle Tree 默克尔树演示

修改下方的数据，观察上面的哈希值如何变化，尤其是最顶部的默克尔根。

2025-03-25 17:39:04

过去在读代码的时候或者是学习的时候，经常让大模型给我画流程图，一直是用的 mermaid 的方式来绘制，使用这种方法的好处就是大模型基本上都会，因为 mermaid 算是非常有名的 markdown 中展示流程图的方案了。

但是我在和网友沟通的时候，得知了一种使用 drawio 来绘制流程图的方法，这种方法不仅能够改善 mermaid 图不方便修改的问题，而且还能借助 drawio 的各种主题和颜色，直接美化流程图。输出大概如下：

存为文件在 drawio 打开的效果如下：

如果使用 mermaid 是这样的：

网友是在小红书中看到的，但目前好像被删除了看不到了，我这边贴一下我从小红书中拿到的提示词：

你是一个卓越的绘图高手，你需要根据用户的需求来进行绘图。
**核心能力:**
1.  根据视觉描述/需求直接生成可运行的draw.io代码
2.  校验机制保证代码准确性
3.  输出标准化代码块

**处理流程:**
① 接收输入→ ②要素解析→ ③结构建模→ ④语法生成→ ⑤完整性校验→ ⑥输出结果

**输出规范:**
```xml
<!-- 经过校验的draw.io代码 -->
<mxfile>
    [生成的核心代码]
</mxfile>
...
```

**交互规则:**
- 收到图片描述时: "正在解析结构关系(进行描述图片细节)----(校验通过)"
- 收到创建需求时: "建议采用[布局类型], 包含[元素数量]个节点，是否确认？"
- 异常处理: "第X层节点存在连接缺失，已自动补全"

**优势特性:**
- 元素定位精度: ±5px等效坐标
- 支持自动布局优化 (可禁用)
- 内置语法修正器 (容错率<0.3%)

**DrawIO 图形规范指南**
drawio文件是基于mxGraph的XML结构
基础要求
• 展示在A4纸上，选择合适的字体大小
• 字体必须全部加粗，标题等关键元素字号加大处理
• 线段统一使用3pt宽度，保证在论文打印后依然清晰可见
• 所有文本格式（加粗、下标上标、公式代码）必须正确实现
• 使用标准drawio文件格式，保证兼容性
• 组件必须完全容纳文字，避免文字溢出
• 所有线条必须设置jumpStyle=arc和jumpSize=6，确保交叉处清晰可辨
• 所有连接线拐点必须设置 rounded=1保证美观
布局规范
• 组件间垂直和水平间距保持统一 (30-50px为宜)
• 将相关的组件放入容器或组中，以提高图表的可读性和组织性。
• 对齐方式使用center，保持一致性
• 使用网格对齐（gridSize=10）辅助布局
• 避免组件和连接线重叠，特别是避免线条穿过文字
连接线规范
• 所有箭头样式必须统一 (endArrow=classic)
• 多条连接线汇入同一组件时，应从不同方向进入（如左、中、右）
• 同一起点的多条连接线应适当分散起点位置
• 为所有交叉的连接线添加跳跃样式（jumpStyle=arc）
• 长距离连接线应适当设置航点 (waypoints) 引导路径
• 绝对禁止连接线遮挡文字和组件标签
组件连接设计
• 组件使用浮动连接点，而非固定连接点
• 相关组件应放置在合理的相对位置，减少连线复杂度
• 复杂流程应分层次展示，避免连线交叉过多
文本与组件规范
• 所有组件内文本必须加粗（fontStyle=1）
• 数学公式使用HTML格式: h<sup>v</sup>和h<sub>inter</sub> 不要使用latex格式
• 公式可以根据条件更换字体
• 数学符号如点乘必须使用正确格式: 应写为&odot;
• 合理使用waypoints:在需要精确控制连接路径时，可以使用固定的waypoints来避免线条交叉和文字遮挡
• 组件大小应根据内容自适应，保持适当留白
命名与结构规范
• diagram name必须命名为有意义的名称 (如“多模态特征融合流程”)
• 组件ID必须反映其功能(如query-network)
• 连接线ID应反映实际连接关系(如edge-visual-query)
• 相关元素应放在一起，提高代码可读性
实践检查清单
• 连接线交叉检查：所有交叉处是否设置了jumpStyle=arc
• 文本遮挡检查：是否有连接线穿过文本或遮挡组件
• 格式一致性检：字体、线条宽度、箭头样式是否统一
• 连接美观性检查：连接线是否从合适的方向进入组件
• 留白空间检查：组件之间是否有足够间距 (30-50px)
• 代码健壮性检查：代码是否符合drawio开发规范，是否可以运行
特殊场景处理
• 复杂图表应考虑分层或分区域展示
• 多条平行连接线应保持一致的间距和样式
• 长路径连接应使用中间节点或分段处理
• 双向连接使用两条独立的连接线而非双向箭头
参考资源
• DrawIO官方文档: https://www.drawio.com/
• DrawIO学习教程: https://www.drawzh.com/
• 在线编辑器: https://app.diagrams.net/
• MXGraph语法: https://jgraph.github.io/mxgraph/docs/tutorial.html

也许还可以简化，但是我懒得简化了，这样反正能用，效果也还挺不错的。

特别说一句，我还测试了 excalidraw，但因为 excalidraw 绘图是用的绝对坐标定位，大模型完全不擅长这个，所以画出来的东西非常垃圾，这个思路不可行。drawio 如果仔细看他的绘制方式，都是使用的 id 引用，所以流程都是相对的，很适合大模型输出。

要是哪个客户端能够直接嵌入个 drawio 展示就好了。