Ren

@Ryrenz · 2026-08-30

🩺 Warp 官方刚刚开源了一个 skill-doctor，给你的 AI 编程 agent 做一次体检，直接告诉你它平时在哪儿浪费时间、哪些 skill 该改。 平时用 agent 干活，最难受的是那种说不清的别扭：明明一件小事，它绕了七八步才做完，改出来的代码你还得回头擦屁股。你隐约觉得是自己 skill 写得不对，但具体错在哪、该改哪一句，只能拍脑袋。 skill-doctor 干的就是这件事。它翻你本地最近 45 天、最多 12 个会话，按效率和代码质量两套标准逐个打分，代码质量看不出证据的会话直接不计入平均，最后按效率 50%、代码质量 35%、技能覆盖率 15% 算一个总分。跑完扔给你一个自包含的 HTML 报告，打开就能看到分数、问题排名，还有针对你现有 skill 的具体修改建议。 最舒服的是它的分寸：所有拟议的改动都写进临时报告目录，不碰你原来的 skill 文件，看完觉得有道理再自己动手。 以前是我们盯着 AI 写的代码，现在轮到 AI 回头盯我们配的 skill 了。 GitHub：https://github.com/warpdotdev/common-skills

meng shao

@shao__meng · 2026-09-01

12 个值得关注的 Agent Skills Grok 系统性研究了 300 多个 GitHub Skills 开源仓库后，筛出了 12 个对其个人配置影响最大的 Skills，咱们按用途把它分为四类。 # 写作去 AI 味（3 个） 1. /humanizer（@blader） https://github.com/blader/humanizer 让写作和改写听起来像人写的。定位是通用"人性化"改写器，偏整体语感。 2. /unslop（@poteto） https://github.com/cursor/plugins/tree/main/pstack/skills/unslop 这是三者中规则最具体、最工程化的一个。它维护一份约 30 条的"AI 腔黑名单"，比如：滥用破折号、强行凑三点排比、"not just X, but Y" 句式、空洞的收尾（"The future looks bright"）、谄媚开场（"Great question!"）、堆砌抽象名词（landscape、tapestry、paradigm）等。它的独到之处是不只做减法——它明确指出"把模式删干净只是完成一半，无菌无个性的文字同样一眼假"，所以还要求改写后加入观点、变化句长、保留适度的"不完美"。 3. /no-ai-slop（@petergyang） https://github.com/petergyang/no-ai-slop 目标与 unslop 重叠，强调"精确、明确像人写的"。Peter Yang 是产品领域的知名作者，这个 skill 更偏产品/内容写作场景。 # 工程流程与纪律（4 个） 4. /agent-skills（@addyosmani） https://github.com/addyosmani/agent-skills Addy Osmani 出品的"生产级工程技能"合集。帖子强调的点是"agent 在动手写规格之前先采访你"——即强制 agent 在需求模糊时先提问澄清，而不是自行脑补假设。这是对抗"AI 自作主张"的经典手段。 5. /superpowers（Jesse Vincent / obra） https://github.com/obra/superpowers 一套完整的 agentic 开发方法论框架：调试时不许猜（必须先复现、定位根因）、强制遵循专业工作流（先写测试、分阶段验证、代码评审等）。核心理念是把资深工程师的职业习惯固化成 agent 无法跳过的流程。适合想让 agent"像正规军而不是野路子"工作的人。 6. /gstack（@garrytan） https://github.com/garrytan/gstack Garry Tan（Y Combinator CEO）公开的自己的完整 Claude Code 配置：23 个有明确立场的工具，分别扮演 CEO、设计师、工程经理、发布经理、文档工程师、QA 等角色。帖子提到的关键价值是"spec、review、QA 剧本，让 agent 无法悄悄改代码"——即通过流程约束保证 agent 的每一步改动都可见、可审。它的意义更多在于"一个高强度使用者的实战配置参考"，而不是通用框架。 7. /impeccable（@pbakaus） https://github.com/pbakaus/impeccable Paul Bakaus（前 Google，现做 AI 工具）的作品，自称"让 AI 更懂设计的设计语言"。用 61 条规则驱动"检测 → 修复 → 复查"的循环，主要面向 UI/设计质量。和纯提示词不同，它试图把设计审美编码成可检查的规则。 # 设计品味（2 个） 8. /skills（@MengTo） https://github.com/MengTo/Skills Meng To 是 Design+Code 创始人，设计教育领域的名人。这套 skills 的目标是让 agent 产出设计系统级别的 UI，而不是"能跑但丑"的界面。 9. /skills（@emilkowalski） https://github.com/emilkowalski/skills Emil Kowalski 是业界公认的顶级设计工程师（前 Linear、Vercel 相关圈子，以动效细节闻名）。能经受真实 audit 的设计与动效技能——他的价值在于把"细节品味"（缓动曲线、间距、微交互）这种最难言传的东西写成规则。 # 认知与研究（3 个） 10. /skills（@mattpocockuk） https://github.com/mattpocock/skills Matt Pocock 是 TypeScript 教育领域的头部作者。他的 skills 套件是"S 级工程与生产力"，覆盖日常工程实践，适合作为通用底子。 11. /cartographer（@KingBootoshi） https://github.com/kingbootoshi/cartographer 一个思路很清晰的工具：在 agent 开始干活之前，先用并行子 agent 给整个代码库画一张地图（架构、模块关系、关键文件）。解决的是 agent 在大型陌生仓库里"瞎逛"、改错地方的常见问题，思路很实用。 12. /last30days（@mvanhorn） https://github.com/mvanhorn/last30days-skill 深度研究类 skill：针对任何话题，跨 Reddit、X、YouTube、Hacker News、Polymarket 等平台检索最近 30 天的讨论。价值在于对抗模型知识截止日和"只看官方文档"的偏差——很多时候真实经验在社群里，而不在文档里。

