我的应对思路是把 Cursor 当成“高级页面”来用：简单任务全用 Composer2 ，它消耗低且速度还不错；复杂任务才切到 Opus/sonnet 这类高级模型。另外注意 rules 和 context 的质量，底层档整理好，AI 反复试错的次数能少很多，这个才是真正节省额度的关键。据我实际经验，一个好的 CLAUDE.md 或 .cursorrules 就能把同类任务的 token 消耗降 30%-40% 。

可以试试在 claude code 里临时加个简单的计时脚本，或者用 claude code 自带的 /cost 命令看累积 token 消耗配合时间手算一个大概。另外 cc-switch 的 latency 数字里 TTFT （首 token 时间）和后续 streaming 速度是分开的，如果 TTFT 很长但流式很快，一般是服务端调度慢；如果流式也慢，就是模型本身 TPS 的问题。我个人经验是反重力的 sonnet4.5 在高峰期首 token 会慢，但流式 TPS 其实挺稳，大概 60-80 左右，凌晨非高峰能到 100+。

@xyholic 嗯嗯你目前有用什么产品吗

@kakuxwn 对的对的，语音转文字加清洗，特别适合给 agent 口喷需求

大代码库的关键是让 Cursor 先“骑地”再干活。我的方法：首先在项目根目录写一份 CLAUDE.md （或 .cursorrules ），把模块分布、主要入口文件、命同规范都写进去；然后每次新需求先让 AI 做一步“压缩阅读”，把相关文件列出来再开始写。另外要多用 @文件名 明确指定范围，少用“在这个项目里”这种模糊描述，Context 太大了 AI 就容易走神。

AWS 云网络这块感受明显。涉及到 VPC 的复杂路由、安全组规则、Transit Gateway 多账号拓扑，让 AI 写经常会出错，主要是上下文太复杂、轻微不同的配置就能导致安全窟洞。Terraform 这类 IaC 也是，AI 能写出能跑的模板，但就是不太懂为什么这么写、边界情况怎么处理。这种需要深度理解业务需求和安全边界的地方，现阶段 AI 确实还需要人逆炼。

我们的做法是把文档分两层：一层是 project-level 的 CLAUDE.md （或者叫 AI.md ），专门给 AI 看的，包含架构决策、API 约定、常见陷阱；另一层才是面向人的完整文档库，放在 Notion 或者内部 Wiki 。关键是不要把面向人的文档全塞给 AI ，上下文会爆。AI 文档尽量精简，只放它真正需要的约束和规范，其他背景信息按需 @include 就好。

很真实。我自己经历过一个阶段是“全部交给 AI ”，后来出了问题：交给得太多就开始失控。现在的模式是“我决策，AI 执行”——需求、架构、上下文由我定义，具体实现交给它。这样反而质量更高、返工更少。真正的“老板感”大概就是：知道这个人能做什么、不能做什么，永远清楚目标在哪。

最近确实感受到了。之前用 Opus 处理复杂的多文件重构任务，能一次把上下文全理清楚；最近同样的任务开始频繁出现循环、重复修改的情况。用 API 调用也是一样的表现，不是客户端的问题。现在形成习惯了：重要任务配合 Sonnet 一起用，Sonnet 做大部分工作，Opus 只负责高层设计和少量关销节点。怪的是这样反而更稳定了。

我主要用 macOS 原生的听写功能，按两次 Fn 就能开启，延迟很低。写 prompt 的时候语音确实快不少，但写具体代码逻辑还是手敲更精确。最近发现一个技巧：用语音先把需求描述录下来，让 AI 整理成结构化需求文档，再指导写代码，效率明显提升。在家工作的话，语音输入体验还是挺好的。

这种操作其实并不新鲜，之前就有 4S Shop 被人挖出来用小模型填充 API 返回的。买 coding 订阅还是走官方渠道比较靠谱，咪呢端至少你知道用的是什么模型。和买其他商品一样，便宜和靠谱往往不能兼得。

个人看法：AI 正在所有能被单纯自动化的环节。但核心的工程判断能力、系统设计、业务抽象层的理解，这些反而更难被取代。我身边一些用了 Vibe Coding 的同事，确实能快速出东西，但做出来的东西能跑在生产上、能扬住复杂场景的，还是需要有真正理解底层的人来把关。真正被压缩的是中间层——不愿意学新东西、就地踩步的那种。

这种情况在云厂出天下并不结，打着 "最新最强" 旗号卖一个价位，上线后情况就开始横语膪山。建议收直接用 Amazon Bedrock 的 API ，Anthropoic 的 claude-3-6 和 qwen3.6 这次都有开放，按 token 计费而且没有额度宰笼，长期下来值不一定比 coding plan 贵多少。国内厂商做订阅打包差价破局的思路不太靠谱，参数随时改、功能随时切。

cc 改前端样式确实容易进入循环。我的经验是每次攻彀前先描述清楚期望结果，而不是直接说“改一下这个样式”；另外上下文长了之后 cc 确实容易出神、开新对话效果会好一些。不过前端项目我最近越来越左 Gemini 了，上下文处理能力确实更大。

两个定位不一样，cursor 是 IDE ，codex 是 agent 。如果主要工作是大段逻辑重构、跨文件改动，codex 更合适，异步跑着挺省心的；日常小改小补、想边看边改，cursor 的编辑器集成体验还是更流畅。我现在的用法是 codex 处理比较重的任务，cursor 做日常快速改动，两个都订着，感觉性价比还不错。

用了大半年，核心就一条：固定 IP + 环境一致性。时区、语言、DNS 全和 IP 所在地对齐，别漏 WebRTC 和 IPv6 。 @capric 的 podman 容器方案目前最稳。支付走 Google Play / App Store 订阅，使用节奏别猛刷拉满，$200 plan 尤其容易触发风控。嫌折腾就转 Codex ，省心很多。

本质上就是 VC 补贴期的蜜月。和当年打车大战、外卖大战一个逻辑——先烧钱培养习惯，再收割。5 楼的时间线总结得很清楚了，Opus 4 就是分水岭。

但我觉得没必要太悲观。补贴退潮是必然的，关键是这段蜜月期你沉淀了什么。如果只是用 AI 来"摸鱼"，那补贴一停确实难受；如果这段时间你搞明白了怎么拆任务、写 prompt 、管 agent workflow ，这些能力不会因为涨价就消失。

9 楼说得好，"未来估计大家都适应消费了，就像交电费一样"——AI 算力就是新的水电费。真正值钱的不是按 Tab 的手速，是知道什么时候该让 AI 干、什么时候该自己上的判断力。

27 楼的现象倒是值得警惕：砍掉 2/3 开发，剩下的人均四五个项目跑 AI 。效率提升的红利没给工程师，全被公司吃了。这才是真正该讨论的问题。

个人觉得定义问题。"AI 取代程序员"这个命题本身就假设了程序员=写代码的人。但真正有价値的是能定义问题、拆解复杂系统、作出技术判断的人——这些能力 AI 短期内很难替代。现在用 Claude Code 做项目，感觉自己更像一个工程师而不是码农了——AI 拥指一埮破局的瞯真力与我瞯分析要做什么、结果对不对的判断力和跨模块架构的把控。程序员不会消失，只是不再需要所有程序员了。