1. 从“e2e”这三个字母说起：端到端测试到底在测什么

第一次看到“e2e”这个标题，很多人脑子里蹦出来的可能是“end to end”的缩写，但真要落到项目里，它指的其实是一整套端到端测试体系的搭建与落地。我接触过的团队里，十个有八个在项目中期才开始补 e2e，结果往往是脚本写了一堆、跑起来全是红的，最后沦为“只在发版前手动点一遍”的摆设。这篇内容就是把我自己在多个项目里踩过的坑、总结出来的可复现方案完整摊开讲一遍，核心关键词就是端到端测试、自动化脚本、测试稳定性、CI 集成、用例分层。

先说清楚这个项目能做什么。它解决的是“单元测试覆盖率高但线上依然出问题”这个经典矛盾——单元测试验证的是函数级别的正确性，接口测试验证的是服务之间的契约，而 e2e 验证的是用户真实操作路径能不能走通。适合谁来参考？如果你是中高级测试工程师、前端或全栈开发者、技术负责人，正在为“回归测试靠人肉”发愁，那这套东西可以直接抄作业。如果你是完全没接触过自动化测试的新手，建议先补一下基础的测试金字塔概念再回来，不然容易在工具选型那一步就卡住。

我个人的判断标准很直接：一个项目值不值得上 e2e，看它有没有跨模块、跨服务、跨页面的核心业务流。比如电商的下单链路、SaaS 的注册到付费链路、后台系统的权限审批链路。如果只是单个表单提交，接口测试就够了，硬上 e2e 是给自己找麻烦。这个判断在后面的章节里我会反复提到，因为它直接决定了你的投入产出比。

2. 整体设计与思路拆解：为什么我不建议一上来就写脚本

2.1 先想清楚 e2e 在测试金字塔里的位置

测试金字塔这个模型大家都听过，底层单元测试最多、中间接口测试次之、顶层 e2e 最少。但实际项目里，很多团队是反过来的——e2e 写了一两百条，单元测试寥寥无几。这种倒金字塔结构带来的直接后果就是：每次代码改动都会让大量 e2e 挂掉，维护成本高到离谱。

我的做法是先把 e2e 的边界划死：只覆盖核心业务流，数量控制在 20 到 50 条之间。什么叫核心业务流？就是“这条链路断了，公司当天就得发公告”的那种。比如支付成功、订单创建、用户登录态保持。至于“修改昵称后头像同步更新”这种，交给接口测试或者组件测试，不要塞进 e2e。

这样设计的逻辑在于：e2e 的执行成本是最高的（启动浏览器、等待网络、处理异步），每多一条用例，CI 时间就多几十秒。而且 e2e 的失败原因往往不是业务逻辑错，而是选择器变了、网络慢了、动画没结束。控制数量就是控制噪音。

2.2 工具选型：Playwright、Cypress、Selenium 怎么选

这是被问得最多的问题。我直接给结论，再解释为什么。

我现在的默认选择是Playwright。原因很实际：它的auto-waiting机制能自动等待元素可交互，省掉大量sleep；trace viewer可以在用例失败后回放整个操作过程，排查效率比截图高一个量级；而且它原生支持多浏览器并行，CI 里跑起来很省心。

Cypress 我也用过很久，它的调试体验确实无敌，但跨域场景和多标签页操作会让人抓狂。如果你的项目是纯前端 SPA、不涉及第三方跳转，Cypress 依然是好选择。Selenium 我只在维护老项目时用，新项目基本不碰，因为手写显式等待的代码量太大，维护成本高。

提示：工具选型不要只看 GitHub star 数，要看你的团队技术栈和 CI 环境。如果 CI 是 Linux 容器，Playwright 的官方镜像开箱即用，省去装浏览器的麻烦。

2.3 目录结构设计：让用例可维护的关键

很多人写 e2e 就是在一个文件里从头写到尾，三个月后自己都看不懂。我推荐的目录结构是这样的：

e2e/ ├── fixtures/ # 测试数据 │ ├── users.json │ └── products.json ├── pages/ # 页面对象 │ ├── login.page.ts │ └── checkout.page.ts ├── specs/ # 用例 │ ├── auth.spec.ts │ └── order.spec.ts ├── utils/ # 工具函数 │ ├── api.ts │ └── db.ts └── playwright.config.ts

