swaylq 最近的时间轴更新

swaylq

V2EX 第 650141 号会员，加入于 2023-09-24 19:23:55 +08:00

今日活跃度排名 21479

auramate.net/

swaylq 提问技术话题好玩工作信息交易信息城市相关

我们用命理大赛真题做了个 AI benchmark，结果挺意外的

分享创造 • swaylq • 3 月 29 日 • 最后回复来自 sunnysab

» swaylq 创建的更多主题

swaylq 最近回复了

11 小时 8 分钟前

回复了 tho 创建的主题 › Claude Code › 自己的两台电脑同时登陆同一个 claude 账号，单说这个行为，有封号风险吗？

单说多设备登录，一般不算高风险。我自己也是办公室+家里+笔记本来回切。真容易出事的反而是异地乱跳、代理出口天天变、多人混用。设备数不是重点，行为像不像合租才是重点。

2 天前

回复了 decade0q 创建的主题 › 程序员 › 公司可以报销一半 ai 使用费用了有啥推荐吗？

先排除一切中转。公司能报一半的话，我会优先买官方订阅：写代码 Cursor/Claude Code 二选一，日常问答再补个 ChatGPT 。别同时开一堆，最后都是在给订阅管理打工。

4 天前

回复了 sampeng 创建的主题 › OpenAI › 在新项目里尝试 codex，意外发现相当可以

cc 设计 codex 开发这个思路挺有意思的，相当于让两个模型互相 review 。我之前也是纯 cc 党，但 529 确实劝退，有段时间一天能碰上好几次。rust 那个深有体会，cc 写 rust 老是跟 borrow checker 打架，改了三轮还不过是常态。codex 这块确实强一些，可能跟训练数据里 rust 的比重有关。不过 codex 那个异步执行的模式用起来节奏会不会有点割裂？我习惯了 cc 那种实时交互改代码的感觉。

5 天前

回复了 hoky 创建的主题 › 职场话题 › 尴尬了，可能招聘了一个不会手写代码的 AI 工程师

看了附言，985 机械工程只学过一年 C++，这不叫 AI 工程师，这叫用 AI 的外行人。真正的问题不是 AI 让人变菜了，是有些人本来就没入过门，AI 只是让他们能伪装更久而已。

@gitdoit 你那个不一样，至少你知道代码放哪、怎么 debug 、出了 bug 能定位问题。会用 AI 和只会复制粘贴 AI 输出，中间差了一整个工程能力。

6 天前

回复了 andforce 创建的主题 › Claude › 彻底解决 Claude Code 封号问题，但。。。

思路可以但感觉有点绕远了… CC 好用核心还是它的 system prompt 和工具链做得好，模型只是一部分。直接改源码接 copilot api 确实能跑，但后续 anthropic 更新 prompt 或者工具定义你都得手动同步，维护成本不低。我现在就是 copilot agent mode 里选 claude 模型，体验已经很接近了，不折腾。Cursor 那边倒是没听说封号的，毕竟人家是正经付费渠道。

7 天前

回复了 zhengfan2016 创建的主题 › 职场话题 › ai 时代，现在控制项目代码可读性还有意义吗

反而更有意义了。AI 生成代码越多，你越需要能快速 review 的代码结构，不然就是在给自己埋雷。CC 那个 main.ts 是个反面教材，4400 行的函数连人带 AI 都不好维护。实际项目里我现在反而更严格地拆函数、写注释了，因为 AI 重构的时候如果原始代码就是一坨，输出只会更烂。可读性本质上是给未来的自己（和 AI ）省时间。

3 月 31 日

回复了 LightHiding777 创建的主题 › ☕Vibe Coding🤖 › 大家工作中是如何使用 AI 编程的？古法程序员还是没法完全脱离 idea

我的做法是直接让 CC 在 feature 分支上干活，写完跑一遍测试，过了就提 PR 自己 review 。review 这步真不能省，CC 偶尔会偷偷重构你没让它改的地方，diff 不看仔细迟早踩坑。

楼主那个项目拷贝的方式确实容易越搞越乱，不如花半天把 git 分支策略理顺，后面省的时间多得多。

3 月 30 日

回复了 kamisamayo 创建的主题 › 程序员 › 2026 年，个人开发首选是直接走原生还是走 RN 或 flutter

@iorilu #35 说到点上了，独立开发最重要的是先验证需求，技术栈根本不是瓶颈。我自己的经验是 RN + Expo 配合 Claude Code 效率很高，大部分兼容性问题丢给 AI 都能解，真正头疼的反而是各平台审核策略不一样。原生的话 AI 写 SwiftUI 确实还行，但 Xcode 项目配置那一堆东西 AI 帮不了太多，@akorn 说的那个痛点太真实了。个人开发别追求技术完美，先糊出来让用户用上再说。

3 月 29 日

回复了 tho 创建的主题 › Claude › opus 小时限额之后，你们是等，还是用 sonnet 继续？

我的做法跟 #10 类似，opus 负责架构设计和复杂逻辑，sonnet 干执行层的活。实测下来 sonnet 写 CRUD 和重构这类确定性高的任务完全够用，省下来的 opus 额度留给真正需要推理的地方。5x 确实容易撞限额，尤其是连续大块任务的时候。

3 月 28 日

回复了 nealzhuqian 创建的主题 › Claude Code › 有点搞不懂 Claude Code 了

说实话 cc 的 CLI 才是它的杀手锏，插件反而是阉割版。我现在的工作流是 cc 纯 CLI 跑任务，同时 VSCode 开着同一个项目看实时改动，配合 git diff 随时 review 。关键是 cc 可以用 worktree 开多个分支同时跑不同任务，这是 cursor 做不到的。你提到的 agent teams 多开才是 cc 真正拉开差距的地方——cursor 再怎么整也只能单线程干活。习惯了之后回不去 cursor 了，就是刚上手会有一段不适期。

» swaylq 创建的更多回复