那个功能真的已经没有了，据我所知，产品中再也没有类似的功能了。我认为你能做的最好的事情如下：
1.创建一个新项目。
1.将项目设置更改为所需的任何设置。
1.更改默认项目中您不喜欢的任何其他内容，例如{ Private declarations }。
1.将此项目添加到存储库。
1.使用文件|新增|自定义以将此项目模板移动到文件中|新的菜单，方便访问。

Project->Options->Target。您可以设置基本配置，然后为Debug和Release提供与基本配置不同的选项。您还可以创建自定义选项集。这意味着它们不同于标准的Debug和Release。您还可以根据不同的目标进行不同的配置（VCL应用程序的调试版本与FMX应用程序的调试版本具有不同的选项，等等。）
要更改默认选项，首先要定义“默认”。您可以从低至“基本配置”开始，通过Project->Options->Delphi Compiler，然后选择All Configuration目标。您可以通过更改Debug和Release配置的基本配置来稍微细化它。您还可以定义自己的选项集，使用Target列表旁边的Save按钮。
您关于“将选项指定为多个项目的默认选项”的具体问题是指base configuration。从那里，您可以细化这些基本选项，以给予调试设置和发布设置（也可以保存为初始默认值，并在每个项目的基础上进行细化）。
因此，对于具体的答案，您可以通过修改base configuration来更改默认值，或者通过修改从该基继承的debug或release配置来获得更具体的答案，这取决于您的最终结果需要是什么以及您要尝试完成什么。

我有一个"默认"项目。所以，我从不启动一个新项目，而是复制那个项目。那个"默认"项目为我做了很多额外的事情，包括improved support for TApplication。
你确实是对的，任何应用程序/项目都不应该在没有溢出检查、范围检查和Assert默认打开的情况下启动（对于调试版本）。
当然，还有更多的设置应该在默认情况下打开，以便进行正确的调试。
也可以像大卫展示的那样（存储库）。但我更喜欢手动操作（复制）优秀的总指挥官的文件和文件夹。

• • 溢出检查**

这将检查某些整数算术运算（+、-、*、Abs、Sqr、Succ、Pred、Inc和Dec）是否溢出。例如，在+（加法）运算之后，编译器将插入附加的二进制代码，以验证运算结果是否在支持的范围内。
当对整数变量的运算产生的结果超出该变量的范围时，就会发生"整数溢出"。例如，如果将整数变量声明为16位有符号整数，则其值的范围可以是-32768到32767。如果对该变量的运算产生的结果大于32767或小于-32768，发生整数溢出。
发生整数溢出时，操作的结果是未定义的，可能导致程序中出现未定义的行为：·Wrap-around结果可能会产生一个wrap-around值，这意味着数字32768实际上会存储为1，因为它比我们能存储的最大值高1个单位（32767）。·截断结果可能会被截断或修改，以适合整数类型的范围。例如，数字32768实际上将被存储为32767，因为这是我们可以存储的最高值。
未定义的程序行为是最严重的错误之一，因为它不是一个容易重现的错误，所以很难跟踪和修复。
如果您激活此选项，需要付出很小的代价：程序的速度将稍微降低。

• • IO检查**

检查I/O操作的结果。如果I/O操作失败，则会引发异常。如果关闭此开关，则必须手动检查I/O错误。如果激活此开关，则需要付出较小的代价：程序的速度将降低，但并不显著，因为与I/O操作本身所需的毫秒级时间相比，此检查引入的几微秒根本算不上什么（硬盘驱动器很慢）。

• • 范围检查**

Delphi极客称之为"最重要的Delphi设置"，我完全同意。它检查所有数组和字符串索引表达式是否在定义的范围内。它还检查所有标量和子范围变量的赋值是否在范围内。
下面是一个示例代码，如果范围检查不可用，它会毁了我们的生活：

Type 
    Pasword= array [1..10] of byte; // we define an array of 10 elements
…
x:= Pasword[20];       // Range Checking will prevent the program from accessing element 20 (ERangecheckError exception is raised). Security breach avoided. Error log automatically sent to the programmer. Bruce Willis saves everyone.

