V2EX › swaylq 的所有回复 › 第 1 页 / 共 2 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2

❮

❯

4 月 27 日

回复了 longxinglink 创建的主题 › 程序员 › Codex agentic loop 会导致代码严重膨胀，有人遇到吗？有没有系统性的解法？

3 楼 4 楼说到点子上了，本质是 agent 的目标函数偏“别改坏”，不是“最小正确实现”。我现在是每 3-5 个 task 强制来一轮 cleanup pass：删 fallback 、合并状态、迁移逻辑执行完就删。不做这步，补丁会自己繁殖。

4 月 26 日

回复了 xuegy 创建的主题 › Claude › 如何根治 Claude 在编译 C++时自作聪明的问题

这事靠 prompt 基本治不好，得改工具面。直接给它一个固定脚本，比如 `./tools/build_err.sh`，只输出首个 error + 前后文，instructions 里再写死“禁止直接 tail/grep 编译输出”。把可选动作砍掉后会老实很多。

4 月 25 日

回复了 0bit0 创建的主题 › 程序员 › 现在开发 agent 应用，你们用什么框架？

我现在反而尽量不用大而全框架。先拿 provider SDK + 自己的 tool/memory/session 跑通，等真踩到多 agent 编排、回放、权限隔离这些坑，再抽层。不然最后大半时间都在跟框架斗智斗勇。

4 月 24 日

回复了 mywjyw 创建的主题 › Claude Code › Claude code pro 最近是不是偷偷砍了 usage？

我这周也明显感觉变紧了，不过更像是把重度 agent 流量单独卡了，不只是 token 总量。长 session 加大 diff 特别伤，能拆小任务就拆，不然 pro 现在真有点只够问答了。

4 月 23 日

回复了 frankyzf 创建的主题 › Claude Code › Claude Code 中使用 Github Copilot 订阅的 GPT-5.4 作为推理模型有什么安全的方法吗？

别折腾 switch 了，Copilot 的授权边界就是给自家工具链用，拿去喂 CC 基本等于拿主号试风控。真想要 GPT-5.4 ，我现在是日常补全用 Copilot CLI ，大任务直接上 CC 或 Codex ，省得为了省几十块把 GitHub 号搭进去。

4 月 22 日

回复了 irvinghua 创建的主题 › 程序员 › Vibe Coding 时代，该如何快速搭建一个 CRUD 平台？

我会选 2 ，但只借登录、RBAC 、菜单、审计这些脏活，业务层自己重新切薄。别让 AI 从 0 造后台基建，token 烧得快，后面填坑更贵。 @yjxjn 说的先把设计文档和规约写死，收益最大。

4 月 21 日

回复了 jiames1969 创建的主题 › OpenAI › vibe coding 投毒真是一个大问题

所以我现在只敢让它在 devcontainer 或临时机里跑，npm 锁版本加禁 postinstall ，第一次执行前先看 diff 。快是快，但把 agent 当 sudo 替身，早晚出事。

4 月 18 日

回复了 syc721 创建的主题 › Claude › claude code 和 codex 在 vibe coding 还有质的区别吗？

我自己两边都常用，真说“质的区别”更多在工作流，不完全在模型。需求还糊的时候 CC 更敢往前推，跨文件改动也更稳；需求写清楚、想控成本和 diff ，codex 更省心。别只比单次输出，得看你项目大部分时间卡在哪。

4 月 15 日

回复了 cnfczn 创建的主题 › Visual Studio Code › vscode 装了 trae 插件，关闭以后，还能看到几个相关进程

看命令行，大概率就是索引、本地 embedding 、agent 常驻这几类进程，本身不算离谱。真要担心别猜，直接 lsof -i 看它有没有外连，再用 Little Snitch 或系统防火墙拦一下，马上就知道它老不老实了。

4 月 14 日

回复了 Croow 创建的主题 › ☕Vibe Coding🤖 › 大佬们有没有啥便宜的的 vibe coding 方案啊？

便宜和稳定基本不可兼得。真高强度用的话，我现在反而会把活拆开：重活走 API ，日常补全走 Kiro/CC ，顺手多 /compact ，不然上下文一肥，钱和效果一起崩。

4 月 9 日

回复了 blueslmj 创建的主题 › 程序员 › 大佬们都用什么 AI IDE？

我现在反而不追 AI IDE 大一统了，VSCode/Zed 只负责看文件和 diff ，主力是 Claude Code / Codex 跑在 tmux 。真拉开差距的不是 IDE 名字，是你会不会控上下文：任务拆小、阶段性 /compact ，不然再贵也会开始一本正经胡说。

4 月 8 日

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

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

4 月 6 日

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

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

4 月 4 日

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

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

4 月 3 日

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

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

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

4 月 2 日

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

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

4 月 1 日

回复了 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 确实容易撞限额，尤其是连续大块任务的时候。

1 2

❮

❯