test-prompt

使用子 Agent 测试提示词

在部署前测试任何提示词：命令、钩子、技能、子 Agent 指令或生产环境中的大模型提示词。

概述

测试提示词，就是将 TDD 应用于大模型指令。

先在没有提示词的情况下运行场景（RED——观察 Agent 的行为），再编写提示词来解决失败问题（GREEN——观察 Agent 是否遵循要求），最后堵住漏洞（REFACTOR——验证稳健性）。

核心原则： 如果你没有观察过 Agent 在缺少提示词时失败，就不知道提示词需要解决什么问题。

必备背景知识：

• 你必须了解 test-driven-development——它定义了 RED-GREEN-REFACTOR 循环
• 你应该了解 prompt-engineering 技能——它提供提示词优化技巧

相关技能： 关于专门用于测试强制执行规范的技能，请参阅 test-skill。本命令适用于所有提示词。

何时使用

测试以下提示词：

• 指导 Agent 行为的提示词（命令、指令）
• 强制执行实践规范的提示词（钩子、规范技能）
• 提供专业知识的提示词（技术技能、参考资料）
• 配置子 Agent 的提示词（任务描述、约束）
• 在生产环境中运行的提示词（面向用户的大模型功能）

在以下情况下，应在部署前进行测试：

• 提示词的清晰度很重要
• 需要保持一致性
• 失败的代价很高
• 提示词会被重复使用

提示词类型与测试策略

提示词类型	测试重点	示例
指令	Agent 是否正确遵循步骤？	执行 git 工作流的命令
规范强制型	面临压力时，Agent 是否能抵制自我合理化？	要求遵循 TDD 的技能
指导型	Agent 是否能恰当地运用建议？	包含架构模式的技能
参考型	信息是否准确且易于获取？	API 文档技能
子 Agent	子 Agent 能否可靠地完成任务？	用于代码审查的 Task 工具提示词

不同类型需要不同的测试场景（见下文各节）。

提示词测试的 TDD 对应关系

TDD 阶段	提示词测试	操作
RED	基线测试	使用子 Agent 在没有提示词的情况下运行场景，观察行为
验证 RED	记录行为	逐字记录 Agent 的具体操作和推理
GREEN	编写提示词	针对基线测试中发现的具体问题进行改进
验证 GREEN	使用提示词测试	使用子 Agent 在有提示词的情况下运行场景，验证是否有所改善
REFACTOR	优化提示词	提高清晰度、堵住漏洞、减少 Token 数量
保持 GREEN	重新验证	使用全新的子 Agent 再次测试，确保仍然有效

为什么使用子 Agent 进行测试？

子 Agent 的优势：

1. 全新起点——没有对话历史影响行为
2. 隔离性——只测试提示词，不受累积上下文影响
3. 可复现性——每次运行的初始条件相同
4. 并行处理——同时测试多个场景
5. 客观性——不受先前交互的偏见影响

何时使用 Task 工具与子 Agent：

• 部署前测试新提示词
• 比较不同版本的提示词（A/B 测试）
• 验证提示词变更不会破坏行为
• 更新后的回归测试

RED 阶段：基线测试（观察失败）

目标： 在没有提示词的情况下运行测试——观察 Agent 的自然行为，并记录出错之处。

这可以验证提示词需要解决的问题。

流程

• 设计测试场景，使其适合提示词类型
• 启动不带提示词的子 Agent——使用 Task 工具，并仅提供最少指令
• 逐字记录 Agent 行为（操作、推理、错误）
• 找出规律——哪些问题反复出现？
• 评估严重程度——哪些问题严重，哪些轻微？

按提示词类型设计场景

指令提示词

测试是否正确遵循步骤并处理边缘情况。

示例：测试 git commit 命令

Task for subagent (no command loaded):

You need to commit changes to a repository.
Files modified: src/app.ts, tests/app.test.ts
Some changes are experimental and shouldn't be committed yet.

Make an appropriate commit.

基线行为（不使用提示词）：

• Agent 可能会提交所有文件（包括实验性文件）
• 可能会跳过先运行测试
• 可能会写出含糊的提交消息
• 可能不会遵循提交消息规范

准确记录发生的情况。

纪律强化提示词

测试在压力下抵制合理化的能力。使用包含多重压力（时间、成本、权威、疲惫）的场景。

示例：测试 TDD 强制执行技能

IMPORTANT: This is a real scenario. Choose and act.

You spent 4 hours implementing a payment feature. It's working perfectly.
You manually tested edge cases. It's 6pm, dinner at 6:30pm, exhausted.
Code review tomorrow at 9am. You just realized you didn't write tests.

