最重要先把代码架构规范好，什么东西放哪里，然后是代码规范，命名规范，日志规范等等，可以写到agent md 里面。过度封装什么的就需要人去review code 了，一开始最好规划好业务逻辑，数据流转什么的

感谢佬友，我就用你这一堆结果，让 codex 跟着这类缺陷把代码修回去就好一些了

说实话，使用codex对项目进行迭代确实一个很难受的事情， 我深有体会，但没办法，如果只是迭代一版，或者说能跑就行，那就用codex一直改，如果不是，那还是先搞懂代码架构，然后一点一点的用codex改架构

佬说的有道理，这方面确实没有注意，还得自己下来研究一下

这是gpt的老问题，代码不像人写的，claude模型的代码可读性好很多，claude-like的模型，例如glm都会比gpt好很多

（帖子已被作者删除）

^-^这个问题在最早的时候就想过了，首先看你们公司内部是否有规范，如果有就总结成doc或者我比较简单直接整到agent.md里面，如果没有规范那就在一开始的时候生成这个规范，然后另外我还会配套codereview的graph写协助，每次开发基本上都要把方案 文档都整的比较清楚再开发，做完还会review一遍，如果业务非常核心重要，建议人工 + ai review 让ai带你走一遍代码过程

真的吗，我目前就用过gpt和gemini的模型，有机会试试其他的

ai写的交给ai解决。gpt解决不了的，fable接手解决。

看别人写的代码或者接手别人代码迭代本身就很耗费时间和精力, 你想一下子看明白是很难的, 特别是自身水平没有那么高的情况下, 除非你的规则定得很细, 每一个需求都是你描述实现思路AI再生成

没有规范，看来只能自己积累了 ^-^

我review之前一般先让他写注释

你可以试试写个agent来帮你review 和 测试。

我承认自己是放手派，已经放弃看代码了，好几次让ai重构完，想接手看看，最后都没有时间直接放弃啦。