从惊艳 Demo 到稳定上线,AI 功能生产化的工程方法论

翻译:Transwan 校对:Carl Cui 从 Demo 到生产的“死亡之谷” 如果你做过 AI 功能,大概率有过这样的体验:团队在开发一个让人兴奋的新功能,发布排期已经敲定;模型能给出近乎完美的回答,系统原型看起来就像德芙那样丝滑。会议室里,每个人都开始想象它上线后会变成一个流行的产品,许多次,我曾坐在这样的会议室里,那种气氛确实很棒。 然后,你开始做发布前测试: 移动端延迟飙升到 10 秒;模型在占实际用户查询 15% 的边缘案例上开始产生幻觉。经过一番努力,你从 A/B 测试结果上看不到明显的提升,因为 AI 输出的方差太大,使得传统的假设检验基本上失效。安全团队第一周就标出了 340 个失败案例,而你每天都在调试那些以各种新颖方式失败的非确定性案例。 很多时候,这不是模型能力问题,而是工程规范问题。发布 AI 产品和交付传统软件很不一样,我吃了苦头之后才明白这一点。下面这份 playbook,就是我从这些经验里总结出来的经验教训。 延迟预算 每个 AI 功能都会带来额外的延迟开销。大语言模型推理需要时间,实际可能是 500 毫秒,也可能是 5 秒,甚至 50 秒,这取决于模型大小、输入长度以及基础设施配置。对 ToC 产品来说,用户往往期待低于 200 毫秒的交互响应,所以系统响应延迟不是一个上线后再优化的小问题,而是设计阶段就必须正面处理的硬约束。 我最常见到的错误,是团队只看 p50 延迟。一个 p50 为 800 毫秒的功能听起来还不错,直到你发现它的 p90 是 15 秒。这意味着每 100 个用户里,就有 10 个要坐在那里等 15 秒以上。放到规模化产品里,这就是每天成千上万次糟糕体验。 我的做法是按交互类型定义延迟预算,而不是给所有场景设一个统一标准: 同步交互,也就是用户盯着 loading 状态等待结果的场景,应该在 1 秒内完成 渐进式交互,也就是输出逐个 token 流式返回的场景,首个 token 应该在 500 毫秒内出现,完整响应最好控制在 5 秒内 异步交互,也就是用户可以继续做别的事的场景,可以在有进度提示的情况下放宽到 20 秒左右 冷启动也要单独测量。模型加载到内存后的第一个请求,可能比后续请求慢 10 倍。如果你的流量是突发型的,冷启动会特别惩罚那些在高峰时段进入产品的高活跃用户。 ...

June 16, 2026 · 2 min · Gaurav Savla

AI 没有取代工程师,它只是暴露了软件工程的真相

翻译:Transwan 改写:Carl Cui 最近几条新闻放在一起看,很有意思:Microsoft 开始收缩部分团队对 Claude Code 的使用,把工程师引回自家的 GitHub Copilot CLI;Uber 在 2025 年底向数千名工程师部署 Claude Code,结果四个月烧完了全年 AI 编程预算;Klarna 曾高调用 AI 替代大量客服,后来又重新招聘人工客服。 这 3 个故事很容易被解读成极端的版本:一种可能会说 AI 编程工具失败了,另一种可能会说这些公司只是暂时没做好成本管理。这两种说法都不准确,我觉得问题的本质其实是:AI 确实能加速一部分工作,但是很多企业把 AI 加速的这部分工作当成了全部工作。 Microsoft:好用,不代表可无限放大 Microsoft 是 AI 时代最激进的玩家之一,向 OpenAI 投入巨资,也深度推进自家的 AI 编程工具。但 Microsoft 内部很多工程师仍然偏好 Claude Code。工具好不好用,工程师的选择已经给出了答案。 问题不在于 Claude Code 没价值,而在于它在企业规模下太容易失控。一个工程师偶尔用 AI 写代码,和一个大型部门把 AI Agent 接进日常开发,是两种完全不同的成本结构。后者消耗的不是一个固定订阅费,而是持续增长的 token、上下文、工具调用和自动化尝试。 所以 Microsoft 的动作,与其说是“停止使用 AI”,不如说是企业终于开始重新思考:哪些 AI 工具值得用,在哪些场景里用,谁来付账,成本上限在哪里,数据和工作流又该留在谁的平台里。 这不是 AI 无用,而是 AI 进入企业主流程之后,凸显出预算、治理和平台控制权的重要性。 Uber:使用量不是价值 Uber 的数据看起来更像一场成功推广:工程师采用率很高,AI 参与的代码提交比例很高,Agentic AI 功能使用率也快速上涨。按很多公司的 AI KPI,这几乎可以写进成功案例。 ...

June 9, 2026 · 1 min · Carl Cui

Claude Code 实践:token 效率提高 71.5 倍的工作流

