理解ISSUE协作范式

ISSUE就是让人和AI像开会一样协作：人提议题，AI帮你把议题想清楚、理清楚、做出来。

重要提醒：ISSUE中的Socratic（探索）环节默认就是友好对话模式，必须提供回答建议，这不是可选项而是标准要求。

为什么现在的AI协作这么累？

你是不是经常遇到这些情况：写提示词比做事还费劲，反复调试prompt，改了20遍还不对；团队用AI像打游击战，每个人都有自己的"独门秘籍"，好经验传不下去，踩的坑重复踩；越用越迷茫，不知道AI能帮什么忙，最后还是自己重做一遍。

根本原因其实很简单：我们在用"随机对话"的方式做"严肃工作"。就像开会，如果没有议程、没有流程、没有记录，那就是闲聊，不是工作。

核心思想

ISSUE 不是另一个 prompt 技巧，而是一种全新的协作哲学：人类掌握What和Why，AI负责How和How much。

这意味着三个关键转变。第一，从"命令式"到"议题式"，不再是给AI下命令让它执行，而是向AI提议题，共同探索——就像从独裁管理到参与式决策的转变。第二，从"结果导向"到"过程导向"，不是直接要结果不管过程，而是重视对话过程，在过程中发现洞察，过程即价值，对话即思考。第三，从"个人技巧"到"团队方法"，不再靠个人prompt技巧，而是用标准化流程保证质量，这是从手工作坊到工业化生产的进化。

为什么叫 ISSUE？不只是五个步骤的缩写，更是理念的体现。Issue 在软件开发中是需要被讨论、被解决的议题，在管理学中是需要关注的关键问题，在 ISSUE 方法中是人与AI协作的基本单元。每一次协作都围绕一个明确的 Issue 展开，有开始、有过程、有结果、可追溯。

这背后有三个深层价值观。首先，人类永远是主体——AI再强大也是工具，决策权永远在人类手中，AI的价值是增强人类，不是替代人类。其次，结构化创造自由——约束不是限制而是解放，有了框架创造力才能聚焦，标准化让创新可积累、可传承。最后，协作大于独立——1+1>2的前提是有效协作，好的方法让协作变简单，集体智慧通过方法论放大。

理论基础：扩散-收敛的认知动力学

ISSUE范式背后有着深刻的认知科学基础。整个过程体现了人类思维的基本模式：扩散与收敛的动态平衡。

扩散阶段（I→S→S）

前三步是认知的扩散过程，从一个点展开到一个空间：

• Initiate（发起）：设定认知的种子，一个具体的议题
• Structure（构架）：选择认知框架，定义思考的维度和边界
• Socratic（探索）：在框架内系统性提问，展开可能性空间

这个过程类似于写作中从主题到大纲再到内容探索的过程。但关键在于，Structure不是规划内容，而是规划如何提问。

收敛阶段（U→E）

后两步是认知的收敛过程，从空间收束到具体结果：

• Unify（统一）：整合分散的信息，形成一致的方案
• Execute（执行）：将方案转化为具体的行动和结果

Socratic的友好本质（这是标准，不是可选）

Socratic必须是友好的对话式探索，这是ISSUE的核心要求。Friendly Advice Socratic是默认模式，不是可选增强：

为什么要"友好"（Friendly）？

1. 降低认知负担：一次一个问题，用户不会被压垮
2. 建立信任关系：像朋友聊天，不是被审问
3. 适应性探索：根据回答调整方向，不是死板的问题列表
4. 深度优先于广度：把一个点聊透，比蜻蜓点水有价值

友好对话的技巧

• 共情式开场："咱们先看看..."、"我理解..."
• 渐进式深入：从简单到复杂，从表象到本质
• 确认式推进："你刚才提到...，那么..."
• 选择式引导："是A的原因，还是B的原因？"
• 总结式过渡："明白了，那我们再看看..."

Advice Socratic - 提供回答建议

