JT

Blog · B003

Effective Command：把 AI 变成本地开发里的顺手命令

Effective Command · 2026-05-24

很多 AI 开发工具喜欢从宏大的入口开始：新的编辑器、新的工作台、新的代理系统，或者一整套替代现有流程的界面。

Effective Command 选择了相反的方向。

它不试图接管开发者的工作环境，也不想把每个动作都包装成一个复杂的 AI 流程。它只问一个更小的问题：在本地开发里，哪些动作重复、高频、又确实适合交给 AI 辅助？

当前答案很朴素：

  1. 写一条准确的 commit message。
  2. 在提交前审查一次本地未提交变更。

于是就有了两个命令：

ec commit
ec review

为什么从 Git 工作流开始

Git 是开发者每天都会碰到的真实工作流。它不性感，但非常稳定。

提交前的两个动作也很典型：

  1. 你需要回顾自己改了什么。
  2. 你需要把这些变化压缩成一句清楚的提交说明。
  3. 你可能还想在提交前让另一个“眼睛”扫一遍风险。

这些动作并不难，但它们消耗注意力。

尤其是小步提交频繁发生时，commit message 很容易变成机械描述：

update files
fix bug
change code

这些信息对未来的自己几乎没有帮助。好的提交信息应该说清楚行为变化，而不是罗列文件名。好的本地 review 也应该优先指出真实风险，而不是制造一堆无关紧要的建议。

Effective Command 的目标就是把这两个动作变得更稳。

不是重新发明 Codex，而是约束 Codex

这个项目不是另一个模型客户端。

它依赖本地已经安装并登录的 Codex CLI，然后把特定任务收束成更短、更一致的命令。

核心思路是：

开发者
  -> ec commit / ec review
    -> codex exec
      -> 本地 Git 仓库上下文

这里最重要的不是“调用 Codex”，而是“给 Codex 正确的边界”。

ec commit 不把完整 diff 直接塞进 prompt，也不通过 stdin 把代码扔给模型。它只告诉 Codex：你正运行在一个本地 Git 仓库里，请自己用只读命令检查未提交变更。

建议命令包括：

git status --short
git diff HEAD --stat
git diff HEAD
git ls-files --others --exclude-standard

这种方式有两个好处。

第一，任务上下文更真实。Codex 看到的是本地仓库状态，而不是被工具预处理过的一段文本。

第二，工具边界更清楚。Effective Command 自己不解析 diff、不拼接大段 prompt、不假装理解代码。它负责组织任务，Codex 负责读取上下文和生成结果。

ec commit：生成，但不强迫

ec commit 的默认流程是：

  1. 检查当前目录是否是 Git 仓库。
  2. 检查是否存在未提交变更。
  3. 调用本地 codex exec。
  4. 让 Codex 自行读取本地变更。
  5. 输出一条 commit message。
  6. 询问是否使用这条 message 执行 git commit。

确认提示是：

Use this message and run git commit? [Y/n]

这个交互很关键。

工具可以建议提交信息，但最终是否提交仍然由开发者决定。直接按 Enter 会执行提交，输入 n 则只输出 message，不提交。

这让命令保持了效率，也保留了控制权。

另外，ec commit 默认不会把 Codex 的中间推理、完整 diff 或冗长过程打到终端里。开发者真正关心的是最终 commit message，以及它是否足够清楚。

ec review：只读审查，不动文件

ec review 的边界更明确：只审查，不修改，不提交。

它同样让 Codex 自行读取本地未提交变更，但输出规则更偏向代码审查：

  1. 优先看 bug、行为回归、安全风险、数据风险和缺失测试。
  2. 不做无意义的格式挑剔。
  3. 如果没有实质问题，要明确说没有发现重要问题。
  4. 输出保持简洁，适合提交前快速扫一遍。

这不是为了替代完整 code review。

它更像提交前的一次本地预检：在你把代码交给远端 CI、PR 或同事之前，先让 AI 从另一个角度看一下。

小工具的关键是少做

Effective Command 当前只做两个命令。

这不是因为想象力不足，而是刻意控制范围。

暂时不做：

  1. ec config
  2. ec summary
  3. 插件系统
  4. 多 provider 管理
  5. API key 管理

这些能力当然可以做，但一旦过早加入，工具就会从“顺手命令”变成“需要管理的系统”。

对个人开发者来说，一个 CLI 工具能长期留下来，往往不是因为它功能最多，而是因为它足够可靠、足够可预测，而且不会在每次使用时要求你重新理解一遍。

设计里的几个细节

这个项目虽然小，但有几个值得保留的工程选择。

第一，使用 Node.js CLI。

package.json 里通过 bin 暴露 ec 命令，安装后可以直接运行：

npm install -g effective-command
ec commit
ec review

本地开发时也可以用：

npm link

第二，命令参数保持有限。

当前支持：

ec commit --lang zh-CN
ec commit --style conventional
ec commit --model gpt-5
ec commit --profile work
ec commit --copy
ec review --lang zh-CN
ec review --model gpt-5

这些参数不是为了炫技，而是覆盖真实需求：语言、模型、Codex profile、commit 风格和复制到剪贴板。

第三，环境变量可覆盖默认行为。

EFFECTIVE_COMMAND_LANGUAGE=zh-CN
EFFECTIVE_COMMAND_MODEL=gpt-5
EFFECTIVE_COMMAND_CODEX_PROFILE=work

这让它可以被个人 shell 环境、公司环境或不同机器稳定复用。

第四，发布前有最小检查。

npm run check
npm pack --dry-run

对 CLI 来说，最基础的质量要求是：入口文件能被 Node 正确解析，npm 包内容不要缺文件。

它适合什么人

Effective Command 适合那些已经在用 Codex CLI，但希望把高频任务变成短命令的人。

如果你每天都会做小步提交，如果你经常在提交前想要一次轻量 review，如果你不想每次都手动打开一个 AI 会话、描述任务、复制 diff、整理输出，那么这个工具就有意义。

它不是为了取代 Git，也不是为了取代 IDE。

它只是把 AI 放在一个更合适的位置：靠近本地仓库，靠近提交动作，靠近开发者已经习惯的命令行。

后续方向

这个项目后续最值得做的不是扩很多命令，而是把现有两个命令做得更稳。

短期重点：

  1. 优化 commit message 的质量和稳定性。
  2. 让 review 输出更像真正的代码审查，而不是泛泛建议。
  3. 改善错误提示，比如没有 Git 仓库、没有未提交变更、Codex 未登录。
  4. 让 npm 发布流程更顺滑。

中期可以考虑：

  1. 支持更细的 review 范围。
  2. 支持只针对 staged changes。
  3. 增加 --dry-run 或更明确的非交互模式。
  4. 改善 CI 或 pre-commit 场景下的可用性。

长期来看，Effective Command 不一定要变成一个庞大的工具箱。它更适合成为一个小而锋利的本地 AI 命令层。

一个好的开发者工具，应该在你需要时出现，在任务完成后退场。

这就是 Effective Command 想保持的姿态。