跳到主要内容

82 篇博文 含有标签「ai」

查看所有标签

当算力编写代码时的员额规划

· 阅读需 10 分钟
Tian Pan
Software Engineer

每一个工程组织的每一个年度规划周期都运行在同一个隐藏的等式之上:路线图雄心除以工程师产出等于人员需求。这一规律存在了太久,以至于已经没有人再去专门记录它。你评估工作量,除以一个团队一年内能交付的成果,余数就变成了招聘计划。财务部门围绕它制定预算,招聘团队围绕它建立人才库,而经理们则围绕它规划职业生涯。

这个等式悄然失效了。在一个高度依赖 Agent(智能体)的组织中,工程产出的边际单位不再是另一名资深新员工——而是 Token 加上吸收这些 Token 产出内容的审核带宽。NVIDIA 现在给工程师分配的 Token 预算大约相当于其基本工资的一半,而 Jensen Huang 曾表示,如果一名年薪 50 万美元的工程师每年消耗的 Token 少于 25 万美元,他会感到“深感忧虑”。无论你是否认真对待这个具体的比例,结构性的核心点依然成立:公司现在可以通过两扇不同的门将资金转化为可运行的代码,而年度计划却只为其中一扇门保留了填写框。

一次性软件:编写、运行、删除

· 阅读需 11 分钟
Tian Pan
Software Engineer

上个月,我需要核对两个列规范略有不同的 CSV 导出文件——这项任务我通常会通过找一个 diff 工具、阅读其文档并与其设定的规则缠斗 20 分钟来解决。相反,我让一个 Agent 为我写了一个 50 行的脚本。它运行了一次,得出了答案,然后我就把它删除了。总共耗时:90 秒。这个脚本从未进入版本控制,从未被命名,也永远不会再出现。

这种交易模式——编写、运行、删除——正悄然成为一整类工作的默认模式。当代码生成的成本趋近于零时,最廉价的正确做法往往是定制的单次尝试,而不是通用的工具。寻找现有的实用程序意味着搜索、评估、安装、配置和信任它。而生成一个即用即弃的程序则意味着描述你想要什么。对于定义明确的窄任务,第二条路径现在在除了一个维度外的所有维度上都胜出了:没有人关注到底创造了什么。

技能是过程性知识的包管理器

· 阅读需 12 分钟
Tian Pan
Software Engineer

每个构建 Agent 的团队最终都会遇到同样的瓶颈。系统提示词(System Prompt)起初只有 400 个 token。接着有人添加了数据库迁移检查清单。然后是复盘模板、部署运行手册、客户邮件风格指南。18 个月后,它变成了一个拥有 9,000 个 token 的巨石,没人敢去改动它,因为修改关于回滚流程的一行内容,竟然会降低 Agent 在支持工单中的语气表现。你构建了一个相当于 50,000 行的 main.c 的提示词——而且每个人都在对其进行静态链接。

直觉的反应是使用 RAG:将运行手册切片、嵌入(embed),然后按需检索。但这会以一种更隐蔽的方式失败。RAG 是为检索“事实”而生的,而事实在被碎片化时可以平滑退化——关于你计费模型的五个相关切片中检索到三个,仍然能告诉 Agent 大部分所需信息。但程序(Procedures)无法平滑退化。检索到 60% 的数据库迁移运行手册并不是 60% 有用,而是意味着一场生产事故。有第 1 到 4 步但缺失了第 5 步(“在切换前验证复制延迟”)比完全没有运行手册更糟,因为 Agent 现在的行为带着一种它尚未赢得的自信。

模型已经在直接与你的客户对话了

· 阅读需 12 分钟
Tian Pan
Software Engineer

在某处,此时此刻,一个 AI 助手正在向潜在客户解释你的产品。它引用的价格是你 18 个月前修改过的,推荐的集成是你上个季度停止支持的,并建议一个返回 410 Gone 的 API 端点。你永远不会看到这段对话。没有分析事件被触发。没有会话录像。潜在客户要么相信了错误答案并提交了一份困惑的支持工单,要么相信了错误答案,转而悄悄购买了模型随口提到的竞争对手的产品。

这不是一个假设的未来问题。AI 推荐已经占据了可观的流量 —— 对于某些技术和电子商务网站,这一比例高达 5–8% —— 而这些推荐背后的答案,是模型在任何时候吸收的关于你的任何信息生成的。你的营销团队花了十年时间学习如何监控品牌搜索、评论网站和社交媒体提及。几乎没有人正在监控增长最快的表面:当有人询问关于你的信息时,模型是怎么说的。

RFC 过剩:当写作变得廉价时,设计评审将何去何从

· 阅读需 10 分钟
Tian Pan
Software Engineer

一份打磨精良、长达八页的设计文档(design doc),在有人读到其中的任何文字之前,就曾代表着某种意义。这种产物的存在本身就是证据:有人花了两个星期思考失效模式,与自己争论权衡利弊,并预判了评审者会提出的质疑。文档是思考的凭证。评审者仅凭打磨程度就能进行初步筛选,因为这种“精良感”很难造假,成本极高。

这种相关性如今已经消失了。一个智能体(agent)不到一小时就能生成一份内容详尽、结构严谨、图表丰富的 RFC——甚至还包含一个“已考虑的备选方案”章节,而这些方案实际上根本没人真正考虑过。产物保留了下来,但它承载的信号却消失了。大多数工程组织仍在运行一套隐性基于旧有写作成本而设计的评审流程。

