Auto-Prompt Generation

What it is

Auto-Prompt Generation（自动生成 Prompt）是 Loop Engineering 的核心子技能：不再由人类逐轮编写提示词，而是让循环系统根据当前目标状态、执行历史和约束条件，动态生成发给 AI 的 Prompt。其终极形态是 Boris Cherny 所说的"我不再给 Claude 写提示词了——我运行的是能自己给 Claude 写提示词并决定怎么做的循环"。

Why it matters

手动 Prompt 在多轮循环中存在四个瓶颈：

• 上下文丢失：多轮后原始意图被稀释
• 重复劳动：每轮都要重新描述目标
• 僵化：无法根据执行结果动态调整策略
• 规模限制：人类无法同时管理 10+ 并行任务

自动生成 Prompt 将工程价值从"单次 prompt craft"转向"循环设计、错误处理和状态管理"。

Three Mechanisms

1. 模板填充机制（Template-Based）

预定义模板 + 动态变量填充。最基础、最可控的方式。

适用场景：结构化任务，状态可明确定义（数据迁移、批量处理） 优点：可控、可预测、易于调试 缺点：不够灵活，难以处理意外情况

核心结构：

• 总体目标
• 当前状态（已完成步骤、当前阶段、剩余任务、上次结果）
• 本轮任务
• 约束条件（预算、时间、规则）
• 输出要求（执行结果、状态标记、下一步建议）

2. 状态驱动机制（State-Driven）

根据系统状态自动生成上下文感知的 Prompt。

适用场景：复杂多阶段任务，需要动态调整策略 优点：灵活、自适应、可处理复杂依赖 缺点：需要维护状态机，设计成本较高

核心组件：

• GoalState 类：管理目标、历史、阶段、产物、预算
• 滑动窗口历史：最近 N 轮执行摘要
• 阶段特定指令：init → execute → verify → finalize
• 预算警告注入：Token 使用率超过阈值时自动追加约束

3. 反思进化机制（Reflective Evolution）

最高级的方式：让 AI 自己反思并改进 Prompt。

适用场景：探索性任务，最佳路径未知，需要持续学习 优点：自我改进、适应未知领域、减少人工干预 缺点：需要额外的反思轮次，成本较高，可能"想太多"

核心流程：

1. 本轮执行回顾（目标、动作、结果、成功否）
2. 反思问题（Prompt 是否清晰？策略是否有效？意外如何预防？目标是否需要细化？）
3. 生成优化后的下一轮 Prompt（修正目标、调整策略、新增预防措施、更清晰验收标准）

Boris Cherny's Workflow

Boris Cherny（Claude Code 负责人）的实际工作流拆解：

架构：目标定义 → 初始化循环 → 执行循环（生成 Prompt → 执行动作 → 观察结果 → 更新状态 → 反思调整）

Step 1: 目标定义（一次性人工输入）

• 目标描述 + 背景 + 验收标准 + 约束条件
• 示例：重构所有数据库查询，添加连接池支持

Step 2: 初始化循环

• 创建工作区和状态文件
• 定义阶段：analyze → implement → verify
• 预设待处理任务列表

Step 3: 执行循环（核心）

• 读取当前状态（phase, turn, completed/pending tasks）
• 生成本轮 Prompt（Python 脚本动态组装）
• 调用 Claude 执行
• 解析结果（SUCCESS / FAILED / GOAL_COMPLETE）
• 更新状态文件
• 卡住检测（零工具调用时暂停）

Step 4: Prompt 生成器（核心中的核心）

• 读取目标文件和状态文件
• 构建动态 Prompt（目标 + 状态 + 阶段指令 + 输出格式）
• 阶段指令示例：analyze 阶段要求输出查询文件列表、模式分析、集成策略

Codex /goal Three-Layer Protection

Codex CLI 的 /goal 命令实现了生产级的自动循环保护：

Layer 1: 零工具调用抑制

• 如果上一轮没有调用任何工具，说明模型"卡住"了
• 强制暂停，避免空转浪费 token
• 原理：模型只是"思考"而没有实际行动时，可能陷入循环或不确定如何继续

Layer 2: 预算控制

