技能介绍

解决什么问题

在企业内部做产品时，需求往往散落在聊天记录、会议纪要和原型截图里。一个完整的功能点，可能同时夹带了“为什么要做”“给谁用”“本期做到哪一步”“页面和流程怎么走”“字段规则与状态怎么定义”“后续怎么验收”六类信息。如果这些信息没有被显式整理，评审时会出现各说各话：业务关心目标，设计关心流程，研发关心边界。到了开发阶段，再回头补规则和状态，往往意味着返工。
这个技能要解决的就是这件事：把零散输入整理成业务、设计、研发都能看懂的材料，而不是把内容写得更大。

它如何工作

它的核心能力围绕几个固定环节展开：

需求理解：先提炼背景、用户、目标、范围和约束。如果信息不足，最多先问 1 到 3 个关键问题，例如“这个功能主要给谁用”“这期必须上线的最小能力是什么”“有没有已经确定不能做的内容”。
产品方案：当上下文足够时，直接按结构输出：产品目标、用户角色、核心流程、页面范围、字段和规则、权限和状态、数据指标、非本期范围、待确认问题。如果用户只要一句话或简短回复，就不展开完整方案。
字段设计：细化表单、列表、筛选项或配置项时，用表格输出 字段、类型、必填、说明、示例，并覆盖用户填写什么、系统自动生成什么、哪些字段必填、哪些需要校验、哪些影响后续流程。
流程设计：描述每一步时，写清楚谁操作、做什么、系统有什么反馈、成功后进入什么状态、失败时怎么处理。
状态设计：状态不混在一起，优先拆成 生命周期状态（如草稿、待审核、已发布）、运行状态（如正常、异常）、可见性状态（如私有、公开），并说明状态含义、进入条件、可执行操作和下一个可能状态。
埋点设计：不只写“统计次数”，而是输出指标、触发时机、去重规则、排除场景和用途，例如“有效浏览”需说明进入详情页、同一用户同一对象每日计 1 次、排除后台预览与创建者自查。

适用边界与注意点

它有几类明确不做的事。第一，没有依据时不承诺推荐算法、自动审核、智能治理等高级能力。第二，不把一期能力描述成完整闭环，也不把管理后台、用户前台、开发者后台混成一个视角。第三，不只写页面，不写规则和状态；不只写“支持管理”，要说明管理什么。输出风格上，它用中文、先给结论再给细节、尽量用短句，避免“智能化赋能”“全面提升体验”这类空泛词。遇到不确定的地方，它会标注 待确认，而不是编造。