提示词工程 —— 任务分解、上下文注入、文件引用、管道输入

简介

这是 Codex CLI 系列文章的收官之作。

在前面的 29 篇文章中，我们覆盖了 Codex CLI 的方方面面：安装认证、exec 命令、沙箱模式、Git 集成、后台模式、工作树并行、PR Review、CI/CD 集成、结构化输出和 Session 管理。

但所有这些功能的效果，最终都取决于一个核心因素：

你如何写 Prompt（提示词）。

同样的 Codex CLI，给不同的 Prompt，结果可能天差地别：

模糊的 Prompt → 模糊的回答，甚至完全偏离方向
精确的 Prompt → 准确的分析，可执行的代码，结构化的输出

本文将系统性地介绍 Codex CLI 的提示词工程技巧，帮助你最大化 AI Agent 的生产力。

一、任务分解

1.1 为什么需要任务分解

假设你给 Codex 一个复杂任务：

bash

# ❌ 不好的 Prompt —— 太笼统
codex exec --full-auto "改进这个项目的代码质量"

AI 不知道：

"代码质量"具体指什么？
优先级是什么？
改进的范围有多大？
有什么约束条件？

1.2 分解原则：MECE 方法

MECE（Mutually Exclusive, Collectively Exhaustive）—— 相互独立，完全穷尽。

text

改进代码质量
├── 代码规范（Style）
│   ├── 格式化
│   ├── 命名约定
│   └── 注释规范
├── 代码结构（Architecture）
│   ├── 模块拆分
│   ├── 依赖管理
│   └── 接口设计
├── 代码安全（Security）
│   ├── 输入验证
│   ├── 认证授权
│   └── 数据加密
└── 代码性能（Performance）
    ├── 算法优化
    ├── 缓存策略
    └── 并发处理

1.3 分解后的执行

bash

# Step 1: 代码规范
codex exec --full-auto "
检查项目的代码规范问题：
1. 运行 lint 工具，报告所有警告和错误
2. 检查命名约定是否一致
3. 检查注释覆盖率

输出格式：JSON
{
  \"lint_errors\": [...],
  \"naming_issues\": [...],
  \"comment_coverage_percent\": number
}"

# Step 2: 代码结构
codex exec --continue --full-auto "
分析项目的代码结构：
1. 列出所有模块及其依赖关系
2. 识别循环依赖
3. 识别过大的文件（>500行）
4. 建议模块拆分方案"

# Step 3: 代码安全
codex exec --continue --full-auto "
进行安全审查：
1. 检查硬编码的密钥和密码
2. 检查 SQL 注入风险
3. 检查 XSS 风险
4. 检查文件操作安全

输出格式：JSON，每个问题包含 severity 和 fix suggestion"

# Step 4: 代码性能
codex exec --continue --full-auto "
进行性能分析：
1. 识别时间复杂度为 O(n²) 或更高的操作
2. 识别不必要的重复计算
3. 建议缓存策略
4. 识别 N+1 查询问题"

1.4 任务分解模板

bash

#!/bin/bash
# task-decomposition.sh —— 自动化任务分解和执行

# 定义任务分解
TASKS=(
  "分析项目结构，生成模块依赖图"
  "检查代码规范，生成修复建议列表"
  "进行安全审查，标记风险等级"
  "分析性能瓶颈，提供优化方案"
  "检查测试覆盖率，识别未覆盖的分支"
)

# 启动会话
echo "🚀 Starting code quality improvement project"

for i in "${!TASKS[@]}"; do
  STEP=$((i + 1))
  echo ""
  echo "=== Step $STEP/${#TASKS[@]} ==="
  echo "Task: ${TASKS[$i]}"

  if [ $STEP -eq 1 ]; then
    codex exec --full-auto "${TASKS[$i]}"
  else
    codex exec --continue --full-auto "${TASKS[$i]}"
  fi

  echo "✅ Step $STEP complete"
done

echo ""
echo "🎉 All steps complete!"