核心思想是页面对象模式（Page Object Model）。把每个页面的元素定位和操作封装成类，用例里只调用方法，不直接写选择器。这样页面改版时，只需要改页面对象，不用动几十条用例。这个设计看起来多写了一层，但维护成本能降一半以上。

3. 核心细节解析与实操要点：选择器、等待、数据隔离

3.1 选择器策略：为什么我禁用 CSS 类名定位

选择器是 e2e 稳定性的命根子。我见过太多用例因为前端改了个类名就集体挂掉。我的原则是：优先用>// 不推荐：类名随时会变 await page.click('.btn-primary.submit-order'); // 推荐：专用测试属性 await page.click('[data-testid="submit-order"]'); // 也可以：语义化角色 await page.getByRole('button', { name: '提交订单' }).click();

>// 等待元素可见 await page.waitForSelector('[data-testid="order-success"]', { state: 'visible' }); // 等待网络请求完成 await page.waitForResponse(resp => resp.url().includes('/api/order') && resp.status() === 200); // 等待 URL 变化 await page.waitForURL('**/order/success');

Playwright 的auto-waiting已经处理了大部分场景，你只需要在涉及异步数据加载时补充显式等待。判断标准很简单：如果这个操作依赖后端返回，就等接口；如果依赖动画结束，就等元素状态。

3.3 测试数据隔离：让用例可以并行跑

e2e 最头疼的问题之一是数据污染。用例 A 创建了订单，用例 B 查询订单列表时多了一条，断言就挂了。解决方案有三层：

第一层是每个用例独立创建数据，用 API 在beforeEach里造数据，用完在afterEach里清理。第二层是数据加唯一标识，比如邮箱用test_${Date.now()}@example.com，避免冲突。第三层是数据库层面隔离，每个测试 worker 用独立的 schema 或者事务回滚。

test.beforeEach(async ({ request }) => { const email = `user_${Date.now()}@test.com`; await request.post('/api/users', { data: { email, password: 'Test1234' } }); });

我实测下来，这套组合拳能让并行执行的失败率从 30% 降到 5% 以下。数据隔离做不好，后面所有优化都是白搭。

4. 实操过程与核心环节实现：从零搭一套可跑的 e2e

4.1 环境初始化与依赖安装

假设你用的是 Node.js 项目，第一步是装 Playwright：

npm init playwright@latest

这个命令会引导你选择语言（TypeScript 或 JavaScript）、测试目录、是否加 GitHub Actions。我建议选 TypeScript，类型提示能帮你少写很多低级错误。装完后会自动生成playwright.config.ts和一个示例用例。

浏览器二进制文件不用手动装，npx playwright install会搞定。如果 CI 环境是 Ubuntu，直接npx playwright install --with-deps一步到位，它会连系统依赖一起装。

4.2 配置文件的关键参数

playwright.config.ts里有几个参数直接决定执行效率和稳定性，我逐个说：