• • 启用运行时错误检查**

要激活运行时错误检查，请转到"项目选项"并选中以下三个框：
在"项目选项"

中启用运行时错误检查

• • Assert**

一个好的程序员必须在代码中使用Assert来提高程序的质量和稳定性。说真的，伙计!你真的需要使用Assert。
Assert用于检查在程序的某个点上应该始终为真的条件，并在不满足条件时引发异常。在SysUtils单元中定义的Assert过程通常用于执行Assert。
你可以把Assert看作是穷人的单元测试。我强烈建议你深入研究Assert。它们非常有用，而且不需要像单元测试那样多的工作。
典型示例：

SysUtils.Assert(Input <> Nil, ‘The input should not be nil!’);

但是为了让程序检查我们的Assert，我们需要在项目设置-〉编译器选项中激活这个特性，否则它们将被忽略，就像它们不在我们的代码中一样。确保你理解我刚才所说的含义!例如，如果我们在Assert中调用有副作用的例程，我们会搞砸。在下面的例子中，在调试过程中，当Assert打开时，Test（）函数将被执行，并且"This was executed"将出现在备忘录中。2然而，在发布过程中，该文本将不会出现在备忘录中，因为现在Assert被简单地忽略了。3恭喜，我们刚刚使程序在调试/发布模式下有了不同的行为。

function TMainForm.Test: Boolean;
begin
 Result:= FALSE;
 mmo.Lines.Add('This was executed');
end;

procedure TMainForm.Start;
VAR x: Integer;
begin
 x:= 0;
 if x= 0
 then Assert(Test(), 'nope');
end;

下面是一些如何使用它的示例：
1要检查输入参数是否在0..100范围内：

procedure DoSomething(value: Integer);
begin
  Assert((value >= 0) and (value <= 100), 'Value out of range');
  …
end;

2在使用指针之前检查它是否不为空：

Var p: Pointer;
Begin
  p := GetPointer;
  Assert(Assigned(p), 'Pointer is nil');
   …
End;

3在继续之前检查变量是否具有特定值：

var i: Integer;
begin
   i := GetValue;
   Assert(i = 42, 'Incorrect response to “What is the answer to life”!');
  …
end;

Assert也可以通过在项目选项中定义NDEBUG符号或使用{$D -}编译器指令来禁用。
在某些情况下，我们还可以使用Assert作为处理错误和异常的更优雅的方式，因为它更具可读性，而且它还包括一个自定义消息，这将帮助开发人员了解哪里出错了。

就我个人而言，我经常在例程的顶部使用它来检查参数是否有效。
激活这个特性会（自然地）使你的程序变慢，因为...嗯，有一行额外的代码要执行。
"没有什么是免费的"
一切美好的事物都是有代价的（幸运的是，我们的代价很小）：启用运行时错误检查和Assert会降低程序的速度，并使程序变得更大。
现在的电脑有很多内存，所以内存的微小增加是无关紧要的，所以我们先把它放在一边，但让我们看看速度，因为这不是我们可以轻易忽视的：

Type                 Disabled   Enabled
Range checking       73ms         120ms
Overflow checking    580ms        680ms
I/O checking         Not tested   Not tested

正如我们所看到的，程序的速度受到这些运行时检查的强烈影响。如果我们有一个程序，速度是关键，我们最好只在调试期间激活“运行时错误检查”。我所做的，我也让它在第一个版本激活，并等待几个星期。如果没有错误报告，然后我发布了一个更新，其中“运行时错误检查”关闭。
就我个人而言，我让“IO检查”始终处于活动状态。由于这种检查而对性能的影响是微观的。

重要警告：

如果你有一个已经存在的项目写得不太好，并且你激活了下面的任何一个运行时错误检查，你的程序可能会比平常更频繁地崩溃。运行时错误检查例程并没有破坏你的程序。它总是被破坏--你只是不知道。运行时检查例程现在正在寻找所有那些代码可疑、低劣和发臭的地方。运行时检查的唯一目的是查找程序中的错误。