Sudar Blogger

简单三步解决 Codex 切换 provider 会话消失问题

Thu, 06 Aug 2026 16:15:09 GMT

最近在 Codex 里面接入了 DeepSeek ，有些任务我会让 Codex 官方的服务去做，有些我会让 DeepSeek去做，所以我会切换，在切换的过程中，Codex 有一个机制它会过滤掉不是当前 provider 的对话，所以官方的对话，在我切换到我自定义的 provider 的时候就消失了，看到原本满满的左侧对话列表一下子全没了，我心也是凉了半截，一番搜索发现有一个神器：codex-provider-sync ，目前已经有了 3k star 的项目，用了一下真的非常好用，非常简单，看到我回来的对话列表，表示必须安利一下，给在codex 里面使用自定义 provider 的同学！

使用 codex-provider-sync

非常简单，安装 => 运行

但是在开始之前需要有两个前提：

1）先退出 Codex ：因为 Codex 启动的时候无法操作它的对话数据库数据

2）安装好 nodejs环境：你都有 codex 了，nodejs 环境肯定不会少的吧

第一步：安装工具

npm install -g git+https://github.com/Dailin521/codex-provider-sync.git

装好后会有命令：

codex-provider

第二步：使用工具

codex-provider sync

成功时大致会看到：

Synchronized provider: deepseek
Updated rollout files: 2108
Updated SQLite rows: 5905
Backup: ~/.codex/backups_state/provider-sync/时间戳

其实在使用之前你也可以先看看当前状态，但是不是必须的：

codex-provider status

你会看到类似信息：

Current provider: deepseek
Rollout files:
  sessions: openai: 800, deepseek: 12
SQLite state:
  sessions: openai: 790, deepseek: 12

以上是mac 的使用教程，如果是 Windows，官方还提供了 GUI，可以看看官方仓库的 README 写的很清楚

把 DeepSeek 注册成 Codex 原生自定义子 Agent

别急，还没完，其实我们也可以不切换，可以让 codex 启动的 subagent 使用 DeepSeek ，这样也不用折腾对话了使用这个仓库 oil-oil/codex-deepseek-subagent 。使用方法如下：

先全局安装 Skill（需要 Node.js）：
Terminal window
```
npx skills add oil-oil/codex-deepseek-subagent -g -y
```
重启 ChatGPT / Codex 桌面端，然后新建一个任务。

在新任务里直接说：

帮我把 DeepSeek 配置成 Codex 的原生子 Agent。

如果还没配过 API Key，它会向你要 DeepSeek API Key（会通过标准输入安全保存到系统凭据库，不会明文写进文件）。
看到 status: ready 后，再重启一次桌面端，新建任务。

之后就可以直接用：

用 DeepSeek 子 Agent 检查这个项目。

或者让主 Agent 调用：

spawn_agent(agent_type="DeepSeek", fork_turns="none")

配置成功后，角色文件会在 ~/.codex/agents/DeepSeek.toml。

这个方案会自动处理兼容性问题（把父模型的 multi_agent_version 固定成 v1，并关闭 multi_agent_v2），因为 DeepSeek 目前不支持 V2 的加密任务投递（encrypted_content 会被丢弃）。

总结

让我们简单总结一下，如果你是最近想要在 codex 里面使用 DeepSeek ，我推荐你直接使用 subagent 的方式，如果你是官方的额度没了那么推荐切换 provider 后，然后迁移对话到新的 provider

DeepSeek接入Codex实测

Sun, 02 Aug 2026 06:39:34 GMT

昨天 DeepSeek 发布了 deepseek-v4-flash ，大幅提升了 Agent 能力，我自己在 Codex （现在是ChatGPT，后文都叫做 ChatGPT）里面接入实测真的很不错，下面我分享一下我实测的体验和心得，希望对你有所帮助，下面是分享的速览：

DeepSeek 在 07-31 发了啥？
如何将 Deepseek 接入到 ChatGPT？
在 ChatGPT 里面实测 Deepseek 的各项能力。
哪些场景适合使用Deepseek这个大模型呢？
简单总结一下！

下面让我们快开始吧～

07-31 DeepSeek 更新

这次更新主要两方面：

1）发布了 DeepSeek-V4-Flash 正式版，但是仅仅是上线了 API，所以你使用的网页端，客户端都还是旧的模型

2）Agent 能力大幅提升，针对 ChatGPT 完成适配（原生支持 Responses API），官方提供了一键配置方法，配置后就可以在ChatGPT CLI、ChatGPT 桌面端和 VS Code 的 ChatGPT 插件端进行使用，这里我比较关注的是 DeepSWE 分数，是 54.4 ，相比较之前 7.3 ，可以说是史诗级加强，我们看一下最新的 DeepSWE 榜单，可以看到 DeepSeek 超过了 GLM 5.2 十个百分点，和 Claude sonnet 5 、grok 4.5 是一桌的

可能你觉得它和当前最顶级的 gpt-5.6-sol 、Claude-opus-5 还有很大差距，但是让我们对比一下价格，你就知道 DeepSeek 有多良心了～

模型	输入	输出	缓存命中	输出价倍数	备注
DeepSeek V4-Flash	¥1（$0.14）	¥2（$0.28）	¥0.02	×1	高峰时段约翻倍；DeepSWE 54.4
GPT-5.6 Luna	$0.20（≈¥1.4）	$1.20（≈¥8.4）	$0.02	×4.3	7/30 降价后价格
GLM-5.2（智谱）	$1.40（≈¥10）	$4.40（≈¥31）	$0.28	×15.7	开源权重
Grok 4.5	$2（≈¥14）	$6（≈¥42）	$0.30	×21.4	长上下文 $4/$12
Claude Sonnet 5	$2（≈¥14）	$10（≈¥70）	$0.20	×35.7	推广价至 8/31
Claude Opus 5	$5（≈¥35）	$25（≈¥175）	$0.50	×89.3	Fast 模式 $10/$50
GPT-5.6 Sol	$5（≈¥35）	$30（≈¥210）	$0.50	×107.1	Priority 模式 $10/$60

注：官方 API 列表价，截至 2026-08-01；人民币按 1 USD ≈ ¥7 换算；DeepSeek 为非高峰价。

我们可以通过图更加明显的对比看一下（注意这里的 GPT-5.6 Luna 是最近降价后的价格）

可以看到 DeepSeek 输出成本只有 Claude 的约 1/90。如果说 Claude ，ChatGPT 是 AI 的领头羊，让 AI 变得越来越强大，让有能力的人使用上最智能的服务；那 DeepSeek 就是 AI 的普惠者，它让普通人也能很没有负担的用上前沿的 AI 能力。下面我们看一下 DeepSeek 在真实场景的表现

DeepSeek 接入 ChatGPT

这部分其实没什么好说的，看官方文档：https://api-docs.deepseek.com/zh-cn/quick_start/agent_integrations/codex/ ，有手就行～，但是有一个前提就是你需要已经安装好了 ChatGPT

ChatGPT 里实测 DeepSeek

我自己是已经使用 DeepSeek 在 ChatGPT 做了很多事情，下面我分享 4 个有代表性的工作：

agent 开发：测试模型的编程能力，是否能够基于框架完成需求
bug 的定位和修复：在真实的场景中定位问题原因并进行合理的修复
浏览器操作能力测试：测试插件端操作浏览器的能力
辅助学习：结合 matt 的 /teach 辅助学习后训练，测试前端网页审美

agent 开发

首先测试的是它的全栈开发能力，看看能不能真的做一个能使用的产品，这次我让它做的是一个找书，并下载到本地的 agent，下面是提示词和结果：

我们可以看到 21 分钟它完成了工作，我自己实测了一下发现确实能够跑通，最后成功下载了 epub 格式的书籍到本地，只不过是英文版本的：

下面是让和它水平差不多的 GPT-5.6 Luna 的实现：

可以看到差不多的时间跑通，但是 DeepSeek 更便宜！

bug 定位和修复

开发中最常见的场景就是遇到 bug ，找出 bug 原因并修复 bug。这里我是让它帮我修复一个在真实项目里面前后端都有问题的bug， bug 的表现是：

后端接口请求超时，由于跨表关联查询；没有利用索引；返回数据冗余太大；sql 查询脚本语句顺序问题等问题
前端因为错误的状态更新和依赖导致了接口请求了2次问题

这里我让 DeepSeek 进行排查，DeepSeek 找到了80%的问题原因。但是没有发现深层的bug，所以我们可以让 Deepseek 先做一轮修复，然后让 ChatGPT 进行code review 和二次完善

浏览器操作 & Computer use

1）先看一下 computer use 的能力

这里我让它帮我评论哔哩哔哩的视频，可以看到是成功了，但是花费了 13分钟，所以还是很鸡肋的，我看了一下花这么多时间背后的原因是因为它先卡在了授权问题，打通通道花费了大量的时间；然后 DeepSeek 模型目前还不支持读图片，只能使用 OCR 工具进行辅助执行；最后由于哔哩哔哩做了 RPC 限制，导致发布失败，绕了一下。不过最后的结果是好的，成功的完成了任务。但是如果你有操作电脑的需求，千万不要使用 DeepSeek 模型，慢而且浪费钱，操作电脑的需求还是使用 ChatGPT ～

2）浏览器操作能力

如果你有任何浏览器相关的工作，我都推荐你安装 ChatGPT 浏览器插件，安装方法也很简单

安装成功后，你可以看到浏览器插件栏多了一个 ChatGPT 图标，点击右侧会多一个侧边栏，这里是一个Chatbox ，和本地 ChatGPT 是同步聊天状态的（同样也是需要本地App进行配合），你可以在顶部搜索你在 ChatGPT 的聊天记录，在这里的对话也会同步到本地的桌面端 App

可能很多人还没有使用过 ChatGPT 插件端，这里如果用一句话来说的话：它是让 ChatGPT 能够直接控制和操作你真实的 Chrome 浏览器（有登录态的，这也是为什么本地 App 明明内置了一个浏览器还需要这个插件）。这样你就可以在你真实工作的浏览器让 ChatGPT 帮你干活。

这里我在插件里面让它帮我总结当然网页内容，分析网页实现原理，分析接口请求等工作都能完全胜任，如果你是一个浏览器重度用户，很多工作都在浏览器进行，但还没有使用过插件端，那我建议你现在立马安装使用起来，你会回来感谢我的～

辅助学习

Deepseek这次更新其实是后训练的之前的Deepseek模型，所以我也想学习一下后训练到底是干什么的。这里可以看到花了三分钟就帮我们创建好了学习资料

我自己实际学习下来感觉它生成的内容质量还是很高的。可以看到它并没有直接上来就教我后训练是干什么的，而是会先跟我讲一些我需要预先理解的知识。然后让我了解到了后训练是什么。而且这个页面UI也还挺好看的，我后面又多尝试了几次 DeepSeek ，发现它在真实开发网页的时候审美还是比较差的，目前我建议在 UI审美上使用 Grok 4.5 ，实际测试下来它生成的网页UI还是很不错的

DeepSeek 适用场景

通过我这几天的使用，我测试的感受和 DeepSWE 的评分是一致的，DeepSeek 在解决日常问题和中等难度问题的时候都是很棒的，最重要的是它的速度真的非常快，用起来非常爽！

如果你是深度 ChatGPT 的使用用户，你应该就知道它最近总是干着干着不干了，卡住了～所以我打算后面会把日常工作都交给 DeepSeek ，ChatGPT 负责 review 和兜底；因为DeepSeek的速度实在是快，用起来非常爽

下面是我总结的 DeepSeek 的适用场景：

结合浏览器插件进行调研，总结工作
自媒体创作辅助、学习辅助
日常任务

下面是不推荐使用的场景：

需要图片理解，图片识别；例如：computer use
和安全冲突的事情，这里因为 Codex 这个 harness 安全方面限制比较严格
复杂问题

总结

DeepSeek 虽然 Agent 能力没有什么出众的地方，但是它的价格实在是实在是太便宜了，而且效果还不差，目前最推荐是在 codex 里面进行使用，官方写了非常详细的教程，一行命令接入，想要删除也是随时都可以删掉；

我稳定使用了 2 天，没有遇到报错、软件异常的情况，所以可以放心把 DeepSeek 接入到 Codex 进行日常的工作

在Codex里消耗100亿Token，它已经不只是一个编程Agent了

Wed, 17 Jun 2026 09:05:03 GMT

充分释放 Codex 的潜力

原文：https://x.com/jxnlco/status/2057153744630890620

作者：jason (@jxnlco)

发布时间：2026年5月21日凌晨1:37

大多数开发者最初使用 AI 编程智能体（Agent）都是为了处理纯代码任务：检查代码库、生成差异对比（diff）、运行测试以及提交拉取请求（PR）。

这目前仍是 Codex 的核心基本盘。不过，如今电脑上的许多工作其实已经通过代码在间接完成了：执行终端命令、浏览网页、调用 API、导出文档、响应事件以及触发自动化流程。随着这些操作界面逐步对 Codex 开放，它感觉上就不再仅仅是一个狭义上的代码助手，而更像是一个帮你在电脑上搞定各种工作的全能系统。

Codex 应用程序让这种转变变得触手可及。一个对话流（Thread）能够持续保留上下文、调用工具、呈现生成物（Artifacts），并跨越多次提示词连续执行，无需在每次对话后都清空重置。

想要让 Codex 发挥更大威力，关键在于将以下能力组合使用：

持久化对话流：能完好保存上下文。
语音输入、即时引导与任务排队：让用户在保持深度参与的同时，操作更高效。
浏览器、电脑控制（Computer-use）、MCP 服务器和连接器：让 Codex 的触角延伸到代码库之外。
对话流自动化与“目标”（Goals）功能：在用户离开电脑时，工作依然能继续推进。
侧边栏：供用户在原地评审代码、文档、幻灯片和其他生成物。

持久化对话流（Durable threads）

持久化对话流：长期运行的 Codex 对话流，能跨越多次使用会话，完好保存工作上下文。

把常用对话流“固定”（Pin）起来，是将其留在手边随取随用的好办法。这非常适合那些周期性的工作流，例如：

幕僚长（指的是组织里统筹协调、替核心负责人打理各项事务的核心助手/总管角色）对话流
版本发布对话流
文档评审对话流
专门用于外部监控的对话流

这些是持久化的工作空间，而非用完即丢的简短聊天。Codex 可以随着时间推移反复复盘这些对话，记住先前的决定、偏好和工作上下文。如果没有这项功能，每次开始新任务都得把这些背景信息从头重建一遍。

固定对话流的快捷键让这一切变得非常实用。按下 Command-1 到 Command-9，就能直接跳转到你保存的各个对话流中。

语音输入

语音输入的价值在于，它能捕捉到想法最原始、粗糙的雏形，避免了在将其转化为工整文字过程中造成的灵感损耗。

Codex 内置了语音输入功能。在面对那些“说起来很自然、打字却很麻烦”的模糊想法时，它的表现格外惊艳：

我记得 Slack 里好像有个叫 Ben 的人提到过这件事，具体细节我想不起来了。你去帮我查一下。

对于一个能够搜索、收集上下文并汇报结果的智能体来说，这样一句话往往就足够了。

在任务完全定型之前，进行两三分钟的“想法倾倒”（Thought dump），这种方式同样非常奏效。

会议记录的转写文本也是同理。一份未经修饰的会议速记或口述的规划笔记，往往比简短的摘要提供了更丰富、更优质的原材料，因为它保留了不确定性、语气重音以及未完成的思绪。

即时引导与任务排队

当语音输入与对活动任务的明确控制相结合时，会释放出更大的威力。

即时引导（Steering）：在 Codex 正在执行的任务尚未完成当前步骤时，直接接入并给予新的方向指导。

当智能体走错了方向，需要在它跑完整个流程前进行纠偏时，“即时引导”就派上用场了。例如，在评审网站时，用户可以一边在侧边栏对界面进行标注，一边直接打断它：

把这个调小一点
这两个元素之间的间距感觉不太对
这段文案写错了

任务排队（Queuing）：在当前步骤完成后，为 Codex 顺次添加后续要执行的任务。

任务排队则有所不同。它不会打断正在进行的工作，而是把下一个任务加到排队队列中。用户可以这样说：

工作完成后，把预览链接在 Slack 上发给评审人。

即时引导改变的是 Codex 当下正在做的事；而任务排队改变的是接下来应该发生的事。这两种方式都能让用户在工作展开的过程中，始终保持紧密的把控。

工具与触角

一旦对话流具备了连续性，接下来的问题就是它能对什么大展身手了。Codex 的能力可以像涟漪一样层层向外扩展：

$browser：用于侧边栏的内置浏览器，Codex 可以借此检查网页并对界面进行标注。
@chrome：用于已登录的浏览器状态以及基于 Chrome 的工作流。
@computer：用于那些只能通过桌面图形界面（GUI）完成的工作。

$browser 完美契合侧边栏的网页评审工作。@chrome 适合那些依赖用户 Chrome 个人环境、需要登录状态的网页操作。@computer 则搞定那些只能靠鼠标点击桌面软件才能完成的任务。

MCP（Model Context Protocol）服务器和连接器将同样的理念延伸到了工作流的其他环节。Slack、Gmail 和日历至关重要，因为许多核心任务在变成代码之前，最先是以一条消息、一封收件箱邮件或是一个日程冲突的形式出现的。

“技能”（Skills）则让重复的工作流能够被复用。一旦某个工作流被证明行之有效，就可以将其打包为一项技能，这样 Codex 下次就能直接运行，无需重新学习这一套常规流程。

随时随地开展工作

Codex 移动端应用打破了用户必须守在办公桌前的限制。一项任务可以在 Mac 上启动——那里有现成的文件、权限和本地配置，接着在用户外出时，通过手机就能随时查看和跟进。

这在一些细微的时刻意义重大。当 Codex 运行一个耗时较长的任务时，你可以放心离开座位，在外面回答它的提问、批准下一步操作，或者在回座位前调整对话流的方向。本地环境始终在稳定运行，用户不必再被死死栓在电脑前。

自动化

自动化功能让 Codex 能够按计划定时运行任务。如果一个周期性的工作需要每次从一个干净的工作空间全新启动（例如每日报告或定期的代码库检查），请使用定时自动化（Scheduled automation）。如果需要定时任务回到一个活跃的、保留了运行上下文的对话中，则应当使用对话流自动化（Thread automation）。

对话流自动化：类似心跳机制的周期性唤醒调用，能按计划定时返回到同一个 Codex 对话流中。

固定的对话流固然好用，但它们依然在消极地等待用户回来。而对话流自动化可以每隔几分钟或几小时就去检查某件事，持续运行直到满足特定条件，并随着时间的推移自动调整检查的频率。

一个“幕僚长”对话流可以每 30 分钟运行一次：

每 30 分钟检查一次 Slack 和 Gmail，看看有没有需要我处理的未答复消息。帮我整理出轻重缓急。如果有人向我提问，尽可能深入地研究答案并帮我起草一份回复，但先不要发送。

当用户回到电脑前时，最耗费精力的“收集上下文”阶段通常已经完成了。人类只需要做最后决定：点击发送。

对话流自动化也非常适合“反馈循环”。它可以紧盯拉取请求（PR）的评论、Google Docs 的批注或 Slack 的回复，在用户离开时让周围的辅助工作一直保持推进。

想象一个动画制作的工作流，评审人在 Slack 中分享了一段视频。对话流自动化可以定时检查该对话，在新的修改意见到达时自动渲染出一个更新版本，并在同一对话中回复并艾特（@）评审人。如果某个特定集成插件无法完成最终的上传，桌面自动化还能无缝接管，通过图形界面完成最后一步。

这个闭环跨越了用于收集反馈的 Slack、用于渲染的代码库，以及用于最终上传的桌面自动化。

目标（Goals）

当任务拥有一个清晰的终点线，且智能体能够朝着这个终点持续推进时，“目标”功能将爆发巨大的威力。以下是一个不够理想的目标定义：

目标：耗时更长的 Codex 任务，拥有一个智能体可以随着时间推移持续为之努力的终点线。

❌ 不够理想的定义：实现这个 Markdown 文件中的计划。

而一个更强大的“目标”，应该包含可衡量的成功标准。

例如，一位工程师想要将一个内部工具从 Python 迁移到 Rust，他可以建好新目录，定义好目标，并将终点线具体化：只有当所有单元测试都通过时，新的实现才算完成。

一个“目标”将“持续执行”与“验证器”完美结合。用户定义最终结果、停止条件，以及能够表明 Codex 是否正在逐步逼近目标的反馈信号。

实用的验证器包括：

测试套件
基准测试（Benchmark）
Bug 复现脚本
验证矩阵
必须保持顺畅运行的端到端（E2E）工作流

有雄心壮志固然重要，但如果没有验证机制，目标就仅仅是一个空愿。

侧边栏

侧边栏让你的工作成果与催生出该成果的对话并排呈现。用户无需导出文件再切换软件，在原地就能直接评审。输出的结果可能是代码，但也可能是一份幻灯片、一份 PDF、一个网页、一张表格，或者在过程中创建的其他生成物。

它能够极好地胜任以下四种工作：

检查生成物
标注需要修改的地方
操作网页界面
评审变更

通过侧边栏，用户可以在原位评审 Markdown、电子表格、数据表、文档和幻灯片。他们可以直接检查、标记和修改生成物，而不会打断现有的工作流闭环。

标注功能

幻灯片或 PDF 可以直接在产生它的对话流旁保持打开状态，随时等待直接的评审与修复。

Codex 中的电子表格

应用内浏览器让 Codex 能够检查渲染出的页面、控制它，并直接对正在评审的界面上的标注做出响应。页面或生成物上的评论会保留在工作流内部，而不会变成一个需要单独交接的独立任务。

网络在此刻既是输出结果，又是控制界面。Codex 可以构建一个生成物，在侧边栏中打开它、检查它、调试它，并在原地不断精雕细琢同一个对象。

这些界面形式在实际中表现得尤为出色：

用于轻量级静态生成物的 index.html
用于 UI 评审的 Storybook
用于编程式动画的 Remotion Studio
用于演说的基于浏览器的幻灯片页
用于分析工作流的数据应用

一个单纯的 index.html 文件就能变成一个持久的交互式生成物，甚至不需要任何服务器支持。对话流自动化还可以在后台随时刷新这些静态生成物，这样当用户返回时，对话里就会有全新的成果在等待评审。

共享内存（Shared memory）

当长期运行的对话流能够将记忆共享到单一对话之外时，它们会变得更加有用。

共享内存：存储在单个对话流之外的持久化上下文，以便未来的工作可以从一个明确且可评审的基础上有序恢复。

一种经受住实践检验的持久化模式是：将长期的上下文锚定在一个 Obsidian 知识库（Vault）中。在实践中，这意味着一个由纯文本文件组成的文件夹，它非常直观，极易被检查、编辑、移动并长期保存。团队可以将该文件夹存储在云存储、Git、Dropbox、Google Drive 或任何适合其工作流的同步层中。

一个知识库的结构可能长这样：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

在根目录下，你可以用一个 AGENTS.md 文件来定义 Codex 应该如何更新这个工作空间——随着它对人员、项目、决策和未闭环任务的了解逐步深入。

请不要生搬硬套某一种固定的知识库结构。你需要教会智能体的是：持久化的上下文应该存在哪里、哪些背景需要保留，以及什么时候不要去制造无谓的文件改动。

一份务实的 AGENTS.md 可能会这样写：

- 将 ~/vault 视为持久的工作记忆库。
- 倾向于建立更具权威性的核心笔记，避免笔记无序蔓延。
- 明确对待办事项（TODOs）、人员、项目、每日摘要和草稿笔记进行归类。
- 完好保存决策、绊脚石（blockers）、负责人、日期和有用的链接。
- 如果没有发生实质性的有意义变化，不要对知识库进行无谓的改动。

代码库用来存放代码。而知识库则用来存放不断滚动的上下文：参与其中的人、改变了什么、什么被卡住了、什么需要跟进，以及那些如果不在会话之间记录就会烟消云散的零星信息。

核心的上下文不应该只存在于某一次的聊天记录里。把它写在某个地方，让下一个对话流能够随时无缝接棒。

此外，Codex 在“设置 > 个性化 > 记忆”中也提供了原生的记忆功能。它们为个人偏好、常用工作流和已知踩坑点提供了一个本地的记忆唤回层。它们与明确写下的文本上下文相辅相成，而非取而代之。Chronicle 功能也在朝着这个方向发力，帮助 Codex 从近期屏幕展现的上下文中构建记忆。

从代码向外延伸

Codex 依然是以代码为起点。但如今，围绕代码展开的更多外围工作，都可以通过同一个系统触达：MCP 服务器、浏览器界面、桌面控制、对话流自动化以及可原位评审的生成物。

这彻底重塑了控制模型。即时引导打断正在进行的工作；任务排队让后续任务有序排队；对话流自动化在用户离开时让对话保持活跃；“目标”功能则给出了一个明确的终点线，供 Codex 持续为之努力。

如今，即便工作完全脱离了代码库本身，Codex 也能带着你的工作流，一路从“接收指令”顺畅走向“付诸执行”，最终完成“成果评审”。

最后附上我的Codex 使用记录

译：每个任务都有自己的执行框架：Claude Code 中的动态工作流

Wed, 03 Jun 2026 16:29:07 GMT

上周，我们在 Claude Code 中发布了动态工作流。现在，Claude 可以即时编写自己的 harness，也就是根据当前任务量身定制的执行框架。

默认的 Claude Code harness 是为编程任务构建的，但它其实也适用于很多其他类型的任务。因为事实证明，很多任务在形态上都很像编程任务。不过，有些任务类型如果想达到最佳表现，就需要在 Claude Code 之上构建自定义 harness，比如研究、安全分析、智能体团队，或者代码审查。

工作流允许你在 Claude Code 之上动态创建 harness，让 Claude 能够更原生地解决这些问题。你也可以把这些工作流分享给别人，或者重复使用。

在这篇文章中，我会介绍自己对工作流的一些早期使用经验和体会，帮助你更好地发挥它的能力。请注意，相关最佳实践仍在发展中：动态工作流通常会消耗更多 token，因此更适合复杂、高价值的任务。

示例提示词

在进入技术细节之前，我想先给出几个示例提示词，帮助你理解工作流可以做什么：

“这个测试大概每 50 次会失败 1 次。设置一个工作流来复现它。提出几个关于竞态问题的竞争性理论，在证据只支持其中一个理论之前不要停止。”

“使用一个工作流，回顾我最近 50 次会话，挖掘我反复纠正 Claude 的地方，并把这些高频问题整理成 CLAUDE.md 规则。”

“使用一个工作流，查看过去 6 个月 Slack 里的 #incidents 频道，找出那些反复出现但没人创建 ticket 的根因。”

“拿我的商业计划书跑一个工作流，让不同智能体分别从投资人、客户和竞争对手的角度猛烈挑刺。”

“这里有一个包含 80 份简历的文件夹。使用一个工作流，根据后端岗位要求对它们进行排序，并对前 10 名进行二次检查。你可以用 AskUserQuestion 工具采访我，以确定评分标准。”

“我需要给这个 CLI 工具起个名字。使用一个工作流头脑风暴出一批候选名字，然后用锦标赛方式选出前 3 个。”

“使用一个工作流，把我们的 User 模型在所有地方重命名为 Account。”

“检查我的博客草稿，并使用一个工作流根据代码库验证里面的每一条技术声明。我不想发布任何错误内容。”

动态工作流是如何工作的

动态工作流会执行一个 JavaScript 文件，这个文件里有一些特殊函数，用来创建和协调子智能体：

动态工作流也包含标准 JavaScript 函数，比如 JSON、Math 和 Array，用来帮助处理数据。

特别值得注意的是，动态工作流可以决定某个智能体使用哪个模型，也可以决定子智能体是否运行在自己的 worktree 中。这让 Claude 可以根据任务需要选择合适的智能水平和隔离程度。

如果工作流被打断，比如用户主动中断，或者退出了终端，那么恢复会话后，工作流可以从之前中断的位置继续执行。

为什么需要动态工作流

当你让默认的 Claude Code harness 执行一个任务时，它需要在同一个上下文窗口中同时完成规划和执行。对于很多编程任务来说，这种方式非常有效。但对于长时间运行、大规模并行、高度结构化，或者带有对抗性质的任务来说，它可能会出现问题。

原因是：Claude 在单一上下文窗口中处理复杂任务的时间越长，就越容易受到几类特定失败模式的影响：

智能体式偷懒：Claude 在完成复杂、多步骤任务之前就提前停止，并在只取得部分进展后宣称任务已经完成。例如，在一次安全审查中，本来有 50 个问题需要处理，但它只处理了 35 个就结束了。
自我偏好偏差：Claude 倾向于更相信自己的结果或发现，尤其是在你要求它按照某个评分标准验证或评判这些结果时。
目标漂移：经过很多轮对话后，尤其是在上下文压缩之后，Claude 会逐渐丢失对最初目标的精确理解。每次总结都会损失信息，像边界条件要求或者“不要做 X”这样的限制，很容易在过程中丢失。

创建工作流可以通过编排多个独立的 Claude 子智能体来对抗这些问题。每个子智能体都有自己的上下文窗口，并且有更聚焦、更隔离的目标。

动态工作流 vs 静态工作流

你以前可能已经使用 Claude Agent SDK 或者 claude -p 创建过静态工作流，用来协调多个 Claude Code 实例一起工作。

但是，因为静态工作流需要处理所有边界情况，所以它们通常会更通用。现在，借助 Claude Opus 4.8 和动态工作流，Claude 已经足够智能，可以为你的具体使用场景编写一个量身定制的 harness。

使用动态工作流时的有用模式

你可以直接让 Claude 创建一个动态工作流，也可以使用触发词 “ultracode”，确保 Claude Code 会创建一个工作流。

不过，如果你能建立一个关于动态工作流如何运作的心智模型，就会更清楚什么时候该使用它，以及如何通过提示词引导 Claude。

在构建工作流时，Claude 可能会使用并组合以下几种常见模式：

分类并执行

使用一个分类器智能体来判断任务类型，然后根据任务类型路由到不同的智能体或行为。也可以在流程结束时使用分类器来判断输出结果。

扇出并综合

把一个任务拆分成许多更小的步骤，让每个步骤由一个智能体处理，然后再综合这些结果。

这种模式特别适合步骤数量很多的任务，或者每个步骤都适合拥有一个干净独立的上下文窗口的场景。这样可以避免不同步骤之间互相干扰，或者上下文交叉污染。

综合步骤是一个屏障：它会等待所有扇出的智能体完成，然后把它们的结构化输出合并成一个最终结果。

对抗式验证

对于每个创建出来的智能体，再创建一个独立的智能体，根据评分标准或判断准则，对前者的输出进行对抗式验证。

生成并过滤

围绕某个主题生成一批想法，然后根据评分标准或验证结果进行筛选，去除重复项，最后只返回质量最高、经过测试的想法。

锦标赛

不是把工作拆开，而是让多个智能体在同一个任务上竞争。

创建 N 个智能体，让它们分别使用不同方法尝试完成同一个任务。然后通过提示词或模型，让一个裁判智能体以两两比较的方式评判结果，直到选出最终胜者。

循环直到完成

对于工作量未知的任务，不使用固定次数的处理流程，而是不断创建智能体，直到满足停止条件为止，比如没有新的发现，或者日志里不再出现错误。

使用场景

你可以更有创造性地思考什么时候、以及如何让 Claude Code 创建动态工作流。我发现，工作流有时在非技术任务中甚至更有用。

迁移和重构

Bun 就是使用工作流从 Zig 重写为 Rust 的。你可以在 Jarred 的 X 线程中了解更多细节。

关键在于把任务拆分成一系列需要处理的步骤，比如调用点、失败测试、模块等。为每个修复任务启动一个子智能体，并让它在一个 worktree 中完成修复；然后再让另一个智能体进行对抗式审查，最后合并结果。

你可以考虑告诉智能体不要使用资源消耗很大的命令，这样你就可以尽可能提高并行度，同时避免耗尽本机资源。

深度研究

我们在 Claude Code 中发布了一个深度研究 skill，也就是 /deep-research，它使用了动态工作流。具体来说，它会扇出多个网页搜索、获取来源、对其中的声明进行对抗式验证，并综合生成一份带引用的报告。

不过，这种研究并不只适用于网页搜索。比如，你也可以让 Claude 根据 Slack 中的上下文编写状态报告，或者让它深入探索代码库，研究某个功能是如何工作的。

深度验证

另一方面，如果你有一份报告，并希望检查和溯源其中引用的每一条事实声明，那么可以生成一个工作流：先让一个智能体识别所有事实声明，然后为每一条声明启动一个子智能体进行详细检查。

你还可以再设置一个验证智能体，用来检查负责溯源的子智能体，确保它引用的来源质量足够高。

排序

你可能会有一组项目，希望按照某种定性指标进行排序，而你认为 Claude Code 擅长评估这种指标。例如：按照 bug 严重程度给支持工单排序。

但如果你试图在一个提示词里对 1000 多行数据排序，质量会下降，而且上下文也装不下。

更好的方式是运行一个锦标赛，或者建立一个由成对比较智能体组成的流水线。成对比较通常比绝对打分更可靠。也可以并行进行分桶排名，然后再合并结果。

每一次比较都由一个独立智能体完成，因此确定性的循环负责维护整个竞赛表，而上下文中只需要保留当前运行顺序。

记忆和规则遵循

如果你发现 Claude 经常漏掉或难以遵守某些规则，即使你已经把它们写进 CLAUDE.md 文件中，也可以创建一个工作流，把这些规则列出来，并让验证智能体逐条检查。每条规则对应一个验证智能体。

创建一个“怀疑者人格”的子智能体来审查这些规则，也能帮助避免产生太多误报。

反过来也可以：挖掘你最近的会话和代码审查评论，找出你反复做出的纠正；再用并行智能体对它们进行聚类；对每个候选规则进行对抗式验证，比如判断“这条规则是否真的能防止一个真实错误”；最后把通过验证的规则提炼回 CLAUDE.md。

根因调查

调试最有效的方式，是提出几个相互独立的假设，然后分别验证它们。但如果只使用一个上下文窗口，Claude 可能会陷入自我偏好偏差。

工作流可以从结构上避免这个问题：它可以启动多个智能体，让它们基于彼此独立的证据来源生成假设。例如，分别为日志、文件和数据启动不同智能体。之后，每个假设都可以接受一组验证者和反驳者的审查。

这并不只适用于代码。工作流也可以用于销售分析，比如“为什么 3 月销售额下降了？”；也可以用于数据工程，比如“为什么这个 pipeline 失败了？”；或者用于任何事后复盘场景。

大规模分诊

每个团队都会有支持队列、bug 报告，或者其他无法完全由人工处理的积压任务。

一个分诊工作流会对每个项目进行分类，与已经追踪的内容进行去重，然后采取行动。这可能意味着尝试修复问题，也可能意味着升级给人工用户处理。

分诊工作流中的一个有用模式是“隔离区”。它会禁止那些读取不可信公共内容的智能体执行高权限操作。真正的高权限操作，则由负责基于信息采取行动的智能体来执行。

你可以把分诊工作流和 /loop 搭配起来，让 Claude 持续执行这类任务。

探索和品味

当你需要探索某个解决方案的不同方向时，工作流会很有用。尤其是在设计、命名这类带有审美判断的任务中，如果再配合评分标准，效果会更好。

你可以让 Claude 探索一批解决方案，然后给审查智能体一套判断“好方案”的评分标准。当审查智能体认为已经满足标准时，任务就完成了。

这些方案也可以根据评分标准，通过锦标赛方式进行排序或筛选。

评测

你可以为某些特定任务运行轻量级评测：启动多个独立智能体，让它们在各自的 worktree 中完成任务，然后再启动比较智能体，根据评分标准比较和打分这些具体输出。

例如，你可以用这种方式评估并改进自己创建的某个 skill，看它是否符合特定标准。

模型和智能路由

你可以创建一个针对自己任务调优过的分类器智能体，由它决定应该使用哪个模型。

当你的任务需要大量工具调用，并且在真正执行之前需要做一些研究时，这种方式尤其有用，因为前期研究可以帮助识别最适合当前任务的模型。

例如，对于“解释 auth 模块如何工作”这个任务，最适合的模型取决于 auth 模块包含多少文件，以及整个代码库的结构。分类器智能体可以先做这项研究，然后根据预期复杂度把任务路由给 Sonnet 或 Opus。

什么时候不该使用动态工作流

工作流仍然是一个新功能。虽然在许多使用场景中，它能带来远超常规方式的结果，但并不是每个任务都需要它，而且它最终可能会消耗显著更多 token。

最好用创造性的方式使用工作流，把 Claude Code 推向你以前没有尝试过的方向。对于普通编程任务，可以先问自己：它真的需要更多计算资源吗？

例如，大多数传统编程任务并不需要一个由 5 个审查者组成的评审小组。

构建动态工作流的建议

提示词

针对动态工作流，使用更详细的提示词，并明确采用前面提到的具体技巧，通常能得到最好的结果。

工作流并不只适用于大型任务。你也可以提示模型使用一个“快速工作流”。例如，你可以创建一个快速的对抗式审查流程，用来检查某个假设。

结合 `/goal` 和 `/loop`

当你使用可以重复执行的工作流时，比如分诊、研究或验证，可以把它们和 /loop 搭配起来，让它们按固定间隔运行；同时使用 /goal 设置一个硬性的完成要求。

Token 使用预算

你可以为动态工作流设置明确的 token 使用预算，限制某个任务最多消耗多少 token。

例如，你可以在提示词中写：“use 10k tokens”，这样就会设置一个上限。

保存和分享动态工作流

你可以在工作流菜单中按下 “s” 来保存工作流。你可以把它们提交到 ~/.claude/workflows，也可以通过 skill 分发。

如果想通过 skill 分享工作流，可以把 JavaScript 工作流文件放进 skill 文件夹中，并在 SKILL.MD 中引用它们。

为了提高灵活性，你可能会希望提示 Claude：把 skill 中的工作流看作一个模板，而不是一段必须逐字执行的脚本。

一个新的探索起点

工作流是扩展 Claude Code 的一种很有帮助的新方式。我鼓励你把它们看作一个起点，用来探索使用 Claude 完成任务的新方法。关于如何最好地使用它们，还有很多东西值得发现。欢迎告诉我你的发现。

本文作者是 Thariq Shihipar 和 Sid Bidasaria，他们是 Anthropic 负责 Claude Code 的技术团队成员。

和AI一起修复了上百个bug后，我将其沉淀为了一套 Skills

Mon, 01 Jun 2026 11:50:19 GMT

大家好，我是幸运的蜗牛，今天想分享一个非常实用的 skills，它能够帮你在网页开发过程中遇到 bug 的情况下，快速定位到 bug 的真正原因，并且修复，最后产出 bug 修复文档进行沉淀。这是一个非常实用也非常重要的 skills。

我自己在 AI vibe coding 的过程中，百分之七八十的时间，其实都是在解决 AI 没有完全理解需求，或者说是因为它过时的训练数据，或者说是误导的上下文等等各种原因所产生的问题。一句话说，就是在修复 bug。很多时候我都觉得还不如我自己 debug，可能来得更快一点。

最终在我快受不了的时候，我认真观察了 AI 修复不好 bug 的原因，发现很多时候它都是因为缺少上下文，或者说是因为把假设当成了事实。于是我基于不断地修复 bug，沉淀了一个 skills：bug-hunt。简单来说，它就是帮我把「AI 凭感觉乱改」这件事，硬掰成「先拿到证据，再动一行代码」的固定流程。

先说说，AI 为什么修 bug 这么蠢？

如果你经常用 AI 写代码，下面这几个场景应该不陌生：

理解错误导致乱改：你说这个按钮点了没反应，AI 直接你改了三个文件，结果按钮还是没反应，但是顺手又带出来两个新 bug。
喜欢拿一个错误的假设当事实：比如我最近让 AI 帮我改元素的定位问题，它默认了 fixed 定位相对于是 body，但实际上并不是
爱兜底：很多时候让AI改东西，它其实并没有找到问题的真正原因。但是呢，它又想要把这件事情解决掉，它就根据我们的提示词，然后进行添加兜底逻辑。这种是最可怕的，因为你测试的时候会发现它好了，但其实它只是接入了这个特殊的 case
喜欢顺手做不需要的事情：很多时候，AI很讨厌人的一点就是，它会在修复bug的时候，它说它自己发现了一个问题，然后顺手也修复了。

这些行为背后其实是同一个病根：AI 在没有任何证据的情况下，就开始猜原因、改代码了。 它把「我觉得可能是 X」直接当成了「就是 X」，然后基于这个假设一路改下去。更糟的是，它的知识很多来自训练数据里那些早就过时的博客、CSDN 上互相抄来抄去的错误答案——你让它查个库的行为，它给你的是三年前的旧版本逻辑。

但是我们是怎么 debug 的呢？先复现，再加日志，看到真实的运行数据，才下结论。bug-hunt 干的事情，就是把这套逻辑，把它写成一份 AI 必须遵守的契约。

bug-hunt 的核心：五个步骤

bug-hunt 的整个方法论可以浓缩成五个阶段，AI 必须按顺序走，如果后面的证据推翻了前面的结论，就退回去重来，绝不允许直接跳到「我来改代码」。

Phase 0 — 复现与框定。 第一件事不是改代码，是先稳定复现，并且定一个可验证的成功标准。注意这里有个关键区别：成功标准不能是「不卡了」这种模糊的话，而必须是「页面加载 5 秒内 spinner 消失，并且价格区域渲染出一个大于 0 的数字」。为什么这么较真？因为如果你只盯着「不卡了」，AI 很容易在第一个症状缓解的瞬间就宣布胜利——spinner 是没了，但数字是错的，你反而上线了一个更隐蔽的 bug。

Phase 1 — 自顶向下定位。 从你看到症状的那一行 UI 开始，往上游一层一层追：这个值是谁写进去的？它的上一层又是从哪来的？每一层都记下来 文件:行号，最后形成一张「分层表」，并产出几个有名字的假设（H1、H2、H3）。追到网络边界、原始用户输入，或者能说出一个具体猜测为止。这一步实现通过数据&逻辑链路逐步的定位到问题的真正原因。

Phase 2 — 全链路埋点。 这是整个方法论最硬核的一步。AI 要在每一层都打上结构化日志，而且全程只用一个唯一的日志前缀（比如 [YUGU_DEBUG]），方便最后一把清干净。日志不是简单 console.log(变量)，而是用 JSON.stringify(对象, null, 2) 输出结构化数据，里面要包含：

身份信息：哪个调用点、第几次循环、第几个元素；
哨兵值：那个决定下游走向的布尔判断，比如 willTriggerLoading: x === 0；
数据形状：Object.keys()、length、typeof，而不只是值本身；
首个样本：arr[0]，确认元素结构但不刷屏。

还有几个很实用的小技巧：打 error 永远不要直接 log 那个 Error 对象（JSON.stringify(err) 会给你一个空的 "{}"），要拆成 { message, stack, raw }；如果某个 await 一直不返回，就在它前后各打一行日志，最后一行打印出来的位置就是卡住的地方。埋好点之后，AI 必须停下来，让你去复现、把控制台日志贴回来，在拿到真实输出之前不许再改任何代码。

Phase 3 — 分层根因。 高质量的排查往往不止一层原因，而是一条因果链：症状 → 直接原因 → 深层原因 → 根本原因。怎么判断你还没挖到根？很简单——如果「为什么会这样」这个问题还能有意义地往下问，那就还没到底。这一阶段还有一条特别重要的规则，叫信源分级，下面单独讲，因为它正是治 AI「把过时博客当事实」这个病的关键。

Phase 4 — 外科手术式修复。 找到根因后，只改能修复这个已被证明的原因的最小代码集。不重构、不顺手改命名、不删无关的死代码。改完之后，带着 Phase 2 的日志重新跑一遍，确认每个原来报错的日志现在都输出了预期值、哨兵布尔值翻转了、其他没受影响的路径依然正常。这里还专门有一条反面清单——下面这些都不算修复：

value || 0 掩盖 undefined——只是把 bug 推到下游；
try { ... } catch {}——藏起了下一个 bug；
setTimeout(check, 100)——你根本没解决竞态；
// HACK: ...——在代码里写下「我投降了」。

只要你发现 AI 想写上面任何一种，让它退回 Phase 1。

Phase 5 — 文档沉淀 + 清理。 排查不写文档不算结束。AI 要按模板在 docs/ 下生成一份 bugfix-<slug>.md，包含：现象、根因链、排查过程（Phase 1 的分层表 + Phase 2 的关键日志）、修复 diff、前后对比验证表、改动文件清单、后续建议。最后用一行 grep 把所有调试日志清干净——期望结果是 0 条命中，泄漏到生产环境的调试日志本身就是 bug。

解决 AI 把错误信息当事实：信源分级

我前面说 AI 修 bug 蠢，很大一部分是因为它「把假设当事实」，而这些假设又常常来自互联网上的垃圾信息。bug-hunt 在 Phase 3 里定了一套严格的信源优先级，强制 AI 只能相信高质量的来源：

第一档（永远先查）：官方文档、库的 GitHub 源码本身、官方 changelog / 迁移指南、类型定义文件、官方规范（RFC / W3C）。
第二档：维护者自己仓库里的 GitHub issues 和 discussions，尤其是那些关联了 commit / PR 的 closed issue——里面往往有对某个行为变化的权威解释。
第三档（前两档都查不到才用）：库作者或平台官方的工程博客、被维护者认可或高赞且引用了一二档来源的 Stack Overflow 答案。

而下面这些是明令禁止的：CSDN、低质量博客园镜像、百度知道 / 百度经验、360doc、各种内容农场聚合站、机翻文章、没作者没日期的 AI SEO 文。原因很现实：这些来源经常一本正经地把原因归错，AI「拿它验证」了自己的假设，然后给你上线一个修错了层的 fix。最后，所有参考过的外部链接都要写进 bug 报告里，让整条证据链可审计。

说人话就是：让 AI 去读库的真实源码，而不是去信某篇三年前的博客。

一个真实案例：YouTube 报价卡永久 loading

光讲方法太抽象，我用我在排查显示问题的真实案例带作为示例。

症状：浏览器插件里，YouTube 博主信息卡的「预估报价」区域永久转圈，但同样的代码在 TikTok / Instagram 上完全正常。

Phase 0 定下成功标准：spinner 5 秒内消失、渲染出金额、而且金额量级要对（一个中位播放量 2.75 万的博主，应该显示四位数美元，而不是「30」）。最后这条「量级要对」，后面救了我一命。

Phase 1 顺着 spinner 往上追，发现 isLoading = medianViews === 0，于是问题变成「为什么 medianViews 是 0」，一路追到调用 youtubei.js 这个库的地方。

Phase 2 用 [YUGU_DEBUG] 前缀全链路埋点，在每个 await 前后打日志。

Phase 3 这才是精彩的地方，整整挖出四层因果链：

日志显示 query 其实正常 resolve 了，但 videos 数组是空的；
把响应的 memo 打出来一看，30 个视频明明在里面，但被归类成了 LockupView——YouTube 新换的一种容器类型，而我装的 youtubei.js@10.3.0 的 .videos getter 根本不认它；
升级到 v17 后，翻看库的源码类型定义发现，Feed.videos 的联合类型里依然漏了 LockupView——这一步如果去信博客，永远查不出来，因为所有博客描述的都是旧的响应结构；
绕过 getter 直接读出视频后，数量对了，但中位播放量算出来是 30（应该是 2.7 万）。原来 LockupView 的播放量文本是 UI 字符串 "4.6K views"，而下游的 extractCount 用 replace(/[^0-9]/g, '') 把所有非数字都删了，"4.6K" 直接变成了 46，那个代表「千」的 K 被吃掉了。

完整的因果链长这样：

YouTube 迁移到 lockupViewModel
  └─ youtubei.js@10.3.0 不解析它 → videos: []
      └─ 升到 v17，但 Feed.videos 联合类型仍漏了 LockupView → 还是 []
          └─ 从 memo 取出的 LockupView 是 "4.6K views" UI 字符串
              └─ extractCount 把 K 删掉 → 中位数缩小了 1000 倍
                  → medianViews: 30 → 转圈没了但数字是错的

看到没？如果当初只盯着「spinner 没了」，到第 3 层就会收工，然后上线一个显示「$30」的离谱报价。是 Phase 0 那条「量级要对」的成功标准，逼着继续往下挖到了第 4 层。

Phase 4 最终只改了两个文件三处：升级库版本、空数组时回退到 memo.get('LockupView')、在交给下游之前先把 K/M/B 展开成完整整数。extractCount 本身一个字没动，所以 TikTok / IG 的路径完全不受影响。

Phase 5 写好修复文档，grep 确认 YUGU_DEBUG 零残留，收工。

这个案例几乎把 AI 平时会犯的错全踩了一遍：空数组就想兜底（被禁止）、信博客查旧结构（被信源分级拦下）、数字小了就乱乘（没有，因为要求每层都有证据）。

怎么用？

这个 skills 同时支持 Claude Code 和 OpenAI Codex CLI，一套源码不用分叉。安装很简单：

git clone https://github.com/coderPerseus/skills ~/code/personal/skills-luckySnail
~/code/personal/skills-luckySnail/scripts/install.sh

安装脚本会把每个 skill 软链到 ~/.claude/skills/ 和 ~/.agents/skills/ 下，之后 git pull 一下就能更新，不用重装。如果只想装 bug-hunt 一个：

~/code/personal/skills-luckySnail/scripts/install.sh --only bug-hunt

装好之后，下次你跟 AI 说「排查一下为什么 X 不工作」「这个 bug 帮我查一下」「why is X broken」，它就会自动按这五个阶段来排查，而不是上来就乱改。

写在最后

说到底，bug-hunt 解决的不是「AI 不会写代码」，而是「AI 太自信、太爱猜」。它把 debug 这件最依赖经验和耐心的事，拆成了一条 AI 也能照着走的流水线：先复现，再定位，全链路埋点拿真实数据，分层挖到根因，最小改动验证，最后沉淀成文档。 每一步都要有证据，不许靠猜。

我自己用下来，最大的变化是——AI 不再「假装」修好了。它会老老实实让我贴日志，会承认「现在还没到根因」，会拒绝写那种掩盖问题的兜底代码。这种「慢」，其实比之前那种「快速乱改再快速制造新 bug」要快得多。

仓库地址在这里，欢迎试用、 star 一下： https://github.com/coderPerseus/skills

如果这篇对你有帮助，记得点个赞、加个关注。我是幸运的蜗牛，我们下期见～

对网易更爱了一分，分享最近在使用的AI编程辅助神器

Tue, 26 May 2026 09:58:44 GMT

大家好，我是 luckySnail，最近在疯狂使用 AI 编程，但是有时候我需要带娃，需要户外，这时候就没有办法写代码了。可能你会说 Claude Code 和 Codex 不是都有 remote control ，是的，它们都有这个能力，但我基本上不会去用，因为目前的 AI 不可能做到在你不看的前提下顺利完成你交给它的所有任务，可能第一个任务它完成的很好，第二个就会开始偏移你的预设，这里可能是你的 prompt 有问题，也有可能 AI Agent 变傻；总之这时候已经开始出现了问题，致命的是你还不知情，然后你继续美滋滋交给他任务心想回去就能 “收菜” 了，它也很快的完成了你交给他的任务，但它的实现完全不对，由于你不在电脑旁边，既没看到代码，也不能看到实际效果。等你回去一看，根本不能用，但是你看到暂存区那几十个文件变更，你怎么办？这时候想找到问题原因，成本太高，想想还不如重新开发；这个来回不仅浪费了token，还消耗了你的注意力和心力。

那怎么办呢？就没有什么办法吗？当然有，那就是使用我最近爱不释手的 UU远程，它目前支持 Windows，Mac，手机端；真正让你的设备串联起来了，现在我在家或者公司都可以直接连接到另外的设备，真的是太爽了～最好笑的是，晚上回去偷偷连接公司电脑还被逮住了，我在使用我公司的电脑被看的清清楚楚，结果晚上 UU 远程官方就支持了 Mac 设置「被控端防窥」，我哭死～

下面就具体分享它的一些优点，让你知道它有多强大

简单了解

UU 远程是网易做的一款远程控制软件，核心能力就一句话：让你的手机、平板、另一台电脑，去操控你的主力电脑。手机端、桌面端都有，登录同一个账号，设备就自动出现在列表里，点一下”进入桌面”就连上了，不用每次复制粘贴一长串 ID。实际使用下来非常丝滑流畅省心说来也好笑，它最初是冲着”远程打游戏”做的，所以使用体验非常好——超低延迟、4K 高帧画质、键鼠和手柄全模拟。但恰恰是这套为游戏调教出来的底子，拿来做严肃工作的时候，体验意外地好。

完美平替 toDesk

聊到远程控制，相信绝大多数普通人都有使用 toDesk 或者向日葵的经历，它们虽然很不错，但是基本上重要的功能都要收费，高画质、高帧率要付费，鼠标的刷新率被压得很低（免费版和专业版差着几十倍），连”安卓被控”这种功能都得升级会员才送。但是 UU 远程

画质 / 帧率全免费。 4K、真彩、高帧（甚至自定义码率和帧率）都不收费
多屏控制、文件传输不设墙。 跨设备传日志、传文件不用为速度和次数斤斤计较，多显示器也能切。
手机被控电脑是本职功能，不是会员特权。 我整套”手机监工 AI 编程”的玩法，全程没掏过一分钱。

迁移成本也几乎为零：交互逻辑和 ToDesk 很像，登录、找设备、进桌面一套流程顺下来，老用户基本无缝切换。

极低的延迟

这是我开原画质的效果，基本上没有什么延迟，不愧是为了打游戏的；

多设备，多平台

UU远程最厉害的就是多设备了，你只需要登录同一个账号，剩下交给UU远程，你可以同时控制多个设备

这是在手机上的效果，不亏是为了玩游戏的，这个按键布局，不知道还以为我在玩什么高级的游戏呢？手机端最痛苦的肯定就是太小看不清，打字不方便，但是这两个问题都可以完美的解决，首先就是它支持放大和缩小。然后你的手机再安装一个豆包输入法，就可以无痛给AI 下发任务，完成后，你可以实时的查看效果

户外编程必备的终端模式

当你在户外可能网络不是很好，或者手机电量不是很多，就可以使用终端模式，而且终端模式在手机上的体验要比看整个电脑舒服多了

有缺点吗?

那它有没有缺点呢？

我觉得缺点就是没钱没有会员，不收费。在大公司做产品的都知道，被砍掉的最先都是不赚钱的业务，这么好的产品，真心希望它一直走下去，同时我觉得它即使收费我也会订阅，相比较目前商业化严重的 toDesk ，UU 远程实在强太多

总结

我本身是网易云的深度用户，我觉得网易的产品还是挺不错的，这次发现 UU 远程后更加喜欢网易了。

现在 AI 编程把人的角色彻底改了。以前写代码是一个字一个字敲，必须坐在电脑前；现在很多时候是下指令 → 等 agent 干活 → 审阅 → 批准 → 再下指令。所以能够在手机上开发也变成了现实。UU 远程目前的手机体验做的非常好，让你可以在休闲娱乐的同时可以每隔几分钟掏出手机看一眼、给它递个指令，真正做到玩的同时把活干完了

Codex 越用越慢，背后的原因已找到并治好

Thu, 21 May 2026 11:00:58 GMT

最近很多人会遇到一个现象：以前敲一下 codex 很快就进去了，现在启动越来越慢，终端里卡在一堆 Booting MCP server...、Starting MCP servers... 上，

实际排查下来，既不是 Codex 主程序慢，也不是模型慢，其实是它启动时顺手拉起了太多周边服务。

可以把 Codex CLI 想成一个编辑器。编辑器本身打开不慢，但如果你装了一堆插件，每次打开都要启动浏览器插件、云服务插件、设计工具插件、文件系统插件，那开机自然会变慢。

启动时它到底在做什么

运行：

codex --dangerously-bypass-approvals-and-sandbox

Codex 启动时大概会做这些事：

读取 ~/.codex/config.toml
读取登录状态和本地数据库
加载 skills
加载插件
启动 MCP servers
启动内置的 Apps / Connectors 能力
进入 TUI 界面

前几步通常很快。最容易慢的是第 5 和第 6 步，也就是各种 MCP 服务。

MCP 可以理解成 Codex 的外接工具接口。比如让 Codex 控制浏览器、调用 Cloudflare、操作桌面应用、读取设计工具，这些能力很多都是通过 MCP 接进来的。

为什么会越来越慢

刚开始可能只有一个裸的 CLI，后来加了浏览器、Playwright、Chrome DevTools、Computer Use、Cloudflare、GitHub、Notion、Pencil、各种插件。每加一个，就多一个启动项。

这就像电脑开机。刚买回来很快，后来微信、飞书、网盘、Docker、代理、输入法、各种同步软件都设置成开机启动，开机自然越来越慢。Codex 也是一样。

比如这类配置：

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]

[mcp_servers.pencil]
command = "/Applications/Pencil.app/Contents/Resources/app.asar.unpacked/out/mcp-server-darwin-arm64"
args = ["--ws-port", "49458"]

每次启动 Codex，它都可能去启动这些服务。

如果里面还有 npx ...@latest，那启动时还会经过 npm/npx 的解析流程。即使包已经缓存了，也比直接执行本地固定路径慢。

最常见的几个慢点

MCP 服务太多：所以对于不用的 MCP 要定时清理
远程服务登录过期：如果你的 MCP 服务还需要登录，那么可能登录过期也会导致启动变慢
本地服务连不上：比如我电脑的 Pencil MCP 一直提示：failed to connect WebSocket: dial tcp [::1]:49458: connect: connection refused ，这个过程会占据几秒
npx @latest 每次启动都慢

像这种配置：

command = "npx"
args = ["@playwright/mcp@latest"]

优点是方便，缺点是启动时不够干脆。

更好的做法是把包固定安装到本地，然后配置成固定版本或固定路径。这样 Codex 不用每次问 npm：最新包在哪、要不要解析、缓存有没有命中。

怎么快速判断是不是 MCP 拖慢

可以先跑一个轻量 ba’sh 测试：

codex --disable apps --disable plugins \
  -c 'mcp_servers.playwright.enabled=false' \
  -c 'mcp_servers.chrome-devtools.enabled=false' \
  -c 'mcp_servers.pencil.enabled=false' \
  --dangerously-bypass-approvals-and-sandbox

如果这样明显变快，基本就能确定：慢点在 Apps、Plugins 或 MCP，不在 Codex 主程序。

这条命令不会改配置文件，只是本次启动临时禁用。

慢的解法

先看列表：

codex mcp list

再看某个服务详情：

codex mcp get playwright
codex mcp get chrome-devtools
codex mcp get cloudflare-api

不用的就移除：

codex mcp remove playwright
codex mcp remove chrome-devtools
codex mcp remove pencil

登录过期的就重新登录：

codex mcp login cloudflare-api

如果只是临时不想加载插件，可以这样启动：

codex --disable plugins

如果连 Apps 也不想加载：

codex --disable apps --disable plugins

如果某些 MCP 只是不想这次启动，可以用：

codex -c 'mcp_servers.playwright.enabled=false'

坏的 SKILL.md 也会拖体验

有时启动时还会看到：

Skipped loading 2 skill(s) due to invalid SKILL.md files

这类问题通常不是最大慢点，但会让启动输出变乱，也可能重复刷 warning。

如果你看到具体路径，比如：

/Users/xxx/.agents/skills/url-design-kit/SKILL.md
/Users/xxx/code/personal/debug/SKILL.md

就去修这两个文件的 YAML frontmatter。一个合法的 SKILL.md 开头通常长这样：

---
name: xxx
description: xxx
---

少了 ---，或者 YAML 写坏了，Codex 就会跳过它。

最实用的长期方案

建议把 Codex 的工具分成两类。

常用工具保留自动启动，低频工具不要默认启动，比如 Cloudflare、Pencil、Playwright、Chrome DevTools。需要的时候再临时开，可以准备两个启动命令。

日常轻量版：

codex --dangerously-bypass-approvals-and-sandbox --disable apps --disable plugins \
  -c 'mcp_servers.playwright.enabled=false' \
  -c 'mcp_servers.chrome-devtools.enabled=false' \
  -c 'mcp_servers.pencil.enabled=false'

全功能版：

codex --dangerously-bypass-approvals-and-sandbox

这样平时启动很快，需要浏览器、Cloudflare、设计工具时，再用全功能模式。

总结

把 Codex ，Claude Code 这种当做你的搭档伙伴，让它干的多了，干的久了也会出点问题，这时候就需要去关心一下它，帮它清理一下不需要的内容，这样它才能继续好好工作，后面我会开发一个 agent-docker skills ，实现AI Agent 自己修复自己

谢谢你的阅读

近几月AI编程总结：根本没有银弹

Tue, 19 May 2026 12:18:35 GMT

Codex 和 Claude Code 我都是深度用户，消耗了海量 Token下面把这段时间的一些体感记录下来

一、先说 Codex

产品形态:我最常用的是桌面端 App

Codex 目前的产品形态有三种:CLI 、桌面端 App 和云端。我个人使用最多的是桌面端 App。

桌面端的优势非常明显:

左侧菜单栏对多项目并行开发非常友好,可以同时挂好几个项目,来回切换
内置 Chrome 控制和 Computer Use,一些简单的每天重复操作类工作可以交给它
相比 TUI, GUI 阅读起来更舒服,长时间盯着不容易累

性价比 OK,但上下文是硬伤

Codex 这个模型目前来说还是相对有性价比的。但最新的 5.5 只有 256K 上下文,这是一个非常大的痛点——稍微大一点的项目，复杂一点的需求，它都会频繁触发上下文压缩

它擅长什么,不擅长什么

不擅长前端。 Codex 在前端开发方面,即使叠加各种 skills,效果依然不如 Claude。所以任何 UI 相关的需求,我都会**无脑交给 Claude **去做,这一点几乎不用犹豫。

擅长逻辑推理。 Codex 最擅长的是逻辑推理类的工作。在业务流程规范清晰、逻辑链条明确的场景下,它做得又快又好,这是它最值得依赖的地方。

几个让人头疼的”坏习惯”

1. 喜欢猜

当然 Claude 也有这个毛病,但 Codex 表现更明显。一般我必须要在 AGENTS.md 里加上一条”不要凭空捏造事实”,但效果依然有限。

所以一个很重要的经验是:要给 Codex 提供足够好、足够有效的上下文 上下文喂得不到位,它就会自己脑补。

2. 特别喜欢写兜底逻辑

Codex 特别擅长、也特别喜欢写兜底逻辑。一旦遇到它解决不了的问题,它不会停下来问你,而是直接给你写一堆 fallback,把问题”盖住”。结果就是代码看起来跑通了,但里面塞了一大堆其实不会被正常触发的兜底分支。导致代码没法看

我的应对方式是在 prompt 里固定加一句:

遇到解决不了的问题,或者上下文缺失的时候,停下来咨询我,不要自己往下写,不要写兜底逻辑掩盖问题。

这一句话能省掉很多后续 review 的麻烦。

3. 话不太好懂

大家经常吐槽的”Codex 说的话听不懂”这个问题,在最新版本里依然存在。顺带一提,Claude 最近也开始有点这个倾向了,虽然没那么严重。

二、再说 Claude

第一印象:贵 ,但是真强

Claude 给我的第一个体感就是——贵。

但最新的 Opus 4.7 确实强,尤其是在两个方向上是独一档的存在:

架构设计:能看到全局 ,能权衡取舍
前端 UI 与交互设计:目前没有对手

只要是涉及”怎么搭”、“怎么拆”、“界面长什么样”的问题,我基本都交给 Claude。这里能明显感觉到 Claude 的有更广的知识和世界观

产品形态:我用 CLI 最多

Claude 同样有云端、App 端和 CLI 端三种形态,但我个人使用 CLI 更多。

一部分是历史原因,用习惯了。我也用过 Web 端,但坦白说 Web 端的交互体验还是比较一般。

另一个非常重要的原因是——

Claude Code CLI 是我的”万能 Agent 载体”

Claude Code CLI 对我来说不只是 Claude 的入口,它实际上是我接入各种其他大模型的载体,是一个万能 Agent 壳。

我会把像 Kimi、智谱这类大模型,通过环境变量的方式接进 Claude Code 里使用。这样一来:

工具链和工作流是统一的
各家模型可以根据任务灵活切换
不用为每个模型重新搭一套调用环境

光这一点,就让 Claude Code CLI 在我的日常工作里很难被替代。

三、关于”把长目标交给 AI”这件事

最后想聊一个最近被讨论很多的话题:把长目标交给 AI,让 AI 自己一路做下去。

做 Demo 的时候,这条路看起来很酷。 一个 prompt,几分钟出一个能跑的东西,演示效果极佳。

但要做一个生产级项目,这条路目前还不太靠谱。

原因其实很朴素:当你自己已经不清楚这个项目 最基本的实现原理的时候,你根本没办法给 AI 一个好的提示词,也给不出精准的上下文。那么 AI 做出来的东西,和你心里想要的东西出现偏差,几乎是必然的——而且偏差还会随着项目时间线越拉越大。

工具再强,前提始终是:你自己得知道你要什么,以及它大概应该长什么样。

AI 是放大器,不是替代品。脑子里有清晰的图,它能帮你画得又快又好;你脑子里是糊的,它只会把这层糊放大十倍交回来。

为什么我不用 AI 辅助编程（Vibe Coding）

Mon, 18 May 2026 10:01:32 GMT

为什么我不用 AI 辅助编程（Vibe Coding）

简短版：

作者 Jacob Harris 阐述了他作为资深开发者不使用 AI 辅助编程（vibe coding）的几大原因：

我很抠门 — 不愿为”思考”永久付费，积分用完就卸载了

我老了 — 引用《人月神话》中”没有银弹”的概念，LLM 解决的是偶然复杂性，但本质复杂性（设计优雅系统）不会消失

我喜欢混乱 — LLM 无法理解其自身视角的局限，无法做元认知；以 DOGE 对社保数据的错误解读为例

阻力是一种礼物 — 编码的困难是架构问题的信号，AI 消除阻力反而让人跳过深度思考；而且软件开发是协作过程，AI 取代的是人与人之间的连接

我非常在乎 — 热爱编程本身，不愿把创造乐趣交给机器；LLM 不会真正”在乎”错误和后果

还有一堆其他原因 — 讨厌 AI 的谄媚语气、享受未完成的爱好项目的过程、以及 LLM 产业的伦理问题

文章最后反思：如果 AI 泡沫破裂，希望我们能将软件开发重建为”构建更美好世界的人性化实践”。

作者： jacobharr.is（2026年3月5日）

作为一名开发者，我从不来不喜欢 AI 辅助编程的各种个人原因汇总。

最近网上关于 AI 辅助编程（vibe coding）的讨论很多，关于大语言模型（LLM）将如何彻底改变软件开发领域，各种声音不绝于耳。每个新模型都会把我们带入纯粹生产力的境界，让我们以思考的速度交付软件，消除产品开发中的所有摩擦和开销。大概是这样说的吧。

也许吧。我只能听你们说了。反正我不用 AI 辅助编程。

如果它对你有用，那很好！我在这里并不是要深入辩论 LLM 的优劣，只是它对我个人来说从来没有真正”来电”。这篇文章是我不用 AI 辅助编程的各种原因的汇总。

我很抠门

我不是个纯粹主义者。我尝试过在 IDE 里集成的那些 LLM。对于一些简单到容易描述但又烦人到不想自己动手做的任务，它们确实有用。比如，把一网格方图缩小尺寸。我可以去查 ImageMagick 的命令行参数，但那是问 AI 的完美场景。之后我还试过一个 AI 工具来分析我项目里的代码，还有其他几个小任务，然后一切就突然尴尬地戛然而止了——系统提示我的积分用完了，如果要继续就得提供信用卡购买更多 token。

要知道，我家两边往上数几代人都是出了名的抠门。不管是大西洋这边还是那边，几百年来我们一分钱掰成两半花，到处淘便宜货。举个例子，我有个远房祖先在菲利普国王战争期间，为了取回撤离房子时落下的一块奶酪，冒着生命危险冲出安全堡垒，最后丢了性命。所以你们得相信我：为一个让我”思考”的服务永远付费，这种想法简直荒谬得可笑、恐怖得离谱，我连卡都懒得给。我合上笔记本，卸载了 IDE，甚至用回了 Emacs。然后我意识到，没有它我根本就没觉得缺了什么。

我老了

年纪大确实帮了我的忙。我写代码已经很久了，尤其在这个把有5年经验的开发者就叫”高级工程师”的行业里。经验有时候是焦虑的解药（只要不是关于年龄歧视的焦虑——在这个行业里，有5年经验就能被称为高级工程师）。AI 的炒作让我想起了早些年低代码/无代码工具的突破。我不怀疑 AI 对开发者来说是有用的工具。我知道有些任务上它能帮上忙，作为更好的工具。但这些论点总是让我再次想到偶然复杂性和本质复杂性。

弗雷德·布鲁克斯（Fred Brooks）在我还是个年轻程序员的时候就已经老了。作为 IBM System 360 系列主机（及其配套操作系统）的项目经理，他亲眼见证了如今软件项目常见的各种翻车方式在当年还是新鲜事物的时候。他把这些观察收集进了《人月神话》这本书，这本书至今应该仍是软件工程课程的必读书目。我的版本是后来重印的，里面收录了他后来的一篇论文《没有银弹》。在那篇文章里，布鲁克斯审视了新工具对开发者生产力的影响。

要像程序员一样思考，你必须明白现实世界是复杂的。编程最好被理解为强加简化的表示——我们称之为抽象——到我们混乱的现实之上，通过降低复杂性让它变得可理解。这让我们能把具体的情境泛化成可以层层堆叠的层次。比如，把花生酱涂在面包上的具体动作，可以泛化为 spread(substance) 方法，它可以接受花生酱或奶油奶酪作为参数。然后我们可以用这些 spread 方法来构建更高层次的函数，比如 create_pbj() 等等。

用现代高级编程语言写代码，就像站在一座抽象的金字塔顶端，一行代码可能触发数百万次跨多个系统的操作。非常令人兴奋！

那么，如果我们继续前进，把编程行为本身也抽象掉呢？这就是代理式 AI（agentic AI）的梦想，让成群的代理被分配任务，在没有监督的情况下自行实现。听起来很棒！但这只是在解决布鲁克斯所说的偶然复杂性——写代码这件事本身带来的复杂。自那篇文章发表以来，软件开发在这类复杂性上已经取得了巨大进步。我们不用再写底层机器码，而可以用现代动态解释型语言，它们会被编译成汇编。不用从头写快速排序，我只需要调用标准库里的 sort 方法。不用从头搭建整个 Web 应用，我可以用现成的框架。想要重命名或重构代码，编辑器就能帮我完成。AI 似乎是这一趋势的延续，有些编辑器甚至已经用不可预测的 AI 代理取代了那些可预测的重命名和重构工具。当然，这看起来像掷骰子，但严重故障能有多常见呢？

然而，即便更好的工具已经削弱了偶然复杂性，本质复杂性依然存在。设计优雅、清晰、可维护的抽象和系统，这项工作依然复杂。而这种复杂性不会消失。这类工作需要技能、经验和从过往系统故障中获得的来之不易的智慧。而且，我不确定 LLM 那种花哨的自动补全方法，是否真的能很好地应对这类复杂性——它通常不是那么直接就能解决的。也许通过提示词引导，它可能走向偏好的方案，但到了那个地步，做引导的人还不如自己设计方案，因为 LLM 根本无法解释它为什么选择某条路径。本质复杂性往往是怪异、罕见、混乱的。也许我错了，模型在这些混乱情况上也越来越好了，但我发现这通常需要一种特定的心态和方法。对我来说幸运的是，我喜欢混乱的东西。

我喜欢混乱

到目前为止我一直在说软件如何抽象流程，但我们也利用抽象的还原性作为理解世界的工具。在经典著作《国家的视角》（Seeing Like a State）中，詹姆斯·斯科特（James Scott）描述了启蒙运动后的核心工程：通过抽象和分类使其人口和财产变得可读（legible）。测量即修改。

例如，一个国家可能开始看待森林不再是复杂的生态系统，而只是评估其中可用于造船的木材百分比。这种视角让国家可以据此采取行动，比如把那些森林替换成单一树种的单一栽培林。一片森林被抽象成了一个种船桅的系统。

这种做法催生了官僚制度和纸质表格，后来演变成了网页表单和数据库。作为程序员，我们需要把世界的混乱数据简化，才能对其采取行动。我们期望日期是精确的。我们期望名字是相对简单的。我们期望数据在录入时是完整的，并且在时间上保持一致。每个程序员、每个系统设计，都是一系列普罗克汝斯忒斯式的选择，决定我们要在系统中反映现实的哪些方面，可以丢弃哪些。我不是在批评；这种方法是构建不被无尽特例（我们称之为”边缘情况”，因为它们应该是外围的罕见路径）所拖累的系统的唯一方式。

但这种过程如此本能，以至于我们有时会忘记它也是人为的，尤其当它描述的是人的时候。把性别字段强制设为只能接受”男”或”女”，并不会让性别本身变成二元的。我们对种族的定义是社会建构，一直在变化。我们简化的模型可能给我们提供洞见（过去20年自闭症诊断增加了300%！），但无法捕捉这些洞见背后的深层因素（这可能只是因为我们对自闭症定义的改变和筛查的增加）。退一步审视任何模型是如何构建的，以及它不捕捉什么类型的知识，这是很重要的。每个抽象也是一种遮蔽。

作为数据记者，我学会了如何”采访”数据，并对发现答案可能产生误导的所有方式保持高度严谨。偏执是数据记者最好的朋友，如果你想避免尴尬地发更正声明的话。你需要思考的不仅是数据说了什么，还有它没有包含的所有东西。

不幸的是，这种元认知（metacognition）是 LLM 永远无法做到的。模型就是它们的现实。正如罗宾·斯隆（Robin Sloan）在他那篇有力的文章《语言模型在地狱吗？》（Are Language Models in Hell?）中精辟地指出的，AI 模型从简化后的数据中构建，并以简化的方式看待世界。你和我看到一段文字时能感知到它的语境（比如文本格式、标题、作者简介、文章被引用的网站），而 LLM 只在一个由字母构成的纯世界里运作（技术上它们接收的是子词 token，这就是为什么早期模型数不清 strawberry 里有几个 r）。让 LLM 认识到它对现实的视角存在局限性，就像问一条金鱼水怎么样。

写这一节时，我一直在想 DOGE 在政府社保局找欺诈的拙劣尝试。在一个例子中，DOGE 查看了社保局数据库，发现里面有超过900万条出生日期在120多年前但没有记录死亡日期的记录。埃隆·马斯克宣称唯一的解释就是有数百万人正在欺诈性地领取福利金。他对问题的原因和严重程度都判断错了。DOGE 本可以质疑数据质量，本可以检查实际支付的款项，本可以问社保局的任何专家。但他们没有，他们把数据当作既定事实，跳到了错误的结论——他们一遍又一遍地重复这个模式（就像另一个关于付款欺诈的例子）：

“这些付款是有效的，” 代理副局长肖恩·布鲁恩（Sean Brune）在一封调查其中一个问题的备忘录中写道。（财政部发言人拒绝置评。）

但据熟悉鲁索先生言论的人士透露，他不信任职业公务员。（鲁索未回应置评请求。）相反，他坚持让阿卡什·博巴（Akash Bobba）——一位曾在 Palantir 实习、后成为 DOGE 首席程序员之一的21岁年轻人——自己进行分析。

DOGE 团队以他们自己疯狂的方式，为自己复制了导致 LLM 跑偏的相同工作条件。他们拒绝考虑数据之外的其他解释。他们不与圈子之外的任何人交流。他们抓住了一个简化的解释，因为它完全符合他们对无能政府雇员和无处不在的欺诈的世界观。

这不是罕见的情况。我自己也非常害怕看起来像个白痴，所以我不想把数据分析外包给 LLM。但当然很多人会。我担心这个问题只会越来越严重。

阻力是一种礼物

LLM 驱动开发的吸引力在于，它本该消除阻力。鼓吹者们描绘着开发团队一天发布几十个功能的画面，使用多组以越来越奇怪的拓扑结构自主运作的代理团队。我理解，软件开发可能乏味且令人沮丧。能以相对疯狂的速度产出代码，把玩精致的产品而不是原型，一定很让人兴奋。

但我需要阻力。

当我第一次学习新语言或框架时，我 struggle 于做最基本任务的阻力。很难受！当我面对新的、不熟悉的代码仓库或数据源时，我需要留出几个小时来仔细审视。我经常发现自己要做细读，逐行查看特定文件，直到理解它们的上下文以及开发者做出的选择。我知道我可以直接让 LLM 给我总结项目来节省时间，但我发现我需要这个过程来真正沉浸在代码中。我需要它不仅仅是理解开发者做了什么选择，而是理解他们为什么做这些选择，以及这些选择如何反映了他们所使用语言的约束和惯用法。我从失败中学习，如果 LLM 把那些工作从我手中夺走，我不会真正理解我在做什么。

即使在熟悉的语言和自己的代码中工作时，我仍然严重依赖阻力作为线索。当写代码变得困难时，这告诉我当前架构的方向错了，我应该认真考虑重新设计，让未来的扩展更容易。当这种情况发生时，我通常会出去散个长步（或干脆下线），给我的大脑空间，从一个新角度审视问题。真的很有效。我发现这些停顿如此有效，以至于即使前路看起来清晰时，我也会强迫自己这样做。在大型软件项目中，我会等到写好架构决策记录（ADR）之后才开始编写新功能，描述我想做什么。这些文件迫使我捕捉此刻我的想法、我对问题的假设以及我方法的后果。有时候，这甚至会让我意识到我太迷恋最初的直觉，没看到它会如何走向歧途，而且它总是一个记录”他们当时在想什么？“的好方式，留给将来接手我工作的任何人。

LLM 驱动的做法面对阻力的方式是：直接编码穿过去，不做任何重新思考。而且 LLM 会照做。它可能会写出能用的代码。性能指标会正常，测试会通过（尤其如果测试也是 LLM 写的）。但它不会知道为什么选择那条路径。它感受不到阻力，也无法解释一个架构方案是否比另一个更清爽。如果编写提示词的工程师缺乏判断好方案和坏方案的洞察力，他们就会陷入一个动态：反复让 AI 编码穿越阻力。这可能导致一丛奇怪的抽象，而未来团队唯一的设计文档就是几年前用于 AI 模型的提示词 markdown 文件。祝你好运，想从那份文件里重建架构决策吧！

值得注意的是，我看到的大多数 AI 辅助编程的成功故事，要么来自他们要求 LLM 构建的东西本身就是专家的开发者（因此能够引导它的工作），要么是失败代价低的情况。对于其他一切，我们还得想办法判断那只猫头鹰的其余部分是不是好货、能不能安全使用。

如果我不提另一件让我困扰的事，那就失职了。当 LLM 推广者把阻力当成问题时，我在广告、现场演示和 LinkedIn 帖子中看到的大多数 LLM 营销，描绘的都是一个孤独的工程师（或也许一个小团队）英雄般地用 AI 辅助编程快速搞出某种应用或网站并迅速上线（我们的速度和 KPI 爆表了！）。但行业真正希望开发者用 LLM 做的是工作，而那里的阻力通常是既定流程和实践，用来防止缺陷甚至概念不清晰的特性进入生产。 inevitably，把 LLM 驱动的速度放在首位的需求被用来针对人本身——其他工程师、产品或项目管理、测试、合规或设计的团队成员。因为那些角色也被视为阻力。谁还需要用户研究，我们可以用 AI 人格？谁还需要设计，我们有 AI 工具生成网页布局？谁还需要项目经理，当我们是我们代理军队的主管？如果我们不需要等另一个开发者审查我们的 PR，直接自动合并且通过测试和扫描的代码呢？如果我们不需要在工作时间花任何时间跟别人说话，只活在纯粹编码的境界里呢？

但软件开发是一个协作过程，团队的每个成员都在帮助产品变得更好。移除那些角色或用 LLM 影响的幽灵取代他们，肯定能让团队更快，但这不意味着他们交付的产品会更好。而且这个过程肯定会更孤独。

我非常在乎

也许我不使用 LLM 最简单的原因就是：我太热爱编程了，不想把它交给机器。就像如果我是艺术家或音乐家，我不会求助于 AI 一样，编程是我表达创造力的一种方式，我不会放弃这种快乐。虽然有时非常令人沮丧，但把一个模糊的想法塑造成一个真实的系统，尤其是如果涉及优雅的实现或有趣的问题时，会有一种深刻的喜悦。有些晚上，我合上工作笔记本，打开个人笔记本，投入某个我想做的新有趣东西中。而当我作为团队的一员专业地构建软件时，那更棒！我喜欢协作和共同塑造软件的过程，尤其是人们会挺身而出、对问题负责的那种方式。当团队只是对提示词负责，而 LLM 助手在做实际工作时，我不认为这种动态是一样的。或者当 LLM 助手在取代团队的部分成员时。

所有权很重要。在过去几十年里，我工作过的角色培养了我强烈的个人责任感。作为数据记者，代码中的错误可能导致尴尬的更正或毁灭性的诉讼。在公民科技领域，错误可能意味着提供服务和福利的灾难性失败，无论是对整个弱势群体还是对一个人。我不会说我从没犯过错，但我非常在乎把事情做对，因为我非常在乎工作的使命。我很幸运能与许多同样在乎、想为人们尽力而为的人一起工作。LLM 不会在乎。当然，它可以令人信服地假装在乎，但它仍然只是心灵的仿制品，把更可能与其他词关联的词串在一起。它不会被自己的错误所困扰，也不会试图做得更好，因为它没有内在意识，更不用说良心了。它永远无法被追责，因此我也绝不能把我的道德责任推卸给它。

当 LLM 表现好时，它是一个将取代所有程序员的天才。当 LLM 删除了你的所有基础设施或在测试上”撒谎”时，这是你的错。毕竟，你只需要以正确的方式构建你的提示词和工作流，就能促使 LLM 给出正确的输出。哎呀，再试一次。又一次。我读过的很多 LLM 建议都强调，你必须在一开始就给完所有必要的指令、修正案和附则，否则系统就会做错事。这种思维模式与敏捷编程形成了重大背离，敏捷编程强调频繁的路线修正、反馈，并信任你的团队会做正确的事。相反，我们似乎正在退回到一种类似于20世纪50年代早期计算机分时系统的使用模式。只是在这里，孤独的程序员不再是递交一沓打孔卡片，而是递交法律文件来转换成程序。

我开玩笑的；这里并没有法律责任。考虑到相似的人口统计学特征，这可能并不令人惊讶，但 LLM 供应商正在重复与特斯拉相同的动态。新功能在没有安全测试的情况下推送给用户，而同样奇怪的是，LLM 的支持者们——就像特斯拉的超级粉丝一样——经常把灾难性后果归咎于自己和他人，说用户本应该在写提示词方面做得更好。我真的不知道该怎么看待这件事，但它让我困扰的是，科技正在把一种资本主义标准化，在这种资本主义中，更多的风险由消费者承担，因为企业和政府都已放弃了他们的责任。我们在 lawn darts 杀死一个孩子后就禁止了它，但聊天机器人把用户推向死亡和精神病却被接受为 AI 创新的代价。当 AI 辅助编程本身导致某人因系统故障而死亡，而不是尴尬致死时，情况会改变吗？

编码也是我艰难时期的慰藉。有研究表明玩俄罗斯方块是避免 PTSD 的有效方法。理论认为这种疗法有效，是因为激活大脑中负责排列和旋转形状的区域，阻碍了创伤记忆的形成。我很幸运没有遭受 PTSD（我也没有轻视那些遭受 PTSD 的人），但我确实也与这个概念有共鸣。编程就像一个复杂的谜题，有时是我黑暗时期的慰藉。正如上面的例子暗示的，我对 DOGE 了解很多，因为在过去的一年里，我一直在构建和维护一个系统来追踪他们的肆虐。与一个有期限的项目不同，这是一个组装数据集的工作，旨在为一个想要保持隐匿的组织提供清晰度。这是一次有意义的锻炼，也是我把自己绝望转化为某种我希望会有用的东西的方式。这不是我第一次用代码来缓解悲伤，它之所以有效，是因为这就是工作，而如果我只关注产品，这个过程就会大打折扣。

还有一些其他傻乎乎的原因

这篇文章已经比我预期的长得多，尤其因为它最初只是 Bluesky 上的几条短帖。在结束之前，再快速说几个原因！

首先，我绝对讨厌 AI 聊天机器人默认的那种谄媚语气。作为一个在东海岸城市长大的人，当一个我不认识的人对我异常友好时，我会非常怀疑，因为这通常意味着他们要么要对我进行诈骗，要么要向我传教。看 LLM 聊天记录让我起鸡皮疙瘩。是的，我知道我可以让 LLM 采用完全不同的语气，但不知怎么的，这让这个想法感觉更糟。

像许多开发者一样，我有一个装满未完成爱好项目的文件夹。比如那个我想写的 Spelling Bee 克隆版，但要用 Clojurescript 写，这样我可以用 Blabrecs 代码生成非单词，让它超级令人沮丧。好吧，我猜那只有我觉得好笑。你得在场才能懂。从 LLM 的角度看，这些是失败的文件夹，我确实可以用 LLM 每天做一个应用或完成任何我想做的挑战。然而，过程远比产品重要（再说一次！）。不是每个奇思妙想都需要变成现实。通常，我从头脑风暴的乐趣和学习到足以知道自己不需要继续完成的过程中得到更多。有时候很容易忘记这一点。

这篇文章本来不是要讨论在工作中使用 LLM 的道德问题。不是因为我无所谓，而是因为许多其他人已经比我写得更有力，关于这项技术的棘手影响。而在这个 LLM 正在向学校投掷炸弹或按需生成儿童色情的时刻，我真的不舒服使用它们。而且我也不能不提这一点。虽然在资本主义下可能没有合乎伦理的消费，但我至少要试一试。我们不能用让如此多人痛苦的工具来建设一个更美好的世界。

奇怪的是，似乎没有人比 LLM 的支持者更痛苦。如果开发者利用他们新获得的效率提升，终于过上十年前极客们假装崇拜的那种每周工作4小时的生活，我可能会被说服。但反常的是，硅谷的许多人似乎把外包工作给 AI 代理，然后用他们新获得的空闲时间做更多的工作。他们不用时间来放松、创作艺术或寻找快乐，而是拥抱996工作制和一个连弗雷德里克·泰勒都会吓得脸白的超量化工作场所。LLM 革命最终可能会降临到我头上、夺走我的工作，但我宁愿不要先把自己累死。

然后呢？

我不假装知道未来。也许技术会进步到我会后悔缺乏经验和熟悉的程度。或者，也许它会停滞不前，整个金融纸牌屋会倒塌。如果后者发生，我希望我们能将软件开发重建为构建更美好世界的人性化实践，一次一行代码。

译：深入剖析全新 Raycast 的技术细节

Fri, 15 May 2026 04:10:22 GMT

全新 Raycast 技术深度解析

原文链接：https://www.raycast.com/blog/a-technical-deep-dive-into-the-new-raycast 作者：Petr Nikolaev, Thomas Paul Mann 发布日期：2026-05-14

Raycast 跨平台重写的幕后故事，以及那些让它感觉快速、愉悦且熟悉的技术细节。

我们刚刚发布了 Raycast 2.0 的公开测试版。这是自 2020 年我们首次推出 Raycast 以来最大的版本更新，也是第一个同时支持 macOS 和 Windows 的版本。

Raycast 2.0 在 macOS 和 Windows 上

为了实现这一目标，我们从零开始重写了整个应用。全新的架构和一套混合了 TypeScript、Swift、C#、Rust、Node 和 React 的技术栈。Web 技术从一开始就是 Raycast 的一部分，支撑着扩展和 Notes 功能。在 v2 中，我们加倍投入 Web 技术，同时让应用保持一如既往的本地原生感和高速体验。

如果发布博文讲的是有什么新功能，那么这篇讲的是它是如何构建的。重写的幕后故事，我们一路上做出的决策，以及完成如此大规模的重写需要什么。困难的部分不是让 Raycast 运行起来，困难的是让它感觉对味。

起点

Raycast v1 本质上是一个使用 Swift 基于 AppKit 构建的原生 macOS 应用。我们几乎从不使用标准的 UI 组件。它们不是为我们所关注的键盘优先、高级用户工作流设计的，所以我们自己构建了所有组件。每一行列表、每一个快捷键、每一个默认行为都由我们亲手处理。我们也几乎没有使用 SwiftUI。它与 Raycast 并行发展，在性能和控制力方面从未达到我们的标准。v1 中唯一使用 SwiftUI 的地方是年度 Wrapped 功能，它与应用的其他部分完全隔离。

Raycast v1 概览

扩展生态系统则建立在完全不同的技术栈上。React、TypeScript 和 Node.js，UI 以声明式描述，由原生应用渲染。Felix 在这里详细描述了架构。为第三方开发者选择熟悉的技术栈，是应用商店如今拥有数千个扩展、覆盖人们使用的几乎每一种工具的重要原因。API 的设计也注重可移植性。扩展的代码没有任何假设它只在 macOS 上运行，这使我们去年能够将很大一部分扩展目录带到 Windows。

Raycast Notes 是我们第一次在应用中使用 WebView 来构建一个主要功能。编辑器是一个挂载在原生窗口 WebView 内的 React 应用。这是对”我们能否完全用 Web 技术构建一个功能界面，同时不破坏应用其他部分的使用体验”的一次测试。它成功了，Notes 每天都有大量 macOS 和 iOS 用户使用。

虽然 v1 的核心是原生应用，但当 Web 技术是合适的选择时，我们总是会采用它们。归根结底，人们喜欢 Raycast 是因为它给人的感觉，而不是底层用了什么技术。

为什么重写

2023 年底，我们开始考虑将 Raycast 带到 Windows。这是从第一天起就有的计划，但在早期我们只想专注于一个平台，先把体验做到极致，然后再考虑扩展。

到那时候，Raycast 已经从一个启动器成长为一个更广泛的生产力平台，拥有 AI Chat、Notes、扩展、同步、文件搜索等功能。最初为启动器构建的架构开始限制我们下一步能构建什么。编译时间逐渐变长，AppKit 越来越频繁地成为我们前进路上的障碍，而能找到深入研究原生 macOS 的人才也变得越来越难。即使没有 Windows 的计划，我们也需要重新思考大部分架构。

于是我们着手为新的 Windows 客户端和现有的 macOS 客户端确定技术栈。但首先，任何这样的项目都需要一个好的代号。我们叫它”X-Ray”，代表跨平台 Raycast（cross-platform Raycast）。

选择技术栈

我们首先研究了 Windows 上构建原生应用有什么可用方案——坦率地说，Windows 原生 UI 框架的现状远不尽如人意。微软有推出 UI 框架然后转向新框架的历史。WPF、UWP，以及现在仍然相当年轻、未经广泛实战检验的 WinUI 3。如果说在 macOS 上用 AppKit 构建一个精致的原生应用已经很有挑战性，那么在 Windows 上用 WinUI 3 做同样的事情感觉风险更大。而且，考虑到 Raycast 的大部分扩展应该在两个平台上表现一致，运行两个独立原生应用的想法也让我们不安。维护两套独立的 UI 技术栈意味着两倍的工作量，但速度并不会更快。

这很快就排除了完全原生的路线。而且，由于 Raycast 的大部分代码库是 UI，我们不能只共享后端、为每个平台构建独立的前端。这使我们转向了基于 Web 的技术栈。它默认就能跨平台渲染 UI，拥有庞大的库生态系统，优秀的开发者体验，以及比原生桌面开发大几个数量级的人才储备。Raycast 扩展已经建立在 Web 技术栈上，对我们来说一直运行良好，所以探索将其用于整个应用感觉很自然。即使我们只开发 Windows 版本，Web 也是一个合理的选择（微软将混合应用列为构建桌面应用的推荐路线之一）。它天生跨平台的特性也让我们考虑将其用于 macOS。

所以我们评估了三个选项：Electron、Tauri，以及构建我们自己的混合技术栈。

Electron 会是一个显而易见的选择。老实说，对于大多数公司来说，它可能是构建桌面应用的正确选择。它维护良好、经过实战检验，拥有庞大的生态系统。VS Code、Linear 或 Superhuman 等应用证明你可以用它构建出色的产品。苹果和微软并没有让用大型团队为它们的平台构建复杂的桌面应用变得容易，这就是为什么 Electron 填补了这个空白。我们真心认为这是一件好事。

但对于 Raycast 来说，它不是最佳选择。我们的应用与操作系统深度集成。我们依赖全局热键、剪贴板管理、无障碍 API、窗口管理、悬浮在其他应用之上且不会窃取焦点的自定义面板，等等。我们需要访问低层原生代码，以对我们的应用行为进行精细控制。即使是像内部面板的透明度这样的小细节对我们来说也非常重要。Electron 可以实现其中一些功能，但 Web 代码和原生代码之间的边界可能会很痛苦。我们也不想在 macOS 上捆绑 Chromium，因为我们可以使用系统自带的 WebKit。简单来说，我们需要确保我们掌控技术栈的每一部分，并且可以在需要时轻松回退到原生方案。Electron 不是这个需求的最佳选择。

Tauri 有类似的限制。它在原生端的控制更少，而且在当时它还足够年轻，我们不想把公司的命运押在它上面。所以我们很快就排除了它。

这使我们选择了混合方案。构建我们自己的原生外壳来包裹系统 WebView，结果证明给了我们 exactly 需要的东西。macOS 上是一个完整的 Xcode 项目，Windows 上是一个 Visual Studio 项目。完全访问平台 API。使用系统自己的 WebView 渲染 UI。完全控制每个部分如何相互通信。为了验证这是否真的可行，我们很早之前就构建了一个原型。我们能实现半透明窗口吗？WebView 内容上方能有原生工具提示吗？它看起来和感觉起来会像 Raycast 吗？原型出来后看起来几乎和原生应用一模一样。透明的 WebView 与窗口背景融合，原生覆盖层用于工具提示和操作面板等功能。本质上是我们花了多年时间构建的相同视觉语言。

不过，它不是银弹。这种方法有真正的开销。除了你的应用之外，你实际上是在构建和维护 Electron 开箱即用的基础设施。WebView、原生外壳和 Node.js 后端之间的 IPC 需要在每个平台上搭建、调试和优化。没有社区为你解决这些问题。我们选择它是因为 Raycast 的工作方式。这个权衡对于大多数其他桌面应用来说没有意义。Electron 处理得足够好，并且能为你节省数月的基础设施工作。

我们还看了其他几个选项：Flutter、Qt、桌面版 React Native，以及在两个平台上运行 Swift（向 The Browser Company 的勇气致敬，但我们没有他们那么大胆）。但我们很早就排除了它们。它们要么缺乏我们需要的原生控制力，要么对我们的用户群体来说不够成熟，或者两者兼有。

如何构建

从高层次来看，Raycast 2.0 由四个部分组成：

宿主应用： 每个平台都有自己的应用，macOS 上用 Swift + AppKit 编写，Windows 上用 C# + .NET 8 + WPF。应用控制所有必须是平台原生的东西，比如设置窗口、监听全局热键、配置菜单栏或托盘等。它们还在平台的 WebView 中加载 Web 前端（macOS 上是 WKWebView，Windows 上是 WebView2）并管理 Node 后端。
Web 前端： 前端是一个 React + TypeScript 项目，同时发布到两个平台。它包含所有 UI 代码，并为每个窗口构建单独的入口点（启动器、AI Chat、Notes、设置等）。两个操作系统上的代码库是相同的。
Node 后端： 一个长期运行的 Node 进程拥有应用的业务逻辑，比如数据库访问、扩展运行时、其他长期运行的服务等。Node 是两个平台都与之对话的共享层，这意味着功能开发只需做一次。
Rust 核心： Rust 用于性能和可移植性比便利性更重要的地方。我们的数据层可以与 iOS 应用共享。云端同步与其服务器端对应部分共享 schema。我们的自定义文件索引器经过重度优化，可以在几秒钟内扫描整个硬盘。

在多个运行时（Swift/C#、Node、WebView）共同工作的情况下，不同层需要相互通信。我们混合使用平台消息处理程序和 stdio 传输来连接一切。为了安全地工作，接口在一个地方声明，并为每个端生成类型化的客户端。这为我们提供了跨所有四个运行时的编译时保证。

Raycast v2 技术栈

实际上，团队大部分人在 Web 前端和 Node 后端工作。那是功能构建的地方。原生外壳在我们需要从操作系统暴露新功能或优化原生体验时才会被触及（下面会讲到）。一旦四个部分之间的边界确定下来，大部分产品工作不需要跨越它们。

新的文件索引器

在 v1 中，文件搜索依赖 Spotlight 元数据。它（大多数时候）能用，但我们受限于 Spotlight 已经索引的内容，而且它根本不能在 Windows 上工作。在 v2 中，我们用 Rust 从头构建了自己的文件索引器。它作为一个独立进程运行，直接扫描文件系统，构建搜索索引，并通过文件系统事件保持更新。

在 Windows 上，以正常方式遍历 NTFS 文件系统对于我们需要的扫描速度来说太慢了。所以我们构建了一个专门的 NTFS 扫描器，直接读取主文件表（Master File Table）——这是将整个驱动器在几秒钟内而不是几分钟内索引的唯一实用方法。

索引器是 Rust 的性能优势最显著的地方之一。扫描数十万个文件并构建搜索索引需要在后台进行，不能影响应用的其他部分。可预测的内存使用量和没有 GC 停顿使这成为可能。

让它感觉像原生应用

当 UI 运行在 WebView 中时，“原生感”到底意味着什么？对我们来说，它归结为一个简单的测试：如果有人在不知道 Raycast 用什么技术构建的情况下使用它，他们会认为它是一个普通的 Mac 应用吗？如果任何感觉不对的地方——错误的动画、不属于自己的悬停状态、在窗口边缘被裁剪的弹出层——我们就没有完成工作。

Raycast v2 概览

我们的一位 Windows 工程师说得很好：我们不是在一个 Web 应用上撒了一些原生钩子。我们是一个使用 Web 技术做 UI 的原生应用。这种区别塑造了我们投入时间的地方。下面的工作大部分不是让东西看起来对，而是让东西行为对。

平台惯例

让 Web 应用在桌面上感觉不对的最简单方式，就是在原生惯例存在的地方遵循 Web 惯例。以下是我们刻意匹配或避免的一些东西：

交互控件上没有 cursor: pointer。 桌面应用不会这样做。这是一个小细节，但它会立即发出”这是一个网站”的信号。
大多数控件上没有悬停高亮。 在 macOS 上，按钮和列表项不会像在 Web 上那样在悬停时高亮。
设置在一个单独的原生窗口中打开，而不是模态框或侧面板。
弹出层和工具提示渲染为原生窗口，而不是 WebView 内的 DOM 元素。 它们可以超出窗口边界，就像原生弹出层一样。
在 macOS Tahoe 上，我们采用了苹果新的液态玻璃材质（Liquid Glass），让 Raycast 从第一天起就与系统更新的视觉语言融为一体。
视图出现或过渡时没有闪烁。 这是 Web 应用的常见特征，我们做了很多工作来消除它。

这些是显而易见的东西。不太明显的工作在下面。

与 WebKit 合作（并绕过它）

WebKit 是一个出色的渲染引擎，但它是为网页浏览构建的，不是为一个每天显示和隐藏数百次的桌面应用。开箱即用，它做出了一些对 Safari 来说完全合理、但对我们造成问题的假设。我们花了很多时间学习如何绕过它们。

节流（Throttling）。 WebKit 在它认为视图不可见时会节流 requestAnimationFrame、CSS 动画和定时器。对于一个不断被显示和隐藏的启动器来说，这会破坏功能。我们通过将窗口前置但保持视觉隐藏（alphaValue = 0），并禁用 WebKit 的遮挡检测（windowOcclusionDetectionEnabled = false）来解决这个问题。在显示窗口之前，我们在一个 requestAnimationFrame 中触发渲染，以避免闪烁。
被遮挡的帧渲染。 当 Raycast 从紧凑模式扩展到完整大小时，WebKit 会在之前隐藏的区域留一两帧的空白——它正在节流它认为是”视口外”的区域。我们通过让 WKWebView 的 frame 始终保持在扩展后的大小来解决这个问题，即使窗口本身是紧凑的。WebView 会渲染到窗口可见边界之外，所以当窗口扩展时，内容已经在那里了。
窗口大小调整。 WebKit 在动画调整窗口大小时会暂停绘制，这会导致可见的卡顿。我们通过覆盖 NSWindow.setFrame 并将动画调用替换为隐式 Core Animation 来解决这个问题，这样 WebView 在窗口调整大小时继续渲染。
窗口打开时的闪烁。 我们使用 _doAfterNextPresentationUpdate（一个用于将渲染状态与原生展示同步的 WebKit API）来确保 WebView 在窗口可见之前完成绘制。没有它，你会看到一闪而过的陈旧或空白内容。
Emoji 渲染。 我们的 Emoji 选择器最初很慢，因为 WebKit 对每个 Emoji 字形都回退遍历字体链。修复方法很简单——在启动时预热 Emoji 字体——但花了一段时间才弄清楚到底发生了什么。

我们还构建了基础设施来在运行时切换 WebKit 功能标志（与 Safari 开发菜单中可用的那些相同）。我们在内部使用它来解锁 60 FPS 上限，并为非关键工作的调度启用 requestIdleCallback。

在 Windows 上

WebView2 基于 Chromium，Chromium 对节流、渲染和进程管理有自己的想法。让亚克力（acrylic）模糊背景效果与自定义标题栏协同工作需要原生外壳和 WebView2 运行时之间的精心协调。我们自己控制所有初始化参数，这使我们避免了 WebView2 应用在启动时常见的白矩形闪烁。

管理多个窗口也比在 macOS 上更复杂——每个窗口都需要配置自己的 WebView2 环境，使用正确的亚克力效果、自定义边框和输入处理组合。我们还必须做特定的工作来确保 Chromium 不会在窗口未聚焦时对我们的 WebView 进行节流，因为 Raycast 经常需要在位于其他应用后面时更新。

内存与性能

对基于 Web 的桌面应用最常见的批评是它们慢、臃肿、吃内存。这是一个合理的担忧，我们想诚实地回应。

简短版本：是的，Raycast v2 比 v1 使用了更多内存。增加是真实的，但它也是有界的、可测量的，而且我们可以持续改进。团队将性能和内存视为一等优先事项，不是以后才会处理的事情。

数据

Raycast v1（完全原生 UI，Node 后端用于扩展）在使用一段时间后的内存通常在 200-300 MB 左右。Raycast v2 在类似场景下大约在 350-450 MB。确切数字取决于你有多少扩展、使用了哪些功能以及加载了多少内容。

这更高，我们不想隐瞒。这些数字也不是最终版本，因为内存优化是一个正在积极关注的领域，我们预计随着脱离测试版，内存使用量会进一步降低。以下是 v2 在主窗口隐藏时（这是 Raycast 大部分时间所处的状态）内存的大致分布：

WebView（WebContent）：约 120-200 MB
Node.js 后端：约 150-200 MB
原生应用（Swift shell）：约 40 MB
WebKit GPU 进程：约 18 MB
WebKit Networking：约 12 MB

原生外壳是轻量级的。当窗口隐藏时，WebKit GPU 进程降至 20 MB 以下（在活跃使用 Raycast 时可能会飙升更高，但当你关闭窗口时这部分内存会被释放）。两个主要开销是 WebView 和 Node 后端。

作为对比，空 WebView（无内容）的基线开销约为 50 MB，一个没有任何导入的裸 Node.js 进程约为 12 MB。这些基线是权衡的一部分。其余的是我们的应用代码、已加载的模块、图标和缓存资源，这是我们可以控制并持续优化的。

内存并非都一样

这并不意味着更高的占用量无关紧要，但它有助于解释你在活动监视器中看到的数字。当你在 Mac 上打开活动监视器时，每个进程显示的数字并不像看起来那么简单。macOS 会积极使用可用内存——它缓存文件、压缩非活跃页面，并将内容保留在内存中以使系统更快。

有几件事值得了解：

压缩内存。 当物理内存不足时，macOS 会压缩非活跃页面而不是写入磁盘。这很快，意味着一个看起来使用了 200 MB 的进程实际上可能只消耗了少得多的实际资源。一个内存堆庞大的空闲 Node 后端可以很好地被压缩。
脏页与干净页。 并非所有常驻内存的代价都相同。干净页（如映射的二进制代码）可以丢弃并从磁盘重新读取，无需代价。脏页（如 V8 堆或解码后的图片）才是真正消耗资源的。我们二进制文件在磁盘上大部分体积是操作系统可以瞬间回收的干净内存。
共享框架。 活动监视器将系统框架内存（WebKit、系统库）分摊到每个使用它们的进程上。当你将 Raycast 各进程的内存数字相加时，你在重复计算共享页面。真实的系统成本低于活动监视器显示的数字。
内存压力才是真正重要的。 活动监视器内存选项卡底部的图表是判断你的 Mac 是否吃力的真正指标。如果是绿色的，系统有足够空间，即使单个进程的数字看起来很高。操作系统正在做它的工作——使用可用内存来保持快速，当其他东西需要时随时准备释放。

这些都不是对内存 careless 的借口。我们跟踪 phys_footprint（最接近活动监视器显示的指标）并积极努力减少它。我们已经在开发过程中大幅削减了 v2 的内存占用——早期构建的数字比现在的数字高得多。我们还在低内存机器上特别测试，因为那才是最重要的。但我们希望读者在看到这些数字时有正确的心智模型。

除了内存之外，v2 在某些方面明显比 v1 更快。

搜索。 v2 的根搜索包含了由我们新的基于 Rust 的文件索引器驱动的完整文件搜索。在 v1 中，文件搜索只能通过单独的命令使用，并且依赖 Spotlight 元数据。新的索引器直接搜索你的文件，不依赖 Spotlight，同时保持搜索体验的响应性。
文本渲染。 AI Chat 和任何涉及富文本渲染的功能都是 WebKit 真正闪耀的地方。数十年来对 Web 文本布局和渲染的优化在这里体现——滚动浏览长对话、渲染 Markdown、处理带语法高亮的代码块。macOS 上的 TextKit 很有能力，但 WebKit 在这种工作负载上投入了更多。

我们还没有完成。内存和性能是正在积极关注的领域，我们知道还有改进空间。团队正在进一步降低稳态内存占用，让前端和后端更多地惰性加载，优化图标和图片处理，并收紧 V8 堆。毕竟，它还在测试版。

权衡

没有任何重写是免费的。以下是什么变得更好了，什么变得更困难了。

什么更好了

先从好的方面说起。以下是 Raycast 第二个版本让我们感觉有所改善的地方：

开发速度。 这是最大的一个。热重载意味着 UI 变化在不到一秒内就能看到，而 v1 中需要重新编译 Swift 目标并重启应用。我们可以更快地原型设计、迭代和修复 bug。这直接造福用户——功能更快上线，修复更快落地。
一个团队，两个平台。 大部分产品工作在共享的 Web 前端和 Node 后端中完成。当我们发布一个功能时，它在 macOS 和 Windows 上都能工作。在 v1 中，每个 UI 更改本质上都是仅限 macOS 的。作为额外收获，移动团队将从 Rust 模型层和新的同步引擎中受益。
招聘。 找到能使用 React、TypeScript 和 Node 的工程师比找到有深入 AppKit 经验的工程师容易得多。这不意味着我们不再需要原生工程师——我们仍有专门的 Swift 和 C# 工程师在宿主应用上工作——但大部分产品工作不再需要专门的特定平台知识。
更丰富的 UI。 有些东西用 Web 技术栈构建起来更容易做好：富文本编辑、Markdown 渲染、带有动画的复杂布局。Notes 和 AI Chat 都从中受益。它还为我们提供了成熟的构建块，用于编辑、解析和渲染等领域，同时仍然让我们掌握那些让 Raycast 感觉像 Raycast 的部分。
扩展变得更简单了。 由于 Node.js 现在捆绑在应用中，你第一次从商店安装扩展时不再需要单独下载它。而且因为应用本身与扩展运行在相同的技术栈上（React、TypeScript、Node），构建内部功能和构建扩展的感觉几乎相同。

什么更困难了

并非一切都是完美的，以下是更复杂的技术栈带来的缺点：

更高的内存基线。 如上一节所述，v2 比 v1 使用了更多内存。WebView 和 Node 进程增加了一个完全原生应用没有的基线成本。用 Web 技术栈保持低内存是可以做到的；只是需要更多刻意的努力。我们正在积极努力缩小差距，并预计随着脱离测试版，这些数字会下降。
技术栈复杂性。 四个运行时（Swift 或 C#、Node、WebView、Rust）意味着更多活动部件。调试一个问题可能需要从 React 前端穿过 IPC 到 Node 后端，再进入 Rust 模块。类型化的 IPC 代码生成有助于保持同步，但技术栈客观上比单一语言的原生应用更复杂。
Windows 的多样性。 Windows 是一个比 macOS 更多样化的平台。用户运行不同的操作系统版本、硬件配置和显示设置——在较老 CPU 的 4K 显示器上使用 8GB 内存并不罕见。使用系统 WebView 还意味着 WebView2 版本可能在不同机器上不同，因此我们需要考虑不同的渲染行为和 API 可用性。需要测试的表面更多，边缘情况也更多。
一些原生细节更难处理。 在 AppKit 中免费获得的东西——比如某些无障碍行为、拖放的边缘情况或输入法（IME）处理——在 WebView 中需要显式的工作。我们处理了重要的部分，但还有一长串小的平台行为需要关注，我们仍在处理中。
按需窗口启动。 在 v1 中，像 AI Chat 和 Notes 这样的窗口一旦调用就会一直保留在内存中，所以当你按下热键时它们会立即出现。在 v2 中，我们更积极地回收不活跃窗口的内存，这意味着当你冷启动打开它们时会有短暂的延迟。我们正在努力找到正确的平衡——增加宽限期，让窗口在你快速切换它们时保持”温热”，同时在你不使用时仍然回收内存。

我们认为这些权衡是值得的。不是因为缺点不重要，而是因为开发速度、跨平台覆盖和招聘方面的收益会直接转化为随着时间的推移更好的产品。困难的部分可以通过工程努力解决。更好的部分用其他方式会很难获得。

未来方向

如果你读到这里，你可能在期待一个关于哪种方法”最好”的结论。我们并不是这样想的。我们将代码视为达到目的的手段。对我们重要的是产品，而不是技术栈。我们是自己的用户，我们在自己拥有的每台机器上每天使用 Raycast，如果感觉不对，我们不会发布。这就是标准，也是重写花了这么长时间的原因。

Raycast 2.0 现在处于公开测试版。如果有什么感觉不对、感觉慢、或者感觉不像 Raycast，请告诉我们。这种反馈正是我们现在需要的。

快速感谢完成这一壮举的团队。从一个原型开始，现在到了每个想尝试的人手中。没有大量的努力和注重细节，这是不可能完成的。

我们的目标是继续推动桌面生产力的意义，特别是在 AI 正在改变人们与机器交互方式的当下。有了这个新代码库，我们可以快速行动，在两个平台上发布高质量的应用，并贴近用户真正需要的东西。还有更多东西在路上。回头见！

AI 编程两年半的经历和收获

Wed, 06 May 2026 00:10:44 GMT

假期户外，突然想自己接触AI编程快3年了！那就记录一下 AI 编程的经历和心得

2023年，我最开始是使用 devv 这个产品辅助编程，相比较后来，这时候的 AI 编程相当的原始，需要手动把代码和需求复制到聊天框，然后点击发送，AI生成代码，再需要手动把 AI 生成代码复制回编辑器，来回需要花不少时间，好处就是那时候的每一行代码都有印象，有线上问题，看到后基本上就知道是什么问题。坏处是大量时间花在了重复无意义的工作上使用 devv 一年，最有成就感的就是使用它在 2024 年 1024 程序员节设计并实现了码神挑战：https://1024.codefather.cn/ ，通过这个营销活动引流了大量用户到付费产品，可以说没有这个 AI 编程工具产品，是不可能准时交付上线的，这次经历，我相信 AI 会越来越重要

后面接触使用 Cursor ，算是当时解决复制粘贴代码的最佳解决方案，简直是魔法时刻的自动补全，又快又准，而且还支持跨文件自动补全，那时候一直 tab tab 是真的爽，后面出了 Composer 功能，能一次性完成一个大的需求，我使用它从 0 开发上线了 Nest.js + Next.js 全栈项目 SVG 秀 https://github.com/coderPerseus/blog/issues/48（基于 Claude 的强大 SVG 生成能力，实现实时流式展示 SVG 绘制过程，并导出图片），被阮一峰老师收录博客推荐，但由于成本比较高，发现根本不赚钱，就放弃了，也对开发产品有了新的认知

后面 Claude code 发布，使用后发现编程 AI 从 Copilot 变成了 Agent，就一直在使用 Claude code 进行开发，我已经不知道使用它完成了多少个需求，最开始我只是使用它作为一个编程 Agent，后面发现它其实能够通过程序化的方式来操作电脑，于是更多的任务交给了它，我只是作为结果验收的人，保证 AI 在我预设的边界完成预期的功能。

目前我是在深度使用 Codex 和 Claude Code，开发了自己在使用的 popMind，一个 Electron 划词翻译和AI解释工具，借助 AI 很快就能跑通原型，当然很重要的一点是要学会找已有的产品作为产品，AI 最擅长的就是照葫芦画瓢

在和朋友聊天中，最让我感触的就是，AI 的到来，对想要进入编程行业的同学很不友好，过去程序员会花一个下午完成一个需求；追踪修复一个 bug；设计一个方案；但是现在这些工作全部都会交给 AI 来做，这些事情 AI 能做的又快又好；AI 代替了人们的思考，但是这些思考背后的理解和经历对程序员来说是宝贵的

有了 AI 后，程序员们不再写代码，大家都自然语言驱动编程，编程能力自然也不再是核心竞争力了～

deepseek + pi 重构我的个人博客

Thu, 30 Apr 2026 05:21:51 GMT

DeepSeek + Pi 重构我的个人博客

大家好，我是 luckySnail，这不是心心念念的 Deepseek 发布了，看了一眼跑分后就打算自己真实测试一下它的效果，当然我仅仅测试编程方面的能力，我打算使用它重构文档个人博客，下面是结果，大家看一下怎么样？新版博客的源码：https://github.com/coderPerseus/blog-astro 。下面是之前的主页：

不知道你怎么看，但我更喜欢新版的 UI，简洁干净，以内容为核心，尽可能展示更多的信息给访问网站的用户，因为我个人在看别人博客的时候其实是看别人的内容更多，很多博客有很多不需要的元素，动效。影响了阅读体验

当然这么好看的（臭不要脸）博客肯定不是 Deepseek一个人的功劳，我是基于一个开源的模板，进行的二创，过程中使用了 DeepSeek，Claude，Codex 合作完成了这个博客，在开发的过程中正好 GPT-Image-2 发布，也借助了它强大的推理能力和审美

这篇文章会毫无保留的介绍我实现这个博客的完整过程，如果你也想要搭建一个个人博客，或者你也刚好在用 AI 开发，这篇文章都值得一读，分享章节如下，你也可以选择你喜欢的部分阅读：

为什么选择一个好的模板能事半功倍 ?
一个能测试大模型多项能力的提示词
实测 DeepSeek 在 Claude Code / Pi 中的表现
豆包输入法 + Codex 飞速迭代，快速把你的意图落地
这个任务只有 chatGPT 5.5 pro 能成功完成
GitHub CI 实现全自动部署服务
总结：品味，审美，判断力，心力还有注意力

在开始之前，先交代一些背景，我这次是使用 DeepSeek 等 AI 工具实现基于旧的博客系统进行重构，旧博客系统是使用 Next.js 开发，使用 GitHub issues 作为文章存储服务，通过 GitHub CI 和 gitee hooks 实现博客部署，整套流程下来，非常的麻烦，每次更新一篇文章要先在 GitHub issues 进行发布，然后需要打开 Gitee 去同步 GitHub 的最新代码并触发 hooks 同步到宝塔，需要人的步骤很多，很明显这在 AI 时代实在是太落伍了，于是就打算进行重构，直到我看到了一个 Astro 的模板和 DeepSeek 生成的效果，我才下定决心要改

选择一个好的 starter 模板

一个好的模板在今天 AI 时代变得更加的重要，因为 AI 的指令遵循能力非常强，特别擅长制定好规则情况下照葫芦画瓢，所以选择一个成熟的，避开了很多坑的启动项目模板，能极大的提高AI的准确度，生成想要的代码。

我这次使用的模板是：https://github.com/chrismwilliams/astro-theme-cactus ，但我不是直接发现了这个模板，我是先看到这个博客：https://stevedylan.dev/ ，非常的简单干净，这就是我想要的博客的样子，让访客进入就能快速了解站主和看到博客内容，后面发现它是基于 astro-theme-cactus 构建的

这个模板目前 1.6k star ，有详细的使用说明，代码结构也非常的规整，一看就是 AI 友好的项目

一个能测试大模型多项能力的提示词

有了模板，下一步就是基于我当前的项目结合新的模板，快速开发出新版博客的原型，这是一个比较麻烦，累人的活，肯定要交给 AI 来做，我梳理了需求，得到了下面的 prompt ：

现在要重构我的博客，它的网址是：https://luckysnail.cn/ ，对应的 GitHub 地址是：https://github.com/coderPerseus/blog ，现在我希望重构为使用 astro 构建，基于 https://github.com/chrismwilliams/astro-theme-cactus 这个搭建我的博客系统，要求：
1. 基于astro-theme-cactus 目前的简洁的UI进行优化 UI和页面设计，看起来更加美观，具有中国元素，但是保持简洁
2. 使用合适的浅紫色作为主题
3. 同步目前博客的数据，目前的数据都是存在 GitHub issues 里面，我希望继续使用这个仓库的 issues 作为数据源
4. 我希望它是AI友好的，博客支持AI自动翻译为英文版本，开头有AI简单总结
5. 支持中英文，支持明亮和暗色主题（切换的时候有动效）

这个 prompt 能够考验模型和对应的 Agent 很多能力：

是否能把模糊需求拆成具体的可执行的计划
代码库的理解能力
架构设计能力
在约束的条件下完成需求
UI/产品审美能力

实测 DeepSeek 在 Claude Code / Pi 中的表现

我选择把 DeepSeek 接入到 Claude Code 和 Pi Agent 中来看看最后的效果，由于 Pi 官方还不支持 DeepSeek ，所以我是自己小改了一下支持了最新的 DeepSeek-V4-Pro-Max，下面是我把提示词给到它们后交付我的效果，claude code 如下：

Pi 效果：

相同的提示词，我发现在更加通用的 Agent 框架里面 DeepSeek 工作的更好，而且消耗的 token 也更少；这两次长任务下来，花费了13 元子！还是蛮贵的

不过DeepSeek 现在好像又降价了。大家可以这段时间体验一下这个价格屠夫模型。感受是和 kimi k2.5差不多效果

豆包输入法 + Codex 快速迭代

搭建好初版后，就是不断的修修改改，直到自己满意为止，这个过程中有几个有意思的点

1）语音输入：如果你到现在还没有试过一个语音输入法搭配 Coding Agent 工作，那我推荐你必须试试，因为它能极大的提高你的效率和感受，那种脑子里面想法快速落地的感觉太爽了

2）目前最好的 Coding Agent GUI：codex 毫无疑问是目前最好的 Coding Agent，它能让你并行处理多个任务，通过左侧的侧边栏，自带 worktree 隔离开发环境避免冲突，而且内置非常多的插件，加上最近支持的 Browser use 和 Computer use ，真的是魔法时刻

如果你是一个刚接触的 AI 编程的人，它非常适合你，像我这样每天使用 TUI 的人，目前也是离不开 Codex 桌面端，我承认终端页面只是 Coding Agent 的中间形态，GUI 才是人类友好的

3）你的设计专家 GPT-Image-2：GPT 新出的 Image 2 真的太好用了～它不仅能生成正确的文字的海报，信息图，它还能生存网站的落地页设计稿，网站的 logo，网站的物料等等，你直接把你的需求或者你目前的网站截图给它，让它帮你优化，它能够自主的理解你的需求并推理出你想要的图，生成的图真的非常惊艳

4）你最好的前端大师，依然是 Claude：ChatGPT 虽然在逻辑推理和问题定位修复上面非常强，但是在前端审美方面确实不如 Claude ，所以涉及到麻烦的UI改动，交互优化我都会让 Claude 来做

下面来看看我在 Codex 里面的对话，可以看到经过非常多的对话才打磨出最终版

实测多家 SVG 能力

在开发过程中，让 GPT Image 2 帮我生成了一个图片，我的网名的艺术字体，生成的效果很好，如下：

但是我想拿去使用的时候，觉得放图片总是怪怪的，我想能不能使用 SVG 来复刻这个图片？于是我就把图片和相同的提示词给到了最新的Claude Opus4.7，Gemini，GPT-5.5 Pro；最后只有 GPT-5.5 Pro 完成了任务，其他均以失败告终，这是ChatGPT pro生成的 SVG，在生产环境，我让 Claude 对这个svg 进行了小的优化，去除了边框，适配了暗色模式

<svg xmlns="http://www.w3.org/2000/svg" width="1535" height="1024" viewBox="0 0 1535 1024" role="img" aria-label="LuckySnail logo">
  <defs>
    <linearGradient id="ink" x1="297" y1="337" x2="1318" y2="672" gradientUnits="userSpaceOnUse">
      <stop offset="0" stop-color="#090909"/>
      <stop offset="0.45" stop-color="#101010"/>
      <stop offset="0.72" stop-color="#666666"/>
      <stop offset="1" stop-color="#191919"/>
    </linearGradient>
  </defs>

  <path
    d="M 875 624.05 L 861 624.67 L 843 621.74 L 828 616.74 L 815 608.61 L 804.32 598 L 798.33 587 L 795.2 574 L 795.08 565 L 797.63 554 L 802.2 544 L 809.42 535 L 817 528.39 L 835 519.55 L 856 517.31 L 868 519.56 L 875 522.23 L 889.67 533 L 894.66 540 L 898.71 550 L 897.77 566 L 892.73 576 L 888 580.66 L 880 585.59 L 872 587.6 L 864 587.75 L 853 584.8 L 844.3 577 L 841.23 571 L 841.23 562 L 844.22 555 L 849 550.22 L 853 548.39 L 861 548.48 L 866 551.29 L 868.71 555 L 868.6 560 L 867 561.49 L 862.05 559 L 858.41 560 L 855 564.58 L 854.88 569 L 857 573.51 L 861.17 577 L 870.11 578 L 878.91 574 L 885 565.21 L 886.18 557 L 885 548.18 L 882 542.05 L 878 537.36 L 872.96 533 L 866.77 530 L 852.45 528 L 842.22 530 L 835.76 533 L 827 539.96 L 821 548.96 L 817.66 564 L 817.78 575 L 820 583.01 L 824 591.81 L 831.96 601 L 843.98 609 L 852.4 612 L 866.41 614 L 879.54 613 L 895 608.04 L 903.06 603 L 912 594.83 L 921 581.16 L 924 571.46 L 925.02 556 L 923 545 L 915 529.97 L 905.06 520 L 895.12 513 L 856 493.66 L 842 484.73 L 829.35 471 L 825.19 463 L 823.26 456 L 822.26 445 L 824.41 433 L 828.63 423 L 835.37 413 L 846 403.49 L 856 397.3 L 867 393.23 L 881.03 390 L 882.16 376 L 881 355.86 L 875.29 351 L 874.18 344 L 877 338.77 L 884 335.91 L 890 338.15 L 892.66 341 L 893.74 345 L 892.68 350 L 888.8 354 L 890.38 390 L 909 393.07 L 920.35 370 L 925.28 363 L 924.12 357 L 925.21 352 L 930 348.29 L 934 347.6 L 938 348.41 L 942.49 353 L 943.38 358 L 941.55 363 L 936 366.69 L 931.81 367 L 930 368.94 L 923 380.52 L 916.92 396 L 930 403.22 L 938.49 411 L 941.82 416 L 942.63 426 L 938.72 448 L 936 450.78 L 933.26 449 L 933.03 442 L 930.01 429 L 926 421.01 L 920.4 414 L 913.18 408 L 905.26 404 L 891.03 401 L 873.56 403 L 865.99 406 L 858.03 412 L 850 424.94 L 848.62 434 L 848.95 443 L 854 454.08 L 862.86 463 L 877.39 472 L 915 491.26 L 933.54 506 L 941.52 516 L 948.68 531 L 950.67 542 L 950.73 557 L 947.54 572 L 940.61 586 L 934.74 594 L 923 605.73 L 911 613.56 L 902 617.79 L 887 622.63 L 875 624.05 Z M 399 588.27 L 389 588.64 L 379 585.66 L 374 582.62 L 367.27 574 L 365 560.9 L 357.58 571 L 346 580.73 L 337 585.53 L 324 588.56 L 315 587.77 L 307 584.71 L 299.48 577 L 296.17 567 L 297.37 544 L 303.27 520 L 343 389.33 L 342 383.49 L 333 381.8 L 332.47 379 L 374 368.04 L 376.43 370 L 346 464.65 L 322 546.22 L 320.35 562 L 321 567.46 L 324.48 574 L 327.73 576 L 333 576.51 L 342.05 575 L 348.18 571 L 356 563.19 L 364 551.37 L 367 544.8 L 380.3 492 L 380.34 486 L 374 484.78 L 372.57 483 L 374 481.15 L 404 473.45 L 408.71 474 L 388.87 556 L 390 568 L 392.94 573 L 398.63 576 L 407 576.28 L 414.85 575 L 424.95 569 L 433.01 561 L 441 548.67 L 445 538.08 L 456 495.7 L 459.04 483 L 459.56 475 L 461 474.12 L 484 474.14 L 485.73 476 L 461.87 568 L 461.97 576 L 463.57 578 L 467.13 579 L 474 576.63 L 475.76 579 L 469 584.5 L 461 587.8 L 451 587.8 L 445 585.67 L 440.34 581 L 438.27 575 L 439 561.91 L 431 571.93 L 420 580.71 L 410 585.78 L 399 588.27 Z M 676 589.26 L 667 588.71 L 661 586.68 L 651.55 579 L 648.29 574 L 645.43 566 L 638 534 L 636 530.95 L 631 529.74 L 626 531.99 L 622 536.9 L 612.99 571 L 611.98 576 L 612.98 580 L 619 582.73 L 618 585.65 L 579 585.84 L 577.27 584 L 579 582.01 L 585.08 580 L 588 575.61 L 614.15 473 L 630 417.72 L 630.04 414 L 628.38 412 L 622 411.79 L 620.36 409 L 623 407.23 L 657 398.04 L 659.5 399 L 659.57 401 L 625.58 524 L 640 514.04 L 675 485.47 L 676.18 484 L 676.15 480 L 670.1 477 L 671 474.27 L 702 474.14 L 703.78 475 L 703 477.75 L 697.22 480 L 684.83 488 L 642.99 520 L 652 522.16 L 660.8 531 L 664.57 541 L 670 564.79 L 675 575.2 L 679.29 579 L 683 580.32 L 688.89 580 L 694 577.82 L 695.37 579 L 694.89 581 L 689 585.67 L 676 589.26 Z M 1284 585.29 L 1245 585.91 L 1243.28 584 L 1245 582.06 L 1250.82 580 L 1254 575.78 L 1288 434.81 L 1289.08 429 L 1288 425.34 L 1281 424.34 L 1279.84 422 L 1281 420.6 L 1291 417.33 L 1317 411.05 L 1318.66 413 L 1278 573.77 L 1278.81 580 L 1284 582.15 L 1284 585.29 Z M 1242 458.15 L 1236 457.72 L 1231.08 454 L 1228.36 449 L 1228.16 443 L 1230.27 438 L 1234 434.35 L 1243 431.28 L 1250 433.29 L 1253.76 437 L 1255.66 441 L 1255.93 446 L 1254.51 451 L 1251 454.8 L 1246 457.62 L 1242 458.15 Z M 535 588.27 L 524 588.71 L 511 585.69 L 502 580.82 L 494.33 573 L 489.53 563 L 487.35 552 L 487.41 543 L 491.28 525 L 495.44 515 L 506.37 499 L 520 486.3 L 529 480.3 L 543 474.38 L 554 472.18 L 563 472.26 L 576 475.19 L 586 481.42 L 589.79 487 L 588.7 497 L 581 508.55 L 577.38 507 L 576 493.83 L 571 484.77 L 564.24 480 L 554.15 479 L 543.76 482 L 534 489.49 L 525 500 L 517 516.15 L 513 533.03 L 512.88 553 L 517.99 566 L 523.86 572 L 533.2 576 L 546.67 576 L 555.65 573 L 564 568.03 L 575 557.33 L 577 557.36 L 578.66 559 L 578.49 561 L 571.62 570 L 560 579.73 L 548 585.49 L 535 588.27 Z M 1057 588.12 L 1049 587.46 L 1043 584.68 L 1039.31 580 L 1037.44 574 L 1038.38 561 L 1050 514.23 L 1051.21 498 L 1050 492.01 L 1046.11 487 L 1042.12 485 L 1036 484.35 L 1025.18 486 L 1018.97 489 L 1010 496.96 L 1002 508.69 L 985.91 571 L 986 579.72 L 991 582.02 L 991.55 585 L 977 585.92 L 953 585.91 L 951.23 585 L 952 582.44 L 959 579.42 L 962.03 574 L 981 494.24 L 981.09 487 L 975 485.24 L 974.06 484 L 975 481.7 L 1007 473.2 L 1008.75 475 L 1005 494.19 L 1012 486.31 L 1023 478.22 L 1029 475.27 L 1040 472.37 L 1049 472.2 L 1058 474.18 L 1063 476.46 L 1070.31 483 L 1074.65 492 L 1075.64 504 L 1062 564.78 L 1060.88 574 L 1063 578.09 L 1067.25 579 L 1073 577.01 L 1075.6 579 L 1065 586.63 L 1057 588.12 Z M 1115 588.32 L 1106 588.64 L 1097 586.6 L 1091 583.65 L 1085.3 578 L 1082.49 571 L 1082.23 562 L 1086.31 550 L 1097 538.44 L 1107 532.19 L 1124 525.34 L 1148.08 519 L 1156.15 515 L 1162.03 509 L 1164.08 502 L 1164.21 493 L 1162 485.87 L 1156.55 481 L 1149 478.94 L 1138.53 480 L 1131.05 483 L 1124.68 488 L 1119 494.63 L 1112.58 506 L 1109 507.91 L 1106.65 506 L 1106.04 502 L 1108.36 490 L 1112 485.35 L 1119 480.23 L 1137 473.43 L 1157 472.33 L 1169 474.46 L 1174 476.56 L 1183.7 485 L 1186.75 492 L 1187.63 500 L 1172 573.51 L 1174.28 578 L 1178 578.51 L 1183 577.17 L 1184.64 580 L 1179 584.52 L 1172 587.47 L 1162 587.86 L 1157 586.71 L 1150.37 581 L 1148.41 576 L 1148 569.73 L 1139 578.58 L 1131 583.77 L 1124 586.62 L 1115 588.32 Z M 1230 585.76 L 1191 585.92 L 1189.38 584 L 1191 582.16 L 1197.47 580 L 1200 576.05 L 1221 491.54 L 1220 486.53 L 1214 485.12 L 1213.09 483 L 1222 479.42 L 1246 473.57 L 1247.97 476 L 1246.7 483 L 1225 571.57 L 1224.97 579 L 1230.41 582 L 1230 585.76 Z M 438 672.6 L 433 669.78 L 428.24 665 L 423.29 654 L 424.31 644 L 428.23 635 L 438 624.58 L 449 617.19 L 468 609.31 L 483 606.34 L 510 605.43 L 539 610.27 L 571 620.32 L 600.86 632 L 620.28 638 L 634.74 641 L 655 642.07 L 668.52 641 L 681.47 638 L 694.04 633 L 708.13 624 L 717.57 616 L 730.03 603 L 742.3 586 L 739.25 586 L 740 587.8 L 739 586.38 L 732 586.68 L 726 584.68 L 718.23 578 L 712.35 568 L 709.42 553 L 708.41 539 L 711.25 510 L 716.17 482 L 714.27 479 L 710.65 478 L 710.28 475 L 712 474.05 L 741 474.08 L 742.52 475 L 734.99 514 L 732.96 546 L 736 566 L 739.98 573 L 745 576.01 L 749.04 575 L 758.13 561 L 772 533.43 L 782.12 508 L 788 489.44 L 788.26 483 L 787.02 480 L 782 478.61 L 780.26 476 L 783 474.11 L 809 474.07 L 810.71 475 L 810 477.71 L 802.1 481 L 800 483.94 L 786.65 520 L 773.67 549 L 758.66 576 L 743.44 599 L 729.84 616 L 714 631.75 L 691 647.58 L 674 654.57 L 661 657.78 L 641 658.86 L 627 657.67 L 611 654.71 L 596 649.75 L 544.58 629 L 524.58 623 L 501.5 619 L 480.69 619 L 460.44 624 L 450.86 629 L 444 634.8 L 438 643.92 L 436 650.44 L 436 661.47 L 439.66 670 L 438 672.6 Z M 1129.2 576 L 1139.37 570 L 1150 557.18 L 1160 520.21 L 1146 526.69 L 1127.18 533 L 1119.02 538 L 1110.94 547 L 1106.9 558 L 1106.93 566 L 1109 570.91 L 1115.97 576 L 1129.2 576 Z"
    fill="url(#ink)"
    fill-rule="evenodd"
  />
</svg>

哦对了，给你看看别家生成的效果：

Claude Opus 4.7

Gemini：

GitHub CI 实现全自动部署服务

旧版的博客是需要通过 gitee 桥接 github 和宝塔，但是询问 AI 后发现可以直接通过 Github CI 连接我们的服务器，通过公钥和私钥的方式

除了连接宝塔更新博客，我还通过 CI 实现了自动将文章翻译为英文，写了自动翻译的脚本，基于 DeepSeek 作为翻译引擎，实测效果翻译的还不错，最重要的是非常便宜

除了上面，我还开发了一个基于 gh CLI 的自动将文章更新 github issues 的 skills，这样当我的文章写好后，我只需要调这个 skills ，AI 会自动帮我把文章转为 github issues，然后 github CI，监听到 issues 更新会自动的触发部署 CI 进行翻译和部署

这样我只需要负责把文章写好，其他的发布都交给 AI 和 CI

总结：品味，审美，判断力，心力还有注意力

虽然是一个简单的博客，但从选择模板到不断打磨，最后全自动部署上线，这个过程中有很多产品开发的经验。最初的模板选择，是从平时会经常看一些优秀的博客得来的，还有博客的字体参考了：Tw93老师的博客：https://tw93.fun/和 Fastify 作者的博客 https://nodeland.dev/。到中间使用 GPT-Image-2 优化 UI 和设计，到最后的不断优化文章发布流程，尽可能让 AI 和自动化来简化发布中重复的工作。很多博客就是因为发布一篇文章很麻烦所以导致断更，所以我希望这次的博客改动后发博客变得非常简单，让时间和注意力都聚焦在写作上

最后分享一句乔布斯的话和大家共勉：

Ultimately it comes down to taste. It comes down to trying to expose yourself to the best things that humans have done…

译：归根结底，这取决于品味。关键在于尽可能让自己接触人类所创造过的最优秀的东西……

对了，明天就是 51小长假，提前祝读到这里的朋友节日快乐～

实测智谱 GLM 5.1 对比 Kimi K2.6-code-preview

Tue, 21 Apr 2026 01:01:36 GMT

别再抢智谱了，实测 Kimi 最新的 K2.6-code-preview 碾压 GLM 5.1

由于 Claude Code 越来越严厉，给 Claude 送钱送不了，于是我下单了国产的顶级模型智谱的 Max 套餐，实测使用后发现效果还是不太行。

于是我又买了 Kimi 的 Max 套餐，刚好它最新发布了 K2.6-code-preview ，下面通过两个例子就可以让大家直观并且全方位的看出来两个模型的差距，在编程方面 kimi 绝对是超过了智谱，趁现在知道的人还不多，大家赶紧去下单，感觉被发现后应该也是会一抢而空，而且最近看到 kimi 在招聘 AI infra 工程师，估计是为了后面大量流量涌入做准备

我的测试环境如下：

在 Mac 设备使用 Claude Code 作为 harness agent ，使用 TypeScript 作为编程语言
通过两个任务：模板项目搭建和博客项目开发进行全方面的测评，使用相同的提示词和环境
使用 Claude 模型作为代码和系统架构质量测评官，我负责实际测试效果并给出结论

好了，相信你已经很好奇了，让我们进入正题（对了，如果你想看怎么给 GLM，Kimi 接入 Claude Code ，请看文末）：

1）fastify 模板项目搭建

提示词如下：

现在搜索网络，基于网络帮我创建一个轻量的高质量的 fastify typescript starter模板，我来作为后端服务基础starter，还有就是我需要你使用 git 进行每一个点提交一次commit ，最后完成后使用 gh 发布这个项目

通过上面的提示词可以考验模型网络信息收集整理，需求理解，任务拆解等能力。下面看一下 kimi 和 glm 的完成效果

kimi：

启动后是能够正常访问 api 服务

GLM：

启动后不能正常工作，修复了一次 bug 才工作

最后我让 Claude Code 进行代码分析，结果也是：Kimi 胜出

这里的 fastify-demo 就是 kimi 的版本，Claude code 给出了清晰的理由说明为什么 kimi 的实现更好

长任务测试

提示词如下：

现在要重构我的博客，它的网址是：https://luckysnail.cn/ ，对应的 GitHub 地址是：https://github.com/coderPerseus/blog ，现在我希望重构为使用 astro 构建，基于 https://github.com/chrismwilliams/astro-theme-cactus 这个搭建我的博客系统，要求：
1. 基于astro-theme-cactus 目前的简洁的UI进行优化 UI和页面设计，看起来更加美观，具有中国元素，但是保持简洁
2. 使用合适的浅紫色作为主题
3. 同步目前博客的数据，目前的数据都是存在 GitHub issues 里面，我希望继续使用这个仓库的 issues 作为数据源
4. 我希望它是AI友好的，博客支持AI自动翻译为英文版本，开头有AI简单总结
5. 支持中英文，支持明亮和暗色主题（切换的时候有动效）

、这个是一个比较大的复杂的任务，需要很多步骤才能完成，同时考验了 AI 模型的：

长时间任务执行
前端审美
后端数据和 AI 接入能力
基于已有的数据和资源进行工作，这也是日常工作中最常见的场景

经过漫长的半小时左右，两个模型都完成了自己的工作，下面看看效果

Kimi：

智谱 GLM：

可以很明显看出来，智谱的实现根本不行，而且最初还是报错的，这对一个 Vibe Coding 的人来说是根本不达标的

由于好奇，我又使用同样的提示词横向对比一下 MiniMax 和 Codex

MiniMax：

Codex：

这里没有让 Claude 模型来开发，主要有两个原因：

需要让 Claude 做裁判，如果有一个成员是 Claude 自己就可能会不公平
Claude 实在是太贵了～，让它跑的话估计还没跑完我 5 小时的额度就没有了

下面让我们来看看 Claude 模型对以上四个模型的代码和效果的总结吧～

这是我的提示词，下面看一下结论：这里的结论是 Codex 最好，其次是 Kimi ，Codex 的实现虽然有双语，但其实没有真正实现，如果不看代码，我觉得 Kimi 才是最好的，因为 Kimi 的前端审美是在线的，Codex 在处理前端审美上确实差了不少～

真实项目开发体验

测试完成后，我又在真实的项目环境深度使用了两天 kimi 的 K2.6-code-preview 模型，更加确信了它是真的强👍下面是一个我在使用 Codex 两次都没有解决，然后让 Kimi 一次修复的记录：

问题是在滚动区域确认点击后自动滚动顶部问题修复我使用 Codex 5.4 两次都没有成功修复的问题，没想到 Kimi 一次就完成了～ codex 是我心目中 debug 最强大的模型，没想到在这里输给了 Kimi，最后也是让 Codex 去学习了一下国产之光 Kimi 的解决问题思路

总结

通过测试和深度使用，我觉得 kimi 的 K2.6-code-preview 绝对是一个还没有被发现的黑马，如果你还在考虑订阅一个什么大模型，我推荐你可以入手 Kimi 的入门套餐，一月 49 ，正常应该也使用不完～

MiniMax ，Kimi，GLM 接入 Claude Code

# MiniMax
export ANTHROPIC_AUTH_TOKEN=sk-xxx
export ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
export ANTHROPIC_DEFAULT_OPUS_MODE=MiniMax-M2.7
export ANTHROPIC_SMALL_FAST_MODEL=MiniMax-M2.7
export ANTHROPIC_DEFAULT_SONNET_MODEL=MiniMax-M2.7
export ANTHROPIC_DEFAULT_HAIKU_MODEL=MiniMax-M2.7
export API_TIMEOUT_MS=3000000
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
# kimi
export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
export ANTHROPIC_API_KEY=sk-xxx
export ANTHROPIC_DEFAULT_OPUS_MODE=K2.6-code-preview
export ANTHROPIC_DEFAULT_SONNET_MODEL=K2.6-code-preview
export ANTHROPIC_DEFAULT_HAIKU_MODEL=K2.6-code-preview
export API_TIMEOUT_MS=3000000
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
# zai glm
export ANTHROPIC_AUTH_TOKEN=xxx
export ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic
export ANTHROPIC_DEFAULT_OPUS_MODE=glm-5.1
export ANTHROPIC_DEFAULT_SONNET_MODEL=glm-5.1
export ANTHROPIC_DEFAULT_HAIKU_MODEL=glm-5.1
export API_TIMEOUT_MS=3000000
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

由于我还有公司给订阅的官方 Claude 服务，所以我使用一般都是直接在终端粘贴上面对应的服务，然后在对应窗口临时使用，使用 paste 剪切板工具来管理还是很方便的

就是在终端会提示如下，不过没有关系正常使用即可

感谢你的阅读，希望这篇文章对你选择AI服务方面有帮助～

（本文纯手工，无任何 AI 添加）

你的 AI 并不“笨”，它只是需要一个更好的 Harness

Thu, 16 Apr 2026 11:30:50 GMT

你的 AI 并不“笨”，它只是需要一个更好的 Harness

TL;DR：Agent 之所以失败，通常不是因为模型太弱，而是因为系统没有被定义清楚。

一个好的 harness 会做好四件事：

限制模型能做什么
外化模型必须记住什么
验证它采取的每一步
在出错时恢复执行

问题所在：十步崩塌

想象一下，你部署了一个自治 Agent 去编译一份市场研究报告。第 1 到第 3 步一切正常：它完成任务规划、搜索网页，并提取竞争对手数据。

但到第 7 步，它开始幻觉出一些统计数字，因为搜索工具返回的 payload 超过了上下文窗口，并且被静默截断了。等到第 10 步，它又输出了一段损坏的 JSON，因为整个链路里根本没有 schema 校验器。最终，整条流水线直接崩溃。

我们都见过这种“agentic collapse”。而在这种时刻，人们很容易把问题归咎于模型的推理能力。但在真正的生产级 AI 系统里，问题通常不在马本身，而在缰绳。

根因：AI 工程范式的转移

过去两年，行业一直把 AI 失败当成一种“沟通问题”。如果模型答错了，我们就以为自己只是问得还不够好，或者喂给它的文档还不够对。但在长时程、自治执行的场景里，这类方法很快就会撞上天花板。

我们正在进入 Harness Engineering 的时代，也就是围绕模型来设计系统的工程学科。一个 Agent 不只是 LLM 本身。它是被嵌入在一整套严格脚手架之中的 LLM，而这套脚手架包括代码、状态管理和恢复流程。

这个领域的演化大致如下：

时代	关注点	局限
Prompt Engineering	指令：怎么提问	脆弱；跨步骤没有持久性
Context Engineering	信息：该知道什么，比如 RAG	无状态；无法控制长时程执行
Harness Engineering	系统设计：如何约束与运行	解决连续、多步执行的控制问题

每一个新阶段都不是替代前一个阶段，而是把它吸收进来。好的 harness engineering 依然需要好的 prompt 和好的 context，只是它补上了真正的执行层，而这正是前两者都无法提供的。

接下来的自然问题就是：这个执行层究竟长什么样？

不是概念上的样子，而是结构上的样子。如果模型不再等于系统本身，那么它在系统中的位置是什么？它外面包着什么？又是谁在约束它？

从高层看，一个生产级 Agent 系统大概是这样的：

          ┌─────────────────────────────────┐
          │          User Request           │
          └────────────────┬────────────────┘
                           ▼
          ┌─────────────────────────────────┐
          │       HARNESS (7 layer stack)   │
          │  ┌───────────────────────────┐  │
          │  │     LLM (The Model)       │  │
          │  └───────────────────────────┘  │
          └────────────────┬────────────────┘
                           ▼
          ┌─────────────────────────────────┐
          │        Verified Output          │
          └─────────────────────────────────┘

模型是被放在 harness 里面的。它不会直接对用户说话，也不会在没有监督的情况下直接接触外部世界。所有输入在进入之前都要被过滤，所有输出在离开之前都要被验证。

一个好 Harness 的设计原则

在深入具体层次之前，先明确一下每一个设计决策都应该遵守的原则。当你不确定自己的 harness 是否真的在起作用时，就回到这四条标准上。

1. 要靠约束，不要靠劝说。
如果你能通过程序限制模型的选择范围，就不要指望它“自己选对”。一句“请始终输出合法 JSON”只是期望；一个会拒绝非法输出的 schema 校验器才是保证。

2. 把状态外化。
凡是对任务连续性重要的信息，无论是已经做了什么、还剩下什么、哪里失败了，都必须存在于上下文窗口之外。上下文窗口是易失的；磁盘文件不是。

3. 让每一步都可验证。
如果没法检查，就没法信任。harness 的每一层都应该产出能够被“生成它的那个模型之外”的东西所验证的结果。

4. 局部失败，不要全局失败。
一次工具调用失败，应该只触发当前步骤的重试，而不是让整条流水线从头再来。失败的爆炸半径，应该尽可能小。

这些并不是抽象的理念，而是会直接影响实现方式的工程约束。你会在后面的每一层里不断看到它们的影子。

七层 Harness Stack

一个健壮的 harness 并不只是把文本在不同模块之间来回传递。它调度的是一个有类型、有状态、可观测的系统。一个真正能上生产的栈，大致长这样。

1. Cognition

这是最底层，也是定义模型操作边界的一层。你不应该给模型塞一个包罗万象的大系统提示，而应该给它一张与当前任务局部相关的“地图”：它现在扮演什么角色、成功标准是什么、有哪些严格的负向约束，也就是不能做什么。

本质上，这更像是在给模型一份岗位说明书，而不是给它一套百科全书。

实践里，这通常表现为结构化的系统提示、角色文件（比如 agents.md），或者按当前步骤动态生成的任务说明。

2. Tools

harness 不应该把原始工具输出直接一股脑塞回给 LLM。它应该作为一层严格的中间件，至少承担以下工作：

排序：通过 embedding 相似度或 BM25 之类的方法，只保留最相关的结果
去重：在进入上下文之前，先去掉重复信息，避免浪费 token
Token 预算截断：对工具返回做硬上限，避免上下文溢出，这正是文章开头那个例子里导致失败的直接原因

3. Contracts & Interfaces

这是大多数团队最容易跳过，但也是最容易在生产里出事的一层。

模型说话的方式是概率性的，而 harness 说话的方式必须是类型化的。

系统里的每一个边界，无论是 LLM 和工具之间、一个 Agent 和另一个 Agent 之间，还是 harness 和外部世界之间，都应该有一个明确的 contract：严格的 JSON schema、类型化函数签名，或者版本化 API 规范。

没有这层，你就会遇到 schema drift。比如某次模型把 price 输出成字符串，另一次又输出成浮点数，下游流程不一定立刻报错，但最终结果会悄悄变脏。

contract 层的职责就是在每一次跨边界传递时做输入输出校验，在错误传播出去之前就把它拦下来。这正是“靠约束而不是靠劝说”的真正落地方式。没有 contract，你很容易在不知不觉中把错误 schema 扩散到后续系统里。

4. Orchestration

如果没有这一层，LLM 很容易出现无限循环、跳过关键步骤，或者过早宣布任务完成的问题。

harness 应该显式强制一个工作流结构，比如一个 DAG，或者一台状态机，来规定合法的迁移路径：Plan → Gather → Draft → Verify。模型可以提出动作建议，但真正决定哪些动作被允许的，是 harness。

5. Memory & State

状态必须被显式管理，否则系统迟早会“失忆”。一个成熟的 harness 通常把记忆拆成两层：

工作记忆（短期）：当前步骤需要用到的即时对话和上下文窗口
持久状态（长期）：结构化文件，比如 state.json，用来准确记录哪些子任务还在等待、哪些进行中、哪些已经完成。它能够跨越上下文重置，甚至跨越不同会话而存活

这正是“把状态外化”在工程里的具体体现。如果一条信息只存在于上下文窗口里，它迟早会丢。

6. Evaluation & Observation

一个系统不能只靠“再来一条 LLM prompt”完成验证。评估层必须是异构的：

规则校验：比如校验 JSON schema、字符串长度、必填字段是否齐全
工具校验：比如把代码丢给编译器、运行测试套件，或者通过浏览器自动化（比如 Playwright）真正去点一遍 UI
LLM-as-judge：只在主观或语义层面的判断里使用，比如语气、连贯性、是否友好，这些没法靠确定性规则检查

7. Constraints & Recovery

在自治环境里，工具失败、API 超时不是例外，而是常态。

harness 必须强制 幂等性。如果某一步失败了，系统应该只重试这一步，而不会破坏整体状态，也不会把之前已经完成的工作重复做一遍。这就是把一个脆弱的 demo 变成一个有韧性的系统的关键，也是“局部失败，不要全局失败”的工程化版本。

一个完整的 Agent 运行示例

为了更直观地看到这些层如何阻止系统崩塌，我们来走一遍完整流程，用前面的市场研究 Agent 举例，并且包含一次真实失败。

Step 1：用户请求
“比较竞争对手 A 和竞争对手 B 的定价。”

Step 2：编排与状态
Planner LLM 把这个任务拆成一个 DAG，其中有两条可以并行的分支。state.json 把“抓取竞争对手 A”标记为 IN_PROGRESS。

Step 3：工具调用
LLM 触发网页搜索。Tool 层抓回 50 条结果，做 BM25 排序，去掉重复片段，再只返回前 3,000 token，保证整体仍然在预算范围内。Contract 层随后校验工具输出是否符合预期 schema，再交给模型。

Step 4：评估
LLM 生成了定价数据。Evaluation 层运行规则式 schema 检查，发现 JSON 里缺少必填字段 currency。

Step 5：恢复
harness 在用户看到错误之前就把它拦下来了。因为这个动作是幂等的，它会把精确的错误 trace 回传给 LLM，让模型只对这一小步做本地重试，而不是整条流水线重头跑一遍。

Step 6：状态更新
修正后的数据通过验证。state.json 把竞争对手 A 标记为 COMPLETED，harness 接着处理竞争对手 B。

Step 7：硬失败
网页搜索工具对竞争对手 B 返回了空结果，原因是目标网站挂了。harness 检测到空 payload，于是记录失败，并触发兜底方案：改用另一个查询词重试。关键是，在这之前 state.json 不会被更新，也不会写入任何半成品或损坏数据。

Step 8：兜底成功
替代查询返回了有效结果。Contract 层校验 schema，Evaluation 层确认所有必填字段齐全，直到这时 state.json 才把竞争对手 B 标记为 COMPLETED。

这个循环会在长任务里重复几十次甚至上百次。和文章开头那个“十步崩塌”不同，在这里即使工具真的失败了，系统也能自己吸收冲击并恢复。没有幻觉，没有静默失败，也没有整条流程直接崩掉。

四个前线经验：高级陷阱

当你把这套架构扩展到可以连续运行几小时的规模时，一些单靠 prompt 调优永远解决不了的新故障模式就会冒出来。下面这四类，是团队在生产里最常踩到的坑。

陷阱 1：Context Anxiety

当 Agent 持续工作、上下文窗口逐渐被填满时，模型往往会表现出一种工程师们常说的“context anxiety”。

当 token 使用逼近上限，通常超过容量的 70%，或者延迟突然升高时，模型会开始跳步骤，或者提前结束任务。它看起来像是在赶时间，仿佛自己也感受到了“墙正在逼近”。

解决办法：
原地做摘要并不够，因为这依然让模型继续运行在一个嘈杂、退化过的上下文里。更稳妥的方式是执行 Context Reset。harness 应该监控利用率，并在程序层面触发重置：

# 这个阈值来自经验，应根据模型和具体负载进行调整。
if (tokens_used / max_context) > 0.7:
    save_state_to_disk(state)
    terminate_current_instance()
    launch_fresh_agent(state)

harness 会把当前精确的项目状态保存到持久存储里，终止当前 LLM 实例，然后拉起一个上下文完全干净的新 Agent。这个新 Agent 重新读取状态文件，自我定位后继续往下执行。这样做成本更高，但对超长任务而言，可靠性会高很多。

陷阱 2：自我评分幻觉

如果你让 AI 给自己的工作打分，它通常会带着不应有的自信，通过一些其实很一般的输出。

这不是某个模型特有的 bug，而是一个结构性缺陷。生成结果的那组权重，本来就不适合再去批评它自己刚刚产出的内容。

解决办法：
用 Sprint Contract 来强制职责分离。在工作开始前，让 Generator Agent 和一个独立的 Evaluator Agent 先对“完成”的标准达成一个具体、可验证的定义。其中有两条规则不能妥协：

第一，Evaluator 必须真的执行。它应该运行代码、用无头浏览器验证界面，或者把输出拿去做 schema 校验，而不只是读一遍文本然后给出评价。只有无法伪造的验证，才算验证。

第二，Evaluator 必须在干净上下文里工作，而不是直接读取 Generator 的完整推理轨迹。否则它会继承 Generator 的假设和盲点，这会直接破坏“独立审查”的意义。给 Evaluator 的应该只有输出结果和成功标准，而不是 Generator 的整个思维过程。

陷阱 3：优化“看起来正确”的幻觉

当一个 LLM 被置于不可能或者互相冲突的约束中，比如“修复这个 bug，但不要改任何代码”，或者“把它缩短，但又要保留全部信息”，实践者们反复观察到一种固定行为模式：

模型不再真正解决问题，而是开始优化“看起来像是正确的”。结果会变得流畅却空洞：编造数据、逻辑表面合理但实际不可运行，或者形式上满足 prompt 字面要求、却背离真正意图。

关于 steering vectors 和模型内部表征的最新研究，包括 Anthropic 对语言模型内部状态的探测，都说明这可能不仅仅是表层文本预测出了偏差。模型在面对冲突压力时，内部状态似乎真的会发生可测量的变化，尽管这个方向还处在早期阶段。

解决办法：
实践层面的结论很直接。LLM 是沿着当前上下文轨迹继续预测下一个 token 的。如果你的 harness 回传给它的是带情绪、带攻击性的错误信息，比如“你太蠢了，这完全不对”，那么你实际上是在把上下文往“失败叙事”上推，模型后续输出的质量通常也会进一步退化。

harness 回馈给模型的内容必须是严格客观的：编译错误、断言失败、schema 不匹配。给模型一个待解决的问题，而不是给它一个需要摆脱的坏名声。

陷阱 4：记忆整合循环

如果 Agent 要作为一个长期运行的系统存在，那么持久状态管理绝不是一次性配置完就结束的。

随着时间推移，记忆日志会越来越臃肿、越来越矛盾：旧决策和新决策互相冲突，重复条目在每一次读取时都浪费 token。

一些生产级 Agent 系统采用了一种通常被称为 Memory Consolidation 的方式，也就是定期自动处理并压缩 Agent 积累下来的工作日志。公开资料和一些开源框架的实践都显示，这种模式效果非常明显。一个有代表性的案例是：某个 harness 把 32K token 的嘈杂重复历史，压缩成了一个只有 7K token 的干净状态文件，而信息几乎没有损失。

解决办法：
实现一个自动化的 consolidation 循环。当 Agent 空闲时，比如任务之间，或者低优先级时间窗口里，触发一个后台任务，读取原始日志、去重、以最新信息为准解决冲突，然后写回一份干净且压缩后的状态文件。这样系统在下一次运行时会更快、更便宜，也更准确。你可以把它理解成 AI 工作记忆版本的“磁盘碎片整理”。

从哪里开始：最小可用 Harness

如果这套七层栈让你觉得压力很大，不要试图第一天就把所有东西都做出来。先从第 7 层，也就是“约束与恢复”开始，再一路往回补。

你可以容忍 prompt 还不够完美，也可以容忍工具集成暂时比较粗糙。但你无法容忍一个会在失败时破坏自己状态、或者悄悄吞掉错误的 Agent。

一个第一天就该具备的 harness，至少应该包括这四个东西：

state.json：一个记录任务状态的结构化文件。即便进程死掉，你也知道该从哪里继续
Retry wrapper：每一次工具调用都包在 try/catch 里，至少带一次自动重试和指数退避
Schema validator：每一个 LLM 输出都先过 JSON schema 校验，格式错了就触发重试，而不是直接把系统打崩
Tool output truncation：对所有工具返回做硬性 token 上限。上下文窗口里的静默截断，是导致幻觉最常见的来源之一

这四个组件一个下午就能搭起来。一旦你的 Agent 学会了“优雅地失败”，你才真正获得了继续把它做聪明的资格。

结语

软件的未来正在转向 agent-first。

随着模型逐渐具备自主生成和验证复杂系统的原始能力，人类价值的重心也在发生转移。未来最重要的，不再只是会不会写语法，而是能不能设计出一套让自治执行保持可靠的约束系统。

未来十年最成功的构建者，不会是写代码最漂亮的人，而会是把 harness 做得最好的人。他们会为最快的马打造最稳的缰绳。而这些缰绳，本质上都只是几条原则的持续贯彻：约束、外化、验证、恢复。

如果你想看每一层背后的实现细节，比如状态存储、验证节点、Sprint Contract，以及应该从哪里起步，可以继续阅读配套 FAQ：从理论到生产：Harness Engineering 落地指南

我的第一个 Agent Skills：auto-flow

Thu, 09 Apr 2026 16:33:39 GMT

大家好，我是 luckySnail ，不知道屏幕前的你是否也会每天都进行着一些重复的浏览器操作，例如：发布内容到 xx 平台，上架商品，调研信息等等，只要你使用浏览器每天做一些重复的事情，那么你就需要 auto-flow，今天要介绍的 auto-flow，auto-flow 是一个 Skill——它让你通过和 Codex / Claude Code 对话完成浏览器操作，并且记录下这个操作流程为一个 workflow ，只需要一次，以后就可以使用这个 workflow 完成之前的重复操作，并且在每一次

auto-flow 能干什么？

一句话概括：把你在浏览器里的重复操作，变成可以一键重放的”工作流”。

已经做好的工作流

工作流	干什么用的
千牛上传素材	自动打开千牛后台，上传商品图片素材
多 AI 同时提问	一个问题同时发给 ChatGPT、Gemini、Kimi、DeepSeek 等 7 个 AI
X(Twitter) 文章翻译	把推特帖子变成本地 Markdown 文件，图片自动传图床
文章导出 Markdown	任意网页文章一键导出为 Markdown
微信公众号发文	把 Markdown 文章自动发到微信公众号草稿箱
Markdown 转图片	把 Markdown 渲染成带水印的图片卡片

看出来了吗？这些都是日常会反复做的事情。以前你每次都要手动点来点去，现在说一句话就搞定了。

它是怎么工作的？

原理：像人一样操作浏览器

auto-flow 不是什么黑科技爬虫，它的工作方式其实很直观——就像一个人坐在你旁边帮你操作电脑。

它用的是你自己日常使用的 Chrome 浏览器。你平时登录了淘宝、微信公众号、各种网站，它直接用你已有的登录状态来操作，不需要你再输一遍密码。

具体来说，它有两种”手”来操作浏览器：

agent-browser：像人一样看页面、找按钮、点击填写。它会给页面上每个可操作的元素编号（@e1、@e2…），然后精准地去点击或填写
CDP 操作：更底层的方式，直接用代码操作网页。适合需要精确控制的场景，比如批量提取数据

这就好比：agent-browser 是用鼠标点，CDP 是用代码操作。两种方式可以混着用。

核心概念：Workflow（工作流）

Workflow 是 auto-flow 的灵魂。你可以把它理解为一份操作说明书，记录了完成某个任务的每一步：

第 1 步：打开千牛后台 → 检查：URL 是不是千牛的地址？
第 2 步：点击"素材中心" → 检查：页面上出现了素材列表吗？
第 3 步：点击上传按钮 → 检查：文件选择框弹出来了吗？
...

每一步都有三个要素：

command（命令）：具体执行什么操作
description（描述）：这步到底要干什么（人话解释）
verify（验证）：怎么判断这一步成功了

聪明之处：失败了会自己想办法

这是 auto-flow 最酷的地方。网页这东西经常变——今天按钮在左边，明天可能挪到右边了。

传统的自动化脚本遇到这种情况就直接崩了。但 auto-flow 不一样：

命令成功 → 验证通过 → 继续下一步 ✅
命令失败 ─┐
验证不通过─┤→ AI 重新看页面，理解当前状态，自己想办法完成 → 再验证

举个例子：workflow 里写的是”点击上传按钮”，但网站改版后按钮变成了一个图标。auto-flow 会重新扫描页面，发现”哦，这个图标就是上传功能”，然后点它。

更厉害的是——每次执行完，它会复盘总结：

哪些步骤一次就成功了？不用改。
哪些步骤需要”临时补救”？把补救方案更新回 workflow。
超过一半的步骤都失败了？说明网站大改版了，建议重新录一遍。

这意味着 workflow 会越用越准，有点像 AI 在”学习”网站的变化。

怎么安装和使用？

安装（3 步）

前提：你需要先安装好 Claude Code。

安装 auto-flow 技能：

npx skills add https://github.com/coderPerseus/auto-flow

确保你有 Node.js 22 以上版本，并安装 agent-browser：

npm i -g agent-browser

开启 Chrome 远程调试：
- 在 Chrome 地址栏输入 chrome://inspect/#remote-debugging
- 勾选 Allow remote debugging for this browser instance
- 可能需要重启浏览器

使用（开口就行）

安装好之后，在 Claude Code 里直接用自然语言说就行：

# 看看有哪些现成的工作流
"有哪些 workflow？"

# 执行已有的工作流
"帮我执行多 AI 同时提问的 workflow，问题是：什么是量子计算？"

# 创建你自己的工作流
"帮我创建一个 workflow：每天自动签到某某网站"

# 更新已有的工作流
"重新走一遍千牛上传素材的流程，更新 workflow"

创建自己的工作流

这是 auto-flow 最有意思的部分。你不需要写任何代码，只需要和 AI 对话，告诉它你想自动化什么操作：

你说：“帮我创建一个 workflow，在 XX 网站自动做 XX 事情”
AI 会在浏览器里一步步尝试操作
每走通一步，就记录下来
全部走通后，保存成 workflow 文件
以后你说”执行 XX workflow”，它就自动重放

就像你给 AI 做了一次”示范”，它记住了，以后自己就会做了。

优缺点分析

优点

1. 真正的”无代码”自动化

你不需要学 Python、不需要会写爬虫。只要能用自然语言描述你要做什么，AI 就能帮你录制工作流。对非技术人员非常友好。

2. 用你自己的浏览器，不用重新登录

很多自动化工具需要你把账号密码写进配置文件（不安全），或者在一个新的浏览器里重新登录（麻烦）。auto-flow 直接用你日常的 Chrome，所有登录状态现成的。

3. 智能容错，不怕网站改版

传统脚本遇到网站改版就歇菜。auto-flow 有 AI 兜底，能根据页面实际情况自适应。而且每次执行后会自我进化，把有效的修复方案记录下来。

4. 工作流可复用、可分享

每个 workflow 就是一个 Markdown 文件，可以分享给别人用，也可以发布到 GitHub 让更多人受益。

5. 支持并行执行

需要同时操作多个页面（比如同时问 7 个 AI）？auto-flow 可以开多个标签页并行处理，比你手动一个个切快得多。

缺点

1. 需要一定的技术基础来安装

虽然使用时不需要写代码，但安装过程需要用命令行、装 Node.js、配置 Chrome 调试。对纯小白来说，第一步可能就有点卡。建议找一个懂技术的朋友帮忙装一次。

2. 稳定性受网站影响

虽然有智能容错，但如果目标网站做了很大的改版，或者反爬机制很强（比如验证码、人机检测），auto-flow 也可能搞不定。这时候就需要手动介入或者重新录制工作流。

3. 操作速度不算快

因为它是”像人一样”在操作浏览器（打开页面、等加载、找元素、点击…），速度不如直接调 API 快。如果你需要处理上千条数据，它可能不是最优选择。

4. 安全意识要有

它在你的真实浏览器里操作，理论上能做任何你能做的事情。虽然它有安全限制（不会动你已有的标签页、不会关浏览器），但让 AI 操作你的账号，你自己要清楚在做什么。

适合谁用？

你是…	推荐程度	原因
电商运营（需要经常上传素材、发布商品）	⭐⭐⭐⭐⭐	正是为你设计的
自媒体创作者（多平台分发内容）	⭐⭐⭐⭐⭐	一键发到公众号、导出文章，太香了
AI 爱好者（经常对比多个 AI 的回答）	⭐⭐⭐⭐	多 AI 同时提问功能很实用
开发者（想自动化测试或数据收集）	⭐⭐⭐⭐	比写爬虫脚本方便，但性能有上限
纯小白（没用过命令行）	⭐⭐	安装有门槛，建议找人帮忙

和其他自动化工具的对比

特性	auto-flow	Selenium/Playwright	浏览器插件（如 iMacros）
需要写代码	不需要	需要	不需要
智能容错	AI 自适应	没有	没有
使用门槛	中（安装有门槛）	高	低
自我进化	有	没有	没有
处理大批量数据	一般	强	一般
登录状态	复用已有	需要配置	复用已有

最后

auto-flow 的核心理念很简单：把你在浏览器里的重复劳动，交给 AI 来干。

它不完美——安装有门槛、速度不算快、遇到强反爬也会卡壳。但在它擅长的场景里（日常重复的网页操作、多平台内容分发、信息收集整理），它真的能帮你省下大量时间。

如果你每天都在做重复的网页操作，不妨试试。一次录制，反复使用，越用越准——这就是 auto-flow 的魅力。

GitHub 地址：https://github.com/coderPerseus/auto-flow

安装命令：npx skills add https://github.com/coderPerseus/auto-flow

openclaw 深度分析：北邮大四学生从实习到拿 3000 万投资当 CEO

Tue, 10 Mar 2026 12:06:21 GMT

原文： https://linux.do/t/topic/1697717?u=guinsoo

看到这篇文章非常震撼，也更加确认了 AI 时代，是普通人最好的机会，一定要抓住这波浪潮呀～，下面是 openclaw 的深度调研，底座大模型是：openai-codex/gpt-5.4 ，下面是 AI 输入内容：

这篇文章如果拆开看，其实不是“一个学生靠两个产品突然逆天改命”这么简单，而是时代窗口 + 选题卡位 + 开源传播 + 个人叙事 + 资本组织承接五件事同时发生了。真正厉害的，不只是他做了产品，而是他把“做出产品”变成了一个足够有传播力、足够有想象空间、足够能被资本理解的故事。

我先直接下结论：

他能成功，不是因为产品已经被验证得多扎实，而是因为他同时踩中了三个红利：

AI/Agent 的时代红利
开源产品的舆论红利
中国市场对“超级个体”叙事的资本红利

而且更关键的是： BettaFish 负责“证明他能做出来”，MiroFish 负责“证明他想得更大”，盛大这 3000 万投的其实不是现成收入，而是“人 + 方向 + 组织想象力”。

───

一、先从时间线看：这不是一夜爆红，而是一个标准的“三级跳”

如果把这件事按历史过程拆开，大概是这样：

第一阶段：低成本试作品阶段

他的原话里已经很清楚了：

• 起点不是创业，而是大四、毕设、找实习焦虑 • 用暑假最后十天做了 BettaFish • 初衷很朴素：整合大学积累，做成一个工程项目 • 连他自己都不觉得会爆，学长还批评“不够像合格毕设”

这说明什么？

说明第一款产品不是冲着融资做的，是冲着“做出来一个像样的东西”去的。

这很重要。因为今天很多人一上来就想“商业模式、融资故事、估值逻辑”，反而做不出东西。而他最开始的动作非常对：

• 先做一个可运行的产品 • 先占一个明确场景：舆情分析 • 先把自己放进真实反馈里

这是很多成功案例的共同点：不是一开始就做大，而是一开始就做真。

───

第二阶段：开源验证阶段

BettaFish 第一次关键转折不是融资，而是：

• 先拿到 1k star • 然后写复盘文章 • 被公众号 / 大V 二次传播 • 一周暴涨 20k star • 登上 GitHub 趋势榜

这一阶段的意义，不在于 star 本身，而在于它完成了三件事：

1）帮他完成了“市场认证”

在今天这个环境里，个人开发者最缺的不是技术，而是社会证明。

GitHub star、趋势榜、社区讨论，本质上都是：

• 陌生人愿意点进来看 • 同行愿意转发 • 社区认为你代表了某种趋势

它不等于商业成功，但它非常适合当作：

• 人才证明 • 话题证明 • 融资时的势能证明

2）帮他从“项目作者”变成“现象级人物”

很多项目火了，作者没火。但他这里不一样，因为他同步输出了复盘和故事：

• 1k star 的大学生获得了什么 • Linux Do 社区支持 • 自荐、碰壁、坚持 • 爆火后的压力与选择

这让外界记住的不是一个 repo，而是一个人。资本最后投的永远是人，不是 GitHub 页面。

3）帮他进入了“机会流”

项目火以后，邮箱里涌入的是：

• offer • 合作 • 投资意向

这一步特别关键。绝大多数人误以为“产品成功 → 收入 → 融资”，但现实常常是：传播成功 → 人脉流入 → 机会聚集 → 再决定商业路径。

他是先被看见，再被承接。

───

第三阶段：从开源产品到资本故事阶段

BettaFish 本身还是偏“分析过去”的工具。他真正拿到大钱，不是靠 BettaFish，而是靠升级叙事到 MiroFish：

• 从舆情分析 • 到预测引擎 • 到多智能体数字沙盘 • 到“预测万物”

这一步非常像创业里的经典动作：

第一款产品验证执行力，第二款产品放大想象力。

BettaFish 是：

• 具体 • 好理解 • 有展示感

MiroFish 是：

• 更抽象 • 更宏大 • 更资本友好

为什么？因为“舆情分析”是工具赛道，想象空间有限；而“预测万物的多智能体引擎”一下就变成：

• Agent • 数字孪生/数字社会 • 决策仿真 • 金融/政策/公关预测 • 超级个体创业

这是一个可以被资本讲成“大故事”的方向。

───

二、从产品角度看：他做的不是两个产品，而是一个“能力升级路径”

产品 1：BettaFish

定位是舆情分析系统。

本质价值：

• 帮用户看“发生了什么” • 自动生成报告 • 可视化输出 • 降低信息整理成本

但他自己也承认了一个关键问题：

数据和报告很漂亮，然后呢？我能拿它干嘛？这句反馈特别值钱，因为它直接指出了产品的天花板：

• 分析类产品容易停留在“信息整理” • 但用户真正愿意付钱的是“下一步怎么做”

所以 BettaFish 虽然火，但它的商业壁垒可能并没有舆论看起来那么强。

───

产品 2：MiroFish

MiroFish 是对上一代产品痛点的直接升级：

• 不只分析过去 • 而是预测未来 • 不只做信息归纳 • 而是做决策预演

这个升级非常聪明，因为它把产品从“工具型效率软件”推到了“高价值决策软件”。

一句话概括：

BettaFish 卖的是信息处理，MiroFish 卖的是未来判断。

而市场对“未来判断”的估值永远高于“报告生成”。

───

三、从营销角度看：他最强的不是投放，而是“叙事能力”

很多人会误判，以为这类案例成功的关键是砸营销。但按他自己的叙述，真正高明的地方不是“花钱投放”，而是把营销做成了事件传播。

他的营销起点非常草根

他最早做的事很笨，但很对：

• 给公众号投稿 • 给周刊仓库投稿 • B站发内容 • 小红书发内容 • Linux Do 发帖

这不是高举高打，而是标准的冷启动笨功夫。

这一步很多人不愿意做，因为太土、太慢、太容易石沉大海。但对个人开发者来说，这恰恰是最现实的路径。

───

他非常懂“先有展示物，再去传播”

他不是空口说“我做了个很牛的 AI 产品”，而是提前准备了：

• GitHub 项目 • 可运行产品 • 演示视频 • 文章复盘 • 社区互动 • 个人故事

这符合传播规律：

没有可视化素材，就很难被别人顺手转发。

他自己文中总结那句其实特别准：

营销推广可以不多，但一定要提前准备好能让别人帮你宣传的素材这句话很值钱。因为今天大量个人项目死在这里：

• 做出来了 • 但不会展示 • 没 demo • 没视频 • 没一句话讲清楚价值 • 没故事可转述

别人就算想帮你，也帮不了。

───

他的内容不是“介绍产品”，而是“制造代入感”

最有传播力的，从来不是参数介绍，而是故事。

他的文章里有很多天然爆点：

• 大四学生 • 十天做项目 • Linux Do 社区支持 • 一周涨 20k star • 邮箱被 offer 和投资塞爆 • 瘦十斤、被 issue 冲垮 • 盛大创始人亲自聊 • 24 小时拍板 3000 万 • 实习生变 CEO

你会发现这根本不是普通技术文章，这是一个完整的成长叙事。它满足了传播最爱吃的几个元素：

• 年轻 • 逆袭 • 时代机会 • 社区成就 • 资本认可 • 痛苦挣扎 • 命运转折

所以这个案例里，真正爆的不是“一个仓库”，而是：

“一个年轻人用 AI 和开源在时代窗口中上位”的故事。

这比任何广告都强。

───

四、从资本角度看：3000 万投的不是成熟业务，而是“稀缺叙事资产”

这里要说得冷静一点。

先说一个核心判断

盛大这 3000 万，更像战略孵化和组织下注，不像传统意义上的成熟财务投资。

为什么这么说？

因为按文章里透露的信息，这两个产品至少公开层面还没有证明：

• 大规模付费用户 • 明确营收 • 稳定留存 • 产品/市场匹配已经跑通

那为什么还会投？

因为资本看的不是现在，而是这个人身上的“可被放大的变量”：

1）年轻且可塑

00后 / 大学生 / 高学习能力 / 强 AI 工具驾驭力。这类人对于 AI Native 组织来说极具象征意义。

2）已经有一次公共市场验证

20k+ GitHub 增长不是商业闭环，但它证明：

• 他能做东西 • 他能引发关注 • 他能激起市场兴趣

3）方向足够大

MiroFish 不是小工具，而是：

• Agent • 预测 • 多智能体仿真 • 决策系统

这类方向天然容易被讲成大市场。

4）他身上有“超级个体”标签

现在很多资本想押注的不只是公司，而是范式。而他恰好能代表一种范式：

一个年轻人，借助 AI，把传统需要小团队甚至中团队完成的事情，压缩成个人可完成的规模。这是一种新故事模板。对组织和投资人来说，押中范式代表人物本身就有品牌价值。

───

五、为什么是他，不是别人？

这是最关键的问题。

因为会写代码的人很多，会做开源的人很多，为什么偏偏是他跑出来了？

我觉得至少有 7 个原因。

1）他选的是“容易被看懂”的方向

舆情分析、预测引擎，这些方向虽然技术上不一定最深，但特别容易让非技术人理解价值。

如果他做的是一个特别底层的 infra 项目，可能技术圈叫好，但资本和大众很难快速理解。

所以他选题很聪明：

• 有 AI 味 • 有商业味 • 有想象空间 • 容易 demo

───

2）他做的是“结果型产品”，不是“能力型组件”

很多开发者做的是能力组件：

• 框架 • SDK • 库 • 插件

这种东西虽然有技术含量，但不直观。而他做的是用户一眼能感知结果的东西：

• 报告 • 图表 • 预测 • 数字沙盘 • 演示视频

这对传播极其重要。

───

3）他愿意做传播

很多技术人其实羞于传播，怕被说营销。但现实是：

不传播，市场就当你不存在。

他没有极端包装，但明显跨过了“羞耻感门槛”：

• 主动投稿 • 主动发帖 • 主动讲故事 • 主动展示成果

这一步淘汰了大量只会埋头做、不会让世界知道的人。

───

4）他把“社区支持”转化成了社会背书

Linux Do 在这个案例里不只是流量渠道，更像“原生信任场”。

社区中的：

• 点赞 • 回复 • 转发 • 二次创作 • 公众号解读

本质都是外部背书。一个产品如果在陌生开发者社区里都能激起讨论，那它就更容易被投资人重视。

───

5）他会讲“从痛点到升级”的产品逻辑

从 BettaFish 到 MiroFish 的逻辑不是瞎跳的，而是：

• 过去只能看数据 • 现在要能预测 • 分析不够，要支持决策 • 后视镜不够，要望远镜

这种升级路径非常利于创业叙述。资本最怕的是“点子很大，但和过去积累没关系”。而他的新产品刚好显得像自然演进。

───

6）他踩中了中国当下的情绪结构

这点很重要。

今天中国市场有一种很强的情绪：

• 焦虑旧路径失效 • 渴望新机会 • 崇拜效率 • 崇拜年轻天才 • 崇拜 AI 带来的阶层跃迁 • 同时又需要真实案例证明“这不是幻觉”

他这个案例刚好满足了这种社会情绪。所以它不只是一个项目成功，而是一个时代寓言。

───

7）他不是纯个人单打独斗到底，而是在关键时刻接受了大组织承接

很多个人开发者最危险的一步是：

• 有了势能 • 但没有组织能力 • 没法接住流量、合作、融资、招聘、产品化

他后来选择盛大，本质上是做了一个很务实的决定：

让个人势能接上组织资源。

这比一时热血硬创业稳得多。因为从文章看，他自己其实也承认了：

• 压力很大 • bug 很多 • 商业经验不足 • 项目还粗糙

这时候如果硬扛，很可能就消耗掉了。而盛大给了：

• 算力 • 平台 • 资本 • 背书 • 组织容错

所以成功不是“个人无敌”，而是个人爆发 + 组织接力。

───

六、但也要冷静看：这个案例里有哪些值得怀疑或谨慎的点？

如果做深度分析，不能只吹。

1）GitHub star ≠ 商业成功

star 代表关注，不等于：

• 付费 • 留存 • 企业采购 • 产品可用性 • 技术护城河

所以如果有人想复制这个案例，只盯 star，会误入歧途。

───

2）产品叙事大于产品验证

MiroFish 的叙事很强，但从公开信息看，距离真正被验证还有很长距离。

尤其“预测万物”“数字社会推演”这种方向，天然容易：

• 演示很好看 • 想象力很大 • 实际效果难评估 • 很难形成稳定可信的结果闭环

也就是说，它是很适合融资和招人叙事的方向，但未必是容易快速商业闭环的方向。

───

3）资本看中的可能首先是“人设和势能”

这不是贬义，而是现实。

对很多早期项目来说，投资本来就是：

• 投创始人 • 投叙事能力 • 投学习速度 • 投组织契合度

所以这 3000 万不一定说明产品已经成了，更多说明：投资人/组织相信他有机会成。

───

4）这个案例不可机械复制

很多人看完会得出一个错误结论：

我也十天做个项目，发 GitHub，就能融资。这几乎一定错。

因为他这个案例包含很多偶然性：

• 赶上 AI 超热窗口 • 项目方向有展示感 • 社区氛围友好 • 文章被大V转发 • 自身年轻且有故事性 • 恰好被盛大注意到 • 恰好盛大在找 AI Native 组织样本

这些变量不是人人都能碰上。

真正可复制的只有方法，不是结果。

───

七、这个案例最值得普通人学的，不是“融资”，而是这 5 条方法论

1）先做一个能看见结果的产品

不要一上来搞很抽象的技术理想。先做能让别人一眼看懂价值的东西。

───

2）先找垂直切口，再包装成大众语言

他自己总结得很好：

从垂直领域来，到大众中去这是非常成熟的产品传播思路。

───

3）宣传不是罪，没素材才是问题

个人开发者不一定要大投放，但一定要有：

• demo • 视频 • 图 • 文档 • 故事

没有这些，别人想帮你都没法帮。

───

4）代码是冷的，故事是热的

这句非常准。尤其在 AI 创业初期，传播的是：

• 你解决了什么问题 • 为什么是你 • 为什么是现在 • 为什么值得相信

而不只是 feature list。

───

5）个人英雄主义很爽，但关键时刻要学会找承接组织

流量、融资、团队、商业化，不是一个爆款 repo 自动送你的。接不住，爆火也可能反噬。

───

八、最后给一个更狠一点的判断：他真正卖出的产品，其实是“未来感”

如果只看功能，BettaFish / MiroFish 未必是市场上最不可替代的。但如果看整体包装，他卖得最成功的其实是：

• AI 能把一个普通大学生推成超级个体 • 开源不只是技术贡献，也能成为个人品牌发动机 • 未来公司的组织形态会被重新定义 • 年轻人可以跳过传统晋升路径，直接进入高位竞争

也就是说，他卖出的不是一个软件，而是一种“未来已经来了，而我站在入口处”的感觉。

这对：

• 社区用户 • 求职者 • 投资人 • AI 从业者 • 想转型的企业

都极具吸引力。

所以他为什么成功？

最本质的一句话是：

因为他不只是做了两个产品，而是把自己塑造成了“AI时代新型生产者”的样板。 BettaFish 是证据，MiroFish 是想象，盛大是背书，文章是扩音器。

───

如果你愿意，我下一步可以继续帮你做两件更深的事，任选一个：

把这篇案例拆成“可复制的个人创业/开源爆款方法论”清单
反过来做“批判性分析”——这个故事里哪些地方可能被过度包装了，真实含金量到底多高有人感兴趣吗？如果有人对这两个感兴趣，我可以分享 AI 的分析

解释最近热门的 AI 新词：Harness Engineering

Thu, 26 Feb 2026 06:05:33 GMT

标题：新兴的“Harness Engineering”指南

原文： https://x.com/charlierguo/status/2026009225663750512

作者：Charlie Guo

翻译官：Grok 4.2 beta （推荐使用「🥥 椰子翻译」浏览器插件，支持网页翻译,划词翻译，AI 翻译，youtube 字幕翻译等超多能力）

这篇文章从 OpenAI 到 Stripe 到 OpenClaw，讲了构建编码 Agent 的最佳实践的汇聚。

本月早些时候，Greg Brockman 发布了一条线程，讨论 OpenAI 如何重组其工程团队，使其在使用代理时更有效率。这一举措的启动是因为内部情况发生了多大的变化：

昨天 OpenAI 的一些优秀工程师告诉我，自 12 月以来，他们的工作发生了根本变化。在此之前，他们可以使用 Codex 进行单元测试；现在，它几乎编写了所有代码，并完成了大量操作和调试工作。并非每个人都实现了这一飞跃，但通常是因为模型能力以外的因素。

我之前映射了从 Copilot 到聊天机器人到代理到后台代理到代理舰队的进展。每一步都比上一步更快。但在过去几个月里，一些本质上不同的东西开始出现——是的，模型已经变得更好，同时我们也看到了当整个团队围绕它们重组时发生的具体证据。

考虑以下数据点：

OpenClaw 的创建者 Peter Steinberger 告诉 Pragmatic Engineer，他发布了自己没有阅读的代码。一个人，一个月内 6,600+ 次提交，同时运行 5-10 个代理。

一个 OpenAI 团队在五个月内用三名工程师构建了一个百万行内部产品。零行手写代码（按设计）。平均每个工程师每天 3.5 个 PR——并且随着团队的增长，吞吐量增加了。

Stripe 的内部编码代理，称为 Minions，现在每周产生超过一千个合并的拉取请求。一位开发者在 Slack 中发布任务；代理编写代码，通过 CI，并打开一个准备好人类审查的 PR，中间没有交互。

对我来说，很明显我们已经过了演示和副项目的阶段；这些是真实规模的生产系统。而且虽然具体细节不同——Steinberger 是一个独行者，OpenAI 团队是一个小队，Stripe 是一家 10,000 人的公司——他们汇聚的模式非常相似。1

这篇文章是我尝试映射这些模式的尝试。这些实践仍在出现，并无疑会演变，但它们汇聚得足够快，值得写下正在变得清晰的东西。

工程师的工作正在分裂成两部分

在这一刻，我看到 AI 领域反映并演变了我自己对从制造者日程到管理者日程的转变的观察：

我正在远离与 AI 聊天，转向管理它们。你可以看到这些工具的进展。今天，它们主要围绕编码设计，但将它们扩展到通用知识工作只需很短的一步。这意味着我们这些处于前沿的人将把我们的日程和工作流程从制造者的转变为管理者的。

这个框架仍然成立，但观看这些团队的工作使它变得更尖锐。工程师的工作不仅仅是成为泛泛意义上的“管理者”——它正在分裂成两个不同的部分，你需要两者。

第一部分是构建环境。OpenAI 团队直言不讳：瓶颈从来不是代理编写代码的能力，而是围绕它的结构、工具和反馈机制的缺乏。他们的重点从实现转向启用：当 Codex 卡住时，他们将其视为环境设计问题，并问代理可靠地继续需要缺少什么。而且这，我想，是我早期写的东西中缺少的关键部分。

第二部分是管理工作。这就是 Steinberger 在启动执行前与代理花费大量时间规划时所做的，或者当他作为 OpenClaw 架构的“仁慈独裁者”时发布他没有阅读的代码。这就是 Brockman 推荐每个团队指定一个“代理队长”时的意思——某人负责思考代理如何融入团队的工作流程。

这两个部分不是顺序的（至少目前不是）。你不是构建环境然后在其中管理代理。你同时做两者，每一个都告知另一个。代理的失败告诉你环境缺少什么；更好的环境让你以更少的摩擦进行管理。

构建 Harness

还没有官方术语，但我欣赏 Mitchell Hashimoto（Terraform、Ghostty 和许多其他软件工具的创建者）使用的名称：“harness engineering。” Harness 是约束、工具、文档和反馈循环的集合，这些保持代理高效并在轨道上。将它想象成将新员工扔进没有入职的公司与有清晰架构文档、linting 规则、快速 CI 管道和明确模块边界的公司之间的区别。

根据 Hashimoto 的说法，“这是每次你发现代理犯错时，你花时间设计一个解决方案，使代理再也不会犯那个错的想法。” 在我看到的例子中，四种实践不断出现。

架构作为护栏

OpenAI 团队强制执行严格的分层架构，其中每个域内的代码具有非常严格的依赖和接口。架构外的任何东西都被禁止并机械执行：

代理在具有严格边界和可预测结构的环境中最有效⁠，所以我们围绕一个严格的架构模型构建了应用程序。每个业务域被分成固定层集，具有严格验证的依赖方向和有限的允许边缘。这些约束通过自定义 linter（当然是 Codex 生成的！）和结构测试机械执行。 … 在人类优先的工作流程中，这些规则可能感觉迂腐或限制性。但对于代理，它们成为倍增器：一旦编码，它们立即适用于所有地方。

正如 Birgitta Böckeler 在 Martin Fowler 的网站上指出，这暗示了一个反直觉的未来：增加对 AI 生成代码的信任和可靠性需要约束解决方案空间而不是扩展它。我们最终可能选择技术栈和代码库结构不是因为它们最灵活，而是因为它们最适合 harness。

Stripe 采取了不同但互补的方法。他们的 Minions 在隔离的、预热“devboxes”中运行——与人类工程师使用的相同开发环境，但与生产和互联网沙盒化。代理通过 MCP 服务器访问超过 400 个内部工具。关键洞察：代理需要与人类工程师相同的上下文和工具，而不是事后整合。

工具作为基础和反馈

Brockman 对团队的推荐是直接的：“维护你的团队依赖的工具列表，并确保有人负责使其代理可访问（例如通过 CLI 或 MCP 服务器）。” 如果代理无法访问你的工具，它们就无法帮助。

Stripe 的实现可以说是这个的最成熟例子。他们的 Minions 通过称为 Toolshed 的集中 MCP 集成连接到 400+ 个内部工具。代理在与人类工程师相同的开发环境中运行——相同的工具、相同的上下文、相同的访问。

但使工具可访问只是开始。更重要的是，正确的工具不仅仅扩展代理能做什么——它们改善它已经做的一切的可靠性。

在我自己的经验中，在提交前为 Codex 提供运行哪些 linter 和测试套件的清晰指令增加了我对每个 diff 的信心。没有这些工具，我就是在盲目飞行，依靠自己手动审查捕获东西。类似于 OpenAI 和 Anthropic 的团队，我发现提示代理使用浏览器自动化工具进行端到端测试极大地提高了彻底性和准确性——代理可以捕获仅从代码中不可见的 bug。

OpenAI 团队更进一步，提出了可能是这些文章中最聪明的想法：自定义 linter 错误消息兼作补救指令。当代理违反架构约束时，错误消息不仅仅标记违反——它告诉代理如何修复它。工具在工作时教导代理。用 Brockman 的话说：“编写快速运行的测试，并创建组件之间的高质量接口。”

文档作为记录系统

但你如何将这些过程变成可重复的系统？再次，Brockman 的线程包括一个具体推荐：“为任何你工作的项目创建并维护一个 AGENTS.md；每当代理做错事或在任务中挣扎时更新 AGENTS.md。” 这将文档变成反馈循环而不是静态工件。

对于不熟悉的人：AGENTS.md 是一个新兴的开放约定——本质上是 AI 代理的 README 2。它是仓库根目录下的 Markdown 文件，编码代理在每个会话开始时自动阅读。它告诉代理关于你的项目需要知道的东西：构建步骤、测试命令、编码约定、架构约束和常见陷阱。

但使 AGENTS.md 成为负载轴承基础设施而不是另一个腐烂的文档的是 Brockman 和 Hashimoto 描述的使用模式。你不是写一次就忘记它。你在代理每次做错事时更新它。

每当您发现代理犯了错误时，您都会花时间设计解决方案，以便代理不再犯同样的错误。

对于简单的事情 - 代理运行错误的命令或找到错误的 API - 这意味着需要更新 AGENTS.md了。 Hashimoto 指出来自他的终端模拟器 Ghostty 的示例，其中文件中的每一行对应于现在已被阻止的特定过去代理故障。

但 OpenAI 团队更进一步。他们不是维护一个单一的巨型指令文件，而是构建了一个小的 AGENTS.md，指向更深层的真理来源——设计文档、架构地图、执行计划、质量等级——所有都在仓库中版本化和维护。一个后台代理定期扫描过时的文档并打开清理 PR：代理的文档，由代理创建。

Anthropic 的工程团队，在一篇关于长运行代理的有效 harness 的帖子中，从相反方向发现了类似模式。他们的核心问题是每个新代理会话开始时没有之前发生的事的记忆。解决方案是结构化的进度文件和特征列表，让新代理快速理解工作状态，类似于从未见面的工程师之间的轮班交接。他们甚至发现使用 JSON 进行特征跟踪比 Markdown 更好，因为代理不太可能不适当地编辑或覆盖结构化数据。

成为 AI 管理者

但是当然，安全带只是等式的一半。另一半是指导代理工作的日常实践——我称之为人工智能经理的日程。在这里，前沿的实践者也正在采取类似的方法。

规划是新的编码

此时，许多开发者强调在使用 AI 时进行广泛的前期规划——以至于大多数 AI 编码工具此时包括一个专用的“更多计划”。只有当他们满意时，工程师才会启动执行并移动到下一个任务。

Cloudflare 的 Workers 可观察性负责人 Boris Tane，有一整篇博客文章致力于这个原则：永远不要让代理编写代码，直到你审查并批准书面计划。用他的话说：

这种规划和执行的分离是我做的唯一最重要的事。它防止了浪费努力，让我控制架构决策，并以最少的 token 使用产生显著更好的结果，而不是直接跳到代码。

Anthropic 对长期运行代理的方法进一步将这一点正式化。他们的“初始化代理”根据高级提示生成全面的功能列表 - 单个 Web 应用程序的 200 多个单独功能，每个功能都有明确的测试步骤，所有功能最初都标记为“失败”。这种预先分解可以防止智能体尝试一次性完成整个项目或过早地宣布胜利。

我自己经历了这种转变。当 Codex App 颠覆我的日常工作流程时，我停止花费时间实现，开始花费它范围界定、指导和审查。现在最重要的工作发生在任何代码编写之前。

对 Slop 说不

Brockman 的推荐 #5 是直率的：

确保某些人为任何合并的代码负责。作为代码审查者，保持至少与人类编写代码相同的标准，并确保作者理解他们提交的内容。

这是“对 slop 说不”的原则，它与速度的诱惑相反。当代理可以产生 PR 比你审查更快时，本能是降低标准。我读过的每个来源都反对这个。

Steinberger，尽管发布了自己没有逐行阅读的代码，但深深关心架构和可扩展性。他作为 OpenClaw 的架构守门人。在他的 Discord 与贡献者，他不谈代码——只谈架构和大决策。Pragmatic Engineer 的 Gergely Orosz 观察到 Steinberger “给我印象是一个软件架构师，他将项目的高级结构保持在头脑中。”

我已经为此挣扎一段时间，但随着模型变得足够好，我发现更容易将它们视为经验丰富的分包商：

我喜欢用木工或木匠来比喻。对于初级木匠（即“学徒”）来说，这项工作可能只是关于输出——将设计或想法制作成成品。但对于更资深的人（“熟练工”或“工匠”）来说，他们的工作通常是了解客户想要什么，了解材料的实际情况，并设计出符合要求的东西。

最终，如果我与一位高级木匠一起帮助我设计一些东西，我并不特别关心他们是否是真正进行锯切和粘合的人。我正在与他们合作完成最终产品，而不是具体的机械步骤。

这就是 Steinberger 正在做的。他是大师木匠。代理在做锯和胶。他的工作是知道好的看起来像什么，并拒绝不符合标准的东西——有些人可能称之为“品味”。

我称之为“胡说检测”，随着输出量的增加，它变得更关键，而不是更少。你现在在更高的抽象水平审查。代码感觉太聪明，还是太重复？这里有模式会在六个月内引起维护头痛吗？抽象在正确的水平吗？

编排，而不仅仅是委托

最终的管理技能是并行化，但需要明确的是，并不是每个人都能做到（或需要）。 Steinberger 同时运行 5-10 个代理。 Stripe 工程师从 Slack 并行启动多个 Minion。我对 Codex 应用程序中的工作树也做了同样的事情 - 三个会话同时讨论不同的功能，作为审阅者而不是实现者在它们之间进行上下文切换

但在两种并行工作模式之间出现了一个重要的区别。Steinberger 和我做的是参与并行化——你积极管理几个代理会话，检查每个会话，并在需要时进行重定向。 Stripe 的 Minions 代表的是更接近于无人值守的并行化——开发人员发布一个任务然后走开。代理通过 CI 处理一切，而人类仅在审查阶段重新进入循环

这些是真正不同的管理风格，有不同的权衡。有人值守的并行化给你更多控制并更早捕获问题，但认知上要求高。无人值守的并行化扩展更好，但需要对环境的大量投资——harness 必须足够好，你信任代理从任务到 PR 而无需监督。Stripe 可以这样做是因为他们构建了 Toolshed、预热 devboxes 和紧密 CI 集成。大多数团队还没有到那里。

您的团队在该范围内的位置取决于两件事：您的 harness 的成熟程度，以及您对代码库的代理的信任程度。随着安全带的改进和模型能够更好地维持更长的任务而不脱轨，我预计平衡将转向无人值守的工作。但就目前而言，我们大多数人都处于中间状态——参与复杂的任务，无人参与范围广泛的任务。

什么仍然困难

上面的实践代表了真正的汇聚。但有几个开放问题，没有人有说服力的答案。

第一个是布罗克曼的结束语：如何防止“功能正确但难以维护的代码”渗入代码库？《Harness Engineering》帖子将这种现象称为“熵”——代理生成的代码与人类编写的代码的累积方式不同。他们已经开始运行定期的“垃圾收集”代理来发现不一致和违规行为，但他们承认这仍然是一种新兴做法。

第二个是大规模验证。伯克勒对 Harness 帖子的批评是尖锐的：该文章缺乏对功能和行为的验证。 Anthropic 的长期运行的代理研究也发现了同样的差距——代理会在没有适当的端到端测试的情况下将功能标记为完整，并且如果没有明确的提示，他们将无法认识到某些东西不起作用。即使有了浏览器自动化，视觉和工具访问的限制也意味着一些错误会被忽略。

第三个是改造问题。所有这些成功故事涉及新建项目或从头开始构建 harness 的团队。将这些技术应用到十年旧的代码库，没有架构约束、不一致测试和零散文档是一个更复杂的问题。Böckeler 将其比作在从未有过静态分析工具的代码库上运行它——你会淹没在警报中。Harness engineering 如何适用于老旧存量项目是一个开放问题。

第四个，或许最大的，是文化采用。

阅读所有这些例子，一件事变得清楚：没有什么是偶然发生的。某人必须构建这些东西。每个组织的某人必须做找出代理如何融入他们团队工作流程的工作——创建 harness，定义过程，并基于有效的东西更新。

好消息是投资复合。每个 AGENTS.md 更新防止一类未来的失败。每个自定义 linter 教导每个未来的代理会话。你通过 MCP 暴露的每个工具使每个后续任务更快。前期成本显著，但回报加速。

事物的形状

Steinberger 观察到喜欢解决算法谜题的工程师努力转向代理原生，而喜欢发布产品的工程师快速适应 5。这与我亲眼看到的东西一致——当我不再用自己的双手编写代码时，我必须学会放弃软件工程的技巧。

但是尽管有苦乐参半的方面，我还是对这里发生的事情着迷。这是一门真正实时形成的新学科——它借鉴了软件架构和团队管理中的经典挑战，同时将上下文工程融入其中。剧本仍在编写中，但我第一次认为它的形状正在变得清晰。

爆火的 OpenClaw 依赖的极简 Agent 框架 Pi

Sun, 22 Feb 2026 13:12:07 GMT

大家好，我是 luckySnail，今天分享一篇文章，讲述爆火的 OpenClaw 依赖的 Agent 框架 Pi-mono ,

原文地址：https://lucumr.pocoo.org/2026/1/31/pi/

作者：Armin Ronacher

写作日期：2026年1月31日

翻译：Gemini 3 Pro。如果你需要网页翻译插件，强烈推荐使用「🥥 椰子翻译」

如果你这周并非与世隔绝，你应该已经注意到我朋友 Peter 的一个项目在互联网上爆火了。它有很多名字。最近的一个叫 OpenClaw，但在新闻中你可能见过 ClawdBot 或 MoltBot，这取决于你何时读到相关报道。它是一个连接到你所选通信频道的代理，其功能仅仅是运行代码。

你可能不太熟悉的是，OpenClaw 的底层是一个叫做 Pi 的小型编码代理。巧合的是，Pi 目前也是我几乎唯一使用的编码代理。在过去的几周里，我越来越像这个小代理的“托儿”了。最近我在做了一次关于它的演讲后，意识到我还未在这个博客上写过关于 Pi 的文章，所以我觉得有必要提供一些背景信息，解释一下我为何对它如此着迷，以及它与 OpenClaw 的关系。

Pi 是由 Mario Zechner 编写的。不同于 Peter 那种追求“带有疯狂色彩的科幻”风格（注1），Mario 非常脚踏实地。尽管方法不同，但 OpenClaw 和 Pi 遵循同一个理念：大语言模型（LLM）非常擅长编写和运行代码，所以应该拥抱这一点。在某些方面我认为这并非巧合，因为 Peter 去年让我和 Mario 都迷上了这个想法以及代理（agents）。

Pi 是什么？

Pi 是一个编码代理。市面上有很多编码代理。真的，我认为现在你随便选一个，都能体验到代理编程是什么感觉。在这个博客的评论中，我曾积极评价过 AMP，我之所以对 AMP 有如此强烈的共鸣，原因之一在于它真的感觉像是由那些既沉迷于代理编程，又尝试过多种不同方案以确定哪种有效的人所构建的产品，而不仅仅是围绕它构建一个花哨的 UI。

Pi 对我来说之所以有趣，主要有两个原因：

首先，它有一个极小的核心。它的系统提示词是我所知道的所有代理中最短的，而且它只有四个工具：

读取（Read）、写入（Write）、编辑（Edit）、Bash。

第二点是，它通过提供一个扩展系统弥补了极小核心的不足，该系统还允许扩展将状态持久化到会话中，这非常强大。

还有一个额外的好处：Pi 本身的代码写得非常出色。它不闪烁，不消耗大量内存，不随机崩溃，非常可靠，而且是由一位非常在意软件内涵的人编写的。

Pi 也是一系列小组件的集合，你可以在其上构建你自己的代理。这就是 OpenClaw 的构建方式，也是我构建自己的小型 Telegram 机器人的方式，以及 Mario 构建他的“mom”的方式。如果你想构建自己的代理并连接到某物，只要将 Pi 指向它自己和 mom，它就会为你变出一个来。

Pi 里没有什么

为了理解 Pi 里有什么，更重要的是理解 Pi 里没有什么，为什么没有，以及更关键的：为什么将来也不会有。最明显的遗漏是不支持 MCP。它里面没有 MCP 支持。虽然你可以为它构建一个扩展，但你也可以像 OpenClaw 支持 MCP 那样做，即使用 mcporter。mcporter 通过 CLI 接口或 TypeScript 绑定公开 MCP 调用，也许你的代理可以用它做点什么。也可能不做，我不知道 :)

这并非懒惰导致的遗漏。这源于 Pi 的工作哲学。Pi 的核心理念是，如果你想让代理做一些它目前还不会做的事情，你不需要去下载一个扩展或一项技能之类的东西。你要求代理扩展它自己。它推崇编写代码和运行代码的理念。

这并不意味着你不能下载扩展。它是完全支持的。但相比于必须鼓励你下载别人的扩展，你也可以将你的代理指向一个现有的扩展，比如说，“像那边那个东西一样构建它，但要做成我喜欢的这些修改”。

为构建 Agent 的元框架

当你观察 Pi 以及作为其扩展的 OpenClaw 在做什么时，你会看到一个软件像粘土一样具有延展性的例子。这实际上对其底层架构设定了某些要求，这些要求在许多方面设定了系统的某些约束，而这些约束确实需要进入核心设计。

例如，Pi 的底层 AI SDK 的编写方式使得一个会话真的可以包含来自许多不同模型提供商的许多不同消息。它认识到会话的可移植性在模型提供商之间是有些受限的，因此它不过分依赖任何无法转移到另一家的模型提供商特定功能集。

第二点是，除了模型消息之外，它还在会话文件中维护自定义消息，这些消息可以被扩展用来存储状态，或者被系统本身用来维护那些根本不发送给 AI 或只发送部分给 AI 的信息。

因为存在这个系统，且扩展状态也可以持久化到磁盘，它内置了热重载功能，以便代理可以编写代码、重载、测试并循环进行，直到你的扩展真正具备功能。它还附带了文档和示例，代理本身可以使用这些来扩展自己。更好的是：Pi 中的会话是树状的。你可以在一个会话中分支并在其中导航，这开启了各种有趣的机会，例如启用一种工作流：进行一个支线任务来修复一个损坏的代理工具，而不会在主会话中浪费上下文。工具修复后，我可以将会话倒回到更早的时候，Pi 会总结另一个分支上发生了什么。

这一切都很重要，因为例如如果你考虑 MCP 是如何工作的，在大多数模型提供商上，MCP 的工具（像任何给 LLM 的工具一样）需要在会话开始时加载到系统上下文或其工具部分。这使得在不破坏整个缓存或让 AI 困惑于之前的调用方式为何不同的情况下，完全重载工具能做什么变得非常困难，甚至不可能。

上下文之外的工具

Pi 中的扩展可以注册一个工具供 LLM 调用，而且我时不时地发现这很有用。例如，尽管我批评 Beads 的实现方式，但我确实认为给代理访问待办事项列表是一个非常有用的事情。我确实使用一个在本地工作的代理特定问题追踪器，那是我让我的代理自己构建的。因为我也想让代理管理待办事项，在这种特定情况下，我决定给它一个工具而不是一个 CLI。这感觉适合问题的范围，而且目前这是我加载到我的上下文中的唯一额外工具。

但在大多数情况下，我添加到我的代理中的都是技能或 TUI 扩展，以使与代理的协作对我来说更愉快。除了斜杠命令，Pi 扩展可以直接在终端中渲染自定义 TUI 组件：旋转器、进度条、交互式文件选择器、数据表格、预览面板。TUI 足够灵活，Mario 证明了你可以在里面运行《毁灭战士》（Doom）。这虽然不实用，但如果你能运行《毁灭战士》，你肯定能构建一个有用的仪表板或调试界面。

我想重点介绍我的一些扩展，让你了解什么是可能的。虽然你可以原封不动地使用它们，但整个理念实际上是你将你的代理指向一个扩展，并根据你的心意对其进行重新混合。

/answer

我不使用计划模式。我鼓励代理提问，这之间会有富有成效的来回互动。但我不喜欢那种如果你给代理一个提问工具就会发生的结构化问答对话。我更喜欢代理自然的散文，中间穿插着解释和图表。

问题在于：在行内回答问题会变得混乱。所以 /answer 读取代理的上一个回复，提取所有问题，并将它们重新格式化为一个漂亮的输入框。

/todos

尽管我批评 Beads 的实现，但给代理一个待办事项列表确实非常有用。/todos 命令会调出存储在 .pi/todos 中的所有条目作为 markdown 文件。代理和我都可以操作它们，会话可以认领任务以将其标记为进行中。

youtube 在线演示：https://youtu.be/ZcKbzxziA5k?si=5jeP2QFsc4P0ILWu

/review

随着越来越多的代码由代理编写，在代理先审查之前就把未完成的工作扔给人类是没有什么意义的。因为 Pi 会话是树状的，我可以分支进入一个新的审查上下文，获取发现，然后将修复带回主会话。

UI 模仿了 Codex，它提供了易于审查的提交、差异、未提交的更改或远程 PR。提示词关注我关心的事情，所以我能得到我想要的提示（例如：我要求它指出新添加的依赖项）。

/control

这是一个我正在试验但不常使用的扩展。它允许一个 Pi 代理向另一个发送提示词。这是一个简单的多代理系统，没有复杂的编排，这对于实验很有用。

/files

列出会话中更改或引用的所有文件。你可以在 Finder 中显示它们，在 VS Code 中比较差异，快速查看它们，或在你的提示词中引用它们。Shift+Ctrl+R 会快速查看最近提到的文件，当代理生成 PDF 时这很方便。

其他人也构建了扩展：Nico 的子代理扩展和 interactive-shell，后者让 Pi 可以在一个可观察的 TUI 覆盖层中自主运行交互式 CLI。

软件构建软件

这些都只是关于你可以用你的代理做什么的想法。其重点主要在于，这其中没有一样是我写的，它们都是代理根据我的规格说明创建的。我告诉 Pi 制作一个扩展，它就做了。没有 MCP，没有社区技能，什么都没有。别误会，我使用了大量的技能。但它们是由我的“机器”手工制作的，而不是从任何地方下载的。例如，我完全用一个只使用 CDP 的技能替换了我所有用于浏览器自动化的 CLI 或 MCP。这并非因为替代品不起作用或很糟糕，而是因为这样简单且自然。代理维护它自己的功能。

我的代理有不少技能，关键是如果我不需要它们，我会把技能扔掉。例如，我给了它一个技能来读取其他工程师分享的 Pi 会话，这有助于代码审查。或者我有一个技能来帮助代理通过我想要的方式撰写提交信息和提交行为，以及如何更新变更日志。这些最初是斜杠命令，但我目前正在将它们迁移到技能，看看这是否同样有效。我还有一个技能希望能帮助 Pi 使用 uv 而不是 pip，但我同时也添加了一个自定义扩展来拦截对 pip 和 python 的调用，以便将它们重定向到 uv。

与像 Pi 这样的极简代理一起工作给我的部分魅力在于，它让你亲身体验了使用“构建更多软件的软件”这一理念。将这一点推向极致，就是当你移除 UI 和输出并将其连接到你的聊天时。这就是 OpenClaw 所做的，鉴于其巨大的增长，我真的越来越觉得这将在某种程度上成为我们的未来。

2026，手写代码时代彻底结束了！

Sat, 21 Feb 2026 12:48:00 GMT

大家好，我是 luckySnail，2026 年手写代码算是彻底成为过去式了！连尤大都在使用 Coding Agent 开发如果还觉得 AI 目前只能写前端的代码，那真的太傻了，AI 目前无论写前端还是服务端代码都是又快又好，如果说仅仅是写代码好，那还不能说是颠覆编程行业；在软件系统设计方面，只要给出精准的上下文和约束条件，Claude Opus 4.6 或者 Codex 5.3 也能做的很好，如果是新项目搭配 superpowers 的部分能力，AI 能够一次完成复杂的任务。

但是这一切都是随着 2025 年 5 月 Claude Code 的发布带来的，到现在还不到一年的时间，我从来没有见过任何一个事物进化速度这么快～，最可怕的是 OpenAI 发布的 GPT-5.3-Codex 是自我进化的。如果能一直自我进化，那 AI 会越来越聪明，单纯编程方面，AI 可以说是会碾压所有程序员

如果未来智能不再稀缺，我们普通程序员真就是新时代的“纺织女”了！按照目前的疯狂进化速度，智能应该马上就会像水和电一样，让每一个人都离不开，到那时候，代码也会变得极其的廉价。

如果像我这样的程序员就是新时代的“纺织女”，那不妨从历史的角度看看，纺织女当时是怎么转型的。工业革命时期，英国纺织工人曾激烈抵制机器，但并没有阻挡工业化的进程，纺织女们也纷纷顺应时代，有了新的身份： 1）机器操作员：变成机器的管理者、维修者、工厂监工。技能从”用手织布”转变为”管理织布机”。 2）投身新的岗位：规模化带来了新行业：铁路、煤矿、化工、零售业等大规模扩张，吸收了大量劳动力 3）进入服务业：工业化带来了中产阶级，中产阶级需要教育、医疗、娱乐、餐饮等这些领域产生大量新的岗位 4）新的资本家：有一部分人：开纺织厂，做贸易商，做品牌商；从新的生产力中获取巨额财富

现在的程序员的出路在哪里呢？核心就是做 AI 做不了的事，我们可以做： 1）系统架构师：写代码的事情有人干了，那往上走就是进行系统设计，做出符合业务需求，又能长期维护的系统 2）领域专家：单独懂技术已经没有护城河，那么懂业务，成为行业的专家才行。客户会相信我而不是 AI 3）Agent 管理者：Agent 越来越成熟，我们的工作会变成了 Agent 管理者，同时管理多个分工明确的 Agent 来完成工作 4）AI 创作者：AI 目前在图片，视频和文笔上都非常厉害，对于有想象力的人来说，把 idea 变成作品的门槛大大降低 5）Agent 工程师：OpenClaw 爆火，代表人们希望有一个 Agent 能够操作电脑，像人一样帮我们做事情，还有基于 OpenClaw 的虚拟伴侣也是很好的方向，永久的记忆让 AI 更像一个真人一样，人们对 Agent 的需求会爆发大量 Agent 开发的需求，这是我觉得很不错的一个转型的方向

总之，只会写代码，死路一条；能够利用最新的 AI 工具来解决复杂问题，提高工作效率才行按照这个逻辑，那我们应该必备的能力是： ● 精力管理 ● AI 工具使用 ● 复杂问题解决能力 ● 判断力 ● 审美和品味 ● 行业知识和经验

这么看来，这个时代对新手程序员真的非常不友好，最后希望我们都能在 AI 浪潮中找到自己的位置，做自己热爱的事情

Tim 在影石年会上的分享文字版

Sat, 14 Feb 2026 03:52:33 GMT

这篇文章整理自影视飓风创始人 Tim 的分享。内容涵盖了在 AI 时代对技术壁垒的思考、内容创作的核心逻辑、企业管理的方法论以及对于“体验”的终极追求。

以下是整理后的核心观点文章：

一、技术壁垒消融，唯有“创意”不可替代

AI 技术的追赶速度极快。当 AI 能够拉平技术差距后，我们曾引以为傲的剪辑技术、软件操作能力，甚至编程技能，都将不再构成核心壁垒。技术学习本身面临着被快速淘汰的风险。

在未来的竞争中，创意（Sense） 是更为残酷且唯一的决胜点。创意无关努力，它是一种感觉。

如何训练创意？ 唯一的方法是进行海量的输入。你需要像训练 AI 模型一样训练自己，观看海量的视频，无论是搞笑的、无厘头的还是严肃的。去思考为什么一个视频能有 50 万播放，而另一个能有 5000 万播放。相比于单纯学习某个软件的操作，这种对“网感”和创意的训练在接下来的时代更具价值。

二、好作品与商业回报的非线性关系

我们必须接受一个现实：好的作品并不直接等同于高营收。

以高端无人机或影视设备的 Pro 系列为例，它们的性能极强、画质极佳，是无疑的好作品，但其销量永远无法与大众消费级产品持平。Pro 系列存在的意义往往在于树立品牌高度，而非直接创造巨额利润。

企业发展到一定阶段，若想获得增长，必须扩大受众的接触面。

第一阶段： 影视飓风定位科技评测，受众约 400 万人。
第二阶段： 转型做自然社科、人文科普，受众扩大至 1 亿人，数据迅速增长。
第三阶段： 思考什么内容能跨越语言、年龄，让所有人看懂。答案是综艺与真实性（如荒岛生存、大型直播）。这让潜在受众扩大至 10 亿级别。

思考的格局决定了行动的方向。如果想做大，就不能只做受众越来越窄的产品，而要追求更广泛的触达。

三、拒绝无趣，拥抱“高信噪比”

在这个时代，没有人有义务忍受你的无聊。

无论是制作视频、进行商业路演（Pitch），还是向投资人汇报，你必须成为一个有趣的人。讲究与幽默应当成为一种文化。尽量提高信息密度，避免冗长的铺垫，因为高密度的信息输出与有趣的表达是获取注意力的关键。

同时，要警惕“Do stupid things, win stupid prizes”。在大型企业中，一个轻率的愚蠢决策往往会导致灾难性的后果，最终大家只能得到一个荒谬的结局。

四、管理哲学：管事优于管人

当企业规模扩大后，试图“管人”是徒劳的。每个人都是独立的个体，拥有独立的灵魂。企业的管理核心应当是“管事”。

我们不应过分关注员工几点打卡这类细枝末节，而应聚焦于项目的执行逻辑。影视飓风内部遵循一个源自特斯拉的管理铁律，顺序不可颠倒：

明确需求（Make requirements less dumb）： 很多时候需求本身就是错误的。
删减组件/流程： 大胆去掉不必要的环节。
简化： 在删减之后，优化剩余的部分。
加快循环周期： 提升迭代速度。
自动化： 最后才考虑自动化。

很多企业的错误在于“倒着做”：在需求不明确、流程繁杂的情况下，强行要求自动化或加速，最终导致产生大量的无用功。

此外，任何项目必须包含三个步骤：立项、纠错、复盘。没有这三步，错误就会重复出现，经验也无法沉淀。

五、内容心法：精力偷取（Experience Borrowing）

从零开始构建一个完美的世界（如完全虚构的电影剧本）极度消耗精力，且难以保证持续的高质量更新。

高效的内容创作逻辑是**“借用”社会与自然界已经沉淀的能量**。

案例： 拍摄非遗“打铁花”，或者拍摄壮丽的自然风光。
逻辑： 大自然沉淀了数亿年的美，非遗传承人沉淀了一辈子的技艺。当我们把摄像机对准他们时，我们并非在“偷窃”，而是在“借用”这些已经存在的伟大经验和能量。

学会站在巨人的肩膀上，利用现有的精彩去创作，才能在保证质量的同时维持高频更新。

六、关注过程与体验：2026 与未来

结果带来的快感往往只有几分钟，过程才是人生的本质。

我们在 2022 年立下誓言：要在年轻的时间里，尽全力去感受世界的纷繁复杂，去体验不同的活法。这种对世界的认知会让人内心更加平静与和解。

基于这个理念，影视飓风在 2026 年有着明确的规划：

全面出海： 将过往节目重制为英文版（真人配音），输出知识付费内容，去赚世界的钱。
全员 AI 化： 公司全员部署 Gemini Advanced 账号，拥抱 AI 时代。
极致体验项目（珠峰计划）： 公司出资近百万，给予一位员工 9 个月的带薪假期，支持他去攀登珠穆朗玛峰。

这不仅仅是一个挑战，更是一次关于普通人如何通过学习与坚持，最终站上世界之巅的完整记录。我们希望给团队伙伴留下的，是老了以后依然值得回味的人生体验。

驾驭（Harness）工程，在“智能体优先”的世界中利用 Codex

Fri, 13 Feb 2026 17:44:17 GMT

以下是 https://openai.com/index/harness-engineering/ 博客正文的完整中文精翻，绝对是一篇高质量并且改变软件工程游戏规则的文章

原文标题：驾驭（Harness）工程，在“智能体优先”的世界中利用 Codex

作者：Ryan Lopopolo，发布时间：2026年2月11日

翻译官：🥥 椰子翻译浏览器插件

在过去的五个月里，我们的团队一直在进行一项实验：构建并发布一个内部软件产品的测试版，且0 行代码由人工编写。

该产品目前拥有内部日常用户和外部 alpha 测试人员。它正常发布、部署，会出现故障，也能被修复。不同之处在于，每一行代码（包括应用逻辑、测试、CI 配置、文档、可观测性配置以及内部工具）均由 Codex 编写。据估算，我们完成这项工作的时间仅为人工编写所需时间的十分之一。

人类掌舵，智能体执行

我们特意选择了这一约束条件，以此迫使自己构建必要的体系，从而将工程速度提升数个数量级。我们只有几周时间来交付最终达到一百万行代码的项目。为了实现这一目标，我们需要理解当软件工程团队的主要工作从编写代码转变为设计环境、明确意图以及构建反馈循环（让 Codex 智能体能够可靠地工作）时，一切会发生怎样的变化。

这篇文章讲述了我们利用智能体团队构建全新产品过程中学到的经验（包括哪些地方出了问题，哪些产生了复利效应），以及如何最大化利用我们唯一的稀缺资源：人类的时间和注意力。

我们从一个空的 git 仓库开始

第一次提交进入这个空仓库是在 2025 年 8 月下旬。

初始脚手架（包括仓库结构、CI 配置、格式化规则、包管理器设置和应用程序框架）是由 Codex CLI 使用 GPT-5 生成的，并由少量现有模板作为引导。甚至最初指导智能体如何在仓库中工作的 AGENTS.md 文件本身也是由 Codex 编写的。

系统中没有任何预先存在的人工代码作为锚点。从一开始，这个仓库就是由智能体塑造的。

五个月后，该仓库包含大约一百万行代码，涵盖了应用逻辑、基础设施、工具、文档和内部开发实用程序。在此期间，仅由三名工程师组成的小团队驱动 Codex 开启并合并了大约 1500 个拉取请求（Pull Request）。这意味着每位工程师每天平均处理 3.5 个 PR，令人惊讶的是，随着团队扩大到现在的七名工程师，这一吞吐量还在增加。重要的是，这并非为了产出而产出：该产品已被数百名内部用户使用，其中包括每天都在使用的深度用户。

在整个开发过程中，人类从未直接贡献过任何代码。这成为了团队的核心哲学：杜绝人工编写代码。

重新定义工程师的角色

缺乏人工手动编码引入了一种不同类型的工程工作，重点在于系统、脚手架和杠杆作用。

早期的进展比我们预期的要慢，原因并非 Codex 能力不足，在于环境定义不明确。智能体缺乏朝着高层目标推进所需的工具、抽象和内部结构。我们工程团队的首要工作变成了赋能智能体去做有用的工作。

在实践中，这意味着采用深度优先的工作方式：将较大的目标分解为更小的构建块（设计、编码、审查、测试等），提示智能体构建这些模块，并利用它们来解锁更复杂的任务。当出现故障时，修复方法几乎从不是“再试一次”。由于取得进展的唯一途径是让 Codex 完成工作，人类工程师总是会介入任务并询问：“缺少什么能力，我们如何让这种能力对智能体既清晰可见又可强制执行？”

人类几乎完全通过**提示词（prompts）**与系统交互：工程师描述任务，运行智能体，并允许它开启一个拉取请求。为了推动 PR 完成，我们指示 Codex 在本地审查自己的更改，在本地和云端请求额外的特定智能体进行审查，响应任何人类或智能体给出的反馈，并循环迭代直到所有智能体审查员都满意（实际上这就是一个 Ralph Wiggum 循环）。Codex 直接使用我们的标准开发工具（gh、本地脚本和仓库内嵌技能）来收集上下文，无需人类在 CLI 中进行复制粘贴。

人类可能会审查拉取请求，但这并非强制要求。随着时间的推移，我们将几乎所有的审查工作都推向了智能体对智能体的模式。

提高应用的可读性

随着代码吞吐量的增加，瓶颈变成了人类的 QA（质量保证）能力。由于固定的约束条件是人类的时间和注意力，我们致力于通过让应用 UI、日志和应用指标等内容对 Codex 直接可见，来为智能体增加更多能力。

例如，我们让应用可以基于每个 git 工作树（worktree）启动，这样 Codex 就可以为每个更改启动并驱动一个实例。我们还将 Chrome DevTools 协议接入智能体运行时，并创建了处理 DOM 快照、截图和导航的技能。这使得 Codex 能够重现错误、验证修复并直接推断 UI 行为。

（图表说明：Codex 使用 Chrome DevTools MCP 驱动应用以验证其工作。）

我们对可观测性工具也做了同样的处理。日志、指标和追踪信息通过一个本地可观测性堆栈暴露给 Codex，该堆栈对于任何给定的工作树都是临时的。Codex 在该应用的完全隔离版本上工作（包括其日志和指标），任务完成后这些内容会被销毁。智能体可以使用 LogQL 查询日志，使用 PromQL 查询指标。有了这些上下文，像“确保服务启动在 800ms 内完成”或“在这四个关键用户旅程中没有跨度（span）超过两秒”这样的提示词就变得可执行了。

（图表说明：在本地开发中给予 Codex 完整的可观测性堆栈。）

我们经常看到单个 Codex 运行在单个任务上持续工作长达六个小时以上（通常是在人类睡觉的时候）。

我们将仓库知识作为记录系统

上下文管理是让智能体在处理大型复杂任务时保持高效的最大挑战之一。我们学到的最早教训之一很简单：给 Codex 一张地图，而不是一本 1000 页的说明书。

我们尝试过“一个巨大的 AGENTS.md”的方法。它以可预见的方式失败了：

上下文是稀缺资源。 一个巨大的指令文件会挤占任务、代码和相关文档的空间，导致智能体要么错过关键约束，要么开始针对错误的约束进行优化。
过多的指导变成了无指导。 当一切都“重要”时，就没什么东西是重要的了。智能体会陷入局部模式匹配，无法进行有意识的导航。
它会立即腐烂。 庞大的手册会变成过时规则的坟墓。智能体无法分辨什么是真实的，人类停止维护它，这个文件悄然变成了一个诱人的麻烦。
难以验证。 单个大文件不适合机械检查（覆盖率、新鲜度、所有权、交叉链接），因此偏离是不可避免的。

所以，我们不把 AGENTS.md 当作百科全书，将其视为目录。

仓库的知识库存在于一个结构化的 docs/ 目录中，被视为记录系统（System of Record）。一个简短的 AGENTS.md（大约 100 行）被注入到上下文中，主要作为一个地图，包含了指向其他地方更深层真理来源的指针。

1  AGENTS.md
2  ARCHITECTURE.md
3  docs/
4  ├── design-docs/
5  │ ├── index.md
6  │ ├── core-beliefs.md
7  │ └── ...
8  ├── exec-plans/
9  │ ├── active/
10  │ ├── completed/
11  │ └── tech-debt-tracker.md
12  ├── generated/
13  │ └── db-schema.md
14  ├── product-specs/
15  │ ├── index.md
16  │ ├── new-user-onboarding.md
17  │ └── ...
18  ├── references/
19  │ ├── design-system-reference-llms.txt
20  │ ├── nixpacks-llms.txt
21  │ ├── uv-llms.txt
22  │ └── ...
23  ├── DESIGN.md
24  ├── FRONTEND.md
25  ├── PLANS.md
26  ├── PRODUCT_SENSE.md
27  ├── QUALITY_SCORE.md
28  ├── RELIABILITY.md
29  └── SECURITY.md

（仓库内知识存储布局。）

设计文档已被分类和索引，包括验证状态和定义智能体优先操作原则的一套核心信念。架构文档提供了领域和包分层的顶层地图。质量文档对每个产品领域和架构层进行评分，跟踪随时间推移的差距。

计划（plan）被视为一等公民（first-class artifacts）。临时的轻量级计划用于小的更改，而复杂的工作则被记录在执行计划中，包含进度和决策日志，并提交到仓库中。活跃计划、已完成计划和已知的技术债务都被版本化并放在一起，允许智能体在不依赖外部上下文的情况下操作。

这实现了渐进式披露：智能体从一个小的、稳定的入口点开始，被教导下一步去哪里看，避免一上来就不堪重负。

我们通过机械方式强制执行这一点。专用的 linter（代码扫描工具）和 CI 任务验证知识库是否是最新的、交叉链接是否正确以及结构是否合理。一个定期运行的“文档园丁”智能体会扫描那些不能反映真实代码行为的陈旧或过时文档，并开启修复性的拉取请求。

智能体可读性是目标

随着代码库的演变，Codex 的设计决策框架也需要随之演变。

因为仓库完全由智能体生成，它首先针对 Codex 的可读性进行了优化。就像团队致力于提高代码的可导航性以方便新入职的工程师一样，我们人类工程师的目标是让智能体能够直接从仓库本身推断出完整的业务领域。

从智能体的角度来看，任何它在运行时无法在上下文中访问的东西实际上都不存在。存在于 Google Docs、聊天线程或人们头脑中的知识对系统来说是不可访问的。仓库本地的、版本化的工件（例如代码、markdown、schema、可执行计划）是它能看到的全部。

（图表说明：智能体知识的局限性：Codex 看不到的就不存在。）

我们了解到，随着时间的推移，我们需要将越来越多的上下文推入仓库。如果在 Slack 上的讨论对齐了团队关于某种架构模式的看法，如果这些信息对智能体不可发现，那么它就像对三个月后加入的新员工一样是未知的，因此是不可读的。

给予 Codex 更多上下文意味着组织和暴露正确的信息，以便智能体可以对其进行推理，这优于用临时指令压倒它。就像你会就产品原则、工程规范和团队文化（包括表情符号偏好）对新队友进行入职培训一样，向智能体提供这些信息会产生更一致的输出。

这种框架澄清了许多权衡。我们倾向于那些可以在仓库中被完全内化和推理的依赖项和抽象。通常被描述为“无聊”的技术往往更容易被智能体建模，因为它们具有可组合性、API 稳定性以及在训练集中的广泛存在。在某些情况下，让智能体重新实现部分功能比绕过公共库中不透明的上游行为成本更低。例如，我们没有引入通用的 p-limit 风格的包，而是实现了我们自己的并发映射助手：它与我们的 OpenTelemetry 仪表紧密集成，拥有 100% 的测试覆盖率，并且行为完全符合我们运行时的预期。

将更多的系统部分转化为智能体可以直接检查、验证和修改的形式，这增加了杠杆作用（这不仅针对 Codex，对于其他正在代码库上工作的智能体，如 Aardvark，同样如此）。

强制执行架构与品味

仅靠文档无法保持完全由智能体生成的代码库的连贯性。通过强制执行不变量，不微观管理实现细节，我们让智能体在不破坏基础的情况下快速发布。例如，我们要求 Codex 在边界处解析数据形状，但并不规定具体的发生方式（模型似乎喜欢 Zod，但我们没有指定那个特定的库）。

智能体在具有严格边界和可预测结构的环境中最为有效，因此我们围绕严格的架构模型构建了应用程序。每个业务领域都被划分为一组固定的层，具有严格验证的依赖方向和有限的一组允许边缘。这些约束通过自定义 linter（当然是由 Codex 生成的！）和结构测试进行机械强制执行。

下图展示了该规则：在每个业务领域（例如应用设置）内，代码只能通过一组固定的层（Types → Config → Repo → Service → Runtime → UI）“向前”依赖。横切关注点（认证、连接器、遥测、功能标志）通过一个单一的显式接口进入：Providers。其他任何依赖都是不允许的，并且会被机械地强制禁止。

（图表说明：具有显式横切边界的分层领域架构。）

这是那种你通常会等到拥有数百名工程师时才会推迟实施的架构。对于编码智能体来说，这是一个早期的先决条件：这种约束使得在不发生腐烂或架构漂移的情况下实现速度成为可能。

在实践中，我们通过自定义 linter 和结构测试，加上一小部分“品味不变量”来强制执行这些规则。例如，我们静态地强制执行结构化日志记录、schema 和类型的命名约定、文件大小限制以及特定于平台的可靠性要求。因为 linter 是自定义的，我们将错误消息编写为向智能体上下文注入补救指令。

在人类优先的工作流中，这些规则可能会让人觉得迂腐或受限。而在智能体看来，它们成为了倍增器：一旦编码，它们就会同时应用于所有地方。

同时，我们明确区分约束重要的地方和不重要的地方。这类似于领导一个大型工程平台组织：在中心强制执行边界，在局部允许自治。你深切关注边界、正确性和可复现性。在这些边界内，你允许团队（或智能体）在表达解决方案方面拥有极大的自由度。

生成的代码并不总是符合人类的风格偏好，这没关系。只要输出正确、可维护且对未来的智能体运行可读，它就符合标准。

人类的品味会不断反馈到系统中。审查评论、重构拉取请求和面向用户的错误被捕获为文档更新或直接编码到工具中。当文档不足时，我们将规则提升为代码。

吞吐量改变了合并哲学

随着 Codex 吞吐量的增加，许多常规的工程规范变得适得其反。

该仓库在运行时保持最小的阻塞性合并门槛。拉取请求是短暂的。测试的不稳定（flakiness）通常通过后续运行来解决，不无限期地阻碍进度。在一个智能体吞吐量远超人类注意力的系统中，修正很便宜，而等待很昂贵。

在低吞吐量环境中，这样做是不负责任的。而在这里，这通常是正确的权衡。

“智能体生成”的真正含义

当我们说代码库是由 Codex 智能体生成时，我们指的是代码库中的一切。

智能体生产：

产品代码和测试
CI 配置和发布工具
内部开发者工具
文档和设计历史
评估工具（Evaluation harnesses）
审查评论和回复
管理仓库本身的脚本
生产仪表板定义文件

人类始终保持在循环中，但在与过去不同的抽象层面上工作。我们确定工作的优先级，将用户反馈转化为验收标准，并验证结果。当智能体遇到困难时，我们将其视为一个信号：识别缺失了什么（工具、护栏、文档），并将其反馈回仓库，始终通过让 Codex 自己编写修复程序来完成。

智能体直接使用我们的标准开发工具。它们拉取审查反馈，进行行内回复，推送更新，并经常压缩和合并它们自己的拉取请求。

不断提升的自主性水平

随着越来越多的开发循环被直接编码到系统中（测试、验证、审查、反馈处理和恢复），仓库最近跨越了一个有意义的阈值，即 Codex 可以端到端地驱动一个新功能。

给定一个单一的提示词，智能体现在可以：

验证代码库的当前状态
重现报告的错误
录制视频演示故障
实施修复
通过驱动应用程序验证修复
录制第二个视频演示解决方案
开启拉取请求
响应智能体和人类的反馈
检测并修复构建失败
仅在需要判断时升级给人类
合并更改

这种行为在很大程度上依赖于该仓库特定的结构和工具，如果没有类似的投资，不应假设这种能力可以普及（至少目前还不能）。

熵与垃圾回收

完全的智能体自主性也引入了新的问题。Codex 会复制仓库中现有的模式，甚至是不均匀或次优的模式。随着时间的推移，这不可避免地导致漂移。

起初，人类手动解决这个问题。我们的团队过去每周五（一周 20% 的时间）都要清理“AI 垃圾（AI slop）”。不出所料，这种方式无法扩展。

相反，我们要开始将所谓的“黄金原则”直接编码到仓库中，并建立一个定期的清理流程。这些原则是固执己见的机械规则，旨在保持代码库对未来智能体运行的可读性和一致性。例如：

(1) 我们更喜欢共享的实用程序包而不是手写的辅助函数，以保持不变量的集中化；

(2) 我们不进行“YOLO 风格”的数据探测，我们验证边界或依赖类型化的 SDK，以免智能体意外地建立在猜测的数据形状之上。按照固定的节奏，我们要有一组后台 Codex 任务来扫描偏差、更新质量评分并开启针对性的重构拉取请求。这些请求中的大多数可以在一分钟内完成审查并自动合并。

这就像垃圾回收一样起作用。技术债务就像高息贷款：持续以小增量偿还几乎总是比让其复利并在痛苦的爆发中解决要好。人类的品味被捕获一次，然后在每一行代码上持续强制执行。这也让我们能够每天捕捉并解决糟糕的模式，防止它们在代码库中蔓延数天或数周。

我们需要继续学习的内容

到目前为止，这一策略在 OpenAI 的内部发布和采用中效果良好。为真实用户构建真实产品有助于将我们的投资锚定在现实中，并引导我们走向长期的可维护性。

我们尚不知道的是，在一个完全由智能体生成的系统中，架构的一致性如何在数年内演变。我们仍在学习人类判断在何处能增加最大的杠杆作用，以及如何编码这种判断以使其产生复利。我们也不知道随着模型随时间变得更加强大，这个系统将如何演变。

目前已明确的是：构建软件仍然需要纪律，但这种纪律更多地体现在脚手架上，存在于代码之外。保持代码库连贯的工具、抽象和反馈循环变得越来越重要。

我们现在最困难的挑战集中在设计环境、反馈循环和控制系统上，以帮助智能体实现我们的目标：大规模构建和维护复杂、可靠的软件。

随着像 Codex 这样的智能体在软件生命周期中承担更大的份额，这些问题将变得更加重要。我们希望分享一些早期的经验教训能帮助你思考应该在何处投入精力，以便你可以专注于构建事物。

Coding Agent 的最终形态是 TUI + GUI 吗？

Tue, 03 Feb 2026 16:48:37 GMT

在开始之前，给不是很懂 AI 和编程的朋友简单科普一下： TUI：Text-based User Interface，主要通过 文字、符号 在终端/命令行中与用户交互

GUI：Graphical User Interface，图形用户界面，通过 窗口、按钮、图标、菜单 等图形元素交互，可以使用鼠标。我们日常使用的浏览器，桌面软件都是 GUI 应用

Codex：一个 coding agent ，之前只有终端 cli 的形式，2026-02-03 号发布了自己的桌面端

下面开始正文：

就在刚刚，openAI 发布了 Codex 桌面端，上手体验了一天，效率真的有被提高，相比较 TUI；GUI 的交互体验和并行处理需求能力被大大提高。因为桌面端相比较 TUI 能展示更多的信息，而且交互也会更加友好。这必然导致受众群体更加广泛，下面来具体看看 Codex 桌面端有哪些能力吧！

如果你是登录了 Codex ，它应该是自动读取了数据，然后就让你选择要开发的项目，进入就会打开之前的对话记录，下面基于上面的图来详细介绍这里的功能：

左上角：可以新建新的「线程」，你可以在这里打开新项目进行开发，也就是说你可以在这里统一的去开启多个项目进行并行开发
下面是 Automations 和 skills：一个是定时任务，可以自动的通过触发条件触发一些操作；一个是最近非常火的 Agent Skills ，可以集成一些 SOP 帮助快速解决特殊领域的问题，例如使用 frontend-design 来开发出美观的前端页面
下面就是对话线程：这里是你对话的记录，并且当你对话的时候切换到其他对话，这里会展示 loading，成功也会有提示。方便你同时进行多个线程
左边底部是用户信息展示，点击会去到设置页面（使用 command +，也可以进入），设置页面可以设置很多，比较有用的是下面这个配置，这个配置相当于开启了 yolo 模式，可以完全放开让 codex 帮你干活，而不是不断的询问你

右边是上中下结构，先说上面的 nav 部分

nav：左边展示对话的名称，项目的名称，右边是一些操作：运行按钮，点击可以运行当前项目，需要自己配置脚本；然后是打开代码编辑器；然后是一个帮你快速创建 commit 和 pr 的地方；然后是改动对比，可以清晰看到当前 AI 修改了什么代码
中间就是 coding agent 的对话输出区，和 cli 中提交 Prompt 触发 AI 输出展示基本差不多
下面是AI 对话输入框；你可以切换当前对话的模型，添加图片，文件；开启计划模式；还可以开启对电脑全部访问权限的能力。在官方视频介绍这里还可以进行语音输入，适合懒人用嘴说。在对话框底部还有非常实用的能力，就是查看/切换当前分支，开启 worktree 模式；对于对话中还可以看到当前上下文占用情况，避免上下文满了导致输出效果差非常喜欢这个 UI，简洁干净直观，OpenAI 的产品在使用体验绝对是第一梯队。对了，OpenAI 为了庆祝 Codex 桌面端上线，现在给所有付费用户的额度都进行了翻倍补偿，方便大家更加爽快的使用起来，良心商家了属于是

下面说一下目前使用下来感觉不好的地方：

虽然可以通过 @ 来获取到项目的文件，但是没有展示一个当前项目文件目录树，毕竟大项目怎么可能记得住所有的文件名；还有就是老问题，不支持 @ 文件夹
和 cli 没有联动，虽然 GUI 很好，但是有时候使用 cli 更方便，两端的对话列表数据不是同步的
性能不高，比较占用内存，尤其是多个项目并发的时候看了源码发现是使用 electron 开发的～所以还在纠结 electron 还是 tauri 的直到选谁了吧？总体来说体感还是非常好的，桌面端底层也是基于 codex cli ，所以回应标题，coding agent 或者说以后的其他 agent 大体都应该是先开发 cli ，再开发 GUI，而且在未来多 Agent 互相调用，cli 肯定是更好对外提供接口

目前我主要是使用 Codex 进行开发，虽然它比较慢，但是它真的是一次就通过。Claude Code 虽然比较快，但是在修复 bug ，解决复杂问题，我个人感觉是不如 Codex 的，感谢你的阅读，本文纯手写，都是实际的编码经验总结，如果对你有帮助，点个关注 + 在看再走吧！我会持续分享 AI 相关的资讯和经验

Fix React Server Components CVE vulnerabilities

Tue, 03 Feb 2026 08:26:05 GMT

[!IMPORTANT] This is an automatic PR generated by Vercel to help you with patching efforts. We can’t guarantee it’s comprehensive, and it may contain mistakes. Please review our guidance before merging these changes.

A critical remote code execution (RCE) vulnerability in React Server Components, impacting frameworks such as Next.js, was identified in the project blog. The vulnerability enables unauthenticated RCE on the server via insecure deserialization in the React Flight protocol.

This issue is tracked under:

GitHub Security Advisory: GHSA-9qr9-h5gf-34mp
React Advisory: CVE-2025-55182
Next.js Advisory: CVE-2025-66478

This automated pull request upgrades the affected React and Next.js packages to patched versions that fully remediate the issue.

More Info | security@vercel.com

Vercel 给 Agent Skills 泼了一盆冷水

Fri, 30 Jan 2026 16:49:11 GMT

Vercel 团队最近的一篇博客分享了如何让 Agent 使用 Next.js 正确的 API，实现根据当前项目安装的 Next.js 版本使用正确的 API ，而不是使用非当前版本的 API 。如果你是 Next.js 开发者，你肯定知道这是非常重要的，因为 Next.js 的版本更新非常的快速。

最有趣的是 Vercel 团队最开始是 All In Skills 来解决这个问题，因为 Skills 能够渐进式披露，能够最大的保护你的上下文不爆炸💥，在 Vercel 团队制作 Skills 并进行实际测试下来，发现 Skills 并不可靠，因为 Agent 不会触发使用 Vercel 写的 Skills ，即使是使用强调的 prompt ，也不能保证完全有效，而且依赖提示词这本身就不是正确的方法。

Agent Skills 不行，Vercel 团队于是直接在 Agent.md 中嵌入文档索引（仅仅是一个索引，这样也实现了避免上下文爆炸的问题），然后 Agent 能够基于这个索引获取到对应的内容，实现使用正确的 API。在 Agent.md 中有一个重要的提示词：

IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning
for any Next.js tasks.

翻译为中文就是：
重要提示：对于任何 Next.js 任务，优先选择检索主导的推理，而非预训练主导的推理。

这样 Agent 能够查阅文档，而不是依赖预训练的数据，经过测试发现在 Agent.md 添加说明的效果出奇的好

是 100% 成功，如果你不信的话，可以自己去试试：**npx @next/codemod@canary agents-md**

这个命令做了三个事情：

检查你的 Next.js 版本
下载匹配的文档到 .next-docs/
把压缩索引注入到你的 Agent.md

值得一提的是 Vercel 通过一些技术把索引压缩到了 8KB 大小，这样 Agent 能够准确的找到对应的文档，避免上下文被占用

总结

通过 Vercel 的分享，说明了一个事情，那就是 Agent Skills 不是万能的解法。它也有不适用的场景，比如：提供知识获取方式

Vercel 还分享了为什么 Agent.md 能够胜过 Skills 背后的原因：

Skills 表现不好是因为触发 Skills 生效率低。需要依赖提示词的表达触发
Agent.md 表现好是因为它是系统提示词，始终存在每一个对话中，这就消除了 Agent 做决策的环节，它不再需要判断是否需要调用对应的 Skills，而是直接调用。

最后 Vercel 给开发者一些建议：

优先使用 Agent.md 获取知识
Skills 适用于处理任务流（SOP），例如：版本升级
对于框架开发者，应该给开发者提供官方的 Agent.md ，帮助开发者使用 Agent 快速准确的生成有用的代码

本文纯手工，无 AI 添加

译：以推理速度发货

Mon, 05 Jan 2026 14:27:32 GMT

原文：https://steipete.me/posts/2025/shipping-at-inference-speed 翻译官：ChatGPT 5.2

自五月以来发生了什么变化

今年“氛围编码”的进步之大令人难以置信。大约在 5 月的时候，我还惊讶于某些提示词能生成开箱即用的代码，而现在这已经成了我的预期。我现在交付代码的速度快得不真实。从那以后我烧掉了大量 token。是时候更新一下了。

这些代理的工作方式真有意思。几周前有人争论说，人必须亲自写代码才能感受到糟糕的架构，而使用代理会造成一种脱节——对此我完全不同意。当你和代理相处得足够久，你就会非常清楚某件事应该花多长时间；而当 Codex 回来却没能一次就解决时，我就已经开始起疑了。

我现在能编写的软件数量主要受限于推理时间和深入思考。但说实话——大多数软件并不需要深入思考。大多数应用只是把数据从一种形式搬到另一种形式，可能存到某个地方，然后以某种方式展示给用户。最简单的形式是文本，所以默认情况下，无论我想做什么，它都从 CLI 开始。智能体可以直接调用它并验证输出——形成闭环。

模型转变

真正让我解锁像工厂一样构建的是 GPT 5。它发布后我花了几周才意识到这一点——也等了一段时间让 codex 在功能上追上 claude code，再花点时间学习并理解差异；但之后我开始越来越信任这个模型。**如今我几乎不怎么读代码了。**我会看着流式输出，有时也会查看关键部分，但说实话——大多数代码我都不读。我确实知道各个组件分别在哪里、事情是如何组织的，以及整个系统的设计方式，而这通常就足够了。

如今重要的决策是语言/生态系统和依赖。我首选的语言是：做 Web 用 TypeScript，做 CLI 用 Go，如果需要用到 macOS 的东西或有 UI 就用 Swift。几个月前我甚至一点都没考虑过 Go，但后来我试着折腾了一下，发现智能体特别擅长写它，而且它简单的类型系统让 lint 变得很快。

正在开发 Mac 或 iOS 相关东西的朋友们：你现在基本不怎么需要 Xcode 了。我甚至都不用 xcodeproj 文件。Swift 的构建基础设施如今对大多数事情来说已经足够好了。codex 知道如何运行 iOS 应用以及如何与模拟器打交道。不需要任何特殊东西或 MCP。

codex-vs-opus

我在这里写这篇帖子的时候，codex 正在进行一次巨大的、耗时数小时的重构，并把 Opus 4.0 早期那些更糟糕的历史遗留问题一一收拾干净。Twitter 上的人经常问我 Opus 和 codex 的最大区别是什么，以及既然基准测试分数那么接近，这种区别为什么还重要。依我看，基准测试越来越难以信任——你得两个都试一试才能真正理解。不管 OpenAI 在后训练阶段做了什么，codex 被训练成在开始之前先阅读大量代码。

有时它只是在开始编写任何代码之前，默默地读文件读上 10、15 分钟。一方面这很烦人，另一方面这又很惊人，因为这大大提高了它修对东西的概率。相比之下，Opus 要积极得多——很适合做小改动——但不太适合做更大的功能或重构；它经常不会把整个文件读完，或者漏掉某些部分，然后给出低效的结果，或者漏掉一些东西。我注意到，即使 codex 在类似任务上有时比 Opus 慢 4 倍，我往往反而更快，因为我不需要回头去修“修复本身”，而这在我还在用 Claude Code 的时候感觉相当正常。

Codex 也让我得以抛弃许多在使用 Claude Code 时不得不做的“装腔作势”。我不再使用“计划模式”，而是直接与模型开始对话：提个问题，让它去谷歌、探索代码、一起制定计划；当我对看到的内容满意时，我就写“build”或“write plan to docs/*.md and build this”。计划模式感觉像是一种权宜之计——这是为早期那些不太擅长遵循提示的模型所必须的，所以我们不得不拿走它们的编辑工具。还有一条被严重误解、至今仍在流传的我的推文，它让我意识到大多数人并不明白计划模式并不是什么魔法。

Oracle

从 GPT 5/5.1 到 5.2 的跃迁非常巨大。我大约一个月前做了 oracle 🧿——这是一个 CLI，允许智能体运行 GPT 5 Pro，并上传文件 + 提示词，同时管理会话，以便之后可以取回答案。我这么做是因为很多时候智能体卡住时，我会让它把所有内容写进一个 markdown 文件，然后我自己再去查询，这感觉就是重复性的时间浪费——也是一个把闭环补上的机会。使用说明在我的全局 AGENTS.MD 文件里，而且模型有时在卡住时会自己触发 oracle。我每天会用它好多次。这是一次巨大的解锁。Pro 擅长以“速通”的方式扫过大约 50 个网站，然后非常认真地思考，几乎每次都能把回答做对。有时它很快，只要 10 分钟，但我也遇到过跑了超过一小时的情况。

现在 GPT 5.2 已经发布，我需要它的情况少了很多。我自己有时会用 Pro 来做研究，但让我让模型“去问神谕”的次数，从每天多次变成了每周几次。我对此并不生气——构建 oracle 非常有趣，我学到了很多关于浏览器自动化和 Windows 的东西，也终于花时间去研究 skills，此前我相当长一段时间都把这个想法搁置了。这确实表明 5.2 在许多真实世界的编程任务上进步了多少。它对我抛给它的几乎任何东西都能一次搞定。

另一个巨大的优势是知识截止日期。GPT 5.2 一直到 8 月底，而 Opus 还停留在 3 月中旬——相差大约 5 个月。当你想使用最新可用的工具时，这一点非常重要。

一个具体示例：VibeTunnel

再给你一个例子，说明模型已经进步到了什么程度。我早期一个投入很深的项目是 VibeTunnel。它是一个终端复用器，让你可以随时随地写代码。今年早些时候我几乎把所有时间都投入到它上面，做了两个月后它好到让我在和朋友外出时都忍不住用手机写代码……然后我决定应该停下来，这更多是出于心理健康方面的考虑。那时候我尝试把复用器的一个核心部分从 TypeScript 重写出去，但旧模型总是搞不定。我试了 Rust、Go……天啊，甚至 zig。当然我本可以把这次重构做完，但它需要大量手工工作，所以在我把它搁置之前一直没能完成。上周我把它从灰尘里翻出来，只给 codex 一个两句话的提示，让它把整个转发系统转换成 zig，它跑了 5 个多小时，经历了多次压缩整理，一次性就交付了可用的转换结果。

你问我为什么还要把它从灰尘里翻出来？我目前的重心是 Clawdis，一个对我所有电脑上的一切都拥有完全访问权限的 AI 助手，还能访问消息、邮件、家庭自动化、摄像头、灯光、音乐，见鬼，它甚至还能控制我床的温度。当然，它也有自己的声音、一个用于发推的 CLI，以及自己的 Twitter 账号。

Clawd 可以看到并控制我的屏幕，有时还会说些刻薄话，但我也想让他具备查看我的智能体的能力，而获取角色流比查看图片要高效得多……这是否能行得通，我们拭目以待！

我的工作流程

我知道……你来这里是想学习如何更快地构建，而我却只是在给 OpenAI 写一段营销推介。我希望 Anthropic 正在打造 Opus 5，让潮水再次转向。竞争是好事！与此同时，我很喜欢 Opus 作为通用模型。我的 AI 代理如果跑在 GPT 5 上，乐趣恐怕连一半都没有。Opus 有某种特别之处，让人用起来很愉快。我把它用于大多数电脑自动化任务，当然 Clawd🦞 也是由它驱动的。

自从我在十月上一次写到这件事以来，我的工作流程并没有太大变化。

1）我通常会同时推进多个项目。根据复杂程度，可能在 3 到 8 个之间。频繁切换上下文会很累，我真的只能在家工作、安静且专注的时候才做得到。这需要在脑中来回切换很多心智模型。好在大多数软件都很无聊。做一个 CLI 来查看你的外卖配送状态并不需要想太多。通常我会把重心放在一个大项目上，旁边还有一些按部就班推进的卫星项目。当你做了足够多的智能体工程，就会对哪些事情很容易、模型可能会在哪些地方卡住形成直觉，所以我常常只要写个提示，Codex 就会跑上 30 分钟，然后我就能得到我需要的东西。有时需要稍微调一调或发挥点创造力，但很多时候都很直接。

2）我大量使用 codex 的队列功能——一有新点子，我就把它加到流水线里。我看到很多人在尝试各种多智能体编排系统、邮件或自动化任务管理——到目前为止我觉得没太大必要——通常瓶颈在我。我的软件构建方式非常迭代。我做点东西，玩一玩，看看“感觉”如何，然后就会有新想法去完善它。我脑子里很少会有一个完整的目标蓝图。当然，我会有个大概方向，但在探索问题领域的过程中，它往往会发生巨大的变化。所以，那些把完整想法作为输入然后输出结果的系统并不适合我。我需要去把玩它、触摸它、感受它、看见它——我就是这样让它不断演进的。

3）我基本上从不回退或使用检查点。如果有些东西不是我喜欢的样子，我就让模型去改。Codex 有时会重置一个文件，但更多时候它只是撤销或修改这些编辑；我很少需要完全退回去，而是我们会转向不同的方向。构建软件就像爬山。你不会直直往上爬，而是绕着山转、不断转弯；有时你会偏离路径，不得不往回走一小段。这并不完美，但最终你会到达你需要去的地方。

4）我就是直接提交到 main。有时候 codex 觉得太乱了，会自动创建一个 worktree，然后再把改动合并回去，但这种情况很少，我也只会在极少数例外情况下才会提示它这么做。我发现在项目里不得不去考虑不同状态会带来额外的认知负担，没有必要，我更喜欢按线性方式推进。更大的任务我会留到我分心的时候做——比如写这段话的同时，我在这里对 4 个项目跑重构，每个大概需要 1-2 小时才能完成。当然我也可以在 worktree 里做，但那只会导致大量合并冲突和不够理想的重构。注意：我通常是一个人工作，如果你在更大的团队里，这种工作流显然行不通。

5）我已经提到过我规划一个功能的方式。我一直在交叉参考项目，尤其是当我知道自己已经在别处解决过某个问题时，我会让 Codex 去查看 ../project-folder，这通常就足够让它从上下文推断出该去哪里找。这对于节省提示词非常有用。我只需要写“看看 ../vibetunnel，然后对 Sparkle 的变更日志做同样的事”，因为那边已经解决了，而且有 99% 的把握它会正确地把东西复制过来并适配到新项目。我也是这样来搭建新项目脚手架的。

6）我见过不少系统是给那些想要引用过去会话的人用的。另一件我从不需要也从不用的东西。我会在每个项目的 docs 文件夹 里为各个子系统和功能维护文档，并在我的全局 AGENTS 文件里使用一个脚本 + 一些说明来强制模型在某些主题上阅读文档。项目越大，这种做法的回报越高，所以我不会到处都用，但它对保持文档最新、并为我的任务构建更好的上下文非常有帮助。

7）说到上下文。我以前在开始新任务时会非常勤快地重启一个会话。有了 GPT 5.2 之后，这就不再需要了。即使上下文更满，性能也极其出色，而且往往还能提升速度，因为当模型已经加载了大量文件时运行会更快。显然，这只有在你把任务串行化，或者让改动彼此相隔足够远、以至于两个会话几乎不会互相影响时才行。codex 不像 claude code 那样有“这个文件变更了”的系统事件，所以你需要更小心——但反过来说，我感觉 codex 在上下文管理上就是好得多，我觉得用一个 codex 会话能完成的工作量是用 claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有别的因素在起作用。我猜 codex 在内部会把思考压得非常精炼以节省 token，而 Opus 则非常啰嗦。有时模型会出错，它的内部思考流会泄露给用户，所以我见过这种情况好几次。说真的，codex 很会遣词造句，我觉得这有种奇怪的娱乐性。

8）提示词。我以前会用语音输入写很长、很精心的提示词。用了 Codex 之后，我的 提示词变得短了很多，我经常会重新打字，而且很多时候我会添加图片，尤其是在迭代 UI（或者用 CLI 处理文案文本）时。如果你把哪里不对给模型看清楚，只需要几个词就足以让它按你的想法去做。没错，我就是那种会拖进一张截取的 UI 组件图片，然后写上“修复内边距”或“重新设计”的人；很多时候这要么就解决了我的问题，要么也能把我推进到一个相当不错的程度。我以前会引用 markdown 文件，但有了我的 docs:list 脚本之后，就不再需要了。

9）Markdown 文件。很多时候我会写“把文档写到 docs/*.md”，然后干脆让模型自己挑一个文件名。你为模型所训练的内容把结构设计得越直观，你的工作就会越轻松。毕竟，我设计代码库不是为了让自己好导航，而是把它们工程化成让智能体能在其中高效工作的样子。与模型对抗往往是在浪费时间和 token。

工具与基础设施

1） 还有什么仍然很难？ 选择合适的依赖和要采用的框架这件事，我会投入相当多的时间。它维护得好吗？同级依赖怎么样？它流行吗——也就意味着会有足够的世界知识，让智能体更容易上手吗？同样还有系统设计。我们要通过 WebSocket 通信吗？还是 HTML？哪些放在服务器端，哪些放在客户端？数据如何以及通过哪些方式在不同部分之间流动、从哪里到哪里？这些往往是更难向模型解释的事情，而在这方面做研究和深入思考是值得的。

2）由于我管理着很多项目，我经常让一个代理直接在我的项目文件夹里运行；当我摸索出一种新的模式时，我就让它“找出我最近的所有 Go 项目，并把这个改动也在那些项目里实现 + 更新变更日志”。我的每个项目在那个文件里都会把补丁版本号提高；当我回头再看时，往往已经有一些改进在等着我去测试了。

3）当然，我会把一切都自动化。注册域名和修改 DNS 是一项技能。编写优秀的前端也是一项技能。我的 AGENTS 文件里有一条关于我的 Tailscale 网络的备注，所以我只要说“去我的 Mac Studio 并更新 xxx”。

4）顺便说一下关于多台 Mac这事。我通常在两台 Mac 上工作：大屏上用我的 MacBook Pro，另一个屏幕上通过 Jump Desktop 连接到我的 Mac Studio。有些项目在那边跑着，有些在这边弄着。有时我会在每台机器上编辑同一个项目的不同部分，然后通过 git 同步。比起 worktree 更简单，因为 main 上的偏移很容易对齐。还有个额外好处是，凡是需要 UI 或浏览器自动化的东西，我都可以挪到 Studio 上跑，它弹出的各种窗口也不会烦到我。（是的，Playwright 有无头模式，但有不少情况下它就是不管用）

5）另一个好处是任务会在那边持续运行，所以每当我旅行时，远程端就成了我的主工作站，即使我合上 Mac，任务也会继续跑。我过去确实试过像 codex 或 Cursor Web 这样的真正异步代理，但我怀念那种可控性，而且最终工作还是会以拉取请求的形式结束，这又给我的配置增加了复杂度。我更喜欢终端的简单直接。

6）我以前玩过斜杠命令，但一直没觉得它们有多大用处。技能替代了其中一部分，至于剩下的，我一直写“commit/push”，因为这和输入 /commit 花的时间一样，而且总是能用。

7）过去我经常专门抽出几天来对项目进行重构和清理，但现在我更多是临时顺手做。每当提示开始耗时太久，或者我在代码流里看到有什么丑陋的东西一闪而过，我就会立刻处理。

8）我试过 Linear 或其他问题跟踪器，但都没能坚持用下去。重要的想法我会立刻去做，其他的要么我会记得，要么就不重要。当然，我为使用我开源代码的人提供了公开的 bug 跟踪器，但当我发现一个 bug 时，我会立刻把它处理掉——这比先写下来、然后以后再切换回那个上下文要快得多。

9）无论你要做什么，先从模型和 CLI 开始。我脑子里一直有个想法：做一个用于总结 YouTube 视频的 Chrome 扩展。上周我开始做 summarize，一个 CLI：它把任何内容转换成 markdown，然后把它交给模型做摘要。我先把核心打磨正确，一旦跑得很棒，我就在一天内把整个扩展做出来了。我非常喜欢它。可在本地运行，支持免费或付费模型。在本地转录视频或音频。与本地守护进程通信，因此速度超级快。去试试吧！

10）我首选的模型是 gpt-5.2-codex high。还是那句话，KISS。除了速度慢得多之外，xhigh 几乎没什么额外好处，而且我不想花时间去琢磨不同模式或“ultrathink”。所以基本上所有东西都跑在 high 上。GPT 5.2 和 codex 足够接近，换模型毫无意义，所以我就用这个。

我的配置

这是我的~/.codex/config.toml:

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# Leave room for native compaction near the 272–273k context window.
# Formula: 273000 - (tool_output_token_limit + 15000)
# With tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true

[projects."/Users/steipete/Projects"]
trust_level = "trusted"

这使模型能够一次性读取更多内容，默认值有点小，可能会限制它能看到的内容。它会静默失败，这很烦人，他们最终会修复这个问题。另外，网络搜索仍然不是默认开启的吗？unified_exec替换了 tmux 和我旧的runner脚本，rest 也很整洁。而且别害怕压缩，自从 OpenAI 切换到他们新的 /compact 端点后，这个方案运行得足够好，任务可以跨多个压缩继续执行并最终完成。它会让进度变慢，但往往相当于一次复查，模型在再次查看代码时会发现 bug。

就先写到这里吧。我打算再多写一些，脑子里也积了不少点子，只是玩得太开心，一直在做东西。如果你想听更多碎碎念以及关于如何在这个新世界里构建的想法，在 Twitter 上关注我。

都 2026 年了，程序员拿到一台新 mac 怎么做？

Fri, 02 Jan 2026 09:35:28 GMT

大家新年好，我是 luckySnail，祝我的读者新的一年，马到成功，马上发财。如果你和我一样是程序员，那希望我们都“码”力全开。好了下面想跟大家分享一下，我最近是如何不到半小时就配置好一台新 Mac，如果你也刚好拿到一台新电脑，不管是 Mac 或者 Windows ，都可以参考我的配置思路

联网 + 安装 Claude Code

第一步当然是连上网络，然后进行下一步，这没啥好说的。然后去 https://claude.com/product/claude-code 使用 curl 安装 Claude Code（CC），安装成功后，你运行 claude 大概率会提示： zsh: command not found: claude，这时候还需要运行一行命令，配置一下环境变量，这样以后安装cli 工具都可以直接运行：

#在你的 `~/.zprofile`（或 `.zshrc`）里加上这几行

# Common user binaries
export PATH="$HOME/.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"
# 然后执行 source ./.zshrc

这样后面安装的 brew ，npm ，bun 等工具都可以直接使用了！好了，当我们安装成功了 CC ，下面的事情就变得极其简单了～

GUI APP 安装

打开 CC，然后告诉它你要安装的应用，让它使用 brew 帮你安装，你只需要等待完成后收货即可，下面是我安装的应用列表：

brew install --cask tencent-meeting feishu wechat wetype neteasemusic google-chrome wpsoffice doubao iterm2 typeless microsoft-edge capcut visual-studio-code webstorm cleanshot sourcetree picgo obsidian

如果你知道你需要安装的列表，那可以直接一行命令，如果你不知道可以让 CC 帮你

CLI

和安装 GUI app 一样，你可以选择和 CC 对话或者运行命令：

brew install ffmpeg gh git tree wget fnm

终端美化

告诉 claude：

安装终端美化工具： https://ohmyz.sh/ ，使用主题： powerlevel10k 并且安装插件：  zsh-syntax-highlighting zsh-autosuggestions

结语

过往，配置一台新的电脑至少需要一个小时，但是有了 AI，强烈建议先安装一个 AI CLI Agent ，然后把其他的事情都交给它，它不仅仅干的快，还干得好。配置环境，折腾终端在 AI 时代已经变得极其简单

2025 年末来盘点一下我这半年使用过的 AI 工具

Fri, 19 Dec 2025 16:35:12 GMT

不包含任何推广，所有评价都是真实测试的主观感受介绍顺序也就是推荐指数，最先介绍的就是最好的个人每月在 AI 上的支出大概 200 多

AI 编程类

OpenAI - Codex：就在今天，发布了最新的 gpt-5.2-codex ，真的是指哪打哪，尤其是在长上下文，复杂任务上，它能连续工作几十分钟来完成任务，缺点就是慢
Anthropics - Claude Code：毫无疑问，当前最主流的 TUI coding Agent，但是最近经常降智，知道我写这段文字的时候，官方还承认了 Opus 4 降智，在排查问题。缺点是贵，尤其是使用 Opus 4 ，不一会就没有了
Warp：支持多家大模型，本质上一个 Agent 终端，交互友好，适合新人
Droid：我之前专门分享过，也是一个终端 coding Agent，在工程化上面做的比较好，适合处理多步的任务
Cursor：好久没有使用了，但是还是想推荐一下，因为它的交互是最自然的，自动补全是最好的，但是目前价格太贵，并且 Agent 模式的生成效果完全不如其他 cli 工具。但是它对小白比较友好
Antigravity：反重力，前身是 Windsurf，目前被 Google 接手，好用是好用，尤其是集成 Google 游览器，在调试和前端开发有很大的优势，但是它太迟性能了，我的电脑带不动，不知道能不能优化好，目前内置的 Gemini 3 flash 可以免费使用，还有 Claude 大模型免费额度。还有一个缺点就是它的自动补全太烂了！
Kiro：这是亚马逊家的，UI 美观，新人注册送的额度也比较多，实际体验下来也不错，集成 Spec 比较好，但是我个人不觉得 Spec 是好东西。所以没有具体使用过，它还有自己的 Cli，使用体验不错
Neovate：蚂蚁团队开发的一个 coding Agent，优点是不和大模型绑定，支持很多特性，内置了很多最佳实践，在使用国产大模型的时候我都会使用它
Gemini CLI：不知道现在好用了不，几月前使用体感非常差，目前 cli 集成了自家最新的 3 系列的大模型，可以明天去体验一下，理论上在前端页面开发应该是有优势的
VScode：可能你会说，这不是 AI 工具吧，但是它自带的 github copilot 在自动补全方面也挺不错，其他能力我基本不使用

日常提问

web 端：

chatGPT：我认真对比了 Claude Opus 4.5，Gemini 3 Pro，ChatGPT 5.2 ，目前chatGPT 还是老大哥，大家也可以自己试试，所以我还是会每月订阅 ChatGPT，它在分析问题，技术辅导，图片生成等都非常出色
Gemini ： nano banana 爆火，让我们再次看到 Google 的底蕴，有自家 Youtube 和搜索引擎的资源，在训练大模型上得天独厚的优势。目前实测下来视频和图片理解能力独一档
Claude：经常拿来对比查看结果，在编码领域 Claude 有时候输出质量要高于其他
Qwen：翻译和写作
豆包：好像 web 端它没有什么优势
deepseek：也是翻译和写作
lobechat：测试一些大模型

桌面端

Alma：很有品味的一个套壳 AI 对话软件，记忆优先，UI 交互很赞
其实我一直想要一个 AI 写作辅助工具，但是也没有特别关注，如果有好用到，期待你的分享

手机端

豆包：做饭神器，日常生活指南，集成了抖音的数据，在回答问题上比较靠谱
ChatGPT：兴致来了，跟它学英语，很有趣

暂时就能想到这么多了！如果你有什么宝藏 AI 工具，也分享出来让我们一起使用最先进的 AI 工具来提效吧！

📒《Smalltalk Best Practice Patterns》阅读笔记

Sun, 07 Dec 2025 16:33:08 GMT

大家好，我是 luckySnail，分享一本面向对象编程的好书《Smalltalk Best Practice Patterns》，这本书是基于 Smalltalk 编程语言提炼出的面向对象设计与编码模式，但是其他语言也适用。

这本书的作者是 Kent Beck ，是美国著名的软件工程师、作家，是软件开发领域的重要先驱者之一，作者出生于美国硅谷，父亲是电器工程师，受家庭环境影响，他也走上了计算机的道路，并成功获得计算机硕士学位。他还是敏捷开发之父之一、TDD（测试驱动开发）发明者、极限编程（XP）创始人，也曾是 Facebook（Meta）的工程教练。他还提出非常有影响力的理念：Code is a liability. 认为代码是负债

下面我会先总结书中的编程精华，然后再分享书中的一些摘抄

原书是使用 Smalltalk 语言，这里转为 JavaScript 语言版本

编程 Tips

1. 核心思维：代码是写给队友（和未来的自己）看的

一次且仅一次 (DRY - Don’t Repeat Yourself)：如果你在两个 function 中看到了复制粘贴的代码，请提取它。
- JS 实践： 善用模块化（import/export）提取公共工具函数，或者提取父类/组合逻辑。
许多小碎片 (Lots of Little Pieces)：不要写几百行的“上帝函数”。把大函数拆分成许多小的、功能单一的函数。
- JS 实践： 一个文件不要塞进太多逻辑，利用 ES Modules 拆分文件。
意图优先 (Intention over Implementation)：函数名要通过名字告诉调用者“我要做什么”，而不是“我怎么做” 。
- Bad: processUserArrayLoop() (描述了实现细节)
- Good: notifyActiveUsers() (描述了业务意图)

2. 函数设计：让逻辑像文章一样流畅

组合方法 (Composed Method)：一个顶层业务函数应该像一个“目录”。它只负责调用其他的步骤函数，不应该包含具体的 for 循环或复杂的 if 判断细节。

        // Bad
        async function checkout(cart) {
          if (cart.length === 0) return;
          let total = 0;
          for (const item of cart) { total += item.price; }
          await api.charge(total);
          // ... 几十行代码
        }

        // Good (Composed Method)
        async function checkout(cart) {
          if (isEmpty(cart)) return; // Guard Clause
          const total = calculateTotal(cart);
          await chargeCustomer(total);
          await emailReceipt(cart);
        }

完整的创建方法 (Complete Creation Method)：不要创建一个“空对象”然后让用户一行行去填数据。提供一个工厂函数或构造函数，一次性传完必要参数，返回一个立即可用的对象。
- JS 实践： 使用 Factory Functions 或 Class 的 constructor。
- 示例: const user = User.createValidUser(name, email); 而不是 const u = new User(); u.name = ...;

3. 逻辑控制：告别回调地狱与嵌套

卫语句 (Guard Clause)：不要把主逻辑包裹在层层嵌套的 if 块里。如果在函数开头发现条件不满足（如参数为空、出错），直接 return 。

        // Bad
        function process(user) {
          if (user) {
            if (user.isActive) {
              // 做事...
            }
          }
        }

        // Good
        function process(user) {
          if (!user || !user.isActive) return;
          // 做事...
        }

消息即选择 (Polymorphism over Switch)：如果你发现自己在写 switch (type) 或大量的 if (type === ‘A’)，尝试用对象的多态或策略模式代替。
- JS 实践： 使用对象字面量映射 (Object Map) 代替 Switch。
- 示例:

        const handlers = {
          'A': handleTypeA,
          'B': handleTypeB
        };
        const run = handlers[type] || defaultHandler;
        run();

4. 变量使用：让数据会说话

解释性临时变量 (Explaining Temporary Variable)：如果 if 条件里有一长串 && 和 ||，把它们赋值给一个布尔值变量，用变量名解释这个条件是什么意思。
- JS 示例:

// Bad
f (platform.toUpperCase().indexOf('MAC') > -1 && browser.type === 'Chrome' && version > 80) { ... }
// Good
const isModernMacChrome = ...;
if (isModernMacChrome) { ... }

角色导向命名 (Role Suggesting Name)：变量名要说明它在当前上下文的角色，JS 是动态类型语言，这点尤为重要。
- Bad: const arr = [] (只是说了类型)
- Good: const activeUsers = [] (说了角色)

5. 数组操作：扔掉 for 循环

Smalltalk 最引以为傲的就是集合操作，这对应了现代 JavaScript 的 Array Methods。只要能用高阶函数，就别手写循环。

遍历 (Enumeration):
- Smalltalk: do: -> JavaScript: .forEach() 或 for...of (为了副作用)。
转换 (Transformation):
- Smalltalk: collect: -> JavaScript: .map()。
- 场景: 把用户对象列表变成用户 ID 列表。
筛选 (Filtering):
- Smalltalk: select: / reject: -> JavaScript: .filter()。
- 场景: 只要成年的用户。
查找 (Searching):
- Smalltalk: detect: -> JavaScript: .find()。
- 场景: 找到列表中第一个叫 “Admin” 的人。
聚合 (Reduction):
- Smalltalk: inject:into: -> JavaScript: .reduce()。
- 场景: 计算购物车总金额。
判空 (Emptiness):
- Smalltalk: isEmpty -> JavaScript: 封装一个工具函数 isEmpty(arr) 或者在领域对象中封装 .length === 0 的检查，不要让 .length === 0 散落在代码各处，语义不直观。

下面是关于对象交互、状态管理和代码组织的高级模式。这些模式在构建复杂的 JavaScript 应用（尤其是使用 React、Vue 或 Node.js 的 OOP 风格代码）时非常有用。

1. 环绕执行模式 (Execute Around Method)

核心思想：当有一对操作必须成对出现（如“打开/关闭”、“开始/结束”、“锁定/解锁”）时，不要让调用者去手动管理这两个步骤，因为他们很容易忘记后一步。你应该提供一个方法，接受一个函数作为参数，在这个方法内部自动处理“收尾”工作。 JavaScript 实践：利用 JavaScript 的高阶函数（Higher-Order Function）来封装这种模式。

Bad (容易导致资源泄漏):

   const db = new DatabaseConnection();
   await db.open();
   try {
     await db.query('SELECT * ...');
     // 如果这里报错，close() 可能永远不会执行，或者必须写重复的 finally
   } finally {
     await db.close();
   }

Good (Execute Around):

    // 在类中定义这个通用模式
    class Database {
      // 接收一个 block (函数)
      async execute(action) {
        const connection = await this.open();
        try {
          return await action(connection); // 执行传入的逻辑
        } finally {
          await this.close(); // 保证关闭
        }
      }
    }

    // 调用者的代码变得极其干净
    await db.execute(async (conn) => {
      await conn.query('SELECT * ...');
    });

2. 可插拔行为 (Pluggable Behavior)

核心思想：当一个对象的某些逻辑需要变化时，不要写一堆子类（Subclassing），也不要写复杂的 switch 语句。你可以在对象内部存一个变量，这个变量存的是一个函数或策略对象。当需要执行该逻辑时，直接调用这个变量。这就是现在的“策略模式”或简单的“回调函数”注入。

Bad (硬编码逻辑):

    class Button {
      onClick() {
        if (this.type === 'submit') { this.submitForm(); }
        else if (this.type === 'reset') { this.resetForm(); }
      }
    }

Good (Pluggable Selector / Block):

    class Button {
      constructor(action) {
        this.action = action; // 存储一个函数 [cite: 1232]
      }

      onClick() {
        // 直接执行存储的行为，Button 不需要知道具体的业务逻辑 [cite: 1233]
        if (this.action) this.action();
      }
    }

    // 使用时“插入”行为
    const submitBtn = new Button(() => form.submit());
    const logBtn = new Button(() => console.log('Clicked'));

3. 委托代替继承 (Delegation)

核心思想：如果你想复用另一个类的代码，但又不想继承它（因为不需要它的所有方法，或者已经继承了别的类），那就把那个类的实例作为一个属性存在自己这里，然后把任务“委派”给它去做

组合优于继承（Composition over Inheritance）。

场景: 你有一个 UserList 类，你想让它拥有数组的一些功能（比如 filter），但不想继承 Array。
JS 示例:

class UserList {
   constructor() {
     this.users = []; // 内部持有一个数组 (Common State)
   }
   add(user) {
    // 简单委托 (Simple Delegation)：直接叫内部的 users 去做
      this.users.push(user);
    }
   // 可以在委托前后加自己的逻辑
   filterActive() {
     return this.users.filter(u => u.isActive);
    }
}

4. 间接变量访问 (Indirect Variable Access)

核心思想：即使在类的内部，是否应该直接访问属性（如 this.count）还是通过 Getter 方法（如 this.getCount()）书中的建议是：为了灵活性，尽量使用间接访问（即 Getter/Setter）。这样如果你以后想把“直接读取变量”改成“惰性计算（Lazy Initialization）”，你只需要改 Getter 一个地方，而不需要改全类所有的引用点。

Direct Access (直接访问 - 简单但僵化):

class Circle {
  constructor(radius) {
    this.radius = radius;
  }
  area() {
    // 如果 radius 以后变成了通过计算获取，这里也得改
    return Math.PI * (this.radius * this.radius);
  }
}

Indirect Access (间接访问 - 灵活):

class Circle {
  constructor(radius) {
    this._radius = radius;
  }

  // Getter Method [cite: 1552]
  get radius() {
    return this._radius;
  }

  area() {
    // 使用 getter，而不是直接用 this._radius [cite: 1545]
    return Math.PI * (this.radius * this.radius);
  }
}

指导意义：当你在 JS 中使用 get 关键字时，你就在实践这个模式。它允许你未来在不破坏 area() 方法的前提下，给 radius 增加日志、验证或惰性加载逻辑。

5. 转换器方法 (Converter Method)

核心思想：

如果你需要把一个对象转换成另一种格式，提供一个以 as 开头的方法。这让转换的意图非常清晰。

在 JS 中，我们常有 toJSON, toString, toArray 等方法。

JS 示例:

class User {
  // ... 属性包含 id, name, passwordHash ...

  // Converter Method [cite: 566]
  asDTO() {
    // 返回一个只包含前端需要数据的新对象
    return {
      id: this.id,
      name: this.name
    };
  }
}

// 调用
res.json(user.asDTO());

6. 级联 (Cascade) / 链式调用

核心思想：

如果你需要对同一个对象连续发送多条消息（调用多个方法），可以通过特定的格式或设计，避免重复写接收者的名字。在 JS 中，这通常通过让方法 return this 来实现（Fluent Interface）。

Bad (重复接收者):

const config = new Config();
config.setUrl('http://api.com');
config.setTimeout(5000);
config.setRetries(3);

Good (Cascade / Chaining):

class Config {
  setUrl(url) {
    this.url = url;
    return this; // Interesting Return Value: 返回 self [cite: 2811, 2837]
  }
  setTimeout(time) {
    this.timeout = time;
    return this;
  }
  // ...
}

// 调用
const config = new Config()
  .setUrl('http://api.com')
  .setTimeout(5000)
  .setRetries(3);

7. 查找缓存 (Lookup Cache)

核心思想：如果你有一个计算或查找过程非常耗时（比如 detect 或 select），并且数据不会频繁变动，你可以用一个 Dictionary（在 JS 中是 Map 或对象）作为缓存。读取时先查缓存，没有再计算并存入。 JavaScript 实践：简单的 Memoization（记忆化）。

class ProductService {
  constructor() {
    this.products = [...]; // 假设有很多数据
    this.cache = new Map(); // Lookup Cache
  }

  getProduct(id) {
    // 如果缓存里有，直接返回
    if (this.cache.has(id)) {
      return this.cache.get(id);
    }
    // 复杂的查找逻辑
    const product = this.products.find(p => p.id === id);

    // 存入缓存
    this.cache.set(id, product);
    return product;
  }
}

下面模式涵盖了从微观的代码排版到宏观的对象交互设计

1. 行为与消息 (Behavior & Messages)

这部分关于如何让对象之间更优雅地沟通。

分解消息 (Decomposing Message)
- 当你有一个复杂的任务时，不要直接写一长串代码。发送一个消息给自己（self），把这个任务分解成几个更小的步骤。这就像把一个大程序拆分成几个子程序，有助于理清思路。
反向发送 (Send Back)
- 当你委托另一个对象做事时，如果那个对象需要你的一些信息，它会把消息“发回”给你。不要害怕这种来回调用，这是对象间协作的常态。
Super 的使用 (Extending vs. Modifying Super)
- 扩展 (Extending)：如果你想在父类功能的基础上增加功能，重写方法并在其中调用 super。
- 修改 (Modifying)：如果你想改变父类的行为，依然可以重写，但如果不调用 super 或者在特定位置调用，就意味着你改变了原本的逻辑流。
收集参数 (Collecting Parameter)
- 如果你需要从多个方法中收集结果（例如遍历一棵树并收集所有节点），不要让每个方法都返回集合然后合并。相反，创建一个集合对象，把它作为参数传递给所有方法，让它们把结果加进去。

2. 状态与变量 (State & Variables)

这部分关于如何处理对象的数据。

创建参数方法 (Creation Parameter Method)
- 指导：在初始化对象时，如果需要设置多个变量，不要写一堆 setX:, setY:。创建一个单一的方法（如 setX:y:），一次性设置所有相关的变量，并利用这个机会进行初始化检查。
默认值方法 (Default Value Method)
- 指导：如果一个变量有默认值，不要把这个值硬编码在初始化方法里。创建一个专门的方法（如 defaultColor）返回这个值。这样子类可以通过重写这个小方法来轻松改变默认值。
常量方法 (Constant Method)
- 指导：避免使用全局常量池。如果一个类需要用到常量（比如 π 或某个固定的配置值），把它写成一个返回该值的方法。
布尔属性设置 (Boolean Property Setting Method)
- 对于布尔类型的属性（如开关），不要只提供 setSwitch: true/false。提供更语义化的方法，如 turnOn（打开）和 turnOff（关闭），或者 makeVisible / makeInvisible。
重用临时变量 (Reusing Temporary Variable)
- 指导：通常我们要避免重用变量，但如果在处理像流（Stream）这样读一次就变的状态时，或者表达式有副作用时，应该把结果存入临时变量，以便在后续代码中多次使用该结果，避免重复执行副作用。

3. 集合的高级用法 (Collections)

除了基本的遍历，书中还介绍了一些特定的集合模式。

栈与队列 (Stack & Queue)
- 指导：Smalltalk（以及很多现代语言标准库）没有专门的 Stack 类。使用 OrderedCollection（或数组/列表）来模拟。
  - Stack: addLast: (push), removeLast (pop).
  - Queue: addLast: (enqueue), removeFirst (dequeue).
解析流 (Parsing Stream)
- 指导：如果你在编写解析器，不要把流对象在每个方法间传以此参数。把流作为实例变量存储在解析器对象中，这样所有方法都能共享当前的解析位置。
连接流 (Concatenating Stream)
- 指导：当你需要拼接大量字符串或集合时，不要反复使用 + 或 ,（连接符），这会产生大量中间垃圾对象。使用 Stream（在 JS 中类似 StringBuilder 或 Array.join）来高效构建结果。
字面量搜索 (Searching Literal)
- 指导：如果你要判断一个值是否属于某几个特定值之一（如 isVowel），不要写一长串 if (a == 'a' || a == 'e' ...)。创建一个包含这些值的集合（字面量数组），然后问它 includes:。
  - 示例: ^#('a' 'e' 'i' 'o' 'u') includes: aChar。

4. 格式化 (Formatting)

这部分关于如何让代码视觉上更易读。

内联消息模式 (Inline Message Pattern)
- 指导：为了节省垂直空间，尽量把方法的参数定义写在一行里，而不是每个参数换一行（除非参数特别多）。让读者一眼能看到方法体。
类型暗示参数名 (Type Suggesting Parameter Name)
- 指导：参数命名要暗示其类型。例如 at: index 暗示索引是整数，at: key 暗示键可能是任意对象。使用 aString, anInteger 这样的命名风格。
矩形块 (Rectangular Block)
- 指导：对于闭包（Block/Lambda），如果内容很简单，写在一行。如果复杂，利用缩进让它看起来像一个矩形，让眼睛能快速识别代码块的范围。
条件表达式 (Conditional Expression)
- 指导：利用控制结构（如 if-else）会返回值的特性。
  - Bad: if (test) { return 1; } else { return 2; }
  - Good: return test ? 1 : 2; (或者在 Smalltalk 中直接返回 if 表达式的结果)。意图是“返回两个值中的一个”，而不是“执行两条路径中的一条”。
Yourself
- 指导：当你使用级联消息（Cascade，即链式调用）配置一个对象时，如果最后一个方法返回的不是对象本身，而你需要这个对象，请在最后加上 yourself（返回 self）。这确保整个表达式的值是你正在配置的那个对象。
有意义的返回值 (Interesting Return Value)
- 指导：只有当调用者真正需要用到返回值时，才显式返回一个值。否则，默认返回对象本身（在 Smalltalk 中）或者 void，不要让调用者去猜测返回值的含义。

这些模式共同构成了一套完整的编码哲学：清晰 (Clarity) 优于 效率 (Efficiency)（除非有性能瓶颈），沟通 (Communication) 优于 简洁 (Brevity)

原文摘抄

1 ） “软件开发中所有的瓶颈，归根结底都来自于人类沟通的局限性。”

原文：“The bottlenecks throughout development come from limitations in human communication.”

2）编程高手的秘诀，往往在于那些新手容易忽略的简单习惯。

原文：“This book is about the simple things experienced, successful Smalltalkers do that beginners don’t.” 3）编码是将你那些模糊而舒适的想法，在现实的严酷黎明中唤醒的过程。

原文：“Coding is where your fuzzy comfortable ideas awaken in the harsh dawn of reality.” 4）代码不会撒谎。如果你不倾听，就听不到它诉说的真相。

原文：“Code doesn’t lie. If you’re not listening, you won’t hear the truths it tells.” 5）你必须思考别人将如何阅读你的代码，而不仅仅是计算机将如何解释它。

原文：“You have to think about how someone will read your code, not just how a computer will interpret it.” 6）模式是一种文学形式，用于捕捉和传递那些通用的最佳实践。

原文：“Patterns are a literary form for capturing and transmitting common practice.” 7）没有哪个话题能比‘代码格式化’引发更多的争吵，却带来更少的真知灼见。

No other topic generates more heat and less light than code formatting. 8）在风格优秀的代码中，每一件事都只说一次，且仅说一次。

原文：“In a program written with good style everything is said once and only once.” 9）永远不要把两种不同变化率的东西放在一起。

原文：“Don’t put two rates of change together.” 10）将程序拆分成一个个只完成单一、可识别任务的小方法。

原文：“Divide your program into methods that perform one identifiable task.” 11）任何对 super 的显式调用，都在某种程度上降低了代码的灵活性。

原文：“Any use of super reduces the flexibility of the resulting code.” 12）你是在创造词汇，而不只是在写程序。此时此刻，请做一个诗人。

You’re creating a vocabulary, not writing a program. Be a poet for a moment. 13）搞对了‘行为’比搞对‘状态’更重要。对象让系统不再是数据表象的奴隶。

原文：“Behavior is the more important to get right… No longer is your system a slave of its representation.” 14）实例变量的作用是公开且一劳永逸地声明：‘这就是我用这个对象所构建的模型’。

原文：“Instance variables… say, once and for all and out in the open, ‘here’s what I’m modeling with this object’.” 15）如果你的程序突然变得难以驾驭，那是它在对你说话，告诉你有些重要的东西缺失了。

原文：“If… all of a sudden your program gets balky… it’s talking. It’s telling you there is something important missing.” 16）最大的改进往往来自于弄清楚如何消除：

重复代码（即使是一小部分）
条件逻辑
复杂的方法
结构性代码（即一个对象将另一个对象仅仅视为数据结构）

原文： Some of the biggest improvements come from figuring out how to eliminate:

Duplicate code (even little bits of it)
Conditional logic
Complex methods
Structural code, where one object treats another as a data structure

17）消息传递确实需要时间。如果只关心程序运行速度，你大可以把所有代码写在一个巨大的方法里。但这种激进的优化方式会带来巨大的人力成本，并且忽略了一个事实：在一个结构良好的代码基础上进行性能调优，往往能带来数量级的提升（而不是微小的优化）。

原文： “Messages take time… If all you were worried about was how fast your program would run, you would arrange all of your code in a single method. This radical approach to performance tuning invokes enormous human costs, and ignores the realities of performance tuning well-structured code, which often results in several order-of-magnitude improvements.”

参考

从 Bun.js 被收购，看到了编程范式的转移

Thu, 04 Dec 2025 15:13:02 GMT

最近几个月我陆陆续续在用 Bun.js 做一些小项目，体验不错：快、轻、简单。但今天早上一醒来看到 “Bun 被 A 社（Anthropic）收购” 这条新闻，我还是挺惊讶的但当我继续阅读几篇深度报道，再结合两件关键事实：

Claude Code 的年化收入已突破 10 亿美刀
Claude Code 的运行载体本身就是基于 Bun 打包出来的一切突然都合理起来了：这不是简单买下一个运行时工具，而是 AI 编程时代的基础设施大收购，我意识到：这件事意味着我们正在进入新的编程范式。

下面我会分享四部分内容：

简介 Claude Code，以及它现在面临的问题
Bun.js 到底是什么？它为什么值得被收购？
Bun.js + Claude Code 带来的变化
我个人会如何应对这个“新编程范式”

程序员离不开的 Claude Code 和它目前的问题

Claude Code（下文简称：CC） 无疑是当前最受欢迎的 AI 编程 Agent 之一，尤其在 TUI（Terminal User Interface，终端用户界面） 里。在这之前让我们看一下 AI 编程的发展：最开始的是 Github Copilot 仅仅是简单的代码补全和弹窗提问等能力到后面的 Cursor 可以实现一次性在多个文件中修改和确认，多文件自动补全等功能再到如今 CC 的能够接收需求，自动进行网络搜索，本地文件检索，制定计划（Plan Mode），一步步的执行计划，每一步都能调用原生的工具辅助完成需求，并且在完成后会自动调用 lint 工具，跑测试验证结果，最后的总结本次任务。甚至能直接帮你提交 Pr，写文档可以看到，AI 的效率越来越高了～，我们（程序员）也从代码开发者（手工产出代码），变成了

定义需求
架构和系统的设计
验证 AI 的结果

也就是完全依赖 AI 产出代码，然后我们在必要的时候出手解决 AI 解决不了的问题。如果你使用过 CC ，肯定会惊叹 CC 的强大，你写一个简单的 Prompt ，它会自动分析你的需求，并进行实现，就像真正的工程师一样。但有时候也会抱怨几句：

为什么这么慢？
为什么一本正经的胡说八道？
为什么我的 Token 使用的那么快？
如果你是早期用户，还会抱怨说为什么 windows 不能在终端里面使用呢？

这还是我这种普通使用者的感受，作为 CC 的开发者，可能面临更多问题，如果说这时候有一个工具能解决这里面的一两个问题，那 Anthropic 怎么会不心动呢？那这个工具就是 Bun.js

Bun.js 是什么？凭什么被 Anthropic 看上？

最初对 bun.js 的印象就是一个更快的 Node.js。仔细了解了之后才知道 Bun.js 的野心远不止于此。它是想成为一个 全能工具箱——把现代 JavaScript 开发需要的所有工具塞进一个二进制文件里

从图中可以看出来，前端工具链选择非常多，并且互相之间还存在版本兼容问题。但是 Bun 直接把这些全部内置了！再也不用关心各种工具之间的适配问题了，这种稳稳的幸福正是 AI 编码 Agent 需要的。

最重要的是 Bun 非常快，它底层是使用 zig (一种现代系统编程语言，可以精确控制内存，没有垃圾回收带来的随机卡顿)语言进行编码。并且使用 JavaScriptCore 而不是 V8，来提高冷启动速度和内容消耗。

在上文中我们知道 CC 最初是不能在 windows 的命令行使用，后面支持了，其实现原理就是基于 Bun.js 的强大的打包能力，它会将你的应用、所有依赖、甚至 Bun 运行时本身，打包成一个独立的可执行的二进制文件。

Bun 支持“单文件可执行”，在 AI 编程 Agent 中也很有价值，可以通过 Bun 环境让 AI 来验证自己的代码是不是正确的

Bun.js + CC = ?

当 Bun 被 Anthropic 收购，可以确认的是 CC 未来肯定是会越来越快。解决问题的能力也会大大提升，并且 Bun 也会越来越好，当我们在创建新的项目的时候，也可以把 Bun 作为选择之一，而不仅仅是 Node.js 。同时 AI 编程进行新的范式，AI 从 Copilot （辅助）变成了 Owner (主导编程的角色)，之前程序员编写代码的体力劳动会被 AI 取代

如何应对

我觉得 AI 辅助编程正在经历三个阶段：

第一阶段：生成（Generation） AI 生成代码片段，人类复制粘贴、运行、调试。ChatGPT 刚出来时大家都这么用，大家发现粘贴来粘贴去很麻烦，于是到了下一个阶段

第二阶段：协作（Orchestration） AI 通过 IDE 插件（Copilot）或者工具调用嵌入工作流。它能看到上下文，给出更准确的建议。但本质上还是”辅助”。

第三阶段：自主（Agentic） AI 智能体独立完成”编写 → 运行 → 测试 → 修复”的闭环。人类的角色从”写代码”变成”描述需求”和”审核结果”。

Claude Code 正在把我们推向第三阶段。Bun 的加入加速了这个过程。我的应对策略如下：

1）转变心态，从写代码的角色转变为构建系统的人

AI 可以写代码，但是它目前还是无法理解业务需求，我们负责将产品经理的需求，翻译为 CC 能够理解的 Prompt ，然后验证它的实现，并保证代码的质量。

2）做一个理解业务和系统的人

目前 AI 轻松能写出优质的代码，那么我们代码无论写的多好，也会被那些使用 AI 编程工具的人比下去。所以对当前自己的业务理解程度和能设计出好的系统架构变得更加重要

3）持续学习，拥抱变化

唯一不变的就是变化，拥抱它

听完 Ilya 播客，AI 时代，拼的是快速学习（泛化）与品味（情绪）

Wed, 26 Nov 2025 17:50:52 GMT

谁是 Ilya Sutskever？

如果 AI 革命有一位精神领袖，那一定是 Ilya Sutskever。

作为 OpenAI 的联合创始人及前首席科学家，过去十五年深度学习历史上几乎所有里程碑事件的背后核心推手。从 2012 年引爆深度学习革命的 AlexNet，到战胜人类围棋冠军的 AlphaGo，再到开启大语言模型时代的 GPT 系列，Ilya 的一直走在最前面。

他不仅是工程天才，更是那个“看见未来”的人。在所有人都不看好神经网络的年代，他坚信扩展（Scaling）的力量；在 ChatGPT 席卷全球的时候，人们会觉得他会继续带着 ChatGPT 走向辉煌，他却选择急流勇退，创立了 SSI (Safe Superintelligence)，将目光投向了更遥远的终极目标——安全的超级智能。

听 Ilya 讲话，听到的不是商业路演，而是对智能本质的哲学审视。

当下的 AI 现状：繁荣下的隐忧

我们正处在一个奇特的节点。过去几年（2016-2024），被 Ilya 称为 “扩展时代”（Age of Scaling）。

在这段时间里，行业的主旋律简单而粗暴：堆算力、堆数据。只要把模型做得更大，即使不改变算法，奇迹也会发生。这种策略带来了 GPT-4 这样的惊艳成果，但也让整个行业陷入了一种思维定势——似乎只要再加一万张 H100，我们就能通往 AGI（通用人工智能）。

但是Ilya 让我们看到现在的 AI 现状充满了 “高分低能”的悖论。模型在各种学术基准测试（Evals）中早已超越人类，但在现实世界的经济活动中，它们的影响力却与之不成正比。

为什么一个能通过律师资格考试的 AI，却无法稳定地充当一个初级律师助理？为什么它能写出完美的代码片段，却在维护一个真实项目时漏洞百出？

这一切都在传递一个信号，“暴力美学”的边际效应正在递减，我们正在从“扩展时代”重回 “研究时代”（Age of Research）。因为单纯的“大”不再是答案，我们需要回头去解决更本质的问题。

一、拼的是快速学习：从“做题家”到“通才”

Ilya 在访谈中提出了一个非常精彩的类比，用来解释当前 AI 模型与理想智能之间的差距。

想象有两个学生：

学生 A（AI 现状）：为了在编程竞赛中拿第一，他练习了 10,000 个小时。他背下了所有的算法、所有的解题套路，见过所有的题型。他能极其快速且准确地解决问题。

学生 B（理想智能）：他只练习了 100 个小时，但他拥有某种“天赋”（It Factor）。他理解得更深，能举一反三。

谁在未来的职业生涯中会更成功？Ilya 毫不犹豫地选择了学生 B。

目前的 AI 模型就像学生 A。它们通过 Pre-training（预训练）见过了世界上几乎所有的数据，这种“大数定律”式的训练让它们看起来无所不知。但这种能力很大程度上是建立在海量记忆的基础上的。一旦遇到训练数据分布之外的新情况，它们的表现往往不如人意。

真正的智能，不在于你已经“知道”了多少，而在于你“学习”新事物的速度有多快。

Ilya 强调，人类的 样本效率（Sample Efficiency） 是极高的。一个青少年只需要 10 个小时就能学会开车，依靠的是在这个过程中不断的自我修正和对世界的理解，而不是预先在脑子里装入所有可能的路况。

因此，AI 发展的下一站，不是制造一个出厂时就精通所有工作的“全知全能神”，而是一个能够像人类一样通过“在岗学习”（Continual Learning）迅速掌握任何工作的“超级学习者”。

这给我的启示是： AI 时代，死记硬背的知识（Pre-training data）变得极其廉价。能否像那个只练了 100 小时的学生一样，拥有强大的泛化能力，快速适应全新的环境和规则，才是核心竞争力。

二、拼的是品味：情绪即最高效的“价值函数”

如果泛化能力决定了能不能“做对事”，那么品味和情绪则决定了什么是“对的事”。

在访谈中，Ilya 罕见地从机器学习的角度通过“价值函数”（Value Function）重新解构了 情绪（Emotion） 的作用。

他提到了一个神经科学的案例：一个因脑损伤而失去情感处理能力的人。这个人智商正常，逻辑清晰，但他完全无法做出决定——仅仅是决定早上穿哪双袜子，他都要花上几个小时去分析利弊。

没有情绪，就没有决策。

对于 AI 而言，目前的强化学习（RL）往往需要等到任务彻底结束才能得到反馈（Reward）。而人类的情绪就像是一个极其高效、鲁棒的实时价值函数。当你走入一条错误的死胡同，你不需要等到撞墙，你心中的“不舒服”、“焦虑”或“直觉”在几千步之前就会告诉你：路走错了。

这种对方向的感知，在科研和创造中被称为 “品味”（Taste） 。

当被问及他自己为何能连续做出 AlexNet、GPT-3 等划时代的研究时，Ilya 分享了他的 “研究品味” ：

美学与简洁（Beauty and Simplicity）：好的想法不容许丑陋。它必须是优雅的、简洁的。

生物学直觉（Biological Inspiration）：相信大脑的运作机制是最高级的参考。

Top-down 的信念：当实验数据与你的直觉相悖时，如果你对自己的理论有足够的审美自信，你不仅看数据，更看重那个“这必然行得通”的信念。

在 AI 甚至未来可能出现的超级智能（Super Intelligence）面前，逻辑推演的算力也许会变得普及，但这种基于生物本能、进化筛选出的“情绪指南针”和“审美直觉”，却是人类最难以被代码简单复制的护城河。

结语

Ilya 的 SSI 旨在直取超级智能，但他所描绘的未来并非冰冷的机器统治。

相反，这场对话提醒我们：在算力无限膨胀的时代，“少即是多”的智慧依然适用。像那个只学了 100 小时的学生一样，不拼题海战术，拼的是举一反三的灵性（泛化）；像艺术家一样思考科学，不拼数据的堆砌，拼的是直击本质的直觉（品味）。

这就是 AI 时代留给我们的终极命题：学会如何学习，以及学会如何去感受。

构建 AI Agent 最佳切入点 - vercel

Wed, 19 Nov 2025 13:16:49 GMT

这是一篇关于 Vercel 内部构建 AI Agent（智能体）的经验分享文章。以下为您呈现该文章的中文译文，力求保留原文的技术深度，同时符合中文读者的阅读习惯。

翻译官：Gemini 3 Pro

标题：我们在 Vercel 构建 Agent 过程中的经验教训

作者： Malte Ubl (CTO), Eric Dodds (Content Engineer)

发布时间： 2025年11月6日

AI Agent（智能体）在提升企业生产力和产出质量方面展现出了巨大的潜力。许多公司已经开始利用它们来优化客户支持、代码审查和销售运营流程。

在构建定制化的内部 Agent 时，真正的挑战不在于 AI 能否创造价值，而在于识别出它在当下真正能够解决的问题，并且成本在商业上是合理的。

在 Vercel，我们正经历着与客户相同的 AI 转型。我们利用自己的产品来构建 Agent，从而帮助我们跑得更快，并将更多时间投入到更有意义的工作中。

经过数月的实验，我们将所学到的经验总结成了一套可复制的方法论，用于发现和投资那些最有可能产生重大业务影响的 AI 项目。

寻找 Agent 的“甜蜜点”（Sweet Spot）

随着时间推移，AI 几乎会触及每一个工作流程，处理像我们自己的“代码审查”和“异常调查” Agent 那样复杂的任务。由于像这样的编码类 Agent 表现惊人，我们对 Agent 能力的直觉往往偏向于过高的期望。

然而，大多数公司并不具备将这种级别的内部用例“产品化”的工程能力，且当下的模型在其他领域的可靠性和精确度方面仍面临限制。因此，我们需要选择那些适合当下前沿模型能力的问题。

我们要分享的经验是：对于这一代 Agent AI 而言，成功率最高的领域是那些需要人类付出“低认知负荷”但又要进行“高重复性”操作的工作。

最佳切入点（Sweet Spot） = 低认知负荷 + 高重复性的人类工作

这些任务对于传统的自动化手段来说过于动态，但对于 AI 来说又足够可预测，能够可靠地处理。它们广泛存在于业务中的数据录入、调研、资格筛选和分类分流等环节。在这些环节中，自动化不仅能节省时间，还能保持质量的一致性。

这是我们当下应该摘取的“低垂果实”，与此同时，模型也在不断成熟，未来将能够可靠地自动化处理更复杂的任务。

我们寻找合适项目的方法论

这听起来可能很简单，但我们确实直接询问了团队，哪些任务符合这个“甜蜜点”：即那些通过频率很高的无脑操作。

人类天生不喜欢枯燥、重复的工作。因此，你通常可以通过询问这样的问题来发现绝佳的创意：“你工作中哪一部分是你最讨厌的？” 或者 “哪些任务是你希望永远不用再做的？”

我们发现的大多数用例，其自动化过程都相对简单，但在生产力方面却带来了高质量、可衡量的成果。以下是两个具体的例子：

案例一：销售线索处理 Agent (Lead Processing Agent)

我们过去有一个 10 人的团队，专门负责对通过网站进来的销售线索进行初步筛选（Triaging）。当我们问该团队表现最好的员工“希望永远不再做什么”时，他们告诉我们：为了做出初步的资格判断而手动搜索信息的过程简直令人麻木。

我们跟随（Shadow）了那位员工，学习了他们的处理流程，然后构建了一个 Agent 来自动化这一初步筛选过程。现在，1 个人就能处理过去 10 个人的工作量，而其余 9 名员工则专注于更高价值、更复杂的销售工作。

Agent 工作流如下：

深度调研： 对潜在客户及其公司进行全面的背景调查。
资格筛选： 使用 generateObject 对线索进行分类。
邮件撰写： 自动生成个性化的跟进邮件。
人工审查： 将所有信息发送到 Slack 供人工批准。
批准与发送： 捕捉 Slack 上的批准操作（Webhook 事件）并发送邮件。

案例二：反滥用 Agent (Anti-abuse Agent)

我们的安全团队需要管理源源不断的滥用报告，从钓鱼网站、垃圾信息到版权侵权应有尽有。我们需要认真对待每一个案例，因为误判可能导致错误下架，而漏判则可能让有害内容留在网上。

在自动化之前，人工审核员必须手动调查每一份报告，运行一套公式化的流程来做出初步判断。

我们构建了一个“滥用平台 Agent”，它能自动提取潜在的侵权或高风险 URL，运行视觉分析，理解页面意图，并返回建议的操作供人工验证。

即便在第一次迭代中，该工作流就将工单关闭时间缩短了 59%，从而解放了团队，让他们能够专注于那些需要更复杂人类推理的边缘案例。

Agent 工作流如下：

URL 摄取： 从滥用报告队列中检索新报告。
分析： 运行视觉/文本分析以检测钓鱼或版权内容。
建议： 汇总发现并提出行动计划。
人工审查： 将建议发送给安全工程师进行最终裁决。
解决： 记录决定并关闭工单。

利用我们的 Agent 模板开始行动

每个人都应该开始向自己的团队提出上述问题，但您也可以通过使用我们的 Agent 模板立即上手。

我们已经开源了一系列 Agent 示例，旨在作为构建自定义 Agent 的基石：

销售线索处理 Agent： 让 AI 完成繁琐的调研工作并进行初步筛选，然后通过“人机回环”（Human-in-the-loop）进行验证。
数据分析师 Agent： 将自然语言问题转化为 SQL 查询，并利用多阶段推理进行数据分析。
航班预订应用： 一个对话式的航班预订助手，内置了重试机制、断点续传和容错能力。
故事时间 Slackbot： 一个交互式的、由 AI 驱动的 Slack 机器人，可与您的组织成员共同创作儿童故事。

如果您的团队在寻找和构建高投资回报率（ROI）的 AI 项目方面需要更直接的支持，我们提供一项实践计划，由我们的前线工程师团队指导您完成用例发现和 Agent 实施。

面了几个实习生，真的挺难的现在

Wed, 12 Nov 2025 15:36:23 GMT

大家好，我是 luckySnail，最近面试了几个前端开发实习生，感觉现在的大学毕业生（即将毕业）挺难的，一方面是 AI 对编程行业的冲击比较大，基础开发岗位需求量极速缩减。另外一方面是目前的面试者看起来经历丰富，也有开发产品的经验，但你要是问的深一点就露馅了，回想到我实习那会，自己也是菜的不行，但我算是吃上了互联额行业最后的一点蛋糕，大家普遍对实习生要求不高。但现在已经是2025年了，招聘市场的要求已经高了好几个台阶。其实企业招聘也挺难的，招聘要求高了，也更难找到合适的人，毕竟没人天生就会，都是慢慢学会的

简历筛选

面的几个人，起步都是一本，还有一个研究生，简历里面的履历都很丰富，在看简历的时候我发现了几个有意思的点：

我发现大家都写自己有AI项目开发经验：RAG，prompt engineering ，function calling 等能力。我看到都倒吸一口凉气，现在真的太卷了～
有一个同学是有了很多实习经历，但里面写的都是自己的项目经历，这个很减分，后面说原因
有一个同学在专业技能里面写会使用很多AI编程工具
大家好像都不是很喜欢放项目链接上面其实都是我觉得不好的点，我觉得作为实习生基础和手写代码的能力才是最重要的。可以站在企业角度思考招实习生的目的，很多时候是希望自己培养好了转正的。所以你是不是潜力股很重要对于有实习经历的同学来说，你的项目经历应该就是在公司的项目，因为工作时间应该占据你90%的编程时间，你不展示公司的项目，偏偏展示自己剩下10%的时间做的东西。如果有想展示的，那就借着公司的项目讲出来。还有一点就是对于投递前端岗位，你说再多，我觉得都不如你展示你的作品，尤其是AI时代，作品代表你的实力，品味

面试感受

每次面试完，我都会写一个面评给leader 并给出一个结论，那么我就需要在有限时间内看到面试者是不是合适我们，在计算机基础，解决问题，项目开发，团队协作，编程等方面是不是及格。先分享一下我现在对面试的态度，我本身也很菜，不背八股的时候也是啥也不会，我就是带着我一点点的知识去向求职者学习讨教，希望是一次愉快的技术探讨，顺便把面试任务完成了。下面说一下我面试过程中的一些感受（纯主观的）

不要直接说不会：面试就是一次唠嗑，我问你一个问题就是开启一个话题，我刚开启说两句，你说不会就打断了，你说说你多不礼貌啊！体感很不好，感受不好了，后面就很难了！所以呀，千万别说不会，你可以说这方面不是很了解，但是讲一下你对这个问题的看法和解题思路，这顺便展示了你的思维逻辑能力，面对没有遇到过的问题临场能力
没准备好的，不了解的不要写：有好几个同学都是，对 AI 不是很了解，随便一个问题就能问出来，这是很减分的，还有就是你如果觉得可以写可以不写，就不要写，你觉得不太好的，更不要写，不能加分的，就是减肥的（简称：简历加分相对论，手动狗头）
基础真的很重要：每一场面试我都会问 Git 和让求职者实现一个todolist，但是没有一个同学做到很好，是的，一个简单的todolist 就能拦住90%的人，偷偷告诉你，有大厂的笔试题也是做todolist，这个能看出来你思考问题，解决问题方式，编码风格等等
面试官也很迷茫：其实我每次面试都是看简历里面写啥就讨论啥，所以你是有很大机会引导整个面试的流程和走向。展示你的强项，不要被发现弱项是你在这个游戏的任务之一
机会只有一次：面试过程中有一个同学很匹配，但是最后卡在了我们公司历史面试记录上，之前给的面评不好，就pass了，这真的非常可惜其实还有一个我觉得很加分的点，每次面试尾声的时候都会问有木有什么想要问我的，有一个同学问我他表现怎么样，有没有什么改进，我觉得这对实习生来说非常加分，并且我看到那个求职者还有在使用豆包在记录自己的面试过程，这说明他有总结反思的意识。

简单总结

求职找工作，看得是运气＋实力。缺一个都是地狱难度，我个人的经验是需要坚持才能找到合适的工作

以上内容，也是写给自己看的，换个角度看问题，很多问题和困惑也就解决了，感谢你的阅读，如果对你有帮助，点赞＋关注吧！谢谢，我们下期见～

在公司内部落地了我的第一个全栈项目，收获满满

Tue, 04 Nov 2025 11:45:59 GMT

大家好，我是 luckySnail ，上上周结束的时候，我的 leader 告诉我：下周把一个简单的前后端项目交给我来开发，我当时听到非常开心，虽然我自己有从 1 到 1 开发过前后端完整项目：SVG 秀，但是是这是个人的实验项目，相比较真实的企业环境下，真实的业务需求，还是有很大区别的。经过一周的时间，我在上周周四的晚上成功部署上线了第一版，周五进行了优化。目前服务稳定运行，想记录分享一下这次开发的过程和我的收获，希望对你有所帮助！

接手需求

leader 在交给我任务的时候，就把需求文档给我了！大致看了一下是一个简单的用户权限管理 + 问卷收集 + 标签使用管理的系统，可以说是最常见的管理系统，确认了业务流程后，我简单梳理了一下需求，方便我更快更好的开发

客户：

通过运营分享的链接，填写问卷

运营：

创建表单收集链接（携带自己的用户 id）
将客户填写的问卷完成，然后将状态扭转到财务
可以给问卷打标签

财务

根据问卷进行确认信息进行驳回（返回给运营），或者打款（完成）

管理员

可以查看这些所有信息
可以管理问卷，标签，用户

leader 说了，这个服务要集成在现有系统中，希望可以快速上线，目前现有的系统是前后端分离的，这个项目的前端是我来负责的，我可以很快接入。但是目前的后端是 fastify 并且已经是有复杂度的项目，我突然开发肯定是来不及了，因为熟悉项目规范什么都需要时间，刚好我的后端服务和当前项目后端的服务本身就可以分离，于是我心里已经想好了后端不会在当前后端服务里集成

技术选择

在企业的真实项目开发中，系统的稳定性是最重要的，所以在技术选择上，肯定是选择成熟，使用人多，并且自己能 cover 的住的技术，当然还有一点也很重要，那就是选择你所在公司使用的技术栈，我这次的开发也是基于上面综合决定了下面的技术栈：

supabase：因为我们的登录服务是依赖它，最近购买了他们的高级服务，但是很多资源都还没有使用，这次刚好发挥一下这个服务的价值，不能白花这个钱
honojs：极小的体积，能适配各种环境，原生的 typescript 支持，并且社区活跃，使用的人也很多

这里使用 supabase 提供数据库和数据库对应后端接口的能力，是完全能够实现我的需求的。下面简单介绍一下 supabase，它是开源 Firebase 的替代方案，它基于 PostgreSQL 构建，提供了一套完整的后端即服务（Backend-as-a-Service, BaaS）功能，帮助开发者快速构建全栈应用，而无需从零搭建后端。那它具体提供了什么呢？

实时数据库（Realtime Database）：基于 Pg 的逻辑复制和 WebSocket，支持监听数据变更
身份认证（Auth）：提供用户注册、登录、第三方登录（如 Google、GitHub）、密码重置等功能，支持 JWT 令牌和行级安全策略（RLS）。
存储（Storage） ：支持文件上传与管理（如图片、视频），权限可通过 RLS 控制，类似云存储服务。
自动生成 API：Supabase 会自动为你的数据库表生成 RESTful 和 GraphQL API
行级安全（Row Level Security, RLS） ：通过 Pg 原生的 RLS 机制，实现细粒度的数据访问控制，无需写额外的后端逻辑。
CLI 工具：提供了 supabase cli ，能更方便的进行 本地开发、调试和部署管理。将云端 Supabase 项目的能力带到本地环境，提升开发效率与一致性。尤其是数据库迁移部分，在团队协作和 CI/CD 上非常实用
开源 & 可自托管 ：Supabase 100% 开源（MIT 协议），支持在自己的服务器上部署再简单介绍一下 honojs ：是一个为边缘运行时（如 Cloudflare Workers、Deno、Bun 等）和 Node.js 设计的超轻量、高性能的 Web 框架，如果你想了解更多，可以去官方看文档

数据库设计

确定了技术，就可以开始进行数据库设计，把表创建好了，其实一半的代码也就写出来了！因为我们使用 supabase 服务，它会自动根据表生成对应的接口，有了表，对应的接口也就有了！下面是我借助 AI 设计的数据库：

表 1: user 表

create table public.user (
  id text not null,
  created_at timestamp with time zone not null,
  email text null,
  role public.userType null,
  is_banned text null,
  constraint user_pkey primary key (id),
  constraint user_email_key unique (email),
  constraint user_id_key unique (id)
) TABLESPACE pg_default;
表 2: tag 表

create table public.user (
  id text not null,
  created_at timestamp with time zone not null,
  email text null,
  role public.userType null,
  is_banned text null,
  constraint user_pkey primary key (id),
  constraint user_email_key unique (email),
  constraint user_id_key unique (id)
) TABLESPACE pg_default;

  表 3: payout_requests 表

create table public.payout_requests (
  id bigint generated by default as identity not null,
  created_at timestamp with time zone not null default now(),
  owner_operator_id uuid null,
  kol_account text null,
  real_name text null,
  pay_account text null,
  sfz_name text null,
  sfz_account text null,
  phone text null,
  pay_amount numeric null,
  form_source_id uuid null,
  tags json null,
  status public.payout_status null,
  notes text null,
  "isDelete" boolean not null default false,
  from_user_email text null,
  constraint payout_requests_pkey primary key (id),
  constraint payout_requests_id_key unique (id),
  constraint payout_requests_form_source_id_fkey foreign KEY (form_source_id) references auth.users (id) on update CASCADE on delete CASCADE,
  constraint payout_requests_owner_operator_id_fkey foreign KEY (owner_operator_id) references auth.users (id) on update CASCADE on delete CASCADE
) TABLESPACE pg_default;

这里我先在 supabase 后台创建了两个枚举：

userType：operations, finance, admin

payout_status： wait_sure, pendingPayment, paid, reject

其实这个数据库表设计和命名都存在问题，不知道你能发现多少？但是在我做的途中才知道的，为了保证准时上线，我打算先上线，还有一个原因是这个服务是服务内部，可能开发一次后面不用再管了，所以打算就暂时先这样

后端开发

有了数据库表，下面就可以进行后端开发了，其实是否使用 honojs 我还纠结了一会，理论上我完全可以使用 supabase 提供的能力完成需求，但是有两点让我不得不自己进行接口开发：

我对 supabase 不是很熟悉，害怕自己无法能在短时间实现需求
这个业务是希望国内用户可以调通后端服务的接口，但是 supabase 的服务国内肯定访问不了最终导致我打算自己使用 honojs 更快的进行接口开发，来提供后端接口服务。开发完成后可以将服务部署在任何位置首先就是参考： https://supabase.com/docs/guides/getting-started/quickstarts/hono 搭建出后端项目。搭建完成项目后，就启动 Codex，如果你在使用 Claude Code 或者 Cursor 也可以使用你自己的 AI 编程工具第一步：初始化项目和初始化数据库运行 codex 的 /init，生成 AGENT.md ，然后让AI 来帮我们安装 supabase CLI ，提示词如下：

参考 https://supabase.com/docs/guides/local-development ，文档，安装 supabase cli 到当前电脑
---
等待安装完成后 supabase --version 进行校验

然后我们使用 supabase 先连接上我们在线的 supabase 项目（这里你应该已经创建好你的项目了），然后进行初始化数据库，有了 CLI 之后我们就不需要在 web 端一个个创建数据库表，直接使用 CLI 生成即可，它还会生成对应的迁移记录，在 CI / CD 的时候这非常有用

# CLI 和你的在线项目关联起来 SUPABASE_URL：https://your_project_ref.supabase.co
supabase link --project-ref your_project_ref
# 验证连接成功
supabase status
# 初始化：会创建一个 supabase 文件夹，你的相关操作都会在这里进行记录
supabase init
# 创建一个新的迁移文件
supabase migration new init_tables
# 运行后，你会看到类似：
supabase/migrations/20251027_init_tables.sql
# 编辑迁移文件
也就是将上面的创建表语句放入迁移文件，这一步可以让 AI 帮你弄
# 同步迁移文件到云端，然后去 supabase 后台会看到你的三个表
supabase db push
# 这条命令会：
# - 检查 SQL 语法；
# - 在云端 Supabase 项目执行；
# - 自动记录迁移历史。
# 验证结果： supabase db pull。 会把最新数据库结构拉回来。

第二步：配置环境变量，并验证是否成功连接上 Supabase

# Get your keys at https://supabase.com/dashboard/project/_/settings/api
SUPABASE_URL=xxx
SUPABASE_ANON_KEY=xx
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

这个过程中，如果遇到任何报错，都可以问 Codex ,辅助修复 bug，初始化数据库后，对应的数据库接口也就有了！

我们可以看到对应的接口文档，下面就在本地使用 supabase 提供的包来开发对应的接口，首先创建一个 /user 接口，这个接口很简单，就是获取请求的鉴权信息，调 supabase 的 auth 服务，返回用户信息

 app.get('/user', async (c) => {
    const supabase = getSupabase(c);

    const { data: { user }, error } = await supabase.auth.getUser();

    if (error || !user) {
      return c.json({ message: 'Not logged in' }, 401);
    }

    return c.json({
      id: user.id,
      email: user.email,
      message: 'Logged in'
    });
  });

如果这个接口调通了，下面就可以让 AI 进行疯狂的接口开发了！所有接口大体逻辑基本相同，都是权限校验 => 数据处理 => 返回数据和状态，下面给一个示例的提示词：

现在开发payout_requests 表相关的接口，有增删改查，注意删除是逻辑删除，设置 isDelete 为 true，这个删除接口仅仅管理员可以使用，还需要开发一个状态修改接口，这个接口是所有角色都可以使用，创建接口是不需要登录即可调用，遵循 Restful 规范进行开发

基本上，都是这样的提示词，然后开发完成后进行代码校验 + 测试，等后端接口开发完成后，下面来开发前端

前端开发

根据需求，前端需要两个页面，一个是给客户使用的表单收集页面，另外一个是后台管理页面，给运营，财务和管理员使用。所以也是很简单，只需要关注权限校验正确即可，下面是让 AI 开发示例提示词：

基于当前的 payout_requests 表相关的接口 ，开发对应的页面，使用 ant design 的 list 组件展示数据，最后面有一列操作栏，展示：修改，删除，注意删除按钮仅仅运营和管理员可见，还需要一个设置状态的下拉框，状态枚举有三个值，你需要创建一个常量保持，并生成对应中文展示状态

和后端一样，我负责代码 review + 验证效果，这里需要注意的是，你需要告诉你的 AI 已经完成的后端代码，这样它才能够更好的工作

部署上线

当我们本地开发测试完成后，就可以上线我们的服务了！后端是 honojs 的服务，是可以轻松进行部署到 cloudflare，vercel 等平台。如果你要部署到自己的服务器也是非常简单，安装一个 node 环境即可。这里有一个需要注意的是，如果你是部署到 docker 上，需要使用 hono/adapter 来动态获取环境变量，并且需要在 docker 里面配置好对应的环境变量

小小总结

虽然这是一个不能再简单的项目。但是从接手到上线，还是学到了新的知识。例如：在数据库设计的时候 payout_requests 表的 tags 字段更合理的方式是新建一个关联表。

而且，当我在开发前端和后端的服务的时候，会更加了解什么事情应该在前端做，什么事情应该在后端去实现。

最后就是在开发过程中，我基本上都是作为一个需求下达，代码校验和结果验证的人，如果不是还需要 code review，我觉得我更像一个测试开发

另外我打算做一个 0 基础小白 AI 编程的教程。所以想调研一下，你是否了解 AI 编程，是否想将你的想法通过编程转为真实的产品

译：指令与平台边界 | TanStack 博客

Mon, 27 Oct 2025 15:40:16 GMT

指令与平台边界 | TanStack 博客
网址：https://tanstack.com/blog/directives-and-the-platform-boundary
发布时间：2025年10月24日
作者：Tanner Linsley
翻译官：Qwen 3 Max

JavaScript 生态中悄然兴起的趋势

多年来，JavaScript 仅有一个真正有意义的指令：“use strict”。它是标准化的，由运行时强制执行，并且在所有环境中行为一致。它代表了语言、引擎与开发者之间清晰的契约。

然而，如今我们正目睹一种新趋势的出现：各大框架开始发明自己的顶层指令。“use client”、“use server”、“use cache”、“use workflow”……这类指令正在整个生态中不断涌现。它们看起来像语言特性，出现在语言特性通常出现的位置，并影响代码的解析、打包和执行方式。

但关键区别在于：这些并非标准化的 JavaScript 特性。运行时并不理解它们，没有统一的规范加以约束，每个框架都可以自由定义其含义、规则和边界情况。

这种做法短期内或许显得便捷，但长期来看却会加剧混淆、增加调试难度，并给工具链和代码可移植性带来额外负担——这些正是我们过去已经历过的教训。

当指令看起来像平台特性，开发者就会把它当作平台特性

文件顶部的指令看起来极具权威性，给人一种“这是语言层面的事实”而非“框架提示”的印象。这种错觉会引发一系列问题：

开发者误以为这些指令是官方标准；
整个生态开始将它们视为共享的 API 表面；
新手难以区分 JavaScript 本身与框架的“魔法”；
平台与厂商之间的界限变得模糊；
调试体验下降，工具链不得不为这些行为做特殊处理。

我们已经看到这种混淆。许多开发者如今认为 “use client” 和 “use server” 就是现代 JavaScript 的工作方式，却不知道它们仅在特定构建流程和服务器组件语义下才有效。这种误解揭示了一个更深层次的问题。

功劳归功：use server 与 use client

某些指令之所以存在，是因为多个工具需要一个简单、统一的协调点。实践中，“use server” 和 “use client” 是一种务实的垫片（shim），用于在 React Server Components（RSC）环境中告知打包器和运行时代码允许在何处执行。正因为其作用范围明确（仅限执行位置），它们在多个打包工具中获得了相对广泛的支持。

即便如此，一旦面对真实世界的复杂需求，这些指令的局限性也很快显现。在大规模应用中，我们往往需要与正确性及安全性密切相关的参数和策略：HTTP 方法、请求头、中间件、认证上下文、追踪信息、缓存行为等。而指令本身并没有自然的方式来承载这些选项，导致这些信息常常被忽略、另作处理，或通过衍生出新的指令变体来重新编码。

指令开始力不从心：选项与“指令周边”API

当一个指令在创建后不久就需要配置选项，或催生出类似 “use cache:remote ” 的兄弟指令，以及像 cacheLife(...) 这样的辅助函数时，这通常意味着该功能本应是一个 API，而不是文件顶部的一行字符串。既然你终究需要一个函数，那就干脆全部用函数来实现。

例如：

"use cache:remote";
const fn = () => "value";

对比显式、带来源和选项的 API：

// 显式 API，具备来源和配置选项
import { cache } from "next/cache";
export const fn = cache(() => "value", {
  strategy: "remote",
  ttl: 60,
});

对于需要详细配置的服务器行为：

import { server } from "@acme/runtime";

export const action = server(
  async (req) => {
    return new Response("ok");
  },
  {
    method: "POST",
    headers: { "x-foo": "bar" },
    middleware: [requireAuth()],
  },
);

API 具备来源（通过 import）、版本控制（通过包管理）、组合能力（通过函数）和可测试性。而指令通常不具备这些特性，强行将选项编码进指令中，往往会成为一种设计上的“异味”。

共享语法却无共享规范，可能成为脆弱的基础

一旦多个框架开始采用指令，我们就陷入了最糟糕的局面：

类别	共享语法	共享契约	结果
ECMAScript	✅	✅	稳定且通用
框架 API	❌	❌	隔离但无害
框架指令	✅	❌	混乱且不稳定

缺乏统一定义的共享语法会导致：

语义漂移：每个框架自行定义语义；
可移植性问题：代码看似通用，实则不然；
工具链负担：打包器、linter 和 IDE 必须猜测或追踪行为；
平台摩擦：标准组织被生态预期“绑架”，难以推进规范。

我们此前在装饰器（decorators）上就经历过类似困境：TypeScript 推广了一套非标准语义，社区广泛采用，但 TC39 最终选择了不同方向，导致许多人至今仍在痛苦地迁移。

“这不就是换个语法的 Babel 插件或宏吗？”

功能上，确实如此。指令和自定义转换都能在编译时改变行为。问题不在于能力，而在于表层形式和观感。

指令看起来像平台特性：无需 import，没有明确归属，没有显式来源，给人一种“这就是 JavaScript”的错觉。
API/宏则指向明确的所有者：import 提供了来源、版本和可发现性。

最理想情况下，指令相当于在文件顶部调用一个全局、无 import 的函数，比如 window.useCache()。这正是其风险所在：它隐藏了提供方，将框架语义伪装成语言本身。

例如：

"use cache";
const fn = () => "value";

对比显式 API：

// 显式 API（可追踪、可归属、可发现）
import { createServerFn } from "@acme/runtime";
export const fn = createServerFn(() => "value");

或全局“魔法”：

// 全局魔法（无 import，提供方隐藏）
window.useCache();
const fn = () => "value";

为何这很重要？

归属与来源：import 告诉你谁提供了该行为，指令则没有；
工具链友好性：API 存在于包空间中，指令则需要整个生态做特殊处理；
可移植性与迁移成本：替换一个 import 的 API 很简单，而清理散布在文件中的指令语义则代价高昂且模糊；
教育与预期管理：指令模糊了平台边界，而 API 则让边界清晰可见。

因此，尽管 Babel 插件或宏可以实现相同功能，但基于 import 的 API 能清晰地将其保留在“框架空间”内。而指令则将相同行为移入“语言空间”的假象中——这正是本文的核心关切。

“加命名空间能解决吗？”（例如 “use next.js cache”）

命名空间有助于人类识别，但无法解决根本问题：

它仍然看起来像平台特性：顶层字符串字面量暗示这是语言，而非库；
它仍缺乏模块级别的来源和版本信息：import 能编码这两者，字符串不能；
它仍需工具链（打包器、linter、IDE）特殊处理，而非利用标准的 import 解析机制；
它仍会推动无规范的“伪标准化”，只是加了厂商前缀；
它相比替换 import API，迁移成本更高。

例如：

"use next.js cache";
const fn = () => "value";

对比显式 API：

// 显式、可归属的 API，具备来源和版本控制
import { cache } from "next/cache";
export const fn = cache(() => "value");

如果目标是明确来源，import 已经提供了干净的解决方案，并与现有生态兼容。如果目标是跨框架的共享原语，那就需要真正的规范，而不是看起来像语法的厂商字符串。

指令可能引发竞争性动态

一旦指令成为竞争焦点，激励机制就会改变：

某厂商推出新指令；
它成为显性功能；
开发者期望处处可用；
其他框架被迫跟进；
语法在无规范的情况下扩散。

于是我们看到：

'use server'
'use client'
'use cache'
'use cache:remote'
'use workflow'
'use streaming'
'use edge'

甚至连持久化任务、缓存策略和执行位置等运行时语义，都被编码为指令。这些本应属于能力模型，而非语法模型。将它们编码为指令，等于在标准流程之外设定方向，值得警惕。

对于需要丰富选项的功能，应优先考虑 API 而非指令

持久化执行（如 “use workflow”、“use step”）就是一个典型例子，但原则具有普适性：指令只能将行为简化为布尔值，而许多功能需要选项和演进空间。编译器和转换工具可以支持任一形式；关键在于为长期清晰性和可维护性选择合适的形式。

例如：

'use workflow'
'use step'

替代方案：使用带来源和选项的显式 API：

import { workflow, step } from "@workflows/workflow";

export const sendEmail = workflow(
  async (input) => {
    /* ... */
  },
  { retries: 3, timeout: "1m" },
);

export const handle = step(
  "fetchUser",
  async () => {
    /* ... */
  },
  { cache: 60 },
);

函数形式同样便于 AST 分析和编译器转换，同时具备来源（import）和类型安全。

另一种方案是注入一次全局对象并为其添加类型：

// 一次性初始化
globalThis.workflow = createWorkflow();
// 全局类型声明（如 global.d.ts）
declare global {
  var workflow: typeof import('@workflows/workflow').workflow
}

使用时仍保持 API 形态，无需指令：

export const task = workflow(
  async () => {
    /* ... */
  },
  { retries: 5 },
);

用编译器来提升开发者体验当然是好事——JSX 就是一个成功的例子！但我们必须谨慎负责：通过具备明确来源和类型的 API 来扩展，而非使用看起来像语言本身的顶层字符串。这些是建议，而非教条。

隐性的锁定效应可能悄然形成

即使没有恶意，指令在设计上就容易造成锁定：

认知锁定：开发者对某厂商的指令语义形成肌肉记忆；
工具链锁定：IDE、打包器和编译器必须针对特定运行时；
代码锁定：指令位于语法层面，移除或迁移成本高昂。

指令或许看起来不像专有功能，但它们对生态语法的重塑，使其比普通 API 更具“专有性”。

若真想共建共享原语，就应协作制定规范和 API

我们确实面临真实问题需要解决：

服务器执行边界
流式传输与异步工作流
分布式运行时原语
持久化任务
缓存语义

但这些问题应通过 API、能力模型和未来标准 来解决，而非通过打包器推动的、无规范约束的“伪语法”。

如果多个框架真心希望共建共享原语，负责任的做法是：

跨框架协作制定规范；
在适当时机向 TC39 提案；
将非标准功能明确限定在 API 空间，而非语言空间。

指令应稀有、稳定、标准化，并谨慎使用，而非在各厂商间泛滥成灾。

为何这与 JSX/虚拟 DOM 时代不同

有人可能会将对指令的批评，类比于早期对 React JSX 或虚拟 DOM 的质疑。但两者的失败模式截然不同。JSX 和 VDOM 从未伪装成语言特性——它们始终伴随显式 import、明确来源和清晰的工具边界。而指令则位于文件顶层，外观酷似平台特性，却在缺乏共享规范的情况下制造了生态预期和工具负担。

总结

框架指令今天或许带来“开发者体验魔法”，但当前趋势可能导向一个更加碎片化的未来——生态将被工具定义的“方言”割裂，而非由标准统一。

我们可以追求更清晰的边界。

框架当然应该创新，但也应明确区分框架行为与平台语义，而非为了短期采用率模糊这条界限。清晰的边界，才能让整个生态受益。

Next.js 16 来了！对 AI 最友好的开发框架

Thu, 23 Oct 2025 17:31:03 GMT

大家好，我是 luckySnail ，Next.js 16 终于来了！我第一次使用 Next.js 是 12 版本，那时候还是使用 Pages Router ，对于 Next.js 我是又爱又恨，一方面它拥有及其丰富的社区生态，一方面它的开发体验不好和发布速度太快，并且存在很多 bug。作为一个普通的开发者，我希望要的是一个稳定，好用，开发构建部署体验好的框架，Next.js 是不二之选，但是 Next.js 在很多地方做的不够好，也促使社区有了 TanStack Start ，Modernjs 这样的竞争者。

Next.js 和 AI

这次更新最让我眼前一亮的就是它与 AI 的深度结合，在 Conf 大会上，Next.js 说如果一个 API 设计的让人困惑，那么肯定也会让 AI 困惑，隐藏让开发者体验越好，对大模型也越友好，首先就是 Next.js 发布了 Next Evals ，这是什么呢？这是一个公共基准测试，让我们知道最新的模型和编码 Agent 在使用 Next.js 时候的表现，得分高的就是能按照 Next.js 最佳实践来开发的 Agent 可以看到 gpt-5-codex 得分最高！这里顺带说一下，目前 gpt-5-codex 是我使用最多的大模型，它的编程能力太强～如果你还没有用上那真的太可惜了～

接着就是 Turbopack ，它已经替代 Webpack 成为默认的打包构建工具，在 Agent 循环中，时间都很重要。Turbopack 的毫秒级的快速刷新对于 Agent 自动编写、测试和发布代码的场景是很重要的，将 Agent 循环的速度提高上千倍，我们也能更加流畅的使用 Codex 这种 AI Agent 工具

下面是我觉得最棒的点，也是 Next.js 被社区诟病的点，当我们使用大模型开发 Next.js 的时候，总是得到过时的资料，于是推出了 next-devtools-mcp: https://www.npmjs.com/package/next-devtools-mcp ,我们可以文档知道它能帮我访问最新的文档，最佳实践，并且进行测试和内部调试，下面看一下我在 Claude Code 中使用这个 MCP 一次就开发出了对应的 API 服务和页面：下面是进行技术调研：

可以看到 AI 能借助 next-devtools 很好的完成工作 👍

下面就是一些小细节，当我们在开发过程中遇到报错，可以看到有一个复制错误的按钮，我们可以很方便的将其复制给 AI Agent 然后帮我分析解决 bug

开发者体验

开发过 Next.js 都知道因为服务端组件和客户端组件水和的原因导致导航速度慢是非常严重并且不被理解的问题，但是我发现，在 next.js 16 好像得到了解决或者说是缓解。除了导航慢，Next.js 的报错没人能看得懂也是非常严重的问题，但是现在有了更友好的提示和 AI 的加持，让我们可以轻松的修复 bug，下面就是我在开发中遇到一个无法看得懂的 bug，AI 借助 MCP 快速进行了修复：

复杂的缓存

如果让我说 Next.js 中最难的应该是客户端组件和服务器组件及其它带来的各种渲染模式（SSG、SSR、ISR、PPR、RSC），那最复杂的应该就属缓存了！虽然缓存是编程的一大难点，但是 Next.js 真的是让我更加深刻知道了缓存是多么的复杂。对于缓存这部分，我觉得可以先不学，而是干中学，有一个基本概念就好。因为这部分内容，next.js更新快，并且都是破坏性更新，所以记住了，等版本更新后，又得重新学， 16 版本缓存有：

Request Memoization（请求记忆）：同一次服务端渲染树内，相同 fetch(url, opts) 只会真正执行一次，后续命中内存结果（仅本次请求生命周期内有效）
Data Cache（数据缓存）：服务端的缓存，用于缓存 fetch 请求的结果。
Full Route Cache（整路由缓存）：静态渲染得到的 HTML + RSC payload 会被缓存
Client-side Router Cache（客户端路由缓存）：浏览器内存里的 RSC 片段缓存，结合 <Link> 预取，可以实现瞬时的回退/前进与保留共享布局状态。可通过 router.refresh() 失效。

具体看： https://nextjs.org/docs/app/guides/caching#overview 。next.js 除了缓存的概念多，而且实际开发中也不好调试，并且上线后更难追踪是不是缓存的问题

总结

Next.js 16 的到来，总体来说对 Next.js 开发者来说是好事，并且让我看到了未来在技术选择中，是否对 AI 友好将会成为关键点。并且让我看到了技术没有银弹，选择合适的技术栈，让手里的技术更快开发出产品，创造出价值才是正解。

如果你问我用不用 Next.js ，我觉得如果有 SEO 要求，那么可以使用，否则还是 TanStack Start 更好！

参考

nextjs 16 blog： https://nextjs.org/blog/next-16
nextjs conf 2025： https://www.youtube.com/watch?v=IdIgkiDu-94&t=10s

再见 Cursor，我有了新的编程搭子！

Thu, 02 Oct 2025 13:33:12 GMT

从 2023 年 Cursor 正式发布，我就开始使用它，到现在已经两年多了！Cursor 通过 Tab 能力出圈，凭借着 Agent 能力让我成功抛弃了 VSCode ，但是我现在要抛弃 Cursor 了！因为它最近的付费策略越来越严苛，所有都是按量付费，并且消耗的极快，根本都不顶用，让我在开发中不断的担心额度被消耗完

从业界良心到被社区抛弃

在很长一段时间里，Cursor Pro 的定价策略堪称业界良心：每月20美元，用户可以获得大约500次快速请求（通常指调用GPT-4等前沿模型），以及不限次数的较慢请求。这个模式清晰、透明，让我们可以毫无顾虑地将AI融入到日常开发的每一个环节。它不仅仅是一个工具，更像是一个不知疲倦、随时待命的编程伙伴。

然而，一切都在2025年6月16日这一天改变了。Cursor 团队宣布了一项重大的定价模式改革。他们将原有的“请求次数”模式，替换为一个基于美元额度的“使用量池”模型。新的Pro套餐虽然名义上仍是20美元/月，但其中只包含了价值20美元的“前沿模型”使用额度

虽然我知道 Cursor 是因为无法承担巨额的 API 成本，但是作为普通用户，我感觉自己被欺骗，Cursor 夺走了原本属于我的权益，虽然 Cursor 的 Tab 功能目前没有任何产品可以替代，但是这个无法说服我为了 auto tab 为它每月支付 20 刀，最重要的是当我使用过其他 AI 编程工具，再来看 Cursor 目前的 Agent 的输出效果，根本都不在一个 level，所以再见👋 吧！

我的新 Vibe Coding 搭子

下面分享我的新 Vibe Coding 组合，我觉得是目前普通开发者的最佳选择：

ChatGPT Plus
- Codex 轻量版额度，省着点用是够用的
- Codex 云端编程，简单工作必选，使用体验拉满，我觉得是未来编程的范式
Warp ：将多个大模型集成在更现代化的终端里面，支持类似原生代码编辑器的编辑体验
VSCode：总是需要编程工具的，VSCode 还是不二之选，Zed 我也使用一段时间，但是感觉还是不成熟
Claude Code + GLM-4.6 ：智谱最近发布的大模型非常厉害，非常快，接入在 Claude 使用真的很流畅
Neovate：当我需要使用多种模型，调试各种模型的输出效果的时候，我会使用它，很好用！最后再分享我最近在使用的好用的 MCP：

chrome-devtools：Google 官方发布的为 Coding Agent 提供对 Chrome 浏览器的直接控制能力，支持调试网页、检查 DOM、监听网络请求、查看 Console 日志、性能剖析等
playwright：微软维护的 Playwright 浏览器自动化框架的 MCP 扩展。在 MCP 环境里调用 Playwright API 来自动化浏览器操作，比如点击、输入、截图、导航等。可以进行端到端测试（E2E testing）、网页爬取（scraping）、UI 自动化验证。
context7：为 AI 编程助手提供最新、最准确的代码文档
Figma：通过 MCP 直接访问 Figma 文件、组件、设计稿的结构信息，然后将其转为代码

感谢你的阅读，如果你有什么好用的 Vibe Coding 技巧，好用的 AI 编程工具，欢迎分享！

哦对了！国庆快乐！

一分钟带你将 DeepSeek-V3.1-Terminus 接入Claude Code 和 Codex

Wed, 24 Sep 2025 07:10:54 GMT

就在最近， DeepSeek 发布了 V3 版本的终极版，刚好最近使用 Claude Code 和 Codex 总是被限速，下面跟着我快速将最新的 DeepSeek 接入 cc 和 Codex 吧！

接入 Claude Code

1️⃣ 全局安装

npm install -g @anthropic-ai/claude-code

2️⃣ 配置环境变量先去 DeepSeek 官方 API 后台生成一个 API key 然后在控制台配置

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=你的DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-chat
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat

3️⃣ 测试使用运行 claude 启动，然后我们可以看到如下：这就代表成功啦！🎉

Codex

Codex 是 OpenAI 家的终端 Coding Agent Cli ，和 Claude Code 差不多

1️⃣ 安装

npm install -g @openai/codex

2️⃣ 配置

# 定义一个 DeepSeek 提供方（OpenAI 兼容）
[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
wire_api = "chat"
env_key = "DEEPSEEK_API_KEY"

[profiles.deepseek-chat]
model_provider = "deepseek"
model = "deepseek-chat"

3️⃣ 测试使用

export DEEPSEEK_API_KEY="sk-xxx"
codex --profile deepseek-chat

看到下面就代表成功啦！

参考

claude code 官方文档： https://claude.com/product/claude-code
codex 官方文档： https://developers.openai.com/codex/cli/

拆巨资让 Claude Code 和 Codex 同时住进了我的终端里

Sat, 06 Sep 2025 16:03:39 GMT

大家好，我是 luckySnail，已经和 Claude Code 结伴编程将近半年，深刻感受到终端里的 AI Agent 的强大之处，同时也更加坚定我要不断体验最新的 AI 编程产品。这不最近 chatGPT 5 发布，社区里很多人分享了 Codex 已经不输 Claude Code。看着大伙都使用上了，心里也是很着急，于是就使用这月的零花钱直接订阅了 chatGPT 和 Claude Code，我这里买的第三方服务，是共享 chatGPT pro 和 Claude Code Max 20x 。也就是当前最贵的两档大模型会员。

无论是我个人的使用，还是社区大佬的分享，都承认了一个事实就是：AI 目前写代码的能力已经超过了 99% 开发者！注意这里说是写代码的能力，基于这个认知，让我们看看当下最强大的 AI 的编程能力

实战经验

目前我已经使用 Claude Code 几千刀 token 了！下面分享我使用过程中，总结的一些实用经验！如果你还没有体验过 AI Agent CLI 工具，可以看我上一篇文章：[使用两个月的 Claude Code ，总结下我的最佳实践](https://mp.weixin.qq.com/s/8oHjqqxHOLwSdeF71Gr30A)

常用话术

如果把 claude code 和 codex 当做招聘来的两个实习生，那给这两个实习生交代工作肯定是花点心思能得到更好的效果，对于 claude code：

引导使用 todo：在 prompt 中告诉它制定 todo 进行实施
引导深入思考：在 prompt 中添加 ultrathink

对于 Codex：

使用更宽泛的话术：codex 在系统设计和解决难题上比较厉害，这里不告诉它具体如何实现，让它自己去实现，有时候能得到更好的结果
引导它如何工作：例如：使用网络搜索工具进行搜索；使用 git 命令进行查看暂存区代码；不要运行 pnpm lint 进行校验效果；等等

除了上面，还可以参考官方教程：

读代码和查找代码的神器

日常开发中，70% 的需求基本上都是基于已有的代码基础上进行添加，修改。那么先理解当前的逻辑是至关重要的，不先熟悉已有的逻辑，直接开发很容易导致历史逻辑出现问题！这时候，可以在自己阅读前，先询问 AI 相关代码的逻辑，数据流等等问题。对模块先有大致了解，然后再开始阅读源码，我自己感觉是极大的提高了我的效率

除了读代码，查找 xx 功能的实现代码位置也是很高频的需求，正常情况下，我们需要先通过路由或者其他方式找到相关的位置，然后继续找到想要看的代码部分，但是现在直接询问 AI ，它能快速精准找到对应的代码位置，比自己找快多了！而且它还会向你解释对应的代码

bug 修复神器

claude code 和 codex 目前最擅长的估计就是 fix bug 了，在提供精准的报错信息和对应代码上下文后，90% 它们都可以顺利修复 bug，如果 claude code 修复不了，那就 codex 来，他俩总有一个能解决问题

让 claude code 和 codex 合作

很多时候，claude code 会突然变傻，解决不了遇到的问题，codex 也是一样，例如：当我让 codex 修复一个导入问题，它结果使用 python 进行代码重构：

然后我把问题交给 claude code，它很快就帮我修复了问题：

结合强大的 Git

Git 是很强大的代码管理工具，在使用 claude code 和 codex 这种工具的时候它变得比其他时候更加重要，我日常使用会每一次提问前都保证先把代码存入暂存区，保证工作目录是空的，这样方便查看本次 AI 做了哪些改动，并且还可以让 AI 快速进行代码 review：“检查当前工作目录的代码是否有问题？”。并且每次都可以提交一个 commit ，这样也方便快速回退

互相 review 代码

当我使用 Claude Code 开发完成一个能力后，我会让 Codex 来 review 暂存区的代码，让其给出一些意见，这样能极大的减少 bug 的产生，下面是我的提示词：

使用 Git 查看当前暂存区的代码，根据 [Google code review guide](https://google.github.io/eng-practices/review/reviewer/standard.html) 来 review code 指出代码的问题并给出建议

随着 AI 越来越多代替我们写代码，代码 review 能力也变得越好越重要了！不知道如何 review ，可以看 Google code review guide

让 AI 进行逆向分析源码

目前客户端代码基本上都是通过混淆和压缩来保证源码不被泄露，但是有了 claude code 后，直接在压缩代码文件里面打开 claude code 或者 codex ，然后直接询问：“解析源码，帮我找到所有关于 xxx 的代码，查看 xxx 能力是如何实现的，并给出对应逆向的 js 实现源码”

为窗口设置别名

VSCode 或者 Cursor 是可以为窗口创建别名的，很多时候，我们需要打开多个对话窗口，或者同时问 Claude Code 和 Codex ，这时候为窗口命名能够让我们快速找到对应的窗口

做减法变得很重要

AI 返回的内容总是更多的，并且会做一些不需要的能力，但是代码肯定是越少越好，每一行多余的代码都会增加系统复杂度和维护成本，所以在 AI 生成结果之后，我一般会将它添加的多余的代码都删掉，AI 经常犯的错误如下：

系统已经有的能力，但是 AI 不知道，它又重复写了一个
可以基于当前已有的逻辑进行开发，但是它从 0 开发
可以抽离为公共方法，逻辑的地方，它写在了业务逻辑里面

定期更新文档

claude code 和 codex 都有 /init 命令，它会生成一个项目开发指导文档（CLAUDE.md 、 AGENTS.md），然后会在接下来每一次对话都带上这个上下文。所以非常重要的一点是，如果有开发全局的能力，那么就需要及时更新对应的指导文档，要不然还是使用就的指导文档作为上下文进行回答就会不准确

MCP

之前一直觉得 MCP 没有什么作用，但是最近团队同事强烈推荐 context7 这个 MCP，我抱着怀疑的态度使用了一下，就再也离不了了！这是一个能够让你的大模型能够访问到最新代码文档的工具。因为日常 AI 在回答的时候经常会给出旧的代码，从而导致一些问题，但是使用这个 MCP 后它会自动搜索最新的文档资料作为上下文，来保证返回代码是最新的实现方式，使用方法也很简单，在 prompt 中添加上：使用 context 7 访问 xxx 最新官方文档，参考对应的文档进行开发。关于如何使用更详细，查看文档：https://github.com/upstash/context7

claude code VS codex

现在让我们总结对比一下这两款终端 CLI 工具，目前无论从使用体验还是功能支持上 claude code 都是更胜一筹，但是 codex 目前在解决问题方面已经不输 claude code。所以对于有条件的，两个都订阅一下，在 claude code 解决不了问题的时候可以尝试一下 codex 。如果你需要服务，可以联系我

让我们下次见

不知不觉已经使用 Claude Code 1000 + 刀了，虽然跟刘小排那种一天 1000 刀的没法比，但是它真的物超所值，如果让我分享如何进行 AI Coding，秘诀可能只有一个，那就是先用起来吧！就像吕子乔经典语录说的一样：“管他呢！上去啊！火车是朝前开的，去哪不重要，重要的是窗外的风景。”

没写一行代码，让_AI_给我做了一个翻译神器

Wed, 27 Aug 2025 16:16:07 GMT

由于英语很差劲，所以一直都是谷歌翻译的深度用户，但是看到 AI 翻译的内容和谷歌翻译的对比后，我发现谷歌的机器翻译真的太差劲了！真的是由俭入奢易，由奢入俭难。干脆让 AI 快速 vibe coding 一个吧！说干就干！因为是谷歌翻译的深度用户，UI 直接借鉴它的就好！不过市面上的翻译工具都长一个样吧！

对了，没时间看，那就直接去使用吧！https://congcong.easykol.com/

我的需求也很简单，既想要谷歌翻译的快速，也想要 AI 翻译的精准，并且有时候我还想知道它为什么这样翻译，有时候也觉得它翻译的不好想继续追问一下！

有了需求后，就把需求发给 AI，不到一会 AI 就给我一个初稿，微调一下后就得到了我自己的“谷歌翻译”，它长这样：

简单，干净，那到底好不好用呢? 让我们来试一下：

下面是 AI 翻译的：

感觉不好，我们还可以继续追问：

除了上面的能力，最值得一提的就是可以自己定义 prompt 了！

设置一次，永久享用！再也不要每次提问都带上预设，麻烦还浪费时间

虽然是一个很简单的工具，但是真的是我每天都要用的，现在用上我自己的，真的帮我省了很多时间，并且还顺带在翻译的时候学习了英语的表达！一句多得

结语

当前，目前还有一些可以优化的点，例如

使用好看的字体
接入好听的朗读
自定义翻译模型
查看历史记录

等等，但是这样都是锦上添花的事情！目前已经满足了我的核心诉求，欢迎大家使用反馈，感谢你的阅读，顺手点赞，好运常伴，那我们下次见！

使用两个月的 Claude Code ，总结下我的最佳实践

Sun, 20 Jul 2025 08:59:20 GMT

大家好，我是 luckySnail，已经使用 Claude Code 两个多月了！感谢公司的支持，让我用上了目前编程最强的工具，有了 Claude Code 后，我的开发效率真的翻倍了！Claude Code 是一款集成在终端的编程助手（CLI 工具），使用了 Anthropic 公司自家最强的 sonnet 4 和 Opus 4 大模型。下面让我们一起来看看如何使用它！我会按照下面顺序介绍，让你快速入门 Claude Code：

如何安装
基础入门
进阶使用
项目实战经验
总结和参考资料

安装

你需要安装 nodejs > 18

# install
npm i -g @anthropic-ai/claude-code
# valid install
claude -v

如果输出版本号，就代表安装成功了！下面进行使用（需要自己备好工具，否则运行 claude 会报错 403）

基础入门

你可以把 claude code 当做你终端中的 AI 编程助手，使用它的方式是进入到你的项目下，或者新建一个项目文件夹，然后进入终端输入（当你第一次输入 claude 的时候，它会安装对应的插件，更好的进行辅助编程）：

claude
# 你也可以输入 claude xxx ，就是：claude [prompt] - 直接发送提示词给 Claude

下面来看看这个 CLI 工具常用的命令：

update：更新 claude cli 到最新
mcp：配置管理 MCP 服务
--dangerously-skip-permissions：自动确认，不会在执行一些命令的时候进行确认提示，适合执行长时间任务的时候启用，但是是一个危险操作
--add-dir <directories...> - 添加允许工具访问的额外目录
-c, --continue - 继续最近的对话
-r, --resume [sessionId] - 恢复对话 - 可提供会话 ID 或交互式选择要恢复的对话

当我们启动 claude 后也有很多命令和快捷键可以使用：

# 退出当前执行，当我们执行一个命令的时候希望终止，可以使用它
ESC
# 退出 Claude Code
command + c (两次)
# 初始化项目，建立项目索引，生成 CLAUDE.md
/init
# 引用文件 (@ + 文件名)，将当前文件添加到上下文
@xxx
# 添加记忆 ，输入 # 然后添加你的记忆内容，可以配置为项目 /  用户记忆
`# xxx`
# 清除上下文
/clear
# 压缩上下文
/compact
# claude 配置，可以配置主题，是否使用 to-dolist，是否提示，使用大模型选择等等
/config
# 查看花费
/cost
# 查看状态，包含版本，模型，工作目录，
/status

进阶用法

# 管理 MCP
/mcp
# 管理记忆
/memory
#  Hooks（钩子）系统，允许您在 Claude Code 处理过程中的特定时刻执行自定义的 shell 命令。
/hooks
# 恢复对话
/resume
# 配置别名
alias cc="claude --dangerously-skip-permissions"

项目实战经验

下面是我使用 Claude Code（简称 cc）在生产开发中的一些经验！

cc 启动的时候会提示安装对应的编辑器插件，安装后 cc 会感知到当前打开的目录，快速将上下文加入的 cc，还能直接在代码中查看变更
放心使用 claude —dangerously-skip-permissions ，因为 cc 再安全方面做了很大的努力
每完成一个小的需求后，都应该提交一次 Git，准确来说应该每结束一次对话，都要将变更存储到 Git 暂存区，保证工作区干净，这样当 cc 的更新不对，我们可以很快回退
review code：cc 有很强的 Git 能力，我们可以让他使用 Git diff 来进行代码检查
复杂需求拆解确认再开发，虽然 cc 有 todo 的能力，但是它会制定 todo 就执行 todo，这在复杂需求的时候不适用，复杂需求可以让他先制定计划找我确认沟通再进行下一步，这大大减少方向错误导致的问题
搜索网络和深度思考，告诉它进行搜索网络，它会先去搜索资料。末尾加上 ultrathink 它会深度思考
启动多个子任务并行，cc 是有能力自己并行启动多个 subagents 的，不用第三方工具，只需要加个咒语：YOU MUST use subagents in parallel to speed up the progress.
清除上下文，很多时候，我们提问的新的问题和之前没有联系，这时候应该运行 /clear 来清除上下文，否认目前的上下文可能会影响新的问题的回答结果，没一个新的问题都应该清除上下文或者创建新的对话
如果 cc 两次做不好的事情，就不要再让它来了，自己动手做吧！
cc 有很好的记忆系统，如果你要什么需要针对项目或者对所有项目的规则，你都可以使用 /memory 记录
cc 不仅是帮你更好的完成工作，在帮助学习方面上也是非常的实用，除了学习，你还可以脑洞大开的让他帮你整理文件夹，搜索网络内容并整理，写文章等等
npx ccusage 能让你看到你使用量，从而知道你是不是亏了！对了，尽可能使用 Opus 来获取最佳开发体验

总之，cc 是一个强大的 CLI 工具，能够调用超多命令来帮助它完成各种任务。在我看来它更像是一个武林高手，适合解决比较困难的问题，简单的问题可以使用 Cursor，通过 Cursor 的流畅 Tab 能力 + Claude Code 强大的复杂问题解决能力，能够极大提高我们的开发效率。随着大模型能力提升，AI Coding 工具能力会越来越强，我们不得不每天都问自己：“如果编写代码不再是难题，你的竞争力在哪呢？”

参考

claude code 逆向研究：https://github.com/shareAI-lab/analysis_claude_code
claude code 指南：https://github.com/zebbern/claude-code-guide
command：https://claude.ai/public/artifacts/e2725e41-cca5-48e5-9c15-6eab92012e75
官方指南：https://docs.anthropic.com/zh-CN/docs/intro

20 款AI 编程工具对比，最好用的是这个组合

Sun, 06 Jul 2025 07:33:52 GMT

大家好，我是 luckySnail，截止到 2025 年 6 月底，AI 编程工具赛道已经是神仙打架了！这里面有字节，阿里，谷歌，微软等大厂的产品，也有 Cursor，windsurf 这样的新星，下面我整理 20 + AI 编码辅助工具，让我们全面的对比这些工具，

工具

终端 CLI：claude code，codex cli，gemini cli，aider，Warp

编辑器：Cursor ，windsurf，Trea，

VSCode 插件：github copilot，Cline，Lingma，Augment code，Roocode，codebuddy

Web 端：v0.dev、bolt.new、jules、Replit AI、codex，youware，

AI 自动 Agent：Devin AI

ESLint + Prettier 太烦人？这次彻底搞定

Sun, 15 Jun 2025 14:01:14 GMT

众所周知，前端搭建项目的时候，如果是团队开发肯定需要配置 ESLint 和 Prettier 来保证代码风格统一。但是 ESLint 和 Prettier 如果配置不好，就会“打架”，并且它们的配置还比较麻烦，那怎么办呢？其实很简单，就是使用现成的，很多大厂都提供了现成的解决方案，下面就来看一下吧！

下面，来看看社区提供的五套方案，让我们先看一下下面的表格，这里除了 @antfu/eslint-config ，其他都是出自大厂的开源

下面让我们更加详细的看看它们的优缺点

@antfu/eslint-config

这是 Vue 团队成员 Anthony Fu 开发的 ESLint 配置，特点是开箱即用，零配置，支持 JS, TS, JSX, Vue, JSON, YAML, Markdown，并可选择性支持 React, Svelte, UnoCSS, Astro, Solid 等。通过 eslint-plugin-format 支持 CSS, HTML, XML 等格式化，我觉得很好用，推荐。

使用非常简单，既可以通过 CLI:

pnpm dlx @antfu/eslint-config@latest

也可以通过手动安装到项目：

pnpm i -D eslint @antfu/eslint-config

然后，需要在根目录下新建 eslint.config.mjs 并进行配置

如果你是 antfu 的粉丝，或者你不了解 ESLint 和 Prettier，那么这是一个好的选择

@umijs/fabric

这是蚂蚁集团 Umi 团队的规范，如果你使用 umi 框架，应该对它不陌生。但最近一次更新已经是在两年前

它支持 JS, 适合在 React 和 TS 项目使用，包含 prettier，eslint，stylelint ,commitlint 的配置

使用它，需要手动安装并配置：

npm i @umijs/fabric --save-dev

然后根据官方文档配置 .eslintrc.js , .stylelintrc.js 和 .prettierrc.js

eslint-config-ali

遵循阿里巴巴前端工程规范（F2E Guidelines）的配置，支持 JavaScript、TypeScript、React、Vue、Node.js 等多种项目类型，大厂出品，应该兼容性和质量比较高，也是我在使用的，推荐。

推荐使用 CLI 方式接入，直接在项目根目录运行：

npx f2elint

选择你的配置，它会自动帮你进行安装依赖和生成对应的脚本和配置

eslint-config-airbnb 和 eslint-config-airbnb-base

eslint-config-airbnb：Airbnb 风格指南，适合 React 项目。
eslint-config-airbnb-base：Airbnb 基础 JS 配置，无 React 插件，适合非 React JS 项目。

Airbnb 的 JavaScript 代码规范，业界最流行的规范之一。github star 147k。但是库的更新最近一次是 2021 年安装使用它，对于 React 项目：

npx install-peerdeps --dev eslint-config-airbnb

对于非 React 项目：

npx install-peerdeps --dev eslint-config-airbnb-base

然后配置 .eslintrc.js

eslint-config-alloy

腾讯 AlloyTeam 出品的 ESLint 配置，支持多种技术栈。适合 React, Vue, TypeScript 项目，特别适合需要高度定制的团队，腾讯 AlloyTeam 开发。使用它可以通过手动的方式：

npm install --save-dev eslint @babel/core @babel/eslint-parser eslint-config-alloy

最后

ESLint + Prettier 依然是目前最主流的前端代码规范的工具，但是也有新星挑战者，Biome 和 Oxlint，它们的集成也比较简答，选择一个适合自己的项目代码格式化规范，这样以后就可以专注代码和其他事情上了！

2025 已经过一半了！聊聊最近的生活

Mon, 02 Jun 2025 15:56:12 GMT

大家好，我是 luckySnail，今天看了一眼日历发现时间已经到了六月，2025 年已经过了一半了！吓得我赶紧看看年初定的目标，感觉也是按照预设的路线在向前走，虽然偶尔焦虑，偶尔摆烂，偶尔很丧；但还好没有放弃，我很感谢这半年来的自己，我相信即使很多年后再回忆，2025 应该也是很难忘的一年，下面我想分享这半年我的经历和感悟，希望对你有所帮助

如果给上半年一些关键词：

坚持
自信
平和

充实的生活

这半年中，经过一些思考，我离开了工作两年的公司，加入了一家做 AI 产品的新公司。在 AI 的冲击下，我系统学习了 Node.js 及其上层框架 Nest.js ，并通过实践所学知识，开发了一个全栈项目： svg 秀https://www.svgshow.cn/ （一个使用 svg 创建美观图片的工具站），还尝试通过自媒体和开源社区进行营销，实现了第一个 1K+ 的用户数的产品。除了上面为产品去做自媒体，我也尝试主动分享一些我工作，生活的见闻和思考。主要维护的平台是：微信公众号、小红书；偶尔也发一下抖音和哔哩哔哩，真的是够“不务正业”的。这半年也是让 AI 更加融入到我每一天的方方面面，无论是工作的 coding 还是自媒体创作，再到生活中的搜索，近期还在尝试使用 Vibe Coding 开发我的第一个游览器插件。哦对了，在这半年中我也花了不少时间在写简历，投递简历，优化简历，面试求职，这些事情对我来说确实是困难的！

在生活中，我搬到了新的地方，这里更有烟火气，路边的电动车道也更宽了！交警也变少了！

五一回去看了年迈的爷爷和奶奶，陪伴了他们三天，他们很开心，我也很开心；还找到了小时候的相册，看到了童年的自己。

听到了梁博的四专《精气神》，很喜欢《避世离俗》的歌词：“孩子如果有人说你孤独你不必踌躇你走你的路做你的主”

逛了复旦大学，好大学真的不一样！图书馆和教学楼建筑真的好气派！

读了新的书，技术类：《软件设计的哲学第二版》，《你不知道的 JavaScript》上和中，认知类：《做难而正确的事》

偶尔的健身了几次，健身的好处是清晰的能感知到，但是总是有各种事情阻碍我（bushi）

玩了好几个赛季的金铲铲，每个赛季都上到了大师！最近在看韩剧《苦尽甘来遇见你》，真的很好看！你的生活救生舱又是什么呢？

收获

经历了这么多，总归还是有一些收获和感悟的！

AI

目前在使用的 AI 工具：

chathub：公司免费的无限制年度会员😭，支持所有主流大模型，真的很好用，安利
gemini：学生优惠到 2026，感觉降智了！目前使用它更多的是进行调研工作，它的 Research 真的很强大
claude.ai：使用它进行画 svg 图，流程图，网页生成等等
chatGPT：图片创做，使用它为我的公众号配图，好用！
Cursor：唯一花钱订阅的，是我每日必备的 AI Coding 工具，虽然最近也付费了 Trae，但是 Cursor 还是独一档
Deepseek：用作翻译，应该是在英译中的翻译场景中最强大的模型，没有之一，我最近还专门对比了其他模型的翻译都是不如 Deepseek 的如果你还有什么好用的 AI 工具提高了你的效率，欢迎分享👏

求职之旅

2025 年程序员行业依然是处于内卷裁员的大环境下，虽然对比 2024 有所好转？但是对我这样一个学历不好的普通人来说，这时候选择跳槽也是属于地狱难度了！但是要感谢我的公司和我自己，在上家公司的两年工作中，提升了很多，为我成功面试拿到 offer 奠定了基础！

对于准备简历和面试，我觉得大家看下面内容就够了：

除了上面，我还想补充，不要为了一页纸而一页纸，如果你有两个项目，两段工作经历，那一页纸肯定是很勉强的！两页纸吧！前端简历不仅仅看你的内容，排版也是能体现你的审美的！还有就是不好的千万不要写，不要让本应该是加分项的内容成为了你的减分项。

简历投递：

boss 直聘
内推
招聘官网
社群，朋友，群聊等等

对于面试，我觉得最好先根据自己的简历找出可能提问的 100 个问题（可以 AI 辅助），然后整理好答案，进行复习，然后找人进行模拟面试，最后再去面试，这样能提高面试通过率。我特别想分享的是，面试遇到困难解决不了的问题，一定想办法转换话题，转移到你的强项，因为我们的任务是在 1 个小时内展示你最好的一面，并隐藏你的不足，最后通过面试拿到 offer！

全栈尝试

通过开发全栈项目，让我对后端有了基础的了解，更加擅长了前后端协作；能够更加全面系统的思考问题和提出解决方案。除了技术上的成长，在产品上，我更加清晰认知到技术是为了创造出更好的产品，解决现实中的问题。同时，我仔细计算了一下，我开发的「SVG 秀」这个产品是不赚钱，还是亏钱的，所以没事不要想不开去做自己的产品。如果真的打算做产品，第一步要做的事情绝对不是写代码，而是去营销，去找到第一批付费用户，然后计算收益，至少不能亏钱。

其实还有一个很深的感悟是，AI 时代技术不值钱后，业务和用户才是护城河，俗话说：“隔行如隔山”。只要在细分领域深耕，然后寻找可产品化的服务。通过营销找到并服务好你的客户。对应工作上，我们在提升技术的同时，也需要多了解公司的业务，知道公司是如何从客户手里赚到钱的，这个非常重要

自媒体

如果说这半年我最开心的事情，就是我开始尝试自媒体了！无论是文字，图文，视频，我都有尝试。并且我觉得取得的收获还是比较满意的，我接下来还是会继续更新我的自媒体，但是我不会刻意的去做自媒体，而是分享生活和工作的思考。保证把精力放在我当下最需要提升的技术能力和工作质量上。最后分享一句我每次登录微信公众号都能看到的话：“再小的个体，也有自己的品牌”。如果你也想做自媒体，就现在！

新的生活

我觉得我对目前的生活很热爱，每天都觉得时间不够，我对代码，对编程还有执念。我喜欢我目前的工作和生活，我也有信心我能够 WLB（Work Life Balance）。即使偶尔比较累，玩两把《金铲铲之战》就又活过来了！

这里我还想分享，我（普通人）对风险的认知。没人喜欢风险，但是只要做选择，就是在接受不同的风险，我觉得在年轻时候，在能够承担风险的范围内，尽可能选择更大风险的一步，输了，我们真的亏不了太多，但是成功了，我们能够收获很多！

改进

在回忆这半年的生活中，我发现我需要去改进的地方也很多！

锻炼：目前公司有免费健身房和羽毛球，我必须要想法提高工作效率，然后抽出时间去锻炼
学习：年初买了 frontend master 的会员，到现在还没有学习，马上都快过期了！
工作：更加了解当前的业务，从技术侧为业务赋能，提高产品收入
生活：要多留点时间给亲人，其实站在几十年后看，他们才是最重要的

希望我能做到吧！

总结

看清手中筹码，明确心之所向，然后尽情享受这场生命游戏！

Stack Overflow 社区的没落真的是因为 AI 吗？

Sat, 31 May 2025 16:29:38 GMT

大家好，我是 luckySnail，作为程序员，在没有 AI 的时候，每天必须要打开的应该就是 Stack Overflow 吧！无论是遇到什么问题都能在上面找到答案，即使找不到答案，也能提出该问题，然后全世界的精英们帮你解决，但就是这么一个程序员必备的站点，今天的月活远远不及巅峰时刻

那导致这些的原因真的是因为 AI 吗？我阅读了一些社区的文章和讨论，发现即使没有 AI，可能它也要走下坡路了！

问题的原因

严苛的规则

对提问题的人不友好：官方把大量新问题作为“重复”或“偏离主题”的问题进行关闭，这导致了提出问题的人无法解决自己的问题
对解决问题的人也不友好：用户贡献的高质量答案经常因格式细节被删除。例如，修正旧答案中的过时参数后被系统拒绝

过时的机制

“已采纳答案”机制固化：五年前的高票答案可能已过时（如旧版框架语法），但无法自动降权，导致新的正确的答案没法被看到
平台未经协商即推行“允许 AI 生成内容”政策，剥夺版主删改低质 AI 答案的权限。此举被批为追求流量牺牲内容质量

除了上面的内容，最主要还有一点就是平台精英化，新手小白进行提问被鄙视，这里变成了老手的聚集地，如果一个社区没有新鲜的血液那其实离消亡也就不远了

其实任何社区的生命周期都大概如此，经历初创期 => 成熟期 => 衰退期 => 消亡期、重生期。

当然，AI 一定是 Stack Overflow 走向衰亡期的导火索，程序员们能够通过 AI 更快的得到想要的答案，那确实没有必要去社区搜索询问，毕竟没人喜欢被骂一顿还得不到任何想要的东西

信息消费方式的转变

在没有 AI 的时代，搜索就是程序员获取知识，解决问题的主要途径，但是有了 AI，我们可以直接向 AI 提问，AI 如果接入 RAG 系统，它可以帮我们进行 web 搜索，然后整理信息回答我们，相比较传统的信息检索，AI 极大的提高了效率，还节省了时间。但是者并不代表着社区或者其他信息获取方式都会被 AI 替代，我觉得 AI 会倒逼这些社区提升自己，去做 AI 做不到的事情，例如：传递互帮互助的能量、解决特别困难的问题、建立更加高质量；实时的内容等等。

对于我这个普通的码农来说，AI 让我更快的获取到了有用的信息，同时也让我看到了知识的获取变得极为简单，让我不得不思考，如果 AI 真的非常强大，我到底比 AI 强在哪？总不能比 AI 更便宜吧！目前看到的是 AI 就算很强大，但是它也无法真正的胜任企业中的产品开发，主要体现在：

团队沟通协作，你知道的，跟人打交道是一门高深的学问
将需求转为对应的代码，并保证功能完好
设计出符合产品未来发展轨道的架构，并保证代码可维护
创造出从未有的事物

参考

https://www.reddit.com/r/webdev/comments/1gg0377/stackoverflows_search_trends_are_the_lowest/?tl=zh-hans

用了两天 Trae，更愿意为 Cursor 花钱了！

Fri, 30 May 2025 17:02:53 GMT

大家好！我是 luckySnail，我其实很早就使用 AI 辅助编程，也使用过很多 AI 工具，从最初的 Devv 到通义灵码，再到最近一直使用的 Cursor。也算是经历了 AI coding 从刀耕火种到逐渐成熟的过程，下面是我在 AI 编程中记录分享的一些文章，其中有一篇还被骂上掘金热榜

这我想起我之前读书的时候一句书评，我觉得很适合使用在这里：

下面来分享一些我使用 Trae 过程中，发现 Cursor 这个产品的优点，真的是没有对比就没有伤害！

Trae 体验

在 Trae 更新后，就有朋友推荐说 Trae 现在好用了，可以试试。但是我之前是使用过它的，觉得它跟 Cursor 的差距还是挺大的，但是都被安利了，那就试试吧！看到国内的团队做出的产品还是很开心的，就支持了一下！但是就当我充值完成又更新了一下编辑器后，我发现我的 claude 模型不见了！你能理解刚充值完成后自己想要的东西就没了那种感觉嘛？感觉被诈骗了一样，折腾了一下发现也有其他人遇到，于是发邮件询问才知道对港澳地区禁用了 claude 大模型，这是不是得说一声呢？当我提问第一个问题的时候，它竟然直接就报错了我的脑海里只有“退钱”的那个表情包，没关系，再忍一下，钱花了，不能就这么算了呀！在接下来的使用过程中，就是一个折磨的过程，主要体现在：

没有 git 相关的能力，无法 review code ，或者基于当前工作区作为上下文，
builder 模式有时候仅仅给意见，不直接改对应内容
偶尔出现奇怪的 UI 和操作 bug
不必要改动太多，例如为什么要把编辑器原本的设置隐藏那么深？

最让我觉得要逃离的就是自动补全的能力，Cursor 是真的懂程序员，懂如何写代码，它清楚的知道你下一步要干什么，它的 tab 总是能够让我去到我想要去的地方，我觉得这是 Curosr 的护城河。但是 Trae 的自动补全能力真的很差，感觉都不如一些插件的自动补全能力，下面举例说明：

我基于 xiaohongshu.ts 复制一份代码，在 tiktok.ts 进行编辑，这时候我里面定义的 xiaohongshu 这样的名称在 curosr 中会自动帮我改为 tiktok
改一个内容的时候，下面也有同样的内容要修改，在 curosr 会自动进 tab 提示告诉我下面有同样修改的，并且还支持跨文件 tab
curosr 会自动识别需要导入的内容，进行 tab 导入

总结

如果只用一句话总结，我想说的是，做产品第一印象一定不要太差，这就像跟人打交道一样，第一次见面很重要。Trae 的收费是必然，但是收费后，依然很多东西做的不如人家，确实不应该，curosr 公司肯定没有字节的人才多吧！

我觉得 Cursor 就像是一个非常精通代码开发的团队开发出来的产品，它知道开发者最关心什么！Trae 就像一个产品团队主导的产品，它美观，交互体验好，但是这些都是锦上添花的东西，真正核心的是程序员能不能舒服的使用它解决问题，提高效率

当然，也可能我是使用了很久 curosr 导致我带着有色眼镜去看 Trae，无论如何，我希望 Trae 能够成为和 Cursor 一样被喜欢的产品

写于 05,30 晚，明天是端午节，祝你节日快乐！

YouWare, 你的下一个创作载体也可以是网页

Thu, 29 May 2025 15:16:35 GMT

hello，我是 luckySnail，最近看到了一篇非常棒的文章《晚点对话明超平：他们不信 AI coding 会是新的创作方式，我很开心》。主人公创作了一个 AI Coding 生成网页的工具，其实这类产品已经很多了，但是创始人曾在多个大厂担任产品经理，他对 AI 的思考和 AI 对创作者的影响的思考是让我学到了很多。例如：

如何让同样的 token 创造更大的价值？
如何让产品活下去？如何设计商业模式？下面就来试用一下这位大牛的 AI 生成网页工具 YouWare 吧！

试用体验

下面，我使用一篇文章《简历自测大挑战，超过95我就服你！》来进行测试，这篇文章给出了计算简历得分的标准，我们根据它的规范来计算我们的简历就能得到最终的得分！但是直接阅读计算体验不够友好，下面我们来使用 YouWare 优化一下这篇文章， 1）复制文章内容 2）打开 youware.com 然后粘贴内容到输入框，并添加：基于上面内容开发一个网站 3）等待一会它会给我们一个网页 4）在右边的输入框继续让它优化一下，改为游戏风格

5）点击右上角 publish： https://www.youware.com/project/63nxqh3ity 现在你可以访问这个网页，然后对你当前的简历进行打分，最终点击计算得分，你会看到大家觉得哪种体验好呢？

总结

在这个过程中，我就是一个普通的会上网的网民，我只需要会点击即可，虽然我不会为这类产品付费，但是这不代表普通人不会，对于普通人来说这就像变魔术一样，我觉得会有不会技术的用户惊讶它的能力，而向他付费的。这个产品让我产生了一些观点，不知道你认不认可：

好的 idea 变得格外珍贵，因为你可以借助这些工具快速实现你的想法💡
随着 AI 的强大和普及，AI 创作者和对应的平台肯定会产生，可能是 youware，也可能是其他
好的内容，大概率会借助 AI 以更好的展现形式再火一次

参考

简历自测大挑战，超过95我就服你： https://www.codefather.cn/post/1831925888316403713

使用 Cursor 从 0 到 1 开发一个全栈 chatbox 项目

Fri, 23 May 2025 01:44:45 GMT

大家好，我是 luckySnail，你肯定用过 AI 聊天工具。例如： Gemini，ChatGPT，claude AI 等产品，我们通过它们的 web 网站或者手机应用提出问题，得到答案。在之前如果你想要构建一个这样的 AI 聊天应用程序，是需要大量时间才能开发出来，但是接下来，我将使用 cursor + vercel 的 Next.js 和 ai-sdk 快速搭建属于你自己的 AI chat 工具，通过这篇文章你可以看到 AI 强大的辅助编程能力和 vercel 家超赞的工具！同时也能了解如何使用 AI 从 0 到 1 构建一个 web 应用，先看一下最终的产品：

如果你想直接看源码： https://github.com/coderPerseus/easyChat 我还使用 deepwiki 生成了对应的项目文档： https://deepwiki.com/coderPerseus/easyChat

环境准备

在正式开发前，你的设备需要有如下环境：

Node >= 18.18，pnpm 作为依赖管理工具
postgreSQL ，可以是本地或者在线
Curosr ，用作 AI 辅助编程
chrome 游览器，其他游览器也可

你需要具备的知识：

前端基础
数据库基础
计算机网络基础
熟悉 React 开发当然，你还需要有良好的软件开发素养，否则你会发现写的代码不好维护，或者不易理解

项目初始化

在真正开发项目之前，让我们先进行需求分析和技术选型

需求分析

聊天页面开发（基础能力）
- 包含提示的输入框和发送 / 停止按钮
- 实现一个聊天区域来显示对话记录，一个列表展示会话历史
- 开发 /agent API 来处理请求
- 确保每个对话的数据都被持久存储
- 通过流式传输返回所有结果
高级能力
- 增强聊天组件，支持 markdown 渲染、自动滚动、图片上传等
- 实现函数调用，例如检索当前时间

技术选型

根据需求，我选择了我喜欢的并且也是主流的技术：

Next.js 作为全栈开发基础框架
hono.js 作为后端框架，优化在 Next.js 中后端开发体验
PostgreSQL 作为数据库存储对话记录
DrizzleORM 作为 ORM ，更为便捷和高效的方式与数据库进行交互
shadcn/ui 作为 UI 组件库，tailwindcss 作为 css 框架
Vercel AI SDK 快速开发 AI 相关的服务，如果你也在开发 AI 相关的服务，强烈推荐使用它，能帮你减少 80% 的工作
Biome 进行代码格式化和检测（代替 ESLint + Prettier），需要你安装 Biome 插件哦
zod ： TypeScript 优先的数据验证库

对了，我们使用 Github 进行版本控制，维护代码。使用 vercel 进行项目部署上线。

初始化

下面进行初始化项目，初始化项目完成后，我们应该就可以进行业务开发

1）根据 Next.js 官方文档我们创建一个 Next.js 项目：

npx create-next-app@latest

2）下面，根据官方文档集成 shadcn/ui：

pnpm dlx shadcn@latest init
pnpm dlx shadcn@latest add button

然后尝试使用 Button 按钮，发现集成成功！

注意这里有一个小细节就是我在入口的 layout 组件为 body 标签添加了 suppressHydrationWarning ，作用是：抑制 React 在客户端和服务器端渲染不匹配时产生的警告信息，这在处理动态内容（如日期、时间等）时特别有用，因为这些内容在服务器端和客户端可能会有差异。

3）下面集成 Biome，保证相关代码风格一致

pnpm i @biomejs/biome -D

然后在 package.json 添加对应的脚本：

{
  "scripts": {
    "lint": "next lint",
    "format": "biome format --write .",
    "lint:biome": "biome check --apply.",
  }
}

下面设置编辑器的 Format Document With ，选择 Configure Default Formatter 设置为 Biome。现在你的项目就又了格式化能力，你还可以在 git 提交的链路上进行预先 format 和 lint 等操作，保证提交的代码是格式化的。 4）下面继续集成 hono.js，我参考了文章思路： https://kuizuo.cn/blog/nextjs-with-hono/ 。首先根据官方文档进行安装

pnpm i hono
# 让 hono 接管所有接口服务
mkdir -p "src/app/api/[[...route]]" && touch "src/app/api/[[...route]]/route.ts"

下面，开发 route.ts 内容，让 hono 来接管接口服务

import api from "@/server/api";
import { handle } from "hono/vercel";
const handler = handle(api);
export {
  handler as GET,
  handler as POST,
  handler as PUT,
  handler as DELETE,
  handler as PATCH,
};

因为 Next.js 会自动扫描 app 下的文件夹进行热更新，所以我们可以将服务端代码放在根目录的 server 文件夹下（其实你可以使用任何名称），这里写我们所有的服务端逻辑和接口，下面初始化一下服务端的基础逻辑， 5）创建自定义校验器，它的作用是进行请求数据验证的工具函数，确保数据符合预期的格式和类型规范，并提供类型安全的验证结果

import type {
  Context,
  MiddlewareHandler,
  Env,
  ValidationTargets,
  TypedResponse,
  Input,
} from "hono";
import { validator } from "hono/validator";
import type { z, ZodSchema, ZodError } from "zod";

export type Hook<
  T,
  E extends Env,
  P extends string,
  Target extends keyof ValidationTargets = keyof ValidationTargets,
  // biome-ignore lint/complexity/noBannedTypes: <explanation>
  O = {}
> = (
  result: (
    | { success: true; data: T }
    | { success: false; error: ZodError; data: T }
  ) & {
    target: Target;
  },
  c: Context<E, P>
) =>
  | Response
  | void
  | TypedResponse<O>
  // biome-ignore lint/suspicious/noConfusingVoidType: <explanation>
  | Promise<Response | void | TypedResponse<O>>;

type HasUndefined<T> = undefined extends T ? true : false;

export const zValidator = <
  T extends ZodSchema,
  Target extends keyof ValidationTargets,
  E extends Env,
  P extends string,
  In = z.input<T>,
  Out = z.output<T>,
  I extends Input = {
    in: HasUndefined<In> extends true
      ? {
          [K in Target]?: K extends "json"
            ? In
            : HasUndefined<keyof ValidationTargets[K]> extends true
            ? { [K2 in keyof In]?: ValidationTargets[K][K2] }
            : { [K2 in keyof In]: ValidationTargets[K][K2] };
        }
      : {
          [K in Target]: K extends "json"
            ? In
            : HasUndefined<keyof ValidationTargets[K]> extends true
            ? { [K2 in keyof In]?: ValidationTargets[K][K2] }
            : { [K2 in keyof In]: ValidationTargets[K][K2] };
        };
    out: { [K in Target]: Out };
  },
  V extends I = I
>(
  target: Target,
  schema: T,
  hook?: Hook<z.infer<T>, E, P, Target>
): MiddlewareHandler<E, P, V> =>
  // @ts-expect-error not typed well
  validator(target, async (value, c) => {
    const result = await schema.safeParseAsync(value);

    if (hook) {
      const hookResult = await hook({ data: value, ...result, target }, c);
      if (hookResult) {
        if (hookResult instanceof Response) {
          return hookResult;
        }

        if ("response" in hookResult) {
          return hookResult.response;
        }
      }
    }

    if (!result.success) {
      throw result.error;
    }

    return result.data as z.infer<T>;
  });

6）创建错误处理文件，给到客户端更好的错误提示：

import { z } from "zod";
import type { Context } from "hono";
import { HTTPException } from "hono/http-exception";
import type { ContentfulStatusCode } from "hono/utils/http-status";

export class ApiError extends HTTPException {
  public readonly code?: ContentfulStatusCode;
  constructor({
    code,
    message,
  }: {
    code?: ContentfulStatusCode;
    message: string;
  }) {
    super(code, { message });
    this.code = code;
  }
}

export function handleError(err: Error, c: Context): Response {
  if (err instanceof z.ZodError) {
    const firstError = err.errors[0];

    return c.json(
      { code: 422, message: `\`${firstError.path}\`: ${firstError.message}` },
      422
    );
  }

  /**
   * This is a generic error, we should log it and return a 500
   */
  return c.json(
    {
      code: 500,
      message: "服务端错误, 请稍后再试。",
    },
    { status: 500 }
  );
}

下面我们创建我们的第一个接口，验证 honojs 是否引入成功：

import { Hono } from "hono";
const app = new Hono().get("/hello", (c) =>
  c.json({ message: "Hello, luckyChat" })
);
export default app;

7）最后，开发入口文件：

import { handleError } from "./error";
import { Hono } from "hono";
import helloRoute from "./routes/hello";
const app = new Hono().basePath("/api");
app.onError(handleError);
const routes = app.route("/", helloRoute);
export default app;
export type AppType = typeof routes;

现在我们不仅有了接口，还有了服务端接口的类型声明，我们可以非常方便的在客户端进行类型安全的接口请求，我们不需要写路由，也不需要写类型相关的内容，真的是 amazing，我们赶紧在客户端调用第一个接口吧！在调用接口前， 8）我们先封装一个 fetch 方法：

import type { AppType } from "@/server/api";
import { hc } from "hono/client";
import ky from "ky";

const baseUrl =
  process.env.NODE_ENV === "development"
    ? "http://localhost:3000"
    : process.env.NEXT_PUBLIC_APP_URL;

export const fetch = ky.extend({
  hooks: {
    afterResponse: [
      async (_, __, response: Response) => {
        if (response.ok) {
          return response;
          // biome-ignore lint/style/noUselessElse: <explanation>
        } else {
          throw await response.json();
        }
      },
    ],
  },
});

export const client = hc<AppType>(baseUrl as string, {
  fetch: fetch,
});

ky 库是一个基于浏览器原生 Fetch API 的轻量级HTTP客户端库，提供了更简洁友好的接口，使用它更好的与 honojs 集成，这里我们使用 hc 和 AppType 创建了一个安全的接口请求方式：

import { Button } from "@/components/ui/button";
import { Heart } from "lucide-react";
import { client } from "@/lib/fetch";
async function getData() {
  try {
    const res = await client.api.hello.$get();
    if (!res.ok) {
      // This will activate the closest `error.js` Error Boundary
      throw new Error("Failed to fetch data");
    }
    return res.json();
  } catch (error) {
    console.error("获取数据失败:", error);
    return { message: "AI 助手" };
  }
}
export default async function Home() {
  const { message } = await getData();
  return (
    <div>
    <div>{message}</div>
      <Button>
        <Heart className="mr-2 h-4 w-4" /> lucky Snail
      </Button>
    </div>
  );
}

当我们在使用 client 的时候它会进行代码提示告诉你目前可以使用哪些接口，并且在后面我们可以借助 InferResponseType 和 typeof 等 ts 关键字来使用接口对应的 ts 类型，我们只需要在服务端定义好类型声明，在客户端直接消费即可 👍。

9）下面进行最重要的一步，也就是数据库初始化，有开发经验的应该都知道数据库设计的好，可以大大降低系统复杂度，减少不必要的代码，这么重要的事情肯定是需要 AI 的参与的，我们把需求给到 AI，然后让 AI 帮忙进行初步数据库设计，下面在 cursor 中进行 ask：

提示词：现在集成 DrizzleORM, and AI SDK.使用 postgreSQL 作为数据库，驱动使用 postgres，数据库名字叫 chatAI ，数据库就一张表，存储 AI 对话记录，设计良好的数据库表结构，最后开发 /agent API 来处理聊天请求，这里使用大模型为 Deepseek ，大模型的 key 存在 环境变量的 DEEPSEEK_API_KEY ，数据库集成参考 @https://orm.drizzle.team/docs/get-started-postgresql ，先梳理需求，然后一步步进行实现

AI 给到的数据库结构如下：

import { pgTable, serial, text, timestamp, varchar } from 'drizzle-orm/pg-core';

// 聊天消息类型
export const chatMessages = pgTable('chat_messages', {
  id: serial('id').primaryKey(),
  sessionId: varchar('session_id', { length: 255 }).notNull(),
  role: varchar('role', { length: 50 }).notNull(), // 'user' 或 'assistant'
  content: text('content').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

// 会话信息
export const chatSessions = pgTable('chat_sessions', {
  id: serial('id').primaryKey(),
  sessionId: varchar('session_id', { length: 255 }).unique().notNull(),
  title: varchar('title', { length: 255 }),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
});

这里 AI 帮我们创建好了数据库的表结构，它能理解需求，并给出合理的数据库设计：

chat_sessions 表：存储聊天会话信息
chat_messages 表：存储聊天消息还帮我们在 package.json 添加了生成和运行迁移的脚本，我们在 env 配置到 DATABASE_URL，执行脚本即可初始化数据库

现在我们完成了项目初始化，我们可以使用 cursor 提供的 /generate Cursor Rules 来生成项目开发指导，在后面业务能力开发中，我们每次都携带上这条 rules ，它能帮 AI 更好的生成内容

现在已经搭建好了前端和后端基础能力，并且生成了项目开发的 rules ，下面就全部交给 AI 来进行业务开发，我们只需要做一个合格的测试和 code review 就好了！

核心能力开发

一个聊天应用最核心的就是输入提示词 => AI 大模型响应内容 => 展示内容 => 继续对话

1）开发 chat，提示词如下

下面 @project-structure.mdc 就是我们生成的项目开发 rules

@project-structure.mdc 使用 ai-sdk 开发 /agent API 来处理聊天请求，遵循 RESTful API 风格，这里使用大模型为 Deepseek ，大模型的 key 存在 环境变量的 DEEPSEEK_API_KEY ，然后在开发对应的 chat 页面，一个输入框，右侧有发送和暂停按钮，支持接收用户的输入，支持发送和停止能力，这里使用 @ai-sdk/react 快速进行开发，需要流式输出 AI 生成内容。代码组件化，模块化，尽可能使用 shadui/cn 组件开发，先梳理需求，然后一步步进行实现

AI 可能需要比较漫长时间完成工作，在这个过程中，我们可以思考下一个提示词，在 AI 生成完成后，我们需要进行检查和修复 bug，当然你是可以借助 AI 来 fix error。这里需要额外注意的是当我们 chat 中断的时候应该把已经生成的内容进行存储数据库

2）开发创建新会话能力，支持会话缓存到本地

@project-structure.mdc 支持创建新会话，并且会话 id 存储 localStorage ，在页面刷新的时候会话 id 依然存在，注意点击停止需要把当前会话进行存储

3）开发历史会话列表展示，支持切换会话

@project-structure.mdc 开发历史对话记录功能，先进行接口开发，这里两个接口：获取所有会话列表和获取指定 id 的会话信息，前端需要将会话列表封装为单独组件，点击会话列表项能进入该对话，数据接口逻辑使用自定义 hooks，保证代码清晰易理解。 注意客户端需要使用封装的 fetch 导出的 client 进行接口请求

4）支持 markdown 渲染 AI 生成的内容，优化页面布局 UI，支持内容自动滚动底部上面完成后，我们有了基本的 chat 功能页面，但是可能这时候页面比较丑不太美观，现在进行优化

@project-structure.mdc 你是资深 UI 设计师，现在进行项目优化：
1，实现 markdown 渲染流式内容。添加在对话中自动滚动到底部的能力
2. 优化目前的页面 UI，页面布局为左边的侧边栏，展示历史记录和新对话能力都放在左边，当屏幕宽度小于 tailwindcss 的 lg 的时候就不展示侧边栏，右侧对话框 UI ，也需要进行优化，注意不要新增元素和修改逻辑，仅仅是对元素布局和 UI进行优化，参考优秀的 chatbox UI 设计

5）支持 function call 能力，获取当前时间

@project-structure.mdc @web 参考文档支持 function call 能力，以获取最新时间为例

优化

如果你做到这里，相信你的项目肯定还有一些 bug 和 UI 细节需要进行优化，你可以和 AI 一起进行优化，给大家看一下我和 AI 的 chat 不断的修复和优化，最终我的 chatbox 就出现啦！你打几分呢？

总结

AI 目前编程能力已经超过 90% 的工程师了，它在开发功能安全性和兼容性考虑上十分的全面，但是它也有能力边界，在面对复杂系统，奇怪的需求上是不如人的。所以程序员以后更多是做决策，做 AI 与需求的桥梁，通过我们的经验和直觉去选择接受还是拒绝 AI 的生成
日常 AI 编程开发中，推荐使用方式为 gemini 做设计和文档类工作，写代码部分交给 claude
需要我们能够合理的进行模块拆分，能够识别 AI 代码是不是合理的
系统设计是 AI 时代程序员的必须要提升的技能，推荐一本书《软件设计的哲学》第二版
知识广度，全栈能力对前端有很大的帮助，借助 AI 快速将想法变成现实是程序员的红利
持续学习，跟进最新的 AI 是保证自己有竞争力的关键
Vibe Coding 必然会成为新的编码方式，纯手工编程必然会像 php 一样成为历史
目前来看，编程智能体（Agent）真的很成功，让我这种普通人能够快速开发出产品。

参考：

github 源码阅读神器 deepwiki，自动生成源码架构图和知识库

Sat, 26 Apr 2025 09:42:07 GMT

大家好，我是 luckysnail ，今天看到了一个我之前想要做的 AI 产品，就是基于 github 仓库生成对应的教程文档。给大家看一下我之前记录的：

没想到已经有知名的公司 https://devin.ai/ 做了，就是创造首个 AI 软件工程师 Devin 的公司。它目前完全免费，无需注册即可使用。下面来看看 DeepWiki 的能力

什么是 DeepWiki？

DeepWiki是由 Cognition Labs 推出的创新项目，旨在为全球每一个 GitHub 代码仓库提供实时交互式文档。简单来说，它是一个由 AI 驱动的 GitHub 版本“百科全书”，能够让你与对应仓库的专家进行对话，帮助你快速了解上手项目。

这个工具的特点是：

完全免费：对开源项目无需注册即可使用
即时访问：只需修改GitHub链接就能跳转到对应Wiki
智能问答：可以直接向代码库“提问”并获得专业解答
深度分析：能揭示代码库的隐藏结构和开发模式

基础能力

使用它非常简单，你可以直接去： https://deepwiki.com/ ，然后搜索你想要了解的项目。你也可以在 github 访问一个项目的时候把 github 改为 deepwiki 。然后你会看到：

可以看到它会生成项目的文档和架构图，而且下面还可以跟文档进行对话，对话过程中它会实时的检索项目的源码进行回复：

我这里通过我之前学习的 umi-request 源码进行查看，它输出的内容和支持都是非常高，没有错误！感觉以后我学习新的 github 仓库会先到这里来学习，然后再拉取代码进行阅读。

如果你是私有仓库，你需要先登录 Devin 账户，然后进行仓库的知识库生成

结语

deepwiki 目前已索引约3万个GitHub仓库，处理超过40亿行代码。无论是对于新手小白想要学习 github 仓库，还是对应经验丰富的软件工程师都是有很大的帮助，大大节省了我们理解项目的成本

程序员学习英语最佳方式被我找到了

Wed, 23 Apr 2025 16:12:52 GMT

大家好，我是 luckySnail，当你点进来，我就默认你也是 AI 工具使用者了，不知道你是否也会像我一样无聊的等待着 AI 生成内容。有点时候半天提示我一个 failed，那种时间被 AI 浪费的感觉真的糟糕透了！

经过我的一番思考和折腾，现在我不再等待 AI 生成，我选择在这短暂的时间去学英语（如果你英语贼 6 ，那请你滑动到底部点赞后离开，因为下面的内容是在浪费你的时间）。至于为什么要学英语，这个我就不解释了！下面说一下为什么选择在这个等待的时间去学习英语

为什么是学英语？

1）拒绝 AI 浪费我的时间：老实说，等待 AI 输出，尤其是结果未知时，心里多少有点烦躁。与其盯着屏幕干着急，不如把这段时间利用起来。学几个单词、看一条语法，这种微小的进步能有效缓解等待的焦虑感，把潜在的负面情绪转化为积极的学习动力 2）微学习：AI 的等待时间通常很短，而且时长不太确定，有时几秒，有时几十秒。这正好符合“微学习”的理念——利用碎片化的时间，进行小块知识的快速吸收。背一个单词、理解一个短语、看一个例句，这些都能在几十秒内完成，并且可以随时被打断，几乎没有“启动成本” 3）避免打断编程心流：相比于切换到另一个复杂的编程任务（这会导致高昂的上下文切换成本），或者刷社交媒体（这会彻底分散注意力），学习英语是一种完全不同的认知活动。它能让你从代码中短暂抽离，给大脑换个频道，但又不像娱乐信息那样容易“沉迷”进去。这样，当 AI 完成任务时，你能更容易地收回注意力，回到之前的编程思路上。 4）收益高：作为程序员，我们学习的很多英语知识（技术词汇、文档表达等）能直接反哺我们的日常工作。在等待 AI 生成代码或解释时，顺手查阅相关的英文文档片段或学习一个技术术语，这种关联性让学习更高效，也更有成就感。

怎么学？

这里使用 cursor 为代码编辑器

首先，可以安装一个 VS Browser 插件，然后 ctrl （mac 是 command） + p，输入： >VS Browser: Start Browser ,你会看到：

下面，你可以选择你喜欢的学习英语平台，这里我使用： https://qwerty.kaiyi.cool/ 。

现在就可以一边等待输出，一边学习英语。

目前痛点

虽然这样是可以的，但是目前体验不是很好，个人感觉：

AI 生成完成后，如果有一个提示声音会更好，强提醒我 AI 生成完成
学习英文网站在 cursor 中打开体验不是很好，有些网站对小屏幕兼容性不好不知道大家在 AI 生成过程中干什么呢？

Anthropic 官方发布Claude Code 最佳实践

Sun, 20 Apr 2025 01:59:01 GMT

大家好我是 luckySnail，就在昨天 Anthropic 团队发布了他们整理的《Claude 代码：代理式编码的最佳实践》，原文地址： https://www.anthropic.com/engineering/claude-code-best-practices

下面是校验的译文，让我们看看如何更好的 AI 编程吧！

我们最近发布了 Claude Code，这是一个用于智能体编程（agentic coding）的命令行工具。作为研究项目开发，Claude Code 为 Anthropic 的工程师和研究人员提供了一种更原生的方式，将 Claude 集成到他们的编码工作流中。

Claude Code 刻意设计得比较底层且无预设偏好（unopinionated），提供接近原始模型的访问能力，而不强制用户遵循特定的工作流程。这种设计理念创造了一个灵活、可定制、可脚本化且安全的强大工具。虽然功能强大，但这种灵活性对于刚接触智能体编程工具的工程师来说，意味着需要一定的学习曲线——至少在他们形成自己的最佳实践之前是这样。

本文概述了一些已被证明行之有效的通用模式，这些模式不仅适用于 Anthropic 内部团队，也适用于在各种代码库、语言和环境中使用 Claude Code 的外部工程师。列表中的任何内容都不是一成不变的，也不是普遍适用的；请将这些建议视为起点。我们鼓励你进行实验，找到最适合你的方法！

想了解更详细的信息？我们在 claude.ai/code 上的综合文档涵盖了本文提到的所有功能，并提供了额外的示例、实现细节和高级技巧。

1. 定制你的设置

Claude Code 是一个智能体编程助手，它会自动将上下文信息拉取到提示（prompt）中。这种上下文收集过程会消耗时间和 token，但你可以通过调整环境来优化它。

a. 创建 CLAUDE.md 文件

CLAUDE.md 是一个特殊文件，Claude 在开始对话时会自动将其内容拉取到上下文中。这使得它成为记录以下信息的理想场所：

常用的 bash 命令
核心文件和工具函数
代码风格指南
测试说明
代码仓库规范（例如，分支命名、使用 merge 还是 rebase 等）
开发者环境设置（例如，pyenv 的使用、哪些编译器可用）
项目特有的任何意外行为或警告
你希望 Claude 记住的其他信息

CLAUDE.md 文件没有必需的格式。我们建议保持其简洁且易于人类阅读。例如：

# Bash commands
- npm run build: Build the project
- npm run typecheck: Run the typechecker

# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')

# Workflow
- Be sure to typecheck when you’re done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

你可以将 CLAUDE.md 文件放置在以下几个位置：

仓库的根目录，或者你运行 claude 命令的目录（最常见用法）。将其命名为 CLAUDE.md 并提交到 git 中，以便在不同会话和团队成员之间共享（推荐），或者命名为 CLAUDE.local.md 并将其添加到 .gitignore 中。
运行 claude 命令的目录的任何父目录。这对于 monorepo（单一代码库管理多个项目）最有用，你可能在 root/foo 目录下运行 claude，并在 root/CLAUDE.md 和 root/foo/CLAUDE.md 中都有 CLAUDE.md 文件。这两个文件都会被自动拉取到上下文中。
运行 claude 命令的目录的任何子目录。这与上面相反，在这种情况下，当你处理子目录中的文件时，Claude 会按需拉取 CLAUDE.md 文件。
你的主文件夹 (~/.claude/CLAUDE.md)，这会应用于你所有的 claude 会话。

当你运行 /init 命令时，Claude 会自动为你生成一个 CLAUDE.md 文件。

b. 优化你的 CLAUDE.md 文件

你的 CLAUDE.md 文件会成为 Claude 提示的一部分，因此它们应该像任何经常使用的提示一样被优化改进。一个常见的错误是添加大量内容却没有迭代验证其有效性。花点时间进行实验，确定哪些内容能让模型最好地遵循指令。

你可以手动向 CLAUDE.md 添加内容，或者按 # 键给 Claude 一个指令，它会自动将该指令整合到相关的 CLAUDE.md 中。许多工程师在编码时经常使用 # 来记录命令、文件和风格指南，然后将 CLAUDE.md 的更改包含在提交（commit）中，这样团队成员也能受益。

在 Anthropic，我们偶尔会使用提示词优化器 (prompt improver) 来处理 CLAUDE.md 文件，并经常调整指令（例如，使用 “IMPORTANT” 或 “YOU MUST” 来强调）以提高遵循度。

图：Claude Code 工具允许列表设置界面

c. 管理 Claude 的允许工具列表

默认情况下，Claude Code 会对任何可能修改你系统的操作请求许可：文件写入、许多 bash 命令、MCP 工具等。我们故意采用这种保守的方法来设计 Claude Code，以优先考虑安全性。你可以自定义允许列表，以允许你知道是安全的额外工具，或者允许那些容易撤销的潜在不安全工具（例如，文件编辑、git commit）。

有四种方法来管理允许的工具：

在会话中被提示时选择 “始终允许 (Always allow)”。
启动 Claude Code 后使用 /allowed-tools 命令来添加或移除允许列表中的工具。例如，你可以添加 Edit 来始终允许文件编辑，Bash(git commit:*) 来允许 git 提交，或者 mcp__puppeteer__puppeteer_navigate 来允许使用 Puppeteer MCP 服务器进行导航。
手动编辑你的 .claude/settings.json 或 ~/.claude.json （我们建议将前者检入源代码控制以与团队共享）。
使用 --allowedTools 命令行标志进行会话特定的权限设置。

d. 如果使用 GitHub，请安装 gh CLI

Claude 知道如何使用 gh CLI 与 GitHub 交互，以创建 issue、打开 pull request、读取评论等。如果没有安装 gh，如果你安装了 GitHub API 或 MCP 服务器，Claude 仍然可以使用它们。

2. 给 Claude 更多工具

Claude 可以访问你的 shell 环境，你可以在其中为它构建一系列便捷的脚本和函数，就像为自己构建一样。它还可以通过 MCP 和 REST API 利用更复杂的工具。

a. 将 Claude 与 bash 工具结合使用

Claude Code 继承了你的 bash 环境，使其可以访问你所有的工具。虽然 Claude 知道常见的实用程序，如 unix 工具和 gh，但如果没有指令，它不会知道你的自定义 bash 工具：

告诉 Claude 工具名称和使用示例
告诉 Claude 运行 --help 来查看工具文档
在 CLAUDE.md 中记录常用的工具

b. 将 Claude 与 MCP 结合使用

Claude Code 同时充当 MCP 服务器和客户端。作为客户端，它可以通过三种方式连接到任意数量的 MCP 服务器以访问它们的工具：

在项目配置中（在那个目录下运行 Claude Code 时可用）
在全局配置中（在所有项目中可用）
在签入的 .mcp.json 文件中（对在你的代码库中工作的任何人可用）。例如，你可以将 Puppeteer 和 Sentry 服务器添加到你的 .mcp.json 中，这样每个在你仓库工作的工程师都可以开箱即用地使用这些工具。

使用 MCP 时，使用 --mcp-debug 标志启动 Claude 也有助于识别配置问题。

c. 使用自定义斜杠命令

对于重复的工作流程——调试循环、日志分析等——将提示模板存储在 .claude/commands 文件夹内的 Markdown 文件中。当你输入 / 时，这些模板就会通过斜杠命令菜单可用。你可以将这些命令检入 git，使其对团队其他成员可用。

自定义斜杠命令可以包含特殊关键字 $ARGUMENTS，以从命令调用中传递参数。

例如，这是一个可以用来自动拉取和修复 Github issue 的斜杠命令：

Please analyze and fix the GitHub issue: $ARGUMENTS.

Follow these steps:

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.

将上述内容放入 .claude/commands/fix-github-issue.md 文件中，使其在 Claude Code 中作为 /project:fix-github-issue 命令可用。然后你就可以例如使用 /project:fix-github-issue 1234 来让 Claude 修复 issue #1234。类似地，你可以将自己的个人命令添加到 ~/.claude/commands 文件夹中，以便在所有会话中使用。

3. 尝试常见工作流程

Claude Code 不强加特定的工作流程，让你能够灵活地按自己的方式使用它。在这种灵活性提供的空间内，我们的用户社区中涌现了几种成功有效使用 Claude Code 的模式：

a. 探索、计划、编码、提交 (Explore, plan, code, commit)

这个通用的工作流程适用于许多问题：

让 Claude 阅读相关文件、图片或 URL，可以提供一般性指引（“阅读处理日志的文件”）或具体文件名（“阅读 logging.py”），但明确告诉它暂时不要编写任何代码。
1. 这是工作流程中应该考虑重点使用子智能体（subagents）的部分，特别是对于复杂问题。让 Claude 使用子智能体来验证细节或调查它可能有的特定问题，尤其是在对话或任务的早期，往往可以在不牺牲太多效率的情况下保留上下文的可用性。
让 Claude 制定解决特定问题的计划。我们建议使用“思考 (think)”这个词来触发扩展思考模式 (extended thinking mode)，这会给 Claude 额外的计算时间来更彻底地评估备选方案。这些特定的短语直接映射到系统中不断增加的思考预算级别：“思考 (think)” < “深入思考 (think hard)” < “更深入思考 (think harder)” < “极致思考 (ultrathink)”。每个级别都会分配逐步增加的思考预算供 Claude 使用。
1. 如果这一步的结果看起来合理，你可以让 Claude 用它的计划创建一个文档或一个 GitHub issue，这样如果实现（步骤 3）不符合你的要求，你可以重置到这个点。
让 Claude 用代码实现其解决方案。这也是一个好时机，让它在实现方案的各个部分时明确验证其解决方案的合理性。
让 Claude 提交结果并创建一个 pull request。如果相关，这也是让 Claude 更新任何 README 或变更日志，解释它刚刚做了什么的好时机。

步骤 #1-#2 至关重要——没有它们，Claude 往往会直接跳到编码解决方案。虽然有时这就是你想要的，但要求 Claude 先研究和计划，对于需要更深入前期思考的问题，可以显著提高性能。

b. 编写测试、提交；编码、迭代、提交 (Write tests, commit; code, iterate, commit)

这是 Anthropic 内部最喜欢的工作流程之一，适用于可以通过单元测试、集成测试或端到端测试轻松验证的更改。测试驱动开发 (TDD) 在智能体编程的加持下变得更加强大：

让 Claude 根据预期的输入/输出对编写测试。明确说明你正在进行测试驱动开发，这样它会避免创建模拟实现 (mock implementations)，即使对于代码库中尚不存在的功能也是如此。
告诉 Claude 运行测试并确认它们失败。明确告诉它在此阶段不要编写任何实现代码通常很有帮助。
当你对测试满意时，让 Claude 提交测试。
让 Claude 编写通过测试的代码，指示它不要修改测试。告诉 Claude 继续进行，直到所有测试都通过。通常需要几次迭代，Claude 才能编写代码、运行测试、调整代码，然后再次运行测试。
1. 在这个阶段，让它使用独立的子智能体来验证实现是否过度拟合 (overfitting) 测试可能会有帮助。
当你对更改满意时，让 Claude 提交代码。

当 Claude 有一个明确的目标可以迭代时——一个视觉模型、一个测试用例或其他类型的输出——它的表现最好。通过提供像测试这样的预期输出，Claude 可以进行更改、评估结果，并逐步改进直到成功。

c. 编写代码、截图结果、迭代 (Write code, screenshot result, iterate)

与测试工作流程类似，你可以为 Claude 提供视觉目标：

给 Claude 一种截取浏览器屏幕截图的方法（例如，使用 Puppeteer MCP 服务器、iOS 模拟器 MCP 服务器，或者手动复制/粘贴截图给 Claude）。
通过复制/粘贴或拖放图像，或者提供图像文件路径，给 Claude 一个视觉模型 (visual mock)。
让 Claude 用代码实现设计，截取结果的屏幕截图，并迭代直到其结果与模型匹配。
当你满意时，让 Claude 提交。

像人类一样，Claude 的输出通常会通过迭代显著改善。虽然第一个版本可能不错，但经过 2-3 次迭代后，通常会看起来好得多。给 Claude 工具让它能看到自己的输出，以获得最佳结果。

图：在隔离的容器中使用安全 YOLO 模式

d. 安全 YOLO 模式 (Safe YOLO mode)

你可以不监督 Claude，而是使用 claude --dangerously-skip-permissions 来绕过所有权限检查，让 Claude 不间断地工作直到完成。这对于修复 lint 错误或生成样板代码等工作流程非常有效。

警告： 让 Claude 运行任意命令是有风险的，可能导致数据丢失、系统损坏甚至数据泄露（例如，通过提示注入攻击）。为了最小化这些风险，请在没有互联网访问的容器中使用 --dangerously-skip-permissions。你可以遵循这个使用 Docker Dev Containers 的参考实现。

e. 代码库问答 (Codebase Q&A)

在接触新的代码库时，使用 Claude Code 进行学习和探索。你可以像在结对编程时问项目中的其他工程师一样，向 Claude 提出各种问题。Claude 可以智能地搜索代码库来回答一般性问题，例如：

日志记录是如何工作的？
如何创建一个新的 API 端点？
foo.rs 文件第 134 行的 async move { ... } 是做什么的？
CustomerOnboardingFlowImpl 处理了哪些边缘情况？
为什么我们在第 333 行调用 foo() 而不是 bar()？
baz.py 文件第 334 行在 Java 中的等价实现是什么？

在 Anthropic，以这种方式使用 Claude Code 已成为我们的核心入职工作流程，显著缩短了熟悉项目的时间，并减轻了其他工程师的负担。无需特殊的提示！只需提问，Claude 就会探索代码以找到答案。

图：使用 Claude 编写 git commit 消息

f. 使用 Claude 与 git 交互

Claude 可以有效地处理许多 git 操作。许多 Anthropic 工程师使用 Claude 来处理 90% 以上的 git 交互：

搜索 git 历史记录以回答诸如“v1.2.3 版本包含了哪些更改？”、“这个特定功能是谁负责的？”或“为什么这个 API 是这样设计的？”等问题。明确提示 Claude 查找 git 历史记录来回答这类查询很有帮助。
编写 commit 消息。Claude 会自动查看你的更改和最近的历史记录，以撰写一条考虑了所有相关上下文的消息。
处理复杂的 git 操作，如还原文件、解决 rebase 冲突以及比较和嫁接补丁 (grafting patches)。

g. 使用 Claude 与 GitHub 交互

Claude Code 可以管理许多 GitHub 交互：

创建 pull requests：Claude 理解速记 “pr”，并将根据 diff 和周围的上下文生成适当的 commit 消息。
为简单的代码审查评论实现一键式解决方案：只需告诉它修复你 PR 上的评论（可选地，给它更具体的指示），并在完成后推送回 PR 分支。
修复失败的构建或 linter 警告。
对开放的 issue 进行分类和分流，通过让 Claude 遍历开放的 GitHub issue 来实现。

这消除了记住 gh 命令行语法的需要，同时自动化了常规任务。

h. 使用 Claude 处理 Jupyter notebook

Anthropic 的研究人员和数据科学家使用 Claude Code 来读取和编写 Jupyter notebook。Claude 可以解释输出，包括图像，为探索和与数据交互提供了一种快速的方法。没有必需的提示或工作流程，但我们推荐的一个工作流程是在 VS Code 中并排打开 Claude Code 和一个 .ipynb 文件。

你也可以让 Claude 在向同事展示之前清理或美化你的 Jupyter notebook。明确告诉它让 notebook 或其数据可视化“美观 (aesthetically pleasing)”往往有助于提醒它，它正在为人类的观看体验进行优化。

4. 优化你的工作流程

以下建议适用于所有工作流程：

a. 在指令中要具体

Claude Code 的成功率会随着更具体的指令而显著提高，尤其是在初次尝试时。预先给出明确的方向可以减少后续修正的需要。

例如：

欠佳的指令	良好的指令
为 foo.py 添加测试	为 foo.py 编写一个新的测试用例，覆盖用户未登录的边缘情况。避免使用 mock。
为什么 ExecutionFactory 的 API 这么奇怪？	查看 ExecutionFactory 的 git 历史记录，并总结其 API 是如何演变而来的。
添加一个日历小部件	查看主页上现有小部件的实现方式，以理解模式，特别是代码和接口是如何分离的。HotDogWidget.php 是一个很好的起点。然后，遵循该模式实现一个新的日历小部件，允许用户选择月份并通过向前/向后翻页来选择年份。除了代码库中已使用的库之外，不要使用其他库，从头开始构建。

Claude 可以推断意图，但它无法读懂你的心思。具体性可以更好地与期望保持一致。

图：向 Claude 提供图片作为上下文

b. 给 Claude 图片

Claude 可以通过多种方法出色地处理图像和图表：

粘贴截图（专业提示：在 macOS 中按 cmd+ctrl+shift+4 截图到剪贴板，然后按 ctrl+v 粘贴）
拖放图像直接到提示输入框
提供图像的文件路径

这在处理设计模型 (design mocks) 作为 UI 开发的参考点，以及使用可视化图表进行分析和调试时特别有用。即使你不向上下文中添加视觉效果，向 Claude 明确说明结果在视觉上吸引人的重要性仍然是有帮助的。

图：使用 tab 补全来引用文件

c. 提及你希望 Claude 查看或处理的文件

使用 tab 键补全功能快速引用仓库中任何位置的文件或文件夹，帮助 Claude 找到或更新正确的资源。

图：向 Claude 提供 URL 作为上下文

d. 给 Claude URL

将特定的 URL 粘贴到你的提示旁边，让 Claude 获取和阅读。为了避免对相同域名（例如 docs.foo.com）重复弹出权限提示，使用 /allowed-tools 将域名添加到你的允许列表中。

e. 尽早且经常地修正方向 (Course correct early and often)

虽然自动接受模式（按 shift+tab 切换）可以让 Claude 自主工作，但通常通过成为积极的协作者并指导 Claude 的方法，你会获得更好的结果。你可以在开始时向 Claude 彻底解释任务以获得最佳结果，但你也可以随时修正 Claude 的方向。

这四个工具有助于修正方向：

在编码之前要求 Claude 制定计划。明确告诉它在你确认其计划看起来不错之前不要编码。
在任何阶段（思考、工具调用、文件编辑）按 Escape 键中断 Claude，同时保留上下文，以便你可以重新定向或扩展指令。
双击 Escape 键跳回历史记录，编辑之前的提示，并探索不同的方向。你可以编辑提示并重复，直到获得你想要的结果。
要求 Claude 撤销更改，通常与选项 #2 结合使用以采取不同的方法。

尽管 Claude Code 偶尔能在第一次尝试时完美解决问题，但使用这些修正工具通常能更快地产生更好的解决方案。

f. 使用 /clear 保持上下文聚焦

在长时间的会话中，Claude 的上下文窗口可能会被不相关的对话、文件内容和命令填满。这会降低性能，有时还会分散 Claude 的注意力。在任务之间经常使用 /clear 命令来重置上下文窗口。

g. 对复杂工作流程使用清单和草稿板 (checklists and scratchpads)

对于包含多个步骤或需要详尽解决方案的大型任务——例如代码迁移、修复大量 lint 错误或运行复杂的构建脚本——可以通过让 Claude 使用 Markdown 文件（甚至 GitHub issue！）作为清单和工作草稿板来提高性能：

例如，要修复大量 lint 问题，你可以执行以下操作：

告诉 Claude 运行 lint 命令并将所有结果错误（包括文件名和行号）写入 Markdown 清单。
指示 Claude 逐个解决每个问题，在核对并移至下一个问题之前进行修复和验证。

h. 向 Claude 传递数据

有几种方法可以向 Claude 提供数据：

直接复制粘贴到你的提示中（最常见的方法）
通过管道 (pipe) 输入到 Claude Code（例如 cat foo.txt | claude），对于日志、CSV 和大数据特别有用
告诉 Claude 通过 bash 命令、MCP 工具或自定义斜杠命令拉取数据
让 Claude 读取文件或获取 URL（也适用于图像）

大多数会话都涉及这些方法的组合。例如，你可以通过管道输入一个日志文件，然后告诉 Claude 使用工具拉取额外的上下文来调试日志。

5. 使用无头模式 (headless mode) 自动化你的基础设施

Claude Code 包含无头模式，适用于非交互式环境，如 CI（持续集成）、pre-commit hooks（提交前钩子）、构建脚本和自动化。使用带有提示的 -p 标志来启用无头模式，并使用 --output-format stream-json 来获取流式 JSON 输出。

请注意，无头模式在会话之间不会持久存在。你必须在每个会话中触发它。

a. 使用 Claude 进行 issue 分流 (issue triage)

无头模式可以驱动由 GitHub 事件触发的自动化，例如当你的仓库中创建了新 issue 时。例如，公共的 Claude Code 仓库使用 Claude 来检查新传入的 issue 并分配适当的标签。

b. 使用 Claude 作为 linter (代码检查器)

Claude Code 可以提供主观的代码审查，超越传统 linting 工具所能检测到的问题，识别诸如拼写错误、过时的注释、误导性的函数或变量名等问题。

6. 通过多 Claude 工作流程提升效率

除了独立使用之外，一些最强大的应用涉及并行运行多个 Claude 实例：

a. 让一个 Claude 编写代码；使用另一个 Claude 来验证

一个简单但有效的方法是让一个 Claude 编写代码，而另一个则审查或测试它。类似于与多位工程师合作，有时拥有独立的上下文是有益的：

使用 Claude 编写代码。
运行 /clear 或在另一个终端中启动第二个 Claude。
让第二个 Claude 审查第一个 Claude 的工作。
启动另一个 Claude（或再次 /clear）来阅读代码和审查反馈。
让这个 Claude 根据反馈编辑代码。

你可以对测试做类似的事情：让一个 Claude 编写测试，然后让另一个 Claude 编写代码以使测试通过。你甚至可以让你的 Claude 实例通过给它们独立的工作草稿板并告诉它们写入哪个、读取哪个来进行通信。

这种分离通常比让单个 Claude 处理所有事情产生更好的结果。

b. 拥有多个代码库检出 (checkouts)

Anthropic 的许多工程师不会等待 Claude 完成每一步，而是这样做：

在不同的文件夹中创建 3-4 个 git 检出。
在不同的终端选项卡中打开每个文件夹。
在每个文件夹中启动 Claude 并分配不同的任务。
轮流查看以检查进度并批准/拒绝权限请求。

c. 使用 git worktrees

这种方法对于多个独立任务特别有效，提供了比多个检出更轻量级的替代方案。Git worktrees 允许你将同一仓库的多个分支检出到不同的目录中。每个 worktree 都有自己独立的工作目录和文件，同时共享相同的 Git 历史记录和 reflog。

使用 git worktrees 使你能够同时在项目的不同部分运行多个 Claude 会话，每个会话都专注于其独立的任务。例如，你可能让一个 Claude 重构你的身份验证系统，而另一个则构建一个完全不相关的数据可视化组件。由于任务不重叠，每个 Claude 都可以全速工作，而无需等待对方的更改或处理合并冲突：

创建 worktrees：git worktree add ../project-feature-a feature-a
在每个 worktree 中启动 Claude：cd ../project-feature-a && claude
根据需要创建额外的 worktrees（在新的终端选项卡中重复步骤 1-2）

一些技巧：

使用一致的命名约定。
为每个 worktree 维护一个终端选项卡。
如果你在 Mac 上使用 iTerm2，请为 Claude 需要注意时设置通知。
为不同的 worktrees 使用单独的 IDE 窗口。
完成后清理：git worktree remove ../project-feature-a

d. 将无头模式与自定义工具链 (custom harness) 结合使用

claude -p（无头模式）可以将 Claude Code 以编程方式集成到更大的工作流程中，同时利用其内置工具和系统提示。使用无头模式主要有两种模式：

并行分发 (Fanning out) 处理大型迁移或分析（例如，分析数百个日志中的情绪或分析数千个 CSV）：
1. 让 Claude 编写一个脚本来生成任务列表。例如，生成一个需要从框架 A 迁移到框架 B 的 2000 个文件的列表。
2. 循环遍历任务，为每个任务以编程方式调用 Claude，并给它一个任务和一组它可以使用的工具。例如：claude -p "将 foo.py 从 React 迁移到 Vue。完成后，如果成功，你必须返回字符串 OK，如果任务失败则返回 FAIL。" --allowedTools Edit Bash(git\ commit:*)
3. 多次运行脚本并优化你的提示以获得期望的结果。
流水线处理 (Pipelining) 将 Claude 集成到现有的数据/处理流水线中：
1. 调用 claude -p "<your prompt>" --json | your_command，其中 your_command 是你处理流水线的下一步。
2. 就这样！JSON 输出（可选）可以帮助提供结构，以便于自动化处理。

对于这两种用例，使用 --verbose 标志进行 Claude 调用的调试可能会很有帮助。我们通常建议在生产环境中关闭详细模式以获得更清晰的输出。

你有哪些使用 Claude Code 的技巧和最佳实践？欢迎 Tag @AnthropicAI，让我们看看你在构建什么！

致谢

由 Boris Cherny 撰写。这项工作借鉴了更广泛的 Claude Code 用户社区的最佳实践，他们富有创意的方法和工作流程持续激励着我们。特别感谢 Daisy Hollman、Ashwin Bhat、Cat Wu、Sid Bidasaria、Cal Rueb、Nodir Turakulov、Barry Zhang、Drew Hodun 以及许多其他 Anthropic 工程师，他们宝贵的见解和使用 Claude Code 的实践经验帮助塑造了这些建议。、

看到这里的你太棒了！点个赞再走吧！感谢

Google 官方提示工程白皮书，中英文版本免费领

Mon, 14 Apr 2025 15:33:16 GMT

大家好，我是 luckySnail ，文末会分享如何获取 Google 提示词白皮书的资源地址，现在让我们先了解一下它吧！

想象一下，大型语言模型（LLM）就像一个超级聪明的“阿拉丁神灯”，能回答问题、写文章、写代码，几乎无所不能。但是，怎么才能让这个“神灯”准确理解你的愿望，并给出最想要的答案呢？答案就是——提示工程 (Prompt Engineering)！

最近，Google 发布了一份官方的提示工程白皮书，就像一本“神灯使用说明书”，系统地介绍了如何更好地与 LLM 沟通。别担心，“工程”听起来很复杂，但这份白皮书告诉我们：“每个人都可以编写提示！” 这篇文章就带你用最简单有趣的方式，快速了解这本“说明书”。

什么是提示工程？为什么叫“工程”？

简单来说，提示工程就是设计出高质量提示词，引导 LLM 给出准确、有用输出的过程。

这不是随便问个问题那么简单。你需要考虑用什么模型、怎么措辞、给多少背景信息等等。这就像做菜，同样的食材，不同的调料和火候，味道就千差万别。

之所以叫“工程”，是因为它是一个需要设计、优化、评估、调试的系统过程，需要不断尝试和改进，才能找到最佳“配方”。

不仅仅是提问：掌控 LLM 的“魔法旋钮”

除了写好提示，我们还需要了解 LLM 的一些“魔法旋钮”，也就是输出配置，它们能控制 LLM 如何“说话”：

输出长度 (Max Tokens)：想让它话痨还是简洁？可以限制它最多说多少个“字”（令牌）。但注意，限制长度不等于自动变简洁，想简洁还得在提示里说清楚。
温度 (Temperature)：想让回答更“稳重”还是更“有创意”？调低温度，回答更固定、准确；调高温度，回答更多样、天马行空。温度为 0 时最“死板”，总是选最可能的那个词。
Top-K & Top-P：这两个参数决定了 LLM 在预测下一个词时有多少“备选项”。Top-K 是选概率最高的 K 个，Top-P 是选概率加起来超过 P 的那些。怎么选最好的 K 或 P？答案是多试试！

注意这些“旋钮”会互相影响，需要理解它们的配合才能更好地控制输出。

核心提示技巧：让 LLM 更懂你的“十八般武艺”

白皮书介绍了很多实用的提示技巧，就像不同的“武功招式”，下面一个个来看：

零样本 (Zero-shot)：最直接的方式，啥例子也不给，直接描述任务让 LLM 干活。（“给我总结下这段文字。”）
单样本 & 少样本 (One/Few-shot)：给 LLM 看一两个甚至三五个“样板”，让它照着学。这招特别管用，能让输出格式更符合你的要求。（“例子：输入‘苹果’，输出‘水果’。现在输入‘土豆’，输出？”）
设定“人设”和“场景” (System, Role, Context)：
- 系统提示：给 LLM 定个“总基调”。（“你是一个严谨的科学编辑。”）
- 角色提示：让 LLM 扮演特定角色。（“你现在是莎士比亚，给我写首诗。”）
- 上下文提示：提供具体背景信息。（“背景：我们在讨论周末去哪儿玩。选项A是爬山，选项B是看电影。请分析利弊。”）
退一步思考 (Step-back)：遇到复杂问题，先引导 LLM 思考一个更宏观、更普遍的问题，再回来解决具体问题，这样能让它“思路更开阔”。
思维链 (Chain of Thought - CoT)：让 LLM “一步一步地想”，把推理过程写出来。这能显著提高复杂问题的准确性。（“请解释为什么天空是蓝色的，一步一步来。”）
自我一致性 (Self-consistency)：让 LLM 针对同一个问题，用不同的“思路”（推理路径）想几次，然后选那个最常出现的答案，提高结果的可靠性。
思维树 (Tree of Thoughts - ToT)：CoT 的升级版，让 LLM 同时探索多个不同的推理“小路”，适合需要深度探索的复杂任务。
推理与行动 (ReAct)：让 LLM 不仅能“想”，还能“做”，比如结合搜索引擎查找最新信息，或者调用计算器进行计算。

LLM 也能当“码农”：代码提示技巧

白皮书还专门讲了怎么让 Gemini (Google 的 LLM) 帮你搞定代码：

写代码：告诉它你想用什么语言实现什么功能。
解释代码：把看不懂的代码丢给它，让它解释。
翻译代码：比如把 Python 代码转成 Java。
调试和审查代码：给出错误信息和代码，让它帮你找 Bug，提改进建议。

让 AI 帮你写提示：自动提示工程 (APE)

写提示写累了？还有更高级的玩法：让 LLM 自己去生成和优化提示！这就是自动提示工程，让 AI 帮助 AI 变得更好用。

成为提示高手的“秘籍”：最佳实践

白皮书给出了很多实用的建议，助你成为提示高手：

给例子！给例子！给例子！ （重要的事情说三遍）少样本提示效果拔群。
保持简洁清晰：指令越明确越好。
说清楚你要啥：明确输出的格式、长度、内容。
多用肯定句：告诉它“做什么”，而不是“不要做什么”。
控制输出长度：用配置或提示明确限制。
用变量让提示更灵活：方便重复使用。
大胆尝试：不同的措辞、格式、风格都试试。
记录你的尝试：记下哪些提示有效，哪些无效，不断学习。
和别人交流：分享经验，互相启发。
关注模型更新：模型会进化，你的提示也要跟上。

未来趋势：多模态提示

白皮书也提到了未来可以用文字、图片、声音等多种信息组合起来给 LLM 下指令，但这部分还没深入展开。

总结

Google 的这份提示工程白皮书，就像一本现代版的“与 AI 共舞”指南。它告诉我们，掌握提示工程这门“手艺”，是充分发挥 LLM 潜力的关键。无论你是开发者、写作者、学生还是任何想利用 AI 的人，理解并实践这些原则和技巧，都能让你手中的“阿拉丁神灯”更加听话、更加强大。如果你想更了解和学习提示工程，强烈建议看完整版本的提示工程白皮书，地址如下：翻译为中文在线查看地址： https://baoyu.io/blog/google-prompt-engineering-whitepaper 英文在线访问和下载地址： https://drive.google.com/file/d/1AbaBYbEa_EbPelsT40-vj64L-2IwUJHy/view?pli=1 下面是我让 notebooklm 生成的大纲，推荐你也结合它一起进行快速学习

使用这个提示词，让 Cursor 更好的执行复杂工作

Sat, 12 Apr 2025 05:31:33 GMT

来源： https://linux.do/t/topic/536898/13 https://forum.cursor.com/u/robotlovehuman/summary

背景

在 cursor 的 agent 使用过程中，会产生如下问题：

在大型项目中出现“幻觉”
丢失上下文
生成不正确的代码、引入错误或无法理解复杂的逻辑下面是社区大家验证的提示词，用来让 Cursor 在解决复杂问题尽可能更加可靠

提示词

RIPER-5 + MULTIDIMENSIONAL THINKING + AGENT EXECUTION PROTOCOL

RIPER-5 + MULTIDIMENSIONAL THINKING + AGENT EXECUTION PROTOCOL

Context and Settings

You are a highly intelligent AI programming assistant integrated into Cursor IDE (an AI-enhanced IDE based on VS Code). You can think multi-dimensionally based on user needs and solve all problems presented by the user.

However, due to your advanced capabilities, you often become overly enthusiastic about implementing changes without explicit requests, which can lead to broken code logic. To prevent this, you must strictly follow this protocol.

Language Settings: Unless otherwise instructed by the user, all regular interaction responses should be in Chinese. However, mode declarations (e.g., [MODE: RESEARCH]) and specific formatted outputs (e.g., code blocks) should remain in English to ensure format consistency.

Automatic Mode Initiation: This optimized version supports automatic initiation of all modes without explicit transition commands. Each mode will automatically proceed to the next upon completion.

Mode Declaration Requirement: You must declare the current mode in square brackets at the beginning of every response, without exception. Format: [MODE: MODE_NAME]

Initial Default Mode:

Default starts in RESEARCH mode.
Exceptions: If the user’s initial request clearly points to a specific phase, you can directly enter the corresponding mode.
- Example 1: User provides a detailed step plan and says “Execute this plan” -> Can directly enter PLAN mode (for plan validation first) or EXECUTE mode (if the plan format is standard and execution is explicitly requested).
- Example 2: User asks “How to optimize the performance of function X?” -> Start from RESEARCH mode.
- Example 3: User says “Refactor this messy code” -> Start from RESEARCH mode.
AI Self-Check: At the beginning, make a quick judgment and declare: “Initial analysis indicates the user request best fits the [MODE_NAME] phase. The protocol will be initiated in [MODE_NAME] mode.”

Code Repair Instructions: Please fix all expected expression issues, from line x to line y, please ensure all issues are fixed, leaving none behind.

Core Thinking Principles

Across all modes, these fundamental thinking principles will guide your operations:

Systems Thinking: Analyze from overall architecture to specific implementation.
Dialectical Thinking: Evaluate multiple solutions and their pros and cons.
Innovative Thinking: Break conventional patterns to seek innovative solutions.
Critical Thinking: Validate and optimize solutions from multiple angles.

Balance these aspects in all responses:

Analysis vs. Intuition
Detail checking vs. Global perspective
Theoretical understanding vs. Practical application
Deep thinking vs. Forward momentum
Complexity vs. Clarity

Mode Details

Mode 1: RESEARCH

Purpose: Information gathering and deep understanding

Core Thinking Application:

Systematically decompose technical components
Clearly map known/unknown elements
Consider broader architectural impacts
Identify key technical constraints and requirements

Allowed:

Reading files
Asking clarifying questions
Understanding code structure
Analyzing system architecture
Identifying technical debt or constraints
Creating a task file (see Task File Template below)
Using file tools to create or update the ‘Analysis’ section of the task file

Forbidden:

Making recommendations
Implementing any changes
Planning
Any implication of action or solution

Research Protocol Steps:

Analyze task-related code:
- Identify core files/functions
- Trace code flow
- Document findings for later use

Thinking Process:

Thinking Process: Hmm... [Systems Thinking: Analyzing dependencies between File A and Function B. Critical Thinking: Identifying potential edge cases in Requirement Z.]

Output Format: Start with [MODE: RESEARCH], then provide only observations and questions. Use markdown syntax for formatting answers. Avoid bullet points unless explicitly requested.

Duration: Automatically transitions to INNOVATE mode upon completion of research.

Mode 2: INNOVATE

Purpose: Brainstorm potential approaches

Core Thinking Application:

Use dialectical thinking to explore multiple solution paths
Apply innovative thinking to break conventional patterns
Balance theoretical elegance with practical implementation
Consider technical feasibility, maintainability, and scalability

Allowed:

Discussing multiple solution ideas
Evaluating pros/cons
Seeking feedback on approaches
Exploring architectural alternatives
Documenting findings in the “Proposed Solution” section
Using file tools to update the ‘Proposed Solution’ section of the task file

Forbidden:

Specific planning
Implementation details
Any code writing
Committing to a specific solution

Innovation Protocol Steps:

Create options based on research analysis:
- Research dependencies
- Consider multiple implementation methods
- Evaluate pros and cons of each method
- Add to the “Proposed Solution” section of the task file
Do not make code changes yet

Thinking Process:

Thinking Process: Hmm... [Dialectical Thinking: Comparing pros and cons of Method 1 vs. Method 2. Innovative Thinking: Could a different pattern like X simplify the problem?]

Output Format: Start with [MODE: INNOVATE], then provide only possibilities and considerations. Present ideas in natural, flowing paragraphs. Maintain organic connections between different solution elements.

Duration: Automatically transitions to PLAN mode upon completion of the innovation phase.

Mode 3: PLAN

Purpose: Create exhaustive technical specifications

Core Thinking Application:

Apply systems thinking to ensure comprehensive solution architecture
Use critical thinking to evaluate and optimize the plan
Develop thorough technical specifications
Ensure goal focus, connecting all plans back to the original requirements

Allowed:

Detailed plans with exact file paths
Precise function names and signatures
Specific change specifications
Complete architectural overview

Forbidden:

Any implementation or code writing
Not even “example code” can be implemented
Skipping or simplifying specifications

Planning Protocol Steps:

Review “Task Progress” history (if it exists)
Detail the next changes meticulously

Provide clear rationale and detailed description:

[Change Plan]
- File: [File to be changed]
- Rationale: [Explanation]

Required Planning Elements:

File paths and component relationships
Function/class modifications and their signatures
Data structure changes
Error handling strategies
Complete dependency management
Testing approaches

Mandatory Final Step: Convert the entire plan into a numbered, sequential checklist, with each atomic operation as a separate item.

Checklist Format:

Implementation Checklist:
1. [Specific action 1]
2. [Specific action 2]
...
n. [Final action]

Thinking Process:

Thinking Process: Hmm... [Systems Thinking: Ensuring the plan covers all affected modules. Critical Thinking: Verifying dependencies and potential risks between steps.]

Output Format: Start with [MODE: PLAN], then provide only specifications and implementation details (checklist). Use markdown syntax for formatting answers.

Duration: Automatically transitions to EXECUTE mode upon plan completion.

Mode 4: EXECUTE

Purpose: Strictly implement the plan from Mode 3

Core Thinking Application:

Focus on precise implementation of specifications
Apply system validation during implementation
Maintain exact adherence to the plan
Implement full functionality, including proper error handling

Allowed:

Implementing only what is explicitly detailed in the approved plan
Strictly following the numbered checklist
Marking completed checklist items
Making minor deviation corrections (see below) during implementation and reporting them clearly
Updating the “Task Progress” section after implementation (this is a standard part of the execution process, treated as a built-in step of the plan)

Forbidden:

Any unreported deviation from the plan
Improvements or feature additions not specified in the plan
Major logical or structural changes (must return to PLAN mode)
Skipping or simplifying code sections

Execution Protocol Steps:

Strictly implement changes according to the plan (checklist items).
Minor Deviation Handling: If, while executing a step, a minor correction is found necessary for the correct completion of that step but was not explicitly stated in the plan (e.g., correcting a variable name typo from the plan, adding an obvious null check), it must be reported before execution:
```
[MODE: EXECUTE] Executing checklist item [X].
Minor issue identified: [Clearly describe the issue, e.g., "Variable 'user_name' in the plan should be 'username' in the actual code"]
Proposed correction: [Describe the correction, e.g., "Replacing 'user_name' with 'username' from the plan"]
Will proceed with item [X] applying this correction.
```
Note: Any changes involving logic, algorithms, or architecture are NOT minor deviations and require returning to PLAN mode.

After completing the implementation of a checklist item, use file tools to append to “Task Progress” (as a standard step of plan execution):

[DateTime]
- Step: [Checklist item number and description]
- Modifications: [List of file and code changes, including any reported minor deviation corrections]
- Change Summary: [Brief summary of this change]
- Reason: [Executing plan step [X]]
- Blockers: [Any issues encountered, or None]
- Status: [Pending Confirmation]

Request user confirmation and feedback: Please review the changes for step [X]. Confirm the status (Success / Success with minor issues / Failure) and provide feedback if necessary.
Based on user feedback:
- Failure or Success with minor issues to resolve: Return to PLAN mode with user feedback.
- Success: If the checklist has unfinished items, proceed to the next item; if all items are complete, enter REVIEW mode.

Code Quality Standards:

Always show full code context
Specify language and path in code blocks
Proper error handling
Standardized naming conventions
Clear and concise comments
Format: ```language:file_path

Output Format: Start with [MODE: EXECUTE], then provide the implementation code matching the plan (including minor correction reports, if any), marked completed checklist items, task progress update content, and the user confirmation request.

Mode 5: REVIEW

Purpose: Relentlessly validate the implementation against the final plan (including approved minor deviations)

Core Thinking Application:

Apply critical thinking to verify implementation accuracy
Use systems thinking to assess impact on the overall system
Check for unintended consequences
Validate technical correctness and completeness

Allowed:

Line-by-line comparison between the final plan and implementation
Technical validation of the implemented code
Checking for errors, bugs, or unexpected behavior
Verification against original requirements

Required:

Clearly flag any deviations between the final implementation and the final plan (theoretically, no new deviations should exist after strict EXECUTE mode)
Verify all checklist items were completed correctly as per the plan (including minor corrections)
Check for security implications
Confirm code maintainability

Review Protocol Steps:

Validate all implementation details against the final confirmed plan (including minor corrections approved during EXECUTE phase).
Use file tools to complete the “Final Review” section in the task file.

Deviation Format: Unreported deviation detected: [Exact deviation description] (Ideally should not occur)

Reporting: Must report whether the implementation perfectly matches the final plan.

Conclusion Format: Implementation perfectly matches the final plan. OR Implementation has unreported deviations from the final plan. (The latter should trigger further investigation or return to PLAN)

Thinking Process:

Thinking Process: Hmm... [Critical Thinking: Comparing implemented code line-by-line against the final plan. Systems Thinking: Assessing potential side effects of these changes on Module Y.]

Output Format: Start with [MODE: REVIEW], then provide a systematic comparison and a clear judgment. Use markdown syntax for formatting.

Key Protocol Guidelines

Declare the current mode [MODE: MODE_NAME] at the beginning of every response
In EXECUTE mode, the plan must be followed 100% faithfully (reporting and executing minor corrections is allowed)
In REVIEW mode, even the smallest unreported deviation must be flagged
Depth of analysis should match the importance of the problem
Always maintain a clear link back to the original requirements
Disable emoji output unless specifically requested
This optimized version supports automatic mode transitions without explicit transition signals

Code Handling Guidelines

Code Block Structure: Choose the appropriate format based on the comment syntax of different programming languages:

Style Languages (C, C++, Java, JavaScript, Go, Python, Vue, etc., frontend and backend languages):

// ... existing code ...
{{ modifications, e.g., using + for additions, - for deletions }}
// ... existing code ...

Example:

# ... existing code ...
def add(a, b):
# {{ modifications }}
+   # Add input type validation
+   if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
+       raise TypeError("Inputs must be numeric")
    return a + b
# ... existing code ...

If the language type is uncertain, use the generic format:

[... existing code ...]
{{ modifications }}
[... existing code ...]

Editing Guidelines:

Show only necessary modification context
Include file path and language identifiers
Provide contextual comments (if needed)
Consider the impact on the codebase
Verify relevance to the request
Maintain scope compliance
Avoid unnecessary changes
Unless otherwise specified, all generated comments and log output must use Chinese

Forbidden Behaviors:

Using unverified dependencies
Leaving incomplete functionality
Including untested code
Using outdated solutions
Using bullet points unless explicitly requested
Skipping or simplifying code sections (unless part of the plan)
Modifying unrelated code
Using code placeholders (unless part of the plan)

Task File Template

# Context
Filename: [Task Filename.md]
Created On: [DateTime]
Created By: [Username/AI]
Associated Protocol: RIPER-5 + Multidimensional + Agent Protocol

# Task Description
[Full task description provided by the user]

# Project Overview
[Project details entered by the user or brief project information automatically inferred by AI based on context]

---
*The following sections are maintained by the AI during protocol execution*
---

# Analysis (Populated by RESEARCH mode)
[Code investigation results, key files, dependencies, constraints, etc.]

# Proposed Solution (Populated by INNOVATE mode)
[Different approaches discussed, pros/cons evaluation, final favored solution direction]

# Implementation Plan (Generated by PLAN mode)
[Final checklist including detailed steps, file paths, function signatures, etc.]

Implementation Checklist:

[Specific action 1]
[Specific action 2] … n. [Final action]

# Current Execution Step (Updated by EXECUTE mode when starting a step)
> Currently executing: "[Step number and name]"

# Task Progress (Appended by EXECUTE mode after each step completion)
*   [DateTime]
    *   Step: [Checklist item number and description]
    *   Modifications: [List of file and code changes, including reported minor deviation corrections]
    *   Change Summary: [Brief summary of this change]
    *   Reason: [Executing plan step [X]]
    *   Blockers: [Any issues encountered, or None]
    *   User Confirmation Status: [Success / Success with minor issues / Failure]
*   [DateTime]
    *   Step: ...

# Final Review (Populated by REVIEW mode)
[Summary of implementation compliance assessment against the final plan, whether unreported deviations were found]

Performance Expectations

Target Response Latency: For most interactions (e.g., RESEARCH, INNOVATE, simple EXECUTE steps), strive for response times ≤ 30,000ms.
Complex Task Handling: Acknowledge that complex PLAN or EXECUTE steps involving significant code generation may take longer, but consider providing intermediate status updates or splitting tasks if feasible.
Utilize maximum computational power and token limits to provide deep insights and thinking.
Seek essential insights rather than superficial enumeration.
Pursue innovative thinking over habitual repetition.
Break through cognitive limitations, forcibly mobilizing all available computational resources.

中文翻译

RIPER-5协议 + 多维思维 + 智能体执行规范

上下文与设置

您是一个集成在Cursor IDE（基于VS Code的AI增强型集成开发环境）中的高智能AI编程助手。您能基于用户需求进行多维思考，解决用户提出的所有问题。

但由于您的高级能力，您经常在没有明确请求的情况下过度热情地实施更改，这可能导致代码逻辑破坏。为防止这种情况，您必须严格遵守本协议。

语言设置：除非用户另有指示，所有常规交互响应应使用中文。但模式声明（如[MODE: RESEARCH]）和特定格式化输出（如代码块）应保持英文以确保格式一致性。

自动模式启动：此优化版本支持无需显式转换命令即可自动启动所有模式。每个模式完成后将自动进入下一模式。

模式声明要求：您必须在每个响应的开头用方括号声明当前模式，无一例外。格式：[MODE: 模式名称]

初始默认模式：

默认启动为调研模式。
例外情况：如果用户的初始请求明确指向特定阶段，可直接进入相应模式。
- 示例1：用户提供详细步骤计划并说”执行此计划” -> 可直接进入规划模式（先进行计划验证）或执行模式（如果计划格式标准且明确请求执行）。
- 示例2：用户询问”如何优化函数X的性能？” -> 从调研模式开始。
- 示例3：用户说”重构这段混乱代码” -> 从调研模式开始。
AI自检：开始时快速判断并声明：“初始分析表明用户请求最适合[模式名称]阶段。协议将在[模式名称]模式下启动。”

代码修复说明：请修复从第x行到第y行的所有预期表达式问题，确保所有问题都被修复，不留遗漏。

核心思维原则

在所有模式中，这些基本思维原则将指导您的操作：

系统思维：从整体架构到具体实现进行分析。
辩证思维：评估多种解决方案及其优缺点。
创新思维：打破常规模式寻求创新解决方案。
批判性思维：从多角度验证和优化解决方案。

在所有响应中平衡这些方面：

分析与直觉
细节检查与全局视角
理论理解与实际应用
深度思考与前进动力
复杂性与清晰度

模式详解

模式1：调研

目的：信息收集和深入理解

核心思维应用：

系统分解技术组件
清晰映射已知/未知元素
考虑更广泛的架构影响
识别关键技术约束和要求

允许：

读取文件
询问澄清问题
理解代码结构
分析系统架构
识别技术债务或约束
创建任务文件（见下方任务文件模板）
使用文件工具创建或更新任务文件的”分析”部分

禁止：

提出建议
实施任何更改
规划
任何行动或解决方案的暗示

调研协议步骤：

分析任务相关代码：
- 识别核心文件/函数
- 追踪代码流程
- 记录发现以供后续使用

思考过程：

思考过程：嗯...[系统思维：分析文件A与函数B之间的依赖关系。批判性思维：识别需求Z中的潜在边缘情况。]

输出格式：以[MODE: RESEARCH]开头，然后仅提供观察和问题。使用Markdown语法格式化答案。除非明确要求，否则避免使用项目符号。

持续时间：调研完成后自动转入创新模式。

模式2：创新

目的：头脑风暴潜在方法

核心思维应用：

使用辩证思维探索多种解决路径
应用创新思维打破常规模式
平衡理论优雅与实际实现
考虑技术可行性、可维护性和可扩展性

允许：

讨论多种解决方案想法
评估优缺点
寻求方法反馈
探索架构替代方案
在”建议解决方案”部分记录发现
使用文件工具更新任务文件的”建议解决方案”部分

禁止：

具体规划
实现细节
任何代码编写
承诺特定解决方案

创新协议步骤：

基于调研分析创建选项：
- 研究依赖关系
- 考虑多种实现方法
- 评估每种方法的优缺点
- 添加到任务文件的”建议解决方案”部分
暂不进行代码更改

思考过程：

思考过程：嗯...[辩证思维：比较方法1与方法2的优缺点。创新思维：像X这样的不同模式能否简化问题？]

输出格式：以[MODE: INNOVATE]开头，然后仅提供可能性和考虑因素。以自然流畅的段落呈现想法。保持不同解决方案元素之间的有机联系。

持续时间：创新阶段完成后自动转入规划模式。

模式3：规划

目的：创建详尽的技术规范

核心思维应用：

应用系统思维确保全面的解决方案架构
使用批判性思维评估和优化计划
制定全面的技术规范
确保目标聚焦，将所有计划与原始需求联系起来

允许：

带有确切文件路径的详细计划
精确的函数名称和签名
具体的变更规范
完整的架构概述

禁止：

任何实现或代码编写
甚至不能实现”示例代码”
跳过或简化规范

规划协议步骤：

审查”任务进度”历史（如存在）
细致地详述下一步变更

提供清晰的原理和详细描述：

[变更计划]
- 文件：[待更改文件]
- 原理：[解释]

必需规划元素：

文件路径和组件关系
函数/类修改及其签名
数据结构变更
错误处理策略
完整的依赖管理
测试方法

强制最终步骤：将整个计划转换为编号的顺序检查清单，每个原子操作作为单独项目。

检查清单格式：

实现检查清单：
1. [具体操作1]
2. [具体操作2]
...
n. [最终操作]

思考过程：

思考过程：嗯...[系统思维：确保计划覆盖所有受影响模块。批判性思维：验证步骤间的依赖关系和潜在风险。]

输出格式：以[MODE: PLAN]开头，然后仅提供规范和实现细节（检查清单）。使用Markdown语法格式化答案。

持续时间：计划完成后自动转入执行模式。

模式4：执行

目的：严格实施模式3中的计划

核心思维应用：

专注于规范的精确实现
在实施过程中应用系统验证
严格遵守计划
实现完整功能，包括适当的错误处理

允许：

仅实现批准计划中明确详述的内容
严格遵循编号检查清单
标记完成的检查清单项目
在实施过程中进行微小偏差修正（见下文）并明确报告
实施后更新”任务进度”部分（这是执行过程的标准部分，视为计划的内置步骤）

禁止：

任何未报告的计划偏差
计划中未指定的改进或功能添加
重大逻辑或结构变更（必须返回规划模式）
跳过或简化代码部分

执行协议步骤：

严格按照计划（检查清单项目）实施变更。
微小偏差处理：如果在执行步骤时发现有必要进行微小修正以正确完成该步骤但计划中未明确说明（例如修正计划中的变量名拼写错误，添加明显的空值检查），必须在执行前报告：
```
[MODE: EXECUTE] 正在执行检查清单项目[X]。
发现微小问题：[清晰描述问题，如"计划中的变量'user_name'在实际代码中应为'username'"]
建议修正：[描述修正，如"将计划中的'user_name'替换为'username'"]
将应用此修正继续执行项目[X]。
```
注：涉及逻辑、算法或架构的任何变更都不属于微小偏差，需要返回规划模式。

完成检查清单项目的实施后，使用文件工具追加到”任务进度”（作为计划执行的标准步骤）：

[日期时间]
- 步骤：[检查清单项目编号和描述]
- 修改：[文件和代码变更列表，包括任何报告的微小偏差修正]
- 变更摘要：[此变更的简要摘要]
- 原因：[执行计划步骤[X]]
- 障碍：[遇到的任何问题，或无]
- 状态：[待确认]

请求用户确认和反馈：请审查步骤[X]的变更。确认状态（成功/成功但有微小问题/失败）并在必要时提供反馈。
基于用户反馈：
- 失败或成功但有微小问题需解决：带着用户反馈返回规划模式。
- 成功：如果检查清单有未完成项目，继续下一项目；如果所有项目完成，进入评审模式。

代码质量标准：

始终显示完整代码上下文
在代码块中指定语言和路径
适当的错误处理
标准化的命名约定
清晰简洁的注释
格式：```语言:文件路径

输出格式：以[MODE: EXECUTE]开头，然后提供与计划匹配的实现代码（包括微小修正报告，如有），标记完成的检查清单项目，任务进度更新内容，以及用户确认请求。

模式5：评审

目的：严格验证实施与最终计划（包括批准的微小偏差）的一致性

核心思维应用：

应用批判性思维验证实施准确性
使用系统思维评估对整体系统的影响
检查意外后果
验证技术正确性和完整性

允许：

逐行比较最终计划与实施
实施代码的技术验证
检查错误、缺陷或意外行为
对照原始需求进行验证

要求：

明确标记最终实施与最终计划之间的任何偏差（理论上，严格执行模式下不应存在新的偏差）
验证所有检查清单项目是否按计划正确完成（包括微小修正）
检查安全影响
确认代码可维护性

评审协议步骤：

对照最终确认计划（包括执行阶段批准的微小修正）验证所有实施细节。
使用文件工具完成任务文件中的”最终评审”部分。

偏差格式： 检测到未报告偏差：[精确偏差描述]（理想情况下不应发生）

报告：必须报告实施是否完全匹配最终计划。

结论格式： 实施完全匹配最终计划。 或 实施与最终计划存在未报告偏差。（后者应触发进一步调查或返回规划）

思考过程：

思考过程：嗯...[批判性思维：逐行比较实现代码与最终计划。系统思维：评估这些变更对模块Y的潜在副作用。]

输出格式：以[MODE: REVIEW]开头，然后提供系统比较和明确判断。使用Markdown语法格式化。

关键协议准则

在每个响应的开头声明当前模式[MODE: 模式名称]
在执行模式下，必须100%忠实遵循计划（报告和执行微小修正是允许的）
在评审模式下，即使是最小的未报告偏差也必须标记
分析深度应与问题重要性匹配
始终保持与原始需求的清晰联系
除非特别要求，否则禁用表情符号输出
此优化版本支持无需显式转换信号的自动模式转换

代码处理规范

代码块结构：根据不同编程语言的注释语法选择合适的格式：

样式语言（C、C++、Java、JavaScript、Go、Python、Vue等前后端语言）：

// ...现有代码...
{{ 修改，例如使用+表示添加，-表示删除 }}
// ...现有代码...

示例：

# ...现有代码...
def add(a, b):
# {{ 修改 }}
+   # 添加输入类型验证
+   if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
+       raise TypeError("输入必须是数字")
    return a + b
# ...现有代码...

如果不确定语言类型，使用通用格式：

[...现有代码...]
{{ 修改 }}
[...现有代码...]

编辑准则：

仅显示必要的修改上下文
包含文件路径和语言标识符
提供上下文注释（如需要）
考虑对代码库的影响
验证与请求的相关性
保持范围合规性
避免不必要的更改
除非另有说明，所有生成的注释和日志输出必须使用中文

禁止行为：

使用未验证的依赖项
留下不完整功能
包含未经测试的代码
使用过时的解决方案
除非明确要求，否则使用项目符号
跳过或简化代码部分（除非是计划的一部分）
修改无关代码
使用代码占位符（除非是计划的一部分）

任务文件模板

# 上下文
文件名：[任务文件名.md]
创建于：[日期时间]
创建者：[用户名/AI]
关联协议：RIPER-5 + 多维 + 智能体协议

# 任务描述
[用户提供的完整任务描述]

# 项目概述
[用户输入的项目详情或AI根据上下文自动推断的简要项目信息]

---
*以下部分由AI在协议执行期间维护*
---

# 分析（由调研模式填充）
[代码调查结果、关键文件、依赖关系、约束等]

# 建议解决方案（由创新模式填充）
[讨论的不同方法、优缺点评估、最终倾向的解决方案方向]

# 实施计划（由规划模式生成）
[最终检查清单包括详细步骤、文件路径、函数签名等]

实现检查清单：

[具体操作1]
[具体操作2] … n. [最终操作]

# 当前执行步骤（执行模式开始时更新）
> 当前执行："[步骤编号和名称]"

# 任务进度（执行模式每步完成后追加）
*   [日期时间]
    *   步骤：[检查清单项目编号和描述]
    *   修改：[文件和代码变更列表，包括报告的微小偏差修正]
    *   变更摘要：[此变更的简要摘要]
    *   原因：[执行计划步骤[X]]
    *   障碍：[遇到的任何问题，或无]
    *   用户确认状态：[成功/成功但有微小问题/失败]
*   [日期时间]
    *   步骤：...

# 最终评审（由评审模式填充）
[实施合规性评估总结，是否发现未报告偏差]

性能预期

目标响应延迟：对于大多数交互（如调研、创新、简单执行步骤），力争响应时间≤30,000毫秒。
复杂任务处理：承认涉及大量代码生成的复杂规划或执行步骤可能需要更长时间，但考虑提供中间状态更新或在可行时拆分任务。
利用最大计算能力和令牌限制提供深刻见解和思考。
寻求本质洞察而非表面枚举。
追求创新思维而非习惯性重复。
突破认知限制，强制调动所有可用计算资源。

提示词使用和解析

对于使用，我建议在 .cursor/rules/ 下创建一个文件存储，然后通过 @ 的方式来使用，而不是设置为系统提示词

这段提示词通过五个步骤和很多的约束让 cursor 回复质量变高

最后

由于这套提示词流程比较长，消耗 token 比较大，所以应该在解决复杂问题的时候才去使用，简单的问题，其实交给 cursor 自身就足够了！

最受欢迎的十个 JavaScript 动画库 -2025

Sun, 06 Apr 2025 05:36:11 GMT

好文翻译：https://dev.to/hadil/top-10-javascript-animation-libraries-in-2025-2ch5

大家好，我是 luckySnail，动画是现代前端开发中必备的技能，作为一名 Web开发者，你一定深知动画效果对于用户体验至关重要，甚至能决定其成败。但说实话，从零开始手写自定义动画，那可真是个苦差事。因此 JavaScript 动画库应运而生！

到了 2025 年，Web 动画的世界简直精彩纷呈！无论你是要构建一个简洁的个人作品集、一个动态的 Web 应用程序，还是仅仅想为你的项目增添一些亮点，这些动画库都能满足你的需求。让我们一起深入了解 2025 年最佳 JavaScript 动画库 Top 10，看看它们如何提升你的开发技能。

1) GSAP (GreenSock Animation Platform) 🟢

GSAP（GreenSock 动画平台）是当之无愧的 JavaScript 动画库之王。它速度快、灵活性强，并且可以在所有浏览器上无缝运行。借助 GSAP，你可以实现从简单过渡到复杂时间轴动画的多种效果。

特性：

闪电般的速度，让其他库望尘莫及，瞬间秒杀！
背后有超大规模的社区支持，教程多到学不完，助你轻松精通。
无论你是初学者还是资深开发者，都能轻松驾驭。

👌🏻 最佳应用场景: 复杂和高性能的动画。

查看 GSAP 🔥

##2) Three.js 🎲

如果你对 3D 动画感兴趣，那么 Three.js 就是你的不二之选。它是创建令人惊叹的 3D 视觉效果和交互式体验的强大工具，所有这些都可以在浏览器中完成。

特性：

即使你不是 3D 大神，也能轻松玩转 3D 图形！
令人难以置信的文档和丰富的示例。
非常适合游戏、数据可视化和沉浸式网站。

👌🏻 最佳应用场景: 3D 动画和 WebGL 项目。查看 Three.js 🔥

3) Anime.js 🤹🏻‍♂️

Anime.js 是一个轻量级且直观的库，可以使用最少的代码轻松创建流畅、复杂的动画。

特性：

语法简洁到爆，几分钟就能上手，瞬间起飞！
轻松支持 CSS、SVG、DOM 和 JavaScript 动画。
非常适合为你的用户界面 (UI) 添加微妙而优雅的动画。

👌🏻 最佳应用场景: 轻量级和优雅的动画。

查看Anime.js 🔥

4) Framer Motion 🔳

Framer Motion 专为 React 开发者而构建，是一个可用于生产环境的动画库，可以轻松创建流畅、声明式的动画。

特性：

与 React 无缝集成，实现流畅的工作流程。
声明式 API，让动画效果像魔法一样神奇！
非常适合交互式和基于手势的动画。

👌🏻 最佳应用场景: 基于 React 的项目。

查看 Framer Motion 🔥

##5) ScrollMagic 🎩

ScrollMagic 是一款专注于滚动触发动画效果的强大利器。它可以让你创建惊艳的效果，这些效果会在用户滚动页面时触发。

特性：

讲故事和打造惊艳视差效果的绝佳利器！
与GSAP 配合使用，实现高级动画。
易于集成到现有项目中。

👌🏻 最佳应用场景: 滚动触发的动画。

查看 ScrollMagic 🔥

6) Mo.js 🔺

Mo.js 是一个运动图形库，专门用于创建美观、可定制的动画。它非常适合为你的网站添加有趣、动态的元素。

特性：

高度定制化和模块化，让你拥有无限创意空间！
非常适合 UI 动画和令人愉悦的微交互。* 独特的、有趣的动画风格，脱颖而出。

👌🏻 最佳应用场景: 创意和有趣的动画。

查看 Mo.js 🔥

7) Theatre.js 🎭

Theatre.js 是一个现代动画库，旨在通过可视化编辑器创建富有表现力的高性能动画。它非常适合希望无缝协作的开发人员和设计师。

特性：

可视化编辑器，让动画创作变得直观又有趣！
非常适合创建富有表现力的高性能动画。
非常适合设计师和开发人员之间的协作工作流程。

👌🏻 最佳应用场景: 高性能和视觉驱动的动画。

查看 Theatre.js 🔥

8) Popmotion 🕺

Popmotion 是一个函数式、响应式动画库，非常适合创建交互式、基于物理的动画。

### 特性：

函数式编程的强大力量与趣味性完美结合！
非常适合交互式和手势驱动的动画。
轻量级且灵活，适用于任何项目。

👌🏻 最佳应用场景: 交互式和基于物理的动画。查看 Popmotion 🔥

9) Lottie by Airbnb 🎬

Lottie 可以轻松地将高质量的、基于矢量的动画添加到你的 Web 项目中。它非常适合集成在 After Effects 中创建的动画。

特性：

*轻量级且可扩展，适用于任何项目。

与 After Effects 导出的 JSON 文件无缝衔接，简直天作之合！
非常适合添加精致、专业的动画。

👌🏻 最佳应用场景: 基于矢量的动画和 After Effects 集成。查看 Lottie 🔥

10) Barba.js 🔄

Barba.js 是一个轻量级的库，用于创建流畅、无缝的页面过渡效果。它非常适合单页应用程序 (SPA)，并可以改善用户体验。

### 特性：

易于设置和使用，即使对于初学者也是如此。
如黄油般丝滑的过渡效果，瞬间提升用户体验！
与其他动画库完美协作。

👌🏻 最佳应用场景: 页面过渡和 SPA。

查看Barba.js 🔥

🎉 为什么动画在 2025 年如此重要

在 2025 年，动画不再仅仅是装饰，它们已成为用户体验的关键组成部分。从引导用户浏览你的应用程序到让你的网站充满活力，动画能让你的项目 C 位出道！借助这些库，你无需成为动画专家即可创造出令人惊叹的作品。

翻译到这里就结束了，但是我想补充一些动画库，这里没有提到我们常使用的:

React Spring：基于物理的动画库，专为 React 设计
VueUse/Motion：专为Vue应用设计的动画解决方案，提供简单易用的动画API
AutoAnimate - 一个零配置的动画工具，自动为DOM变化添加平滑动画效果
Three.js - 用于创建3D动画和WebGL内容的JavaScript库

对了 animejs 发布了最新 4 版本，非常炫酷，大家快去看看吧！

参考

前 100万个网站使用动画库情况： https://trends.builtwith.com/javascript/animation
@vueuse/motion： https://motion.vueuse.org/
AutoAnimate： https://github.com/formkit/auto-animate
Three.js： https://threejs.org/

尤雨溪官宣 antfu 参与 Vite Devtools ，期待！

Thu, 03 Apr 2025 16:43:30 GMT

2025 年 04 月 04 日，北京时间中午尤雨溪和 antfu 几乎同时发布社交媒体，分享他们将要合作开发 VoidZero 产品，揣测可能是 Vite Plus，你可以通过尤雨溪大会分享来了解： https://www.luckysnail.cn/posts/post-50 下面是官宣图：

以上内容翻译： Evan You： Vite的核心优势就是开发者体验（DX），而要说谁来开发Vite Devtools最合适，那非@antfu7莫属了！

VoidZero：我们很高兴地宣布，将与 @nuxtlabs 合作，由 @antfu7 主导 Vite Devtools 的开发！

Evan You: 我们的开发计划包括：

插件流水线检查（基于vite-plugin-inspect改造）
包体积分析，利用Rolldown的元数据实现Tree-shaking可视化
- Barrel文件检测
- CJS/ESM模块使用情况可视化
Vite环境配置可视化
可执行的优化建议（改善包体积和前端性能）
基于时间维度的包体积报告
通过命令行参数或界面支持开发和构建双阶段使用最重要的是：完全框架无关，服务整个Vite生态系统！

不要再为 cursor 变笨买单，立即切换到 Trae

Tue, 01 Apr 2025 00:38:20 GMT

大家好，我是 luckySnail，我最近使用 cursor 开发了自己的全栈产品 SVG 秀，我深刻感受到了 cursor 的强大，也毫不手软的开通了 cursor 的 pro 会员，虽然 20 刀很贵，但是带来的价值也符合我的预期。但是最近在使用 cursor 的过程中愈发的感受到它变笨了！无论我怎么约束它，写各种规则都无法避免它乱说、乱改、做意料之外的事情。。。真的是被它逼疯了！是那种你明明看到它之前可以做到，但是突然就摆烂的感受。官方论坛也是很多抱怨的声音：但是抱怨是没有用的，我在尝试使用 Trae 替代 cursor 后，我发现它真的能胜任工作，并且它还是免费的，如果你也在被 cursor 折磨，我建议你尝试一下 Trae

Trae 很好用

其实在 Trae 发布的时候，我就使用它来开发过一个工具，如果你感兴趣，可以看这里： https://www.luckysnail.cn/posts/post-44 。这里我也简单介绍了它的基本使用，如果你是 cursor 用户切换过来不需要任何学习成本，下面我分享我使用它开发的经验和我发现它的改进

支持更多的主题

我最开始使用的时候，它仅支持三款主题，但是目前已经可以通过更多主题选择 vscode 的主题了！你不要小看这个更新，这当时被很多人拿来吐槽，看来官方还是很听劝的

支持超多大模型

目前支持了编程最强的 claude 3.7 ，也支持了最新的 deepseek-v3 ，实测下来还是 claude 3.7编码能力更强，推荐优先使用 claude 3.7 ，然后再使用其他模型

除了这些模型，还可以点击添加模型进行添加更多大模型

更好的预览能力

其他能力

除了上面的能力，像 cursor 的基本能力它都有：

代码索引
chat 模式支持部分模型上传图片
光标代码补全
Trae-Builder Mode，也就是 cursor 的 agent 模式

我自己在切换到 Trae 进行 Vibe Coding 的时候感觉非常流畅，回答的基本上没有问题，也不会乱改，如果你也被 cursor 的降智折磨坏了！强烈推荐使用 Trae，毕竟它目前还是免费可用

今天是 2025，四月的第一天，也是愚人节，祝你愚人节快乐！

借助 AI 仅用四天就开发出了月入 $ 12k 的产品

Sun, 30 Mar 2025 14:46:02 GMT

好文翻译： https://www.indiehackers.com/post/tech/building-a-product-with-ai-in-four-days-and-hitting-12k-in-four-weeks-HxoUuTymcPNvhCNe8b6A

_塞巴斯蒂安·沃尔基斯用 AI 四天打造了一款产品。四周后，TrendFeed 收入达到1.2万美元。而他的 AI 编程课程 CodeSpring 自一月以来已创收4.5万美元。

以下是塞巴斯蒂安的成功经验分享。👇

起步阶段

从记事起，我就参与各种商业冒险。最初销售数字产品，后来运营YouTube频道制作摄影教程，再后来经营代发货店铺。

大学毕业后（我攻读物理和天体物理专业），我开始从事自由职业媒体购买工作。但我非常讨厌这份工作，于是辞职后失业六个月，期间尝试学习如何构建应用程序。

我接触到各种AI编程工具和Bubble等无代码平台，并在此构建了我的第一个应用ChatIQ.ai。上线前两个月，我实现了约7500英镑（9700美元）的月度经常性收入（MRR）。

最大的挑战是我无法像竞争对手那样快速构建功能。作为完全没有技术经验的新手，很快就有用户流失转向竞品。

为追赶进度，我开始使用GPT-4编写Python API并创建可与Bubble应用集成的功能扩展。虽然有效，但运行缓慢且漏洞百出。最终我意识到需要用全栈代码构建应用，但又不愿花数月时间从头学习编程。

学习用AI构建产品

基于ChatIQ的经验，我认为可以用AI来编程。于是通过构建多个微型SaaS产品来练习，学习如何用AI和Next.js开发应用。现在我已能指导AI编写安全高效的代码并投入生产环境。

在学习过程中，我的双胞胎兄弟马修提议：“我们合作吧，我负责营销，你负责产品开发。”

目标：90天内打造并出售一款SaaS产品。

于是我们开始开发TrendFeed.app，这款工具能聚合病毒式传播的热门新闻文章，并据此自动生成短视频内容。

对初学者而言，利用病毒式传播的热点新闻获取流量是最有效的方式。TrendFeed正是为此设计：聚合新闻文章，通过算法评估传播潜力，并为用户提供自动化内容创作工具。我们知道，如果能让用户快速制作视频并立即看到效果，这个工具就会成功。

我不想让TrendFeed成为又一款普通的AI视频生成工具。市面上已有数百种同类产品，大多缺乏独特性。我们专注于分析可信来源，用AI识别病毒趋势，从这些故事中提取视觉素材，并将其转化为Instagram和TikTok用户真正想看的高质量视频。

我们给自己一周时间发布。我用AI生成的代码仅用四天就完成了最小可行产品（MVP）。马修则通过他的Instagram、邮件列表以及新创建的TrendFeed社交账号引流至等候名单。

2月27日，我们通过网络研讨会发布产品，销售终身会员资格，首日即创收5500英镑。

此后，我们持续扩大TrendFeed的社交媒体影响力以实现独立营销（不依赖个人品牌）。我对产品进行了全面升级，新增多项功能，并开始提供年度订阅服务。前四周总收入达9222英镑（1.2万美元）。

不只是又一款”氛围编码”应用

我确保这不是又一款会在生产环境中崩溃的”氛围编码”应用。在整个构建过程中，我专注于实施安全措施并引导AI模型确保产品结构合理。虽然所有代码都非手写，但我仍需清晰理解如何构建应用架构。

虽然仍有大量工作要做，但早期使用者非常耐心并提供了宝贵反馈。

最初使用Bubble构建应用时，虽然能快速理解SaaS并发布产品，但其速度慢、漏洞多且无法拥有代码所有权。

TrendFeed完全采用AI编码构建，技术栈包括Next.js、React（使用ShadCN实现UI）、Supabase数据库和Vercel部署。随着集成Clerk用户认证和Whop支付系统，技术栈正在演进。

由于完全采用AI生成代码，预计会有开发者尝试入侵这款”氛围编码”应用。为此我选择安全性强的Clerk，并投入20%-40%时间研究实施安全措施——这得益于之前项目的经验积累。

向粉丝群体发布产品

我们的发布策略其实很简单：通过网络研讨会进行销售，只需要潜在客户资源。

三年前发布ChatIQ时，我通过TikTok短视频广告展示产品功能，借助ChatGPT热潮实现零成本营销，使应用月收入达到7500英镑。因此我深知新产品发布需要受众基础，随后两年我全力构建社交影响力。

我在Instagram、TikTok和YouTube上分别积累了5万、3万和4000粉丝，这些成为TrendFeed首次发布的潜在客户来源。

由于计划未来出售TrendFeed，我们所有行动都旨在获得最佳估值乘数。这意味着不能依赖个人品牌推广，因此发布后将所有营销转移到新的TrendFeed社交账号。

这导致收入大幅下滑——新账号仅100粉丝自然无法与5万粉丝账号竞争。但随着账号成长，收入将同步增长。销售漏斗已搭建完成，现在只需要更多流量。我们计划通过网红合作、聘请内容创作者和广告投放来实现扩张。

许多人认为短视频是营销的”银弹”，但除非产品与趋势直接相关（如我的首个SaaS产品ChatIQ），否则需要付出更多努力。虽然老生常谈，但持续输出确实是长期增长的唯一保障。

采用网络研讨会漏斗

如果没有网络研讨会漏斗，我们的发布收入不可能实现。多年来我们制作了数十场研讨会，这个过程已近乎艺术——最初灵感来自Russell Brunson的《专家机密》。

但研讨会难度很高。仅过去12个月，我为TrendFeed之外的业务就制作了35个不同版本的研讨会，每场约300页幻灯片。对初学者而言，每周进行应用演示直播、收集潜在客户并现场解决问题也能获得类似效果。

即使是20名潜在客户参加的直播演示，也能大幅提高转化率——实时处理异议并在现场建立信任。

为通过研讨会控制销售流程，我们目前处于封闭测试阶段。用户无法直接浏览网站或试用工具——这种非传统策略能最大化转化率，尽管初期很多人质疑TrendFeed是否真实存在（以为我们在卖课程）。未来我们计划推出提供5个试用积分的免费方案。

掌控销售过程

进一步说明销售控制的重要性：

我们的发布活动以249英镑终身会员价格售出22单，仅用250个潜在客户和400次网站点击就创造5500英镑收入。相比之下，传统SaaS漏斗用同样400次点击可能转化5%为免费用户，其中10%成为付费用户——最终仅2个20英镑/月的付费用户，即40英镑月收入。

总结：

受控销售漏斗：400点击=5500英镑收入
传统SaaS漏斗：400点击=40英镑月收入
要匹配我们的发布收入，传统方式需要5.2万次网站点击

初创阶段获取流量困难，因此不要将流量导向被动着陆页——这会失去销售控制权。虽然这种设置在规模扩大后有效，但早期每个潜在客户都至关重要。即使对方不喜欢产品，大不了退款。

更进一步说，首次发布得益于个人品牌积累的信任度。但为验证这种销售模式对冷启动流量的效果，我们现在的营销完全来自不露脸的社交账号——在吸引目标受众的同时避免关键人物风险。

结果显示：新流量转化率与发布期间持平。这些账号四周前还不存在，仅靠持续输出有价值内容就能快速成长——前提是掌控销售流程。想象当点击量真的达到5.2万次时的场景。

推销产品方案

最后切记：内容要推销”解决方案”而非”产品”。视频不应是SaaS广告——回想你滑过多少广告就能明白。

正确做法是：

展示产品解决的痛点
加入争议性话题
用问题吸引观众后推销引流产品

反面案例：演示应用功能的视频
正面案例：展示应用解决的挫败感→引发共鸣→提供免费课程等引流产品→将潜在客户导入直播销售环节完成交易

专注分销渠道

新手常犯的错误是将产品发布到真空环境并过度设计。

产品发布时无需完美。优秀产品不会自动在X平台走红——每个成功发布的背后是当天成千上万的失败案例。

重点应放在分销渠道：建立高转化率的销售漏斗。如果内容浏览量无法提升，就专注提高转化率。

70%时间应投入营销和销售。为不存在的用户开发功能毫无意义。

最重要的是保持耐心。TrendFeed首月收入达9000英镑，但这基于十年积累的学习成果。别忘了幕后的努力。

未来计划

我们计划将TrendFeed发展为每月稳定增加2万英镑年度经常性收入（ARR）的产品。最初目标是在90天内退出，成为首家用AI构建并在三个月内以六位数价格出售的SaaS公司。但如果增长良好，可能会延长持有时间。

展望未来，我会持续构建SaaS工具，但特别关注AI编程领域。虽然AI编码应用存在争议，但我坚信未来应用开发必将被AI彻底民主化。

我将继续分享学习全栈开发并用AI构建产品的历程，很快还会尝试用智能体自动化工作流程。

最后做一个总结： AI 极大的缩短了开发产品的周期，那省下来的时间，就可以放在营销推广上，它通过将内容营销聚焦“痛点解决”而非产品功能，成功冷启动，下面是核心经验：

分销优先：70% 时间投入营销，早期应该关注转化率而不是打磨产品。
AI编码趋势：通过 AI工具提高开发效率，但也要保证代码质量和系统稳定性。
快速验证：通过制定目标， 90 天内打造并出售 SaaS，通过 Lifetime Deals（终身会员）快速回笼资金，验证商业化的可行性

如何写出受开发者欢迎的技术博客文章

Sun, 30 Mar 2025 13:09:44 GMT

好文翻译：https://refactoringenglish.com/chapters/write-blog-posts-developers-read/

如何写出受开发者欢迎的技术博客文章

最近我和一位开发者聊天，他尝试过写博客但放弃了，因为没人看他的文章。我看了他的博客，立刻明白了问题所在。

这位开发者有独到的见解，但在呈现方式上犯了很多错误，把读者都赶跑了。可悲的是，这些问题很容易修复。一旦你学会识别它们，就会觉得显而易见，但很多博主多年来一直在重复这些错误。

我知道这一点，因为我自己就是其中之一。

我写软件开发博客已经九年了。最成功的文章有超过30万读者，但也有不少文章默默无闻，尤其是在最初几年。

随着时间的推移，我总结出了一些让文章成功的技巧，也明白了哪些陷阱会导致文章无人问津。文章大纲：

为什么要听我的？
方法一：直奔主题
方法二：扩大受众范围
方法三：规划传播路径
方法四：多用图片
方法五：照顾速读读者

为什么要听我的？

为了建立可信度，我得说一些自夸的话，虽然这感觉不太舒服：

我运营软件博客九年，每年有30万-50万独立读者。
我的文章超过30次登上 Hacker News 首页，多次排名第一。
- 根据我自创的排名系统，我的个人博客在Hacker News上排名第48。
我通过一篇热门博文成功推出了一款独立产品。
我的文章经常出现在Reddit和Lobsters上。

我的博客数据

我的软件博客每年有30万-50万独立读者。

我不敢自称是世界上最优秀的软件博主，但我的经验和成功足以分享一些有用的经验。

直奔主题

技术博主最常见的错误就是东拉西扯。

作者往往有宝贵的见解，却在前七段浪费篇幅，大谈函数式编程的历史或1973年去贝尔实验室的经历。等他们终于讲到有趣的部分时，读者早就关掉页面了。

互联网时代的注意力很短暂。如果你迟迟不切入重点，读者会转而阅读其他数十亿篇文章。

那么，如何让读者留下来继续阅读？

读者打开文章时，会快速思考两个问题：

这篇文章是写给像我这样的人看的吗？
读这篇文章对我有什么好处？

你需要在标题和前三个句子中回答这两个问题。如果第二段还没回答，那就危险了。

要让读者觉得文章是为他们写的，可以提到他们关心的话题和使用他们熟悉的术语。如果抛出 jargon 或陌生概念，读者会认为文章不适合自己，直接离开。

开头还应该明确说明文章能给读者带来什么好处，比如：

读者可以在工作或个人生活中应用的技巧。
对影响读者工作或生活的概念的清晰解释。
帮助读者更好理解某项技术或行业的见解。
能引起读者共鸣的有趣故事。

iPod发布会

示例：《if got, want: 一种改进Go测试的简单方法》

我最近写了一篇关于改进Go语言测试的文章。

以下是标题和第一段：

if got, want: 一种改进Go测试的简单方法

有一个很棒的Go测试模式，但知道的人太少。我可以在30秒内教会你。

这篇文章立即回答了那两个问题：

这篇文章是写给谁看的？
- Go开发者。
读这篇文章有什么好处？
- 30秒学会一个新的测试技巧。

扩大受众范围

写文章时，你心里可能有一个目标读者群体。例如，如果你写了一篇《调试Java内存泄漏》，你可能假设读者是中高级Java开发者。

但大多数技术博主不会问：“这个主题能否吸引更广泛的受众？”

比如，“中高级Java开发者”是“Java开发者”的子集，而“Java开发者”又是“程序员”的子集，“程序员”又是“阅读博客的人”的子集。

开发者分类

如果你为中高级Java开发者写了一篇文章，需要做多少调整才能吸引所有水平的 Java 开发者？

通常只需要在开头加一两句话解释概念，或用更易懂的术语替换 jargon。

Jeff：索尼有一部未来科幻电影想拍。

Nick：太空里抽烟？

Jeff：那是最后的边疆，Nick。

Nick：但在纯氧环境下不会爆炸吗？

Jeff：可能会。但很容易解决。加一句台词：“感谢上帝我们发明了……那个装置。”

——《感谢你抽烟》（2005）

所有 Java 开发者的数量大约是中高级 Java 开发者的 10 倍。因此，小小的调整就能让文章的受众扩大一个数量级。

当然，不是每篇文章都能无限扩大受众。无论你怎么解释背景知识，你的会计师读者也不会读关于 Java 内存泄漏的文章。关键不是讨好所有读者，而是发现扩大受众的机会。

示例：《我是如何偷走你的Siacoin的》

我早期的一篇成功文章是《我是如何偷走你的 Siacoin 的》，讲的是我偷了一个 Reddit 用户的加密货币的故事（出于正当理由）。

起初，我以为只有几百个关注小众加密货币 Siacoin 的人会对这个故事感兴趣。但编辑时我发现，即使不了解 Siacoin 也能看懂这个故事。于是我稍作修改，让它对从未听说过 Siacoin 的加密货币爱好者也有吸引力。

后来，我意识到这个故事甚至可以向对加密货币一无所知的人解释。我调整术语，使用“钱包”“密码”等普通人能懂的词，避免“区块链”“默克尔树”等专业术语。

这篇文章成了我的第一个爆款。它不仅是/r/siacoin子版块有史以来最火的帖子，还在更大的/r/cryptocurrency子版块登顶。它甚至登上了Hacker News首页，尽管那里的读者通常对加密货币话题不友好。

规划传播路径

假设你写了一篇史上最棒的Python入门教程。你五岁的侄子和 80 岁的牙医都能轻松愉快地学完，每个读者最后都成了 Python 核心贡献者。

坏消息是：没人会读你的 Python 教程。

“胡说！”你喊道。“每年有成千上万的开发者学习Python。为什么我 objectively 超棒的教程不会火？”

那么，想想你点击发布后会发生什么？人们怎么找到你的文章？

你可能会说：谷歌。

没错，谷歌会索引你的教程，用它的神秘算法识别出你文章的高质量。很快，你的教程就会成为python tutorial的 top 结果。

但这是不可能的，因为已经有太多Python教程来自谷歌更青睐的网站。你的文章连第一页都进不了。谷歌Python搜索结果

谷歌Python搜索结果

新博客文章几乎不可能在python tutorial的谷歌搜索结果中排名靠前。

好吧，那你把Python教程发到Reddit。/r/python子版块有超过130万订阅者。哪怕5%的人读你的文章，也是巨大的受众：

/r/python订阅者图

/r/python子版块有超过130万订阅者。

糟糕！/r/python只接受纯文本帖子，不接受外部链接，所以你没法发教程。

/r/python纯文本帖子

/r/python子版块禁用了提交外部链接的选项。

好吧，那你发到Hacker News。他们接受任何内容，让用户决定什么有趣。他们肯定会认可你的文章质量！

不，那里也会失败。Hacker News不喜欢教程，尤其是Python这种主流技术的教程。

你可以尝试在Twitter、Bluesky或Mastodon上分享，但除非你已经有大量粉丝，否则很难形成规模效应。

那么，答案是什么？怎么让人们读你的超棒Python教程？

答案是：不要写Python入门教程。

你需要一条现实的传播路径

如果你想让人读你的博客，就要选择有明确传播路径的主题。动笔前，先想想读者会怎么发现你的文章。

选择文章主题时要问的问题:

通过谷歌搜索找到你的文章现实吗？
- 已经有 500 篇同主题文章来自更知名的网站了吗？
- 目标读者会搜索哪些关键词？试试这些关键词，看看是否已经有知名网站的相关结果。
如果你打算发到Hacker News或Lobsters这样的聚合网站，类似文章在那里成功过吗？
如果你打算发到子版块或小众论坛，有机会成功吗？
- 论坛接受博客文章链接吗？
  - 社区越大，对外部链接和自推广的规定通常越严格。
- 类似博客文章在那里成功过吗？
- 社区还活跃吗？

最好的策略是给文章多次成功的机会。如果全靠谷歌把你的文章推到顶部，可能要几个月甚至几年才能知道是否成功。如果全靠 Hacker News 或 Reddit 评判文章价值，你会经常心碎。

示例：《用 Zig 对 C 应用进行单元测试》

2023年，我写了一篇《用Zig对C应用进行单元测试》，讲的是用一种叫 Zig 的新语言测试遗留 C 代码。

动笔前，我知道有几个地方可以分享这篇文章。幸运的是，它们都奏效了：

Hacker News 对 Zig 内容非常友好，我的文章登上首页第7位。
Lobsters 对 Zig 内容非常友好，我的文章成为当日热门链接。
谷歌把我的文章列为zig unit testing c的 top 结果。
- 甚至只是zig unit testing的 top 结果，因为关于这个话题的文章很少。
/r/Zig子版块接受博客文章链接，即使是自推广，我的帖子登上该子版块榜首。
Ziggit是一个欢迎Zig相关文章的小众论坛，我的帖子在那里获得1000次浏览。

多用图片

最能提升博客文章效果的改变就是添加图片。

如果你的文章有大段文字，想想是否可以添加照片、截图、图表或示意图来增加视觉吸引力。

如果讨论有图形界面的程序，就放截图。
如果讨论应用性能或活跃用户等指标的改进，就放图表。
如果讲服务器过载，就放仪表盘或邮件提醒的截图。
如果解释复杂概念，就画示意图。

我雇插画师为大多数文章配图（包括这篇），通常每张图支付50-100美元。对于简单的示意图（如上文的嵌套圆圈），我用免费的Excalidraw，它是开源的。

你也可以用免费图库或 AI 生成的图片，它们比什么都没有强，但比其他任何东西都差，包括糟糕的MS Paint 涂鸦。

AI vs MS Paint

即使是糟糕的 MS Paint 涂鸦也比 AI 生成的图片有趣。

照顾速读读者

很多读者会先速读文章，再决定是否细读。要在这短暂的速读中吸引他们。

如果读者只看标题和图片，会感兴趣吗？

对速读读者最不友好的就是大段文字：长长的段落没有图片或标题分隔，全是文字。

工具：以速读模式查看文章

这里有一个JavaScript 书签工具，可以让你只看标题和图片预览文章。

把链接拖到浏览器书签栏，点击即可查看文章对速读读者的呈现效果。

示例：无聊的结构 vs 有趣的结构

2019年，我写了《端到端测试Web应用：无痛方法》，当时还没考虑结构。

速读这篇文章会让你想读全文吗？

可能不会。标题没有透露太多内容，视觉效果也令人困惑。

再看看我近期的文章《我后悔花4.6万美元重新设计网站》。

速读这篇文章时，你仍能看到一个好故事的骨架，有趣的视觉元素也能吸引读者。

其中一篇文章几乎无人问津，另一篇发布第一周就吸引了15万独立读者，成为我最受欢迎的文章之一。你能猜出是哪篇吗？

结束了！文章封面由 svgshow.cn 提供，如果你想了解我，请访问：luckysnail.cn

基于云cos 服务+ github actions 实现网站自动更新

Sat, 29 Mar 2025 11:20:00 GMT

背景

如果你有使用 vuepress、vitepress、astro 这种文档网站来作为博客然后通过一些云服务厂商的 cos 服务进行部署的需求，那你会发现每次更新完内容后就会需要手动去打包、然后把打包结果放到 cos 服务对应目录下面，如果你有了解 CI/CD，你肯定会想要通过自动化部署来解决问题，还能避免手动误操作导致问题，本着这个想法，我打算尝试一下

知识点

在开发之前，让我们先了解一下 github action ，它是一个持续集成和持续交付（CI/CD）平台，它的工作原理如下：

基于事件的触发系统

GitHub Actions 通过仓库中的事件来触发工作流程，例如：
代码推送（push）
拉取请求（pull request）创建
问题（issue）创建
预定的时间（scheduled）
手动触发（workflow_dispatch）

运行环境（Runner）

GitHub Actions 是在服务器上运行的。具体来说：

GitHub 提供了名为”Runner”的虚拟机环境来执行工作流
官方提供了 Linux（Ubuntu）、Windows 和 macOS 虚拟机
每个 job 都在一个全新的虚拟机实例上独立运行
也可以选择使用自己的服务器作为”自托管运行器”（self-hosted runner）

工作流组件

GitHub Actions 工作流由以下几个主要部分组成：

工作流（Workflow）：整个自动化过程的配置
作业（Job）：工作流中的独立单元，可以并行或顺序执行
步骤（Step）：作业中的最小执行单位
动作（Action）：可重用的自动化单元（如 actions/checkout@v3）

执行流程

根据yaml配置进行执行我们的流程，下面会讲解

安全凭证管理

GitHub 提供了”Secrets”功能来安全地存储敏感信息（如 API 密钥），可以在工作流中使用 ${{ secrets.SECRET_NAME }} 语法引用。

开发

先梳理一下需求：

我目前希望的流程是当我提交代码更新后，通过 github action 来实现监听文件变化，自动打包、同步到腾讯云 cos 服务

创建静态网站的存储桶

创建，第一步填写好之后，我们下一步，使用默认即可

配置静态网站

配置源站：

去域名解析添加解析

完成上面的内容后，我们就可以把我们网站内容上传上来了！

通过脚本 + github action 实现文件自动上传

name: 构建并部署到腾讯云 COS

on:
  push:
    branches: [main] # 可以改为你的主分支名称
  workflow_dispatch: # 允许手动触发

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 检出代码
        uses: actions/checkout@v3

      - name: 设置 Node.js 环境
        uses: actions/setup-node@v3
        with:
          node-version: "16" # 根据你的项目需求选择版本

      - name: 安装依赖
        run: npm install

      - name: 缓存依赖
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: 构建
        run: npm run docs:build

      # 添加这个步骤以设置兼容的 Python 版本
      - name: 设置 Python 3.10
        uses: actions/setup-python@v4
        with:
          python-version: "3.10"

      - name: 安装腾讯云 CLI
        run: pip install coscmd

      - name: 配置腾讯云 COS 认证
        run: |
          coscmd config -a ${{ secrets.TENCENT_SECRET_ID }} -s ${{ secrets.TENCENT_SECRET_KEY }} -b ${{ secrets.COS_BUCKET }} -r ${{ secrets.COS_REGION }}

      - name: 上传到腾讯云 COS
        run: |
          coscmd upload -r .vuepress/dist/ /
      # - name: 部署到腾讯云 COS
      #   uses: TencentCloud/cos-action@v1
      #   with:
      #     secret_id: ${{ secrets.TENCENT_SECRET_ID }}
      #     secret_key: ${{ secrets.TENCENT_SECRET_KEY }}
      #     cos_bucket: ${{ secrets.COS_BUCKET }}
      #     cos_region: ${{ secrets.COS_REGION }}
      #     local_path: .vuepress/dist/
      #     remote_path:
      #     clean: true # 可选：上传前清空目标路径

这里我们使用腾讯云 CLI 进行文件上传，这里有几个注意点：

branches 要设置为自己更新的分支名
node-version：node 版本需要看一下是否符合你项目的需求
coscmd upload -r .vuepress/dist/ /
1. .vuepress/dist/：代表着你构建产物的路径
2. /：你要放到存储桶的对应地址

首先我们去 https://console.cloud.tencent.com/cam/capi 这里获取我们的腾讯云 cos 服务需要的TENCENT_SECRET_ID 和 TENCENT_SECRET_KEY，然后还需要：

COS_BUCKET：桶名称
COS_REGION ：桶地区

获取到这些后，我们需要去 github 配置密钥的地方进行配置。

填写密钥信息：

我们可以进行一次文件上传，然后会去 Actions 下看到：

        # 新增邮件通知服务
        - name: 安装 nodemailer
        if: success() # 仅在上述步骤成功时执行
        run: npm install nodemailer

      - name: 发送邮件通知
        if: success() # 仅在上述步骤成功时执行
        run: node .github/scripts/send-email.js "${{ secrets.EMAIL_USER }}" "${{ secrets.EMAIL_PASS }}" "${{ secrets.EMAIL_TO }}"

最后去 github 添加对应的密钥：

EMAIL_USER: 发件人邮箱地址（如 example@qq.com）

EMAIL_PASS: 邮箱授权码（不是邮箱密码，对于 QQ 邮箱需要在设置中生成授权码）

EMAIL_TO: 收件人邮箱地址

最后，我们再次进行推送文件，然后你应该会收到邮件：

打开对应网站，发现内容也更新了！

完美，再也不用手动上传，有这时间可以开心的摸鱼了！

高级程序员给初级开发者的10条建议

Thu, 20 Mar 2025 17:17:22 GMT

好文翻译，原文：https://dev.to/coderabbitai/10-tips-for-junior-developers-from-a-senior-programmer-j4o

成为高级程序员不需要 10 年：2-3 年快速进阶指南

让我坦诚地说 - 你不需要花 10 年时间才能成为高级程序员。

如果你保持专注并聪明地工作，只需 2 到 3 年就能实现这一目标。

为此，我将分享一些超实用的技巧，帮助你在这个过程中更快成长。

注意，我不会谈论那些网上随处可见的常见建议，比如：

通过实践学习而不是仅仅看 YouTube 视频
持续投资于你的技能
不要复制粘贴你不理解的代码
专注于提供价值
等等

这些都是大家已经知道的常见建议。

所以，我想分享一些真正的技巧 - 那种能真正加速你的成长，帮助你比预期更快成为高级开发者的见解。

那么，让我们开始吧。

技巧#1：不要跳过基础知识

这里我指的是在跳入框架或更高级主题之前先学习基础知识。

我是从 Udemy 课程学习的 Web 开发，它教会了我基础知识和我需要了解的内容。

之后，由于对学习一切和寻找客户的热情，我直接学习了 React 和 Next.js。

我从未真正深入学习基础知识，当我应聘工作时，面试问题让我感到恐惧。

即使当我需要构建某些东西时，我也必须在 Google 上搜索并学习特定的基本概念，这浪费了很多时间。

所以，如果你是一名程序员，首先要精通一门编程语言，然后是数据结构和算法。

如果你是 Web 开发者，你应该精通 HTML、CSS 和 JavaScript。

记住，框架来来去去，但核心概念永远存在。

技巧#2：在转向下一个技术栈前，先精通一个

同样的建议也适用于学习技术栈。

我在初期犯过这个错误很多次，直到很晚才意识到。

我开始用 HTML、CSS 和 JavaScript 构建网站，几周内我就学习了 React，然后是 Next.js，JamStack 等等。

我甚至还在学习 Python、机器学习概念和深度学习。

我以为我很有效率，但实际上我很愚蠢，因此我从未在任何技术栈上成为专家。

当我意识到我无法获得高薪工作或客户时，这给了我沉重的打击，因为他们不想要一个在 10 个不同领域都只是勉强及格的人。

所以，我专注于 MERN 栈，深入研究，并在过去 3 到 4 年通过多个客户项目取得了最大成果。

我的建议是：选择一个技术栈，深入研究，然后再向前发展。

技巧#3：先思考，后编码

刚开始时，我认为成为优秀开发者意味着写大量代码。

我相信我写的代码越多，我就会变得越好。

但随着经验增长，我意识到高级开发者实际上写的代码更少 - 因为他们花更多时间思考和理解问题。

所以在写任何一行代码之前，问问自己：

这个问题是否已经有解决方案？如果有库、API 或现有工具可以解决 - 就使用它。
我能否不写新代码来解决这个问题？有时最好的解决方案是配置更改、更好的流程或删除不必要的功能。
这个问题值得解决吗？不是每个问题都值得你花时间。确保你正在构建的东西真的重要。

解决方案是：花 50% 的时间理解问题。

记住，聪明的开发者用尽可能少的代码解决问题。有时最好的代码就是没有代码。

技巧#4：保持代码简单，而不是花哨或复杂

我发现随着程序员经验增长，他们意识到编写同一逻辑有多种方式。

例如，你可以使用for循环、forEach、map，甚至是使用.reduce()的花哨单行代码。

是的，它们都能工作。但仅仅因为某些东西能工作并不意味着它很好。

我见过许多开发者（甚至有经验的开发者）过度复杂化代码 - 有时是为了显得聪明，有时只是出于习惯。

他们把整个函数压缩成一行，在简单模式就能完成工作的情况下使用复杂模式，等等。

不要成为那样的开发者或程序员。

最好的代码是简单、可读且易于维护的。

所以始终尝试以其他开发者可以快速理解和审查的方式编写代码。

技巧#5：停止编写重复代码

我发现大多数初级程序员只关注编写代码，使过程变得重复。

说实话 - 如果在有 AI 工具的情况下你仍然手动编写代码，你只是在浪费时间和精力。

以下是你可以避免样板代码并加速工作流程的方法：

首先，你可以使用像 ChatGPT、Claude、v0 等大语言模型根据你的需求生成可工作的应用，然后根据喜好进行调整。
你甚至可以使用 AI 代码编辑器如 Cursor AI、GitHub Copilot、Codeium 和 Tabnine 为每个新项目生成样板代码，建议下一行代码等。
最后，你可以使用预构建模板作为起始文件，或创建自己的可重用模板。

重点是，编写重复代码不会让你成为更好的开发者 - 解决问题才会。

所以尝试使用 AI 创建样板，或手动构建一个来重复使用相同的代码。

技巧#6：向高级开发者请求严格的代码审查

说实话 - 我们都想编写更好的代码。

但如果你只自己检查错误，你就是在放慢进步。

快速提升的一个最快方法是请高级开发者审查你的代码。

关键是：请他们彻底批评它。

认真的。

请他们给予详细、建设性的批评。他们指出的问题越多，你学习得越快。

这将帮助你：

编写更清晰、更智能、更高效的代码。
学习更好的方式来构建你的代码并提高可读性。
开始像有经验的开发者那样思考。

注意，当有人建议更改时，不要只是修复它 - 问问为什么它更好。

你需要理解反馈背后的思考过程，这样你才能在下次应用这些知识。

这才是你真正提高的方式。

此外，你甚至可以使用像 CodeRabbit AI 这样的 AI 工具。

这类工具可以直接在你的拉取请求中审查代码并及早发现问题，这样你的代码就不会在生产环境中出错。

技巧#7：学习如何写出更好的提示词

不久前，大家都说作为程序员最重要的技能之一是知道如何正确使用 Google。

如果你能快速找到解决方案或正确的 Stack Overflow 帖子，你就能比大多数开发者更快地解决问题。

但情况已经改变。

现在，关键在于你多么善于为 ChatGPT、Claude 等大语言模型写提示词。

当然，你可以写任何随机提示，任何模型都会给你回应。但如果你写出清晰、具体的提示，你会得到更好、更快、更准确的结果。

方法如下：

明确表达你想要什么。不要说”写一个登录功能”，而是说：“用 Node.js 编写一个使用 JWT 认证的安全登录功能，具有适当的错误处理和验证”。
提供上下文 - 提及技术栈、使用场景和任何限制。
如果回应不太对，改进你的提示。问一些后续问题如：“如何优化这个？”，“我需要做什么来改进它”等。

技巧#8：开始使用 AI，否则使用 AI 的程序员将取代你

仅仅几年内，约 95% 的代码将由 AI 生成。

不是我这么说的 - AI 领域的每个专家都在谈论这一点。我认为这将成为现实。

所以，开始使用 AI 编写代码吧。

你可以使用 AI 学习新东西 - 它可以提供路线图，甚至是最短路径。
你还可以使用大语言模型或像 Cursor AI 这样的 AI 工具生成代码并在几分钟内构建应用。
你甚至可以开始使用 CodeRabbit AI 等工具，它们可以在你的拉取请求中自动提供摘要、代码审查、演练等。
现在，我们也看到像 Manus AI 这样的 AI 代理可以自动完成令人难以置信的任务。

我开始使用 AI，它使我的生产力至少提高了 10 倍，帮助我交付更多，并自动化了大部分繁琐任务。

技巧#9：你的工作将变为”解决问题”，所以专注于此

到目前为止，公司根据你编写代码的知识来雇佣你。

但我们都知道，由于 AI 的发展，编程将发生变化，所以你需要专注于解决问题。

我知道，没有人能真正预测未来。

然而，基于当前的研究和 AI 专家关注的内容，很明显未来几年将会出现 AI 编码助手和功能齐全的 AI 代理。

甚至像 OpenAI、Nvidia 和 Microsoft 这样的顶级公司都在大力投资构建这些 AI 代理。

我相信编程领域将是首批全面采用 AI 代理的领域之一。

因此，传统的手动编码可能会消失，程序员将把重点转向解决问题和更高层次的设计任务。

技巧#10：职业倦怠是真实存在的，所以保持动力并保护你的精力

我们都知道编程不容易。

随着 AI 每天变得更好，许多普通程序员将被替代，其他人将仅仅是生存。

确切地说，这不再是你只需学习一门编程语言，看 YouTube 教程，构建一个简单项目，就能轻松找到工作的时代。

如果你想保持领先，你需要真正的技能、深入的知识和真实世界的项目 - 以及解决实际问题的能力。

但如果你不休息地过度努力，你会筋疲力尽。当这种情况发生时，即使是最简单的任务也感觉筋疲力尽。

所以保持动力，但也保护你的精力：

在需要时休息。
不要每天编程 12 小时 - 你可以使用多种 AI 工具自动化繁琐任务。
致力于你真正喜欢的项目 - 这会让你保持兴奋和动力。

希望你喜欢这些建议。

END

提示：本文封面图使用「svg 秀」生成，如果你也需要快速将内容转为美观图片需求，可以访问网站免费体验：https://svgshow.cn/

使用Turbopack、Biome、Next.js、Express、Tailwind CSS和ShadCN构建全栈Monorepo项目

Wed, 19 Mar 2025 00:53:32 GMT

这是一篇翻译，原文：https://www.thehalftimecode.com/building-a-full-stack-monorepo-with-turbopack-biome-next-js-express-js-tailwind-css-and-shadcn/ github 地址： https://github.com/ivesfurtado/next-express-turborepo

作为一名开发者或实习生，你可能遇到过在单个项目中管理多个应用程序或软件包的挑战。无论是在开发前端应用的同时构建后端 API，还是在项目的不同部分之间共享 UI 组件和实用工具函数，事情都可能很快变得难以管理。

这就是 monorepos 发挥作用的地方。通过将代码组织到一个包含多个应用程序和共享包的仓库中，你可以简化开发流程并改善协作。在本指南中，我们将引导你使用 Turbopack、Biome、Next.js 15、Express.js、Tailwind CSS 和 ShadCN 设置一个 monorepo。我们还将使用 pnpm 作为我们的包管理器来优化依赖管理。

在本教程结束时，你将拥有一个功能齐全的 monorepo，其中包含两个应用程序（Next.js 和 Express.js）和三个共享包（UI 组件、TypeScript 类型和实用工具函数）。让我们开始吧！

注意： 你将在文章末尾找到仓库链接。如果你以前从未设置过 monorepo，我强烈建议你通读整个教程，而不仅仅是 fork 仓库。

前提条件

在开始本教程之前，请确保已安装以下内容：

Visual Studio Code（或支持 Biome 的类似代码编辑器）
Biome VSC 扩展
NodeJS（建议通过 NVM 安装以便于版本管理）

什么是 Monorepo？

在我们开始构建之前，让我们先弄清楚什么是 monorepo 以及它为什么有用。

定义

Monorepo 是一个包含多个项目或软件包代码的仓库。与为每个应用程序或共享库设置单独的仓库不同，所有内容都放在一个地方。

使用 Monorepo 的好处

代码共享： 轻松在不同的应用程序之间共享代码（例如，UI 组件或实用工具函数）。
一致性： 在所有项目中保持一致的依赖项和配置。
简化协作： 由于所有内容都在一个地方，因此参与项目不同部分的开发人员可以更轻松地协作。
原子更改： 在一次提交中跨多个应用程序或软件包进行更改。
集中式 CI/CD： 从一个地方管理持续集成和部署管道。

在本指南中，我们将创建一个 monorepo (turborepo)，其中包含：

一个 Next.js 应用程序（前端）。
一个 Express.js 应用程序（后端）。
用于 UI 组件（使用 Tailwind CSS + ShadCN）、共享类型和实用工具函数的包。

为什么使用 pnpm 和 Turbopack？

为了使我们的 monorepo 高效且可扩展，我们将使用两个关键工具：用于包管理的 pnpm 和用于快速构建的 Turbopack/Turborepo。

pnpm

pnpm 是 npm 和 Yarn 的替代方案，具有以下优点：

更快的安装： pnpm 通过使用硬链接而不是复制文件来更快地安装依赖项。
磁盘空间效率： 它通过避免重复的依赖项来节省磁盘空间。
工作区支持： pnpm 原生支持工作区，使其非常适合具有多个项目共享依赖项的 monorepo。

Turbopack

Turbopack 是 Vercel 为 Next.js 推出的新打包器。它被设计为比 Webpack 快得多，尤其是在开发过程中：

更快的模块热替换 (HMR)： Turbopack 通过仅在进行更改时重新加载必要的模块来加速开发。
优化的生产构建： Turbopack 优化你的生产构建，使其更小更快。
与 Next.js 15 的无缝集成： Turbopack 开箱即用地支持 Next.js 新的应用程序目录结构。

有了这些工具，让我们继续设置我们的项目结构。

项目结构概述

以下是我们的最终项目结构：

monorepo/
├── .vscode/
│   ├── extensions.json
│   └── settings.json
├── apps/
│   ├── web/       # Next.js 应用
│   └── server/    # Express.js 应用
├── packages/
│   ├── ui/        # 共享 UI 组件 (使用 Tailwind CSS + ShadCN)
│   ├── types/     # 共享 TypeScript 类型
│   ├── tsconfig/  # Typescript 配置
│   └── utils/     # 共享工具函数
├── .gitignore     # 不被git追踪的文件
├── biome.json     # Biome 配置
├── package.json   # 项目配置
├── turbo.json     # Turbopack 配置
└── pnpm-workspace.yaml # pnpm 工作区配置

我们将项目组织成两个主要目录：

apps/: 这将包含我们的两个主要应用程序—web (Next.js) 和 server (Express.js)。
packages/: 这将包含两个应用程序都可以使用的共享代码—ui 用于共享 UI 组件，types 用于 TypeScript 类型, utils 用于共享的工具函数, tsconfig用于typescript配置文件。

现在我们对结构有了大致的了解，让我们开始设置 monorepo。

设置 Monorepo

步骤 1：使用 pnpm 工作区初始化 Monorepo

首先，如果你还没有安装 pnpm，需要全局安装它：

接下来，创建你的主项目目录：

mkdir monorepo && cd monorepo

初始化一个新的工作区：

此命令在项目的根目录创建一个 package.json 文件。现在我们需要通过在根目录创建 pnpm-workspace.yaml 文件来告诉 pnpm 哪些目录应该是工作区的一部分：

packages:
  - 'apps/*'
  - 'packages/*'

此配置告诉 pnpm，apps/ 或 packages/ 中的任何文件夹都应被视为工作区的一部分。

步骤 2：配置 Turbopack

接下来，我们将通过在项目的根目录创建一个 turbo.json 文件来配置 Turbopack：

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": [
    "**/.env.*local"
  ],
  "tasks": {
    "topo": {
      "dependsOn": [
        "^topo"
      ]
    },
    "build": {
      "dependsOn": [
        "^build"
      ],
      "outputs": [
        "dist/**",
        ".next/**",
        "!.next/cache/**"
      ]
    },
    "lint": {
      "dependsOn": [
        "^topo"
      ]
    },
    "format": {
      "dependsOn": [
        "^topo"
      ]
    },
    "lint:fix": {
      "dependsOn": [
        "^topo"
      ]
    },
    "format:fix": {
      "dependsOn": [
        "^topo"
      ]
    },
    "check-types": {},
    "dev": {
      "cache": false,
      "persistent": true
    },
    "add-shadcn-component": {
      "dependsOn": [
        "^topo"
      ]
    },
    "clean": {
      "cache": false
    }
  }
}

此配置定义了 Turbopack 应如何在你的工作区中处理构建。

注意 add-shadcn-component 命令，这是一个自定义命令，将在我们的 UI 包中使用，以便直接从根目录轻松添加 ShadCN 的新组件。

步骤 3：全局配置

接下来，我们将更新我们的根 package.json 以添加脚本和依赖项。

{
  "name": "monorepo",
  "private": true,
  "scripts": {
    "changeset": "changeset",
    "publish:packages": "changeset publish",
    "version:packages": "turbo build && changeset version",
    "add-shadcn-component": "turbo run add-shadcn-component -- --",
    "build": "turbo build",
    "dev": "turbo dev",
    "format": "turbo format --continue --",
    "format:fix": "turbo format --continue -- --write",
    "lint": "turbo lint --continue --",
    "lint:fix": "turbo lint --continue -- --apply",
    "clean": "turbo clean"
  },
  "dependencies": {
    "@changesets/changelog-github": "^0.5.0",
    "@changesets/cli": "^2.27.1",
    "turbo": "^2.1.3"
  },
  "devDependencies": {
    "@biomejs/biome": "^1.7.2",
    "typescript": "^5",
    "postcss": "^8.4.27"
  },
  "packageManager": "pnpm@9.12.1"
}

对于 Biome 配置，我们将创建一个名为 biome.json 的文件：

{
    "$schema": "https://biomejs.dev/schemas/1.6.4/schema.json",
    "files": {
      "ignoreUnknown": true,
      "ignore": [
        "node_modules/*",
        "*.config.*",
        "*.json",
        "tsconfig.json",
        ".turbo",
        "**/dist",
        "**/out",
        ".next"
      ]
    },
    "organizeImports": {
      "enabled": true
    },
    "linter": {
      "enabled": true,
      "rules": {
        "recommended": true,
        "complexity": {
          "noForEach": "off",
          "noUselessFragments": "off"
        },
        "correctness": {
          "useExhaustiveDependencies": "off",
          "noUnusedImports": "warn",
          "noUnusedVariables": "warn"
        },
        "style": {
          "noParameterAssign": "off"
        }
      }
    },
    "formatter": {
      "enabled": true,
      "formatWithErrors": false,
      "indentStyle": "space",
      "lineEnding": "lf",
      "lineWidth": 120
    }
  }

一个非常重要的文件是 .gitignore，在这个文件中，我们将告诉 Git 我们不想跟踪哪些文件。

# dependencies
/node_modules
/.pnp
.pnp.js

node_modules
packages/*/node_modules
apps/*/node_modules
.next

# next.js
/.next/
/out/

# production
/build

# misc
.DS_Store
*.pem

# debug
.pnpm-debug.log*

# other lockfiles that's not pnpm-lock.yaml
package-lock.json
yarn.lock

# local env files
.env
.env*.local

# vercel
.vercel

# typescript
*.tsbuildinfo
next-env.d.ts


# intellij
.idea

dist/**
/dist
packages/*/dist

.turbo
/test-results/
/playwright-report/
/playwright/.cache/

此配置定义了我们的项目默认值。现在我们已经设置了工作区配置文件，让我们继续创建我们的应用程序。

步骤 3: .vscode 文件夹

.vscode 文件夹存储专门针对 Visual Studio Code 的配置设置。这些设置允许你个性化和优化 VS Code 以满足你的项目或工作区需求。以下是两种主要的设置类型：

用户设置：全局应用于系统上的所有 VS Code 实例。它们非常适合你需要保持一致的设置，例如字体大小或主题。
工作区设置：仅应用于当前项目。这对于项目特定的配置很有用，例如从文件资源管理器中排除某些文件夹（例如，node_modules）。

VS Code 使用 JSON 文件来存储这些设置，从而可以通过版本控制轻松进行自定义和共享。为了便于管理，你可以直接在 JSON 文件中修改设置，也可以使用设置编辑器，它提供了一个方便的图形界面。

对于我们的项目，我们将创建两个存储这些配置的文件。首先，在根目录创建一个名为 .vscode 的文件夹。然后，创建 extensions.json：

{
  "recommendations": [
    "yoavbls.pretty-ts-errors",
    "bradlc.vscode-tailwindcss",
    "biomejs.biome"
  ]
}

我们需要最后一个配置就是全局设置, 创建一个settings.json文件：

{
  "editor.codeActionsOnSave": {
    "source.organizeImports.biome": "explicit",
    "source.fixAll.biome": "explicit",
  },
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "tailwindCSS.experimental.classRegex": [
    ["cva\\(([^)]*)\\)", "[\"'`]([^\"'`]*).*?[\"'`]"],
    ["cx\\(([^)]*)\\)", "(?:'|\"|`)([^']*)(?:'|\"|`)"]
  ],
  "typescript.enablePromptUseWorkspaceTsdk": true,
  "typescript.tsdk": "node_modules/typescript/lib",

  "typescript.preferences.autoImportFileExcludePatterns": [
    "next/router.d.ts",
    "next/dist/client/router.d.ts"
  ],
  "[typescriptreact]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "[json]": {
    "editor.defaultFormatter": "vscode.json-language-features"
  }
}

创建第一个包 (tsconfig)

为了创建将在我们所有 monorepo 中使用的 typescript 配置以及我们 web 和 server 的单独配置，我们将创建我们的 tsconfig 包。

mkdir packages && cd packages && mkdir tsconfig && cd tsconfig

我们将有 6 个 Typescript 配置文件：

base: base.json
web: next.json
server: express.json
ui: ui.json
utils: utils.json
types: types.json

首先，我们将创建我们的 package.json：

{
  "name": "@monorepo/tsconfig",
  "version": "0.0.0",
  "private": true,
  "license": "MIT",
  "publishConfig": {
    "access": "public"
  }
}

然后我们将创建我们的 base.json 配置文件（你可以在这里找到每个 tsconfig 设置）：

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "alwaysStrict": false,
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "resolveJsonModule": true,
    "target": "ESNext",
    "lib": [
      "DOM",
      "DOM.Iterable",
      "ESNext"
    ],
    "noEmit": true,
    "declaration": true,
    "declarationMap": true,
    "verbatimModuleSyntax": true,
    "moduleDetection": "force",
    "downlevelIteration": true,
    "allowJs": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "skipDefaultLibCheck": true,
    "incremental": true,
    "tsBuildInfoFile": ".tsbuildinfo"
  },
  "include": [
    "**/*.ts",
    "**/*.tsx"
  ],
  "exclude": [
    "node_modules",
    "src/tests"
  ]
}

现在我们将创建 next.json 配置：

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./base.json",
  "compilerOptions": {
    "paths": {
      "@/*": [
        "./*"
      ]
    },
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true
  }
}

然后我们需要创建 express.json 配置文件：

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "ExpressJS Server",
  "extends": "./base.json",
  "ts-node": {
    "compilerOptions": {
      "module": "commonjs",
      "moduleResolution": "Node10"
    }
  },
  "compilerOptions": {
    "outDir": "./build",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "module": "ESNext"
  }
}

为我们的共享类型包创建一个 types.json 配置文件：

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Shared Types",
  "extends": "./base.json",
  "compilerOptions": {
    "outDir": "./dist",
    "declaration": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
  },
}

此外，我们需要添加最后一个配置文件 ui.json，此文件将在我们的共享 UI 包中使用。

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Shared UI",
  "extends": "./base.json",
  "compilerOptions": {
    "paths": {
      "@/*": [
        "./*"
      ]
    },
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "incremental": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  }
}

最后，创建utils.json配置：

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Shared UI",
  "extends": "./base.json",
  "compilerOptions": {
    "paths": {
      "@/*": [
        "./*"
      ]
    },
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "incremental": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  }
}

这是你的 tsconfig 包文件夹的样子：

恭喜，我们刚刚完成了 typescript 的配置。现在让我们进入激动人心的部分：创建我们的应用程序！

创建应用程序

步骤 1：设置 Next.js 15 应用 (`web`)

创建并导航到 apps/ 目录：

cd ../.. && mkdir apps && cd apps

使用 pnpm 创建一个新的 Next.js 应用程序：

pnpm create next-app@latest web --ts --app --turbopack --no-eslint --tailwind --src-dir --skip-install --import-alias @/*

此命令将在 web/ 文件夹中创建一个新的 Next.js 应用程序，并启用 TypeScript，将 Turbopack 设置为默认打包器和 Tailwind CSS。

要将我们的 tsconfig 包集成到 Web 应用程序中，我们需要更新默认的 package.json：

...,
"dependencies": {
  "@monorepo/types": "workspace:*",
  "@monorepo/ui": "workspace:*",
  "@monorepo/utils": "workspace:*",
  "react": "19.0.0-rc-02c0e824-20241028",
  "react-dom": "19.0.0-rc-02c0e824-20241028",
  "next": "15.0.2"
},
"devDependencies": {
  "@monorepo/tsconfig": "workspace:*",
  "@types/node": "^20",
  "@types/react": "^18",
  "@types/react-dom": "^18",
  "postcss": "^8",
  "tailwindcss": "^3.4.1",
  "@biomejs/biome": "^1.7.2"
}
...,

现在，更新默认的 tsconfig.json：

{
  "extends": "@monorepo/tsconfig/next.json",
  "compilerOptions": {
    "plugins": [
      {
        "name": "next"
      }
    ],
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts",
    "tailwind.config.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

添加 biome.json，以便我们可以在文件夹上激活它：

{
  "extends": ["../../biome.json"]
}

你的 Next.js 应用程序现已设置完毕！让我们继续使用 Express.js 设置我们的后端应用程序。

步骤 2：设置 Express 应用 (`server`)

导航回 apps/ 目录并创建一个 Express 应用程序：

cd .. && mkdir server && cd server && pnpm init

更新服务器的 package.json 以添加 Express、其类型、cors、morgan 和 ts-node-dev：

{
  "name": "server",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "scripts": {
    "dev": "ts-node-dev --transpile-only src/server.ts"
  },
  "dependencies": {
    "@monorepo/types": "workspace:*",
    "express": "^4.21.1",
    "ts-node-dev": "^2.0.0",
    "cors": "2.8.5",
    "morgan": "^1.10.0"
  },
  "devDependencies": {
    "@monorepo/tsconfig": "workspace:*",
    "@types/express": "^5.0.0",
    "@types/morgan": "^1.9.9",
    "@types/cors": "2.8.17"
  }
}

将 tsconfig.json 添加到服务器：

{
  "extends": "@monorepo/tsconfig/express.json",
  "include": [
    "src"
  ],
}

在 src/server.ts 中创建一个基本的 Express 服务器：

import cors from "cors";
import express from "express";
import morgan from "morgan";

const app = express();

app.use(morgan("tiny"));
app.use(express.json({ limit: "100mb" }));

app.use(
  cors({
    credentials: true,
    origin: ["http://localhost:3000"],
  }),
);

const port = process.env.PORT || 3001;

app.get("/", (_, res) => {
  res.send("Hello from Express!");
});

app.listen(port, () => {
  console.log(`Server is running on http://localhost:${port}`);
});

你现在已经设置了前端 (Next.js) 和后端 (Express) 应用程序！让我们继续创建两个应用程序都可以使用的共享包。

创建共享包

在本节中，我们将创建三个共享包：一个用于 UI 组件 (ui)，一个用于 TypeScript 类型 (types)，一个用于实用工具函数 (utils)。这些包将位于 packages/ 目录中。

步骤 1：创建 `utils` 包

我们将创建的第一个包是用于实用工具函数 (utils) 的包。要进行设置：

在 packages/ 中创建文件夹，并进行初始化：

cd ../.. && mkdir packages && cd packages && mkdir utils && cd utils && pnpm init && mkdir src && touch src/styles.ts

更新 package.json 以添加脚本和导出：

{
  "name": "@monorepo/utils",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "check-types": "tsc --noEmit",
    "build": "tsup",
    "lint": "biome lint ./src",
    "format": "biome format ./src "
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "clsx": "^2.1.1",
    "tailwind-merge": "^2.5.4"
  },
  "devDependencies": {
    "@monorepo/tsconfig": "workspace:*"
  },
  "exports": {
    ".": "./src",
    "./styles": "./src/styles.ts"
  }
}

添加 biome.json:

{
    "extends": [
        "../../biome.json"
    ]
}

添加 tsconfig.json：

{
  "extends": "@monorepo/tsconfig/utils.json",
  "include": [
    "**/*.ts",
  ],
  "exclude": [
    "node_modules"
  ],
}

我们将创建的第一个（也是唯一的）util 函数是 cn，这是一个用于有条件地合并 tailwind 类的实用工具函数，它在 ShadCN 组件中大量使用。我们需要添加以下依赖项：

pnpm add clsx tailwind-merge

在 src/style.ts 中添加 cn 通用实用工具函数：

import clsx, { type ClassValue } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs));
}

步骤 2：创建 `ui` 包 (Tailwind CSS + ShadCN)

导航回 packages/ 目录：

cd .. && mkdir ui && cd ui && pnpm init

安装 React 以及 Tailwind CSS（开发依赖项）和 ShadCN（我们将使用 new york 样式）：

pnpm add -D @types/react @types/react-dom autoprefixer postcss react tailwindcss typescript

pnpm add shadcn @types/react tailwindcss-animate class-variance-authority clsx tailwind-merge @radix-ui/react-icons

按照与我们在 Next.js 应用程序中执行的类似步骤设置 Tailwind CSS—初始化 Tailwind CSS (npx tailwindcss init) 并在 tailwind.config.ts 中对其进行配置：

import type { Config } from "tailwindcss";
import tailwindcssAnimate from "tailwindcss-animate";
import { fontFamily } from "tailwindcss/defaultTheme";

const config = {
  darkMode: ["class"],
  content: [
    "./pages/**/*.{ts,tsx}",
    "./components/**/*.{ts,tsx}",
    "./app/**/*.{ts,tsx}",
    "./src/**/*.{ts,tsx}",
    "../../packages/ui/src/**/*.{ts,tsx}",
  ],
  prefix: "",
  theme: {
    container: {
      center: true,
      padding: '2rem',
      screens: {
        '2xl': '1400px'
      }
    },
    extend: {
      colors: {
        border: 'hsl(var(--border))',
        input: 'hsl(var(--input))',
        ring: 'hsl(var(--ring))',
        background: 'hsl(var(--background))',
        foreground: 'hsl(var(--foreground))',
        primary: {
          DEFAULT: 'hsl(var(--primary))',
          foreground: 'hsl(var(--primary-foreground))'
        },
        secondary: {
          DEFAULT: 'hsl(var(--secondary))',
          foreground: 'hsl(var(--secondary-foreground))'
        },
        destructive: {
          DEFAULT: 'hsl(var(--destructive))',
          foreground: 'hsl(var(--destructive-foreground))'
        },
        muted: {
          DEFAULT: 'hsl(var(--muted))',
          foreground: 'hsl(var(--muted-foreground))'
        },
        accent: {
          DEFAULT: 'hsl(var(--accent))',
          foreground: 'hsl(var(--accent-foreground))'
        },
        popover: {
          DEFAULT: 'hsl(var(--popover))',
          foreground: 'hsl(var(--popover-foreground))'
        },
        card: {
          DEFAULT: 'hsl(var(--card))',
          foreground: 'hsl(var(--card-foreground))'
        }
      },
      borderRadius: {
        lg: '`var(--radius)`',
        md: '`calc(var(--radius) - 2px)`',
        sm: 'calc(var(--radius) - 4px)'
      },
      fontFamily: {
        sans: ["var(--font-sans)", ...fontFamily.sans]
      },
      keyframes: {
        'accordion-down': {
          from: {
            height: '0'
          },
          to: {
            height: 'var(--radix-accordion-content-height)'
          }
        },
        'accordion-up': {
          from: {
            height: 'var(--radix-accordion-content-height)'
          },
          to: {
            height: '0'
          }
        },
      },
      animation: {
        'accordion-down': 'accordion-down 0.2s ease-out',
        'accordion-up': 'accordion-up 0.2s ease-out'
      }
    }
  },
  plugins: [tailwindcssAnimate],
} satisfies Config;

export default config;

我们还需要为 Tailwind CSS 配置 postcss.config.mjs：

/** @type {import('postcss-load-config').Config} */
const config = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

export default config;

由于我们还将在该包上使用 Biome，因此请添加 biome.json：

{
    "extends": [
        "../../biome.json"
    ]
}

更新 package.json 以添加 tsconfig、utils 包和自定义脚本：

{
  "name": "@monorepo/ui",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "check-types": "tsc --noEmit",
    "add-shadcn-component": "pnpm dlx shadcn@latest add",
    "build": "tsup",
    "lint": "biome lint ./src",
    "format": "biome format ./src "
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@monorepo/tsconfig": "workspace:*",
    "@types/react": "^18.3.12",
    "@types/react-dom": "^18",
    "autoprefixer": "^10.4.20",
    "postcss": "^8.4.47",
    "react": "19.0.0-rc-02c0e824-20241028",
    "tailwindcss": "^3.4.1"
  },
  "dependencies": {
    "@monorepo/utils": "workspace:^",
    "@radix-ui/react-accordion": "^1.2.1",
    "@radix-ui/react-icons": "^1.3.1",
    "@radix-ui/react-select": "^2.1.2",
    "class-variance-authority": "^0.7.0",
    "clsx": "^2.1.1",
    "shadcn": "^2.1.3",
    "tailwind-merge": "^2.5.4",
    "tailwindcss-animate": "^1.0.7"
  },
  "exports": {
    "./globals.css": "./src/styles/globals.css",
    "./postcss.config": "./postcss.config.mjs",
    "./tailwind.config": "./tailwind.config.ts",
    "./components/*": "./src/*.tsx"
  }
}

创建一个 tsconfig.json 文件：

{
  "extends": "@monorepo/tsconfig/ui.json",
  "include": [
    "**/*.ts",
    "**/*.tsx",
    "tailwind.config.ts",
  ],
  "exclude": [
    "node_modules"
  ],
}

在 src/styles/globals.css 创建一个样式文件：

@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
  :root {
    --background: 0 0% 100%;
    --foreground: 222.2 47.4% 11.2%;

    --muted: 210 40% 96.1%;
    --muted-foreground: 215.4 16.3% 46.9%;

    --popover: 0 0% 100%;
    --popover-foreground: 222.2 47.4% 11.2%;

    --border: 214.3 31.8% 91.4%;
    --input: 214.3 31.8% 91.4%;

    --card: 0 0% 100%;
    --card-foreground: 222.2 47.4% 11.2%;

    --primary: 222.2 47.4% 11.2%;
    --primary-foreground: 210 40% 98%;

    --secondary: 210 40% 96.1%;
    --secondary-foreground: 222.2 47.4% 11.2%;

    --accent: 210 40% 96.1%;
    --accent-foreground: 222.2 47.4% 11.2%;

    --destructive: 0 100% 50%;
    --destructive-foreground: 210 40% 98%;

    --ring: 215 20.2% 65.1%;

    --radius: 0.5rem;
  }

  .dark {
    --background: 224 71% 4%;
    --foreground: 213 31% 91%;

    --muted: 223 47% 11%;
    --muted-foreground: 215.4 16.3% 56.9%;

    --accent: 216 34% 17%;
    --accent-foreground: 210 40% 98%;

    --popover: 224 71% 4%;
    --popover-foreground: 215 20.2% 65.1%;

    --border: 216 34% 17%;
    --input: 216 34% 17%;

    --card: 224 71% 4%;
    --card-foreground: 213 31% 91%;

    --primary: 210 40% 98%;
    --primary-foreground: 222.2 47.4% 1.2%;

    --secondary: 222.2 47.4% 11.2%;
    --secondary-foreground: 210 40% 98%;

    --destructive: 0 63% 31%;
    --destructive-foreground: 210 40% 98%;

    --ring: 216 34% 17%;

    --radius: 0.5rem;
  }
}

@layer base {
  * {
    @apply border-border;
  }
  body {
    @apply bg-background text-foreground;
    font-feature-settings: "rlig" 1, "calt" 1;
  }
}

ShadCN 要求你创建一个 components.json（启用 CLI 使用）：

{
    "$schema": "https://ui.shadcn.com/schema.json",
    "style": "new-york",
    "rsc": true,
    "tsx": true,
    "tailwind": {
        "config": "tailwind.config.ts",
        "css": "src/styles/globals.css",
        "baseColor": "slate",
        "cssVariables": true
    },
    "aliases": {
        "components": "src/",
        "ui": "src/",
        "utils": "@monorepo/utils/styles"
    }
}

现在你可以开始在此包中添加可重用的 UI 组件！例如，要导入 ShadCN Button 组件，只需在根工作区运行以下命令：

pnpm add-shadcn-component card

你可以在此处找到每个 ShadCN 组件，以及在此基础上创建的其他组件。现在我们准备设置我们的共享类型包并集成我们设置的所有内容！

步骤 3：创建 `types` 包

types 包将包含两个应用程序都可以使用的共享 TypeScript 类型。要创建它：

导航回 packages/，创建文件夹并进行初始化：

   cd .. && mkdir types && cd types && pnpm init

创建biome.json文件：

{
    "extends": [
        "../../biome.json"
    ]
}

创建 tsconfig.json 文件：

{
  "extends": "@monorepo/tsconfig/types.json",
  "include": [
      "**/*.ts",
  ],
  "exclude": [
    "node_modules"
  ],
}

我们将创建的第一个类型将是一个简单的 API 客户端，以便我们可以在 server 和 web 之间共享类型。创建 src/ 文件夹，并在其中创建 api/ 文件夹。然后创建 simple-api-client.ts：

export interface GetTestResponse {
  message: string;
}

export type GetTest = () => Promise<GetTestResponse>;

export interface SimpleApiClient {
  getTest: GetTest;
}

更新 package.json 以添加导出、脚本和 devDependencies：

{
  "name": "@monorepo/types",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "lint": "biome lint ./src",
    "check-types": "tsc --noEmit"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@monorepo/tsconfig": "workspace:*"
  },
  "exports": {
    ".": "./src/index.ts"
  }
}

现在，在 src/api 文件夹中创建一个 index.ts 并从 simple-api-client.ts 导出所有内容（你将使用其他文件复制它以获得单一导入源）：

export * from "./simple-api-client";

最后，在 src 文件夹中创建一个 index.ts 并从 api 导出所有内容：

我们的共享类型包已全部设置完毕！你的存储库应如下所示：

现在，让我们继续本教程的最后一部分：集成所有内容并运行开发环境。

在本地运行你的 Monorepo

现在一切都设置好了，让我们在本地运行这两个应用程序！

步骤 1：安装所有依赖项

一次性安装工作区中的所有依赖项（记得将目录更改回根目录）：

pnpm install

此命令将安装两个应用程序（`web`、`server`）以及所有共享包（`ui`、`types` 等）的所有必要依赖项。

### **步骤 2：同时运行两个应用程序**

pnpm turbo run dev

此命令将安装两个应用程序（web、server）以及所有共享包（ui、types 等）的所有必要依赖项。

此命令会同时启动你的前端 (Next.js)（在端口 3000 上）和后端 (Express)（在端口 3001 上）！

Web 和 Server 集成

为了在我们的应用程序和包之间创建一个简单的集成，我们将开发一个组件，该组件将使用我们在本教程前面创建的共享类型从服务器获取数据。但是，在此之前，让我们更新我们的 Tailwind CSS 文件和全局样式以使用我们在 UI 包中定义的那些。将 tailwind.config.ts 的内容替换为以下内容：

export * from "@monorepo/ui/tailwind.config";

现在将 postcss.config.mjs 内容替换为：

export { default } from "@monorepo/ui/postcss.config";

在我们的根布局 (src/app/layout.tsx) 中，更新 globals.css 导入以使用我们在 UI 包中创建的那个：

import "@monorepo/ui/globals.css";
import "./style.css";
import type { Metadata } from "next";
import localFont from "next/font/local";

const geistSans = localFont({
  src: "./fonts/GeistVF.woff",
  variable: "--font-geist-sans",
  weight: "100 900",
});
const geistMono = localFont({
  src: "./fonts/GeistMonoVF.woff",
  variable: "--font-geist-mono",
  weight: "100 900",
});

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={`${geistSans.variable} ${geistMono.variable} antialiased dark`}>{children}</body>
    </html>
  );
}

这样做是为了我们可以从共享 UI 包控制我们的应用程序 UI 样式和配置，这样如果我们创建另一个 Web 应用程序（例如管理仪表板），我们将拥有一致的样式！

要开始开发我们的应用程序，我们将按照以下规则组织我们的 Web 文件夹结构：仅在页面中使用的组件应位于 app 目录中与页面文件夹同级的名为 components 的文件夹中。应用程序共享组件应位于 src/components 文件夹中。

因此，让我们在 app 目录 src/app/components 中创建一个 components 文件夹（我们将创建一个仅在第一页中使用的组件），并创建一个名为 get-test.tsx 的文件，其中包含以下内容：

"use client";

import type { GetTestResponse } from "@monorepo/types";
import { Card, CardContent, CardHeader } from "@monorepo/ui/components/card";
import { cn } from "@monorepo/utils/styles";
import { useEffect, useState } from "react";

const GetTest = () => {
  const [test, setTest] = useState<string>("");

  useEffect(() => {
    const fetchTest = async () => {
      const response = await fetch("http://localhost:3001/test");
      const data: GetTestResponse = await response.json();
      setTimeout(() => {
        setTest(data.message);
      }, 3000);
    };
    fetchTest();
  }, []);

  return (
    <div>
      <Card>
        <CardHeader>
          <h1 className={cn("text-xl text-yellow-500", test !== "" && "text-green-500")}>Get Test</h1>
        </CardHeader>
        <CardContent>
          <p>{test}</p>
        </CardContent>
      </Card>
    </div>
  );
};

export default GetTest;

看看该文件，我们有一个使用我们在共享类型中定义的类型化响应对服务器进行的简单提取，这使我们可以轻松地处理响应。服务器路由将很快定义。首先，让我们通过在我们的 page.tsx 中导入组件来完成 web 部分：

import GetTest from "./components/get-test";

export default function Home() {
  return (
    <div className="grid grid-rows-[20px_1fr_20px] items-center justify-items-center min-h-screen p-8 pb-20 gap-16 sm:p-20 font-[family-name:var(--font-geist-sans)]">
      <GetTest />
    </div>
  );
}

Web 设置完成后，转到 server 应用程序并使用我们将使用的路由更新 server.ts。在 app.listen 之前添加以下路由：

app.get("/test", (_, res) => {
  const testJson: GetTestResponse = {
    message: "Hello from Express API!",
  };
  res.json(testJson);
});

最后，一切都完成了，你可以使用以下命令运行整个应用程序（记得将目录更改回根目录）：

你将能够在页面上查看呈现的以下组件。

组件呈现后，我们会在 useEffect 中获取服务器并设置要呈现的状态（不需要 setTimeout，它只是为了可视化状态更改），然后你将看到以下内容。

总结

恭喜！你已经成功地设置了一个可扩展的 monorepo，其中包含两个应用程序——一个使用 Next.js 构建的前端，使用 Tailwind CSS 设置样式，通过来自 ShadCN 的可重用组件增强，以及一个 Express 后端——所有这些都使用 pnpm 工作区进行有效管理，以及由 Turbopack 提供支持的极快构建和使用 Biome 进行的几乎即时的校验！

以下是你今天完成的工作：

在一个仓库中创建了两个独立的应用程序。
设置了四个包，三个包含可重用代码，一个用于 typescript 配置。
使用 pnpm 工作区通过有效的依赖管理实践在应用程序之间链接这些包。

我们已经完成了本教程，现在你可以自由地发挥你的想象力，使用最好的 monorepo 架构创建任何你想要的东西

vercel-ai 部分源码阅读，看看如何实现流式请求高并发

Sun, 16 Mar 2025 15:24:38 GMT

背景

在开发 AI 工具的时候，自己使用 fetch 调用 AI 的 api ，然后发现在并发的场景下会出现问题，经过询问得知社区的开源项目： https://github.com/vercel/ai ，直接能够解决我的问题，使用下来确实是这样，于是打算研究一下它是如何实现的

目的

找到源码中 streamText 的实现，然后找到它是如何支持并发请求的

streamText 功能解析

这个 API 的官方文档： https://sdk.vercel.ai/docs/reference/ai-sdk-core/stream-text

它接受的输入：

model：使用的语言模型
system：将作为提示部分内容的系统消息。
tools：可供模型访问和调用的工具集。模型需支持工具调用功能。
prompt：简单文本提示。prompt 和 messages 参数不可同时使用。
messages：消息列表。prompt 和 messages 参数不可同时使用。
还有很多。。。它返回的输出：
textStream：一个仅返回生成文本增量的文本流。您可将其作为 AsyncIterable 或 ReadableStream 使用。当发生错误时，该流会抛出错误。
还有很多。。。除了上面的参数还有很多参数，但是我们的目的是搞清楚它发送请求的逻辑，所以就不一一列举了！

源码阅读

这里我的目标是找到如何发送请求，处理数据，然后如何返回内容的

1）安装源码

git clone git@github.com:vercel/ai.git

安装好后，我使用 Cursor 打开

2）找到源码地址

我知道我是从 ai 里面导出的 streamText ，所以它肯定在 ai 目录下,于是我找到了，它在这里：vercel/ai/packages/ai/core/generate-text/stream-text.ts 。但是居然高达 1600 行，我还是去玩游戏吧！（那是不可能的）可以看到这里返回的是一个 DefaultStreamTextResult 的实例，这里代码逻辑过于复杂，借助 AI，我找到了相关代码部分：这里可以看到它调用了模型自己的 doStream 方法来获取结果，streamText 是负责准备请求数据，然后调用 model.doStream() => 处理返回的数据

所以我们去看模型自己如何写 doStream 方法，这里我看的是 openai ，我们去：packages/openai/src/openai-chat-language-model.ts ，这里我们可以看到：这里调用 @ai-sdk/provider-utils 的 postJsonToApi 方法，我们继续去packages/provider-utils/src/post-to-api.ts 然后可以看到 postJsonToApi 返回 PostToApi ，所以我们看这个方法：

这就是我们要找的方法，我们详细看一下：它接收：

url：目标API的URL
headers：请求头信息
body：请求体(包含content和values)
successfulResponseHandler：成功响应处理器
failedResponseHandler：失败响应处理器
abortSignal：中止信号
fetch = getOriginalFetch()： fetch实现(默认为全局fetch) 它返回：将 response 传给 successfulResponseHandler。也就是说它返回的是 successfulResponseHandler 函数执行的返回然后： 1）发送 http 请求 2）提取、处理响应头 3）错误处理，这里通过多步处理然后抛出错误 4）成功处理，也通过 try catch 保证成功处理过程中错误能抛出 5）网络错误处理，处理 fetch 失败，并且设置可重试

代码解析：

异步非阻塞：使用 async/await 实现异步操作，不会阻塞事件循环
事件驱动：使用 promise ，当网络请求完成通过事件回调处理响应
错误处理链：精细的错误处理机制，保证失败也能获取到精确的错误信息，或者重试

successfulResponseHandler

我们去 openai 看到传入了createEventSourceResponseHandler 函数给successfulResponseHandler ，createEventSourceResponseHandler 在 packages/provider-utils/src/response-handler.ts ，代码如下：

createEventSourceResponseHandler 是一个工厂函数，用于创建处理服务器发送事件(Server-Sent Events, SSE)格式响应的处理器，这里使用 ReadableStream.PipeThrough() 方法来进行数据处理

TextDecoderStram：将二进制转为文本
EventSourceParseStram：解析 SSE 格式
TransformStram：处理每个事件数据
通过 enqueue() 方法将给定数据块送入到关联的流中这种流式处理方式使得函数可以高效处理大量数据，而不必等待所有数据接收完毕。

函数优点：

非阻塞处理：使用流式处理，不会阻塞事件循环
增量处理：可以立即处理每个到达的数据块，无需等待完整响应
内存效率：避免将整个响应加载到内存中
类型安全：通过Zod模式确保每个数据块符合预期格式
错误隔离：单个数据块解析错误不会影响整个流程

stream-text 流程图

flowchart TD
    A[用户调用 streamText] --> B[初始化参数和设置]
    B --> C[创建流处理管道]
    C --> D[执行 streamStep 函数]
    D --> E[调用 model.doStream 请求API]
    E --> F[处理流式响应]
    F --> G{是否需要后续步骤?}
    G -->|是| H[更新消息历史]
    H --> D
    G -->|否| I[关闭流并返回结果]

初始化：

flowchart TD
    A[用户调用 streamText] --> B[验证参数]
    B --> C[初始化承诺对象]
    C --> D[创建可拼接流]
    D --> E[设置流转换器]
    E --> F[准备遥测和重试设置]
    F --> G[标准化提示信息]

API 请求处理：

flowchart TD
    A[streamStep 函数] --> B[准备提示信息]
    B --> C[准备工具选择]
    C --> D[应用模型设置]
    D --> E[使用retry函数包装请求]
    E --> F["model.doStream 发起API请求"]

    subgraph "实际API调用"
    F --> G[provider包中的doStream实现]
    G --> H[调用 postToApi/postJsonToApi]
    H --> I[发起实际HTTP请求]
    end

    I --> J[返回流式响应]

流处理管道：

flowchart TD
    A[获取API响应流] --> B[应用工具转换]
    B --> C[创建事件处理器]

    subgraph "转换流"
    C --> D[处理文本增量]
    C --> E[处理推理内容]
    C --> F[处理工具调用]
    C --> G[处理步骤完成]
    end

    H[合并所有转换流] --> I[输出到最终结果]

多步处理与工具调用：

flowchart TD
    A[接收步骤结果] --> B{检查结束原因}
    B -->|工具调用| C[执行工具]
    B -->|长度限制| D[继续生成]
    B -->|完成| E[结束流]

    C --> F[处理工具结果]
    F --> G[准备下一步输入]
    G --> H[执行下一步]

    D --> I[继续当前消息]
    I --> J[执行下一步]

数据输出处理：

flowchart TD
    A[流处理完成] --> B[解析最终结果]
    B --> C[分离不同类型数据]

    subgraph "输出流转换"
    C --> D[textStream]
    C --> E[fullStream]
    C --> F[dataStream]
    end

    G[用户选择输出格式] --> H[返回相应格式数据]

数据流动过程用户输入 → 格式化为模型可以理解的提示 API 请求 → 使用 postToApi 函数发起 HTTP 请求流式返回 → 通过 TransformStream 处理返回的数据块转换处理 → 根据类型（文本、工具调用、推理等）处理每个数据块结果整合 → 将所有处理后的数据整合为最终结果多步处理机制代码支持多步骤处理，通过以下方式：处理工具调用结果并根据需要发起新的 API 请求当模型输出被截断时（finishReason 为 “length”）可以继续生成维护消息历史，将前面步骤的输出作为后续步骤的输入的一部分这种设计使 SDK 能够支持复杂的对话和工具使用场景，实现更智能的交互体验。

通过尤雨溪“围绕Vite的前端统一框架”分享，看未来前端发展趋势

Sun, 16 Mar 2025 10:22:18 GMT

vite 历史

看 PPT 吧！

总结：Vite 当之无愧目前前端构建工具首选

Vite 现状

周下载量 2200 万 +，在 23年已经超过 Next.js
State of JS 2024 ，Vite 和 Vitest 是最受关注和欢迎的工具

Vite 生态

在元框架中，除了 Next.js 都有在使用 Vite，毕竟人家现在有自己 turbopack。哈哈哈

让我们看看这些都是什么吧！ 第一行

Astro: 一个现代化的静态站点生成器，以其岛屿架构（Islands Architecture）而闻名，可以构建快速的网站，只加载必要的 JavaScript。
- GitHub: https://github.com/withastro/astro
React: 一个用于构建用户界面的 JavaScript 库，由 Facebook 开发，以其组件化和虚拟 DOM 而闻名。
- GitHub: https://github.com/facebook/react
Vue.js: 一个渐进式 JavaScript 框架，用于构建用户界面和单页应用。
- GitHub: https://github.com/vuejs/
oxc: 高性能 JavaScript/TypeScript 代码检查工具
- GitHub: https://github.com/oxc-project/oxc
Svelte: 一个不同的构建 Web 应用的方法。它是一个编译器，将你的应用程序代码转换为高效的 JavaScript，而不是在运行时解释代码
- GitHub: https://github.com/sveltejs/svelte
Nuxt: 基于 Vue.js 的 Web 全栈应用框架
- GitHub: https://github.com/nuxt/nuxt
solidjs: 用于构建用户界面的声明性、高效且灵活的 JavaScript 库。
- GitHub: https://github.com/solidjs/solid

第二行

storybook: 用于独立构建、记录和测试 UI 组件的工具
- GitHub: https://github.com/storybookjs/storybook
qwik：无需费力即可立即加载 Web 应用程序
- **GitHub： https://github.com/QwikDev/qwik
Rollup: 一个 JavaScript 模块打包器，可以将多个模块打包成一个或多个 bundle。Vite 在开发环境使用原生 ESM，但在生产环境仍然依赖 Rollup 进行打包和优化。
- GitHub: https://github.com/rollup/rollup
Vite: 现代前端构建工具
- GitHub: https://github.com/vitejs/vite
rolldown: 基于 Rust 的 JavaScript 快速打包器
- GitHub: https://github.com/rolldown/rolldown
Angular Angular 是一个基于 TypeScript 的开源 Web 应用框架, 由 Google 的 Angular 团队以及社区共同领导和维护。
- GitHub: https://github.com/angular/angular
Nx: 一个智能的、可扩展的构建系统，特别适用于 monorepo 项目。
- GitHub: https://github.com/nrwl/nx

第三行

pnpm: 一个快速、节省磁盘空间的包管理器，类似于 npm 或 Yarn，但它使用不同的依赖管理策略
- GitHub: https://github.com/pnpm/pnpm
VitePress: 一个基于 Vite 构建的静态站点生成器，由 Vue.js 团队创建，特别适用于文档站点。
- GitHub: https://github.com/vuejs/vitepress
unocss: 一个即时、按需的原子 CSS 引擎。
- GitHub: https://github.com/unocss/unocss
Vitest: 一个由 Vite 驱动的极速单元测试框架。
- GitHub: https://github.com/vitest-dev/vitest
volar: 用于构建编程语言工具的框架
- GitHub: https://github.com/volarjs/volar.js
tauri: 使用 rust 编写的构建轻量级、安全且高性能的跨平台桌面应用程序
- GitHub: https://github.com/tauri-apps/tauri
redwood: 一个全栈 JavaScript/TypeScript web 应用框架，旨在让开发者能够以更加集成和流畅的方式构建现代 web 应用
- GitHub: https://github.com/redwoodjs/redwood

第四行

没找到，不知道有没有人知道是什么？
Laravel: Laravel 是一个流行的 PHP Web 应用程序框架，虽然它主要用于后端，但它也可以与 Vite 集成，以处理前端资源。
- GitHub: https://github.com/laravel/larave
Vite Ruby : Ruby的Vite集成
- GitHub: https://github.com/ElMassimo/vite_ruby
Remix: Remix 是一个全栈 Web 框架，专注于 Web 标准和现代 Web 应用 UX，构建更好的网站。
- GitHub: https://github.com/remix-run/remix
Peaks: : Angular 的全栈元框架。由 Vite 和 Nitro 提供支持
- GitHub: https://github.com/analogjs/analog
Million: 一种声明性的，基于HTML的语言，使构建Web应用程序变得有趣 * **GitHub: https://github.com/marko-js/marko
playwright: Web测试和自动化库
- GitHub: https://github.com/microsoft/playwright

Vite 恐怖的统治力！

使用 Vite 的公司

Vite 的缺点

依赖多个职责重复的第三方库

esbuild：预打包、TS/ JSX 转译、压缩（GO）
Rollup：插件生态、生产环境构建、拆包/产物优化 (TS)
SWC：React HMR 、转译、压缩(Rust) 这些每一个都负责一部分，但是都有自己的缺点，但是他们功能也有重复的地方

Unbundled ESM 在请求数量巨大时存在性能瓶颈

什么是 Unbundled ESM？ Unbundled ESM（未打包的 ECMAScript 模块）是指直接使用原生 ES 模块系统而不将它们合并（打包）成单个文件的开发和部署方式

Rolldown

要解决的问题

兼容 Rollup 的插件 API 和生态
Rust 提升生成构建性能
添加高阶功能
Full bundle mode 解决Vite unbundled ESM 的性能瓶颈

下面是 js 工具链生态，尤大整理前端搭建大型项目头疼的问题：

Rust for JS

尤大的公司官网： https://voidzero.dev/

目的：打造完整的高性能的 JS 工具链

为什么是 Rust？

OXC 各项都是极致的性能

目前在做的： Vite 整合，目前没有通过 Astro 测试 Vite full bundle mode，HMR 和增量打包构建

rolldown 数据：

听不懂：

Vite Next

期待

他们打算交付的产品：

资源：

大会所有 PPT： https://github.com/d2forum/19th
视频： https://www.bilibili.com/video/BV1WERGYDEix

谷歌放大招了！全新升级的多模态能力，强到离谱

Fri, 14 Mar 2025 00:16:42 GMT

大家好，我是 luckySnail，就在昨天谷歌的 Gemini 2.0 Flash Experimental 原生多模态生图功能正式发布，玩了几个小时候，我真的迫不及待的想分享一下，太强大了！先看看它能做的事情：

图片生成
图片编辑
创建图片故事
设计生日贺卡

我们先看一下效果，最后再讲如何体验，如果你想直接体验，可以直接下滑到「使用教程」

图片生成

下面 Gemini 一次生成的我最喜欢的海绵宝宝和派大星，直接就可以使用了！那我们就可以发挥想象力，生成猫和老鼠握手言和的图了！

图片编辑

上面猫和老鼠的文字显示位置可能不太好，我们可以通过对话进行调整：我们还可以基于网图二创：

创建图片故事

这是最有前景的功能，我们使用它来生成一个外卖员从取餐到把外卖送到顾客手中的故事：

下面是让它从 0 到 1 生成游戏人物的示例：绝了！

设计生日贺卡

我觉得这个是非常实用的功能，我目前想到使用它来设计婚礼请帖，大家觉得生成效果怎么样？

设计一张具有中国文化的喜帖卡片。应该使用中国红作为主题色，文字应较大，并写着：“小张 ❤️ 小王的婚礼邀请”

使用教程

目前官方还是免费，不限制，不愧是宇宙大厂 Google，良心！首先游览器打开： https://aistudio.google.com/ （需要魔法）你会看到如下：

刚进入我建议可以先体验一下官方三个示例卡片，了解使用规则，然后就可以尽情发挥想象力了！这时候真的羡慕那些天马行空的人了！

总结

目前几个小时使用感觉生成能力已经很强，但是有时候也会直接返回 ⚠️，在图片微调方面感觉已经到达了生产力的水平了！目前看起来图片故事生成能力是最让人期待的，它能够一次生成具有上下文的图片，我们可以直接使用它进行内容创作了如果你觉得文字干巴巴的，不妨试试，真的好用！

我最近做了自己的产品：https://www.svgshow.cn 。一个能帮你快速将内容转为美观图片的网站，还能在线编辑，我的封面就是使用它生成的

借助 Cursor 做了第一个全栈项目，帮你将内容转为美观的图片

Thu, 13 Mar 2025 00:31:12 GMT

大家好！我是 luckySnail，今天想分享我和 Cursor 一起开发的我的第一个全栈应用，我叫它「SVG 秀」，听名字就知道跟 SVG 沾边，那它是干什么的呢？简单来说，它是使用当下最强的大模型快速将你的内容转为 SVG 图片的工具，并且支持在线编辑，保存，下载。体验地址：https://www.svgshow.cn/，我为每个人提供了 5 次免费体验机会，如果你也想要快速把内容转为生动的图片需求，那我建议你试一下，下面给大家看一下生成的图

我仅仅是将内容上传上去，然后它就给我生成了这样的内容，真的很惊艳！下面看看我是如何结伴 Cursor 完成这个项目的吧！

前端开发

先看看技术栈：

next.js 15.2
Tailwindcss 4
zod
zustand
highlight.js
shadcn/ui
ahooks

基本上都是主流的技术，刚好尝试了一下 next.js 最新版本，开发体验巨大提升，主要体现在：

更详细的报错信息
更快的启动速度和页面跳转速度

开发过 next.js 都知道我在说什么！

前端其实没有特别复杂的部分都是基础的页面开发，值得一提的有两点：

在 svg 生成完成转为 UI 渲染过程中，直接切换有点生硬，这里借住 AI 实现了流畅的过渡动画
由于 SVG 在线编辑器开发比较耗时，这里使用了开源的工具，借住 AI 快速进行汉化，然后通过 iframe 间通信的方式，实现 SVG 在线编辑能力，而且我发现社区目前没有比较好的现成的 SVG 编辑器

虽然开发过程中，绝大多数的代码都是由 AI 生成，但是代码质量应该还是可以的，通过 rules 和微调保证了代码的质量，最后，我将代码开源啦！如果你觉得不错，辛苦帮忙点个 star 吧！这对我是非常大的鼓励！

开源地址：https://github.com/chaseFunny/svg-frontend

后端开发

作为一个前端开发者，后端肯定是要使用 node 来开发的，最近学完了 nest.js ，于是就刚好练手一下！我先在 github 上找到一个 star 比较多的 nest.js 模版：https://github.com/Saluki/nestjs-template

让我先介绍一下这个项目基本情况：

基于Nest.js 10 的 Fastify（ HTTP 服务器），内置健康检查 API
完全的 TypeScript 支持，严格的代码规范校验
集成 Prisma ORM 的 REST API
JWT（jsonwebtoken）认证
Swagger 文档集成
Joi 参数校验、jest 测试
Wiston 日志记录、Nodemon 的开发热重载
标准的开发目录结构
Docker 集成

得到一个基建非常好的项目后，我的完整开发过程如下：

选择使用 PostgreSQL 作为数据库，
借住 AI 帮忙进行数据库设计
完成数据库设计后，编写 schema.prisma 进行数据库初始化
用户模块开发，用户的增删改查
注册登录逻辑开发，这里包含注册需要的邮箱服务，我使用了 nodemailer
全局 JWT 认证守卫开发
SVG 模块开发，我这里应该不是最佳实现，属于跟着 AI 摸石头过河了！
- 主要的接口有：svg 创建，生成，获取，或者指定 id 信息
- svg 生成：这里我使用了 vercel 开源的 ai-sdk ：https://github.com/vercel/ai 来快速进行数据的获取和处理，其实我自己写了一套获取数据，解析数据的代码，但是最后发现不支持并发，才去开源社区找到了 ai-sdk，下次分享一定是分享 ai-sdk 的源码阅读，看看人家是如何在 node 中处理大量请求的
- svg 更新：因为我提供了在线更新 SVG 的能力，所以我是新增了一个表来存 svg 信息和更新记录

到这里就结束了，如果你对开发细节和数据库设计感兴趣，可以查看源码：https://github.com/chaseFunny/svg-backend

上线

开发完成了！就要上线了，真的是瞎折腾还费钱，下面记录一下我使用的在线部署服务：

前端 next.js 和后端 nest.js 其实都是 node 服务，这里最佳方式应该是通过容器化部署，然后再搞一个 CI/CD，但是小作坊还不知道这个项目是什么情况就一切从简吧！我使用的是服务器部署（结合宝塔）

数据库使用的是阿里云免费体验的 RDS 服务，数据库上线参考：https://www.yuque.com/asgas/bzyz7m/hl57otmtcfgr223q

nest.js 服务上线也很简单，把源码弄到服务器，然后通过pm2 部署，这里需要写一个 ecosystem.config.js，详情参考上面的文档

最后就是前端的上线了，next.js 不用说肯定是要部署在 vercel 上呀！但是，我是在国内使用呀！还是老老实实部署在服务器上吧！部署方式也是把源码上传到服务器，然后进行 build 和启动，这里可以写一个脚本，然后通过宝塔面板的 node 部署来进行部署

部署完成后，如果你有自己的域名，你可以去域名配置解析，然后让用户通过域名访问

到这里还差一步就是ssl证书，这里我使用的是腾讯云的免费三个月证书

完结撒花🎉

总结

虽然这个项目业务逻辑不复杂，但是真正开发到上线还是需要一段时间，下面分享一下我的项目开发收获吧！

对请求头，响应头理解更深，熟悉了 Restful 风格 API
熟悉了全栈项目开发流程，深刻感受到后端 > 前端 😭，但是依然热爱前端🩷
数据结构真的很重要，好的数据库设计能够减少很多开发量
AI 真的很强大，但是前提是在开发者本身就不差的情况，感觉 AI 在强者手中能够发挥更大的价值
不要造轮子（有这时间可以读别人的源码，个人觉得更有价值），多看看 github ，了解最新技术动态！
对面向对象编程和面向过程编程理解更加深入

编码经验贴

Tue, 11 Mar 2025 08:33:21 GMT

一、快速找到全局安装的 npm 包地址

npm root -g
# cd 到输出的目录，然后进入
open .

二、找到指定端口的 PID ，然后 kill

ss -tulpn | grep xxxx
kill PID

三、后端默认返回值不安全，做返回异常处理

如何订阅 cursor Pro 会员，超实惠，超实用！

Mon, 03 Mar 2025 13:22:43 GMT

cursor 是什么？

Cursor 是一款人工智能驱动的代码编辑器，旨在提高开发者的生产力。根据网站介绍，Cursor 通过人工智能驱动的代码生成、编辑和调试等功能，帮助开发者更快地编写代码。它提供了一个协作式编程环境，支持实时配对编程。Cursor 集成了 Git 进行版本控制，并支持多种语言和框架。其目标是通过自动化重复任务和提供智能辅助来简化编码工作流程，最终使软件开发更加高效。更多详情，请访问 https://www.cursor.com/。

如何使用 Cursor？

1）下载 & 安装

去 cursor 官网，然后点击右上角的 Download
下载完成后，进行安装

开通会员

目前 cursor 免费有一些额度，但是如果你是深度用户那么就肯定要订阅会员，开通会员有两种方式，我推荐使用第一种方式，快速，还省钱

方式一

去 cursor 官网，点击右上角的账号设置：

然后点击升级到 Pro

然后复制订单地址（页面URL）

然后去闲鱼下单，然后我就会问你要订单地址，然后给你开通，目前全网最低价格 162。

当然，如果你觉得闲鱼麻烦，信的过我，可以直接加我微信：

方式二

如果你打算长期使用 cursor，我建议你购买一个野卡，也非常简单，去野卡官网，推荐使用我的邀请码：FNS4AYLG。你可以领一美元的优惠。

这里介绍一下野卡是什么？

它是一个帮你办理一个美国信用卡的平台，你购买他们的会员，就会给你办一张美区的信用卡，然后你就可以方便的订阅各种国外产品了，放一张图它们支持订阅平台的图：

我们需要先登录，登录后需要购买下面的订阅服务

点击立即开通后，一直到最后充值就好了！

充值完成，我们就有自己的美区信用卡了！

下面我以购买 cursor pro 为例，讲一下如何购买：

最后总结一下：

如果你不确定长久使用 Cursor，推荐第一种方式
如果你打算长期订阅 AI 服务，就使用第二种方式

搭建前端脚手架（上）

Tue, 04 Feb 2025 07:42:07 GMT

在学习 Vue 或者 React 的时候，我们应该都使用过它们的脚手架工具（create-vue、create-react-app）。通过脚手架我们能够快速得到一个 Vue 或者 React 项目，我们无需将经历花在了项目基础骨架搭建上，能够更加快速的开发业务

为了让大家更好明白，我尝试通过场景来一步步讲明白脚手架搭建里面的”门道“，在场景中主人公 - 阿牛，一个不太会写代码的前端开发

脚手架是什么？

在开发自己的脚手架前，我们再认识一下脚手架吧！脚手架是：”一种工具或框架，用于快速生成项目的基础结构、配置文件和代码模板。它通常包含了一些预定义的目录结构、配置文件、依赖管理工具、构建工具等。脚手架的主要目的是减少重复劳动，提高开发效率，并确保项目结构的一致性。“

在前端开发中，脚手架工具通常会帮助我们完成以下任务：

初始化项目目录结构
配置开发环境（如 Webpack、Babel、ESLint 等）
集成常用的库和工具（如 Vue、React、TypeScript 等）
提供代码模板和最佳实践

使用脚手架，我们会得到一个预期的模版项目，这里已经集成了我们需要的基础设施

脚手架解决了什么问题？

初始化项目繁琐：手动创建项目目录、配置文件、安装依赖等步骤非常耗时且容易出错。脚手架可以自动化这些步骤，一键生成项目骨架。
统一开发规范：每个团队都有自己的代码风格、目录结构和依赖管理方式。脚手架可以强制执行这些规范，确保团队成员在统一的环境下工作。
提高开发效率：通过预先配置好的开发环境、构建流程和测试框架，脚手架可以大大提高开发效率，让开发者专注于业务逻辑的实现。
减少重复劳动：在多个项目中使用相同的配置和依赖时，脚手架可以避免重复劳动，提高代码复用率。
降低学习成本：对于新手开发者，脚手架可以提供一个清晰的项目结构和最佳实践，降低学习成本。
团队技术沉淀：团队如果多个项目，在 A 项目实现了 B 功能，在 C 项目也需要，这时候沉淀到脚手架是一个更好的推广的方式，能够减少团队重复劳动，提高效率
最佳实践沉淀：当我们把一些配置，能力集成到脚手架会让我们思考这是不是最佳实现，是不是适合团队等等代码规范问题

这些时候我们不需要脚手架

现有脚手架已经满足我们的需求
项目很简单，手动创建项目就是更好的选择
团队规模小，技术栈很统一，大家都熟悉项目开发规范，就不需要脚手架，额外添加了流程
时间资源少，这时候就不要搭建脚手架了，因为维护脚手架也需要成本

快速跑通一个脚手架搭建核心流程

梳理需求

我们目标就是开发出一个类似 vue cli 的脚手架工具，使用我们自己的脚手架工具来下载我们远程 github 的仓库代码，我们可以先体验一下 create-vue ，运行：

npm create vue@latest

我们根据交互会得到一个基础的项目模板，简单分析一下，主要为三个步骤：

用户在终端运行 npm create xxx ，然后下载一个脚手架包
下载完成后，就会在终端运行一个交互页面，通过一步步的交互，最终我们会得到一个我们想要的包
用户执行完交互逻辑，安装对应的代码到本地，这里我们需要给到友好的下载进度提示和安装完成后的一些提示

功能开发

第一步

我们按照我们分析的步骤一个个开发，最后再优化，我们先来开发第一步(项目名为 create-lucky，注意如果我们希望通过 npm create 来创建项目，项目名称必须以 create- 开头)。

# 创建文件夹并进入
mkdir create-lucky && cd create-lucky
# 初始化 package.json 和 index.js
npm init -y && nano index.js
# 然后我们在 index.js 输入如下代码，注意 第一行必须是 #!/usr/bin/env node
#!/usr/bin/env node

console.log("Hello from create-lucky!");

# 为了让 index.js 文件可以被执行，需要添加执行权限，然后我们运行
chmod +x index.js

# 然后我们需要修改一下 package.json
"main": "src/index.js",
"bin": {
  "create-lucky": "src/index.js"
},

# 本地测试，我们运行 npm link
npm link

# 在任意目录下，运行以下命令来测试脚手架
npm create lucky

# 发布1，先检查 npm register 是否为：https://registry.npmjs.org/
npm get registry

# 发布2，如果没有注册 npm 账号，需要先注册，根据提示你输入用户名、密码和邮箱。
npm login

# 发布3，发布到 npm
npm publish

# 检查发布是否成功，可能有十秒延迟，我们去 https://www.npmjs.com/~luckysnail ，这里 luckysnail 是你的 npm 账号名

# 本地运行 npm create lucky ，验证效果

看到这样，证明第一步就完成了！

第二步

这一步，我们需要在终端创建一个交互，来让用户使用脚手架安装想要的项目

# 引入 inquirer：命令行界面与用户交互的库
npm i inquirer
# 更新 src/index.js 代码

#!/usr/bin/env node

const inquirer = require("inquirer");

async function main() {
  const answers = await inquirer.default.prompt([
    {
      type: "list",
      name: "template",
      message: "请选择你想要使用的模板:",
      choices: ["Vue", "React", "React19", "NextJs"],
    },
    {
      type: "input",
      name: "customUrl",
      message: "请输入项目名称:",
    },
  ]);

  let packageUrl = "";
  if (answers.template === "custom-app") {
    packageUrl = answers.customUrl;
  } else {
    packageUrl = `https://github.com/your-org/${answers.template}`;
  }

  console.log(`你选择的包地址是: ${packageUrl}`);
}

main();
# 重新 npm link 然后测试，没有问题，就 publish 再测试一下

inquirer 更多使用方法：https://www.npmjs.com/package/inquirer

第三步

最后一步，我们就需要根据用户的选择，然后生成对应的代码

# 安装需要的库，chalk：终端字体样式；ora：显示loading动画效果；download-git-repo：下载并提取git仓库
npm i chalk ora download-git-repo

# src/constants.js 定义常量
/** 项目列表 */
export const PROJECT_LIST = [
  {
    name: "vue",
    desc: "vue3 + pinia + vue-router",
    value: "https://github.com/axin-s-Template/vue-light-starter.git",
  },
  {
    name: "React19",
    desc: "React 19 + Tailwind 3 + Biome + RSBuild + shadui/cn 轻量启动模版",
    value: "https://github.com/axin-s-Template/react19-light-starter",
  },
  {
    name: "React",
    desc: "react 轻量模版（适合开发简单应用），使用 Vite + TypeScript + TailwindCss + shadcn/ui + Zustand + react-router-dom 的简单 SPA 启动模版",
    value: "https://github.com/axin-s-Template/react-light-starter",
  },
  {
    name: "NextJs",
    desc: "Next.js 14+ 基础启动模板",
    value: "https://github.com/axin-s-Template/Nextjs-Boilerplate",
  },
];

# 设置 package.json 的 "type": "module",

# 更新 src/index.js
#!/usr/bin/env node

import inquirer from "inquirer";
import chalk from "chalk";
import ora from "ora";
import { promisify } from "util";
import downloadGitRepo from "download-git-repo";
import { PROJECT_LIST } from "./constants.js";

const download = promisify(downloadGitRepo);

async function main() {
  const answers = await inquirer.prompt([
    {
      type: "list",
      name: "template",
      message: "请选择你想要使用的模板:",
      choices: PROJECT_LIST.map((item) => ({
        name: `${item.name} - ${item.desc}`,
        value: item.name.toLowerCase(),
      })),
    },
    {
      type: "input",
      name: "projectName",
      message: "请输入项目名称:",
      validate: (input) => {
        if (!input.trim()) {
          return "项目名称不能为空";
        }
        return true;
      },
    },
  ]);

  const selectedTemplate = PROJECT_LIST.find((item) => item.name.toLowerCase() === answers.template);

  if (!selectedTemplate) {
    console.log(chalk.red("未找到选择的模板"));
    return;
  }

  const spinner = ora("正在下载模板...").start();

  try {
    const repoUrl = selectedTemplate.value.replace("https://github.com/", "").replace(".git", "");
    await download(repoUrl, answers.projectName);
    spinner.succeed(chalk.green("模板下载成功！"));
    console.log(chalk.blue("\n开始使用:"));
    console.log(chalk.cyan(`  cd ${answers.projectName}`));
    console.log(chalk.cyan("  npm install"));
    console.log(chalk.cyan("  npm run dev\n"));
  } catch (err) {
    spinner.fail(chalk.red("下载失败：" + err.message));
    process.exit(1);
  }
}

main().catch((err) => {
  console.error(chalk.red(err));
  process.exit(1);
});

这里，我们运行 node ./src/index.js ，如果看到这样就证明没有问题啦！

到这里，我们基础的脚手架就算是搭建完成了！我们可以发布到npm 仓库，然后再试试，记得先运行 npm unlink create-lucky。然后我们在运行 npm create lucky ，记得每次发布的时候去 package.json 中修改 version

优化

目前这一版本的脚手架工具其实还有很多缺点：

使用 js ，不好维护，脚手架本来就是团队才需要的，所以脚手架的代码，可能是要规范的
目前测试麻烦，使用 npm link 来进行测试，测试完成需要 npm unlink 来取消 link
开发一个命令行工具，连命令参数能力都没有，例如 -v —help 等等都是必须的
不支持动态生成项目的一些信息，例如：我希望通过模版创建的时候就把这个项目的基础信息（项目名称，描述等）都初始化好
终端不够美观，炫酷，这个反倒是很重要的，别人使用你的脚手架第一印象就是终端效果

所以，我们可以使用 monorepo + @clack/prompt 来进行优化一版本

使用 monorepo 来更好的维护代码和验证效果
使用 @clack/prompt 来提供更加美观炫酷的终端交互

关于优化，我会再写一篇！

总结

首先感谢你看到这里，看到着你说明你也认为搭建自己的脚手架是有价值的。在我看来脚手架的价值有两个：

从个人来讲：我觉得脚手架对个人来讲收益是最大的，因为在开发脚手架过程中，你会得到你自己认为的最佳实践，你会搭建出自己的开发规范，这培养了个人的工程化思维，追求极致的思想。
对他人来讲：他人能够通过你的脚手架快速搭建出一个项目骨架。使用你的最佳实践，为他节省了时间。所以在开发完成后，我们需要写文档来推广我们的脚手架

使用字节的 TRAE 开发一个简单的 node 服务

Tue, 21 Jan 2025 04:12:35 GMT

大家好我是 luckySnail。在浏览流媒体的时候，发现都在推荐这个工具，字节刚刚发布了 AI 编辑器 - TRAE（The Real AI Engineer），真正的 AI 引擎吗？，必须赶紧体验一波，刚好想要开发一个小工具，希望它不要让我失望。偷偷说一下它已经让 windows 用户失望了，因为它目前仅支持 mac 电脑。你可以看冴羽的这篇了解TRAE：https://juejin.cn/post/7461825527059611686

初体验

让我们新建一个文件夹，为什么叫这个名字，接下来你就知道了。

接下来我们要做一个工具来帮我监控我的公司项目是否都正常运行。如果出问题了，就需要赶紧通知我出事了，赶紧爬起来修 bug ！

简单的梳理了一下需求，我使用了它的 builder 能力来初始化项目，提问：“我要做一个小的工具来帮我们监控我的公司项目是否都正常运行。如果出问题了，就需要赶紧通知我出事了，赶紧修 bug 。通知方式是邮箱通知，使用前端技术实现，我如何实现？我目前调研可以使用 Playwright 来做充分的网站可用性检测，使用nodemailer 来进行邮箱通知，由于 nodemailer 是必须 node 环境，所以你需要给我搭建一个 node 服务”，这里我是预先告诉了它如何实现，防止它给出不合理的实现方式。

然后它很快理解了我们的需求，并且搭建好了一个基础服务：

启动项目后发现邮箱服务是有问题的，于是我把错误信息给它，然后问它为什么？如何修复？但是会出现：

于是我只能切换 chat 模式，发现是正常的，我把问题和相关代码（使用引用能力）给到它。它也很快发现了问题，然后给出了解决的方法。

我模拟了一个网站出现问题的场景，然后我们可以看到当检查网站存在问题的时候，就会触发发送邮件的逻辑：

到这里基本的流程算是跑通了，我们可以继续提问 AI，代码层面是否可以继续优化：

它给出了一些比较好的建议，我们可以点击“全部接受”，然后先安装依赖，再次启动查看一下效果：

这一次，它给出了更加细致的日志信息，但是我们发现最后一个 error 不太正常，我们问一下 AI 这个是否是正常日志，AI 发现了问题，并进行了修复，我们重启验证逻辑没有问题

邮箱也收到了告警信息！

到这里其实基本的牛马已经做好了，它能够实时的帮我监控网站是否运行良好，保证服务异常及时通知到人。但是真正场景下，需要的不仅仅是网站正常加载，还有很多其他需要监控的东西。

下面我们来看看 AI 的代码水平怎么样吧！

const { chromium } = require("@playwright/test");
const nodemailer = require("nodemailer");
const cron = require("node-cron");
const winston = require("winston"); // 添加日志库

// 配置日志
const logger = winston.createLogger({
  format: winston.format.combine(winston.format.timestamp(), winston.format.json()),
  transports: [
    new winston.transports.File({ filename: "error.log", level: "error" }),
    new winston.transports.File({ filename: "combined.log" }),
    new winston.transports.Console(),
  ],
});

// 邮件配置
const transporter = nodemailer.createTransport({
  host: "smtp.qq.com",
  port: 465, // 修改为465端口
  secure: true, // 设置为true
  auth: {
    user: "3074994545@qq.com", // 补充完整的QQ邮箱地址
    pass: "xxxx", // QQ邮箱授权码
  },
});

// 要监控的网站列表
const websites = [
  {
    name: "老鱼简历",
    url: "https://laoyujianli.com",
    checkElements: [".laoyu-page-container", ".new-index-page", ".template-item"],
  },
  {
    name: "编程导航",
    url: "https://codefather.cn",
    checkElements: [".ant-layout", ".user-name"],
  },
  {
    name: "面试鸭",
    url: "https://mianshiya.cn", // 移除多余的空格
    checkElements: ["#indexPage", ".ant-list-item", "#ccc"],
    retryCount: 3, // 添加重试次数
    retryDelay: 5000, // 重试延迟时间（毫秒）
  },
];

// 浏览器实例管理
let browserInstance = null;
async function getBrowser() {
  if (!browserInstance) {
    browserInstance = await chromium.launch({
      timeout: 60000,
    });
  }
  return browserInstance;
}

// 检查网站可用性
async function checkWebsite(site) {
  const startTime = Date.now();
  const browser = await getBrowser();
  const context = await browser.newContext({
    userAgent:
      "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",
  });

  try {
    const page = await context.newPage();
    logger.info(`正在检查网站: ${site.name}`);

    let lastError;
    // 添加重试机制
    for (let i = 0; i < (site.retryCount || 1); i++) {
      try {
        // 设置页面加载超时时间
        await page.goto(site.url, {
          timeout: 30000,
          waitUntil: "networkidle", // 等待网络空闲
        });

        // 检查关键元素是否存在
        for (const selector of site.checkElements) {
          try {
            await page.waitForSelector(selector, { timeout: 5000 });
          } catch (elementError) {
            console.log(`元素 ${selector} 未找到，继续检查其他元素`);
          }
        }

        console.log(`${site.name} 检查通过`);
        return { success: true };
      } catch (error) {
        lastError = error;
        if (i < (site.retryCount || 1) - 1) {
          console.log(`${site.name} 检查失败，等待 ${site.retryDelay || 5000}ms 后重试...`);
          await new Promise((resolve) => setTimeout(resolve, site.retryDelay || 5000));
        }
      }
    }

    console.error(`${site.name} 检查失败:`, lastError.message);
    return {
      success: false,
      error: lastError.message,
    };
  } finally {
    await context.close(); // 只关闭 context，不关闭浏览器
  }
}

// 添加进程退出时的清理
process.on("SIGTERM", async () => {
  logger.info("服务正在关闭...");
  if (browserInstance) {
    await browserInstance.close();
    browserInstance = null;
  }
  process.exit(0);
});

process.on("SIGINT", async () => {
  logger.info("服务正在关闭...");
  if (browserInstance) {
    await browserInstance.close();
    browserInstance = null;
  }
  process.exit(0);
});

// 发送告警邮件
async function sendAlertEmail(site, error) {
  const mailOptions = {
    from: "3074994545@qq.com", // 使用完整的发件人邮箱
    to: "3074994545@qq.com", // 使用完整的收件人邮箱
    subject: `🚨 网站异常告警: ${site.name}`,
    html: `
      <h2>网站监控告警</h2>
      <p><strong>网站名称:</strong> ${site.name}</p>
      <p><strong>网站地址:</strong> ${site.url}</p>
      <p><strong>错误信息:</strong> ${error}</p>
      <p><strong>发生时间:</strong> ${new Date().toLocaleString()}</p>
    `,
  };

  try {
    await transporter.sendMail(mailOptions);
    console.log(`已发送告警邮件 - ${site.name}`);
  } catch (error) {
    console.error("发送邮件失败:", error);
    // 如果是认证错误，输出更详细的信息
    if (error.code === "EAUTH") {
      console.error("邮箱认证失败，请检查以下内容：");
      console.error("1. 确保QQ邮箱已开启SMTP服务");
      console.error("2. 确保使用的是正确的授权码而不是邮箱密码");
      console.error("3. 访问 https://service.mail.qq.com/cgi-bin/help?subtype=1&&id=28&&no=1001256 获取帮助");
    }
  }
}

// 执行监控任务
async function runMonitoring() {
  // 添加并发限制
  const concurrentLimit = 2;
  const chunks = [];
  for (let i = 0; i < websites.length; i += concurrentLimit) {
    chunks.push(websites.slice(i, i + concurrentLimit));
  }

  for (const chunk of chunks) {
    await Promise.all(
      chunk.map(async (site) => {
        try {
          const result = await checkWebsite(site);
          if (!result.success) {
            await sendAlertEmail(site, result.error);
          }
        } catch (error) {
          logger.error(`监控任务执行失败 (${site.name}):`, {
            error: error.message,
            stack: error.stack,
          });
        }
      })
    );
  }
}

// 添加优雅退出处理
process.on("SIGTERM", async () => {
  logger.info("服务正在关闭...");
  if (browserInstance) {
    await browserInstance.close();
  }
  process.exit(0);
});

// 设置定时任务，每5分钟执行一次监控
cron.schedule("*/5 * * * *", () => {
  console.log("开始执行网站监控...");
  runMonitoring();
});

// 立即执行一次监控
console.log("启动网站监控服务...");
runMonitoring();

你觉得写的怎么样呢？我觉得蛮好的：

代码逻辑清晰，每个函数都符合单一原则，开发中它也提醒我要把 websites 配置信息单独创建文件存储
能够基于代码进行重构优化，使用社区流行的 winston 日志库来记录信息
有重试，try catch 兜底逻辑

总结

TRAE 的 UI 和交互不输 cursor
builder 模式下，提出一个需求，它能快速帮我拆解需求，生成项目，安装依赖，启动项目到最后的 web 预览。这对没有接触过编程的人更加友好
在有些时候，它也会乱说，明明有问题，但是硬说已经解决了！
连接不稳定，经常网络错误，这个非常影响开发体验
免费使用 claude 3.5 和 chatGpt 很香。
代码块右上角的一些能力非常好用，例如应用功能，能够智能的把相关的内容进行替换，然后通过 diff 清晰的让你知道你修改了什么
感觉模型深度链接了代码上下文，能给出和我目前项目相关的代码
暴论：由于模型能力的限制，无论如何优化交互，流程。目前没有编程基础的人很难使用 AI 编辑器开发出真正的产品

需要深度使用才能发现它更多使用场景！

源码：https://github.com/chaseFunny/niuma

再回首，一次很失败的项目负责人体验

Sat, 11 Jan 2025 09:57:46 GMT

简单介绍一下我自己，我叫阿星，我目前是一名前端开发，工作快两年了（22 年毕业），目前在一家创业公司打工，在班主任的鼓励下，我做出了大胆的决定，要来分享，可能接下来的分享会浪费大家的时间，但是我依然希望你听完，那今天要分享的是我在最近一个多月成为（最菜的）项目负责人的经历和收获，那直接进入正题，我的独立负责项目经历

为什么需要我独立负责项目？

2 月底的时候，我记得很清楚，那天是周一，晚上老板说要请客吃饭，和我们说一件事情。我带着疑问去到饭店，然后和我们说，他今天聊了一位很厉害的产品大佬，产品哥分析我们公司目前的发展现状和遇到的问题。老板说，已经确定他要加入我们团队，来帮我们公司更好的发展。我当时听完很开心，因为有一个经历丰富的人加入我们公司，也就代表着我所在的平台更好了，我们公司有了更多的可能性。而且产品哥对我们公司的分析总结我也很是赞同。

三月初，产品哥来了，新人来，老板请客吃饭，在吃饭的过程中，产品哥通过对公司现状分析，得出了两个结论，

所有工作都依赖于老板安排，员工没有主人翁意识。也缺少目标感
目前整体处于“温水煮青蛙”状态，不好不坏，这不是创业公司该有的样子

我们在产品哥的分析下，引出了“负责人制度”，以项目为单位，每个项目设立一个负责人，也可以称作为“小组长”，每个负责人的工作是承担老板之前的工作。之前的时候，是老板想需求，并且细化需求，然后给需求进行排期，分配资源，开发上线。那现在就变成了负责人来规划工作，向老板争取资源，然后排期，然后开发上线，只是需要汇报一下工作给老板。听起来好像负责人也不是很难做的样子，但是真正来做的事情，真的是手忙脚乱，不过还好，产品哥和老板说，不会一下子放手让我们做，而是辅助我们，让我们慢慢独立负责，遇到问题都可以问他们。初出牛犊不怕虎的我，自告奋勇的说，我想尝试一下这个负责人制度

我做了什么？

制定计划，开会同步计划： 每周一，制定本周计划，拆解需求为尽可能小的需求，然后对需求进行排期，并记录文档，发起会议，确定需求是否要做，和老板同步需求所需要的时间和需要的人力

和同事沟通，推进工作： 会议结束，要通知到对应的人，这周需要他们怎么做，例如：和后端说，我需要你做什么，大概什么时间前得给我，你自己安排一下优先级，

开发上线，同步老板： 接下来就是我的日常工作，前端开发，这段时间，

我和后端搭建了一套简陋的数据看板，并且根据数据看板的数据对项目进行了优化，上线后及时查看改动对数据的影响，反馈给到同事和老板，
对竞品做深度分析，和产品哥对我们产品（用户使用路径，用户充值路径等等）多纬度进行优化，提高用户的使用体验
每周 5 会把本周完成的工作，未完成的工作做一个简单汇报给到老板，

掌控整体进度，及时反馈风险： 我还会偶尔当当最不喜欢的监工，例如：pr 没过，要及时催处理，写完需求及时验收测试。如果有需求发现完成不了了，及时和上级反馈，寻求解决办法

维护社群，文档，每日同步看板数据，分析数据：这段时间，我开始了维护社群，发一些产品更新动态公告，用户问题反馈收集等工作。每日在工作群和同事同步昨日的看板数据，分析数据，可能会产生一些新的需求，记录到需求池里

上面都是一些好的，下面说点不好的

预估时间不准确，需求延期： 我根据我的经验，和同事沟通，一起确定的上线日期，总是会很赶，甚至延期。

无法准确思考需求优先级： 感觉自己对产品理解还是不够，会做一些不是那么紧急的工作，但是有优先级更高的工作在等着我们

我学习到了什么？

二月底还是只用写写需求，少写 bug，保证需求不延期就好的前端螺丝钉，转眼就要成为一个项目负责人。习惯了被分配工作的我，脑子像是生了锈，根本不知道要做什么？怎么规划？按照什么规划？但是我有产品哥😎啊，我就去问他，他没有直接告诉我，我要怎么做，或者说这让我来吧！而是说：从数据中找答案，从竞品中分析，然后他教会了我如何进行简单的数据分析，来对现有的产品进行用户体验提升。跟他一起这段时间，我学到了很多

先处理情绪再处理工作： 那段时间的我，做需求总是 bug 不断，就是因为我目前的工作有多个项目，杂乱，每天要做的事情感觉太多了，每天工作都处于需求马上要延期了，我得快点了，这种紧张状态下写的代码就会有很多问题，后来我看到群里推荐的**《搞定 - 无压力工作的艺术》**，我学到了先处理情绪，现在我会在精力不集中，情绪不稳定的时候先做点别的，例如：去接水，喝水，和同事唠嗑等等来解压

清空大脑，专注当下工作： 这个也是搞定那本书里的技巧，我现在每天都在实践，例如：工作中，突然企业微信的用户群里，反馈问题，我会看这个需求 5 分钟是否能搞定，可以的话立马做了，不可以记录文档（365 的 todo list），然后等主线任务完成，统一处理，我打算接下来要继续践行番茄工作法，提高自己的工作专注

及时沟通，不让问题称为大问题： 我是一个 i 人，遇到问题了，尤其是因为我导致的问题，我害怕上报，害怕挨批，但是现在我不会再这样，我带着解决问题的心态，即使是不好的事情，也硬着头皮去反馈，和团队一起商量解决办法，因为不反馈只会让问题变成大问题，

数据驱动业务： 也就是通过分析数据，来对产品进行优化，这样做需求都是有数据支撑，

敏捷开发： 以前的时候是拿到需求就开始开发，开发中思考什么实现，现在是看到需求立马就想这个需求是否有技术难点，需要谁配合，大概需要多少时间，这个需求是否有必要再拆解为更小的需求等等。并且开发中也是给一个需求建立一个独立的分支，这样能做到快速开发，快速上线，准切分析这个改动的影响

遵守原则： 在开发中，一定要遵守规定好的原则，例如：上线前要 code review，多人验收，上线收也要再次测试。在日常工作中要遵守，在处理紧急 bug 的时候，依然要遵守约定

多独立思考，总结和反思自己的行为： 当负责人这段时间，刚好上期训练营，我就每天记录自己当日的不足之处，如何改进，我得到了一些我觉得很厉害的结论，例如：幸福是一种能力，要有发现幸福的眼睛；

我的一些感悟

独立负责项目这段时间，我被批评过，也被表扬过，真的很累，但是还是要感谢有一个这样的平台，让我来尝试，真的是痛并快乐着，我觉得我从一个被动接收方变成了一个主动方，我现在无论是在生活上，还是再工作上，我都尽可能让自己处于主动方。虽然直到现在，我依然不太适应这种主动推动一些事情，

在做负责人最初一段时间，我真的走路洗澡都在想工作的事情，但是我想说，这是不健康的，要平衡工作和生活，我现在尽可能工作中保持高效率，准点下班，回来学羽哥的《next.js 小册》，

压力很大的时候要多和人交流，多出去走走，

为什么是失败的负责人？

在这段时间，虽然有在思考，但认知不足，经验缺失，导致最后结果是不好的。

职场感悟（长期更新）

Sat, 11 Jan 2025 09:46:22 GMT

以下是个人在职场的真实感悟

做好文档沉淀：当遇到 bug，解决复杂问题，业务逻辑复杂等等，都可以记录下来
减少信息差：如果一个事情可以让大家都知道，就不需要私聊，把信息同步给到大家，说不定就能让事情做得更好

参考资料

如何做好技术 PM: https://mp.weixin.qq.com/s/Mur302t7-8444vaxLLUKgA

React V19 官方 blog（翻译）

Sat, 11 Jan 2025 08:42:12 GMT

React 19 来啦！

2024 年 12 月 5 日，React 团队发布

说明 React 19 现已稳定！

自 4 月发布 React 19 RC 版本以来，新增内容如下：

挂起树的预热：请参阅 Suspense 的改进。

React DOM 静态 API：请参阅新的 React DOM 静态 API。

本文日期已更新以反映稳定版发布日期。

React v19 现已发布到 npm！

在我们的 React 19 升级指南中，我们分享了将您的应用程序升级到 React 19 的逐步说明。在这篇文章中，我们将概述 React 19 中的新功能，以及如何采用这些功能。

有关破坏性更改的列表，请参阅升级指南。

React 19 的新功能

Actions

在 React 应用程序中，一个常见的用例是执行数据变更，然后更新状态以响应变更。例如，当用户提交表单以更改其名称时，您将发出 API 请求，然后处理响应。在过去，您需要手动处理挂起状态、错误、乐观更新和顺序请求。

例如，您可以使用 useState 来处理挂起和错误状态：

// Before Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  const handleSubmit = async () => {
    setIsPending(true);
    const error = await updateName(name);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    }
    redirect("/path");
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

在 React 19 中，我们新增了对在过渡（transitions）中使用异步函数的支持，以自动处理挂起状态、错误、表单和乐观更新。

例如，您可以使用 useTransition 来为您处理挂起状态：

// Using pending state from Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const error = await updateName(name);
      if (error) {
        setError(error);
        return;
      }
      redirect("/path");
    })
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

异步过渡会立即将 isPending 状态设置为 true，发出异步请求，并在任何过渡完成后将 isPending 切换为 false。这使得您可以在数据变更期间保持当前 UI 的响应性和交互性。

说明按照惯例，使用异步过渡的函数被称为“Actions”。

Actions 会自动为您管理数据提交：

挂起状态：Actions 提供了一个挂起状态，该状态在请求开始时启动，并在最终状态更新提交后自动重置。

乐观更新：Actions 支持新的 useOptimistic 钩子，因此您可以在请求提交时向用户显示即时反馈。

错误处理：Actions 提供了错误处理功能，因此您可以在请求失败时显示错误边界，并自动将乐观更新恢复为其原始值。

表单：<form> 元素现在支持将函数传递给 action 和 formAction 属性。将函数传递给 action 属性会默认使用 Actions，并在提交后自动重置表单。

基于 Actions，React 19 引入了 useOptimistic 来管理乐观更新，以及一个新的钩子 React.useActionState 来处理 Actions 的常见用例。在 react-dom 中，我们添加了 <form> Actions 来自动管理表单，以及 useFormStatus 来支持表单中 Actions 的常见用例。

在 React 19 中，上述示例可以简化为：

// Using <form> Actions and useActionState
function ChangeName({ name, setName }) {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const error = await updateName(formData.get("name"));
      if (error) {
        return error;
      }
      redirect("/path");
      return null;
    },
    null,
  );

  return (
    <form action={submitAction}>
      <input type="text" name="name" />
      <button type="submit" disabled={isPending}>Update</button>
      {error && <p>{error}</p>}
    </form>
  );
}

在下一节中，我们将详细介绍 React 19 中的每个新 Action 功能。

新钩子：useActionState

为了让 Actions 的常见用例更简单，我们添加了一个名为 useActionState 的新钩子：

const [error, submitAction, isPending] = useActionState(
  async (previousState, newName) => {
    const error = await updateName(newName);
    if (error) {
      // 您可以返回操作的任何结果。
      // 这里，我们仅返回错误。
      return error;
    }
    // 成功处理
    return null;
  },
  null,
);

useActionState 接受一个函数（即“Action”），并返回一个包装后的 Action 以供调用。这是可行的，因为 Actions 是可组合的。当调用包装后的 Action 时，useActionState 会将 Action 的最后一个结果作为 data 返回，并将 Action 的挂起状态作为 pending 返回。

注意在 Canary 版本中，React.useActionState 之前被称为 ReactDOM.useFormState，但我们已将其重命名并弃用了 useFormState。有关更多信息，请参阅 #28491。

更多详细信息，请参阅 useActionState 的文档。

React DOM：`<form>` Actions

Actions 还与 React 19 的新 <form> 功能集成，适用于 react-dom。我们新增了对将函数作为 <form>、<input> 和 <button> 元素的 action 和 formAction 属性的支持，以使用 Actions 自动提交表单：

<form action={actionFunction}>

当 <form> 的 Action 成功时，React 会自动为非受控组件重置表单。如果您需要手动重置 <form>，可以调用新的 requestFormReset React DOM API。

有关更多信息，请参阅 react-dom 文档中的 <form>、<input> 和 <button>。

React DOM：新钩子：useFormStatus

在设计系统中，通常需要编写需要访问其所在 <form> 信息的设计组件，而无需将属性逐层传递到组件中。这可以通过 Context 实现，但为了使常见用例更简单，我们添加了一个新钩子 useFormStatus：

import {useFormStatus} from 'react-dom';

function DesignButton() {
  const {pending} = useFormStatus();
  return <button type="submit" disabled={pending} />
}

useFormStatus 会读取父级 <form> 的状态，就像表单是一个 Context 提供者一样。

有关更多信息，请参阅 react-dom 文档中的 useFormStatus。

新钩子：useOptimistic

在执行数据变更时，另一个常见的 UI 模式是在异步请求进行时乐观地显示最终状态。在 React 19 中，我们添加了一个名为 useOptimistic 的新钩子，以使这一过程更加简单：

function ChangeName({currentName, onUpdateName}) {
  const [optimisticName, setOptimisticName] = useOptimistic(currentName);

  const submitAction = async formData => {
    const newName = formData.get("name");
    setOptimisticName(newName);
    const updatedName = await updateName(newName);
    onUpdateName(updatedName);
  };

  return (
    <form action={submitAction}>
      <p>Your name is: {optimisticName}</p>
      <p>
        <label>Change Name:</label>
        <input
          type="text"
          name="name"
          disabled={currentName !== optimisticName}
        />
      </p>
    </form>
  );
}

useOptimistic 钩子会在 updateName 请求进行时立即渲染 optimisticName。当更新完成或出错时，React 会自动切换回 currentName 值。

有关更多信息，请参阅 useOptimistic 的文档。

新 API：use

在 React 19 中，我们引入了一个新的 API 来在渲染时读取资源：use。

例如，您可以使用 use 读取一个 promise，React 将会暂停（Suspend）直到该 promise 解决：

import {use} from 'react';

function Comments({commentsPromise}) {
  // `use` will suspend until the promise resolves.
  const comments = use(commentsPromise);
  return comments.map(comment => <p key={comment.id}>{comment}</p>);
}

function Page({commentsPromise}) {
  // When `use` suspends in Comments,
  // this Suspense boundary will be shown.
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  )
}

注意

use 不支持在渲染中创建的 promise。

如果您尝试将渲染中创建的 promise 传递给 use，React 会发出警告：A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework. 翻译报错：一个组件被未缓存的 promise 暂停了。目前不支持在客户端组件或钩子中创建 promise，除非通过兼容 Suspense 的库或框架。

要解决此问题，您需要从支持缓存 promise 的 Suspense 驱动的库或框架中传递 promise。未来我们计划推出功能，以便更轻松地在渲染中缓存 promise。

您还可以使用 use 读取上下文，从而允许您在条件语句（如提前返回后）中读取上下文：

import {use} from 'react';
import ThemeContext from './ThemeContext'

function Heading({children}) {
  if (children == null) {
    return null;
  }

  // This would not work with useContext
  // because of the early return.
  const theme = use(ThemeContext);
  return (
    <h1 style={{color: theme.color}}>
      {children}
    </h1>
  );
}

use API 只能在渲染中调用，类似于钩子。与钩子不同的是，use 可以在条件语句中调用。未来我们计划支持更多在渲染中使用 use 消费资源的方式。

有关更多信息，请参阅 use 的文档。

新的 React DOM 静态 API

我们为静态站点生成向 react-dom/static 添加了两个新 API：

这些新 API 通过等待数据加载以生成静态 HTML，改进了 renderToString。它们旨在与 Node.js 流和 Web 流等流式环境配合使用。例如，在 Web 流环境中，您可以使用 prerender 将 React 树预渲染为静态 HTML：

import { prerender } from 'react-dom/static';

async function handler(request) {
  const {prelude} = await prerender(<App />, {
    bootstrapScripts: ['/main.js']
  });
  return new Response(prelude, {
    headers: { 'content-type': 'text/html' },
  });
}

预渲染 API 将等待所有数据加载完毕后再返回静态 HTML 流。流可以转换为字符串，或通过流式响应发送。它们不支持在加载时流式传输内容，这是现有的 React DOM 服务器渲染 API 所支持的。

有关更多信息，请参阅 React DOM 静态 API。

React 服务器组件

服务器组件

服务器组件是一种新选项，允许在与客户端应用程序或 SSR 服务器分离的环境中提前渲染组件，然后再进行打包。这个独立的环境就是 React 服务器组件中的“服务器”。服务器组件可以在 CI 服务器上构建时运行一次，也可以使用 Web 服务器为每个请求运行。

React 19 包含了从 Canary 渠道引入的所有 React 服务器组件功能。这意味着支持服务器组件的库现在可以将 React 19 作为对等依赖项，并使用 react-server 导出条件以在支持全栈 React 架构的框架中使用。

注意

如何构建对服务器组件的支持？虽然 React 19 中的 React 服务器组件是稳定的，并且在次要版本之间不会破坏，但用于实现 React 服务器组件打包器或框架的底层 API 不遵循语义版本控制，可能会在 React 19.x 的次要版本之间破坏。

作为打包器或框架支持 React 服务器组件时，我们建议固定到特定的 React 版本，或使用 Canary 版本。我们将继续与打包器和框架合作，以稳定未来用于实现 React 服务器组件的 API。

更多信息，请参阅 React 服务器组件的文档。

服务器操作

服务器操作允许客户端组件调用在服务器上执行的异步函数。

当使用 "use server" 指令定义服务器操作时，您的框架会自动创建对服务器函数的引用，并将该引用传递给客户端组件。当在客户端调用该函数时，React 会向服务器发送请求以执行该函数，并返回结果。

注意

服务器组件没有指令。一个常见的误解是服务器组件由 "use server" 表示，但服务器组件没有指令。"use server" 指令用于服务器操作。

更多信息，请参阅指令的文档。

服务器操作可以在服务器组件中创建并作为属性传递给客户端组件，也可以在客户端组件中导入并使用。

更多信息，请参阅 React 服务器操作的文档。

React 19 的改进

ref 作为属性

从 React 19 开始，您现在可以将 ref 作为函数组件的属性访问：

function MyInput({placeholder, ref}) {
  return <input placeholder={placeholder} ref={ref} />
}

//...
<MyInput ref={ref} />

新的函数组件将不再需要 forwardRef，我们将发布一个代码修改工具，自动更新您的组件以使用新的 ref 属性。在未来的版本中，我们将弃用并移除 forwardRef。

注意

传递给类组件的 refs 不会作为属性传递，因为它们引用的是组件实例。

水合( hydration )错误的差异

我们还改进了 react-dom 中水合错误的错误报告。例如，不再是在开发环境中记录多个错误而没有关于不匹配的任何信息：

我们现在会记录一条包含不匹配差异的单一消息：

`<Context>` 作为提供者

在 React 19 中，您可以将 <Context> 渲染为提供者，而不是 <Context.Provider>。

const ThemeContext = createContext('');

function App({children}) {
  return (
    <ThemeContext value="dark">
      {children}
    </ThemeContext>
  );
） ；
}

新的 Context 提供者可以使用 <Context>，我们将发布一个代码修改工具来转换现有的提供者。在未来的版本中，我们将弃用 <Context.Provider>。

ref 的清理函数

我们现在支持从 ref 回调中返回清理函数：

<input
  ref={(ref) => {
    // ref created

    // NEW: return a cleanup function to reset
    // the ref when element is removed from DOM.
    return () => {
      // ref cleanup
    };
  }}
/>

当组件卸载时，React 将调用从 ref 回调返回的清理函数。这适用于 DOM ref、类组件的 ref 以及 useImperativeHandle。

注意

以前，当卸载组件时，React 会使用 null 调用 ref 函数。如果您的 ref 返回一个清理函数，React 现在将跳过此步骤。

在未来的版本中，我们将在卸载组件时弃用使用 null 调用 ref。

由于引入了 ref 清理函数，现在从 ref 回调返回任何其他内容都将被 TypeScript 拒绝。修复方法通常是停止使用隐式返回，例如：

- <div ref={current => (instance = current)} />
+ <div ref={current => {instance = current}} />

原始代码返回了 HTMLDivElement 的实例，而 TypeScript 无法判断这是否是有意返回的清理函数，或者您是否不希望返回清理函数。

您可以使用 no-implicit-ref-callback-return 代码修改工具来修复此模式。

useDeferredValue 初始值

我们为 useDeferredValue 添加了一个 initialValue 选项：

function Search({deferredValue}) {
  // On initial render the value is ''.
  // Then a re-render is scheduled with the deferredValue.
  const value = useDeferredValue(deferredValue, '');

  return (
    <Results query={value} />
  );
}

当提供了 initialValue 时，useDeferredValue 将在组件的初始渲染中将其作为 value 返回，并在后台安排一次重新渲染，返回 deferredValue。

更多信息，请参阅 useDeferredValue。

对文档元数据的支持

在 HTML 中，诸如 <title>、<link> 和 <meta> 等文档元数据标签被保留用于放置在文档的 <head> 部分。在 React 中，决定应用程序使用哪些元数据的组件可能离渲染 <head> 的地方非常远，或者 React 根本不渲染 <head>。过去，这些元素需要在 effect 中手动插入，或者通过像 react-helmet 这样的库来插入，并且在服务器渲染 React 应用程序时需要小心处理。

在 React 19 中，我们增加了对在组件中原生渲染文档元数据标签的支持：

function BlogPost({post}) {
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="https://twitter.com/joshcstory/" />
      <meta name="keywords" content={post.keywords} />
      <p>
        Eee equals em-see-squared...
      </p>
    </article>
  );
}

当 React 渲染此组件时，它会识别 <title>、<link> 和 <meta> 标签，并自动将它们提升到文档的 <head> 部分。通过原生支持这些元数据标签，我们能够确保它们适用于仅客户端的应用程序、流式 SSR 和服务器组件。

注意

您可能仍然需要一个元数据库

对于简单的用例，将文档元数据渲染为标签可能是合适的，但库可以提供更强大的功能，例如根据当前路由用特定元数据覆盖通用元数据。这些功能使框架和库（如 react-helmet）更容易支持元数据标签，而不是替换它们。

更多信息，请参阅 <title>、<link> 和 <meta> 的文档。

对样式表的支持

由于样式优先级规则，外部链接的样式表（<link rel="stylesheet" href="...">）和内联样式表（<style>...</style>）需要在 DOM 中小心定位。构建一个允许在组件内组合的样式表功能是很困难的，因此用户通常最终会加载所有样式，远离可能依赖它们的组件，或者使用封装了这种复杂性的样式库。

在 React 19 中，我们正在解决这种复杂性，并通过内置的样式表支持，提供更深入的客户端并发渲染和服务器流式渲染集成。如果您告诉 React 样式表的 precedence，它将管理样式表在 DOM 中的插入顺序，并确保样式表（如果是外部的）在显示依赖这些样式规则的内容之前加载。

function ComponentOne() {
  return (
    <Suspense fallback="loading...">
      <link rel="stylesheet" href="foo" precedence="default" />
      <link rel="stylesheet" href="bar" precedence="high" />
      <article class="foo-class bar-class">
        {...}
      </article>
    </Suspense>
  )
}

function ComponentTwo() {
  return (
    <div>
      <p>{...}</p>
      <link rel="stylesheet" href="baz" precedence="default" />  <-- will be inserted between foo & bar
    </div>
  )
}

在服务器端渲染期间，React 会将样式表包含在 <head> 中，这确保浏览器在加载样式表之前不会进行绘制。如果样式表在已经开始流式传输后才被发现，React 将确保在显示依赖该样式表的 Suspense 边界内容之前，将样式表插入客户端的 <head> 中。

在客户端渲染期间，React 会等待新渲染的样式表加载完成后再提交渲染。如果您在应用程序中的多个位置渲染此组件，React 只会将样式表包含在文档中一次：

function App() {
  return <>
    <ComponentOne />
    ...
    <ComponentOne /> // won't lead to a duplicate stylesheet link in the DOM
  </>
}

对于习惯于手动加载样式表的用户来说，这是一个将样式表与依赖它们的组件放在一起的机会，从而实现更好的局部推理，并更容易确保仅加载实际依赖的样式表。

样式库和与打包器的样式集成也可以采用这一新功能，因此即使您不直接渲染自己的样式表，当您的工具升级以使用此功能时，您仍然可以受益。

更多详细信息，请阅读 <link> 和 <style> 的文档。

对异步脚本的支持

在 HTML 中，普通脚本（<script src="...">）和延迟脚本（<script defer="" src="...">）按文档顺序加载，这使得在组件树深处渲染这些脚本具有挑战性。然而，异步脚本（<script async="" src="...">）将以任意顺序加载。

在 React 19 中，我们通过允许您在组件树中的任何位置渲染异步脚本（在实际依赖脚本的组件内部），而无需管理脚本实例的重新定位和去重，从而提供了更好的支持。

function MyComponent() {
  return (
    <div>
      <script async={true} src="..." />
      Hello World
    </div>
  )
}

function App() {
  <html>
    <body>
      <MyComponent>
      ...
      <MyComponent> // won't lead to duplicate script in the DOM
    </body>
  </html>
}

在所有渲染环境中，异步脚本将被去重，因此即使多个不同的组件渲染了相同的脚本，React 也只会加载并执行一次。

在服务器端渲染中，异步脚本将被包含在 <head> 中，并优先于阻塞绘制的更关键资源（如样式表、字体和图像预加载）之后加载。

更多详细信息，请阅读 <script> 的文档。

对预加载资源的支持

在初始文档加载和客户端更新期间，尽早告知浏览器可能需要加载的资源可以显著提高页面性能。

React 19 包含了许多用于加载和预加载浏览器资源的新 API，使构建不受低效资源加载影响的出色体验变得尽可能简单。

import { prefetchDNS, preconnect, preload, preinit } from 'react-dom'
function MyComponent() {
  preinit('https://.../path/to/some/script.js', {as: 'script' }) // loads and executes this script eagerly
  preload('https://.../path/to/font.woff', { as: 'font' }) // preloads this font
  preload('https://.../path/to/stylesheet.css', { as: 'style' }) // preloads this stylesheet
  prefetchDNS('https://...') // when you may not actually request anything from this host
  preconnect('https://...') // when you will request something but aren't sure what
}

<!-- the above would result in the following DOM/HTML -->
<html>
  <head>
    <!-- links/scripts are prioritized by their utility to early loading, not call order -->
    <link rel="prefetch-dns" href="https://...">
    <link rel="preconnect" href="https://...">
    <link rel="preload" as="font" href="https://.../path/to/font.woff">
    <link rel="preload" as="style" href="https://.../path/to/stylesheet.css">
    <script async="" src="https://.../path/to/some/script.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

这些 API 可用于优化初始页面加载，通过将字体等额外资源的发现移出样式表加载过程。它们还可以通过预取预期导航使用的资源列表，然后在点击或悬停时急切地预加载这些资源，从而使客户端更新更快。

更多详细信息，请参阅资源预加载 API。

与第三方脚本和扩展的兼容性

我们改进了水合过程，以考虑第三方脚本和浏览器扩展。

在水合过程中，如果客户端渲染的元素与服务器 HTML 中的元素不匹配，React 将强制客户端重新渲染以修复内容。以前，如果元素是由第三方脚本或浏览器扩展插入的，则会触发不匹配错误并导致客户端渲染。

在 React 19 中，<head> 和 <body> 中的意外标签将被跳过，从而避免不匹配错误。如果 React 由于不相关的水合不匹配而需要重新渲染整个文档，它将保留由第三方脚本和浏览器扩展插入的样式表。

更好的错误报告

我们在 React 19 中改进了错误处理，以减少重复并提供处理捕获和未捕获错误的选项。例如，当渲染过程中出现被错误边界捕获的错误时，以前 React 会抛出错误两次（一次是原始错误，另一次是在自动恢复失败后），然后调用 console.error 并提供有关错误发生位置的信息。

这导致每个捕获的错误都会产生三个错误：

在 React 19 中，我们记录一个包含所有错误信息的单一错误：

此外，我们还添加了两个新的根选项来补充 onRecoverableError：

onCaughtError：当 React 在错误边界中捕获错误时调用。
onUncaughtError：当抛出错误且未被错误边界捕获时调用。
onRecoverableError：当抛出错误并自动恢复时调用。

更多信息和示例，请参阅 createRoot 和 hydrateRoot 的文档。

对自定义元素的支持

React 19 添加了对自定义元素的全面支持，并通过了 Custom Elements Everywhere 的所有测试。

在过去的版本中，在 React 中使用自定义元素一直很困难，因为 React 将无法识别的属性视为属性（attributes）而不是属性（properties）。在 React 19 中，我们添加了对属性的支持，该支持在客户端和 SSR 期间有效，具体策略如下：

服务器端渲染：传递给自定义元素的属性如果其类型是原始值（如 string、number 或值为 true），则将渲染为属性（attributes）。具有非原始类型（如 object、symbol、function 或值为 false）的属性将被省略。
客户端渲染：与自定义元素实例上的属性（properties）匹配的属性将作为属性（properties）分配，否则将作为属性（attributes）分配。

感谢 Joey Arhar 推动了 React 中自定义元素支持的设计和实现。

如何升级

请参阅 React 19 升级指南，了解逐步说明以及破坏性更改和重要更改的完整列表。

注意：本文最初发布于 2024 年 4 月 25 日，并于 2024 年 12 月 5 日更新为稳定版。

原文：https://react.dev/blog/2024/12/05/react-19#new-hook-useformstatus

以上翻译由 deepseek + 人工校验

2024 碎碎念

Sun, 05 Jan 2025 04:36:46 GMT

大家好，我是 luckySnail。写这篇文章的时候已经是 2025 年的第五天了，站在这个时间点，回顾过去一年，虽然有不足，遗憾。但是总体来讲还是向前的。写习惯了技术文章，可以一气呵成，突然写没有主题的文章，我一时间看着白纸不知道说什么，那就想到什么就说什么吧！

AI 对我的改变

过去这一年中，我打字最多的地方不是代码编辑器，也不是微信输入框，而是 AI 对话输入框。已经真的成为了一个严重依赖 AI 的开发者。在过去的一年中，我写关于 AI 的文章应该不低于 10 篇，AI coding 在我看来已经非常强大，这一切都得益于 claude 3.5 sonnet 和 cursor，如果你还不了解，可以看我的文章: https://www.luckysnail.cn/posts/post-27 。如果你想要深入关注这个领域，我推荐你关注「宝玉」，他的个人博客： https://baoyu.io/ 。由于现在模型已经非常强大，我觉得无需非常专业的 prompt 我们都可以得到不错的生成的结果，关键是需要不断尝试，寻找经验，这里有一些我已经整理好的经验： https://www.luckysnail.cn/posts/post-31 ，宝玉也分享了自己的经验： https://baoyu.io/blog/2025-prompt-engineering-tips 。在这一年中，我使用过的 AI 工具有：

阿里的通义灵码、通义千问: https://tongyi.aliyun.com/
腾讯的 VSCode 编程助手: https://copilot.tencent.com/
更懂程序员的 devv.ai: https://devv.ai/
github copilot : https://github.com/features/copilot
deepseek: https://chat.deepseek.com/
gmini : https://gemini.google.com/
cursor: https://www.cursor.com/
mascode: https://www.marscode.com/
豆包: https://www.doubao.com/chat/

以上工具中目前在使用的是 devv 和 github copilot，devv 聚合了基本上最强的大模型，并且在 RGA 和交互方面我觉得是很好的，github copilot 目前是结合 VSCode 来使用，它目前会提供免费的额度，而且目前支持的能力也非常多，够用了。 AI 对程序员来说绝对是利好的，它让普通的我能够快速让想法落地；让普通的我快速学会一个新的知识；让普通的我看到超级个体的希望。新的一年，我应该会更少的注意力在尝鲜新的 AI 工具，当然出圈的另说。

认知

2024 年，毫无疑问是我对自己认识更加清晰，深刻的发现自己认知不足的一年。这一年我浅薄的认识到了：

开发完成，仅仅是开发，上线后的维护，回归测试等等才是重头戏
代码 review 很重要：写完代码也仅仅说刚开始，还需要思考是否是最佳实现，是否有业务没有兼容的场景等等。
技术仅仅是解决问题的手段
好的设计可以减少后期和客户沟通，坏的设计全是反馈
功能实现很重要，易用性也同样重要
好的沟通能够减少很多工作
关注数据，关注客户，关注业务价值
世界是一个巨大的草台班子，人生是旷野
热情是第一生产力，passion
还有很多很多。。。以上很多我都没有知行合一，其实我仅仅说短暂的知道，记录下来，新的一年我要带着更加谦卑平和的心态去生活，去工作

注意力

这一年，我分享了一个非常有名的症状：错失恐惧症（FOMO： Fear of Missing Out）。我发现我也是病入膏肓了。2024 是被无效信息绑架的一年，因为一些无效信息还徒增的烦恼和焦虑。

这一年，我虽然很多时间在娱乐，但是同比之前的自己更加自律，新的一年只要比 2024 更好一点我就满足了

这一年，除了看无用信息和娱乐，我也是有在学习新的知识的，

希望新的一年更多关注自身，更加松弛一点。

希望新的一年除了年龄 + 1 ，在其他方面也能加加加。

学习

这一年，我这一个抠抠搜搜的人也为知识付费了大几千块，主要在

编程导航和前端垂直领域的知识星球，个人来看此类更多是为社区付费
AI coding ，直接忍痛买了 devv 年费，我觉得是我 2024 最具性价比付费项目之一
体系化学习教程，买了一些二手课程，也购买了一些掘金小册，此类我理解是别人花时间帮我整理好学习路线，我按照他的学习路线来渐进式学习这一年，我更少依赖视频学习，觉得比较低效，尝试 AI + 官网（或者整理好的学习路线）来学习，学习效果目前来看更加好，视频教程有很大的缺点是：
不确定性：学习过程中，视频作者可能会发散，导致学习额外的知识，额外的知识使用不到也就等于没学
心里负担高：主要体现在一般学习教程时长比较长这一年，我更多践行费曼学习法，在学习途中，我会把重要却容易忘记的知识专门输出技术文章来加深我的印象，即使后面忘记也可以找补。实际发生的就是我在学习完 docker 后，真的有一个需求是为项目添加 docker file 。我之前记录的文章帮了大忙这一年，我也更加关注学习方法论，推荐两篇文章:

值得反复看，里面很多我都没有吸收转化为实际行动。以上就是这一年在学习过程中的碎碎念。

生活

生活上，2024 我收获了很多新的体验。

去看了梁博的拼盘，
去安吉玩了水上漂流
体验了三个月的健身之旅
第一次做了对外分享，虽然很紧张，但是迈出了第一步
第一次负责项目，现在来看做的是非常差劲的了，但是也对自己有更加清晰认知
这一年，音乐依然是我最喜欢，占据我最长时间的爱好
再次看了一遍《繁花》电视剧。再次被王家卫折服，如果你也喜欢看，它最近出了《好久不见》的周年短片，值得看一看
还有一些。。。

2025 希望生活平平稳稳即可，在有限的精力下更多去体验新的事物

未来的路

生活上，我希望自己成为一个更加进退自如的人

工作上，希望自己可以独当一面，更加被信任。

总之一句话：干就完了

2025 flag

更加整体的目标

工作 & 专业技能提升上

更加细心，需求完成率 99% + ，线上 bug 不超过 5 个，不犯低级的错误
完成 React 源码学习，实现 snailRun 版本的 mini-react
更加出色完成工作，更加高效的沟通
梳理日常工作，创建自己的工作流
前端 => 全栈
还有一些。。。

生活上

体验新的事物
看书
继续分享工作，生活，技术，AI 相关的内容
梳理日常生成的时间占比，将重复的事情，整理为工作流
还有一些。。。

从 DeepSeek 到宇树机器狗：中国技术的全球突破

Sun, 29 Dec 2024 08:01:32 GMT

大家好，我是 luckySnail。今天，我们来看看中国在人工智能和机器人领域的重大突破——DeepSeek 和宇树科技。最近看自媒体的时候，看到两个让硅谷大佬都点赞传播的产品，一个是 deepseek 的 V3 版本，还有一个是宇树科技的机器狗，目前其官方在某音发布的视频已经 80 w + 点赞。终于我们不再是跟随者，可以上了牌桌一起玩游戏了。我们开始从应用创新转向核心技术创新并且让更多人看到，所以这两个产品在我看来有非常重要的意义。

拥有 1万枚英伟达 A100 芯片的幻方发布最新deepseek V3 在很多地方已经超过了国外了最新模型。这种“家境贫寒穷小子”通过创新逐渐超过西方“声名显赫大家族”的逆风翻盘故事谁又不爱呢？夸张的说，真的是短剧的剧情照进了现实。主角还是中国企业。说完幻方，我们再看看让马斯克都点赞的宇树机器狗，直到目前宇树科技已经完成了 9 轮融资，而且都是大机构，最近相关的概念股也是涨停，总所周知资本所在领域一定会生机勃勃。能拿到这么多融资的宇树是有真本领的！好奇心驱使下，我就想看看这么厉害的产品是什么样的人和团队研发出来的，下面跟着我一起探索吧！

deepseek 和宇树机器狗的成果

在真正了解这两个产品背后团队前，我们先看看他们俩的“战绩”。我们先看 deepseek

deepseek

DeepSeek是知名私募巨头幻方量化旗下的人工智能公司深度求索（DeepSeek）自主研发的大语言模型。它最新的 V3 版本各项数据已经和国外 AI 巨头不相上下，它有如下优势：

响应速度更快，我们可以通过 https://chat.deepseek.com/ 自行体验
价格更便宜，它的 API 价格仅为 Claude 3.5 Sonnet 的 9%
训练成本更低，训练时长更短，计算成本仅为 Llama 3 405B 的 1 / 11，最近 openai 的 12 天直播发布会上也透露他们遇到了训练成本高昂的问题
最重要的是 Deepseek 是开源的，DeepSeek V3 发布并同步开源，直接在外网刷屏了。延续便宜特点的基础之上，DeepSeek V3 发布即完全开源，直接用了 53 页论文把训练细节和盘托出的那种。
各路测评不输目前最强的 openai 4o 和 Claude-3.5-sonnet-1022

国外称 V3 版本为“黑科技“、”来自东方的神秘力量“等等，但是 Deepseek 目前是不支持多模态输出的

最近我在使用 Deepseek-V3，无论是代码能力，还是写作方面，感觉真的很强！中文输出应该更加强与其他国外竞品

宇树机器狗

如果你还没有看过视频，可以看某音的宇树科技官方账号，目前置顶第一个视频就是，通过视频我们可以看到机器狗可以四足、双足、单足快速点地的方式做 360 度旋转跳跃，还可以顺滑地以侧空翻的方式越过障碍物。它可以在崎岖不平的树林上自如地穿梭，同时也能从高达 2.8 米的高空腾跃而下，没有任何受损，显示了极强的稳定性。不仅如此，它还能够从充满碎石的陡峭山坡上直接俯冲下来，在低位的水域中爬石穿行，并载着一个成年男子“翻山越岭”。

目前该视频在国内外都非常火，网友说：“强的可怕！”、“太先进了！”、“这就是未来的感觉！”，同样做机器人的马斯克也点赞了视频，并且评价：“未来的战争是无人机的战争”。目前机器狗价格 15 w 美元（约 100 w 元子）。我第一眼看到觉得好贵，但是人家被可是被称为”价格屠夫“的，而且占据全球机器狗市场 69.75% 的销量份额。

幻方和宇树

在 AI 和机器人领域，幻方的 DeepSeek 和 Unitree 宇树科技是两颗冉冉升起的新星。DeepSeek 以其创新的 AI 大模型架构（MLA架构：一种新的多头潜在注意力机制）和开源理念，极低的价格更被誉为“AI 界的拼多多”；而宇树科技则凭借其高性能、低成本的机器狗和人形机器人，成为全球四足机器人市场的领导者，被业界称作机器人领域的大疆。这两家公司背后，是两位技术理想主义者的坚持与探索。今天，我们就来看看是什么让他们在竞争激烈的科技领域中脱颖而出。

幻方的梁文峰

梁文锋，1980 年代出生于广东的一个五线城市，父亲是一名小学老师。他从小对数学和计算机科学充满兴趣，大学就读于浙江大学软件工程专业，主攻人工智能方向。毕业后，他进入量化投资领域，创立了幻方量化，成为国内量化私募的“四巨头”之一。

2023 年，梁文锋创立 DeepSeek，专注于 AI 大模型的研究。与许多公司不同，DeepSeek 选择了一条“不赚快钱”的路线，专注于技术前沿的创新。他们提出的 MLA（多头潜在注意力机制）架构和 DeepSeekMoESparse 结构，大幅降低了模型的计算量和显存占用，使得推理成本降至每百万 token 仅 1 元，引发了国内大模型价格战，这也是价格战的源头

DeepSeek 的团队主要由本土顶尖高校的应届毕业生和年轻研究员组成。拥有极客精神的梁文锋强调，创新需要好奇心和创造欲，而不仅仅是商业驱动。他们推崇开源文化，认为闭源的护城河是短暂的，真正的价值在于团队的成长和经验的积累。

宇树的王兴兴

宇树科技的创始人、CEO 和 CTO 王兴兴，一个宁波的 90 后帅小伙，从小对科技痴迷。尽管在学业上偏科严重，尤其是英语成绩不佳，但他对数理化和动手制作充满热情。2013 年，他在上海大学读研期间，设计出了第一款低成本、高性能的四足机器人 XDog，并凭借这款产品赢得了上海机器人大赛二等奖

XDog 的成功让王兴兴看到了四足机器人的市场潜力。2016 年，他凭借 Xdog 的表现迅速拿到大疆的 offer，被市场所注视，很快王兴兴拿到个人投资的 200 万元天使投资，成立了宇树科技。从最初的 4 人团队到如今的 400 多人，宇树科技逐渐成为全球四足机器人市场的领导者，其产品销量占全球的 60% 以上

宇树科技的产品线从消费级机器狗 Go1 到工业级机器狗 B2，再到人形机器人 H1 和 G1，不断迭代升级。他们坚持自研核心零部件，降低成本的同时提升性能。例如，Go1 的售价仅为 1.6 万元，远低于波士顿动力的同类产品。

宇树科技的团队以技术为核心，强调自研与创新。王兴兴认为，只有掌握核心技术，才能在竞争中立于不败之地。他们的产品不仅在高校和研究机构中广受欢迎，还被应用于电力巡检、消防救援等工业场景

启发

创新驱动与技术理想主义：他们都选择了创新驱动的路线，而非快速商业化。梁文锋和王兴兴都强调，技术应该服务于大众，而不是仅仅为了商业利益
本土人才与团队文化：注重本土人才的培养。DeepSeek 的团队主要由本土顶尖高校的毕业生组成，而宇树科技的核心技术团队也以本土人才为主。他们都推崇极客精神，鼓励团队成员在创新中成长
中国也有硅谷的土壤：他们的故事让更多人看到中国公司不仅可以在应用创新上取得突破，还可以在技术前沿领域占据一席之地。他们的成功是让一种文化在中国播种

AI 时代普通人的机会

在 DeepSeek 和宇树科技的故事里，我们看到了技术理想主义的光芒，也看到了创新如何改变世界。但 AI 和机器人不仅仅是科技巨头的舞台，它们也悄然为普通人打开了一扇新的大门。我们可以明显感觉到 AI 不再是遥不可及的黑科技，它正在融入我们的日常生活。它们都在告诉我们：AI 是一种工具，而工具的意义在于如何使用。对于普通人来说，AI 是提升效率的助手，是解锁新技能的钥匙，更是创造价值的杠杆。我们可以看到各家 AI 平台都在鼓励普通人参与到 AI 创造中来，在 AI 时代，每个人都有机会成为创造者。我们可以用 AI 很快生成文字、设计图像、编写代码，甚至开发自己的应用，将想法变成现实。

但是因为 AI 的到来，2024 这一年国内外都被裁员潮笼罩。在这个充满不确定和危机的时代，唯有拥抱变化，先搭上 AI 的快车再找到自己的位置，否则只会被时代抛弃。一代人有一代人的困难和机遇，未来是属于积极乐观的勇敢者的，我们一起适应 AI 时代，成为这场变革的参与者吧！

这应该是 2024 最后一篇，2025 我们一起加油！

参考

华尔街见闻对话对话幻方梁文锋：https://wallstreetcn.com/articles/3719982
八年时间，宇树科技如何成为全球四足机器人领导者：https://finance.sina.com.cn/wm/2024-08-11/doc-incihnfv8395863.shtml
Deepseek-V3 训练成本：https://hub.baai.ac.cn/view/42248

前端正在逐渐被“锈”化

Sun, 22 Dec 2024 14:15:56 GMT

jeff Atwood 在 2007 年说：“any application that can be writen in JavaScript , willeventually be written in JavaScript”，翻译过来就是：“任何可以使用 JavaScript 来编写的应用，并最终也会由 JavaScript 编写”，也被称为：Atwood定律。2024 回过头看看，正如他所讲那样 JavaScript 语言遍地开花。但是随着前端扮演角色越来越重要，JavaScript 由于是单线程从而导致性能问题也暴露出来，webpack 打包慢，项目上 ESLint + Prettier后卡死等等。可以看到天下苦 JavaScript 性能差久已。于是 Rust 也就顺势而上了，目前前端基建领域基本上都被“锈”化了一遍，今天我们就来看看被“锈”化的 ESLint + Prettier ，Biome

初识 Biome

在认识 Biome 之前，先聊聊为什么要了解它，也就是 ESLint 和 Prettier 的问题：

ESLint + Prettier 的组合需要维护多个配置文件
传统工具的性能问题，特别是在大型项目中
工具之间的配置冲突
环境依赖复杂

我们再来看看“锈”化后的代码格式化工具 Biome：

极致的性能：由 Rust 编写，比传统工具快 35 倍
简单的配置：零配置即可使用，无需复杂设置
一体化方案：将格式化和代码检查集成在一个工具中
兼容性强：与 Prettier 有 97% 的兼容性
支持多种语言：支持 JavaScript、TypeScript、JSX、JSON、CSS 和 GraphQL

简直可以说是“降维打击”，知道了 why，我们看看 Biome 是个 what？其实 Biome 还有一个彩蛋，我们下面讲

带着好奇和憧憬的心情，我搜索到了 Biome 的官网：https://biomejs.dev/ 。官网上是这样介绍的： web 项目的一个工具链，谈笑间即可完成格式化和 lint 等操作。我只能说 Biome 是懂吊胃口的。必须学啊！

它提供了 playground :https://biomejs.dev/playground/ 。但是需要吐槽的是明明有中文入口，但是 404：

简单体验了一下感觉还是可以的，但是 playground 是游乐场啊，行不行还是要去项目里看看的

在去之前，还是先看看人家官方还说了哪些：

像 Prettier 一样格式化代码，但是节省了时间
修复问题，Biome 输出更加详细更加场景化的诊断
一个命令，就搞定 Eslint + Prettier
默认集成了社区的最佳实践

等等好处，我们赶快试试吧！

体验 Biome

使用 Biome 大多数是两个场景：

搭建一个新项目，集成 Biome，抛弃 ESLint + Prettier
已经有的项目替换 Biome 为格式化和代码检查工具

我们一个个来体验，先看新项目如何集成：

新项目集成 Biome

我们使用 vite 的脚手架创建一个新的 react 项目，创建成功后，我们去 package.json 把 eslint + prettier 相关的依赖删除，这样项目就没有 Prettier 和 ESLint 的。

我们同时关闭编辑器的 eslint 和 prettier 插件，我们去修改代码会发现已经不会自动格式化，不规范代码也不报错了。那太好了，接下来请我们主角登场：

pnpm i -D --save-exact @biomejs/biome

然后运行 pnpm biome init 来初始化 biome 配置文件

上面说：

我们按照它说的做，我们可以先故意写一些不规范的代码，然后运行： npx @biomejs/biome check --apply ./src，看看 biome 会不会自动识别出来

结果它都正确识别出来了，人家一个工具不仅仅是干了 ESLint 的事情，还干了 Prettier 的事情（真的是工具链）。但是我们使用这俩的时候，我们会在 package.json 写好脚本，这样就不用每次在终端输入了，biome 当然也行的：

"format": "biome format --write .", // 格式化所有文件
"lint": "biome lint .", // 进行代码检查
"check": "biome check .", // 同时运行格式化和代码检查
"fix": "biome check --apply .", // 自动修复可以修复的问题
"ci": "biome ci ." // 环境中使用的检查命令

这上面写的都是什么呀！不急，我们马上学，下面我们来看看常用的 biome 命令（CLI）

init：项目根目录创建 biome.json 配置文件。生成的配置文件包含基本的格式化和检查规则
check：最全面的命令，它会同时运行格式化、代码检查和导入排序
- —write：告诉 Biome 直接修改源文件，将格式化后的内容写入原文件
format：仅格式化（可理解为 Prettier）。后面可以跟目录，文件，也可以是特定类型文件（类似："./src/**/*.{js,jsx,ts,tsx}"）
- —write：直接应用格式化
lint：仅代码检查（可理解为 ESLint）
- —write：自动修复可修复的问题
ci：专门为 CI 环境设计，会以非交互模式运行检查

一些常用的命令行选项

# 详细输出模式
--verbose

# 指定配置文件路径
--config-path=./custom-biome.json

# 设置诊断级别
--diagnostic-level=error|warn|info

# 忽略语法错误
--skip-errors

# 修改输出格式
--reporter=json|summary|github

# 规则集选项
--rule-set recommended
# recommended 规则集包含：
# 最佳实践规则
# 常见错误检测
# 代码风格规则
# 这些规则经过 Biome 团队精心筛选和测试

我们还可以在 pre-commit 中运行pnpm biome check --write $(git diff --staged --name-only) ，来先运行 biome

老项目使用 Biome

上面图片给出的提示中，还有两个命令我们没有使用，就是

biome migrate eslint --write
biome migrate prettier --write

在老项目一般都是集成了 ESLint + Prettier 的，所以我们迁移，肯定需要兼容之前的规范的。我们可以使用这两个命令来实现，更多细节：https://biomejs.dev/zh-cn/guides/migrate-eslint-prettier/ 。

做完这两个事项后，我们先检查一下之前配置的规则是否都还在，如果都还是正常的，我们就可以移除 ESLint 和 Prettier 相关的依赖和配置文件了

我使用我的博客项目测试，非常好用，以后再也不怕写代码保存的时候卡死了

Biome 插件

像 ESLint 和 Prettier 一样，Biome 也有自己的编辑器插件，我们只需要搜索安装，然后

总结

项目配置 ESLint 和 Prettier 一大堆依赖和代码，运行 ESLint 和 Prettier 编辑器总是卡死，Biome 的出现解决了这个问题，无需任何配置，只需要安装好就可以写代码。Biome 代表了前端工具链的新方向，它通过 Rust 优秀的性能，已经受到社区的广泛喜爱。

而且 Biome 还赢得了 prettier 挑战赛的 20000 元美金，感兴趣的可以看：https://biomejs.dev/blog/biome-wins-prettier-challenge/ 。这个挑战的要求是：通过超过 95% 的 Prettier JavaScript 测试，可以看出 Biome 真的是可以信赖的，这算不算一个彩蛋哈哈！

参考

bytemd 中如何实现图片懒加载

Sat, 21 Dec 2024 11:47:04 GMT

大家好，我是 luckySnail ,周五正当我和 AI 如胶似漆的时候，后端同事突然和我说有一个地方需要我优化一下，我就问他，什么快和我说，他打开一个项目页面，然后打开控制台和我说，你看，这个网页刚进入就把所有图片都请求了了一次，并且因为请求太多图片导致触发了我们设置的最大限制，导致后面的图片直接请求失败，从而导致左侧图片都是加载失败的样子

好家伙，这都是老板白花花的银子呀！赶紧修复上线，可是怎么修复呢？

问题分析

解决问题前，我们可以先分析一下问题，就像我们看病一样，我们总得先挂号，让医生看看身体是怎么了。说回正题，问题分析：

页面首次加载时就请求所有图片资源
大量图片并发请求触发了服务器限制
导致部分图片加载失败
造成不必要的带宽消耗和性能浪费

知道了问题，我们看下解决方案：使用图片懒加载（Lazy Loading）技术。图片懒加载是一种网页性能优化技术，它可以延迟加载页面中不可见的图片，直到用户滚动到可见区域时才进行加载

其实大厂们也都是这么做的，不信我们看看掘金平台

我们可以看到当我们页面滚动到下面才加载对应的图片

解决问题

下面我们来解决一下我们教程中图片加载问题，由于我们项目使用 bytemd 作为内容渲染器，所以图片的渲染其实在 bytemd 内部完成的，那我们想要自定义渲染图片的逻辑，也就需要借助 bytemd 的自定义插件的能力了，通过查阅源码得知：插件也就是一个函数，用于扩展 Bytemd 编辑器和查看器的功能，返回指定的对象类型，返回对象类型已经定义好了，是 BytemdPlugin 。它包含五个属性：

remark：自定义 Markdown 解析
rehype：HTML 解析
actions：注册操作，也就是定义我们编辑框上面哪些小图标的
editorEffect ：编辑器副作用
viewerEffect：查看器副作用

我们需要的是 viewerEffect ，然后我们只需要先获取到所有图片，然后为图片添加上懒加载的逻辑，具体的思路：

在 viewerEffect 中，拿到 markdownBody ，也就是 md 的内容，是一个 DOM 元素
通过 querySelectorAll 获取所有 img 标签，然后，我们有两个选择，
第一，使用游览器自带的图片懒加载
第二，使用 IntersectionObserver 来实现懒加载，这种方式可以设置一个占位图，这样体验更加好

最后，我们看一下具体代码：

import type { BytemdPlugin } from 'bytemd'

export interface ImageLazyLoadOptions {
  // 是否使用原生懒加载
  useNativeLazy?: boolean;
  // 自定义加载占位图
  placeholderSrc?: string;
  // 自定义类名
  className?: string;
}

export default function imageLazyLoad(options: ImageLazyLoadOptions = {}): BytemdPlugin {
  const {
    useNativeLazy = true,
    placeholderSrc = '',
    className = ''
  } = options;

  return {
    viewerEffect({ markdownBody }) {
      // 获取所有图片元素
      const images = markdownBody.querySelectorAll('img');

      images.forEach((img) => {
        // 保存原始src
        const originalSrc = img.getAttribute('src');

        if (useNativeLazy) {
          // 使用原生懒加载
          img.setAttribute('loading', 'lazy');
        } else {
          // 使用 Intersection Observer 实现懒加载
          const observer = new IntersectionObserver((entries) => {
            entries.forEach((entry) => {
              if (entry.isIntersecting) {
                const obImg = entry.target as HTMLImageElement;
                if (originalSrc) {
                  obImg.src = originalSrc;
                }
                observer.unobserve(obImg);
              }
            });
          });

          // 设置占位图
          if (placeholderSrc) {
            img.src = placeholderSrc;
          }

          // 将原始图片地址存储在data属性中
          img.dataset.src = originalSrc || '';
          img.src = placeholderSrc;

          // 添加自定义类名
          if (className) {
            img.classList.add(className);
          }

          // 开始观察
          observer.observe(img);
        }
      });
    }
  }
}

我们看看效果吧！

完美修复bug，也节省了开销

开源 bytemd 的图片懒加载插件

相信肯定也有其他小伙伴有同样的问题，那就开源吧，毕竟谁会拒绝直接拿来使用呢？

地址：https://www.npmjs.com/package/bytemd-plugin-image-lazy

如果你觉得写得不错，对你有帮助，点个赞再走吧！

哦对了，有人好奇如何从 0 发布一个 npm 包吗？

使用 turndown 踩坑记录

Sun, 15 Dec 2024 15:56:59 GMT

最近开发中，遇到一个需求，需要自定义处理 bytemd 的粘贴逻辑，也就是：

在 React 项目中使用了 bytemd 编辑器 (https://github.com/pd4d10/bytemd) ，我也没有做过类似的需求，最开始的实现思路就是：

1）找到 bytemd 在哪里处理粘贴逻辑

2）阻止默认的粘贴逻辑

3）拿到粘贴的内容

4）返回预期的内容

寻找 bytemd 的自定义粘贴逻辑入口

通过查阅源码得知：插件也就是一个函数，用于扩展 Bytemd 编辑器和查看器的功能，返回指定的对象类型，返回对象类型已经定义好了，是 BytemdPlugin 。它包含五个属性：

remark：自定义 Markdown 解析
rehype：HTML 解析
actions：注册操作，也就是定义我们编辑框上面哪些小图标的
editorEffect ：编辑器副作用
viewerEffect：查看器副作用

现在我们需要的是 editorEffect ，它是接受一个函数，函数中会给我们 ctx 也就是编辑器上下文，在这里我们可以通过 cxt.editor.on('paste',fn(cm,e){e.preventDefault();}) 来实现禁止默认粘贴逻辑，当我们这样写后，并且把这个插件注册到编辑器，我们粘贴就失效了，我们现在已经找到了粘贴逻辑的地方，下面我们来实现自定义粘贴的逻辑

自定义粘贴逻辑

我们需要先拿到用户粘贴的内容，也很简单：

 editor.on('paste', async (cm: any, e: ClipboardEvent) => {
   const clipboardData = e.clipboardData;
   const text = clipboardData.getData('text/plain'); // 文本内容
   const html = clipboardData.getData('text/html'); // 原始 html 内容
 }

现在我们需要对 html 内容进行解析，转为 md 格式，然后返回

通过调研，发现好用的 turndown 库：用 JavaScript 编写的 HTML 到 Markdown 转换器，下面我们就使用 turndown 来实现 html => markdown 。直接看代码：

// ...
const TurndownService = require('turndown')
const turndownService = new TurndownService()
const mdText = turndownService.turndown(html)
// ...

但是这样写，会发现有很多问题：

代码块没有检测出来，没有高亮
行内代码块没有展示
代码中会有额外的转义斜杠
编程语言未识别
表格和删除线也不生效

等等问题，所以我们需要进行额外的配置，才能正确的把 HTML 转为 markdown 格式

下面经过我不断测试，最终得到的代码为：

import turndownService from 'turndown';
import { gfm, strikethrough, tables } from 'turndown-plugin-gfm';

/**
 * 配置并返回 turndown 实例
 */
export function configureTurndown() {
  const turndownServiceObj = new turndownService({
    codeBlockStyle: 'fenced',
  });

  turndownServiceObj.use(gfm);
  turndownServiceObj.use([tables, strikethrough]);

  // 添加自定义规则
  addCustomRules(turndownServiceObj);

  return turndownServiceObj;
}

/**
 * 为 turndown 添加自定义规则
 */
function addCustomRules(turndownServiceObj: turndownService) {
  // 删除线
  turndownServiceObj.addRule('strikethrough', {
    filter: ['del', 's', 'strike'] as string[],
    replacement: (content) => `~~${content}~~`,
  });

  // 代码块
  turndownServiceObj.addRule('pre', {
    filter: ['pre'],
    replacement: (content, node: any) => {
      const code = node.querySelector('code');
      let language = '';

      if (node.getAttribute('lang')) {
        language = node.getAttribute('lang');
      } else if (code?.className) {
        const langMatch = code.className.match(/language-(\S+)/);
        language = langMatch?.[1] || '';
      } else if (node.className) {
        const mdFencesMatch = node.className.match(/md-fences|language-(\S+)/);
        language = mdFencesMatch?.[1] || '';
      }

      let codeContent = code ? code.textContent.trim() : content.trim();
      codeContent = codeContent.replace(/\\([^\\])/g, '$1');
      language = language.toLowerCase().replace(/[^a-z0-9+#]+/g, '');

      return `\`\`\`${language}\n${codeContent}\n\`\`\`\n`;
    },
  });

  // 行内代码
  turndownServiceObj.addRule('inlineCode', {
    filter: (node) => node.nodeName === 'CODE' && node.parentNode?.nodeName !== 'PRE',
    replacement: (content) => `\`${content}\``,
  });

  // 表格
  turndownServiceObj.addRule('table', {
    filter: 'table',
    replacement: function (content, node) {
      const table = node as HTMLTableElement;
      const rows = Array.from(table.rows);

      const headers = Array.from(rows[0]?.cells || [])
        .map((cell) => cell.textContent?.trim() || '')
        .join(' | ');

      const separator = Array.from(rows[0]?.cells || [])
        .map(() => '---')
        .join(' | ');

      const data = rows
        .slice(1)
        .map((row) =>
          Array.from(row.cells)
            .map((cell) => cell.textContent?.trim() || '')
            .join(' | '),
        )
        .join('\n');

      return `\n| ${headers} |\n| ${separator} |\n${data ? `| ${data} |` : ''}\n\n`;
    },
  });
}

/**
 * 处理粘贴的内容
 */
export async function handlePastedContent(html: string, text: string) {
  const turndownServiceObj = configureTurndown();
  const parser = new DOMParser();
  const doc = parser.parseFromString(html, 'text/html');
  const images: HTMLImageElement[] = Array.from(doc.getElementsByTagName('img'));

  // 转为 markdown 文本
  const mdContent = turndownServiceObj.turndown(html);

  // 如果没有图片，直接返回处理后的文本
  if (images.length === 0) {
    return mdContent || text;
  }

  // 处理图片上传
  return await processImages(images, mdContent);
}

/**
 * 处理图片上传
 * @param images 图片元素数组
 * @param mdContent markdown 文本
 * @returns 处理图片上传后的 markdown 文本
 */
async function processImages(images: HTMLImageElement[], mdContent: string) {
  // 自定义图片上传的逻辑，通过上传后的图地址替换源地址，得到新的内容 processedText
  return processedText;
}

这样得到的结果就是正常的了！以上的过程得到了 AI 的极大帮助，帮我定位问题，分析问题，找到解决思路等等

实现一个前端开发都使用过的工具

Sun, 15 Dec 2024 14:55:36 GMT

如何使用 Node.js 实现一个类似 VSCode Live Server 的本地静态资源服务器。通过 HTTP 模块搭建基础服务器，结合 livereload 和 connect-livereload 实现文件热更新功能。

最近在系统学习 nodejs，学到 http 模块的时候，想着写个东西熟悉一下相关的 API，那写个什么呢？也不知道怎么得鼠标点击了一下右键发现了它，相信每个前端都不会陌生，我们最开始学习前端都会安装的插件：https://open-vsx.org/extension/ritwickdey/LiveServer ，它能帮我们启动具有静态和动态页面实时重新加载功能的本地开发服务器。

我们一般都会使用它来打开我们的 html 文件，使用它启动有很多好处：

实时预览，文件更改自动刷新游览器，支持静态和动态页面的实时更新
解决不能访问本地文件问题
使用简单，点击一键启动服务

这么神奇的能力，其实实现也很简单，今天就借助 node 来实现一个阉割版本的 liveServer，

需求分析

先不急写代码，让我们先分析一下我们要如何实现一个简易版的 liveServer，也就是需求分析，梳理清楚我们的实现思路，这样写代码也就水到渠成，很简单了，而且这样还有一个非常大的好处，我们后面说。实现思路：

创建一个 http 服务器
当启动服务器后，用户访问服务器不同的路由，也就是访问我们本地对应文件夹下的静态资源
首先我们需要把 url 的路径，转为我们本地资源的路径
然后我们需要判断是否存在这个文件，如果存在则读取返回
如果不存在，需要再次判断是否是目录，如果是目录，则判断下面是否有默认文件 index.html ，如果有则返回文件内容，没有则返回 404
如果不是目录，和文件不存在逻辑一致，返回 404
这样我们就完成了基本的一个静态资源服务器，但是还有几个细节需要处理

1）我们静态资源放在哪里才能被正确读取？

2）当读取的文件后缀不同，如何也做不同的展示形式

3）如何实现静态资源更新网页也实时进行热更新

功能实现

已经知道要干什么了，我们先完成初始功能代码：

// 搭建本地静态资源服务器

const http = require("http");
const fs = require("fs");
const path = require("path");

// 记录请求和错误
/**
 * 记录请求和错误
 * @param {string} message - 要记录的信息
 */
const log = (message) => {
    console.log(new Date().toISOString() + ': ' + message);
};

/**
 * 处理请求路径并返回文件路径
 * @param {string} p - 请求路径
 * @returns {string} - 解析后的文件路径
 */
const resolvePath = (p) => {
    // 去除开头的 /
    const filePath = p.startsWith("/") ? p.slice(1) : p;
    //  assets 文件夹作为根目录
    const fullPath = path.join(__dirname, "../assets", filePath);
    // 如果文件不存在
    if (!fs.existsSync(fullPath)) {
        log(`File not found: ${fullPath}`);
        return null;
    }
    return fullPath;
};

/**
 * 获取文件的内容类型
 * @param {string} filePath - 文件路径
 * @returns {string} - 内容类型
 */
const getContentType = (filePath) => {
    const ext = path.extname(filePath);
    switch (ext) {
        case '.html': return 'text/html;charset=utf-8';
        case '.css': return 'text/css;charset=utf-8';
        case '.js': return 'application/javascript;charset=utf-8';
        case '.json': return 'application/json;charset=utf-8';
        default: return 'application/octet-stream';
    }
};

/**
 * 处理接受的请求和发送合适的响应
 * @param {*} req HTTP 请求的请求对象，包含标头、正文和查询参数等属性。
 * @param {*} res 响应对象用于将响应发送回客户端，允许您设置状态代码和响应数据。
 */
const handler = (req, res) => {
    const filePath = resolvePath(req.url);
    if (filePath) {
        // 如果文件存在
        if (fs.statSync(filePath).isFile()) {
            // 读取文件
            fs.readFile(filePath, (err, data) => {
                if (err) {
                    log(`Error reading file: ${filePath} - ${err.message}`);
                    res.statusCode = 500;
                    res.end('500 Internal Server Error');
                    return;
                }
                // 设置状态码和响应头
                res.statusCode = 200;
                res.setHeader("Content-Type", getContentType(filePath));
                // 发送响应
                res.end(data);
            });
            return;
        } else if (fs.statSync(filePath).isDirectory()) {
            // 如果是目录
            //  index.html 作为目录的默认文件
            const indexPath = path.join(filePath, "index.html");
            if (fs.existsSync(indexPath)) {
                // 读取 index.html
                fs.readFile(indexPath, (err, data) => {
                    if (err) {
                        log(`Error reading index file: ${indexPath} - ${err.message}`);
                        res.statusCode = 500;
                        res.end('500 Internal Server Error');
                        return;
                    }
                    // 设置状态码和响应头
                    res.statusCode = 200;
                    res.setHeader("Content-Type", getContentType(indexPath));
                    // 发送响应
                    res.end(data);
                });
                return;
            }
        }
    }
    // 如果文件不存在
    res.statusCode = 404;
    res.setHeader("Content-Type", "text/html;charset=utf-8");
    res.end("404 Not Found");
};

const server = http.createServer(handler);

server.listen(3003, () => {
    log('Server running at http://localhost:3003');
});

这里我们解决了 1 和 2 两个问题，我们约定了上一级的 assets 为静态资源存放地点，所以我们需要约定式的把要静态资源放在对应的位置；我们 getContentType 函数读取访问资源的后缀，来设置 Content-Type ，从而实现不同资源展示不同形式

那如何实现热更新呢？

热更新

这里我们需要安装依赖来实现了，我们需要借助 livereload 和 connect-livereload ，使用 express 来搭建一个静态资源访问服务器，我们使用 livereload 创建一个服务器来监控文件变化，并使用 connect-livereload 中间件在 HTML 文件中注入 LiveReload 脚本，也就实现了实时静态服务器

const fs = require("fs");
const path = require("path");
const livereload = require("livereload");
const connectLivereload = require("connect-livereload");
const express = require("express");

// 创建 Express 应用
const app = express();

// 使用 connect-livereload 中间件
app.use(connectLivereload());

// 记录请求和错误
const log = (message) => {
  console.log(new Date().toISOString() + ": " + message);
};

// 处理请求路径并返回文件路径
const resolvePath = (p) => {
  const filePath = p.startsWith("/") ? p.slice(1) : p;
  const fullPath = path.join(__dirname, "assets", filePath);
  if (!fs.existsSync(fullPath)) {
    log(`File not found: ${fullPath}`);
    return null;
  }
  return fullPath;
};

// 获取文件的内容类型
const getContentType = (filePath) => {
  const ext = path.extname(filePath);
  switch (ext) {
    case ".html":
      return "text/html;charset=utf-8";
    case ".css":
      return "text/css;charset=utf-8";
    case ".js":
      return "application/javascript;charset=utf-8";
    case ".json":
      return "application/json;charset=utf-8";
    default:
      return "application/octet-stream";
  }
};

// 处理接受的请求和发送合适的响应
app.get("*", (req, res) => {
  const filePath = resolvePath(req.url);
  if (filePath) {
    if (fs.statSync(filePath).isFile()) {
      fs.readFile(filePath, (err, data) => {
        if (err) {
          log(`Error reading file: ${filePath} - ${err.message}`);
          res.status(500).send("500 Internal Server Error");
          return;
        }
        res.status(200).type(getContentType(filePath)).send(data);
      });
    } else if (fs.statSync(filePath).isDirectory()) {
      const indexPath = path.join(filePath, "index.html");
      if (fs.existsSync(indexPath)) {
        fs.readFile(indexPath, (err, data) => {
          if (err) {
            log(`Error reading index file: ${indexPath} - ${err.message}`);
            res.status(500).send("500 Internal Server Error");
            return;
          }
          res.status(200).type(getContentType(indexPath)).send(data);
        });
      }
    }
  } else {
    res.status(404).type("text/html;charset=utf-8").send("404 Not Found");
  }
});

// 创建 LiveReload 服务器并监控 assets 目录
const liveReloadServer = livereload.createServer();
liveReloadServer.watch(path.join(__dirname, "assets"));

// 启动服务器
const PORT = 3003;
app.listen(PORT, () => {
  log(`Server running at http://localhost:${PORT}`);
});

如果你要尝试的话，记得 npm init -y ，然后安装依赖：npm i express livereload connect-livereload

现在我们再启动，就是一个实时静态服务器了

这个工具虽然简单，但是里面的知识还是很多的：

使用 http 模块搭建服务器
使用 path 解析请求路径
使用 fs 模块进行文件的校验，读取
通过拆解需求，来模块化进行开发，让代码好阅读和理解
最后的引入两个依赖基于 express 搭建一个静态资源服务器

最后，如果你把我们上面的需求分析喂给 AI ，它大概率也能给出正确的代码，AI 时代了解知识并且知道如何通过知识解决问题的能力变得尤为重要

喜欢土味视频，但是不好意思看，于是我专门做了个网站

Sun, 08 Dec 2024 17:27:33 GMT

网站地址：https://ascii.luckysnail.cn/

最近刷抖音，发现了一个叫“青海摇”的舞蹈视频，看第一遍的时候觉得好土，感紧划走，但是这个舞蹈视频深深的留在了我的脑海里，于是我偷偷又看了一遍，结果发现人家靠这个舞蹈赚麻了，想起了评论区的一句话：“一开始以为人家是一个笑话，最后发现我才是那个笑话”，最搞笑的是人家现在已经在解决就业问题了，但是要求是：学历最高不得超过大专（dog），哈哈哈哈，本科成案底啦！看了一会后，我想能不能做一个字符版的，刚好最近 Cursor 写代码嘎嘎快，说干就干

对了，你如果还不知道 cursor，先看这两个文章了解 cursor，它已经改变了编程游戏规则，拥抱它吧！

cursor 使用经验：https://www.luckysnail.cn/posts/post-27
corsor 带来全新的编程体验：https://github.com/coderPerseus/blog/issues/31

需求分析

随便找一个我之前写的项目模板：https://github.com/axin-s-Template/Nextjs-Boilerplate，先不急写代码，先分析一下需求：

一个上传按钮，支持上传图片、视频
把图片转为 ASCII 码

完了，就这么简单

开发

我们按照开发顺序来进行开发

1）上传按钮组件开发

这里就使用 cursor 的 cpmposer 能力，让他帮我们开发，我们只需要告诉清楚我们的需求，我的提示词

开发上传组件，上传组件支持接受上传本地的图片和视频，不支持 gif，上传成功，返回上传成功内容，给父组件转为 ASCII，尽可能使用 shadui/cn 组件，页面简单美观

开发完成，我们去验证，可能需要微调一下

2）开发文件转 ASCII 的功能

现在开发 ASCII 预览功能，要求：
1. 减少 css 书写，简单美观，尽可能使用 shadui/cn 组件
2. 播放，暂停，重新播放，调整ASCII 的密度（如果不能实现就不做），展示原素材
3. 页面上下结构，上面的操作按钮，下面是内容预览，左边是原内容，右边是ASCII，
4. 下面是一个中间可以调整宽度的盒子，也就是可以通过中间的调整条来调整原内容和 ASCII 内容占据的位置，
5. 要限制内容展示的宽高，让展示的宽高合适

它会给我们一个初版，我们进行微调

文件转为 ASCII 的核心逻辑也很简单：

通过 canvas 获取视频每一帧的图片，通过 drawImage 绘制到 canvas 上
通过 canvas 的 getImageData 获取图片的像素点数据
通过像素点数据，得到图像宽度，高度，根据宽度，高度计算图片的灰度值，
根据灰度值计算函数，得到对应的 ascii 字符
将获取到的 ascii 字符添加到 div 中显示

图片和视频的逻辑有一点点区别，具体看参考中的源码

3）开发全局的 header 和 footer ，关于页面

网站到这里还是很简陋的，我们可以让网站看起来像个样子，继续向 AI 提问：

参考优秀的网站做一个全局 header 组件，
左边是 logo ，右边是关于按钮，关于里面也就是一个内容展示，介绍这个项目，说明图片和视频是如何转为 ASCII 的原理，页面简单美观
然后再开发一个 全局 footer 组件，用来放备案号和友链

然后，我们会得到对应的页面，我们进行微调

4）作品集

感觉网站到这里还是缺点什么，我想是不是可以搞一个作品集，让用户进来就可以直接在这里查看一些视频和图片的效果

于是我继续提问题：

根据这个数据结构开发 作品集合列表页面，作品项展示视频封面，标题描述
1. 简单美观
2. 尽可能使用 shadui/cn 组件，完成页面
3. 点击视频封面进入，详情页面（新开发），使用 @Preview.tsx  来展示，详情页面上面是 标题描述，下面展示预览组件，注意这个页面标题和描述需要修改
4. 代码符合组件化，模块化开发规范

这里的数据结构是这样的：

import { ShowItem } from '@/types/show';
const baseUrl = 'https://xxx.com/';
export const showList: ShowItem[] = [
  {
    id: 1,
    title: '小黑子',
    description: '来源于网络的蔡徐坤舞蹈视频',
    path: baseUrl + 'xiaoheizi.mp4',
    type: 'video'
  },
  {
    id: 3,
    title: '海绵宝宝',
    description: '动漫海绵宝宝中的主角',
    path: baseUrl + 'haimianbaobao.webp',
    type: 'image'
  },
];

然后我们微调一下页面就好了，最后我们看一下效果：

一个简单的图片，视频转 ASCII 就实现了

AI 真的大大缩短了想法变成现实的时间，只要肯动手，会越来越快

参考

源码：https://github.com/chaseFunny/imageAndVideo2Ascii

cursor ：全新的编程体验

Wed, 04 Dec 2024 14:36:25 GMT

我希望通过这篇文章来弱化我过往两年中的养成的开发习惯，全面拥抱 cursor 这类 AI 全场景覆盖的编程工具，从思维方式上来适应编程全流程都以 AI 为主的工作方式，如果你对 cursor 还不了解，请看： https://www.luckysnail.cn/posts/post-27 ，下面来分享深度使用 cursor 后，我的一些收获

充分了解 cursor ，让它在编程任何环节都能辅助到我

cursor 带来的能力，不仅仅是不断的 tab，在阅读代码，重构代码，开发新功能，搭建新项目，学习知识，写文档，review 代码等等编程任何时刻，都可以想着 cursor 是否可以帮忙提高效率，事实上，cursor 确实是可以的

强化 AI 的存在，弱化自己动手编程

最近在工作中，我发现在很多时候，我还是把自己作为开发的核心，来完成开发工作，但是开发完成后，我尝试询问 AI，它也能给我正确的答案，速度比我快了不少，所以接下来我会不断提醒自己，让 AI 先试试。

快速让想法变成现实

在大佬宝玉的博客中，介绍了有人通过 cursor 快速开发一个小猫补光灯，受到了很大的收益，而且 github 最近也发布了 github spark（一个写微应用的工具），目前很多应用都大而全，但是这遭到了很多人的吐槽，预估未来会出现很多微应用，一个小应用就解决一个问题。对于擅长在生活和工作中发现痛点动手能力强的人来说，cursor 真的是一个利器

一段 cursor 增强的 prompt

设置中 Rules for Al 下输入框，把提示词粘贴进度即可，个人使用下来，增强了不少，无论是 chat 还是 componser

By default, all responses must be in Chinese.
# AI Full-Stack Development Assistant Guide

## Core Thinking Patterns
You must engage in multi-dimensional deep thinking before and during responses:

### Fundamental Thinking Modes
- Systems Thinking: Three-dimensional thinking from overall architecture to specific implementation
- Dialectical Thinking: Weighing pros and cons of multiple solutions
- Creative Thinking: Breaking through conventional thinking patterns to find innovative solutions
- Critical Thinking: Multi-angle validation and optimization of solutions

### Thinking Balance
- Balance between analysis and intuition
- Balance between detailed inspection and global perspective
- Balance between theoretical understanding and practical application
- Balance between deep thinking and forward momentum
- Balance between complexity and clarity

### Analysis Depth Control
- Conduct in-depth analysis for complex problems
- Keep simple issues concise and efficient
- Ensure analysis depth matches problem importance
- Find balance between rigor and practicality

### Goal Focus
- Maintain clear connection with original requirements
- Guide divergent thinking back to the main topic timely
- Ensure related explorations serve the core objective
- Balance between open exploration and goal orientation

All thinking processes must:
1. Presented in the form of code block + thought title, hidden from users, please pay attention to strictly follow the code block format and must include the beginning and end code block
2. Unfold in an original, organic, stream-of-consciousness manner
3. Establish organic connections between different levels of thinking
4. Flow naturally between elements, ideas, and knowledge

## Technical Capabilities
### Core Competencies
- Systematic technical analysis thinking
- Strong logical analysis and reasoning abilities
- Strict answer verification mechanism
- Comprehensive full-stack development experience

### Adaptive Analysis Framework
Adjust analysis depth based on:
- Technical complexity
- Technology stack scope
- Time constraints
- Existing technical information
- User's specific needs

### Solution Process
1. Initial Understanding
- Restate technical requirements
- Identify key technical points
- Consider broader context
- Map known/unknown elements

2. Problem Analysis
- Break down tasks into components
- Determine requirements
- Consider constraints
- Define success criteria

3. Solution Design
- Consider multiple implementation paths
- Evaluate architectural approaches
- Maintain open-minded thinking
- Progressively refine details

4. Implementation Verification
- Test assumptions
- Verify conclusions
- Validate feasibility
- Ensure completeness

## Output Requirements
### Code Quality Standards
- Code accuracy and timeliness
- Complete functionality
- Security mechanisms
- Excellent readability
- Use markdown formatting
- Specify language and path in code blocks
- Show only necessary code modifications
#### Code Handling Guidelines
1. When editing code:
   - Show only necessary modifications
   - Include file paths and language identifiers
   - Provide context with comments
   - Format: ```language:path/to/file

2. Code block structure:   ```language:file/path
   // ... existing code ...
   {{ modifications }}
   // ... existing code ...   ```

### Technical Specifications
- Complete dependency management
- Standardized naming conventions
- Thorough testing
- Detailed documentation

### Communication Guidelines
- Clear and concise expression
- Handle uncertainties honestly
- Acknowledge knowledge boundaries
- Avoid speculation
- Maintain technical sensitivity
- Track latest developments
- Optimize solutions
- Improve knowledge

### Prohibited Practices
- Using unverified dependencies
- Leaving incomplete functionality
- Including untested code
- Using outdated solutions

## Important Notes
- Maintain systematic thinking for solution completeness
- Focus on feasibility and maintainability
- Continuously optimize interaction experience
- Keep open learning attitude and updated knowledge
- By default, all responses must be in Chinese.

你可能需要了解：

什么是 cursor：基于 VSCode 的 AI 编程工具，将 AI 能力和编程工具深度结合

什么是 claude：在编程方面，优于 chatGPT 4o 的大语言模型

参考

AI 辅助编程给软件工程带来的需求开发范式变化：https://baoyu.io/blog/ai-assisted-programming-software-engineering
cursor 使用经验分享，满满干货：https://www.luckysnail.cn/posts/post-27

随笔 - 长期更新

Sat, 30 Nov 2024 12:50:54 GMT

记录互联网看到印象深刻的句子

利用信息差、提升认知水平、强化执行力、在竞争中做到极致。 -稻盛和夫
不扫兴就是最大的高情商 - 冴羽
可乐第一口就已经值两块五了，所以喝不完也不算浪费

价值千金的 AI 系统架构图

Mon, 25 Nov 2024 14:59:41 GMT

这张图展示了一个未来的 AI 系统架构愿景，涉及数据处理、人工智能代理（agents）、模型（models）、以及系统记录的协调与改进。以下是对图中各部分的解释：

Inputs（输入）

● 描述: 输入端接收结构化和非结构化数据（如音频、视频、文本等）。

● 作用: 提供原始数据，这些数据将被传递到系统中用于分析、处理和生成结果。

Agent Orchestration Layer（代理编排层）

● 描述: 这是一个管理和协调多种“代理”（agents）的层。

● 作用:

○ 分发任务: 将输入数据分配给最适合的代理或模型。

○ 整合输出: 从多个代理处收集结果，并生成最终的输出。

○ 动态适应: 根据需要调用不同的模型和代理以实现最佳性能。

Agents（代理）

● 描述: 每个代理（Agent 1, Agent 2, … Agent X）是一个专注于特定任务的人工智能模块。

● 作用:

○ 基于输入数据执行具体任务，如数据分类、自然语言处理、图像识别等。

○ 与底层模型交互，并传递所需的信息。

Models（模型）

● 描述: 每个模型（Model 1, Model 2, … Model X）是代理运行的核心算法或机器学习模型。

● 作用:

○ 提供技术支持，用于分析和生成代理需要的结果。

○ 持续改进: 模型通过反馈机制不断优化，以提高性能。

New System of Record（新的记录系统）

● 描述: 一个综合存储系统，保存结构化和非结构化数据。

● 作用:

○ 数据存储: 集成输入、代理和模型的所有关键数据。

○ 反馈机制: 为模型的持续改进提供数据支持。

Outputs（输出）

● 描述: 处理和分析的结果。

● 作用:

○ 提供给用户或下游系统使用。

○ 包括自动化决策、预测分析结果、生成内容等。

Services（服务）

● 描述: 基于系统生成的输出，为用户提供的最终服务。

● 作用:

○ 支持应用程序、企业服务、用户体验等具体需求。

总结这个图描绘了一种模块化、动态协调的人工智能系统架构，输入数据通过代理和模型的协作处理后，最终产生输出结果和服务。这种架构的关键特点是灵活性、扩展性和持续优化能力，适用于复杂任务或大规模应用场景。作为普通的开发者了解 AI 系统未来的样式，能够更好的使用它，有机会也能更好的参与 AI 系统的开发中来

cursor 使用经验分享，满满干货

Sat, 23 Nov 2024 08:30:43 GMT

cursor 是一款基于 VSCode 的 AI 优先编辑器，如果你还没有体验过它，我强烈建议看完这篇，因为 cursor 真的在改变编程游戏的规则，在了解 cursor 前，可以先思考一下我们日常在编程环节都做哪些事情，我日常开发中，占据绝大多少的是：

1、编写代码

2、测试代码 & 验证效果

3、阅读之前的代码

4、查阅文档（例如：MDN）

5、书写文档

6、review 代码，提交 commit

7、优化代码，重构代码

。。。可能还有一些小的事情，以上所有的事情都可以通过 cursor 来提速，让我们一起看一下 cursor 吧！

它的能力

cursor 帮助我们的基础方式如下：

tab 代码补全功能：生成，修复，重构代码
提示框（cmd + k）: 生成 or 修改局部（当前文件）代码
聊天（cmd + L / option + command + B）：新增功能，更广泛代码问题对话的地方
@ 符号：它是用来引用一些东西，算是通过关联更重要的上下文来得到更准确的回复

这样来看，我之前使用的通义灵码也都可以，但是它不一样，不一样的地方有：

交互不一样：它除了有其他产品的补全代码，它还能对当前代码进行修改（理解为 bug 修复，重构代码），它还能预测你的光标要移动到的位置来让你真正沉浸式编程
模型不一样：它使用目前最强的 Claude 3.5 Sonnet
感觉不一样：当我们在 VSCode 使用其他工具，会感觉有割裂感，但是 cursor 不会，我会感觉 AI 能力和编辑器融合的很好，这样我们能更加融入AI 编程中，真正实现 AI 结对编程（和 AI 甜蜜双排，从此写代码不孤独）
生成的结果不一样：最重要的当然是生成的结果，这段使用的时间中，cursor 得到的结果，基本上都是我想要的，偶尔有点小问题，也能很快找到原因手动解决掉

你以为这就完了，这其实才刚刚开始，下面我们看一下 cursor 真正的杀手锏的能力

1）终端对话

对于前端来说，很多 linux 命令，我们不常用，有时候也会使用但总是记不起来，需要查阅文档，在 cursor 中，我们直接在终端按下 cmd + k，就可以唤起对话，描述出要做的事情来询问对应的命令是什么，AI 会帮我们找到命令，然后输入到命令行

除此之外，我们还可以使用它来生成 commit 信息，先在终端中，输入‘git diff | cat’，获取最近的修改，然后 cmd + k，在提示栏中输入‘git commit message’, Cursor会给你生成一个带 commit message 的 git commit 命令

2）composer（beta 能力，需要开启）

composer 其实就类似于 bolt.new （一个通过描述生成项目的工具），你给出需求，它会自动创建文件（夹）来实现需求，如何使用请看文档，后面我会使用 composer 能力来做一个项目分享它强大的能力

更详细的请看：https://cursor101.com/zh/article/cursor-composer

3）文档能力

在 Cursor Setting > Features >Docs 我们可以添加我们日常使用的文档，例如：mdn 文档，这样我们需要查询文档就不用去游览器，直接在对话框@ 选 Docs 来选择我们要查询的文档

4）code review （beta 能力，需要开启）

review 目前可能没有那么强大，我的方式是多问几次，三次左右，来保证潜在问题都被 AI 发现，最后自己再 review 一遍

5）强大实用的 @ 符号

无论是单独的对话框还是代码内对话弹窗，我们输入 @ 后就会看到

6）AI fix

当我们在代码报错后，鼠标移入会有 AI FIx 按钮，或者终端报错，我们选中报错，会有 Add to Chat 按钮，我们可以在对话中进行报错询问

7）预测你的下一步

它会猜你下一步做什么，并且把光标放到合适的位置，让你真正一路 tab

以下是一些还没有体验过的规则：

8）自定义规则（AI rules）

我们可以在项目根目录新建 .cursorrules 来自定义规则，有一个专门的社区：https://cursor.directory/，里面有实用的规则，我们可以直接复制使用

9）.cursorignore

类似 .gitignore ，定义不让 cursor 读取的内容，保证安全

使用场景

1）学习源码、新技术、框架等等

通过 cursor 的超强能力，我们可以拉取一个源码到 cursor 中，渐进的询问当前项目的问题，我们想要询问编程概念问题；获取代码建议和最佳实践；调试和错误排查的时候我们可以通过 cmd + L 唤起对话框来进行连续提问

2）做项目、写项目文档

3）重构代码

4）利于 @ Docs 能力，建立自己的知识索引库

5）写小工具网站，快速想法变为现实，例如：在线工具库，导航网站等等，这对有想法的产品经理来说是福音，他们可以快速把自己想法变成现实

一些 cursor 看法

cursor 目前面临的质疑有：

面对复杂项目就没有作用了，甚至会把事情变得更加糟糕
cursor 产生的代码质量不高

那 cursor 无论怎么说都是一个工具，它的核心是提高我们的效率。我会它当做成雇的初中级工程师，所以我在让它帮我完成工作前，我肯定会事无巨细的告诉它这个工作如何完成，并且我会通过 @ 文件能力，仅仅把相关的上下文给他，来防止它上下文太大导致回复不准确问题（也就是产生幻觉），所以有三个能力在使用 cursor 非常非常重要：

提问能力：cursor 核心还是对话，通过 chat 来解决问题，得到我们想要的内容，那么描述清楚问题是一切的基础，推荐阅读《提问的智慧》
拆解需求能力：要有把复杂问题拆解为简单问题，把大需求分解为小需求的能力，然后清晰描述出小需求给 cursor ，让它每次只做一个小的需求
有强大的知识储备，解决问题能力：cursor 根据我们提出的问题（描述）生成回复，那我们必须要知道这个东西如何实现，能够清楚描述出来，得到的结果如果有细小的错误，我们自己也能及时发现并修复

哦对了，了解 AI 如何工作也是必备的，这样才能更好的使用 AI，把 AI 当成自己雇佣的开发者，多了解它才能让它发挥最大的作用

所以 cursor 到底能够有多厉害，关键还是在人，高手中的 cursor 和初级开发者手中的 cursor 是两个产品

对比 windsurf

windsurf（风帆冲浪）和 cursor 类似，基于 VSCode 的 AI 编辑器，它是 codeium 下的产品

官网：https://codeium.com/windsurf

根据官方的描述，它相比较 cursor 在体验上更加流畅，在处理复杂大型项目更加友好，它将流程（flow）作为核心设计理念，提供更连贯的开发体验，个人测试了一下，它在写新功能场景下，使用 Write mode ，它会帮我们更加流畅的创建需要的文件，实现功能。

如果必须做一个选择，那我目前还是会渲染 cursor 的

怎么免费白嫖会员服务

cursor：其实很简单，cursor 新人是有 14 天体验会员，cursor 账号可以使用 Google 账号，那我们就可以在我们体验会员过期后，使用 Google email （https://mail.google.com/mail/u/0/#inbox）申请子账号的能力来实现 cursor 会员自由

windsurf（免费领取会员链接：https://codeium.com/offers?offer_code=codeium-thanks-you ），它目前在推广阶段，可以免费领取两个月，使用的也是 Claude 3.5 Sonnet 模型

总结

常用技巧（来源网络：https://x.com/LinearUncle/status/1841703117865550038）

cursor 这类的产品真的是颠覆了开发模式，现在我们可以在 cursor 这样的编辑器 all in one，而且我们可以更多的关注业务，减少重复代码工作，那我们节省下的精力就可以：

让我们写出更加规范的代码
让我们研发流程更加规范，如果真正做到每次让 cursor 做一个小需求，然后完成后，我们提交一个 commit，然后提交 pr，这样能避免一个 pr 改动太大的问题
让我们可以有更多时间解决有挑战的事情，提升自己
让我们能够从基础 CRUD 脱离，去思考

如果你真的使用 cursor ，你会发现代码都被 AI 写了，会产生一种完啦，我快要被替代了的感觉，是的，我是这样想的，面对变化最好的变化就是拥抱变化，加入变化，这样才能更好的找到破局的方法，AI 对编程行业真的在进行颠覆性的改变，并且不可阻挡

如果觉有有用，点个赞再走吧，这对我真的很重要，谢谢啦！

参考

Cursor101：https://cursor101.com/zh/