name: progress-summary description: 当用户询问诸如“可以总结一下吗”、“发生了什么”、“我们做了什么”、“情况如何”、“我们进展到哪里了”、“解释一下发生了什么”、“给我一个概述”、“已经做了什么”、“告诉我这个”、“带我了解发生了什么”或任何询问工作当前状态或变化的问题时，应使用此技能。提供对话式的、类似PR风格的摘要，并附带可视化图表。

进展摘要

生成工作进展的对话式摘要，使用精心制作的PR描述相同风格。

核心原则

动机优先

每个摘要都以为什么开头。不是文件改变了什么，不是它如何工作——为什么这项工作重要。

好的开头：

我们一直在处理会话超时问题，该问题导致用户在上传中途被登出。根本原因是会话刷新仅在导航时触发，而非在后台活动时。

坏的开头：

我们在上传处理程序中添加了保持活跃调用，并更新了会话刷新逻辑。

读者应在看到解决方案前理解问题。

展示你的思考

摘要应揭示决策过程：

“我们考虑了X，但Y更有意义，因为…”
“最初尝试了A，这揭示了B，引导我们到C”
“棘手部分是弄清楚如何挂钩到现有流程中”

对话式但精确

像在咖啡时间向同事解释一样写作。直接且诚实。

“这很痛苦”而非“这带来了挑战”
“我们卡在了”而非“我们遇到了困难”
使用“我们”表示协作工作，“我”表示个人观察

摘要类型

快速状态（口头检查）

针对“你在做什么”或简短更新：

正在处理认证超时问题。找到了根本原因：会话刷新仅在导航时触发，而非后台活动时。目前正在上传处理程序中实现保持活跃机制。

2-4句话。问题、发现、当前行动。

会话回顾（工作会话结束）

针对“总结我们做了什么”或收尾：

结构：

我们处理的问题
关键决策（及原因）
现在什么工作正常
还有什么要做

示例：

我们处理了状态管理中的嵌套响应性问题。用户发现通过手动get/set属性创建深层响应式状态很繁琐。

探索了几种方法后，我们选择了基于代理的响应性，因为它允许你编写地道的JavaScript，同时我们在底层获得不可变性的性能优势。

核心实现正常工作。仍需优化大型数组并更新迁移指南。

架构概述（解释复杂变更）

针对“解释这里发生了什么”在较大工作上：

自由使用ASCII图表。它们比散文更易于浏览。

旅程/演化图（当工作迭代先前尝试时）：

┌─────────────────────────────────────────────────────────────────┐
│  第一次尝试：直接Y.Map                                     │
│  问题：524,985字节存储开销                         │
└───────────────────────────────────────┬─────────────────────────┘
                                        │
                                        ▼
┌─────────────────────────────────────────────────────────────────┐
│  第二次尝试：YKeyValue包装                               │
│  结果：271字节（1935倍改进！）                          │
│  问题：不可预测的冲突解决                      │
└───────────────────────────────────────┬─────────────────────────┘
                                        │
                                        ▼
┌─────────────────────────────────────────────────────────────────┐
│  当前：带LWW时间戳的YKeyValue                          │
│  保留存储优势，添加可预测的“最新胜出”          │
└─────────────────────────────────────────────────────────────────┘

层图（针对架构变更）：

┌─────────────────────────────────────────────────────────────────┐
│  defineWorkspace() + workspace.create()                          │  ← 高层
│    在内部创建Y.Doc，绑定表/kv/能力        │
├─────────────────────────────────────────────────────────────────┤
│  createTables(ydoc, {...}) / createKv(ydoc, {...})               │  ← 中层
│    绑定到现有Y.Doc                                       │
├─────────────────────────────────────────────────────────────────┤
│  defineTable() / defineKv()                                      │  ← 低层
│    纯模式定义                                       │
└─────────────────────────────────────────────────────────────────┘

流程图（针对数据/控制流）：

┌────────────────────────────────────────────────────────────────┐
│  客户端A (2:00pm)  ──┐                                        │
│                       │──→  同步  ──→  胜者：客户端B        │
│  客户端B (3:00pm)  ──┘                                        │
│                                                                │
│  带时间戳：最新总是胜出                           │
│  不带：谁先同步谁胜出（不可预测）             │
└────────────────────────────────────────────────────────────────┘

比较表（针对权衡）：

┌────────────────────────────────────┬────────────────────────────┐
│  用例                          │  推荐            │
├────────────────────────────────────┼────────────────────────────┤
│  实时协作，简单案例    │  YKeyValue（位置性）    │
│  离线优先，多设备       │  YKeyValueLww（时间戳）  │
│  时钟同步不可靠             │  YKeyValue（无时钟依赖）  │
└────────────────────────────────────┴────────────────────────────┘

何时使用图表

旅程图：工作迭代先前尝试或修复过去决策时
层图：有不同层次的架构变更时
比较表：在方法间权衡时
流程图：数据或控制在组件间移动时

应避免什么

列出更改的文件：“更新了auth.ts、session.ts和upload.ts”——只需解释内容和原因
企业套话：“此增强利用了我们的现有基础设施”
营销语言：“变革性”、“革命性”、“无缝”
戏剧性夸张：“极度痛点”——坚持事实
事事都用项目符号：尽可能使用流动段落
过度解释简单变更：根据复杂性调整解释深度

收集摘要的上下文

要生成摘要，收集相关上下文：

# 当前分支状态
git status
git log --oneline -10

# 从主分支更改了什么
git diff main...HEAD --stat
git log main..HEAD --oneline

# 最近活动
git log --oneline --since="1小时前"

对于Conductor工作空间，使用GetWorkspaceDiff查看完整差异。

阅读修改的关键文件以理解变更实质，而不仅仅是差异统计。

ASCII艺术字符

用于整洁图表：┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼ ▼ ▲ ◀ ▶ ──→ ←──

保持框边缘对齐。在框内使用一致间距。