复杂一点的活，我开场第一句不是需求，是先立规矩。大概这么约定：
- 先别输出。让它把我这段需求里所有含糊的地方在心里过一遍，不用列给我看。
- 每轮只问一个问题，而且是它觉得眼下最关键的那个。这条最要紧，问题一次堆满屏就没人愿意答了，跟做需求评审一模一样，一口气抛一堆，最后哪个都落不了地。
- 问到它自己有把握为止，然后把理解到的需求复述一遍给我确认。
- 我确认了，它才动笔。
听着绕，其实一般三五个问题就到位。对比以前的做法：直接让它写，写完发现理解偏了，改一版、再改一版，来回五版，时间全耗在返工上。前面多花几轮问答，换的是后面不用推倒重来，算下来快太多。
要它复述，是因为问完不代表懂对了，复述出来我才看得见它理解的版本，偏了当场纠正最省事。
也不是每次都走全套。急的时候我直接打一句“不用问了，写”，它就跳过盘问。我自己的体感是，这套在写方案、做技术选型上收益最大，这类需求本身就有很多我没说清、它也不该乱猜的地方；写条短文案就没必要上这么重的流程，规矩比活还长。
