Claude Code 的 --help 中列出了 50 多个命令行参数。在每天高强度使用两周后，我编写了一个仅有 60 行的 zsh 包装函数 cco，把我自己真正想要的参数固化了进去。虽然代码本身非常简短，但最有趣的部分在于这 60 行代码背后的设计决策——其中绝大多数方案我都经历过至少一次的推倒重来。
以下是我的决策日志。如果你也在深度使用 Claude Code，这些踩坑经验或许能帮你少走很多弯路。
决策 1：使用 Shell 函数，而不是别名（Alias）或独立 Shell 脚本
最直觉的偷懒做法是定义一个别名：alias cc="claude --permission-mode acceptEdits ..."。但在你想使用子命令（如 cco plan、cco safe、cco review）时，别名就抓瞎了，因为它无法根据传入的参数进行分支路由。
我的第二个想法是在 ~/.local/bin/cc 中放一个独立的 Shell 脚本。这在大多数情况下都行得通，但它会衍生出一个子 shell（subshell）。对于无状态的命令这无所谓，但当你想包装一个交互式进程时，情况就不同了——Claude Code 需要继承父终端的 tty 以进行 tmux 挂载和 Prompt 交互式渲染。独立脚本在测试时看似正常，但在某些边缘场景下会表现得极其诡异。
而 Zsh 函数运行在当前的 shell 环境中，能够干净地继承 tty，完美支持子命令分发，还可以通过 compdef 轻松实现 Tab 键自动补全。因此，我最终选择了它。代价是它必须常驻在你的 .zshrc 中，不便直接移植给 Bash 用户，但我个人用起来完全足够了。
决策 2：命名为 cco 还是 cc
我一开始选择的名字是 cc，仅需两个字母，还是“Claude Code”的完美首字母缩写。但在我即将敲定它时，我多留了个心眼，检查了一下我的系统环境。
在 macOS 系统中，cc 是一个指向系统 C 编译器（/usr/bin/cc，通常是 Clang）的符号链接。在交互式 Shell 中，Zsh 函数的执行优先级高于 $PATH 路径查找，这意味着我的 cc 函数会彻底覆盖（Shadow）系统自带的编译器命令。
有人可能会争辩：我从来不在终端里直接敲 cc 来编译代码，Cargo、CMake、Make 都是通过程序调用它的。然而，虽然像 Rust 的 cc crate 等底层编译工具通常通过 execvp 绕过 Shell 函数直接调用二进制，但仍有部分构建脚本在特定情况下会通过 Shell 包装器来间接调用 cc。一旦发生冲突，你将不得不面对极其难以排查的底层编译失败。为了省去未来数小时无谓的 Debug 痛苦，我最终将其改名为 cco。多敲一个字符，换来百分百的安全，这绝对值得。
决策 3：将系统提示词解耦存放在独立文件中
Claude Code 允许通过 --append-system-prompt "string" 追加自定义系统提示词。把提示词直接硬编码在 Zsh 函数里看似很省事，但千万不要这么做。
系统提示词是会不断演进和膨胀的。我的提示词一开始只有三行（包含反谄媚、置信度标记、先输出反驳论点等规则），但现在已经逼近三十行。在 Shell 函数内部编辑三十行多行文本，并处理各种复杂的字符转义（Escaping），绝对会是一场灾难。将其保存在一个独立文件中，并在 Zsh 函数中动态读取，才是更优雅的做法。
【AgentUpdate 深度解析】Claude Code 的推出标志着 AI Agent 正在从“黑盒”网页交互走向“白盒”本地工作流。作者对 `cco` 的封装，本质上是在解决 Agent 与宿主环境（终端、编译链、操作系统）的协同冲突。相比传统的重型 Agent 框架，这种面向终端的轻量级 CLI Agent 展现出了极高的工程实用性。未来，Agent 的生态边界将不再局限于独立的浏览器窗口，而是通过类似 Zsh 函数、快捷键和底层工具链无缝融合。对底层系统环境（如 TTY 继承、命名空间冲突）的精准处理，将是下一代本地端 Agent（On-device Agent）开发者必须跨越的工程门槛。
