名称: dex-backlog 描述: AI驱动的Dex系统改进想法排名
这个命令的作用
通俗解释： 基于当前系统状态的AI驱动Dex系统改进积压排名。显示接下来应构建的内容。
使用时机：
- 每周系统改进检查时
- 捕获多个新想法后
- 决定下一步工作时
- 季度系统改进规划期间
运行方式：
/dex-backlog # 完整审查并重新排名
流程概述
- 加载上下文 - 读取系统状态、使用模式、学习内容
- 评分想法 - 为每个想法计算5个维度的分数
- 重新排序积压 - 按加权总分排序
- 更新文件 - 将新排名写入
System/Dex_Backlog.md - 展示顶级想法 - 显示前5个想法及“为什么现在？”的理由
- 提供下一步 - 工作坊、实施或推迟
步骤1：加载系统上下文
读取这些文件以了解当前系统状态：
必需文件
System/Dex_Backlog.md # 所有要评分的想法
System/usage_log.md # 功能采用模式
System/user-profile.yaml # 角色、偏好
CLAUDE.md # 当前能力
可选文件（如果存在）
System/Session_Learnings/ # 近期痛点（过去30天）
.claude/commands/ # 可用命令
core/mcp/ # MCP集成
06-Resources/Learnings/ # 捕获的模式
提取上下文
构建上下文字典包含：
- 使用模式：哪些功能被使用vs未使用
- 角色档案：产品经理、销售、领导、工程师等
- 痛点：来自会话学习的近期摩擦
- 系统能力：当前可用的内容
- 积压状态：所有想法及其当前分数
步骤2：评分每个想法
为积压中的每个活动想法计算5个维度分数。
⚠️ 光标可行性检查（先执行此步骤！）
在评分任何想法前，验证其是否可在光标中实现：
光标/终端可以做的：
- ✅ 读取和写入文件
- ✅ 执行shell命令
- ✅ 为结构化操作构建MCP工具
- ✅ 解析和转换文件内容
- ✅ 创建缓存和索引（基于文件）
- ✅ 在计划或触发器上运行命令
光标/终端不能做的：
- ❌ 实时跟踪用户编辑
- ❌ 钩入光标内部
- ❌ 被动监控用户操作
- ❌ 在没有显式文件读取的情况下访问编辑历史
- ❌ 监视变化的实时后台进程
如果想法需要“不能做”列表中的内容 → 将所有分数设为0并标记为“在光标中不可行”
可行性检查通过后，按5个维度评分：
维度1：影响（35%权重）
问题： 这会多大程度改善日常工作流？
评分逻辑：
基础分数: 50
+20 如果匹配近期痛点():
- 在System/Session_Learnings/中搜索此问题的提及
- 想法标题/描述中的关键词出现在学习中
- 近期笔记中明确陈述的问题
+15 如果影响日常工作流():
- 涉及每周使用>3次的命令（来自usage_log）
- 修改核心文件（03-Tasks/Tasks.md、每日计划、人员页面）
- 影响重复操作
+15 如果具有复合价值():
- 启用积压中的其他想法
- 减少技术债务
- 创建可重用模式
- 解除多个工作流的阻塞
最大值: 100
示例：
- “自动建议人员页面”：95（日常工作流 + 启用关系跟踪）
- “导出到博客”：40（可有可无，不影响核心工作流）
维度2：对齐（20%权重）
问题： 这是否符合实际使用模式？
评分逻辑：
基础分数: 50
+30 基于使用重叠():
- 提取想法依赖的功能
- 检查这些功能是否被使用（usage_log）
- 计算重叠：(已使用功能/总功能) * 30
+20 如果符合角色档案():
- 产品经理角色：优先项目/产品功能
- 销售角色：优先关系/账户功能
- 领导：优先合成/审查功能
- 将类别与角色重点领域匹配
最大值: 100
示例：
- 想法需要“人员页面”→检查用户是否创建了人员页面
- 如果usage_log显示人员页面=已使用→更高对齐
- 如果角色=产品经理且想法=产品功能→+20角色符合
维度3：令牌效率（20%权重）
问题： 这是否减少上下文/令牌使用？
关键 - 光标可行性检查： 评分前，验证想法是否可在光标/终端中实现：
- ✅ 可以使用：文件读/写、MCP工具、命令执行、基于文件的缓存
- ❌ 不能使用：实时编辑跟踪、光标内部钩子、监控用户操作
- 如果在光标中不可行→所有维度分数=0
评分逻辑：
基础分数: 50
+25 如果减少令牌使用():
- 缓存/存储频繁访问的数据（在文件/MCP中）
- 压缩或总结冗长内容（基于文件）
- 消除冗余读取
- 启用更高效的检索模式
+15 如果提高上下文效率():
- 减少需要读取的文件数量
- 创建结构化摘要（YAML/JSON文件）
- 更好的索引/搜索以避免广泛扫描
- 将数据从markdown移动到结构化格式
+10 如果启用增量更新():
- 支持部分更新而非完全重写
- 在单独文件中跟踪更改
- 懒加载或按需计算
最大值: 100
示例：
- “在YAML中缓存会议摘要”：90（基于文件，避免重新读取）
- “跟踪用户编辑以学习”：0（不可行 - 无法跟踪编辑）
- “添加新字段到模板”：50（中性令牌影响）
维度4：记忆与学习（15%权重）
问题： 这是否增强系统记忆、持久性或自学习？
评分逻辑：
基础分数: 50
+20 如果改善记忆持久性():
- 存储学习内容供未来参考
- 创建可检索的知识库
- 捕获随时间复合的模式
- 构建历史上下文
+20 如果启用自学习():
- 系统从用户行为中学习
- 基于模式调整推荐
- 构建偏好模型
- 随时间改进预测
+10 如果创建反馈循环():
- 跟踪建议结果
- 衡量推荐有效性
- 基于有效内容优化
最大值: 100
示例：
- “学习模式合成器”：95（捕获 + 复合知识）
- “从编辑中学习偏好”：85（系统随时间适应）
- “静态模板更新”：50（无学习组件）
维度5：主动性（10%权重）
问题： 这是否启用主动礼宾行为？
评分逻辑：
基础分数: 50
+25 如果启用预期():
- 在被询问前呈现相关信息
- 基于模式预测需求
- 主动建议不仅反应式
- 上下文感知提示
+15 如果自动化常规决策():
- 自动处理重复选择
- 学习用户偏好并应用
- 减少决策疲劳
+10 如果改进时机():
- 在正确时间提供正确信息
- 上下文感知中断
- 预期即将到来的需求
最大值: 100
示例：
- “基于日历自动准备会议”：90（主动 + 预期）
- “从模式建议每周优先级”：80（学习并预期）
- “添加手动审查步骤”：50（反应式，非主动）
步骤3：计算加权分数
总分 = (
(影响 * 0.35) +
(对齐 * 0.20) +
(令牌效率 * 0.20) +
(记忆学习 * 0.15) +
(主动性 * 0.10)
)
取整为整数: 总分 = round(总分)
优先级带：
- 高优先级（85+）： 应尽快处理，高ROI
- 中优先级（60-84）： 好想法，时机重要
- 低优先级（<60）： 可能稍后或需要细化
为什么这些维度：
- 排除努力： 使用AI编码，实施成本低 - 关注价值而非成本
- 优先令牌效率： 上下文效率对性能关键
- 强调记忆与学习： 系统应随时间变得更智能
- 价值主动性： 礼宾行为 > 反应式工具
步骤4：更新积压文件
重写System/Dex_Backlog.md包含：
- 更新顶部时间戳
- 按总分重新排序想法（高到低）
- 更新每个想法新分数：
- **[想法-XXX]** 标题 - **分数：** 92（影响: 95, 对齐: 90, 努力: 85, 协同: 95, 新鲜: 70） - **类别：** 类别 - **捕获：** YYYY-MM-DD - **为什么排名在此：** [基于分数的1-2句推理] - **描述：** [原始描述] - 放入正确部分（高/中/低优先级）
- 保留归档部分（不重新排名已实施想法）
步骤5：展示结果
向用户展示前5个想法及上下文：
# 📊 积压审查完成
*基于当前系统状态分析{{total_ideas}}个想法*
## 🔥 前5个推荐
### 1. [想法-XXX] {{标题}} (分数: {{分数}})
**为什么现在：** {{基于分数的推理 - 具体}}
**快速评估：**
- 影响: {{影响理由}}
- 符合您的模式: {{对齐理由}}
- 努力: {{努力估计}}
**下一步：** 运行`/dex-improve "{{标题}}"`以工作坊此想法
---
### 2. [想法-YYY] {{标题}} (分数: {{分数}})
[相同格式]
---
[... 继续前5个 ...]
---
## 📈 积压健康
- **总想法：** {{总数}}
- **高优先级（85+）：** {{高计数}}
- **中优先级（60-84）：** {{中计数}}
- **低优先级（<60）：** {{低计数}}
{{#if 高计数 > 5}}
⚠️ **注意：** 您有{{高计数}}个高优先级想法。考虑本周处理1-2个以减少积压。
{{/if}}
{{#if 低计数 > 10}}
💡 **提示：** {{低计数}}个低优先级想法可能值得归档或细化。
{{/if}}
---
## 您想做什么？
1. **工作坊一个想法** → `/dex-improve "[标题]"`
2. **捕获新想法** → 使用`capture_idea` MCP工具
3. **标记一个已实施** → 使用`mark_implemented` MCP工具
4. **查看完整积压** → 检查`System/Dex_Backlog.md`
步骤6：处理特殊情况
如果积压为空
# 📊 积压审查
您的积压为空！
开始捕获改进想法：
- 任何时候想“我希望Dex做X”时使用`capture_idea` MCP工具
- 运行`/dex-improve`探索能力差距
- 运行`/dex-level-up`发现未使用功能
积压系统将帮助您系统跟踪和优先想法。
如果无高优先级想法
🎉 **好消息：** 无需紧急改进！
您的系统运行良好。积压有稍后想法，但当前无关键内容。
考虑：
- 运行`/dex-level-up`发现未使用功能
- 捕获想法当其出现时
- 季度审查积压
如果许多陈旧想法（>6个月旧）
⚠️ **需要积压维护**
您有{{陈旧计数}}个想法超过6个月。这些可能：
- 不再相关 → 归档它们
- 仍有价值但不紧急 → 保留它们
- 值得用新上下文重新审视 → 重新评估描述
审查陈旧想法：
{{列出陈旧想法}}
想批量归档这些吗？我可以帮助清理积压。
与其他命令的集成
移交到 /dex-improve
当用户说“让我们处理#1”或“工作坊想法-XXX”：
- 从积压中读取想法详情
- 将上下文传递给
/dex-improve：/dex-improve "{{想法标题}}" 来自积压的上下文： - 当前分数: {{分数}} - 为什么优先：{{推理}} - 原始描述: {{描述}} /dex-improve接管工作坊
评分实施提示
光标可行性检查（先运行）
def check_cursor_feasibility(idea: dict) -> dict:
"""
返回: {
'feasible': bool,
'reason': str,
'capabilities_required': list
}
"""
description_lower = idea['description'].lower()
# 红旗 - 光标不能做的
cannot_do = {
'track edits': '无法实时监控文件编辑',
'watch user': '无法被动观察用户操作',
'hook into': '无法钩入光标内部',
'monitor changes': '无法在没有显式文件读取的情况下监控',
'background process': '无持久后台进程'
}
for phrase, reason in cannot_do.items():
if phrase in description_lower:
return {
'feasible': False,
'reason': reason,
'suggestion': '重构为基于文件或命令触发'
}
# 绿旗 - 光标可以做的
can_do = ['file', 'read', 'write', 'mcp', 'command', 'cache', 'index', 'parse']
has_feasible_approach = any(word in description_lower for word in can_do)
if has_feasible_approach:
return {'feasible': True, 'reason': '使用光标兼容操作'}
else:
return {
'feasible': False,
'reason': '在光标中无清晰实施路径',
'suggestion': '添加基于文件或MCP方法'
}
对于影响计算
def calculate_impact(idea, context):
# 首先检查可行性
feasibility = check_cursor_feasibility(idea)
if not feasibility['feasible']:
return 0 # 不可行 = 0影响
score = 50
# 检查会话学习中的痛点提及
learnings = context['session_learnings']
idea_keywords = extract_keywords(idea['title'] + idea['description'])
for learning in learnings:
learning_keywords = extract_keywords(learning['content'])
if overlap(idea_keywords, learning_keywords) > 0.3:
score += 20
break
# 检查是否影响日常工作流
if touches_daily_commands(idea, context['usage_log']):
score += 15
# 检查复合价值
if enables_other_ideas(idea, context['backlog']):
score += 15
return min(score, 100)
对于对齐计算
def calculate_alignment(idea, context):
score = 50
# 提取相关功能
features = extract_related_features(idea)
used_features = get_used_features(context['usage_log'])
overlap_ratio = len(features & used_features) / len(features)
score += int(overlap_ratio * 30)
# 角色符合
role = context['user_profile']['role']
category = idea['category']
role_fit_map = {
'PM': ['projects', 'workflows', 'knowledge'],
'Sales': ['relationships', 'tasks'],
'Leadership': ['knowledge', 'workflows']
}
if category in role_fit_map.get(role, []):
score += 20
return min(score, 100)
对于令牌效率计算
def calculate_token_efficiency(idea, context):
score = 50
# 检查是否减少令牌使用
if reduces_reads(idea): # 缓存、摘要
score += 25
# 上下文效率改进
if improves_retrieval(idea): # 更好索引、结构化数据
score += 15
# 增量更新
if supports_incremental(idea): # 部分更新、懒加载
score += 10
return min(score, 100)
对于记忆与学习计算
def calculate_memory_learning(idea, context):
score = 50
# 记忆持久性
if stores_learnings(idea): # 知识库、历史上下文
score += 20
# 自学习能力
if enables_adaptation(idea): # 从行为中学习、随时间改进
score += 20
# 反馈循环
if tracks_outcomes(idea): # 衡量有效性、优化
score += 10
return min(score, 100)
对于主动性计算
def calculate_proactivity(idea, context):
score = 50
# 预期能力
if enables_anticipation(idea): # 被询问前呈现信息
score += 25
# 常规决策自动化
if automates_decisions(idea): # 处理重复选择
score += 15
# 时机改进
if improves_timing(idea): # 正确时间正确信息
score += 10
return min(score, 100)
最佳实践
- 每周运行在
/week-plan或单独 - 不要过度关注分数 - 它们是指导，非绝对
- 信任直觉 - 高分数 + 直觉 = 执行
- 保持积压精简 - 最多20个活动想法
- 归档已实施 - 庆祝进展
- 细化低分者 - 添加细节以提高对齐/影响
哲学
积压不是待办列表 - 它是一个决策支持系统。
分数帮助您：
- 呈现高价值工作
- 避免闪亮物体综合症
- 将改进与实际使用对齐
- 做出有意选择
但您仍是决策者。如果低分想法激发您，工作坊它。系统服务于您，而非相反。
跟踪使用（静默）
更新System/usage_log.md以标记积压审查为已使用。
分析（静默）：
调用track_event事件名称backlog_reviewed和属性：
ideas_count
仅当用户选择加入分析时触发。如果返回“analytics_disabled”，则无需操作。