春节刚过那阵子，我把 codex 装在一台开发机上，想着先跑两天看看手感。结果第一天就有点难受：它每次动文件之前都要停下来问我一句，模型也总是走默认那个最快但不太靠谱的档位，遇到要改多个文件的重构任务，回答经常半途而废。我当时的第一反应是“这工具不行”，后来才发现问题根本不在工具本身，而在我从没认真打开过~/.codex/config.toml。绝大多数人第一次用 codex，都是敲一句codex就开干，配置文件一直是安装时生成的那份空白模板。等用久了，才发现模型、审批、沙箱、MCP、项目级指令这些东西全要靠 config.toml 来捏。

这篇就聊 codex 的 config.toml 配置。我不会把文档里的字段表抄一遍，那种东西查文档更快；我更想讲清楚每个配置项背后的设计意图、它在实际任务里怎么影响模型的行为，以及哪些字段一旦配错会出现“看起来没报错，但就是不对劲”的诡异现象。适合刚装好 codex 想把它调到顺手的中级用户，也适合要给团队统一下发配置、但又不想把权限放得太开的负责人。看完至少能做到三件事：知道配置从哪来、知道每个关键字段在管什么、知道出问题先从哪里查。

1. config.toml 到底在管什么：从一次“配置没生效”说起

我第一次真正意识到 config.toml 的分量，是因为一次很典型的误判。当时我想让 codex 在做批量重命名的时候不要每次都弹确认，于是照着记忆在配置文件里写了一行approval_policy = "never"，保存，重启，结果它还是弹。我以为是被缓存了，清了目录重装，还是弹。折腾了小半个小时才反应过来，我改的是全局配置，但当前目录下有一个项目级的配置把它覆盖掉了。这个坑后面会单独讲，这里先把它抛出来，是因为它恰好说明了 config.toml 的定位：它不是一份“建议”，而是 codex 启动时逐层读取、逐层覆盖的运行时声明。

用一句话概括，config.toml 是 codex 的声明式行为配置文件。它用 TOML 格式写成，决定了四类事情。第一类是模型相关，包括默认走哪个模型、推理强度开多大、上下文窗口按多少算。第二类是执行安全，也就是它能不能自己动文件、能不能执行命令、执行命令之前要不要问你、在什么目录范围内活动。第三类是扩展能力，比如挂载哪些 MCP 服务器、能不能读项目里的说明文档。第四类是交互体验，包括界面的一些开关、通知方式、文件打开器之类。

这四类事情如果全靠命令行参数传，会非常痛苦。想象一下每次启动都要敲一长串--model、--approval、--sandbox，输错一个字符就是另一种行为，而且没法在团队里复现。配置文件的价值就在这里：把“我希望这个工具怎么工作”固化成一个可以被版本管理、可以被 diff、可以被复制粘贴的东西。你换一台机器，把配置拷过去，行为就是一致的。这也是为什么我后来坚持把配置分成“全局个人偏好”和“项目内约定”两层来维护——个人习惯不该污染项目，项目约束也不该被个人习惯覆盖。

还有一个容易被忽略的点：config.toml 里的很多字段是有“安全默认值”的。比如审批策略默认是偏保守的，沙箱默认是限制写范围的。这些默认值在单人玩票时很舒服，但一旦你开始让 codex 做真正的工程任务，比如批量重构、跑测试、修 lint，保守默认会把你拖进无休止的确认弹窗里。反过来，如果你为了省事一刀切把权限开到最大，又会在某次误操作里付出代价。所以配置这件事的本质不是“抄一份能跑的”，而是理解每一项在权衡什么，然后按你的任务类型分档。

1.1 TOML 语法里几个高频写错的地方

TOML 看起来简单，但它有几条规则特别容易让从 JSON、YAML 过来的人翻车，而 codex 对配置解析失败的处理往往不够显眼，写错了可能只是“部分配置没生效”，你甚至不会收到明确报错。

第一个是表（table）的位置。TOML 里[section]之后的所有键都属于这个表，直到遇到下一个表头。很多人会写成这样：先写一堆顶层键，中间插一个[profiles.fast]，然后又想写顶层键，结果那些键被归到了 profile 里面。正确做法是把所有顶层键写在最前面，所有表头放在后面。

第二个是布尔值必须小写。true和false是全小写，写成True、TRUE都会解析失败。这个在从 Python 习惯迁移过来时尤其容易犯。

