V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sampeng  ›  全部回复第 3 页 / 共 218 页
回复总数  4354
1  2  3  4  5  6  7  8  9  10 ... 218  
尊重他人命运 放下助人情节。。你们相信这是一个工作 n 年人都没意识到的问题???

最多说 1 次,第二次爱改不改,又不是我写的代码。老板问就是代码不是我写的,问题没出我这。除非我是 leader 或者项目负责人,那是另一回事。
34 天前
回复了 6166aa 创建的主题 程序员 cursor + figma mcp 项目模板及 ai 讨论
@blankmiss

@Mr54 我试过。只能从 figma 读,不能反过来。我其实是想找反过来的,利用 mcp 让 AI 帮我去做图。。
35 天前
回复了 6166aa 创建的主题 程序员 cursor + figma mcp 项目模板及 ai 讨论
你自己做 figma ?还是有提供 figma 的?没看到 figma 有可以出设计稿的 mcp 啊。
哦。你看看 10 几年前的计算机科学专业,是不是一地鸡毛。我看起来人工智能专业和这个是一回事。
哪有什么工资。。那是房贷,信用卡钱公司暂时帮你保管而已。
慢慢的,发现 ETF 波动还是有点低,加上雅江那个什么新闻让西藏天路涨了好几天,很眼红,我开始买个股


你不亏谁亏。。。你就是在赌博而已。不懂就无脑 etf ,etf 亏 20%需要点时间得。
35 天前
回复了 activeliangg 创建的主题 程序员 和前端小姐姐吵起来了
你们 leader 呢? leader 这个时候装死?
35 天前
回复了 engongong 创建的主题 程序员 请教前端大佬一个跨域保存 cookie 问题
别人的?你要是可以那不叫跨域,那叫偷 cookie😂
35 天前
回复了 hamsterbase 创建的主题 程序员 程序员不应该在 ai 上省钱
我其实不太赞同 200 刀档的。20 就可以了,100 是极限了…200 档不做自己项目就有点自我感动了
36 天前
回复了 hamsterbase 创建的主题 程序员 程序员不应该在 ai 上省钱
问题就是。投进去 1450 人民币。带来的到底是情绪价值还是所谓的效率提升?是不是应该打个问号?
36 天前
回复了 5sheep 创建的主题 生活 农村户娶了城市户,孩子上哪那边的户
首先。。先问问有没宅基地,有没有分土地。我记得这几年确权后就没分地这种事了。唯一的优势只有拆迁赔偿。或者偶尔的天降祥瑞(去年北京大水没淹,结果按人头算一人給 8000 )。但我是觉得无论如何都比不上城市户口啊。就为了那后面没有任何保障的几桶油,读书的时候要折腾,看病啥玩意都要折腾。
都大差不差,但搞个流程图的都是向上管理的
37 天前
回复了 iflyapi 创建的主题 职场话题 为什么公司里会有那么多人拼命工作?
如果认真工作被嘲讽太卷,这个社会的价值观真的完蛋了。
我在设计一个 mcp ,当前 mcp 是 spec 的一个架子。像这些约束不好处理的,我打算用外部 mcp 来逻辑强制串联来解决。比如 tdd 是标准流程,可以通过 mcp+hooms 来串联强制检查每一步的结果,自动在代码层逻辑上强制设置状态。在考虑咋做 ing…
@Philippa 回车快了…你猜为什么我的提示词里

Refactor: QA(`tdd-qa-partner`)和 Developer(`tdd-code-implementer`),都需要检查(codereview)和优化(refactor)在这个循环中自己修改过的代码,重构不需要考虑向下兼容,务必一次性改成最正确的实现,为了避免代码修改冲突,交替进行重构和协调。不能并行执行