export default defineConfig({ testDir: './e2e/specs', timeout: 30000, // 单条用例超时，默认 30 秒够用 retries: process.env.CI ? 2 : 0, // CI 上失败重试 2 次，本地不重试 workers: process.env.CI ? 4 : undefined, // CI 并行 4 个 worker reporter: [['html'], ['list']], // HTML 报告 + 控制台输出 use: { baseURL: 'http://localhost:3000', trace: 'on-first-retry', // 首次重试时记录 trace screenshot: 'only-on-failure', video: 'retain-on-failure', }, });

retries这个参数争议很大。我的观点是：CI 上必须开重试，本地必须关。CI 环境网络抖动、资源竞争是客观存在的，重试能过滤掉偶发失败。但本地如果开重试，你会误以为用例是稳定的，掩盖真实问题。trace: 'on-first-retry'也是同理，只在重试时记录，避免每次跑都生成一堆文件。

4.3 写第一条核心业务流用例

以登录到下单为例，完整用例长这样：

import { test, expect } from '@playwright/test'; import { LoginPage } from '../pages/login.page'; import { CheckoutPage } from '../pages/checkout.page'; test.describe('核心下单链路', () => { test('用户登录后可以成功下单', async ({ page }) => { const loginPage = new LoginPage(page); const checkoutPage = new CheckoutPage(page); await loginPage.goto(); await loginPage.login('test@example.com', 'Test1234'); await expect(page).toHaveURL(/dashboard/); await checkoutPage.addToCart('product-001'); await checkoutPage.goToCheckout(); await checkoutPage.fillShippingInfo({ name: '测试用户', phone: '13800000000', address: '测试地址', }); await checkoutPage.submitOrder(); await expect(page.getByTestId('order-success')).toBeVisible(); await expect(page.getByTestId('order-number')).toContainText('ORD'); }); });

这条用例覆盖了登录、加购、填地址、提交、断言成功五个环节。注意断言部分——不要只断言页面跳转，要断言业务结果，比如订单号出现、状态变成“已支付”。这样即使页面结构变了，只要业务逻辑对，用例依然能过。

4.4 CI 集成：让 e2e 自动跑起来

CI 配置的核心是启动应用 + 跑测试 + 上传报告。以 GitHub Actions 为例：

name: e2e on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npm run start:test & - run: npx wait-on http://localhost:3000 - run: npx playwright test - uses: actions/upload-artifact@v4 if: always() with: name: playwright-report path: playwright-report/

这里有个细节：npm run start:test &后面的&是让应用在后台跑，wait-on是等端口就绪再执行测试。少了这一步，测试会在应用还没起来时就跑，全部失败。if: always()保证即使测试失败也上传报告，方便排查。

5. 常见问题与排查技巧实录：那些让我加班到凌晨的坑

5.1 用例偶发失败：如何定位是代码问题还是环境问题

偶发失败是 e2e 最折磨人的问题。我的排查顺序是：先看 trace，再看网络，最后看并发。

Trace viewer 会记录每一步的 DOM 快照、网络请求、控制台日志。如果失败时元素明明存在但点击没生效，大概率是动画没结束或者被遮挡。如果网络请求返回 500，那是后端问题。如果本地跑十次都过、CI 跑十次挂三次，那就是并发资源竞争，需要降低 worker 数量或者加数据隔离。

我整理了一份速查表：

现象	可能原因	解决方向
元素找不到	选择器变了 / 加载慢	换>// global-setup.ts import { chromium } from '@playwright/test'; async function globalSetup() { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('http://localhost:3000/login'); await page.fill('[data-testid="email"]', 'test@example.com'); await page.fill('[data-testid="password"]', 'Test1234'); await page.click('[data-testid="login-btn"]'); await page.waitForURL('**/dashboard'); await page.context().storageState({ path: 'e2e/.auth/user.json' }); await browser.close(); } export default globalSetup; 然后在配置里引用这个文件，所有用例自动带上登录态。这一招能让整体执行时间缩短 40% 以上。但要注意：涉及登录本身的用例要单独排除，不能复用状态。 5.3 避坑清单：我踩过的五个典型坑 第一个坑是用page.waitForTimeout代替条件等待，前面说过了，这是万恶之源。第二个坑是在用例里硬编码测试数据，导致重复执行时主键冲突，必须用时间戳或随机数。第三个坑是忽略时区和语言设置，CI 是 UTC 本地是 CST，日期断言全挂，要在配置里统一locale: 'zh-CN'和timezoneId: 'Asia/Shanghai'。 第四个坑是把 e2e 当接口测试写，在浏览器里发请求验证响应体，这完全没必要，接口测试更合适。第五个坑是不清理测试数据，跑一个月后数据库里全是垃圾数据，查询接口变慢导致超时。我的做法是每次 CI 跑完触发一个清理脚本，按创建时间删除测试数据。 提示：e2e 用例的命名要包含业务场景，比如“登录后下单成功”，不要用“test1”“test2”。半年后你回头看报告，能一眼知道哪条链路挂了。 6. 用例分层与执行策略：让 e2e 跑得又快又准 6.1 冒烟用例与全量用例的分离 我把 e2e 分成两档：冒烟用例（smoke）和全量用例（regression）。冒烟用例只覆盖最核心的 5 到 10 条链路，每次提交都跑，5 分钟内出结果。全量用例覆盖所有业务流，每天夜间跑一次，或者发版前手动触发。 实现方式是用 Playwright 的 tag 功能： test('登录后下单成功 @smoke', async ({ page }) => { ... }); test('修改收货地址后重新下单 @regression', async ({ page }) => { ... }); 然后命令行用--grep @smoke或--grep-invert @smoke来筛选。这样开发提交代码时只跑冒烟，快速反馈；发版前跑全量，保证覆盖。 6.2 失败重试与隔离执行 前面提到 CI 上开重试，但重试有个副作用：可能掩盖真实的偶发 bug。我的做法是记录重试日志，如果某条用例连续多次重试才过，就标记为“不稳定用例”，单独拉出来分析。Playwright 的 JSON reporter 会输出重试次数，可以写个脚本统计。 另外，失败用例隔离执行也很重要。默认情况下一条用例失败不影响其他用例，但如果用例之间有依赖（比如 A 创建的数据 B 要用），就会连锁失败。我的原则是用例之间绝对独立，需要共享数据就用 API 在beforeAll里造，不要依赖前一条用例的执行结果。 6.3 执行时间优化：从 20 分钟压到 5 分钟 优化执行时间有几个立竿见影的手段。第一是并行，Playwright 默认按文件并行，把用例拆到多个文件里能充分利用 worker。第二是复用登录态，前面讲过了。第三是禁用不必要的资源加载，比如图片、字体、分析脚本： await page.route('**/*.{png,jpg,jpeg,svg,woff,woff2}', route => route.abort()); await page.route('**/analytics/**', route => route.abort()); 第四是只跑受影响的用例，通过 git diff 分析改动文件，映射到相关用例。这一招在大型项目里效果显著，能把 20 分钟压到 5 分钟以内。但映射规则需要维护，适合用例数量超过 100 条的项目。 7. 从能跑到好用：e2e 体系的持续演进 7.1 报告与告警：让失败第一时间被看到 用例跑完没人看报告，等于白跑。我的做法是把 Playwright 的 HTML 报告上传到内部静态服务器，CI 失败时在群里发通知，附上报告链接和失败用例列表。如果团队用即时通讯工具，可以写个 webhook 推送。 报告里最关键的信息是失败截图和 trace 文件。截图让非技术人员也能看懂哪里挂了，trace 让技术人员能回放操作过程。我要求所有失败用例必须附带这两样，否则排查效率会大打折扣。 7.2 用例评审与定期清理 e2e 用例也需要 code review。我见过太多用例是“能跑就行”，选择器随便写、断言随便加，三个月后没人敢改。我的做法是把 e2e 用例纳入正常的 PR 流程，要求：选择器用> SEO优化 网站运营 关键词排名 推广干货 返回列表 RELATED READING 延伸阅读 更多一线实战笔记与深度复盘，助您持续精进 Celeborn引擎优化PB级Shuffle性能实践 1. 项目背景与核心挑战在大规模分布式计算场景中，Shuffle操作一直是影响性能的关键瓶颈。当数据规模达到PB级别时，传统的Shuffle实现方式会暴露出诸多问题：网络带宽成为稀缺资源、磁盘I/O压力剧增、计算节点频繁OOM（内存溢出&… 2026/10/26 11:37:36 阅读全文 → Ollama+AnythingLLM+Open WebUI本地知识库部署与调优 上个月帮一个做工业设备的团队收拾他们那套本地知识库，起因特别朴素：售前把三百多页的产品手册、两百多条历史工单和一堆内部报价规则直接丢进公有云对话框里问，被合规那边看到截图，当场叫停。他们的诉求其实很典型——既要大模型… 2026/10/26 11:37:36 阅读全文 → 技能管理实战：从盘点、习得到应用的完整方法论 1. 为什么我学过 30 多种技能，真正能拿出来用的不到 5 个先说一个让我印象特别深的场景。几年前我和几个朋友一起做一个内部训练项目，需要有人能在短时间内梳理出一套文件归档规则。有人会电脑操作，有人懂文档管理，有人擅长流程设… 2026/10/26 11:37:36 阅读全文 → t3code：Electron+iOS跨端开发的CLI实践范式 1. “t3code”不是工具名，而是开发者圈里一个正在成型的生态代号最近在几个前端工程化群和 Electron 开发者 Slack 频道里，“t3code”这个词出现频率明显升高——但它既不是 npm 上已发布的包，也不是 GitHub 上有 star 的开源项目&#xff0c… 2026/10/26 12:31:54 阅读全文 → BridgeGPT：AI大模型在桥梁管养中的技术突破与应用 1. 项目背景与核心价值BridgeGPT作为指令集与重庆交通大学联合研发的桥梁管养AI系统，在今年世界交通运输大会上引发了行业高度关注。这个基于大模型技术的专业解决方案，标志着AI在交通基础设施运维领域实现了从通用能力到垂直场景的实质性突破。我实地体… 2026/10/26 12:31:54 阅读全文 → AI账号被封全复盘：风控逻辑、申诉与数据抢救指南 我盯着邮箱里那封标题为“账号安全提醒”的系统通知，愣了好几秒。点开之前我还想着多半是哪个小号又被异地登录检测误伤了，结果正文第一行就写着——你的账号已被暂停使用，理由是违反了平台服务准则。我再登录试试，果然&#xff0… 2026/10/26 12:31:54 阅读全文 → 实测Claude中文能力跃升：从翻译腔到地道中文的技术解析 最近圈子里聊得最多的一个话题，就是Claude突然就会说中文了。这个"突然"当然不是毫无来由，但对普通用户来说，体感确实很直接：以前拿它处理中文内容，总带着一股"翻译腔"，语法挑不出毛病… 2026/10/26 12:31:54 阅读全文 → 如何对LLM大型语言模型进行评估与基准测试：从性能指标到推理能力的落地实践 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/26 12:31:54 阅读全文 → 163条Excel技巧重排：从选区清洗到图表公式的自检路径 简介：《Excel使用技巧大全（超全）》是一份面向Excel初学者和日常办公人员的技巧合集文档，聚焦表格操作、数据整理与办公效率提升，可帮助读者改善快捷键不熟、选区与工作表管理混乱等问题。内容围绕163种实用技巧展开&am… 2026/10/26 12:29:54 阅读全文 → t3code：Electron+iOS跨端开发的CLI实践范式 1. “t3code”不是工具名，而是开发者圈里一个正在成型的生态代号最近在几个前端工程化群和 Electron 开发者 Slack 频道里，“t3code”这个词出现频率明显升高——但它既不是 npm 上已发布的包，也不是 GitHub 上有 star 的开源项目&#xff0c… 2026/10/26 12:31:54 阅读全文 → BridgeGPT：AI大模型在桥梁管养中的技术突破与应用 1. 项目背景与核心价值BridgeGPT作为指令集与重庆交通大学联合研发的桥梁管养AI系统，在今年世界交通运输大会上引发了行业高度关注。这个基于大模型技术的专业解决方案，标志着AI在交通基础设施运维领域实现了从通用能力到垂直场景的实质性突破。我实地体… 2026/10/26 12:31:54 阅读全文 → AI账号被封全复盘：风控逻辑、申诉与数据抢救指南 我盯着邮箱里那封标题为“账号安全提醒”的系统通知，愣了好几秒。点开之前我还想着多半是哪个小号又被异地登录检测误伤了，结果正文第一行就写着——你的账号已被暂停使用，理由是违反了平台服务准则。我再登录试试，果然&#xff0… 2026/10/26 12:31:54 阅读全文 → 实测Claude中文能力跃升：从翻译腔到地道中文的技术解析 最近圈子里聊得最多的一个话题，就是Claude突然就会说中文了。这个"突然"当然不是毫无来由，但对普通用户来说，体感确实很直接：以前拿它处理中文内容，总带着一股"翻译腔"，语法挑不出毛病… 2026/10/26 12:31:54 阅读全文 → 如何对LLM大型语言模型进行评估与基准测试：从性能指标到推理能力的落地实践 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/26 12:31:54 阅读全文 → 163条Excel技巧重排：从选区清洗到图表公式的自检路径 简介：《Excel使用技巧大全（超全）》是一份面向Excel初学者和日常办公人员的技巧合集文档，聚焦表格操作、数据整理与办公效率提升，可帮助读者改善快捷键不熟、选区与工作表管理混乱等问题。内容围绕163种实用技巧展开&am… 2026/10/26 12:29:54 阅读全文 → 全国计算机二级C语言真题PDF高效刷题指南 简介：这份PDF是全国计算机二级C语言考试的试题与答案解析，专为备考二级C语言的考生准备。内容涵盖C语言特点与设计理念、程序基本组成单位、main函数执行流程、函数嵌套调用规则、标识符命名规范、整型实型字符型数据类型、八进制十六进制数合法形式、运… 2026/10/26 0:35:00 阅读全文 → requests+BeautifulSoup：爬虫抓取h1标题的入门实战指南 简介：一份以实战为导向的Python爬虫入门资源，面向具备基本编程基础、希望快速掌握网络数据抓取的初学者，可解决从零编写简单爬虫的常见困惑。实例以requests库发送HTTP请求、BeautifulSoup解析HTML文档，完整演示从网页中提取 标题… 2026/10/26 0:01:17 阅读全文 → OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析 简介：这是一份面向图形学求职者与3D开发者的OpenGL面试题资料，围绕计算机图形学核心考点整理，适合准备图形渲染、游戏引擎方向面试的中高级开发者查漏补缺。压缩包内共1个doc文档，约19KB，内容以问答形式覆盖渲染对象矩… 2026/10/26 0:35:00 阅读全文 → 全国计算机二级C语言真题PDF高效刷题指南 简介：这份PDF是全国计算机二级C语言考试的试题与答案解析，专为备考二级C语言的考生准备。内容涵盖C语言特点与设计理念、程序基本组成单位、main函数执行流程、函数嵌套调用规则、标识符命名规范、整型实型字符型数据类型、八进制十六进制数合法形式、运… 2026/10/26 0:35:00 阅读全文 → requests+BeautifulSoup：爬虫抓取h1标题的入门实战指南 简介：一份以实战为导向的Python爬虫入门资源，面向具备基本编程基础、希望快速掌握网络数据抓取的初学者，可解决从零编写简单爬虫的常见困惑。实例以requests库发送HTTP请求、BeautifulSoup解析HTML文档，完整演示从网页中提取 标题… 2026/10/26 0:01:17 阅读全文 → OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析 简介：这是一份面向图形学求职者与3D开发者的OpenGL面试题资料，围绕计算机图形学核心考点整理，适合准备图形渲染、游戏引擎方向面试的中高级开发者查漏补缺。压缩包内共1个doc文档，约19KB，内容以问答形式覆盖渲染对象矩… 2026/10/26 0:35:00 阅读全文 → 热搜量不是文档频率：先把 BM25 的统计口径分开 一个词突然被搜了一万次，BM25的IDF会不会立刻下降？仅凭查询次数，不能得出这个结论。 Lucene BM25Similarity文档中的IDF输入是docCount与docFreq，分别与参与统计的文档、包含该词的文档有关。查询量不是这两个变量。把热搜计数写… 2026/10/26 0:01:23 阅读全文 → AI行业变局：合规、Mod化与上下文管理的实战启示 今天的AI圈，三条新闻值得认真拆一拆：加州向OpenAI发出传票，Claude Code正式开放Mod化，Meta则放出了“让模型改写自己上下文”的新方向。单看任何一条，都觉得是各自领域的一次例行更新，但放在一起&#xff0… 2026/10/26 0:03:24 阅读全文 → 计算机视觉与AI原生应用融合的技术实践 1. 计算机视觉与AI原生应用的融合趋势计算机视觉作为人工智能领域最成熟的分支之一，正在经历从传统算法到深度学习的技术跃迁。当这项技术与AI原生应用深度结合时，正在催生一系列突破性的应用场景。我从事计算机视觉开发八年，亲眼见证了这项技… 2026/10/26 0:03:24 阅读全文 → 我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/25 12:33:48 阅读全文 → Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/25 16:56:08 阅读全文 → 2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置） /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/25 20:34:35 阅读全文 →