让 AI 自己干活之前，先教它检查工作 根据 Andy 分享的 Lauren Tan 视频整理，适合没时间看完整视频、也没有编程基础的朋友。 你让 AI 做一件事，它很快回复：完成了。 可你打开文件，发现内容漏了；试一下它做的功能，又发现按钮没反应。你只好把问题发回去，等它修改，再检查一遍。 来回几次，AI 一直在忙，你也始终没能离开。 工程师 Lauren Tan 的这次分享，就在讨论怎样逐步改变这种状态：让 AI 承担更多工作，同时具备检查结果、发现问题和继续修正的能力。 她主要谈软件开发，但其中不少方法，普通 AI 用户也能用上。 一、把“检查结果”也交给 AI 先解释一个词：Agent，通常译作“智能体”。在这次分享里，可以把它理解为能调用工具、操作软件、执行任务的 AI 助手。 它能动手做事，但执行结果仍然需要验证。 Lauren 早期也需要紧盯着 AI。它会非常肯定地说找到了错误原因，可继续检查后，才发现它没有看清实际情况。 于是，发现问题的是她，传递截图的是她，检查改动有没有用的还是她。AI 承担了部分执行，她仍然负责连接各个环节。 她开始把验证能力补进工作流程。 例如，一个按钮原来点不动。AI 修改以后，应该重新打开软件、点击按钮，观察该出现的结果是否真的出现。如果仍然有问题，就收集运行记录，继续寻找原因。 这就是“验证”：拿实际结果检查任务有没有完成。 换成一个办公场景更容易理解。 假设你让 AI 做一张自动计算平均分的成绩表。它说已经填好公式，还需要输入几组已知数据，核对计算结果，再看看空白或缺考记录会怎样处理。 这个成绩表例子是我补充的类比。它对应的变化是： 把任务的终点，从“做出来”延长到“做出来以后检查是否能用”。 当然，一次检查通过，不能证明所有情况都没有问题。但它让“完成”有了可以观察的依据，也让人能根据实际表现逐步增加信任。 二、给 AI 一份具体的工作地图 接下来，Lauren 又发现了一个问题。 AI 即使能操作软件，也未必知道用户说的功能在哪里。用户反馈“侧边栏有问题”，它可能连这个侧边栏怎样打开、包含哪些功能都不清楚。 于是，她给 AI 补上一份“功能地图”。 你可以把它理解为给新同事的工作指引：要处理什么问题，先进入哪个页面；哪个按钮对应什么功能；完成操作以后，应该看到什么。 刚来的同事会用电脑，但他仍然需要知道： 报名表存在哪里； 哪个文件是现行版本； 哪些资料只能参考； 最终结果要交到哪里。 AI 同样需要这些信息。 它拥有通用能力，却不天然了解你的软件、文件和工作习惯。把入口、对象、操作路径和预期结果交代清楚，才能减少它的猜测。 这对知识工作尤其有用。让 AI 整理资料之前，可以先告诉它原始材料在哪里、来源怎样记录、整理结果保存到哪里、哪些判断需要留给自己。 这些信息写清楚一次，以后就能反复使用。 三、把反复纠正的话，整理成固定方法 Lauren 的工作流，是在使用过程中逐步形成的。 她观察 AI 怎样工作，发现它反复犯的错误，再把应对方法保存下来。 例如，AI 还没有阅读相关内容，就开始解释问题。她便把“先查清实际情况，再下判断”的方法整理成可以重复使用的说明。 这类说明被称为 Skill。 可以把它理解为：AI 遇到某类任务时，会翻开的操作手册。 Lauren 把自己积累的一批方法组织成了名为 pstack 的插件。 对于普通用户，也可以从自己反复提醒 AI 的话里寻找线索： “引用数字时附上出处。” “修改前先读完相关内容。” “没有找到依据的地方，明确标出来。” “完成后检查文件是否保存、链接是否有效。” 如果同样的话每次都要说，就值得把它整理成固定流程，让 AI 下次遇到相似任务时按流程执行。 但手册写出来以后，还需要检查它到底有没有用。 四、用实际任务检验这些方法 这就涉及另一个词：Eval，也就是评测。 直白地说，就是给 AI 安排有明确要求的任务，观察它是否做到了。 例如，你整理了一套“资料总结流程”。接下来可以用不同材料试几次，看看： 它有没有遗漏关键条件； 能不能区分作者观点和已经证实的事实； 引用是否能回到原始来源； 不确定的地方有没有说明； 换一份材料后，这套流程是否仍然有效。 Lauren 会通过评测观察 Skill 的表现。随着软件和工作方式变化，这些说明也需要维护。 因此，一套方法的价值，要通过实际工作来判断：它是否减少了错误，是否减少了来回修改，是否让结果更容易检查。 这也解释了为什么别人的提示词或工作流，拿来以后经常还需要调整。任务、资料和工具环境不同，效果也会不同。 五、能明确判断的错误，可以交给系统拦住 Lauren 进一步发现，有些要求仅靠文字提醒还不够。 AI 可能忘记，也可能理解错。对于能够明确判断的错误，她会把要求做进自动检查流程：一旦违反，系统就报告问题。 软件开发里有一个常见词叫 CI，可以简单理解为：每次提交改动后，系统自动按规定检查一遍。 例如，改动有没有破坏原有功能，某些部分之间是否出现了不允许的依赖。 她也会整理软件内部结构，让相关功能更容易找到，让正常操作的路径更清楚。这类整理通常叫“重构”。 这些工作都在改善 AI 的工作环境，让它更容易做对，也更容易发现自己做错了。 放到普通人的工作中，同样可以找到适合自动检查的部分： 文件是否存在，链接是否有效，表格有没有缺列，必填信息是否完整，计算结果是否符合已知样例。 至于观点有没有说服力、内容是否真正适用、自己是否认同，仍然需要人判断。 六、这些基础，怎样支持更多 AI 一起工作？ 看到“一个人管理很多 Agent”，大家很容易先关注数量。 Lauren 的分享补充了另一个值得关注的部分：当更多任务交给 AI 以后，怎样让工作持续推进，并且留下可以检查的结果。 功能地图帮助 AI 找到工作入口；Skill 帮助它按已有方法执行；验证工具让它检查结果；自动检查则能及时暴露一部分错误。 这些基础逐步建立起来，更多 AI 才能沿着相对清楚的流程分工。 她举过一个例子：名为 Benny 的 AI 助手接到问题报告后，先去重现问题，结果发现开发中的最新版本已经修复。接下来需要做的是把修复发布给用户。 这个例子很具体：AI 先核对现状，便能减少重复劳动，也能判断下一步真正需要做什么。 她还自述，有一次醒来时，约 20 个 PR 已经合入。 PR 可以理解为一份待检查和接收的软件修改提案；“合入”就是把修改接收到共同使用的代码版本中。 这是她分享的个人经历。更值得普通用户借鉴的，是支撑这类协作的过程：任务有入口，执行有方法，完成有依据，出错后能够继续处理。 七、普通人可以怎样开始？ 不需要先搭建一整支 AI 团队。可以从一项自己反复要做的工作开始，把它补成一个完整流程。 例如，让 AI 整理一段视频。 过去可能只说：“帮我总结这个视频。” 现在可以把要求讲得更具体： 请先取得可用的字幕或转写，记录视频来源。 按主题整理主要观点，遇到术语时用普通人能理解的话解释。 区分作者观点、案例和你补充的解释。 对关键数字、人物和结论检查依据；暂时无法核实的内容单独列出。 完成后，检查是否遗漏重要部分，确认文件已经保存、引用链接有效，再交付给我。 这里的示例是我结合她的方法作出的应用解释，并非视频原话。 同样的思路也可以用于整理会议、制作表格、收集研究资料、准备课程。 先选一项任务，观察 AI 会在哪一步卡住、哪些错误反复出现，再逐步补充操作说明和检查方法。 八、也要看到背后的投入 Lauren 在分享中提到，自己在 AI 实验室工作，拥有非常充裕的 token 条件。 Token 是模型处理文字等信息时使用的计量单位，调用模型通常会消耗额度或产生费用。 同时运行多个助手、反复评测、整理软件结构，都需要资源，也需要前期建设。 因此，借鉴她的方法时，可以先看一项工作是否足够重复、节省的时间是否值得这些投入。 偶尔做一次的小任务，简单交代清楚就够了。经常做、容易漏、每次都要反复检查的任务，更适合逐步建立固定流程。 从这段分享里，我最想带走的是一个很实用的动作： 下次交给 AI 一项工作时，除了告诉它要做什么，再把“怎样检查自己做得对不对”一起交代清楚。 当这种方法逐渐积累下来，AI 就能承担更完整的一段工作，人也能把更多注意力放在理解、选择和判断上。