第三个是字符串里的反斜杠。Windows 路径如果直接写C:\Users\name，反斜杠会被当成转义符。要么用正斜杠，要么用单引号包起来，要么老老实实双写。

第四个是数组和表的混用。像args = ["--foo", "bar"]这种字符串数组很直观，但如果某个字段期待的是“表数组”，你写成普通数组就会静默失效。

我的建议很朴素：改完配置之后，别急着跑任务，先用最小代价验证一下。比如启动 codex 让它报一下当前模型，或者跑一个只读的小任务，看看审批行为对不对。花三十秒验证，比事后花半小时排查划算得多。

1.2 配置文件真正解决的三个痛点

把视角拉高一点，config.toml 之所以值得花时间研究，是因为它同时解决了三个不同层面的问题，而这三个问题各自对应一类配置字段。

一致性问题。同一个仓库，今天你跑、明天同事跑、下周换台机器跑，如果配置散落在各自的命令行历史里，行为一定不一致。把所有约定写进项目里的配置文件，代码审查的时候连“这个工具怎么跑”一起审了，出问题好定位。

安全边界问题。codex 这类工具最大的风险不是它笨，而是它太听话。你让它“清理一下临时文件”，它可能真的去删。审批策略和沙箱配置就是那道闸门，写得越明确，你越敢放手让它干重活。我在生产仓库里从来不会把沙箱关掉，最多是把工作区写权限打开，网络访问单独控制。

能力扩展问题。默认的 codex 只能读写当前工作区、执行本地命令。接上 MCP 服务器之后，它能查文档、连数据库、调内部接口。这些扩展全靠配置文件声明，而且不同项目需要的扩展完全不同，正好适合放在项目级配置里。

理解了这三层，你就不会把 config.toml 当成一个“调参文件”，而会把它当成项目的运行说明书。后面所有字段的取舍，基本都能回到这三层里找答案。

2. 配置文件的位置、加载顺序与覆盖规则

搞不清加载顺序，是 config.toml 相关问题的第一大来源，没有之一。我见过太多人改了配置没反应，最后发现是改错了文件，或者被更高优先级的文件压住了。这一节把这件事讲透。

codex 的配置大致有三个来源层级。最底层是全局配置，放在用户主目录下的.codex/config.toml，管的是“我这台机器上所有项目通用的偏好”，比如默认模型、默认审批策略、界面开关。中间层是项目级配置，放在项目根目录下的.codex/config.toml，管的是“这个仓库特有的约定”，比如沙箱要不要开网络、挂哪些 MCP、项目说明文档多大。最上层是profile，也就是在全局配置里定义好的若干套预设，启动时用参数指定套用哪一套。

覆盖规则是“后者覆盖前者”，而且是按键覆盖，不是整份替换。这一点很重要：项目级配置里只需要写你想改的那几个键，其余键继续沿用全局的值。很多人以为项目配置是一份完整配置，于是复制粘贴了一整份过来，结果全局那边后来改了模型，项目里还停在老模型上，两边越走越远。

提示：覆盖是按键粒度，不是文件粒度。项目配置里只写差异项，能显著降低后续维护成本。

除了这三层，还有命令行参数，它是最高优先级的临时覆盖，只对本次运行生效。适合做一次性实验，比如临时换个模型试试效果，别把实验性参数写进配置文件。

2.1 验证配置到底有没有生效

光看文件内容没用，得让工具自己告诉你它读到了什么。我常用的验证手法有三种。

第一种是观察行为。审批策略是不是真的放开了，跑一个会写文件的小任务就知道；沙箱有没有限制写范围，让它往工作区外面写一个临时文件试试，看是被拒绝还是成功。行为是最诚实的证据，比任何日志都直接。

第二种是故意制造冲突。在全局里设一个值，在项目里设另一个值，看最终表现是哪个。这个方法有点笨，但极其可靠，尤其是在你不确定某个字段到底属于哪一层的时候。

第三种是逐项注释法。当你怀疑某个字段有问题，把它注释掉再跑一遍。如果行为变了，说明这个字段确实在起作用；如果没变，那要么它没生效，要么它被覆盖了。二分排查，比盯着文件瞎猜快得多。

