少招人，多买 Token？Claude Code 叙事背后的第一性原理
开头：这篇文章要冷静看
今天读到机器之心整理的一篇访谈文章，标题很抓人：Claude Code 之父谈「品味」是不是人类护城河，以及工程师不再亲手写代码以后，公司应该看什么。
文章里最容易被转发的一句话，大概是「少招人，多给 token」。
这句话很有冲击力，也很适合传播。但越是这种话，越不能只按字面理解。
一方面，Claude Code 确实代表了一个真实趋势：AI 编程工具正在从补全、问答，走向能读上下文、改文件、跑命令、处理反馈的 Agent。
另一方面，Claude 背后是 Anthropic，Claude Code 背后也有明确的商业模型。让组织投入更多 token，本身当然也有营销成分。供应商说「多买 token」，就像云厂商说「多上云」一样，不能直接等同于中立建议。(最近一直在提醒自己，互联网别人说的/做的/建议，都有营销成分，比如小红书，抖音 ==> 起号做自媒体软广，或者为了自己兜卖课程)
所以我更想把这篇文章当作一个样本：它不是终局答案，而是 AI 原生组织叙事的一次集中呈现。
真正值得拆解的，不是要不要买更多 token，而是：为什么 token 在某些场景里会变成新的生产资料？它到底替代了什么，又替代不了什么？
一、先把营销层和真实趋势分开
这篇文章的叙事非常完整。
它先讲 Claude Code 怎么从一个实验产品变成 Coding Agent，再讲模型能力提升如何改变开发方式，然后推到组织结构、招聘标准、通才价值，最后落到「品味也可能被模型学习，剩下的是价值观」。
这个叙事是有力量的，个人认为AI时代，Storytelling 是非常重要的，包括产品思维、商业策略、组织文化，这种不确定的产物 AI 是不能轻易替代的。
但里面至少有两层东西要分开看。
第一层是产品营销。
如果一个 AI 公司正在卖模型能力，它自然会强调模型正在接管更多工作；如果一个产品按 token 或使用量收费，它自然会鼓励组织把预算从人力转到模型使用上。这不是阴谋，只是商业激励。
第二层是真实趋势。
即使把营销滤镜拿掉，软件工程的抽象层级也确实在变化。过去我们从汇编到高级语言，从手工部署到 CI/CD，从人工排查到可观测性平台，每一次抽象上移，都会改变人的工作重心。
AI Agent 只是把这件事推到了更靠近「任务」和「意图」的位置。
如果说以前的工具是在帮我们更快地写代码，那么现在的 Agent 更像是在帮我们运行一个工作循环：理解目标、读取上下文、提出计划、执行修改、跑检查、根据失败继续调整。
真正的变化不是「模型会写代码」。
真正的变化是：执行成本下降以后，组织会重新计算什么值得自动化，什么值得保留给人。
二、第一性原理：组织买的不是 token，而是闭环
回到第一性原理，一个团队要完成一件事，至少需要六个要素。
- 目标：到底要解决什么问题。
- 上下文：有哪些约束、历史、代码、用户和业务背景。
- 执行：谁来改、谁来写、谁来配置、谁来推进。
- 反馈：怎么知道结果对不对。
- 复用：这次做完以后，下次能不能更便宜。
- 责任：出了问题谁来判断、承担和修正。
token 只直接影响其中一部分：执行、探索、反馈循环的成本。
模型可以让你更快生成方案，更快试错，更快读代码，更快把文档、脚本、测试、界面串起来。它能让一个人同时驱动多个小循环，也能让原来需要等待别人回答的问题先被 Agent 消化掉。
但 token 不会自动给你目标。
它不会自动知道什么是好业务，什么是坏需求，什么风险不能碰，什么信息不能泄露，什么输出必须由人确认。
如果一个团队本来就没有清晰目标，没有测试，没有验收标准，没有安全边界，那么更多 token 只会让混乱变得更快。
这也是我对「少招人，多买 token」最核心的保留意见：它只有在团队已经能定义闭环、度量闭环、复用闭环时才成立。
否则买的不是生产力，而是更昂贵的幻觉。
从 OpenClaw -> Hermes -> Harness / Loop ，我们可以看到，定义清晰目标、边界、约束、风险、责任，是组织买 token 的核心。
三、为什么这个观点仍然有启发
保留怀疑，不等于否定启发。
我认为这篇文章真正有价值的地方，是它把工程师角色的变化说得比较彻底。
以前我们习惯把工程师理解成「写代码的人」。但在 AI Agent 工作流里，写代码本身会越来越像一个中间产物。
人的位置会向两端移动。
一端是更前面的定义问题：判断做什么、不做什么，拆出任务边界，识别真正的约束。
另一端是更后面的验收结果：看 diff，跑检查，判断风险，决定能不能进入用户环境。
中间那段执行，会越来越多交给 Agent。
这和我们平时做 Codex 工作流的感受是一致的。真正让 Agent 稳定产出的，不是把提示词写得更长，而是把仓库规则、任务边界、检查命令和发布前清单放进系统里。
比如我最近在基于 Codex 的一个内容生产仓库，不能只说「帮我写一篇文章」。它需要知道：
- 原始材料放在哪里。
- 草稿应该放在哪里。
- 什么语言和语气适合账号。
- 哪些内容不能编造。
- 生成 HTML、摘要、封面提示词和发布清单的命令是什么。
- 最后为什么不能自动发布。
这才是 Agent 能持续工作的基础。
放到软件工程里也一样。不是「让 Claude/Codex 随便发挥」，而是把它纳入一个可检查的工程运行时。
四、品味不是护城河，价值观也不是空话
原文还有一个很尖锐的点：很多人说「品味」是 AI 时代人类最后的护城河，但文章转述的观点并不认同。
我觉得这里也要拆开。
如果所谓品味，只是对某些模式、风格、写法、交互的偏好，那么它确实会被模型侵蚀。模型看过足够多案例，也能从反馈里学会什么更像「高级」、什么更容易被用户接受。
但如果品味背后包含的是价值排序，那就不是简单的风格问题了。
比如：
- 为了增长，能不能牺牲透明度？
- 为了效率，能不能绕过审核？
- 为了演示效果，能不能模糊没有核验的数据？
- 为了降低成本，能不能把所有判断都交给模型？
这些问题不是模型不能回答，而是模型不应该替你承担。
所以我更愿意把「价值观」翻译成工程语境里的三个词：边界、责任、取舍。
边界决定什么不能做。
责任决定出了问题谁来收口。
取舍决定在速度、成本、质量、安全之间怎么排序。
这部分才是人不能外包的地方。
五、给团队的可执行工作流
如果真的想把「更多 token」变成生产力，而不是账单，可以从一个很朴素的流程开始。
第一步，选低风险但高频的任务。
不要一上来就让 Agent 接管核心架构决策。先从文档更新、测试补齐、日志分析、内部工具、内容流水线、数据整理这类可验证任务开始。
第二步，把上下文文件化。
把规则写进 AGENTS.md、README.md、模板、检查脚本和测试用例里。不要让团队每次都靠聊天重新解释一遍。
第三步，把任务拆成小闭环。
一个任务最好能在几十分钟内完成，并且有明确产物：一个文件、一个测试、一份报告、一个预览页面、一个可复用脚本。
第四步，给 token 预算配反馈指标。
不要只看「用了多少 token」，要看它换来了什么：节省了多少等待、沉淀了什么自动化、减少了多少重复解释、有没有提高交付稳定性。
第五步，保留人工审核点。
涉及发布、删除、权限、账单、用户数据、外部发送、生产环境变更，都必须有人确认。Agent 可以准备，不能擅自越过边界。
六、招聘标准会怎么变
如果工程师越来越少亲手写代码，公司还应该招什么样的人？
我不认为答案是「不招人」。
更合理的答案是：少招只会等任务的人，多招能定义问题、组织资源、验证结果的人。
未来的强工程师，不一定是一天写最多代码的人，而是能把一个模糊目标变成稳定系统的人。
他需要懂技术，但不只懂技术。
他要能和用户对话，能看数据，能写清楚需求，能设计验证路径，能让 Agent 帮自己扩展执行半径，也能在 Agent 做错时迅速把问题拉回地面。
这更像 Builder，而不是狭义的 Coder。
不过也要小心另一个误区：通才不是浅尝辄止。
AI 会降低跨领域迁移成本，但不会消灭深水区。系统设计、安全、数据治理、可靠性、产品判断，仍然需要长期积累。区别只是，未来的专家也要学会用 Agent 扩展自己的边界。
七、给个人开发者的一张检查清单
如果你现在就想实践，可以用这张清单判断自己是在买生产力，还是在买热闹。
- 这个任务有没有明确验收标准？
- Agent 需要读取的上下文是否已经文件化？
- 有没有一条可以运行的检查命令？
- 输出是否会沉淀成下次可复用的脚本、模板或文档？
- 有没有记录 token、时间、返工和人工审核成本？
- 任务失败时，是否能快速定位是目标不清、上下文不足、模型能力不足，还是检查机制不足？
- 是否明确哪些动作必须由人确认？
如果这些问题大多答不上来，先不要急着扩大 token 预算。
先把工作流补齐。
结尾：Token 是燃料，不是方向盘
我对这篇文章的最终理解是：它讲的不是 Claude Code 单点有多强，而是组织运行方式正在被 Agent 改写。
这件事是真的。
但它同时也是供应商最愿意讲的故事：更多模型、更大上下文、更多 token、更少人力摩擦。
我们要从故事里拿走方法，而不是被故事牵着走。
token 可以是燃料，可以让试错更便宜，让循环更快，让一个人驱动更多自动化。
但方向盘仍然在人的手里。
真正的竞争力不是「我买了多少 token」，而是「我能不能把 token 变成可验证、可复用、可治理的工作系统」。
这也是我现在越来越相信的一件事：
AI 原生工作流的重点，不是让人消失。
而是让人从重复执行里抽身出来，去设计更好的循环，并对最终结果负责。
资料来源与核验说明
- 本文基于用户提供的机器之心公众号文章进行二次解读，原文链接：Claude Code之父：「品味」不是人类护城河；当工程师不再写代码，招聘看什么？。
- 原文列出的视频地址为：YouTube 访谈视频。当前成稿没有逐字核验视频，只把公众号文章视作二手转述来源。
- 文中关于 ContentOps / Codex 工作流的部分来自 Walker 当前仓库实践与既有对话经验，已做概括处理，不包含内部 URL、私有 IP、token、密钥或未发布项目细节。