川处安

@leoshen0 · 2026-09-03

看了下评论区发现，很多人现在对 Skill 还是有很严重的误解，认为 Skill 无非就是一堆 prompt 的组合，其实不是这样的，纯 prompt 只是 Skill 用法之一，更大的价值是在重塑 AI 和外部环境交互的方式，从 MCP 这样常驻上下文改为渐进式披露，减少上下文的开销，可以参考之前写的一篇博客 https://shens.blog/posts/202603/mcp-skill-cli/

Viking

@vikingmute · 2026-09-03

这个 show-me 的 skill 真的不错 https://github.com/humanlayer/skills/blob/main/plugins/show-me/skills/show-me/SKILL.md 觉得非常实用，让 AI 在解释技术问题时，优先画出来给你看，而不是堆一大段文字。 而且它会根据问题选择用合适的图来表达，不是炫技画大图，用可以说明问题的最小图，这些图让 AI 总结一下： 伪代码：解释算法、业务逻辑。 Call Tree：解释函数调用链、runtime control flow。 Component Tree：解释 React/UI 组件结构。 File Tree：解释项目目录、模块职责和重构方案。 Mermaid 图：解释组件交互、时序、数据流。 Diff：特别适合改之前 → 改之后。 HTML 可视化：问题比较复杂的时候，甚至可以直接生成一个独立 HTML infographic / diagram / 小型 slide deck。 我在项目中试了一下去看 AI 写的代码，很清晰，推荐一下。

小墨同学

@xiaomovps · 2026-08-30

