learn-prototype

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

改良主义学习法（learn-prototype）

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

何时用

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

流程（教练模式：引导用户做和提问，不替他做）

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

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

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

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

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

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

第四步：迭代 / 推翻

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

第五步：沉淀方法论

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

注意

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

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