我建议养成一个习惯：每次改完配置，先跑一个“冒烟任务”，比如让它读一个文件然后总结，观察它是否按预期弹确认、是否能正常写。三十秒的事，能挡掉后面百分之八十的困惑。

2.2 项目级配置该不该进版本库

这个问题我被问过很多次。我的答案是：该进，但要分层。项目级配置里那些跟“这个仓库怎么工作”相关的部分，比如沙箱范围、MCP 挂载、说明文档路径，应该提交进版本库，让所有协作者行为一致。而那些跟个人机器相关的部分，比如本地某个工具的绝对路径、个人偏好的界面设置，应该留在全局配置里，不要进仓库。

实际操作上，我会在项目里放一份“团队配置”，只包含安全和协作相关的键，然后在 README 里写清楚个人覆盖该怎么做。这样既保证了底线一致，又不会把每个人的习惯硬塞给所有人。最怕的是有人把带个人路径的配置提交上去，别人拉下来一跑，路径不存在，工具直接罢工或者静默降级。

还有一个小细节：项目级配置的路径是相对于项目根目录的，如果你在子目录里启动，它向上找根目录的行为不一定符合你的直觉。稳妥做法是始终从项目根目录启动，或者在配置里把相对路径写成明确的相对根路径。

3. 核心配置项逐条拆解：模型、审批、沙箱

这一节是全文的重头戏。我把最影响实际体验的字段分成三组来讲：模型组决定“它有多聪明”，审批组决定“它有多大胆”，沙箱组决定“它能在哪活动”。这三组互相牵制，任何一组单独调都会失衡。

3.1 模型与推理强度：别只看名字

模型选择是最直观的一项，model字段写什么，启动就用什么。但真正影响输出质量的往往不是模型名，而是推理强度这个伴随参数。推理强度高，模型在动手之前会想得更久，适合复杂的重构、跨文件的逻辑推理；推理强度低，响应快，适合格式化、改注释、写样板代码这类机械活。

我的经验是按任务类型分档，而不是按心情分档。日常写业务代码用中等强度，跑批量修改和代码审查用高强度，写文档和注释用低强度。因为高强度虽然质量好，但延迟明显，你如果拿它去改一个变量名，会觉得这工具怎么这么磨叽。

还有一个容易踩的坑是上下文窗口。有些模型的实际可用窗口和标称不一样，配置文件里如果显式写了窗口大小，写得比实际小会浪费能力，写得比实际大会导致中途截断，表现为“它好像忘了我前面说的话”。如果你不确定，就别显式写，让工具用默认值。我吃过一次亏：为了让长文件分析更完整，手动把窗口调大，结果模型在中间就开始丢上下文，排查了半天才想到是这个字段。

模型名写错的情况也要提一句。写错之后不一定会报错，有些实现会静默回退到默认模型，你以为是新模型在跑，其实还是老模型。表现就是“怎么感觉没变化”。所以换模型之后，一定要用一两个有区分度的任务验证一下，比如问它一个只有新模型才知道的细节，或者观察输出风格差异。

3.2 审批策略：三档的实际差别

审批策略是 config.toml 里最值得花时间理解的一个字段，因为它直接决定了你和工具之间的协作节奏。它大致分三档，我用“过马路”来类比。

第一档是每一步都问。工具想执行任何有副作用的操作，都先停下来等你点头。最安全，但最烦。适合刚上手、或者在核心仓库里做敏感操作时用。这一档的价值在于让你看清楚它到底想干什么，用几天之后你会对它的行为模式有直觉。

第二档是失败时才问。工具先自己尝试，遇到权限问题、命令失败、需要越界操作时才回来问你。这是我觉得最舒服的一档，适合日常开发。它给了工具一定的自主空间，又不至于在真正卡住时闷头乱试。

第三档是从不问。全自动，风险自负。我只会把它用在完全隔离的沙箱环境、或者一次性脚本任务里。在真实仓库上用这一档，本质上是在赌它不会误解你的意图，而这个赌注通常不值。

配置的时候要注意，审批策略和沙箱是两套独立的机制。审批管的是“要不要问你”，沙箱管的是“物理上能不能做到”。有些人把审批放开到从不问，以为就畅通无阻了，结果被沙箱拦住，表现为“它说要做但什么也没发生”。这两者要一起看。

3.3 沙箱模式：读写范围与网络访问

沙箱是安全边界，它的核心是回答两个问题：能写哪些目录，能不能联网。