这里在优化和检查要用英文解释?嘿嘿,因为我还有 zen-mcp-server 。这两个字是关键词。重构和检查阶段是由外部的 gemini 和 opus 共同 review 和检查提出想法后嚷 sonnet 来解决的。效果相当可以,每次都能发现一些实现的小问题和 bug
@Philippa 你说的其实没错,这是降低效率的行为。但是正确率上升了。测试覆盖的还不错,逃不过自己的 review 。我认为这是不可缺少的一步,比不可控的练丹是要强很多的,哐哐哐写一堆没用代码和一次写好代码还是有区别的,我愿意接受慢一点但是整体接受率提升。

还是有细节区别的,我昨天对比过不用 agents 和不用 tdd 。
1.单元测试更详细了,因为有 spec ,可以先仔细 review 单元测试有没错。
2.最后的 tdd 的最后的重构阶段效果让我眼前一亮,因为一直以来困扰我的全自动拉屎得到了缓解,可以看到代码质量在最后重构阶段会大幅度提升。
3.green 阶段不再一口气写一大堆看起来很牛逼但是没卵用的垃圾代码,不对、不是不会,是在大幅度减少,因为 green 阶段是参考单元测试,以单元测试为目标写最小化代码。我经常看到注释里:这个实现先简化,因为单元测试要求只处理 xx 情况。
4.整体流程可控,在 plan 阶段发现不是 tdd 就可以提前取消了,要求严格保证

不过你说的问题是存在的,比如偶尔 skip 掉状态设置,还是提示词没约束好。我也在改进,不要让在 agent 阶段做,让主控在一个循环的前后进行操作,这个可以在 todowriter 里观察到,没有就重来。


慢我觉得慢慢迭代 cc 会解决的,昨天我一直在 debug 观察到底啥慢。还是要官方下场解决更新。但 token 消耗确实很莫名其妙…找原因中…一个可能是 agents 的上下文处理和主控不一样。其实观察 ccusage ,每小时的 token 消耗只是大了 20-30%,但代码生成数也多了 20-30%(因为单元测试更详细,非常的规范)。问题还是出在慢上面。
我要知道我会告诉你?
@zqguo 都不用再改,在要求里不让他用子代理。消耗 token 就少一个数量级了。。我也在调查。。这个子代理的 token 消耗多的不能理解。。我 max 都会吃 cd 。但不用子代理。依然进行 TDD 。效果也不差,可能会不稳定。我调查 ing 。。。总的来说是一个思路。。
@Philippa 有一点搞错了。核心并不是上下文,而是 TDD 的流程。
在 agent 看来。1 ,2 ,3 都是上下文。这是很自然的事。如果是我做。就是一个 issues 是总需求,3 个子需求是 1 ,2 ,3 。
这样 tdd 的流程就是

RED 阶段:QA ,知道人和动物的 class 是怎样的,创建人应该预期是什么样,结果是如何。然后针对这个编测试代码。预期失败
GREE 阶段:Developer ,知道人和动物的 class 是怎样的定义的,行为是什么。根据测试代码。编写实际的创建人的代码。
重构阶段:QA 和 Developer 交替优化各自的代码,清理临时函数,拆解大函数,检查是不是真的完成了创建人这样的动作。

这是一个 TDD 循环,再做创建人物的 TDD 循环。最后做人物去摸宠物的 TDD 循环。

你理解的是一个 agent 干所有事,并不是这样的。agent 是把这些需求作为上下文。目的是什么在创建 context 的时候会明确的说明。

我尝试这个流程,搞出奇怪 code 的原因基本是自己上下文没说清楚或者说没有 review 。

AI 是工具,不是魔法。我没打算一个需求給他,就自动 spec+tdd 完事了。这是不可能的,质量没法保障。我要事先 review 上下文的顺序是否合理,内容是否能够指导开发。主控的 prompt 的过程我会先 plan 模式看一眼是不是理解偏差了。

我这只是方法论。我有个暴论,通过一个工具,一个命令,在人完全不参与的情况下就把需求完全实现并且代码质量都极其好的都是吹牛逼。
1  2  3  4  5  6  7  8  9  10 ... 218  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3035 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 12:06 · PVG 20:06 · LAX 05:06 · JFK 08:06
Developed with CodeLauncher
♥ Do have faith in what you're doing.