Claude Code、Codex、DeepSeek Harness 和 Pi，看起来都在做 Agent，但走的其实是四条完全不同的路。 以前我也喜欢比较谁写代码更强，但最近坚持研究 Pi，我越觉得真正应该在意的：它想替用户决定多少东西，又愿意把多少控制权交给你。 1、Claude Code：越来越像一个完整的 Agent 产品 Claude Code 现在已经把 Plan、Sub-agent、Hooks、Skills、MCP、插件这些东西基本都补齐了，甚至已经可以从 CLI、IDE、Web、Mobile 不同入口去使用。 它给我的感觉就是，Anthropic 已经替你把大部分正确答案选好了。 你不需要研究太多 Harness，拿起来就能干活，而且整个 Claude 生态配合得非常顺。 如果只是问我哪个最适合直接工作，我可能还是会优先想到它。 2、Codex：更像一个被严格管起来的工程师 Codex 给我印象最深的反而不是某个功能，而是 Sandbox、Approval、Network Policy 这些东西。 它一直在解决一个很现实的问题：Agent 权限越来越大以后，怎么让它可以大胆干活，但又不至于真的把机器干废。 包括现在的自动 Review，本质上甚至是再安排一个 Agent，专门判断另外一个 Agent 这一步能不能执行。 所以我觉得 Codex 的方向很明显： 不仅要让 Agent 会干活，还要让它在一个可控的边界里面干活。 3、DeepSeek Harness：目前最像一个大型实验场 它现在的口号非常直接： Everything is a Plugin。 Plan、Sub-agent、模型、Tool、Session，包括很多核心能力都在往插件化方向拆，甚至工具调用本身还分 Native Mode 和 Code Mode。 而且现在已经可以接 DeepSeek、Anthropic、OpenAI、自定义 Provider，并不是只能跑 DeepSeek。 但是它目前仍然处于 Developer Preview，官方自己都明确提醒会有 Breaking Changes。 所以我更愿意把它理解成一个正在快速进化的 Agent 架构实验，而不是一个已经完全稳定的成品。 4、Pi：四个里面最像“什么都不替你决定”的那个 Pi 默认甚至连 Sub-agent、Plan Mode、Sandbox 这些很多人认为 Agent 应该有的东西都不愿意往 Core 里面塞。 需要什么就 Extension，想给 Agent 一套工作流程就 Skill，再复杂一点就直接打成 Package。 这种方式最大的好处就是轻，Context 很干净，而且你几乎可以一直往里面改。 其实这些Agent我一路折腾下来，最开始想得也很简单：哪个 Agent 更强、哪个模型写代码更好，我就用哪个。 但是工具用得越多，我反而越开始关心同一个模型为什么换个 Harness 表现就不一样，Context 怎么组织，Tool 为什么这样设计，哪些能力应该进 Core，哪些应该留给插件。 到这里以后，我研究的已经不只是“哪个工具更好用”，而是在慢慢形成自己对 Agent 的判断。 可能真正有意思的，不是选出最强 Agent，而是慢慢理解一个好 Agent 到底应该怎么被设计出来。

RiverAi7z

@RiverAi7z · 2026-08-27

分享一下我是怎么用 Herdr 的： Herdr 对我最大的价值，是让不同模型可以互相发送消息。 我会同时开 Grok、Claude Opus、Codex 等 Agent，让它们分别给方案，再互相评审一轮，最后让主模型汇总收敛。 相当于从减少了我在AI 之间复制粘贴，变成让 AI 自己讨论。 效果非常好。

lifcc

@mylifcc · 2026-08-30

用以下Agents.md可以缓解GPT-5.6 Sol的过度设计和测试。我在做一个更细致但更重的方案，做好之后发出来。 ## Design simplicity (anti-over-engineering) Over-engineering is the most frequent correction in this workspace. These are hard defaults and they apply INSIDE the requested scope, not just to adjacent changes: - No backward compatibility, migration shims, legacy fallbacks, or old-data backfill unless the user explicitly asks for them. Assume breaking changes are acceptable by default. - Words like 完美 / 长远 / 通用 / 一定不能影响 / "perfect" / "long-term" describe quality goals, not authorization to platformize. Implement only what the current stated requirement needs; mention future extensions as one-line notes in the final message, never as extra code, schemas, tiers, modes, or config surfaces. - Do not mechanize judgment: no hardcoded validators, closed error-code sets, alias tables, or rule engines to enforce what instructions and review already cover. - Validate once at the trusted boundary. Do not duplicate the same check across layers (double probes, dual bookkeeping that must be reconciled). - Design-size checkpoint: before writing code, if the plan adds a new abstraction layer, a new config surface, more than ~5 new files, or any speculative option, present the minimal version and the additions as separate items and default to the minimal version. - VibeGuard's error-handling strictness (U-17/U-29) applies to real error paths inside the requested change; it never justifies adding new validators, checks, or compatibility layers. - When the user says something is over-designed: cut it, do not defend it. ## Problem framing and tool choice - Before the first tool call, identify the exact target, failure direction,and requested access path. - The user's latest correction overrides earlier assumptions immediately. - When the user specifies SSH, CLI, API, or another access path, use that path. Do not substitute UI automation unless the requested path is unavailable. - Do not use Computer Use, desktop UI automation, screen control, or synthetic clicks/keystrokes unless the user explicitly requests Computer Use or UI operation for the current task. The presence of a running desktop app, an available Computer Use tool, or a potentially useful signed-in session is not authorization. - Diagnose the named system first. Do not inspect or modify adjacent tools merely because they could plausibly cause the symptom. - For troubleshooting, establish evidence before mutation. Make one minimal change, verify the original symptom, then stop when it passes. - If the target or direction is genuinely ambiguous, ask one short clarification question before operating external systems.

Yuepan Chao

