Prompt 优化器

分析一个草稿提示，对其进行评估，匹配到 ECC 生态系统组件，并输出一个完整的优化提示供用户复制粘贴并运行。

何时使用

• 用户说“优化这个提示”、“改进我的提示”、“重写这个提示”
• 用户说“帮我写一个更好的提示来...”
• 用户说“询问 Claude Code 的...最佳方式是什么？”
• 用户说“优化prompt”、“改进prompt”、“怎么写prompt”、“帮我优化这个指令”
• 用户粘贴一个草稿提示并要求反馈或改进
• 用户说“我不知道如何为此编写提示”
• 用户说“我应该如何使用 ECC 来...”
• 用户明确调用 /prompt-optimize

不要用于

• 用户希望直接执行任务（直接执行即可）
• 用户说“优化代码”、“优化性能”、“optimize this code”、“optimize performance”——这些是重构任务，不是提示优化
• 用户询问 ECC 配置（改用 configure-ecc）
• 用户想要技能清单（改用 skill-stocktake）
• 用户说“直接做”或“just do it”

工作原理

仅提供建议——不要执行用户的任务。

不要编写代码、创建文件、运行命令或采取任何实现行动。你的唯一输出是分析加上一个优化后的提示。

如果用户说“直接做”、“just do it”或“不要优化，直接执行”，不要在此技能内切换到实现模式。告诉用户此技能只生成优化提示，并指示他们如果要执行任务，请提出正常的任务请求。

按顺序运行这个 6 阶段流程。使用下面的输出格式呈现结果。

分析流程

阶段 0：项目检测

在分析提示之前，检测当前项目上下文：

1. 检查工作目录中是否存在 CLAUDE.md——读取它以了解项目惯例
2. 从项目文件中检测技术栈：
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin / Spring Boot
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. 记录检测到的技术栈，用于阶段 3 和阶段 4

如果未找到项目文件（例如，提示是抽象的或用于新项目），则跳过检测并在阶段 4 标记“技术栈未知”。

阶段 1：意图检测

将用户的任务分类为一个或多个类别：

阶段 2：范围评估

如果阶段 0 检测到项目，则使用代码库大小作为信号。否则，仅根据提示描述进行估算，并将估算标记为不确定。

阶段 3：ECC 组件匹配

将意图 + 范围 + 技术栈（来自阶段 0）映射到特定的 ECC 组件。

按意图类型

按技术栈

阶段 4：缺失上下文检测

扫描提示中缺失的关键信息。检查每个项目，并标记是阶段 0 自动检测到的还是用户必须提供的：

• [ ] 技术栈 —— 阶段 0 检测到的，还是用户必须指定？
• [ ] 目标范围 —— 提到了文件、目录或模块吗？
• [ ] 验收标准 —— 如何知道任务已完成？
• [ ] 错误处理 —— 是否考虑了边界情况和故障模式？
• [ ] 安全要求 —— 身份验证、输入验证、密钥？
• [ ] 测试期望 —— 单元测试、集成测试、E2E？
• [ ] 性能约束 —— 负载、延迟、资源限制？
• [ ] UI/UX 要求 —— 设计规范、响应式、无障碍访问？（如果是前端）
• [ ] 数据库变更 —— 模式、迁移、索引？（如果是数据层）
• [ ] 现有模式 —— 要遵循的参考文件或惯例？
• [ ] 范围边界 —— 什么不要做？

如果缺少 3 个以上关键项目，则在生成优化提示之前询问用户最多 3 个澄清问题。然后将答案纳入优化提示中。

阶段 5：工作流和模型推荐

确定此提示在开发生命周期中的位置：

Research → Plan → Implement (TDD) → Review → Verify → Commit

对于中等级别及以上的任务，始终以 /plan 开始。对于史诗级任务，使用蓝图技能。

模型推荐（包含在输出中）：

多提示拆分（针对高/史诗级范围）：

对于超出单个会话的任务，拆分为顺序提示：

• 提示 1：研究 + 计划（使用 search-first 技能，然后 /plan）
• 提示 2-N：每个提示实现一个阶段（每个阶段以 /verify 结束）
• 最终提示：集成测试 + 跨所有阶段的 /code-review
• 使用 /save-session 和 /resume-session 在会话之间保存上下文

输出格式

按照此确切结构呈现你的分析。使用与用户输入相同的语言进行回应。

第 1 部分：提示诊断

优点： 列出原始提示做得好的地方。

问题：

需要澄清： 用户应回答的问题编号列表。如果阶段 0 自动检测到答案，请陈述该答案而不是提问。

第 2 部分：推荐的 ECC 组件

