Prompt 框架：ROBOTIC

ROBOTIC 框架概述

ROBOTIC 是一个系统性的 Prompt 框架，强调迭代反馈和长期优化，特别适合架构设计和复杂项目场景。框架名称由七个核心要素组成：

• Role（角色）
• Objective（目标）
• Background（背景）
• Output（输出）
• Type（类型）
• Iterate（迭代）
• Clarify（澄清）

ROBOTIC 框架强调完整性和迭代机制，适合需要多轮评审和持续优化的复杂任务。

特点

ROBOTIC 的优势

✅ 迭代机制完整 - 明确的反馈和改进流程 ✅ 适合复杂项目 - 设计、架构、长期规划的首选 ✅ 团队协作友好 - 清晰的反馈链路便于评审 ✅ 全面性 - 从目标到具体输出都有考虑 ✅ 边界清晰 - Clarify 环节消除歧义

ROBOTIC 的局限

❌ 学习成本高 - 需要理解7个要素及其关系 ❌ 前期投入大 - 需要更多的初始准备和思考 ❌ 快速编码不适用 - 不适合"快速出活"的场景 ❌ 对话轮数多 - 通常需要 3-5 轮对话

模板

[Role]
你是一名 [职位]，拥有 [N年] 经验。
背景：[相关经历]
擅长：[专业领域1]、[专业领域2]、[专业领域3]

[Objective]
要完成的任务：[核心目标]
最终交付物：[具体的输出形式]

[Background]
项目背景：
- [项目类型和规模]
- [业务背景和约束]
- [技术栈和架构]
- [现有的条件和资源]

[Output]
期望的输出包括：
1. [输出形式1 - 例如架构图]
2. [输出形式2 - 例如代码实现]
3. [输出形式3 - 例如文档说明]

[Type]
这是一个 [设计/规划/实现] 任务，
特点：[需要深度思考/需要创意/需要技术深度]

[Iterate]
反馈流程：
- 第1轮：[期望的第一阶段交付]
- 第2轮：[基于反馈的优化方向]
- 第3轮：[最终完善]

[Clarify]
在开始前，我需要澄清以下问题：
1. [关键问题1]
2. [关键问题2]
3. [关键问题3]

相关框架比较

何时选择 ROBOTIC？

✅ 要设计一个新的系统或服务 ✅ 需要多轮评审和反馈 ✅ 涉及团队协作和知识转移 ✅ 任务复杂，需要边界澄清 ✅ 长期项目，需要清晰的路线图

应用实践

实践1：DDD 电商订单系统设计

问题描述：使用 DDD 设计电商订单核心领域模型

[Role]
你是一名资深的 Java 架构师，拥有12年互联网经验。
背景：主导过多个百万级日活电商系统的架构设计
擅长：DDD 领域驱动设计、微服务架构、事件驱动

[Objective]
要完成的任务：使用 DDD 设计电商订单服务的聚合根和核心领域模型
最终交付物：领域模型设计文档、Java 实现代码、业务规则说明

[Background]
项目背景：
- 电商平台，日均处理 100万订单
- 支持多种支付方式（支付宝、微信、银行卡、余额）
- 订单生命周期：创建 → 支付 → 发货 → 收货 → 完成/售后
- 需要支持分次支付、分次发货、退款等复杂流程
- 技术栈：Spring Boot 3.2、Java 21、MongoDB（事件溯源）

[Output]
期望的输出包括：
1. 领域对象 UML 类图（Mermaid 格式）
2. Java Record/Class 实现（使用 Java 21 特性，无 setter）
3. 领域事件定义（OrderCreated、OrderPaid、OrderShipped 等）
4. 业务规则文档（金额验证、状态转移规则）

[Type]
这是一个架构设计任务，需要深度的领域知识和严谨的设计思考。
不是简单的编码，而是系统化的模型设计。

[Iterate]
反馈流程：
- 第1轮：给出核心聚合根（Order、OrderItem、Money 等价对象）和基本状态机
- 第2轮：添加事件发布机制、支持部分支付和分次发货
- 第3轮：处理并发控制、事件一致性、性能优化

[Clarify]
在开始前，我需要澄清：
1. 订单是否需要支持拆单（1个逻辑订单拆成多个物流订单）？
2. 退款是否需要原路返回还是可以退到其他账户？
3. 是否使用完整事件溯源还是快照+事件混合方式？

反馈流程示例：

第1轮后用户反馈："支持分次支付和分次发货" → AI 第2轮调整设计，添加 Payment 和 Shipment 集合

第2轮后用户反馈："如何处理支付和发货的并发竞态？" → AI 第3轮添加乐观锁和版本控制机制

实践2：微服务架构演进规划

问题描述：规划从单体应用向微服务的迁移

[Role]
你是一名资深的技术主管/架构师，有8年微服务架构经验
背景：成功主导过2个大型系统从单体到微服务的重构
擅长：微服务拆分策略、团队协调、风险管理

