你们是怎么解决 CodeX 写代码过于难看的问题的

[Pig930]

RT ，最近主力切换到 CodeX 之后发现 CodeX 会写无穷无尽的胶水代码、兜底代码和一些根本不存在的转换/try-catch 等等，哪怕在 prompt 里详细写清楚需要做的事情，或者用 Opus 4.7 写 plan 再执行也不会有很大改善。仿佛这种倾向刻进 CodeX 骨子里了。今天让它写一个简单的训练脚本，100 行的脚本里有一半是对一个命令行参数是否正确输入的判断，彻底晕了。 之前自己在网上找了一些方法写进 AGENTS.md 里，

## Coding Standard
1. Simplicity First.
2. Failfast instead of over-design, over-engineering, over-error-handling and over-fallbacks
   - Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
   - A simple feature doesn't need extra configurability.
   - Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code andframework guarantees. Only validate at system boundaries (user input, external APIs).Don't use feature flagsor backwards-compatibility shims when you can just change the code.
   - Don't create helpers, utilities, or abstractions for one-time operations.Don't design for hypotheticalfuture requirements. The right amount of complexity is the minimum needed for the current task-three similarlines of code is better than a premature abstraction
   - Avoid backwards-compatibility hacks like renaming unused _vars, re-exporting types, adding // removedcomments for removed code, etc. If you are certain that something is unused, you can delete it completely

And also the coding-rules and other guidelines/skills

也装了 andrej-kaparthy-guidelines, superpowers 之类的 skill ，实在是限制不了。大家有什么建议/经验吗，或者还是说回到 Claude 是更好的选择😭

[Had]

@8355 claude 只会写无穷无尽的注释吧

[zhengfan2016]

@Had 我的 claude 都不写注释，写的比 codex 简洁，我用的默认 sonnet 4.6

[sampeng]

这事有两面性，防御编程本身没错。要求不要兜底也没错。怎么权衡就是人的能力，AI 本质是摇骰子。所以要人去平衡。

[8355]

@Had 默认的会，啰嗦写一堆说明，举个例子给他就不写了，把历史写过的也全改掉了

[lujiaosama]

看起来思考强度只开中还能治 codex 罗里吧嗦的问题？我也是嫌弃一大堆的兜底代码，看起来好累啊

[shunia]

developer instructions 里加一些限制会好很多，比如说尽量 happy path ，代码应当简洁直接，不要引入额外的复杂度和设计模式等。

[shunia]

@shunia #26 这玩意代码写的结果都还可以，但是质量实在是很难顶，不是 codex 的问题，大模型都这样，代码整体实现很不错，但是 review 的时候去读一遍就真的跟吃 shi 一样难受。

[saltbo]

你只在 Agents.md 里写会有注意力漂移的问题。你需要用 subagents 。 定义一个专门负责 CR 的 subagent ，里面写上你对代码的要求。然后在 Agents.md 里定义工作流，要求每次提交之前必须调起 subagent 进行 CR 。 这样就能保证代码写出来是你想要的效果了。 亲测有效。

[swananan]

我现在是写完的代码认真 review 一遍，让它重写几次

[jroger]

可以添加如下提示词试试：

```markdown
## 要求
- 采用面向对象编程思维，禁止流水账式编码；
- 能用设计模式要用设计模式，提高代码质量；
- 代码职责要单一，可维护；
```

把提示词放入项目 `CLAUDE.md`

[Perry]

Red green TDD 写好了 不要管代码好不好看，信就对了，有问题说明测试没写好

[DonaldY]

codex 会按照你本地代码风格的。

[Pig930]

@saltbo 可以分享下 prompt 嘛，非常感谢

[ktyang]

方法就是不看代码

[Qds]

以前领导还让我研读阿里的编程规范手册，让我学习大师的优秀代码，现在 ai 时代，人均 vibe coding 的 时代，感觉意义不是那么大了，以前还在想代码艺术啥的，现在想想还是算了吧

[jaylanzhou]

1. 你对代码的“美观”是如何定义的，除了基础的设计模式之外，每个人或公司的编程要求是不同的，请你自己先整理好相关的 skill
2. 规范分两层，codex 的全局 skill 以及项目的 skill ，全局的 skill 写一些所有项目通用的设计规范，项目的 skill 中写一些项目相关的规范
3. 示例代码，你可以在项目中定义一个 demo 包，写一套你觉得符合要求的示例逻辑，并在 skill 中提示，严格按照此代码结构执行
4. 知识库，大厂的做法是将你每次的 prd 及代码整理出一个汇总文档或者变更日志，放到知识库里，下次 agent 会去参考，到这一步其实就已经是 spec coding 而不是 vibe coding 了，取决于你对项目的稳定性要求多高，每个项目不一样，如果是简单的项目，可以让他写变更日志或总结，直接弄成 md 文档放到项目里