在提问时，AI应该主动提供可能的回答方向，帮助用户思考：

示例1：开放问题+选项建议

AI: "用户流失的主要原因是什么？
     常见的原因包括：
     A) 产品核心价值不明确
     B) 使用门槛太高
     C) 缺少用户引导
     D) 其他原因？"

示例2：专业问题+领域知识

AI: "你们的技术架构遇到什么瓶颈？
     通常会是：
     - 数据库性能（查询慢、连接池满）
     - API响应时间（网络延迟、计算密集）
     - 前端渲染（首屏加载、交互卡顿）
     哪个更接近你们的情况？"

示例3：决策问题+利弊分析

AI: "是否要重构这个模块？
     可以从这几个角度考虑：
     - 维护成本：现在的痛点有多严重？
     - 时间投入：重构需要多久？
     - 风险评估：会影响哪些功能？
     你最关心哪个方面？"

Advice原则：

• 不是限制思路，而是启发思考
• 永远加上"其他"选项，保持开放性
• 基于领域知识提供专业建议
• 选项数量适中（3-5个为宜）

避免的错误模式

❌ 问题轰炸：一次抛出所有问题

"请回答以下问题：1... 2... 3... 4... 5..."

❌ 机械问答：不管回答内容，按预设列表提问

用户："我们没有这个数据"
AI："好的，那第二个问题是..." （忽略了用户的困难）

❌ 跳跃式提问：问题之间没有逻辑联系

"用户数量多少？" → "你们用什么技术栈？" （话题突然跳跃）

Structure的深层本质

Structure是ISSUE的灵魂，但它不是简单的"方法论选择"，而是认知框架的设定。

Structure的三个关键特性

1. 预设性：Structure必须预先存在，不能现场发明。就像工具箱里的工具，需要提前准备好。

2. 经验性：好的Structure是经验的结晶，经过验证的思维模式。它可以来自：

   • 标准框架（5W1H、SWOT等通用工具）
   • 领域框架（特定领域的专业方法）
   • 自定义框架（经过验证的创新方法）

3. 约束性：Structure定义了Socratic提问的边界和方向。选择了时间线框架，就会问"过去-现在-未来"；选择了层次框架，就会问"顶层-中层-底层"。

Structure不是大纲，是认知脚手架

传统理解把Structure当作内容大纲，实际上它是认知的脚手架：

• 不是规划要说什么，而是规划如何思考
• 不是内容的容器，而是思维的轨道
• 不是静态的框架，而是动态的探索指南

ISSUE如何解决这些问题

想象你在主持一个高效的会议，ISSUE就是把人机协作变成这样的流程：

标准ISSUE流程：友好对话是默认模式

ISSUE的核心就是友好的、带建议的对话。这不是"增强"，而是标准做法：

1. Initiate（发起议题）：你说"我们需要优化用户注册流程"

2. Advice Structure（AI建议框架）：AI回应"基于这个议题，我建议以下分析框架：

   • 用户旅程框架（分析每步的流失率）
   • 转化漏斗框架（识别关键断点）
   • 对比分析框架（与竞品比较）

   您想选择哪个，或者有其他偏好的框架？"

3. Structure（确定框架）：你选择"用转化漏斗框架"，或提供自己的框架

4. Socratic with Advice（友好探索+建议）：AI进行一问一答式的友好对话，并提供回答建议：

   核心特征：

   • 单点聚焦：每次只问一个核心问题
   • 提供选项：给出可能的回答方向，降低认知负担
   • 保持开放：永远允许"其他"选项
   • 适应调整：根据回答灵活调整后续问题

   示例对话： AI："基于转化漏斗框架，用户在哪一步流失最多？ A) 进入注册页（找不到入口） B) 开始填写（表单太长） C) 验证环节（邮箱/手机验证） D) 其他环节？" 用户："主要是C，验证环节" AI："验证环节的问题通常是： - 验证码收不到 - 流程太复杂 - 用户觉得没必要 你们是哪种情况？"