@smallnest · 2026-08-31

如果你不能外包你的理解，你咋掌控AI写的那一大坨代码? 使用 /understand skill 去理解代码

sunmer

@sunmer575399 · 2026-09-01

我愿称之为AI界的天花板，codegraph，63.1k star真不是白给的 1️⃣ 给代码库建知识图谱，AI读代码前先把结构摸透，回答问题时不用翻遍整个仓库。我自己跑了下，Claude Code理解项目速度肉眼可见地快了。 2️⃣ 代码一改图谱自动同步，不用手动重建索引...这玩意儿最骚的是，大改文件后增量更新秒级完成，不用等半天重新扫描。 3️⃣ 实测token消耗能砍掉三到四成，工具调用次数也少了一截...装完插进Cursor和Codex就能用，本地跑不传代码。 开源协议宽松，商用也没问题，感兴趣的试试。 这项目背后逻辑其实挺狠的——作者应该是把AI coding的上下文管理思路整个重做了一遍，等于把"每次问答都重新读代码"变成了"查预建好的索引" 按63k star的增速，社区里已经有大佬拿它接私活做代码审查工具，一个月多赚几千块。 同类产品里目前没见谁把本地化和同步做这么细的。 你们平时用AI写代码，token烧得最狠的场景是啥？ 🔗 https://github.com/colbymchenry/codegraph #AI #AI工具老炮

WquGuru

@wquguru · 2026-09-02

@dotey 老师给了一个节省Claude消耗的秘诀~/.claude/settings.json中设置 CLAUDE_CODE_DISABLE_1M_CONTEXT=1，禁用 1M 上下文，同时把部分模型会话按 200K 窗口来预算和自动压缩。还有一个几乎很少有人用到，但效果十分显著的技巧：/doctor。 它可以清掉没用的 skills、MCP、识别过长的 CLAUDE.md。我用它两分钟清掉了 10K 常驻垃圾占用。按一天 50 个 Agent Session 算：每天少烧 50 万 token，一个月少烧 1500 万 token。这还没算长上下文带来的反复读文件、延迟 compact、质量变差后的返工。

meng shao

@shao__meng · 2026-09-03

阿里 Zvec 团队开源 zg (zvec-grep) 一个本地优先、面向开发者和 AI Agent 的搜索工具，把语义检索、BM25、混合检索和 ripgrep 精确匹配收进同一个 CLI/MCP 入口，让 Agent 用更少的工具调用和 token 找到散落在本地文件里的信息。 https://github.com/zvec-ai/zvec-grep 要解决的问题 · rg 在目标明确时（函数名、报错、配置项）快且精确，但 Agent 的任务越来越多是自然语言意图：“恢复主题偏好”对应的实现可能叫 hydratePreferences，词面几乎不重叠。 · 纯关键词匹配要么漏，要么放宽后结果爆炸且无相关性排序；Agent 只能反复猜词、多次搜索、逐个读文件拼上下文——工具调用多、耗时长、context 膀胀，还可能基于不完整证据推理。 · zg 的定位：保留 rg 的精确/快速/穷尽，叠加语义发现、相关性排序和上下文组织。 设计与实现 · 四种检索一体：语义 / BM25 / 混合（RRF 融合去重排序）/ rg，覆盖“开放探索 → 相关性收敛 → 精确验证”全程，Agent 可按线索充足程度直接跳到任一阶段，不是固定流水线。 · 结构感知抽取：按代码符号、文档章节切成可独立寻址的信息单元，保留路径和位置；默认返回紧凑排序结果 + 有限预览，按需再加载全文。 · 本地优先：扫描、抽取、Embedding、索引、检索全部在设备端完成；内置 11 个本地 Embedding 模型，默认 local/potion-code-16m-v2（16M 参数静态模型，约 32 MiB，无需 GPU），Django 仓库 3457 文件在 M4 Pro 上索引 <30s；远程 Embedding 需显式授权才启用。 · 零配置接入：zg install 自动发现 Codex、Claude Code、Cursor、OpenCode 并配置 MCP；CLI 与 MCP 共享同一本地索引。 · 支持 macOS / Linux / Windows；索引嵌入式存储（Zvec），无需独立数据库服务；支持增量更新。 官方评测数据 配对 A/B，同一 Agent/模型/提示词，基线用 Agent 原生工具，zg 组仅加预建索引 + MCP 工具 + 使用指引： · SWE-QA-Bench（20 题代码仓库问答）：工具调用减少 >50%，输入 token 减少约 50%，Judge 得分 +1.50。 · BrowseComp-Plus（80 题深度研究）：准确率 98.67% → 99.00%，输入 token −37.56%，工具调用 −43.52%，Agent 耗时 −38.58%。 产品路线图 图搜索与更多结构化信号、查询规划/重排/可解释性；PDF/Word/PPT、图片 OCR 与版面抽取；进一步压缩上下文；优化本地模型与资源占用，探索 iOS/Android 等受限环境。

