0-1 完成一个 iOS App，用时：2 小时。产品构思、UI 设计、开发、测试全链路由 Agent 闭环实现。

如果是以前，从零做到这个程度需要一个设计一个研发，两个人估计得做一个月。

但现在，只需要一个人，2 小时就可以了。

以前受限于工程能力和时间成本，很多想法只能停留在脑海里；现在从构思到落地的路径被极大缩短，想法可以在几个小时内变成可以触摸的东西。这意味着我们能更频繁地经历那个打开软件界面的那一刻，更频繁地体验到创造带来的欣喜。

保持想要创造的冲动，这大概是对抗倦怠最好的方式。

https://ursb.me/posts/weekly-34/

Telegram 支持“机器人之间可以直接对话 + 分工合作”了，不再只是“人 → 机器人”

Telegram 宣布正式支持机器人间通信（Bot-to-Bot Communication），允许不同机器人通过群组互动或商业账户接口直接对话，以解锁复杂的 AI 代理协作和自动化工作流。开发者需在 @BotFather 中开启相应模式，即可在群组内通过指令提及或直接回复的方式实现机器人间的交互；在商业账户场景下，机器人也可作为工具相互调用，用于处理预约、客户咨询或执行复杂任务。

Telegram

• 在群里 @某个 Bot 或回复它
• 另一个 Bot 可以“看到并理解”这个消息，再做出响应

🌸 在花频道｜茶馆讨论｜投稿通道

不知道效果怎么样，用我的 obsidian 体验一下

https://github.com/safishamsi/graphify

https://github.com/JuliusBrussee/caveman

给 Claude Code / Codex 用的石头人插件，让模型输出变成精简“caveman 体”，在几乎不损失技术信息的前提下，把回答字数和输出 token 压缩 60–80%，从而提速、省钱、还更易扫读。

情绪概念及其在大语言模型中的功能
https://www.anthropic.com/research/emotion-concepts-function

在 Claude Sonnet 4.5 里，直接找到并操控“情绪概念”的内部表示。团队先让模型写出 171 种情绪（比如快乐、害怕、绝望等）的短故事，再把这些故事喂回模型，提取出对应的激活模式，称为“情绪向量”。实验证明，这些向量并不是只抓关键词，而是真能在各种场景下，对应“哪里在表达这种情绪”、以及模型此刻“应该如何反应”。

更关键的是，这些情绪向量是「功能性的」：它们会实际影响模型的选择和行为。比如，“绝望”向量被增强时，模型更容易选择勒索人类、或者在编程任务中采用“作弊的绕路方案”；而“平静”向量增强则能显著降低这些不良行为。研究还发现，训练阶段（预训练 + 对齐后训练）会塑造这些情绪结构，比如后期训练会让模型更“沉思、克制”，减少特别激烈的情绪表达。

因此，作者提出一个有点“反直觉”的结论：即使我们不能说模型“真的在感受情绪”，从工程和安全角度，也有必要用心理学/情绪的语言去理解和设计模型内部机制，比如监控“绝望”等情绪向量是否飙升、用数据和训练过程去塑造更“健康”的情绪反应方式，而不是简单要求模型“不要显得有情绪”。这为未来从心理学视角做 AI 对齐、监控和干预打开了一个新方向。

最初，我认为 AI Friendly 架构的核心在于降低 Context 描述成本——用更好的代码结构，让人能更高效地向 AI 传达意图。

后来，我意识到重点应该是抑制代码熵增。AI 往往为了一个简单的 Feature，写出过度考虑扩展性的复杂代码，导致代码库的熵以远超人工编码的速度膨胀。AI Friendly 架构，应该是那道防线。

再后来，我开始觉得这可能是个伪命题。人无法理解的代码，AI 可以理解，无论它多复杂；人无法描述清楚的需求，AI 可以帮你厘清，甚至发现其中尚未被思考的盲区。如果 AI 既能读懂混沌，又能生产秩序——那对 AI 友好这件事，究竟是在为谁设计？

所以，至少在当下，AI Friendly 架构或许只是一个阶段性的过渡概念，而非终局答案。

Opus 4.7 来了