synthetic-users

synthetic-users — 诊断 + 脚本 v2

工作流的第四站。它用合成角色测试 ux-research 制作的指南——这些角色是带有明确特征的模拟用户——之后才开始第一分钟的真实实地调研。通用领域示例：B2B 预约管理应用可以模拟一位小型诊所的管理员，以及一位曾尝试过类似工具但已弃用的怀疑者。

何时调用

何时	从 / 到
ux-research 的研究计划已有 v1 版指南	从 ux-research 进入（.agents/skills/ux-research/SKILL.md）
诊断 + 脚本 v2 已完成	退出：真实实地调研——对真实用户进行访谈，由操作者接手开展；这不是此工具包中的技能
真实实地调研之后	insight-engine（.agents/skills/insight-engine/SKILL.md）对原始回答进行归纳，然后工作流进入由 prd 编写的战略层（.agents/skills/prd/SKILL.md）

第一条规则

这无法验证任何事情。 会话以这句话开场，并在结束时再次重申：合成角色的任何回答都不能作为某项功能对真实用户有效的证据。它只有一个目的——在投入实地调研时间之前找出指南中的缺陷——除此之外别无用途。无论在文中重复这条规则多少次，只要诊断读起来像是验证了假设，就说明写得不好。

合成角色

创建每个角色时，都会采用 .agents/skills/grill/SKILL.md#method 中的压力测试方法——引用路径，绝不复制——逐一审视每项拟议特征的来源，再决定是否将其纳入角色档案。

每个模拟角色的特征都要标明明确来源，并逐项注明：

标记	来源
(evidence)	针对该细分群体已开展的真实研究——一次访谈、一项使用数据，或 Discovery Brief、Market Brief 中提供的信息
(public data: )	描述该细分群体所属人群的公开数据集，需注明名称和链接
(assumption)	没有研究或公开数据支持的设定

没有标记的特征不得纳入角色档案。

将某项特征标为假设之前，先从公开数据中查找依据。 要查找的目录包括 Kaggle（kaggle.com/datasets）、Hugging Face（huggingface.co/datasets）和 Google Dataset Search（datasetsearch.research.google.com）。如果某个数据集涵盖这项特征，则标记为 (public data: <source>)；如果没有，就保留为 (assumption)。

绝不能把公开数据标记为证据。 公开数据集描述的是一般人群，而不是本产品的细分群体：若将其算作证据，就会让合成角色显得比实际更经验证。

至少设置一位怀疑者，并说明理由：曾尝试过类似工具但已弃用的人、有业务层面顾虑的人（如成本或流程变更），或者根本没有假设所提出的问题的人。只会确认假设的一组角色无法帮助发现缺陷：他们只适合确认假设。

每个模拟回答都要指出所依据的特征，并标出该特征的来源：“我不会用它，我已经在用 Jira（依据：每天使用 Jira，public data）”。无论特征的标记是什么，回答本身始终是虚构的。注明特征能说明哪些回答有依据、哪些纯属设定，也能帮助区分是问题本身有缺陷，还是角色构建得不好。

不能只有“我喜欢！”而不提代价。 合成角色的每个热情回答都必须同时说明代价或阻力：这对他们有什么成本、让他们担心什么，或者他们必须停止做什么。只有热情的回答说明这份指南是为了确认而写，而不是为了学习。

问题缺陷分类

v1 脚本中的每个问题都会根据此列表进行审查；发现的缺陷会连同改写后的问题一并记录在旁边，而不只是指出缺陷：

缺陷	示例	改写
引导性问题（暗示答案）	“你不觉得自动提醒会很有用吗？”	“今天你如何避免错过预约？”
假设性问题（“你会使用……吗？”）	“你会使用能自动重新安排预约的功能吗？”	“说说你上次不得不重新安排预约的经历。”
双重问题	“这个仪表板是否清晰且易于使用？”	拆分为两个问题，每个问题只询问一个属性
没有行为依据的问题	“你总体上怎么看预约管理？”	“你上次为团队管理预约是什么时候？”
该细分群体不会使用的行话	产品团队内部的技术术语	采用该细分群体使用的词语，取自先前的研究

诊断 + 脚本 v2

最后，将交付成果写成针对已加载产品节点的带日期研究文件，保存在：

research/<YYYY-MM-DD>-script-diagnosis.md

带日期，且绝不覆盖。该路径属于大脑自身 tree.md 中的 content: */products/*/research/*.md 行：无需新增 glob，也无需添加 resolver 行。如果没有产品节点，这个同名文件——<YYYY-MM-DD>-script-diagnosis.md——则会保存到当前文件夹中。

诊断包含以下四个部分，按此顺序排列，每部分都使用其原样标题：

## Synthetic personas
## Simulation
## Defects found and rewrites
## Script v2

• 合成人物画像：每份画像都要标明其特征属于 (evidence)、(public data: <source>) 或 (assumption)，并指出持怀疑态度的人物画像。
• 模拟：针对 v1 脚本模拟的回答，每条回答都要指出其依据的特征；每种热情表现旁边都要标明其代价。
• 发现的缺陷及改写：列出分类中出现的每个缺陷，并附上改写后的问题。
• 脚本 v2：修正后的访谈指南，可直接用于实际调研。

脚本 v2 部分开头和结尾都要完整写出第一条规则：“这不能验证任何内容”——分别放在第一个问题之前和最后一个问题之后。

此交付成果不作何种保证

诊断 + 脚本 v2 不能取代实际调研：它的作用是减少第一场真实访谈中会遇到的有缺陷脚本。综合实际调研得出的内容——从访谈记录中提炼发现——不属于这项技能的工作：这由 insight-engine 负责。

目标位置

此技能会先确定目标位置，再生成交付成果，绝不会事后才确定。有三种情况， 两个目标位置：

• 已加载产品节点：交付成果写入该节点的 research/<YYYY-MM-DD>-<name>.md。
• 有 brain，但没有产品节点——尚无工作区，或工作区中没有产品节点：交付成果写入当前文件夹中的文件。
• 完全没有 brain：交付成果写入当前文件夹中的文件。

没有产品节点时，文件仍会写入当前文件夹。结束消息只写出刚刚写入的路径，然后结束——这是此技能的正常结束方式，并非需要特别说明的异常情况。

此技能绝不会询问要使用哪个目标位置，也绝不会自行编造第三个目标位置。

其余技能包会逐个安装技能。先查看 .agents/skills/，再查看 .claude/skills/（同一技能同时存在于两处时只算一次），仅提供尚未安装的技能——每个会话只提供一次：在该会话中，此技能首次结束时提供，此后无论同一交付成果还是其他交付成果再次结束，都不再提供：

• grill — npx skills add pedroromeroluna/ai-first-product-skills --skill grill
• insight-engine — npx skills add pedroromeroluna/ai-first-product-skills --skill insight-engine
• prd — npx skills add pedroromeroluna/ai-first-product-skills --skill prd
• ux-research — npx skills add pedroromeroluna/ai-first-product-skills --skill ux-research

一次安装整个技能包：npx skills add pedroromeroluna/ai-first-product-skills。此命令会安装技能包提供的内容；以上列出的任何技能都需要通过指定名称来安装。