和 AI 聊天不难难的是长期协作我做了一套三层机制很多人和 AI 协作还停留在“问一个问题、改一段文案、写一段代码”的阶段。这当然没问题。但只要协作从一次性任务进入长期项目你很快就会发现真正困难的地方已经不是“AI 能不能帮你做点事”而是什么时候只是闲聊什么时候已经进入正式推进什么时候需要记录什么时候不需要什么时候应该进入项目级流程什么时候只是一个快速处理的小任务协作规则应该写在哪里是项目仓库里还是更高层的地方当项目越来越多时如何避免每个项目都长出一套新的协作约定如果这些问题不提前处理后面几乎一定会出现这些情况上下文恢复成本越来越高规则不断重复讨论记录散落在多个地方项目推进和协作方式互相缠绕每次重新开始都像“从头来过”所以真正需要设计的不只是“让 AI 做什么”而是如何把人与 AI 的长期协作变成一套可复用、可查询、可迭代、可治理的机制。我后来逐步抽象出一套三层结构Scene → Mode → Special Mode它分别回答三个问题Scene这次在做什么Mode在这个场景下怎么协作Special Mode当前具体对象下有没有局部特例这篇文章想讲清楚的就是这套结构为什么值得设计以及它如何真正落地。一、为什么需要一套“协作操作系统”单次任务中人与 AI 的协作通常不需要太多规则。但一旦进入长期协作你会碰到一类完全不同的问题。比如同时推进多个项目既有规划仓又有代码仓、知识库仓有些内容必须长期保留有些内容完全不值得记录有些动作是正式推进有些只是顺手处理的小动作AI 不再只是临时工具而是在参与长期协作这时如果没有一套协作机制最常见的问题就是1. 项目和规则混在一起项目仓里既有项目规划又有协作规则又有临时流程仓库职责会越来越乱。2. 规则反复讨论每遇到一个新情况就得重新讨论一遍这次要不要记这算不算正式推进要不要更新仓库需不需要切换工作方式3. 上下文越来越难恢复几天之后再回来很容易忘当前推进到哪当时为什么这么定当前默认按什么方式协作归根到底问题不在于 AI 回答得够不够快而在于协作本身没有被设计成系统。二、第一步先分清“这次在干什么”再谈“怎么做”很多人一开始设计协作方式时很容易先讨论“模式”。比如这次你主导我辅助这次 AI 多做一点这次快速试验这次共创推进这些都属于“怎么做”也就是Mode。但真实对话里更先需要回答的问题其实是这次我们到底在干什么这就是Scene的作用。Scene当前场景例如casual-chat闲聊exploration探索planning规划沉淀project-execution项目推进quick-task快速执行retrospective复盘校准只有先知道当前在哪个 Scene后面才知道要不要进入项目机制要不要记录要不要更新仓库要不要继续细分协作方式Mode在这个 Scene 下怎么协作注意不是每个 Scene 都需要 Mode。一个更合理的做法是在重场景下定义 Mode在轻场景下保持简单例如在project-execution下可以细分Mode A用户主导实现AI 辅助设计/审阅/排障Mode B默认共创模式用户主导方向与验收AI 主导方案压实与推进Mode C快速验证模式AI 快速搭原型用户重点看结果和价值判断Special Mode具体对象下的局部特例这一层很关键但也最容易被忽略。因为真实协作里某些对象往往有自己的长期稳定规则。例如某个规划仓更偏“记录优先”某个代码仓更偏“实现优先”某条长期主线默认有特殊的推进方式这时候就需要Special Mode。但要注意Special Mode 不是新的入口而是建立在 Scene / Mode 基础上的局部叠加层。所以这套结构真正稳定的形式应该是Scene → Mode → Special ModeScene当前在做什么Mode在这个场景下怎么协作Special Mode当前对象下的局部规则三、这套结构到底解决了什么问题如果用一句话概括它解决的是把“当前在做什么、怎么做、在当前对象下还有什么特例”三件事分开。这件事看起来简单实际上非常重要。因为如果不分开你后面很容易混淆当前到底是在探索还是已经进入推进现在讨论的是工作方式还是讨论的是对象特例这条规则是整个系统通用还是只适用于某个项目把这三层拆开以后整个协作系统的层级就清楚了。可以用一个最小结构图理解Scene当前在做什么 ↓ Mode在这个场景下怎么协作 ↓ Special Mode当前对象下的局部规则再换一种更直白的表达Scene → 这次在干什么 Mode → 在这个场景下怎么干 Special Mode → 当前对象有没有局部特例如果再落到仓库层面大致可以理解成scene-mode-playbook通用协作规则ai-project-incubator项目规划与阶段记录local-kb-assistant代码实现与工程推进MEMORY.md长期协作记忆这样一来很多原本缠在一起的问题就能被拆开处理。四、为什么最高层入口不能让 AI 擅自切换当 Scene 这层建立起来以后一个非常现实的问题马上就出现了AI 能不能根据上下文自动判断 Scene然后直接切过去表面上看这样很聪明也很省沟通。但真正的问题是Scene 是最高层入口。一旦 Scene 切错后面整串动作都会偏要不要记录要不要更新仓库要不要进入项目推进流程要不要启用 Mode要不要启用 Special Mode所以最高层入口不能让 AI 擅自正式切换。我最后定下来的原则是AI 可以先做内部理解但不能不经确认就正式切换到新的 Scene并触发机制性动作。这里的“机制性动作”包括落盘更新仓库启用或切换 Mode启用 Special Mode进入正式项目推进其他依赖 Scene 判断的正式动作换句话说可以AI 先理解“当前更像哪个 Scene”不可以AI 不问用户直接切过去并开始执行对应机制我会把这条规则压成一句最容易记的话可以先猜但不能不经确认就正式切。这条规则我认为是整套方法里最关键的稳定器。五、系统不仅要能定义还要能查询很多规则系统的问题不是没写而是写完以后根本用不起来。因为真实使用时用户最常问的不是抽象概念而是很具体的问题当前我们现在处于什么状态当前有哪些场景哪些场景有 Mode当前默认规则是什么所以一套协作机制必须天然支持“查询入口”。至少应该支持这三类查询1. 查询当前状态最推荐的问法当前协作状态是什么这个入口最好能返回当前 Scene当前 Mode如有当前 Special Mode如有当前作用域当前状态来源显式指定 / 上下文延续 / 待确认2. 查询场景列表最推荐的问法协作场景有哪些3. 查询体系总览最推荐的问法当前有哪些协作场景和模式这一步很重要因为它让整套机制从“文档说明”变成“可运行、可访问、可查询”的协作操作系统。六、为什么还需要“迁移案例”和“确认策略”定义状态还不够真实协作里更常见的问题是什么时候应该留在当前 Scene什么时候该切到另一个 Scene哪些只是小动作不需要正式迁移所以一套可用的系统不能只有静态定义还要能解释动态迁移。例如高频迁移通常会是casual-chat → explorationexploration → planningplanning → project-executionproject-execution → retrospectiveretrospective → planningquick-task ↔ 原主线同时还需要有“场景确认策略”明确什么时候 AI 应该主动确认什么时候只做内部理解不打断什么时候可以继续沿用当前 Scene如果没有这些系统很容易变成“定义得很清楚但真实使用还是很别扭”。七、为什么还必须补“治理规则”任何规则系统只要真的开始使用就一定会越来越长。这时最危险的不是不够多而是越来越乱。最常见的问题是什么都想写成规则什么都想发明一个 Special Mode一次性偏好被误写成长期基线通用规则和局部规则写反位置规则改了但没有同步到速查和查询入口所以系统不只要能扩展还要能治理。我认为至少需要两类治理1. Special Mode 编写规范核心原则是能写通用层就不要轻易写 Special Mode。只有当某条规则满足这些条件时才值得成为 Special Mode长期稳定强绑定某个对象会反复出现通用层表达不了2. 规则变更流程核心原则是不是每次提到“规则”都应该立刻生效。一条规则更合理的流程应该是先讨论判断值不值得沉淀判断属于通用层还是局部层确认后再正式落盘必要时同步长期记忆与相关仓库这一步非常关键因为它能防止系统越长越乱。八、真正让这套方法成立的不是文档而是真实跑过一次我觉得这套方法最有价值的一点不是结构图不是文档多而是它已经被拿来真实跑过。这是最关键的。因为很多机制在纸面上都很好看但一到真实协作就会暴露问题。一个典型的真实链路大概会是这样选择真实主线确认 Scene确认 Mode确认 Special Mode推进真实动作记录回规划仓对应到实际推进通常会是先决定不是纯演练而是拿真实主线来跑AI 提议进入project-execution用户显式确认 SceneAI 提议采用Mode B用户显式确认 ModeAI 提议启用某个 Special Mode用户显式确认 Special Mode随后真正推进一个动作例如先记录这次真实协作链路再创建代码仓再把代码仓初始化回写到规划仓到这里系统才真正完成一个闭环有规则有确认有推进有记录有回写这比任何抽象定义都更有说服力。因为它证明了一件事这套方法不是停留在文档里的而是可以真正驱动协作的。九、如果你也想尝试可以先从这三步开始如果你也想试一试这套方法不需要一开始铺得很大。我更建议你先做一个最小版本。第一步先定义几个 Scene不需要太多4~6 个就够。例如闲聊探索规划项目推进快速执行复盘第二步只给最重的 Scene 定义 Mode不要一开始给所有 Scene 都设计 Mode。最简单的做法是先只给project-execution定义 A / B / C第三步把通用规则和项目规则分仓管理不要把所有规则都塞进某个项目仓。建议最少拆成一个元规则仓协作系统一个项目规划仓一个代码仓做到这三步你的协作方式就已经会比大多数“纯口头约定”稳定很多。十、这套方法适合谁这套方法尤其适合下面几类人1. 正在长期使用 AI 参与项目的人如果你已经不只是偶尔问问题而是让 AI 真正参与项目推进这套方法会很有帮助。2. 手上有多个仓库或多条主线的人只要你开始同时维护规划代码知识库长期记录就会越来越需要一套协作底盘。3. 不满足于把 AI 当“临时工具”的人如果你想要的不是“一次回答”而是“长期共事”那么这套方法会比单纯堆提示词更有价值。结语真正难的不是让 AI 回答而是让协作可持续单次提问靠提示词长期协作靠机制今天让 AI 回答问题已经不难难的是把这种互动从一次性问答升级成一种长期、稳定、可持续的合作关系。真正困难的不是让 AI 写一段代码让 AI 总结一篇文章让 AI 帮忙整理一份文档真正困难的是让协作有边界让状态可查询让切换有机制让规则可治理让项目可接续让系统能随着真实使用不断长大而不是越来越乱从这个意义上说Scene → Mode → Special Mode不是一个为了概念好看而设计的框架。它更像是一种基础设施思维不是把 AI 当一个临时工具而是认真搭一套“人如何与 AI 长期共事”的底层机制。而一旦这套机制开始成形它的价值就不再局限于某一个项目。它会成为未来所有项目、所有长期主线、所有人与 AI 协作方式的共同底盘。使用附对话记录百度网盘scene-mode-playbook的诞生.docx
和 AI 聊天不难，难的是长期协作：我做了一套三层机制
和 AI 聊天不难难的是长期协作我做了一套三层机制很多人和 AI 协作还停留在“问一个问题、改一段文案、写一段代码”的阶段。这当然没问题。但只要协作从一次性任务进入长期项目你很快就会发现真正困难的地方已经不是“AI 能不能帮你做点事”而是什么时候只是闲聊什么时候已经进入正式推进什么时候需要记录什么时候不需要什么时候应该进入项目级流程什么时候只是一个快速处理的小任务协作规则应该写在哪里是项目仓库里还是更高层的地方当项目越来越多时如何避免每个项目都长出一套新的协作约定如果这些问题不提前处理后面几乎一定会出现这些情况上下文恢复成本越来越高规则不断重复讨论记录散落在多个地方项目推进和协作方式互相缠绕每次重新开始都像“从头来过”所以真正需要设计的不只是“让 AI 做什么”而是如何把人与 AI 的长期协作变成一套可复用、可查询、可迭代、可治理的机制。我后来逐步抽象出一套三层结构Scene → Mode → Special Mode它分别回答三个问题Scene这次在做什么Mode在这个场景下怎么协作Special Mode当前具体对象下有没有局部特例这篇文章想讲清楚的就是这套结构为什么值得设计以及它如何真正落地。一、为什么需要一套“协作操作系统”单次任务中人与 AI 的协作通常不需要太多规则。但一旦进入长期协作你会碰到一类完全不同的问题。比如同时推进多个项目既有规划仓又有代码仓、知识库仓有些内容必须长期保留有些内容完全不值得记录有些动作是正式推进有些只是顺手处理的小动作AI 不再只是临时工具而是在参与长期协作这时如果没有一套协作机制最常见的问题就是1. 项目和规则混在一起项目仓里既有项目规划又有协作规则又有临时流程仓库职责会越来越乱。2. 规则反复讨论每遇到一个新情况就得重新讨论一遍这次要不要记这算不算正式推进要不要更新仓库需不需要切换工作方式3. 上下文越来越难恢复几天之后再回来很容易忘当前推进到哪当时为什么这么定当前默认按什么方式协作归根到底问题不在于 AI 回答得够不够快而在于协作本身没有被设计成系统。二、第一步先分清“这次在干什么”再谈“怎么做”很多人一开始设计协作方式时很容易先讨论“模式”。比如这次你主导我辅助这次 AI 多做一点这次快速试验这次共创推进这些都属于“怎么做”也就是Mode。但真实对话里更先需要回答的问题其实是这次我们到底在干什么这就是Scene的作用。Scene当前场景例如casual-chat闲聊exploration探索planning规划沉淀project-execution项目推进quick-task快速执行retrospective复盘校准只有先知道当前在哪个 Scene后面才知道要不要进入项目机制要不要记录要不要更新仓库要不要继续细分协作方式Mode在这个 Scene 下怎么协作注意不是每个 Scene 都需要 Mode。一个更合理的做法是在重场景下定义 Mode在轻场景下保持简单例如在project-execution下可以细分Mode A用户主导实现AI 辅助设计/审阅/排障Mode B默认共创模式用户主导方向与验收AI 主导方案压实与推进Mode C快速验证模式AI 快速搭原型用户重点看结果和价值判断Special Mode具体对象下的局部特例这一层很关键但也最容易被忽略。因为真实协作里某些对象往往有自己的长期稳定规则。例如某个规划仓更偏“记录优先”某个代码仓更偏“实现优先”某条长期主线默认有特殊的推进方式这时候就需要Special Mode。但要注意Special Mode 不是新的入口而是建立在 Scene / Mode 基础上的局部叠加层。所以这套结构真正稳定的形式应该是Scene → Mode → Special ModeScene当前在做什么Mode在这个场景下怎么协作Special Mode当前对象下的局部规则三、这套结构到底解决了什么问题如果用一句话概括它解决的是把“当前在做什么、怎么做、在当前对象下还有什么特例”三件事分开。这件事看起来简单实际上非常重要。因为如果不分开你后面很容易混淆当前到底是在探索还是已经进入推进现在讨论的是工作方式还是讨论的是对象特例这条规则是整个系统通用还是只适用于某个项目把这三层拆开以后整个协作系统的层级就清楚了。可以用一个最小结构图理解Scene当前在做什么 ↓ Mode在这个场景下怎么协作 ↓ Special Mode当前对象下的局部规则再换一种更直白的表达Scene → 这次在干什么 Mode → 在这个场景下怎么干 Special Mode → 当前对象有没有局部特例如果再落到仓库层面大致可以理解成scene-mode-playbook通用协作规则ai-project-incubator项目规划与阶段记录local-kb-assistant代码实现与工程推进MEMORY.md长期协作记忆这样一来很多原本缠在一起的问题就能被拆开处理。四、为什么最高层入口不能让 AI 擅自切换当 Scene 这层建立起来以后一个非常现实的问题马上就出现了AI 能不能根据上下文自动判断 Scene然后直接切过去表面上看这样很聪明也很省沟通。但真正的问题是Scene 是最高层入口。一旦 Scene 切错后面整串动作都会偏要不要记录要不要更新仓库要不要进入项目推进流程要不要启用 Mode要不要启用 Special Mode所以最高层入口不能让 AI 擅自正式切换。我最后定下来的原则是AI 可以先做内部理解但不能不经确认就正式切换到新的 Scene并触发机制性动作。这里的“机制性动作”包括落盘更新仓库启用或切换 Mode启用 Special Mode进入正式项目推进其他依赖 Scene 判断的正式动作换句话说可以AI 先理解“当前更像哪个 Scene”不可以AI 不问用户直接切过去并开始执行对应机制我会把这条规则压成一句最容易记的话可以先猜但不能不经确认就正式切。这条规则我认为是整套方法里最关键的稳定器。五、系统不仅要能定义还要能查询很多规则系统的问题不是没写而是写完以后根本用不起来。因为真实使用时用户最常问的不是抽象概念而是很具体的问题当前我们现在处于什么状态当前有哪些场景哪些场景有 Mode当前默认规则是什么所以一套协作机制必须天然支持“查询入口”。至少应该支持这三类查询1. 查询当前状态最推荐的问法当前协作状态是什么这个入口最好能返回当前 Scene当前 Mode如有当前 Special Mode如有当前作用域当前状态来源显式指定 / 上下文延续 / 待确认2. 查询场景列表最推荐的问法协作场景有哪些3. 查询体系总览最推荐的问法当前有哪些协作场景和模式这一步很重要因为它让整套机制从“文档说明”变成“可运行、可访问、可查询”的协作操作系统。六、为什么还需要“迁移案例”和“确认策略”定义状态还不够真实协作里更常见的问题是什么时候应该留在当前 Scene什么时候该切到另一个 Scene哪些只是小动作不需要正式迁移所以一套可用的系统不能只有静态定义还要能解释动态迁移。例如高频迁移通常会是casual-chat → explorationexploration → planningplanning → project-executionproject-execution → retrospectiveretrospective → planningquick-task ↔ 原主线同时还需要有“场景确认策略”明确什么时候 AI 应该主动确认什么时候只做内部理解不打断什么时候可以继续沿用当前 Scene如果没有这些系统很容易变成“定义得很清楚但真实使用还是很别扭”。七、为什么还必须补“治理规则”任何规则系统只要真的开始使用就一定会越来越长。这时最危险的不是不够多而是越来越乱。最常见的问题是什么都想写成规则什么都想发明一个 Special Mode一次性偏好被误写成长期基线通用规则和局部规则写反位置规则改了但没有同步到速查和查询入口所以系统不只要能扩展还要能治理。我认为至少需要两类治理1. Special Mode 编写规范核心原则是能写通用层就不要轻易写 Special Mode。只有当某条规则满足这些条件时才值得成为 Special Mode长期稳定强绑定某个对象会反复出现通用层表达不了2. 规则变更流程核心原则是不是每次提到“规则”都应该立刻生效。一条规则更合理的流程应该是先讨论判断值不值得沉淀判断属于通用层还是局部层确认后再正式落盘必要时同步长期记忆与相关仓库这一步非常关键因为它能防止系统越长越乱。八、真正让这套方法成立的不是文档而是真实跑过一次我觉得这套方法最有价值的一点不是结构图不是文档多而是它已经被拿来真实跑过。这是最关键的。因为很多机制在纸面上都很好看但一到真实协作就会暴露问题。一个典型的真实链路大概会是这样选择真实主线确认 Scene确认 Mode确认 Special Mode推进真实动作记录回规划仓对应到实际推进通常会是先决定不是纯演练而是拿真实主线来跑AI 提议进入project-execution用户显式确认 SceneAI 提议采用Mode B用户显式确认 ModeAI 提议启用某个 Special Mode用户显式确认 Special Mode随后真正推进一个动作例如先记录这次真实协作链路再创建代码仓再把代码仓初始化回写到规划仓到这里系统才真正完成一个闭环有规则有确认有推进有记录有回写这比任何抽象定义都更有说服力。因为它证明了一件事这套方法不是停留在文档里的而是可以真正驱动协作的。九、如果你也想尝试可以先从这三步开始如果你也想试一试这套方法不需要一开始铺得很大。我更建议你先做一个最小版本。第一步先定义几个 Scene不需要太多4~6 个就够。例如闲聊探索规划项目推进快速执行复盘第二步只给最重的 Scene 定义 Mode不要一开始给所有 Scene 都设计 Mode。最简单的做法是先只给project-execution定义 A / B / C第三步把通用规则和项目规则分仓管理不要把所有规则都塞进某个项目仓。建议最少拆成一个元规则仓协作系统一个项目规划仓一个代码仓做到这三步你的协作方式就已经会比大多数“纯口头约定”稳定很多。十、这套方法适合谁这套方法尤其适合下面几类人1. 正在长期使用 AI 参与项目的人如果你已经不只是偶尔问问题而是让 AI 真正参与项目推进这套方法会很有帮助。2. 手上有多个仓库或多条主线的人只要你开始同时维护规划代码知识库长期记录就会越来越需要一套协作底盘。3. 不满足于把 AI 当“临时工具”的人如果你想要的不是“一次回答”而是“长期共事”那么这套方法会比单纯堆提示词更有价值。结语真正难的不是让 AI 回答而是让协作可持续单次提问靠提示词长期协作靠机制今天让 AI 回答问题已经不难难的是把这种互动从一次性问答升级成一种长期、稳定、可持续的合作关系。真正困难的不是让 AI 写一段代码让 AI 总结一篇文章让 AI 帮忙整理一份文档真正困难的是让协作有边界让状态可查询让切换有机制让规则可治理让项目可接续让系统能随着真实使用不断长大而不是越来越乱从这个意义上说Scene → Mode → Special Mode不是一个为了概念好看而设计的框架。它更像是一种基础设施思维不是把 AI 当一个临时工具而是认真搭一套“人如何与 AI 长期共事”的底层机制。而一旦这套机制开始成形它的价值就不再局限于某一个项目。它会成为未来所有项目、所有长期主线、所有人与 AI 协作方式的共同底盘。使用附对话记录百度网盘scene-mode-playbook的诞生.docx
