ICIO
Input-Context-Instruction-Output
📦 组成要素
输入 Input
提供输入数据
上下文 Context
提供上下文
指令 Instruction
给出具体指令
输出 Output
指定输出格式
✅ 适合
迭代式问题解决
📖 详细说明
Prompt 框架:ICIO
ICIO 框架概述
ICIO 是一个强调迭代式问题求解的 Prompt 框架,特别适合需要分步骤逐层深化的问题。框架名称由四个核心要素组成:
- Init(初始化问题)
- Clarify(澄清细节)
- Iterate(迭代优化)
- Outcome(最终输出)
ICIO 框架强调问题的渐进式求解,是解决模糊需求的有力工具。
特点
| 特点 | 说明 |
|---|---|
| 学习曲线 | 低,逻辑简单直观 |
| 适用场景 | 问题求解、逐步优化、需求细化 |
| 框架复杂度 | ⭐ 简洁(4个要素) |
| 有效性 | ⭐⭐⭐⭐ 很高 |
| 迭代性 | 强(明确的迭代机制) |
| 灵活性 | 高(可根据反馈随意调整) |
ICIO 的优势
✅ 逐步精化 - 从模糊到明确,从简单到复杂 ✅ 易于调整 - 每步都可以基于反馈修改方向 ✅ 发散后收敛 - 先探索多个方向,再聚焦最优方案 ✅ 学习友好 - 过程中不断学习和优化 ✅ 高效反馈 - 快速验证想法的可行性
ICIO 的局限
❌ 需要多轮对话 - 不是一次得到最终答案 ❌ 时间成本 - 相对耗时,不适合紧急情况 ❌ 收敛困难 - 有时会陷入局部最优
模板
[Init]
初始化问题:
- [核心问题描述]
- [初步想法或假设]
[Clarify]
澄清方向(第1轮):
- [需要了解的关键信息]
- [可能的约束条件]
- [期望改进的维度]
[Iterate]
迭代优化(第2-N轮):
- 基于你的反馈调整方向
- 深化某个维度的细节
- 验证可行性
[Outcome]
最终输出:
- [综合多轮反馈的最优方案]
- [完整的实现方案]
相关框架比较
| 维度 | ICIO | BROKE | ROBOTIC |
|---|---|---|---|
| 速度 | 慢(多轮) | 快(一次) | 中等 |
| 效果 | 逐步优化 | 直接结果 | 完整方案 |
| 适合 | 模糊问题 | 明确需求 | 复杂项目 |
| 反馈 | 实时反馈 | 可选反馈 | 计划反馈 |
| 学习成本 | 低 | 极低 | 中 |
应用实践
实践1:API 设计迭代
问题描述:设计一个用户查询 API,需要逐步优化
[Init]
初始化问题:
设计一个查询用户列表的 REST API
初步想法:GET /users 返回所有用户
[Clarify - 第1轮]
我需要澄清:
- 是否需要分页?用户量有多大?
- 是否需要筛选(按状态、部门等)?
- 响应字段是否需要可选定制?
- 性能要求是什么?
基于回答,我会给出改进的 API 设计
过程示例:
第1轮反馈:"10万用户,需要分页和筛选" → AI 改进:添加分页、筛选参数,讨论分页策略
第2轮反馈:"不同客户端需要不同字段" → AI 继续改进:添加字段选择机制(fields 参数或 GraphQL 方案)
第3轮反馈:"性能要求 P99 < 200ms" → AI 最终方案:缓存策略、索引建议、字段裁剪
实践2:架构方案优化
问题描述:逐步优化应用架构
[Init]
初始化问题:
我想从单体应用迁移到微服务
初步想法:按业务域拆分(订单、支付、库存)
[Clarify - 第1轮]
澄清关键信息:
- 团队规模?拆分后能否独立维护?
- 数据一致性要求?
- 部署方式?
- 迁移的时间压力?
基于这些,我会给出初步的拆分方案
过程示例:
第1轮:"8人团队,可接受最终一致,有9个月" → AI:提出基于 Saga 模式的异步通信方案
第2轮用户反馈:"支付系统很复杂,是否要单独拆出来?" → AI:讨论支付的独立性,可能拆为 PaymentService
第3轮用户反馈:"现在有 Redis 缓存,能否利用?" → AI:加入缓存策略到最终架构方案
实践3:性能优化方案
问题描述:逐步诊断和优化性能问题
[Init]
初始化问题:
应用在流量高峰期响应变慢
[Clarify - 第1轮]
需要澄清的信息:
- 是哪个接口变慢?
- 变慢发生在什么场景(并发量、数据量)?
- 现在的监控数据是什么?
- 用的什么数据库和缓存?
基于这些信息,我会给出初步的诊断方向
过程示例:
第1轮:"订单查询接口,P99 从 100ms 升到 5s,QPS 5000" → AI:初步怀疑是数据库查询慢,建议检查索引和慢查询日志
第2轮用户反馈:"查询日志正常,没有慢查询" → AI:转向其他方向,考虑网络延迟、缓存失效等
第3轮用户反馈:"发现是上游依赖服务超时导致级联故障" → AI:最终方案:加入超时控制、断路器、异步处理
ICIO 框架最佳实践
✅ 做这些事
-
清晰的初始问题
- 一句话总结核心问题
- 给出初步想法(即使不完整)
-
主动澄清关键信息
- 问题越明确,迭代越高效
- 不要让 AI 随意假设
-
及时反馈
- 每轮给出清晰的反馈
- 说明哪里不满意、为什么
-
知道何时停止
- 当方案满足需求时停止
- 不必穷尽所有可能性
❌ 避免这些事
-
初始问题太模糊
- ❌ "帮我优化一下"
- ✅ "我的订单查询接口响应慢"
-
反馈不具体
- ❌ "还是不对"
- ✅ "这个方案假设了强一致性,但我只需要最终一致"
-
无限迭代
- ❌ 不知道何时停止
- ✅ "基于成本和效果,我选择这个方案"
-
不跟进反馈
- ❌ AI 提问后不回答
- ✅ 及时提供信息和反馈
常见问题
Q: ICIO 和 ROBOTIC 的区别是什么?
A: ROBOTIC 是事先规划好的迭代(3轮固定),ICIO 是灵活的按需迭代(N轮不定)。
Q: 什么时候选择 ICIO?
A: 当问题模糊、需求不清时,ICIO 能更好地逐步化解歧义。
Q: 迭代几轮比较合理?
A: 通常 2-4 轮。超过 5 轮可能效率变低,应该重新评估。