不是，人类学的出来走两步

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出现“摆烂”行为时，可以尝试用更具“权威性”的指令，如“住监狱”，观察其反应。