一个常见陷阱：规定的是解决方案，而非问题

有一种失败模式值得单独拎出来说，因为它实在太容易掉进去了。当你坐下来写规格时，诱惑在于去描述你脑中已经想好的那个解决方案——"一个带标签页的侧边栏""一个弹出来的模态框""一张 Postgres 表"。但一份满是解决方案的规格，会悄悄锁定一些你还没资格去做的决定。

对比这两行：

差:  添加一个左侧边栏，每个书籍状态有可折叠的分区。
好:  让我能按状态分组查看书籍，又不丢失完整列表。

第一句已经选定了一个侧边栏、可折叠的分区，以及一种布局——而这一切都在还没人确认它们是不是正确的选择之前。第二句陈述的是要完成的活，让 AI（以及你）有自由去找到能满足它的最简单方案，而那也许只是三个筛选按钮。描述你想要的结果；让实现尽可能长久地保持可商量。解决方案在规格里改起来很便宜，在代码里改起来却很昂贵。