• 使用率 > 100%：完全停止
• 使用率 > 80%：注入预算警告到 Prompt，迫使优先完成核心任务
• 使用率 < 80%：继续执行

Layer 3: 完成审计协议

• 拆解验证：将目标拆解为具体可交付物，逐一验证
• 证据检查：每个需求必须有实际证据支持（文件、测试结果、输出）
• 禁止代理证据：不能仅凭"测试通过"就认为完成，必须检查实际功能
• 用户确认：存在不确定性时标记 NEEDS_REVIEW 而非 COMPLETE

关键陷阱：

• "我写了代码" ≠ "功能实现了"
• "测试通过了" ≠ "需求满足了"
• "看起来没问题" ≠ "验证完成"

Six Building Blocks Implementation

基于 Addy Osmani 的 Loop Engineering 框架，以下是每个构建块的具体实现参考：

1. 目标规范（Goal Spec）

• description + success_criteria + constraints + max_turns + max_tokens
• validate_completion()：逐条检查成功标准

2. 状态管理（State Manager）

• SQLite 持久化每一轮的状态（goal_id, turn, prompt, actions, result, timestamp）
• get_context_window()：获取最近 N 轮用于上下文

3. 工具调用追踪（Tool Call Tracker）

• record()：记录工具名、参数、结果、时间戳
• has_real_progress()：检查最后几个调用是否重复（防卡住）

4. 预算守卫（Budget Guard）

• check_and_update()：累计 token，检查轮次和预算
• 超过阈值时返回 halt_reason 或 warning

5. 完成审计器（Completion Auditor）

• AUDIT_PROMPT：让 Claude 对完成情况进行严格审计
• 输出：PASS / NEEDS_MORE_WORK / REJECT

6. 人工介入触发器（Human Escalation）

• 可配置触发条件（连续失败、破坏性操作、预算耗尽但目标未完成）
• 返回优先级、消息、上下文

Practical Example: Wiki Absorb Automation

基于实际需求（自动 wiki-absorb），可运行的循环设计：

目标：自动监控 raw/to-learn/ 目录，对新文章执行 wiki-absorb 流程

验收标准：

1. 检测新文件（按修改时间或 git status）
2. 读取并分析内容
3. 生成合适的 wiki 页面路径和标题
4. 更新 _absorb_log.json
5. 更新 log.md
6. 更新 index.md
7. 创建/更新概念页面

约束：

• 不覆盖已有 wiki 页面（除非明确标记为更新）
• 保持 wiki 的目录结构规范
• 所有操作可追踪（通过 log）

Key Principles

1. 目标 > 过程：定义清晰的终态，让路径自发涌现
2. 验证 > 产出：产出代码 ≠ 完成目标，必须通过验收标准
3. 约束 > 自由：给模型明确的边界，反而能提升效率
4. 审计 > 信任：自动审计机制防止"代理证据接受"

Usage Matrix

Common Pitfalls

• 过度设计：不要为简单任务构建复杂循环
• 上下文膨胀：定期压缩历史，保持 Prompt 简洁
• 循环依赖：避免 A 依赖 B，B 依赖 A 的死锁
• 目标漂移：定期检查是否偏离原始目标

Related Concepts

Key Quotes

1. "我不再给 Claude 写提示词了。我运行的是能自己给 Claude 写提示词并决定怎么做的循环。" — Boris Cherny
2. "目标 > 过程，验证 > 产出，约束 > 自由，审计 > 信任"
3. "循环本身是中性的。深度理解工作的开发者利用它加速；试图逃避思考的人则利用它快速陷入更深的困境。"

Evidence across sources

Open Questions

• 三种机制之间如何组合？是否存在"混合机制"的最佳实践？
• 反思进化的成本效益边界在哪里？何时应该停止反思、直接执行？
• 如何设计 Loop 的"刹车机制"——当理解腐蚀达到临界点时自动暂停？
• 自动生成 Prompt 的评估标准是什么？如何衡量一个 Prompt 生成器的质量？

Related

• Loop Engineering
• Claude Code /goal 命令实战指南
• Agent in Loop Methodology
• Self-Verification Loops
• Dynamic Workflows
• Claude Code Overview