@stimw 可以试一下 Cursor ，原因如上

@owen800q Cursor 有目前业内最好的 prompt engineering 和 tool call 设计，它当前还不是 Codex 和 Claude Code 可以碰瓷的。

举例来说的话，比如：

Cursor Rules 是直接被嵌入到首个 User 信息的，而 Claude Code 是把 CLAUDE.md 当成一条 User 信息插入在首个 User 信息之前，Codex 则是在 System Prompt 里提醒 AI 要去读 AGENT.md 。比较来看，当然是 Cursor 的做法更好。

Cursor 会拦截所有的 grep 操作，并且将它转成 grep tool call 并强制加上上下文信息，而 Claude Code 的做法是单独提供 grep 工具并且在 Prompt 里要求 AI 用工具而不是命令行，Codex 的做法是不提供 grep 工具，让 AI 优先用 rg 。

Cursor 会在编辑工具的返回内容里提醒 AI 要使用 read_lints 检查修复所有的 linting 错误，而 Claude Code 和 Codex 都只是在初始 Prompt 里强调要跑 linting 。

并且 Cursor 虽然有 25 tool call 自动停下来的限制，但这比起 Claude Code 经常在莫名其妙的地方写一个 Summary 然后停下来要好得多。

至于 Cursor 的 GPT-5 ，我的体感是 gpt-5-high-fast 比 codex 快，而 gpt-5-high 比 codex 慢，思考时长没啥区别。

@dssxzuxc 确实是这样的。明显感觉用 GPT-5 的时候的思维模式和用 Claude 不一样，它非常容易起疑心，但我觉得这一点在写代码的时候反而是好事情。

Claude 需要用很多重语气词告诉它要去刨根问底，但依然不能避免它看到一个什么类似的东西就经验主义，而 GPT-5 则需要明确告诉它一个合适的调查范围，以及在哪里可以拿到足够的知识。

如果把二者都当成员工的话，我确实会更信任 GPT-5 一点，因为我自己的写码风格也是会一路深挖到底，而不是模仿着抄抄就完事的。

@anivie 我倒是对 a 社那个什么立场表态没啥感想，我对 Claude Opus 4.1 最核心的感想是，它确实比起 GPT-5 有更大的知识和经验储备，但是盲从用户、过度自信和过度设计这些方面确实让人觉得它用起来很不省心，这种沮丧的拉锯战让人很难觉得它的 token 真的值这个价。

@dji38838c 现在从 Claude Max 200 刀切换到了 Pro ，我实际上没有在 Plus 下试用过 codex ，因为我是一直都用最高思考预算的那种，和小模型斗智斗勇属实没啥必要。

@Scarb warp 就算了吧，暗改模型，玩不起就别给这么大额度

@Jack927 干活细不细可以用 cursor rules 约束的，并且 cursor 不拦截你检查 system prompt ，所以你的 cursor rules 可以很花哨，比如直接约定怎么处理<user_query>，看到<outline>应该转去一块块读文件等等。

@musi Claude Code 是在 prompt 层阻止 AI 调用 bash 运行 grep ，然后提供一个带行号的 grep tool ，但是实测这个阻止的成功率并不高。Cursor 会直接拦截 bash grep 一类的指令并且尝试翻译为 tool 调用，如果失败则直接把错误告知 AI 让它滚去用 tool 。

并且 Cursor 无论是 read 工具还是 edit 工具都会返回 linting 信息，Claude Code 则依旧是在 Prompt 上说一句编辑完了记得检查 linting 。

这两个策略区别带来的是很确切的行为差距。

@SignUpWithSolana 纯 CLI 的工具目前还真没见到在 tool 方面做得比 Cursor 好的，你可以尝试让这些工具直接输出单个 tool 调用的结果，并且将结果保存为一个文件。这里面 Cursor 的自带 tool 做得最好，而自带工具又是没办法用 MCP 去彻底替换掉的。

