你如何与 AI
共同工作

这一天，你与 AI 的协作已呈现出“小型工作室”的形态：你负责提出问题、判定体验、定义价值和作出取舍；AI 负责研究、提问、试作、编码、素材制作、检查和文档整理。你在不同对话之间安排任务，查看产物后修正方向，并把部分做法沉淀成下一次可以调用的工具。

最有效的协作发生在你把判断变成可检查条件的时候。“保留孩子作者权”“可以纠正与停止”“在同一个房间完成动作”“直出三件服装”“一段故事怎样才算一本书”，都比泛泛要求更能决定产物。图像、网页和视频又让你可以针对实际结果继续判断。

最大的摩擦来自任务和状态增多后，你仍承担着大量同步与审校工作。主产品长对话不断推进，Pitch、首用引导、两类视频和宣传又分支展开。每一条新指令都可能需要进入多个产物。较晚才具体化的质量标准进一步增加了回头修改的范围。现有记录支持这一协调压力的判断，但没有证据证明某次压缩、分叉或模型切换直接导致了特定错误。

从综合工作模式看，你具有很强的方向控制和产物判断能力；还可以进一步把这些能力写入稳定的任务合同、当前状态和验收制度。推理预算已经偏高，下一轮值得优先改进的是交付条件的清晰度、分支同步和验证覆盖。记录不足以计算 AI 节约了多少时间或成本，也不能据此判定哪款模型最好。

“今天”按这次黑客松的 10 月 11 日 GMT+8 理解；10 月 12 日 00:00–00:19:11 作为跨午夜收尾。本轮审计及正在生成的复盘不计入当日行为。

以上是事件顺序，不是工时表、连续在线时长或多任务效率排名。

覆盖分三层。第一层是封存的本项目工作记录：13 个主会话、59 个执行子代理会话及 3 个自动审查会话；本轮新分析会话排除。第二层是同日额外核对的 6 个新本地任务、1 个前日创建但当天延续的原型 Skill 会话、1 个晚间辩论队会话，以及 1 个远程本地模型调度会话。另检查了一个旧发布流程会话，其原始文件中未取得本时间窗的新模型上下文，作为背景材料，不计入当日活跃任务。第三层是 16:00 起的 Computer History，封存到次日 00:19:11。

16:00 前的界面操作无法由 Computer History 补证；21:57 至次日 00:13 的采集缺口也不能被解释成休息、离线或停止工作。其他项目的所有旧会话是否在当天恢复，未逐一穷尽。因此，这是一份覆盖主要已取得证据的综合工作模式复盘，无法声称重建了全天每一次 AI 交互。

你当天的交互可以分为六种。它们各有适用位置，表现最好时能够相互衔接。

这些方式表明，你在观察产物后会改变自己的要求。3D 尝试后回到 2D，允许通过低成本试作更新判断；结束提问后开始制作，又避免了持续停留在讨论。

关键摩擦：模糊形容词留给 AI 的解释空间过大

“文字太多”之后又出现“引导不够”，最后收敛为图形与文字并用。这组反馈表达的是两个同时成立的要求：减少阅读负担，又要让首次使用者知道下一步。若 AI 把第一句直接理解为删掉提示，就可能偏离完整意图。较好的开场表达是：保留哪三条必须理解的信息、分别在何时出现、以何种形式出现，以及哪个动作算成功。

18:16 的成书质量要求把产物标准具体化：原始一句话怎样扩成有结构的绘本，怎样保留孩子的意图，图画怎样与文字对应。它对后续实施有决定性价值，同时说明此前“生成了绘本”与“绘本质量达到你的标准”之间仍存在空隙。建议把一个合格样例和一个不合格样例放到实施前，并把未知质量列入试验目标。

你的短指令为什么有时有效

“三件直接展示”“1.5 倍快放”“回到 2D”建立在已有产物和共同历史上，信息量实际很高。脱离相同版本，这类指令便可能失去参照。改进时无需把每条消息都写成长提示词，只需补上 目标产物／版本、具体改变、仍然有效的约束，尤其在分叉、压缩或换任务之后。

你倾向于给 AI 一段完整工作：调研、实施、检查、整理文档，甚至发布更新；当体验偏离、阶段已经够用或方向需要变化时，再通过新消息、历史消息编辑、停止与分叉进行控制。这种协作适合任务可以逐步验收、产物容易回看的情况。

