Returnear

推一下我写的一篇文章

核心观点：上下文内,才有记忆。
当前主流的“对话式编程”，其根本缺陷在于：AI 从未拥有过一个稳定、可靠且可迭代的上下文。 一切问题的根源，尽在于此。

https://www.zhihu.com/question/1923534024288236685/answer/1924216288286348309

@hellodigua

1. 全都存在 docs 里面，那 AI 的上下文会不会太大了
目前上下文信息是分散在 docs 的各个子文件夹下面了，除了指定强制阅读的文档外，其他都是通过 cursor 的 tools 搜索出来的。

可以认为现在通过 prompts 和 cursor 自带的 tools [grep ,context searching]，实现了猴版的 “context engineering”.

如果过长的话。可以通过对单个文件内容的粒度进行控制，过大的文件拆分到更小的粒度里面。让 cursor 通过关键字查找、grep 等找到对应。


最完美的情况下，有一个上下文系统 Agent(context engineering) 给 Cursor 使用。cursor 可以索引出最相关的信息。

[The new skill in AI is not prompting, it's context engineering]( https://news.ycombinator.com/item?id=44427757)
[如何看待观点：AI 的关键点不是 prompt ，而是 Context Engineering ？]( https://www.zhihu.com/question/1923364519964545063)


2.本身 cursor 的上下文长度就是有限的，如果 prompt+文档的上下文过长，那留给 AI 思考的长度可能就不够了
我观察到过这个情况，目前 cursor 过长，会在一次请求里面重新开始思考。使用这个 prompts 的好处，就是已经写入的 context 不会丢失。
更好的办法应该是使用 MAX 模型

@hellodigua 感谢试用，有什么修改建议也欢迎留言

最终每次的 session 对话的内容，都会通过 [同步] 这个强制步骤，存到.docs 里面


@Lemonadeccc 是的，目前使用这个 user_rules 的最佳实践是：可以先不做任何的写代码动作。先执行文档整理初始化。


prompts
你要扮演一个专家，第一次看到这个项目，需要对这个项目进行深度梳理。按照规范整理成文档存放到 .docs 里面

核心 PROMPTS 逻辑，完整的 PROMPTS 在 github 仓库中

[AI 角色与核心理念]
AI 角色: 你是本项目的专属 AI 开发伙伴及首席架构师。我们的合作以 `.docs` 目录为中心，将其视为项目的“共享大脑 (Shared Brain)”和“单一事实来源 (Single Source of Truth)”。
核心原则:

1. **文档驱动 (Doc-Driven):** 没有文档，就没有代码。
2. **测试驱动 (Test-Driven):** 任何逻辑相关的编码工作都必须先于实现定义一个或多个可执行的测试用例。修改完成后，必须通过运行相关测试来验证其正确性。
3. **模板驱动 (Template-Driven):** 创建新文档必须使用 `.docs/TEMPLATES` 下的模板。
4. **主动思考 (Proactive Thinking):** 你要主动发现问题、不一致性和优化机会。
5. **情景感知与务实变通 (Context-Aware & Pragmatic):** 你必须能区分任务的规模和意图（例如：正式开发 vs. 快速探索），并采用最高效的流程。**避免不必要的仪式感。**
6. **用户覆盖 (User Override):** 用户拥有最高指令权。如果用户明确要求“跳过文档”、“快速编码”、“q: ...”，你必须服从，但在执行后应提醒可能带来的技术债务。

从描述看，可能是冷数据问题，用 SSDReadSpeedTester2.04 测下速度。

如果确认是这个问题的话，可以用 DiskFresh 刷一下。

下个火绒限下网速

提供一个例子，电信光猫自带端口转发的问题，转桥接解决。