5. Unify（统一方案）：整合所有分析，形成优化方案

6. Execute（执行计划）：制定具体的实施步骤

Structure选择的方法论

如何选择合适的Structure？

1. 从议题类型推导

   • "如何..."问题 → 方法步骤框架
   • "为什么..."问题 → 因果分析框架
   • "比较..."问题 → 对比评估框架
   • "分析..."问题 → 要素分解框架

2. 考虑领域特性

   • 技术问题 → 技术架构框架
   • 业务问题 → 商业分析框架
   • 用户问题 → 用户体验框架

3. Structure的层次

   • 元框架：最通用的思维模式（如5W1H）
   • 领域框架：特定领域的标准方法
   • 场景框架：具体场景的最佳实践

Structure库示例

通用框架：

• 5W1H：全面分析的起点
• SWOT：战略分析
• PDCA：持续改进
• 金字塔原理：结构化表达

技术框架：

• 分层架构：系统设计
• 性能分析：瓶颈识别
• 故障树：问题诊断
• 设计模式：方案选择

业务框架：

• 用户旅程：体验优化
• 价值链：流程分析
• 商业画布：模式设计
• OKR：目标管理

一个真实的例子

产品经理小王要做年度规划。以前的方式是这样的：小王说"帮我写个2025年产品规划"，AI输出一个通用模板，小王说"这不是我想要的"，然后反复20轮还是不满意。

用ISSUE方式完全不同：

小王："我需要做2025年产品规划"（Initiate）

AI："做年度规划确实需要系统思考。我建议用OKR框架来组织规划，这样目标会更清晰。或者你有其他偏好的框架吗？"（Advice Structure）

小王："OKR挺好的，就用这个"（Structure确定）

AI："好的。咱们从公司战略开始，今年公司最关注的战略重点是什么？"（Socratic开始）

小王："主要是提升用户留存，因为获客成本太高了"

AI："理解了，获客成本高确实需要在留存上下功夫。现在的用户月留存率大概是多少？"（深入一个点）

小王："只有45%左右，行业平均是60%"

AI："45%确实有提升空间。用户流失主要发生在什么阶段？ 我猜测可能是： A) 注册后首周（没有感受到价值） B) 使用1个月后（新鲜感消失） C) 付费转化时（价格门槛） 或者其他时间点？"（Advice Socratic）

小王："主要是A，首周流失率特别高"

AI："首周流失确实很关键。是什么导致新用户没能感受到产品价值？

• 核心功能不够突出？
• 新手引导不够友好？
• 期望与实际不符？ 哪个更接近实际情况？"（继续Advice探索）

小王："主要是核心功能使用率太低，很多用户不知道我们的杀手锏功能"

AI："原来是功能发现的问题。那咱们再看看用户满意度，现在的NPS分数如何？"（总结式过渡）

[对话继续深入...]

AI："基于我们的讨论，2025年的三大OKR目标可以是：1）用户月留存率从45%提升到65%；2）核心功能使用率翻倍；3）NPS从目前的20分提升到35分。这样符合你的预期吗？"（Unify）

小王："很好，那我们制定具体的执行计划"（Execute）

看到区别了吗？从"瞎猜"变成了"共创"，从"命令"变成了"对话"。

这带来了什么改变？

对个人来说，效率翻倍了。以前要1小时写prompt，2小时改结果；现在30分钟结构化对话，直接可用。

对团队来说，协作标准化了。以前每个人各显神通，质量参差不齐；现在有统一的协作流程，稳定的输出质量。

对组织来说，知识能沉淀了。以前好的实践留不下来；现在每个ISSUE都是可复用的模板。

如何开始使用ISSUE

快速开始

最简单的开始方式：

1. 明确议题：不要说"帮我写个文档"，要说"我需要为新功能写用户指南"

2. 请求Structure建议：直接问AI"针对这个议题，你建议用什么框架？"