Computer History 中直接命中相关控件的记录包括 14 次“Edit message”点击、4 次“Stop”点击、5 次“Fork chat from here”点击。这些是按钮操作观察，不等于 14 次编辑提交、4 个失败任务或 5 个成功新分支。首用引导的分叉曾连续点击两次，实际取得一个新会话。

18:14–18:16 附近出现编辑、停止和质量要求重写，随后 18:16 的用户消息明确了成书标准。可确认你在此时主动改变工作合同；无法从按钮点击反推出每一次停止的内部原因。3D 回退附近也有停止操作，记录只能支持时间邻近，不能证明它具体取消了哪一步。

这种控制方式的收益是让判断保持在人手里。你的作者权要求、第三种成功状态、减少无意义选项以及停止提问，都是针对产品目的的实质判断。代价是长任务中出现新要求时，已完成部分与继续执行部分都要重新对齐。更适合的节奏是先声明 AI 可以自主完成到哪个检查点，并要求它在检查点交出可检查结果，再决定扩展方向。

法通会话提供了当天较完整的范例：先调研方案，随后同意实施，同时要求独立分支、验证、验收报告、代码审查和你的审批；之后你表示已确认合并，再要求版本发布。这是对不同阶段分配不同权限的证据。该表述记录了你的授权与确认，本报告没有重新检验发布平台或合并收据。

本项目的 13 个主会话由 8 个独立根会话与 5 个 Tell 分叉构成。下表“任务角色”是审计归类；带引号的名称是应用返回的会话标题。主会话之外的 59 个子代理属于执行分工，不能视为你手动创建了 59 条平行聊天。

“主上下文”按独立 turn ID 去重；它不是调用次数或发言数。当天取得 150 条本项目用户请求，其中 90 条归属于 Tell 主线；同一轮可接收多条补充消息，两者不能直接相除计算效率。

分叉的收益

Pitch 和视频能够带着产品背景启动；你无需从头介绍所有机制。分叉还使不同输出形式可以各自迭代，主产品保持推进。宣传使用独立目录，也便于管理它自己的交付物。

分叉的代价

分叉继承的是某个历史时点，此后主线的新决定需要另行同步。Pitch、首用引导和视频应采用哪一版产品事实，不能只靠“来自同一个项目”保证。多数 Tell 分叉继续使用同一项目工作区；会话分开与文件隔离是两回事。现有材料未证明发生了由并行编辑造成的覆盖或回归，应把它列为需要管理的条件，而非已经发生的事故。

目前“(2)–(5)”标题主要表达创建顺序。对你快速切换尚可，对后续检索或交接帮助有限。建议按 项目／阶段／输出／版本 命名，例如“Tell／Shipping／Pitch／v1.0”，并在每条会话首部列出它负责的文件、读取的事实版本和结束条件。

你的优势是会主动保存上下文。前期明确要求阅读交接稿并继承已讨论的问题；14:04 分出制作说明，要求记录交互、决策和技术选择；之后要求代码讲解；跨午夜又为辩论队准备 Work 迁移文档。这些动作让工作可以脱离一条聊天继续推进。

当日 13 个主会话共取得 41 个归属明确的压缩事件；Tell 主线 13 个，音乐 9 个，Moonlit 8 个。统计剔除了子流继承父对话造成的重复。压缩是长会话管理行为，其数量能说明需要反复重新整理上下文，不能证明记忆已经丢失，也不能解释某个具体实现错误。

三种上下文应当分别维护

制作说明擅长保存“怎样走到这里”，工作分支更需要“现在应该采用什么”。建议保留一份简短的 CURRENT_STATE.md，每次重要决定后更新；历史决策另放在追加式 DECISIONS.md。新会话先读当前状态，再按需要查历史，而不依靠整段聊天推测现状。

编辑历史消息需要补一条变更记录

介绍片分支的会话元数据仍保留原始制作任务的摘要，但当前首条用户消息已经显示为“1.5 倍快放”修订。它说明回看首条消息未必能恢复最初完整任务。建议使用“新增变更消息＋版本号”；若选择编辑，则同步写一条“改了什么、从何时生效、影响哪些产物”。现有审计对无法取得的原文保留缺口，没有补造时间线。

原制作说明曾请求“思维链”。可移交、可审计的应是可见的决策依据、交互记录、实验结果和技术取舍。本复盘没有提取或推断模型的私有内部推理；一篇解释文档也不自动等于完整制作历史。

