个人使用体验｜2026-10-23。本次不是同条件对照测试；上下文、工具权限及追问轮次未统一，未据此比较底层模型强弱。
最近我一直想让 AI 更深入地参与工作。平时用 ChatGPT 讨论方案、Codex 做工程实现，偶尔通过 Work 处理多步骤任务。工具越用越多，历史讨论却越来越分散：某次决策为什么做、后续还有什么没完成，常常需要翻好几个地方。
所以我很期待 Dot：它能检索我在 ChatGPT、Work、Codex 中的相关工作记录。但能找到过去的上下文，是否就能更好地帮我想清楚下一步？ 实际体验并不完全符合我的预期。
一、我拿一个真实问题试了试
为了保护业务隐私，我把场景抽象成普通的软件研发团队：产品、研发、业务角色协作，项目持续迭代，但当前交付版本和下一设计版本不清晰；部分需求通过口头沟通进入开发；阻塞事项缺少明确的推进责任人。
我需要的不是一套标准化 Scrum 制度，而是一个能在现有工具基础上落地的轻量迭代机制。我给 Dot 的背景包括：已有成果、角色分工、确定与未确定事项、当前阻塞和我希望它如何与我讨论。
二、Dot 能理解问题，却没能充分推动讨论
Dot 能识别版本管理、职责分工、评审和交付等主题，给出的方向并非明显错误。但在我的使用中，回答通常偏短。
例如，我更想知道：设计到什么程度才能进入开发？紧急需求怎么插入？当前交付版和下一设计版如何并行？谁推动解除阻塞？这些细节往往需要我一再追问。
第二个差异是研究过程：我希望 AI 在必要时主动检索 Scrum、Kanban、持续交付等实践，再结合小团队的约束比较取舍；但 Dot 在这次交流中没有充分展现出这样的研究与推演过程。
最明显的是多轮共创。工作问题常常从“版本编号”逐步深入到“产品交接标准”和“阶段验收”。我期待 AI 能发现这种关键转变，而不是只回答当前一问。
三、继续在 ChatGPT 聊天，体验不一样
我在 ChatGPT 聊天模式中讨论同类问题时，体验更接近“共同推演”：从版本范围聊到需求准入、设计交接、研发排期、阻塞解除和验收标准；当我补充团队暂时无法稳定按双周节奏发布时，讨论也能转向先建立最小规则，而不是生搬固定周期。
我更看重的不是回答字数，而是识别矛盾、提出备选、说明取舍、根据新条件调整方案。在需要资料依据时，聊天模式也更符合我希望主动查资料的使用习惯。
但这不是严格的模型能力实验：两种模式的上下文、工具权限、追问轮次未必一致。同一匿名化提示词、相同工具权限和追问轮次的对照，仍有待补做。
四、Dot 的一个优点，反而让我想继续使用
Dot 对我最有用的，是跨工具查找和整理工作上下文。当我忘记某项决策在哪次 ChatGPT 聊天里讨论，或想汇总一段时间内 Codex 和 Work 的相关记录时，它能帮我减少手工翻找。
这并不代表检索覆盖完整。重要结论仍需回到原始记录核对，尤其不能把总结里的推测当作既定决定。
五、我开始区分三种 AI 工作模式
| 模式 | 典型任务 | 关键评价标准 |
|---|---|---|
| 任务执行 | 按明确目标整理报告、完成任务 | 是否准确完成并可验收 |
| 上下文检索 | 查找历史讨论、归纳记录 | 来源是否可靠、覆盖是否充分 |
| 方案共创 | 设计流程、架构、产品方案 | 是否主动分析、比较取舍、持续修正 |
检索到上下文，不等于充分利用上下文；回答更多文字，也不等于思考更深入。 我真正需要的是识别关键矛盾、提出可行方案、指出风险，并在后续讨论中修正判断。
六、你也可以复现这个对比
可以用一个不涉及商业秘密的题目：
我负责一个四人研发团队，当前产品设计、开发和测试之间常有临时变更。团队已有任务管理工具，我想建立轻量版本机制，但不希望增加太多流程。请先分析关键问题，必要时查找成熟实践，与我逐步讨论可执行方案，不要直接给一套复杂制度。
尽量统一上下文、工具权限和追问轮次，保存原始回答。重点比较四项：问题理解、外部资料依据、方案可执行细节、多轮调整能力。
七、目前我怎么分工
ChatGPT 用于开放性问题讨论；Codex 负责代码和工程任务；Work 处理跨步骤研究和执行；Dot 负责跨工具历史检索、整理和目标明确的任务。
这只是我的个人使用经验，不是产品能力的普遍排名。随着产品变化，结论也可能变化。
AI 能找到我过去想过什么，不代表它一定能帮我把下一步想得更清楚。
你是否也用过 Dot？有没有找到让它更适合复杂方案讨论的方法？
