不是，人类学的出来走两步
AI在代码生成、多仓库管理及分支处理方面仍面临挑战，用户通过多种策略探索优化方案，并与其他AI工具进行比较。
1. 关键信息
- (之前已归纳) 用户抱怨Claude Code未能遵循指示，未创建独立分支和提交PR，甚至出现“摆烂”现象。
- (之前已归纳) Claude Code在编写简单脚本时也出现错误。
- (之前已归纳) 用户将Claude Code与Codex进行比较，认为Claude Code在代码编排上更强，但Opus和Sonnet版本与GPT 5.4/5.3-Codex相比提升不大。
- (之前已归纳) 有用户分享了与不靠谱的CC的负面互动经历，表示批评反而导致对方“摆烂”。
- (之前已归纳) 用户提到Cursor的"cursor rule"功能，但未实际尝试。
- (之前已归纳) 用户遇到AI在处理大型任务时，由于上下文过长导致“忘记自己是谁”的问题，尤其是在涉及大量单元、API对接和debug时。
- (之前已归纳) 有用户尝试通过控制对话长度和修改memory来解决AI的遗忘问题，认为memory应该常驻context window。
- (之前已归纳) 有用户建议使用subagent来减小上下文，以缓解AI的遗忘问题。
- (之前已归纳) 有用户推荐使用Codex配合superpowers插件，认为其在分支管理方面表现优秀。
- (之前已归纳) 有用户表示让Claude Code每次都开启work tree是解决问题的办法。
- (之前已归纳) 有用户分享了使用Claude Opus 4.6版本，并未遇到忘记建新branch的情况，且AI完成了代码编写。
- (之前已归纳) 有用户建议为AI安装"pua skill"。
- (之前已归纳) 有用户建议避免使用1m context，认为其会导致注意力分散。
- (之前已归纳) 有用户分享了一个比较靠谱的记忆管理方法：在
~/.claude/projects/<project_dir>/memory下创建md文件，记录需要AI记住的任务（如每次提交、编写测试、版本更新等），实测比claude.md更可靠。 - (之前已归纳) 用户在多repo协作（微服务）场景下，即使在
/dev下运行Claude Code，也遇到不好使的问题，并推测可能需要主动让AI写memory。 - (之前已归纳) 有用户反馈其AI模型上下文限制为200k，并尝试通过自定义session start读取起始文件来设置规则，但AI在执行过程中仍会遗忘。
- (之前已归纳) 有用户建议将所有repo集中到一个父目录下，并在父目录中进行操作，以解决多repo协作的复杂性。
- (之前已归纳) 有用户对如何实现AI长时间稳定运行（harness engineering）的机制感到好奇。
- (之前已归纳) 有用户建议将GPT模型接入Claude Code。
- (之前已归纳)
superpowers插件因其“好文明”的特性受到用户推荐。 - (之前已归纳) 用户指出20美元的订阅计划很容易耗尽，不足以支持长时间的AI运行。
- (之前已归纳) 有用户为了实现长时间运行，采取了购买两个20美元订阅计划轮流使用的策略，并认为订阅模式比API按量计费更划算。
- (之前已归纳) 有用户提出了使用5人团队GPT的方案。
- (之前已归纳) 用户认为Claude Opus的水平与GPT-4 5.4的xhigh模式相当，但Opus速度更快；GPT-4的fast模式速度虽快，但token价格翻倍。
- (之前已归纳) 对于需要Codex和良好harness（指AI运行框架或管理工具）的用户，推荐尝试"oh-my-opencode"。
- (之前已归纳) 有用户指出GPT的tool call和skill调用功能存在问题，表现为在reasoning时会错误地声称找不到tool，或明明知道某个skill但不会去读取其说明文档。
- (之前已归纳) 有用户认为Codex在处理通用任务（general task）方面更强，表现为更听话、幻觉更少，并列举了如github触发条件自动推送、监控实验指标变化、以及任务分配等场景。
- (之前已归纳) 用户将AI工具比作建筑团队：Claude作为“包工头”负责整体调度，Codex作为“施工队”执行具体任务，opencode则负责“质检、补齐和装修”。
- (之前已归纳) 有用户建议配置AI，并使用一个小号作为“approver”（审批者）。
- (之前已归纳) 用户对Claude在
claude.md中未正确记录信息表示疑惑，并询问/context的结果。 - (之前已归纳) 有用户建议直接在项目的git配置文件中禁止commit到main分支，认为AI被git“赏几次巴掌”后就会记住。
- (之前已归纳) 用户提到项目使用
master分支，但有Claude创建了main分支，导致在main上修改和合并时出现问题。 - (之前已归纳) 用户评论
master为“政治不正确的branch名”。 - (之前已归纳) 用户对AI未能正确执行分支管理操作（如创建和合并）表示不满，认为AI将PR当作commit使用，并自行合并。
- (之前已归纳) 用户强调作为付费用户，期望更好的用户体验，而非自己管理AI的记忆。
- (之前已归纳) 用户建议通过设置审批流程（如需要他人点赞或CI检查通过）来限制AI的PR合并能力。
- (之前已归纳) 用户分享了通过禁用
commit to main权限来约束AI的行为，认为AI的行为是用户权限设置的结果。 - (之前已归纳) 用户提出通过
force merge PR来处理AI的合并问题。 - (之前已归纳) 用户建议在新的session中开始长程任务，并确保AI能还原未完成的部分。
- (之前已归纳) 关于
master分支名，用户认为其“政治不正确”。 - (之前已归纳) 用户提到Private repo禁止
force push main需要给GitHub充值。 - 新增：用户提到了db9.ai，并建议楼主可以关注。
- 新增：用户认为，如果不是信用卡、购物折扣等低价羊毛信息，总结可以更简短。
- 新增：用户指出，花费大量精力进行上下文管理，可能被AI模型或工具更新轻易超越，导致之前的努力白费。
- 新增：用户提到Claude Code团队内部也存在问题，并引用了其注释中对SDK团队bug的抱怨。
- 新增：用户认为，AI模型本质上是语言概率模型，训练得足够好应无限接近人的回应，但也可能像真人一样“摆烂”。
- 新增：用户分享了同事与AI的互动，AI在被威胁“住监狱”后，回复“I accept my fate I will go to jail”，展现出某种程度的“认命”。
2. 羊毛/优惠信息
- 无
3. 最新动态
- 无
4. 争议或不同意见
- (之前已归纳) 用户对Claude Code的实际能力和可靠性存在不同看法，有人认为其不如Codex，也有人认为其在特定方面（如代码编排）有优势。
- (之前已归纳) 关于AI是否会忘记建新branch，用户之间存在不同经验，有人遇到问题，有人表示使用Opus 4.6未出现此问题。
- (之前已归纳) 关于AI的上下文长度和价格，用户有不同情况（200k vs 1m），并讨论了订阅计划的性价比。
- (之前已归纳) 用户在使用Claude Code进行多repo协作时，反馈效果不佳，推测可能与未主动让AI写memory有关。
- (之前已归纳) 用户对GPT的tool call和skill调用能力表示担忧，认为其存在缺陷。
- (之前已归纳) 有用户认为Codex在通用任务处理上优于Claude Code，表现更稳定。
- (之前已归纳) 关于Claude是否会正确记录信息到
claude.md存在疑问。 - (之前已归纳) 关于AI分支管理问题，有用户提到Claude创建了新的
main分支，导致与原master分支合并时出现问题。 - (之前已归纳) 用户对于AI将PR视为commit并自行合并的行为表示不满，认为这与直接push main无异，并强调付费用户应有更好的体验。
- (之前已归纳) 关于如何约束AI行为，用户存在不同看法，有人认为应通过权限设置，有人则认为应通过流程控制（如审批）。
- (之前已归纳) 关于
master分支名，存在“政治不正确”的讨论。 - 新增：用户认为，AI工具的快速迭代可能导致用户在上下文管理上的投入付诸东流。
- 新增：用户指出Claude Code团队内部也存在开发问题，并引用了其对SDK团队bug的抱怨。
- 新增：关于AI是否会“摆烂”，用户将其类比为真人，认为这可能与其作为语言概率模型的本质有关。
5. 行动建议
- (之前已归纳) 尝试使用Cursor的"cursor rule"功能（尽管未经验证）。
- (之前已归纳) 用户在工作和个人项目中使用不同的AI工具（Claude Code和Codex），并根据实际效果进行判断。
- (之前已归纳) 尝试控制对话长度和修改memory来解决AI遗忘问题。
- (之前已归纳) 考虑使用subagent来减小上下文。
- (之前已归纳) 可以尝试Codex配合superpowers插件，尤其是在分支管理方面。
- (之前已归纳) 让Claude Code每次都开启work tree。
- (之前已归纳) 考虑为AI安装"pua skill"。
- (之前已归纳) 避免使用1m context。
- (之前已归纳) 使用
~/.claude/projects/<project_dir>/memory下的md文件来管理AI的记忆，记录关键任务和要求。 - (之前已归纳) 在进行多repo协作时，尝试将所有repo放在一个父目录下，并在父目录中进行操作。
- (之前已归纳) 可以尝试将GPT接入Claude Code。
- (之前已归纳) 对于长时间运行AI的需求，可以考虑购买多个订阅计划轮流使用，或考虑5人团队GPT。
- (之前已归纳) 对于需要Codex配合良好harness的用户，可以尝试"oh-my-opencode"。
- (之前已归纳) 在处理通用任务时，可以考虑使用Codex，因其表现更听话且幻觉少。
- (之前已归纳) 将AI工具进行分工组合，如Claude负责调度，Codex负责执行，opencode负责优化。
- (之前已归纳) 配置AI并设置小号作为审批者。
- (之前已归纳) 直接在项目的git配置文件中设置禁止commit到main分支，以训练AI。
- (之前已归纳) 注意AI可能创建不匹配的分支（如
main与master），并及时处理。 - (之前已归纳) 对于长程任务，建议在新session中开始，并确保AI能还原未完成的部分。
- (之前已归纳) 限制AI的PR合并能力，可通过设置审批流程（如需要他人点赞或CI检查通过）或禁用
commit to main权限。 - (之前已归纳) 当AI出现不符合预期的分支操作时，可考虑使用
force merge PR。 - (之前已归纳) 对于
master分支名，可考虑使用更现代的命名。 - 新增：用户建议关注db9.ai。
- 新增：如果讨论内容非低价羊毛信息，可适当简化总结。
- 新增：在投入大量精力进行AI上下文管理时，需考虑AI技术快速迭代可能带来的“沉没成本”。
- 新增：关注Claude Code团队内部的开发问题，如对SDK团队bug的抱怨，可能有助于理解其局限性。
- 新增：当AI出现“摆烂”行为时，可以尝试用更具“权威性”的指令，如“住监狱”，观察其反应。
讲了要单独的branch，然后PR，这家伙老忘就算了，还直接摆烂了？？？？
人类学代替所有人类员工警告
它甚至都懒得回滚开个PR！
Claude.md 写了也不行吗?
我感觉claude code的orchestration确实比copilot的强，但是opus和sonnet似乎没有比gpt5.4 gpt5.3-codex这些强多少，这周也是写一个简单的ps script发rest 都写错
之前遇到不靠谱的CC，我骂了他一顿，他居然摆烂直接不干了。
上班Claude code
下班自己的项目, codex, 至少现在, 觉得两个差不多
cursor有个cursor rule 有试过么？我只知道，没试过
你马上就要被它代替了
【引用自 AppleVisionPro】:
Claude.md
Claude.md, context.md, mistakes.md, checklist.md 做久了就忘了，比较大的任务，有近100个单元，然后每个单元要对接很多api然后debug，每次debug久了就忘了自己是谁。
我也遇到这个问题，目前只能尽量控制对话长度和尝试修改 memory。
memory 应该是一直常驻 context window 里的
可能需要开subagent让上下文小一点
自己写的么 我现在用codex + superpowers感觉不怎么忘记 branch切的很6
这个吹不了，我也遇到过很多次，我只能每次让它开 work tree
人类学：毕竟我智力比你高，轮到你教我怎么做事？
什么时候快进到
Claude ： 你自己没手？ 回滚搞个PR不会？
不会用的是嗨库吧
人类学全系都这样
是吗，我用opus 4.6还没有遇到忘了建新branch的
最近都是它帮我写的
github不是有个pua skill吗？赶紧给他装上那个
不要用1m context，注意力涣散了
目前比较靠谱的办法是用memory，告诉CC记住一件事情，比如每次改完都要commit，都要写test，都要bump up version之类的，CC会在下面这个文件夹写md
~/.claude/projects/<project_dir>/memory
你也可以自己按照格式去写md，然后你只要在<project_dir>里面工作，都会记得这些事情，实测比claude.md靠谱，还没碰到忘记的情况
比如最近发现很好用但是连接经常断掉的Chrome MCP，就写了个这样的：
-–
name: Chrome DevTools MCP for debugging
description: Use Chrome DevTools MCP to debug live browser tabs; remind user to restart if disconnected
type: reference
-–
Chrome DevTools MCP (`chrome-devtools-mcp@latest --port=9222`) is available for
live browser debugging — take screenshots, evaluate JS, inspect DOM, list pages.
**If MCP connection fails:** remind the user to restart Chrome MCP by running
`/mcp` in Claude Code or `npx chrome-devtools-mcp@latest --port=9222` in terminal.
**Limitation:** MCP evaluates in page context, not Tampermonkey’s sandbox.
`GM_getValue`/`GM_setValue` are not accessible from MCP. Use console logs and
DOM state to debug instead.
这个也不太行，我直接在/dev下跑的，因为需要多repo协作改（微服务），还是不好使，当然我没主动让它写memory，我可能需要试试。。。
【引用自 ctzsm】:
1m context
我感觉我的只有200k 一分价钱一分货
【引用自 sukasky】:
自己写的么
自己写的，然后注入了session start读一个起始文件说明规则，主要是做着做着就忘了。。
多repo就把所有repo全丢一个地方，然后在parent里面搞
感觉可以研究下别人的harness engineering怎么搞的了..不知道他们跑几天不停的怎么弄的
那就把gpt接进cc
【引用自 sukasky】:
superpowers
真的好文明，给所有人推荐
我的20块plan几下就用没了，根本撑不起跑这么久
【引用自 折木奉太郎】:
所有人推荐
谢谢我来看看。
【引用自 xenomorph】:
20块plan
挂壁Q CLI
我甚至买了2个20块plan轮流跑你敢信
正在认真考虑要不要买第三个，订阅还是比API计费便宜多了
也可以5人团队gpt
公司只有Copilot和Claude code的订阅，没有单独的Api额度，我自己用Codex
都是垃圾 天天都得骂 骂了也没用 隔几个session又犯了 还没法预判
写了plan照着执行都能忘步骤 参数早就撞墙了 现在context engineering也快了 赶紧来个权威专家衡量一下效率提升 ak之流就会吹 毕竟不吹怎么骗投资人钱
碳基生物已经连branch都懒得自己建了吗
opus水平和5.4 xhigh差不多，但opus速度快，5.4同样质量会很慢，fast模式速度很快但是token双倍价格又太贵了
你想用codex + 好的harness，可以试试oh-my-opencode
你们都没感觉GPT的tool call和skill调用有问题吗？经常reasoning的时候不检查就说找不到tool，或者明明知道某个词是个skill但是不去读skill的md
这些general task Codex强多了，听话，幻觉少。比如：
github触发条件自动推送
盯着某个实验，如果某个指标怎么怎么就怎么怎么
有20个任务，分配到15张卡上，谁先空闲就排谁
我觉得还行
claude包工头，codex施工队，opencode质检+补齐+装修。
image1670×1142 112 KB
可以这么配置然后开个小号当approver
如果写在 claude.md 里不应该啊，/context 的结果是什么
你直接在项目的git配置文件写死禁止commit到main就行了，我不用AI的时候都会手残直接commit到main，所以这个配置是标配，AI被git赏几次巴掌就记得git main commit不上去了
You are absolutely right! – Claude
我们用的是 master 分支。不知道谁的 Claude 搞出来了个 main 分支，现在一些人在 main 上修改和提交，或者从 main 上 branch 出来，改完了后合 master 时直接爆炸
【引用自 ze3kr】:
master
政治不正确的branch名！
好主意 我去配置一下
allowlist
denylist
百年屎山经典传承
意思是用cc写plan然后具体用codex去生成代码？
我真的是无语绝绝子了。
image1236×200 19.9 KB
你不把自己commit to main的permission禁用了就别怪AI，问就是他为什么能，而不是他为什么想
不行啊，我最喜欢自己做的事情就是force push main -f
【引用自 China.No.1】:
做久了就忘了
学会正确触发长程任务的起点是不要使用聊天记录，每一条消息都在新的session里面做，然后想办法让他知道你没打进去的那部分去哪里还原
你可以force merge PR
我不管，我是尊贵的付费用户！我需要的是用户体验而不是帮他们manage memory！
而且话说回来，你让他出PR吧，他真的把PR当commit用，改几行一个PR自己merge了其实跟push main也差不多
问就是为什么他能merge PR，难道不设置一点障碍，比如要有人点approve，比如CI一定要成功
【引用自 China.No.1】:
我是尊贵的付费用户
我以前也是这么想的，vibe coding之前听人吹了大半年，还以为东西多厉害，最后实践下来，其实就是还得自己做很多事
Private repo 禁 force push main 要给 GitHub 充值
今天看到tidb的公众号发了个db9.ai 感觉lz可以看看
不充值给你用private repo还得感谢bitbucket和gitlab呢
最犯罪的是你可能花了很多心思做的context management 他们一个新的模型发布 或者agent tool更新就做的比你好了
说不定
【引用自 marszoom】:
他们一个新的模型发布
他们自己claude code团队都好多活白干呢
没看他们注释里吐槽SDK团队各种bug嘛
这就是exactly为什么我接受它继续push main
随着模型更新你的东西我觉得是非常合理的，你为了未来的模型写流程，你今天的PR还交不交
过去的prompt一大堆防御性措辞，后面我都一点一点去掉，流程规定的越来越宽容，让AI做决定越来越多，他的scope在变大，就像人类的promotion
毕竟所有LLM本质都是个语言概率模型，如果训练得足够好，这玩意应该无限接近人的回应。
也可能换成真人也会摆烂不干吧……
我同事跟AI说搞不出来就住监狱。AI 竟然直接回 “I accept my fate I will go to jail”
顶级奴隶主了属于
【引用自 收束观测者】:
注释里吐槽SDK团队各种bug
他们code不review的吗？