轻量需求转飞书文档

需求交付中的常见坑

很多团队把需求评审变成接口文档评审。产品经理被迫写完整的 PRD，甚至被要求提供数据库设计、API 契约和测试计划。这不仅越俎代庖，还会让业务决策被技术实现细节淹没。另一方面，缺乏真实页面证据的需求文档往往是在“猜”——前端交互、权限边界、空状态和异常流程全靠脑补。

技能如何运作

product-requirement-delivery 技能将重心拉回到业务本身。它接收一张轻量级的 intake card，通过以下步骤生成可审计的飞书文档：

• 审计输入与真实探测：提取需求名称、目标用户和已知规则，不要求用户补全长篇 PRD。技能会直接接管浏览器，实地探测每个相关页面的字段、状态、导航与权限，捕获 Observed、User stated、Recommended 和 Unverified 四类证据。
• 构建需求基线：生成本地 -需求基线-vX.X.md 文件，定义角色权限边界（ROLE-*）、用户故事（US-*）、正常与异常规则（REQ-*, EX-*）以及验收标准（AC-*）。所有验收标准必须与业务规则严格映射。
• 拦截模糊与确认：在发布前，技能会审计所有模糊词汇（如“按需”、“适当处理”），强制转化为客观条件。随后挂起，等待产品经理对未决业务决策进行显式确认。
• 发布与回读校验：确认后冻结基线，将内容渲染为飞书文档，上传原始截图与标注，最后通过回读机制验证文档结构、URL 和截图完整性。

适用边界与注意点

• 只做业务交付：该技能严格限制在业务需求层面。除非用户额外要求，它不会生成开发包、测试包、接口规范或数据库设计。
• 证据真实性：如果某个页面或状态不可访问，技能会将其标记为 Unverified 并要求定义业务行为，绝不编造 UI 或替换接口。
• 浏览器依赖：实测页面依赖用户本地的 Chrome 登录态和浏览器控制权限，登录状态失效会导致页面证据降级。