夜雨聆风
《米国エンジニアリングチームの現状》
牛尾剛 / Microsoft Azure Functions 团队 Senior SWE / 驻西雅图
发表时间：2026年5月27日
https://note.com/simplearchitect/n/n345fe785fe72
一、文章结构梳理
文章分四个板块：
- 组织形态
——个人商店模型 × マルチロール × 自働化 - 技术演进
——Coding Agent → Cloud Agent Solution - Agent的能力边界
——"从Agent视角能看见什么" - 时代判断
——"なんでもAI"时代结束，进入成本与成果的精算阶段
二、逐节完整解读
组织形态
1-1 个体户模式没有变
牛尾さん所在的团队，AI前后组织形态没有变化——依然是"个体户"：一个工程师独立负责立案 → 规格明确化 → 开发 → 发布 → 运营的全链路。遇到阻塞时Manager帮助解锁，但主体责任始终在个人。
这个模型在AI之前就跑得很好。AI进来之后，不是颠覆这个模型，而是让这个模型的每个环节都被增幅，所以整体跑得更顺了。工程师现在更像是"AI的Manager"。
这个模型的成立前提是——工程师本人有能力判断"这件事值不值得做"。立案是起点，没有立案能力，后面的一切增幅都是在错误方向上加速。日本大企业培养出来的工程师，往往精通"开发→发布→运营"这三段，但"立案"这段是被产品经理或事业部门代劳的。所以当AI增幅到来，日本工程师在技术侧感受到的解放是真实的，但在判断侧暴露出的空洞也是真实的。
1-2 マルチロール——"成为大谷翔平"
AMA（Ask Me Anything）会议上，高层说了一句话："みなさん、大谷翔平になってください"。意思是：AI既然已经扩展了个人能力边界，公司就会相应提高对每个人的期待值。牛尾さん自己也开始做一些市场调研类的工作，而Manager被告知"只是管理的人不需要了"，Manager也要兼任架构师或者提供其他独立价值。
这不是鸡汤，这是劳动力密度提升后的组织重新定价：同样一个人头，公司期待他能产出更多维度的价值。
这句话放到日本语境里，现实版本不是"大谷翔平"，更接近"図面屋兼営業担当兼PMO"——同一个人要画架构图、写PRD、还要在客户的検討会上解释为什么这个方案合规。区别在于，美国的マルチロール是能力增幅之后的自然外延，日本的往往是人手不足之后的强制堆叠。表面相似，驱动机制和结果质量完全不同。
真正的マルチロール（Multirole），每个角色都需要有独立的判断框架，不只是会用AI做更多事。否则是"用AI把错误的事情做得更快更多"。
1-3 自働化——Manager不再帮你铺路
这是三段里面最值得深想的一段。
牛尾さん说：阻塞发生时，以前Manager会帮你解锁（交涉、协调、推进）；现在这些事工程师要自己主动处理。他举了同事Zachさん的例子——Zach有一个想做的事，他自己去找相关工具的作者谈、给牛尾さん的工具贡献代码、收集各方意见、克服困难、坚持推进，最终把项目做完。
牛尾さん对此的评价是："这才是今后需要的行动方式。"
"自働化"这个词，牛尾さん用的是「自働」（自律的自动化），不是简单的「自動」（机械化自动）。这个区别很关键——它强调的是有内驱力的主动推进，而不是按规则自动执行。
这对日本AI创业的含义是：我们的B2B产品，能不能帮助企业里的"Zach"更容易地存在？ 日本企业结构天然压制Zach式的人——因为他的行为会破坏稟議ラインの秩序（审批流）。如果我们的工具能够在不冲击既有流程的前提下，给Zach一条绕过摩擦的路径，那才是真正的产品价值。
技术演进
2-1 Coding Agent的现状
团队已经构建了大量Coding Agent资产：Skills / Repositories / Agent Definition / MCP / CLI等。有人同时开多台DevBox（云端开发机）并行运行Agent，不只用于开发，还用于Incident的RCA（根因分析）和市场调研。
这段揭示的是一个很重要的组织层面事实——Agent的价值不在于单次的对话，而在于积累的资产体系。Skills、Repositories、Agent Definition——这些是可复用的、可迭代的、可以形成组织记忆的东西。
对照日本企业：大多数人还在用AI做一次性的问答，没有在积累资产。PoC做完了，那些prompt、那些工作流、那些context设计就消失了，下一个项目重新从零开始。这是日本AI应用停留在"试验层"的一个结构性原因——不是技术不够，是没有建立AI应用的知识资产管理机制。
2-2 从Coding Agent到Cloud Agent Solution的回摆
这是文章里技术判断最有重量的部分。
牛尾さん说：Coding Agent很强，但它有一个天花板——用户Token的限制。当你需要自动化处理Incident、需要在没有人盯着的情况下持续运行、需要沙盒安全边界的时候，Coding Agent不够用了。所以他们在把某些工作从Coding Agent迁移到SRE Agent（Cloud Agent Solution）——一种更适合自动化流水线的形态。
但他同时说：两者的性能差距现在已经大幅缩小。决定用哪个的不再是"哪个更聪明"，而是"哪个更适合这种工作的自动化模式"。
我认为这个判断直接影响我们的产品架构选择。
当前很多日本AI产品的设计逻辑是"对话界面 + 背后的LLM"——本质上是一个Coding Agent的简化版。这个形态适合有人在场的增幅任务，不适合无人值守的自动化流程。
如果我们的目标客户是企业的运营团队，他们真正想要的不是一个更聪明的对话框，而是一个在他们不在场时也能帮他们把事情做完的机制。这是产品设计层面的根本不同。
日本企業文化里有一个隐形的逻辑：判断必须有人背书。这既是采用自动化Agent的阻力，也是护城河——能够帮助企业在保留"人的最终确认"前提下，把大量中间环节自动化的产品，才是符合这个文化逻辑的正确设计。
2-3 "Agent能看见什么"是核心问题
牛尾さん得出了一个关键洞察：Coding Agent之所以强，不只是因为模型聪明，更是因为它能"看见"的东西多——workspace里checkout的repository、MCP、CLI等工具接入。Cloud Agent Solution性能追上来，也是因为能"看见"的东西对齐了。
Agent的能力边界，本质上是它的上下文视野边界。
这是我见过对"Agent为什么好用或不好用"最务实的解释，没有之一。
把它翻译成产品设计语言：当你在设计一个AI产品时，最重要的架构决策不是选哪个模型，而是设计这个Agent能看见什么、不能看见什么。
对于日本B2B产品，这个问题的答案直接决定了数据接入策略——你的Agent需要连接客户的哪些系统？需要访问哪些文档？需要知道哪些业务上下文？这些"视野设计"，才是产品差异化的真正来源，而不是你用的是GPT-4还是Claude还是Gemini。
时代判断与成本方程式
3-1 "なんでもAI"时代结束
牛尾さん的判断：半年前那种"反正先往AI上套"的不稳定状态已经过去了。现在大家更清楚AI真实的能力边界在哪里，也更清楚怎么用AI产出真实的业务成果。
他说这话的语气不是失落，是专业化的轻松——从试错阶段进入专业阶段，不再需要焦虑"我是否用了最新的AI"，而是开始问"我是否用AI产出了真实的价值"。
日本市场比美国慢一个身位，但方向是一样的。我们现在的客户里，有些人还在"AI元年"的兴奋状态里——PoC申请预算很容易，因为"AI"这个词就是预算关键字。但这个窗口不会永远开着。
当"AI"不再是预算关键字，产品的真实价值才是唯一的通行证。 现在是积累真实证据的时候，不是继续做Demo的时候。
3-2 成果方程式
牛尾さん的个人方程式：
アウトカム ＝ 自分 ＋ AIのアウトカム － Tokenのお値段
他说各家公司已经开始对模型涨价，AI便宜用的红利期结束了。企业内部也会开始限制Token用量。个人的评价，会同时考虑产出了什么和烧了多少Token。
为此他列出了几个具体应对：
掌握并分析自己的Token使用量 让LLM写代码来节省Token（而不是用LLM做所有事） 自己做更快的操作就自己做、把它记熟 搭Cloud Service让自动化在用户Token之外运行
我认为w这个方程式是一把非常锋利的刀，切进来直接划开了"AI用了很多"和"AI产出了很多"之间的区别。
对日本企業クライアントを想定すると（假设客户），他们对"运用コスト"（成本）的敏感度极高——这恰好是我们可以做文章的地方。大多数竞争对手在卖AI能力，我们可以卖的是AI成本可预测性。让客户在签约之前就能看见这个产品的Token消耗曲线，让他们在运营过程中有成本控制的仪表盘——"慎重"的企业文化，在这里不是阻力，而是我们的切入点。
牛尾さん的方程式是工程师视角的个人ROI，但它的结构可以直接移植成企业客户的AI投资回报框架：
企業としてのAIアウトカム ＝ 業務成果の向上 ＋ 工数削減 － APIコスト － 運用・保守コスト
把这个方程式做成可视化的成本模型，放在PoC第一天就给客户看——这本身就是信任建设的动作。
三、总体反思
牛尾さん这篇文章写的是美国，但它对我的价值在于提供了一个参照系——不是"硅谷怎么做就怎么抄"，而是"硅谷已经走过的路，日本在哪个位置，哪些东西可以直接用，哪些需要重新设计才能活下来"。
有三个东西是可以直接用的：
资产积累意识（Skills / Repositories / Agent Definition） "Agent能看见什么"的设计框架 成果方程式作为产品ROI模型
有两个东西需要重新设计：
マルチロール——美国是能力扩展后的自然外延，日本需要先解决"判断力"的培养问题，不能直接照搬 自働化——美国的前提是个人信任度极高，日本需要在"人的最终确认保留"的框架内设计自动化路径
四、行动清单
本周：把Token成本方程式翻译成我们产品的客户ROI模型，做成一张A4纸的框架，下次PoC提案时带进去。
下周架构评审：把"Agent能看见什么"作为独立议题，逐一盘点当前产品的上下文视野——哪些客户系统我们现在连不到、连到了但没有利用好、以及连进去之后会触碰哪些个人情報的红线。
下个季度：把PoC过程中积累的prompt设计、工作流模板、context设计文档，整理成可复用的内部资产库。不能让每个项目都从零开始。这不只是效率问题，这是组织记忆的建设。
持续观察：牛尾さん提到模型涨价、Token红利期结束。日本还处在"AI预算关键字"阶段，但这个窗口在缩短。在窗口关闭之前，必须用真实的运营数据建立起可以独立支撑续约的商业证明——不能永远靠"AI"这两个字开门。
