跟这个关系不大。
我这里因为项目很复杂了，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.*