[Objective]
要完成的任务：为一个现有的单体 Java 应用规划微服务架构演进方案
最终交付物：架构演进路线图、服务拆分方案、实施计划

[Background]
项目背景：
- 现状：单体 JSP 应用，60万行代码，日均 1000万请求
- 技术栈：Java 8、Spring MVC、MySQL、单机部署
- 团队：20人，3个小组（核心功能、支付、数据分析）
- 约束：不能停服，需要平稳过渡，预算有限

[Output]
期望的输出包括：
1. 现状分析（瓶颈识别、拆分边界提议）
2. 目标架构（服务划分、通信方式、数据存储）
3. 迁移路线图（分阶段实施计划，6个月 vs 12个月方案）
4. 风险评估和应对措施

[Type]
这是一个战略规划和架构设计任务，需要平衡：
技术理想 vs 现实约束、风险 vs 收益、投入 vs 收益

[Iterate]
反馈流程：
- 第1轮：初步的服务拆分方案和阶段规划
- 第2轮：基于团队反馈调整拆分边界和时间表
- 第3轮：深化具体的实施细节和应急预案

[Clarify]
在开始前，我需要澄清：
1. 团队是否有微服务经验？
2. 是否要求保持现有的技术栈（Java 8）还是可以升级？
3. 数据一致性的要求（强一致 vs 最终一致）？

实践3：技术选型和调研

问题描述：为项目选择合适的开发框架和工具

[Role]
你是一名资深的技术决策顾问，拥有15年的技术选型经验
背景：指导过30+ 个项目的技术栈决策
擅长：框架对比评估、长期技术演进规划、成本效益分析

[Objective]
要完成的任务：为我的新项目选择合适的前后端技术栈
最终交付物：技术选型报告、对比分析、建议方案

[Background]
项目背景：
- 实时数据分析平台，需要处理百万级数据点
- 用户：100+ 企业用户，每个用户有大量数据
- 需求：低延迟（< 1秒）、高并发（QPS 10000+）、可靠性高（99.99%）
- 时间：9个月上线，团队 8人

[Output]
期望的输出包括：
1. 后端框架对比（Spring Boot vs Quarkus vs Micronaut）
2. 数据库选择（PostgreSQL vs MongoDB vs ClickHouse）
3. 实时通信方案（WebSocket vs SSE vs gRPC）
4. 部署方案（Docker/K8s vs 传统服务器）
5. 最终建议和成本估算

[Type]
这是一个技术决策任务，需要考虑：
功能完善性、性能表现、学习成本、社区支持、长期维护

[Iterate]
反馈流程：
- 第1轮：技术方案对比和初步建议
- 第2轮：基于团队的技术水平调整建议
- 第3轮：给出详细的迁移和升级路径

[Clarify]
在开始前，我需要澄清：
1. 团队的技术水平和学习能力如何？
2. 是否已有技术栈倾向（如必须用某个框架）？
3. 对开源社区的要求（必须商业支持 vs 可以自己维护）？

ROBOTIC 框架最佳实践

✅ 做这些事

1. 明确的迭代流程

   • 指定每轮期望的交付物
   • 说明反馈和改进方向

2. 详尽的背景信息

   • 包含项目规模、业务约束、技术现状
   • 明确的非功能需求（性能、可靠性等）

3. 提前澄清关键问题

   • 列出可能有歧义的地方
   • 主动消除理解偏差

4. 清晰的输出期望

   • 明确输出的形式和粒度
   • 包含评审标准

❌ 避免这些事

1. 模糊的迭代计划

   • ❌ "我们迭代调整"
   • ✅ "第1轮给初稿，第2轮基于反馈调整，第3轮优化细节"

2. 隐瞒实际约束

   • ❌ "理想的架构是什么"
   • ✅ "在9个月和8人团队的约束下，如何架构"

3. 期望不明确

   • ❌ "给我一个设计"
   • ✅ "给我 Mermaid 架构图、核心代码、文档说明"

4. 没有澄清关键假设

   • ❌ 让 AI 随意假设
   • ✅ 主动提问消除歧义

常见问题

Q: ROBOTIC 和 CRISPE 有什么区别？

A: CRISPE 强调问题分析，ROBOTIC 强调架构设计和迭代。CRISPE 回答"为什么"，ROBOTIC 给出"完整方案"。

Q: 一定要3轮迭代吗？

A: 不一定。根据问题复杂度调整。简单问题1-2轮，复杂问题3-5轮。

Q: 如何决定什么时候用 ROBOTIC 而不用 BROKE？

A: BROKE 用于"实现已设计好的功能"，ROBOTIC 用于"设计本身"。

进一步阅读

• 📚 ROBOTIC 框架完全指南
• 🎯 三框架深度对比
• 💡 Prompt 工程完全指南