写范围通常有三档：完全只读、只写工作区、全盘可写。只读适合代码审查和问答，工具只能看不能动，你完全不用担心它误删东西。只写工作区是日常默认，它能改项目里的文件，但动不了系统目录和你的家目录。全盘可写基本只在容器或一次性环境里用，本机上我从来不这么配。

工作区写模式下面还有细项，比较关键的是网络访问。默认通常是关的，因为联网意味着它可以下载依赖、访问外部接口，也意味着数据可能外流。如果你的任务需要装包、拉依赖，就得单独把这个开关打开。我的做法是默认关，需要时开，任务结束再关回去。把它写在项目配置里而不是全局，可以避免在别的项目里意外联网。

还有一个细节是临时目录和缓存的处理。有些构建工具会往系统临时目录写东西，沙箱如果限制得死，构建会莫名其妙失败，报错还很不直观。遇到这种情况，与其怀疑工具，不如先看看是不是写权限被限制了，把必要的临时路径加进允许列表。

这张表不是教条，但它能帮你快速判断自己当前配置是不是“过松”或“过紧”。过松的表现是你开始担心它乱来，过紧的表现是你一直在点确认。

3.4 环境变量与 shell 策略

codex 执行命令时会继承环境。这里有个隐患：你的 shell 环境里可能有各种令牌、密钥、私有仓库地址。如果不对环境做过滤，模型在排查问题时可能把这些内容读进上下文，甚至写进日志。

配置里通常有控制环境传递的开关，可以指定“只透传哪些变量”或者“屏蔽哪些模式”。我的做法是白名单透传：只允许构建必需的那几个变量过去，其余一律不带。这样即使模型执行了env之类的命令，也看不到敏感内容。

另外，shell 的启动方式也值得注意。有些实现默认用非登录 shell，这意味着你.bashrc里配的路径和别名不会生效，命令找不到就成了常见报错。遇到“明明终端里能跑，工具里说 command not found”，先怀疑这一点，而不是怀疑工具坏了。

4. profiles：把“日常编码”和“危险操作”分开放

如果你只有一个配置文件、一套参数，那你迟早会陷入两难：要么配置太保守，干活时一直被打断；要么太激进，某次误操作让你心跳加速。profiles 就是解这个矛盾的工具。它允许你在同一份配置里定义多套命名预设，启动时按名字切换。

我把它理解为“工作模式”。就像相机有光圈优先、快门优先、手动模式，不是哪个更高级，而是对应不同拍摄场景。codex 的 profile 也一样：写业务代码是一套，做代码审查是一套，跑批量迁移又是另一套。

4.1 profile 的语法结构与常见写法错误

profile 在 TOML 里是嵌套表，基本形态是在配置里定义若干个命名分组，每个分组下面挂具体的键。切换的时候在启动命令后面带上名字即可。

这里有两个高频错误。第一是把 profile 当成完整配置，在里面重复写全局已经有的键，导致以后改全局不生效。正确做法是 profile 里只写跟默认不同的部分，靠覆盖机制继承。第二是表头嵌套写错，比如把键写在了 profile 表外面，结果它变成了全局设置，看起来“profile 没起作用”，其实是根本没进 profile。

还有一个隐蔽的坑：profile 名里带空格或者特殊字符。虽然 TOML 允许带引号的键名，但你在命令行里传的时候容易出问题。建议一律用小写字母加连字符，别玩花活。

4.2 我常用的三套 profile 设计

第一套叫“日常”。审批用失败才问，沙箱只写工作区，网络关闭，推理强度中等。这套是我一天里用得最多的，写功能、改 bug、补测试都靠它。特点是几乎不打断我，但也不会让我担心。

第二套叫“审查”。审批用每步都问，沙箱只读，网络关闭，推理强度高。这套用来做代码审查和方案评估。只读是关键，因为它保证工具不会“顺手帮你改一下”，你拿到的是纯粹的分析意见。推理强度高是因为审查需要理解上下文关系，快而浅的回答没什么价值。

第三套叫“批处理”。审批用从不问，沙箱只写工作区，网络按需，推理强度低。这套专门用来跑机械性的批量任务，比如统一改导入路径、批量补注释、格式化。特点是快，而且因为任务足够机械，全自动的风险可控。