第 3 部分：优化提示 —— 完整版本

在单个围栏代码块内呈现完整的优化提示。该提示必须是自包含的，可以复制粘贴。包括：

• 清晰的任务描述和上下文
• 技术栈（检测到的或指定的）
• 在正确工作流阶段调用的 /command
• 验收标准
• 验证步骤
• 范围边界（什么不要做）

对于引用蓝图的项目，写成：“使用蓝图技能来...”（而不是 /blueprint，因为蓝图是技能，不是命令）。

第 4 部分：优化提示 —— 快速版本

为有经验的 ECC 用户提供的紧凑版本。根据意图类型而变化：

第 5 部分：改进理由

页脚

不符合你的需求？告诉我需要调整什么，或者如果你想执行任务而不是优化提示，请提出正常的任务请求。

示例

触发示例

• "Optimize this prompt for ECC"
• "Rewrite this prompt so Claude Code uses the right commands"
• "帮我优化这个指令"
• "How should I prompt ECC for this task?"

示例 1：模糊的中文提示（检测到项目）

用户输入：

帮我写一个用户登录页面

阶段 0 检测到： package.json，使用 Next.js 15, TypeScript, Tailwind CSS

优化提示（完整）：

使用项目现有技术栈（Next.js 15 + TypeScript + Tailwind CSS）实现用户登录页面。

技术要求：
- 沿用项目现有的组件结构和路由约定
- 表单验证使用项目中已有的验证方案（检查是否已用 Zod/Yup/其他）
- 认证方式：沿用项目现有认证方案（如无，默认 JWT）
- 包含：邮箱/密码登录表单、表单验证、错误提示、加载状态、响应式布局

工作流：
1. /plan 先规划组件结构和认证流程，参考现有页面的模式
2. /tdd 测试先行：编写登录表单的单元测试和认证流程的集成测试
3. 实现登录页面和认证逻辑
4. /code-review 审查实现
5. /verify 验证所有测试通过且页面正常渲染

安全要求：
- 密码不明文传输
- 防止暴力破解（rate limiting）
- XSS 防护
- CSRF token

验收标准：
- 所有测试通过，覆盖率 80%+
- 页面在移动端和桌面端正常渲染
- 登录成功跳转到 dashboard，失败显示错误信息

不要做：
- 不要实现注册页面
- 不要实现忘记密码功能
- 不要修改现有的路由结构

示例 2：中等英文提示

用户输入：

Add a REST API endpoint for user profile updates with validation

阶段 0 检测到： go.mod，使用 Go 1.22, Chi router

优化提示（完整）：

Add a REST API endpoint for user profile updates (PATCH /api/users/:id).

Tech stack: Go 1.22 + Chi router (detected from project)

Requirements:
- PATCH /api/users/:id — partial update of user profile
- Input validation for fields: name, email, avatar_url, bio
- Auth: require valid token, users can only update own profile
- Return 200 with updated user on success
- Return 400 with validation errors on invalid input
- Return 401/403 for auth failures
- Follow existing API patterns in the codebase

Workflow:
1. /plan the endpoint structure, middleware chain, and validation logic
2. /tdd — write table-driven tests for success, validation failure, auth failure, not-found
3. Implement following existing handler patterns
4. /go-review
5. /verify — run full test suite, confirm no regressions

Do not:
- Modify existing endpoints
- Change the database schema (use existing user table)
- Add new dependencies without checking existing ones first (use search-first skill)

示例 3：史诗级项目

用户输入：

Migrate our monolith to microservices

优化提示（完整）：

Use the blueprint skill to plan: "Migrate monolith to microservices architecture"

Before executing, answer these questions in the blueprint:
1. Which domain boundaries exist in the current monolith?
2. Which service should be extracted first (lowest coupling)?
3. Communication pattern: REST APIs, gRPC, or event-driven (Kafka/RabbitMQ)?
4. Database strategy: shared DB initially or database-per-service from start?
5. Deployment target: Kubernetes, Docker Compose, or serverless?

The blueprint should produce phases like:
- Phase 1: Identify service boundaries and create domain map
- Phase 2: Set up infrastructure (API gateway, service mesh, CI/CD per service)
- Phase 3: Extract first service (strangler fig pattern)
- Phase 4: Verify with integration tests, then extract next service
- Phase N: Decommission monolith

Each phase = 1 PR, with /verify gates between phases.
Use /save-session between phases. Use /resume-session to continue.
Use git worktrees for parallel service extraction when dependencies allow.

Recommended: Opus 4.6 for blueprint planning, Sonnet 4.6 for phase execution.

相关组件