在连续两周高强度使用Claude Code之后，一位开发者为其创建了一个60行的Zsh包装器，命名为cco。这个包装器有效地预设了50多个命令行参数，极大地简化了与AI助手的交互。这项工作的真正价值不仅在于包装器本身，更在于其背后细致的决策过程，这为所有认真优化Claude Code工作流的同行提供了宝贵的见解。
决策一：选用Zsh函数，而非别名或Shell脚本
最初的直觉可能是使用别名（例如：alias cc="claude --permission-mode acceptEdits ..."）。然而，在需要处理子命令（如cco plan、cco safe或cco review）的场景下，别名因缺乏基于参数的分支处理能力而迅速变得不切实际。
接下来考虑的是一个独立的Shell脚本，放置在~/.local/bin/cc。尽管这种方式适用于许多无状态命令，但它会派生出一个子Shell。对于需要直接访问父终端TTY的交互式进程来说，这可能导致严重问题——这对正确的tmux会话附加或命令行提示符渲染至关重要。尽管在初步测试中可能看起来正常，但这种方法在更复杂的实际边缘案例中往往会出现异常行为。
最终选择的方案是Zsh函数。函数直接在当前Shell环境中执行，确保TTY的干净继承。这种设计天然支持子命令分派，并且可以通过compdef实现复杂的Tab键自动补全。主要权衡是其有限的移植性；对于Bash用户而言，需要完全重写，但对于个人开发者工具而言，这是一个可以接受的折衷方案。
决策二：命名考量：cc还是cco
开发者最初选择了cc，这是一个简洁且与“Claude Code”相关的助记符。然而，一次关键的检查，对比了现有别名和系统命令后，揭示了潜在的冲突。虽然cl已被cargo clippy --all-targets占用，但在macOS上，cc是C编译器（位于/usr/bin/cc）的符号链接。尽管Zsh函数在交互式Shell中会优先执行，从而遮蔽系统命令，但通过execvp进行的程序化调用并不会识别Shell函数。
一个重大的风险出现在Rust生态系统中，特别是cc crate（被openssl-sys和ring等众多依赖项使用），它有时会在其构建脚本中通过Shell包装器调用cc。尽管遇到此类冲突的概率可能较低，但调试那些难以理解的构建失败的成本将异常高昂。
因此，包装器最终被重命名为cco。尽管这增加了按键次数，但为了避免潜在的系统级冲突和模糊的调试场景，这被认为是一项值得的投入。这项决策强调了在确定短命令名前，进行尽职调查（例如搜索别名文件和使用type <name>命令）的极端重要性。
决策三：将系统提示（System Prompt）外部化存储
最初，将系统提示直接内联到函数中，使用--append-system-prompt "string"参数可能看起来很方便。然而，系统提示往往会显著增长和演变；例如，这位开发者的提示就从三行扩展到了近三十行。
在Shell函数内部直接编辑包含复杂文本和转义字符的冗长多行字符串，本身就是一件痛苦且容易出错的事情。这种方法会使维护、版本控制和可读性变得复杂。通过将系统提示外部化到一个单独的文件中，开发者实现了一种更易于管理和编辑的设置，简化了未来的修改，并确保了更清晰的关注点分离。
