1. superpowers 是什么我给 Codex CLI 装的这层技能包先给还没接触过的朋友一句话介绍superpowers 是一个开源插件项目作者在 GitHub 上的仓库名是 obra/superpowers它把技能、记忆、角色分工这三样东西打包接到 OpenAI 官方的 Codex CLI 和 Claude Code 这类终端 AI 助手上面。我这个月几乎每个工作日都在用最大的感受可以用一句话概括装上之前 Codex 像一个记性很差但很聪明的实习生装上之后像一个手里有标准作业流程的老师傅。先说痛点。Codex CLI 本身的能力不弱它能读你的仓库、跑编译、跑测试、改代码但它有两个天然短板。第一是没有跨会话记忆昨天定好的技术方案今天新开一个会话它完全不记得你得重新把背景讲一遍。第二是没有内建的工作流程你让它用 TDD 的方式实现一个功能它可能会先写实现再补测试甚至把测试和实现一次性全给你写完根本没经历红绿重构的过程。这两个问题在小 demo 上不明显一旦放到真实项目里效率差距就非常大了。superpowers 解决的就是这两件事。它把该怎么做一件事写成 markdown 技能文档agent 遇到对应任务时按需查阅、按步骤执行同时提供一套长期记忆机制把关键的技术决策、项目约定、个人偏好存成文本文件下次会话继续使用。它还带了一套角色体系可以在一个会话里让 agent 切换不同的身份来分工协作。这篇文章不是官方文档的翻译是我自己实际用了一个月之后的完整记录怎么装、怎么配、怎么在 Java 项目里跑通 TDD 流程、记忆系统怎么管、以及我踩过的几个坑。适合两类人看一类是已经在用 Codex CLI 但觉得它不够靠谱的开发者另一类是刚听说 superpowers 这个词、想搞清楚它到底能干什么的人。1.1 为什么技能包比多写几句提示词有效很多人第一反应是我不装插件直接在系统提示词里写你要遵循 TDD、要写记忆不就行了我一开始也是这么想的实际试下来发现差很远。提示词是一次性的、静态的。你写在配置里那几句话agent 每次会话都会看到但它不会因为你写了要遵循 TDD就真的去遵循。原因很简单上下文窗口里同时有很多指令提示词只是一句话没有任何操作细节agent 很容易把它当成用户偏好而不是必须执行的流程。技能文档则完全不同它是一份完整的操作手册包含具体的步骤、检查点、完成标准。当 agent 判定任务匹配某个技能时它会把整份手册读进上下文然后按步骤执行每完成一步还要自检。另一个关键差别在于可维护性。提示词是死的你改一次要重新加载配置技能是活的它是一堆独立的 markdown 文件你可以随时往技能库里加新的技能也可以让 agent 在实际执行过程中帮你完善某个技能文档。这就像你把团队的新人培训手册从一段口头叮嘱升级成了一份可以不断迭代的 SOP。1.2 技能、记忆、角色superpowers 的三个支柱拆开来看superpowers 做的事情其实不复杂就三块。第一块是技能库Skills也是核心。它的目录下按领域放了很多 markdown 文档比如测试驱动开发、调试排错、代码审查、写技术方案、做依赖升级等等。每个文档描述一个完整的工作流程agent 遇到对应场景就去查阅并按流程执行。技能库不是固定的你可以写自己的技能比如发布前检查清单数据库迁移流程相当于把团队规范变成了 agent 能自动执行的东西。第二块是记忆Memory。超级助手最烦人的一点就是每次会话都失忆superpowers 用纯文本文件把关键信息落盘。某个项目用了什么技术栈、你偏好的代码风格、已经拍板的技术决策都可以写进记忆文件。下次会话 agent 启动时先查记忆就能接上上次的话头。它不只是存你显式告诉它的东西还可以在会话结束时自动总结本次的结论写入记忆。第三块是角色Agents。它在一个人机对话会话里支持多种角色切换比如项目经理角色负责拆任务、开发角色负责写代码、调试角色负责排查问题。听起来很玄本质就是不同的角色对应不同的行为约束和上下文让 agent 在会话里分身完成各环节的工作。这三块叠加起来的效果是从一个会聊天的代码补全工具变成一个能独立推进任务的工程协作者。当然它不是万能的底层的 Codex 模型能力决定了天花板superpowers 做的是把天花板下面那部分流程纪律补上。2. 安装与初始化从零到能用的完整流程这部分写给还没装过的人。我装的时候踩了不少坑这里给出一条完整可复现的路径从环境准备到验证生效每一步都说清楚为什么这么做。2.1 环境准备先确认这几样东西在装 superpowers 之前我建议你先把基础环境理清楚缺任何一样后面都会出怪问题。首先是操作系统。superpowers 的安装脚本是 shell 脚本macOS 和 Linux 上最顺畅Windows 用户建议用 WSL2在 WSL 里装 Linux 发行版再操作比在 PowerShell 里硬折腾省心得多。我最初就是在 Windows 原生环境里试的结果光是路径分隔符和权限问题就耗了半天。然后是 Node.js。Codex CLI 本身是 npm 包需要 Node.js 环境建议 20 及以上版本。你可以在终端里执行node --version确认如果版本太老建议先升级否则后面装 Codex CLI 或者插件时经常出现莫名其妙的依赖问题。最后也是最重要的你必须已经有一个能正常使用的 Codex CLI。如果没有先执行下面的命令安装并登录npm install -g openai/codex codex --version codex logincodex login会走浏览器的 OAuth 流程登录成功后 Codex 才能调用模型。这一步完成标准是你在终端里敲codex随便问一句你好它能正常回复。基础环境到这一步就绪后面装 superpowers 才有意义——插件只是增强层底层 agent 必须本身能跑通。2.2 三步完成安装superpowers 的安装方式很直接就是克隆仓库然后跑安装脚本。我推荐的路径git clone https://github.com/obra/superpowers.git cd superpowers ./install.sh这里有个重要的选型问题clone 到哪个目录。很多教程直接让你 clone 到临时目录装完就把仓库删了结果过两天技能文件全丢了。我的建议是 clone 到一个固定位置比如~/superpowers或者~/.codex/superpowers让它长期待在那里。原因后面讲踩坑的时候会细说。安装脚本做的事情大致可以理解为三步。第一把插件的技能库、入口指令、辅助脚本复制到 Codex 的配置目录通常是~/.codex下面的某个子目录第二在你的 Codex 全局配置里追加一段入口说明让 agent 每次启动都知道自己有一份技能库和记忆库可以使用第三创建记忆目录和初始文件。整个过程中如果遇到Permission denied之类的权限报错先给脚本加执行权限再重新跑chmod x install.sh ./install.sh2.3 装完怎么确认真的生效了装完不等于生效很多人的问题恰恰出在以为自己装好了。我的验证习惯是三步走。第一步看配置。打开~/.codex/config.toml正常情况下应该能看到和 superpowers 相关的引用可能是一段说明文字也可能是指向某个文件的路径。如果你完全看不到 superpowers 相关的内容说明安装脚本没有正确修改配置需要重新跑。第二步开一个新会话直接问。在终端里运行codex开一个新会话然后问它你当前加载了哪些技能请把你知道的 superpowers 技能列出来。如果它一脸茫然甚至说不知道 superpowers 是什么那说明入口指令没有生效多半是配置没加载。这里有个细节一定要开新会话旧的会话上下文里没有新的配置。第三步验证记忆目录。执行ls看一下~/.codex下面有没有生成 superpowers 相关的目录结构里面应该有记忆文件。如果目录结构都不存在说明安装脚本执行不完整回到上一步重新检查。这三步全过才算真正装好了。我见过不少人在第一步就发现配置根本没被改还以为是自己的问题——其实就是安装脚本某个环节静默失败了这种情况下面有专门的排查章节。3. 配置机制拆解技能为什么是按需加载而不是全塞进上下文理解了安装流程还得理解它的工作机制否则你遇到问题根本不知道从哪下手。这一节我把 superpowers 的配置和加载逻辑拆开讲清楚。3.1 技能文件长什么样技能的本质是一个 markdown 文档通常放在技能库的 skills 目录下每个技能一个子目录。我打开过几个技能文件看结构基本是文件开头有一段元信息写清楚技能叫什么、在什么场景下使用、触发关键词是什么正文是操作步骤每一步都有明确的动作和完成标准。以 TDD 技能为例它写的不是你要写测试这种空话而是一步一步的流程先根据需求写出一个会失败的测试用例运行测试确认它在预期的地方失败红灯阶段写最小实现代码让测试通过再次运行全部测试确认没有破坏其他功能绿灯阶段最后在测试保护下做重构。每一步都有检查点比如如果测试没有先失败就通过了那么说明测试写错了需要回头检查断言。这个格式本身就是有用设计的核心。agent 读技能文档时它不是在读一句口号而是在读一份可以被检查的操作清单。它能按步骤执行还能自我检查是否跳步。这是普通提示词完全做不到的。3.2 按需加载为什么上下文不会被撑爆很多人担心如果技能库里有几十个技能每个文档还那么长Codex 的上下文窗口装得下吗这正是 superpowers 设计上最巧妙的地方——它不会把所有技能一次性塞进上下文。实际的加载机制是分层的。每次会话启动时agent 只读取一个入口索引这个索引比较短大致写着你有一个技能库当遇到 XX 类型任务时去查技能目录下的技能列表找到匹配的技能文档再阅读。当你的任务进来了比如你说帮我写一个测试agent 先看技能列表发现测试驱动开发这个技能与任务匹配于是它调用读文件能力打开对应技能文档把完整流程读进上下文然后才动手。这个先索引再按需展开的机制让它能维护一个大技能库而不影响日常对话的上下文占用。我自己的经验是技能越多越好只要描述写得清晰agent 就能准确匹配不会出现技能太多导致对话变笨的情况。反过来如果你把几十个技能全写进一个文件里让 agent 每次启动都读上下文很快就不够用了对话质量会明显下降。3.3 记忆是怎么读写和落盘的记忆机制的实现同样很朴素就是一堆 markdown 文件放在记忆目录里。目录通常按项目或按主题分成多个文件比如memory/spring-boot-project.md、memory/个人偏好.md这种粒度。读取时机是会话开始。入口指令会提示 agent 先查看记忆目录了解这个项目的背景和已经做过的决策再开始干活。这就是它能接上上次话头的原因。写入时机主要是两类一类是你明确告诉它记住这条约定agent 会把内容追加到对应记忆文件另一类是会话结束时agent 总结本次的关键决策写进记忆里。这个机制的关键在于规则要写清楚。我刚开始用的时候agent 经常不主动写记忆后来我在会话里加了一条固定指令每次会话结束前把本次做出的技术决策和原因写入记忆文件。从那以后就稳定多了。你不需要懂代码只需要理解一个原则记忆文件是给 agent 看的项目维基你对它写什么它下次就记得什么。3.4 入口指令生效的底层逻辑入口指令到底是怎么让 agent 遵守的说白了就是配置文件里那一段说明让 Codex 每次启动时都读到它。它相当于给 agent 设定了一个初始上下文你是谁、你有哪些工具、遇到什么情况该怎么做。这个机制和 AGENTS.md 很像但更进一层。AGENTS.md 是项目级的静态说明告诉 agent这个项目是什么样的superpowers 的入口指令是动态的它不仅描述现状还定义了 agent 的行为方式——去哪里找技能、去哪里查记忆、什么时候写记忆。打个比方AGENTS.md 是公司的规章制度海报superpowers 是给新人配的导师手册后者告诉你遇到具体事情该找谁、按什么流程办。理解这一层之后遇到配置没生效之类的问题你就知道排查方向了先看入口指令有没有被 agent 读到再看技能有没有正确匹配而不是像无头苍蝇一样乱试。4. 实战用 TDD 技能在 Java 项目里开发一个计算器光讲概念没用直接上实战。这一节我用一个完整的 Java Maven 项目演示 superpowers 的 TDD 技能怎么约束 agent同时对比一下有技能和没技能的行为差异。4.1 为什么用 Java 举例而不是 Python我查了最近的热搜词发现很多人搜superpowers java说明大家最关心的是这工具在 Java 这种重型项目里到底好不好用。我特意选 Java有三个原因。第一Java 项目的步骤链路长先有 Maven 或 Gradle 构建再有编译、测试、打包多个环节任何一个环节出问题都会让整个流程卡住。这种项目最需要流程纪律也最能体现技能的价值。第二Java 的编译器很严格agent 想蒙混过关很难代码有问题直接编译失败瞒不过去。第三Python 项目里 agent 的自由度大很多时候跳步了也不报错Java 项目里你要是跳了先写测试这一步直接就露馅了。所以拿 Java 演示说服力最强。4.2 五分钟准备一个可运行的 Maven 项目先创建项目骨架。用 Maven 的 archetype 生成一个最简的 Java 项目mvn archetype:generate \ -DgroupIdcom.example \ -DartifactIdcalc \ -DarchetypeArtifactIdmaven-archetype-quickstart \ -DinteractiveModefalse cd calc接着在pom.xml里加上 JUnit 5 依赖否则 agent 写测试的时候会因为没有测试框架而卡住。我把加入依赖单独拿出来说是因为这个细节特别容易忽略你要是没提前配好测试框架agent 可能会自己上网搜依赖并写进 pom.xml这样也不是不行但一来耗时二来容易引入版本冲突。提前配好让它专注于业务逻辑dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.2/version scopetest/scope /dependency配好后跑一次mvn test确认项目本身是健康的。这一步很重要它建立了初始状态正常的基线后面 agent 改乱了代码你马上能分辨出来。4.3 在会话里让 agent 按 TDD 技能干活项目就绪后开一个 Codex 会话工作目录切到calc下然后输入这样的指令这是一个 Maven Java 项目。请使用你掌握的 TDD 技能为 Calculator 类实现一个整除方法 divide(int a, int b)要求两个整数相除返回 int除数为零时抛出 IllegalArgumentException。接下来重点观察它的行为序列这是判断技能是否真正生效的关键。我的实测里agent 的行为是这样的先是静默片刻它应该是在技能库里找到了 TDD 技能文档并读取了流程然后它没有直接写实现而是先创建了CalculatorTest.java写了三个测试用例正数相除、整除结果、除数为零抛异常写完测试后它主动执行了mvn test验证测试处于失败状态——这一步通常会有编译失败因为Calculator类还不存在但这正是红灯阶段应该有的状态。看到测试失败后它才开始创建Calculator.java写了最简单的实现。再跑一次mvn test这次测试通过了。最后它没有立刻收工而是停下来问我测试覆盖了异常场景和正常场景是否需要补充边界用例整个过程就是标准的 Red-Green-Refactor我没有额外催促它自己就按流程走完了。这个结果让我挺惊讶的因为就在前一周同一个项目、没有 superpowers 的时候我给 Codex 下了几乎一样的指令它直接噼里啪啦把Calculator.java和CalculatorTest.java一次写完然后告诉我完成。表面上效率很高但仔细观察它的测试没什么边界意识而且它完全没有先跑一次失败的测试来验证测试本身是有效的——这意味着它写的测试到底能不能测出问题它自己也不知道。4.4 有技能和没技能的对比我把两轮实验的行为列成了一张表差异一目了然。行为环节没有 TDD 技能有 TDD 技能先写实现还是先写测试同步写实现和测试先写测试是否主动运行失败的测试基本不运行主动运行并确认红实现代码的克制程度会顺手写很多扩展功能只写满足测试的最小实现是否主动做重构不一定流程内建了重构检查测试质量用例零散常缺边界覆盖典型场景和异常注意我并不是说没技能时 Codex 永远做不好它有时候也会写得挺好。但没有流程约束的时候它的行为是不可预期的这次很好下次可能就把异常处理丢了。技能的作用是把高质量行为变成稳定复现的默认行为这才是它最重要的价值。4.5 实测中的几个注意事项第一首次运行mvn test时 Maven 需要下载大量依赖可能卡几十秒甚至更久agent 有时候会误以为命令卡死而中断操作。我建议在进入会话前先手动跑一次mvn test把依赖缓存好可以省掉很多麻烦。第二agent 执行命令需要权限。Codex CLI 默认会请求你授权运行命令你在会话里尽快给它授权否则它跑测试的过程会反复被打断。如果公司电脑有严格的执行策略建议先在企业环境里评估好权限方案再引入这个工具。第三技能不是一次加载永远有效。如果你发现 agent 开始跳流程了通常是因为会话上下文被其他内容冲掉了技能文档的注意力。这时候最简单的做法是重新提一句请回顾你加载的 TDD 技能按照它的流程继续。这一句话往往就能把它拉回正轨。5. 跨会话记忆让 Codex 过一夜还记得你的技术决策如果说技能是 superpowers 的工作方式那么记忆就是它的大脑存储。这一节我讲一个真实的隔夜实验以及我在使用记忆功能过程中总结出来的一套方法。5.1 一个真实的隔夜实验我手头有个 Spring Boot 项目对象转换一直用的手写工具类。有一天我让 Codex 帮我评估要不要引入 MapStruct它在会话里分析了依赖注入、性能、可维护性几个维度最后建议引入 MapStruct还把理由写在了对话里。会话结束时我补了一句把这次的技术决策和理由写入记忆文件。第二天新开一个会话我故意没有提供任何背景直接问它这个项目的对象转换方案定了吗它沉默了一下然后回答根据之前的决策本项目使用 MapStruct 替代手写转换器理由是统一类型转换逻辑、减少样板代码、提升可维护性。当前迁移状态记录在项目的迁移计划中。那一刻确实有点震撼——它真的记得昨天的事情。作为对比我在另一个没有记忆功能的环境里做过同样的实验第一天明确告诉 Codex 一个技术约定第二天新会话里问它它完全想不起来重新把代码读了一遍又给了一套新的建议甚至和昨天的结论相反。这个对比很好地说明了记忆功能为什么重要AI 的聪明程度在一个会话内是稳定的但跨会话的能力完全取决于有没有持久化机制。5.2 我总结出的记忆使用三板斧第一板斧会话结束前固定让它总结并写入记忆。我几乎每次会话结束都会说请把本次会话的关键决策、原因、以及尚未完成的事项写入记忆文件。这句话的效果立竿见影它会把散落在对话里的信息结构化地落到 markdown 文件里。你不需要知道它具体写了什么下次会话它能回答出来就是有效。第二板斧项目开始时让它先查记忆再看代码。开新会话的第一条指令我通常会写先查看记忆目录了解这个项目的背景和技术决策再开始分析。这样它就不会一上来就闷头读全部代码而是带着记忆里的上下文去匹配代码效率高很多。这里要注意你要确认它真的去查了记忆文件而不是随口答应。可以追问一句你刚才查到了哪些和本项目相关的记忆确认它确实执行了。第三板斧重要的约束要明确说记住两个字。普通对话里说的话agent 不一定认为需要写入记忆但如果你说记住这条约束本项目的数据库迁移脚本必须由人工执行它就会把这条约束写入记忆文件并且后续会话都会遵守。这相当于给 AI 一个显式的写盘指令。5.3 记忆文件膨胀了怎么办记忆机制用久了必然面临一个问题文件越来越大agent 每次会话都要读大量历史反而拖慢分析速度。我遇到过一次agent 在会话开始时读了一个 3000 多行的记忆文件结果光理解上下文就花了很长时间而且有些历史决策已经过时误导了当前任务。我的建议是三条。第一按项目分文件不要一个全局文件装所有内容每类主题一个文件让 agent 能精确读取。第二只记决策和约束不记过程。agent 不需要记住我昨天花了三小时排查了一个问题这个过程它只需要记住最终决定使用方案 A这个结论。第三定期手动清理把过时决策标记为已废弃或者干脆删掉。我大概是每两周清理一次把已经落地的决策归档只留下仍然有效的约束。还有一个教训别把敏感信息写进记忆文件。因为记忆文件是纯文本存放在本地如果里面有数据库密码、API Key 之类的机密一旦泄露就是事故。把这里当成开发笔记本来对待只记工程决策不记密钥凭据。6. 踩坑记录安装和使用的四类问题排查链路工具再精巧也是软件我用下来遇到不少问题。这一节我不直接给答案按照我实际排查的顺序来写因为学会排查思路比记住答案更有用。6.1 报错一安装脚本报 Permission denied我第一次运行./install.sh就报错了提示权限不够。很多人都遇到这个问题因为仓库拉下来的文件默认没有执行权限。解决很简单chmod x install.sh ./install.sh这个坑本身不难但它带出了一个更大的坑如果安装脚本在某个步骤静默失败你是看不到明确报错的。所以装完一定要回到前面说的三步验证那里检查配置和目录结构确认真的生效了。权限问题只是最表面的一层下面往往还藏着别的问题。6.2 报错二配置改写了但 agent 不认识 superpowers这是最让人困惑的一类问题安装脚本正常完成config.toml里也能看到 superpowers 的内容但新会话里问 agent它一脸茫然。我的排查链路是这样的。第一步确认 Codex CLI 版本。codex --version看看版本号如果版本比较旧可能不支持配置里的某些字段。这就像你给一个老系统加了新配置项它不认识自然不生效。解决方法是升级npm install -g openai/codexlatest升级后重新开一个会话再问一次。第二步确认入口指令在会话里真的被读到了。你可以直接问 agent你的系统级指令里有哪些请复述其中关于技能的部分。如果它复述不出来说明入口指令根本没加载原因多半是配置文件解析失败或者缓存问题。这时候可以删掉会话记录缓存重新开一个干净会话。第三步如果还不行干脆把config.toml里 superpowers 相关的段落截图记下来然后删掉重新跑一遍安装脚本让它重新写入。很多时候重装比手动修改配置更干净。6.3 报错三技能文档路径不对agent 找不到技能有一次我把 superpowers 仓库 clone 到了/tmp/superpowers这个临时目录安装跑完一切正常。过了两天系统清理临时目录仓库被删了然后 agent 就再也找不到技能了。排查了半天才发现入口指令里写的技能路径指向的还是那个临时目录。这个坑的教训是路径在安装时就被写死进了配置所以安装前就要选好固定目录。我的经验是 clone 到~/.codex/superpowers让它和配置在一起。如果你想改位置改完之后需要重新跑安装脚本让入口指令里的路径同步更新。不要手动去改路径字符串容易漏改。6.4 报错四记忆文件被读爆agent 反而变笨了这个属于使用层面的问题记忆文件越写越多agent 启动时读的上下文越来越大表现得越来越啰嗦但越来越不聪明。我一度以为是模型变笨了后来排查发现是记忆文件太乱。排查思路是这样先看记忆目录下有哪些文件按修改时间和大小排个序找出那些上千行的老文件然后打开看内容发现里面既有有效决策也有大量过时的过程记录。解决方法是把记忆文件拆分、精简只留下有效的约束和决策过时的内容要么删除要么标记为已废弃。清理完再开新会话agent 明显清醒了很多。这个问题的根源在于记忆功能本身不会帮你判断什么该记、什么不该记它只会照单全收。所以记忆内容的卫生需要你自己维护这是使用任何记忆型 AI 工具都必须付出的维护成本。6.5 通用排查思路遇到问题先分清层级最后总结一套通用的排查链路无论遇到什么问题按这个顺序走基本都能定位。先分清楚是哪个层面出了问题是安装层面脚本没跑完、配置没写入、加载层面配置写了但 agent 没读到、还是执行层面agent 读了但没按流程做。安装层面的问题看目录结构和配置文件加载层面的问题在会话里直接追问 agent执行层面的问题给它一句请回顾技能流程通常就能纠正。第二步是检查版本。不管是 Codex CLI 还是 superpowers 本身都是快速迭代的项目版本不匹配是最常见的问题源头。安装前看一眼作者仓库的 README确认当前推荐的最低版本。第三步是最小复现。不要在一个复杂的项目里排错建一个空目录放一个最简单的文件重新跑流程。这样能把变量压缩到最少很多问题在最小环境下会变得极其明显。这套思路不仅能用在 superpowers 上排查任何 AI 编程工具的问题都适用。7. 最后说点我的个人体会写到最后我不想做什么宏大总结就说几句实际的感受。这个工具最适合的人不是那些只拿 AI 写点小脚本的开发者而是需要在真实项目里稳定交付的人——尤其是 Java、Go 这类工程约束强的领域。它解决的核心问题不是让 AI 更聪明而是让 AI 更守规矩。聪明的模型很多但愿意按流程一步一步走、不跳步、不自作主张的模型靠的是流程把这个行为约束出来。我的建议是别一上来就把官网示例抄一遍先挑一个你日常最痛的点比如每次让 AI 改代码都不跑测试然后写一个只有三五步的技能文档让 agent 严格执行。从一个点开始比全面铺开更容易坚持。等这个流程稳定了再把团队规范、发布清单这些逐步沉淀成技能慢慢你就有了一份可以复用的团队 AI 操作手册。还有一个我自己的习惯每周挑一个下午把本周和 agent 协作的会话记录过一遍看看哪些流程经常被打断、哪些指令需要反复说。这些观察就是最好的新技能素材。工具迭代很快但把经验沉淀成流程这件事什么时候都不会过时。