1.5 依赖关系分解

有些任务之间有依赖关系，需要按特定顺序执行：

bash

# 正确的执行顺序：
# 1. 先理解 → 2. 再分析 → 3. 然后规划 → 4. 最后执行

# Step 1: 理解
codex exec --full-auto "
阅读并理解 src/auth/ 目录下的所有文件。
列出每个文件的职责、输入、输出和依赖。
不要做任何修改。"

# Step 2: 分析（依赖 Step 1 的理解）
codex exec --continue --full-auto "
基于你对代码的理解，分析以下问题：
1. 哪些函数过于复杂（圈复杂度 > 10）？
2. 哪些模块耦合度过高？
3. 有哪些重复的代码可以提取？"

# Step 3: 规划（依赖 Step 2 的分析）
codex exec --continue --full-auto "
基于分析结果，制定详细的重构计划。
包括：
1. 重构的具体步骤
2. 每个步骤的风险评估
3. 回退方案
4. 预计影响的文件列表"

# Step 4: 执行（依赖 Step 3 的计划）
codex exec --continue --full-auto "
按照你制定的计划，逐步执行重构。
每完成一个步骤后：
1. 运行测试确保没有破坏
2. 报告当前进度
3. 等待确认后再继续下一步"

二、上下文注入

2.1 为什么需要上下文注入

AI 不知道你的项目背景、技术栈、编码规范，除非你告诉它。

bash

# ❌ 缺乏上下文
codex exec --full-auto "重构这个函数"

# ✅ 注入上下文
codex exec --full-auto "
项目背景：这是一个电商平台的订单处理系统
技术栈：Node.js + TypeScript + PostgreSQL
编码规范：遵循 Airbnb TypeScript Style Guide

请重构以下函数，要求：
1. 使用 async/await 替代回调
2. 添加错误处理
3. 遵循单一职责原则
"

2.2 上下文注入的层次

text

┌────────────────────────────────────────────┐
│              上下文注入层次                  │
├────────────────────────────────────────────┤
│                                            │
│  第 1 层：项目信息                          │
│  ├── 项目名称、类型                         │
│  ├── 技术栈                                 │
│  └── 团队规模                               │
│                                            │
│  第 2 层：编码规范                          │
│  ├── 命名约定                               │
│  ├── 代码风格                               │
│  └── 测试要求                               │
│                                            │
│  第 3 层：业务规则                          │
│  ├── 领域模型                               │
│  ├── 业务约束                               │
│  └── 边界条件                               │
│                                            │
│  第 4 层：当前任务                          │
│  ├── 任务目标                               │
│  ├── 约束条件                               │
│  └── 期望输出                               │
│                                            │
└────────────────────────────────────────────┘

2.3 使用上下文文件

bash

# 创建项目上下文文件
cat > .codex-context.md << 'EOF'
# Project Context

## Overview
- **Name**: OrderFlow
- **Type**: E-commerce order processing system
- **Language**: TypeScript
- **Runtime**: Node.js 20+
- **Database**: PostgreSQL 15

## Architecture
- **Pattern**: Layered Architecture
- **Layers**: Controller → Service → Repository
- **Communication**: REST API + Event-driven (RabbitMQ)

## Coding Standards
- **Style**: Airbnb TypeScript Style Guide
- **Testing**: Jest + Supertest, min 80% coverage
- **Error Handling**: Custom error classes, centralized error middleware
- **Logging**: Winston, structured JSON logs

## Important Constraints
- DO NOT modify database schema without migration files
- DO NOT use `any` type
- All public APIs must have OpenAPI documentation
- All async functions must have try/catch with proper error handling
EOF

# 在 Prompt 中引用上下文
codex exec --full-auto "
请阅读 .codex-context.md 了解项目背景。

基于项目上下文，重构 src/services/OrderService.ts 中的 processOrder 函数。
要求：
1. 遵循项目中定义的编码规范
2. 添加适当的错误处理
3. 确保测试覆盖率不低于 80%"

