当Codex遇见Superpowers:在Linux终端构建你的AI编程员工
- 2026-04-23 21:15:59
- 丁国栋
- 原创 17
如果你还在手动复制粘贴AI生成的代码片段,或者不断纠正AI助手那些缺乏测试、结构混乱的实现,那么你正在错过AI编程的下一阶段:代理驱动开发。这不是关于更快的代码补全,而是关于创建一个能独立执行复杂工程任务、遵循最佳实践的AI伙伴。
第一部分:Codex - 你的终端AI工程师
Codex(这里特指OpenAI Codex CLI)不是一个聊天机器人,也不是IDE插件。它是一个能在你的终端中运行、拥有上下文感知能力和执行权限的AI代理。你可以把它想象成一个坐在你旁边的资深工程师,不仅能阅读你的代码、理解项目结构,还能直接运行命令、修改文件、甚至执行测试。
它解决了什么? 传统AI编码工具(如Copilot)是“建议者”,你需要手动接受、修改和执行。而Codex是“执行者”。你给它一个目标(比如“修复所有lint错误”或“为这个模块添加单元测试”),它会分析上下文,制定计划,并安全地执行操作。这解决了“想法到可运行代码”之间的最后一公里问题,尤其适合重构、调试、项目初始化等繁琐任务。
在Debian/Ubuntu上安装Codex: Codex基于Node.js,安装非常简单。
# 1. 确保Node.js环境(推荐Node 18+)
node --version
# 若未安装,使用NodeSource安装
# curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version
npm --version
# 2. 全局安装Codex CLI
npm install -g @openai/codex
# 3. 验证安装
codex --version
重要的原则与注意事项
在兴奋地开始之前,你必须理解并遵守这些原则,否则效率工具会变成麻烦制造者。
权限最小化:任何封装了sudo、rm、chmod等命令的别名或脚本,都必须极度谨慎。永远不要为rm设置默认的-rf参数别名,这是血的教训。
透明化:你的别名或函数名应当含义清晰。执行时,最好能先echo出将要执行的真实命令(尤其是在脚本中),或者使用set -x来调试。知其然,更要知其所以然。
环境隔离:针对特定项目的别名,应放在项目本地的.env文件或独立脚本中,通过source引入,避免污染全局环境。
可追溯:重要的、复杂的操作逻辑,即使封装了,也应在函数内或附近用注释写明意图和关键参数说明。
认证:安装后运行codex,它会引导你通过浏览器用ChatGPT账户登录(推荐),或通过设置OPENAI_API_KEY环境变量使用API密钥。
如果是使用 AIGoCode 搭配 Codex 使用,则可以使用配置文件进行连接设置,需要创建 config.toml 和 auth.json 两个文件。
# 删除旧目录并创建新目录
rm -rf ~/.codex && mkdir -p ~/.codex
# 创建 config.toml
cat > ~/.codex/config.toml << 'EOF'
model_provider = "aigocode"
model = "gpt-5.3-codex"
model_reasoning_effort = "high"
disable_response_storage = true
preferred_auth_method = "apikey"
[model_providers.aigocode]
name = "aigocode"
base_url = "https://api.aigocode.com"
wire_api = "responses"
requires_openai_auth = true
EOF
# 创建 auth.json,请将 YOUR_API_KEY 替换为正确的 API Key。
cat > ~/.codex/auth.json << 'EOF'
{
"OPENAI_API_KEY": "YOUR_API_KEY"
}
EOF
核心使用模式:
- 命令模式:
codex "解释这个项目的结构"。适合一次性任务。 - 交互模式:直接输入
codex进入。在此模式下,你可以进行多轮对话,Codex会记住上下文并持续执行复杂任务链。 - 审批模式:通过
-a参数或内部命令设置安全级别,从只建议(suggest)、自动编辑但需确认(auto-edit),到全自动执行(full-auto)。
第二部分:Superpowers - 为AI注入工程纪律
Superpowers 本身不是一个独立工具,而是一个技能框架与方法论。它最初为Claude Code设计,但其理念适用于任何具备一定自主性的AI编码代理。
它的核心价值是强制流程。一个原生的AI代理可能直接跳入编码。而加载了Superpowers的代理,会被强制遵循一套软件工程的最佳实践流程:
- Brainstorming(头脑风暴):先通过提问厘清真实需求,输出设计文档。
- Writing Plans(编写计划):将设计拆解为原子任务(每个2-5分钟),明确每一步的文件、代码和验证。
- Subagent-Driven Development(子代理驱动开发):为每个任务启动专注的子代理执行,并由主代理进行两轮审查(规范符合性、代码质量)。
- Test-Driven Development(测试驱动开发):严格遵循“红-绿-重构”循环,先写失败测试,再写最少通过代码。
它解决了什么? 它解决了AI代理“聪明但鲁莽”的问题——缺乏系统设计、忽视测试、代码结构随意。Superpowers用流程约束创造力,确保产出物的可维护性和正确性。
第三部分:当Codex加载Superpowers技能
虽然Superpowers原生深度集成于Claude Code等环境,但其哲学和部分模式可以应用于配置Codex。关键在于利用Codex的上下文指导文件——AGENTS.md。
如何为Codex注入“超能力”思维: Codex会在项目根目录、当前目录或~/.codex/下寻找AGENTS.md文件,并遵循其中的指令。你可以将Superpowers的核心原则编写成Codex的“工作规范”。
-
创建全局指导文件:
mkdir -p ~/.codex nano ~/.codex/AGENTS.md -
在
AGENTS.md中植入Superpowers工作流:# 项目开发规范 (基于Superpowers哲学) ## 核心原则 1. **测试驱动**:任何新功能或修复,必须先编写失败的测试。 2. **先设计,后编码**:对于非琐碎任务,必须先与我(用户)确认设计要点,包括接口、数据流和边界条件。 3. **原子任务**:将复杂任务分解为可在5分钟内描述清楚的小步骤。 4. **验证前置**:每个步骤都应有明确的验证方法(如运行特定测试、检查输出)。 ## 请求新功能时的流程 当我提出一个功能需求时,请按顺序执行: 1. **澄清与设计**:向我提问以明确需求细节、边界情况和潜在方案。汇总成一份简短的设计摘要并征得我的同意。 2. **任务分解**:将同意的设计分解为具体的编码任务列表。 3. **逐步执行与审查**:逐个执行任务。每个任务完成后,简要说明做了什么,并运行相关测试验证。 -
在项目级进行更细化的控制:在具体项目根目录创建
AGENTS.md,定义技术栈、代码风格、特定的启动命令等,让Codex的上下文感知更精准。
通过对话引导:即使没有完美的AGENTS.md,你也可以在每次与Codex的交互中,手动执行Superpowers流程。例如,当提出一个复杂需求时,首先命令它:“请先使用brainstorming技能,与我讨论这个API端点的设计。”
第四部分:一体化实践指南与验证
假设我们要在现有的Node.js项目中添加一个用户登录功能。
1. 初始化与验证环境:
# 在项目目录中
codex --version
# 应输出Codex版本,确认安装成功
# 启动交互模式,并观察其行为
codex
进入交互界面后,输入
/status,检查模型和权限设置。
2. 触发“超能力”工作流: 在Codex交互界面中,输入:
我需要为这个Express.js项目添加基于JWT的用户登录功能。请先与我进行头脑风暴,厘清需求。
可以让AI先写一个 spec 规格说明书,再根据规格说明书去创建执行计划,拆解任务。
验证点1:一个配置了工程思维的Codex(或通过AGENTS.md引导)应该会开始反问,而不是直接写代码。它会问:
- “现有的用户数据模型是怎样的?”
- “你希望JWT密钥如何管理?使用环境变量吗?”
- “需要包含密码重置和邮箱验证吗?”
- “对登录速率限制有要求吗?”
3. 设计确认与计划: 回答完问题后,要求它:“请基于我们的讨论,生成一份简要的设计文档和实施计划。” 验证点2:它应该输出一个分步骤的计划,类似:
- 创建
user.model.js(如果不存在)。 - 在
auth.controller.js中实现/api/auth/login和/api/auth/register端点。 - 创建
auth.middleware.js实现JWT验证中间件。 - 为以上功能编写单元测试和集成测试。
4. 执行与观察: 批准计划后,说:“开始执行第一个任务。” 验证点3:观察它是否遵循“红-绿-重构”。它应该先创建或修改测试文件,让测试失败(红),然后实现最小代码让测试通过(绿),最后可能进行重构。你可以通过/diff命令随时查看它做了哪些更改。
关键注意事项与心法
- 安全第一:始终从最严格的审批模式(如
auto-edit)开始,让Codex每次修改前都需你确认。谨慎使用full-auto模式,尤其在生产项目目录中。 - 版本控制是生命线:在执行任何实质性修改前,确保当前工作目录已提交到Git。Codex的修改是真实的,
git diff和git checkout -- .是你的后悔药。 - 它增强你,而非取代你:你的角色从“打字员”转变为“架构师”和“审查者”。你需要提供清晰的目标、审核设计、判断计划是否合理。AI负责高保真地执行。
- 从简单任务开始:不要一开始就让AI重构整个系统。从“添加一个工具函数”、“修复这个已知bug”开始,逐步建立信任和理解。
- 理解成本:Codex使用OpenAI的模型,会消耗Token。复杂的、多轮的任务成本不低。在
AGENTS.md中要求它“保持简洁”和“优先使用现有库函数”有助于控制成本。
为什么是Linux终端?
因为终端是开发者的核心操作环境,集成了文件系统、版本控制、进程管理和所有命令行工具。Codex在此运行,意味着它能无缝接入你最熟悉、最强大的工作流。Superpowers所倡导的系统性、可验证性,与Linux的“一切皆文件”、“小工具组合”哲学天然契合。这不仅是安装两个工具,而是在你的核心生产环境中,部署了一位经过严格工程训练的AI副驾驶。
最终,Codex提供了“手”和“眼”(执行与感知),而Superpowers提供了“脑”和“纪律”(流程与规范)。它们的结合,标志着一个新范式的开始:人类负责战略、创意和决策,AI负责战术、实施和重复。你不再只是给AI下命令,而是在进行一场高度结构化的结对编程。
工具存在的意义是扩展你的能力,而非增加你的负担。Codex让你“做得快”,Superpowers式的封装让你“做得稳”。从今天开始,有意识地将那些让你眉头一皱的重复的操作固化下来,把那些复杂的问题简单化,把活分配给AI去干,把宝贵的脑力留给真正需要创造力和决策的事情上去。