Erwin

@ErwinWu000 · 2026-09-01

关于 AI 做代码审查，我还想补充一个很多人没注意到的坑 AI 极其容易掉入局部陷阱。很多时候我们让 AI 审代码，它一上来就默认你的框架和方案是对的，只会在你的方案里去找安全漏洞或者小修小补 但对大多数开发者（尤其是新手）来说，最关键的是审查这个方案本身选得对不对。你可能用 A 方案修修补补折腾了半天，换成 B 方案这些问题根本就不会存在 另一个烦人的点是 AI 的挤牙膏审查。你让他审一遍，改完问题再让他审，他又能挑出新问题。说明他不是一次性从底层原理出发把根源解决掉，而是在那里硬找问题、刷存在感 为了避免这两个问题，我总结了一个Prompt，评论区看看👇

Kenton Varda

@KentonVarda · 2026-08-27

In all seriousness: Sol is great at reviews. Most of the problems it surfaces are actually legit, and things I wouldn't have found myself. Note that you have to repeatedly start new contexts and have it re-review; if you just ask it to look again from the same context, it'll only tell you if the things it flagged before are now fixed. New context finds new problems. Eventually though, you get to diminishing returns and can end the loop. It is still important that a human is evaluating each finding and deciding whether it's worth fixing and providing opinions about the right way to fix. Note that I do not let Sol implement the fixes, or write any code, because its code is... not great. I use Fable to write code, or Opus for easier tasks or when I'm not allowed to use Fable. But when Fable reviews its own code (even from a fresh context) it finds far fewer problems than Sol does. So it's a Fable-Sol loop...

卡颂

@kasong2048 · 2026-09-01

这是个很有洞察的观点，我想提出些不同的观点： AI Coding 能力已经很强了，很多 Review 出来的 bug 并不是由于编码失误产生的，而是因为「需求没有完全对齐，AI 必须脑补完整需求，导致实现与需求产生偏差」 “架构缺陷”这种重大问题的根源是「没有对齐需求」，所以解决办法应该是从「需求对齐侧」下手，而不是带着偏差进入实现，再靠 Review 来发现偏差 Review 的作用更多是「宏观上对齐了需求，但是遗落了细节，Review 发现了这些细节偏差」

XiaoLei Liu

@leo_xiaolei · 2026-09-04

吹嘘牛逼的 Skill 千篇一律 真正厉害的 Skill 万里挑一 /show-me 是一个高度符合我认知的 Skill 强烈推荐大家一试 非广

LinearUncle

@LinearUncle · 2026-09-01

卧槽，Chrome 插件也能全自动 UI 测试了！ Agent 开发 → 安装 → 测试一条龙！ 装上 chrome-dev-tools-mcp，内置 5 个 Chrome Extension 工具，再配上截屏和点击，全自动 UI 测试直接跑通。 https://github.com/ChromeDevTools/chrome-devtools-mcp

Viking

@vikingmute · 2026-09-01

Vercel 这篇 《How our agents build on-brand pages with design.md》 非常好 https://vercel.com/blog/how-our-agents-build-on-brand-pages-with-design-md 文章说的是 他们如何用一份公开的 design.md 让各种 coding agent 在任何场景下也能做出看起来像 Vercel 自己设计的页面，比如 pdf，报告，一次性活动页等等。 通过不断进化 design.md，公开 css 文件，然后不断的评测迭代升级前两个文件。 这里不仅仅是 design.md, 还有一个公开的 css 文件，把 header、表格、数据条、图表等做成有限 有文档的 class/token。agent 只在 HTML 里用这些名字 不再自己发明字号、间距、布局。样式表在浏览器里加载 不进模型上下文，我觉得这个创新挺有意思 后面还有 Build your own 的教程，教你怎样从头开始打造一套这个系统，很实用。 截图是文章中用之前和之后的对比。

Yifan Xu

