秋田散人(@akitabtc):是的，github issue/pr 其实就是项目的外挂记忆/图书馆，本地一定要配置 gh （github cli，为了本地 agent 高效和 github 通信），如果我来写 coding agent 产品应该会把这东西 cache 进来吃透先来理解整个项目。PR merge 一定要走 squash merge，因为自动合成的 commit message 里会自带 PR/Issue ID，变向成为了注释指针。给 agent 简单通过 git blame 就能索引这个图书馆。

2026.08.31 03:50

是的，github issue/pr 其实就是项目的外挂记忆/图书馆，本地一定要配置 gh （github cli，为了本地 agent 高效和 github 通信），如果我来写 coding agent 产品应该会把这东西 cache 进来吃透先来理解整个项目。PR merge 一定要走 squash merge，因为自动合成的 commit message 里会自带 PR/Issue ID，变向成为了注释指针。给 agent 简单通过 git blame 就能索引这个图书馆。

青十五@mev15_eth

2026.08.31 03:36

参考 @akitabtc 的思路，最近把所有项目的memory都迁移到了各个项目的github里，作为issue记录下来。之前都是直接新启动一个项目就开始蹬，memory越积越多，经常会在memory里记录一些遗留bug、调研过但未实施的方案等等。迁移之后一个好处是正规化了，按开发流程来，解决完之后提pr，merge之后会自动关闭issue，相当于用开发流程保证了记忆的清理机制；再一个是实现了云记忆，因为在多台服务器上做云开发，统一把memory搬到github不会造成记忆割裂；有了云记忆之后，就可以专门搞一台机器配上专门的Claude/Codex订阅做开发自动化，定时扫描issue的优先级和状态，自动进入开发流程，写完代码提pr，最后人工审核review上线