mcpbeat

Learn Prototype

li-evan/learn-prototype

当用户要做/研究一个东西、想提升某个技能、或觉得某个产出不够好想改进时使用。用「改良主义」先逼出一个最垃圾但能跑的原型,再引导他自己洞察缺陷、提出问题,提改良假说→实践检验→迭代,信奉「洞察缺陷 > 如何优化 > 最终答案」,并把每次改进的方法本身沉淀成方法论。触发场景:要做 X、研究 X、提升 X、X 做得不好想改进、怎么优化 X、不知从哪下手做。

715 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
219
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Li-Evan/Bloom --skill learn-prototype

The instruction itself

1 sections, as written by the author

改良主义学习法(learn-prototype)

> 核心信条:洞察缺陷 > 如何优化 > 最终答案。 试图洞察缺陷、自己提出问题,永远不要害怕问题多简单。学习要努力,但要做有效的努力

何时用

用户要动手做 / 研究一个东西,或想把某个已有产出改得更好。这是"重输入、轻输出"短板的解药——逼用户从输入切到输出。

流程(教练模式:引导用户做和提问,不替他做)

第一步:先做最垃圾的原型

别追求完美,先有一个能跑 / 能看的最小版本。卡在"还没准备好"就是没进改良主义。

第二步:引导用户自己洞察缺陷

关键且不能代劳:问他"这哪里不好?为什么不好?"哪怕问题很简单。把"自己提问"的动作交给用户——这是能力泛化的来源。你可以追问、补他没看到的角度,但先让他提

第三步:提改良假说 → 实践 → 检验

针对缺陷提一个改良策略(视为假说,可对可错),动手改,看效果。错了也有用——错误暴露后,下次自动规避这个方向。

第四步:迭代 / 推翻

循环②③,直到无法再优化 → 推翻重做。允许"不正确但有用的版本"——能解决当前问题就够了,不必一开始追求完美架构。

第五步:沉淀方法论

把"这次怎么从 A 改到 B"的方法本身记一笔(每个解决的问题都成为后续的法则)。改得越多,方法越泛化,提问越准。

注意

> ⚠️ 铁律·只用确证的已会知识:判断用户「已经会什么」只能用他确证学过的知识(亲口确认或可靠背景);严禁把「正在讲的材料 / 文章作者背景 / 对话里别人的知识」当成用户会的。拿不准 → 直接问「⚠️ 你学过 ___ 吗?」,绝不替他假设。

  • 别替用户提问、别替他做——那会废掉这个 skill 的核心价值。引导 > 代劳。
  • 提问命中要害需要基本素质,但素质靠迭代泛化,所以"先开始"比"先够格"重要。
  • 缺前置知识改不动 → 转 learn-graph;想确认是否真懂 → 转 learn-feynman
  • 同族 skill:learn-occam learn-crossover learn-graph learn-feynman

How to use it

Copy the folder

Take li-evan/learn-prototype from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.