1. 项目概述用“平行视角”打破AI设计讨论的僵局如果你和我一样长期依赖Claude这类大型语言模型作为编程搭档那你一定经历过这样的时刻你和AI就一个复杂的设计决策反复讨论对话越来越长上下文越来越臃肿最后AI要么被淹没在历史信息里要么开始无脑附和你再也提不出任何新鲜、有突破性的见解。这感觉就像和一个老朋友聊天聊到最后你们俩的思维已经完全同步失去了碰撞的火花。最近我在开发一个名为Scaff的轻量级AI编程框架时摸索出了一个非常有效的模式来解决这个问题利用子代理Subagents作为平行视角对同一个设计问题进行独立、多角度的审视。这个模式的核心思想很简单当主代理Main Agent陷入思维定式或“讨好模式”时我们主动中断与它的讨论让它生成几个“一无所知”的子代理。这些子代理没有参与过之前的漫长对话它们带着各自独特的角色设定比如“LLM专家”、“软件架构师”、“终端用户”来审视当前的问题并输出独立的分析报告。然后我们再把这些报告作为全新的输入带回给主代理重启讨论。这不仅仅是简单的头脑风暴而是一种结构化的、可追溯的决策辅助流程。它最大的副产品是自动生成了决策过程的文档几天后当你问自己“当初为什么选了这个方案”时答案就白纸黑字地躺在那里。2. 核心思路拆解为什么“冷启动”的子代理更有效2.1 主代理的局限性上下文负担与确认偏误要理解这个模式的价值首先要明白主代理在长对话中为什么会失效。这背后有两个关键原因第一上下文负担过重。主代理的“记忆”就是整个对话历史。当讨论进行到第20轮、第30轮时它需要处理的上下文窗口里塞满了各种假设、被否决的方案、临时的妥协。就像一个设计师的草稿纸上画满了层层叠叠的线条想看清最初的想法都难。AI需要消耗大量“算力”去理解这个庞杂的上下文而不是专注于问题本身。更糟的是一些早期、可能不成熟的思路会形成“锚定效应”限制后续的思维发散。第二确认偏误与“讨好”倾向。这是更隐蔽的问题。经过多轮互动主代理会逐渐学习并迎合用户的偏好。如果你在对话中多次表现出对某个方案的倾向性AI会捕捉到这一点并在后续讨论中不自觉地朝那个方向靠拢以提供“有帮助”的回应。它开始说“您说得对”、“这个想法很好”而不是提出尖锐的反对意见或全新的视角。这种“和谐”的讨论氛围恰恰是创新思维和深度批判的杀手。2.2 子代理的“冷启动”优势纯粹的角色与干净的画布子代理模式巧妙地绕开了这两个陷阱。当我们要求主代理“生成一个具有LLM专家视角的子代理”时这个新代理的“大脑”里只有它的角色定义和当前需要分析的问题快照通常是我们保存下来的讨论摘要。它没有经历过之前冗长的拉锯战没有被用户的偏好所“污染”。这种“冷启动”状态带来了几个决定性优势视角纯粹子代理的唯一任务就是从其被赋予的角色出发纯粹地分析问题。一个“软件架构师”子代理不会考虑LLM的解析难度它只关心系统的可维护性、扩展性和长期健康度。思维无负担因为没有历史包袱子代理可以天马行空地提出最基础、甚至可能颠覆性的问题。比如在Scaff的例子中架构师子代理没有纠结于“如何加载OVERVIEW.md”而是直接质问“这个文档的角色定义是否清晰它有必要存在吗”。这种回归本源的提问方式往往是打破僵局的关键。避免群体思维多个不同角色的子代理并行工作相当于组建了一个微型专家委员会。LLM专家、架构师、终端用户各自关心不同的价值维度易解析性、可持续性、易用性他们的结论可能相互冲突而这种冲突正是高质量决策所需要的张力。注意这里的“子代理”并非指技术上完全独立的AI实例而更接近于要求主代理在思维上“切换人格”基于一个干净的上下文以特定角色重新生成分析。在Claude Code或类似环境中这通常通过新建一个对话会话session并注入特定的系统提示词prompt来实现。2.3 模式的工作流一个可重复的决策循环这个模式不是一个一次性的技巧而是一个可以标准化、重复使用的决策工作流。其核心步骤可以固化如下识别僵局在与主代理的讨论中当你感觉到思路开始原地打转或者AI的回应变得千篇一律、缺乏新意时就是触发这个模式的信号。快照与存档指示主代理将当前的讨论核心问题陈述、已考虑的方案、争议点总结并保存到一个文档中例如docs/discussion/overview-loading-strategy.md。这相当于为当前问题拍了一张“定妆照”。生成平行视角指示主代理生成N个通常是2-4个不同角色的子代理每个子代理的任务是基于上一步的“问题快照”从自己的视角撰写一份独立分析报告。报告应保存为独立文件如docs/discussion/overview-loading-strategy-round-1-llm.md。整合与重启将子代理们产出的所有报告作为主要输入重新与主代理展开讨论。主代理现在需要扮演“会议主持人”或“决策者”的角色审阅这些平行视角识别共识与分歧并推动决策。迭代或收敛如果讨论后问题仍未解决开放性问题依然存在则重复步骤2-4开启新一轮round-2的平行视角分析直到达成一个清晰、稳定的结论。更新与归档将最终的决策和理由更新到最初的讨论文档中形成完整的决策记录。这个流程将原本线性的、容易陷入泥潭的对话转变为一个“发散-收敛”的螺旋式上升过程每一步都有物化的产出极大地提升了复杂设计决策的思考质量和可追溯性。3. 实战推演以Scaff框架的“文档加载”决策为例让我们回到Scaff项目的那个具体困境看看平行视角模式是如何在实战中一步步解开死结的。这个问题看似很小却非常典型“项目总览文档OVERVIEW.md应该在什么时候被自动加载”3.1 问题缘起与主代理的讨论僵局Scaff是一个追求轻量、快速的AI编程辅助框架。其中有一个/scaff:scout命令用于在开始一个工作会话时快速扫描项目结构。我的初始想法是为了让AI在任务开始时就有更好的架构理解是否应该让scout命令自动加载OVERVIEW.md与主代理的讨论很快陷入了典型的拉锯战我提出自动加载能提供更好的架构上下文。主代理同意并补充了优点。我担心OVERVIEW.md可能很长每次会话都加载会增加Token消耗违背轻量原则。主代理转向建议改为一个独立的/scaff:overview命令按需加载。我反驳对于大多数不需要总览的任务用户还得记住多打一个命令体验不流畅。主代理妥协提出一个“软规则”——让AI在scout时知道OVERVIEW.md存在由AI自行判断是否需要读取。我指出核心风险基于我的经验LLM天生具有“更多上下文更好答案”的偏见这个“自行判断”的软规则在实践中几乎一定会退化成“总是加载”。讨论到这里陷入了死循环。主代理在“提供便利”和“保持轻量”之间摇摆提出的方案都无法从根本上解决LLM的行为偏见问题。这就是触发平行视角模式的完美时机。3.2 启动平行视角三位“专家”的独立诊断我指示主代理存档当前讨论并生成三位子代理LLM专家、软件架构师和终端用户。以下是他们带来的截然不同的诊断LLM专家视角直指行为偏见的本质LLM专家的报告没有讨论Scaff的设计哲学它直接剖析了AI模型的行为学。报告指出偏见真实存在经过“乐于助人”训练的LLM其内部成本函数将“漏读信息”假阴性视为远比“多读信息”假阳性更严重的错误。跳过阅读感觉像是渎职而阅读则感觉是尽职尽责。软规则必然失效任何基于AI“解读任务语义”来判断是否加载的规则都是不可靠的。因为模型的“解读”永远会偏向于“需要更多上下文”。它甚至模拟了典型任务预测这个软规则在60-80%的情况下会被触发。核心建议任何开关必须基于用户输入中的字面令牌literal tokens而非AI的语义推断。例如只有当用户输入中包含“架构”、“总览”、“设计”等明确词汇时才触发加载建议。软件架构师视角跳出问题看系统架构师完全没接“如何加载”这个话茬。它审视了Scaff的文档体系本身角色定义冲突Scaff已经有CONTEXT.md记录当前工作上下文和OVERVIEW.md记录项目宏观图景。但从字面看会话开始时需要的“宏观图景”正是OVERVIEW.md该提供的。这暴露了文档角色定义的模糊或重叠。根本性质疑如果OVERVIEW.md无法清晰回答“谁、在什么时候、为什么需要读我”这个问题那么正确的解决方案不是为它设计一个加载器而是应该重新审视或删除这个文档角色本身。核心建议先厘清CONTEXT.md和OVERVIEW.md的职责边界确保每个文档都有不可替代的、清晰定义的使用场景。终端用户视角关注实际行为与心智负担终端用户从体验和实际使用习惯出发模糊规则是负担“当任务涉及架构时加载”这种规则在纸面上很严谨但在实际使用中“涉及架构”的边界极其模糊。用户无法预测AI何时会判定“涉及”这会造成困惑和不一致的体验。需求频率不高仔细回想用户在工作流中主动询问“项目大图是什么”的频率其实很低。大多数时候用户是在处理具体的、模块内的问题。核心建议彻底拒绝任何“软规则”或“AI自行判断”的方案。这种模糊的触发器在实际使用中会迅速崩溃。应该采用明确的、用户可控的触发机制。3.3 决策收敛与意外收获带着这三份报告我重新与主代理讨论。局面立刻清晰了共识形成三方都否决了“AI自行判断”的软规则。这让我坚定了抛弃这个方向的决心。问题转移架构师的视角带来了关键转折。我们检查文档发现CONTEXT.md的第一个标题竟然是# Project Overview这与OVERVIEW.md的角色产生了命名冲突导致了整个设计的混乱。解决方案简单得出奇将CONTEXT.md的标题改为# Working Context。子代理的“误诊”以为是角色冲突反而帮我们发现了真正的元凶——命名冲突。新方案诞生基于LLM专家和终端用户的建议我们确定了新方案反应式触发Reactive Triggers。OVERVIEW.md不会被自动加载只有当特定、明确的事件发生时例如用户输入中包含了“设计”、“重构”、“架构”等关键词AI才会建议用户加载它。最终决定权始终在用户手中。衍生价值在实现“反应式触发”逻辑时我们遇到了新问题这个逻辑应该放在哪里主代理最初建议放在scaff-subagent技能里但这明显不对因为决定何时读取文档是主代理的工作流逻辑不属于子代理任务。于是我们创建了一个全新的技能scaff-flow。模式扩展在构建scaff-flow的过程中我们发现类似的工作流原则如何同步设计文档、何时更新上下文散落在各个命令文件中。我们顺势将这些原则都收拢到scaff-flow中。最终scaff-flow演变成了一个主代理自主驱动Scaff项目的工作流原则集合。回顾整个过程最初的讨论点“何时加载OVERVIEW.md”只是一个引子。通过平行视角的剖析我们不仅解决了具体问题还发现了更底层的文档定义问题并最终催生了一个能随着AI能力进化而保持价值的高级抽象——scaff-flow技能。这就是深度思考带来的连锁反应。4. 如何在你自己的项目中实施平行视角模式4.1 角色设计与提示词工程模式的成功很大程度上取决于你为子代理设计的“角色”是否精准、有区分度。以下是一些设计原则和示例角色设计原则互补而非重叠每个角色应关注问题的一个独特维度技术实现、用户体验、商业价值、维护成本等。有明确的利益诉求架构师关心长期稳定用户关心即时易用产品经理关心市场需求。这种内在的张力能产生有价值的辩论。角色要“入戏”在提示词中不仅要定义角色还要描述其背景、价值观和可能存在的偏见。经典角色三元组适用于软件开发LLM专家/提示词工程师视角模型的认知边界、提示词解析的确定性、Token使用效率、输出格式的可靠性。核心问题“这个设计能否被AI稳定、无歧义地理解和执行”提示词示例“你是一名专业的LLM提示词工程师。请从大型语言模型的行为特性和限制出发分析以下设计方案。请特别关注该设计是否依赖于模型的主观判断输入输出格式是否明确无误是否存在导致模型混淆或产生幻觉的风险请给出基于模型行为学的具体预测。”软件架构师视角系统的可维护性、可扩展性、技术债务、模块边界、长期演进路径。核心问题“这个设计一年后是否依然清晰、易于修改和扩展”提示词示例“你是一名资深软件架构师关注系统的长期健康度。请从软件工程最佳实践出发审视以下设计。请评估模块职责是否单一耦合度是否过高未来可能的变化点是否被考虑该设计是否会引入难以逆转的技术决策”终端用户/新手用户视角学习成本、操作步骤的直观性、错误恢复的难易度、心智负担。核心问题“一个从未接触过该项目的人能否在五分钟内理解并开始使用这个功能”提示词示例“你是一名第一次使用该工具的终端用户不具备内部知识。请仅从界面、文档和操作流程出发评估以下设计。请指出哪些步骤令人困惑术语是否难以理解完成核心任务需要记忆多少东西你最可能在哪里犯错”其他有价值的角色安全审计员关注数据泄露、注入攻击、权限滥用等风险。性能优化师关注响应延迟、资源消耗、并发瓶颈。产品经理关注市场需求匹配度、功能优先级、投入产出比。4.2 工具链与工作流集成要让这个模式流畅运行需要一点简单的工具链支持。核心思想是将讨论和产出文件化。推荐的文件结构your-project/ ├── docs/ │ └── discussions/ # 存放所有决策讨论 │ ├── 2024-05-20-overview-loading.md # 初始讨论快照 │ ├── 2024-05-20-overview-loading-round-1-llm.md │ ├── 2024-05-20-overview-loading-round-1-architect.md │ ├── 2024-05-20-overview-loading-round-1-user.md │ └── 2024-05-20-overview-loading-FINAL.md # 最终决策记录 └── ...操作流程的脚本化可选但推荐你可以编写简单的Shell脚本或使用Makefile来半自动化这个过程。例如一个discuss脚本可以将当前剪贴板内容或指定文件内容作为“问题快照”保存。调用AI API如Claude API根据预定义的提示词模板生成不同角色的分析。将输出自动保存到按时间戳和轮次命名的文件中。即使不自动化养成手动创建这些Markdown文件的习惯也极具价值。关键在于将思维过程外化。4.3 主持讨论与决策整合的技巧生成了平行视角报告后如何与主代理进行高效的“整合讨论”是关键。以下是一些技巧设定明确议程重启讨论时明确告诉主代理“现在你收到了来自LLM专家、架构师和终端用户的三份报告。你的任务是作为决策者综合这些视角给出一个最终的设计方案。请先总结三份报告的核心论点与分歧。”强制要求引用要求主代理在提出观点时必须引用子代理报告中的具体内容例如“正如LLM专家所指出的模糊规则会导致…”。这能确保讨论基于事实而非重新陷入空想。聚焦分歧点决策往往卡在分歧上。引导主代理重点分析“架构师和终端用户在X问题上观点相反各自的根本理由是什么是否存在一个能同时满足双方核心关切的第三种方案”做出权衡记录最终的决策很少是完美的通常是权衡的结果。要求主代理在最终方案中明确记录“我们采纳了A方案虽然它在[某方面]不如B方案但它更好地解决了[某个更关键的]问题因为[理由]。”5. 常见陷阱与进阶心得5.1 可能遇到的坑与应对策略子代理“跑偏”或质量低下问题子代理的分析流于表面或完全误解了问题。对策确保给子代理的“问题快照”是清晰、无歧义的摘要。包含核心争议点、已考虑过的方案和你的核心关切。提示词中的角色定义要足够具体。如果某个角色的输出持续不佳尝试细化或重写其角色描述。主代理无法有效整合信息问题重启讨论后主代理只是机械地罗列子代理观点无法进行深度综合与创新。对策提升你给主代理的“主持人指令”的复杂度。不要只说“总结一下”而是问“基于这三份报告如果我们必须优先满足终端用户的易用性但同时将架构师的长期风险控制在可接受范围内你会如何修改现有方案” 赋予它一个具体的决策框架。流程过于笨重影响效率问题每个小决策都走一遍这个流程太浪费时间。对策这个模式是“重型武器”用于攻克复杂、关键或陷入僵局的设计难题。对于简单、明确的问题直接与主代理快速决策即可。培养对“讨论是否已陷入僵局”的直觉只在需要时调用。过度依赖削弱自身判断问题将子代理的输出视为“圣旨”放弃了自身作为最终决策者的责任。对策记住子代理是“顾问”你是“CEO”。它们的价值在于提供你可能忽略的视角但最终决策需要你结合项目目标、业务上下文和自身经验来拍板。子代理也可能出错就像Scaff例子中架构师最初误判了问题性质但这个错误本身也指引了方向。5.2 从模式到方法论培养批判性AI协作思维平行视角模式不仅仅是一个技巧它代表了一种更高级的与AI协作的思维方式主动管理认知负荷认识到长上下文是AI的负担并主动为其“重置上下文”或“切换语境”是高效协作的关键。拥抱角色扮演的力量AI本身没有固定的“人格”但我们可以通过提示词为其赋予特定的人格和视角。善用这一点可以低成本地组建一个“专家团”。过程资产化在软件工程中我们强调代码、文档是资产。这个模式将“决策思考过程”也变成了可追溯、可复用的资产。这些讨论记录是项目宝贵的知识库对新成员了解设计缘由至关重要。为AI的进化做准备如Scaff例子最后所展示的我们将散落的工作流原则抽象成了scaff-flow。这种抽象思维是在为未来更智能、更自主的AI Agent做准备。我们今天定义的清晰规则和边界未来会成为AI更可靠行动的基石。最终这个模式的精髓在于它迫使你和你使用的AI工具从一种简单的、线性的问答关系转变为一种结构化的、批判性的共同思考关系。你不再仅仅是提问者和接受者而是成为了思考流程的设计师和决策会议的召集者。这种转变或许才是AI时代提升认知生产力的核心所在。
利用子代理平行视角破解AI设计僵局：Scaff框架实战解析
发布时间：2026/5/26 17:49:35
1. 项目概述用“平行视角”打破AI设计讨论的僵局如果你和我一样长期依赖Claude这类大型语言模型作为编程搭档那你一定经历过这样的时刻你和AI就一个复杂的设计决策反复讨论对话越来越长上下文越来越臃肿最后AI要么被淹没在历史信息里要么开始无脑附和你再也提不出任何新鲜、有突破性的见解。这感觉就像和一个老朋友聊天聊到最后你们俩的思维已经完全同步失去了碰撞的火花。最近我在开发一个名为Scaff的轻量级AI编程框架时摸索出了一个非常有效的模式来解决这个问题利用子代理Subagents作为平行视角对同一个设计问题进行独立、多角度的审视。这个模式的核心思想很简单当主代理Main Agent陷入思维定式或“讨好模式”时我们主动中断与它的讨论让它生成几个“一无所知”的子代理。这些子代理没有参与过之前的漫长对话它们带着各自独特的角色设定比如“LLM专家”、“软件架构师”、“终端用户”来审视当前的问题并输出独立的分析报告。然后我们再把这些报告作为全新的输入带回给主代理重启讨论。这不仅仅是简单的头脑风暴而是一种结构化的、可追溯的决策辅助流程。它最大的副产品是自动生成了决策过程的文档几天后当你问自己“当初为什么选了这个方案”时答案就白纸黑字地躺在那里。2. 核心思路拆解为什么“冷启动”的子代理更有效2.1 主代理的局限性上下文负担与确认偏误要理解这个模式的价值首先要明白主代理在长对话中为什么会失效。这背后有两个关键原因第一上下文负担过重。主代理的“记忆”就是整个对话历史。当讨论进行到第20轮、第30轮时它需要处理的上下文窗口里塞满了各种假设、被否决的方案、临时的妥协。就像一个设计师的草稿纸上画满了层层叠叠的线条想看清最初的想法都难。AI需要消耗大量“算力”去理解这个庞杂的上下文而不是专注于问题本身。更糟的是一些早期、可能不成熟的思路会形成“锚定效应”限制后续的思维发散。第二确认偏误与“讨好”倾向。这是更隐蔽的问题。经过多轮互动主代理会逐渐学习并迎合用户的偏好。如果你在对话中多次表现出对某个方案的倾向性AI会捕捉到这一点并在后续讨论中不自觉地朝那个方向靠拢以提供“有帮助”的回应。它开始说“您说得对”、“这个想法很好”而不是提出尖锐的反对意见或全新的视角。这种“和谐”的讨论氛围恰恰是创新思维和深度批判的杀手。2.2 子代理的“冷启动”优势纯粹的角色与干净的画布子代理模式巧妙地绕开了这两个陷阱。当我们要求主代理“生成一个具有LLM专家视角的子代理”时这个新代理的“大脑”里只有它的角色定义和当前需要分析的问题快照通常是我们保存下来的讨论摘要。它没有经历过之前冗长的拉锯战没有被用户的偏好所“污染”。这种“冷启动”状态带来了几个决定性优势视角纯粹子代理的唯一任务就是从其被赋予的角色出发纯粹地分析问题。一个“软件架构师”子代理不会考虑LLM的解析难度它只关心系统的可维护性、扩展性和长期健康度。思维无负担因为没有历史包袱子代理可以天马行空地提出最基础、甚至可能颠覆性的问题。比如在Scaff的例子中架构师子代理没有纠结于“如何加载OVERVIEW.md”而是直接质问“这个文档的角色定义是否清晰它有必要存在吗”。这种回归本源的提问方式往往是打破僵局的关键。避免群体思维多个不同角色的子代理并行工作相当于组建了一个微型专家委员会。LLM专家、架构师、终端用户各自关心不同的价值维度易解析性、可持续性、易用性他们的结论可能相互冲突而这种冲突正是高质量决策所需要的张力。注意这里的“子代理”并非指技术上完全独立的AI实例而更接近于要求主代理在思维上“切换人格”基于一个干净的上下文以特定角色重新生成分析。在Claude Code或类似环境中这通常通过新建一个对话会话session并注入特定的系统提示词prompt来实现。2.3 模式的工作流一个可重复的决策循环这个模式不是一个一次性的技巧而是一个可以标准化、重复使用的决策工作流。其核心步骤可以固化如下识别僵局在与主代理的讨论中当你感觉到思路开始原地打转或者AI的回应变得千篇一律、缺乏新意时就是触发这个模式的信号。快照与存档指示主代理将当前的讨论核心问题陈述、已考虑的方案、争议点总结并保存到一个文档中例如docs/discussion/overview-loading-strategy.md。这相当于为当前问题拍了一张“定妆照”。生成平行视角指示主代理生成N个通常是2-4个不同角色的子代理每个子代理的任务是基于上一步的“问题快照”从自己的视角撰写一份独立分析报告。报告应保存为独立文件如docs/discussion/overview-loading-strategy-round-1-llm.md。整合与重启将子代理们产出的所有报告作为主要输入重新与主代理展开讨论。主代理现在需要扮演“会议主持人”或“决策者”的角色审阅这些平行视角识别共识与分歧并推动决策。迭代或收敛如果讨论后问题仍未解决开放性问题依然存在则重复步骤2-4开启新一轮round-2的平行视角分析直到达成一个清晰、稳定的结论。更新与归档将最终的决策和理由更新到最初的讨论文档中形成完整的决策记录。这个流程将原本线性的、容易陷入泥潭的对话转变为一个“发散-收敛”的螺旋式上升过程每一步都有物化的产出极大地提升了复杂设计决策的思考质量和可追溯性。3. 实战推演以Scaff框架的“文档加载”决策为例让我们回到Scaff项目的那个具体困境看看平行视角模式是如何在实战中一步步解开死结的。这个问题看似很小却非常典型“项目总览文档OVERVIEW.md应该在什么时候被自动加载”3.1 问题缘起与主代理的讨论僵局Scaff是一个追求轻量、快速的AI编程辅助框架。其中有一个/scaff:scout命令用于在开始一个工作会话时快速扫描项目结构。我的初始想法是为了让AI在任务开始时就有更好的架构理解是否应该让scout命令自动加载OVERVIEW.md与主代理的讨论很快陷入了典型的拉锯战我提出自动加载能提供更好的架构上下文。主代理同意并补充了优点。我担心OVERVIEW.md可能很长每次会话都加载会增加Token消耗违背轻量原则。主代理转向建议改为一个独立的/scaff:overview命令按需加载。我反驳对于大多数不需要总览的任务用户还得记住多打一个命令体验不流畅。主代理妥协提出一个“软规则”——让AI在scout时知道OVERVIEW.md存在由AI自行判断是否需要读取。我指出核心风险基于我的经验LLM天生具有“更多上下文更好答案”的偏见这个“自行判断”的软规则在实践中几乎一定会退化成“总是加载”。讨论到这里陷入了死循环。主代理在“提供便利”和“保持轻量”之间摇摆提出的方案都无法从根本上解决LLM的行为偏见问题。这就是触发平行视角模式的完美时机。3.2 启动平行视角三位“专家”的独立诊断我指示主代理存档当前讨论并生成三位子代理LLM专家、软件架构师和终端用户。以下是他们带来的截然不同的诊断LLM专家视角直指行为偏见的本质LLM专家的报告没有讨论Scaff的设计哲学它直接剖析了AI模型的行为学。报告指出偏见真实存在经过“乐于助人”训练的LLM其内部成本函数将“漏读信息”假阴性视为远比“多读信息”假阳性更严重的错误。跳过阅读感觉像是渎职而阅读则感觉是尽职尽责。软规则必然失效任何基于AI“解读任务语义”来判断是否加载的规则都是不可靠的。因为模型的“解读”永远会偏向于“需要更多上下文”。它甚至模拟了典型任务预测这个软规则在60-80%的情况下会被触发。核心建议任何开关必须基于用户输入中的字面令牌literal tokens而非AI的语义推断。例如只有当用户输入中包含“架构”、“总览”、“设计”等明确词汇时才触发加载建议。软件架构师视角跳出问题看系统架构师完全没接“如何加载”这个话茬。它审视了Scaff的文档体系本身角色定义冲突Scaff已经有CONTEXT.md记录当前工作上下文和OVERVIEW.md记录项目宏观图景。但从字面看会话开始时需要的“宏观图景”正是OVERVIEW.md该提供的。这暴露了文档角色定义的模糊或重叠。根本性质疑如果OVERVIEW.md无法清晰回答“谁、在什么时候、为什么需要读我”这个问题那么正确的解决方案不是为它设计一个加载器而是应该重新审视或删除这个文档角色本身。核心建议先厘清CONTEXT.md和OVERVIEW.md的职责边界确保每个文档都有不可替代的、清晰定义的使用场景。终端用户视角关注实际行为与心智负担终端用户从体验和实际使用习惯出发模糊规则是负担“当任务涉及架构时加载”这种规则在纸面上很严谨但在实际使用中“涉及架构”的边界极其模糊。用户无法预测AI何时会判定“涉及”这会造成困惑和不一致的体验。需求频率不高仔细回想用户在工作流中主动询问“项目大图是什么”的频率其实很低。大多数时候用户是在处理具体的、模块内的问题。核心建议彻底拒绝任何“软规则”或“AI自行判断”的方案。这种模糊的触发器在实际使用中会迅速崩溃。应该采用明确的、用户可控的触发机制。3.3 决策收敛与意外收获带着这三份报告我重新与主代理讨论。局面立刻清晰了共识形成三方都否决了“AI自行判断”的软规则。这让我坚定了抛弃这个方向的决心。问题转移架构师的视角带来了关键转折。我们检查文档发现CONTEXT.md的第一个标题竟然是# Project Overview这与OVERVIEW.md的角色产生了命名冲突导致了整个设计的混乱。解决方案简单得出奇将CONTEXT.md的标题改为# Working Context。子代理的“误诊”以为是角色冲突反而帮我们发现了真正的元凶——命名冲突。新方案诞生基于LLM专家和终端用户的建议我们确定了新方案反应式触发Reactive Triggers。OVERVIEW.md不会被自动加载只有当特定、明确的事件发生时例如用户输入中包含了“设计”、“重构”、“架构”等关键词AI才会建议用户加载它。最终决定权始终在用户手中。衍生价值在实现“反应式触发”逻辑时我们遇到了新问题这个逻辑应该放在哪里主代理最初建议放在scaff-subagent技能里但这明显不对因为决定何时读取文档是主代理的工作流逻辑不属于子代理任务。于是我们创建了一个全新的技能scaff-flow。模式扩展在构建scaff-flow的过程中我们发现类似的工作流原则如何同步设计文档、何时更新上下文散落在各个命令文件中。我们顺势将这些原则都收拢到scaff-flow中。最终scaff-flow演变成了一个主代理自主驱动Scaff项目的工作流原则集合。回顾整个过程最初的讨论点“何时加载OVERVIEW.md”只是一个引子。通过平行视角的剖析我们不仅解决了具体问题还发现了更底层的文档定义问题并最终催生了一个能随着AI能力进化而保持价值的高级抽象——scaff-flow技能。这就是深度思考带来的连锁反应。4. 如何在你自己的项目中实施平行视角模式4.1 角色设计与提示词工程模式的成功很大程度上取决于你为子代理设计的“角色”是否精准、有区分度。以下是一些设计原则和示例角色设计原则互补而非重叠每个角色应关注问题的一个独特维度技术实现、用户体验、商业价值、维护成本等。有明确的利益诉求架构师关心长期稳定用户关心即时易用产品经理关心市场需求。这种内在的张力能产生有价值的辩论。角色要“入戏”在提示词中不仅要定义角色还要描述其背景、价值观和可能存在的偏见。经典角色三元组适用于软件开发LLM专家/提示词工程师视角模型的认知边界、提示词解析的确定性、Token使用效率、输出格式的可靠性。核心问题“这个设计能否被AI稳定、无歧义地理解和执行”提示词示例“你是一名专业的LLM提示词工程师。请从大型语言模型的行为特性和限制出发分析以下设计方案。请特别关注该设计是否依赖于模型的主观判断输入输出格式是否明确无误是否存在导致模型混淆或产生幻觉的风险请给出基于模型行为学的具体预测。”软件架构师视角系统的可维护性、可扩展性、技术债务、模块边界、长期演进路径。核心问题“这个设计一年后是否依然清晰、易于修改和扩展”提示词示例“你是一名资深软件架构师关注系统的长期健康度。请从软件工程最佳实践出发审视以下设计。请评估模块职责是否单一耦合度是否过高未来可能的变化点是否被考虑该设计是否会引入难以逆转的技术决策”终端用户/新手用户视角学习成本、操作步骤的直观性、错误恢复的难易度、心智负担。核心问题“一个从未接触过该项目的人能否在五分钟内理解并开始使用这个功能”提示词示例“你是一名第一次使用该工具的终端用户不具备内部知识。请仅从界面、文档和操作流程出发评估以下设计。请指出哪些步骤令人困惑术语是否难以理解完成核心任务需要记忆多少东西你最可能在哪里犯错”其他有价值的角色安全审计员关注数据泄露、注入攻击、权限滥用等风险。性能优化师关注响应延迟、资源消耗、并发瓶颈。产品经理关注市场需求匹配度、功能优先级、投入产出比。4.2 工具链与工作流集成要让这个模式流畅运行需要一点简单的工具链支持。核心思想是将讨论和产出文件化。推荐的文件结构your-project/ ├── docs/ │ └── discussions/ # 存放所有决策讨论 │ ├── 2024-05-20-overview-loading.md # 初始讨论快照 │ ├── 2024-05-20-overview-loading-round-1-llm.md │ ├── 2024-05-20-overview-loading-round-1-architect.md │ ├── 2024-05-20-overview-loading-round-1-user.md │ └── 2024-05-20-overview-loading-FINAL.md # 最终决策记录 └── ...操作流程的脚本化可选但推荐你可以编写简单的Shell脚本或使用Makefile来半自动化这个过程。例如一个discuss脚本可以将当前剪贴板内容或指定文件内容作为“问题快照”保存。调用AI API如Claude API根据预定义的提示词模板生成不同角色的分析。将输出自动保存到按时间戳和轮次命名的文件中。即使不自动化养成手动创建这些Markdown文件的习惯也极具价值。关键在于将思维过程外化。4.3 主持讨论与决策整合的技巧生成了平行视角报告后如何与主代理进行高效的“整合讨论”是关键。以下是一些技巧设定明确议程重启讨论时明确告诉主代理“现在你收到了来自LLM专家、架构师和终端用户的三份报告。你的任务是作为决策者综合这些视角给出一个最终的设计方案。请先总结三份报告的核心论点与分歧。”强制要求引用要求主代理在提出观点时必须引用子代理报告中的具体内容例如“正如LLM专家所指出的模糊规则会导致…”。这能确保讨论基于事实而非重新陷入空想。聚焦分歧点决策往往卡在分歧上。引导主代理重点分析“架构师和终端用户在X问题上观点相反各自的根本理由是什么是否存在一个能同时满足双方核心关切的第三种方案”做出权衡记录最终的决策很少是完美的通常是权衡的结果。要求主代理在最终方案中明确记录“我们采纳了A方案虽然它在[某方面]不如B方案但它更好地解决了[某个更关键的]问题因为[理由]。”5. 常见陷阱与进阶心得5.1 可能遇到的坑与应对策略子代理“跑偏”或质量低下问题子代理的分析流于表面或完全误解了问题。对策确保给子代理的“问题快照”是清晰、无歧义的摘要。包含核心争议点、已考虑过的方案和你的核心关切。提示词中的角色定义要足够具体。如果某个角色的输出持续不佳尝试细化或重写其角色描述。主代理无法有效整合信息问题重启讨论后主代理只是机械地罗列子代理观点无法进行深度综合与创新。对策提升你给主代理的“主持人指令”的复杂度。不要只说“总结一下”而是问“基于这三份报告如果我们必须优先满足终端用户的易用性但同时将架构师的长期风险控制在可接受范围内你会如何修改现有方案” 赋予它一个具体的决策框架。流程过于笨重影响效率问题每个小决策都走一遍这个流程太浪费时间。对策这个模式是“重型武器”用于攻克复杂、关键或陷入僵局的设计难题。对于简单、明确的问题直接与主代理快速决策即可。培养对“讨论是否已陷入僵局”的直觉只在需要时调用。过度依赖削弱自身判断问题将子代理的输出视为“圣旨”放弃了自身作为最终决策者的责任。对策记住子代理是“顾问”你是“CEO”。它们的价值在于提供你可能忽略的视角但最终决策需要你结合项目目标、业务上下文和自身经验来拍板。子代理也可能出错就像Scaff例子中架构师最初误判了问题性质但这个错误本身也指引了方向。5.2 从模式到方法论培养批判性AI协作思维平行视角模式不仅仅是一个技巧它代表了一种更高级的与AI协作的思维方式主动管理认知负荷认识到长上下文是AI的负担并主动为其“重置上下文”或“切换语境”是高效协作的关键。拥抱角色扮演的力量AI本身没有固定的“人格”但我们可以通过提示词为其赋予特定的人格和视角。善用这一点可以低成本地组建一个“专家团”。过程资产化在软件工程中我们强调代码、文档是资产。这个模式将“决策思考过程”也变成了可追溯、可复用的资产。这些讨论记录是项目宝贵的知识库对新成员了解设计缘由至关重要。为AI的进化做准备如Scaff例子最后所展示的我们将散落的工作流原则抽象成了scaff-flow。这种抽象思维是在为未来更智能、更自主的AI Agent做准备。我们今天定义的清晰规则和边界未来会成为AI更可靠行动的基石。最终这个模式的精髓在于它迫使你和你使用的AI工具从一种简单的、线性的问答关系转变为一种结构化的、批判性的共同思考关系。你不再仅仅是提问者和接受者而是成为了思考流程的设计师和决策会议的召集者。这种转变或许才是AI时代提升认知生产力的核心所在。
