这里有一个问题，为什么要 codex, cc, cursor 一起用？我觉得一般人是直接用更好的淘汰旧的，用了 cc 之后就不会再去用 cursor 了。感觉专注迁移更好点。这个产品让我想起了 09 年那个百谷虎网站，一次搜索可以搜出百度，谷歌，雅虎的结果，可以横向对比。

@jonsmith 啥意思？你是想写代码还是让它做生活助手？如果是写代码那 Hermes openclaw 换啥 model ，加啥 skill 都没用。它俩不是用来写代码的，是生活助手。hermes agent 其实就是更智能化的 openclaw ，具体用起来我感觉没差啊。而且有时候比 openclaw 还慢。不过我也是最近才开始用 hermes ，不好说什么

openclaw 和 hermes agent 他俩就不是拿来写代码的。看效果看起来跟 Claude Code 差别不大，那为啥不直接用 cc 这么成熟的东西。。。。

哎。当然不是了。RAG 都过时了。其实国外有个声音就是 RAG is DEAD 。因为 context engineering 出来之后，大家发现其实逻辑不用放 RAG 里面，也不是每次都要向量搜索。逻辑完全可以放到 context 里面，而且是以一种人类可以阅读的 markdown 方式记录下来。
如果需要跟外部沟通就用 MCP 。
langchain 是最早期的版本。后来出了 langgraph + langsmith 。基本都用 langgraph 了。但是 langgraph 其实也有很多人质疑。因为 claude 源码泄露后，大家发现 claude 根本没用 langgraph 之类的做 ui ，用的是 TAOR ，其实很简单，就是 LLM 回答一遍，然后问自己回答完了吗？还需要调用什么工具？然后重复这个循环就行了。也不用 langgraph 这么复杂。
现在也没什么人用 langgraph 。主要是看起来还是有点抽象。但是我觉得 langgraph 是被低估了，因为简单的 TAOR 有可能会出现无限循环，因为没有特别好的边界控制能力。毕竟 langgraph 再难学，写的也不是你啊。。怕啥。。是 ai 在写。

很多人 vibe code 就是让野生 AI 开始自己乱写。这样只会把自己搞死。

通俗版：
其实 vibe coding 是一个养猫的过程。它是一只猫🐱。一开始它生成一点点代码你就要一行一行的看，单元测试也是一行一行的看，然后把规则加到 CLAUDE.md 里面。你也是一个铲屎官。每天铲它拉出来的屎山代码。
这个过程要持续很久。等养了一段时间之后，它写的代码就可以比较放心了。但是最好也别让他直接推 PR 上去。尽量还是自己看一下。

专业版：
用 Human in the loop 来控制智能体必然会产生的架构偏移，减缓软件熵的增长，从而做出可维护的系统。

你不会就让野生的 AI 直接写把。野生的 ai 写的代码没法用。只会写出一堆屎山代码。
写代码的 ai 是一只猫🐱，你要慢慢的养。每天还要铲它写出来的屎山代码。然后你要教它。
ai 写代码是一个由慢到快的过程。前几天，或者前几周是很慢的。你得让它生成出来之后，再生成单元测试。然后你慢慢的一行一行的读。发现什么问题就让它记录到 CLAUDE.md 里面去作为 Never 段的内容。然后你可以添加 ARCHITECTUR.md 等很多文件，具体看社区版的上下文治理。
养一个月就差不多了。然后它写代码就很快了，你慢慢的就可以不怎么看了。
至于为什么是 CLAUDE.md 而不是 AGENTS.md 。那是因为除了 claude code 以外的都是垃圾，是无法驯服的傻鸟🪿

除了 cc 其他的都别用。cc 回答简短。不知道就说不知道。gpt 那套真扛不住，回答特别长，不懂瞎回答。真的到干活的时候就来回的在一个地方打转。

没问题啊。。

别用 cursor 了，这玩意快死了。还是老一套的想法，程序员写代码，ai 做辅助。现在是 ai 写代码，程序员做辅助。用 cc 就够了，国外都开始流行 黑暗面了 就是 vim + cc 或者你随便打开一个 sublime 或者 zed ，只是你自己看，要改什么全部让 cc 做，自己别敲一个字

确实需要很多 skill 。不过也不需要这么多 skill 。
- requirement skill 梳理需求 和 grillwithdoc skill 。这个有个简单的方法，不用你写 skill 。你让 ai 采访你。不过最终做多了可能还是会有一个 skill
- TDD 是个骗局，你可以写完代码再补单元测试，但是记住用经典派，别用伦敦派
- 单元测试需要 skill 吗？我好像没用，就是在 never 里面写上一些禁忌
- code review 这个最好不要让 AI 做。因为 AI 自己看自己写的代码都很满意。而且低级的错误 AI 不会犯，高级的错误它自己看不出来。所以 code review 自己做
- feature-doc-maintainer 更新文档。这个事情别让 ai 自动。凡是这种有创造性的时候都要你自己参与，ai 辅助，不然它就按照生成 javadoc 的标准给你写文档。写出一个完全没有灵魂的文档



不过光这样不够。如果你全部流程就一个 agent 或者一个 session ，它迟早要上下文爆掉，然后瞎搞。
应该是做多个 agent ，分配不同的 role ，然后让它们协作，需求分析 + 架构师 + 程序员 + 测试
如果跟更复杂就是

需求分析 + 开发组长 + N 个开发 + 测试组长 + N 个测试

这部分的架构就复杂了，还有很多问题。cc 现在也在测试这个 agent team 模式。这个才难

有啊，而且我就不用 cc cli 的。我都用 vscode + cc plugin

你这个问题叫上下文治理。看你用的什么工具了。如果是 codex ，就创建一个 AGENTS.md ，如果是 cc 就创建一个 CLAUDE.md 。
主要内容就是这个项目是干什么的，技术栈是什么，最重要的一段叫 never 。你也可以用中文叫 禁止的事 之类的。这段落自己维护，会越来越长，就是 ai 踩过的坑。如果你的项目大，还有很多文档。你不要都写到 CLAUDE.md 里面，你要渐进式披露。cc 社区自己研发的一套上下文治理是

CLAUDE.md 文件 项目规则、Agent 行为规则 人工
MEMORY.md 文件 长期记忆、长期偏好、长期经验 半自动
NOTES.md 文件 临时工作笔记、scratchpad 人工
DECISIONS.md 文件 关键架构/技术决策历史 人工
ARCHITECTURE.md 文件 系统结构、模块关系、数据流 人工
LEARNINGS.md 文件 踩坑经验、经验总结 半自动
TASKS.md 文件 当前任务列表、待办事项 人工
SESSION.md 文件 当前 session 工作记录 半自动
docs/ 文件夹 长文档上下文来源 人工
memory/ 文件夹 memory 分类存储 半自动
prompts/ 文件夹 prompt 模板、workflow prompt 人工
.cursorrules 文件 Cursor 兼容规则 人工

你可以自己去搜索一下，具体我就不细说了

gpt 聪明过吗？在 cc 面前就是个垃圾

好好学习怎么让 AI 写代码，然后你作为人的价值就是抵抗架构偏移，降低软件熵，编排多 AI 工作流。因为 LLM 的极限在于架构偏移。重构，最佳实践，单元测试，对代码的品味从来没有像现在这么重要