硅谷最近有个反直觉的现象聊AI的人越来越不关心模型参数反而关心推理成本能不能再降一半。上个月在帕洛阿尔托一个技术午后的聚会上几乎每个话题到最后都会绕回同一个问题这套东西跑起来到底要烧多少钱。作为【国金计算机科技】栏目的硅谷随笔这篇不谈宏大叙事只记录我在一线看到的选型逻辑、工程手段和商业闭环还有一些实打实踩过的坑。做工程、带团队、或者需要看项目做判断的人多少都能从中找到一点对得上号的场景。1. 硅谷AI应用分层从模型军备竞赛到端侧务实落地过去一年硅谷在AI这件事上最大的变化不是某个新模型发布而是整个产业链突然被分出了清晰的层次。最底下是算力和基础模型中间是模型网关、评测工具、可观测性平台最上面是大量垂直应用。应用层的创业公司几乎不再动辄宣称“自训模型”而是大大方方地承认我们用现成的模型把数据、流程和产品体验做出壁垒。这个分层趋势直接影响了我怎么评估一个AI项目。看一家公司先别问“你们用哪个模型”先问“你们的请求长什么样”。是高频低延迟的意图分类还是知识密度极高、需要长上下文的问答是内部数据敏感、必须私有化部署还是可以接受一定程度的数据出域请求特征没有搞清楚模型选型就是碰运气。1.1 硅谷公司怎么选模型先看请求特征我见过最典型的错误是团队一上来就选能力最强的模型处理所有流量。某家做客服自动化的团队早期把所有用户消息都丢给最强的大模型结果是准确率确实高成本也高得吓人——单月推理账单直接吃掉大半轮融资的钱。后来他们做了分层意图识别用传统的分类器FAQ检索走向量召回只有真正复杂的多轮对话才进入大模型。成本降了七成用户体感几乎没有变化。这个案例在硅谷不是孤例。选模型不是选最好的而是选“够用且能规模化”的。实操中我会从一个简单的评分表出发请求类型推荐路径关注指标高频固定结构输出小模型 / 传统规则P99延迟、每千次成本开放问答、复杂推理强能力大模型幻觉率、上下文长度数据敏感、私有化场景可私有部署的开源模型部署成本、运维复杂度海量文档检索增强向量库 RAG串联召回精度、检索延迟关键在于不要用单一模型承载所有类型而是把流量按请求特征切分。硅谷现在流行的“模型路由”思路就是同一个原理先用便宜的小模型处理检测到置信度不高再升级到强模型。路由器看起来是个很轻的中间层实际上它对业务的理解深度决定了一家AI应用公司的毛利率。1.2 成本、延迟和幻觉三个绕不开的标尺每次看AI项目我都会追问三个数字单位请求成本、P99延迟、幻觉率。这三个数字任何一个失控都可能让商业模型破产。成本计算很容易被人忽略细节。单次请求成本等于输入token数乘输入单价加上输出token数乘输出单价再乘上每天请求量和30天就是一个月的理论账单。如果产品做到日活10万每个用户平均一天发起20次请求那这个数字会被快速放大。很多硅谷团队会通过引入Prompt缓存、输出长度上限、局部微调来压低成本。延迟则要看P99而不是平均值。平均值好看没用总有5%的请求会因为模型推理、网络抖动而慢得离谱。对话类产品里用户能接受的极限大约是三秒超过这个时间流失率会明显上升。所以不少团队会在前置环节加一个快速响应兜底先返回一个模板化答复后台再慢慢让大模型完善。幻觉是更隐蔽的问题。我在尽调时会把评测集当作最重要的资产来看。这个评测集不需要很大20到50条真实业务样本就够用关键是覆盖高频场景和危险的边界情况。每次更换模型、调整Prompt或引入RAG都要用同一套评测集回归。硅谷最成熟的AI团队不是Prompt写得有多漂亮而是评测集管得有多严格。1.3 从“全上大模型”到“能小则小”还有一个值得记录的转变越来越多硅谷工程师开始主动做减法。能上规则的地方不上模型能用小模型的地方不用大模型能缓存的结果绝不重复推理。这个思路听起来保守却是商业上最理性的选择。有一个做文档处理的团队最初所有解析任务都交给大模型后来发现很多字段提取用正则和传统NLP就能完成。他们花两周做了个混合管线把大模型调用量压到原来的两成接口费用大幅下降。更妙的是由于大部分流程已经规则化系统的可解释性反而变好了客户审计时更放心。我也在硅谷看过很多反面的例子。有些项目PPT做得很好一问到关键路径上哪些环节真的需要大模型创始人的回答却很模糊。这种模糊往往意味着他们还没把推理成本吃透。把AI当“万能药”还是当“特定环节的组件”是区分成熟团队和跟风团队的试金石。2. 命令行复兴与工具链重构小团队怎么把研发效率打上去硅谷工程师的桌面上正在发生一场静悄悄的工具革命。很多比我年轻十岁的开发者日常主界面就是一个终端加一个编辑器配合AI代码助手完成大量工作。过去需要鼠标点来点去的操作如今又被命令行和脚本捡了回来。我最早不理解这种“复古”直到自己试着把工作流全部脚本化才明白这背后是对效率的极度较真。命令行为什么会在AI时代复兴一个很重要的原因是AI补全了命令行最大的短板记忆负担。以前你得记住一长串参数和管道用法现在只要用自然语言描述意图AI会帮你生成命令。工具本身没变但使用门槛被AI大幅拉低了。于是熟悉终端的人如虎添翼不熟悉的人也愿意重新开始学了。2.1 硅谷开发者桌上那些低调工具真正占据硅谷开发者时间的往往不是发布会上的炫酷产品而是一堆看起来毫不性感的命令行工具文本搜索、JSON解析、HTTP请求、进程管理以及围绕GitHub的各种自动化脚本。我观察到一个趋势小团队开始把“点击式操作”尽可能变成“声明式脚本”。比如发布流程以前要在网页控制台上手动点构建、点部署、点验证现在用一个Makefile或持续集成流水线把整个链路串起来一条命令搞定。这种转变带来的效率提升不是线性的因为脚本意味着可复用、可审计、可被穿越——新人照着一套命令就能复现整个环境。工具链重构还有一个隐含价值知识沉淀。只要操作写进了脚本它就不再是某个人脑子里的经验而变成团队可检查的资产。在快节奏的创业环境里人员流动难免脚本和自动化流水线就是团队记忆的载体。我评估一支技术团队时会特别留意他们把多少常规操作变成了自动化。自动化比例越高团队应对人员流动的能力通常越强。2.2 用自动化工作流把评审时间压缩一半代码评审一直是研发流程里最耗时也最容易被跳过的一环。硅谷的流行做法不是用制度逼人评审而是把评审这件事自动化掉一大部分让人只做关键判断。我这里贴一个自己在用的自动化评审工作流核心思路很简单让机器处理能机器处理的事情人只处理需要上下文理解的问题。name: pr-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkoutv4 - name: 静态检查 run: make lint - name: 变更影响面分析 run: ./scripts/impact.sh - name: AI变更摘要 run: ai-summarize-diff --max-lines 800 - name: 自动打标签 run: auto-label --rules .github/labels.yml这套流程跑完后人工评审只需要做三件事看AI摘要是否准确确认影响面是否超出预期再对关键文件和风险点做深度检查。很多PR的评审时间能从30分钟压缩到10分钟以内。更关键的是机械性问题在机器阶段就已经被拦截人工评审的注意力可以集中在真正需要判断力的地方。2.3 警惕AI辅助引发的“熟练度空心化”工具链太顺也会带来新的问题。我在硅谷跟几个年轻工程师深聊过发现一个共性他们很依赖AI补全写代码但对代码为什么会编译失败、依赖为什么冲突、线上性能为什么陡降往往缺乏耐心去深挖。这是一种我称之为“熟练度空心化”的现象。单独一两次依赖AI没问题但如果长期只做“生成—粘贴—跑通”工程师对系统底层机制的理解会越来越薄。遇到线上事故时AI不会替你背锅。所以我的建议是团队要刻意保留一些高难度、不插电的调试场景。比如每周留半天关掉代码补全纯靠日志和阅读源码去定位一个潜伏的bug。这对资深工程师是基本要求对新人是必不可少的训练。从这个角度看硅谷的开发者工具革命并不仅仅是自动化吃掉重复劳动它同时提高了解问题的下限和上限。下限是被工具托住上限是看你能不能在工具失效的时候仍然稳住。能稳住的人会越来越值钱。3. 开源不是慈善硅谷开源项目的增长与变现逻辑硅谷可能是全世界把开源与商业结合得最深的地方。外人看开源项目常常有一种误解免费开放了公司靠什么赚钱实际上硅谷的开源策略有一套非常成熟的商业逻辑而且模式已经反复验证过。简单说开源解决的是获客和信任问题卖的是企业级场景下的省心和安全。每次评估一个开源项目我都会先问一个反直觉的问题这个项目为什么要开源如果创始团队只回答“我们信仰开放”我会在心里打个问号。真正成立的理由通常是让潜在客户以最低成本验证我们的技术能力然后凭借他们在生产环境跑出来的经验和信任把企业级产品卖出去。3.1 从MIT协议到Open Core硅谷开源变现的三条路硅谷开源商业化目前主要有三条路径。第一种是Open Core把最核心的引擎开源把多租户、权限管理、审计日志这些企业功能放进闭源版本。第二种是Cloud Hosted项目保持开源但公司提供全托管的云服务用户不想自己运维就直接付费。第三种是基于开源项目做周边增值比如咨询、培训、认证体系。为了更直观我常用这张表来对比模式开源范围收入来源适合场景常见风险Open Core核心引擎开源企业版订阅基础设施类项目开源版跑得太好用企业版卖不动Cloud Hosted全部开源托管服务费用开发工具、数据类项目被云厂商“白嫖”后低价竞争增值服务全部开源咨询、认证、培训生态型项目收入天花板明显难以规模化我不太看好单纯靠增值服务做大的模式它很难形成指数级增长。更值得关注的是Open Core和Cloud Hosted。可这两条路各自都有一个绕不开的坎如果开源版本过于完整企业客户没有付费动力如果开源版本太弱又吸引不到社区关注。这个度怎么拿捏是开源商业公司的核心手艺也是我尽调时反复考察的重点。3.2 开源仓库里的尽调信号聊到尽调我看开源项目从来不看star数量那东西的可信度现在已经被稀释得很厉害。我有一套自己的信号清单。第一是看提交的集中度。如果一个仓库star很高但过去一年核心模块只有一个人提交这意味着严重的“关键人风险”。这个人一旦离开项目基本停摆。第二是看issue响应时间尤其是外部用户的提问能不能得到有质量的答复。这反映的是一个社区是否真的有运营机制而不只是代码被搁在那里。第三是看依赖更新频率长期不更新依赖的项目往往已经处于维护者心有余而力不足的状态。Licensing是我必查的一项。很多开发者不重视的开源协议在商业整合时会导致致命问题。比如某个看似宽松的协议实际包含了专利授权条款或者要求使用方公开改动后的源码。这些细节一旦被忽视后期上市或并购时就会变成天价的法律漏洞。3.3 维护者视角文档和社区比代码更磨人很多工程团队在评估要不要采用某个开源项目时觉得代码写得漂亮就行。但在硅谷维护过开源项目的人会告诉你代码只是起点文档和社区才是持续投入的大头。我见过好几个技术很优秀的项目因为README写得像内部笔记外部用户根本没法上手最终社区越来越冷。反过来一些技术上不算惊艳的项目因为教程详尽、示例完整、issue回应及时反而迅速获得了企业客户。文档本质上是降低用户的认知成本而社区运营本质上是降低用户的冒险成本。一家愿意在没直接收入的地方持续投入的公司往往更明白长期价值的含义。这一点在尽调里会被我放大来看创始团队聊产品时是否能把帮助文档、模板仓库、升级指南当作一等公民来谈。如果一提这些就含糊说明他们还没有真正想清楚开源生态的运转方式。4. 远程协作的仪式感分布式团队如何不散架硅谷这几年在办公形态上做了一个巨大的自然实验从全员线下到全员远程再到如今的混合办公。我接触过几十支分布在不同时区的工程团队结论是远程本身不会让团队散架散架是因为把原来线下的默契当成了理所应当的东西。要维持战斗力必须设计新的仪式感。注意我这里说的仪式感不是拍脑袋的团建。它指的是那些能稳定承载决策、对齐信息、建立信任的固定动作。远程团队一旦缺少这些固定动作就会出现“大家各做各的看起来都在忙实际走向完全不同的方向”的失控局面。4.1 异步文档优先会议只做决策分布式团队要跨时区协作最重要的原则是异步优先。凡是能在文档里说清楚的事都不要开会。硅谷成熟团队的做法是任何重要讨论先写一页背景文档包括背景、目标、可选方案和倾向意见然后让相关人在文档上评论。等评论收敛了再开一个短会做最终决策。这个习惯最大的好处是效率没有损耗。想想看如果每次讨论都要拉一个跨时区的会议光是找所有人的空档就可能耗掉一整天。而文档评论可以让每个人在自己高效的时间段参与。文档还是长期资产三个月后新人入职翻一遍历史决策文档就能快速了解系统的来龙去脉。但异步不意味着无限期等待。我给团队立的规矩是文档发出后核心干系人要在24小时内给出反馈需要快速确认的紧急事项则明确标记“需要今天回复”。没有截止时间的异步最后会变成没人负责的拖延。4.2 ADR是我在硅谷学到最值钱的一课在硅谷我学到最有用的一个工程习惯是给重要技术决策写ADRArchitecture Decision Record。它的核心很简单把一次架构决策的背景、方案、理由和后果写下来成为团队长期可查的记录。一个典型的ADR长这样# ADR-001订单表使用PostgreSQL而非MongoDB ## 背景 订单数据需要强一致性和复杂事务早期评估了MongoDB和PostgreSQL。 ## 决策 采用PostgreSQL使用JSONB字段存储部分灵活属性。 ## 理由 - 订单金额和库存扣减需要事务保证MongoDB在4.0后才支持多文档事务 - 团队对关系型数据库运维更熟悉 - JSONB可兼顾未来灵活的元数据扩展 ## 后果 - 复杂聚合查询能力更强 - 需要在写入层处理部分数据校验避免JSONB字段失控为什么说它值钱因为技术决策里最贵的成本不是当时写代码的几小时而是三个月后有人问“当初为什么这么设计”时没有人能给出准确答案。ADR把决策上下文固化下来团队就再也不用靠记忆或考古去理解系统。我评估一个技术团队成不成熟会直接问他们有没有ADR机制。没有的通常都是在靠“核心老员工脑子里的一张地图”运转。4.3 仪式感设计别让分布式团队变成散装团队除了异步文档固定的同步节奏同样必要。硅谷团队常见的做法是每周一次不超过15分钟的周会每个人讲三件事上周做了什么、这周打算做什么、卡在哪。严格限时不讨论细节细节约在会后单独聊。更有意思的是“Demo日”文化。每两周或每个月团队拿出一个下午每个人轮流演示自己做的功能原型哪怕只是一个粗糙的交互稿。远程状态下这种演示是最好的同步方式——它能让大家直观感受到别人在推进什么而不是只看到冰冷的任务看板。Demo日还会自然催生互相启发一个人演示了某个工具脚本另一个人立刻说“这个思路我下个迭代就能用上。”远程协作还有一个很容易被忽略但非常重要的要素让每个人知道“关键路径上有谁在等自己”。硅谷团队会把跨团队的依赖关系显式写进项目文档标出阻塞项和负责人。一旦某人发现自己的产出阻塞了别人他会主动优先处理。这种机制比任何“价值观”口号都管用因为远程团队最怕的就是默默等待和无休止的反复确认。5. 科技尽调里的技术信号看项目时我到底在看什么最后这部分写给需要对科技项目做判断的同行。我在硅谷看项目的思路可能和传统财务尽调很不一样。业务数字当然重要但技术信号往往能提前暴露一个项目的真实成色。尤其是AI项目技术判断的权重比过去任何时候都高。因为AI项目的特点是壁垒可以在几个月内剧烈变化如果团队对底层技术没有清晰的边界认知财务模型再漂亮都可能被突然袭来的成本和技术瓶颈击穿。我做技术尽调的基本方法是假设自己是这个项目的第一个技术合伙人。不是以外部专家的视角去挑毛病而是想象如果让我接手这套系统我能不能在理解的基础上继续演进。顺着这个思路很多信号会自然浮现出来。5.1 尽调第一眼架构评审和技术栈判断拿到一个项目我会先看它的架构和代码库这比看PPT要诚实得多。技术栈本身没有绝对的对错但有成熟度的差异。早期项目用最主流的组件不是没个性而是聪明招人容易、社区成熟、踩坑有前车之鉴。相反如果早期项目就在自研数据仓库、自研消息队列我会非常警惕因为这意味着团队可能在用不可维护的复杂度换取一时的“掌控感”。我列了一张常用的观察表观察项正常信号危险信号数据存储需求匹配的主流数据库用SQL存JSON、用文档库强做事务服务拆分按业务边界明确拆分微服务数量远超团队人数开源组件少量、维护活跃、协议清晰大量自研轮子且无文档测试与CI关键路径有自动化测试测试全部是摆设构建不稳定依赖管理版本锁定、升级有计划长期不更新、锁文件缺失这个表不是用来一票否决而是用来定位“需要额外深挖的地方”。比如一个团队技术栈偏旧不代表项目不行但它可能反映团队的现代工程能力不足。一个团队微服务拆得很碎也不代表上线跑不起来但一定意味着运维复杂度和招聘要求会很高。这些信号最终要综合起来判断。5.2 访谈创始人时最常被绕开的三类问题访谈创始人时我最喜欢问三类对方通常想绕开的问题。第一类是“为什么选这个技术栈”。很多人会回答“快”那我会继续追问快到了什么程度这块技术选型省下的时间是否足够覆盖后来迁移或运维补课的代价如果这个问题答不清楚说明选型很可能只是几个人的偏好而不是经过权衡的工程决策。第二类是“如果数据量放大100倍会发生什么”。这个问题的价值在于逼出系统的真实瓶颈。创始人说“加机器就好”时我会追问是无状态加机器还是某个数据库成了瓶颈如果是数据库当前读写的扩展路径是什么这类问题能很快分辨一个人是真的理解自己的系统还是只在PPT层面运行。第三类是“核心指标哪个先崩”。我一般会问如果明天用户量翻十倍系统里最先出问题的会是哪个组件是慢查询、第三方接口限流还是日志满盘这个问题几乎总能引出很有意思的回答。一个能把“核心指标先崩”说得很具体的技术负责人通常对监控、容量和边界条件有真实手感。反之如果对方只能给出“我们会扩容”这种回答我会把风险评级调高。5.3 技术风险的定价思维尽调最终的输出不是“项目好或不好”而是“这些技术风险我可不可以承受并且足以在价格上反映出来”。我把常见技术风险分了三个等级对应不同的处理手段。高风险的情况比如核心系统依赖某个只有一个人的关键模块或者团队把最重要的竞争优势寄托在完全无法验证的技术假设上。这种项目即便商业故事再好我也会要求估值上有足够的安全边际并且明确后续技术验证的里程碑。中风险的情况比如架构可以支撑当前规模但扩展路径不清晰。处理方式是把它写进投资条款的后续条件比如设置数据量达到某个水平时的压力测试目标或者要求引入有规模化管理经验的工程负责人。低风险的情况比如技术栈成熟、团队有清晰的ADR和自动化测试文化。这类项目技术不是主要矛盾尽调重心可以更多转向市场、销售和竞争。技术尽调最有价值的时刻是帮整个投资决策划定哪些问题在现阶段不必过度纠结。追求一个零风险的项目往往会错过太多机会真正要做的是给技术假设定价并且设计验证节奏。最后说一点个人经验我访谈后会把录音重听至少两遍第一遍听创始人在讲什么故事第二遍专门听细节里的含混处。故事能打动我但含混处往往藏着真正决定项目生死的技术判断力。硅谷这个圈子的好东西大多不是藏在光鲜的演示文稿里而是藏在代码提交记录、文档更新频率和一次不经意的架构决策里。这些东西才是随笔里最值得长期记录的内容。