问HN：我握得不对吗？
我一直在努力将最新的模型融入我的工作流程中。最近我主要使用Codex，但我仍然遇到了一些困难。
例如：无论我怎么做，我都无法阻止Codex引入代码检查错误。
我使用制表符而不是空格进行缩进。似乎这个模型在处理使用空格编写的代码时有很大的偏好（显而易见）。尽管我有一个非常清晰的风格指南（Codex在检查我的代码库后帮助我编写的！），明确规定使用制表符进行缩进，但模型还是会随意进行一些更改，随机地引入空格。在某些地方，它会正确使用制表符，但在同一文件的后面部分又会回到使用空格。
我有一个代码检查工具，我已经教会模型运行它来捕捉这些问题，但A) 这感觉像是在浪费令牌，B) 模型经常忘记运行代码检查工具。
这就像是有一个从未使用过制表键的初级开发者。他们有时会记得在打开PR之前将空格转换为制表符，但并不是每次都能做到。因此，我不得不一次又一次地给他们相同的反馈。
这个例子——使用制表符而不是空格——只是模型似乎总是收敛于由软件“钟形曲线”中心决定的局部最优解的一个特定案例。但总的来说，我发现这几乎适用于我想要强制执行的任何“古怪”风格意见：
- 避免使用TypeScript的`any`或`unknown`：模型仍然会乐于引入这些以让编译器满意。
- 避免复杂的三元表达式：不，模型喜欢这些。
- 避免难以理解的一字母变量与更长的自描述变量：不，`a`就是了。
我感觉我正在使用一个非常擅长产生普通软件开发者平均输出的工具。它无法在进行我想要的更改时，将我的审美/架构需求放在思考的前面。就像我雇了《记忆碎片》中的那个家伙作为实习生。
除了不断强调无论如何都要使用制表符（从而浪费宝贵的令牌）之外，人们是如何解决这个问题的？
除了语法之外，我仍然能够使用这些模型粗略地实现新功能或特性，但它们编写代码的方式感觉……不够优雅。模型在处理特定任务时，往往能够抓住一个单一的统一见解，从而大大简化它所写的代码，但它在没有我告诉它这个见解存在的情况下，无法意识到这一点。
查看原文
I've been steadfastly trying my best to incorporate the latest-and-greatest models into my workflow. I've been primarily using Codex recently. But I'm still having difficulties.<p>For example: no matter what I do, I can't prevent Codex from introducing linter errors.<p>I use tabs instead of spaces for indentation. It seems like the model is massively weighted on code written using spaces (duh). Despite having a very well articulated styleguide (that Codex helped me write after examining my codebase!) that clearly specifies that tabs are used for indentation, the model will happily go off and make a bunch of changes that incorporate spaces seemingly at random. It will use tabs correctly in certain places, but then devolve back to using spaces later on in the same files.<p>I have a linter that I've taught the model to run to catch these things, but A) that feels like such a waste of tokens and B) the model often forgets to run the linter anyway.<p>It's like having a junior developer who has never used the tab key before. They remember to ctrl-f their spaces->tabs sometimes before opening a PR, but not all the time. So I wind up giving them the same feedback over and over.<p>This example -- tabs instead of spaces -- is just one specific case where the model seems to invariably converge on a local maximum that is dictated by the center of the software bell curve. But in general I'm finding it to be true of just about any "quirky" style opinion I want to enforce:<p>- Avoid Typescript's `any` or `unknown`: the model will still happily throw these in to make the compiler happy<p>- Avoid complex ternaries: nope, the model loves these<p>- Avoid inscrutable one-letter variables versus longer, self-descriptive ones: nope, `a` it is<p>It just seems like I'm using a tool that is really good at producing the average software output by the average software developer. It's not able to keep my aesthetic / architectural desires at the front of its thinking as it's making my desired changes. It's as if I hired the guy from Memento as an intern.<p>How do people get around this, other than slathering on even more admonitions to use tabs no matter what (thereby wasting valuable tokens)?<p>Beyond syntax, I'm still able to use the models to crudely implement new features or functionality, but the way they write code feels... inelegant. There's often a single unifying insight within grasp that the model could reach for to greatly simplify the code it wrote for a given task, but it's not able to see it without me telling it that it's there.