Claude 工程负责人：别再给 AI 搬运任务

Felix Rieseberg 曾经这样使用 Claude：发现一份崩溃报告，复制过去，让它修复；再发现一份，再重复一次。后来他意识到，自己已经成了 Claude 的传送带。

他改了工作流：让 Claude 能够访问相关崩溃数据，自己判断哪些问题需要处理。人要先把数据和工具接好，模型才能接手更完整的任务。

这个变化击中了主持人 Marina Mogilko 的困扰。她管理着一个 35 人团队，大家已经大量使用 AI，但产出仍要经过团队，再送到她手里。生产变快了，最后拍板的人却越来越忙。

这场对话围绕同一个问题展开：当 AI 能做的事情越来越多，工作该怎样重新分配？

先想清楚，任务完成之后要发生什么

Felix 说，他现在花很多时间做原型：提出不同想法，让 Claude 做出来，再比较哪些值得保留。过去工程管理者要先估算开发、维护和机会成本，如今不少问题可以先做出东西，再拿到用户面前判断。

成本下降后，人的注意力依然有限。他用一个夸张的对照解释这件事：即使能做出 1000 个原型，也可能每天只能请别人认真看 1 个。这是对注意力瓶颈的说明，并非经过测量的产能指标。

他判断产品有没有价值，会看用户能否很快理解它，能否借它完成过去做不到的事。增加按钮很容易，决定哪些按钮根本不该出现，需要理解使用者。

因此，他把 AI 的用途分成自动化和能力扩展。自动化节省重复劳动；能力扩展让人越过原本欠缺的知识、技巧或工具门槛。后者通常要求重新安排工作。

一个有用的追问是：完成眼前这项任务，是为了让什么结果发生？ 逐条修崩溃是任务，改善软件稳定性是目标。写出一份分析是任务，帮助团队作出更好的决定是目标。目标足够具体、能够验证时，模型才有机会选择更合适的路径。

专业能力，藏在方法和工具里

给模型加上“顶级专家”的头衔，可能只会换来更像专家的措辞。Felix 更关心它有没有使用这个领域真正有效的方法。

他举了天气查询的例子。模型猜中气温，不应自动获得好评；如果它确认了地点、找到可信的数据源，即使结果偏差 0.5 度，过程也更值得信任。可靠的来源和可检查的步骤，决定了下次还能不能做好。

创作也有过程。Felix 提到作家 Adam Davidson 会让 Claude 强化一个论点、寻找最有力的反驳、指出自己不认同的地方。写作被拆成可以反复推敲的动作，审美才有机会进入工作流。

谈到动画与 3D 内容时，他提到 Opus 5.5，也强调了 Blender 这类专业工具的作用。他自己不会用 Blender，却能让 Claude 制作网站里的三维素材，再判断效果是否合适。这是他的使用经验，不能据此推导出任意创作任务都已得到解决。

这里可以提炼出一个更具体的要求：先列出优秀从业者会使用的原始资料、工具和步骤，再实际使用它们。专业词汇只是表面，方法必须进入执行过程。

制作和验收，放到不同的会话里

模型说得很有把握，并不代表它说对了。Felix 最直接的办法是对抗审查：让另一个会话带着挑错的任务检查成品。

他以自己的博客为例，会启动 5 个独立讨论，让它们分别尝试推翻文章：事实是否错误，推理有没有跳步，是否误解了问题。随后，再由一个独立的“裁判”判断这些批评是否成立，把有效意见交回原来的写作者。这套做法可以在原视频的审查讨论中找到。

批评也需要审查。有些意见看似合理，却偏离目标，或者无法执行。找到漏洞有时比从头创作容易，因此审查者未必总要使用最昂贵的模型，但效果仍取决于任务。

Felix 不愿意依赖同一个会话给自己的作品打分。 他更喜欢来自外部的硬证据；另开一个 Claude 会话，是缺少其他验证手段时的补充。

他对自己的一种编辑核查流程表达了 100% 的信任：要求 Claude 为演示文稿里的每个数字找到可靠的一手来源。这描述的是他的信任程度，访谈没有提供证明正确率达到 100% 的独立测试。

这层区别很关键。几个会话互相同意，仍然不能替代原始数据、实际运行结果或用户反馈。审查的价值在于暴露问题，并把判断重新接回证据。

数据按需读取，Skills 定期重新检验

Felix 使用项目组织不同工作，但很少先给模型安排固定人格。他认为，通用模型本来就能跨领域工作，过早划定“这个只做研究，那个只懂财务”，可能限制它利用相关信息。

工程负责人如果只能看代码，很难理解客户真正遇到的问题。客户沟通、使用情况、业务结果，都可能影响判断。AI 也需要相应的视野。

这并不要求把所有资料一次塞进对话。Felix 的做法是提供工具，并清楚说明每个工具背后有什么数据，让模型按需查找。实施时，数据访问仍应限于任务相关且已获授权的范围。

