这两天被 codex 折腾的受不了,提的需求过度设计,写的代码一坨一坨的,明明很简单的一个逻辑,硬生生给你拆几个文件搞个几百行,已经让他参考目标框架和代码结构了,就是听不懂,还喜欢测试,改一行代码,会生成一坨测试文件又是编译又是测试的,md 最后发现整个仓库测试代码比我业务代码还多,像 golang 这种喜欢把测试代码和业务代码放一个包下的编程风格,看起来头大
这两天被 codex 折腾的受不了,提的需求过度设计,写的代码一坨一坨的,明明很简单的一个逻辑,硬生生给你拆几个文件搞个几百行,已经让他参考目标框架和代码结构了,就是听不懂,还喜欢测试,改一行代码,会生成一坨测试文件又是编译又是测试的,md 最后发现整个仓库测试代码比我业务代码还多,像 golang 这种喜欢把测试代码和业务代码放一个包下的编程风格,看起来头大
|
honjow13h 7m ago
1
|
|
wenqiang120813h 6m ago
2
https://github.com/unclebob/ub-mode 试试这个 我这两天用的还行
|
|
zed101813h 3m ago
3
|
|
durban12612h 59m ago
4
解决办法是放弃使用
|
|
5
用 medium ,然后提示词里提一嘴就行了😅
|
|
MrTerrorist12h 52m ago
6
Ponytail 、https://github.com/uucz/moyu 、https://github.com/lennney/stop-that-shit 只能选一个试试,还有就是人工时不时盯着,必要时及时在会话中引导
|
|
dallaslu12h 37m ago
7
.gitigore
``` *_test.go ``` (doge |
|
Lukedis11h 39m ago
8
我不让测试的时候,codex 不会测试,没有不要求的时候,就是正常的测试流程,我编写了测试规范,不做测试不太敢用,单元测试、性能测试、压力测试,例如:任务清单有好几项任务,我要求完成所有的任务,再做测试,codex 就是按照要求处理,没有要求的时候,每完成一项,就正常走测试流程,我有编写工作报告的规范,codex 每完成一项任务,都需要编写对应的工作报告(基准是什么、业务目标是什么、动了哪些文件、旧的示例代码和测试代码是否同步修改、证明为什么符合业务目标),然后我让其他 AI 审核,我还是更喜欢代码健壮的,许愿式编程,属于是瞎几把写,管杀不管埋,能用就行
|
|
Lukedis11h 32m ago
9
代码的屎坑多了,AI 也改起来也难
|
|
10
这样的风格是对的,要适应 AI 的这种风格。
|
|
gdm11h 4m ago
11
AI 和人不一样他们需要这种设计来保证运行无误,选择 AI 编程就要忍受这个
|
|
12
|
|
DuskRift10h 0m ago
13
你又不写代码 管那么多
|
|
MarkLeeyun9h 38m ago
15
同感。我的经验是:把"最小改动"写进 AGENTS.md 之类的项目规范里,明确要求"不新增文件、不新增抽象、不写测试除非我要求",并且每次只给一个小任务,做完先 review 再继续。另外让它先输出改动计划(要改哪些文件、多少行),确认后再动手,能挡掉大部分过度设计。
|
|
bytenoob9h 21m ago
16
最好的方式就是换 claude
|
|
hahiru9h 6m ago
17
AGENTS.md 里面的必填项。
## 硬约束(任何 AI 会话都必须遵守) 1. **每个功能按满足当前需求的最简单方式实现。** 复杂度必须由真实需求驱动,不允许"为将来预留"的抽象。 2. **单实现不写接口。** 只有一个实现时不建 `IXxx` 接口、不建工厂/提供者/路由器。 3. **不写需求外的东西。** 新模块、新配置项、新接口必须先和用户确认。发现"顺手能做"的功能,提出来,不要直接写。 4. **没有消费者的代码不进仓库。** 接口必须有真实前端调用方才实现;文档明确"不做"的功能一行代码都不留。 5. 上一个版本( XXX3.0 )因违反以上原则积累了约 1/3 死代码(推荐引擎、AI 任务中台等),本仓库以此为戒。 |
|
htxy19858h 33m ago
18
唉,claude 不让我们用,codex 让用的又这么拉,一点都对不起那么贵的价格,难绷。实在不行用国模了,反正都是拉,大哥不笑二哥,凑活用吧。
|
|
19
@htxy1985 这个月到期不打算续费了,今天测试了一个中转的 claude ,使用模型指纹测试 opus5.5 实际是 hiku4.6 ,偶尔会路由到 opus4.6,反正不是 opus5.5,中转站的坑还是不能趟,官方又封号,是在不行国模顶一下吧
|