每个用过 Cluade Code 的开发人员都有过这种体会:关闭一个会话时感觉挺好的,第二天早上打开一个新的会话,Claude 像是“失忆”了一样。你得在新的会话中跟 Claude 重新解释项目的技术决策,然后 Claude 重新读取项目文件,在能解决问题之前,就已经用掉很多 token。每天重复这么几次,会浪费大量的 token。 解决方案:这篇文章分享一个名为 claude-code-memory-setup 的 GitHub 仓库。这个仓库通过组合两个免费工具为 Claude Code 建立持久化记忆系统,可以让 token 消耗降低至原来的 1.4%。 1. 本质上是一个两层结构 第一层:Obsidian 作为声明性记忆 为所有项目创建单一的 Obsidian 仓库 Obsidian 仓库包含原子化的 Zettelkasten 风格笔记、会话日志、架构决策等 Obsidian 仓库根目录下包含一个 CLAUDE.md 文件,告诉 Claude Code 如何读写这个仓库 通过 /resume 和 /save 命令实现会话间记忆传递 /resume 让 Claude 在回答任何问题之前读取最后几个会话日志和当前项目的决策文件 /save 写入一个新的会话日志,并可选择运行 git commit 解决“昨天做了什么”的失忆问题,不需要重复解释 第二层:Graphify 作为结构性记忆 Graphify 是一个免费的 CLI 工具,它使用 tree-sitter(支持 20 多种语言)在本地解析代码库,生成知识图谱 将代码结构转换为可查询的 JSON 文件,Claude Code 查询这个文件,不需要重新读取源文件 对于一个包含 126 个 TypeScript 文件的项目,生成的图谱大小为 172KB,包含 332 个节点和 258 条边,查询成本从 20,000+ token 降至约 280 token 通过与 git hook 配对,可以在每次提交自动更新知识图谱 2. 工作流程 打开 Claude Code -> /resume 加载 Obsidian 上下文 Claude 查询 graph.json 理解代码结构 工作完成后 -> /save 写入日志 git commit 自动重建图谱 3. 记忆 vs 提示词 超越提示词工程:给 AI 提供持久化记忆和代码结构地图 记忆复合效应:提示词是短暂的,记忆是累积的 4. 实际价值 这个项目一个实用、低成本的技术方案,解决了 Claude Code 用户普遍面临的 token 浪费问题,通过建立系统化的记忆机制大幅提升工作效率和成本效益。 ...

May 12, 2026 · 1 min · Carl Cui

AI 101:10 个概念看懂人工智能

我们经常听到这样一些术语:LLM、Agent、向量数据库、tokens、embeddings、RAG,等等。大多数文章会跳过这些基本知识,围绕某个概念直接展开。实际上,理解了这些核心概念,AI 会变得容易很多。 这篇文章主要普及 10 个最重要的 AI 概念,同时会附上相关的资料。 1. Tokens - 文本信息处理的基本单位 AI 模型在理解一个句子之前,并不是像我们人类那样去阅读它,它首先把句子分成一个个小片段,这些小片段就叫做 token。 Token 的正式译法是词元。2026 年 3 月,全国科学技术名词审定委员会与国家数据局正式将 token 在人工智能领域的中文名称确定为“词元”。 我们会把句子当成一个完整的语义来理解,但 AI 是一个 token 一个 token 地处理。跟 AI 模型聊天时,我们输入一句话,它看到的是一连串的 token。 一般来说,一个英文单词大约对应 1 ~ 2 个 token,而一个中文字符大约对应 1 ~ 3 个 token。 例如毛主席的这句话:“世界是你们的,也是我们的,但是归根结底还是你们的”,包括标点在内共 24 个字符,在 GPT-5 中对应 16 个 token: AI 通过 token 来衡量一切: 输入大小 输出大小 价格 上下文窗口 记忆 1.1 尝试 Tokenization 你可以通过下面两个在线词元分词器(Tokenizer)来尝试词元切分(tokenization): OpenAI Tokenizer Tiktokenizer 2. Embeddings - AI 如何理解语义 在词元切分(tokenization)后,文本被转换为一连串数字(见下图),这些数字被称为“词嵌入”或“词向量”(embeddings)。Embeddings 通过数学方式来表示语义,想象一个包含很多词语的集合: ...

May 8, 2026 · 3 min · Carl Cui

2026 年本地 AI 机器构建指南

译者:Carl Cui 听着,我懂。在 2024 年,每个人都在购买云端 API token,好像它们即将过时一样。“哦,直接调用 API 就行!”他们说。“太方便了!”他们说。好吧,如果你在 2026 年还在按 token 付费,恭喜你,你很可能在为不拥有自己的 AI 技术栈而支付溢价。 让我告诉你一件事:本地 AI 不再是奢侈品,而是生存策略。读完这篇文章,你会确切知道该构建什么样的机器,既不会超出预算,也不会让你发疯。 第一部分:为什么选择本地 AI? 在谈论 token 之前……先谈谈隐私 这里很少有人问的问题:你真的愿意把你的密码和信用卡信息交给某个第三方 API 吗? 想想看。每次你通过云端调用 LLM 时,你都在信任: 你的数据会发送给陌生人(AI 公司) 你的提示词可能被保存为“机密” 你的 agent 记忆存储在你不控制的服务器上 最要命的是:你自己的 agent 记忆是关键。 当你运行本地 AI 时,你的 agent 会随着时间的推移构建上下文——它会记住你在意什么、你之前问过什么、什么对你重要。使用云端 API 时,除非你明确告诉它们要记住,否则这些历史记录通常分散在不同的服务中。 使用本地 AI: 你的记忆保持属于你(不是租来的) 不需要每个月“重置”你的 agent 上下文 敏感数据不会泄露,因为……嗯,它根本不会泄露到任何地方!它就在那里,在你的机器里 现在让我们谈谈实际成本。因为是的,隐私很重要——但钱也很重要。 这是 2024–2025 年没人告诉你的:按 token 定价是个陷阱。 而且从那以后情况变得更糟。 问题不仅仅是模型说得更多(它们确实如此——现代 agent 喜欢滔滔不绝)。而是 你既要为输入 token 付费,又要为输出 token 单独付费。 这意味着: ...

April 26, 2026 · 5 min · Andrew Zhu