AI带你学｜Claude 命令的参数：给一个自主 Agent 划边界

你在终端里跟 Claude 干了半小时活。它想改一个不该改的文件，你说别动；它跑偏了，你按 Esc 拉回来；它问「要执行 rm -rf build/ 吗」，你扫一眼路径，回车放行。

这半小时里你其实一直在做同一件事：实时地给它划边界。只是做得太自然，你不会把它当成一项工作。

然后你想把同样的流程搬进 CI——每个 PR 自动审一遍，半夜跑，没人看着。

搬过去的那一刻，前面那半小时里你做的每一件事都失效了。没有人能回答「是否允许执行这条命令」；没有人能按 Esc；没有人会看见它跑偏；甚至没有人知道它跑完花了多少钱。你唯一还能说话的时机，是在它启动之前。

参数就是这个时机里唯一的语言。

理解这一点，整份参数列表的形状就变了。它不是一堆功能开关，而是一个构造函数的签名：

▎它和「在 prompt 里写规矩」的区别

没有参数层的时候，人们只有三条路：全程盯着（无法规模化）、在 prompt 里写「请不要删除文件」（这是请求，不是约束）、或者整个丢进容器（粒度粗、反馈环长）。

参数的价值，是把「请求」变成执行时绕不过去的机制。

参数有五六十个，还在往上加，短选项、别名、枚举值随版本变。背它们既不现实也没价值——那是 AI 干的活。真正值得装进脑子的，是每次跑 Agent 之前问自己的七个问题。

七个轴的好处不在于分类整齐，而在于遇到任何一个没见过的新参数，你都能立刻知道它在管什么；反过来，遇到任何一个需求，你也知道该往哪个方向找，哪怕想不起具体拼写。

但这七个轴的重要性差得非常远。下面不按编号讲，按你实际会栽在哪里的顺序讲。

这是整套参数里最重要、也最容易混淆的一处区分。

· 能力回答的是：这只手在不在。–tools 决定 Agent 有哪些内置工具，–mcp-config 决定它能不能碰数据库和内部 API。

· 权限回答的是：这只手能不能动。–permission-mode 设定默认信任姿态，–allowedTools / –disallowedTools 在这个姿态上开例外。

一次工具调用要走完这条链，才会真的执行：

看懂这条链，就能拆掉一个很常见的误会：–allowedTools 不是用来「开启」工具的。名字里有 allowed，看着像开关，其实它是预授权——决定的是「用这个工具还需不需要问一句」，而不是「有没有这个工具」。给一个不在 –tools 里的工具做预授权，一点作用都没有。

▎–dangerously-skip-permissions 不是提速开关

它确实变快了——确认弹窗全没了。但它的本质是责任转移：权限系统的职责被整体移交给了环境隔离。

如果环境是一次性容器、没有网络、没有真凭证，这笔交易划算：权限系统本来的价值是「防止在你在意的环境里造成不可逆后果」，当环境本身不值钱，这个价值归零，而每一步确认的摩擦还在。如果环境是你的开发机，你只是撤掉了安全网，没有换上新的。

如果你没法一句话说清「出错了会毁掉什么」，就说明你还不该用它。

顺带一提，还有个 –allow-dangerously-skip-permissions——它只是让「绕过权限」这个选项在会话里可用，而不是默认开启。两者差一个词，风险差一个量级。

▎这里也是从业者真正有分歧的地方

一派认为，Agent 就该关在一次性容器里全速跑，逐条确认是在用人的注意力补技术的短板；另一派认为，哪怕在容器里也要保留只读边界，因为「隔离」的容器往往仍有网络、仍挂着凭证、仍能推分支。这个分歧没有通用答案——它取决于你的容器里到底装了什么，而这件事只有你自己知道。

–print 看起来只是「不进入交互界面，打印完就退出」。表面现象没错，但它同时改变的东西远不止 UI：

· 工作区信任对话框被跳过（帮助文本明确写了这点，也顺带提醒：只在你信任的目录里用）；

· 校验失败的设置文件被静默忽略，不再弹错误——自动化环境里没人看弹窗，但这也意味着配置写错了你不会知道；

· 会话持久化的默认行为变了；

· 前面提到的那一整批参数，到这一侧才被解锁。

所以 -p 是语义切换：从「人机对话」切到「函数调用」。你不是关掉了界面，你是换了一套契约。

