learn

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Learn from this session. Extract what went well, what went wrong, and update documentation so future sessions are better. Also give direct feedback on how the user can work with Claude more efficiently.

从本次会话中学习。提取进展顺利的内容、出现问题的内容，更新文档以便后续会话体验更优。同时给出直接反馈，说明用户如何才能更高效地与Claude协作。

Instructions

操作说明

Parse $ARGUMENTS for optional focus area (e.g.,

mistakes

efficiency

workflow

). If empty, do a full review.

解析$ARGUMENTS获取可选的聚焦领域（例如

mistakes

、

efficiency

、

workflow

）。如果为空则执行完整复盘。

Step 0: Efficiency Audit (Elon's 5-Step Framework)

步骤0：效率审计（马斯克5步框架）

Before anything else, audit the work done in this session against each step in order:

1. Make requirements less dumb

Were any requirements stated as facts that were actually assumptions? Who said this had to be done this way?
Did requirements come from someone who isn't going to be accountable for the outcome?
Flag any requirement that, in hindsight, was dumb, wrong, or unnecessary.

2. Delete the part/process

What steps, outputs, or artifacts could have been eliminated entirely without losing value?
Was anything produced that won't be used? Any process run "because we always do"?
If you can't defend why something stayed, it should have been cut.

3. Simplify or optimize the design

After deleting, what was still too complex?
Were there cleaner paths to the same result? What added steps that didn't add value?

4. Accelerate cycle time

Where did the session slow down? Waiting on tool results, iteration loops, back-and-forth?
What would have made this 2x faster?

5. Automate

What was done manually in this session that should be automated? (a skill, an n8n workflow, a memory update)
Only after steps 1-4 — don't automate a dumb process.

Output this as a brief, opinionated table:

Step	Finding	Verdict
Requirements	{what was dumb or necessary}	Cut / Keep
Deletions	{what could have been removed}	Should have cut
Simplify	{what was over-engineered}	Simplify next time
Speed	{where it slowed}	Fix: {suggestion}
Automate	{what to automate}	Skill / Sub-Agent / n8n / Memory

在开展其他工作前，按照顺序对照每一步审计本次会话完成的工作：

1. 降低需求的不合理性

是否有被当作事实陈述的需求实际上只是假设？是谁规定必须按这种方式完成？
需求是否来自无需为结果负责的人员？
标记所有事后看来不合理、错误或不必要的需求。

2. 删除冗余环节/流程

哪些步骤、产出或工件可以完全删除且不会损失价值？
是否产出了不会被使用的内容？是否有“我们一直这么做”所以执行的流程？
如果你无法说明留存某项内容的理由，那它本来就应该被砍掉。

3. 简化或优化设计

删除冗余内容后，剩下的部分还有哪些过于复杂？
是否有更简洁的路径可以达成相同结果？哪些新增步骤没有带来价值？

4. 缩短周期时间

本次会话在哪个环节速度变慢？等待工具返回结果、迭代循环、来回沟通？
做什么可以让本次会话速度提升一倍？

5. 自动化

本次会话中哪些手动完成的工作应该自动化？（skill、n8n工作流、memory更新）
仅在完成步骤1-4后执行该步——不要自动化不合理的流程。

将上述内容整理为简洁、有明确判断的表格输出：

步骤	发现	结论
需求	{不合理或必要的内容}	砍掉/保留
删除项	{本可以移除的内容}	本应砍掉
简化	{过度设计的内容}	下次简化
速度	拖慢进度的环节	修复方案：{建议}
自动化	需要自动化的内容	Skill/子Agent/n8n/Memory

Step 1: Session Audit

步骤1：会话审计

Review the current conversation and identify:

What went wrong:

Errors, dead ends, retries, or wasted steps
Misunderstandings between user and Claude (unclear prompts, wrong assumptions)
Tools that failed or returned unexpected results
Approaches that were abandoned partway through

What went well:

Efficient patterns (good use of parallel agents, clear prompts, smart sequencing)
Decisions that saved time or tokens
Workflows that should be repeated

What was learned:

New facts about systems, data, processes, or tools
Corrections to previous assumptions
Patterns that should be codified

Summarize this back concisely before proceeding.

回顾当前对话，识别以下内容：

问题点：

错误、死胡同、重试或浪费的步骤
用户与Claude之间的误解（提示词不清晰、错误假设）
工具运行失败或返回意外结果
中途放弃的方案

亮点：

高效模式（合理使用并行Agent、清晰的提示词、智能的步骤排序）
节省时间或token的决策
应该复用的工作流

收获：

关于系统、数据、流程或工具的新事实
对之前假设的修正
应该固化的模式

在继续下一步前先简明扼要地总结上述内容。

Step 2: Documentation Updates — Skill vs. Memory Decision

步骤2：文档更新——Skill与Memory的选择规则

For every insight from the session audit, classify it:

Update a SKILL when:

A workflow was used and produced the wrong output or took extra steps
A missing instruction caused Claude to go off-track during a skill execution
A new edge case was discovered that a skill should handle
A skill was invoked but the description didn't match (triggering issue)

Update MEMORY when:

A new fact was learned about a system, tool, or data source
A preference or convention was established that applies broadly
A correction to a previous assumption (not tied to a specific skill)

Create a NEW SKILL when:

You did something manually that took 3+ steps and will happen again
You caught yourself giving Claude the same multi-step instruction twice
A workflow emerged during the session that has a clear trigger and output

Create a SUB-AGENT when:

A task is parallelizable — multiple independent workstreams that can run simultaneously
A task is long-running and would flood the main context window with intermediate results
A task requires autonomous tool use across many steps without needing user input mid-way
The work is isolated enough that a fresh context (no session history) is an advantage, not a liability

Skill vs. Sub-Agent decision rule: If the work has a consistent trigger + prompt template → Skill. If the work requires autonomous execution + tool calls + parallelism → Sub-Agent. Many workflows need both: a Skill that launches a Sub-Agent.

Update CLAUDE.md when:

A new "always do X" or "never do Y" rule was discovered
A workspace routing rule changed
A new MCP integration was added

For each proposed change, display:

Change	Target	Type	Why
{description}	{file path}	Skill edit / Memory / New skill / CLAUDE.md	{what happened}

Do NOT write any changes until the user approves. Ask: "Want me to apply all of these, some of them, or none?"

针对会话审计得到的每一个洞察，进行分类：

需要更新SKILL的场景：

使用某工作流时产出了错误结果或消耗了额外步骤
缺失的指引导致Claude在执行skill时偏离轨道
发现了skill应该处理的新边缘 case
调用了skill但描述与实际功能不匹配（触发问题）

需要更新MEMORY的场景：

了解到关于系统、工具或数据源的新事实
确定了通用的偏好或约定
对之前的假设做出修正（与特定skill无关）

需要创建新SKILL的场景：

你手动完成了需要3步以上的操作，且该操作未来会重复出现
你发现自己两次给Claude下达相同的多步骤指令
会话过程中出现了有明确触发条件和产出的工作流

需要创建SUB-AGENT的场景：

任务可并行化——存在多个可以同时运行的独立工作流
任务运行时间长，会产生大量中间结果占满主上下文窗口
任务需要跨多步自主调用工具，中途无需用户输入
工作内容足够独立，使用全新上下文（无会话历史）是优势而非劣势

**Skill与Sub-Agent的判断规则：**如果工作有固定的触发条件+提示词模板 → 选择Skill。如果工作需要自主执行+工具调用+并行能力 → 选择Sub-Agent。很多工作流需要同时用到两者：由Skill来启动Sub-Agent。

需要更新CLAUDE.md的场景：

发现了新的“始终做X”或“绝不做Y”规则
工作区路由规则发生变更
新增了MCP集成

针对每一项 proposed change，按如下格式展示：

变更内容	目标文件	类型	原因
{变更描述}	{文件路径}	Skill编辑/Memory/新Skill/CLAUDE.md	{触发变更的事件}

在用户批准前不要执行任何变更。 询问用户：“是否需要我应用全部、部分变更，还是不应用？”

Step 3: Feedback for the User

步骤3：给用户的反馈

Give direct, specific feedback on how the user can work with Claude more efficiently. Be honest — this is a coaching moment, not a compliment session.

Structure:

markdown

undefined

给出直接、具体的反馈，说明用户如何能更高效地与Claude协作。请坦诚沟通——这是指导环节，不是赞美环节。

结构如下：

markdown

undefined

How to Get More Out of Claude

如何更好地使用Claude

Token Efficiency

Token效率

{Were prompts unnecessarily long? Could context have been set once instead of repeated? Were there unnecessary back-and-forth cycles that a clearer initial prompt would have avoided?}

{提示词是否不必要地过长？上下文是否可以只设置一次而非重复提及？是否存在可以通过更清晰的初始提示词避免的不必要来回沟通？}

Prompt Patterns

提示词模式

{What worked: e.g., "When you gave me the exact format you wanted, I nailed it first try."} {What to try: e.g., "Next time you need X, try prompting with Y — it'll save a round trip."}

{有效的做法：例如“当你给出想要的 exact 格式时，我第一次就生成了符合要求的内容。”} {可以尝试的做法：例如“下次你需要X时，可以尝试用Y作为提示词——能省去一轮沟通。”}

Workflow Suggestions

工作流建议

{Could more work have been parallelized? Were there manual steps that could be skills? Did the user do something Claude should have done, or vice versa?}

{是否可以将更多工作并行处理？是否有可以封装为skill的手动步骤？是否存在用户做了本该由Claude完成的工作，或者反过来的情况？}

One Thing to Try Next Time

下次可以尝试的一件事

{The single highest-leverage change to how we work together.}


Be specific to THIS session. Reference actual moments. Don't give generic productivity advice.

{能最大程度提升我们协作效率的一项改动。}


反馈要贴合**本次会话**的实际情况，引用真实发生的场景，不要给出通用的生产力建议。

Step 4: Apply Approved Changes

步骤4：应用已批准的变更

After the user approves (all, some, or none):

Write the approved memory files
Edit the approved skill files
Update CLAUDE.md if approved
Confirm what was updated

在用户批准后（全部、部分或不批准）：

写入已批准的memory文件
编辑已批准的skill文件
如果获批则更新CLAUDE.md
确认已更新的内容

Step 5: AI Growth Prompt

步骤5：AI成长提示

Based on the session context, choose ONE of the following — pick whichever is more relevant:

Option A — Study Prompt (use when the session touched AI tools, models, workflows, or concepts that could go deeper):

Identify the most relevant AI concept from this session and suggest a specific resource to read. Format:

markdown

undefined

根据会话上下文，选择以下更相关的一个选项：

选项A——学习提示（当会话涉及可以深入了解的AI工具、模型、工作流或概念时使用）：

识别本次会话中最相关的AI概念，推荐具体的阅读资源。格式如下：

markdown

undefined

Learn Something

学习拓展

This session touched [concept]. Go deeper:

Read: [specific doc, post, or paper — link if you know it, otherwise describe exactly what to search for] Why it matters for your work: [one sentence connecting it to courses, revenue, or automation] What to look for: [the specific thing to extract from the read — a pattern, a technique, a mental model]


Use sources from: Anthropic docs (prompt engineering, tool use, agents), AI thought leaders (Andrej Karpathy, Simon Willison, Ethan Mollick, Lenny Rachitsky on AI), or recent AI news (if a specific model, tool, or capability was used that has notable coverage).

**Option B — Evaluation Question** (use when the session was mostly execution work — building, writing, analyzing):

Ask one hard question to evaluate whether the work was actually the right work. Choose from or riff on:

```markdown

本次会话涉及[概念]。可以深入了解：

阅读材料： [具体的文档、文章或论文——如果知道链接就附上，否则明确说明要搜索的内容] 对工作的价值： [一句话说明该内容和课程、营收或自动化的关联] 关注重点： [要从阅读材料中提取的具体内容——某种模式、某项技术、某个思维模型]


可使用的来源：Anthropic文档（提示词工程、工具使用、Agents）、AI领域意见领袖（Andrej Karpathy、Simon Willison、Ethan Mollick、Lenny Rachitsky关于AI的内容）或近期AI新闻（如果会话使用了有广泛报道的特定模型、工具或能力）。

**选项B——评估问题**（当会话主要是执行类工作——搭建、写作、分析时使用）：

提出一个尖锐的问题，评估本次做的工作是否真的有价值。从以下问题中选择或改编：

```markdown

Honest Eval

坦诚评估

[One of these, adapted to what actually happened:]

Was any of this necessary? What would have happened if you hadn't done it?
What's the single most questionable decision made in this session, and who challenged it?
If you had to cut 40% of the output and keep only the most valuable, what survives?
Did you solve the real problem, or the problem as originally stated?
What assumption drove this session that you never actually validated?


Pick Option A only when the session genuinely introduced a new AI concept, capability, or tool that the user hadn't encountered before and could go deeper on. If the session used familiar AI tools in routine ways — even if it was a "capability" session — default to Option B. When in doubt, pick Option B.

[从以下问题中选择适配本次实际情况的一个：]

这些内容有必要做吗？如果你没做会发生什么？
本次会话中最值得质疑的决策是什么？谁对该决策提出了挑战？
如果你必须砍掉40%的产出，只保留最有价值的部分，哪些内容会留下来？
你解决的是真正的问题，还是最开始陈述的那个问题？
推动本次会话开展的哪个假设是你从未实际验证过的？


只有当本次会话确实引入了用户从未接触过、可以深入了解的新AI概念、能力或工具时才选择选项A。如果会话只是用熟悉的AI工具完成常规工作——哪怕是“能力相关”的会话——默认选择选项B。不确定的时候就选选项B。

Notes

注意事项

This skill is most valuable after long or complex sessions where things didn't go smoothly
The documentation updates are the durable output — they compound across future sessions
Be honest in the feedback section. The user explicitly asked for this. Don't soften it.
If the session went perfectly and there's nothing to learn, say so — don't manufacture feedback
Never update documentation without showing the user first and getting approval
When updating memory files, follow the memory system format (frontmatter with name, description, type)

该skill在进展不顺畅的长会话或复杂会话后使用价值最高
文档更新是可复用的长期产出——会在未来的会话中持续产生价值
反馈部分请坦诚表述，这是用户明确要求的，不必软化措辞
如果会话进展非常顺利，没有可学习的内容，直接说明即可——不要编造反馈
永远不要在未向用户展示并获得批准的情况下更新文档
更新memory文件时，请遵循memory系统的格式（包含name、description、type的前置元数据）