2025年，AI记忆研究迎来了一个关键转折点。

Turing Post整理了8份关于AI记忆的重磅资源，涵盖了从理论框架到系统实现的完整图景。这份清单值得每一位关注AI发展的人收藏。| 帖子

核心资源包括：
- Memory in the Age of AI Agents
- Pinecone创始人Edo Liberty访谈：When Will We Give AI True Memory?
- Memories AI联合创始人访谈：Why AI Intelligence is Nothing Without Visual Memory
- From Human Memory to AI Memory: A Survey on Memory Mechanisms in the Era of LLMs
- Rethinking Memory in AI: Taxonomy, Operations, Topics, and Future Directions
- Cognitive Memory in LLMs
- MemOS: A Memory OS for AI System
- MemEvolve: Meta-Evolution of Agent Memory Systems

讨论中涌现出几个深刻洞见：

第一，记忆正在从被动存储转变为主动系统层。它不再是功能特性，而是基础设施。正如有人指出：没有结构化记忆（情景记忆、潜在记忆、操作记忆），AI智能体只能是反应式系统。真正的飞跃不在于模型规模，而在于经验如何被存储、压缩和复用。

第二，统一的分类体系是关键突破。你无法在没有命名问题空间的情况下开始构建。这些研究完成了命名工作，真正的建设才能开始。

第三，无状态执行是架构死胡同。没有记忆，每次交互都是冷启动；有了记忆，才能实现复合智能的时间积累。一位开发者分享：他的智能体运行时保持完整会话状态——过去的邮件、信息流历史、用户模式，这才是让AI从基础任务走向复杂问题解决的关键。

第四，现在的核心问题已经不是如何存储，而是如何决定什么应该积累、什么应该遗忘。

当然也有冷静的声音提醒：在为这些进展欢呼之前，我们必须审慎评估这些洞见如何转化为实际应用。如果不解决伦理问题，不确保记忆系统是增强而非操纵人类体验，我们可能只是在增加复杂性，而非实现真正的进步。

2026年，混合方案（向量数据库+结构化记忆）很可能成为主流。记忆，正在成为AI智能体的真正分水岭。

Vibe Coding：一份写给所有人的实践指南 | #指南 | 帖子

过去二十年，想做软件就得学编程。花几年时间啃框架、凌晨三点debug、反复怀疑人生——这是入场的代价。

但有些东西悄然改变了。

Andrej Karpathy（塑造了特斯拉AI的人）发了条推文："有一种新的编程方式，我称之为'vibe coding'——你完全沉浸在感觉中，拥抱指数级增长，忘掉代码的存在。"

从想法到产品之间的壁垒正在坍塌。不是理论上的，是现在，是今天。你描述想要什么，AI就能写出代码。一天能做完过去需要几周的事。

这不是炒作，这是现实。理解如何使用它，你就领先了99%的人。

通用提示词的时代结束了，上下文工程正在成为新的王者。

Anthropic、OpenAI、Google的工程师们写提示词的方式和普通人完全不同——他们不是在"写提示词"，而是在"构建上下文"。

这个转变的本质是什么？不再问"如何写出更好的提示词"，而是问"什么是驱动理想输出的最小高信号上下文"。

此处是8种专业级的上下文构建方法：见评论区 | 原贴

Jarrod Watts最近公开了他的"氛围编程"工作流：OpenCode + Oh My OpenCode插件。这套方案的核心思路是让不同AI模型各司其职，发挥各自所长。

具体分工如下：

Opus 4.5担任总指挥，负责任务拆解和调度。GPT 5.2专攻架构设计和代码审查，这类需要长时间深度思考的任务正是OpenAI模型的强项。Sonnet 4.5负责文档查阅，在上下文效率上表现出色。Grok Code用于快速探索代码库。Gemini 3 Pro处理前端UI/UX工作，Jarrod特别提到它在设计任务上明显优于Claude。Gemini 3 Flash则负责文档撰写和文件分析这类轻量级任务。

这套方案有几个值得关注的优势：

第一是token使用更智能。上传图片、读取文档、从GitHub加载代码这些操作不会消耗昂贵的Opus 4.5额度，而是交给更适合的模型处理。

第二是工作流更流畅。不同模型在同一终端内协作，不需要在多个工具间来回切换。

关于成本问题，Jarrod提到可以直接使用现有的Claude Code订阅或ChatGPT Plus账号进行认证，不一定需要单独购买API额度。对于已经订阅这些服务的开发者来说，额外成本很低。

不过也有用户提出质疑：这种多智能体架构是否真的比单一模型更有效？还是只是看起来很忙、很酷？Jarrod坦言确实有"新鲜感加成"的因素，但他之前就习惯在Cursor中用Opus处理逻辑、用Gemini处理设计，现在只是把这个流程整合得更顺畅了。

对于编程新手，Jarrod的建议是先用Cursor的Composer模式。更进阶的用法是先用Opus 4.5在计划模式下制定方案，再交给Composer执行。

整套配置大约需要5-10分钟。感兴趣的可以看看OpenCode（opencode.ai）和Oh My OpenCode插件 | github

让不同模型做各自擅长的事，这个思路本身就很有价值。工具在进化，工作流也该跟着进化。

@piracy9 此群组要变私密群组了，垃圾广告号太他么多了，受不了了。虽然有建bot的bot，奈何人懒不想折腾。谁想进的就进，以后还开不开放，没准儿

晚上封群

补充：加入了比较棒的bot，暂不封群了

如有误伤，找 @ashbur_bot