进展摘要Skill：把“我们做到哪了”讲成一段清晰的 PR 故事
核心结论速览
- 一句话定位：progress-summary 是一个专注“工作进展叙述”的 AI 技能，它把零散的代码改动、会话过程与决策碎片，整理成类似 PR（Pull Request）描述风格的对话式摘要。
- 动机优先原则：它不罗列“改了哪些文件”，而是先回答“为什么要做这件事”，让读者在看懂方案前先理解问题。
- 三种摘要形态：快速状态（口头检查）、会话回顾（一次工作收尾）、架构概述（复杂变更解释），按场景自动选择深度。
- 可视化表达：内置 ASCII 图表范式，包括旅程图、层图、流程图、比较表，帮助把架构演进和权衡讲清楚。
- 适用人群：开发者、技术负责人、协作型团队，以及任何需要向他人（或未来的自己）解释“发生了什么”的人。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 进展摘要Skill |
| 技能英文名 | progress-summary |
| 技能ID | 11869 |
| 技能类型 | 对话与工作汇报类 AI 技能 |
它解决什么问题
在真实开发工作中，最耗时的往往不是写代码，而是“说清楚”。站会要讲进度、交接要写说明、复盘要解释决策、回滚要追溯原因。常见的困境包括：
- 改动清单堆了一屏，但没人知道这些改动为什么必要；
- 隔了三天回看自己的工作，只记得“改了会话逻辑”，忘了当初踩的坑；
- 向非本模块的同事解释架构演进，讲十分钟对方还在问“所以原来错在哪”。
progress-summary 的切入点很明确：从动机出发，用对话式语言，按需配上图表，把一段工作史讲成一个有前因后果的故事。它明确反对“更新了 auth.ts、session.ts 和 upload.ts”这种文件清单式汇报，也反对“此增强利用了我们的现有基础设施”这类企业套话。
一键安装的思路与步骤
AI 技能的通用安装逻辑是：先确认宿主环境支持技能加载，再通过技能市场或技能入口添加，最后用一句典型提问验证是否生效。由于本技能详情未提供具体的安装命令、下载链接与价格信息，以下步骤以通用流程描述，具体命令、入口位置与计费方式请以官方说明为准。
- 确认前提：你的 AI 助手/开发工具需支持技能（Skill）机制，且已登录可用账号。
- 找到入口：在工具的技能市场、技能库或插件面板中搜索技能名
progress-summary或技能ID11869。 - 添加启用：按界面提示完成添加，部分环境会要求确认权限范围（例如是否允许读取仓库状态、Git 记录等上下文）。
- 验证生效：新建一个对话，直接问“可以总结一下吗”或“我们进展到哪里了”。如果返回的是一段动机先行、对话口吻的摘要，而不是干巴巴的改动列表，说明技能已正常加载。
- 补充上下文习惯：若你的工作依赖 Git，可在提问前让助手查看当前分支状态与最近提交，摘要质量会明显提升。
之所以强调“一键安装”的价值，在于这类技能属于低改造成本、高复用频率的能力：不需要重构工作流，只需在每次需要“讲清楚”的时刻把它叫出来。
该技能的主要功能和特点
- 动机先行的摘要结构：每份摘要都以“为什么”开头。技能给出的对照示例非常直白——好的开头是“我们一直在处理会话超时问题，该问题导致用户在上传中途被登出，根本原因是会话刷新只在导航时触发”，坏的开头是“我们在上传处理程序中添加了保持活跃调用”。读者必须先懂问题，再看方案。
- 暴露思考过程：鼓励写出“我们考虑过 X，但 Y 更合理，因为……”“最初尝试 A，结果发现了 B，于是走到 C”“棘手的地方在于怎么挂到现有流程上”这类决策轨迹，而不是只呈现最终结论。
- 对话式但精确的语气：像在咖啡间向同事解释那样写，直接、诚实。用“我们”表示协作工作，用“我”表示个人观察；说“这很痛苦”而不是“这带来了挑战”。
- 三种摘要粒度：
- 快速状态：2-4 句话，覆盖问题、发现、当前行动，适合“你在做什么”这类口头检查；
- 会话回顾：按“处理的问题 → 关键决策及原因 → 现在什么正常 → 还剩什么”四段式收尾；
- 架构概述：面向复杂变更，自由使用 ASCII 图表辅助说明。
- 四种图表范式：旅程/演化图（工作迭代过旧方案时）、层图（存在分层架构变更时）、流程图（数据或控制流跨组件移动时）、比较表（在多种方案间权衡时）。技能还附带了绘制用的框线字符集，并强调框边对齐、间距一致。
- 明确的负面清单：不列改动文件、不写企业套话、不用“变革性/革命性/无缝”这类营销词、不搞戏剧化夸张、不事事都用项目符号、不过度解释简单变更。
- 上下文采集指导：给出查看当前分支状态、最近提交、相对主分支差异的命令思路，并提示对 Conductor 工作空间可使用
GetWorkspaceDiff查看完整差异；同时提醒要阅读关键文件理解变更实质，而不只看差异统计。
和普通工具比强在哪：一般 Git 工具只会给你提交列表和 diff 统计，普通 AI 摘要往往也只是把 diff 翻译成人话。progress-summary 的差异在于它规范了叙事结构——先动机、再决策、后结果，必要时配图，本质上是在做“技术写作”而非“文本压缩”。
如何使用该技能？
第一步：用自然语言触发
这个技能靠“意图”触发，不依赖特殊命令。详情中列出的触发问法包括：“可以总结一下吗”“发生了什么”“我们做了什么”“情况如何”“我们进展到哪里了”“解释一下发生了什么”“给我一个概述”“已经做了什么”“告诉我这个”“带我了解发生了什么”，以及任何询问工作当前状态或变化的问题。
第二步：选择摘要粒度
根据场合自行指定，或让技能判断：
- 站会前：“用快速状态给我说一下现在在做什么。”
- 一天收尾：“总结我们这轮会话做了什么，用会话回顾的结构。”
- 交接文档：“解释一下这次状态管理改造，用架构概述，配演化图。”
第三步：提供必要的上下文
若环境可访问仓库，先让助手确认当前分支、最近若干条提交、相对主分支的差异范围；若不能访问，就手动粘贴关键信息：问题背景、尝试过的方案、最终选择、当前遗留。
第四步：检查输出是否合格
一份合格输出应满足三条自查：开头讲清“为什么”；中间至少有一处决策理由；结尾说明“现在什么能用、还剩什么”。若看到大段文件清单或空泛形容词，说明没走对路子，可直接要求“按 progress-summary 的风格重写，动机优先”。
输入输出示例
输入：
我们进展到哪里了？帮我总结一下这次会话。
输出（会话回顾风格示意）：
我们处理的是状态管理里嵌套响应性难以编写的问题。用户反馈手工 get/set 属性来构造深层响应式状态太繁琐。
探索了几种做法后，我们选了基于代理的响应性，因为它允许写地道的 JavaScript，同时在底层仍能拿到不可变带来的性能优势。
核心实现目前正常工作。仍需优化大型数组场景，并更新迁移指南。
第五步：按需索要图表
直接说“用一张演化图说明我们换方案的经过”或“用一个比较表说明两种实现的取舍”，比让它自由发挥更稳。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| progress-summary（进展摘要Skill） | 面向“工作叙述”的对话式摘要技能 | 动机优先叙事、三种摘要粒度、四类 ASCII 图表、负面清单约束 | 需宿主支持技能机制；触发方式为自然语言，几乎无学习成本 | 站会汇报、会话收尾、架构变更解释、交接文档 | 优势：叙事结构规范，输出可直接复用为 PR 描述；不足：不负责代码分析本身，依赖上下文供给质量 |
| 通用 AI 助手直接提问 | 无专门技能约束的通用对话 | 能总结对话、改写文本 | 零门槛 | 临时性、轻量总结 | 优势：随手可用；不足：容易滑向文件清单式、套话式输出，叙事结构不稳定 |
| Git 提交历史与差异统计工具 | 版本控制层面的客观记录 | 提交列表、diff、分支对比 | 需熟悉命令行或图形客户端 | 代码审计、变更追溯 | 优势：事实精确、可核查；不足：只有“改了什么”，没有“为什么”和“决策过程” |
| PR 模板 / 变更说明文档规范 | 流程与文档规范 | 强制填写背景、方案、测试说明 | 需团队约定并坚持执行 | 团队级协作流程 | 优势：制度化、可沉淀；不足：靠人写，写作负担重，质量参差 |
从对比可以看出，progress-summary 的位置在“客观记录”与“人工写作规范”之间：它把 PR 描述的写作方法论固化进 AI 技能，既保留了叙事的专业度，又把写作成本压到一句提问。
该技能的典型应用场景与实际体验情况
场景一：每日站会前的快速对齐（开发者）
痛点是站会只有两分钟，容易讲成流水账。使用方式是开会前问一句“快速状态”，拿到 2-4 句话的问题—发现—行动三段式，直接照着说。实际体验上，这类短摘要上手最快，几乎不需要额外提示词；注意事项是上下文要给足，否则“当前行动”容易写得含糊。
场景二：一天工作收尾的会话回顾（独立开发者 / 小团队）
痛点是隔天回看只剩模糊印象。使用方式是用会话回顾结构生成四段式总结，顺手存进笔记或提交说明里。实际体验上，价值在“关键决策及原因”这一段——它逼着把“当时为什么不用另一种方案”记下来，几周后回看收益明显。注意事项：如果当天尝试了大量失败路径，输出可能偏长，可要求只保留最终决策链。
场景三：架构改造的对外解释（技术负责人）
痛点是要向其他模块同事解释一次状态管理改造，纯文字讲不清演进脉络。使用方式是要求“架构概述 + 演化图”，把第一次尝试的存储开销问题、第二次尝试的改进与遗留问题、当前方案如何补齐，用三格流程图串起来。实际体验上，ASCII 图表在终端、代码评审、纯文本聊天里都能直接显示，不需要图片渲染，这点在工程环境里非常实用；注意事项是要检查框线是否对齐，字符错位会影响可读性。
场景四：多工作空间的差异梳理（使用 Conductor 等环境的团队）
痛点是同时推进多个工作空间，容易搞混各自改了什么。使用方式是借助 GetWorkspaceDiff 查看完整差异，再让技能按“问题—决策—现状”组织。实际体验上，先看差异统计再读关键文件，摘要的“实质感”会强很多；只喂统计数字时，输出容易浮于表面。
整体来看，这个技能上手难度低、效果稳定性取决于上下文质量。它不是替你思考，而是把你的思考按专业标准组织出来。
该技能能为用户带来的价值
- 把“汇报成本”降到一句话：以往写一段合格的进展说明要十来分钟，现在用一句“总结一下”即可获得可用的初稿，再花一两分钟微调即可发出。
- 降低沟通门槛：动机先行的结构天然照顾了不了解背景的读者，跨模块、跨职能沟通的返工率明显下降。
- 沉淀决策知识：强制记录“考虑过什么、为什么没选”，让团队知识从“结果”扩展到“推理过程”，这对新人接手和未来复盘的价值远超单次摘要本身。
- 统一表达标准：负面清单（不列文件、不写套话、不用营销词）实际上是一份轻量的技术写作规范，长期使用会反向改善团队整体的文档习惯。
- 纯文本可视化：ASCII 图表在任何纯文本环境可用，不需要图床、不需要渲染，适配代码评审、终端、聊天工具等全部场景。
- 长期价值：每次摘要都是一份可检索的工作档案。半年后回看“为什么当初放弃方案 A”，答案就在当时的摘要里。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：在支持技能机制的 AI 工具中，通过技能市场或技能库搜索 progress-summary 或技能ID 11869 添加启用即可，随后用“可以总结一下吗”验证是否生效。具体安装命令、入口位置与是否收费，以官方说明为准，本技能详情中未提供相关价格信息。
Q2：它和直接让 AI“总结一下”有什么区别？
A：区别在结构约束。普通总结容易变成改动清单或空泛概括；progress-summary 规定了动机优先的开头、决策过程的呈现、三种摘要粒度、四类图表范式，还有明确的负面清单（不列文件、不写套话、不用营销词），输出更接近一份专业 PR 描述。
Q3：适合谁用？不写代码的人能用吗？
A：核心用户是需要讲清工作进展的人：开发者、技术负责人、需要做交接和复盘的协作团队。只要你的工作是“有过程、有决策、需要向他人解释”的类型，即便不是写代码，也能用它的叙事结构；但涉及 Git 上下文采集的部分，对工程环境更友好。
Q4：为什么它总要我先讲“为什么”，我只想知道改了什么怎么办？
A：这是技能的刻意设计。只讲“改了什么”，读者无法判断改动是否合理，也无法在未来复用时理解约束条件。如果确实只需要极简信息，可以明确要求“用快速状态，2 句话，只讲问题和当前行动”，它仍会保留最小限度的动机交代。
Q5：和 Git 工具、PR 模板相比该怎么选？
A：三者不冲突。Git 工具提供事实（改了什么），PR 模板提供流程约束（必须写什么），progress-summary 提供表达方法（怎么写才讲得清）。实践中常见的组合是：用 Git 工具取上下文，用本技能生成初稿，再套进团队的 PR 模板。