需求文档助手

解决什么问题

需求文档最常见的失败不是写得不够长，而是写完后没人能判断“什么时候算完成”。做一个某功能 被当成共识，但目标与方案、事实与假设、范围与愿望这三对边界始终没被切开。本技能不扩写篇幅，而是逐条钉住边界，让各角色用同一套口径验收。典型场景：新功能立项、旧流程改造、缺陷转需求、跨系统联动、上线前补验收口径。

它如何工作

按固定顺序推进：

• 先固定问题：按“谁—情境—限制—无法完成什么—影响”描述；用户给方案时先反推问题，原方案降级为候选。
• 定义成功与不成功：写明观察方式、统计口径、时间窗口和最低可接受变化，并列出不可牺牲的条件（错误率、人工审核、隐私边界）。
• 建立角色与场景：区分直接使用者、被影响者、审批者和系统操作者，覆盖触发条件、前置状态与失败去向。
• 划清三层范围：本次必须、明确不做、后续候选；对 支持、智能、实时 等含糊词追问可测定义。
• 写规则与状态：先列业务对象及状态，再写谁能在什么条件下把状态从哪里变到哪里，覆盖冲突、空值、超时、撤销和重试。
• 补齐数据与权限：关键字段说明来源、必填性、格式、默认值与保留期限；权限按角色、资源、动作和条件描述。
• 形成可执行验收：每条场景含前置条件、动作、可见结果和证据位置，覆盖拒绝路径、边界值与并发恢复。
• 做影响与发布检查：接口、存储、历史数据、通知、报表、客服和回滚，把一次性交付与长期运营责任分开。
• 拆成可追踪任务：按可独立验收的行为切分，关联需求编号、依赖和回归范围。

输出用稳定编号（如 OBJ-01、AC-07），保证任务能回指需求、核心需求都有验收。

适用边界

• 不虚构用户调研、业务数据、法规结论或技术约束。
• 不替决策人默认批准范围、预算和上线日期，不把界面草图当作完整业务规则。
• 没有验证证据时，不承诺实现一定满足性能或安全要求。
• 不自动修改生产系统、项目计划或外部任务。

变更不靠阻止来管理：先比较目标是否变化，再评估规则、数据与回归范围，最后由明确的决策人确认。