ICIO

Input-Context-Instruction-Output

⭐⭐ 中等 4 个要素 ⏱️ 5 分钟学习

📦 组成要素

I

输入 Input

提供输入数据

C

上下文 Context

提供上下文

I

指令 Instruction

给出具体指令

O

输出 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 框架最佳实践

✅ 做这些事

  1. 清晰的初始问题

    • 一句话总结核心问题
    • 给出初步想法(即使不完整)
  2. 主动澄清关键信息

    • 问题越明确,迭代越高效
    • 不要让 AI 随意假设
  3. 及时反馈

    • 每轮给出清晰的反馈
    • 说明哪里不满意、为什么
  4. 知道何时停止

    • 当方案满足需求时停止
    • 不必穷尽所有可能性

❌ 避免这些事

  1. 初始问题太模糊

    • ❌ "帮我优化一下"
    • ✅ "我的订单查询接口响应慢"
  2. 反馈不具体

    • ❌ "还是不对"
    • ✅ "这个方案假设了强一致性,但我只需要最终一致"
  3. 无限迭代

    • ❌ 不知道何时停止
    • ✅ "基于成本和效果,我选择这个方案"
  4. 不跟进反馈

    • ❌ AI 提问后不回答
    • ✅ 及时提供信息和反馈

常见问题

Q: ICIO 和 ROBOTIC 的区别是什么?

A: ROBOTIC 是事先规划好的迭代(3轮固定),ICIO 是灵活的按需迭代(N轮不定)。

Q: 什么时候选择 ICIO?

A: 当问题模糊、需求不清时,ICIO 能更好地逐步化解歧义。

Q: 迭代几轮比较合理?

A: 通常 2-4 轮。超过 5 轮可能效率变低,应该重新评估。


进一步阅读