我如何使用 Dot：从一句反馈，到一份可验收的结果

回看自己的 Dot 使用记录，我发现最值得分享的，往往是任务中间那些很短的补充。

“只要键盘弹起就会滚动。”

“最后一场中了也没戏了，也就是未中奖。”

“能直接给我生成文件吗？”

这几句话分别出现在页面修复、业务规则调整和 PPT 制作中。它们补上了触发条件、业务反例和交付要求，也改变了任务接下来的方向。

整理这些过程后，我逐渐形成了一套使用习惯：先把目标和现状交代清楚，在执行中持续给反馈，最后根据证据确认结果。下面用三个真实案例，讲讲我具体怎么做。

文中的案例整理自 2026 年 10 月 25—26 日的 Dot 使用记录。测试、PR 和发布状态均指当时的任务回报，不能据此判断相关项目现在的状态。

一、我怎样把 Dot 放进具体任务里

我的使用场景比较杂：修页面、检查移动端适配、核对代码变更、跟进发布，也会做 PPT、调整配色和处理图片。

在这些任务里，我通常先在 Dot 首页说明需求。需要展开执行时，记录里会出现关联的独立任务，里面继续调查、修改和检查；首页则能看到不同任务的进展。我可以继续补充条件、追问状态，或者指出某处理解不准确。

对我来说，任务通常会经过这样几个环节：

说明目标 → 对齐范围 → 执行任务 → 回报证据 → 补充反馈。

同一个目标可能走好几轮。第一轮用来摸清问题，第二轮补边界，后面再核对结果。重要的是，每一轮都能知道自己正在解决什么，以及下一步还缺什么。

二、页面为什么乱跳：先把触发条件说准

在打牌记账页面里，我遇到过一个问题：给别人付账，准备输入金额时，页面会自动往下滚动。

最初，我的反馈是：

为什么给别人付账，会自动往下滚动？

后来又补充：

不应该自动滚动才对。

只要键盘弹起就会滚动。

“给别人付账”描述了场景，“键盘弹起”才进一步明确了触发条件。有了这句补充，排查就更容易聚焦到输入框、键盘和页面视口之间的关系。

在转交给独立执行任务的说明里，Dot 还保留了几个要求：金额输入必须可用、可见；背景不能无故跳动；已有工作和房间数据需要保留；取消、确认、重复进入以及切换收款人都要考虑。

这也让我意识到，修复异常时，需要同时说清楚正常体验应该怎样。 如果只是消除某个现象，却让金额输入变得难用，这个结果依然不符合我的需求。

从“改了什么”继续追到“验证了什么”

后续任务回报中，付款输入改为原生模态框，同时固定背景的几何和滚动位置。验证记录包括 28 项聚焦测试，以及 320、390、768 像素三种视口下的 Chromium 合成检查；该次检查中，背景滚动位置保持在 650 像素，金额输入仍然可见。

任务随后继续核对同一提交的检查状态，回报 GitHub CI 和 Vercel 检查通过。

但还有一个明确的缺口：真实 iOS、Android 设备上的键盘验证仍未完成。 该次回报中的 PR #11 也仍然是草稿、未合并。

我会把这些信息放在一起读：代码做了什么、检查覆盖了什么、哪些环境仍然没验证。桌面合成检查提供了证据，真机上的实际体验还需要另一次确认。

对非研发任务，这个习惯也适用。比如一份报告已经排版完成，还需要核对数据来源；一张图片已经导出，还需要看看实际投屏时的文字是否清楚。

三、一个业务反例，怎样让规则变得准确

另一个案例发生在应用的组合结果状态判断中。原来的处理方式比较粗：混合组合统一等全部比赛结束后，再显示最终状态。

我提出了一个具体情况：总共四场，组合里最少需要命中两场；如果已经有三场正式确认未命中，即使最后一场命中，也无法满足条件。

我的反馈大意是：结果其实已经确定了，剩余赛果可以稍后补齐，或者查看时继续同步。

这里补充的是一个业务事实：有些情况下，整体结果可以先确定，明细仍然需要继续更新。

Dot 据此修正了规则方向：先判断所有组合是否都已经失去中奖可能；如果已经确定，就显示相应状态；剩余结果继续补齐，同时保留官方纠错后重新计算的能力。

这个过程没有停在“理解你的意思”。后续记录里，这条规则被单独拆成草稿 PR #15，并回报了 47 项后端测试、74 项现有 UI 测试通过，以及继续检查提前判定后的刷新流程。再往后的消息中，CI 也回报通过，但仍明确写着草稿、未合并。

一个具体反例，帮助任务同时澄清了三件事：

• 哪种情况不需要等待全部明细结束。
• 状态确定以后，哪些更新还要继续。
• 后续事实发生变化时，结果是否能够重新计算。

如果我只说“这个状态不对”，这些条件就还藏在我的理解里。把一个完整例子交出去，才更容易让双方对同一条规则达成一致。

做文档、方案和流程设计时也可以这样反馈：指出具体哪种情况不符合预期，再说明为什么，以及希望看到什么结果。

