bear330

@extrem 他们想让我们这么用, 因为项目越来越大, 被 LLM 搞得重复越来越多, 理论上你给他足够时间和足够的 token, 还有足够多的 test case 它还是可以修正, 这里重点是: 1. 不 review 是不行的, 只是 review 的是 production code 还是 test case, 那也是 code 2. 是改得好, 但成本会累加之后改一个问题就越花越多, 越改越久, AI 公司就想要我们这样玩

有人主张, 不要 review code, 而是要求 test, 只要 test 会过, 基本不管它写了什么, 有点像我们现在像不会去 review compiler 产生出来的 assembly 的意思像现在 openclaw 就是这个流派的最大宗 => “Don’t review code; review output / tests passed” 我个人觉得根本狗屁不通(强调只是个人观点), 理由是:

1. compiler 是高度确定性的而且严格验证的, 但 LLM 不是 =>
叫 LLM 产生 test case 有时候 test case 本身都是假的或质量不到位的, 那就算 test 过了也不表示没有问题你至少得去 review test case (所以完全不 review 应该不太靠谱)

2. 再来 LLM 因为 context window 及 RAG 能力不足的关系 =>
只能看到项目的部分无法关心全貌, 导致产生的源代码会极度多的重复内容, 完全不 DRY, 而这导致不符合 single source of truth 在需求变动或修改错误时, 很可能产生大量的不一致

3. 而 LLM 的 context window 有极限 =>
不但是现阶段有极限, 未来也很难突破极限(训练资料问题), 所以 2 是无解的

4. 这表示针对 2 来说, 除非你的 test case coverage 接近 100%, 不然一定有很多奇奇怪怪没改到没一致的边角 bug =>
而 test case 过了也可能一团糟, 那除非你把 test case 设计得很严谨, 这回到了 1, 你必须很认真的 review 大量的 test case, 如果你想要都不 review LLM 的 code 的话, 但 review 大量的 test case 而 test case 本身也是 code, 也被 LLM 同 2 大量的 copy/paste, 你 review 起来也是一样累, 不然就是要让 LLM 在这里很严谨的作, 这导致鸡生蛋蛋生鸡, 你只是把 review production code 的心力换成了 review test code

所以只看 test case 会过而不去管 code 这个方法论, 有基本的问题, 更像是种 ai hype, 听起来很爽, 但实务上问题一大堆, 只是把一个问题换成了其它问题

如果您是想找 p2p 工具, 要不试试我的? 也流量免费的 https://github.com/nuwainfo/ffl