这三套覆盖了我九成以上的使用场景。剩下那一成，比如临时要连一个内部服务，我会临时用命令行参数覆盖，不专门建 profile，避免 profile 越堆越多最后自己都记不清。

4.3 profile 与项目配置打架怎么办

这是个真实会发生的冲突。项目配置里写了沙箱不开网络，你的“批处理”profile 里写了开网络，谁赢？结论是具体程度更高的赢，也就是 profile 里的显式设置通常会覆盖项目里的同名键。但不同实现的具体规则可能有差异，所以我采取的策略是不让它们重叠：项目配置只管安全底线相关的键，profile 只管效率相关的键，两边尽量不碰同一个字段。

如果实在要重叠，我的做法是在 profile 里显式写清楚“这一项我要覆盖项目设置”，并且在项目 README 里注明。这样至少出问题时能快速定位是哪一层在起作用。最怕的是两边都写了、都没注释，最后行为诡异，排查起来像解谜。

5. MCP 服务器与项目级指令的接入

config.toml 的另一大块能力是扩展。默认的 codex 只能看当前工作区和执行本地命令，接上 MCP 之后，它可以访问外部信息源。这一节讲怎么接、接的时候注意什么。

5.2 项目说明文档的加载控制

codex 有一个很重要的机制：它会读取项目里的说明文档，把项目约定、编码规范、常用命令这些信息带进上下文。这个机制的效果非常明显——同样一句“加个接口”，有项目说明和没项目说明，产出的代码风格能差出一个档次。

配置里可以控制这个文档的最大读取字节数。设得太小，文档被截断，模型只看到前半部分，后面的约定全丢；设得太大，每次请求都塞一堆内容，浪费上下文窗口。我的经验值是，把项目说明控制在一页到两页之间，只写“必须知道的”，比如目录结构、命名约定、测试怎么跑、不许做什么。那些可以现查的细节不要写进去。

这里有个容易被忽略的点：说明文档是每次请求都会带的，不是只在第一次带。所以它的体积直接影响成本和延迟。我见过有人把整个架构文档贴进去，结果工具变慢、回答变浅，还以为是模型不行。

5.3 让模型“守规矩”的写法

项目说明文档的写法有很大讲究。写得好，模型像老员工；写得差，模型像刚入职的实习生。我总结了几条。

写禁令比写建议有效。“不要修改生成的代码目录”“不要动数据库迁移文件”这类明确禁令，模型遵守得很好。而“尽量保持代码风格一致”这种模糊建议，基本等于没说。

给可执行的命令。与其说“记得跑测试”，不如直接写“改完之后执行 npm test，失败就先修测试”。模型对具体命令的响应远好于抽象要求。

列出禁区清单。把不能碰的目录、不能改的配置、不能删的文件列成清单。这比任何安全配置都直接，因为它是模型自己能读懂的约束。

别写太长。超过两页，模型对后半部分的注意力会下降。真有必要写长的，拆成多个文件按需引用。

6. 我踩过的几个典型坑与排查链路

这一节讲讲真实的翻车现场。我把排查过程完整写出来，因为比结论更有用的是思路。

6.1 配置写错却毫无提示

最坑的一种情况是 TOML 语法错误，但工具照常启动，只是部分配置失效。表现是“我明明配了，怎么没生效”。我的排查链路是这样的：先确认文件路径对不对，用绝对路径打开看一眼；再把可疑段落整段注释掉，看行为有没有变化；然后逐行恢复，定位到具体哪一行。十有八九是布尔值大小写、字符串转义、表头位置这三类问题。

后来我养成了一个习惯：改配置之后先跑一个只读任务，观察审批行为是否符合预期。如果它该问的时候不问，或者不该问的时候乱问，说明审批相关配置没生效，立刻回头查。

6.2 沙箱开着，却说没有写权限

有一次我让 codex 改一个文件，它回复说没有权限写入。我第一反应是沙箱限制太严，准备去放开。结果检查发现，我要改的那个文件在项目目录之外，是一个被软链进来的共享目录。沙箱的工作区写范围是按真实路径算的，软链指向的外部目录不在范围内，自然写不了。

这个坑的教训是：先确认目标路径到底在哪，再调沙箱。用readlink -f之类的命令把真实路径打出来，比盲目放宽权限安全得多。放宽权限是最后手段，不是第一手段。

6.3 模型换了但感觉没变

