persona-docs

Persona Docs 是一款专注于产品用户研究的文档生成技能，旨在帮助产品团队在项目启动初期建立清晰的目标用户定义。通过结构化的模板和指导流程，该技能引导用户完成从目标用户画像定义、痛点分析到用户旅程映射的完整文档创建过程，确保产品决策始终围绕真实用户需求展开。

核心用法上，该技能通过分析现有代码库或产品描述，结合交互式提问（如"谁是主要用户"、"解决什么痛点"等），生成包含六大核心组件的标准化文档：目标用户画像、需求痛点、发现路径、入职流程、用户旅程图以及功能接触点。用户可通过 OpenClaw/Moltbot 等平台的 npx 命令安装使用，支持单文件或多文件模式存储于 docs/PERSONA.md 或 docs/personas/ 目录。

显著优点在于其强制性的以用户为中心的设计思维。该技能强调"在产品编码前先定义用户"，通过具体的质量标准和"NEVER Do"清单（如禁止仅描述人口统计特征、禁止创建超过3个初始画像等）避免常见陷阱。文档结构注重可操作性，要求描述足够具体以使团队成员形成一致理解，同时保持迭代灵活性，建议每季度回顾更新。

潜在局限性包括其 T3 来源属性（个人开发者社区项目）带来的权威性相对不足，以及作为文档模板工具无法替代真实的用户访谈和数据验证。此外，技能依赖用户自行提供准确的产品背景信息，若输入偏差可能导致生成的用户画像脱离实际。对于复杂的多角色产品，需要手动处理角色冲突和优先级排序，自动化程度有限。

该技能特别适合产品经理、UX 研究员、初创公司创始人和新加入团队的成员使用。对于处于项目启动阶段缺乏明确方向的产品团队，或需要统一团队对目标用户认知的场景尤为 valuable。也适用于规划重大功能前的需求验证，以及新成员快速理解产品定位的入职培训。

使用风险方面，主要需注意该技能为纯文档工具，生成的用户画像仅为假设性框架，必须结合实际用户反馈验证。长期不更新会导致文档失效甚至产生误导。此外，虽然安装命令涉及 npx 和 shell 操作，但均为用户手动执行示例，无自动执行风险。建议在使用前审查模板内容，确保符合实际产品定位。

核心用法

persona-docs 是一款纯文档类的 Skill，专为产品经理、UX 设计师和开发团队设计，用于系统化创建和维护用户画像文档。其核心流程包括：分析现有代码库中的用户线索→通过澄清性问题确定目标用户→从最小可行文档开始迭代完善。文档结构涵盖六大核心组件：目标用户画像（含角色、技术背景、使用场景）、用户需求与痛点分析、产品发现路径、用户引导流程、用户旅程地图以及功能触点映射。

显著优点

方法论严谨：基于用户中心设计（UCD）原则，强调" personas 应该是任何产品的第一份文档"，从源头避免功能堆砌。模板提供具体的质量对比示例（如"Backend engineers at mid-size SaaS companies" vs "Developers"），大幅降低文档撰写门槛。

场景覆盖全面：覆盖产品全生命周期关键节点——项目启动、受众转型、团队对齐、功能规划、新人 onboarding，具有强实操性。

迭代友好：明确反对"一次性完美文档"，倡导从最小可行版本开始、季度复盘更新，符合敏捷开发理念。

多角色产品支持：提供主次 persona 优先级策略和冲突处理指南，解决复杂产品的用户定位难题。

潜在缺点与局限性

依赖团队执行力：文档质量高度依赖团队是否真正投入用户研究；若缺乏实际数据支撑，易沦为"纸上 personas"。

初创团队 overhead：对于极早期 MVP 验证阶段，完整 personas 文档可能显得过重，作者建议的"最小可行版本"仍需一定投入。

无自动化集成：作为纯 Markdown Skill，不提供与用户分析工具（如 Mixpanel、Amplitude）的数据打通，需手动更新。

适合人群

• 产品经理和 UX 研究员，需系统化输出用户洞察
• 技术负责人启动新项目，需对齐团队对目标用户的认知
• 开源项目维护者，需明确贡献者和使用者画像
• 设计系统或开发者工具团队，用户为其他开发者

常规风险

认知风险：团队可能将 personas 视为"写完即完成"的静态文档，忽视季度复盘要求，导致决策基于过时假设。

过度简化风险：严格限制初始 personas 不超过 3 个的准则，虽有助于聚焦，但可能在特定场景下遗漏关键用户群体。

来源可信度：Skill 来自个人开发者（T3 级别），虽经 S+ 安全认证，但长期维护稳定性需社区验证。