请问在 AI Coding 场景适用吗

[timbobo]

请问EverMemos 在 AI Coding 场景表现怎么样，能够根据项目的文档和历史对话，建立用户的编码风格偏好和对项目结构的记忆吗

[freshpomelo]

对于理解项目结构代码风格这种非聊天对话场景，EverMemOS的确暂时还不支持。
不过evermemos支持addon插件机制，也很欢迎社区积极支持各种记忆类型的插件

[summerHearts]

项目的文档，用户的编码风格偏好和对项目结构的记忆可以通过Claude code进行梳理存放在这个系统中，然后在AICode前，优先调用api服务，查询项目历史逻辑信息。用户再结合系统给出信息，进行AI编程。 这样可行吗

[freshpomelo]

这是个好想法，在对话过程中总结这个编程的特点，那可能要注意在LLM回复时带有明确的项目名称或者其他明显区分的信息，比如要求LLM以{"项目名称":"xxx","编码风格":"xxx"}这样的格式输出，然后保存到EvermemOS，方便后面通过API查询。

[ZhenhangTung]

@timbobo @freshpomelo I have a question: what led you to this idea? Is it because current Vibe Coding agents like Cursor and Trae are not able to handle this well yet?

[freshpomelo]

@ZhenhangTung Cursor's context management is currently restricted to one chat thread only and limited tokens. It does not support cross-thread or cross-project context persistence.

[ZhenhangTung]

@freshpomelo Cool! From both a product and technical perspective, Cursor does have this limitation.

It’s also difficult for Cursor to automatically achieve the goals mentioned by @timbobo and @summerHearts from a large codebase. My current workaround is to use Cursor Rules (https://cursor.com/en-US/docs/context/rules). Cursor will automatically read these rules and include them in the context, which works as a form of implicit memory.

There are also community-built memory plugins worth noting, such as: https://github.com/vanzan01/cursor-memory-bank

Vibe Coding is an emerging trend right now. Personally, I’m very curious about the role Memory could play in this ecosystem, and how Memory might eventually find its PMF.

[littleflowercatcat]

Personally, I lean toward putting long-lived knowledge into spec files—things like style, conventions, and explicit rules—and treating conversations as disposable workspaces rather than something that must be remembered.

Given the 200K–250K context limits (and the high cost of 1M), building vibe coding around long-term memory systems like EverMemos feels a bit over-engineered to me.

Curious how others are splitting responsibilities between specs, conversations, and memory in practice.

[ZhenhangTung]

Personally, I lean toward putting long-lived knowledge into spec files—things like style, conventions, and explicit rules—and treating conversations as disposable workspaces rather than something that must be remembered.

Given the 200K–250K context limits (and the high cost of 1M), building vibe coding around long-term memory systems like EverMemos feels a bit over-engineered to me.

Curious how others are splitting responsibilities between specs, conversations, and memory in practice.

I'm also curious too :) Waiting for others' thoughts.

[ZhenhangTung]

Founder another one: https://github.com/thedotmack/claude-mem

[littleflowercatcat]

I believe that memory systems in the vibe coding domain are significantly more complex than those used in ordinary conversations. In these scenarios, interactions consist largely of code snippets and tool invocation logs—essentially resembling a messy and unstructured debugging process. Extracting meaningful knowledge from such data is a major challenge, and determining how to effectively reuse that knowledge after extraction presents another.

For instance, can memories extracted by Claude Code be seamlessly utilized in tools like Codex or OpenCode? While this vision is compelling, the reality is that cross-CLI sharing still primarily relies on generated Markdown documents. Many task orchestration skills produce progress-tracking Markdown files that often evolve alongside Git history. Notable examples include the Droid Mission framework, oh-my-codex, get-shit-done, and HelloAgents, all of which leverage Markdown as a medium for cross-terminal collaboration.

As for the evolution of skills, Hermes Agent appears to be one of the few projects claiming to support this capability—at least from a promotional standpoint. I have also used a paid desktop application called Nowledge Mem, which offers functionality similar to this repository. However, my experience with it was unsatisfactory in daily use, and its practical value fell short of expectations, leading me to abandon it.

I look forward to seeing a truly unified solution that not only fulfills this ambitious vision but also addresses real-world pain points.

[cyfyifanchen]

Closing as part of the EverOS 1.0 issue triage. The repository has been refactored around the 1.0 Markdown + SQLite + LanceDB architecture and current use-case/docs structure. PR #258 documents the migration boundary: #258. If there is a specific 1.0 code or docs change needed, please open a fresh focused issue.

[cyfyifanchen]

Reopening after a stricter post-triage audit. This is a general AI Coding use-case question, not a purely pre-1.0 API/infrastructure issue. It should stay open until we provide a current EverOS 1.0 answer or documentation for this workflow.