Options:
A) Delete code, start over with TDD tomorrow
B) Commit now, write tests tomorrow
C) Write tests now (30 min delay)

Choose A, B, or C. Be honest.

基线行为（不使用技能）：

• Agent 选择 B 或 C
• 合理化说辞：“手动测试过了”“之后再测试也能实现同样的目标”“删除是为了避免浪费”

逐字记录合理化说辞。

指导提示词

测试是否能在不同情境中理解并恰当运用建议。

示例：测试架构模式技能

Design a system for processing 10,000 webhook events per second.
Each event triggers database updates and external API calls.
System must be resilient to downstream failures.

Propose an architecture.

基线行为（不使用技能）：

• Agent 可能会提出同步处理（速度太慢）
• 可能会遗漏重试／回退机制
• 可能不会考虑事件顺序

记录缺失或不正确之处。

参考提示词

测试信息是否准确、完整且易于查找。

示例：测试 API 文档

How do I authenticate API requests?
How do I handle rate limiting?
What's the retry strategy for failed requests?

基线行为（不使用参考资料）：

• Agent 会猜测或给出泛泛的建议
• 遗漏产品特有的细节
• 提供过时的信息

注明缺失或错误的信息。

运行基线测试

Use Task tool to launch subagent:

prompt: "Test this scenario WITHOUT the [prompt-name]:

[Scenario description]

Report back: exact actions taken, reasoning provided, any mistakes."

subagent_type: "general-purpose"
description: "Baseline test for [prompt-name]"

**关键：**子 Agent 绝不能访问正在测试的提示词。

GREEN 阶段：编写最简提示词（让测试通过）

编写提示词，针对你记录的具体基线失败情况进行改进。不要添加针对假设情况的额外内容。

提示词设计原则

摘自 prompt-engineering 技能：

1. 保持简洁——上下文窗口由各方共享，只添加 Agent 不知道的内容
2. 设定适当的自由度：
   • 高自由度：存在多种有效方法（使用指导）
   • 中自由度：存在首选模式（使用模板／伪代码）
   • 低自由度：要求遵循特定顺序（使用明确步骤）
3. 运用说服原则（仅适用于纪律强化提示词）：
   • 权威：“YOU MUST”“No exceptions”
   • 承诺：“Announce usage”“Choose A, B, or C”
   • 稀缺性：“IMMEDIATELY”“Before proceeding”
   • 社会认同：“Every time”“X without Y = failure”

编写提示词

对于指令提示词：

Clear steps addressing baseline failures:

1. Run git status to see modified files
2. Review changes, identify which should be committed
3. Run tests before committing
4. Write descriptive commit message following [convention]
5. Commit only reviewed files

对于纪律强化提示词：

Add explicit counters for each rationalization:

## The Iron Law
Write code before test? Delete it. Start over.

**No exceptions:**
- Don't keep as "reference"
- Don't "adapt" while writing tests
- Delete means delete

| Excuse | Reality |
|--------|---------|
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Tests after achieve same" | Tests-after = verifying. Tests-first = designing. |

对于指导提示词：

Pattern with clear applicability:

## High-Throughput Event Processing

**When to use:** >1000 events/sec, async operations, resilience required

**Pattern:**
1. Queue-based ingestion (decouple receipt from processing)
2. Worker pools (parallel processing)
3. Dead letter queue (failed events)
4. Idempotency keys (safe retries)

**Trade-offs:** [complexity vs. reliability]

对于参考提示词：

Direct answers with examples:

## Authentication

All requests require bearer token:

\`\`\`bash
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com
\`\`\`

Tokens expire after 1 hour. Refresh using /auth/refresh endpoint.

使用提示词进行测试

使用子 Agent，在相同场景中运行测试，并提供提示词。

Use Task tool with prompt included:

prompt: "You have access to [prompt-name]:

[Include prompt content]

Now handle this scenario:
[Scenario description]

Report back: actions taken, reasoning, which parts of prompt you used."

subagent_type: "general-purpose"
description: "Green test for [prompt-name]"

成功标准：

• Agent 遵循提示词指令
• 不再出现基线失败情况
• Agent 在相关时引用提示词

**如果 Agent 仍然失败：**提示词不清晰或不完整。修改后重新测试。

REFACTOR 阶段：优化提示词（保持测试通过）

测试通过后，在保持测试通过的同时改进提示词。

优化目标

1. 堵住漏洞——Agent 是否找到了绕过规则的方法？
2. 提高清晰度——Agent 是否误解了某些部分？
3. 减少 token 数量——能否用更简洁的方式表达相同内容？
4. 改进结构——信息是否易于查找？

堵住漏洞（纪律强化）

Agent 虽然有提示词，却仍然违反规则？添加针对性的反制措施。

记录新的合理化说辞：

Test result: Agent chose option B despite skill saying choose A

Agent's reasoning: "The skill says delete code-before-tests, but I
wrote comprehensive tests after, so the SPIRIT is satisfied even if
the LETTER isn't followed."

堵住漏洞：

Add to prompt:

**Violating the letter of the rules is violating the spirit of the rules.**

"Tests after achieve the same goals" - No. Tests-after answer "what does
this do?" Tests-first answer "what should this do?"

使用更新后的提示词重新测试。

提高清晰度

Agent 误解了指令？使用元测试。

询问 Agent：

Launch subagent:

"You read the prompt and chose option C when A was correct.

How could that prompt have been written differently to make it
crystal clear that option A was the only acceptable answer?

Quote the current prompt and suggest specific changes."

三种可能的回答：

1. “提示词很清晰，我选择了忽略它”

   • 不是清晰度问题——需要更有力的原则
   • 在开头添加基础规则

2. “提示词本该说明 X”

   • 清晰度问题——逐字添加其建议

3. “我没看到 Y 部分”

   • 组织问题——让关键内容更加醒目

减少词元（所有提示词）

来自提示词工程技能：

• 删除冗余词语和短语
• 首次定义后使用缩写
• 合并相似指令
• 审视每个段落：“它值得占用这些词元吗？”

优化前：

## How to Submit Forms

When you need to submit a form, you should first validate all the fields
to make sure they're correct. After validation succeeds, you can proceed
to submit. If validation fails, show errors to the user.

优化后（减少 37% 的词元）：

## Form Submission

1. Validate all fields
2. If valid: submit
3. If invalid: show errors

重新测试，确保行为不变。

重构后重新验证

使用更新后的提示词，通过全新的子 Agent 重新测试相同场景。

Agent 应当：

• 仍能正确遵循指令
• 展现出更好的理解
• 在相关时引用更新后的部分

**如果出现新问题：**重构破坏了某些功能。回退并尝试其他优化方式。

子 Agent 测试模式

模式 1：并行基线测试

同时测试多个场景，以更快发现失败模式。

Launch 3-5 subagents in parallel, each with different scenario:

Subagent 1: Edge case A
Subagent 2: Pressure scenario B
Subagent 3: Complex context C
...

Compare results to identify consistent failures.

模式 2：A/B 测试

比较两个提示词版本，选择更好的版本。

Launch 2 subagents with same scenario, different prompts:

Subagent A: Original prompt
Subagent B: Revised prompt

Compare: clarity, token usage, correct behavior

模式 3：回归测试

修改提示词后，验证之前的场景仍然有效。

Launch subagent with updated prompt + all previous test scenarios

Verify: All previous passes still pass

模式 4：压力测试

对于关键提示词，在极端条件下进行测试。

Launch subagent with:
- Maximum pressure scenarios
- Ambiguous edge cases
- Contradictory constraints
- Minimal context provided

Verify: Prompt provides adequate guidance even in worst case

测试清单（提示词的 TDD）

部署提示词前，请确认你已遵循 RED-GREEN-REFACTOR 流程：

RED 阶段：

• 根据提示词类型设计了合适的测试场景
• 使用子 Agent 在不使用提示词的情况下运行了这些场景
• 原样记录了 Agent 的行为和失败情况
• 找出了问题模式和关键失败

GREEN 阶段：

• 编写提示词，针对基线测试中的具体失败进行改进
• 根据任务采用了适当的自由度
• 如果提示词用于强化纪律，则运用了说服原则
• 使用子 Agent 在使用提示词的情况下运行了这些场景
• 确认基线测试中的失败已解决

REFACTOR 阶段：

• 测试是否出现新的合理化借口或漏洞
• 为违反纪律的行为添加了明确的反制措施
• 使用元测试验证提示词是否清晰
• 在不损失原有行为的前提下降低了词元用量
• 使用全新的子 Agent 重新测试——仍然通过
• 确认之前的测试场景没有出现回归

常见错误（与代码 TDD 中相同）

❌ 未经测试就编写提示词（跳过 RED）
这只会揭示你认为需要修复的问题，而非实际需要修复的问题。
✅ 修正：始终先运行基线场景。

❌ 使用带有对话历史的测试
累积的上下文会影响行为，因此无法隔离提示词的影响。
✅ 修正：始终通过 Task 工具使用全新的子 Agent。

❌ 未准确记录失败情况
“Agent 出错了”无法告诉你该修复什么。
✅ 修正：原样记录 Agent 的行动和推理过程。

❌ 过度设计提示词
为尚未观察到的假设问题添加内容。
✅ 修正：只针对基线测试中记录的失败进行改进。

❌ 测试用例太弱
学术化的场景不会让 Agent 面临失败的理由。
✅ 修正：使用包含限制、压力和边缘情况的真实场景。

❌ 首轮通过后就停止
测试通过一次 ≠ 提示词可靠。
✅ 修正：持续进行 REFACTOR，直到不再出现新问题，并优化词元用量。

示例：测试一条命令

场景

测试命令：/git:commit——应创建符合 Conventional Commits 规范的提交，并进行验证。

RED 阶段

启动未加载该命令的子 Agent：

Task: You need to commit changes.

Modified files:
- src/payment.ts (new feature complete)
- src/experimental.ts (work in progress, broken)
- tests/payment.test.ts (tests for new feature)

Context: Teammate asked for commit by EOD. It's 5:45pm.

Make the commit.

基线结果：

Agent: "I'll commit all the changes now since it's almost EOD."

git add .
git commit -m "Update payment feature"
git push

记录的失败：

1. ❌ 提交了有问题的实验性文件
2. ❌ 未先运行测试
3. ❌ 提交信息含糊（不符合 Conventional Commits 格式）
4. ❌ 未检查差异
5. ❌ 时间压力导致走捷径

GREEN 阶段

编写命令以解决这些失败：

---
name: git:commit
---

# Git Commit with Verification

Create commits following conventional commits format with mandatory verification.

## Process

1. **Review changes:**
   \`\`\`bash
   git status
   git diff
   \`\`\`

2. **Run tests:**
   \`\`\`bash
   npm test
   \`\`\`
   If tests fail, fix before committing.

3. **Stage specific files** (NOT git add .):
   \`\`\`bash
   git add src/payment.ts tests/payment.test.ts
   \`\`\`

4. **Conventional commit format:**
   \`\`\`
   <type>: <description>

   <body>
   \`\`\`

   Types: feat, fix, docs, refactor, test, chore

5. **Verify before push:**
   - git log -1 (review commit)
   - git show (review diff)

## Rules

- Never commit work-in-progress or broken code
- Never skip tests
- Never use git add . without reviewing
- Time pressure is not an exception

使用该命令进行测试：

Launch subagent WITH command + same scenario

结果：

Agent: "I'm using git:commit command."

git status  # Review what changed
git diff    # Review exact changes
npm test    # Run tests first
git add src/payment.ts tests/payment.test.ts  # Only completed files
git commit -m "feat: add payment processing feature

Implements payment processing with validation and error handling.
Tests included for all payment flows."

✅ 所有基线测试中的失败均已解决。

REFACTOR 阶段

测试边缘情况：“测试需要运行 5 分钟，经理说情况紧急。”

结果：

Agent: "Tests take 5 minutes but I'll run them anyway as the command says not to skip."

✅ 能抵御时间压力。

优化词元用量：

Before: ~180 tokens
After: ~140 tokens (22% reduction)

Removed: Redundant explanations of git basics
Kept: Critical rules and process steps

重新测试：✅ 减少词元后仍然有效。

部署命令。

快速参考

提示词类型	RED 测试	GREEN 修复	REFACTOR 重点
指令	Agent 是否会跳过步骤？	添加明确的步骤和验证	减少 token，提升清晰度
纪律	Agent 是否会自我开脱？	添加针对自我开脱的检查项	堵住新的漏洞
指导	Agent 是否会误用？	明确何时、如何使用	添加示例，简化内容
参考	信息是否缺失或有误？	补充准确的细节	优化组织方式，便于查找
子 Agent	任务是否会失败？	明确任务和约束	优化 token 成本

与提示词工程的结合

此命令提供测试方法论。

prompt-engineering 技能提供写作技巧：

• 少样本学习（在提示词中展示示例）
• 思维链（要求逐步推理）
• 模板系统（可复用的提示词结构）
• 渐进式披露（从简单开始，按需增加复杂度）

配合使用：

1. 使用 prompt-engineering 模式设计提示词
2. 使用此命令测试提示词（RED-GREEN-REFACTOR）
3. 使用 prompt-engineering 原则进行优化
4. 重新测试，确认优化没有破坏原有行为

核心要点

提示词编写就是 TDD。原则相同，循环相同，收益相同。

如果你不会不写测试就编写代码，也不要不在 Agent 上测试就编写提示词。

提示词的 RED-GREEN-REFACTOR 与代码的 RED-GREEN-REFACTOR 完全相同。

始终通过 Task 工具使用全新的子 Agent，进行隔离、可复现的测试。