四、PPT 做好了，为什么我还在继续反馈

这次分享稿的制作过程，本身就是第三个例子。

最开始，PPT 的中文显示出现问题。Dot 先做了一页字体兼容性试修，让我重新打开检查，但这一轮没有解决我的显示问题。

于是我继续反馈：

ppt 修复得不太行啊，能直接给我生成文件吗？

这句话把交付要求说得更明确了：我需要拿到实际文件，能够下载、打开、修改，并用于分享。

之后，Dot 转为提供可下载的 PPTX 和 PDF。交付说明里也区分了它们的用途：PPTX 用于继续编辑，包含逐页演讲备注；PDF 方便阅读和投屏核对。同时，记录明确提醒 PPTX 没有嵌入字体，换设备后仍可能替换。

这让我在交代文档任务时，多关注一个问题：这个产物最后会在哪里、由谁、用什么方式使用？

如果我要现场讲，就需要演讲节奏、投屏可读性和备注；如果要交给别人改，就需要可编辑内容；如果要跨设备阅读，就要考虑格式和字体。

后来，我又对分享稿提出“有些过于简单化”的反馈。稿件于是继续调整为章节页、关键数字、阶段时间线和证据卡片的表达方式。内容准确、文件可用和现场讲起来顺畅，是需要分别打磨的几个方面。

五、我怎样判断任务推进到哪一步

同时跟进几件事时，状态说明尤其重要。“已修改”“测试通过”“已经合并”“已经发布”，各自回答的是不同的问题。

我会这样理解：

任务回报	可以确认的进展	接下来需要关注的内容
已完成修改	已经有具体产出	改动是否符合需求
测试或检查通过	所述范围内已有检查证据	未覆盖的环境与场景
PR 仍是草稿	改动已整理，尚未合并	评审、验收和合并条件
已合并或已发布	对应阶段已经有状态回报	实际环境和使用效果
存在前置条件	当前推进受到依赖限制	需要谁补充什么信息或操作

在我的记录里，就有一次 App 修改的检查已经通过，但合并前还需要核实生产数据库里的两张表。另一次，我要求把 PR 与主分支同步；冲突处理完成后，任务又进入新一轮回归检查。

这些状态提醒我：新的改动完成以后，需要看与这一轮对应的证据，不能直接沿用上一轮的结论。

所以，我会继续问得更具体：

这次改了什么？验证了哪些操作？还有哪些环境没检查？现在停在哪一步？

这样的追问能帮助我决定下一步是继续补材料、实际验收，还是处理某个前置条件。

六、一条需求，我现在会补充这五项

我没有一套每次照抄的长提示词。但几个案例整理下来，有五类信息很常用。

目标：这次希望得到什么结果。

现状与材料：当前发生了什么，已有实现、原稿、截图或文档在哪里。

边界：哪些内容、数据或原有行为必须保留。

验收：执行什么操作，看到什么，才算满足要求。

本轮输出：这次先调查、给方案、修改、生成文件，还是只核对状态。

比如，基于键盘问题，可以整理出下面这条需求：

手机记账页打开金额输入后，背景会自动向下跳。我希望输入框保持可见，背景位置稳定，并保留房间数据和原有记账逻辑。请先调查触发原因，给出修改方案和验收清单，覆盖键盘打开、关闭、取消、确认、重复进入以及切换收款人，并说明哪些验证需要真机完成。

这是一条根据案例整理的示例。真正使用时，我会把已经知道的情况补进去，不确定的条件则继续确认。

每次输入不一定都要很长。比如追进展时，“核对这次同步后的 CI 状态，说明尚未验证的部分”，就已经比一句“现在怎样了”更明确。

七、把反复有效的做法留下来

有些要求只适用于当前任务，有些则会反复出现。

我的做法是，把本轮目标和验收写在当前请求里；把长期协作约定整理到 AGENTS.md，例如先检查再修改、保留无关改动、提交前核对范围；遇到专项任务时，再采用对应的 Skills。

这份固定说明也会随着实际使用调整。某种要求说过几次，或者某类问题反复发生，就值得把它写得更清楚。

本次内容整理还按我的约定使用了 TypeSafe：Jev 辅助判断候选案例适合放在哪类主题下，复杂的事实核对、结构安排和文章写作由 Codex 完成。这里的分工只描述本次整理过程。

对我来说，使用 Dot 的价值逐渐体现在这些连续的小动作里：把触发条件补准，把反例说完整，把交付方式讲清楚，再追问一次证据和缺口。

下次再交出一个任务，我仍会先补上那句最容易遗漏的话：

满足什么条件，我才会认为这件事完成了？

记录截图

以下为当时的真实记录裁切，仅用于说明案例过程。截图中的状态以消息发生时为准。

1. 键盘任务的阶段结果

CI 和 Vercel 检查通过，PR 仍是草稿，真机验证仍待完成。

2. 具体反例与规则调整

从明确的业务反例，继续到独立任务的创建。

3. PPTX 与 PDF 的交付说明

文件用途与字体限制，都需要在交付时说清楚。