2.4 动态上下文注入

bash

#!/bin/bash
# dynamic-context.sh —— 根据代码变更动态注入上下文

# 获取变更的文件
CHANGED_FILES=$(git diff --name-only HEAD~1 HEAD)

# 构建上下文
CONTEXT="## Changed Files\n\n"
for file in $CHANGED_FILES; do
  CONTEXT+="### $file\n\n"
  CONTEXT+="\`\`\`typescript\n"
  CONTEXT+=$(cat "$file")
  CONTEXT+="\n\`\`\`\n\n"

  # 添加 git diff
  CONTEXT+="#### Changes\n\n"
  CONTEXT+="\`\`\`diff\n"
  CONTEXT+=$(git diff HEAD~1 HEAD -- "$file")
  CONTEXT+="\n\`\`\`\n\n"
done

# 获取相关的测试文件
TEST_FILES=$(echo "$CHANGED_FILES" | sed 's|src/|test/|' | sed 's/\.ts$/\.test.ts/')
for test_file in $TEST_FILES; do
  if [ -f "$test_file" ]; then
    CONTEXT+="### Test: $test_file\n\n"
    CONTEXT+="\`\`\`typescript\n"
    CONTEXT+=$(cat "$test_file")
    CONTEXT+="\n\`\`\`\n\n"
  fi
done

# 写入临时文件
echo "$CONTEXT" > /tmp/dynamic-context.md

# 执行 Codex
codex exec --full-auto "
阅读 /tmp/dynamic-context.md 了解当前代码变更。

审查这些变更：
1. 检查是否遵循项目编码规范
2. 检查是否有潜在 bug
3. 检查测试是否充分
4. 给出改进建议"

2.5 使用 Codex 的内置上下文注入

bash

# 方式 1：使用 @ 符号引用文件
codex exec --full-auto "分析 @src/auth/login.ts 和 @src/auth/middleware.ts 的安全问题"

# 方式 2：引用目录
codex exec --full-auto "审查 @src/api/ 目录下的所有路由处理函数"

# 方式 3：引用 Git 历史
codex exec --full-auto "分析最近 5 次提交中 src/ 目录的变更模式"

# 方式 4：引用 PR 信息
codex exec --full-auto "审查 PR #123 的变更，参考 @.github/PULL_REQUEST_TEMPLATE.md"

三、文件引用

3.1 @ 文件引用语法

Codex CLI 支持使用 @ 前缀直接引用文件：

bash

# 引用单个文件
codex exec --full-auto "解释 @src/main.ts 中的依赖注入逻辑"

# 引用多个文件
codex exec --full-auto "比较 @src/serviceA.ts 和 @src/serviceB.ts 的实现差异"

# 引用配置文件
codex exec --full-auto "根据 @tsconfig.json 和 @package.json 分析项目配置"

3.2 通配符引用

bash

# 引用所有 TypeScript 文件（谨慎使用，可能超出上下文限制）
codex exec --full-auto "列出 @src/**/*.ts 中所有导出的接口"

# 引用特定模式
codex exec --full-auto "检查 @src/**/*.test.ts 中是否有遗漏的边界情况"

# 引用文档文件
codex exec --full-auto "根据 @docs/*.md 更新 @README.md"

3.3 文件引用的上下文限制

AI 模型的上下文窗口有限，引用太多文件会超出限制：

text

┌──────────────────────────────────────────────┐
│          文件引用 vs 上下文窗口                │
├──────────────────────────────────────────────┤
│                                              │
│  模型           │ 上下文窗口 │ 约等效文件数    │
│  ──────────────┼───────────┼───────────────│
│  o3-mini        │ 200K tokens│ ~50 个中等文件  │
│  o3             │ 200K tokens│ ~50 个中等文件  │
│  o4-mini        │ 200K tokens│ ~50 个中等文件  │
│                                              │
│  注意：实际数量取决于文件大小和语言            │
│                                              │
└──────────────────────────────────────────────┘

