不会代码，也可以先交付三份可评审产物
虚构的社区器材站准备上线“预约借用投影仪”。产品负责人希望先了解其他预约服务怎样处理名额、写清需求，再把流程交给工程师。Codex 可以帮助组织材料和草稿，但不应因为生成得快就把未知需求、竞品宣传和已验证事实混在一起。最适合开始的交付是证据矩阵、PRD 和可编辑流程图，而不是一次安装九个不明包。 本文保留原文中英文的竞品分析、PRD、流程图三个场景。所有产品和记录均为合成示例，没有实际访问私人系统、采访用户或发布功能。先明确输入、工具可用性和验收，技能只在对应步骤辅助；不会代码不代表可以省略事实核对和产品判断。
场景一：用证据矩阵回答竞品做了什么
先定义比较问题：预约是否锁定名额、取消后怎样释放、是否存在候补，以及使用者能否看见状态。选两三个与当前任务可比的公开服务，不把不同客群、不同套餐和不同地区直接放在一个排名里。保存产品名、页面、访问日期、套餐、可见行为与证据位置，无法访问的功能写未核实。 让 Codex 把公开说明和经授权的观察整理成矩阵。每个单元格区分官方描述、实际观察、推断和未知；某页没提候补不能直接等于产品没有候补。不要为了表格整齐补造价格、使用人数或用户反馈，也不把宣传中的“智能”当成具体能力。截图或引用需保留上下文，避免功能在另一条件下才可用。 从矩阵提炼机会前，先问我们的用户是否有同样问题。器材站的投影仪数量有限，候补或许比更复杂的营销功能重要，但这仍是待验证假设。列出支持、反例与下一步研究，不让竞品拥有某项功能自动变成“我们必须做”。产物应能说明取舍，而不是功能越多分数越高。 若团队已经使用并授权连接 Notion，可以在整理已审核资料这一步使用 Notion Research & Documentation。公开详情、OpenAI plugins 固定来源与 MIT 许可已核验。它适合在可读的授权资料中检索与综合成文，前提是所需 Notion 工具、来源与目标位置明确；不是通用网页爬虫，不保证市场数据完整，也不代替用户研究。没有连接时可用普通资料表，不为了这一步新开账户。 交付证据矩阵、来源清单、比较限制与机会假设。每个重要结论回到具体单元格，临近决策时复核时效。让审阅者能区分“竞品怎样描述自己”和“我们实际观察到什么”，比输出一份漂亮的竞品报告更有价值。
场景二：把想法变成包含失败路径的 PRD
从用户任务开始：工作人员需要借出设备，借用者需要知道是否预约成功，管理者需要处理冲突。明确本次范围，例如只支持单件设备与固定时段，不顺带加入支付、跨站点和复杂审批。写目标、非目标、角色、前提、数据字段、业务规则、状态、异常与验收，而不是先填满模板。 对“预约成功”给出可观察定义：服务端确认后有稳定编号，设备时段已占用，刷新后能看到状态。按钮变绿或出现成功文案不是持久化证明。重复点击、网络超时、同一时段竞争、取消和名额释放要分别说明。超时可能是结果未知，不能一律引导用户重新提交而不考虑重复预约。 每条规则带编号和例子。例如同一投影仪同一时段只能有一项有效预约；未取得确认前展示处理中；取消后按约定释放。再给正例、反例与待决问题，避免研发各自解释。涉及权限时说明谁可看、谁可取消、是否能代操作，不把“管理员”当无限权限万能词。 用 Given/When/Then 或普通清晰语句写验收，两者都可以，关键是输入、动作和可观察结果。区分页面、接口和数据层证据：页面提示可由浏览器检查，持久化与并发需要相应工程验证。PM 不必自己实现所有测试，但应知道结论需要哪类证据，不能把 AI 草稿当成已经通过评审。 技术需求文档的表达复核可以使用 Writing Guidelines。公开详情、Vercel 固定源码与 MIT 许可已核验；提供已有 PRD、术语和读者，它适合改善结构、清晰度与操作说明。它不决定业务优先级，不验证用户需求，也不把文档变成没有漏洞的完整系统。 交付 PRD 版本、规则与验收映射、未决项和评审意见。对待确认内容明确负责人，不用模型编造一个答案填空。需求变更时记录影响的规则和图，而不是只改一段正文造成多个产物不一致。
场景三：先画状态与分支，再决定图形工具
用一张节点表列开始、输入、服务端检查、成功、失败、未知和取消。边标明触发条件，区分用户动作与系统判断。器材预约至少要画出名额冲突和超时未知，不只画一条理想成功线。每条终点对应 PRD 中的状态，循环有停止或返回条件，避免用户卡在没有出口的处理中。 开源 Mermaid 适合把文本图源纳入版本管理，选择依据是可编辑语法、文档和渲染生态，而不是图看起来更像设计稿。用适合当前图的流程或时序表达，长节点文字尽量收敛。图源必须在团队实际使用的渲染器里验证，不同版本支持和布局可能不同，PNG 能打开不代表图源仍可编辑。 如果需要按借用者、服务端、工作人员分区，可以组织分组并在评审中说明责任；不能把某种布局自动当作严格泳道语义。时序图有助于展示请求与确认，状态图有助于看生命周期，不必用一张大图包办所有视角。白板工具也可选择，但导出图与可编辑源应一起交接。 让 Codex 将图与规则编号对照：每个条件来自哪条规则，取消是否释放，失败和未知是否区分，管理员介入发生在哪里。用合成案例逐条沿图走一遍，找无入口、无出口与矛盾路径。渲染成功只证明语法或部分布局可用，不证明业务逻辑正确。 产物包括可编辑图源、实际渲染结果、节点规则表和问题记录。本文没有关联未核验的流程图技能，也不把已有数据库 ER 图工具当作预约业务流程工具。后续有候选时再核对公开详情、固定来源、许可、依赖与输出格式。
让技能在真实任务里被验收
根据官方 OpenAI 文档，技能包含任务指令与可选资源，并由当前环境按描述或明确调用使用。安装、发现、调用和产物验收是不同状态。先核验 SkillPI Skill Finder 官方来源和安装前提，再按实际缺口找候选；也可直接审阅一个已知包，不必为了任务先安装发现器。具体目录与调用方式以当前产品和环境为准，不承诺所有 Agent 相同。 选择时记录来源版本、许可、脚本、工具与数据范围。需要 Notion、浏览器、运行时或账户的包，安装文件不会自动提供这些前提；运行也可能产生模型与外部服务费用。不要沿用“免费且更省 token”的统一承诺，先用一个小样例检查实际输出。 可这样提出任务：“用合成器材预约需求，先产出带来源类型的比较矩阵，再写范围明确、含异常状态的 PRD，最后生成可编辑流程并映射规则。未经证据不要补造价格或访谈，不连接真实数据、不发布。分别标明使用的技能步骤、实际完成与待验证项。”这让非技术负责人也能逐项审阅，而不是只能评价文稿是否好看。
FAQ 与排错
资料不够怎么办？保留未知与研究计划，不把完整报告的格式当事实完整性。PRD 被反复打回怎么办？检查目标、规则、范围与验收是否一致，先解决关键分歧而非继续扩写。图与正文不一致怎么办？以确认过的规则版本为基准同步修订，并保留变更记录。 技能未出现怎么办？查实际环境、文件结构、元信息、作用范围与当前产品支持，不能断言九成都是某一个目录问题。技能是否替代 PM？不会替你确定价值、承担决策和组织真实验证。不会代码能否使用？可以先从资料与文档产物开始，但工具运行与发布仍需前提和权限。三个场景不必各装三个包，够用且可验证比凑组合重要。
来源与维护
保留原文双语的竞品分析、PRD、流程图与安装 FAQ，采用原创投影仪预约贯穿案例。技能机制参考官方 OpenAI 文档，图源参考 Mermaid 上游，关联包使用固定源码。移除匿名成功引语、百位用户实测、热度和零成本保证。本文未进行真实竞品测试或用户访谈，后续按来源与目录变化复核关联，保持公开 slug 和语言配对。