@chenyongchanggg 板着脸认真说事情的时候可能会有点过拟合吧…就隐约带一点 AI 味道，但是是真人没毛病嗯

@Jinmu24 没啥求教的，我觉得也不需要上一个 ADR ，在该 Reflection 的点提醒，然后 Reflection 结果持久化，去调优 Reflection 就行了，没啥必要去翻倍 usage 审查，事实上 LLM 对于自己犯的错误非常敏感，这是 RLHF 的核心部分。

狠狠摔一跤就是指，你要让它去犯错和挣扎，而不是要让它去预先怀疑。因为怀疑是普适性的，它会怀疑每一件事，导致任务完成时间拉长，而如果让它对着怀疑去 reflection ，它不会有把 finding 记录下来的东西，你给它套上一个 sidecar LLM 也没用，如果不踩坑，两者大概率都不响，因为 base model bias 摆在那里，两个模型之间会倾向于认同彼此，你要让它响才行。

提高怀疑本身也是很难建立平衡和 metrics 的，而 Reflection 思路则容易很多，很多时候开发任务是需要人来做这个 reasoning 的，任务完成时间是刚需，而提高怀疑的代价清晰，收益不确切，预测收益困难，策略只能是全用上，就像越来越依赖 xhigh 一样。

@Jinmu24 我的评价：

它的驱动力不成立，或者说我的看法相反：我觉得 LLM 应该狠狠摔一跤或者在 HITL 里站直了挨骂，然后它学会的东西会被积累以降低后续的任务完成时间。你的驱动力是抬高怀疑，这增加的额外消耗是普遍的，而错误本身不是。

https://www.v2ex.com/t/1235190

没时间搓 codex 版，但是如果你的 harness 是 Claude Code ，我搓的这东西有时候能救命。

@liupeiqiang 不是这个意思，是说这是经典的 AI 味道，浓到让人觉得会有点“最不绕弯子的太稳了”。

同 Opus 5 主力，Fable 只在编排层，不总是 xhigh 拉满。

目前用量是超过两个 20x 订阅，不总是能超第三个订阅，要看实际工作量。

到了这个用量之后，实际上切号就真的是个麻烦事了，瓶颈在 5h ，切号又不能全自动化，否则会被 A\抓现行。现在是主动把 5h 周期钉住，这样稍微好处理一点。

虽然说我觉得 AI 做前端无可厚非，但是看到“The honest take”的时候还是会皱眉。

ZDR 我目前先不奢望了，只是希望内容真的不要被拿去当作语料，那个卖数据得免费用量的东西别开。

另外，实际上我有一个侧面：我会用会议笔记去长期挂着耳机，开在手机上，然后想到什么就说出来，让会议笔记帮我收想法，但是这拖着一个会议当然是很麻烦。只是这个实现起来也费劲，VAD 和 EOT 都要有了，否则分分钟跑炸用量。

此外，如果你是 Soniox ，其实那个 STT 对于自纠正的认同度很高，它本质上是一个 LLM 。另外如果你实时把 transcript 吐出来的话，人类就会看到这个乱糟糟的文本里面拼错的部分然后尝试纠正，这种纠正可以在 LLM 完成整理之后去跑另一个流程，识别并且去提升正确率。Typeless 选择隐藏这个乱糟糟的东西，制造了魔法效果，但也留下了黑盒，抹掉了自纠正空间，这个留给你取舍吧。

一句话介绍：

我每周烧掉起码两个，差不多三个 Max 20x 订阅。

https://github.com/wdhwg001/csift 是我给 Claude Code 的 session 层打的补丁。https://www.v2ex.com/t/1235190 是在 V2EX 上的宣传，因为这么重的用户才能挖到的东西确实是受众很窄，所以只作为重度 AI 使用者之间递名片用。

有自己的编排层，懒得开源，市面上躺着的 superpowers 的 yet another 茫茫多。

有点子。

不在找 CTO ，但欢迎 networking ，有意的话回复，我不主动加过去打扰，因为毕竟同样都是技术人，相轻也是常态，没有点 ego 就不是 cofounder 了。

dsh 是 flask ，但这个 flask 要的知识，尤其是脑子里对于各种最佳实践的取舍知识，那可太多了。

对于 Harness Engineer 以外的人来说，它不是 npm ，是 360 软件管家。

@MHPSY 其实这件事对于 Claude Code 自己的架构来说不太好办，因为它几乎是纯 TypeScript 的，但 JSONL 的规模大到 Bun/Nodejs 很难吃得下，这个项目背后藏着很麻烦的优化问题，因为它和 ripgrep 不一样，rg 不需要考虑结构，而它需要在考虑结构的前提下完成大量 session 的 regex 扫描，而这里面的拓扑一类的功能还涉及到动辄几十甚至几百个 JSONL 的扫描，带拓扑的多 session 找起来更费劲。

这东西绊了 AI 很长时间，我亲眼看着 Fable 试了六七个方案，profile 的构建吃了我差不多 200G 空间，最后才把时间压到<1 秒。

@MHPSY 感谢试用。

虽然刚开源没有多少 stars ，但是它扛过了严格的变异测试，并且内部的优化从 mmap 到 simd 和并行化都有，我对它的质量还是放心的。

@xingxingluolei 首先确保你使用的是正品的 Opus 5 。然后 Opus 确实在 5 之前有严重的上下文注意力问题，那时候通常推荐锁更低的上下文，但是现在不存在了，锁上下文更多的是省你自己的开支，因为 credit 里 cached read 免费，但 uncached read 不免费。

这件事有一个最简单的处理方法：不更换 session 。

并且如果你的前提是不更换 session ，那么一切都自然顺畅了，不需要那些复杂的东西了。

A 的重置前提是：感受到了 O 的压力。

和用户诉求无关，A 本来的用户基本盘就很大，算力也不是爆棚的那种，模型偏好大参数 SL 而不是拼命 RLHF ，所以除非 Tibo 去跳脸跳到让 A 压力爆表，否则它不会重置的。

@dingawm 41 秒，5 个 tool call ，不符合 xhigh 的认知，并且/clear 过，那么按照 xhigh 的习惯肯定会先查清楚。

41 秒…首先你不开 verbose 的时候 CC 就是真的会偷懒，其次你 reasoning 开太低了，越低就越是纯粹的执行机器。