3.4 智能文件选择策略

bash

#!/bin/bash
# smart-file-selection.sh —— 智能选择需要引用的文件

TARGET_FILE=$1

# 获取直接依赖的文件
DEPENDENCIES=$(grep -r "import.*from" $TARGET_FILE | \
  sed "s/.*from ['\"]//" | sed "s/['\"].*//" | \
  sed 's|@/|src/|g' | sed 's/$/.ts/')

# 获取相关的测试文件
TEST_FILE=$(echo "$TARGET_FILE" | sed 's|src/|test/|' | sed 's/\.ts$/\.test.ts/')

# 获取相关的类型定义
TYPE_FILE=$(echo "$TARGET_FILE" | sed 's/\.ts$/\.d.ts/')

# 构建引用列表
REFS="@$TARGET_FILE"

for dep in $DEPENDENCIES; do
  if [ -f "src/$dep" ]; then
    REFS+=" @src/$dep"
  fi
done

if [ -f "$TEST_FILE" ]; then
  REFS+=" @$TEST_FILE"
fi

if [ -f "$TYPE_FILE" ]; then
  REFS+=" @$TYPE_FILE"
fi

echo "📁 Files to reference: $REFS"
echo ""

# 执行审查
codex exec --full-auto "审查以下文件及其依赖关系：$REFS

关注点：
1. 类型安全
2. 错误处理
3. 性能问题
4. 代码重复"

3.5 使用 ripgrep 辅助文件引用

bash

# 查找所有使用特定函数的文件，然后引用它们
USAGE_FILES=$(rg -l "processOrder" src/ | tr '\n' ' ')

# 构建 @ 引用
REFS=$(echo "$USAGE_FILES" | sed 's/^/@/g')

codex exec --full-auto "分析 processOrder 函数的所有使用场景：$REFS

检查：
1. 错误处理是否一致
2. 参数传递是否正确
3. 是否有遗漏的使用场景"

3.6 文件引用与 Git 结合

bash

# 引用最近修改的文件
RECENT_FILES=$(git diff --name-only HEAD~5 HEAD | head -20)
REFS=$(echo "$RECENT_FILES" | sed 's/^/@/g' | tr '\n' ' ')

codex exec --full-auto "审查最近修改的文件：$REFS"

# 引用特定分支的变更
BRANCH_FILES=$(git diff main...feature-branch --name-only)
REFS=$(echo "$BRANCH_FILES" | sed 's/^/@/g' | tr '\n' ' ')

codex exec --full-auto "审查 feature-branch 的变更：$REFS"

四、管道输入

4.1 标准输入管道

Codex CLI 支持通过标准输入接收内容：

bash

# 管道输入：将 git diff 直接传入
git diff HEAD~1 HEAD | codex exec --full-auto "审查以下代码变更"

# 管道输入：将错误日志传入
npm run build 2>&1 | codex exec --full-auto "分析以下构建错误，提供修复方案"

# 管道输入：将测试输出传入
npm test 2>&1 | codex exec --full-auto "分析测试失败原因，建议修复"

4.2 管道与文件引用结合

bash

# 管道输入 diff + 文件引用上下文
git diff HEAD~1 HEAD | codex exec --full-auto "
审查以下代码变更。参考相关文件的完整上下文：

@src/config/database.ts
@src/config/redis.ts

变更内容：
$(cat)"

4.3 多管道组合

bash

# 组合多个信息源
(
  echo "=== Git Diff ==="
  git diff HEAD~1 HEAD
  echo ""
  echo "=== Lint Output ==="
  npm run lint 2>&1 | tail -50
  echo ""
  echo "=== Test Output ==="
  npm test 2>&1 | tail -100
) | codex exec --full-auto "
综合分析以下信息：

1. Git Diff：代码变更
2. Lint Output：代码规范问题
3. Test Output：测试结果

给出综合审查报告。"

4.4 管道输入工作流

bash

