一般问这种问题前，应该先问公司的 it 管理相关规章制度。。。。。这其实不是个单纯的技术问题

当别人还在那整调度、调电源计划的时候，我早就直接 BIOS 里把所有小核都禁用了。相信我，这是最简单的方法。而且续航也没减少多少。

在国外生活肯定要刷海外版 ROM 的。国内 ROM 很多功能、包括 google 框架都是阉割有问题的，想不折腾直接刷是最好的

@Kirkcong 每个公司规模和工作风格不一样。我在的公司比较随意，遇到比较急的同一楼层一般瞄一眼人在不在工位，然后直接过去问。不急或懒得爬楼就是发 slack 。远程一样，不急着处理的问题定时间拉会，急的直接 slack 上问能不能语音。

@lacklock
语音有个问题，远程久了会逐渐开始抵触语音和视频通话。
打语音和视频本质上和打电话是一回事，本能上是很让人抵触的。在家办公随时随地都可能会有人语音过来很难受。而且每次语音前都要问一下对方现在方便语音吗然后等回复，每天动不动就这样成本也挺高的，最好还是嫌麻烦直接发消息了。交流这方面，远程是真没办法做到线下这么丝滑，这事我远程的最大感受

远程最大的问题还是在于交流效率的低下、纯文字交流更容易引发冲突矛盾
线下遇到问题扒拉一下边上同事就能立刻有响应但是线上不同
文字很难像线下说话那样直接几句话把事情一来一回说清楚，也没有肢体的互动交流（文字交流费半天劲的事，很多时候线下直接指一下屏幕就行了）
还有就是文字无法看到对话表情，导致经常会因为文字误判对方的语气和态度。经常远程一定偶尔会遇到，和对话打字解决问题，明明没什么情绪但聊着聊着情绪就上来导致事态升级的情况。线下的表交流等能很大程度缓解这种问题，那马有误解也能立刻通过对话纠正问题

用的 claude 的模型？最近感觉 claude 模型整体价格发生了异常

让 ai 别写那么多边界判断和安全 check 就能立刻让 ai 味道降低非常非常多

让 ai 写个前端，满天飞的都类似

const globalRuntime: typeof globalThis = typeof globalThis !== "undefined" ? globalThis : ({} as typeof globalThis);

这种玩意。这还算程度轻的。不知道还以为这代码重要到出错人类就会灭亡呢

ai 写出的这种算破玩意我是真的懒得多看一眼

国外 Anytime 这种全球连锁全球店都能用的会员也才一年 5000 ，这加一个已经不是一般的贵了。这是带多少节私教课？

@bytesfold 我已经把 subagent 禁用了

@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 就要强制我一直后台开着这破玩意