- 主题:有使用过augmentcode的么，看别的论坛说超越cursor了
--
FROM 222.128.189.*
我用过， 全局性比cursor强， 看网上说它对上下文的限制是200K，而cursor是60K.
不过具体到某个局部的实现， 它不如cursor, 不清楚为什么
--
FROM 124.79.64.*
没用过，不感兴趣。
这些本质上拉不开太大差距的，用熟练更重要。
我最近拉了一个7天每天提交量，把我自己都吓到了。
最高的一天我提交了1.4w行代码，平均每天6k行代码。
3个月前我亲测，24小时不睡觉用ai写代码的极限效率是6k行代码。我觉得这已经是我自己都不可逾越的高山了，没想到现在都成为常态了。
以上说的，全部是能通过编译的rust代码，清单：
| 日期 | 新增行数 | 删除行数 | 净变化 |
| :--------- | :------- | :------- | :----- |
| 2025-05-31 | 24546 | 17168 | 7378 |
| 2025-05-30 | 5466 | 2467 | 2999 |
| 2025-05-29 | 19416 | 4986 | 14430 |
| 2025-05-28 | 8302 | 2177 | 6125 |
| 2025-05-27 | 3045 | 1943 | 1102 |
| 2025-05-26 | 7893 | 426 | 7467 |
| 2025-05-23 | 984 | 190 | 794 |
| 2025-05-22 | 2068 | 0 | 2068 |
【 在 stub 的大作中提到: 】
--
修改:lvsoft FROM 101.229.187.*
FROM 101.229.187.*
这些代码不用 review 吗？
是什么类型的代码？
【 在 lvsoft 的大作中提到: 】
: 没用过，不感兴趣。
: 这些本质上拉不开太大差距的，用熟练更重要。
: 我最近拉了一个7天每天提交量，把我自己都吓到了。
: ...................
--
FROM 27.152.110.*
我来review。我现在已经基本不看ai写了啥代码了。我现在review ai的review。
那些提交低谷都是我重度参与的结果。人就是这里面的瓶颈。
而且说实话，你真的用到我这个强度你就会理解，根本就不需要你来review。ai啥都明白，它设计的架构没任何问题。比如涉及的需要密码的场合，我让它先存config.yaml里面临时过度下方便我调试，结果它干的不情不愿的，我强迫他这么干，它起手就是argon2，把这个文件加gitignore，仓库里只有config.yaml.sample，还一直给我强调怕我把这个文件提到git。
就这觉悟秒杀99.99%的人类，人类就是瓶颈，需要你review嘛？
【 在 hgoldfish 的大作中提到: 】
: 这些代码不用 review 吗？
: 是什么类型的代码？
:
--
FROM 101.229.187.*
你这个还是领域相关的， 我写的是RTL与C, C++的混合代码
这方面AI应该没怎么被喂过很多代码，所以有很多常识性的错误，比如sv里import一个C里面的函数， SV里的一个bit [1:0]， 在C侧应该是svBitVecVal*, 但ai容易把它搞成char, 还有相互调用的限制。 绝大多数仿真器是不允许C侧直接调用一个SV中的function的， 需要SV先调用C侧的函数，再在C侧函数里调SV中的函数。 因为ai理解有错，所以写出来的架构和数据流也经常问题。哪怕告诉他这些限制，它还是会犯一些小错。关键在于我不知道AI哪些理解有误，这是需要使用经验的积累的， 用的多了就知道AI对哪些理解有误，这样就能提高效率。
augment对于全局的理解比cursor好，我认为还是有用的，一个大的项目，它分解的比较好。然后局部的实现可以再用cursor来写。
当然人厉害，用什么工具都厉害
【 在 lvsoft 的大作中提到: 】
: 我来review。我现在已经基本不看ai写了啥代码了。我现在review ai的review。
: 那些提交低谷都是我重度参与的结果。人就是这里面的瓶颈。
: 而且说实话，你真的用到我这个强度你就会理解，根本就不需要你来review。ai啥都明白，它设计的架构没任何问题。比如涉及的需要密码的场合，我让它先存config.yaml里面临时过度下方便我调试，结果它干的不情不愿的，我强迫他这么干，它起手就是argon2，把这个文件加gitignore，仓库里只有config.yaml.sample，还一直给我强调怕我把这个文件提到git。
: ...................
--
FROM 124.79.64.*
跟这个关系不大。
我这里因为项目很复杂了，ai的上下文是装不下的，所以你说的这种错误比比皆是。
这么说吧我现在都是关linter写的，因为只要它一做事情马上就是上百个错误，linter满江红已经没意义了。
然后我现在也基本不看ai在干嘛，不看它写的具体代码，我连单元测试都不要了。我觉得单元测试是一种负担，没啥价值只会拖累迭代的灵活性。要可靠性等定型了再去做单元测试和提升覆盖率也不迟。
我现在主要看它写的文档，包括设计文档和分析文档，然后我只做方向性的指示。最后整出来的代码基本上不会有结构上的问题。只会在一些小地方犯一些小错误，比如没有初始化（这些往往还是我的问题，比如ai在文档里说了需要我去建数据库，但我一目十行看漏了之类的），或者通讯协议这里有拼写错误（比如rust这里是snake case, ts哪里是camel case）。归根结底都是因为跳出了rust的语言范围失去了强约束。所以我还是我最早的观点，ai时代rust是唯一选择，可能没有之一。然后新时代编程很多思路都变了，很多你觉得重要的东西现在完全不重要。所以才会有vibe coding这个说法，我现在的ai coding基本上就是意识流，我压根就不关心细节。细节全部由rust去保证。
【 在 eematlab 的大作中提到: 】
: 你这个还是领域相关的， 我写的是RTL与C, C++的混合代码
: 这方面AI应该没怎么被喂过很多代码，所以有很多常识性的错误，比如sv里import一个C里面的函数， SV里的一个bit [1:0]， 在C侧应该是svBitVecVal*, 但ai容易把它搞成char, 还有相互调用的限制。 绝大多数仿真器是不允许C侧直接调用一个SV中的function的， 需要SV先调用C侧的函数，再在C侧函数里调SV中的函数。 因为ai理解有错，所以写出来的架构和数据流也经常问题。哪怕告诉他这些限制，它还是会犯一些小错。关键在于我不知道AI哪些理解有误，这是需要使用经验的积累的， 用的多了就知道AI对哪些理解有误，这样就能提高效率。
: augment对于全局的理解比cursor好，我认为还是有用的，一个大的项目，它分解的比较好。然后局部的实现可以再用cursor来写。
: ...................
--
修改:lvsoft FROM 117.135.83.*
FROM 117.135.83.*
【 在 lvsoft 的大作中提到: 】
: 跟这个关系不大。
: 我这里因为项目很复杂了，ai的上下文是装不下的，所以你说的这种错误比比皆是。
: 这么说吧我现在都是关linter写的，因为只要它一做事情马上就是上百个错误，linter满江红已经没意义了。
: ...................
不linter怎么用, 最后编译再纠错么
--
FROM 61.48.14.*
所以要rust呀，rust能编译过就基本没啥错误了。
【 在 stub 的大作中提到: 】
: 不linter怎么用, 最后编译再纠错么
--
FROM 117.135.83.*
架构上的东西是非常重要，但这需要AI对这个领域要比较深的理解，这样他才会有个60分的东西出来，人工再指导迭代一下，很容易达到90分， 可能自己写也就80分。
但在有些领域，AI训练的语料明显是不够的，这时候出来的设计大方向是有问题的。
自顶向下的设计方法是非常好的， 和AI一起工作， 先让他写arch spec，再design spec, 再module spec, 再实现和UT。 我年初的时候用cursor (sonnet 3.5)尝试过，但不太成功，我设计的是一个比较复杂的软硬件协同模型（一半是RTL一半是CPP), 两者互为一体。我对一些细节也没有思考清楚，或者没考虑到，所以代码都写的差不多了，才发现性能有问题，要推翻重来。输入了很多细节，但只要有一些细节没提到，AI就出错。
我觉得你能发挥AI最大的作用，前提还是你对你自己做的东西比较清楚，哪怕AI有不足可以比较清楚的说清楚。这个是要很多积累的。
而我在做一些探索性的feature时，我并不清楚全部细节，遗漏了一些东西，那么出来的东西完全不对。
【 在 lvsoft 的大作中提到: 】
: 跟这个关系不大。
: 我这里因为项目很复杂了，ai的上下文是装不下的，所以你说的这种错误比比皆是。
: 这么说吧我现在都是关linter写的，因为只要它一做事情马上就是上百个错误，linter满江红已经没意义了。
: ...................
--
FROM 124.79.64.*