#!/bin/bash
# pipeline-workflow.sh —— 完整的管道输入工作流

# Step 1: 收集信息
echo "📊 Collecting information..."

(
  echo "## PR Information"
  gh pr view $PR_NUMBER --json title,body,labels | jq -r '.title + "\n\n" + .body + "\n\nLabels: " + (.labels | map(.name) | join(", "))'

  echo ""
  echo "## Code Changes"
  gh pr diff $PR_NUMBER

  echo ""
  echo "## CI Status"
  gh pr checks $PR_NUMBER 2>/dev/null || echo "No CI checks available"

  echo ""
  echo "## Comments"
  gh pr view $PR_NUMBER --json comments | jq -r '.comments[] | "**" + .author.login + "**: " + .body + "\n"'

  echo ""
  echo "## Related Files"
  gh pr diff $PR_NUMBER | grep "^+++ b/" | sed 's/+++ b\/@/' | tr '\n' ' '

) > /tmp/pr-context.txt

# Step 2: 执行审查
echo "🤖 Running review..."

cat /tmp/pr-context.txt | codex exec --full-auto "
你是一个高级代码审查员。请分析以下 PR 信息并给出结构化审查报告。

输出格式：
{
  \"status\": \"approved\" | \"changes_requested\",
  \"score\": 0-100,
  \"summary\": \"one line summary\",
  \"issues\": [{
    \"type\": \"security|bug|performance|style\",
    \"severity\": \"critical|high|medium|low\",
    \"description\": \"detailed description\",
    \"file\": \"file path\",
    \"line\": number or null,
    \"suggestion\": \"fix suggestion\"
  }],
  \"positive_feedback\": [\"list of good things\"]
}" > /tmp/review-result.json

# Step 3: 处理结果
echo "📋 Processing results..."

STATUS=$(jq -r '.status' /tmp/review-result.json)
SCORE=$(jq -r '.score' /tmp/review-result.json)

echo "Review Status: $STATUS"
echo "Score: $SCORE/100"

# 如果有严重问题，创建 Issue
jq -r '.issues[] | select(.severity == "critical") | .description' /tmp/review-result.json | \
  while read -r issue; do
    gh issue create --title "🚨 $issue" --label "from-ai-review"
  done

# 发布 PR 评论
jq -r '"## AI Review (Score: \(.score)/100)\n\n**Status:** \(.status)\n\n**Summary:** \(.summary)\n\n### Issues\n\n" + (.issues | map("- **[\(.severity)]** \(.description)") | join("\n")) + "\n\n### Positive\n\n" + (.positive_feedback | map("- " + .) | join("\n"))' /tmp/review-result.json | \
  gh pr comment $PR_NUMBER --body-file -

echo "✅ Review complete"

4.5 Here Document 管道

bash

# 使用 here document 传入多行内容
codex exec --full-auto << 'PROMPT'
你是一个数据库优化专家。

数据库信息：
- 类型：PostgreSQL 15
- 大小：50GB
- 表数量：120
- 最大表：orders (15M rows)

当前性能问题：
1. /api/orders 接口响应时间 > 2s
2. 每日凌晨 2 点数据库 CPU 使用率 > 90%
3. 慢查询日志中有大量全表扫描

请分析可能的原因并提供优化方案。
PROMPT

4.6 环境变量注入

bash

# 通过环境变量注入敏感信息（不要在 Prompt 中硬编码）
export DB_SCHEMA=$(psql -d mydb -c "\dt+" -t 2>/dev/null | head -20)
export API_ROUTES=$(grep -r "router\.\(get\|post\|put\|delete\)" src/ | wc -l)

codex exec --full-auto "
分析以下数据库和 API 信息：

数据库表结构：
$DB_SCHEMA

API 路由数量：$API_ROUTES

给出性能优化建议。"

4.7 动态管道生成

bash

#!/bin/bash
# generate-prompt.sh —— 根据项目状态动态生成 Prompt

