最近我在整理 dots 的工程用法，想把公开案例、可以复制的提示词和动手练习放在一起。这篇文章适合使用 windows、go、python 和 kubernetes，也需要做离线交付的开发者。
资料查阅日期：2026 年 10 月 25 日。产品入口、可用地区和账号权限可能变化，具体以你的账号和当前官方说明为准。
先说最值得学的用法
把一个需要持续上下文的目标交给 dot，让它整理信息、维持任务状态、提出下一步，再把明确的实现工作交给合适的执行环境。你负责关键决策、授权范围与验收。
例如，别只问“怎么做评论分类”。可以让 dot 帮你维护“数据准备、cpu 训练、评估、离线交付”这条工作线；需要写代码时再交给 codex；每一步用明确产物验收。
这篇文章把四类材料分开写：
- 官方案例与说明：官方公开展示或说明的工作方式，不代表所有用户都这么用。
- 员工个人经验：员工以个人身份分享的经历，不当作产品能力保证。
- 社区用户自述：保留原始出处，但自述不等于独立测试。
- 本文设计示例：为开发者场景编排的建议与提示词，不冒充他人实测。
它不是使用人数排行榜，也不据几个帖子推断“大家最常用什么”。文中的提示词供你选择后使用，阅读文章不会自动执行、发布或修改任何东西。
想先看别人怎么用，就从七个场景开始。想马上练习，可以先看任务卡，再跟着评论分类 pipeline 的七轮对话走一遍。
dot、work、codex 和你怎样分工
可以先用一个简单分工理解：
- dot：围绕持续目标协调信息、跟进变化、组织下一步。
- work：承接研究、分析、文件等具体任务。
- codex：在明确的环境和代码范围内实现、调试、测试、审查。
- 你：决定目标与取舍，批准有后果的动作，核对结果是否符合真实需求。
这是工作分工，不是能力的绝对分界。官方也把 dot 定位为持续协调者，可以委派 work 或 codex。来源：Meet dots（页面未注明独立发布日期，查阅于 2026-10-25）。
有三个容易踩的前提：
- 新任务不等于自动继承全部聊天。 把当前决定、相关文件、限制和验收方法明确传过去。来源：Tasks and memory（查阅于 2026-10-25）。
- 你的电脑、云端电脑、已连接账号是不同资源。 本机浏览器登录过某网站，不代表云端也已登录；本地执行要核对连接和在线状态。来源：Connect computers and apps（查阅于 2026-10-25）。
- windows 不需要被默认改造成 linux 工作流。 官方 windows codex 支持原生 PowerShell；具体任务仍要核对执行位置和工具。本文所说“离线交付”指产物在离线目标环境运行，不是 dots 本身完全断网运行。来源：windows sandbox（查阅于 2026-10-25）。
七个有出处的场景
下面七项有不同强度的公开来源：一个官方公开案例，三个员工个人经验，三个社区用户自述。它们提供的是做事方法，不是成功率保证。每个场景后面的工程提示词，都是本文重新设计的用法。
场景一 把分散反馈变成可以调查的问题
官方公开案例。 chatgpt 官方介绍，工程师 @rennsong 用 dot 汇集社交媒体与用户报告中的反馈，更新 space 跟踪表，再使用 codex 调查和修复 bug。这是官方公开案例，不是独立客户评测；本文依据帖子文字，没有声称复现其结果。原帖（2026-10-23，查阅于 2026-10-25）。
它解决的不是“不会写修复代码”，而是反馈分散、重复报障、缺乏复现条件，以及修复与原始问题脱节。
开发者适配建议。 后端平台 的报障可能来自邮件、讨论和日志。先让 dot 把这些材料整理为候选问题清单，每项保留影响版本、复现条件、原始链接和未知项，再决定哪些值得进入代码调查。
前提与分工。 dot 需要能读取你指定的来源；你负责确认数据可用范围和优先级；codex 只接收必要的代码调查上下文。仅整理信息时，不必启动代码实现。
开始：
只读整理这些已授权的反馈。按问题合并重复项，保留原始链接，区分用户报告与已复现缺陷。先给我最值得调查的三项，不改代码、不联系报告人。
追问：
对第一项列出最小复现条件、缺失证据和可能受影响的模块。缺少的信息标未知，不把猜测写成根因。
验收：
检查每项结论是否有原始证据。把“已复现”“仅报告”“待确认”分开。需要修改时先给范围建议；创建 pr/mr 前必须取得我的明确批准。
常见误区。 同一问题出现多次不自动证明影响严重；一条报障也不能直接当成缺陷事实。先整理和验证，再考虑修复。
场景二 用 dot 协调工程任务 避免自己不断转述
员工个人经验。 openai 员工 @rennsong 分享，通过自己的 dot 协调工程工作，将任务路由到相关线程或云端环境并跟进。帖子还提到，调查中发现相邻代码的问题后，dot 询问是否创建草稿 pr。这是员工自述，不是所有任务的能力保证。原帖（页面显示 2026-09-29，显示时区未确认；查阅于 2026-10-25）。
开发者适配建议。 一个需求可以拆成 go 接口、python 处理流程和交付文档，但要共享同一份接口契约。dot 维护决定与依赖，codex 执行边界明确的代码任务，你审查取舍和最终结果。
前提与分工。 先明确环境、仓库、分支和工作目录。独立调查可以并行；会修改相同文件或依赖同一未定接口的任务，不宜一开始就并行。
本机执行需确认电脑在线、chatgpt 桌面应用保持运行。云端代码任务需要已配置的 codex 云端环境和仓库，不能把 dot 自带云端电脑当作现成的代码环境。参见官方 Tasks and memory 与 Connect computers and apps（查阅于 2026-10-25）。
开始：
把这项需求拆成不超过三个可验收工作包，列出输入、输出、依赖和负责人。先只规划，找出必须串行的部分，不创建实现任务。
追问：
我批准在指定测试环境实施第一个工作包。开工前核对路径、分支和基准版本；已有同目标任务就先核对能否续接，避免重复开工。
验收：
汇总各工作包的产物、测试证据和未完成项。发现相邻问题先报告，不顺手扩范围；不要提交、推送或创建 pr/mr。
常见误区。 “多代理”不等于自动更快。同一文件被并发改动、接口口径不同、重复研究，都会增加整合成本。先一个工作包跑通，再决定是否扩大并行。
场景三 从一句修改意见找到真正的规范
员工个人经验。 openai 员工 Gabriel Chua 分享，设计同事在 slack 中指出演示应用的字体问题，并提到已有模板。作者把消息交给 dot，让它去 drive 找模板、提取字体规范，再与远程源码比较。原帖（页面显示 2026-10-13，显示时区未确认；查阅于 2026-10-25）。这是跨来源核对的实例，本文没有独立验证其最终改动质量。
开发者适配建议。 你收到“这不符合我们之前的接口约定”时，先别让 ai 凭印象修改。让它找到讨论、接口文档和当前实现，整理“要求、实现、差异、证据”四件事。
前提与分工。 dot 负责找对文档与版本；codex 负责读取指定实现；你确认冲突要求中哪一版有效。只能访问已连接且获授权的来源，不能假定 slack、drive 和代码天然互通。
开始：
根据这条评审意见，查找它提到的接口约定。先确认文档版本与适用范围，再和当前实现做只读对照。不直接改代码。
追问：
把明确违反规范、规范表述不清、实现合理但文档过时这三类情况分开。遇到两个版本冲突，列证据让我决定。
验收：
每条差异附文档位置与代码位置。没有找到依据的意见标成待确认，不把讨论中的猜测升级为正式要求。
常见误区。 最新消息不总是最新规范；旧文档也不一定失效。重要的是版本、适用范围以及谁作出了明确决定。
场景四 先验收一个样板 再批量生成
社区自述。 一位 reddit 用户描述，把 photoshop mockup 模板、截图、logo 和颜色等输入准备好后，让 dot 批量制作，再对两处 logo 位置作调整，并通过手机跟进。此经验未经独立重现，也不证明所有桌面软件都能稳定自动化。原始评论（检索信息显示所在帖子为 2026-10-09，评论精确时间未核实；查阅于 2026-10-25）。
开发者适配建议。 可以把这套方法迁移到多个版本的离线交付文档：先完成一份标准 README、配置说明和验收清单，再处理其他环境差异。这里迁移的是“样板先行”的方法，不是 photoshop 案例证明了交付包一定正确。
前提与分工。 你提供合格样例与环境差异；dot 管理样板和待处理清单；涉及程序生成或校验时再由 codex 执行。先验收一份，后续批量范围另行明确。
开始：
参照这份合格样例，先做一个 cpu 离线交付说明。沿用结构，未知的依赖版本和路径留待确认，不编造。暂不批量。
追问：
按目标系统、架构、python 版本和配置差异列出变量。哪些内容能复用，哪些必须逐环境验证？
验收：
检查样板能否让没有看过聊天的人独立操作。样板确认后再生成其他版本，并附差异清单，不机械替换环境名称。
常见误区。 一份样板上的错误会被批量放大。文档生成成功，也不代表对应安装步骤已经运行成功。
场景五 长文档审阅靠检查点接续
社区自述。 一位用户描述跨日处理大量 pdf、穿插其他问题后继续审阅的经历。同一讨论也提醒，排队任务未必如预期自行启动。作者对内部机制的部分判断来自 ai 自述，不能当成产品事实。原帖（检索信息显示 2026-10-01，精确时区未核实；查阅于 2026-10-25）。
开发者适配建议。 审阅 pipeline 或 kubernetes 离线安装文档时，先建文件清单，再按明确问题审阅。例如只查“依赖是否齐全、版本是否一致、安装与回滚步骤能否对上”。不要一次请求含糊的“全面分析所有资料”。
前提与分工。 dot 维护已审、待审、冲突和证据位置；codex 只在有授权时核对相关脚本；你确认文档用途与有效版本。文件可读、任务已启动和审阅已完成是三种不同状态。
开始：
先登记这批文档的文件名、版本和适用环境。本轮只审依赖与安装前提，每个结论附页码或章节位置，先完成前三份。
追问：
保存检查点：已审内容、待审内容、冲突、原文位置和下一步。不要用一段笼统摘要代替状态记录。
验收：
恢复前核对文件和版本是否变化。只继续未完成部分；确认实际任务状态。若未启动或被阻塞，直接说明，不把“会继续”算作已执行。
常见误区。 “它记得我们聊过”不能替代进度和证据。长任务最需要的是可核对的检查点，而不是更长的承诺。
场景六 把真实运行反馈变成下一轮修复输入
社区自述。 一位用户分享 dot 编写并打包游戏 mod 的经历：即使任务称已完成或测试，用户实际运行仍发现问题；截图和明确的失败描述有助于下一轮修复。这不是可复现基准，但揭示了很实际的验收缺口。原帖（2026 年 10 月公开讨论，精确日期未核实；查阅于 2026-10-25）。
开发者适配建议。 go/python 服务和离线包同样需要区分构建、单测、端到端以及目标环境验收。要求 dot 汇总证据，而不是只转述“codex 说测过了”。
前提与分工。 codex 报告真实运行命令和结果；dot 对照验收清单追问缺口；你在真实业务或无法被代理访问的目标环境完成最后验证，并反馈可复现信息。
开始：
检查这次交付是否真的达到验收条件。列出构建、单测、端到端和目标环境验证各自的状态与证据，未执行就写未执行。
追问：
我的环境、版本、输入、操作步骤和错误输出如下。先复现并判断差异来自代码、依赖还是环境；不要只根据截图重写整个项目。
验收：
修复后重跑最小复现和相关回归测试。说明哪些测试只在你的环境通过，哪些仍需要我确认。
常见误区。 “生成了测试”不等于“运行了测试”，“单测通过”不等于“离线目标机可用”。交付时必须保留未验证项。
场景七 重复成功后再写 sop 和安排检查
员工个人经验。 openai 员工 Dennis 分享，将重复工作整理为可复用流程，再考虑自动化；帖子还谈到用共享文档协调工作。本文只借用这个可迁移的方法，不据此推荐全天通话、大量并行或跨代理联动。原帖（2026-09-29，查阅于 2026-10-25）。
开发者适配建议。 把已验证的离线包核对流程整理成 sop：目标平台、依赖、模型文件、校验值、安装、预测、回滚。等流程稳定，再决定哪些部分适合按需复用，哪些确实需要定时检查。
前提与分工。 你选择重复任务及资源边界；dot 整理流程与提醒条件；codex 执行获准的脚本验证。公开案例不代表你的账号已经配置了任何计划或获得了持续访问权限。
开始：
根据这次已经验证的交付，把稳定步骤写成 sop。列出输入、步骤、验收、失败处理和必须人工决定的事项；只生成文档，不创建定时任务。
追问：
判断哪些步骤值得复用，哪些随环境变化必须重新确认。若建议定时检查，先说明来源、频率、有效期、通知条件、运行范围和停止条件。
验收：
用另一份样本人工监督执行一次，记录偏差。只有流程通过、计划范围获批后才设置；保存后核对时间、时区、启用状态和结束条件。
常见误区。 自动化会重复原有流程，包括其中的错误。一次性跟踪不必做成永久计划；无变化时不发消息，也不等于没有执行工作。
先把一个任务说清楚
不必学一大套“提示词工程”。给 dot 一张能执行、能验收的任务卡，比不断追加“再专业一点”更有效。
一张任务卡至少写清七件事：
- 目标：最后要得到什么，不是泛泛地“帮我研究”。
- 输入：哪份文档、哪段讨论、哪个仓库或哪批数据可以作为依据。
- 环境：windows、本地目录、指定云端环境，还是只用公开资料。
- 边界：能读什么、能改什么，哪些动作必须先问。
- 输出：Markdown、补丁、测试报告、待办清单，还是一个可运行包。
- 验收：用什么证据判断完成。
- 停止：做到哪里停；遇到缺权限、缺数据、外部依赖时怎么办。
可以直接复制这个骨架：
目标：……
可用输入：……
执行环境：……
允许：……
不允许：……
交付物：……
完成证据：……
停止条件：……
先指出缺少的关键条件；非关键缺口做明确标注后继续。
这张任务卡扩展自官方的目标、上下文、约束、完成条件四项结构；环境、权限和停止点是本文为工程协作补充的实践建议。来源：Best practices（查阅于 2026-10-25）。
本文采用的一条工程协作边界：创建任何 pr 或 mr 前，必须获得我的明确批准。 只读排查、建议修改、生成补丁、实际修改文件、提交 commit、推送分支、创建 pr/mr、合并发布，是不同的动作。授权一个，不等于授权后面的全部动作。
用一个评论分类 pipeline 串起完整协作
这一节是为 windows 后端工程师设计的教学示例，不是公开用户案例，也不是已经跑通的项目记录。下面的回复是“你应当要求看到什么”，不是实际测试结果。
目标很具体：输入评论，输出正面、负面或中性标签；在 cpu 上完成训练、评估、批量预测和离线交付。先跑通闭环，再考虑模型、服务化和 kubernetes。不要第一轮就把三个问题混成一个大任务。
第一轮 定义结果和权限
你可以这样开始：
我要做一个评论三分类的最小完整闭环。
开发机是 windows，主要用 go 和 python。
本轮只设计方案，不运行命令、不改文件。
训练和推理只用 cpu，最终必须能离线交付。
先使用不含个人信息的合成小样本验证流程。
输出数据契约、阶段划分、目录建议和验收清单。
不接生产服务，不读取真实客户评论，不创建 pr/mr。
每个阶段说明 dot、codex 和我各自要做什么。
你应当拿到的不是一长串模型名，而是这些决定：
- 输入至少包含
text；训练样本另有label。标签只能来自预先定义的三个值。 - 先用一个轻量 cpu 基线，例如字符级 TF-IDF 加线性分类器，验证数据和工程流程。它只是候选起点，不预先保证效果。
- 训练、验证、测试各司其职；相同或近似重复评论不能随意跨集合泄漏。
- 中性如何定义、反讽和混合情绪如何标注，先写成标注规则。
- 离线交付目标要明确操作系统、cpu 架构和 python 版本。windows 开发不意味着最终包一定在 windows 上运行。
- kubernetes 放到后续阶段。第一阶段成功的标准是命令行闭环可以复现。
分工也应当清楚：dot 整理目标、约束和未决问题；codex 在指定且可用的执行环境里实现和验证；你决定业务标签规则、数据可用范围，以及是否进入下一阶段。
第二轮 固定验收 再批准实现范围
追问：
把方案改成一页验收清单。
必须覆盖空文本、缺失标签、非法标签、中文、重复样本。
给出每类 precision、recall、F1 和混淆矩阵。
小样本只证明流程可跑，不证明业务效果达标。
不设一个拍脑袋的准确率门槛。
标明需要我决定的业务门槛，其他部分继续完善。
这里最重要的技巧，是把“程序运行成功”和“模型可以用于业务”分开验收。
脚本不报错，只代表某次运行完成。模型是否足够好，还取决于样本代表性、类别分布、标注一致性、误判成本，以及未参与调参的测试集表现。不能因为合成样本上的数字好看，就宣布业务可用。
确认方案后，再授权一个小范围的实现：
我批准在指定的测试目录中创建最小原型。
不修改其他目录，不推送代码，不创建 pr/mr。
先检查可用执行环境并告诉我实际在哪里运行。
如果不能在我的 windows 机上执行，就先交付待验证版本，
不得把其他系统的运行结果称为 windows 验证通过。
需要安装软件、外部传输数据或扩大权限时先说明。
把批准范围写到目录、动作和数据级别，比一句“你看着办”更容易控制结果。
第三轮 先完成最小纵向闭环
给 codex 的实现任务可以由 dot 整理成这样：
先做最小纵向闭环：
合成数据 → 校验 → 切分 → 训练 → 评估 → 保存产物 → 预测。
所有预处理只在训练数据上拟合。
固定随机种子，记录依赖版本和运行命令。
预测输出保留输入行标识与预测标签。
先不要增加 web ui、数据库、消息队列和 kubernetes。
完成后给出变更文件、实际执行命令、退出状态和产物路径。
未执行的步骤明确写“未验证”。
一个合理的初版目录可以是：
sentiment-pipeline/
README.md
data_contract.md
label_guide.md
sample_data/
src/
validate.py
train.py
evaluate.py
predict.py
tests/
artifacts/
reports/
offline/目录名可以改，验收职责不要丢。训练产物、评估报告和离线包最好有不同位置，避免把旧模型和新报告误当成同一轮结果。
第四轮 验收证据 不接受一句通过了
追问：
请逐条对照验收清单。
对每条标记：已验证、未验证、失败或阻塞。
已验证项附对应命令、关键输出和产物。
检查评估报告对应的模型、数据切分和本次代码是否一致。
不要把“有测试文件”写成“测试已执行”。
若失败，先解释原因和最小修复范围，避免顺手重构。
你要看的证据包括：
- 输入异常是否按约定拒绝或处理。
- 三个类别是否都在报告里出现，样本数是否合理。
- 训练流程能否从干净目录重跑，而不是依赖上一次残留文件。
- 新评论能否经同一套预处理得到标签。
- 测试结果是否来自本次版本和目标环境。
- 性能数据是否注明样本数、批大小、硬件、线程数和预热方式。没有这些条件，cpu 时延很难比较。
第五轮 做离线交付而不是压缩源码
接着提出独立任务：
为目标离线环境制作交付包。
先确认操作系统、cpu 架构、python 版本及是否允许容器。
列清依赖、模型产物、测试样例、安装和回滚步骤。
检查是否存在首次运行自动下载、在线鉴权或外部 api 调用。
在断网或等价受控环境中验证安装和预测；
做不到就说明缺少哪一种验证，不宣称离线可用。
附文件校验值和已知限制。
离线包常见的坑不在业务代码里：
- 为 linux 准备的依赖包不能直接当作 windows 离线依赖。
- 在已有开发环境里成功运行，不代表在干净目标机上能安装。
- 代码没有联网逻辑，不代表依赖或模型加载器不会在首次运行时下载资源。
- 保存了模型文件，不代表还原了训练时的预处理和标签映射。
如果选择容器交付，还要分别验证镜像架构、所需镜像是否齐备、目标环境导入方式和启动命令。不能把“本机 docker 能跑”直接等同于“目标集群能部署”。
第六轮 再决定是否接入服务或 kubernetes
到了这一步，才讨论 go 后端或集群集成：
最小离线闭环验收后，再比较两个方案：
A. python 批处理，go 负责任务编排；
B. python 推理服务，go 通过明确接口调用。
按离线部署、cpu 开销、故障定位和维护成本比较。
先输出接口契约和建议，不修改现有服务或集群。
如果建议 kubernetes，说明它解决了什么实际问题，
不要只因为我会 kubernetes 就默认必须上集群。
后端工程师关注的接口、超时、重试、批处理大小、输入校验和可观测性，到这里才进入正确的位置。模型本身没有通过验收，外面套一个服务不会让它更可靠。
第七轮 保存接续包
当你要下班或换设备时，让 dot 保存任务状态，而不是只保存一份聊天摘要：
请整理一个下次可以直接接续的状态包：
已确认目标与禁止事项；
当前代码、数据、模型和报告版本；
实际完成的验证与未验证项；
下一步唯一优先任务；
需要我确认的决定。
不自动开始新阶段，不创建 pr/mr。
下一次的开场可以很短：
基于这份接续包继续。先核对文件和环境是否还有效，
只推进“下一步唯一优先任务”，不要从头重做调研。
接续包不是新环境已经拥有旧文件的证明。更换机器、目录、会话或权限之后，仍要核对输入和环境。
十个日常小技巧
1 先问最影响结果的一个缺口
不要要求 dot 每次都问十个问题。可以说：“只问会改变方案的关键问题；其他假设写出来后继续。”在上述 pipeline 中，目标操作系统会影响离线包，目录命名通常不会。
2 一次推进一个可验收的小闭环
“读数据、训练、出预测”是纵向闭环；一次生成十个尚未连接的模块不是。先完成能够检验方向的最小结果，再扩大范围。
3 限定输入比强调聪明更有用
“只看这个模块、这两个日志和最近一次失败”比“全面检查整个系统”更容易得到可验证结论。需要扩范围时，让 dot 解释新证据和预计收益。
4 用三级结论防止猜测冒充事实
要求每份报告区分“已证实”“较可能”“尚未知”，每个已证实结论附证据位置。让它明确写出还能推翻当前判断的证据。
5 用增量更新代替重写整份报告
已有一份结论后说：“只报告自上一版以来的新增证据、结论变化和待我决定的事。”这能减少阅读负担，也避免每轮把同一批背景重新展开。
6 给并行任务划清交界
适合并行：分别查官方约束与用户实践，分别检查数据质量与接口契约。需要串行：标签定义没定就训练、目标系统没定就打离线包。多个执行任务编辑同一批文件，反而更容易产生冲突。
7 测试清单先于实现
把空输入、边界条件、错误路径和验收证据写在前面。验收不是最后一句“再帮我测试一下”，否则往往只剩一轮表面检查。
8 监测一定写清提醒门槛和停止条件
“帮我盯一下”缺少对象、来源、频率和结束条件。更好的表达是：“在我有权限访问的这次 CI 运行结束前跟踪；失败、需要我处理或完成时通知；不要每次状态不变都发消息。”若要固定周期的长期检查，应另外明确周期、有效期和可接受的资源消耗。
9 让交付物脱离聊天也能用
README 应写明环境、安装、命令、输入输出、失败排查和已知限制。把“上面提到的文件”“按之前那样运行”改成明确名称和路径规则。离线接收方不应依赖你的聊天记录。
10 把尝试与授权分开
“帮我写一封邮件”先得到草稿；“给我一个部署方案”先得到方案；“查一下为什么失败”先得到诊断。发送、部署、改权限、推送分支、创建 pr/mr 等动作，都要按明确范围获得授权。
减少重复工作 让精力留给关键验证
提高效率的重点，是减少无价值重做，而不是省掉必要验证。
- 先扫描再深入。 先找到关键文件、错误和证据，再按线索扩大范围。
- 先复用再重写。 指定已有报告与产物，只补新增缺口；但版本和环境变化时，相关结论要重新核对。
- 按结果选择输出。 只需要一个决策时，先给结论与证据，不必同时制作网站、演示文稿和多种附件。
- 稳定约定写短写清。 仓库的 AGENTS.md 适合放测试命令、目录规则和禁止事项；单次任务细节留在任务卡，过时约定及时清理。来源：Best practices（查阅于 2026-10-25）。
已开始的任务和已保存的周期计划也要分开管理。停止当前任务，不等于取消后续计划；停止操作也不会撤销已完成的改动。按实际任务与计划状态核对，别只依赖一句“已停止”。来源：Control your dot（查阅于 2026-10-25）。
最先尝试这三件事
第一件 把一个已经打开的工作线索整理成行动清单
选择一段讨论、一份需求或一次失败记录，只做整理和只读判断。要求给出证据、下一步和待你决定的问题。这最容易看出 dot 能否真正帮你减少上下文切换。
第二件 完成一个小型 cpu 评论分类闭环
用合成数据和独立测试目录，验证训练、评估、预测、离线交付的链路。先得到可复现的工程骨架，再考虑真实数据和复杂模型。
第三件 跟踪一个有明确终点的任务
例如一轮测试或一次 CI。约定什么时候通知、何时停、哪些动作只能建议。先练习短期、只读、有终点的跟踪，再考虑长期周期任务。
提示词速查表
- 结果泛泛而谈：每个结论给证据和下一步。完成时应看到：能据此行动。
- 反复从头做：复用这份产物，只补新增缺口。完成时应看到：有清晰增量。
- 工程范围越做越大：只完成这一条纵向闭环。完成时应看到：最小链路可验证。
- 不知道是否真的测了：列实际命令、环境、结果和未验证项。完成时应看到：证据对应本次版本。
- 离线包无法安装：在干净目标环境断网验收。完成时应看到：安装与预测均验证。
- 监测不断刷屏：只在完成、失败或需我处理时通知。完成时应看到：到约定终点停止。
- 换会话后丢进度：输出版本、状态、下一步和禁止事项。完成时应看到：能核对后接续。
- 担心越权：修改、发送、推送和发布分别授权。完成时应看到：动作未超批准范围。
最后记住一个判断标准：好的协作会留下可检查的产物、可追溯的证据和清楚的下一步。 如果只有一段听起来很完整的回复，还不算一个闭环。