@yifanxu_ephai · 2026-09-01

大家好，LayerFS v0.1.0 已正式开源 🎉 LayerFS 是面向多智能体工作负载的内容寻址文件系统存储引擎：基于 SQLite 保存共享的不可变历史，通过 CAS、CDC、COW 和零拷贝分支，让每个 Agent 都能快速创建隔离的临时 Workspace，并按工具调用记录变更；有价值的状态可以 Commit、Fork、回滚、复用，适合并行开发、RL/MCTS rollout、环境工程和 RSI 实验。 目前项目仍处于实验阶段，欢迎大家体验、反馈问题、提交 Issue 和 PR 🙏 如果你觉得这个方向有价值，麻烦帮忙支持一下： 在 X 上点赞、转发、关注： https://x.com/yifanxu_ephai 在 GitHub 点 Star、提交 Issue 或参与贡献： https://github.com/Ephemeral-AI-Lab/layerfs 每一个 Star、反馈和 PR，都会帮助 LayerFS 更快成为适合 Agent 运行时的基础设施。感谢大家支持！🚀

LanLance

@LanLance24 · 2026-09-02

半年前 Agent 爆发的三月我在公司内分享过一次《Harness Engineering》，八月初又分享了《我把 Claude Code 换成 Pi》。三月给 AI 加约束，八月给 AI 减约束，再到今天看其实 AI Coding 的实践已经稳定下来了。 https://x.com/i/article/2095142015419695106

Amto

@XAMTO_AI · 2026-09-04

系统设计面试最怕两件事：没框架，背了也不敢画。 这份笔记把 Alex Xu《System Design Interview》 卷一、卷二拆成 28 章：从单机扩到百万用户，再到限流、短链、信息流、聊天、YouTube、支付、对象存储、证券交易所。 面试题长什么样，设计该怎么开口，都摊开了。 1.5 万星👍，刷题前先把地图看清楚。 传送门https://github.com/liquidslr/system-design-notes

Leo｜LeoLabs.me

@runes_leo · 2026-09-04

我把 X 收藏夹改成了一个会自动消化的 Agent 收件箱。 以后看到值得留的内容，我只负责点一下收藏。 剩下的流程交给 Agent： 1. 定时读取新收藏 2. 去重并判断有没有价值 3. 分配去向：研究、内容、产品、任务，或者无需行动 4. 下游真正产出结果 5. 写下验收回执 6. 显式开启后，自动取消已经处理完成的收藏 7. 重新打开原帖，确认真的取消成功 也就是说，收藏不再等于「以后再看」。 它会直接进入工作流： 收藏一次 → Agent 自动消化 → 变成研究、内容或任务 → 完成后从收件箱清走 这里最重要的安全门是：只有真实产物和验收回执都存在，才能判定处理完成。 抓取失败、数据不完整、原帖身份对不上，都会立即停止并保留收藏，不会拿「空结果」冒充收件箱已经清零。 账号修改默认关闭。自动清零需要先审查自己的处理流程，再显式打开。 Python 开源工具，MIT 许可证，v0.2.0： https://github.com/runesleo/bookmark-digest

程序员Left

@coder_left · 2026-09-01

https://x.com/i/article/2094660924267438080

李国宝

@liguobao2077 · 2026-09-02

秀一下ds-harness-remote插件支持CodeX的样子。干了三天了，终于有点曙光的样子了，尽量今天发个版。 https://dsh.r2049.cn/

GitHubDaily

@GitHub_Daily · 2026-09-04

用 Agent 编程工具写代码越来越顺手，但有个问题，代码提交后，过几天回头看，当时为什么这么改、AI 做了哪些推理，早想不起来了。 偶然看到 Atlas 这个项目，给 AI 编程加上了「源代码管理」的概念，每次提交都能追溯到完整的对话和推理过程。 它会自动记录每个 AI 会话的提示词、工具调用和文件变更，并把这些信息关联到对应的 Git 提交上，形成可查询的检查点。 GitHub：http://github.com/pacifio/atlas 可以同时运行 Claude Code、Codex 等多个 AI 助手，共享同一份记忆。一个助手做的决策，另一个助手下次提问时能直接看到，切换助手不用从头交代背景。 还内置了编辑器、终端、知识库、论文检索等功能，所有数据默认存在本地，不需要注册账号就能用。 如果我们日常重度依赖 AI 写代码，又想让每次修改都留下清晰的来龙去脉，可以试试。