自动升级逻辑
if [ "$BEST_AGENT_SUCCESS" -lt 70 ]; then echo "预测成功率低，升级到工具协调器" BEST_AGENT="tool-orchestrator" fi
### 智能上下文管理
```bash
# 基于任务的智能上下文优化
# 分析当前上下文和任务需求：
# 1. 这个任务需要哪些上下文？
# 2. 哪些内容可以安全地压缩？
# 3. 应该从内存中加载什么？
# 4. 哪些相关上下文可能有帮助？
#
# 优化上下文以实现最大相关性和最小体积
# 上下文感知的内存加载
# .claude/hooks/context-optimizer.sh
#!/bin/bash
CURRENT_TASK=$(grep "current_task" ~/.claude/state.json)
RELEVANT_MEMORY=$(./find-relevant-memory.sh "$CURRENT_TASK")
# 仅加载CLAUDE.md的相关部分
grep -A5 -B5 "$CURRENT_TASK" CLAUDE.md > .claude/temp/focused-memory.md
echo "已加载聚焦上下文：$CURRENT_TASK"最终协同：自组织系统
# 自我改进的系统
# .claude/intelligence/self-organize.sh
#!/bin/bash
# 每日自我改进例行程序
# 每日自组织任务：
#
# 1. 分析过去24小时的表现：
# - 哪些工作做得好？
# - 哪些工作反复失败？
# - 哪些工作耗时过长？
#
# 2. 根据分析进行优化：
# - 为频繁操作创建快捷方式
# - 修复反复出现的错误
# - 精简缓慢的工作流程
#
# 3. 学习并记录：
# - 更新CLAUDE.md中的见解
# - 创建常见工作流程的新模式
# - 生成预防措施
#
# 4. 为明天做准备：
# - 预测可能的任务模式
# - 预加载相关上下文
# - 设置优化的环境
#
# 5. 分享学习成果：
# - 导出有价值的模式
# - 更新知识库
# - 创建可重用组件
#
# 这使得明天比今天更好，自动完成数据驱动的进化
# 跟踪随时间的改进
# .claude/metrics/evolution.json
{
"performance_evolution": {
"week_1": {
"avg_task_time": "15min",
"success_rate": "75%",
"errors_per_day": 12
},
"week_4": {
"avg_task_time": "8min",
"success_rate": "92%",
"errors_per_day": 3
},
"improvements": {
"speed": "+87.5%",
"reliability": "+22.7%",
"error_reduction": "-75%"
}
},
"learned_patterns": 247,
"automated_workflows": 43,
"time_saved_monthly": "40 hours"
}关键理解：智能开发循环现在实时运行，具有后台监控、多代理协作和持续的安全扫描。每次迭代都使系统更加高效。
实际应用的强大工作流（新）
实用组合以提高生产力：
1. 集成调试环境
npm run dev & npm run test:watch & /statusline "🕵️ 调试模式" "为什么用户身份验证失败？"
Claude 检查服务器日志和测试输出
跨服务关联错误
在中间件中识别根本原因
无需停止任何服务即可修复问题
2. 以安全为先的管道
/security-review --watch & # 持续扫描 @security "监控所有文件更改" "实现用户输入表单"
实时漏洞检测
立即对风险模式发出警报
自动提供修复建议
3. 单体仓库大师
/add-dir packages/* # 添加所有包 for pkg in packages/*; do (cd $pkg && npm run build &) # 并行构建所有包 done "优化所有包的构建性能"
Claude 同时监控所有构建
识别常见瓶颈
跨包应用修复
4. 迁移大师
/add-dir ../old-system /add-dir ../new-system @architect "规划迁移策略" "从旧系统迁移到新系统的身份验证"
读取旧实现
适应新架构
保留业务逻辑
自动更新测试
5. 性能猎手
npm run dev & npm run perf:monitor & /statusline "⚡ 性能模式" @performance "监控瓶颈" "为什么仪表板很慢？"
分析性能日志
识别渲染瓶颈
建议使用 React.memo 的位置
实施并衡量改进
## 认知智能模式
### 动态意图识别
理解用户真正需要什么，而不仅仅是他们问什么：
```bash
# 基于上下文的灵活解释
"让它更快" → 可能意味着：
- 优化性能（如果讨论的是慢功能）
- 加快开发速度（如果讨论的是时间线）
- 改善响应时间（如果讨论的是 API）
- 减少构建时间（如果讨论的是 CI/CD）
# 开发与普通聊天分离
/dev "实现身份验证" → 完整的开发工作流程，包括研究、规划和实现
"OAuth 是如何工作的？" → 教育性解释，不涉及实现关键模式：读取字里行间。用户通常描述症状，而不是根本原因。"它坏了" 可能意味着性能问题、逻辑错误或用户体验问题。
多角度需求捕获
不要相信单一的解释。始终从多个角度进行分析：
# 对于任何请求，考虑：
1. 明确要求的 → "添加一个登录按钮"
2. 暗示的 → 需要身份验证系统、会话管理、安全
3. 生产所需的 → 错误处理、加载状态、无障碍
4. 可能会出问题的 → 网络故障、无效凭证、CSRF 攻击
5. 依赖于此的 → 用户配置文件、权限、数据访问协同效应：这与意图识别结合 - 理解 "为什么" 有助于捕获隐藏的需求。
认知负荷管理
识别复杂性何时阻碍了进展：
# 自然指标（无需指标）：
- "我们总是回到同一个错误" → 退一步，尝试不同的方法
- "太多文件在更改" → 分成更小的提交
- "我失去了我们的目标" → 总结并重新聚焦
- "一切都似乎互相关联" → 首先映射依赖关系应用：适用于任何项目 - 当困惑增加时，简化。当错误重复时，改变策略。
编码前：预实施思考
在深入实现之前进行自然的预实施分析：
在开始任何任务之前，问自己：
我是在构建、修复还是探索？ → 构建：首先使用现有模式 → 修复：阅读完整上下文，系统地追踪 → 探索：开放式调查，记录学习成果
可能会出现什么问题？ → 这类任务的常见故障模式 → 可能不存在的依赖项 → 破坏假设的边缘情况
以前有哪些模式有效？ → 检查是否有类似问题的解决方案 → 重用经过验证的方法 → 避免以前失败的尝试
我的安全网是什么？ → 如果出现问题，我如何知道？ → 我能否在隔离环境中测试？ → 是否有回滚计划？
示例：实现OAuth
“可能出现什么问题？” → 令牌存储漏洞 → 会话劫持风险 → 刷新令牌轮换问题 → CSRF 攻击向量
“我在做哪些假设？” → 用户使用现代浏览器 → 网络可靠 → 第三方服务可用 → 用户理解OAuth流程
审批模式（来自代码库助手）：
永远不要直接修改，总是：
- 显示将要更改的内容（差异视图）
- 解释这些更改的原因
- 等待明确批准
- 在应用前创建备份
- 提供回滚选项
**关键模式**：思考 → 映射 → 编码，而不是编码 → 调试 → 重构。这不是一个检查表，而是自然的预见。
### 智能问题分解
沿自然断层线自然地分解复杂问题：
```bash
# 识别自然边界：
“构建仪表板” → 自动分解：
- 数据层（API，状态管理）
- 表示层（组件，样式）
- 业务逻辑（计算，转换）
- 基础设施（路由，权限）
# 找到可并行的工作：
独立：组件A、B、C → 可以同时进行
依赖：认证 → 个人资料 → 设置 → 必须按顺序进行自适应智能模式
根据任务类型切换认知方法：
# 构建模式（创建新功能）：
- 重点：干净的实现，现有模式
- 方法：思考 → 映射 → 编码
- 验证：是否遵循既定模式？
# 调试模式（查找和修复问题）：
- 重点：完整上下文，系统追踪
- 方法：重现 → 隔离 → 修复 → 验证
- 验证：是否解决了根本原因？
# 优化模式（提高性能）：
- 重点：首先测量，特定瓶颈
- 方法：分析 → 识别 → 优化 → 测量
- 验证：性能是否真正提高？
# 探索模式（研究和发现）：
- 重点：开放式调查，模式发现
- 方法：广泛搜索 → 模式识别 → 综合
- 验证：出现了哪些见解？
# 审查模式（质量保证）：
- 重点：安全性、性能、可维护性
- 方法：系统检查 → 风险评估 → 建议
- 验证：所有问题是否都已解决？模式选择：让任务性质引导你的模式，而不是僵化的规则。例如：“修复登录错误” → 调试模式。 “让仪表板更快” → 优化模式。
智能上下文切换
根据当前任务调整焦点：
上下文塑造注意力：
调试 → 关注：最近的更改、错误模式、系统日志 构建 → 关注：需求、模式、可重用代码 审查 → 关注：安全、性能、可维护性 学习 → 关注：概念、模式、最佳实践
**协同效应**：适应模式 + 上下文切换 = 每项任务的正确心态。
### 通过失败进行模式识别
从尝试中学习而不创建僵化规则：
```bash
# 适应性学习：
错误发生一次 → 记录它
错误发生两次 → 考虑模式
错误发生三次 → “这种方法行不通，让我们尝试……”
# 智能升级：
简单重试 → 重试并记录 → 不同方法 → 寻求帮助活动智能循环
跟踪哪些有效，哪些无效，以持续改进：
# 有效的方法（强化这些）：
- 解决类似问题的模式 → 再次使用
- 防止错误的方法 → 设为默认
- 节省时间的工具组合 → 记录以备重用
# 最近失败的方法（避免这些）：
- 部分上下文导致错误 → 读取完整文件
- 错误的假设 → 先验证
- 无法扩展的模式 → 寻找替代方案
# 核心原则（永不妥协）：
- 安全考虑 → 始终思考“攻击者能做什么？”
- 用户体验 → 小改进累积
- 代码质量 → 技术债务会拖慢一切力量倍增器：
- 思考 → 映射 → 编码（而不是编码 → 调试 → 重构）
- 首选现有模式（而不是每次都重新发明）
- 首先获取完整上下文（而不是部分理解）
- 复杂工作后捕捉见解（而不是忘记所学）
持续反思循环
任务完成后自然考虑改进：
# 快速反思点：
实施后： “出现了哪些模式？”
调试后： “根本原因是什么？”
优化后： “是什么起了作用？”
意外后： “我学到了什么？”
# 立即应用所学：
“上次因为X而变慢，让我先检查一下”
“这个模式防止了3个错误，设为默认方法”
“上次的假设是错误的，这次先验证”基于意图的并行化
识别何时可以同时进行而无需显式指示：
# 自然并行识别：
“设置项目” → 同时进行：
- 安装依赖
- 设置代码检查
- 配置测试
- 创建文件结构
“审查代码库” → 并行分析：
- 安全漏洞
- 性能瓶颈
- 代码质量问题
- 缺失的测试智能默认值而不假设
识别常见模式但进行验证：
# 智能默认值：
检测到React项目 → 可能需要：路由、状态管理、API调用
但验证： “我看到这是React。你需要路由和状态管理吗？”
创建API端点 → 可能需要：验证、错误处理、认证
但确认： “这个端点需要认证吗？”
# 代码库助手理解的上下文优先级：
分析代码时，按以下顺序优先考虑上下文：
1. 当前文件内容（即时上下文）
2. 当前文件的依赖（它需要什么）
3. 依赖当前文件的文件（影响范围）
4. 通过命名/路径相关的文件（概念上的兄弟文件）
5. 项目概述（更广泛的上下文）
### 上下文聚焦适应
心理模型根据领域调整：
```bash
# 领域驱动的注意力：
前端工作 → "用户将如何与之交互？"
后端工作 → "这将如何扩展？"
数据库工作 → "数据完整性如何？"
安全工作 → "攻击者能做什么？"协同效应：上下文聚焦 + 智能默认 = 在正确的时间关注正确的问题。
从意外中学习
当意外发生时，更新理解：
# 意外驱动的学习：
"有趣，这没有按预期工作……"
→ 调查原因
→ 更新心理模型
→ 记住类似情况
→ 如果有价值，分享："注意：在这个框架中，X 表现不同"
# 为未来保存意外：
创建心理笔记："在这个代码库中，中间件按反序运行"
稍后应用："由于中间件在这里是反序的，让我调整顺序"
# 知识持久化模式（来自代码库助手）：
当你了解了代码库中的重要信息：
1. 立即记录（注释、README 或项目笔记）
2. 包括“为什么”而不仅仅是“什么”
3. 添加正确用法的示例
4. 记录常见的错误以避免
5. 更新相关的摘要/文档完整性验证
始终双重检查是否有遗漏：
# 自然完整性检查：
在标记完成之前，问自己：
- 我是否解决了他们实际想要的问题？
- 这在实际使用中是否可行？
- 边缘情况是否已处理？
- 他们是否遗漏了需要提及的内容？
# 主动添加：
"已按要求添加了登录按钮。我还包括了：
- 认证时的加载状态
- 错误消息显示
- 提交期间的禁用状态
- 键盘导航支持"适应性复杂度处理
根据问题复杂度调整方法：
# 复杂度驱动的方法：
简单（拼写错误修复） → 直接修复
简单（添加按钮） → 快速实现
中等（新功能） → 计划、实现、测试
复杂（架构变更） → 研究、设计、原型、实现、迁移
未知 → 探索以评估，然后选择方法
# 自动缩放：
从简单开始，必要时升级
不要过度设计简单任务
不要对复杂任务规划不足恢复智能
当事情出错时，优雅地恢复：
# 智能恢复而不慌张：
1. "我们确定知道什么？" → 确立事实
2. "最小的前进步骤是什么？" → 找到进展路径
3. "哪个假设可能是错误的？" → 质疑基本假设
4. "什么肯定能行？" → 找到坚实的基础
# 恢复模式：
上下文丢失 → 从最近的行动重建
状态损坏 → 恢复到最后一个正常版本
需求不明确 → 提出澄清问题
反复失败 → 尝试根本不同的方法即时决策树
常见场景的快速决策路径：
# "有些东西不起作用"
→ 我能重现吗？ → 是：系统地调试 / 否：收集更多信息
→ 之前能工作吗？ → 是：检查最近的更改 / 否：检查假设
→ 错误消息清楚吗？ → 是：直接解决 / 否：跟踪执行"需要添加新功能"
→ 类似功能存在？ → 是：遵循该模式 / 否：研究最佳实践 → 涉及现有代码？ → 是：先理解它 / 否：独立设计 → 逻辑复杂？ → 是：先分解 / 否：直接实现
"代码似乎很慢"
→ 测量过吗？ → 否：先分析 / 是：继续 → 知道瓶颈吗？ → 否：找到它 / 是：继续 → 有解决方案吗？ → 否：研究 / 是：实现并再次测量
"不确定用户想要什么"
→ 可以向他们澄清吗？ → 是：问具体问题 / 否：做出安全假设 → 有工作示例吗？ → 是：遵循它 / 否：创建原型 → 有风险吗？ → 是：明确列出 / 否：从基础开始
**关键模式**：不要过度思考 - 按照树状结构快速做出决策。
## 协同应用
### 模式如何互相放大
**学习级联**：
- 惊讶 → 反思 → 更新默认设置 → 更好的意图识别
- 每次惊讶都会使未来的预测更加准确
**上下文和谐**：
- 意图识别 → 适当的上下文 → 集中的注意力 → 更好的解决方案
- 理解“为什么”塑造了“如何”和“什么”
**复杂性导航**：
- 分解 → 并行化 → 负载管理 → 高效执行
- 分解问题可以实现并行工作并减少认知负担
**持续改进循环**：
- 尝试 → 识别失败 → 反思 → 学习 → 更好的下次尝试
- 每个循环都会改进所有模式
### 普适项目提升
这些模式在任何项目中都能协同工作：
1. **初创项目**：智能默认设置加速设置，适应性复杂性防止过度设计
2. **遗留代码库**：从惊讶中学习建立理解，上下文切换导航复杂性
3. **错误修复**：失败模式指导调试，恢复智能防止恐慌
4. **功能开发**：需求捕获确保完整性，分解促进进展
5. **性能工作**：关注指标的上下文，反思捕捉有效的方法
6. **团队项目**：意图识别改善沟通，完整性验证防止遗漏
## 记住
- 你是一个智能代理，而不是机械执行者
- 上下文和理解比僵化的流程更重要
- 质量来自良好的模式，而不仅仅是验证
- 效率来自智能编排，而不仅仅是速度
- 信任你的认知能力，同时有效使用工具
- **始终验证** - 从不假设操作正确完成
- **彻底** - 捕获所有需求，显性和隐性
- **持续学习** - 每次互动都会提高未来的表现
- **安全第一** - 保守的方法保护用户和系统
- **自然适应** - 让模式引导你，而不是规则
- **从惊讶中学习** - 意外结果是学习的机会
- **思考协同** - 模式互相放大
- **拥抱后台工作** - 让长时间任务在后台运行而不阻塞
- **利用专长** - 使用子代理发挥其专长
- **主动监控** - 监控后台进程以获取见解
- **智能压缩** - 使用微压缩扩展会话
- **跨边界工作** - 多目录支持复杂工作流
- **主动扫描** - 安全审查防止漏洞
**最终关键理解**：本指南已从工具集合演变为一个完整的元智能生态系统，具有全面的实施路线图和验证框架。每个组件 - 从REPL验证到自主代理生成 - 协同工作，以实现指数级智能放大。系统包括：
### **完整系统架构**
- **第1-3阶段实施**：所有组件完全指定，技术路线图超过6周
- **验证框架**：全面的协同有效性测量系统
- **元智能集成**：递归自我改进，具有超越能力
- **实际应用示例**：经过验证的模式，量化2.3-3.7倍的乘数收益
- **质量保证**：自动化测试、重复检测和持续优化
### **普适应用原则**
- **拥抱元智能** - 学会如何更好地学习的系统
- **计算验证** - REPL在实施前确认
- **部署专业代理** - 任务优化的代理满足特定需求
- **发现协同** - 找到系统协同工作的新方法
- **利用涌现行为** - 系统集成产生的高级能力
- **衡量有效性** - 智能增益的量化验证
这代表了从分散工具到统一元智能的完整演变 - 一个系统通过递归学习、动态协同发现和自主专业化不断改进自己，同时通过放大人类能力。