把 AI 当成一位客户，让它写一份贴合你水平的需求说明，配上里程碑和可验证的成功标准，但绝不给代码。
在 Kodokon 中打开本课一旦你越过了基础阶段，教程就不再推动你前进了：它们让你沿着标记好的路径抄写解决方案。真正推动一名合格开发者前进的，是那种略高于自己水平的项目——难到足以逼你做决策，又有框架到不至于陷进泥潭。问题在于：给自己校准几乎不可能，你要么挑得太简单，要么挑得太雄心勃勃。AI 恰恰擅长这种校准，前提是你给它正确的角色。错误的做法：“帮我写一个记账应用”——你拿到成品，技能为零。正确的做法：让 AI 扮演写需求说明的客户；开发者是你。
你是一位项目客户（产品负责人）。你写需求说明，你**绝不**写代码。
我的情况：我经常练习 [语言/技术]。我已经掌握：[诚实的清单]。我想提升：[有针对性的概念，例如：异步错误处理、测试、拆分成模块]。
可用时间：大约 [X] 小时，分摊在 [周期] 内。
请为一个迷你项目写一份需求说明：
- 需求最多 5 行，用真实客户的口吻表述（说清楚**要什么**，绝不说**怎么做**）。
- 3 到 5 个有序的里程碑，每个都以一个可运行、可演示的成果收尾。
- 每个里程碑：**可观察**的成功标准（“命令 X 显示 Y”“情形 Z 被以一条清晰的信息拒绝”——而不是“代码干净”）。
- 一项技术约束，迫使我用到那些有针对性的概念。
- 如果我提前完成，给 2 个可选的扩展。
禁令：不给代码片段，不指定函数名或库名，不给实现提示。实现是我的活。校准依赖两项只有你才掌握的信息：你已经会什么（要诚实，否则项目会太简单）和你想练什么（一两个概念，不是六个）。里程碑把项目变成一个反馈回路：每一步都交付一个可演示的行为，从而避免你陷入去修建一座架构大教堂的泥潭。至于可观察的成功标准，它们改变了一切：“代码干净”无从验证，“导入一个损坏的文件时显示一条明确的错误而不崩溃”十秒钟就能验证。不可观察的标准是一种观点；可观察的标准是一次验收测试。
你是以下这个项目的客户：[复述需求说明，或粘贴当前的里程碑]。
我认为我已经完成了里程碑 [X]。从用户的角度看，我的程序做了这些事：[描述可观察的行为，而不是代码]。
1. 逐条过一遍该里程碑的成功标准：向我提出精确的问题，以核实它是否真正达成，包括边界情形（空输入、超出范围的取值、重复执行两次的操作）。
2. 如果某条标准未达成，指出是哪一条、怎么回事，但不要告诉我如何修复。
3. 如果全部通过，说出下一个里程碑——同样不给代码或实现提示。这套验证仪式再现了真实项目的验收测试：客户不读你的代码，他们拷问的是行为。关于边界情形的那些问题才是有价值的部分——正是在那里，你发现自己的实现没有处理什么。接下来还有任何单人项目都逃不掉的关键时刻：卡住。翻脸改口“帮我把这部分写了”的诱惑此时达到顶峰。用一套梯度提示的规程来抵抗它：每一级多说一点，而你只消耗刚好能让自己重新动起来的那一级。
我在我的项目 [背景] 上卡住了。卡点是：[你想做什么、你试过什么、在哪里出了问题]。
请给我**梯度**提示，一次只给一级：
- 提示 1：大方向的线索——一个要重温的概念，或一个方向，用一句话说。
- 提示 2（仅在我要求时）：更精确一些——我这套思路里哪一部分要重新考虑。
- 提示 3（仅在我要求时）：解决方案的原理，用大白话讲清楚，不给代码。
从提示 1 开始，然后等我回复。绝不跳级，哪怕我不耐烦或者一再坚持。