Claude Code 复杂任务拆解效率太低
- 内容介绍
- 文章标签
- 相关推荐
需求：接入websocket，并且完成分布式websocket的功能，使用redis的pub/sub功能进行connection的转发。
理论上来说需求不复杂，实现过程一波N折。
- git worktree 多级嵌套问题。cc会嵌套多层，导致目录结构乱了。
- superpowers虽然已经对需求进行了拆分，但是tdd的模式导致开发效率太低了，而且本身模型就是公益站，可能不太稳定，经常就断连了。然后retry 10次。
- 虽然任务进行了拆分，但是cc不会分段提交，内容太多，tdd太多，中间很大部分时间ai都已经魔怔了。我也看不到效果，虽然他在输出，我也看不到实际内容。
- 老生常谈的一个问题，需要yes、yes、yes的确认机制，既然是agent 并行开发，我目前看到的好像–dangerously-skip-permissions。没试过
总结还是会有这些问题，cursor之类的软件确实还是存在即合理。目前还不算深度使用cc，都已经很心累。截止到现在这个需求还在tdd，review。 my god please，已经3 days。
深度使用CC的大佬，有没有一些实用的经验。交流一下
--【壹】--：
- 中转≠纯血表现
- 官订并不需要一直yes yes
总结cc+中转就是这样
--【贰】--：
答案是：A\的模型能力相比于发布时大幅降低，工具的因素占比很小
--【叁】--：
cc上用tdd会会做着做着就乱来，这方面gpt还是挺好的规规矩矩的做完全套
--【肆】--：
我感觉也是，我又换回 opencode， 还想把 superpowers 关掉了，但是为啥 codex 装上 superpowers 还很快呢
--【伍】--：
整些有的没的 一看模型 用的是对头家的 GPT-5.4
--【陆】--：
superpowers这类工作流，tdd其实是一个很好的通过软件工程手段保证自动化工作质量的机制。
你要是觉得一直yes yes yes很繁琐，其实完全可以提前构思好你的需求，通过文档的形式一次性提供给模型。避免多次交互带来的繁琐交互，也省token。
要自动化的话，dangerously-skip-permissions我觉得是没办法不用的。
Romic:
内容太多，tdd太多，中间很大部分时间ai都已经魔怔了
这个我觉得可能更多是上下文工程的问题，考虑一下你的上下文大小，上下文太大了模型的输出质量就会下降。该手动拆给新的session得手动拆。如果你的任务流程很复杂，你可以在plan阶段就让模型按阶段输出多个文件，然后开不同的session去管理每个阶段的开发。
当然，最近A社的模型体验也确实不如一开始好了。
worktree确实是一个问题，特别是它不主动清理。每次我都得手动清理。
Romic:
而且本身模型就是公益站，可能不太稳定，经常就断连了。然后retry 10次
这个无解的，三色图.jpg。
不过最近付费的也没那么稳定了，不管国内国外。还是算力不够，用的人多
Romic:
cursor之类的软件确实还是存在即合理
佬友可以详细说说cursor吗 有挺长一段时间没用了。想听听你说的它的好处。
--【柒】--：
用sp我一般是先头脑风暴出需求文档，之后是生成需求计划，最后执行计划，没有用worktree和tdd，太繁琐了，之前用那个worktree它都不会自动清理删除的，还要我手动去删
--【捌】--：
superpowers,ccw,allincc,bmad那些感觉都有点重了，还是要自己根据实际的开发场景先写每个阶段的skill，然后再串起来更接地气
--【玖】--：
我也是基本一样的问题，那个配置我不敢打开，还是手动yes
--【拾】--：
感谢老哥的认真回复。RESPECT
cursor不用一直 yes。 然后毕竟是窗口，如果是简单的修改bug，cursor直接拖拽文件@即可。
其次可以自定义rule。 claude 还不知道怎么处理。
上下文窗口原计划是使用planning for file，但是还没理清楚怎么和superpowers结合。
dangerously-skip-permissions 太有争议了，可以多花一点时间去观察agent的工作，也不愿直接放权。
但是对于质量来说，superpowers的头脑风暴和任务拆分，高级程序员的水平。所以花时间是合理的，
如果能解决一直yes的情况，体验会更好。
例子：
方案设计上的需要我决策，执行层面 比如git diff、 cd xxx，从一开始权限其实已经在当前目录下。
目前就做了2个任务：
- 分布式websocket在业务中实现。*但是和业务太耦合，后续其他项目集成又要重新cp一次，懂得都懂）
- 抽成spring-boot-start-websocket，方便其他项目后续集成
功能完成了，还没测试，如果有需要知道的结果的，可以follow一下。后续同步出来。
--【拾壹】--：
确实，我只用了superpowers。复杂任务拆分 还行，就是强制tdd等 老慢了。 不过优势在于 我们测试是不是可以直接不用测，跑过测试案例直接 一路绿灯
--【拾贰】--：
你用的哪个模型？公益站掺水了吗？这些东西说白了和模型能力直接挂钩的
--【拾叁】--：
tdd不太了解，一直yes这个就用你提到的那个参数就可以
--【拾肆】--：
b0a0601f3503e8d49fd61a7929803409726×840 132 KB
这个流程试试呢我测了一下还可以
--【拾伍】--：
superpowers用的还不是太熟，组件相关功能我还是偏向tdd 如果是业务功能代码，代码审查一下基本逻辑即可，不需要tdd。
--【拾陆】--：
实际上算是tdd开发模式的弊端吧，因为每个功能都需要写单元测试的案例，然后还需要 不停的去 yes yes yes，效率会很低。
--【拾柒】--：
你连 dangerously-skip-permissions 都没用过吗？那你这个问题提出来可能没有什么说服力了。虽然我也觉得 Claude Code 现在处理复杂任务的能力并没有那么厉害
需求：接入websocket，并且完成分布式websocket的功能，使用redis的pub/sub功能进行connection的转发。
理论上来说需求不复杂，实现过程一波N折。
- git worktree 多级嵌套问题。cc会嵌套多层，导致目录结构乱了。
- superpowers虽然已经对需求进行了拆分，但是tdd的模式导致开发效率太低了，而且本身模型就是公益站，可能不太稳定，经常就断连了。然后retry 10次。
- 虽然任务进行了拆分，但是cc不会分段提交，内容太多，tdd太多，中间很大部分时间ai都已经魔怔了。我也看不到效果，虽然他在输出，我也看不到实际内容。
- 老生常谈的一个问题，需要yes、yes、yes的确认机制，既然是agent 并行开发，我目前看到的好像–dangerously-skip-permissions。没试过
总结还是会有这些问题，cursor之类的软件确实还是存在即合理。目前还不算深度使用cc，都已经很心累。截止到现在这个需求还在tdd，review。 my god please，已经3 days。
深度使用CC的大佬，有没有一些实用的经验。交流一下
--【壹】--：
- 中转≠纯血表现
- 官订并不需要一直yes yes
总结cc+中转就是这样
--【贰】--：
答案是：A\的模型能力相比于发布时大幅降低，工具的因素占比很小
--【叁】--：
cc上用tdd会会做着做着就乱来，这方面gpt还是挺好的规规矩矩的做完全套
--【肆】--：
我感觉也是，我又换回 opencode， 还想把 superpowers 关掉了，但是为啥 codex 装上 superpowers 还很快呢
--【伍】--：
整些有的没的 一看模型 用的是对头家的 GPT-5.4
--【陆】--：
superpowers这类工作流，tdd其实是一个很好的通过软件工程手段保证自动化工作质量的机制。
你要是觉得一直yes yes yes很繁琐，其实完全可以提前构思好你的需求，通过文档的形式一次性提供给模型。避免多次交互带来的繁琐交互，也省token。
要自动化的话，dangerously-skip-permissions我觉得是没办法不用的。
Romic:
内容太多，tdd太多，中间很大部分时间ai都已经魔怔了
这个我觉得可能更多是上下文工程的问题，考虑一下你的上下文大小，上下文太大了模型的输出质量就会下降。该手动拆给新的session得手动拆。如果你的任务流程很复杂，你可以在plan阶段就让模型按阶段输出多个文件，然后开不同的session去管理每个阶段的开发。
当然，最近A社的模型体验也确实不如一开始好了。
worktree确实是一个问题，特别是它不主动清理。每次我都得手动清理。
Romic:
而且本身模型就是公益站，可能不太稳定，经常就断连了。然后retry 10次
这个无解的，三色图.jpg。
不过最近付费的也没那么稳定了，不管国内国外。还是算力不够，用的人多
Romic:
cursor之类的软件确实还是存在即合理
佬友可以详细说说cursor吗 有挺长一段时间没用了。想听听你说的它的好处。
--【柒】--：
用sp我一般是先头脑风暴出需求文档，之后是生成需求计划，最后执行计划，没有用worktree和tdd，太繁琐了，之前用那个worktree它都不会自动清理删除的，还要我手动去删
--【捌】--：
superpowers,ccw,allincc,bmad那些感觉都有点重了，还是要自己根据实际的开发场景先写每个阶段的skill，然后再串起来更接地气
--【玖】--：
我也是基本一样的问题，那个配置我不敢打开，还是手动yes
--【拾】--：
感谢老哥的认真回复。RESPECT
cursor不用一直 yes。 然后毕竟是窗口，如果是简单的修改bug，cursor直接拖拽文件@即可。
其次可以自定义rule。 claude 还不知道怎么处理。
上下文窗口原计划是使用planning for file，但是还没理清楚怎么和superpowers结合。
dangerously-skip-permissions 太有争议了，可以多花一点时间去观察agent的工作，也不愿直接放权。
但是对于质量来说，superpowers的头脑风暴和任务拆分，高级程序员的水平。所以花时间是合理的，
如果能解决一直yes的情况，体验会更好。
例子：
方案设计上的需要我决策，执行层面 比如git diff、 cd xxx，从一开始权限其实已经在当前目录下。
目前就做了2个任务：
- 分布式websocket在业务中实现。*但是和业务太耦合，后续其他项目集成又要重新cp一次，懂得都懂）
- 抽成spring-boot-start-websocket，方便其他项目后续集成
功能完成了，还没测试，如果有需要知道的结果的，可以follow一下。后续同步出来。
--【拾壹】--：
确实，我只用了superpowers。复杂任务拆分 还行，就是强制tdd等 老慢了。 不过优势在于 我们测试是不是可以直接不用测，跑过测试案例直接 一路绿灯
--【拾贰】--：
你用的哪个模型？公益站掺水了吗？这些东西说白了和模型能力直接挂钩的
--【拾叁】--：
tdd不太了解，一直yes这个就用你提到的那个参数就可以
--【拾肆】--：
b0a0601f3503e8d49fd61a7929803409726×840 132 KB
这个流程试试呢我测了一下还可以
--【拾伍】--：
superpowers用的还不是太熟，组件相关功能我还是偏向tdd 如果是业务功能代码，代码审查一下基本逻辑即可，不需要tdd。
--【拾陆】--：
实际上算是tdd开发模式的弊端吧，因为每个功能都需要写单元测试的案例，然后还需要 不停的去 yes yes yes，效率会很低。
--【拾柒】--：
你连 dangerously-skip-permissions 都没用过吗？那你这个问题提出来可能没有什么说服力了。虽然我也觉得 Claude Code 现在处理复杂任务的能力并没有那么厉害