不过这个能力经常被高估。schema 保证的是形状，不是内容。字段齐了不代表填对了，把 severity 填成「high」是合法的枚举值，也可能是完全错误的判断。schema 把「解析失败」这类问题消掉了，把「判断错误」原样留在原地。真要用在 CI 上，该有的抽样复核一样得有。

同一侧还有一个几乎不该省的参数：–max-budget-usd。它把「不确定的成本」变成「有界的成本」。无人值守的自动化最坏的情况不是做错事，是做错事做了一整夜。

「多给点上下文总没坏处」是个很自然的直觉，对人成立，对 Agent 不成立。

每加一个 –add-dir，你都在同时做三件事：花钱、稀释注意力、扩大搜索空间。前两件是线性的代价，第三件是非线性的——目录多了以后，Agent 找错文件、改错地方的概率上升得比你预期快。给精确的少量上下文，几乎总是好过「以防万一都给上」。

这一轴里有个值得单独说的区分：–system-prompt 是替换，–append-system-prompt 是追加。绝大多数场景你想要的是后者——你只是想加一层约束，而不是把 Claude Code 内置的那套行为基座整个扔掉。替换掉之后会连带失去什么，不总是显而易见的。

▎顺手说一个含金量很高、却总被跳过的参数

–exclude-dynamic-system-prompt-sections 做的事，是把 cwd、环境信息、记忆文件路径、git status 这些逐机器不同的内容，从系统提示挪到第一条用户消息里。目的不是省字数，是提高 prompt cache 的跨用户命中率。

顺带一提，它明确写着「只对默认系统提示生效」——你一旦自己写了 –system-prompt，这个优化就自动失效了。这正是上面那个「替换的代价不总是显而易见」的一个具体例子。

▎会话是对象，不是聊天记录

一旦你不再把会话当成「历史消息的列表」，而当成一个可寻址、可分叉的状态对象，很多用法会自己浮出来。

▎隔离是并行的前提，但只挡得住文件冲突

–worktree 看起来是个便利功能——省得来回切分支。从单人单任务的视角看，确实如此。

但把视角换到「同时驱动 N 个 Agent」，它的性质就变了。人类工程师的并行度受限于注意力；Agent 的并行度受限于冲突域。你可以同时开五个 Agent，前提是它们不会同时写同一个文件。worktree 消除的正是这个冲突域，它是并行的物理前提，不是操作上的省事。配上 –background 让会话脱离前台、-n 让你认得出谁是谁，一个人驱动多个 Agent 才真的成立。

–model 决定用哪个大脑，–effort 决定它想多久（low / medium / high / xhigh / max）。这两个是正交的，但很多人把 effort 当成 model 的替代品。

选择依据不是「越强越好」，而是错误成本 vs 单位成本：

· 任务可验证、可重跑、错了代价小（批量整理、格式转换、初筛）——便宜模型跑十次，通常比贵模型跑一次更划算。

· 任务一次性、难验证、错了代价大（架构决策、安全相关改动）——该上强模型，还该把 effort 拉高。

实践中一个更常见的正确动作是：先别换模型，先调 effort。同一个模型换个思考强度，往往比换模型更精准地命中你的需求，价格曲线也更平缓。

–fallback-model 是这一轴里的容错件：主模型过载时自动降级，不让整条流水线挂掉。它同样标着 only works with –print——又一个证据，说明这套参数是为无人值守设计的。

有三个参数不属于任何一轴，它们是关于参数本身的：

所以当行为突然变得奇怪——同样的 prompt，昨天好好的今天很怪——第一个动作不是换模型，是 –safe-mode 跑一次。正常，说明问题在你的配置里，再用 –setting-sources 逐层加回去定位；还是不正常，才轮到怀疑别的。这是最省时间的一步，也是最容易被跳过的一步。

有个细节值得留意：–safe-mode 关掉的是你的自定义，管理员策略仍然生效。这条小注脚透露了整个配置体系的形状——企业策略在最上面，是你绕不过去的。

排查「为什么它不听我的」，从这条链的顶端往下看。

到这里，容易产生一种错觉：只要边界画得够准，Agent 就能放心跑。并不是。有几件事参数从设计上就管不了。

参数这个领域里，知识的半衰期差别很大。

下次要跑一个 Agent，先别去翻 –help。

先回答四个问题就够了：谁来做，它能碰到什么，它被允许改什么，结果给谁看。这四个答案定下来，剩下的拼写交给 AI——它比你记得准，而且不会记错版本。