准备组建 AI 应用团队，别把“十个人就够了”直接填进招聘预算。晚点的访谈标题写的是“做应用 10 个人就够了”，正文介绍引用的魏小康原话则是：“十几个善用 AI 的人，就可以完成过去两百人的工作。”标题的人数与正文引语并不完全相同，后者还强调了善用 AI 这一条件。
晚点 LatePost 于 11 月 12 日发布的访谈介绍，将魏小康介绍为前字节跳动、美团招聘负责人。他同时看好顶尖模型人才的价值，并对应用公司的产研人数提出质疑。这些属于受访者判断，不是经过对照测试得出的通用编制标准。
先测交付，不只测生成代码
ToolAI 的建议是，把这场讨论变成一次小范围验收：挑一个边界明确的真实需求，固定质量要求，记录从需求确认到上线验收的完整耗时。不要只计 AI 写代码的时间，把人工检查、返工和测试一起算进去。
比较基线可以选用既有交付记录，或安排使用与不使用 AI 的可比任务，但要核对任务难度、人员经验和验收标准是否接近，并比较总人工工时。没有这样的基线，试验只能帮助发现瓶颈，不能估算可削减人数；即使测出节省工时，也不能直接换算成岗位。
这里最容易算错的是，把“产出更多代码”当成“少招人也能交付”。如果节省的开发时间转移成了审查负担，缺口可能出现在验收端，而不是编写端。该补哪个岗位，要看任务卡在哪里，不能先定人数再找理由。
METR 在今年 2 月的研究更新提供了一个设计对照时的提醒：部分开发者会避开他们不愿在没有 AI 时完成的任务。挑选任务时，也要记录被排除的工作及原因，避免只测最适合 AI 的部分。
预算里保留审查和失败成本
费用也别只看工具订阅。建议把模型调用、失败重试以及人工修正分别记账，再和通过验收的任务对应。便宜的生成过程，不自动等于便宜的交付结果。
如果暂时无法做完整对照，先保留现有分工，让 AI 接手容易验收的环节，比按照访谈标题调整编制更稳妥。遇到权限、敏感数据或上线操作，则应事先指定人工确认责任，不能把“工具能做”当成“可以放手”。
下一次讨论招聘时，带上实际完成的任务、返工原因和总成本，而不是一个理想团队人数。那份记录才能回答：现在缺的是写代码的人，还是判断代码能不能交付的人。