V2EX › Zhuzhuchenyan 的所有回复 › 第 1 页 / 共 16 页

V2EX = way to explore

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

For Existing Member Sign In

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯

16 小时 24 分钟前

回复了 zzdz 创建的主题 › 问与答 › 关于域名解析到香港服务器， IP 能直连，但是通过访问域名被连接重置

福建著名的墙中墙，你所在的地区应该是白名单制度，不在名单上的直接重置链接

3 天前

回复了 Voyager2718 创建的主题 › 程序员 › 肉身在墙外，现在做物理机远程 Claude 的生意怎么样？

帮朋友做过一段时间，后来绝交了
一开始想的很美好的
后来问题接连不断
1. 机器莫名其妙重启了，连不上 ssh ，我那时候睡觉夺命 call 把我叫起来
2. 家里突然没网了，同上
3. 号被封了，最开始让我赔偿他全部损失，后来说让我赔一半的钱

做机器托管就是很多糟心事，然后你未必能说服使用者愿意付你机器托管额外的费用。然后 Claude 封号肯定是基于风控模型的，和 claude 对话各种使用习惯也在模型里，使用境外机器并不能 100%免封

7 天前

回复了 summertimesad 创建的主题 › 程序员 › 2026 年了，还有老架构坚持 MySQL 单表数据不能超过 2000 万行

这个论断在现在的硬件平台确实不适用了
从存储的角度来说，自从我们托管的机器换了 NVME ，面对 10000 倍性能提升的 4K 随机读，和 1000 倍性能提升的 4K 随机写，感受到的差异是巨大的

12 天前

回复了 zhuchuanjun 创建的主题 › 问与答 › codex 怎么破除道德限制

有渠道的话注册一下 https://openai.com/zh-Hans-CN/daybreak/
就不会有 cyber abuse 邮件了

13 天前

回复了 hachimen 创建的主题 › OpenAI › 感觉 codex 纯靠灌大量上下文来 reasoning

尝试一下新的实验性的上下文管理方案看看
https://community.openai.com/t/experimental-context-management-compaction-in-codex/1395578

9 月 30 日

回复了 Features 创建的主题 › 程序员 › O÷卖不起 plan 为什么不选择倒闭呢？

@Features 自从 5.6 更新以后，并发消耗同一个套餐就有可能被风控标记

9 月 30 日

回复了 Zhuzhuchenyan 创建的主题 › 机场 › 求推荐一个中德延迟低的机场

感谢各位的推荐，目前上车 misaka 的优化线路，延迟比我想象的优秀

9 月 25 日

回复了 Frankcox 创建的主题 › Claude › 打脸食言了， Opus 5.5 确实有其强大之处

OpenAI 模型的强项就是指令遵循，代价就是对使用者的能力要求比较高，很难跳出使用者的框架
相比之下 Claude 的系列模型发散能力更强，对模糊指令的完成度会更好一些。

9 月 14 日

回复了 andyJado 创建的主题 › 程序员 › gpt-6-astra max 100 刀干不出来一个 docker 迁徙 nix

@royzxq Vibe Coding 大体分为两种使用方式
Vibe 敏捷和 Vibe 瀑布，大体上就是模仿人类的敏捷开发范式或者瀑布流开发范式
许愿式开发就是 Vibe 瀑布但是不给出具体需求和约束，只给出结果的 Vibe 方式

9 月 9 日

回复了 blackantt 创建的主题 › OpenAI › Google play 支付时，会对比发卡行的账单地址吗？

昨天亲测支付成功，浦发银行 VISA + Google Play 支付，改免税州地址，全局美国 IP 代理，只需要发卡人名字正确就可以

9 月 1 日

回复了 TimG 创建的主题 › 程序员 › 存储表结构 RAG 与 Skill 哪个更优？

@Dav1s 因为还有维护 llms.txt 的成本，所以每次框架大版本更新的时候都要重新检查是否更新了 llms.txt 。
对于不更改整体文档结构的小修小补，不涉及到 llms.txt 的更新频繁点也无所谓。

9 月 1 日

回复了 TimG 创建的主题 › 程序员 › 存储表结构 RAG 与 Skill 哪个更优？

对于更新频率很低的文档查阅类的需求，现在我们团队都是统一用 https://llmstxt.org 提供的实践来让 agent 自行查阅了
更新比较勤的框架基本都自带了，例如
https://angular.dev/llms.txt
https://reactflow.dev/llms.txt
内网的话完全可以克隆一份当前版本的支持文档，在内网部署后更改 llms.txt 的链接即可
这套方案的优势就是不依赖外部工具，前提是文档本身质量很高，并且更新频率不能太高。

8 月 18 日

回复了 lymanbernadette6 创建的主题 › OpenAI › 中转站什么比例才是与 codex 官方的价格齐平的？

你如果按周限额统计的话
plus 一周 85 刀
一个月用满 340 刀
按 20 刀来算倍率就是 0.06

要是能经常用满周限额的话肯定是 plus 比中转便宜的

8 月 9 日

回复了 dacoco 创建的主题 › 程序员 › Deepseek 招游戏开发, 游戏开发方向”和“Web 3D 与渲染方向

进去做工具和数据是吧，工具程序员和数据分析可是在游戏开发行业的鄙视链底层了
适合想转行的

7 月 5 日

回复了 hanbaoji 创建的主题 › 程序员 › 把 5.5 和 5.4 的 xhigh 做糖果测试对比， 5.5 完败

使用 gpt5.5 medium 无法复现
https://i.v2ex.co/Rg2U8uxL.png

7 月 3 日

回复了 hiboshi 创建的主题 › 程序员 › 不懂就问，简历中吹嘘自己是公司大模型部署的维护人，哪里能找到真实点的企业设备？

很多搞 GPU 租赁的平台
几个大的公有云都有 GPU 实例 B200 B300 都有
太贵的话，外网有很多小商家也做 GPU 租赁，都是按小时计费的，玩几天要不了多少钱就

6 月 30 日

回复了 ycyppq123 创建的主题 › MacBook Air › m5 macbook air 用什么散热器

小风扇对着键盘吹就行了
亲测能起到改散热 90%的效果

6 月 29 日

回复了 rogwan 创建的主题 › 程序员 › 纯 AI 编写 Oneshot 跑通的项目，能到什么规模？

https://developers.openai.com/showcase
基本都是 demo 的程度

6 月 29 日

回复了 Chuyuxuan 创建的主题 › AI Agent 智能体 › 大大们是怎么管理 AI 生成的 spec ，并且落地成为项目资产的？

我们的实践是，对单个需求开发的 spec 不能被合入主仓库
由 spec 产生的代码本就是对 spec 的精细化翻译，如果团队成员无法从代码了解功能的话基本上过不了 review

我看你问题里说的可能是面向一整个系统的包含多个子项目和子任务的 spec ，这种我们一般不跟随 repo 走，有专门的团队化文档和其他工具维护整体规约和进度，同时暴露一些接口给 ai 工具参考调用即可

Spec 进入 git 管理还有一个问题是，我们必须要对 spec 进行维护。比如说功能 1 的 spec ，明天功能 1 变成了 1.1 ，我们要么增量添加 1.1 的 spec ，要么修改功能 1 的 spec ，对团队成员造成了额外的负担。有点像 ORM 时代每次数据库变更都要写的 migration 一样，

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