Answers:
让我们改写一下：
一个好的自动代码生成器的成本值得吗？
是。
劣质的自动代码生成器的成本是否值得为其他人创造更多的工作，但值得作者付出？
绝对不。不好的代码没有任何借口。如果有人想变得聪明并使用自动代码生成，那么他们应该花一些时间来确保生成的代码是好的代码。否则，这有什么意义？它只是在推动代码生产，而在代码生产方面，美元应该停止在编写它的开发人员身上。
生成器生成的代码绝不能手工维护。如果需要更改，则必须调整发生器和/或其设置，然后再次运行。考虑到这一点，只要生成机制本身非常清晰，生成的代码是否令人费解且没有文档记录都没关系。（请确保记录以下事实：生成代码，生成器在哪里以及其工作方式。）
打个比方：虽然我的计算机的处理器始终在执行机器代码，但只要知道如何使用高级语言和编译器创建该机器代码，我就无需了解任何信息。我听说GCC有时会产生低于标准的机器代码，但是只要它能完美运行，谁会在乎。数据库抽象层会生成与DB引擎一起运行的SQL，但是只要抽象层清晰且有效，谁会关心SQL的外观？
如果使用得当，代码生成器无疑不仅可以节省创建成本，而且可以节省维护成本。
代码生成器是一种编译器。您不必担心编译器输出的美观程度，只需使用源代码即可。使用它然后进行手工修改输出通常比仅仅以人类可以理解的形式从头开始编写更难，并且这意味着您无需大量工作就无法再次使用代码生成器，因为您必须应用对相同的难以理解的代码进行相同的更改。
因此，如果它们是构建过程的一部分，并且如此进行记录，则可能会很好。生成器的输入就是源代码，生成的任何内容都是中间结果，不要被弄乱了。
但是，如果某人使用一个人生成了难以理解的代码（该代码原本应该用作源代码），那么该人就会生成错误的代码。人们是通过机械方式还是手工方式生成错误代码都没有关系，这仍然是错误代码，并且您仍然会遇到质量问题。
因此，您需要将此视作其他开发人员偷工减料并编写错误的代码。我不知道你在商店里怎么处理。
从其他答案的评论看来，您似乎是在问团队标准，而不是代码生成器本身。
代码生成工具应包括在项目中，并且（在适当情况下）应作为构建过程的一部分。我们团队中的一个例子就是我们使用Subsonic 2.2，我们已经从构建时的数据库对象生成了类。
执行此操作的exe作为项目的一部分检入SVN，以便团队的新成员可以从svn获取新项目并立即进行构建，而不必弄清楚所有这些数据库类的来源（在本示例中，甚至不将生成的代码包含在svn中）。