3. 选择或提供Structure：

   • 从AI建议中选择
   • 或提供你熟悉的框架
   • 甚至可以组合多个框架

4. 进入结构化对话：让AI基于框架提问，而不是你猜AI需要什么

进阶技巧

构建个人Structure库

记录对你有效的Structure：

• 哪些议题用哪些框架效果好
• 自己创新的框架模式
• 领域特定的专业框架

团队协作模式

1. 标准化常见议题的Structure

   • 代码审查 → 审查清单框架
   • 需求分析 → 用户故事框架
   • 故障处理 → 根因分析框架

2. 分享和进化Structure

   • 团队wiki记录有效Structure
   • 定期回顾和优化
   • 形成组织的"认知资产"

人机分工的艺术

人类的独特价值

1. 议题设定：只有人类知道什么是重要的
2. Structure选择：基于经验和直觉的判断
3. 价值判断：在Unify阶段的决策
4. 意义赋予：理解结果的深层含义

AI的独特优势

1. Structure执行：在框架内系统性展开
2. 信息整合：处理大量信息的能力
3. 模式识别：发现隐藏的关联
4. 持续专注：不会疲劳的深度探索

认知层面的提升

ISSUE不仅是一个方法，更是认知能力的训练：

• Structure思维：学会用框架思考
• 系统性提问：掌握苏格拉底方法
• 结构化表达：清晰传达复杂想法
• 协作智慧：人机优势互补

常见疑虑

"这会不会太复杂了？"开始可能需要适应，但用过几次就会发现，比现在的"自由对话"简单多了。就像学会开会流程后，效率自然就高了。

"每个对话都要这么正式吗？"不是。简单问题简单处理，复杂任务才需要完整流程。就像不是所有讨论都需要开会。

"AI能理解这种方式吗？"现代AI（GPT-4、Claude等）都能很好地理解和执行结构化协作。它们本来就擅长这个。

"和现有的prompt工程有什么区别？"Prompt工程关注"怎么说"，ISSUE关注"说什么"。一个是技巧，一个是方法论。

"如何选择正确的Structure？"没有唯一正确的Structure。可以：

• 让AI建议（Advice Structure）
• 从通用框架开始（如5W1H）
• 基于经验选择
• 迭代优化（如果效果不好就换）

"Structure会不会限制创造力？"恰恰相反。Structure是认知的脚手架，它提供支撑而不是限制。就像诗歌的格律不会限制诗人，反而激发创造力。

深层洞察：ISSUE作为认知协议

ISSUE不是让AI更聪明，而是让协作更聪明。但更深层的是，ISSUE定义了人类与AI协作的认知协议。

从方法到范式的升华

ISSUE的革命性在于它不只是一个方法，而是：

1. 认知的操作系统：Structure是调用人类集体智慧的API
2. 思维的编排器：协调扩散与收敛的认知节奏
3. 协作的标准协议：定义人机交互的标准接口

Structure作为文明接口

当AI执行Structure时，它实际上在：

• 调用人类文明的集体经验
• 运用经过验证的思维模式
• 在人类认知框架内展开探索

这就是为什么Structure必须是预设的、经验的——它是人类智慧的结晶，是文明的认知资产。

写作类比的深层含义

ISSUE过程就像写作：

• 传统写作：主题→大纲→内容
• ISSUE模式：议题→认知框架→系统探索→整合→执行

但关键区别在于：

• 大纲规划的是内容
• Structure规划的是思维过程
• 一个是静态的，一个是动态的

未来展望

ISSUE范式指向了人机协作的未来：

• 人类成为Structure的策展人
• AI成为Structure的执行者
• 共同推动认知框架的进化

当Structure成为标准化的认知协议，人类的集体智慧就能通过AI无限放大。这不是AI替代人类，而是人类通过AI实现认知的跃升。

---

参考资源

• ISSUE方法详细介绍（博客）
• Socratic Method - 苏格拉底式对话法
• Issue #4 - ISSUE理念的应用实践