@menfrexu 理论如此，但应该就是客户端的缺陷。

@Shrink9 是啊，非常不理解，这么基础的功能为什么一直不管不修复，官方也不说明。哎

@aicodingsh 并不是，主 Agent 调用一个 edit 工具去改的代码，还不是 bash 里改的，依然无法回滚

@JZen
通过数数字测试，确实在实时听我说的话，但是我一说话就打断了。


另外我看网上的视频，他们 chatgpt 的男声非常逼真的真人声，带点方言的感觉，我这里的听着都是很老外的中文发音。也不知道他们是选的哪个音色，

@wumulaozu 嗯 是有价值的

@wha582 其实也可以，但还是那句话，飞书有着不可替代的生态优势，某个群里的几轮对话直接转发到我的开发任务群里就自动变成了一个任务，某个邮件，某些附件，这些都是只有在你的团队 IM 里才能做到的

@HENQIGUAI 按说不至于，我网络应该挺好的

@WilliamColton 我怎么测都不行，他刚开口就被我下一句话打断了

我个人经历下遇到两个现象
1 ，各种 ai 的 code 加强或集成产品，最终还是回到 codex 和 claude 原生。可能是因为订阅制走官方最安心，也可能是因为更想要去信任 top 公司的设计。
2 ，开发中其实每天都是大量碎片化的任务要一个一个去串行完成，虽然 worktree 可以并行开发，但很多任务的文件重叠度很高，函数复用度，和逻辑依赖都很高，还是串行开发最好，但是每个开发任务里在模型干活的时候大脑不禁又想到很多事情于是又会产生很多 todo 。所以一直想要通过看板产品去管理 todo ，在飞书上折腾了一圈，最后我却回归了创建了一个话题群，一个任务就是一个话题，这真的是最最方便和高效的管理模式。

因为在我的场景里，任务管理的最大痛点根本不是任务的状态流转，如果有人同意我希望可以回复我一句+1 ，这是一个我一直以来很大的误区！！！！！
大量 todo 管理的核心都在状态上，但对我来说最重要的反而是内容编辑，话题群反而是最高效的，我可以随时给一个话题 append 新内容或者编辑已有内容，飞书对话里富文本，附件，对话引用什么都能贴。每个完成的任务我就给话题标记一个 done 的 emoji 。

这件事让我思考了很多，我觉得给了我很多做产品的启发
1 ，入口是王道
2 ，用户的使用方式永远是选择最便捷和朴素的方法
3 ，用户使用一个功能的方式往往是突破产品设计初衷的，
4 ，设计者觉得很难用的东西却有可能是用户喜欢的东西，反之亦然

为什么我也是 live 模型 但是无法做到全双工 依然只能一人一句 互相抢话

再问大家一个问题哦，
我从来没用过 codex 和 claude 的 goal 模式，这个收益如何啊，大家都用在什么情况下。

@lihanst 哦哦 我 codex 用的不多，这个还真不知道，请问是怎么去让 codex 去完成一次对抗审查，然后自动完成 BUG 修复。

@kingfire 跨 AI 或者人工去做对抗式审查主要是对开发者心力上的消耗问题，如果人工去做这种事情，必然会把你拉入对结果审查的情境，对结果不信任的困境，一旦人参与进去，会产生大量的心力消耗，会变得很容易疲惫。人的心力/精神也是有额度的，也得科学管理啊

@kuhung 就是开启 xhigh+workflow 模式，然后他一般都会完成任务后做一次对抗式审查。 或者你主动切换到 ultracode 模式下和 AI 说做一次对抗式审查也可以

@weixind
@zuosiruan 我是为了使用 workflow 的能力去做对抗式审查，因为他真的每次都查出来一些 bug 去修复，虽然我也没细看这些 bug 是不是真的有必要修。

分享一下经历呗，哈哈。

对每个号被封的原因的猜测，
都做了哪些尝试

我觉得大家说的都很贴合实际情况，我在帖子里 append 了我的一些新的想法，欢迎大家讨论哈。

@bitmin 是的，我也是有这感受，可以去完全为了自己的业务系统深度打造一个内部支撑平台，这种感受真的很好。但无疑也打击了 2b 行业。


@jjx 你说的对，严格说只是 ERP 一个小的子集，但未来可能也会开始面对各种问题再去迭代产品，买一个成熟产品的好处就是别人替你提前解决了你未来要面对的需求与问题。


@chengran630 @liuxh7 是这样的，传统 2b 的商业模式和产品涉及很难去切入中小企业这种一上来没有这么多复杂需求的公司。



@seven777 我 append 的观点里也有提到，有些用户需求表达不清楚是因为他对行业不熟，他的表达必然是片面的局部思考的。越是行业内深耕的人，越容易无法理解用户，他的思考模式受大量经验影响，已经很难去理解一个普通人的脑子里在想什么了。人如此，产品也是如此，我觉得这也正是一些 2b 产品的困境，难以向前兼容。

@qeeshaw 哈哈，这事水还是挺深的

@osilinka 你说得是对的，其实我自己原本也不想做。不过好在只服务公司自身业务，当下需求小，数据量也少，后期要么我们自研 erp 跟着需求一起迭代，要么随着业务增长再做替换吧。 这些就后面再看了。

@lujiaosama
@DIO
我们的 erp 毕竟只服务于我们自己的产品，需求不会一上来就那么爆炸，满足当下场景就好了，后期慢慢迭代。

是的哈，自己是老板自己做，反而效率高，真加个人进来我感觉摩擦会更大，反而各种掣肘

@yoyoluck 这还挺逗哈哈