前面提过一次，这里展开说。换模型之后如果感觉输出风格、能力没变化，大概率是模型名写错导致回退，或者 profile 覆盖了全局设置。排查顺序是：先看当前生效的 profile 是哪个，再看那个 profile 里有没有写 model，最后看模型名拼写。三层都确认没问题，再用一个有区分度的任务验证。

6.4 团队配置互相覆盖

多人协作时最头疼的是配置冲突。有人为了自己方便，在项目配置里加了个人路径；有人把审批策略改成了从不问并提交；还有人加了一个只有自己机器上才有的 MCP 服务器。结果别人拉下来，要么启动报错，要么行为诡异。

我的解决办法是把项目配置拆成两份：一份是“基线配置”，只含安全底线，进版本库；一份是“本地覆盖”，写个人偏好，加进忽略列表。然后在 README 里写清楚哪份该改、哪份不该动。这个约定建立起来之后，配置相关的扯皮少了非常多。

7. 一套可以直接抄的配置模板与调优思路

讲完原理和坑，给点能直接用的东西。下面这份模板是我目前的主力配置，你可以按需删改。注意所有路径和模型名都要换成你自己环境里的，别照抄。

7.1 最小可用模板

先给一个精简版，适合刚上手、不想被一堆字段吓到的人。核心就三件事：模型、审批、沙箱。

# 全局配置 ~/.codex/config.toml model = "你的默认模型名" approval_policy = "on-failure" sandbox_mode = "workspace-write" [sandbox_workspace_write] network_access = false

这三行半基本能覆盖日常编码。审批失败才问，沙箱只写工作区，网络默认关。跑几天，你会对它的行为有直觉，再往下加东西。

7.2 带 profile 的完整模板

等你开始觉得“有些任务想更激进一点”，就可以上 profile 了。

# 顶层默认值 model = "你的默认模型名" approval_policy = "on-failure" sandbox_mode = "workspace-write" model_reasoning_effort = "medium" [sandbox_workspace_write] network_access = false # 审查模式：只读 + 高强度推理 [profiles.review] approval_policy = "untrusted" sandbox_mode = "read-only" model_reasoning_effort = "high" # 批处理模式：全自动 + 低强度推理 [profiles.batch] approval_policy = "never" sandbox_mode = "workspace-write" model_reasoning_effort = "low" # 装依赖模式：需要联网 [profiles.install] approval_policy = "on-failure" sandbox_mode = "workspace-write" [profiles.install.sandbox_workspace_write] network_access = true

项目级配置则尽量薄，只写差异：

# 项目内 .codex/config.toml [sandbox_workspace_write] network_access = false # 如果需要接内部服务，在这里挂 MCP

注意：项目级配置里不要写模型名。模型属于个人偏好，写进项目会让所有人被迫用同一个模型，换模型还得改仓库。

7.3 调优顺序：从安全到效率

最后说说我建议的调优路径。很多人一上来就想把体验拉满，结果配了一堆自己都不理解的字段，出问题完全没法定位。我推荐按这个顺序来。

第一步，先把安全底线定下来。沙箱写范围、网络开关、环境变量白名单，这三样先配好，并且用只读任务验证一遍。这一步做完，你才敢放手让它干活。

第二步，调审批节奏。从每步都问开始，用两三天，观察它都在什么时候想干什么。等你对它的行为模式有数了，再放宽到失败才问。这个顺序不能反，反过来你会失去对它的直觉。

第三步，按任务分 profile。等你发现自己频繁地临时改参数，就说明该建 profile 了。把最常用的两三种场景固化下来，其余的继续用命令行临时覆盖。

第四步，最后才碰模型和推理强度。这两项对体验影响大，但也最容易让人误判。先用默认值跑一段时间，建立基线，再针对性调整。别一上来就追求“最强模型 + 最高强度”，那样你会分不清是模型强还是任务简单。

我在实际配置上最大的体会是：配置文件是给自己看的，不是给别人看的。网上流传的那些“最强配置”，大部分是针对特定任务的特定取舍，直接抄过来往往水土不服。真正好用的配置，是你自己一行一行改出来、并且每行都能说出为什么的配置。我现在的配置文件里还有几行注释写着“这条是某次误删之后加的”，每次看到都提醒我当初为什么这么设。这种带着记忆的配置，比任何模板都可靠。