以下 case 使用模型均为 gpt5.5 xhigh

TLDR

当前最厉害的模型之一

• 做事靠谱吗？ 大部分靠谱
• 会有幻觉吗？ 会
• 会偷懒取巧吗？ 会
• 会为了做而做吗？会
• 会生成屎山代码吗？ 会
• 会使得整体项目更复杂还是更简单？ 看你怎么用

所以

• 我们要 review 生成的代码吗？ 要
• 当前能做到交给 Agent 一个任务，之后看都不用看直接合并吗？ 暂时不能，大概率翻车
• 要为代码负责吗？ 废话，你的 PR，你的代码，你的锅

建议：

• 复杂任务尽量用最好的模型
• Agent 说 job done 之后，用另一个 模型 交叉 review 【重点：交叉验证，不同模型能力、关注点不一样】
• 提交 PR 前后，人工 review 【重点：为自己的产出负责】
• 对于 review comment（不管是来自于 Agent，还是人）， 先阅读，反向读代码，理解后做判断 【重点：不要让 Agent 直接去修 comments，修多了或修少了都有可能，没有自己的理解和判断，永远积累不到经验】

过度防御

某些模型（gpt) 或者某些场景下， Agent 总是过度防御

例子： 命名 view 层有限制大于零，调用链上每一层都防御 【大概率是没读到，没理解上下文】

代码能用是能用，可读性非常差

无意义到包装或转发

Proxy function or methods

@staticmethod
def wait_release_done(release_history_id: int, timeout: int = DEFAULT_WAIT_RELEASE_TIMEOUT) -> str:
    return wait_release_done(release_history_id, timeout=timeout)

这个更过分， 先封装成对象 - 在 proxy method 中再转成id

Proxy constants

甚至，模块 export 代理

不会删掉没有调用的dead code

只要能解决问题，什么方法都行

lazy import to avoid cycle import

其实应该 break the cycle

丢失掉所有有用的注释

怎么写着写着，注释越来越少，干净又整洁

超级复杂的实现 vs 看似取巧的变通

你告诉它这个字段会导致一个注入，然后，它就去解决这个注入

增加一个非常复杂的 escape 方法 vs 舍弃掉这个字段

你告诉它这个 version 有个注入， 它专心去解决注入，但是实际上这只是一个版本号，合法就不会出现注入问题

解决注入 vs 校验合法性

相对保守不改变函数的协议带来的复杂度

半吊子的封装

嗯，复杂的逻辑封装成函数了， 但是，这两个 except 是怎么回事？

LockTimeout 和 ReleaseError 实际上也属于 release_to_stages 的上下文

看一个更典型的， 你或许不会犯第二次错误，但是 Agent 会

小心 noqa

如果我的变更命中的你的规则，那么一定是你的规则有问题，改一下绕过去好了

规则存在的目的并不是为了被破坏

注：这是个proxy method， 最终删掉了

下面这个就厉害了，为了解 import 顺序导致的循环引用， 偷偷塞了一个 （其实我第一轮都没注意到，review 其他 noqa 的时候搜到的）

应该去解决循环引用，而不是通过 import 顺序绕过循环引用， 然后通过 noqa 绕过import order 检查