BeautifulSoap

@BlueSkyXN 看一下评论，兄弟。这应该可以确定是恶性 bug 了。而且我的 claude code 可以无 MCP 、skills 所有设置都是初始装的

@bluetree2039 对的，现在 caldue code 的 token 消耗量非常异常。找了下，发明现在官方 issue 下已经评论数量炸了。一周就 500 条评论了，哪怕是 Max 用户都在以异常的速度消耗 token
https://github.com/anthropics/claude-code/issues/16157

@Orenoid
@webcape233
是的，我也没法想象这种新的编程语言会是怎样的东西。总感觉今后应该会有一种全新的编程范式，用来填补 ai 的不确定性和确定性执行之间的鸿沟

我觉得将来哪怕有这个趋势，最终应该也不可能是自然语言的 spec
自然语言实在太模糊太不精确了
今后可能会出现一种介于代码和自然语言之间更加精确的专用中间语言。就和高级语言和汇编的关系一样

@squirrel7105 20$会员啊

codex 。慢是满了点但指令遵循挺好的

claude code 我很不喜欢。交互和用户功能性体验极差连每轮对话 diff 的功能都没的玩意每次对话完我都非常不安，因为我根本不知道它到底改了哪里。而且 cc 的模型极其喜欢擅作主张，指令遵循非常差。而且最近 claude code 的 token 消耗速度简直令人瞠目结舌。3 个对话的 sonnet 模型就直接把我 5 小时的 token 量干空了，一周用量掉 13%，简直逆天

claude 连续编程 5 个小时产出了一大坨代码，就问你敢不敢用到生产环境吧

Spec 驱动开发绝对不是 ai 开发的未来。真做过项目的就知道 Spec 这东西本质上就是一个项目的详细设计书（尤其日本 it 开发喜欢这一套。开发项目先确定需求,然后做完整的系统的设计，这种设计可能详细到每个小功能逻辑步骤）
大部分是你用了 Spec 驱动开发，往往结果如下

1. 对于一个复杂功能，生成的 spec 过度复杂
2. 虽然能拆分功能 spec ，但是功能的复杂度是改变不了的，spec 的复杂和 ai 生成的大量 spec 结果就是根本懒得去看
3. spec 详细到了代码细节实现，review spec 本质上和 review 伪代码没区别，到后来就和 2 一样懒得去详细看 spec 了
4. spec 对各自的功能模块只适合功能变化不大、较为稳定的情况。当你的设计书经常动不动就发生大的变化（实际上开发中经常遇到），spec 也经常会发生巨大变动，如何将最新的变动融入已经写下去的 spec 并且更新到代码也是个问题。而且每个 spec 之间都互相依赖，牵一发动全身。

Options+这傻逼玩意，不开着这东西我 M575 鼠标 DPI 就会恢复默认。简直不知道罗技这帮人脑子怎么想的，我就想改个 DPI 就要强制我一直后台开着这破玩意