 |
msg7086🏢 Software Engineer V2EX member #38436, joined on 2013-05-04 05:31:44 +08:00Today's activity rank 4684 |
msg7086
 |
Per msg7086's settings, the topics list is only visible after you sign in |
Deals info, including closed deals, is not hidden
msg7086's recent replies
15h 34m ago Replied to a topic by edgeedge › 程序员 › AI Coding 还看源代码吗？要是不看，会害怕血崩吗？ |
> 但若不是 AI Coding ，而是自己一行行写的话
自己一行行写那么多代码早就加班到猝死了。
> 吓出冷汗
吓出什么冷汗，只是个公司业务而已，报错率高就高了，让 AI 快速排查原因就完事了。你们都代码写完直接上生产了，想必本来也对产品质量没有变态苛刻的需求，遇到问题原地迭代再上线就行了。自己吓自己。
> 是否会担心，或做些什么，来保证自己对项目的持续开发、持续维护、甚至上线，都仍然有信心担责
我用 AI Coding 如果出了问题，那就是我测试用例写得还不够，AI code review 做得还不够暴力。Vibe 时代，代码可以被看成是黑盒，你要做的是在黑盒之上，用测试，用流程，用行政角度的方法，去保证这个黑盒的可用性。纯 Vibe 项目我几乎不会看实现，而且很多时候我也看不懂，因为我不会要求他用我能看懂的语言来写。我只关心行为是否正确，所有的功能是否都由测试覆盖到了。
之前 vibe 了一个字节码反编译器，大约 20 万行代码，两三千个测试用例，全方面覆盖所有代码细节，用官方测试自己编译器的压力套件来测试我自己的项目。那至少我知道我的项目可用性和官方编译器的可用性会在同一个等级上。那我也不可能自己去读这 20 万行代码吧。
自己一行行写那么多代码早就加班到猝死了。
> 吓出冷汗
吓出什么冷汗，只是个公司业务而已，报错率高就高了，让 AI 快速排查原因就完事了。你们都代码写完直接上生产了，想必本来也对产品质量没有变态苛刻的需求，遇到问题原地迭代再上线就行了。自己吓自己。
> 是否会担心，或做些什么，来保证自己对项目的持续开发、持续维护、甚至上线，都仍然有信心担责
我用 AI Coding 如果出了问题，那就是我测试用例写得还不够，AI code review 做得还不够暴力。Vibe 时代，代码可以被看成是黑盒，你要做的是在黑盒之上，用测试，用流程，用行政角度的方法，去保证这个黑盒的可用性。纯 Vibe 项目我几乎不会看实现，而且很多时候我也看不懂，因为我不会要求他用我能看懂的语言来写。我只关心行为是否正确，所有的功能是否都由测试覆盖到了。
之前 vibe 了一个字节码反编译器，大约 20 万行代码，两三千个测试用例，全方面覆盖所有代码细节，用官方测试自己编译器的压力套件来测试我自己的项目。那至少我知道我的项目可用性和官方编译器的可用性会在同一个等级上。那我也不可能自己去读这 20 万行代码吧。
4 days ago Replied to a topic by dayudayupao › 程序员 › 想收集下大家是怎么使用 codex 这类工具开发(新/老)软件的 |
一般先分拆出 MVP ？做完 MVP 以后再往上加功能吧。
5 days ago Replied to a topic by haonanaaaaaa › 程序员 › 大家现在 Windows 下面是如何使用 codex 的，怎么搞都有问题 |
如果不是刚需开发 windows 项目的话，我是开了个 Linux VM ，上面装上 codex CLI ，然后从桌面版远程连上去干活，再开个 syncthing 同步到本地查看。
codex 桌面版毛病一大堆，但是一旦远程连上 Linux 以后，一切都变得舒服起来了。没有铺天盖地的 git.exe 和 taskkill.exe ，不会轰炸你的内存和 CPU ，体验还和本地几乎一样。
codex 桌面版毛病一大堆，但是一旦远程连上 Linux 以后，一切都变得舒服起来了。没有铺天盖地的 git.exe 和 taskkill.exe ，不会轰炸你的内存和 CPU ，体验还和本地几乎一样。
5 days ago Replied to a topic by ldy619354397 › 问与答 › chatgpt 的套餐能直接对接 api 使用吗？ |
你是否在找 sub2api 之类的工具。
5 days ago Replied to a topic by realkobe › OpenAI › 两个 GPT 账号，这是什么情况？ |
可能和你实际用的模型有关？限额不是严格按照 API 价格结算的。
5 days ago Replied to a topic by crocoBaby › Local LLM › 云 llm 越卷越便宜， mac 统一内存本地部署 32b 已经没意义了 |
@MoonLin 是啊，甲方是美国联邦政府和美国国防部。
你的意思是说，原本用订阅/中转的用户，突然有一天发现自己用 AI 的成本涨了 50 倍，然后他们还会继续乐呵呵地给你送钱？
本来花 200 刀订阅的开发者，发现下个月开始按量计费，一个月要收 12000 刀，他们就会乐呵呵每个月掏出 12000 刀给模型厂商？
要不要先去学一下经济学 101 。
本来花 200 刀订阅的开发者，发现下个月开始按量计费，一个月要收 12000 刀，他们就会乐呵呵每个月掏出 12000 刀给模型厂商？
要不要先去学一下经济学 101 。
5 days ago Replied to a topic by crocoBaby › Local LLM › 云 llm 越卷越便宜， mac 统一内存本地部署 32b 已经没意义了 |
「签保密协议」的保密等级有限。真正保密等级高的，要么自建开源模型，要么自建机房然后让对方进驻。
比如我司的云计算产品，别人要采购，他们可能是自己建一个保密机房，然后我们的人进去部署好整个云计算环境，然后他们用。我们这边要访问机房里的环境，必须要政审拿到权限才可以进。要 debug ，得他们的人连上服务器，然后和我们共享屏幕，我们指导对方怎么查日志找问题。
比如我司的云计算产品，别人要采购，他们可能是自己建一个保密机房，然后我们的人进去部署好整个云计算环境，然后他们用。我们这边要访问机房里的环境，必须要政审拿到权限才可以进。要 debug ，得他们的人连上服务器，然后和我们共享屏幕，我们指导对方怎么查日志找问题。
6 days ago Replied to a topic by blackantt › 程序员 › 似乎开源项目作者不知道/不想利用 AI 来加速自己的开发？ |
之前我收到过一位开源项目开发者关于使用 AI 的看法。
其中有很大一项就是：
许可证污染。
你做自己的项目，你想怎么搞就怎么搞，反正你自己负责，开 AI 拉多大的都无所谓。（我现在 vibe 的一个项目已经非常大了，几千个提交，就是这么做的。）
但是这是别人的项目，而且是开源项目，想必还是比较出名的项目。
那么问题就来了，你怎么保证 AI 生成的代码不是和其他私有项目或者许可证不兼容项目里的代码一个样？
比如你在给 MIT 项目贡献某种算法，结果后来被爆出来和另一个 GPL 项目里的算法非常类似。
怎么办？整个项目都给你污染成 GPL 了。
所以很多人非常忌讳这种 AI vibe 大功能的 PR 。
如果是简单的修改，比如你找到一个 C++内存溢出问题，修改一下缓冲区长度，又或者是 double free 了你给修一下条件，这种属于著作权法上「简单修改」的情形，一般维护者是接受的。
后来那位维护者也提到，如果只是生成简单的测试用例，或者参与 debug 工作找到代码错误，这些一般都是可接受的。所以后来我给这个开源项目做的贡献就是写了一个独立于项目的测试框架套件，由我反向导入开源项目作为子模块，然后跑测试用例。
当然楼上几位提到的维护者的精力也是很重要的一点。你是作为一个第三方开发者去贡献代码的，而第一方开发者对项目的了解程度远比你高，你无心引入的一些变更，对方仔细审核以后就可能会发现隐藏的 bug 。再加上万一对方合并 PR 以后出现问题，责任在对方头上，而不是你头上。维护者身上的压力远比一个 PR 作者要大。
其中有很大一项就是：
许可证污染。
你做自己的项目，你想怎么搞就怎么搞，反正你自己负责，开 AI 拉多大的都无所谓。（我现在 vibe 的一个项目已经非常大了，几千个提交，就是这么做的。）
但是这是别人的项目，而且是开源项目，想必还是比较出名的项目。
那么问题就来了，你怎么保证 AI 生成的代码不是和其他私有项目或者许可证不兼容项目里的代码一个样？
比如你在给 MIT 项目贡献某种算法，结果后来被爆出来和另一个 GPL 项目里的算法非常类似。
怎么办？整个项目都给你污染成 GPL 了。
所以很多人非常忌讳这种 AI vibe 大功能的 PR 。
如果是简单的修改，比如你找到一个 C++内存溢出问题，修改一下缓冲区长度，又或者是 double free 了你给修一下条件，这种属于著作权法上「简单修改」的情形，一般维护者是接受的。
后来那位维护者也提到，如果只是生成简单的测试用例，或者参与 debug 工作找到代码错误，这些一般都是可接受的。所以后来我给这个开源项目做的贡献就是写了一个独立于项目的测试框架套件，由我反向导入开源项目作为子模块，然后跑测试用例。
当然楼上几位提到的维护者的精力也是很重要的一点。你是作为一个第三方开发者去贡献代码的，而第一方开发者对项目的了解程度远比你高，你无心引入的一些变更，对方仔细审核以后就可能会发现隐藏的 bug 。再加上万一对方合并 PR 以后出现问题，责任在对方头上，而不是你头上。维护者身上的压力远比一个 PR 作者要大。
Select Language