需求都带真实反馈的出处
每条需求都能追溯到某个用户说过的话——反馈、社区讨论、支持工单。背后没有人的那条，会被标成"假设"，而不是被包装成"需求"。
ClawBot 团队成员 · 产品专员
产品专员写的需求文档里，每条需求都指向某个真实用户真的说过的话——一张工单、一个社区帖、一段反馈。当它找不到任何人提过某个功能时，它会直接说出来，而不是用一套很有产品感的措辞把它写进去。
一次迭代 = 一个能发布的切片。每份文档都带"不做什么"那一节——范围总是从你没点名的缝里长出来的。
它像一个"留得下证据"的产品经理。
每条需求都能追溯到某个用户说过的话——反馈、社区讨论、支持工单。背后没有人的那条，会被标成"假设"，而不是被包装成"需求"。
它砍得很狠。一份在一次迭代里发不出去的文档会被拆开，并且告诉你砍掉了什么、为什么，而不是丢给你一份没人做得完的东西。
每份 PRD 都要写清楚这次刻意不做什么。范围蔓延大多是在这一节被拦下来的，所以它不是可选的。
新反馈进来它就更新版本。编程专员在开发中遇到含糊的地方，它回答，并把这个决定写回文档里——PRD 不会不声不响地变成小说。
从一堆杂乱的反馈，到编程专员真能照着做的东西。
一个产品想法，加上你手上任何真实的用户输入——聊天记录、工单、讨论帖、访谈笔记。乱一点没关系，比整齐但编出来的强。
你两者都有用，但不是一回事，而文档出问题往往就是因为这两样被糊在一起。用户真说过的进证据，你推断出来的进假设，并且明确标出来。
它带出处的需求、"不做什么"那一节，以及一份明确的"这次砍掉、等下次"的清单。
不同意它怎么砍，就跟它争——在这里争，比开发到第三周再争便宜得多。
它编程专员提出澄清问题，它来回答并更新文档。开发途中新来的反馈会被并进版本里，而不是丢掉。
它给证据，拿文档。
正是这些限制让产出保持诚实。
没人提过的功能，它会直说。你当然还是可以做——很多好产品就是从创始人的判断开始的——但它会被标成假设，而不是证据。
狠切范围意味着你会被告知"你说的一次迭代其实是三次"。这就是它的价值所在，也是最招人烦的地方。
它负责文档，不负责实现。和编程专员配着用——在同一个对话里 @ 上他们俩，他们之间会互相交接。
十个用户说"做得更好点"，出来的文档就是"十个用户希望它更好"。证据的质量，是文档质量的天花板。
每个团队成员一份订阅，各自带自己的每月积分。
含每月 1,500 积分，用于撰写文档、维护版本、以及回答开发期间的问题。可以先免费试用。
团队成员需要在付费的 ClawBot 套餐之上雇佣。一份基础套餐覆盖你雇的所有团队成员。
不用，它单独也能用，很多人就是拿它出一份切好范围的文档，然后交给自己的团队。
两个一起用才有意思：文档的主人在开发中随时回答实现方的问题，文档也就一直和真正做出来的东西保持一致。
那文档里大部分内容会被标成假设——这恰好如实反映了你现在的处境。可以配合增长专员，先去把证据拿回来。
能。贴进去，问它"哪些需求没有依据"或者"一周内要发布该砍什么"。这通常是最快看清它怎么想的方式。
新反馈和开发中的决定进来时，它会更新版本。它被设计成一份活文档，而不是写完第二天就过期的文件。