优先把可验证的工程任务交给 AI

AI 改过多少个 PR，能说明使用频率，却不能证明它改善了决定服务表现的关键工作。作者提出一个判断：团队更容易把 AI 用在能快速验收的任务上，而架构、需求和事故分析这些更难判断对错的工作，可能仍少有涉及。

一项覆盖 207,049 次科研会话的研究，为这个判断提供了间接证据。它值得程序员读的地方，是提醒我们分清：哪些工作适合交给 AI，以及交出去之后，谁来判断结果。

使用频率高，可能只是因为结果容易检查

据原文介绍，Anthropic 于 2026 年 11 月 5 日发布「AI for scientific discovery: How researchers use Claude」，分析了 2026 年 8 月 2 日至 9 月 30 日消费者套餐中的 207,049 次科研会话，并将各类任务的会话占比，与研究人员日常投入的时间占比比较。

任务	Claude 会话占比	Claude Code 会话占比	日常时间占比
数据分析	33.7%	48.1%	27.6%
写作与沟通	32.0%	原文未提供	16.0%
数据收集	11.5%	11.9%	28.6%
构思与假设生成	4.2%	2.1%	7.1%

写作与沟通的会话占比，是其时间占比的两倍；数据收集和构思则偏低。但这些数字描述的是任务分布，不能读成「写作效率翻倍」，也不能据此判断节省了多少时间。

研究还给任务的 AI 处理能力打分。得分前 20% 的任务，Claude 使用量约为按时间占比预期的两倍，Claude Code 约为四倍；后 20% 的任务几乎没有被使用。

这个能力评分，与任务适合强化学习的程度存在 0.78 的相关性。原文所说的适合强化学习，是指成功容易验证、能模拟大量样例、反馈来得快。

作者据此推断：有明确合格线、能快速得到反馈的任务，更容易成为 AI 的用武之地。映射到软件开发，生成函数、写测试、机械重构和摘要都有较短的检查路径；系统设计、需求取舍和事故归因，则往往需要讨论才能判断质量。

这里的软件工程映射是作者的推断，不是 Anthropic 对工程团队的实测结论。

分配任务前，先看验收难度和结果重要性

作者建议给重复出现的工作问两个问题：结果能否快速检查？它对最终结果是否重要？

这比单看 AI 参与比例更有用。同样是一个 AI 参与的 PR，修改说明文字与修复关键逻辑，对服务的价值显然不同。

任务特点	作者建议的处理方式
容易检查，而且重要	优先尝试 AI，同时保留审核步骤。
容易检查，影响较小	可以充分使用，但别直接计作服务改善。
难以检查，而且重要	明确人类负责人，让 AI 起草或提出反方意见。

重点是把原本难验收的任务，提前整理出检查依据。

实现之前先写验收测试，让 AI 对着标准完成代码。请求架构建议之前，先填写架构决策记录（ADR）的上下文、选项、决策和后果。写需求时保留少量合格范例，用来比较新草稿。做事故分析时，先约定时间线字段和证据规则，再让 AI 整理笔记。

这些做法都在解决同一个问题：别等模型交出一份流畅的答案，才开始讨论什么叫合格。

审核成本仍然由人承担，扩大使用之前，先明确谁负责检查。

我的判断

我赞同作者把关注点从「用了多少 AI」转向「任务能否验收、是否重要」。对程序员来说，这能解释一种常见误判：产出增加了，但关键决策的质量有没有改善，仍然答不上来。

不过，容易检查不等于检查充分。测试通过，只能说明代码满足已有断言；diff 看起来合理，也不能保证需求理解正确。作者建议先写验收依据，方向是对的，但依据本身仍需要判断。

研究的边界也很明确：样本来自消费者套餐，企业使用和其他工具不在范围内；研究对象是科学家，结果是相关性。它无法证明「更容易验证」就是使用更多的原因，更无法直接证明同样的分布存在于前端或全栈团队。

与按角色或开发阶段统一配置 AI 相比，这种按任务分配的方法更细，但需要有人维护验收标准。原文没有提供工程团队采用前后的对照数据，因此它是一套值得试验的工作方法，还不能当成已被证明的提效方案。

能拿来做什么

• 回看团队最近交给 AI 的五项任务，分别记录验收方式、结果重要性和审核人，检查是否只积累了容易完成的小任务。
• 为前端交互或 Node 接口生成实现之前，先写清可执行的验收用例；审核时同时检查代码和用例是否覆盖了需求。
• 让 AI 参与架构讨论时，先提供 ADR 的上下文和候选方案，再要求它比较后果、提出反方意见，由明确的负责人作出决定。
• 用 AI 整理事故材料之前，先约定时间线字段和证据要求，再逐项核对整理结果与原始记录是否一致。