research-product

# 渐进式产品研究 目标不是完成一份产品报告，而是让 Agent 在真实执行中逐步认识产品。每次只研究当前任务需要的部分，并更新能够跨轮次复用的稳定认知。 ## 证据层级 按以下顺序区分，不得混写： 1. **已观察事实**：代码、配置、路由、界面、公开页面、真实数据或用户明确陈述直接支持。 2. **暂定解释**：多条事实共同支持，但仍需要使用或市场证据验证。 3. **工作假设**：为了推进当前 loop 提出的可能用户、问题、场景或价值，必须写明验证方式。 4. **未知**：没有证据时保留“未知”，不为了填满 SOUL 而补齐。 代码通常只能直接证明产品形态、组成和可见能力。不得从“存在某功能”直接推断“用户最需要它”“它解决了某个核心问题”或“这是产品差异化”。 ## 每次执行 1. 读取现有 `SOUL.md` 和当前 Model 的相关 Memory，确定这次真正缺少哪一小块产品认知。 2. 定位产品载体：当前/相邻本地仓库、用户指定路径、原型、线上 URL 或用户描述。 3. 只读检查与问题直接相关的代码、文档、路由、配置和页面，不进行无目标的全仓扫描。 4. 需要验证可见行为时，让调用方 Model 使用 [screenshot-assets](../../executors/screenshot-assets/SKILL.md) 获取真实页面证据；截图和本次研究记录进入该 Model 的 Memory。 5. 列出“新增事实 / 被修正事实 / 新假设 / 仍未知”，每项附来源路径、URL、截图或用户陈述。 6. 按 [SOUL 增量写入协议](references/soul-update.md) 修改 `SOUL.md`。只更新本轮有新证据的字段，不重写整份文件。 7. 将带时间的检查过程、证据清单和下一步验证动作写入调用方 Model 的 `memory/<model-name>/products/<product-slug>/`。 ## 写入边界 - `SOUL.md`：产品的稳定认知、明确假设、关键未知和证据链接。 - Model Memory：本轮检查过程、截图、页面状态、临时分析、冲突证据和后续验证任务。 - 产品仓库：产品实现本身；除非用户要求修改，不因研究而写入。 - Collector：只维护研究方法，不保存某个产品的事实。 发现冲突时保留旧说法和新证据，先降级为“待验证”，不要静默覆盖。用户明确纠正产品事实时，记录为用户陈述，并在能验证时补上产品证据。 ## 交付 报告本轮实际研究了什么、SOUL 哪些行发生变化、哪些结论仍只是工作假设、证据保存在哪里，以及下一次应在什么真实行动中验证。不要宣称已经“完整理解产品”。