本项目 13 个主会话取得 142 个独立 turn ID，其模型与推理级别组合如下。配置名按历史原始记录保留；这里只评价当天使用行为，不对当前产品能力、价格或模型排名作推荐。

这组分布支持“黑客松工作倾向使用高推理预算”。同日额外任务也有 medium、high：法通接入会话出现 Sol／medium 与 Sol／ultra；每周复盘与晚间辩论队分别出现 Sol／high、Astra／high。因此，不能把黑客松统计扩展为你全天所有任务都使用 xhigh／ultra。

Tell 主线的配置变化

主线期间需求复杂度、任务形式和质量标准也在变化，不能把某个更好的产物直接归因于一次切换。纸船画错六次后换用生成备用模型的记录也表明：产品图像的语义正确性，需要针对生成模型与样例直接检查；提高编程助手推理预算不能代替这一验证。

能由界面选择与后续运行相互印证的例子

• 18:19:30 点击 Astra；18:19:35 首用引导分支取得 Astra／xhigh 上下文。
• 18:24:43 点击 Astra；18:25:02 介绍片分支取得 Astra／ultra 上下文。
• 21:24:18 点击 Astra；21:24:32 辩论队报名任务取得 Astra／high 上下文。
• 次日 00:19:02 点击 Sol；封存窗口内缺少足以确定后续哪项工作使用它的记录。

界面合计观察到 7 次“Select model”菜单点击、4 次明确模型选项点击。只是切换到另一个已有不同配置的会话，也会改变菜单显示；不能将所有标签变化计为你的选型动作。

下一轮的选择方法

先按任务需要选择推理预算，再看返工与验证结果。可试行：常规改字、重排和格式转换使用较低预算；多约束实现使用中等或较高预算；问题定义、架构取舍和复杂故障升级预算。上述是待验证的工作策略，不保证某个级别一定更好。

用几类固定样例比较 第一稿可用程度、需要你纠正的次数、端到端等待和实际费用（若可取得）。固定输入、验收条件和工具权限；升级时记录要解决哪个失败。当天记录没有这样的对照，无法断言 ultra 是否划算，也无法将模型等待时间与电脑前时间等同。

三层会互相影响，但评价指标不同。主助手把代码写对，不保证图像画对；一个媒体备用模型修复了某个样例，也不能证明它改善了主对话的规划能力。

59 次 spawn_agent 调用均未提供显式模型或推理级别参数，56 次未写 fork_turns，3 次写 all。实际运行取得的 Sol／xhigh 是运行环境的结果，不能解释为你亲自作出了 59 次模型选择；也不能根据参数缺省断言每个子代理都读过全部历史。部分任务说明被加密保存，本报告不解码或补造其内容。

执行消息中大量回报、追问和追加任务，说明协调本身是一项工作。次数不代表协调质量。较好的委派单位是一个能够明确核验的成果，例如“提交一份含来源与限制的竞品表”“实现这个隔离目录的组件”“审查这一个版本的变化”，并写明收到结果后由谁整合。

远程本地模型调度任务显示，你还在设计 AI 工作的基础设施：模型怎样按内存切换、生成服务怎样开放、内容怎样保留、体验 Key 拥有哪些能力。当天 02:32 的要求包括恢复文本模型与提供快捷切换，13:33 又要求创建文本／图像／视频体验权限。这里的协作体现了对运行条件和控制面的关注。现有会话末尾的服务验证是历史助手报告，本次没有重测；体验 Key 的鉴权验证也不等于该轮执行了三种真实生成。

当天并非只有一个产品会话。你一边探索多个儿童 AI 方向，一边维护已有工具、安排实际事务，又把经验整理为新流程。这有三个值得保留的特征。

第一，你会把 AI 交付接入已有工作体系。法通任务要求分支、验收、PR、审查与审批；后续安装沿用实际 Skill 目录、保留授权状态，再检查登录并进行文章核验。它形成了“开发—安装—就绪检查—应用到真实内容”的闭环要求。这里评价的是任务组织方式，结果以原会话的具体收据为准。

第二，你会把判断成本较低的生活事务交给 AI。早餐委托通过补充偏好与收餐信息推进。它扩展了助手的用途，也说明并非每个任务都需要长篇规划。缺失的信息可以一次性补齐，完成条件则应对应实际订单状态。本复盘不把草稿、询问或界面操作算作已下单。