搬运崩溃报告的故事，正是这套思路的缩影。前期要投入时间接通数据，之后才能减少人反复找资料、复制、分派的劳动。

Skills 同样需要重新检验。他说团队仍大量使用 Skills，只是模型更新很快，为旧模型写下的细碎指令，有时会让新模型表现更差。有明确评估标准的人，可以比较保留和移除某条规则后的结果，再决定是否继续使用。

这项建议的前提是能够判断好坏。没有对照结果，就无法知道一条规则是在保护质量，还是已经成了负担。

谈到入门，Felix 建议先用桌面端的浏览器能力试跑真实工作，观察流程是否有用。等效果得到验证，再考虑接入更高效的连接器。先获得一次可观察的结果，通常比一开始设计庞大的系统更容易校准方向。

把历史反馈变成可以校准的判断标准

主持人用一个大致比例描述她的工作：最后发布的内容可能保留了 Claude 的 70%，另有 30% 来自她的修改。她认为自己的口味就藏在这些修改里，但反馈散落在聊天记录中，下一轮生成并不一定能用上。

Felix 给出了一套从真实材料出发的方法：收集过去的反馈，把它们整理成规则和原则，再请模型提出一些可能存在、但本人尚未明确表达的偏好。最后这些偏好仍需要本人确认。

例如，反复出现的修改可能揭示作者更重视具体案例，或者不接受没有来源的数字。这样的标准来自已经作出的选择，比一开始凭空写出一份完整风格指南更容易核对。这两个例子是对方法的解释，并非访谈中对主持人口味的判断。

信任也可以逐步建立。Felix 建议把人工审查和 AI 审查并排运行：人先独立写下意见，再比较 Claude 会怎么评，观察它漏掉了什么、误判了什么，以及哪些地方已经接近。

几轮比较之后，团队才更清楚哪些工作可以放手，哪些仍要人工复核。他也提醒，同一个人周一和周五看同一份材料，意见可能不同。审查标准可以校准，但很难做到毫无波动。

从这套方法可以推得一个实际要求：反馈必须重新进入后续工作。否则团队只会更快地产出需要管理者重看的内容，最终的瓶颈仍然留在同一个人身上。

执行变便宜，理解用户仍然费功夫

软件更容易制作，会不会让现有产品失去价值？Felix 认为，用户仍会为真正解决问题的好产品付费。人们喜欢一个工具，通常因为它把需求处理得很好，甚至比使用者自己想到的办法更好。

他更期待那些难用、却因为缺少选择而不得不用的软件被替换。酒店前台、机场、牙科诊所等传统业务中，还有大量需要改善的工作流程。机会要求创业者走进去，观察工作人员怎样完成事情，理解关系、流程和限制。

工程师的价值也可以按这个方向衡量。他更重视真实作品、用户是否受益、能否与客户沟通，以及能否把不同系统组合成有效的方案。熟记某个 API 的价值可能下降，理解系统并把它用到真实场景里的能力仍然重要。

这也是他欣赏滑铁卢大学实习经历的原因：他遇到的一些新人，入职前已经见过不同公司的协作方式，知道如何推动想法、争取资源、与其他职能合作。这是他的管理经验，不是对学历或学校的普遍排名。

给年轻人的建议因此很具体：做出别人真正能试用的东西，接触真实业务，证明自己能理解需求并完成交付。技术能力最终要通过这些结果被看见。

目标可以放大，边界要靠结果找到

Felix 相信模型能力和日常用法之间还有很大距离，但他没有把这解释为 AI 可以接管所有目标。只丢下一句“去赚钱”，模型通常仍走不远。有效的目标需要处于足够有价值、又能够推进和验证的层级。

访谈里，他还转述了一个故事：有人让 Claude 分析 NASA 的公开数据，可能找到了新的行星候选。他同时明确说结果尚未确认，自己也不是天文学家。这个故事体现了他对探索范围的兴趣，不能作为发现已经成立的证据。

谈到未来，他把今天的 AI 产品比作智能手机成熟之前的设备：形态还会变，眼下的使用习惯也可能很快过时。这是他的判断，访谈没有给出可以兑现的产品时间表。

从整场对话能提炼出的工作方法，是把目标说明白，让模型接触相关资料和专业工具，再用独立证据检验结果。人可以逐步减少搬运和分派，把精力留给需求、取舍与反馈。能否放手，最终由一次次可检查的结果决定。

原始资料：Claude Engineering Lead: “Stop Using Claude Like It’s 2024”，Silicon Valley Girl，2026-10-20 发布，时长 49 分 23 秒。主持人 Marina Mogilko，嘉宾 Felix Rieseberg。

Felix 的个人网站列明他曾负责 Claude.ai、Cowork 和 Claude Code Desktop 的工程工作；补充阅读为他的文章 How to be more ambitious: A tutorial for humans with models。本文依据完整英文自动字幕整理，核对了人名、产品名及关键术语，删去广告与重复口语，保留个人观点、未确认案例和能力边界；并非逐字实录。