先完成一项可以评审的小任务
产品经理第一次用 Codex，难点常常是没有把资料、目标和交付边界说清楚。本例为虚构的共享画室做预约改版：访客想知道剩余座位，值班人员需要处理取消，负责人希望减少临时电话。练习依次产出环境检查记录、竞品证据矩阵、访谈需求表和一份可以讨论的 PRD；不假定安装后就能自动访问公司的文档或业务系统。
从自己熟悉的产品开始，并把任务限定为“判断是否值得优先做取消后的座位释放”。这一判断比“研究整个预约市场”更容易核对。所有示例产品、访谈和数值均为练习设定，不能当成真实市场数据或上线效果。
第零天：准备环境和第一批能力
按 官方 Codex CLI 入门 选择适合当前系统的安装方式，登录后进入专用练习目录。确认账号可用、当前项目路径正确、读写范围符合任务。先让代理列出目录中的三份练习文件并各概括一句，不联网、不改文件；它应能分清产品说明、访谈摘录和预约规则。失败先排查登录、路径、文件格式与权限，不急着叠加技能。
准备一个简短任务说明：服务谁、目前如何预约、哪里出现问题、哪些资料可以引用、最终交付什么。原始资料保持只读，报告写到单独目录。不要直接投入含姓名、电话和预约习惯的真实访谈；先去标识化，并确认使用授权。遇到无法读取的文件，让代理说明缺少什么，不能用猜测补全内容。
安装扩展时先检查 SkillPI Skill Finder，缺少则按 官方仓库说明 安装，再搜索具体任务。查看候选的完整指令、固定来源版本、许可证、依赖和权限；先试一个样本再扩展。Codex 的技能有显式调用和按任务匹配两种方式，详见 官方技能说明，但自然语言提到一个词并不保证必然调用某个技能。
本次在 SkillPI 搜索 product requirements 没有返回结果，因此不把原文中的竞品或 PRD 技能名称直接变成目录链接。GitHub 的 PM Skills 项目 有分阶段文档和样例，可参考其拆分产物的方式；它在这里是方法来源，不代表已作为 SkillPI 关联技能验证，也没有替读者下载执行。
任务一：把竞品分析变成有出处的选择
给代理的任务卡可以写：“比较预约工具甲、乙与我们的人工流程，只回答取消后多久释放座位、是否通知候补人、谁能操作取消。先列证据缺口，再给矩阵和待验证问题，不推荐购买。”用虚构资料做演练时，明确标签为模拟；换成真实研究时，每格记录官方帮助页面、观察日期、版本或地区、事实摘要和不确定性。
矩阵一行对应一个决策问题，一列对应一个方案。页面写明支持候补，不等于默认自动通知；没有找到说明，也不等于不支持。区分文档明确描述、实际授权试用观察和仍未证实三种状态。无法联网时只整理已有资料并标注日期，不把旧截图写成最新功能。
第一版报告先给负责人检查两件事：比较问题是否影响当前决策，来源是否能支持结论。再让代理补缺口、修正矛盾，最后写适用条件。例如本例只提出“先验证取消释放是否足以减少人工协调”，不因为某个竞争者功能多就建议全盘模仿。SWOT 可以帮助组织讨论，但每个判断仍需证据，不能把表格填满当作分析完成。
任务二：从访谈摘录提炼需求而不扩大结论
提供三段去标识化的练习材料：访客说取消后不知道还有没有位置；值班人员说更新表格时会漏看电话；负责人说暂时不增加人员。要求代理把原话、观察到的行为、推测原因和待确认需求分开，给每条发现一个来源编号。三个人的反馈不代表全体用户，也不能据此计算总体需求比例。
将“我想收到提醒”转成可验证问题：提醒对象是谁、哪个状态变化触发、允许什么渠道、何时算打扰、失败后怎么处理。代理先输出需求清单和冲突，不直接决定方案。负责人确认本轮只做座位释放与页面状态，短信、支付和完整候补队列暂不做；保留这些排除项及理由，后续评审才不会把新想法悄悄当成已承诺范围。
产物是带来源编号的需求表、未解决问题及负责人。假设取消会降低人工电话量，应标为假设，下一步需要观察现有流程的基线和试点结果。不要让代理生成听起来合理的访谈原话或伪造研究参与者。
任务三：多轮对齐后写第一份 PRD
先给产品背景、目标用户、已确认需求、现有流程、约束和证据编号，再要求代理只写提纲与问题。确认后再出正文。至少说明问题与目标、范围内外、角色权限、正常与异常流程、验收条件、指标口径和未决项。PRD 是团队协商的记录，不是生成一次就自动批准的实现合同。
本例的需求 R1 为“已确认预约被成功取消后，释放一个座位并在页面展示更新”。验收样本写明初始容量八人、已占七人，取消一个已确认预约后已占六人；重复取消不再减一；取消失败时页面保留原计数并解释失败。八、七、六只是合成测试数据。并发行为与更新时限仍需工程确认，不能凭产品文案许诺即时一致。
指标可以定义为试点期需要人工协调的取消次数，分母为同一时期成功取消总数。先确认日志是否能够获得、谁负责解释，再制定目标；没有基线时先测量，不编造提升百分比。英文原文强调的战略背景也应落实到这里：本轮服务“减少取消后的人工协调”，并非为了展示更多自动化功能。若管理目标不同，先调整问题和衡量方式。
用途匹配的 Skill 放在文字走查步骤
草稿事实和范围对齐后，可使用 Writing Guidelines 检查技术说明的结构、措辞和例子，输出带文件位置的可操作修改建议。它需要目标文档和读取链接写作手册的网络能力；开始前说明受众是产品、设计和工程共同评审，并按中文语境调整风格。
这个技能面向技术写作，不负责发现用户需求、核验竞争者功能或证明产品策略正确。文案改顺后，逐条复查证据编号和需求含义，避免编辑把“可能”改成“必然”，或删掉影响工程判断的例外。需要 Word 或交互原型时，另选已经核验且适合当前格式的工具，不能因为有一份 Markdown 就声称已导出全部产物。
常见问题与交付验收
不会代码能开始吗？上述研究和需求练习可以从自然语言与文件开始，但仍要能识别来源、未决项和权限；工程可行性需要相应负责人确认。第一次交付物是可评审的分析与需求，不等于功能已经上线。
PRD 仍像模板怎么办？检查是否给了真实约束、反例、已有决定与证据；要求先提问，再保留确认记录。字段多并不代表上下文完整。
耗时和费用怎么估？限制方案数、来源数、迭代轮次与输出格式，记录实际模型用量及外部服务费用，不承诺统一几分钟或所有技能免费。最小验收是文件可打开、矩阵有出处、需求可追踪、关键异常可说明、未验证项没有被写成事实。通过后再逐步学习数据分析、汇报与协作；保留这次任务卡作为下一次可改进的起点。