Perplexity API 的竞品监控，核心不是“自动生成一份竞品报告”，而是把联网检索、证据留存、变化判断和行动提醒连接成闭环。对一人公司而言，最小可行方案应围绕少量竞品运行：先选择 3—5 个直接竞争者，再补充一个低价替代方案或客户可能自行使用的通用工具，避免信息噪音超过决策价值。

先定义监控信号

每个竞品至少建立三类固定查询任务：产品与公司更新、价格与套餐变化、用户反馈。查询必须固定问题、时间范围和输出格式，并要求返回事件日期、变化摘要、影响、来源 URL 和证据强度。对于价格，尤其要区分“当前页面显示什么”和“相比上次快照发生了什么”。第一次采集只能标记为“首次采集”，不能直接判断涨价或降价。

用户反馈应被视为趋势线索，而不是市场统计。单条匿名评论只能进入低可信度观察区；只有多个可靠来源反复指向同一问题，才适合触发产品、报价或销售话术调整。若同时观察 Perplexity 对不同用户问题的推荐结果，也应记录查询日期和完整问题，因为这只能反映本次查询中的可见度，不能代表市场份额。

用 API 固化采集流程

自动化流程可以拆成“读取竞品清单—提交查询—保存原始结果—结构化解析—快照比较—发送提醒”。数据表至少保留竞品、监控类型、采集时间、摘要、变化类型、旧值、新值、影响等级、证据等级、来源 URL、行动建议和处理状态。不要只保存模型摘要，还要保存完整提示词、原始返回内容和人工确认结论，便于追溯误判来自检索、归纳还是判断。

接入 Perplexity API 时，接口地址、模型名称和参数应以当前官方开发者文档为准。API 密钥放在环境变量或密钥管理服务中，不要写进代码；同时设置超时、失败重试、状态记录和每日查询上限。接口失败不能被误判为“未发现变化”。

真正有价值的是快照比较，而不是日报数量。价格应按套餐名称比较价格、计费周期和限制条件；页面结构变化但没有明确价格证据时，只标记为“页面变化，需人工核实”。提醒也应分级：明确价格变化或直接重叠功能立即提醒，单一来源更新进入每日汇总，无法核验的传闻放入周报。

最终看板只需保留今日变化、价格快照、反馈主题和待处理行动。每条情报都必须对应“更新定价页、修改演示、联系客户或继续观察”等动作；无法改变决策的信息，不应长期占据主区域。