产品上线前最忙的几天，问题通常不在于没人做事。开发正在改最后一个 Bug，设计在导出素材，运营还在改介绍页，负责人却要在几个群和十几份文件之间确认：哪一版需求作准，截图里的功能还在不在，文案写的上线时间有没有改变。
这类工作很适合用来理解 OpenAI Dot。它可以协助整理变化、跟进资料和协调任务，但“替我把产品上线”仍然太宽。上线过程中，代码合并、对外承诺、账户操作和页面发布，分别涉及不同的决定。
可以把它带进一个范围有限的项目：例如一个已有原型的小工具，两周后准备开放内测。先让它保持信息一致，再考虑交给它更多工作。以下是一套可以改成自己项目的做法，示例中的产品和日期都是假设，不是某个已经完成的上线记录。
先准备一份能作准的发布简报
一个长期助手首先需要知道项目是什么。不要把二十段历史聊天一起丢进去，然后期待它自动辨认哪段决定已经作废。
发布简报不必很长，但至少回答六件事：产品给谁用，解决什么问题，这次上线包含什么，明确不包含什么，预计何时开放，谁负责最后确认。再附上当前原型、代码仓库和素材位置。
例如，一个“自由职业者项目记录工具”的第一版，可以只包含客户、项目和交付记录，不包含自动开票和支付。把这些范围写清楚，后续宣传稿就不会顺手加上尚未实现的功能。
还应给简报一个版本日期。有人在会议里提出“以后加上财务统计”，并不意味着它成为本次承诺。Dot 整理讨论时，要区分建议、决定和已经完成的功能。
这份发布简报是当前作准版本。请先核对需求、原型和上线素材是否一致。输出差异清单，分别列出尚未确认的建议、已确认但未完成的功能，以及素材中出现而简报没有承诺的内容。先不要修改任何公开页面。
第一轮把差异找出来，比马上要求它写十种渠道文案更重要。背景不一致时，多生成一种文案，就多一个将来要修的版本。
让它跟变化，而不是重复抄计划
项目真正难的是变化。比如原定的搜索功能推迟、截图要重新拍、帮助中心还有旧说明，消息会在不同地方出现。
你可以让 Dot 维护一份变更记录，每条变更只记事实、影响和待决定事项。把“搜索延后”写成一个事实，把“官网第二屏和帮助文档要改”写成影响，把“是否继续原定开放日期”留给负责人决定。
这张表也可以按工作需要添加“已经通知谁”。一条变化被记录，不代表设计、客服和运营已经都知道。不要让助手仅凭某个频道出现过消息，就写成“团队已同步”。
如果项目使用共享页面，把发布简报和变更表放在固定位置，会比每次在对话里生成一份全新副本容易维护。Dot 可以协助修改和讨论，但同一份文档最好有明确的编辑负责人。
官方 Space 工作指南介绍了与助手共同修改页面的方法，也说明发布初期的 Keep Updated 并未直接开放。页面里写了“每天更新”，不代表自动更新已经设好；需要保存的定时安排仍要单独确认。
把委派任务写成能接住的交接单
Peter Yang 演示中的 App 上线任务，最有参考价值的一点是分工：代码工作和素材工作没有混成一个难以检查的大块。Dot 负责协调，具体任务继续由相应工具处理。
公开演示涉及开发与上线素材协作。准备就绪、提交审核和正式可下载，是不同阶段。
自己使用时，可以给每项任务一份短交接单。它应该包含目标、输入、产物、约束和验收方法。
例如截图任务：输入是当前可运行的内测版本和截图规格；产物是五张导出图片及源文件；约束是不能展示尚未实现的搜索和支付；验收方法是尺寸正确、文字可读、数据不含真实客户信息。
代码任务则需要明确仓库、分支、具体问题、允许修改的范围和检查命令。不要把“处理一下上线问题”直接转交给开发助手，它可能同时接触配置、页面、数据与依赖，最后很难知道哪个变化出于原始要求。
Dot 接收结果之后，应该核对各项任务是否覆盖了总体目标。截图全部导出成功，不能证明产品可以发布；测试全部通过，也不能证明宣传文案与实际功能一致。
截图和介绍页，要反向核对产品
模型很擅长把产品讲得完整，这恰恰可能成为上线材料的麻烦。一段顺畅的介绍里，容易夹进你从未决定提供的功能。
做素材时，不妨从真实界面和真实操作路径开始。先选目标用户最常做的三件事，再选择能对应这些事情的画面。不要为了让图看起来丰富，临时拼上未实现的分析图表或虚构数据。
截图标题也要准确。页面只是帮助记录项目，就不要写成“全自动管理客户”；支持导出文件，就不要顺手写成“无缝同步所有平台”。文案越短，越需要每个词有对应功能。
可以要求 Dot 做一次反向检查：
逐句检查介绍页和截图标题。每项功能描述必须对应当前版本的一条可见操作路径。找不到依据的句子标出来，不要替我补功能。把用户需要手动完成的部分写清楚。
这个任务不需要大篇幅报告。每一句有问题的文案、对应的产品事实和建议改法，三列就够了。负责人看完能直接决定改哪一处。
有些产品画面需要用模拟数据，这本身没有问题。重要的是不要把模拟数据装成真实客户成绩，也不要用不存在的功能界面冒充已经交付的产品。
公开演示中的付费页面，适合拿来讨论什么
Peter Yang 让 Dot 制作付费产品页面，第一版不满意，再提出更具体的修改意见。这个过程说明反馈的重要性，但“第二版更好看”仍然不是“产品可以卖出去”。
页面可以很快生成，产品承诺和实际交付仍需要逐项核对。
设计一个付费工具包，首先要说清楚购买者得到什么。是一份文档、四个互动工作流、一次辅导，还是持续服务？这些差别会影响价格、支持和退款安排。
让 Dot 协助的时候，可以先要求它写出“交付清单”和“不适用场景”。对产品经理工具包来说，适合已有客户访谈材料的团队，可能不适合尚未确定产品方向的人。把限制写明，比一味增加漂亮的卖点更接近真实交易。
还可以让它列出客户购买前最可能提出的五个问题，并指出每个问题应该由哪份交付物回答。这样做能暴露产品本身的空白：宣传页说支持竞品研究，包里却只有一个空表格，就值得在上线前处理。
原始演示的视频章节包括页面制作和不足之处。看这类内容时，最好同时关注创作者做了哪些反馈，而不只看模型用了多久。
给上线检查分成三轮
第一轮看材料是否齐全。应用包、帮助说明、截图、隐私页面、联系入口和交付内容，分别是谁提供、放在哪里、有没有缺失。
第二轮看材料是否一致。名称、价格、功能范围、开放时间和使用前提，应该在各个渠道一致。尤其是价格和试用期限，稍有差异就会给支持工作增加麻烦。
第三轮看结果是否真的出现在目标位置。文件放在本机，草稿保存在后台，页面正式可访问，是不同状态。Dot 可以帮助记录结果，但每一步都要有对应位置。
| 检查对象 | 合适的交付证据 | 容易误判的状态 |
|---|---|---|
| 截图素材 | 导出文件与尺寸 | 对话里显示了一张预览 |
| 代码修改 | 差异、检查结果、提交位置 | 助手说问题已解决 |
| 帮助文档 | 当前页面与内容 | 文稿已写好但没有更新 |
| 内测申请 | 提交记录 | 表单已填，尚未提交 |
| 官网发布 | 公共地址的当前内容 | 编辑器里有完整草稿 |
如果有一项需要人工完成，就直接标出“等待人工”。这比把整个项目写成“基本完成”更容易安排后续。
失败报告应能让下一位继续工作
产品上线时，登录过期、权限不足、接口限制都可能发生。一次任务失败，最不该留下的是只有一句“遇到了问题”。
让 Dot 交代最后成功的步骤、失败所在位置、已经生成的文件和需要你处理的事项。后台编辑器打不开，先保存文稿；发布接口不通，先保留构建产物；截图工具失败，先交出已确认的规格和素材清单。
还应避免失败后无意义地重复尝试。比如登录流程需要你完成验证，换一堆提示词不会解决。应该把交接请求送到你确定的地方，并说明在你处理前哪些工作还可以继续。
官方电脑指南说明了登录接管与本机连接的区别。云端浏览器不继承本机登录；换到本机工作也不等于把云端会话搬过去。任务所在环境必须明确，才好判断登录问题如何处理。
用“变更影响”安排通知
项目越临近上线，信息越多。如果 Dot 每完成一个小步骤都通知，负责人很快就会忽略所有消息。
可以把通知条件与影响联系起来：发布日期可能变动、公开承诺与实际产品冲突、关键材料缺失、需要你审批的动作。这些值得打断你；正常生成了一个文件、更新了一条内部待办，则可以留在记录里。
每日汇总也可以只包含三部分：今天改变了什么、这些变化影响哪些交付、明天必须由谁决定什么。没有变化的背景不用重新写。
任务安排要说明时区和结束日期。一次两周内测项目，完成后应取消重复检查，再明确是否进入下一阶段。不要让准备发布的提醒在产品上线一个月后还继续发送。
任务与记忆说明介绍了持续跟进和保存定时安排。实际管理时，应打开任务记录确认设置，而不是仅凭助手答应过就默认每天会运行。
上线之后，先处理真正影响使用的问题
项目开放后，Dot 的工作可以从准备材料转向整理反馈。这里也别直接说“持续优化产品”。先规定反馈来源、去重方法、哪些问题要立即提醒，以及什么需要进入下一次迭代。
一个按钮的位置不够直观和用户数据无法保存，优先级不同。十个人提出相似建议，也可能都来自同一篇社交帖子，不能自动代表十份独立需求。
要求它保留原始反馈、具体版本和复现条件，能帮助开发接住问题。没有条件的问题先列待补充，不要猜测症状。对已经修好的问题，记录修复在哪个版本，不要仅凭回复过用户就标成完成。
产品负责人最终仍需要决定做什么、什么时候做和承诺到什么程度。Dot 能协助减少遗漏、保持材料一致和追踪结果。一次上线里，能把这三件事做扎实，就比临时增加几十份文案和一套看起来很完整的计划更有用。