macOS 自己的 gptk 支持 dx12 都多久了，你们还搁这儿每年花俩星期做个功能就薅用户的钱呢

翻页了，不过语境是 AI 的话，那还真是 react 。语境不是 AI 的话，solidjs 是真的非常好用。

实测下来 Claude 对 react 的熟练度几乎是所有语言和框架里最高的，然后才是 vue3 和 solidjs ，前者总是觉得写得不够最优，后者总是会把 tsx 当 react 的 tsx 去写。

@needhourger
所以考察这些实际上也是对实践派到底写过多少复杂代码的考量。

我确实是那种不愿意使用任何我看不懂的东西的人。我觉得这不算什么坏事，甚至于我会觉得代码里出现某种魔法是一个挺让我不安的事情的。

放在前端里，这种习惯会要求我去了解 async await 的 babel 结果，去了解 react 和 vue 的渲染流程，去了解 vite 的打包流程。

放在后端里，这种习惯会要求我去了解请求是怎么经过 router 再到达 handler 的，response 又是怎么一路传递出去的。

我觉得这实际上是个挺好的习惯，因为这种积累可以让我在写代码的时候回避很多隐形的坑，并且在遇到麻烦的问题的时候不至于无从下手。后者尤其关键，因为这种了解会赋予一个模糊的“知道哪里可能是故障点”的直觉，在切换框架和语言的时候也很容易上手。

如果说只会写业务才叫实践派，那其实更是和 AI 没什么区别了，Claude 4 目前写出来的业务代码质量已经很高了。但 AI 目前最缺乏的就是运用它可以复述出来的庞大知识去解决复杂故障的能力，这就是需要人介入的地方。

@zhouyin 这些真的是 mid 级在不包含系统设计的纯技术轮该问的问题，而且是 Python 后端应该会的部分…

而且其实这里面很多问题都真的一点也不过分，甚至你切换一下主力语言的话，这些问题大部分都可以平移过去的。

至于薪酬，国内的 mid 普遍给的都是 30-60 吧，但这不是我司的数据，因为我司并不在国内…

老实说全栈讲不出 immutable 实在是太水了，这真的不八股文了，而且问的也不难…

要我的话，如果你 py 是主语言，我大概会问这些难度的东西：
threadlocal 实现
asyncio 的 task 的线程安全
timezone native 和 pytz 的坑
pydantic 和 dataclass 的行为区别
Annotated 和 annotation
contextvar 为什么是 asyncio 安全的
给一个用 LOAD_FAST 优化的用例
cffi 和 raii
poetry 、pdm 和 uv 的行为区别
WSGI 和 ASGI 的中间件

这才只是面 3-5 年会问到的难度，8 年的 py 技术岗的技术面怕是要连 six 、future 和 past 甚至是 asyncio 发展史和 gevent 都问了

而且上面的全都不八股文，全是我实际用到过的东西

pg ，说实话 my 会死锁这个设计始终非常弱智，但是 pg 的 vacuum 有时候有写入性能和占用空间的坑，上个透明压缩会好很多。

系统目前是 15.1 ，这毛病看来 15.2 也没修。

看了一眼，uptime 71 天，这玩意现在吃 18.8G……

讲道理 snipaste 缺功能确实很头疼…

基本上 amd64 的性能只能达到原生的三分之一到一半，够用是够用的。

另外需要更新到新系统，至少 sonoma 吧，旧版本有一些奇怪的 rosetta bug 。

另外 docker desktop 还是推荐用，比 orbstack/colima/rancher 要好，一个比较突出的点是它设置 swap 很方便，而 rancher 需要在 docker host 上跑命令才行，colima 更麻烦。

还有 docker desktop 是可以在 vm 外修改文件之后触发 vm 内的重打包的，而替代品们都很难实现这一点，这个对于 jetbrains 系这种不完整支持 remote 的 ide 来说很头疼。