generate_prompt() {
  echo "## Project Analysis Request"
  echo ""
  echo "### Context"
  echo "- Project: $(basename $(pwd))"
  echo "- Language: $(find . -name '*.ts' -o -name '*.js' -o -name '*.py' | head -1 | sed 's/.*\.//')"
  echo "- Total files: $(find . -type f -not -path './.git/*' -not -path './node_modules/*' | wc -l)"
  echo "- Total lines: $(find . -type f -not -path './.git/*' -not -path './node_modules/*' -name '*.ts' -o -name '*.js' -o -name '*.py' | xargs wc -l 2>/dev/null | tail -1)"
  echo ""
  echo "### Recent Changes (last 5 commits)"
  git log --oneline -5
  echo ""
  echo "### Current Branch: $(git branch --show-current)"
  echo ""
  echo "### Open TODOs"
  rg -n "TODO|FIXME|HACK" src/ 2>/dev/null | head -20
  echo ""
  echo "### Task"
  echo "基于以上信息，生成项目健康报告。"
}

# 生成 Prompt 并执行
generate_prompt | codex exec --full-auto "$(cat)"

五、实战：完整的提示词工程模板

5.1 角色定义模板

bash

# 定义 AI 的角色
ROLE="你是一个有 10 年经验的资深软件工程师，擅长：
- TypeScript/Node.js 开发
- 系统架构设计
- 代码审查和质量保证
- 性能优化
- 安全最佳实践

你的审查风格：
- 严格但不苛刻
- 关注可维护性
- 注重边界情况
- 提供具体的修复建议而非泛泛而谈"

codex exec --full-auto "$ROLE

审查以下代码变更..."

5.2 输出格式模板

bash

OUTPUT_FORMAT="

## 输出格式要求

请严格按照以下 JSON Schema 输出：

