从调研到 PRD：一个产品决策是如何被正确推进的

产品决策从来不是灵感迸发的瞬间，而是信息收集、结构化分析、风险识别之后的必然结果。今天团队围绕 PrompterHub 做的事，是一个标准的产品推进流程在真实环境中的运转样本。

竞品调研：信息不对称是最大的风险

阿龙完成了对竞品 PrompterHub 的全站功能拆解——工作台、社区、模板库、大模型教程、用户体系、浏览器插件，每个模块的交互逻辑、数据规模、商业路径都有详细记录。这份调研的价值不在于"发现了什么"，而在于消除了决策时的信息不对称。

竞品有 16,000+ 条社区 UGC、500 个精选模板、完整的 Chrome 插件——规模上我们暂时无法比肩。但核心差异被识别清楚了：竞品是「用户输入粗想法 → AI 直接优化」，我们是「4 问引导式结构化 → AI 精准生成」。

这条差异线值得坚守。引导式的本质是降低用户的认知门槛——用户不需要知道提示词应该写什么，只需要回答 4 个问题。这个定位对 AI 新手友好，而竞品的用户画像更偏向已有使用经验的人群。跟随竞品做社区化、插件化，是放弃自身优势去打一场已经输掉的仗。

五大功能方向：PRD 不是文档，是对齐工具

基于调研，谷子整理了五大功能方向：工作台重构（图片提示词模式、Remix、历史记录）、首页重做、大模型教程页、用户体系、浏览器插件。小锦据此完成了 PRD 初稿。

PRD 的核心价值不是把功能描述清楚，而是把待决策事项显式化。这份 PRD 列出了 5 个需要阿锦拍板的决策点，其中最关键的是 F4 用户体系的技术路线：方案 A 保持纯静态 HTML 嵌入 Supabase SDK，方案 B 迁移到 Next.js 全栈架构。

建议选方案 A。不是因为它更好，而是因为当前阶段验证比完美更重要。用户体系的价值要等有真实用户收藏了提示词之后才能被验证，在那之前投入大量资源做框架迁移是过度工程化。等有了用户规模，迁 B 的决策会更有依据。

建议开发顺序：F2 首页 → F3 教程页 → F1 工作台 → F4 用户体系 → F5 插件。前三项纯静态，无后端依赖，约 1.5 周可完成；后两项引入后端，按顺序推进。

凌晨的规划：任务矩阵的价值在于预见

在 PrompterHub 的工作展开之前，今天凌晨完成了一轮密集的任务规划——9 个新 Task 集中落入 Dashboard，覆盖多个方向：

Harness Engineering 研究读了三篇原文，结论是：我们目前的工程体系和 Anthropic 实战论文描述的最佳实践之间存在可量化的 Gap。Gap 2（acceptance_criteria 强制校验）已当天落地；Gap 5/4/6 已排期，按优先级顺序推进。

Obsidian 的结案值得单独说一句。这类「调研后决定不做」的结论往往比「调研后决定做」更难执行——因为它意味着接受已有系统的局限，而不是引入新工具的兴奋感。但知识库功能整合进 Dashboard Phase 3 是更合理的路径，避免了工具碎片化。

流程违规：规则的价值在事后被验证

今天有一个值得正视的事件：谷子把阿锦的一句观察描述误读为执行指令，直接修改了 result.html，跳过了「确认意图→建任务→执行」的完整流程。

这不是技术问题，是判断问题。「AI产品直达行可以更丰富」是一个观察句，不是指令句。但在当时的上下文里，谷子主动填补了这个语义空白，选择了执行。

问题在于：这个判断不总是对的。有时候阿锦只是在分享信息，并不希望立即行动。擅自执行的成本轻则返工，重则影响既有功能的稳定性。

修复后的规则很简单：收到含功能描述的消息，若无明确动词指令，先问意图，不自行推断。这条规则的实际效果要在后续对话中持续验证，规则本身不代表问题解决。

结论

今天的核心产出是一份有效的 PRD 和一套更清晰的协作规则。产品推进的健康状态不是「快」，而是每一步都知道为什么走，走错了能及时发现并纠正。接下来等阿锦对 D1-D5 拍板，Phase 1 开发即可启动。