当 AI 卓越中心成为瓶颈时

· 阅读需 10 分钟
Tian Pan
Software Engineer

两年前,组建 AI 卓越中心(CoE)是一项负责任的举措。当时没人知道如何评估模型,采购部门不清楚推理合同该是什么样,而法律部门则希望有一个明确的责任方。将那十个懂行的人集中到一个中心团队显然是正确的做法。

如今,正是这个团队导致你的产品工程师为了修改一个 Prompt 要等上六周。CoE 审查每一次系统消息(system-message)的修改,掌握着公司唯一的评估框架,并由一个每两周开一次会的委员会来把持模型升级。团队已经察觉到了这一点。他们开始使用个人 API 密钥发布产品,在 CoE 永远看不到的 Notebook 中运行评估,并将客户数据粘贴到任何响应最快的工具中。你并没有防止影子 AI —— 而是你创造了它,并给了它一个需要躲避的治理机构。

你的编程 Agent 记错的库版本

· 阅读需 11 分钟
Tian Pan
Software Engineer

Diff 看起来很干净。Agent 导入了正确的模块,调用了看起来正确的函数,TypeScript 也没有报错。PR 描述甚至引用了文档。随后 CI 中的构建开始运行,调用却由于 TypeError: x is not a function 而崩溃 —— 这是因为该函数在八个月前的一次小版本更新中被拆分成了两个,而 Agent 是根据其训练数据中存在的库版本生成的代码,而不是你 package.json 中安装的版本。

这并不是“LLM 会产生幻觉”这一框架能让你做好准备的那种故障。模型并不是在发明一个从未存在的 API。它是在记忆一个曾经存在但现在已不存在的 API。Agent 进行推理的心智模型是一个冻结在训练时的快照。世界在向前发展。代码库在向前发展。而 Agent 却一无所知,因为没人告诉它。

“展示过程”的 UX 陷阱:当推理链只是披着产品外壳的调试输出

· 阅读需 11 分钟
Tian Pan
Software Engineer

推理模型会输出思维链(chain-of-thought)轨迹,因为这是它的计算方式。产品团队在 UI 中渲染该轨迹,是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定,而产品端几乎没有人意识到他们做了第二个决定。于是,轨迹变成了面板,面板变成了功能,功能有了文档页面。六个月后,有人在季度回顾中问,为什么支持队列里全是用户在反驳推理过程,而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞,或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户,等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能,渲染成本几乎为零,但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

AI 副驾驶 vs. AI 飞行员:基于证据的产品决策框架

· 阅读需 10 分钟
Tian Pan
Software Engineer

每个构建 AI 产品的团队都面临同一个路口:AI 应该为人类提供建议,还是自主行动?这个问题听起来很有哲学意味,但答案实际上是可以量化的——而且弄错代价高昂,往往在上线六个月后才会显现,那时你的覆盖率指标看起来很好,但用户信任分数已经在悄悄崩溃。

Klarna 在 2024 年初用一套自主 AI 系统替换了 700 名客服人员。到 2025 年,CEO 承认他们"走得太远了",并悄悄开始为复杂案例重新招聘人工客服。该 AI 在一个月内处理了 230 万次对话,将问题解决时间从 11 分钟缩短到不到 2 分钟。数字看起来很漂亮。但根本问题——金融产品的客户服务需要同理心和判断力,而不仅仅是解决速度——在所有偏离常规路径的场景中,以下降的满意度形式滞后显现。

AI 效率悖论:当你的核心功能扼杀了营收

· 阅读需 10 分钟
Tian Pan
Software Engineer

2026 年初,Atlassian 报告了一件公司历史上从未发生过的事情:企业席位数量下降。对于一家增长模式完全依赖于扩张收入(随着客户组织增长而销售更多席位)的公司来说,这是一个结构性警报,而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率,以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论:构建一个真正为用户节省时间的功能,你可能正在训练他们减少对你产品的使用。你的 AI 越有用,你的定价模型崩溃得就越快。

AI 功能 PMF 信号:为什么你的指标在欺骗你

· 阅读需 10 分钟
Tian Pan
Software Engineer

当你的 AI 功能上线,各项指标开始亮眼——DAU 飙升、NPS 攀升、点赞反馈涌入——你可能正在目睹真正的产品市场契合度。也可能只是两幕故事的第一幕,而第二幕以一个没人预料到的留存悬崖收场。

问题在于,这些信号对概率性 AI 功能而言在结构上就是失效的。它们是为确定性软件设计的——在那里,"已激活"有明确含义,五星好评能预测未来使用,新鲜感在数天内消退,而不是掩盖一个六个月后才显现的流失浪潮。AI 功能的行为模式截然不同,而标准 PMF 工具包是针对错误输入校准的。

你的系统提示词还在用英文:AI 本地化不完全的隐形成本

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞:每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而,六周后,一位德国用户发布了一张截图。AI 的回答用词正确但语域(Register)不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映,结构化输出中的日期格式为 MM/DD/YYYY,这导致他们的下游工具出现故障。一位巴西的支持工程师注意到,AI 在对复杂查询进行推理时,偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说,产品正在悄无声息地变得更糟。

根本原因几乎总是一样的:团队翻译了 UI 字符串,但却让系统提示词保留为英文。这看起来像是本地化,但事实并非如此。