V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  Parva  ›  全部回复第 1 页 / 共 8 页
回复总数  148
1  2  3  4  5  6  7  8  
❮ ❯
23 小时 57 分钟前
回复了 wukaige 创建的主题 › 问与答 › V 友们,胡姓,帮忙取一个好听的名字
胡=古+月

《把酒问月·故人贾淳令予问之》 ———李白
今人不见古时月,今月曾经照古人。
古人今人若流水,共看明月皆如此。

借诗取名:胡今月、胡若水
2 天前
回复了 SWALLOWW 创建的主题 › 问与答 › 我的 token 溢出了
/goal build gta6
3 天前
回复了 yierban 创建的主题 › 职场话题 › 前端这个行业真要完了
别说了,码奸( AI 工程师),干掉了前端兄弟和后端兄弟,现在连自己都要干掉了。
3 天前
回复了 300 创建的主题 › 分享发现 › 一个 AI 耗时过长的原因
codex 做什么都容易过度,过度设计,过度开发,过度测试。跟它提一下不要过度,就会好很多了。或者试试这个 skill:ponytail
3 天前
回复了 burden7 创建的主题 › 分享发现 › 一起拓展一下 AI agent 的使用思路
作为一名安卓开发,最近感触挺深的。

随着 AI Agent 能力越来越强,也越来越值得信任,我的使用思路逐渐从跟它反复掰扯,变成给它搭建好环境,打通开发、调试、验证的完整闭环。

我的做法是让它自己写 Skill ,记录操作经验,后面遇到类似问题就能直接复用。比如自己启动模拟器、解锁真机、处理安装过程中遇到的阻碍、录屏并用 FFmpeg 截帧分析问题。再到自己查看测试提的 Bug 、理解并复现问题、修复验证、提交代码、自动回复 Bug 单等等。

这些流程不需要我一次性设计好,而是遇到一个问题,就让它解决并沉淀下来,下次自己处理。

就这样,闭环越来越完善,我也一点点把自己给蒸馏掉了。
你主动拉开与前车的距离,利用这个空间提前起步,但你身后的车辆并不知道你的意图,只能跟在你后面,等绿灯亮起后才能起步。结果就是,你提高了自己的通行效率,却降低了后车的通行效率,导致后面所有的车反而更慢了。
5 天前
回复了 Parva 创建的主题 › 随想 › AI 量身定制软件的时代
METR 的数据:AI 独立完成的任务复杂度(按人类专家所需时间衡量,50% 成功率),从 2024 年以来,每 89 天翻一倍。2026 年的 Claude Opus 4.6 已经达到约 12 小时。按照这个速度再推两年,就是 300 倍,3500 多小时,相当于一个程序员接近两年的工作量。这还只是按过去两年的 AI 发展速度推演,AI 已经逐渐开始接手研发下一代 AI ,这条每 89 天翻倍的曲线甚至还会继续变陡。
2028 年,随口说一句,GTA6 级别的游戏已经可以一句话生成。想看三体第四部,AI 直接生成出来。
5 天前
回复了 Parva 创建的主题 › 随想 › AI 量身定制软件的时代
5 天前
回复了 Parva 创建的主题 › 随想 › AI 量身定制软件的时代
@wudaye 我就是太闲了故意来为此发帖( doge )现在真的是一个/goal 就没我事了。

https://img.li/i/sHu0m4qjhyju.jpg
9 天前
回复了 Parva 创建的主题 › 奇思妙想 › 闲置资源共享变现平台
突然想到个 idea ,让 AI 帮忙捋了捋,自己懒得折腾了,分享出来
把用量提升上去,ai agent 技巧就会有质变,先开个 gpt-pro 20x (不过这两天变得好慢😢)
+1 ,喜提重置
7 月 19 日
回复了 Geeksun2021 创建的主题 › 摄影 › 西湖上空刷新了一只喷火龙
好酷啊 喷火龙
7 月 3 日
回复了 aikilan 创建的主题 › 程序员 › 我只是硅基生物的通信协议
哈哈哈,精辟,脑子:我就是个中间件,别把计算任务往我这塞
“如果你不看代码,那么你的价值何在?仅仅是提需求?提需求的话这活谁都能干。”

实际工作也不是只提需求。程序质量怎么保证,出了问题怎么查、怎么修,最后还是得有人兜底(背锅)
“不阅读代码的程序员会不会被淘汰”

会。「程序员」会被淘汰,就像工业革命中的「手工纺织工人」。但「工程师」不会被淘汰,coding 只是手段,目的是为了解决问题,而不是为了代码而代码。「程序员」是 coding 的人,「工程师」是解决问题的人。

短期来看,「程序员」还不能被淘汰,「工程师」还是得阅读代码,AI 还没到能完全兜底复杂系统的程度。不然像隔壁帖子 vibe coding 做 AI 客服,问题越修越多(也不知道他们最后谁背锅)

我的建议是:架构/底层/核心链路的代码越需要人工把关,业务分支/边缘逻辑可以更多交给 AI ,即使出问题了修复也不难。

以上是个人观点,如果你也赞同,那么问题变成:“如何越少读代码的同时保证质量”
我觉得楼主可以做一个"个人 AI 软件作品"宣传站了,大家都恨不得借此宣传哈哈哈
做了一个将自己觉得有用的 AI 对话给记录和分享的平台。
https://xiaodao.cool/
https://i.imgur.com/DsiR0MU.png
6 月 18 日
回复了 ximaoyang 创建的主题 › 程序员 › claude code 实践心得:飘才是最大的敌人
把“飘”问题拆成几层:

第一层:模型能力不足

第二层:信息不足
1. 用户没有把自己真正想要的东西表达给 AI ,给了 AI 太大的自由空间
2. Agent 没拿到关键文件、关键信息,即上下文工程没做好

第三层:执行过程漂移
1. Agent 之间传递失真
2. Sub-Agent 上下文独立,彼此不统一

第四层:结果缺乏验证
1. 没有建立有效的验收机制,错误结果直接进入下一步
2. 模型觉得自己对,但编译不过、测试挂了

---

建议:

1. 相信 codex 、cc 自身的 Harness Engineering ,不要额外堆太多通用 Multi-Agent 、Rules 、Skill 、插件,容易适得其反

2. 尽可能把结果描述清楚。自己到底想要什么,验收标准是什么。很多时候过程和实现方案没那么重要,结果符合预期就是好结果
AI 接知识库已经是几年前的事了,你还造

关键是不愿意使用你造的 AI 入口

这产品功能当然是加分项,但是,除非体验有数量级提升,否则我不愿意为了这点便利放弃已经形成习惯的 ChatGPT 网页或 app 对话。
1  2  3  4  5  6  7  8  
❮ ❯
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   2756 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 07:11 · PVG 15:11 · LAX 00:11 · JFK 03:11
♥ Do have faith in what you're doing.