第三，你会把今天的执行经验转为未来的工作能力。原型验证 Skill、21:02 的视频流程抽离、每周电脑使用复盘和 Work 迁移，都是这种行为的例子。复盘自动化当天还要求试跑；这是一种先检查方法再长期复用的做法。是否已经发布成功、是否持续执行，需使用各任务的收据，本报告没有新建或改动这些流程。

这种模式有很高的复用潜力，但多个工具维护任务与主交付交错，也会增加切换和追踪成本。建议区分三个队列：正在交付、阻塞交付的工具问题、可稍后沉淀的改进。工具问题若不阻塞当前交付，先记下明确需求，留到固定收尾时段处理。

这一天的记录显示出较强的好奇心、行动倾向和产物判断参与度。这是工作行为描述，不能由凌晨活动、停止按钮或频繁切换推断焦虑、疲劳、心理状态或睡眠情况。

最终产物显示 AI 可以把你的构想扩成较完整的交付组合。真实儿童是否愿意使用、能否理解并控制它，仍需要用户验证；不能由成年人的试用、录制 Demo 或模型生成质量代替。

证据整理本身也有误归因风险：此前工作评估曾把 Moonlit 的解除额度请求与 Tell 后来的 300 次供应商限制连写，现已保留勘误。它提示后续模型分析应始终带项目 ID、会话 ID 和来源编号；相似主题和时间邻近不足以合并事件。这是审计分析中的归因错误，不能据此推定你原有协作失误。

优先改三件事：把质量标准前置，把当前状态写成文件，把分支交付绑定到同一版本。它们直接针对当天已见摩擦。无需先把所有任务改造成复杂流程。

1. 开始研究或制作前，用一页写清目的与结束条件。包含目标用户、价值判断、可做与暂不做范围、一个成功样例、一个失败样例，以及你亲自验收的部分。AI 可以先复述和指出冲突，再执行。
2. 重要决定后，更新当前状态并发出变更摘要。说明决定、理由、影响的任务、旧方案是否放弃；在 Pitch、视频和宣传开始前明确采用哪一版。
3. 每个分支只承担一个可交付结果。指定读取材料、可写目录、模型预算策略、检查点和整合负责人。共享业务文件需安排唯一主责；只做素材或说明的分支使用独立目录。
4. 验收区分四种状态。产物文件已生成；技术检查通过；你已按样例审阅；外部平台已收件或确认。每项分别写证据，未确认就保留为待确认。
5. 交付后再沉淀 Skill，并保留一次真实试跑。整理适用前提、失败与恢复方式、输入输出和权限；不要把一个样例的成功写成通用承诺。

可复制：分支任务卡

项目与任务：
本次交付物：
采用的当前状态：CURRENT_STATE.md，版本／时间／代码提交：
先读取：
允许写入的目录／文件：
必须保留的约束：
成功样例／失败样例：
AI 可自主完成到：
需要我判断的检查点：
模型与推理预算：先采用＿＿；遇到＿＿再升级，并记录原因。
验收：技术检查＿＿；人工审阅＿＿；外部收件＿＿。
交回：文件链接、验证证据、限制、对其他分支的影响。
整合负责人：

可复制：新一轮修改与模型升级记录

目标产物与当前版本：
看到的具体问题：
本次修改／试验：
继续有效的约束：
为什么现在修改：
影响的分支与文件：
完成条件与检查样例：
若需要升级模型：要解决的失败＿＿；保持相同的输入与验收条件。
修改后结果：通过／未通过／需要人工确认。
同步到 CURRENT_STATE.md，并通知相关任务读取更新。

下一次复盘只需额外记录少数数据：有多少任务首稿达到最低可用条件；哪些修改源于标准后定，哪些源于执行错误；分支是否用了正确版本；你等待和审阅了哪些环节；如果能取得账单，再加入实际费用。以这些结果衡量模式的变化，比增加会话、代理或推理级别的数量更有用。

本文依据当时留存的对话、项目文件、历史验收与指定时段的电脑使用记录形成。事实、复盘判断和改进建议分别评价；时间邻近和配置变化本身不能证明因果。

这份公开阅读版收录报告正文。原始会话、项目文件、编辑记录及联系方式保留在本地审计中，未随本站发布。后来补充的线下背景与得票结果见《让 AI 听孩子讲故事》制作手记。