\`\`\`json
{
  "review": {
    "status": "approved" | "changes_requested",
    "score": <0-100>,
    "summary": "<one-line summary>",
    "categories": {
      "security": { "status": "pass" | "fail", "issues": [...] },
      "performance": { "status": "pass" | "fail", "issues": [...] },
      "maintainability": { "status": "pass" | "fail", "issues": [...] },
      "testing": { "status": "pass" | "fail", "issues": [...] }
    },
    "action_items": [
      {
        "priority": "P0" | "P1" | "P2",
        "description": "...",
        "file": "...",
        "estimated_effort": "<S/M/L>"
      }
    ]
  }
}
\`\`\`

只输出 JSON，不要包含其他文字。"

5.3 完整的审查模板

bash

#!/bin/bash
# complete-review-template.sh

# 1. 角色
ROLE="你是一个资深代码审查员..."

# 2. 项目上下文
CONTEXT=$(cat .codex-context.md 2>/dev/null || echo "No context file found")

# 3. 代码变更
DIFF=$(git diff HEAD~1 HEAD)

# 4. 输出格式
FORMAT="输出格式：JSON..."

# 5. 审查标准
CRITERIA="审查标准：
1. 安全性：检查注入、XSS、CSRF、敏感数据泄露
2. 性能：检查 N+1 查询、内存泄漏、不必要的计算
3. 可维护性：检查命名、注释、函数长度、模块职责
4. 测试：检查测试覆盖率、边界情况、mock 使用
5. 规范：检查代码风格、lint 规则、提交规范"

# 组合完整 Prompt
FULL_PROMPT="$ROLE

## 项目上下文
$CONTEXT

## 代码变更
\`\`\`diff
$DIFF
\`\`\`

## 审查标准
$CRITERIA

## 输出格式
$FORMAT"

# 执行审查
echo "$FULL_PROMPT" | codex exec --full-auto "$(cat)"

5.4 Prompt 迭代优化

bash

#!/bin/bash
# prompt-iteration.sh —— 迭代优化 Prompt

# 初始 Prompt
PROMPT="审查这个 PR"

# 第一轮
RESULT=$(codex exec --full-auto "$PROMPT")
echo "Round 1 result: $RESULT"

# 分析结果，优化 Prompt
if echo "$RESULT" | grep -q "general"; then
  PROMPT="$PROMPT

  请具体指出代码中的问题行号和具体问题，不要给出泛泛的建议。
  对于每个问题，提供具体的修复代码示例。"
fi

# 第二轮
RESULT=$(codex exec --continue --full-auto "$PROMPT")
echo "Round 2 result: $RESULT"

# 继续优化...

六、高级技巧

6.1 少样本提示（Few-Shot Prompting）

bash

codex exec --full-auto "审查以下代码变更，按照示例格式输出：

示例 1：
变更：添加了用户注册接口
审查：[SECURITY] 密码没有哈希处理，使用 bcrypt
修复：const hashedPassword = await bcrypt.hash(password, 10);

示例 2：
变更：修改了数据库查询
审查：[PERFORMANCE] 使用了 SELECT *，应该只查询需要的字段
修复：SELECT id, name, email FROM users WHERE...

现在审查以下变更：
$(git diff HEAD~1 HEAD)"

6.2 思维链提示（Chain of Thought）

bash

codex exec --full-auto "审查以下代码。请按照以下步骤思考：

Step 1: 理解这段代码的目的是什么
Step 2: 分析数据流和控制流
Step 3: 识别潜在的安全问题
Step 4: 识别潜在的性能问题
Step 5: 检查边界情况和错误处理
Step 6: 评估代码的可维护性
Step 7: 综合以上分析，给出审查结论

代码变更：
$(git diff HEAD~1 HEAD)"

6.3 对抗性测试提示

bash

codex exec --full-auto "假设你是一个攻击者，审查以下代码并找出所有可以利用的漏洞：

代码：
$(cat src/auth/login.ts)

对于每个漏洞：
1. 描述攻击向量
2. 说明利用方式
3. 评估影响程度
4. 提供修复方案"

6.4 对比分析提示

bash

# 对比两个实现
codex exec --full-auto "对比以下两种实现方式，分析各自的优缺点：

实现 A (@src/serviceA.ts):
$(cat src/serviceA.ts)

实现 B (@src/serviceB.ts):
$(cat src/serviceB.ts)

从以下维度对比：
1. 性能
2. 可维护性
3. 可扩展性
4. 安全性
5. 测试友好度

给出推荐方案。"

总结

提示词工程是驾驭 AI Agent 最重要的技能。本文系统性地介绍了四大核心技巧：

1. 任务分解： 使用 MECE 方法将复杂任务拆分为独立的子任务，按依赖关系有序执行。

2. 上下文注入： 分层注入项目信息、编码规范、业务规则和当前任务目标，让 AI 具备领域知识。

3. 文件引用： 使用 @ 语法精确引用文件和目录，配合智能选择策略控制上下文大小。

4. 管道输入： 通过标准输入、here document、环境变量等方式，将动态生成的内容传入 Codex CLI。

关键要点：

好的 Prompt = 角色定义 + 上下文 + 明确任务 + 输出格式
复杂任务一定要分解，不要指望一个 Prompt 搞定一切
始终指定输出格式，优先使用 JSON Schema
利用管道将 Git、CI、日志等工具的输出无缝集成到 AI 工作流中
迭代优化 Prompt，根据 AI 的输出调整你的指令

系列结语

🎉 恭喜！你已经完成了 Codex CLI 系列的全部 30 篇文章！

从安装认证到提示词工程，我们已经覆盖了：

阶段	文章	核心主题
入门	19-20	安装、认证、exec 命令
核心	21-22	沙箱模式、Git 集成
进阶	23-24	后台模式、工作树并行
实战	25-26	PR Review、批量审查
集成	27-28	CI/CD、结构化输出
管理	29	Session 管理
精通	30	提示词工程

希望这个系列能帮助你充分挖掘 Codex CLI 的潜力，将 AI Agent 真正融入你的开发工作流。

Happy Coding! 🚀