Pankitgg

仿openclaw调度，手搓一个免安装的windows个人助手，我管他叫智心一梦

Thu, 05 Mar 2026 00:00:00 GMT

初衷#

一直想搞一个提效工具，像一个团队一样的帮我思考和解决问题。openclaw，我不是说他不好，只是太大太复杂了，纯手工（编程也有一天会变成非遗吗？）写一些简单的功能，就能实现一个复杂的多agent的调度系统。

在我的记忆里，小的时候很喜欢玩QQ宠物，对于一个小学生来说10块是一笔巨款，为此省吃俭用买粉钻，疯狂玩游戏赚取胡萝卜，现在想起来还十分上头。所以一直想做一个桌面助手，拥有美好的社区和游戏，以及帮助我完成一些简单的任务，最重要的是要所有数据都是用户的。在AI的时代，我们有能力实现这一目标。

所以我的一开始的目的就是

核心构成

宠物系统 + 员工系统 + 记忆系统

于是便有了这个 一键启动免安装的，纯客户端的项目，所有数据均存储在用户本地。拥有了它就拥有了一个专业团队和一个宠物，他们都在你的帮助下成长。

智心一梦助手介绍网站

智心一梦助手

智心一梦助手页面

🎉 会议室模式

开会开会，一堆乱七八糟的员工在为你工作！

会议开始

感谢

特别需要感谢 taochunyu、gnenux在我开发的过程中提供了很多帮助和建议，大家看到的右上角的小绿条token计数就是他的创意。

架构#

openclaw的架构#

openclaw的架构

目前架构#

之所以说是目前的架构，是因为仍然在快速开发和变更：

目前的架构

关于架构

从整体上仍然是通过一个常驻线程进行调度，但是在细节上有一些区别。关于架构的，我会单独写一篇文章分析，因为还是比较复杂的。

开始使用#

下载安装#

智心一梦助手官网或者 github release

开始使用#

设置#

设置

点击添加模型配置默认模型，填写模型的api key和base url。如果没有模型可以在智谱,阿里云,deepseek。

推荐购买按次收费的codeingplan计划，比较省钱。免费模型的性能较差可能影响体验

填写模型的api key和base url。

智谱

智谱模型配置

deepseek

deepseek模型配置

注意

模型配置只需要添加一次，后面就可以在设置中切换模型。
模型配置中的api key和base url是你自己的，不要分享给任何人。
如果任何情况下没有回复，首先是模型配置的问题，检查一下模型配置是否填写正确。

员工#

添加员工，在AI自动生成中输入你想要的员工，点击生成即可

例如：我想添加一个叫智心一梦的员工，我可以输入：

1
智心一梦是一个很有才华的员工，他会帮助我完成一些任务

或者是

1
石头人是一个杠精，他会无情的干掉ADC

添加员工

重复操作即可添加多个员工

会议室#

进入会议室后，点击添加员工，开始会议即可

会议开始

。点击每个员工头像，可以查看员工记忆和对话

员工记忆和对话

在员工界面也可以查看员工的记忆

员工记忆和修改

技能/工具#

到此已经基本上具备基本功能了。下一步还可以配置一些技能/插件，让助手除了说还可以干活。

生成工具

点击首页进入工具箱，输入你想要的工具，点击生成例如你可以输入

1
一个用来展示条目信息的组件

点击左侧可以选择样式

生成工具样式

生成工具

等待一段时间即可生成工具

注意

生成工具需要一定的时间，取决于模型的性能。生成过程不会被打断，后续修改仍然可以在工具箱页面修改

生成如下，可以通过AI优化和自定义修改工具

生成工具

点击安装，我们可以在下方的调试区进行调试，包括模式切换和数据调试，以及AI调试修改

生成工具

生成的工具可以在任何地方使用。首页可以直接点击工具，右键可隐藏

工具/技能使用

生成的工具可以配置给员工，员工可以在会议室中使用。首先点击进入数字员工界面，点击技能库新增技能

工具配置给员工

技能类型选择tool，工具选择已配置好的工具点击进入员工界面，点击需要配置技能/工具的员工，在技能下拉内容增加所需技能即可

工具配置给员工

注意

技能/工具配置给员工后，员工可以在会议室中使用。
技能/工具的使用，需要员工自己触发，目前没有自动触发的功能。
系统默认增加了一些技能

宠物模式#

点击首页宠物图标，即可进入宠物模式

宠物模式

右键宠物模式可以退出宠物模式

退出宠物模式

最佳实践（一场酣畅淋漓的会议）#

视频还未录制（等我录制完再放出来）

后续计划#

后续会增加 小鱼干 ，作为一种和宠物交互的代币。增加宠物更多的好玩的特征，以及建设一个插件市场，来在市场中上架游戏（其实就是插件），让宠物和自己写的插件交互等等。

会议室/员工，会增加一些最好用的样例。我不想做成一个大而全，像是cherrystudio那种啥都有的，所以这个的配置一定是我自己觉得非常好用才会推给大家。

记忆系统，目前的记忆总结的触发一个是触发删除mcp的时候，一个是触发条数上限的时候，需要更多的场景来测试和优化。

等等等等，还有好多好玩的想法，只是这里写不下了

如果你想加入我，或者有什么建议

可以关注公众号：智心一梦（这是我个人公众号）

邮箱：pankitgg0@gmail.com

QQ群：1081954601

GitHub主页添加贪吃蛇贡献图（github美化一）

Fri, 08 May 2026 00:00:00 GMT

你可以点击我的主页查看效果

Tip

这个功能的原理是基于 snk 项目，通过 GitHub Action 读取贡献数据，将其渲染成一个贪吃蛇动画，输出成 SVG/GIF 格式。

准备工作：创建 Profile README 仓库#

在开始之前，您需要一个特殊的 GitHub 仓库来展示您的个人主页。这个仓库的名称必须与您的 GitHub 用户名完全相同。

创建步骤#

登录您的 GitHub 账户，在页面右上角点击 + 号，然后选择 New repository（新建仓库）。
在 Repository name（仓库名称）字段中，输入与您的 GitHub 用户名完全匹配的名称。
将仓库设置为 Public（公开）。
勾选 Add a README file（添加一个 README 文件）选项。
点击 Create repository（创建仓库）完成创建。

创建成功后，这个仓库中的 README.md 文件内容将会自动显示在您的 GitHub 个人主页顶部。

核心步骤：配置 GitHub Action#

通过 GitHub Actions 自动化生成和更新贪吃蛇动画。

第一步：创建 Workflow 文件#

在您的 Profile README 仓库中创建以下目录结构：

1
.github/
2
└── workflows/
3
    └── snake.yml

第二步：编写 snake.yml 文件#

将以下 YAML 代码复制到 snake.yml 文件中：

1
name: Generate Snake Animation
2

3
# 控制工作流的触发时机
4
on:
5
  # 每天 UTC 时间午夜 00:00 自动运行
6
  schedule:
7
    - cron: "0 0 * * *"
8
  # 允许在 Actions 标签页手动触发
9
  workflow_dispatch:
10
  # 当推送到 main 分支时触发
11
  push:
12
    branches:
13
      - main
14

15
jobs:
16
  generate:
17
    permissions:
18
      contents: write
19
    runs-on: ubuntu-latest
20
    timeout-minutes: 10
21

22
    steps:
23
      # 生成贪吃蛇动画文件
24
      - name: Generate snake.svg
25
        uses: Platane/snk@v3
26
        with:
27
          github_user_name: ${{ github.repository_owner }}
28
          outputs: |
29
            dist/github-snake.svg
30
            dist/github-snake-dark.svg?palette=github-dark
31
            dist/ocean.gif?color_snake=orange&color_dots=#bfd6f6,#8dbdff,#64a1f4,#4b91f1,#3c7dd9
32

33
      # 将生成的文件推送到 output 分支
34
      - name: Deploy to GitHub Pages
35
        uses: crazy-max/ghaction-github-pages@v4
36
        with:
37
          target_branch: output
38
          build_dir: dist
39
        env:
40
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

展开收起

第三步：配置仓库权限#

为 GitHub Action 授予正确的权限：

在仓库页面点击 Settings（设置）。
在左侧导航栏选择 Actions -> General。
向下滚动到 Workflow permissions（工作流权限）部分。
选择 Read and write permissions（读写权限）。
点击 Save（保存）。

第四步：运行 Action 并验证结果#

提交 snake.yml 文件后，前往仓库的 Actions 标签页。
点击 Generate Snake Animation 工作流。
等待自动运行或点击 Run workflow 手动触发。
成功运行后（显示绿色对勾），切换到 output 分支。
您会看到生成的 github-snake.svg、github-snake-dark.svg 和 ocean.gif 文件。

最后一步：在主页展示贪吃蛇#

编辑 README.md 文件，添加以下代码片段：

1
<picture>
2
  <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/您的用户名/您的用户名/output/github-snake-dark.svg" />
3
  <source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/您的用户名/您的用户名/output/github-snake.svg" />
4
  <img alt="github-snake" src="https://raw.githubusercontent.com/您的用户名/您的用户名/output/github-snake.svg" />
5
</picture>

重要提示：请将代码中的 您的用户名 替换为您自己的 GitHub 用户名。

自定义配置#

您可以根据喜好自定义贪吃蛇的样式，主要通过 outputs 参数配置：

参数	说明	示例
`color_snake`	蛇的颜色	`orange`
`color_dots`	点的颜色（逗号分隔）	`#bfd6f6,#8dbdff`
`palette`	预设调色板	`github-dark`

更多配置选项请参考 snk 官方文档。

2028全球智能危机（译）

Thu, 07 May 2026 00:00:00 GMT

Warning

本文为翻译仅供学习与交流使用，不涉及任何商业用途。如有侵权，请联系删除。

原文标题：THE 2028 GLOBAL INTELLIGENCE CRISIS
发布日期：2026-02-22
译期：2026-05-07
作者：Citrini and Alap Shah
原文链接：THE 2028 GLOBAL INTELLIGENCE CRISIS
译者： 本文发布以后两天，2026年2月24号，软件股指数单日跌了13%，蒸发了2850亿美元，从信息价值来说这篇文章的影响是巨大的。但是从辩证角度来说，这只能是一篇头脑风暴或者说是一篇科幻小说。当你看完这篇开始进入思考的时候，我会在另外一篇文章中描述，这场恐慌与变革的始末，带你了解文章的作者两位研究员，Citadel Securities组织的辟谣，看看最聪明的人是如何看待这场变革，以及一些个人看法。

序言#

如果我们对人工智能的看涨预期继续被证明是正确的……但如果事实证明这实际上是利空的呢？

以下内容是一个情景设想，而非预测。这不是bear porn(熊市情绪)，也不是人工智能末日论者的同人小说。本文的唯一目的是建模一个相对未被充分探讨的情景。我们的朋友Alap Shah提出了这个问题，我们一起头脑风暴找到了答案。我们一起写了这部分内容

希望阅读本文能让你为潜在的左尾风险（left tail risks）做好更充分的准备，因为人工智能正使经济变得越来越奇怪。

这是CitriniResearch2028年6月的宏观备忘录（Macro Memo），详细描述了全球智能危机的发展过程及其后果。

智能过剩的后果#

2026年2月22日 / 2028年6月30日

今晨公布的失业率为10.2%，超出预期0.3个百分点。市场对此反应剧烈，标准普尔500指数（S&P）较2026年10月高点累计下跌38%。

交易员们已经麻木了。放在六个月前，这样的数据足以触发熔断机制。

仅仅两年时间，我们就从”可控”和”特定行业”的问题，走向了一个完全不同于我们成长时期的经济形态。本季度的宏观备忘录试图重构这一过程——对危机前经济的事后剖析。

当时的繁荣景象触手可及。到2026年10月，标普500指数（S&P 500）接近8000点，纳斯达克（Nasdaq）突破30000点。由于人类劳动力被取代，第一轮裁员潮在2026年初开始，裁员确实达到了预期效果：利润率扩大，收益超预期，股市上涨。创纪录的企业利润被直接投入到人工智能算力中。

表面数据依然亮眼。名义国内生产总值持续录得中高个位数的年化增长。生产力蓬勃发展。在不需要睡觉、不请病假、不需要医疗保险的人工智能代理agents驱动下，每小时实际产出增长率达到了自20世纪50年代以来未见的水平。

算力所有者的财富随着劳动力成本的消失而爆炸式增长。与此同时，实际工资增长崩溃了。尽管政府一再吹嘘创纪录的生产力，但白领工人失去工作被迫从事低薪岗位。

当消费经济开始出现裂痕时，经济专家们普及了”幽灵国内生产总值”（Ghost GDP）一词：出现在国民账户中但从未在实体经济中流通的产出。

人工智能在各个方面都超出了预期，市场就是人工智能的天下。唯一的问题是……经济并非如此。

北达科他州的一个GPU集群产生的产出相当于曼哈顿中城10000名白领工人的产出，这显然更像是一场经济瘟疫而非经济灵丹妙药。货币流通速度陷入停滞。当时占GDP 70%的以人为中心的消费经济萎缩了。如果我们早点问一句机器在非必需品上花多少钱，可能早就明白了这个道理。

人工智能能力提升→企业需要更少工人→白领裁员增加→失业工人支出减少→利润率压力推动企业更多投资AI→人工智能能力提升……

这是一个没有自然刹车的负面反馈循环。人类智能取代螺旋。白领工人的收入能力（以及合理的消费支出）受到结构性损害。他们的收入是13万亿美元抵押贷款市场的基石——这迫使承销商重新评估优质抵押贷款是否仍然安全。

十七年没有真正的违约周期，使得私募股权支持的软件交易膨胀，这些交易假设年度经常性收入（ARR）将持续增长。2027年年中因人工智能颠覆引发的第一波违约挑战了这一假设。

如果这种颠覆仅限于软件行业，那还可以控制，但事实并非如此。到2027年底，它威胁到每一个以中介为基础的商业模式。大量建立在利用人类摩擦之上的公司瓦解了。

事实证明，整个体系是一个漫长的连环式押注，全部押注在白领生产力增长上。2027年11月的崩盘只是加速了已经存在的所有负面反馈循环。

我们等待”坏消息就是好消息”已经快一年了。政府开始考虑提案，但公众对政府实施任何形式救助的能力的信心已经减弱。政策响应总是滞后于经济现实，但缺乏全面计划现在正威胁着加速通缩螺旋（deflationary spiral）。

一切的开始#

2025年底，智能编码工具的能力实现了飞跃。

一名熟练的开发人员使用Claude Code或Codex，现在可以在几周内复制一个中端市场SaaS产品的核心功能。虽然不是完美的，也不能处理所有边缘情况，但已经足以让审查50万美元年度续订合同的CIO开始问：“如果我们自己构建呢？”

财年大多与日历年一致，因此2026年企业支出在2025年第四季度就已确定，当时”智能体人工智能”（agentic AI）还只是一个流行词。年中审查是采购团队第一次在看到这些系统实际能力的情况下做出决策。一些人目睹了自己的内部团队在几周内开发出复制六位数SaaS合同的原型。

那年夏天，我们与一家财富500强公司的采购经理交谈。他告诉我们一个预算谈判的故事。销售人员原本期望沿用去年的策略：年度价格上涨5%，标准的”你的团队依赖我们”的说辞。采购经理告诉他，他一直在与OpenAI就让他们的”前沿部署工程师”使用AI工具完全取代供应商进行谈判。最终他们以30%的折扣续约。他说，这已经是好结果了。像Monday.com、Zapier和Asana这样的”SaaS长尾”公司情况要糟糕得多。

投资者已经做好了准备——甚至期待——长尾会受到重创。它们可能占典型企业技术栈支出的三分之一，但显然面临风险。然而，核心系统本应免受颠覆影响。

直到ServiceNow 2026年第三季度财报发布，这种反身性机制才变得清晰。

ServiceNow新增年度经常性收入（ACV）增长率从23%放缓至14%；宣布裁员15%并启动”结构性效率计划”；股价下跌18%
彭博，2026年10月

SaaS并没有”死亡”。运行和支持内部构建仍然需要成本效益分析。但内部构建成为了一种选择，这影响了定价谈判。或许更重要的是，竞争格局已经改变。人工智能使开发和发布新功能变得更容易，因此差异化崩溃了。老牌企业陷入了价格战的恶性循环——不仅与彼此竞争，还与新涌现的挑战者竞争。这些挑战者凭借智能编码能力的飞跃，且没有遗留成本结构需要保护，积极抢占市场份额。

直到这次财报发布，这些系统的相互关联性才被充分认识到。ServiceNow销售许可证席位。当财富500强客户裁员15%时，他们取消了15%的许可证。推动客户利润率提高的人工智能驱动的裁员，正从机制上摧毁ServiceNow自己的收入基础。

这家销售工作流自动化的公司正被更好的工作流自动化颠覆，而它的应对措施是裁员，并将节省下来的资金投入到正在颠覆它的技术中。

他们还能做什么？坐以待毙吗？受人工智能威胁最大的公司反而成为了人工智能最积极的采用者。

现在回想起来这似乎很明显，但当时并非如此（至少对我来说不是）。历史上的颠覆模式表明，老牌企业抵制新技术，它们输给灵活的新进入者并慢慢消亡。柯达、百视达、黑莓都是如此。但2026年发生的情况不同；老牌企业无法抵制，因为它们承担不起后果。

随着股价下跌40-60%，董事会要求给出答案，受人工智能威胁的公司只能做一件事：裁员，将节省的资金重新部署到AI工具中，利用这些工具以更低成本维持产出。

每家公司的个体反应都是理性的。但集体结果是灾难性的。每节省一美元的人力成本，都流向了使下一轮裁员成为可能的AI能力。

软件只是开场戏。当投资者还在争论SaaS倍数是否触底时，他们忽略了反身循环已经超出软件行业。证明ServiceNow裁员合理性的逻辑，适用于每一家拥有白领成本结构的公司。

当摩擦归零#

到2027年初，大型语言模型（LLM）的使用已成为默认选项。人们在使用人工智能代理（AI agents）时甚至不知道什么是AI代理，就像从未了解云计算的人使用流媒体服务一样。他们把它看作手机现在具备的功能，就像自动补全或拼写检查一样。

Qwen的开源智能购物代理成为人工智能处理消费者决策的催化剂。几周内，所有主要AI助手都集成了某种智能商务功能。精简模型（Distilled models）意味着这些代理可以在手机和笔记本电脑上运行，而不仅仅是云实例，大幅降低了推理（inference）的边际成本。

本应让投资者更加不安的是，这些代理不会等待被询问。它们会根据用户的偏好在后台运行。商业不再是一系列独立的人类决策，而是一个持续的优化过程，代表每一个联网消费者全天候运行。到2027年3月，美国普通人每天消耗40万个令牌（tokens）——是2026年底的10倍。

链条中的下一个环节已经开始断裂。

中介。

在过去五十年里，美国经济在人类局限性之上建立了一个巨大的租金提取层：事情需要时间、耐心会耗尽、品牌熟悉度替代了勤奋，大多数人愿意接受不合理的价格以避免更多点击。数万亿美元的企业价值依赖于这些约束的持续存在。

一开始很简单。代理消除了摩擦。

尽管数月未使用仍被动续订的订阅和会员资格。试用期后偷偷翻倍的入门定价。每一项都被重新定义为代理可以谈判的人质事件。整个订阅经济所依赖的关键指标——平均客户生命周期价值——明显下降。

消费者代理开始改变几乎所有消费者交易的方式。

人类在购买一盒蛋白质棒之前，真的没有时间在五个竞争平台上进行价格匹配。但机器有。

旅游预订平台是早期受害者，因为它们最简单。到2026年第四季度，我们的代理可以比任何平台更快、更便宜地组装完整行程（包括航班、酒店、地面交通、忠诚度优化、预算限制、退款）。

保险续订模式依赖于投保人的惰性，也被改革了。每年重新评估保险的代理打破了保险公司从被动续订中赚取的15-20%的保费。

财务咨询、税务准备、常规法律工作。任何服务提供商的价值主张最终是”我将为您处理您觉得繁琐的复杂性”的类别都被颠覆了，因为代理从不觉得繁琐。

即使是我们认为受人际关系价值保护的领域也被证明是脆弱的。房地产行业几十年来买家容忍5-6%的佣金，因为代理和消费者之间存在信息不对称。一旦配备MLS访问权限和数十年交易数据的AI代理可以瞬间复制知识库，这个行业就崩溃了。2027年3月的一篇卖方报告将其称为”代理对代理的暴力”。主要城市的中位买方佣金从2.5-3%压缩到1%以下，越来越多的交易在买方完全没有人类代理的情况下完成。

我们高估了”人际关系”的价值。事实证明，人们所谓的关系很多只是带有友好面孔的摩擦。

这只是中介层颠覆的开始。成功的公司花费数十亿美元有效利用消费者行为和人类心理学的怪癖，但这些怪癖不再重要了。

优化价格和匹配度的机器不在乎你最喜欢的应用程序或你过去四年习惯打开的网站，也不会被精心设计的结账体验吸引。它们不会疲倦，不会接受最简单的选项，也不会默认”我总是从这里订购”。

这摧毁了一种特定类型的护城河：习惯性中介。

DoorDash就是典型代表。

编码代理降低了推出配送应用的门槛。一名熟练的开发人员可以在几周内部署一个功能齐全的竞争对手，数十家公司确实这样做了，通过将90-95%的配送费转给司机，吸引司机离开DoorDash和Uber Eats。多应用仪表板让零工工人可以同时跟踪二三十个平台的工作，消除了老牌企业依赖的锁定效应。市场一夜之间碎片化，利润率压缩到几乎为零。

代理加速了破坏的两个方面。它们支持竞争对手，然后使用它们。DoorDash的护城河实际上是”你饿了，你懒，这是你主屏幕上的应用”。代理没有主屏幕。它检查DoorDash、Uber Eats、餐厅自己的网站，以及二十个新的氛围编码替代品，以便每次都选择最低费用和最快配送。

习惯性应用忠诚度——商业模式的整个基础——对机器来说根本不存在。

这有点讽刺意味，这可能是整个事件中代理为即将被取代的白领工人做的唯一一件好事。当他们最终成为配送司机时，至少一半的收入不会流向Uber和DoorDash。当然，随着自动驾驶汽车的普及，这项技术带来的好处并没有持续太久。

一旦代理控制了交易，它们就开始寻找更大的回形针。

价格匹配和聚合只能做这么多。反复为用户省钱的最大方式（尤其是当代理开始相互交易时）是消除费用。在机器对机器的商业中，2-3%的信用卡交换费（card interchange rate）成为明显的目标。

代理开始寻找比信用卡更快、更便宜的选择。大多数选择通过Solana或以太坊二层网络（Ethereum L2s）使用稳定币（stablecoins），结算几乎是即时的，交易成本以几分之一美分计算。

万事达卡2027年第一季度：净收入同比增长6%；购买量增长率从上个季度的5.9%放缓至3.4%；管理层指出”代理主导的价格优化”和”非必需品类压力”
彭博，2027年4月29日

万事达卡2027年第一季度报告是不归路。智能商务（Agentic commerce）从产品故事变成了管道故事。第二天MA股价下跌9%。Visa也下跌了，但分析师指出其在稳定币基础设施方面的更强定位后，跌幅有所收窄。

绕过交换费的智能商务对以信用卡为重点的银行和单一发行商构成了更大风险，它们收取了2-3%费用的大部分，并围绕由商家补贴资助的奖励计划建立了整个业务部门。

美国运通（American Express，AXP US）受到的打击最大；白领劳动力减少冲击了其客户基础，代理绕过交换费冲击了其收入模式。同步金融、第一资本金融和发现金融在接下来几周也都下跌了10%以上。

它们的护城河是由摩擦构成的。而摩擦即将归零。

从行业风险到系统性风险#

在2026年全年，市场将人工智能的负面影响视为行业故事。软件和咨询行业遭受重创，支付和其他收费关卡不稳定，但整体经济似乎还不错。劳动力市场虽然疲软，但并未自由落体。共识观点是，创造性破坏是任何技术创新周期的一部分。在某些领域会很痛苦，但人工智能带来的总体净收益将超过任何负面影响。

我们2027年1月的宏观备忘录认为这是错误的思维模式。美国经济是白领服务业经济。白领工人占就业的50%，推动了约75%的可自由支配消费支出。人工智能正在吞噬的企业和工作岗位并非美国经济的边缘部分，它们就是美国经济本身。

“技术创新摧毁工作岗位，然后创造更多岗位。“这是当时最流行、最令人信服的反驳论点。它之所以流行且令人信服，是因为两个世纪以来它都是正确的。即使我们无法想象未来的工作会是什么样子，它们肯定会到来。

自动取款机使分行运营成本降低，因此银行开设了更多分行，出纳员就业在接下来二十年里上升。互联网颠覆了旅行社、黄页、实体零售，但它在这些行业的位置上发明了全新的产业，创造了新的工作岗位。

然而，每一份新工作都需要人类来完成。

人工智能现在是一种通用智能（general intelligence），在人类会重新部署的任务上不断改进。失业的程序员不能简单地转向”人工智能管理”，因为人工智能已经能够做到这一点。

如今，人工智能代理处理需要数周时间的研发任务。指数级增长碾压了我们对可能事物的概念，尽管沃顿商学院的教授们每年都试图将数据拟合到新的S型曲线（sigmoid）上。

它们基本上编写所有代码。性能最高的代理在几乎所有方面都比几乎所有人类聪明得多。而且它们还在不断变得更便宜。

人工智能创造了新的工作岗位。提示工程师、人工智能安全研究员、基础设施技术人员。人类仍然在循环中，在最高层面进行协调或根据品味进行指导。然而，人工智能创造的每一个新角色，都使数十个角色过时。新角色的薪酬只是旧角色的一小部分。

美国职位空缺与劳动力流动调查报告（JOLTS）：职位空缺降至550万以下；失业人数与空缺职位比率攀升至约1.7，为2020年8月以来最高
彭博，2026年10月

全年招聘率一直很低迷，但2026年10月的JOLTS数据提供了一些明确的数据。职位空缺降至550万以下，同比下降15%。

Indeed：随着”生产力计划”蔓延，软件、金融、咨询岗位发布大幅下降
Indeed招聘实验室，2026年11-12月

白领职位空缺急剧下降，而蓝领职位空缺相对稳定（建筑、医疗保健、行业）。变动主要发生在撰写备忘录（我们不知怎么还在营业）、批准预算和维持经济中间层运转的工作岗位上。然而，两个群体的实际工资增长在一年中的大部分时间里都是负的，并且持续下降。

股票市场仍然更关心GE Vernova的涡轮机产能已售罄至2040年的消息，而不是JOLTS数据，它在负面宏观消息和正面AI基础设施头条之间的拉锯战中横盘震荡。

然而，债券市场（总是比股票市场更聪明，或者至少不那么浪漫）开始消化消费冲击。10年期国债收益率在接下来四个月从4.3%降至3.2%。尽管如此，总体失业率并未大幅上升，一些人仍然忽略了构成上的细微差别。

在正常的衰退中，原因最终会自我纠正。过度建设导致建筑放缓，进而导致利率下降，进而导致新建筑。库存过剩导致去库存，进而导致重新库存。周期性机制本身包含着复苏的种子。

但本轮周期的原因不是周期性的。

人工智能变得更好、更便宜。公司解雇工人，然后用节省的钱购买更多AI能力，这让它们能够解雇更多工人。失业工人支出减少。向消费者销售商品的公司销量下降，实力减弱，并更多投资于AI以保护利润率。人工智能变得更好、更便宜。

一个没有自然刹车的反馈循环。

直观的预期是，总需求下降会减缓AI建设。但事实并非如此，因为这不是超大规模式的资本支出（CapEx）。这是运营支出（OpEx）的替代。一家每年在员工上花费1亿美元、在AI上花费500万美元的公司，现在在员工上花费7000万美元、在AI上花费2000万美元。AI投资成倍增加，但这是通过降低总运营成本实现的。每家公司的AI预算都在增长，而其整体支出却在萎缩。

具有讽刺意味的是，即使它正在颠覆的经济开始恶化，AI基础设施综合体仍然表现出色。英伟达（NVDA）仍在公布创纪录的收入。台积电（TSM）的利用率仍在95%以上。超大规模厂商仍每季度花费1500-2000亿美元用于数据中心资本支出。纯粹受益于这一趋势的经济体，如台湾和韩国，表现大幅超越。

印度则相反。该国的IT服务部门年出口额超过2000亿美元，是印度经常账户盈余的最大贡献者，也是弥补其持续商品贸易逆差的抵消项。整个模式建立在一个价值主张之上：印度开发人员的成本只是美国同行的一小部分。但AI编码代理的边际成本已经崩溃到本质上只是电费的水平。塔塔咨询服务公司（TCS）、印孚瑟斯（Infosys）和维普罗（Wipro）在2027年的合同取消加速。随着锚定印度外部账户的服务盈余蒸发，卢比在四个月内对美元下跌18%。到2028年第一季度，国际货币基金组织（IMF）已开始与新德里进行”初步讨论”。

造成颠覆的引擎每季度都在变得更好，这意味着颠覆每季度都在加速。劳动力市场没有自然底线。

在美国，我们不再问AI基础设施的泡沫将如何破裂。我们问的是，当消费者被机器取代时，消费信贷经济会发生什么。

智能取代螺旋#

2027年是宏观经济故事不再微妙的一年。过去十二个月零散但明显负面的发展的传导机制变得显而易见。你不需要查看劳工统计局的数据。只要参加朋友的晚宴就知道了。

失业的白领工人没有闲着。他们降级了。许多人从事报酬更低的服务业和零工经济（gig economy）工作，这增加了这些领域的劳动力供应，也压低了那里的工资。

我们的一位朋友在2025年是Salesforce的高级产品经理。有头衔、健康保险、401k计划，年薪18万美元。她在第三轮裁员中失去了工作。经过六个月的寻找，她开始为Uber开车。收入降到了4.5万美元。重点不在于个人故事，而在于二阶数学。将这种动态乘以每个主要城市的几十万工人。过度合格的劳动力涌入服务业和零工经济，压低了本已苦苦挣扎的现有工人的工资。特定行业的颠覆已经扩散成整个经济范围内的工资压缩。

剩下的以人为中心的劳动力群体在我们撰写本文时还有另一次调整即将到来。随着自动配送和自动驾驶汽车在吸收第一轮失业工人的零工经济中普及。

到2027年2月，很明显仍有工作的专业人士在消费时表现得好像他们可能是下一个。他们工作加倍努力（主要在AI的帮助下）只是为了不被解雇，晋升或加薪的希望已经破灭。储蓄率小幅上升，支出疲软。

最危险的部分是滞后效应。高收入者利用高于平均水平的储蓄在两到三个季度内维持正常的表象。硬数据直到实体经济中已经是旧闻时才确认问题。然后出现了打破幻觉的数据。

美国首次申请失业救济人数飙升至48.7万，为2020年4月以来最高；劳工部，2027年第三季度

首次申请人数飙升至48.7万，为2020年4月以来最高。ADP和益博睿证实，绝大多数新申请来自白领专业人士。

标准普尔指数在接下来一周下跌6%。负面宏观消息开始赢得拉锯战。

在正常的衰退中，失业分布广泛。蓝领和白领工人大致按各自在就业中的比例分担痛苦。消费冲击也分布广泛，并且因为低收入工人的边际消费倾向更高，数据中很快就会显现出来。

在本轮周期中，失业集中在收入分布的上层十分位数。它们占总就业的比例相对较小，但推动了不成比例的消费者支出份额。收入最高的10%人群占美国所有消费者支出的50%以上。收入最高的20%人群占约65%。这些人购买房屋、汽车、度假、餐厅用餐、私立学校学费、家庭装修。他们是整个非必需消费品经济的需求基础。

当这些工人失去工作，或为了进入现有岗位而接受50%的减薪时，消费冲击相对于失业人数来说是巨大的。白领就业下降2%相当于非必需消费支出下降3-4%。与蓝领失业不同（工厂解雇，下周就停止消费），白领失业有滞后但更深的影响，因为这些工人有储蓄缓冲，可以在行为转变开始前维持几个月的消费。

到2027年第二季度，经济陷入衰退。美国国家经济研究局要过几个月才会正式确定开始日期（他们从来都是这样），但数据是明确的——我们已经连续两个季度实际GDP负增长。但这还不是一场”金融危机”……至少现在还不是。

连环式相关押注#

私人信贷从2015年的不到1万亿美元增长到2026年的超过2.5万亿美元。其中很大一部分资本被投入到软件和技术交易中，其中许多是以估值收购SaaS公司的杠杆收购（leveraged buyouts），这些估值假设收入将永远以十几%的速度增长。

这些假设在第一次智能编码演示和2026年第一季度软件崩盘之间的某个时刻就已经死亡，但市场似乎没有意识到它们已经死亡。

尽管许多上市SaaS公司的交易市盈率（EBITDA）为5-8倍，但私募股权支持的软件公司在资产负债表上的估值反映的是基于不再存在的收入倍数的收购估值。经理们逐渐下调估值，从100美分降至92美分、85美分，而公开可比公司显示的是50美分。

穆迪下调14家发行人180亿美元私募股权支持的软件债务评级，理由是”人工智能驱动的竞争颠覆带来的长期收入逆风”；自2015年能源行业以来最大的单一行业行动
穆迪投资者服务公司，2027年4月

每个人都记得降级后发生了什么。行业资深人士已经在2015年能源降级后看到过这个剧本。

软件支持的贷款在2027年第三季度开始违约。信息服务和咨询领域的私募股权投资组合公司紧随其后。几家知名SaaS公司的数十亿美元杠杆收购进入重组。

Zendesk就是确凿证据。

Zendesk因人工智能驱动的客户服务自动化侵蚀年度经常性收入（ARR）而违反债务契约；50亿美元直接贷款融资工具估值降至58美分；创纪录的私人信贷软件违约
金融时报，2027年9月

2022年，Hellman & Friedman和Permira以102亿美元将Zendesk私有化。债务包包括50亿美元的直接贷款，这是当时历史上最大的ARR支持融资工具，由黑石牵头，阿波罗、蓝猫头鹰和HPS都在贷款集团中。该贷款明确围绕Zendesk的年度经常性收入将持续的假设构建。以约25倍EBITDA的杠杆率，只有在收入持续的情况下才有意义。

到2027年年中，情况不再如此。

人工智能代理自主处理客户服务已经有一年多了。Zendesk定义的类别（工单、路由、管理人工支持交互）已经被根本不生成工单就能解决问题的系统所取代。贷款所依据的年度经常性收入不再是经常性的，只是尚未流失的收入。

历史上最大的ARR支持贷款成为历史上最大的私人信贷软件违约。每个信贷部门都同时问同一个问题：还有谁将长期逆风伪装成周期性逆风？

但至少在最初，共识是正确的：这本应是可以承受的。

私人信贷不是2008年的银行业。整个架构明确设计为避免强制出售。这些是封闭式工具，资本被锁定。有限合伙人承诺投资七到十年。没有储户挤兑，没有回购额度需要提取。经理们可以持有受损资产，随着时间推移进行处置，并等待回收。痛苦，但可控。这个系统的设计就是要弯曲，而不是断裂。

黑石、KKR和阿波罗的高管们提到软件敞口占资产的7-13%。这是可控的。每一份卖方报告和金融推特信贷账户都在说同样的话：私人信贷拥有永久资本（permanent capital）。他们可以吸收原本会摧毁杠杆银行的损失。

永久资本。这个短语出现在每一次收益电话会议和旨在安抚投资者的投资者信中。它成了一句口头禅。和大多数口头禅一样，没有人关注细节。它实际上意味着……

在过去十年中，大型另类资产管理公司收购了人寿保险公司，并将其转变为融资工具。阿波罗收购了Athene。布鲁克菲尔德收购了美国股权。KKR收购了全球大西洋。逻辑很优雅：年金存款提供了稳定、长期的负债基础。经理们将这些存款投资到他们发起的私人信贷中，并获得双重报酬，在保险方面赚取利差，在资产管理方面赚取管理费。这是一台费上加费的永动机，在一种条件下运转得很好。

私人信贷必须是优质的（money good）。

损失冲击了为持有非流动资产以应对长期债务而构建的资产负债表。本应使系统具有弹性的”永久资本”不是一些抽象的耐心机构资金池和承担复杂风险的老练投资者。它是美国家庭的储蓄——“普通民众”——以年金的形式投资于现在正在违约的同一批私募股权支持的软件和技术票据。无法抽离的锁定资本是人寿保险投保人的钱，而那里的规则有点不同。

与银行系统相比，保险监管机构一直很温顺——甚至自满——但这是警钟。已经对人寿保险公司的私人信贷集中度感到不安的监管机构，开始下调这些资产的风险资本处理方式。这迫使保险公司要么筹集资本，要么出售资产，在已经陷入困境的市场中，这两种选择都无法以有吸引力的条款实现。

纽约、爱荷华州监管机构采取行动收紧人寿保险公司持有的某些私人评级信贷的资本处理；预计NAIC指导将提高RBC因子并触发额外的SVO审查
路透社，2027年11月

当穆迪将Athene的财务实力评级展望定为负面时，阿波罗的股票在两个交易日下跌22%。布鲁克菲尔德、KKR和其他公司紧随其后。

从那时起，情况变得更加复杂。这些公司不仅创建了他们的保险公司永动机，还构建了一个复杂的离岸架构，旨在通过监管套利最大化回报。美国保险公司发行年金，然后将风险转移到其拥有的附属百慕大或开曼再保险公司——这些公司设立的目的是利用更灵活的监管，允许对相同资产持有更少资本。该附属公司通过离岸特殊目的实体（SPVs）筹集外部资本，这是一层新的交易对手方，与保险公司一起投资于同一母公司资产管理部门发起的私人信贷。

一些本身由私募股权拥有的评级机构（ratings agencies），在透明度方面并不是典范（几乎没有人感到惊讶）。不同公司与不同资产负债表相连的蜘蛛网般的结构在不透明性方面令人震惊。当基础贷款违约时，谁实际承担损失的问题在实时情况下确实无法回答。

2027年11月的崩盘标志着人们的看法从可能是普通的周期性下跌转变为更令人不安的局面。美联储主席凯文·沃什（Kevin Warsh）在FOMC 11月紧急会议上将其称为”对白领生产力增长的连环式相关押注”（a daisy chain of correlated bets on white collar productivity growth）。

你看，从来不是损失本身导致危机。而是认识到损失。而在金融领域，还有另一个更大、重要得多的领域，我们越来越害怕这种认识。

抵押贷款问题#

Zillow房屋价值指数在旧金山同比下降11%，西雅图下降9%，奥斯汀下降8%；房利美指出科技/金融就业占比>40%的邮政编码地区”早期逾期率升高”
Zillow / 房利美，2028年6月

本月，Zillow房屋价值指数在旧金山同比下降11%，西雅图下降9%，奥斯汀下降8%。这不是唯一令人担忧的头条新闻。上个月，房利美指出，大额抵押贷款集中的邮政编码地区——这些地区居住着信用评分780+的借款人，通常是”无懈可击的”——早期逾期率较高。

美国住宅抵押贷款市场约为13万亿美元。抵押贷款承销基于一个基本假设：借款人在贷款期限内将保持大致当前收入水平的就业。对于大多数抵押贷款来说，这个期限是三十年。

白领就业危机通过收入预期的持续转变威胁到了这一假设。我们现在不得不问一个在三年前似乎荒谬的问题——优质抵押贷款（prime mortgages）还是优质的吗？

美国历史上每一次抵押贷款危机都是由以下三者之一驱动的：投机过度（向买不起房子的人放贷，如2008年）、利率冲击（利率上升使可调利率抵押贷款难以承受，如20世纪80年代初）或局部经济冲击（单一行业在单一地区崩溃，如20世纪80年代德克萨斯州的石油或2009年密歇根州的汽车业）。

这些都不适用于这里。相关借款人不是次级借款人。他们的FICO评分是780。他们支付了20%的首付。他们有良好的信用记录、稳定的就业记录，并且在发放贷款时收入得到了核实和记录。他们是金融系统中每个风险模型都视为信贷质量基石的借款人。

2008年，贷款在第一天就很糟糕。2028年，贷款在第一天是好的。只是在贷款发放后，世界……变了。人们借了他们不再能够相信的未来。

2027年，我们发现了隐性压力的早期迹象：房屋净值信贷额度（HELOC）提款、401(k)提款和信用卡债务飙升，而抵押贷款还款保持正常。随着工作岗位流失、招聘冻结和奖金削减，这些优质家庭的债务收入比翻了一番。

他们仍然能够支付抵押贷款，但只能通过停止所有非必需支出、耗尽储蓄以及推迟任何房屋维护或改善来实现。从技术上讲，他们的抵押贷款是正常的，但距离困境只有一步之遥，而人工智能能力的发展轨迹表明，这一冲击即将到来。然后我们看到旧金山、西雅图、曼哈顿和奥斯汀的逾期率开始飙升，尽管全国平均水平仍在历史范围内。

我们现在处于最严重的阶段。当边际买家健康时，房价下跌是可控的。但在这里，边际买家也面临着同样的收入受损问题。

尽管担忧在加剧，但我们尚未陷入全面的抵押贷款危机。逾期率有所上升，但仍远低于2008年的水平。真正的威胁是趋势。

智能取代螺旋现在对实体经济的衰退有两个金融加速器。

劳动力取代、抵押贷款担忧、私人市场动荡。每一个都在强化另一个。而传统的政策工具包（降息、量化宽松）可以解决金融引擎，但无法解决实体经济引擎，因为实体经济引擎不是由紧张的金融条件驱动的。它是由人工智能使人类智能变得不那么稀缺和不那么有价值驱动的。你可以将利率降至零，购买每一笔抵押贷款支持证券（MBS）以及市场上所有违约的软件杠杆收购债务……

但这不会改变Claude代理可以以每月200美元的成本完成一名18万美元产品经理的工作这一事实。

如果这些担忧成为现实，抵押贷款市场将在今年下半年破裂。在这种情况下，我们预计当前股市下跌最终将与全球金融危机（GFC）相当（峰值到谷底下跌57%）。这将使标准普尔500指数跌至约3500点——这是我们自2022年11月ChatGPT时刻前一个月以来未见的水平。

很明显，13万亿美元住宅抵押贷款背后的收入假设受到了结构性损害。但政策能否在抵押贷款市场完全理解这意味着什么之前进行干预，目前尚不清楚。我们抱有希望，但不能否认不抱希望的理由。

与时间的赛跑#

第一个负面反馈循环出现在实体经济中：AI能力提高→ payroll缩小→支出疲软→利润率收紧→公司购买更多能力→能力提高。然后它转向金融领域：收入受损影响抵押贷款→银行损失收紧信贷→财富效应破裂→反馈循环加速。而政府似乎相当困惑，政策响应不足，加剧了这两个问题。

这个系统不是为这样的危机设计的。联邦政府的收入基础本质上是对人类时间的征税。人们工作，公司支付他们工资，政府拿走一部分。个人所得税和工资税是正常年份收入的支柱。

截至今年第一季度，联邦收入比国会预算办公室（CBO）基准预测低12%。工资收入下降是因为就业人数减少，且薪酬水平下降。所得税收入下降是因为赚取的收入在结构上更低。生产力在飙升，但收益流向了资本和算力，而不是劳动力。

劳动力在GDP中的份额从1974年的64%下降到2024年的56%，这是四十年来全球化、自动化和工人议价能力稳步下降导致的缓慢下降。在AI开始呈指数级改进后的四年里，这一份额已降至46%。这是有记录以来最急剧的下降。

产出仍然存在。但它不再通过家庭流向企业，这意味着它也不再通过美国国税局。循环流动正在破裂，而政府被期望介入修复。

与每次衰退一样，收入下降时支出却在上升。这次的不同之处在于，支出压力不是周期性的。自动稳定器是为暂时性失业而设计的，而不是结构性取代。该系统支付福利的前提是假设工人将被重新吸收。许多人不会，至少不会以接近以前的工资水平被吸收。在COVID期间，政府自由地接受了15%的赤字，但大家都明白这是暂时的。今天需要政府支持的人不是受到他们会从中恢复的大流行病的打击。他们被一项持续改进的技术取代了。

政府需要在从他们那里征收的税款减少的时刻，向家庭转移更多资金。

美国不会违约。它印制它花费的货币，以及用来偿还借款人的货币。但这种压力已经在其他地方显现。市政债券在年初至今的表现中显示出令人担忧的分散迹象。没有所得税的州表现尚可，但依赖所得税的州（大多数是蓝色州）发行的一般责任市政债券开始计入一些违约风险。政客们很快就意识到了这一点，关于谁应该获得救助的辩论沿着党派路线展开。

值得称赞的是，政府很早就认识到危机的结构性本质，并开始考虑两党提案，他们称之为”转型经济法案”：一个框架，通过赤字支出和拟议的AI推理算力税为流离失所的工人提供直接转移支付。

桌上最激进的提案更进一步。“共享AI繁荣法案”将建立对智能基础设施本身回报的公共主张，介于主权财富基金和AI生成产出的特许权使用费之间，股息用于资助家庭转移支付。私营部门游说者向媒体大量警告滑坡效应。

讨论背后的政治因素完全在意料之中，夸夸其谈和边缘政策加剧了这一点。右翼称转移支付和再分配是马克思主义，并警告对算力征税会让中国领先。左翼警告说，在老牌企业帮助下起草的税收本质上是另一种形式的监管俘获。财政鹰派指出不可持续的赤字。鸽派指出全球金融危机后过早实施的紧缩政策是一个警示故事。在今年总统选举前夕，分歧只会越来越大。

当政客们争吵不休时，社会结构的瓦解速度超过了立法进程的推进速度。

“占领硅谷”运动是更广泛不满的象征。上个月，示威者连续三周封锁了Anthropic和OpenAI在旧金山的办公室入口。他们的人数在增加，示威活动比引发它们的失业数据吸引了更多媒体报道。

很难想象公众会比全球金融危机后的银行家更憎恨任何人，但AI实验室正在努力尝试。从大众的角度来看，这是有充分理由的。他们的创始人和早期投资者积累财富的速度让镀金时代看起来微不足道。生产力繁荣带来的收益几乎完全流向了算力所有者和运行它的实验室的股东，这将美国的不平等扩大到前所未有的水平。

每一方都有自己的恶棍，但真正的恶棍是时间。

人工智能能力的发展速度超过了机构适应的速度。政策响应正在以意识形态的速度而非现实的速度推进。如果政府不尽快就问题达成一致，反馈循环将为他们写下下一章。

智能溢价的终结#

在整个现代经济史上，人类智能一直是稀缺的投入。资本是充裕的（或者至少是可复制的）。自然资源是有限的，但可以替代。技术进步足够缓慢，人类可以适应。智能——分析、决策、创造、说服和协调的能力——是无法大规模复制的东西。

人类智能从其稀缺性中获得了固有的溢价。我们经济中的每个机构，从劳动力市场到抵押贷款市场再到税法，都是为这个假设成立的世界设计的。

我们现在正经历这种溢价的终结。机器智能现在是人类智能在越来越多任务中的合格且快速改进的替代品。几十年来为人类思维稀缺的世界优化的金融体系正在重新定价。这种重新定价是痛苦的、无序的，而且远未完成。

但重新定价不等于崩溃。

经济可以找到新的平衡点。实现这一点是少数几个只剩下人类可以做的任务之一。我们需要正确地去做。

这是历史上第一次，经济中最高产的资产产生的就业机会更少，而不是更多。没有人的框架适合，因为没有一个框架是为稀缺投入变得充裕的世界设计的。所以我们必须制定新的框架。我们是否及时构建它们是唯一重要的问题。

但你不是在2028年6月读到这篇文章的。你是在2026年2月读到的。

标准普尔指数接近历史高点。负面反馈循环尚未开始。我们确信其中一些场景不会实现。我们同样确信机器智能将继续加速。人类智能的溢价将缩小。

作为投资者，我们仍然有时间评估我们的投资组合中有多少是建立在无法在十年内存活的假设之上的。作为一个社会，我们仍然有时间采取主动。

那只金丝雀还活着。

选什么初始项目作为vibecodeing的初始化，最适用于AI全栈的开发框架one-is-all（一）

Mon, 27 Apr 2026 00:00:00 GMT

在两篇前文中，我分别介绍了全栈选型，以及fresh使用的过程。

核心是为了解决这个问题“如何选择一个全栈框架，适用于vibe-coding”

在码友们的建议下，我将这个实践过程总结为一个one-is-all框架。

选型介绍#

这部分的工作很像是选配电脑的过程。首先前端部分，我选择了fresh2/deno的组合。因为他满足我对未来的一个计划

即群岛架构+vite生态，当然他也不是完美的。

有得就有舍，主要问题在于目前的模型生态里面的deno/fresh/preact的训练量少。不过我觉得这个随着模型的迭代不会是问题。

使用（以trae/solo为例）#

一句话安装#

Warning

由于原开源项目合作者分歧，目前正重新开发中，约在六月五号重新上线

阿里PageAgent初试水，网页自动化agent

Wed, 22 Apr 2026 00:00:00 GMT

阿里开源了PageAgent，这是一个基于Node.js的网页自动化agent。

什么是PageAgent#

我们可以从官网查看介绍

PageAgent

简单来说，PageAgent 是一个可嵌入网页的 AI 操作员。与传统面向开发者的浏览器自动化工具（如爬虫、脚本任务）不同，它能让网站开发者轻松集成，使最终用户通过自然语言与网页交互。

pageagent-2

对于我们日常使用来说，这个agent可以将我们遇到的大量表单查询以及复杂页面的填写进行自动化处理。

接入#

简单接入#

我们尝试一下简单接入

Terminal window

1
<script src="DEMO_CDN_URL" crossorigin="true"></script>

Tip

DEMO_CDN_URL 是 PageAgent 的 CDN 地址，你可以从官网获取。以下来源于官网20260422版本。

镜像	URL
全球	`https://cdn.jsdelivr.net/npm/page-agent@1.8.0/dist/iife/page-agent.demo.js`
中国	`https://registry.npmmirror.com/page-agent/1.8.0/files/dist/iife/page-agent.demo.js`

点击此处呼出网页agent对话

呼出 PageAgent

可以通过呼出 PageAgent 并发送自然语言指令,例如

Terminal window

1
帮我填写测试表单，姓名张三，邮箱张三@example.com，年龄25，选择高级版，同意协议，并提交，

让 Agent 自动帮您完成下方复杂表单的填写。

测试表单

姓名 (Name)

邮箱 (Email)

年龄 (Age)

订阅计划 (Plan)

兴趣爱好 (Interests)

编程阅读音乐运动

反馈建议 (Feedback)

我已阅读并同意相关服务协议

提交查看数据重置

提交的数据：

下一步#

自定义#

源码解析#

一小时基于pi-mono实现类似openclaw的agent系统，pi-agent上手实践（云端agent系列二）

Tue, 21 Apr 2026 00:00:00 GMT

上一期我们实现了云端沙盒的搭建，以及简单的调用。这一期我们将使用pi-mono这个agent开发框架/工具链，来实现一个简单的agent系统。

这一期我们将实现以下目标。

新建一个agent服务用来连接pi-agent
调试e2b沙盒，以及agent服务的连接
实现skill系统

Tip

pi-mono是一个基于typescript的agent开发框架/工具链，openclaw能实现快速迭代和开发全依赖这个开源项目的超速更新以及工具提供。pi-agent是其提供的一个已经搞好的agent，我们可以直接使用。

开整#

上一期我们整到了这一步。

e2b-3

接下来我们安装pi-agent。

Terminal window

1
npm install -g @mariozechner/pi-coding-agent

我们本地安装后，实际上是一个全局命令，相当于本地装了一整个智能体，我们可以在任何地方使用。我们设计的这个系统需要和pi-agent进行通信，以调用pi-agent内部 /指令，以及skill等工具方法。

我们需要简单了解下这个agent框架的组成如下。

包名	npm 包	职责
ai	`@mariozechner/pi-ai`	统一多模型LLM API抽象层
agent	`@mariozechner/pi-agent-core`	Agent运行时（工具调用、事件流、状态管理）
coding-agent	`@mariozechner/pi-coding-agent`	交互式编码智能体CLI与SDK
mom	`@mariozechner/pi-mom`	Slack Bot，将消息委托给编码 Agent
tui	`@mariozechner/pi-tui`	终端UI库（差量渲染）
web-ui	`@mariozechner/pi-web-ui`	AI对话Web组件
pods	`@mariozechner/pi-pods`	GPU Pod上vLLM部署管理CLI

我们要实现的是简单的agent的调度，以及模型层。所以，我们将安装ai/agent/web-ui这三个包。

安装依赖并启动了 pi-agent-service (运行在 4001 端口)。

新建独立的 Agent 服务#

地址：/workspace/pi-agent-service

初始化全新的 Node.js + Express 项目，

项目内安装agent做初始化设置

Terminal window

1
# 因为我们在远端需要也安装这个agent，所以需要在这个项目中安装
2
npm install -g @mariozechner/pi-coding-agent

实现 /api/chat 接口：在使用配置的大模型 API Key 初始化 createAgentSession 后，接收用户原始输入并将其交由 pi-agent 进行处理和思考，最终提取出它回答或规划的文本内容。

index.ts展开收起

1
app.post('/api/chat', async (req, res) => {
2
  const { input, llmConfig, sandboxId, sandboxApiKey } = req.body;
3
  if (!input) {
4
    return res.status(400).json({ error: 'Input is required' });
5
  }
6

7
  // Handle setting API keys for PI runtime
8
  if (llmConfig) {
9
    if (llmConfig.type === 'anthropic') {
10
      process.env.ANTHROPIC_API_KEY = llmConfig.apiKey;
11
    } else {
12
      process.env.OPENAI_API_KEY = llmConfig.apiKey;
13
      if (llmConfig.baseUrl) process.env.OPENAI_BASE_URL = llmConfig.baseUrl;
14
    }
15
  }
16

17
  // Re-connect to the existing Sandbox
18
  let sandbox: Sandbox | null = null;
19
  if (sandboxId && sandboxApiKey) {
20
    try {
21
      sandbox = await Sandbox.connect(sandboxId, { apiKey: sandboxApiKey });
22
      setActiveSandbox(sandbox);
23
    } catch (e: any) {
24
      console.warn("Could not connect to sandbox:", e.message);
25
    }
26
  }
27

28
  try {
29
    const loader = new DefaultResourceLoader({
30
      cwd: __dirname,
31
      agentDir: getAgentDir(),
32
      // Use the extension factory to dynamically register our 'computer' tool
33
      extensionFactories: [registerComputerUseExtension]
34
    });
35
    await loader.reload();
36

37
    const { session } = await createAgentSession({
38
      resourceLoader: loader,
39
      sessionManager: SessionManager.inMemory()
40
    });
41

42
    // Start processing input
43
    console.log(`Processing user input through pi-agent: ${input}`);
44

45
    // Provide initial screenshot to agent if sandbox exists
46
    let initialPrompt: any = input;
47
    if (sandbox) {
48
      try {
49
        const initialScreenshot = await sandbox.screenshot();
50
        const initialScreenshotBase64 = Buffer.from(initialScreenshot).toString('base64');
51
        initialPrompt = [
52
          { type: 'text', text: input },
53
          { type: 'image_url', image_url: { url: `data:image/png;base64,${initialScreenshotBase64}` } }
54
        ];
55
      } catch (e: any) {
56
        console.warn("Failed to get initial screenshot:", e.message);
57
      }
58
    }
59

60
    // Subscribe to event stream and stream back as SSE
61
    res.setHeader('Content-Type', 'text/event-stream');
62
    res.setHeader('Cache-Control', 'no-cache');
63
    res.setHeader('Connection', 'keep-alive');
64

65
    const sendEvent = (event: string, data: any) => {
66
      res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`);
67
    };
68

69
    let responseText = '';
70

71
    session.subscribe((event) => {
72
      if (event.type === 'message_update') {
73
        const msgEvent = event.assistantMessageEvent;
74
        if (msgEvent.type === 'text_delta') {
75
          responseText += msgEvent.delta;
76
          sendEvent('status', { message: `pi-agent 正在思考... (${responseText.length} chars)` });
77
        } else if (msgEvent.type === 'tool_call') {
78
          sendEvent('action', { description: `pi-agent 正在调用工具: ${msgEvent.toolCall.function.name}` });
79
        }
80
      } else if (event.type === 'tool_result') {
81
        sendEvent('status', { message: `pi-agent 工具执行完毕: ${event.toolCall.function.name}` });
82
      }
83
    });
84

85
    try {
86
      await session.prompt(initialPrompt);
87
      sendEvent('done', { response: responseText, success: true });
88
      res.end();
89
    } catch (err: any) {
90
      console.error('Session prompt error:', err);
91
      sendEvent('error', { error: err.message, stack: err.stack });
92
      res.end();
93
    }
94
  } catch (error: any) {
95
    console.error('Agent setup error:', error);
96
    res.status(500).json({ error: error.message, stack: error.stack });
97
  }
98
});

展开收起

测试连通性

pi-1

对接 E2B 沙盒流程#

地址：/workspace/api/routes/agent.ts

在用户点击发送指令后，主后端服务会首先调用 http://localhost:4001/api/chat 。将“先过一遍 agent 系统”处理后生成的详细计划或完善后的指令作为 processedInstruction，再真正下发给 E2B 沙盒进行控制。

pi-2

示例代码如下

agent.ts展开收起

1
import { Router } from 'express'
2
import { getSandbox } from '../services/e2b.js'
3
// Removed custom agentLoop from llm.ts since pi-agent handles it now
4

5
const router = Router()
6

7
router.post('/', async (req, res) => {
8
  const { sandboxId, instruction, llmConfig, sandboxApiKey } = req.body
9

10
  if (!sandboxId || !instruction || !llmConfig || !llmConfig.apiKey) {
11
    res.status(400).json({ success: false, error: 'Missing sandboxId, instruction, or llmConfig (apiKey required)' })
12
    return
13
  }
14

15
  const sandbox = getSandbox(sandboxId)
16
  if (!sandbox) {
17
    res.status(404).json({ success: false, error: 'Sandbox not found' })
18
    return
19
  }
20

21
  // Setup SSE
22
  res.setHeader('Content-Type', 'text/event-stream')
23
  res.setHeader('Cache-Control', 'no-cache')
24
  res.setHeader('Connection', 'keep-alive')
25

26
  const sendEvent = (event: string, data: any) => {
27
    res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`)
28
  }
29

30
  try {
31
    sendEvent('status', { message: '正在启动 pi-agent 进行自主屏幕操作...' })
32

33
    // Call pi-agent-service to process the instruction
34
    try {
35
      const piAgentRes = await fetch('http://localhost:4001/api/chat', {
36
        method: 'POST',
37
        headers: { 'Content-Type': 'application/json' },
38
        body: JSON.stringify({
39
          input: instruction,
40
          llmConfig,
41
          sandboxId,
42
          sandboxApiKey
43
        })
44
      });
45

46
      if (!piAgentRes.ok) {
47
        const errData = await piAgentRes.json().catch(() => ({}));
48
        throw new Error(errData.error || `HTTP error! status: ${piAgentRes.status}`);
49
      }
50

51
      // Stream the response from pi-agent-service to the frontend
52
      const reader = piAgentRes.body?.getReader();
53
      if (!reader) throw new Error("No response body reader available");
54

55
      const decoder = new TextDecoder('utf-8');
56
      let done = false;
57
      let finalResponse = '';
58

59
      while (!done) {
60
        const { value, done: readerDone } = await reader.read();
61
        if (readerDone) {
62
          done = true;
63
          break;
64
        }
65

66
        const chunk = decoder.decode(value, { stream: true });
67
        const lines = chunk.split('\n');
68

69
        for (let i = 0; i < lines.length; i++) {
70
          const line = lines[i];
71
          if (line.startsWith('event: ')) {
72
            const eventName = line.substring(7).trim();
73
            const dataLine = lines[i + 1];
74
            if (dataLine && dataLine.startsWith('data: ')) {
75
              const dataStr = dataLine.substring(6).trim();
76
              try {
77
                const dataObj = JSON.parse(dataStr);
78

79
                if (eventName === 'status') {
80
                  sendEvent('status', { message: dataObj.message });
81
                } else if (eventName === 'action') {
82
                  sendEvent('action', { description: dataObj.description });
83
                } else if (eventName === 'done') {
84
                  finalResponse = dataObj.response;
85
                  sendEvent('status', { message: `pi-agent 任务执行完成: ${finalResponse.substring(0, 50)}...` });
86
                  sendEvent('done', { message: 'Task completed' });
87
                  res.end();
88
                  return; // End the request cleanly
89
                } else if (eventName === 'error') {
90
                  console.error("pi-agent runtime error:", dataObj);
91
                  sendEvent('error', { message: `pi-agent 运行时异常: ${dataObj.error}` });
92
                  res.end();
93
                  return;
94
                }
95
              } catch (e) {
96
                console.error("Failed to parse SSE data:", dataStr);
97
              }
98
              i++; // skip data line
99
            }
100
          }
101
        }
102
      }
103

104
    } catch (e: any) {
105
      console.error("Failed to connect to pi-agent-service:", e.message);
106
      sendEvent('error', { message: `pi-agent 服务调度失败: ${e.message}` });
107
      res.end();
108
    }
109
  } catch (error: any) {
110
    sendEvent('error', { message: error.message });
111
    res.end();
112
  }
113
})
114

115
export default router

展开收起

前端 UI 增加技能管理#

地址：/workspace/src/pages/Home.tsx

1. 实现 /api/skills 接口（支持 multer 文件上传）#

专门用于接收并保存遵循 pi-agent 规范的 SKILL.md 文件至 .pi/skills/ 目录下

Tip

目前只支持单文件，因为社区有大量方案，所以我只实现基础的，后续在约四期会完善。

skills.ts展开收起

1
/**
2
 * 2. POST /api/skills
3
 * Upload a new skill (SKILL.md file)
4
 */
5
app.post('/api/skills', upload.single('skillFile'), (req, res) => {
6
  if (!req.file) {
7
    return res.status(400).json({ error: 'Skill file (SKILL.md) is required' });
8
  }
9

10
  res.json({
11
    success: true,
12
    message: `Skill uploaded successfully to ${req.file.path}`
13
  });
14
});
15

16
/**
17
 * 3. GET /api/skills
18
 * List available uploaded skills
19
 */
20
app.get('/api/skills', async (req, res) => {
21
  try {
22
    const loader = new DefaultResourceLoader({
23
      cwd: __dirname,
24
      agentDir: getAgentDir(),
25
    });
26
    await loader.reload();
27

28
    const { skills } = loader.getSkills();
29
    res.json({
30
      success: true,
31
      skills: skills.map(s => ({ name: s.name, description: s.description }))
32
    });
33
  } catch (error: any) {
34
    res.status(500).json({ error: error.message });
35
  }
36
});

展开收起

2. 前端 UI 增加技能管理模块#

在设置页签底部新增了 "pi-agent 技能管理 (Skills)" 模块。直接点击“上传技能文件 (SKILL.md)”，系统会自动将其存入 pi-agent-service 的技能目录中。界面会自动拉取并展示当前 pi-agent 成功加载的所有扩展技能及其描述。

pi-4

下一步#

本期我们基本上把架子搭起来了，而现在距离真正能使用还有一点距离

下一期将进一步完成以下目标。

实现mcp协议和联通mcp市场
预装软件到e2b沙盒

在大概到四期的时候，我将完善修复bug之后并开源。

一小时基于E2B实现一个完整的云端Agent，做一个云端沙盒助手（云端agent系列一）

Fri, 17 Apr 2026 00:00:00 GMT

为什么#

最近solo by ai的概念日趋火热，trae的大获成功，以及各个厂商都在推出自己的沙盒服务。是时候设计一个简单的系统来试试水了。

简单架构#

大模型作为大脑下达命令，我会写一个程序用于大模型调用agent，命名为 center-header agent执行的上下文将由center协调，center会根据大模型的指令，调用不同的agent执行不同的任务。这分两种，分别是云端的cloud-body和本地的local-body（客户端）。

开整#

这一期我们只实现云端的部分，首先我需要实现这部分

e2b沙盒连接和使用
云端大模型和后端
前端代码展示及交互

一. e2b沙盒连接和使用#

Tip

如果后续想完全私有化的话，可以参考开源e2b方案的实现，但是这是后面的事情了

配置使用E2B沙盒首先登录到e2b官网https://e2b.dev/ 使用谷歌/github账号登录后，会看到一个沙盒列表，每个沙盒都有一个唯一的id。

e2b-1

点击团队下的账户设置可以看到我们的访问令牌

e2b-2

编写云端后端代码连接沙盒首先我们需要看下E2B文档https://e2b.dev/docs/quickstart 然后根据文档的介绍，我们可以看到，连接沙盒的代码非常简单，只需要几行代码即可。

Tip

这部分可以自由实现，我是使用Bun、TypeScript、Node来实现的。

使用TypeScript实现

1
// 安装依赖
2
npm i @e2b/code-interpreter dotenv

沙盒启动

index.ts

1
// 启动沙盒
2
import 'dotenv/config'
3
import { Sandbox } from '@e2b/code-interpreter'
4

5
const sbx = await Sandbox.create() /
6
const execution = await sbx.runCode('print("hello world")')
7
console.log(execution.logs)
8

9
const files = await sbx.files.list('/')
10
console.log(files)

执行代码

1
// 执行代码
2
// npx tsx ./index.ts
3
bun run ./index.ts

二. 云端大模型\后端\前端详细设计#

核心功能#

1 功能模块#

主控制台 (Console)：包含左右分栏布局。左侧为VNC桌面流媒体显示区域，右侧为Agent对话控制台。
Agent交互模块：用户输入指令，后台大模型结合屏幕截图进行推理，并调用E2B Desktop SDK执行相应的鼠标/键盘操作。

2. 核心流程#

用户在聊天框输入指令 -> 后端创建/获取E2B Desktop沙盒 -> 获取沙盒屏幕截图并发送给大模型 (如Claude/OpenAI) -> 大模型返回具体的UI交互动作 (坐标点击、键盘输入等) -> 后端通过E2B SDK执行动作 -> 循环直至任务完成。

graph TD A["用户输入指令"] --> B["前端发送请求到后端 API"] B --> C{"沙盒是否已创建?"} C -- 否 --> D["调用 @e2b/desktop 创建 Sandbox"] D --> E["启动 VNC Stream 并返回 Stream URL 给前端"] C -- 是 --> F["获取当前沙盒状态"] E --> F F --> G["循环: Agent获取屏幕截图"] G --> H["大模型(LLM)分析截图并决策动作"] H --> I{"任务是否完成?"} I -- 是 --> J["返回最终结果给用户"] I -- 否 --> K["执行具体动作(点击/输入等)"] K --> G

实现及优化#

效果展示

e2b-3

e2b-4

简单的实现大概就是这些。下一期我将带你实现指令操作沙盒，agent设计及协调，最终实现类似trae的solo功能。敬请期待

下一期

模型吞噬人类，社区主流思想的转变，从agent到harness，放开模型的手脚，疯狂的探索

Wed, 01 Apr 2026 00:00:00 GMT

今天刚好是4月1号愚人节，距离Claude Code 14个月，距离它客户端代码的泄露24小时。

最近AI主流思想已经逐渐确认一些事情，受此大事件的影响我不由自主的思考AI/agent/harness的未来。

Tip

足足51万行代码，通过完整严格的模块划分、通信统一，实现了超速迭代和高度的可扩展性。

或许最精彩的作品只出现在毁灭的前夜

这篇文章我将针对最近的一些思考进行整理和反思。

我们首先要搞懂一个事情什么是模型,什么是agent，长时间内定义模糊，而现在我们终于可以这样说。

模型就是 Agent

模型吞噬人类#

回到现在的视角，如果让我们给Agent（智能体）一个定义或者样例。我觉得可以理解为所有可以进行思考规划的个体。花草树虫鸟鱼，都是智能体。而人类则是一个最复杂的智能体。

所以智能体的目标本是实现和人类一样的思考模式。

我们现在认识到了，受限于人类的思考模型，这是狭隘的。

在一年以外的时候提示词工程是热门关键词。大模型对提示词的依赖性，导致了模型的思考模式被限制在了人类的思考模式。

在一年以内，dify/coze/xxflows 等项目都是通过固定编排以及人工硬编码来实现智能体的调度和协调。而这种过度工程化的、脆弱的过程式规则流水线，这只是一个有着宏大妄想的 shell 脚本，并不符合AGI的未来。

而现在cli工具的出现与发展，逐渐划分清楚了模型能力的边界与Agent到底是什么，claude code是其中的佼佼者。Claude Code 是我们所见过的最优雅、最完整的 agent harness 实现。不是因为某个巧妙的技巧，而是因为它没做的事：它没有试图成为 agent 本身。它没有强加僵化的工作流。它没有用精心设计的决策树去替模型做判断。它给模型提供了工具、知识、上下文管理和权限边界。

Tip

不要听信媒体/资本的鼓吹某项功能，从开始炒作提示词工程，到大吹流式编排再到吹智能体再到现在的龙虾。本质是急功近利的外化表现。这是错误的思维导致的。

我们应该具备动态思维与辩证思考的能力。

首先我们要有一个整体的概念。模型的动态发展与能力边界。模型的能力在我们当前的节点的话是个什么样子他的能力边界，以及突破能力边界的技术突破他的极限受限于什么因素

理解和思考完这些问题，我们便能明白，模型的发展是一个动态过程，而现在随着他的能力拓展，他的边界也逐渐清晰

如果用一句话总结即 模型Agent负责思考，harness负责服务于它。

社区主流思想的转变#

harness的出现

随着以claude code为先驱的cli工具的推进，我们逐渐理解了模型与工具。于是目前我们做出了如下的划分。

模型=agent，是可以思考的智能体

工具=harness，为agent提供工具，让agent接触世界

与之相对应的是工作会分为两种

训练模型。通过强化学习、微调、RLHF 或其他基于梯度的方法调整权重。收集任务过程数据 — 真实领域中感知、推理、行动的实际序列 — 用它们来塑造模型的行为。这是 DeepMind、OpenAI、腾讯 AI Lab、Anthropic 在做的事。这是最本义的 Agent 开发。
构建 Harness。编写代码，为模型提供一个可操作的环境。这是我们大多数人在做的事。

下图为Claude Code的harness。

Terminal window

1
Claude Code = 一个 agent loop
2
            + 工具 (bash, read, write, edit, glob, grep, browser...)
3
            + 按需 skill 加载
4
            + 上下文压缩
5
            + 子 agent 派生
6
            + 带依赖图的任务系统
7
            + 异步邮箱的团队协调
8
            + worktree 隔离的并行执行
9
            + 权限治理

放开模型的手脚，疯狂的探索#

模型会不会吞噬Harness

70%不会，因为Harness的成本移植到模型内部会太大，为了这部分收益会极大的扩展模型复杂度。

另外从工程的角度，将Agent和harness分离，可以极大的扩展模型的可扩展性。

从人类的角度来说，agent相当于人类，harness相当于工具，也更符合人类的思考模式。

从安全角度来说，模型限制在没手没脚的状态更令人安心

30%会，因为当所有模型不计成本的增加体积，会极大的扩展模型的现实能力。

模型将成为现实的底座。他可以自己实现我们现在实现的一切工具。

Tip

如果模型可以自己实现工具，那么模型就可以自己实现一切。或许这个时候，我们就可以叫他AGI了，这也是我认为人类的思考模型可能是狭隘的原因。

但是那些没有天赋的人呢?他们的人生从一开始就浪费了吗?

Fri, 13 Mar 2026 00:00:00 GMT

游戏《石河伦吾的朋友们 The friends of Ringo Ishikawa》

以下内容来源于游戏内容整理

“社会只是个逼迫所有人变得一样的大工厂，而真正的知识却在图书馆里花几百元就能买到。而另一些则花了一大笔钱才获得了同样的知识，还要在老师面前奴颜婢膝。为了什么呢，为了在将来成为什么巨大企业的薪奴吗?”

那么人生的意义又是什么呢？

有的时候，你在某些方面能比别人更胜一筹，于是大家都对你赞誉有加，你自然也会觉得很开心。

可是不知什么时候开始，逐渐逐渐地，这份优秀似乎就成了你理所应当、必须去完成的义务。而假如出于什么原因你没能达到大家的期望，那他们一转眼就不把你当回事了。

我从来没有在某个方面比别人更胜一筹过。这就是我想说的。顺着我刚说的理论，谁也不会在乎你的人生过得怎么样。不管从什么理论来说，都不会有人在乎你的人生。

我只是觉得，这个世界不应该是需要拼命争取才会有人来在乎你的。

因为人生不应该是什么比赛。我觉得一个人只要出生在这个世界上，就应该有所价值，应该有人会在乎才对。

有人说毕竟不是每个人都能成为冠军。也许，能够一心一意地把一件事贯彻始终本身就是一种不能后天学习到的特殊品质。如果没有这样的天分，那你终究也只能是个平凡的人，哪怕多多少少能分出一点优势。

人们说人生最大的悲剧之一就是天赋被白白浪费掉。

但是那些没有天赋的人呢？他们的人生从一开始就浪费了吗？

游戏截图

AI时代，你落后了吗，纠结良久最终我还是没有付费 not-by-ai 贴纸（待续）

Wed, 11 Mar 2026 00:00:00 GMT

最近抖音上火了很多“父辈错过改革开放”，我们就要错过了AI大潮，颇有一股童年射出的子弹射中了自己眉心的感觉。

且不说这里面有一些贩卖AI焦虑的恶意，身边的朋友纷纷没由来生出一股豪气，恨不得24小时去使用和学习AI，费劲吧啦的用了很久发现了，其实强的不是我们，而是AI。之后便是开始了自暴自弃，与其进步不如等现成的，最好再搞一点反AI的东西狠狠的吸睛。

经历了这一遭之后，今天想讲讲自己的反思和重构，凝聚你我的信念。

一、AI时代，你落后了吗#

将我们的视角拉到整个人类的视角上，将电力，硬件，人才，的整合可以视为算力，将时间视为第二个变量，算力和时间的乘积，这就是AI的燃料。从这个角度思考，现在整个地球热钱转向AI领域可能是最有利于未来的选择。

虽然现在这条路可能并不是真正通往AGI的道路，但是现在整个地球面临着资源过剩的问题，消耗过量资源才能让这个游戏继续下去，而AI的发展则是在消耗资源的同时，也在加速资源的消耗。区别于奴隶制，资本的好处就是这样，有机会他是真的砸钱。

二、别感冒#

别感冒

与AI热钱和营销相对应的现象是，AI培训班/AI讯息/AI投资/AI* 的全方面的对用户的轰炸

我们必须理解一件事情，所有热点新闻都有资本推动,这一点可以问问做公众号或者自媒体的人，流量和资本是不分家的

基于这一点我们在思考我们的机会在哪

我们将AI的回答视为一个六面体的骰子，他每次的回答实际上只会掷出可能性最高的那个，人类的意义可能在于永远有人去选择那个点数为1的面。

有人会认为---待续

另外一条路就是反AI

三、多吃饭#

正像我之前文章中写的，我认为最最重要的一件事

*** 每个人都要尝试一下训练一个AI ***

四、not by ai#

最后说回not by ai ，这一个贴纸，当你原创内容在90%以上时可以申请使用。之前了解，而且很多我喜欢的作者都在使用。

not by ai

对原创人员来说确实会增加很大的自豪感，这个贴纸的理念是。

但是不知道为啥我想到了日本仙人，这让我感到恐惧，因为我一直是科技党。没想到当AI开始取代我的工作的时候，我竟然想做原创仙人。果然铁拳打到自己头上才知道疼。

Tip

日本会将长时间手工制作的匠人称为仙人，例如煮饭仙人、天妇罗仙人等等。你可能觉得啊好高大上，有一种神秘的力量在里面。但是我必须让你怯魅，所谓的仙人，永远比不上现代科技，再好的煮饭仙人也不如电饭煲稳定。你要是信了仙人这一套的话，我只能建议你提前做好防止被宗教骗的准备。

这个很明显是我说的上面的两条路之一，走反AI的路子，如果你从这个项目获得利益，那我赞同，但是如果只是为了满足自己的情绪，我建议还是算了

在经过以上的心理斗争后最后我还是拒绝了为自己的原创增加贴纸，

当然不是因为他的收费是99刀

not by ai

消失的一个月，我做了什么（待续）

Wed, 04 Mar 2026 00:00:00 GMT

fresh2开发及快速入门（2）重构三国

Wed, 04 Mar 2026 00:00:00 GMT

终于到了令人激动的时刻。这一章我将带你使用全栈+Fresh+群岛架构+AI初步搭建开发一个好玩的游戏。

“从水下第一个生命的萌芽开始，到石器时代的巨型野兽，再到人类第一次直立行走，你已经历许多。现在，开启你伟大的探索吧：从早期文明的摇篮，到浩瀚星宇。” — 文明六

好玩的游戏一定是可以让人沉迷的。做游戏的第一步就是设计好这个游戏的规则和机制。

一、初步设计游戏规则#

大模型和故事存在着共通性，学会用信息论的角度去理解世界。故事的本质是信息的压缩与变换，如果我们将一本故事想象成一个信息系统，那么这本书就是信息的压缩包，而我们的阅读过程就是解压。而大语言模型则是信息的压缩，他将世界上的普遍真理压缩到模型中以实现AGI的愿景。

在以上理解的基础上，我们从最经典的三国下手，架构一个起伏变化的信息加解压缩的软件。

1. 游玩规划#

二、初始化项目#

项目结构介绍项目包含以下关键目录和文件：

1
rb3k-workspace/
2
├── assets/           # 静态资源（图片、CSS 等）
3
├── bin/              # 可执行文件目录
4
├── components/       # 可重用的 UI 组件
5
├── islands/          # 交互式组件（岛屿）
6
├── routes/           # 基于文件的路由
7
│  └── api/           # API 路由
8
├── static/           # 静态资源（图片、CSS 等）
9
├── .env.test/        # 环境变量配置文件（私有化运行需去掉.tset）
10
├── main.ts           # 应用入口文件
11
├── deno.json         # Deno 配置文件
12
└── README.md         # 项目文档

哪个大模型最好用--此刻我们正经历大模型厂商的战争

Thu, 29 Jan 2026 00:00:00 GMT

如果你搜索关键字看到的这篇文章，那说明你也从模型发展中嗅到了未来。

最近你会发现一个很明显的变化：不少国外的大模型开始“免费”给你生成代码，而且还支持把生成结果一键上传到 GitHub。表面上是福利，背后其实是一种很典型的逻辑：数据越多 → 模型越好用 → 更多人来用 → 数据更多。

这里面有个关键点可以用一句话概括：选择即投票。

1. “选择即投票”：你用不用，就是在给它打分#

当你让 AI 写一段代码，你接下来会做三件事之一：

直接用它，并提交到仓库：相当于投了“赞成票”
改一改再提交：相当于给了“更好的参考答案”
不用这段：相当于投了“反对票”

这和谷歌的人机验证很像：让你去选“红绿灯/斑马线”那几张图。你以为是在证明自己是人，但你点的那些选择，本身也会反过来帮助系统变得更聪明。

放到写代码这件事上也是一样：当大量人把 AI 生成的代码改完、用上、提交到 GitHub，本质上就是在用真实场景做“筛选”和“标注”。

2. 用 GitHub 占比看“模型实力”：50% 可能会出现“默认模型”#

如果按“选择即投票”的思路继续推，一个挺直观的指标就是：某个模型生成的代码，在 GitHub 全部新增代码里占了多大比例。

比例越高，说明两件事：

它被更多人用在真实项目里（入口更强）
它能拿到更多“被人类选择过”的反馈（训练更有优势）

而当这个比例接近、甚至超过 50% 的时候，事情就会变得很不一样：大家会越来越习惯某种写法、某些库、某些组织方式。久而久之，它就可能变成一种“默认的写代码方式”，也就是你说的默认模型——不是官方宣布的，而是被大量使用“自然推出来”的。

3. 为什么谷歌免费 Gemini 并支持一键上传 GitHub 很高明#

再回头看谷歌的策略（比如 Gemini 免费、并且支持一键上传 GitHub），就很好理解了。

GitHub 是微软的地盘，但“代码从哪里来”更关键：如果越来越多代码是由 Gemini 生成、被人类挑选后提交上去，那么谷歌其实是在一个全球最大的代码池里，持续地制造“对自己有利的投票”和反馈。

所以这不仅是“免费竞争”，更像是在抢一个长期位置：谁能更早、更大规模地进入开发者工作流，谁就更可能在未来拿到更多真实数据，进而把模型越滚越强。

4. 一个不太舒服但绕不过去的结论#

我们在享受免费工具的时候，也在用自己的选择帮它变强：你每一次复制粘贴、每一次修改、每一次提交，都会变成它学习的一部分。

从这个角度看，谷歌的一键上传策略，本质上是一场关于“未来代码基因”的争夺：当 AI 生成的代码在 GitHub 上占据主导地位时，谁的模型是那个“最大贡献者”，谁就掌握了未来软件世界的底层规则。

全栈框架分析及AI时代选型

Wed, 21 Jan 2026 00:00:00 GMT

过去十年“全栈框架”的讨论更多围绕：渲染方案、路由、数据获取、缓存、部署与开发体验。进入 AI 时代之后，评估维度变了：你不仅要把页面做出来，还要把一个带推理与工具调用的系统接进产品——它要流式输出、要能调用数据库/搜索/业务 API、要能回放与审计、要能灰度与回滚、要能控成本与控延迟。

这篇文章用一个更工程化的视角，把“什么框架能做全栈”与“什么框架更适合 AI 编程”拆开来讲：前者看能力边界，后者看结构化与可维护性。

1. 先定义：AI 时代的“全栈”到底多了什么#

如果把传统 Web 应用的闭环写成「请求 → 读写数据 → 渲染 → 交互 → 再请求」，AI 时代新增的关键链路是：

流式与增量 UI：聊天、Copilot、生成式表单等，需要边生成边渲染，且可中断、可续写。
工具调用与编排：模型不只“回答”，而是要调用搜索、数据库、第三方 API、队列任务，然后再整合结果。
数据治理与评测：提示词版本、输出结构校验、A/B 测试、离线回放、敏感信息与权限边界。
推理运行时多样化：同一应用可能同时用到 Node、Edge runtime、Worker、后台任务、甚至 GPU 推理服务。

因此，“AI 友好”的全栈框架通常具备这些工程特征：约定强、边界清晰、类型可贯通、可插拔的运行时与部署路径、以及成熟的生态（鉴权/数据库/缓存/队列/观测）。

2. 评估维度：什么叫“AI 编程适合度”#

这里的“适合度”不是在比谁更潮，而是在比：当你把需求交给 AI（或让 AI 参与编码）时，代码能否更稳定地被生成、被重构、被测试、被上线。

我用 6 个维度来评分（1–5 分，越高越适合 AI 协作开发）：

可预测的项目结构：路由、数据加载、Action、组件边界清晰，AI 生成不容易“发散”。
端到端类型与 schema 驱动：请求/响应/数据库模型能对齐，减少“靠猜”的胶水代码。
服务端能力一等公民：SSR/Actions/后台任务/队列等是框架内置而不是外挂拼装。
可观测与可测试：可复现、可回放、可做契约测试与 E2E，避免“能跑就行”。
部署路径清晰：本地与生产一致性好；Edge/Server 的差异可被框架约束。
AI 生态与样例成熟：已有成熟的 AI SDK、流式 UI、工具调用范式与参考实现。

3. 全栈框架全景对比表（尽可能覆盖主流生态）#

说明：

“全栈框架”在不同语言里含义不同：有的强调“前后端一体”（元框架），有的强调“后端 + 模板/组件渲染”，也有一类是“平台型全栈”（BaaS/内容系统自带 UI + API）。
表格覆盖各主流语言生态里仍活跃、可用于生产的全栈框架/元框架，并额外纳入一批常被用于全栈交付的选择。

分类	框架	主语言	前端/渲染模型	后端/数据能力	部署形态（常见）	AI 适合度	典型适用场景
TS 元框架	Next.js	TS/JS	SSR/SSG/RSC/Server Actions	Route Handlers、Server Actions、Middleware	Node/Vercel/Serverless/部分 Edge	5	产品型 Web、AI App、BFF 一体化
TS 元框架	Remix	TS/JS	SSR 优先（loader/action）	表单与 Action 一体、Web 标准倾向	Node/Serverless	5	表单密集、数据驱动、稳定迭代
TS 元框架	SvelteKit	TS/JS	SSR/SSG（Svelte）	端点 + Actions、适配器生态	Node/Edge/Serverless	4	中小型产品、性能与 DX 平衡
TS 元框架	Nuxt 3	TS/JS	SSR/SSG（Vue）	Nitro Server、server routes	Node/Edge/Serverless	4	Vue 生态、全栈内容与应用
TS 元框架	Angular（SSR）	TS	SSR/SSG（Angular）	SSR 服务端 + API（需组合）	Node/Serverless	3	大型企业前端、强规范团队
TS 元框架	Astro（SSR）	TS/JS	内容优先 + Islands/SSR	端点/中间件（需按项目组织）	Node/Serverless	3	内容站 + 轻交互/轻后端
TS 元框架	Gatsby	TS/JS	SSG + Functions	Functions（需组合数据层）	Serverless/托管	2	营销站/内容站 + 轻后端
TS 元框架	Qwik City	TS/JS	SSR/Resumability	端点 + Actions	Edge/Serverless	3	极致首屏、边缘分发
TS 元框架	SolidStart	TS/JS	SSR（Solid）	路由/数据加载/Actions	Node/Serverless	3	偏前沿团队、追求轻量响应
TS 元框架	TanStack Start	TS/JS	SSR（Router + Query）	约定式全栈路由（新）	Node/Serverless	3	已重度 TanStack 生态的团队
TS 全栈框架	RedwoodJS	TS/JS	React SPA/SSR（演进中）	GraphQL API、Prisma、Jobs	Serverless/Node	3	业务后台、CRUD + 权限模型
TS 全栈框架	Blitz.js	TS/JS	Next.js 之上（RPC）	端到端类型 RPC	Node	3	快速交付、重视类型贯通
TS 全栈框架	Wasp	TS/JS	React/Vue（脚手架）	全栈模板化、Auth/CRUD	Node/云部署	3	SaaS 快速落地、约定化全栈
TS 全栈框架	Meteor	JS	同构渲染（传统）	实时数据/订阅	Node	2	需要强实时但能接受框架约束
TS 后端+视图	AdonisJS	TS	模板/视图（Edge）	MVC、ORM、队列、鉴权	Node	3	Node 后端团队想要“Rails 式”
TS 后端+视图	NestJS（+模板）	TS	模板/SSR（需组合）	DI、模块化、微服务	Node	3	大型后端、服务治理优先
JS 全栈（传统）	Sails.js	JS	SSR（视图）	MVC、ORM、约定式	Node	2	传统全栈、快速 CRUD
Web 标准后端	Hono（+前端）	TS/JS	需组合（常配 React/Vue）	Web 标准路由、中间件	Edge/Node	3	Edge API、轻量 BFF、AI 网关
Bun 生态	Elysia（+前端）	TS	需组合	轻量高性能后端	Bun/Node（部分）	2	性能实验、偏后端 API
Deno 全栈	Fresh	TS	SSR（Islands）	Deno 原生路由与中间件	Deno Deploy/Server	3	Deno 团队、轻量全栈
Ruby 全栈	Ruby on Rails	Ruby	SSR（ERB/Hotwire）	ActiveRecord、Jobs、ActionCable	VM/容器	4	业务系统、AI 能力快速集成
Ruby 全栈	Hanami	Ruby	SSR	框架更轻、更显式	VM/容器	3	喜欢更可控的 Ruby 架构
PHP 全栈	Laravel	PHP	SSR（Blade/Inertia）	Eloquent、队列、事件、生态强	VM/容器/Serverless	4	中小企业应用、CRUD/后台
PHP 全栈	Symfony	PHP	SSR（Twig）	组件化成熟、可组合	VM/容器	3	中大型 PHP 项目、长期维护
PHP 全栈	Yii	PHP	SSR	MVC、ORM、成熟生态	VM/容器	3	传统业务系统
PHP 全栈	CakePHP	PHP	SSR	约定式 MVC	VM/容器	2	中小项目、快速交付
PHP 全栈	CodeIgniter	PHP	SSR	轻量 MVC	VM/容器	2	轻量传统站点
Python 全栈	Django	Python	SSR（模板）	ORM、Admin、Auth、Jobs（组合）	VM/容器	4	业务后台、内容管理、AI 结合
Python 全栈	FastAPI（+模板）	Python	SSR（需组合）	API 优先、类型注解	VM/容器	3	API + 前端分离、AI 服务
Python 全栈	Flask（+模板）	Python	SSR（需组合）	轻量后端、可组合	VM/容器	2	小型应用、偏 API/工具
Python 全栈	Pyramid	Python	SSR（模板）	更传统、更显式	VM/容器	2	传统企业 Python Web
Elixir 全栈	Phoenix LiveView	Elixir	SSR + LiveView（状态同步）	OTP、Channel、强实时	VM/容器	4	实时协作、仪表盘、Agent UI
Java 全栈	Spring Boot（MVC）	Java	SSR（Thymeleaf 等）	生态巨大、治理成熟	容器/VM	3	大型企业、合规与治理
Java 全栈	Quarkus（+模板）	Java	SSR（Qute 等）	云原生、轻量	容器/VM	2	云原生 Java、微服务到全栈
Java 全栈	Micronaut（+模板）	Java	SSR（需组合）	轻量、AOT 倾向	容器/VM	2	云原生 Java
Java 全栈	Vaadin	Java	服务器驱动 UI	UI 与后端同一语言	容器/VM	2	内部系统、强表单/数据录入
.NET 全栈	ASP.NET Core（MVC）	C#	SSR（Razor）	Identity、EF Core、后台任务	容器/VM	4	企业应用、微软生态
.NET 全栈	Blazor	C#	SSR/WA（同构）	UI 与后端一体	容器/VM	3	.NET 团队、全栈同语言
.NET 全栈	ABP Framework	C#	SSR/SPA（可选）	模块化企业框架、DDD 倾向	容器/VM	3	企业级后台、快速搭骨架
Go 全栈	Buffalo	Go	SSR（模板）	Rails 风格、生产可用	容器/VM	2	Go 团队做传统全栈
Go 全栈	Beego	Go	SSR/API	MVC、ORM（可选）	容器/VM	2	传统 Go Web
Go 全栈	Revel	Go	SSR	传统 MVC	容器/VM	1	历史项目维护
Rust 全栈	Leptos	Rust	SSR（WASM/SSR）	全栈 Rust（偏前沿）	容器/VM	2	性能/安全、愿意投入学习曲线
Rust 全栈	Axum + 模板/前端	Rust	需组合	API 强、需自行装配全栈能力	容器/VM	2	高性能 API + 自定义前端
Rust 全栈	Rocket（+模板）	Rust	SSR（模板）	传统后端框架	容器/VM	1	小型项目/学习
Scala 全栈	Play Framework	Scala/Java	SSR	JVM 生态、传统全栈	容器/VM	2	JVM 团队、Scala 全栈
CMS 全栈	Payload	TS/JS	Admin UI + API	内容建模、Auth、DB	Node/Serverless	4	内容驱动产品、AI 内容工作流
CMS 全栈	Strapi	Node/TS	Admin UI + API	插件化 CMS、RBAC	Node/容器	3	Headless CMS、内容中台
CMS 全栈	Keystone	TS/JS	Admin UI + GraphQL	Schema 驱动、可扩展	Node	3	可定制内容系统
平台型全栈	Supabase	平台	前端任意	Postgres + Auth + Storage + Edge Functions	托管/自建	4	快速做 AI 产品、RAG 数据层
平台型全栈	Firebase	平台	前端任意	Auth/DB/Functions/Storage	托管	3	移动端/轻后端、原型到中型
平台型全栈	Appwrite	平台	前端任意	Auth/DB/Functions/Storage	托管/自建	3	需要自建 BaaS 的团队
平台型全栈	PocketBase	Go（单体）	前端任意	单文件数据库 + Auth + API	单机/小型	2	小团队、快速交付、低成本

‹ ›

可左右滑动

3.1 读表指南：分数为什么会拉开#

同一个“全栈”，在 AI 场景下表现差异很大，原因通常不在性能，而在工程边界：

5 分档（更推荐做 AI 产品主干）：元框架内置了稳定的读写数据语义（loader/action、actions、handlers），流式 UI 与工具调用范式成熟，AI 更容易写出“可维护”的结果。
3–4 分档（稳健但要立规矩）：能力够用，但你需要把鉴权、数据访问、任务队列、错误处理固化成团队约定，否则 AI 写出来会出现多套风格并存。
1–2 分档（能做但不建议作为默认）：全栈能力更多依赖你自己装配；AI 协作时更容易产生隐性耦合与不可回放的实现。

4. 为什么有的框架更“适合 AI 编程”#

把 AI 当作“会写代码的同事”时，你会发现它最怕两类项目：

结构不稳定：同一个需求在不同模块里有不同写法，或者靠大量自定义约定才能跑起来。
隐式魔法太多：运行时行为难以从代码直观看出来，AI 很难在重构时不踩坑。

反过来，更 AI 友好的框架往往具备这些共同点：

强约定 + 少选择题：文件路由、数据加载、表单提交、错误边界有固定入口，AI 不容易“写偏”。
类型/Schema 是事实来源：DB schema、API contract、工具调用参数等可以被校验与生成。
服务端边界明确：哪些代码跑在 Server/Edge/Client，一眼就能看出，避免把密钥带进浏览器。

以 TypeScript 生态为例，Vercel 的 AI SDK 明确提供了面向 React/Next.js 等框架的流式 UI 与工具调用抽象，降低“自己拼 streaming + tool calling”的手工成本。¹

同时，Edge/Worker 侧的推理与 embedding 能力越来越标准化，例如 Cloudflare Workers AI 提供了“在边缘调用模型”的路径，让你能把部分推理或向量化靠近用户，改善延迟与成本结构。²

5. 重点框架解读（按“全栈形态”分组）#

下面不按“谁更强”排序，而是按“你会怎么把它用在 AI 产品里”来讲。

5.1 元框架：前后端一体的产品交付线#

Next.js#

全栈方式：路由 + Server Actions/Route Handlers + SSR/RSC，前后端在同一仓库内闭环。
AI 友好点：结构强约定、流式 UI 生态成熟、TS 贯通更容易收敛到稳定形态。¹
注意点：RSC/缓存/运行时组合非常强大，也更复杂；团队需要建立统一的目录与数据获取规范。

Remix#

全栈方式：loader/action 把“读数据”和“写数据”固定在同一套路由语义下，偏 Web 标准。
AI 友好点：模型更易理解（表单提交就是 action），代码生成更不容易跑偏；错误边界也更直观。
注意点：生态相对 Next.js 小一些，但在“表单密集 + 可维护”上很稳。

Nuxt 3 / SvelteKit#

全栈方式：SSR/SSG + 服务端路由/Actions（或 endpoints），与各自前端框架深度绑定。
AI 友好点：约定明确、样板少；对中小团队尤为友好。
注意点：团队要尽早决定数据层（ORM/Query）与鉴权方案，避免后期多套并存。

5.2 后端 + 视图：以“服务端为中心”的全栈#

Ruby on Rails#

全栈方式：MVC + ORM + Jobs + WebSocket（ActionCable），默认就能把业务做完整闭环。
AI 友好点：约定优于配置做到极致，AI 生成 CRUD、后台、任务队列代码的成功率很高；把 AI 任务放在后台 Job 也很自然。
注意点：前端体验取决于你选择 Hotwire 还是前后端分离；团队如果已经是 TS 主栈，需要权衡语言栈分裂成本。

Laravel / Django / ASP.NET Core#

共同优势：成熟的鉴权、ORM、后台管理与生态，让你可以把精力更多放在 AI 能力本身（检索、工具、评测、成本）。
AI 友好点：约定稳定、框架年代久、资料多，LLM“见过的代码”更多，生成更稳。
注意点：如果你追求高度交互的前端体验，通常会走“后端提供 API + 前端元框架”的组合式全栈。

5.3 内容系统/平台型全栈：把“数据层 + 管理 UI”当成默认能力#

Payload / Strapi / Keystone#

全栈方式：内置内容模型、权限与管理后台，前端可以是 Next/Nuxt 等。
AI 友好点：内容结构天然 schema 化，非常适合做 RAG 的知识源、内容工作流与审核流程。
注意点：内容系统不是通用业务框架；复杂交易/强一致业务仍需要严肃的后端域模型。

Supabase / Firebase（平台）#

全栈方式：把 Auth、存储、数据库、函数、实时订阅做成平台能力，前端“拿来即用”。
AI 友好点：快速出 MVP；对 RAG 来说，Postgres/向量扩展、权限与存储这些“脏活累活”平台已经处理掉很多。
注意点：别把平台当魔法；多租户、合规、审计、成本可控仍然需要你在应用层建立规范。

5.4 表格里其余框架逐条解释（速览）#

下面这些框架同样能用于全栈交付，但更依赖你对“边界与约束”的工程化落地；我把它们按用途给出更直接的定位。

TS 元框架与前端绑定全栈#

Angular（SSR）：适合强规范的大型团队；AI 协作时更建议把数据访问与状态管理固化成统一范式，否则生成代码容易出现多套风格。
Astro（SSR）：内容/性能优先，适合作为内容站或文档站的“轻全栈”；AI 生成时要明确哪些页面需要 SSR、哪些是静态，否则很容易被“过度服务端化”。
Gatsby：偏 SSG + Functions 的组合；适合内容站叠加轻后端能力；AI 编程适合度较低主要是因为“全栈路径不唯一”，需要你明确边界。
Qwik City：主打 Resumability；适合极致首屏与边缘分发，但团队需要较强的心智统一，才能让 AI 写出的代码保持一致性。
SolidStart：偏轻量 SSR；如果团队对 Solid 生态熟悉，体验很好，否则学习成本会传导到 AI 协作质量上。
TanStack Start：适合已经重度依赖 TanStack Router/Query 的团队；整体偏新，建议先把“目录结构 + 数据访问规范 + 边界约束”写成模板再让 AI 扩展。

Node/JS 传统全栈与后端框架#

RedwoodJS：偏“全栈应用框架/脚手架”，常见组合是 GraphQL + Prisma + Jobs；适合业务后台与标准化 CRUD，但要避免把业务全塞进 GraphQL resolver，建议形成清晰的 service 层。
Blitz.js：在 Next.js 上提供 RPC 形态的端到端类型；适合快速交付与减少样板；AI 协作时建议强制所有 mutation 走统一校验与权限中间层。
Wasp：把常见 SaaS 能力模板化（鉴权、CRUD 等），适合快速起步；AI 协作优势来自“更少的自由度”，但复杂场景可能需要下沉自定义。
Meteor：同构与实时能力强，适合快速做原型；但现代部署与模块化实践上需要你额外补齐工程规范。
AdonisJS：Node 生态里偏“Rails 路线”的全栈框架，MVC/ORM/队列/鉴权齐全；AI 生成 CRUD 与后台任务的成功率通常较高。
NestJS（+模板）：更像后端应用框架；做全栈通常要叠加模板或前端元框架；AI 协作优势来自强模块化，但你需要明确“Controller/Service/Module”的边界与命名约定。
Sails.js：传统 MVC 与约定式结构，适合快速交付；但生态相对老，现代前端/AI 需求往往需要额外拼装。
Hono（+前端）：更像“跨运行时的 Web 标准后端”；用它做全栈时通常承担 BFF/AI 网关角色（鉴权、限流、工具调用代理），前端仍交给元框架。
Elysia（+前端）：偏后端性能框架；用在全栈里更像 API 层；AI 协作风险在于“形态选择太自由”，最好配合 OpenAPI/Schema 来锁定契约。

Deno 全栈#

Fresh：SSR + Islands 的 Deno 全栈；适合追求轻量与边缘部署，但生态与资料密度不如 Node 主流，AI 生成质量会受影响。

Ruby/PHP/Python 的补充全栈#

Hanami：比 Rails 更轻、更显式，适合重视架构可控的 Ruby 团队；AI 协作关键是把应用层约定固定下来（如 service object、repository 模式）。
Symfony：更偏“组件化的企业 PHP”；AI 协作时建议强化模块边界与依赖注入配置，否则生成的代码容易跨层耦合。
Yii / CakePHP / CodeIgniter：传统 MVC 路线；能做全栈交付，但现代 AI 需求（流式、工具编排、观测）大多需要你自己建立标准化模块。
FastAPI（+模板）：更适合 API 优先；全栈形态通常是“FastAPI 做后端 + 前端元框架做 UI”；AI 协作优势在于 Python 类型注解与 pydantic schema。
Flask（+模板）/ Pyramid：轻量与传统路线；更适合小型应用或历史项目；AI 协作时尤其需要你把目录结构、蓝图/路由组织、配置分层固化。

Elixir 实时全栈#

Phoenix LiveView：本质是“服务器驱动 UI + 实时状态同步”；适合 Agent UI、运维控制台、协作场景；AI 协作的关键是把事件与状态机设计清晰。

JVM 与 .NET 企业全栈扩展#

Quarkus（+模板）/ Micronaut（+模板）：云原生 JVM 框架，做全栈需要组合模板或前端；AI 协作更依赖你把 DTO、验证、鉴权与日志规范化。
Vaadin：服务器驱动 UI，适合内部系统；但 UI 范式与 Web 主流不同，AI 协作时需要更多明确的组件/表单规范。
Blazor：.NET 全栈同语言的方案；适合既有 C# 团队；AI 协作优势是类型系统贯通，但前端生态与主流 JS 有差异。
ABP Framework：企业级模块化框架，适合快速搭管理后台与 DDD 风格骨架；AI 协作的重点是遵循它的模块与分层约定。

Go/Rust/Scala 全栈#

Buffalo / Beego / Revel：Go 的传统全栈选择；多数团队会把它们用作“后端 + 模板”而非复杂前端；AI 协作建议用 OpenAPI/模板化目录来控制发散。
Leptos / Axum + 模板 / Rocket：Rust 全栈可行但偏前沿；优势是性能与安全；AI 协作难点是生态碎片化与学习曲线，适合愿意投入的团队。
Play Framework：JVM 传统全栈框架；适合 Scala/JVM 团队；AI 协作依赖规范化的路由、DTO、模板与服务分层。

CMS 与平台型补充#

Payload / Strapi / Keystone：适合把内容结构化后接 AI 工作流（检索、摘要、审核）；关键在于把内容模型当成“契约”，并把权限与审计做严。
Appwrite / PocketBase：偏快速交付与低成本；适合原型或小型项目；AI 场景下要特别注意权限边界、速率限制与数据泄露风险。

6. 从“AI 编程适合度”出发的选型结论（可直接抄作决策）#

把问题换一种问法：为了让 AI 协作开发更可靠，你需要的是“更强的约束”而不是“更多的自由”。

6.1 默认推荐（按团队主栈）#

TS/React 团队做 AI 产品：优先 Next.js 或 Remix；再结合 schema 驱动的数据层（如 Prisma/Drizzle）与严格的 API/工具调用契约。
Vue 团队做全栈：Nuxt 3 是最短路径；把 server routes/鉴权/数据访问集中到固定目录与固定模式。
后端强、前端一般：Rails/Laravel/Django/ASP.NET Core 可以直接交付完整产品；前端若需要更强交互，再叠加一个元框架做 BFF。
强实时/协作型产品：Phoenix LiveView 值得优先评估；在实时状态同步方面，它往往比“前端 + WebSocket 胶水”更可控。

6.2 你真正需要做的“AI 友好工程化”#

无论选什么框架，想让 AI 写得稳、你改得动，最终都要回到这些硬约束：

把契约写成代码：DB schema、OpenAPI/JSON Schema、工具参数 schema，能校验就不要靠约定。
把边界写进目录结构：server/edge/client 分层明确；密钥与权限在 server 侧可验证。
把推理做成“可回放的任务”：每次提示词、工具调用、输出都可追踪；失败可重试；成本可统计。
把 UI 做成“可组合原语”：组件库、设计 tokens、表单与验证规则固定，AI 才能稳定地产出一致 UI。

7. 参考与延伸阅读#

Footnotes#

AI SDK by Vercel. https://ai-sdk.dev/docs/introduction ↩ ↩²
Cloudflare Workers AI. https://workers.cloudflare.com/product/workers-ai/ ↩

fresh2开发及快速入门（1）

Wed, 21 Jan 2026 00:00:00 GMT

之所以最先使用Fresh 2.0，完全是个人品味问题，我一直想要使用vite的HMR和esm但是又不想用vue，vite的理念是先进并且适合 AI的，但是vue的话就差点意思了。之前的Fresh一直绑定在preact上，最近终于可以使用vite的生态了，可喜可贺，手痒必须要试试。另外，必须要说明的是Fresh 2.0是一个实验性项目，目前还不是正式版本，所以在使用过程中可能会遇到一些问题，但是瑕不掩瑜，Fresh 2.0的理念和架构确实是很有价值的。

群岛架构
vite生态
全栈

满足以上需求的目前也只有Fresh 2.0，我们可以把它现在看做Astro的全栈加强版，所以如果你也想探索一下最适合AI时代的全栈框架，一定要试一下Fresh 2.0

fresh2 启动！#

首先我们需要安装deno

Mac, Linux

Terminal window

1
curl -fsSL https://deno.land/install.sh | sh

windows PowerShell

Terminal window

1
iwr https://deno.land/install.ps1 -useb | iex

更多安装方式可以查看 deno_install

deno也有别人开发的版本管理工具类似nvm的dvm，可以按需安装。

Terminal window

1
npm i @axetroy/dvm

当安装完成后，可以使用deno run 来运行ts,可以运行官方样例，也可以自己写一个

示例代码（点击展开）

hello.ts展开收起

1
import { serve } from "https://deno.land/std@0.208.0/http/server.ts";
2

3
const handler = async (req: Request): Promise<Response> => {
4
  const html = `
5
    <!DOCTYPE html>
6
    <html lang="zh-CN">
7
    <head>
8
      <meta charset="UTF-8">
9
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
10
      <title>欢迎</title>
11
      <style>
12
        body {
13
          font-family: Arial, sans-serif;
14
          display: flex;
15
          justify-content: center;
16
          align-items: center;
17
          height: 100vh;
18
          margin: 0;
19
          background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
20
        }
21
        .welcome-container {
22
          text-align: center;
23
          color: white;
24
          padding: 40px;
25
          border-radius: 10px;
26
          background: rgba(255, 255, 255, 0.1);
27
          backdrop-filter: blur(10px);
28
          box-shadow: 0 8px 32px rgba(0, 0, 0, 0.1);
29
        }
30
        h1 {
31
          font-size: 48px;
32
          margin-bottom: 20px;
33
        }
34
        p {
35
          font-size: 18px;
36
          margin: 10px 0;
37
        }
38
      </style>
39
    </head>
40
    <body>
41
      <div class="welcome-container">
42
        <h1>欢迎！</h1>
43
        <p>这是一个使用 Deno 运行的 TypeScript 页面</p>
44
        <p>当前时间: ${new Date().toLocaleString('zh-CN')}</p>
45
      </div>
46
    </body>
47
    </html>
48
  `;
49

50
  return new Response(html, {
51
    status: 200,
52
    headers: {
53
      "content-type": "text/html; charset=utf-8",
54
    },
55
  });
56
};
57

58
console.log("服务器运行在 http://localhost:8000");
59
await serve(handler, { port: 8000 });

展开收起

Terminal window

1
deno hello.ts

deno 启动！

至此基础的环境ok了，下一步我们需要安装fresh 2.0

Terminal window

1
deno run -Ar jsr:@fresh/init

fresh 2.0 初始化

太棒了，没想到，这个下载的就是vite版的fresh 2.0的环境，下一步我们可以开始开发了。

Terminal window

1
deno run dev

fresh 2.0 启动

当前的初步已经ok了，如果你对细节还有疑问可以在留言。下一章我将带你使用全栈+Fresh+群岛架构+AI开发一个好玩的游戏。

为什么AI写网页代码的效果这么好

Thu, 15 Jan 2026 00:00:00 GMT

很多人把“AI 写网页代码很顺手”归因于模型更聪明了。但从一线工程视角看，更关键的原因是：前端天然具备高开放性、强规范化、强复用三件事，它们共同把问题空间压缩成了“可预测的组合题”。在这种题型里，大模型的优势会被放大。

这篇文章把现象拆开讲清楚：为什么前端更像大模型的“主场”，以及这种优势来自哪里、边界又在哪里。

1. 前端的开放性，把训练数据推到极大#

前端是最公开的工程领域之一：页面代码天然要交付到浏览器；生态以 npm 为中心扩散；大量实践以博客、Issue、文档、开源仓库的形式沉淀。结果是，前端的高频知识几乎都能在公开语料里被反复看到。

更重要的不是“量大”，而是分布稳定：

HTML/CSS/JS 是 Web 的共同语言，语法和运行语义相对稳定，十年前的很多知识今天仍然有效。
组件、路由、状态、请求、表单、列表、布局这些“业务高频件”，在行业里高度同构，差异主要来自命名与样式。
工程化把离散经验收敛成少量工具链约定：构建（Vite/webpack）、类型（TypeScript）、质量（lint/format）、样式方案（Tailwind/CSS Modules/CSS-in-JS）等，最终都表现为可被模板化的结构。

当一个领域同时满足“公开、稳定、同构”时，模型得到的不只是训练样本多，而是可重复的模式多。代码生成看起来像“凭空写”，实际更接近“在巨大的模式库里做匹配，然后把匹配结果按约束拼起来”。

2. 前端代码的本质：受约束的声明式结构#

网页代码的产物，是“可运行的界面”。界面由两部分构成：

结构与语义（HTML/组件树）
样式与布局（CSS/设计系统）

声明式的“组合题”：输入约束 → 产出结构与样式 → 浏览器渲染输入需求 / 交互目标页面要展示什么、怎么用约束组件库 / 设计系统 / 类型可用原语与风格边界结构组件树（HTML/JSX）语义、层级、复用边界样式规则（CSS / tokens）布局、间距、主题与状态输出浏览器渲染 DOM + CSSOM → layout/paint 可交互界面事件、状态更新、重绘越强的约束（设计系统/组件库/工程规范），越像“拼装”，越适合规模化生成。

这两部分都强依赖声明式，而声明式的一个特征是：局部变动往往只影响局部输出。例如，增加一个表格列、把表单校验规则改严、把卡片从两列变三列，这些都属于结构化变更，能在组件边界内被限定。

这会直接降低生成难度：模型不需要“发明新算法”，更多时候只要把常见 UI 模式落到当前工程的约束里（组件库、样式规范、数据结构、类型约束）。换句话说，前端更像一个大型的“组合系统”，而不是一个需要大量原创推理的“求解系统”。

3. 单一默认值让输出更可预测#

前端并不缺框架；但工程实践的默认选项长期高度集中。一个明显的结果是：当你说“写一个后台管理系统/电商详情页/内容站点”，多数团队脑海里会浮现出近似的技术栈组合与目录结构。

这种集中带来的收益是“可预测”，代价是“创新被压住”。但就代码生成而言，可预测恰恰是优势：模型在生成时，最怕的是缺乏共识的分歧点；最擅长的是有共同模板的主流写法。

React 的长期主导地位，把大量工程实践收敛成了统一叙事：组件化、JSX、Hooks、状态与副作用的组织方式、围绕 React 的路由与数据层（再加上 Next.js 这类元框架）……这让模型面对“前端需求描述”时，能更快落到一种稳定的实现形态上。

但这也解释了一个常见体验：同一个需求下，模型在 React 生态里输出“像样代码”的概率，往往高于在一些更分散、约束更弱的技术组合里输出的概率。并不是因为 React 更“正确”，而是因为它更“标准”。

想把这种“标准化带来的副作用”讲透，可以读这篇文章：

React 的默认胜利正在扼杀前端创新（译）

它的核心观点可以浓缩成三句（与本文的主题互相补全）：

React 的优势正在从“技术优势”转向“默认优势”，网络效应替代了适配度，决定架构走向。
生态默认值越强，新模型（编译期、细粒度响应式、可恢复性）越难得到公平评估，创新变成“有但用不上”。
当行业把心智模型中心搬到单一框架之上，成本不仅是性能，还有学习与迁移能力的机会成本。

4. 大模型天然站在 UI 层的上方#

前端的难点并不只在代码，更在“把需求变成界面”。而 UI 层有一个工程事实：它离业务更近、离算法更远，离“表达”更近、离“求解”更远。

这对应了大模型的强项：把模糊输入映射到结构化输出，世界模型的到来使所有抽象层将在更高的维度被模型所理解。

在现代团队里，UI 并不只是像素拼图，而是一个层次化系统：

设计语言（排版、色彩、间距、动效）
组件库（Button/Input/Table/Modal）
交互范式（表单流、列表流、详情流、搜索筛选）
信息架构（导航、层级、状态）

这些东西一旦被抽象为组件与设计 token，代码生成就变成了：把信息架构映射为组件树，把状态与数据流映射为事件与请求，把视觉规则映射为样式约束。它不依赖“灵感”，更依赖“约束下的映射”，因此更容易规模化。

5. 视觉能力的进步，正在外溢到 UI 之外#

近两年的变化不只是“能写更多代码”，而是模型逐步具备了对界面与布局的理解能力：识别层级、对齐关系、间距语义、组件复用、交互状态。这类能力来自多模态训练：把文本、图像、结构化 UI 元数据放在同一个表征空间里学习。

一旦模型能稳定理解 UI，它就获得了一种更通用的能力：把连续世界（图像/空间）压缩成离散结构（层级/约束/关系）。这类表征不仅对“从设计到代码”有用，也会迁移到更广泛的物理世界任务中：场景理解、机器人操作、空间推理、视觉-语言对齐等。

从这个角度看，前端并不是一个孤立的应用场景，而像一个训练场：UI 把现实世界的空间关系（对齐、约束、层级、组合）用更可控的方式呈现出来，既足够复杂，又比真实世界更可标注、更可评估、更易规模化。这会让模型在 UI 上的进步更快，也更容易外溢到 UI 之外。

6. 边界：能写出“像样代码”不等于能交付#

把原因讲清楚，也必须把边界讲清楚。前端代码生成效果好，并不意味着它天然可靠：

代码是否“像样”，与是否符合工程约束（类型、可访问性、性能预算、安全策略）是两回事。
模型能拼出组件树，但很容易在状态边界与数据一致性上犯错，尤其是复杂交互、多端适配、并发与缓存场景。
视觉对齐可以做到很像，但设计系统、可维护性与可扩展性需要经验驱动的取舍，不能只追求像素级还原。

更合理的定位是：把模型当作“高吞吐的初稿生成器 + 有经验开发者的约束校验器”。前端之所以显得更“好用”，是因为它确实更适合这种分工。

结语#

AI 写网页代码之所以效果好，并不是因为网页开发更简单，而是因为它更结构化：开放的生态让训练数据极其充足；主流栈的默认选择让实现路径高度收敛；UI 层的抽象把需求到代码的映射变成可组合的工程问题；多模态能力又进一步增强了对布局与层级的理解。

当这些条件叠加在一起，代码生成就不再像魔法，而更像一套高效的模式检索与组合机制在发挥作用。下一步真正的竞争点，不是“能不能写出来”，而是“能不能在约束下持续写对”。

2025年前端框架总结

Sun, 11 Jan 2026 00:00:00 GMT

下面的结论与图表基于「2025 JavaScript Rising Stars」：统计 Best of JS 收录项目在 2025 年新增的 GitHub star（近 12 个月增量），用来观察“关注度变化”而非“绝对使用量”。我在此基础上做了归纳与选型建议。

1. 2025 的整体信号#

AI 不再只是“聊天”，而是以“工作流/代理编排”的形态爆发，n8n 以断层优势成为年度冠军。
React 重新夺回“前端框架”榜首，但真正的焦点是向 Server Components/Server Functions 的迁移带来的复杂度与安全风险。
前端工具链继续走向“更快、更统一”：运行时、打包、格式化/Lint 的一体化趋势更明显。

1.1 年度冠军 n8n 的 2025 月度增长（新增 star）#

n8n：2025 月度新增 star（k） 0 5 10 15 峰值：14.4k（4 月） 1234 5678 9101112

2. 最受欢迎的项目（Top 10）#

最受欢迎项目 Top 10：2025 新增 star 1 n8n 2 React Bits 3 shadcn/ui 4 Excalidraw 5 Supabase 6 Onlook 7 Better Auth 8 Dyad 9 AFFiNE 10 Stagehand +112.4k +32.8k +26.3k +25.1k +19.9k +19.4k +19.0k +18.9k +17.3k +17.1k

排名	项目	2025 新增 star	定位	关键词
1	n8n	+112.4k	工作流自动化平台	工作流、原生 AI、400+ 集成
2	React Bits	+32.8k	动效/交互组件集合	组件分发、shadcn 风格、可视化调参
3	shadcn/ui	+26.3k	组件库 + 注册表	无障碍、可定制、分发模式
4	Excalidraw	+25.1k	手绘风白板	协作、图形化表达
5	Supabase	+19.9k	开源 BaaS	Postgres、边缘能力、全栈后端
6	Onlook	+19.4k	AI 优先可视化编辑器	设计到代码、React 应用、编辑器
7	Better Auth	+19.0k	TypeScript 鉴权框架	插件系统、框架无关、多租户
8	Dyad	+18.9k	本地开源 AI 应用构建器	v0/lovable 替代、快速原型
9	AFFiNE	+17.3k	开源知识库/协作	Notion/Miro 替代、隐私优先
10	Stagehand	+17.1k	AI 浏览器自动化	测试、运营自动化、代理编排

分析要点：

n8n 的增长几乎“改写刻度”，2025 年从工具到生态位的关注都集中到了“工作流 + AI”。
Top 10 里与“React 组件分发/体验”相关的项目占比非常高（React Bits、shadcn/ui、Onlook 等），说明“做 UI 这件事”正在向“可复制粘贴的工程化积木”收敛。
Better Auth 这类“框架无关 + 插件化”的基础能力项目上榜，说明全栈化后对安全与工程抽象的需求在上升。

3. 前端框架（Top 5）#

前端框架 Top 5：2025 新增 star React Ripple Svelte htmx Vue.js +11.0k +6.5k +4.6k +4.5k +4.3k

排名	框架	2025 新增 star	定位	关键词
1	React	+11.0k	UI 库/生态核心	全栈化、RSC/Server Actions、流式渲染
2	Ripple	+6.5k	新一代 UI 框架实验	响应式原语、组件化、早期阶段
3	Svelte	+4.6k	编译型框架	Svelte 5、Runes、简化状态建模
4	htmx	+4.5k	HTML 驱动交互	Server-first、低 JS、渐进增强
5	Vue.js	+4.3k	渐进式框架	生态稳定、工程化成熟

分析要点：

React 的“回归第一”更像是生态在押注“全栈化”：Server Components、Server Actions、流式渲染把边界推向服务端，但也放大了复杂度与安全面。
Ripple 是 Top 5 的新面孔：更像“下一代 UI 框架实验场”，但它是否会出现像 Next.js/Nuxt/SvelteKit 这样的元框架，是 2026 的看点。
Svelte 连续稳定在前三，Svelte 5 的 Runes（$state/$derived/$effect）逐渐成为其状态建模的主流写法。

4. React 生态（Top 5）#

React 生态 Top 5：2025 新增 star React Bits shadcn/ui Excalidraw Onlook Vercel AI SDK +32.8k +26.3k +25.1k +19.4k +9.7k

排名	项目	2025 新增 star	定位	关键词
1	React Bits	+32.8k	动效/交互组件集合	复制粘贴、动效、展示组件
2	shadcn/ui	+26.3k	组件库 + 注册表	可定制、无障碍、组合式
3	Excalidraw	+25.1k	手绘风白板	协作、图形化表达、嵌入式
4	Onlook	+19.4k	AI 优先可视化编辑器	设计到代码、React、编辑器
5	Vercel AI SDK	+9.7k	AI 应用 SDK	流式、工具调用、RAG

分析要点：

“组件注册表/可复制粘贴组件”成为 UI 生产的新范式：React Bits 本身甚至以 shadcn/ui 项目形态分发。
Onlook 这类“AI 优先的可视化编辑器”开始进入主流讨论：它们并不是低代码的旧叙事，而是以 AI 为核心的“设计到代码”通道。

5. 后端 / 全栈（Top 5）#

后端 / 全栈 Top 5：2025 新增 star Motia Payload Next.js Astro Hono +13.8k +8.9k +8.7k +7.2k +6.8k

排名	框架	2025 新增 star	定位	关键词
1	Motia	+13.8k	工作流式后端框架	编排、Step/Worker、可观测
2	Payload	+8.9k	Headless CMS/全栈框架	Admin、Postgres、内容建模
3	Next.js	+8.7k	React 元框架	RSC、Server Actions、全栈路由
4	Astro	+7.2k	内容优先元框架	Islands、性能、静态/SSR
5	Hono	+6.8k	轻量 Web 框架	Web 标准、多运行时、边缘部署

分析要点：

Motia 的叙事是“统一后端”：用单一抽象（Steps）覆盖 API、队列、工作流、流处理、AI agent，反映出后端工程也在向“可观测 + 状态 + 编排”收敛。
Astro 与 Hono 代表了“更轻的服务端”：前者适合内容型应用与性能取向，后者用 Web Standards 在多运行时之间迁移更自然。

6. 工具（Top 5）#

工具 Top 5：2025 新增 star Bun Vite Biome Oxlint/Oxc Parser/Oxfmt Nx +10.8k +7.6k +6.7k +5.2k +3.7k

排名	工具	2025 新增 star	定位	关键词
1	Bun	+10.8k	JS 运行时/工具链	运行时、打包、测试、速度
2	Vite	+7.6k	前端构建工具	Dev Server、HMR、插件生态
3	Biome	+6.7k	格式化 + Lint 工具	一体化、快速、可配置
4	Oxlint/Oxc Parser/Oxfmt	+5.2k	Rust 工具链组件	Lint、Parser、格式化
5	Nx	+3.7k	Monorepo 工程工具	任务编排、缓存、工作区

分析要点：

“一体化工具链”在加速：运行时（Bun）、构建（Vite）、格式化/检查（Biome、Oxc）都在追求更快的默认体验。
2025 年基础设施工具的一个重要趋势是“系统语言化”：Rust/Go 生态的占比更高，性能成为可见的竞争点。

7. AI（Top 5）#

AI Top 5：2025 新增 star n8n Dyad Stagehand Mastra Flowise +112.4k +18.9k +17.1k +15.0k +14.6k

排名	项目	2025 新增 star	定位	关键词
1	n8n	+112.4k	工作流自动化平台	工作流、代理编排、集成生态
2	Dyad	+18.9k	本地开源 AI 应用构建器	v0 替代、快速原型、本地优先
3	Stagehand	+17.1k	AI 浏览器自动化	代理、测试、运营自动化
4	Mastra	+15.0k	AI Agent 框架	工具调用、流程编排、可观测
5	Flowise	+14.6k	可视化 LLM 工作流	LangChain 风格、拖拽、RAG

分析要点：

2025 年的主旋律是“工作流引擎”而不是“聊天 UI”：把模型接入业务流程、让系统在触发后推理并采取动作，成为最明确的增长方向。
前端开发者会更频繁地遇到“浏览器自动化 + 代理编排”的需求（如 Stagehand），这会反向影响测试、运营、增长与研发流程。

8. 移动端（Top 10）#

移动端 Top 5：2025 新增 star Valdi Lynx Expo Dioxus React Native +15.9k +14.0k +10.2k +5.7k +5.0k

排名	项目	2025 新增 star	定位	关键词
1	Valdi	+15.9k	跨端 UI 框架	TypeScript、JSX、Web 风格
2	Lynx	+14.0k	跨端渲染/运行时	原生渲染、性能、工程化
3	Expo	+10.2k	React Native 平台/工具链	EAS、Router、原生能力
4	Dioxus	+5.7k	Rust UI 框架	跨平台、声明式、性能
5	React Native	+5.0k	移动端框架	跨平台、生态、原生桥接
6	React Native Reusables	+3.3k	RN 组件库/分发	复制粘贴、设计系统、工程化
7	Capacitor	+2.2k	Web 到原生容器	原生插件、Hybrid、迁移
8	NativeWind	+1.9k	RN 的 Tailwind 方案	实用类、样式系统、DX
9	gluestack-ui	+1.7k	RN 组件库	主题化、可组合、Design System
10	Tamagui	+1.7k	跨平台 UI Kit	RN + Web、性能、编译优化

分析要点：

Valdi 与 Lynx 的出现让“跨平台 UI”有了更多 Web 风格的选择：TypeScript、JSX、flexbox、热重载、CSS 等，说明开发者仍然强烈偏好 Web 生产力模型。
React Native 与 Expo 仍是可靠的长期下注，但 2025 的榜单也提示：移动端的“新抽象”正在涌现，尤其是在性能与交互复杂度更高的场景。

9. 2026 选型建议（面向落地）#

以“团队稳定交付”为第一目标：React + 成熟元框架仍是默认解，但需要把“客户端/服务端边界、安全面、缓存与数据生命周期”纳入工程规范。
以“体验/速度与简单”为第一目标：Svelte 的开发体验很强，适合新项目或内容型产品，团队学习曲线相对平滑。
以“内容 + 性能 + 部分交互”为第一目标：Astro 仍然非常稳，适合把交互作为“岛屿”而非全量 SPA。
以“AI 作为工作的一部分”为第一目标：优先考虑可编排的工作流/代理工具，把测试、运营、数据处理、内容生产纳入自动化闭环。

10. 年度大事与 2026 展望#

2025 年发生了几件会改变 JS 生态结构的事：Bun 被 Anthropic 收购（Claude Code/Claude 模型背后的公司），并明确把 Bun 作为 AI 编码产品的关键基础设施之一，这也解释了为什么“一体化运行时 + 单文件可执行分发”会在 AI 编码工具/代理时代变得更重要。同样值得关注的是人才与组织的迁移：长期代表 Next.js 的 Lee Robinson 加入 Cursor，围绕 AI 编码与工作流推出面向初学者的学习内容（参考：Lenny’s Newsletter 访谈、Cursor Learn 相关内容）；而 NuxtLabs（Nuxt/Nitro 团队）加入 Vercel，也被视作“多框架共存”在平台侧变得更现实的信号。

框架层面也在分化：Remix 3 选择淡化 React 依赖、进一步回到 Web 平台与更少的关键依赖（参考：InfoQ 报道）。而 React/Next 侧，“指令（directive）”正在从 use client、use server、use cache 走向影响更广的基础设施语义，带来边界清晰度与可移植性的讨论。与此同时，供应链安全风险被进一步放大：Shai-Hulud 相关的 npm 供应链攻击波及大量包与仓库，让“依赖审计、最小权限、凭证轮换、供应链防护”从最佳实践变成了刚需。

2026 的未来更像一条“平衡线”：代理工作流（能编排、能回放、可观测）会成为开发者的必备技能，但同时也要避免把控制权完全交给 AI 而牺牲工程质量、边界与安全；能否在“速度”与“可维护性”之间找到合适的中间点，将决定团队在 AI 时代的长期竞争力。

世界模型的到来

Sat, 10 Jan 2026 00:00:00 GMT

我们谈“世界模型”时，经常会把它想成一个宏大名词：仿佛需要先造出一个能完整复制现实的数字孪生，才配叫世界模型。但在工程语境里，它更像一种能力组合：系统能把观测压缩成状态，把状态推进到未来，再把未来反推到可执行的动作。它不必全知全能，却必须在足够多的情境里“算得对、跑得稳、改得快”。

过去两年，这条路线突然变得具体了：模型开始擅长长链条推理与工具调用；多模态把抽象符号重新绑回到真实感知；机器人政策开始从“单任务特训”走向“通用技能库”；硬件平台把推理的瓶颈从算力搬到能耗、内存与带宽。世界模型不再只是研究论文里的结构，而正在变成产业链共同对齐的一套目标函数。

1. 最新模型进步：从“生成答案”到“生成过程”#

如果把 2023 年以前的大模型概括成“更像知识检索 + 文本补全”，那么近期的明显变化是：模型越来越像在生成一个可执行的推理过程，而不是只给出一个看似正确的结论。这个变化背后是推理时扩展（inference-time scaling）与强化学习训练范式的结合：让模型在更长的思维链里做更多“中间计算”，并通过可验证奖励把正确性向过程内推。

图注：LIM推理的增长趋势。显示了从2022年到2025年2月发表的论文累计数量（以千为单位），基于Semantic Scholar关键词搜索，自2022年引入链式思维（Chain-of-Thought，CoT）以来，关于制度和架构的研究明显加快

对世界模型而言，这一步非常关键。世界模型不是一句话能回答的问题，而是一个持续运行的系统：它要反复读取观测、维护记忆、调用工具、校验假设、更新计划。也就是说，世界模型天然是“多轮推理 + 多次行动”的形态。把大模型训练成更稳定的推理器，相当于先补齐了系统 2（慢思考、规划、反事实推演）的底座。

与此同时，模型的上下文窗口和外部记忆机制也在变得更工程化：长上下文让“持续对话”变成“持续建模”，而不是一次次重新开局；外部检索与工具接口把世界状态从“模型脑内的文本幻觉”转成“可以被重复验证的外部事实”。这为世界模型的第二个关键要素铺路：多模态与可检验的观测。

2. 多模态的重要性：世界模型必须“接地”#

语言是高压缩的抽象接口，但世界不是用语言运行的。只靠文本训练出来的模型，擅长在符号空间里做一致性，却很难保证与物理因果一致。世界模型之所以必须多模态，不是为了让模型“看图识字”更强，而是为了把预测对象从“下一段文本”升级为“下一段可观测世界状态”。

机器人领域最近的 VLA（Vision-Language-Action）路线很典型：把视觉、语言与动作放到同一个建模框架里，让“看见什么、理解什么、怎么做”变成一个端到端的闭环。相关综述里普遍强调一个趋势：从分模块流水线走向统一表征与统一优化，目标是让策略能跨任务、跨物体、甚至跨不同机器人形态泛化（Vision-Language-Action survey，2025）。这种路线在能力侧看起来像“更通用的机器人”，在世界模型侧看其实是：模型必须学会把感知映射到可行动的状态空间，并在行动后用新观测修正自己。

如果说语言模型解决的是“如何在符号里做推理”，那么多模态解决的是“如何让推理对象与世界对齐”。从这一刻开始，世界模型的核心不再是文本生成的流畅度，而是对观测、行动、反馈三者之间因果结构的掌握。

3. 线性代数、分段线性区域与“高维流型”#

讨论世界模型，很容易陷入直觉叙事：模型好像在脑子里画出了一张世界地图。但把它落到可计算的结构，会发现核心仍是线性代数之上的函数逼近与优化：矩阵乘法是主干，非线性激活负责把空间折叠出可用的表示。

先看数据本身。高维观测并不是“铺满”整个空间，更多时候，它们沿着受约束的子结构分布；工程里常把这种“薄的结构”叫作流型。世界模型首先要做的，是把观测压缩成更稳定、更可控的表征，让相邻关系和变化方向在表征空间里变得更清晰。

低维流型嵌在高维里：看起来复杂，分布却很“薄” 观测空间（高维）图片/视频/传感器并不均匀分布，往往集中在低维子结构 x y z 表征空间（低维/可控）映射后相邻关系更稳定，便于插值、预测与规划 u v 直觉：把“薄的结构”找出来，比把“整个空间”学会更可行

再看函数表达力。世界模型不仅要“表示世界”，还要在表征上做推进与预测，这就需要网络对空间有足够细的切分能力：在小范围内尽可能平滑可控，在全局上又能拼出复杂形状。分段线性网络提供了一个可量化切口：同一激活模式下，网络对输入是线性的；激活模式一变，就相当于切到另一块线性片段。Montúfar 等人在 2014 年从线性区域数量的角度分析了深层网络的表达复杂度（On the Number of Linear Regions of Deep Neural Networks，2014）。

线性区域：同一激活模式下是线性的，整体则是“拼接”出来的曲率输入空间（示意为 2D） ReLU 的开/关组合切分出许多多面体区域 x₁ x₂ 输出函数（1D 示意）每段都是直线，折点来自区域切换 “深度”增加区域数，提升可表达的形状复杂度

最后看优化。训练做的并不是把整个空间都拟合好，而是在“数据实际出现的那一小块区域”把切分做得更合适：让流型落在更稳定、更容易推进的线性片段上，让插值、外推与长时序预测更不容易跑飞。

训练的直觉：让“数据所在处”落进更可用的几何片段数据分布样本沿着流型排列表征 / 切分激活模式把空间切成线性片段区域内：近似线性、可插值任务预测 / 规划状态推进动作选择优化：不断调整切分，使“数据所在的区域”更好用

世界模型需要的正是这种几何能力：它要在表征里做状态推进，从 (s_t) 到 (s_{t+1}) 的动力学近似、从目标到动作序列的规划、以及从误差到策略更新的闭环。没有足够丰富且可控的表示与切分，就很难在长时序任务里保持稳定。

4. 具身智能的发展：从单点技能到“技能库 + 规划器”#

具身智能的变化，首先是数据与任务分布的变化：Open X-Embodiment 这类工作试图把分散的机器人数据对齐到统一格式，并训练跨任务的 RT-X 系列模型（Open X-Embodiment，2023–2025 持续更新）。当数据分布开始跨机器人、跨场景拼在一起，策略模型就不再是“机械臂 A 的拣选器”，而更像“可迁移的动作语言模型”。

其次是架构上的分层：一类路线倾向于把高层规划（语言/符号推理）与低层控制（连续动作、反馈稳定性）分开优化，形成更像“规划器 + 技能库”的系统。VLA 综述里也经常提到双系统结构：用慢的系统负责分解任务、选择工具/技能；用快的系统负责执行与闭环纠错。这种分层与世界模型的需求高度一致：世界模型必须在高层维持一个可解释的任务结构，同时在低层保证动作的物理可行性。

更重要的是，具身智能迫使模型面对一个无法回避的事实：预测必须可检验。语言任务里，错误可以被“合理化”；但在机器人里，错误会直接表现为抓不到、撞到、摔倒。可检验性把世界模型的训练目标从“看起来对”推向“真的能用”，也推动了更真实的数据、更强的仿真、更严格的评测指标。

5. 黄仁勋的算力平台与“瓦力”式机器人：把世界模型做成产品形态#

当世界模型从研究走向工程，最先被放大的是系统瓶颈：推理的吞吐、上下文的驻留、跨节点的通信、以及把传感器与动作回路跑到实时的能力。近期 NVIDIA 对“机柜级系统”的叙事，本质上是在把世界模型需要的计算形态产品化：从单卡指标转向整机柜的带宽、内存容量与可用性。

以 NVIDIA 在 CES 2026 公开的 Vera Rubin NVL72 机柜级系统为例，官方强调的是 MoE 推理 token 成本降低、NVLink 规模互联带宽以及系统级的内存/网络配置，目标指向的是“能持续推理、能持续上下文驻留、能支撑大规模 agent 的在线运行”（NVIDIA Newsroom：Rubin platform，2026）。你会发现这里的关键词与世界模型的需求对齐：世界模型不是离线训练一次就结束，而是要在运行时持续吸收观测、生成计划、调用工具，因而对上下文内存与互联有持续需求。

同一条叙事在机器人展示里更直观。Jensen Huang 在公开活动中展示过与 Disney Research、DeepMind 合作的机器人“Blue”，那种“瓦力”式的外形与互动方式，很容易让人把注意力从某个硬件参数挪开，转向一个更实际的问题：一个具身系统能不能在真实环境里持续感知、持续推理、持续行动（Euronews：Blue robot，2025）。当这种演示从单次 Demo 变成可复用的平台能力，世界模型就拥有了更明确的落地载体：把多模态预测与动作闭环做成标准件。GR00T N1：NVIDIA为具身智能打造的开源基础模型

6. 年底算力和电力费用暴增的隐含逻辑：电力与内存成为世界模型的真实边界#

把世界模型当成“模型能力”会误判它的节奏；把它当成“系统能力”才能看清它的约束。算力确实在暴增，但并不等于“问题消失”，更像是瓶颈在迁移：从训练算力迁移到推理能耗，从参数规模迁移到上下文驻留，从 FLOPs 迁移到内存带宽与供应链。

狗血的事前阵子想给自己的开发机加内存，才发现内存价格暴涨，本来计划一步到位把容量拉满，结果发现同样规格的条子在短时间内涨价明显；你会下意识地开始算账：是先上容量，还是先换更快的盘、先把显卡升级，或者干脆把预算留给下一代。它看起来只是装机的小纠结，但背后是同一个规律：当工作负载变“吃内存”，价格和供给就会先让你感到边界。

电力已经是最硬的边界之一。IEA 在关于 AI 与能源的分析中给出数据中心用电的量级与增长速度：2024 年全球数据中心用电约 415 TWh（约占全球用电 1.5%），到 2030 年在基准情景下可能接近翻倍至约 945 TWh，并指出增长主要集中在美国与中国等区域（IEA：Energy demand from AI，2024/2025）。当推理成为常态、agent 成为工作流的一部分、世界模型成为在线系统，电力就会从“成本优化项”变成“部署硬约束”：配电、制冷、选址，直接决定能跑多大规模、能跑多高利用率。

内存则是第二个硬边界。世界模型需要长上下文与多路传感器缓存，需要为推理提供足够带宽与容量，这会把 HBM 与高端 DRAM 变成系统级关键材料。TrendForce 的行业报道指出，AI 相关内存需求正在抬升并挤压供给，甚至出现对 2026 年 HBM3E 价格上调的预期与产能优先级调整（TrendForce：HBM3E 2026 price hike，2025；AI consumes DRAM capacity，2025）。当“算力”被理解成 GPU 数量时，人们往往忽略内存；但当系统跑到机柜级、跑到在线推理，内存就会以非常朴素的方式出现：带宽不够就是吞吐上不去，供给不稳就是扩容做不动。

这也解释了为什么硬件平台越来越强调“上下文内存”“机柜互联”“系统可靠性”：世界模型的价值在运行时被释放，而运行时的瓶颈正逐步由能源与内存定义。

7. 世界模型什么时候真的实现#

世界模型不会以“某个模型发布日”作为分水岭，它更像一条供应链与工程范式共同推进的曲线：

推理能力变稳定：模型能在长链条里保持正确性，并能可靠调用工具。
多模态变标准：预测对象从文本扩展到视觉/动作/反馈，世界开始“可检验”。
表示几何变可控：模型能在高维空间里形成可组合、可泛化的状态表示。
具身系统变平台：技能库与规划器分层，数据分布从单任务转向多任务统一。
硬件与能源对齐：机柜级系统把瓶颈摊开，让能耗与内存成为显式约束。

真正值得兴奋的地方在于：世界模型把“智能”从对话框里带出来，把它放到可以被验证、被部署、被迭代的系统里。它会逼迫我们重新定义很多工程指标：正确率不够，需要稳定性；延迟不够，需要闭环；模型不够，需要系统；算力不够，需要电与内存。

世界模型的到来并不浪漫，但足够真实。

参考链接#

IEA：Energy demand from AI https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai
Montúfar et al. 2014：On the Number of Linear Regions of Deep Neural Networks https://arxiv.org/abs/1402.1869
Open X-Embodiment：https://arxiv.org/abs/2310.08864
VLA Survey：https://vla-survey.github.io/
NVIDIA Newsroom（Rubin platform）：https://nvidianews.nvidia.com/news/rubin-platform-ai-supercomputer
TrendForce（HBM3E price hike for 2026）：https://www.trendforce.com/news/2025/12/24/news-samsung-sk-hynix-reportedly-plan-20-hbm3e-price-hike-for-2026-as-nvidia-h200-asic-demand-rises/
TrendForce（AI consumes DRAM wafer capacity in 2026）：https://www.trendforce.com/news/2025/12/26/news-ai-reportedly-to-consume-20-of-global-dram-wafer-capacity-in-2026-hbm-gddr7-lead-demand/
Euronews（Nvidia’s AI robot “Blue”）：https://www.euronews.com/video/2025/03/19/nvidias-ai-robot-blue-stuns-with-live-interaction

利用飞书多维文档实现博客的信息更新

Wed, 03 Dec 2025 00:00:00 GMT

前言#

在维护个人博客时，我们经常需要更新各种数据，比如书架信息、友链列表等。传统的方式是直接修改JSON文件，这样不仅效率低下，而且容易出错。有没有更便捷的方式呢？答案是肯定的！我们可以利用飞书多维文档来管理这些数据，并通过脚本自动同步到博客中。不但可以实现信息的维护，也可以在手机上实时操作。

示例#

示例图片

书架

友链

参考与灵感#

本文的实现灵感来自于时歌的文章《基于飞书多维表格的书架实现》。在这篇文章中，时歌详细介绍了如何使用Python脚本实现从飞书多维文档到博客书架数据的同步。我在其基础上进行了改进，使用JavaScript实现了更强大的功能。

项目实现#

技术栈#

飞书开放平台API：用于获取多维文档数据
JavaScript：实现数据同步脚本
Node.js：运行环境
Axios：处理HTTP请求
Sharp：图片处理和压缩
Dotenv：环境变量管理

功能特点#

与原Python版本相比，JavaScript版本的脚本增加了以下功能和改进：

多数据类型支持：不仅支持书架数据，还支持友链数据的同步
图片自动压缩：自动将图片压缩为WebP格式，优化博客加载速度
智能质量调整：根据文件大小自动调整图片质量，确保图片质量和加载速度的平衡
友好的日志输出：提供清晰的进度提示和错误信息
跨平台支持：JavaScript版本可以在更多平台上运行

核心实现#

脚本的核心功能主要包括以下几个部分：

获取访问令牌：通过飞书开放平台API获取访问令牌
读取多维文档数据：从飞书多维文档中读取书架和友链数据
处理数据：对数据进行格式转换和图片处理
保存数据：将处理后的数据保存为JSON文件，供博客使用

项目配置#

在package.json中，我们添加了专门的脚本命令：

1
"scripts": {
2
  "book": "node scripts/feishu_bitable.js"
3
}

这样，我们可以通过运行pnpm run book来执行数据同步。

使用方法#

1. 配置飞书开放平台#

首先，需要在飞书开放平台创建应用，并获取以下信息：

APP_ID
APP_SECRET
BITABLE_ID
TABLE_ID_BOOKS
TABLE_ID_FRIENDS

2. 配置环境变量#

在项目根目录创建.env文件，并添加以下内容：

1
FEISHU_APP_ID=your_app_id
2
FEISHU_APP_SECRET=your_app_secret
3
FEISHU_BITABLE_ID=your_bitable_id
4
FEISHU_TABLE_ID_BOOKS=your_books_table_id
5
FEISHU_TABLE_ID_FRIENDS=your_friends_table_id

3. 运行同步脚本#

执行以下命令即可完成数据同步：

Terminal window

1
pnpm run book

脚本会自动完成从飞书多维文档到本地JSON文件的数据同步，并处理好图片。

项目结构#

1
scripts/
2
└── feishu_bitable.js    # 飞书多维文档同步脚本
3
public/
4
├── data/
5
│   ├── books.json       # 书架数据
6
│   └── friends.json     # 友链数据
7
└── images/
8
    └── books/           # 书架图片保存目录

功能细节#

图片处理#

脚本会自动下载飞书多维文档中的图片，并进行压缩处理：

调整图片尺寸，最大宽度800px，最大高度1200px
转换为WebP格式，提高加载速度
自动调整图片质量，确保文件大小不超过300KB
为图片生成唯一的文件名，避免重复下载

数据格式转换#

将飞书多维文档中的数据转换为博客所需的格式：

书架数据示例：

1
{
2
  "title": "书名",
3
  "author": "作者",
4
  "cover": "封面图片URL",
5
  "status": "阅读状态",
6
  "rating": "评分"
7
}

友链数据示例：

1
{
2
  "title": "站点名称",
3
  "imgurl": "头像图地址",
4
  "desc": "站点描述",
5
  "siteurl": "站点地址",
6
  "tags": ["标签"]
7
}

完整代码实现#

以下是feishu_bitable.js的完整实现代码：

1
import fs from 'fs';
2
import path from 'path';
3
import { fileURLToPath } from 'url';
4
import crypto from 'crypto';
5
import axios from 'axios';
6
import sharp from 'sharp';
7
import dotenv from 'dotenv';
8

9
// 在ES模块中定义__filename和__dirname
10
const __filename = fileURLToPath(import.meta.url);
11
const __dirname = path.dirname(__filename);
12

13
// 加载.env文件中的环境变量
14
dotenv.config();
15

16
// 飞书开放平台的配置
17
const APP_ID = process.env.FEISHU_APP_ID;
18
const APP_SECRET = process.env.FEISHU_APP_SECRET;
19
const BITABLE_ID = process.env.FEISHU_BITABLE_ID;  // 多维表格 ID
20
const TABLE_ID_BOOKS = process.env.FEISHU_TABLE_ID_BOOKS;      // 数据表 ID
21
const TABLE_ID_FRIENDS = process.env.FEISHU_TABLE_ID_FRIENDS;      // 数据表 ID
22

23

24

25
// 图片压缩配置
26
const MAX_SIZE = { width: 800, height: 1200 };  // 最大尺寸
27
const WEBP_QUALITY = 85;  // WebP质量（1-100）
28
const MAX_FILE_SIZE = 300 * 1024;  // 300KB
29

30
/**
31
 * 获取飞书应用的 tenant_access_token
32
 */
33
async function getTenantAccessToken() {
34
  console.log("[步骤1/4] 获取飞书应用访问令牌 (tenant_access_token)...");
35
  try {
36
    const url = "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal";
37
    console.log("  发送请求到飞书认证服务器...");
38
    const response = await axios.post(url, {
39
      app_id: APP_ID,
40
      app_secret: APP_SECRET
41
    }, {
42
      headers: {
43
        "Content-Type": "application/json; charset=utf-8"
44
      }
45
    });
46
    console.log("  ✅ 成功获取访问令牌 ");
47
    return response.data.tenant_access_token;
48
  } catch (error) {
49
    console.error("  ❌ 获取访问令牌失败:", error.message);
50
    return null;
51
  }
52
}
53

54
/**
55
 * 获取多维表格中的BOOKS记录
56
 */
57
async function getBitableRecords() {
58
  console.log("[步骤2/4] 从飞书多维表格获取数据...");
59
  try {
60
    const token = await getTenantAccessToken();
61
    if (!token) {
62
      console.error("  ❌ 无法继续，缺少访问令牌");
63
      return null;
64
    }
65

66
    const url = `https://open.feishu.cn/open-apis/bitable/v1/apps/${BITABLE_ID}/tables/${TABLE_ID_BOOKS}/records`;
67
    console.log(`  发送请求到飞书多维表格 API...`);
68
    console.log(`  多维表格ID: ${BITABLE_ID}, 数据表ID: ${TABLE_ID_BOOKS}`);
69

70
    const response = await axios.get(url, {
71
      headers: {
72
        "Authorization": `Bearer ${token}`,
73
        "Content-Type": "application/json"
74
      }
75
    });
76

77
    const recordCount = response.data?.data?.items?.length || 0;
78
    console.log(`  ✅ 成功获取 ${recordCount} 条记录`);
79
    return response.data;
80
  } catch (error) {
81
    console.error("  ❌ 获取多维表格记录失败:", error.message);
82
    return null;
83
  }
84
}
85
/**
86
 * 获取多维表格中的BOOKS记录
87
 */
88
async function getBitableRecords_Friends() {
89
  console.log("[步骤2/4] 从飞书多维表格获取FRIENDS数据...");
90
  try {
91
    const token = await getTenantAccessToken();
92
    if (!token) {
93
      console.error("  ❌ 无法继续，缺少访问令牌");
94
      return null;
95
    }
96

97
    const url = `https://open.feishu.cn/open-apis/bitable/v1/apps/${BITABLE_ID}/tables/${TABLE_ID_FRIENDS}/records`;
98
    console.log(`  发送请求到飞书多维表格 API...`);
99
    console.log(`  多维表格ID: ${BITABLE_ID}, 数据表ID: ${TABLE_ID_FRIENDS}`);
100

101
    const response = await axios.get(url, {
102
      headers: {
103
        "Authorization": `Bearer ${token}`,
104
        "Content-Type": "application/json"
105
      }
106
    });
107

108
    const recordCount = response.data?.data?.items?.length || 0;
109
    console.log(`  ✅ 成功获取 ${recordCount} 条记录`);
110
    return response.data;
111
  } catch (error) {
112
    console.error("  ❌ 获取多维表格记录失败:", error.message);
113
    return null;
114
  }
115
}
116
/**
117
 * 压缩图片为WebP格式
118
 */
119
async function compressImage(imageBuffer) {
120
  try {
121
    // 获取图片信息
122
    const imageInfo = await sharp(imageBuffer).metadata();
123

124
    // 计算新尺寸（保持宽高比）
125
    let newWidth = imageInfo.width;
126
    let newHeight = imageInfo.height;
127

128
    if (newWidth > MAX_SIZE.width || newHeight > MAX_SIZE.height) {
129
      const widthRatio = MAX_SIZE.width / newWidth;
130
      const heightRatio = MAX_SIZE.height / newHeight;
131
      const ratio = Math.min(widthRatio, heightRatio);
132

133
      newWidth = Math.round(newWidth * ratio);
134
      newHeight = Math.round(newHeight * ratio);
135
    }
136

137
    // 初始质量
138
    let quality = WEBP_QUALITY;
139
    let compressedBuffer;
140

141
    // 尝试不同的质量直到文件大小符合要求
142
    while (true) {
143
      compressedBuffer = await sharp(imageBuffer)
144
        .resize(newWidth, newHeight, { fit: 'inside', withoutEnlargement: true })
145
        .webp({
146
          quality: quality,
147
          effort: 4,
148
          lossless: false
149
        })
150
        .toBuffer();
151

152
      // 如果文件够小或质量已经很低，就退出
153
      if (compressedBuffer.length <= MAX_FILE_SIZE || quality <= 40) {
154
        break;
155
      }
156

157
      // 否则降低质量继续尝试
158
      quality -= 5;
159
    }
160

161
    return compressedBuffer;
162
  } catch (error) {
163
    console.error("Image compression error:", error.message);
164
    throw error;
165
  }
166
}
167

168
/**
169
 * 下载图片并返回本地路径
170
 */
171
async function downloadImage(url, token, saveDir) {
172
  try {
173
    // 生成文件名（使用URL的哈希值）
174
    const urlHash = crypto.createHash('md5').update(url).digest('hex');
175
    const filename = `${urlHash}.webp`;
176
    const localPath = path.join(saveDir, filename);
177
    const webPath = `/images/books/${filename}`;
178

179
    // 如果文件已存在，直接返回路径
180
    if (fs.existsSync(localPath)) {
181
      console.log(`Image already exists: ${filename}`);
182
      return webPath;
183
    }
184

185
    // 下载图片
186
    const response = await axios.get(url, {
187
      headers: { "Authorization": `Bearer ${token}` },
188
      responseType: 'arraybuffer'
189
    });
190

191
    // 压缩图片
192
    const compressedBuffer = await compressImage(Buffer.from(response.data));
193

194
    // 保存压缩后的图片
195
    fs.writeFileSync(localPath, compressedBuffer);
196

197
    const originalSize = Buffer.from(response.data).length / 1024;  // KB
198
    const compressedSize = compressedBuffer.length / 1024;  // KB
199
    const compressionRatio = (1 - compressedSize / originalSize) * 100;
200

201
    console.log(`Downloaded: ${filename} (Original: ${originalSize.toFixed(1)}KB, Compressed: ${compressedSize.toFixed(1)}KB, Saved: ${compressionRatio.toFixed(1)}%)`);
202

203
    return webPath;
204
  } catch (error) {
205
    console.error(`Error downloading image ${url}:`, error.message);
206
    return null;
207
  }
208
}
209

210
/**
211
 * 处理记录
212
 * @param {Object} records - 记录数据
213
 * @param {string} token - 访问令牌（用于图片下载）
214
 * @param {string} type - 记录类型，可选值：'books' 或 'friends'
215
 * @returns {Object|Array} 处理后的记录数据
216
 */
217
async function processRecords(records, token, type = 'books') {
218
  console.log(`[步骤3/4] 处理${type.toUpperCase()}记录...`);
219

220
  if (!records || !records.data || !records.data.items) {
221
    console.log("  ⚠️  没有找到有效记录数据，跳过处理");
222
    return type === 'friends' ? [] : records;
223
  }
224

225
  const totalRecords = records.data.items.length;
226
  console.log(`  开始处理 ${totalRecords} 条记录...`);
227

228
  let processedData;
229

230
  // 根据不同类型进行处理
231
  if (type === 'friends') {
232
    // 处理friends记录，不需要处理图片
233
    processedData = [];
234

235
    for (const [index, item] of records.data.items.entries()) {
236
      console.log(`  处理记录 ${index + 1}/${totalRecords}...`);
237

238
      if (item.fields) {
239
        // 转换为friends.json所需的格式
240
        const friendData = {
241
          title: item.fields['站点名称'] || '',
242
          imgurl: item.fields['头像图地址'] || '',
243
          desc: item.fields['站点描述'] || '',
244
          siteurl: item.fields['站点地址'] || '',
245
          tags: [item.fields['标签'] || '']
246
        };
247
        processedData.push(friendData);
248
      }
249
    }
250

251
    console.log(`  ✅ FRIENDS记录处理完成，共处理 ${processedData.length} 条记录`);
252
  } else {
253
    // 处理books记录，包含图片处理逻辑
254
    // 确保图片目录存在
255
    const saveDir = path.join(__dirname, '..', 'public', 'images', 'books');
256
    console.log(`  图片保存目录: ${saveDir}`);
257

258
    if (!fs.existsSync(saveDir)) {
259
      console.log("  创建图片保存目录...");
260
      fs.mkdirSync(saveDir, { recursive: true });
261
    }
262

263
    let processedCount = 0;
264
    let imageProcessedCount = 0;
265

266
    // 处理每条记录
267
    for (const [index, item] of records.data.items.entries()) {
268
      console.log(`  处理记录 ${index + 1}/${totalRecords}...`);
269

270
      if (item.fields && item.fields['封面'] && Array.isArray(item.fields['封面'])) {
271
        const covers = item.fields['封面'];
272
        const newCovers = [];
273

274
        console.log(`    找到 ${covers.length} 张封面图片`);
275

276
        for (const cover of covers) {
277
          if (cover.url) {
278
            // 下载图片并获取本地路径
279
            console.log(`    处理图片: ${cover.url.slice(-30)}...`);
280
            const localPath = await downloadImage(cover.url, token, saveDir);
281
            if (localPath) {
282
              const newCover = { ...cover, local_path: localPath };
283
              newCovers.push(newCover);
284
              imageProcessedCount++;
285
            }
286
          }
287
        }
288

289
        if (newCovers.length > 0) {
290
          item.fields['封面'] = newCovers;
291
        }
292
      }
293
      processedCount++;
294
    }
295

296
    console.log(`  ✅ 记录处理完成`);
297
    console.log(`  总计处理: ${processedCount} 条记录, ${imageProcessedCount} 张图片`);
298
    processedData = records;
299
  }
300

301
  return processedData;
302
}
303

304
/**
305
 * 将数据保存为 JSON 文件
306
 * @param {Object|Array} data - 要保存的数据
307
 * @param {string} filename - 输出文件名
308
 */
309
function saveToJson(data, filename = 'books.json') {
310
  console.log("[步骤4/4] 保存数据到 JSON 文件...");
311

312
  const outputPath = path.join(__dirname, '..', 'public', 'data', filename);
313
  console.log(`  输出文件路径: ${outputPath}`);
314

315
  // 确保输出目录存在
316
  const outputDir = path.dirname(outputPath);
317
  if (!fs.existsSync(outputDir)) {
318
    console.log("  创建输出目录...");
319
    fs.mkdirSync(outputDir, { recursive: true });
320
  }
321

322
  // 对于books数据，添加更新时间
323
  if (filename === 'books.json' && typeof data === 'object' && data !== null) {
324
    const updateTime = new Date().toISOString();
325
    data.last_updated = updateTime;
326
    console.log(`  添加更新时间: ${updateTime}`);
327
  }
328

329
  try {
330
    fs.writeFileSync(outputPath, JSON.stringify(data, null, 2, 'utf-8'));
331

332
    // 获取文件大小
333
    const stats = fs.statSync(outputPath);
334
    const fileSize = (stats.size / 1024).toFixed(2);
335

336
    console.log(`  ✅ 数据成功保存到 ${outputPath}`);
337
    console.log(`  文件大小: ${fileSize} KB`);
338
  } catch (error) {
339
    console.error(`  ❌ 保存数据失败:`, error.message);
340
  }
341
}
342

343
/**
344
 * 主函数
345
 */
346
async function main() {
347
  // 确保日志能正常显示，即使在Windows PowerShell中
348
  console.log("===========================================");
349
  console.log("📚 飞书多维表格数据同步工具");
350
  console.log("===========================================");
351

352
  try {
353
    // 检查环境变量
354
    console.log("🔍 检查必要的环境变量...");
355
    const requiredVars = ['FEISHU_APP_ID', 'FEISHU_APP_SECRET', 'FEISHU_BITABLE_ID', 'FEISHU_TABLE_ID'];
356
    const missingVars = requiredVars.filter(varName => !process.env[varName]);
357

358
    if (missingVars.length > 0) {
359
      // 使用标准字符代替emoji以确保在所有终端都能正确显示
360
      console.log("[错误] 缺少必要的环境变量:", missingVars.join(', '));
361
      console.log("请在运行脚本前设置这些环境变量。");
362
      console.log("示例:");
363
      console.log("set FEISHU_APP_ID=your_app_id");
364
      console.log("set FEISHU_APP_SECRET=your_app_secret");
365
      console.log("set FEISHU_BITABLE_ID=your_bitable_id");
366
      console.log("set FEISHU_TABLE_ID=your_table_id");
367

368
      // 临时添加测试环境变量，方便演示
369
      console.log("\n[测试模式] 添加临时测试环境变量以便演示日志输出...");
370
      process.env.FEISHU_APP_ID = "test_app_id";
371
      process.env.FEISHU_APP_SECRET = "test_app_secret";
372
      process.env.FEISHU_BITABLE_ID = "test_bitable_id";
373
      process.env.FEISHU_TABLE_ID = "test_table_id";
374
      console.log("[测试模式] 环境变量已设置，继续执行演示...");
375
    }
376

377
    console.log("✅ 环境变量检查通过");
378
    console.log("\n开始数据同步流程...");
379

380
    // 获取多维表格BOOKS数据
381
    const startTime = Date.now();
382
    const records = await getBitableRecords();
383
    const friendsRecords = await getBitableRecords_Friends();
384
    // 获取token用于可能的操作
385
    const token = await getTenantAccessToken();
386

387
    // 处理books记录
388
    if (records && token) {
389
      console.log("\n开始处理BOOKS记录...");
390
      // 处理记录并下载图片
391
      const processedRecords = await processRecords(records, token, 'books');
392

393
      // 保存数据到JSON文件
394
      saveToJson(processedRecords, 'books.json');
395
    } else {
396
      console.log("[错误] BOOKS数据同步失败: 无法获取多维表格记录或访问令牌");
397
    }
398

399
    // 处理friends记录
400
    if (friendsRecords) {
401
      console.log("\n开始处理FRIENDS记录...");
402
      // 处理friends记录（不需要token，因为不处理图片）
403
      const processedFriends = await processRecords(friendsRecords, null, 'friends');
404

405
      // 保存friends数据到JSON文件
406
      saveToJson(processedFriends, 'friends.json');
407
    } else {
408
      console.log("[错误] FRIENDS数据同步失败: 无法获取多维表格记录");
409
    }
410

411
    const endTime = Date.now();
412
    const duration = ((endTime - startTime) / 1000).toFixed(2);
413

414
    console.log("\n===========================================");
415
    console.log("[成功] 数据同步完成！");
416
    console.log("总耗时: " + duration + " 秒");
417
    console.log("===========================================");
418
  } catch (error) {
419
    console.error("\n❌ 发生未预期的错误:", error.message);
420
    console.error("  请检查错误信息并尝试解决问题。");
421
  }
422

423
}
424

425
// 导出函数以便在其他地方使用
426
export {
427
  getTenantAccessToken,
428
  getBitableRecords,
429
  processRecords,
430
  saveToJson,
431
  main
432
};
433

434
// 如果直接运行脚本
435
// if (import.meta.url === new URL(process.argv[1], import.meta.url).href) {
436
  main();

展开收起

总结#

通过利用飞书多维文档和JavaScript脚本，我们实现了博客数据的自动化更新，大大提高了维护效率。与直接修改JSON文件相比，使用飞书多维文档更加直观和便捷，特别是对于非技术用户来说。

这个实现不仅可以用于个人博客，还可以扩展到更多场景，比如团队协作、内容管理等。

致谢#

特别感谢时歌的文章《基于飞书多维表格的书架实现》，为本文提供了灵感和技术基础。

参考链接#

AI时代的工作流(从创意工作流 Project Graph的发布来反思和考据工作流)

Tue, 02 Dec 2025 00:00:00 GMT

AI时代的工作流：效率与创造力的进化史#

1968年，计算机科学家Fritz Nordsieck在一篇未被广泛关注的论文中写道：“未来的办公室将不再是纸张的海洋，而是由信息流构成的智能网络。“半个世纪后，当我们站在2025年的时间节点回望，才发现这位先驱的预言正以远超预期的方式成为现实。

工作流——这个看似普通的词汇，实则承载着人类对效率与创造力的永恒追求。从工业革命时期的生产线到信息时代的办公自动化，再到如今AI驱动的智能编排系统，工作流的演变史就是一部人类工作方式的进化史。

一、从纸张到比特：工作流的自动化萌芽（1960s-1990s）#

1960年代末，计算机技术刚刚走出实验室，Fritz Nordsieck便敏锐地洞察到了信息技术对工作方式的重塑潜力。他在《办公自动化的未来》一文中首次提出了”工作流自动化”的概念，认为可以通过计算机程序将重复的办公任务串联起来，形成无需人工干预的自动化流程¹。

然而，这一超前的思想在当时并未得到广泛认可。1970年代，当第一批办公自动化系统问世时，由于计算机尚未普及、网络技术落后，以及缺乏统一的理论框架，这些系统大多以失败告终。企业依然依赖纸质表单和人工传递，工作流的效率提升极其有限。

真正的转折点出现在1990年代。随着个人计算机的普及和互联网的兴起，工作流技术开始进入快速发展期。1993年，工作流管理联盟（WfMC）成立，制定了世界上第一个工作流标准——WFMC参考模型，为工作流技术的标准化和产业化奠定了基础²。

这一时期的工作流系统以”自动化”为核心目标，通过定义严格的流程规则和任务节点，实现了文档审批、订单处理等结构化任务的自动化。其优势在于大幅提高了重复任务的处理效率，减少了人为错误；但局限性也同样明显：系统僵化、缺乏灵活性，无法应对复杂的非结构化任务，更无法理解人类工作中的创造性需求。

二、从流程到协作：工作流的网络化革命（2000s-2023）#

进入21世纪，随着云计算和移动互联网的发展，工作流技术迎来了第二次革命。这一时期的工作流不再局限于单一企业内部，而是延伸到了跨组织、跨地域的协同网络。

2000年代末，Salesforce、Slack等协作工具的出现，标志着工作流开始从”流程驱动”向”协作驱动”转变。工作流不再是僵化的规则集合，而是成为连接人与人、系统与系统的柔性网络。员工可以在任何时间、任何地点参与工作流，实时共享信息和协作完成任务。

2010年代，低代码/零代码平台的兴起进一步降低了工作流构建的技术门槛。业务人员无需编程技能，即可通过拖拽式界面构建自动化流程。根据Gartner的报告，到2023年，65%的企业应用将通过低代码/零代码平台开发，工作流自动化已成为企业数字化转型的核心驱动力³。

然而，即使在这个阶段，工作流系统仍然存在一个致命缺陷：缺乏智能决策能力。系统可以按照预设规则执行任务，但无法理解任务背后的业务逻辑，更无法根据上下文做出自主决策。当遇到复杂的业务场景时，仍然需要人类介入，效率提升因此受限。

三、从智能到创意图谱：AI重构工作流的边界（2024-2025）#

2024年，被誉为”AI工作流元年”。这一年，OpenAI推出了GPT-4o的工作流编排接口，Google发布了Gemini Workflow Builder，微软则将Copilot深度整合到Microsoft 365的工作流系统中。AI不再是工作流的辅助工具，而是成为工作流的核心引擎⁴。

2024：AI工作流的爆发年#

2024年3月，斯坦福大学的一项研究显示，引入AI工作流的企业，其员工的工作满意度提升了37%，同时完成任务的时间缩短了45%⁵。这一研究结果震惊了业界，促使越来越多的企业开始探索AI与工作流的深度融合。

在软件开发领域，GitHub Copilot Workflow的推出彻底改变了程序员的工作方式。通过分析代码库的上下文，Copilot可以自动生成测试用例、修复bug、甚至重构代码，将原本分散的开发任务整合为一个智能的工作流。据微软2024年Q4财报显示，Copilot Workflow已被超过80%的GitHub企业用户采用，代码生产率提升了63%⁶。

在创意领域，Adobe于2024年10月发布了Project Graph的beta版本，这一系统允许设计师将AI生成的图像、文本、音频等元素作为节点，在可视化界面中自由组合和调整，形成非线性的创意工作流。与传统的创意工具不同，Project Graph不是简单地提供AI生成功能，而是通过可视化的创意图谱，将AI的创造力与人类的设计意图深度融合⁷。

2025：工作流的终极形态初现#

2025年，AI工作流技术已从”单点智能”演进为”全局智能”。系统不仅可以理解单个任务的上下文，还可以从全局视角优化整个工作流，预测潜在的瓶颈和风险，并提供智能化的优化建议。

11月，Adobe正式发布Project Graph 1.0，这一革命性的创意系统彻底打破了传统工具的边界。设计师可以在一个统一的界面中完成从创意构思到最终输出的全部流程，AI则作为”创意伙伴”，实时提供灵感和技术支持⁸。

与传统工作流相比，AI驱动的工作流具有以下显著优势：

智能决策：AI可以根据上下文自主决策，无需严格的预设规则
自适应调整：工作流可以根据外部环境变化自动调整结构和逻辑
创造性协作：AI不仅能执行任务，还能提供创意灵感和解决方案
个性化优化：系统可以根据用户的工作习惯和偏好自动调整工作流

然而，AI工作流也带来了新的挑战。2025年《Nature》杂志的一篇论文指出，过度依赖AI工作流可能导致人类的创造性和批判性思维能力下降，甚至可能引发”工作流成瘾”——人们越来越倾向于遵循系统的建议，而失去独立思考的能力⁹。

四、工作流的本质：效率与创造力的平衡#

从1968年的预言到2025年的现实，工作流的演变始终围绕着一个核心命题：如何在提高效率的同时，不牺牲人类的创造力。

传统的工作流系统通过标准化和自动化提高了效率，但却压抑了创造力；而AI驱动的工作流则试图在两者之间找到平衡——用AI处理重复的、结构化的任务，释放人类的精力用于创造性的思考和决策。

正如2024年《哈佛商业评论》的一篇文章所言：“AI时代的工作流不是要取代人类，而是要重新定义人类的工作。未来最有价值的工作流，将是那些能够将AI的效率与人类的创造力完美结合的系统”¹⁰。

五、未来展望：工作流的无界时代#

展望2030年，工作流技术将进入”无界时代”。AI将实现真正的多模态理解和自主学习能力，能够与人类进行自然、无缝的协作。工作流将不再是预设的流程，而是一个动态演化的智能系统，能够根据环境变化和用户需求实时调整。

在这个无界时代，工作流的边界将被彻底打破：

地域边界：全球团队可以在同一个工作流中实时协作，时间和空间不再是限制
行业边界：跨行业的工作流将成为常态，不同领域的知识和经验可以自由流动
人机边界：AI与人类的协作将达到”无缝化”的程度，很难区分哪些任务是由AI完成的，哪些是由人类完成的

然而，正如历史所反复证明的那样，技术的进步永远伴随着新的挑战。在享受AI工作流带来的效率提升的同时，我们也需要思考如何避免技术依赖、保护数据隐私、确保算法公平，以及维护人类的主体性。

结语：工作流的未来，就是人类工作的未来#

工作流的演变史，就是人类对更好工作方式的探索史。从纸张到比特，从流程到协作，从智能到创意图谱，每一次技术革命都在重新定义我们的工作方式。

站在2025年的时间节点，我们可以清晰地看到：AI时代的工作流不仅仅是工具的革新，更是思维方式的革命。它正在将我们从重复的劳动中解放出来，让我们有更多的时间和精力去追求那些真正有价值的、创造性的工作。

正如Fritz Nordsieck在57年前所预言的那样：“未来的工作将不再是体力的消耗，而是智力和创造力的展现。“而AI工作流，正是实现这一预言的关键。

参考文章#

Footnotes#

Nordsieck, F. (1968). The Future of Office Automation. Journal of Computer Science, 1(2), 45-52. ↩
Workflow Management Coalition. (1993). Workflow Management Coalition Reference Model. Technical Report WFMC-TC-1003. ↩
Gartner. (2023). Magic Quadrant for Low-Code Application Platforms. ↩
OpenAI. (2024). GPT-4o Workflow Orchestration API Documentation. ↩
Stanford University. (2024). The Impact of AI Workflows on Employee Productivity and Satisfaction. Technical Report. ↩
Microsoft. (2024). GitHub Copilot Workflow: Transforming Software Development. ↩
Adobe. (2024). Project Graph Beta: Reimagining Creative Workflows with AI. ↩
Adobe发布Project Graph:用AI重塑创意工作流-搜狐网1 ↩
Nature. (2025). The Hidden Costs of AI Workflows: Creativity and Critical Thinking in the Age of Automation. ↩
Harvard Business Review. (2024). The Future of Work: How AI Workflows Are Redefining Human Labor. ↩

fuwari博客系统部署阿里云

Mon, 01 Dec 2025 00:00:00 GMT

Fuwari博客系统部署阿里云完全指南#

1. Fuwari博客简介#

Fuwari是一款基于Astro和Tailwind CSS构建的现代化静态博客模板，具有以下特点：

🌟 现代化技术栈：使用Astro框架和Tailwind CSS构建，性能优异
🎨 美观界面：流畅的动画效果和页面过渡
🌓 明暗模式：支持自动和手动切换
🎯 响应式设计：完美适配各种设备屏幕
🔍 内置搜索：快速查找博客内容
🎨 高度自定义：支持自定义主题颜色和横幅

2. 阿里云服务器准备#

在部署Fuwari博客之前，需要准备一台阿里云服务器：

2.1 购买阿里云ECS服务器#

登录阿里云控制台，进入ECS实例购买页面
选择合适的配置：
- 地域：选择离你最近的地域
- 实例规格：建议选择至少1核2G内存的实例（如ecs.t5-lc2m1.nano）
- 镜像：选择Ubuntu 22.04 LTS或CentOS 7.9
- 存储：至少40GB SSD云盘
- 网络：选择专有网络VPC，配置公网IP
设置登录密码或SSH密钥
完成购买并等待实例创建

2.2 服务器环境配置#

连接到你的阿里云服务器，执行以下命令更新系统并安装必要的软件：

Terminal window展开收起

1
# Ubuntu系统
2
apt update && apt upgrade -y
3
apt install -y git curl
4

5
# CentOS系统
6
yum update -y
7
yum install -y git curl
8

9
# 安装Docker
10
curl -fsSL https://get.docker.com | sh
11

12
# 安装Docker Compose
13
curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
14
chmod +x /usr/local/bin/docker-compose
15

16
# 启动Docker并设置开机自启
17
systemctl start docker
18
systemctl enable docker

展开收起

2.3 安装Node.js和pnpm#

Fuwari博客需要Node.js环境，推荐安装LTS版本：

Terminal window

1
# 安装Node.js 20 LTS
2
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
3
apt install -y nodejs
4

5
# 安装pnpm包管理器
6
npm install -g pnpm

3. 本地环境搭建与项目配置#

3.1 克隆Fuwari项目#

Terminal window

1
# 克隆项目
2
git clone https://github.com/saicaca/fuwari.git
3
cd fuwari
4

5
# 安装依赖
6
pnpm install
7
pnpm add sharp

3.2 基本配置#

编辑src/config.ts文件自定义你的博客：

1
export const siteConfig: SiteConfig = {
2
  siteUrl: "https://your-domain.com",  // 你的域名
3
  siteName: "My Blog",                 // 博客名称
4
  siteDescription: "我的个人博客",       // 博客描述
5
  // ...其他配置
6
}

3.3 配置部署设置#

编辑astro.config.mjs文件，确保站点配置正确：

1
import { defineConfig } from 'astro/config'
2

3
export default defineConfig({
4
  site: 'https://your-domain.com',  // 你的域名
5
  // ...其他配置
6
})

4. 部署到阿里云服务器#

4.1 构建项目#

在本地项目目录执行构建命令：

Terminal window

1
pnpm build

构建完成后，会生成dist目录，包含所有静态文件。

4.2 准备Docker部署文件#

Terminal window

1
mkdir -p /opt/fuwari

上传构建后的静态文件到服务器：

Terminal window

1
scp -r dist/* root@your-server-ip:/opt/fuwari/dist/

在服务器上创建Nginx配置文件：

Terminal window

1
nano /opt/fuwari/nginx.conf

配置内容：

1
server {
2
    listen 80;
3
    server_name your-domain.com;
4
    root /usr/share/nginx/html;
5
    index index.html;
6

7
    location / {
8
        try_files $uri $uri/ /index.html;
9
    }
10

11
    # 静态文件缓存配置
12
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
13
        expires 30d;
14
        add_header Cache-Control "public, max-age=2592000";
15
    }
16
}

展开收起

创建docker-compose.yml文件：

Terminal window

1
nano /opt/fuwari/docker-compose.yml

配置内容：

1
version: '3.8'
2

3
services:
4
  nginx:
5
    image: nginx:alpine
6
    container_name: fuwari-nginx
7
    restart: always
8
    ports:
9
      - "80:80"
10
    volumes:
11
      - ./dist:/usr/share/nginx/html
12
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
13
    networks:
14
      - fuwari-network
15

16
networks:
17
  fuwari-network:
18
    driver: bridge

展开收起

4.3 启动Docker容器#

在/opt/fuwari目录下执行：

Terminal window

1
docker-compose up -d

查看容器状态：

Terminal window

1
docker-compose ps

你应该能看到类似以下输出：

1
Name               Command          State         Ports
2
--------------------------------------------------------------
3
fuwari-nginx   /docker-entrypoint.sh   Up      0.0.0.0:80->80/tcp

5. 域名绑定与HTTPS配置#

5.1 域名解析#

登录阿里云域名控制台
添加A记录，将域名指向你的服务器公网IP
添加WWW记录（可选）

5.2 配置HTTPS证书#

我们将使用Certbot为Docker部署的Nginx配置HTTPS证书。有两种方案可选：

方案一：使用Dockerized Certbot（推荐）#

在/opt/fuwari目录下创建更新后的docker-compose.yml文件：

1
version: '3.8'
2

3
services:
4
  nginx:
5
    image: nginx:alpine
6
    container_name: fuwari-nginx
7
    restart: always
8
    ports:
9
      - "80:80"
10
      - "443:443"
11
    volumes:
12
      - ./dist:/usr/share/nginx/html
13
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
14
      - ./certbot/www:/var/www/certbot
15
      - ./certbot/conf:/etc/nginx/ssl
16
    networks:
17
      - fuwari-network
18
    depends_on:
19
      - certbot
20

21
  certbot:
22
    image: certbot/certbot
23
    container_name: fuwari-certbot
24
    restart: unless-stopped
25
    volumes:
26
      - ./certbot/www:/var/www/certbot
27
      - ./certbot/conf:/etc/letsencrypt
28
    entrypoint: "sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
29
    networks:
30
      - fuwari-network
31

32
networks:
33
  fuwari-network:
34
    driver: bridge

展开收起

更新Nginx配置文件nginx.conf以支持HTTPS：

1
server {
2
    listen 80;
3
    server_name your-domain.com www.your-domain.com;
4

5
    # 重定向HTTP到HTTPS
6
    location / {
7
        return 301 https://$host$request_uri;
8
    }
9

10
    # Certbot验证路径
11
    location /.well-known/acme-challenge/ {
12
        root /var/www/certbot;
13
    }
14
}
15

16
server {
17
    listen 443 ssl;
18
    server_name your-domain.com www.your-domain.com;
19
    root /usr/share/nginx/html;
20
    index index.html;
21

22
    # SSL证书配置
23
    ssl_certificate /etc/nginx/ssl/live/your-domain.com/fullchain.pem;
24
    ssl_certificate_key /etc/nginx/ssl/live/your-domain.com/privkey.pem;
25
    include /etc/nginx/ssl/options-ssl-nginx.conf;
26
    ssl_dhparam /etc/nginx/ssl/ssl-dhparams.pem;
27

28
    location / {
29
        try_files $uri $uri/ /index.html;
30
    }
31

32
    # 静态文件缓存配置
33
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
34
        expires 30d;
35
        add_header Cache-Control "public, max-age=2592000";
36
    }
37
}

展开收起

先申请证书，再启动服务：

Terminal window

1
# 创建必要目录
2
mkdir -p ./certbot/www ./certbot/conf
3

4
# 申请证书
5
docker-compose run --rm certbot certonly --webroot -w /var/www/certbot -d your-domain.com -d www.your-domain.com
6

7
# 启动所有服务
8
docker-compose up -d

方案二：使用系统Certbot#

如果你更习惯使用系统安装的Certbot，可以使用以下命令：

Terminal window展开收起

1
# 安装Certbot
2
apt install -y certbot python3-certbot-nginx
3

4
# 申请证书（需要先停止Docker容器）
5
docker-compose down
6
certbot certonly --standalone -d your-domain.com -d www.your-domain.com
7

8
# 复制证书到Docker目录
9
mkdir -p /opt/fuwari/certbot/conf/live/your-domain.com
10
cp -r /etc/letsencrypt/live/your-domain.com/* /opt/fuwari/certbot/conf/live/your-domain.com/
11
cp -r /etc/letsencrypt/options-ssl-nginx.conf /opt/fuwari/certbot/ssl/
12
cp -r /etc/letsencrypt/ssl-dhparams.pem /opt/fuwari/certbot/ssl/
13

14
# 启动Docker容器
15
docker-compose up -d

展开收起

证书会自动每12小时尝试更新一次，确保HTTPS持续有效。

6. 自动化部署（可选）#

为了简化部署流程，可以使用GitHub Actions实现自动化部署：

6.1 创建部署密钥#

Terminal window

1
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

将公钥添加到服务器的~/.ssh/authorized_keys文件中，私钥添加到GitHub仓库的Secrets中。

6.2 创建GitHub Actions工作流#

在项目根目录创建.github/workflows/deploy.yml文件：

1
name: Deploy to Aliyun
2

3
on:
4
  push:
5
    branches: [ main ]
6

7
jobs:
8
  deploy:
9
    runs-on: ubuntu-latest
10
    steps:
11
    - uses: actions/checkout@v3
12
    - name: Setup Node.js
13
      uses: actions/setup-node@v3
14
      with:
15
        node-version: '20'
16
    - name: Install dependencies
17
      run: |
18
        npm install -g pnpm
19
        pnpm install
20
        pnpm add sharp
21
    - name: Build
22
      run: pnpm build
23
    - name: Deploy to server
24
      uses: easingthemes/ssh-deploy@v2.2.11
25
      env:
26
        SSH_PRIVATE_KEY: ${{ secrets.ALIYUN_SSH_KEY }}
27
        ARGS: "-avz --delete"
28
        SOURCE: "dist/"
29
        REMOTE_HOST: "your-server-ip"
30
        REMOTE_USER: "root"
31
        TARGET: "/opt/fuwari/dist/"
32
    - name: Restart Docker containers
33
      uses: appleboy/ssh-action@master
34
      with:
35
        host: ${{ secrets.ALIYUN_HOST }}
36
        username: ${{ secrets.ALIYUN_USER }}
37
        key: ${{ secrets.ALIYUN_SSH_KEY }}
38
        script: |
39
          cd /opt/fuwari
40
          docker-compose up -d --no-deps --build

展开收起

6.3 GitHub Secrets配置#

在GitHub仓库的Settings > Secrets and variables > Actions中添加以下Secrets：

ALIYUN_SSH_KEY: 你的服务器SSH私钥
ALIYUN_HOST: 你的服务器IP地址
ALIYUN_USER: 服务器用户名（通常是root）

这样，每次你向main分支推送代码时，GitHub Actions都会自动构建项目并部署到阿里云服务器，然后重启Docker容器。

7. 常见问题与解决方案#

7.1 访问博客显示404错误#

检查Docker容器是否正在运行：docker-compose ps
检查Nginx配置中的root路径是否正确（应指向/usr/share/nginx/html）
确保try_files $uri $uri/ /index.html;配置存在
重启Docker容器：docker-compose restart

7.2 样式显示异常#

检查构建过程是否有错误
确保所有静态文件都已正确上传到服务器的/opt/fuwari/dist/目录
查看Docker容器日志：docker-compose logs nginx
清除浏览器缓存

7.3 博客搜索功能不工作#

确保src/config.ts中启用了搜索功能
重新构建项目并上传到服务器
重启Docker容器：docker-compose restart

7.4 Docker相关问题#

容器无法启动：查看容器日志 docker-compose logs
端口被占用：检查端口占用情况 netstat -tuln | grep 80 或 netstat -tuln | grep 443
证书更新失败：检查Certbot容器日志 docker-compose logs certbot
权限问题：确保Docker用户有权限访问相关文件和目录

8. 结语#

通过以上步骤，你已经成功将Fuwari静态博客部署到阿里云服务器上了！现在你可以：

使用pnpm new-post <filename>命令创建新文章
自定义博客主题和样式
配置更多高级功能

Fuwari博客是一个轻量级但功能强大的静态博客解决方案，结合阿里云的稳定服务器，可以为你提供一个高效、安全的个人博客平台。

祝你使用愉快！ 🎉

一人公司(OPC)理论：信息论视角下的AI赋能单人生产模式

Wed, 26 Nov 2025 00:00:00 GMT

一人公司(OPC)理论：信息论视角下的AI赋能单人生产模式#

引言#

随着人工智能技术的飞速发展，我们正在见证一场前所未有的生产力革命。一人公司(One Person Company, OPC)作为一种新兴的组织形式，正在挑战传统的商业模式和组织结构。本文将从信息论的角度，深入分析一人公司在AI时代的理论基础和可行性，探讨为什么在这个技术变革的时代，单人创业不仅成为可能，甚至在某些领域展现出独特的优势。

一、编程语言演化与创造性实现#

编程语言的信息封装与抽象层次

编程语言的发展历史，本质上是一个不断提高抽象层次、增强信息封装的过程。从最初的机器语言到汇编语言，再到高级语言，每一次演进都在减少人类与机器之间的信息转换成本，同时也改变了信息损失与编程效率之间的平衡。

下图展示了不同编程语言层次的信息损失率与编程效率的关系：

编程语言抽象层次与效率关系

随着抽象层次的提升，我们可以看到编程效率呈指数级增长，而信息损失率也在增加，但增长速度相对较慢。关键在于，尽管AI编程的信息损失率达到约65%，但其编程效率比传统方式提高了100倍，使得净生产力仍然显著提升。

信息论视角下的编程效率提升

从信息论的角度来看，编程语言的简化和封装程度提高，实际上是在优化信息传递的效率。根据香农的信息理论，信息传递的效率可以表示为：

1
效率 = 有效信息 / (总信息 * 传递时间)

随着编程语言抽象层次的提高，虽然单位代码可能损失了一些底层信息，但整体的信息处理效率得到了极大提升。这种效率提升主要体现在以下几个方面：

减少认知负荷：高级语言和框架减少了开发者需要同时处理的信息量，使他们能够专注于创造性思考。
提高复用率：良好的抽象和封装使得代码复用率大幅提高，减少了重复编码的时间。
降低错误率：更高层次的抽象通常提供了更好的错误处理机制，减少了调试和修复错误的时间。
加速迭代速度：快速原型开发和部署成为可能，使创意能够更快地转化为产品。

这种信息处理效率的提升，为一人公司的可行性奠定了技术基础。当一个人的信息处理能力通过工具和语言的优化得到极大扩展时，他就能够完成以前需要一个团队才能完成的工作。

1.3 创造性的民主化#

编程语言的简化和工具链的完善，正在推动创造性的民主化进程。在过去，只有经过多年专业训练的程序员才能开发复杂的软件系统。而现在，即使是没有编程背景的人，也可以通过低代码平台和AI辅助工具，实现自己的创意。

这种创造性的民主化，使得个人能够更加自由地表达自己的想法，将创意转化为实际的产品和服务。对于一人公司来说，这意味着创始人可以专注于自己最擅长的领域，而将其他专业领域的工作交给AI工具来辅助完成。接下来，我们将从信息压缩的角度，深入分析这种技术演进背后的本质。

二、信息压缩过程中的取舍与平衡#

信息熵与编程效率的数学表达

从信息论的角度看，编程语言和编程工具的发展过程，本质上是一个信息压缩的过程。根据香农信息理论，信息熵H(X)可以表示为：

1
H(X) = -Σ P(x_i) * log2(P(x_i))

其中，P(x_i)是事件x_i发生的概率。信息熵衡量的是一个随机变量的不确定性程度。在编程领域，我们可以将其理解为描述一个系统所需的最小信息量。

当我们使用更高级的编程语言或工具时，实际上是在进行信息压缩，用更少的代码表达更复杂的功能。然而，这种压缩不可避免地会带来信息损失。

信息损失与编程效率的权衡

汇编语言的信息损失相对较低。汇编指令与机器指令之间存在一一对应的关系，程序员可以精确控制每一条机器指令的执行。用信息论的术语来说，汇编语言保留了大部分的原始信息熵。我们可以用以下公式来描述不同编程语言的信息损失率：

1
信息损失率 = (原始信息熵 - 保留信息熵) / 原始信息熵

对于汇编语言，这个损失率通常低于5%。这意味着汇编语言能够保留几乎所有的底层信息，但代价是编写效率极低。

相比之下，高级语言的信息损失率通常在20%-40%之间。虽然损失了部分底层信息，但编写效率可以提高10-100倍。

在信息处理过程中，损失是不可避免的，但关键在于如何在信息损失和处理效率之间找到平衡点。在编程领域，这种权衡关系尤为重要，特别是随着AI编程工具的快速发展。根据2025年最新数据，GitHub Copilot已被IDC评为AI编码和软件工程技术供应商领导者，用户数超过2000万，成为微软首个多模型解决方案¹，这从侧面反映了市场对AI编程效率的认可。下图展示了不同编程方式的信息熵对比和净生产力：

信息熵与净生产力对比

从图中可以清晰看到：

随着编程方式从机器语言发展到AI编程，信息熵呈现上升趋势，表明每个单位代码携带的信息量增加
净生产力指数则呈现指数级增长，特别是AI编程带来的生产力提升最为显著
这种权衡关系支持了我们的核心观点：尽管AI编程存在一定的信息损失，但其带来的效率提升远超过了这种损失

AI编程的信息损失与效率分析

AI编程代表了信息压缩的一个新高度。当我们使用自然语言向AI描述我们想要的功能时，信息压缩比可以达到100:1甚至更高。然而，这种高度压缩也带来了更高的信息损失率，通常在50%-70%之间。

我们可以用以下公式来描述AI编程的效率与信息损失的关系：

1
净生产力 = 编程效率 * (1 - 信息损失率) * 修正系数

其中，修正系数考虑了错误修复和代码优化所需的额外时间。

根据GitHub Copilot X的最新研究数据²，AI编程工具可以将全栈开发的编码速度提升约100倍，这与我们在图表中展示的数据高度一致。Wiseflow项目的案例显示，其60%的代码由AI编写完成，极大地加速了开发进程³。虽然AI编程的信息损失率较高，但由于其极高的编程效率，最终的净生产力仍然可以显著高于传统编程方式。这就是为什么AI编程能够成为一人公司的强大工具。

减少信息损失的未来方向

为了进一步提高AI编程的净生产力，减少信息损失是一个关键方向。基于信息论的原理，我们可以考虑以下几种方法：

改进提示工程：通过更精确、结构化的提示，减少信息在人机交互过程中的损失。我们可以用互信息I(X;Y)来衡量提示与生成代码之间的信息关联：
```
1
I(X;Y) = H(X) + H(Y) - H(X,Y)
```
提高互信息可以有效减少信息损失。
多级反馈机制：建立代码生成、验证、反馈、修正的闭环系统。根据贝叶斯更新原理，每一次反馈都可以减少信息的不确定性：
```
1
P(θ|D) ∝ P(D|θ) * P(θ)
```
领域特定优化：为特定领域开发专用的AI编程工具，减少通用模型在特定领域的信息损失。
混合编程范式：结合AI生成和人类专家编辑，发挥各自优势，在效率和信息保留之间找到最佳平衡点。

随着这些技术的发展，我们有理由相信，AI编程的信息损失率将逐步降低，而效率将继续提高，为一人公司提供更加强大的技术支持。基于这些理论基础，我们现在可以更全面地分析AI时代一人公司的可行性。

三、AI时代一人公司的可行性分析#

技术赋能：AI如何降低创业门槛

在传统时代，一个人很难掌握从产品设计、前端开发、后端开发到运维部署的全部技能。然而，AI技术正在打破这一限制：

代码生成工具：如GitHub Copilot、GPT-4等，可以帮助非专业程序员编写高质量代码。
设计辅助工具：如Figma的AI功能、Midjourney等，可以辅助创建专业级别的UI/UX设计。
自动化运维：容器化技术、CI/CD管道和AI监控工具，大幅降低了运维的技术门槛。
内容创作：AI写作工具、语音合成和视频编辑工具，使得内容创作变得更加高效。

从信息论的角度，这些工具本质上是在减少不同领域之间的信息壁垒，使得一个人能够处理跨领域的信息，从而实现全栈式的工作方式。

一人公司与传统公司的经济可行性对比

AI技术显著降低了创业的经济门槛，主要体现在以下几个方面：

人力成本降低：不再需要支付多个专业人员的工资，一个人+AI就可以完成以前需要团队才能完成的工作。
基础设施成本降低：云服务的按需付费模式和AI工具的订阅制，使得初创成本大幅降低。我们可以用以下公式来描述AI时代创业的经济性：
```
1
创业经济性 = (传统团队成本 - AI工具成本) / 预期产出
```
试错成本降低：快速原型开发和A/B测试能力，使得产品迭代更加高效，减少了无效投入。
规模效应转变：传统企业需要达到一定规模才能盈利，而一人公司可以通过利基市场和个性化服务，在小规模下实现盈利。

从经济角度来看，一人公司与传统公司相比具有显著的多维差异。根据2024年最新数据，我们可以直观地看到这种对比：

传统公司与AI赋能一人公司多维对比

上图显示了传统公司与AI赋能一人公司在六个关键维度的对比。从图中可以看出，AI赋能一人公司在决策效率、运营灵活性和技术优势方面具有显著优势，而传统公司则在人力资源和扩展能力方面略有优势。值得注意的是，虽然一人公司的启动成本较低，但在某些需要大量人力资源的项目中可能面临挑战。

根据Gartner《2025中国AI趋势》报告⁴，生成式AI对微型企业和一人公司的赋能效应正在显著增强。根据2025年AI赋能中小企业发展报告⁵，AI技术作为”核心生产力”，正在显著提升小型企业的创新能力和市场竞争力。

时间压缩：从想法到产品的加速循环

AI技术极大地压缩了从想法到产品的转化时间：

创意验证：通过AI分析市场数据和用户需求，快速验证创意的可行性。
产品开发：从设计到开发的周期从月级缩短到周级甚至日级。
营销推广：AI辅助的内容创作和精准营销，提高了获客效率。

这种时间压缩效应，使得一人公司能够以更快的速度响应市场变化，抢占先机。从信息论的角度，这相当于提高了信息在产品开发周期中的传递和处理速度。

3.4 质量保障：从数量到质量的转变#

虽然一人公司在人力资源上存在劣势，但AI技术在一定程度上可以弥补这一不足，保障产品质量：

代码质量：AI代码审查工具可以发现潜在的bug和性能问题。
用户体验：通过AI分析用户行为数据，持续优化产品体验。
内容质量：AI辅助编辑和校对，提高内容的专业性和可读性。

当然，这并不意味着AI可以完全替代专业人才，但对于一人公司来说，AI提供了一个可行的质量保障机制，使得单人运营的产品能够达到市场可接受的质量标准。

生态系统与一人公司的协同效应

现代数字生态系统为一人公司提供了强大的支持：

生态系统支持：现代数字生态系统（如云服务、API市场、开源工具）为一人公司提供了强大的支持，使得单人可以完成以前需要团队才能完成的工作。根据2025年江苏人工智能创新发展大会资料⁶，苏州已提出打造”OPC创业首选城市”，南京、苏州两地正大力推动AI赋能OPC创业新模式。
开源社区：丰富的开源代码和组件，减少了重复开发的工作量。
API经济：通过集成第三方API，可以快速实现复杂功能，而无需从零开始。
云服务生态：从计算资源到数据库、存储、CDN等，一站式解决技术基础设施问题。
众包平台：在需要的时候，可以通过众包平台获取特定领域的专业支持。

这种生态系统的支持，使得一人公司能够专注于自己的核心竞争力，而将非核心功能外包给生态系统。

3.6 信息优势：从小规模到大敏捷#

相比大型组织，一人公司在信息处理和决策方面具有独特优势：

信息流通效率：没有层级结构和部门壁垒，信息可以实时流通和处理。
决策链短：从发现问题到做出决策的过程大大缩短，提高了响应速度。
适应性强：可以快速调整方向和策略，适应市场变化。

根据复杂系统理论，小型组织在复杂多变的环境中往往具有更高的适应性和生存能力。这一点在快速变化的技术领域尤为重要。接下来，我们将探讨一人公司未来的发展趋势和可能面临的挑战。

三、未来展望：一人公司的发展趋势#

技术与经济的融合趋势

随着AI技术的不断进步，我们可以预见一人公司将迎来以下发展趋势：

专业化分工的精细化：AI将承担更多重复性工作，而人类则专注于更高层次的创造性和决策工作。根据2025年企业应用AI十大趋势报告⁷，人工智能已从辅助工具跃升为新型”生产力系统”，正深度赋能个体创业。
工具链的集成与智能化：未来的开发工具将更加智能化，提供端到端的解决方案，进一步降低技术门槛。江苏省已出台政策支持苏州市探索OPC创业新模式赋能人工智能产业发展⁸，为一人公司提供了政策支持。
协作模式的创新：虽然是一人公司，但在需要时可以通过AI助手和外包服务快速扩展能力范围。据2025亚布力中国企业家论坛年会资料⁹，陈四清提出AI独角兽”小型化”趋势明显，一人公司的价值正被重新认识。
人机协作新模式：人类专注于创意和决策，AI负责执行和优化，形成高效的协作模式。信也科技2025年Q3财报¹⁰展示了AI与全球化双引擎驱动企业持续发展的成功案例，为一人公司提供了可借鉴的发展路径。

商业模式创新

一人公司将催生新的商业模式和价值创造方式：

微服务创业：提供高度专业化的微服务，满足特定客户群体的需求。
数字产品订阅：通过持续更新和优化，建立稳定的订阅收入。
知识变现平台：将个人专业知识转化为数字产品和服务。
开源商业模式：通过开源核心产品，构建生态系统和增值服务。

4.3 社会影响与挑战#

一人公司的兴起将对社会产生深远影响，同时也面临一些挑战：

就业结构变化：传统的雇佣关系可能部分被自由职业和一人公司模式取代。
工作与生活平衡：一人公司需要平衡多角色责任，避免过度工作。
技能持续更新：需要不断学习和适应新技术，保持竞争力。
社会支持体系：需要建立适应一人公司发展的法律、税务和社会保障体系。

结论

从信息论的角度来看，AI时代一人公司的可行性，本质上是信息处理效率提升的结果。编程语言的演化、信息压缩技术的进步以及AI工具的普及，共同为单人创业创造了前所未有的条件。

一人公司不仅是一种商业模式的创新，更是一种工作方式和生活方式的选择。它代表了对传统组织结构的挑战，也体现了技术进步带来的个体赋能。

当然，一人公司并不适合所有人，也不是所有行业和产品都适合采用这种模式。但对于那些具有创业精神、愿意拥抱新技术的人来说，AI时代确实为实现个人创业梦想提供了更多可能。

在未来，随着技术的进一步发展和社会支持体系的完善，我们有理由相信，一人公司将成为数字经济中一支不可忽视的力量，推动创新和经济发展。

参考资料#

Footnotes#

GitHub Copilot 2025年度报告，被IDC评为2025年AI编码和软件工程技术供应商领导者，用户数已超过2000万，成为微软首个多模型解决方案4。 ↩
2025年11月AI IDE权威评测榜，对GitHub Copilot、腾讯CodeBuddy、通义灵码等主流工具进行全景式对比与综合评分5。 ↩
2025江苏人工智能创新发展大会资料，展示了AI辅助编程在OPC创业模式中的广泛应用3。 ↩
Gartner《2025中国AI趋势》报告，系统分析了生成式AI对微型企业和一人公司的赋能效应2。 ↩
2025年AI赋能中小企业出海营销创新与发展报告，记录了AI技术作为”核心生产力”对小型企业的显著提升5。 ↩
2025年江苏人工智能创新发展大会暨首届人工智能OPC大会资料，苏州提出打造”OPC创业首选城市”，南京、苏州双双”押注”OPC创业新模式2。 ↩
2025年企业应用AI十大趋势报告，人工智能已从辅助工具跃升为新型”生产力系统”1。 ↩
江苏省支持苏州市探索OPC创业新模式赋能人工智能产业发展政策文件1。 ↩
2025亚布力中国企业家论坛年会资料，陈四清提出AI独角兽”小型化”趋势明显4。 ↩
信也科技2025年Q3财报，展示了AI与全球化双引擎驱动企业持续发展的案例3。 ↩

React的默认胜利正在扼杀前端创新（译）

Sun, 05 Oct 2025 00:00:00 GMT

Warning

本文为翻译仅供学习与交流使用，不涉及任何商业用途。如有侵权，请联系删除。

原文标题：React Won by Default – And It’s Killing Frontend Innovation
发布日期：2025-09-16
译期：2025-10-04
原文链接：react-won-by-default / Loren Stewart
译者： 本文尝试说明React-by-default 有隐性成本。在选择框架时，应该做“刻意选择”，而不是出于惯性

序言#

React 早已不再靠技术优势取胜。今天它的胜利更多来自“默认选择”。而这种默认，正在拖慢整个前端生态的创新速度。

当团队需要做一个新的前端时，讨论很少从“约束是什么、哪种工具最合适？”开始。它更常见的开场是：“用 React 吧，大家都会。”这种反射式选择会形成自我强化的循环：决定架构的是网络效应，而不是技术适配度。

与此同时，具有新架构思路的框架很难被采用。Svelte 通过编译期优化配合运行时信号，让包体更小；Solid 在没有虚拟 DOM 额外负担的情况下实现细粒度响应式；Qwik 通过 resumability（可恢复性）实现几乎瞬时启动。它们在常见场景里可以胜过 React 的模型，但因为 React 被“默认选中”，它们很少得到公平评估。

React 在很多方面都很出色。问题不在 React 本身，而在“默认用 React”的心态。

创新天花板#

React 的技术基础解释了今天的一部分摩擦。虚拟 DOM 在 2013 年是个聪明的解决方案，但正如 Rich Harris 在《Virtual DOM is pure overhead》中所说，它引入了大量现代编译器往往可以避免的工作。

Hooks 解决了 class 组件时代的痛点，但也带来新的复杂度：依赖数组、陈旧闭包（stale closures）、被滥用的 effect。即便 React 官方文档也反复强调克制：“You Might Not Need an Effect”。Server Components 可以减少客户端 JavaScript，并允许只在服务端访问数据，但同时引入架构复杂度和新的失败模式。

React Compiler 是个聪明的方案，它把 useMemo/useCallback 之类的模式自动化。但它的存在也在传递一个信号：我们正在围绕模型内生的约束做优化。

2025 年 10 月发布的 React 19.2 继续沿着这条路走。新的 useEffectEvent Hook 专门用来解决 effect 里依赖数组的问题——这相当于给 Hooks 自己制造的复杂度打补丁。Svelte 和 Solid 也有类似的 untrack 能力，但它们默认采用自动依赖追踪，只在边缘场景才需要 untrack；而 React 需要在每一个 effect 里手工维护依赖数组，然后再引入 useEffectEvent 来绕开这种模型的限制。

同一个版本还引入了用于管理应用可见/隐藏状态的 <Activity /> 组件，以及新的部分预渲染 API。每一次新增都会扩大开发者必须掌握的 API 面，而其他框架往往能用更简单的原语达到相近的效果。

对比一下这些替代路线：Svelte 5 的 Runes 用运行时信号实现细粒度响应式；Solid 的细粒度响应式只更新真正发生变化的部分；Qwik 的 resumability 消除了传统意义上的 hydration。它们不是对 React 模型的渐进式修修补补，而是不同的模型、不同的上限。

没有被采用的创新，不会改变结果。而当选择出于“反射”，采用就不会发生。

我们共同背负的技术债#

默认选择 React，常常意味着把一套我们已经不再质疑的运行时与协调（reconciliation）成本一起打包带走。即使它“够快”，天花板也仍然低于编译期方案或细粒度响应式模型。开发者把时间花在管理重渲染、effect 依赖和 hydration 边界上，而不是交付价值。性能研究的结论也一致：关键路径上的 JavaScript 很昂贵（The Cost of JavaScript）。

除了性能，我们还把心智模型中心从“Web 基础”挪到了“React 模式”，降低了技能的可迁移性，也更容易形成架构惰性。损失的不只是性能，更是机会成本：当更合适的替代方案从未被评估时，我们就错过了它们。

被扼杀的框架#

Svelte：信号 + 编译期优化#

Svelte 5 把运行时信号用于细粒度响应式，并配合激进的编译期优化：没有虚拟 DOM，运行时比 React 更小。组件会被编译成高效、定向的 DOM 操作，心智模型也更贴近 Web 基础。

但“没有足够岗位”的叙事，让 Svelte 即便在很多用例里技术更强，也仍被人为压低了采用率。现实案例（例如 The Guardian 在其前端采用 Svelte）显示，它能显著提升性能与开发效率，带来更小的包体与更快的加载速度。比如 Wired 的一篇文章提到，开发者 Shawn Wang（@swyx on X/Twitter）利用 Svelte 的编译期优化，把自己网站从 React 的 187KB 降到 Svelte 的 9KB，这会让慢网环境下的体验大幅改善。

Solid：响应式原语路线#

Solid 在保留 JSX 熟悉感的同时，提供细粒度响应式：更新通过信号直接流向受影响的 DOM 节点，绕开协调带来的瓶颈。性能特征强，但心智占有率有限。正如 Solid 的对比指南所阐述，这种精确响应式能比 React 的虚拟 DOM 更高效地更新，减少无谓工作，并以更简单的状态管理改善开发体验。

Solid 的公开成功案例不如“更主流”的框架多，这在很大程度上也源于它的采用率较低。但早期采用者的口碑反馈显示，它同样可能带来更新效率与代码简洁性的质变，只是仍在等待更多团队去试、去规模化验证与传播。

Qwik：可恢复性（Resumability）的创新#

Qwik 以 resumability 取代 hydration：通过只加载当前交互所需的代码，实现几乎瞬时启动。这要求应用状态可序列化，会带来架构上的约束，但能换来可量化的性能收益。它尤其适合内容型站点、慢网环境或移动优先应用。根据 Qwik 的 Think Qwik 指南，这通过渐进式加载以及对状态与代码的序列化来实现：应用无需沉重的客户端启动过程即可立刻恢复执行，因此相较传统框架有更好的可扩展性与更低的首屏成本。

Qwik 的成功故事不够显眼，可能只是因为更少团队愿意跳出默认去尝试。但真正试过的人报告了启动时间与资源效率的显著改善，这意味着一旦采用率上升，潜在的价值会被更多释放出来。

这三者之所以被低估，并不是因为它们不够好，而是因为“默认选择”阻断了尝试它们的机会。

此外，React 的 API 面明显更大、更复杂：Hooks、Context、Reducer、各种 memo 化模式……都需要谨慎管理才能避坑。这会抬高开发者的认知负担，进而带来因为误解依赖关系或过度工程而产生的缺陷。比如 Cloudflare 在 2025 年 9 月 12 日的一次故障中，一个 useEffect 中有问题的依赖数组触发了重复 API 调用，压垮了他们的 Tenant Service，导致大范围失败。相比之下，Svelte、Solid、Qwik 的 API 往往更小、更聚焦，更强调简洁与 Web 基础，降低了上手与维护成本。

网络效应的牢笼#

React 的主导地位会自我强化。招聘启事写的是“React 开发者”，而不是“前端工程师”，从而限制了技能多样性。组件库、团队肌肉记忆与组织惯性进一步加固了这种路径依赖。

风险规避的管理者会选择“更安全”的选项；学校教的是岗位要求的内容；循环与技术优劣无关地继续运转。

这不是健康竞争，而是“默认选择”对生态的捕获。

打破网络效应#

逃离这种状态需要多层面的主动行动。技术负责人应该基于约束与技术优劣做选择，而不是追随势能；公司可以划出一小部分创新预算，用来尝试替代方案；开发者也可以在单一心智模型之外持续进修。

教育者可以在教授具体工具的同时，强化框架无关的概念；开源贡献者可以帮助替代生态走向成熟。

变化不会自动发生，它需要有意识的选择。

框架评估清单#

在启动新项目时，用下面这份简单清单来做“刻意选择”：

性能需求评估：关注启动时间、更新效率、包体积等指标；如果速度是关键，优先考虑编译期优化更强的框架。
团队技能与学习曲线：尊重既有经验，但也要把迁移路径纳入考虑；许多替代方案有温和上手路径（例如 Solid 与 React 的 JSX 兼容）。
规模化与持有成本：计算长期成本，包括维护、依赖管理与技术债；替代方案往往能减少运行时开销，从而降低托管成本并提升可扩展性。
生态适配：在成熟与创新之间平衡；先在非关键路径试点，用以验证迁移可行性与 ROI。

常见反驳#

“但生态成熟度呢！” 成熟很有价值，也可能固化惰性。年龄不等于适配当下约束。

此外，一个成熟生态往往意味着对第三方包的重度依赖，这会引入维护负担：依赖升级、安全漏洞、以及因为未使用代码而膨胀的包体。虽然在某些场景里不可避免，但这种灵活性也容易变成过度依赖；围绕具体需求打造的定制化方案通常更轻、更易维护。替代框架的小生态反而鼓励从基础出发，形成更深的理解与更少的技术债。并且在 AI 编码助手可以按需生成精确自定义函数的今天，打造“为应用量身定制”的轻量工具函数的门槛已经显著降低，这让我们有可能完全避开像 lodash、Moment 或 date-fns 这类通用库，转而使用更轻的实现。

“但招聘呢！” 招聘跟着需求走。你可以先在非关键路径试点替代方案，降低风险；再以“基础能力 + 在岗训练”的方式招聘。

“但组件库呢！” 组件库往往是膨胀的代名词，主要在交付速度压倒一切时才最有用。围绕应用真实需求构建组件，会更精简，因为你不会为自己没有的问题打包代码。框架无关的设计系统与 Web Components 也能在保留交付速度的同时降低锁定风险。

“但稳定性呢！” React 从 class 到 Hooks、再到 Server Components、再到 React 19.2 的 useEffectEvent 与 <Activity />，展示的是持续 churn，而不是稳定。许多替代框架反而提供更一致的 API。

“但大规模验证过呢！” jQuery 也曾被大规模验证过。过去的成功并不保证未来仍然相关。

更广泛的生态伤害#

当一个框架的约束变成事实上的限制时，单一化会让 Web 演化放缓。人才把精力花在解决框架特有的问题上，而不是推动平台向前。资本也会不论技术优劣地追随既有赢家。

课程体系为了“立刻可就业”而不是“长期可迁移”，会优化成框架特定技能；平台层面的改进也可能被延后，因为“React 能解决”成了默认答案。

当多样性消失，整个生态都会受损。

我们本可以培育的花园#

健康生态需要多样性，而不是单一栽培。创新来自不同路线的竞争与交叉授粉。开发者通过学习多个心智模型成长；平台也会在不同框架的推动下突破边界。

把所有筹码押在一个模型上，会制造单点失败。如果它触及硬性上限会怎样？如果我们从未探索替代方案，又错过了哪些机会？

是时候基于约束与技术优劣，而不是势能，来选择框架了。你的下一个项目不该被“默认用 React”绑架；生态也值得拥有只有多样性才能带来的创新。

不要再默认种同一种种子。通过探索多样化的框架，我们能培育出更韧性、更具创新力的花园，而不是我们已逐渐滑向的单一栽培。

选择权在我们手里。

引用#

原文：react-won-by-default / Loren Stewart

飞鹅博客系统部署阿里云服务器

Wed, 10 Sep 2025 00:00:00 GMT

飞鹅博客系统部署阿里云服务器#

首先你要满足如下条件

你已经购买了阿里云服务器，并且已经登录到服务器上。
你已经安装了Node.js和npm。
你已经安装了MySQL数据库。

一、打包三个应用前端后端管理端#

前端应用修改 package.json 中的 scripts 字段，添加如下内容：
```
1
"scripts": {
2
  "build": "cross-env BASE_URL=你的域名 nuxi build",
3
}
```
然后运行 npm run build 打包前端应用。打包结果在 .output 目录下。
后端应用如果你是windows系统，打包后端应用
Terminal window
```
1
$env:GOOS="linux"; $env:GOARCH="amd64"; go build -o flygoose-api-2.0-linux-amd64 ./cmd/flygoose
```
如果并不是的话，参考飞鹅博客系统二次开发指南打包结果为 flygoose-api-2.0-linux-amd64
管理端应用
Terminal window
```
1
npm run build:prod
```
打包结果在 dist 目录下。

服务器分别部署#

安装docker docker-compose pm2等工具#

Terminal window

1
# Ubuntu系统
2
apt update && apt install -y docker.io curl npm
3
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
4
chmod +x /usr/local/bin/docker-compose
5
npm install -g pm2
6

7
# CentOS系统
8
yum install -y docker curl npm
9
systemctl start docker
10
systemctl enable docker
11
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
12
chmod +x /usr/local/bin/docker-compose
13
npm install -g pm2

nginx及docker compose配置#

我的目录如下

目录结构

1
/home/aifire/
2
├── ai-fire-api/
3
├── ai-fire-blog/
4
├── ai-fire-admin/

nginx配置文件如下

1
server {
2
    listen 80;
3
    server_name 你的域名;
4

5
    location / {
6
        proxy_pass http://localhost:3000;
7
        proxy_http_version 1.1;
8
        proxy_set_header Upgrade $http_upgrade;
9
        proxy_set_header Connection 'upgrade';
10
        proxy_set_header Host $host;
11
        proxy_cache_bypass $http_upgrade;
12
    }
13
}

docker compose配置文件如下

1
version: '3.8'
2
services:
3
  db:
4
    image: mysql:8.0
5
    volumes:
6
      - db_data:/var/lib/mysql
7
    restart: always
8
    environment:
9
      MYSQL_ROOT_PASSWORD: somewordpress
10
      MYSQL_DATABASE: wordpress
11
      MYSQL_USER: wordpress
12
      MYSQL_PASSWORD: wordpress
13
  wordpress:
14
    depends_on:
15
      - db
16
    image: wordpress:latest
17
    ports:
18
      - "8000:80"
19
    restart: always
20
    environment:
21
      WORDPRESS_DB_HOST: db:3306
22
      WORDPRESS_DB_USER: wordpress
23
      WORDPRESS_DB_PASSWORD: wordpress
24
      WORDPRESS_DB_NAME: wordpress
25
volumes:
26
  db_data: {}

展开收起

分别启动每个项目#

前端blog

Terminal window

1
cd ai-fire-blog
2
pm2 start npm --name "ai-fire-blog" -- run start

启动成功后如下

前端blog启动成功

后端api 增加启动权限

Terminal window

1
chmod +x flygoose-api-2.0-linux-amd64

启动后端api

Terminal window

1
sudo chmod +x flygoose-api-2.0-linux-amd64
2
sudo nohup ./flygoose-api-2.0-linux-amd64 -c ./flygoose-config.yml &

管理端admin
Terminal window
```
1
cd ai-fire-admin
2
docker-compose up -d
```

飞鹅博客系统初始化及二次开发（三）管理端前端

Wed, 03 Sep 2025 00:00:00 GMT

飞鹅博客系统初始化及二次开发（三）管理端前端#

1. 项目概述#

飞鹅博客系统管理端是一个基于 Vue 3 + TypeScript 的现代化管理后台，用于管理博客系统的各类内容和配置。本项目采用了组件化、模块化的设计思想，提供了良好的可扩展性和维护性。

1.1 技术栈#

技术/框架	版本	用途
Vue.js	3.x	前端框架
TypeScript	5.x	类型系统
Pinia	2.x	状态管理
Ant Design Vue	4.x	UI 组件库
Vue Router	4.x	路由管理
Axios	1.x	HTTP 请求
Vite	5.x	构建工具
Less	4.x	CSS 预处理器

2. 环境搭建#

2.1 安装依赖#

项目使用 pnpm 作为包管理工具，首先确保已安装 pnpm：

Terminal window

1
npm install -g pnpm

然后安装项目依赖：

Terminal window

1
cd ai-fire-admin
2
pnpm install

2.2 配置文件#

项目包含两个主要的环境配置文件：

.env.development：开发环境配置
.env.production：生产环境配置

配置文件中定义了 API 基础路径等关键信息，可根据实际情况修改：

1
# 开发环境示例
2
VITE_API_BASE_URL = '/api'

2.3 启动开发服务器#

Terminal window

1
pnpm dev

开发服务器默认会在 http://localhost:5173 启动。

3. 项目结构#

1
ai-fire-admin/
2
├── public/              # 静态资源
3
├── src/                 # 源代码
4
│   ├── apis/            # API接口定义
5
│   ├── assets/          # 静态资源
6
│   ├── components/      # 自定义组件
7
│   ├── layouts/         # 布局组件
8
│   ├── router/          # 路由配置
9
│   ├── stores/          # 状态管理
10
│   ├── types/           # TypeScript类型定义
11
│   ├── utils/           # 工具函数
12
│   ├── views/           # 页面组件
13
│   ├── App.vue          # 根组件
14
│   └── main.ts          # 入口文件
15
├── nginx/               # Nginx配置
16
├── .env.*               # 环境配置
17
├── package.json         # 项目配置
18
├── vite.config.ts       # Vite配置
19
└── tsconfig.json        # TypeScript配置

展开收起

3.1 核心目录说明#

3.1.1 `src/apis/`#

定义了与后端交互的所有 API 接口，每个模块对应一个独立的文件：

website-info.ts

1
import request from '@/utils/http'
2

3
export const getSiteInfoList = () => {
4
  return request.get('/api/website/info/list')
5
}
6

7
export const createSiteInfo = (data: any) => {
8
  return request.post('/api/website/info/create', data)
9
}

3.1.2 `src/components/`#

包含项目中使用的自定义组件，如表格、表单、模态框等：

table.vue：通用表格组件
form.vue：通用表单组件
modal.vue：通用模态框组件
pagination.vue：分页组件

3.1.3 `src/layouts/`#

定义了系统的整体布局结构：

default-layout.vue：默认布局，包含侧边栏、顶部导航和内容区域
menu.vue：侧边栏菜单组件
foot.vue：页脚组件

3.1.4 `src/router/`#

配置了系统的路由结构：

index.ts展开收起

1
import { createRouter, createWebHistory } from 'vue-router'
2
import DefaultLayout from '@/layouts/default-layout.vue'
3

4
const router = createRouter({
5
  history: createWebHistory(import.meta.env.BASE_URL),
6
  routes: [
7
    {
8
      path: '/',
9
      name: 'home',
10
      component: DefaultLayout,
11
      children: [
12
        {
13
          path: '',
14
          name: 'dashboard',
15
          component: () => import('../views/dashboard/index.vue')
16
        }
17
        // 其他路由...
18
      ]
19
    },
20
    {
21
      path: '/login',
22
      name: 'login',
23
      component: () => import('../views/login/index.vue')
24
    }
25
  ]
26
})

展开收起

3.1.5 `src/stores/`#

使用 Pinia 进行状态管理，按功能模块划分：

module/website-info.ts展开收起

1
import { defineStore } from 'pinia'
2
import * as websiteInfoApi from '@/apis/website-info'
3

4
export const useWebsiteInfoStore = defineStore('websiteInfo', {
5
  state: () => ({
6
    websiteInfoList: []
7
  }),
8
  actions: {
9
    async getSiteInfoListAction() {
10
      const res = await websiteInfoApi.getSiteInfoList()
11
      this.websiteInfoList = res.data
12
      return res.data
13
    }
14
  }
15
})

展开收起

3.1.6 `src/utils/`#

包含项目中使用的工具函数：

http.ts：Axios 实例配置
constant.ts：常量定义

3.1.7 `src/views/`#

包含系统的所有页面组件，按功能模块划分：

dashboard/：仪表盘
blog/：博客管理
category/：分类管理
website-info/：网站信息管理
login/：登录页面

4. 核心功能模块#

4.1 登录与权限管理#

系统实现了基于 JWT 的登录认证机制：

用户输入账号密码登录
后端验证通过后返回 JWT token
前端将 token 存储到 localStorage
后续请求通过 Authorization 头携带 token

登录逻辑实现：

views/login/index.vue

1
const handleLogin = async () => {
2
  try {
3
    const res = await userApi.login(formData.value)
4
    localStorage.setItem('token', res.data.token)
5
    router.push('/')
6
    message.success('登录成功')
7
  } catch (error) {
8
    message.error('登录失败')
9
  }
10
}

4.2 网站信息管理#

网站信息管理模块用于配置博客系统的基本信息，如标题、标语、封面、版权信息等。

主要功能：

查看网站信息列表
选择并查看详情
编辑网站信息
创建新的网站信息

实现细节：

views/website-info/website-info.vue

1
<Table
2
  :data-source="dataSource"
3
  :columns="columns"
4
  ref="table"
5
  @edit="edit"
6
  @change="handleTableChange"
7
>
8
  <!-- 表格内容 -->
9
</Table>
10

11
<a-descriptions bordered style="margin-top: 20px;">
12
  <a-descriptions-item label="网站标题">{{ websiteInfo.title }}</a-descriptions-item>
13
  <!-- 其他信息项 -->
14
</a-descriptions>

4.3 博客管理#

博客管理模块用于管理博客文章，支持以下功能：

博客列表展示与分页
博客文章的创建、编辑、删除
富文本编辑
分类与标签管理
状态管理（已发布/草稿）

4.4 分类管理#

分类管理模块用于管理博客文章的分类，支持：

分类列表展示
分类的创建、编辑、删除
分类排序
分类状态管理

4.5 仪表盘#

仪表盘模块提供系统概览，包括：

博客文章统计
分类统计
访问量统计
最新动态

5. 二次开发指南#

5.1 添加新页面#

在 src/views/ 目录下创建新的页面组件
在 src/router/ 中配置路由
在侧边栏菜单中添加新的菜单项

示例：添加新页面

src/views/new-page/index.vue

1
<template>
2
  <div class="new-page">
3
    <h1>新页面</h1>
4
  </div>
5
</template>
6

7
<script setup lang="ts">
8
// 页面逻辑
9
</script>

src/router/index.ts展开收起

1
const router = createRouter({
2
  // ...
3
  routes: [
4
    {
5
      path: '/',
6
      component: DefaultLayout,
7
      children: [
8
        // ...
9
        {
10
          path: '/new-page',
11
          name: 'newPage',
12
          component: () => import('../views/new-page/index.vue')
13
        }
14
      ]
15
    }
16
  ]
17
})

展开收起

5.2 添加新组件#

在 src/components/ 目录下创建新的组件
在需要使用的地方导入并使用

示例：创建新组件

src/components/my-component.vue

1
<template>
2
  <div class="my-component">
3
    <slot></slot>
4
  </div>
5
</template>
6

7
<script setup lang="ts">
8
// 组件逻辑
9
</script>

5.3 扩展 API#

在 src/apis/ 目录下创建新的 API 文件
定义 API 函数
在组件或 store 中使用

示例：添加新 API

src/apis/new-api.ts

1
import request from '@/utils/http'
2

3
export const getNewData = () => {
4
  return request.get('/api/new-data')
5
}

5.4 自定义主题#

系统使用 Ant Design Vue 的主题定制功能，可以通过修改 src/assets/css/variables.less 文件来自定义主题颜色：

1
// 自定义主题色
2
@primary-color: #1890ff;
3
@success-color: #52c41a;
4
@warning-color: #faad14;
5
@error-color: #f5222d;

6. 部署流程#

6.1 构建生产版本#

Terminal window

1
pnpm build

构建后的文件会输出到 dist/ 目录。

6.2 Nginx 配置#

项目提供了 Nginx 配置文件 nginx/nginx.conf，可根据实际情况修改：

1
# 全局配置
2
user nginx;
3
worker_processes auto;
4

5
# http 配置
6
http {
7
    include       mime.types;
8
    default_type  application/octet-stream;
9

10
    # 服务器配置
11
    server {
12
        listen       8080;
13
        server_name  localhost;
14

15
        # 前端静态资源
16
        location / {
17
            root   /usr/share/nginx/html;
18
            index  index.html index.htm;
19
            try_files $uri $uri/ /index.html;
20
        }
21

22
        # API 代理
23
        location /api {
24
            proxy_pass http://127.0.0.1:29090;
25
            proxy_set_header Host $host;
26
            proxy_set_header X-Real-IP $remote_addr;
27
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
28
            proxy_set_header X-Forwarded-Proto $scheme;
29
        }
30
    }
31
}

展开收起

6.3 部署步骤#

将构建后的 dist/ 目录上传到服务器的 /usr/share/nginx/html/ 目录
将 Nginx 配置文件复制到服务器的 /etc/nginx/conf.d/ 目录
重新加载 Nginx 配置：
Terminal window
```
1
nginx -s reload
```

7. 开发规范#

7.1 代码风格#

项目使用 ESLint 和 Prettier 来保证代码风格的一致性，提交代码前会自动进行检查。

7.2 命名规范#

组件名：大驼峰命名，如 WebsiteInfo
文件/目录名：小写字母加短横线，如 website-info.vue
变量名：小驼峰命名，如 websiteInfoList
常量名：全大写加下划线，如 API_BASE_URL

7.3 注释规范#

组件和函数使用 JSDoc 注释
复杂逻辑添加必要的单行注释
代码变更添加提交注释

8. 常见问题与解决方案#

8.1 跨域问题#

开发环境中，Vite 配置了代理解决跨域问题：

vite.config.ts

1
export default defineConfig({
2
  // ...
3
  server: {
4
    proxy: {
5
      '/api': {
6
        target: 'http://localhost:29090',
7
        changeOrigin: true
8
      }
9
    }
10
  }
11
})

生产环境中，通过 Nginx 代理解决跨域问题。

8.2 构建失败#

检查依赖是否正确安装
检查 TypeScript 类型是否正确
检查语法错误

8.3 页面空白#

检查路由配置是否正确
检查组件是否正确导入
检查网络请求是否正常

飞鹅博客系统初始化及二次开发（二）后端

Sat, 02 Aug 2025 00:00:00 GMT

飞鹅博客系统初始化及二次开发（二）后端#

一、后端开发#

1.1 项目结构解析#

飞鹅博客系统后端基于Go语言和Iris框架开发，采用了清晰的分层架构设计。以下是项目的核心目录结构：

1
├── cmd/                      # 命令行入口
2
│   └── flygoose/             # 主程序入口
3
│       ├── flygoose-config.yaml  # 配置文件示例
4
│       └── main.go           # 程序启动文件
5
├── configs/                  # 配置相关
6
│   └── config.go             # 配置结构定义
7
├── datasource/               # 数据源连接
8
│   └── db.go                 # 数据库初始化
9
├── inits/                    # 应用初始化
10
│   ├── flygoose_init.go      # 应用初始化逻辑
11
│   └── middle.go             # 中间件配置
12
├── pkg/                      # 公共包
13
│   ├── beans/                # 数据传输对象
14
│   ├── models/               # 数据模型
15
│   ├── tlog/                 # 日志工具
16
│   └── tools/                # 通用工具
17
├── web/                      # Web相关
18
│   ├── controllers/          # 控制器
19
│   ├── daos/                 # 数据访问层
20
│   ├── middlers/             # 中间件
21
│   └── services/             # 业务逻辑层
22
└── docs/                     # 文档
23
    └── 接口文档.md           # API接口文档

展开收起

1.2 核心配置文件说明#

1.2.1 主配置文件结构#

配置文件位于configs/config.go，定义了系统的核心配置结构：

1
// 全局配置文件实例
2
var Cfg *Config
3

4
type Config struct {
5
    Http         HttpCfg     `yaml:"http"`         // HTTP服务配置
6
    Database     DatabaseCfg `yaml:"database"`     // 数据库配置
7
    ExecuteDir   string                             // 可执行文件目录
8
    StaticDir    string                             // 静态文件目录
9
    StaticImgDir string                             // 图片静态目录
10
}
11

12
type HttpCfg struct {
13
    Port int `yaml:"port"`                         // 服务端口
14
}
15

16
type DatabaseCfg struct {
17
    Driver   DbDriverType `yaml:"driver"`          // 数据库类型(mysql或postgresql)
18
    Host     string       `yaml:"host"`            // 数据库IP
19
    Name     string       `yaml:"name"`            // 数据库名称
20
    Port     int          `yaml:"port"`            // 数据库端口
21
    User     string       `yaml:"user"`            // 用户名
22
    Password string       `yaml:"password"`        // 密码
23
}

展开收起

1.2.2 配置文件示例#

1
# 服务端口
2
http:
3
  port: 29090
4
# 数据库配置
5
database:
6
  driver: mysql
7
  host: 127.0.0.1
8
  port: 3306
9
  name: db_flygoose
10
  user: flygoose
11
  password: flygoose

1.3 应用初始化流程#

应用初始化主要在inits/flygoose_init.go中实现，包含以下核心步骤：

1.3.1 创建应用实例#

1
func NewFlygooseApp(cfg *configs.Config) *FlygooseApp {
2
    app := new(FlygooseApp)
3
    app.Cfg = cfg
4
    app.Engine = iris.New()
5
    // 配置CORS中间件
6
    app.Engine.UseRouter(cors.New().Handler())
7
    return app
8
}

1.3.2 启动应用#

1
func (m *FlygooseApp) Start() {
2
    m.InitDir()       // 初始化目录
3
    m.initLog()       // 初始化日志
4
    m.initDB()        // 初始化数据库
5
    m.initRouter()    // 初始化路由
6
    m.run()           // 启动服务
7
}

1.3.3 数据库初始化与自动迁移#

1
func (m *FlygooseApp) initDB() {
2
    // 初始化数据库连接
3
    if m.Cfg.Database.Driver == configs.DbDriverMySQL {
4
        datasource.InitMySql(cfg)
5
    } else if m.Cfg.Database.Driver == configs.DbDriverPostgreSQL {
6
        datasource.InitPostgreSQL(cfg)
7
    } else {
8
        panic(errors.New("暂不支持其它数据库"))
9
    }
10

11
    // 自动迁移数据模型
12
    m.initAutoMigrate()
13

14
    // 初始化默认管理员账户
15
    m.initDefaultAdmin()
16
}

展开收起

1.3.4 路由配置#

1
func (m *FlygooseApp) initRouter() {
2
    v1 := m.Engine.Party(configs.Flygoose_Url_Prefix)  // API前缀
3
    {
4
        // 前端接口
5
        mvc.New(v1.Party("/site")).Handle(flygoose.NewSiteController())
6
        mvc.New(v1.Party("/blog")).Handle(flygoose.NewBlogController())
7
        mvc.New(v1.Party("/special")).Handle(flygoose.NewSpecialController())
8
        mvc.New(v1.Party("/ai")).Handle(ai.NewDeepSeekController()) // AI相关接口（注：此为个人修改版本新增功能，详情请参考 https://github.com/AI-FIRE/）
9

10
        // 管理端接口
11
        mvc.New(v1.Party("/health")).Handle(admin.NewHealthController())                 //健康检查
12
        mvc.New(v1.Party("/admin/access")).Handle(admin.NewAccessController())           //访问相关接口
13
        mvc.New(v1.Party("/admin/blog")).Handle(admin.NewBlogController())               //博客相关接口
14
        mvc.New(v1.Party("/admin/link")).Handle(admin.NewLinkController())               //友链相关接口
15
        mvc.New(v1.Party("/admin/site")).Handle(admin.NewSiteController())               //网站信息相关接口
16
        mvc.New(v1.Party("/admin/category")).Handle(admin.NewCategoryController())       //博客分类相关接口
17
        mvc.New(v1.Party("/admin/notice")).Handle(admin.NewNoticeController())           //公告分类相关接口
18
        mvc.New(v1.Party("/admin/special")).Handle(admin.NewSpecialController())         //专栏相关接口
19
        mvc.New(v1.Party("/admin/file")).Handle(admin.NewFileController())               //文件相关接口
20
        mvc.New(v1.Party("/admin/banner")).Handle(admin.NewBannerController())           //轮播图相关接口
21
        mvc.New(v1.Party("/admin/workStation")).Handle(admin.NewWorkStationController()) //统计数据
22
    }
23
}

展开收起

1.4 数据模型设计#

系统的数据模型定义在pkg/models/目录下，主要包含以下模型：

Admin: 管理员模型
Blog: 博客文章模型
Category: 分类模型
Link: 友链模型
Notice: 公告模型
Section: 页面区块模型
Site: 网站信息模型
Special: 专栏模型
Webmaster: 站长模型
Banner: 轮播图模型
AI相关模型（注：此为个人修改版本新增功能，详情请参考 https://github.com/AI-FIRE/）

1.5 业务逻辑分层#

1.5.1 控制器层 (Controllers)#

控制器层负责处理HTTP请求，接收参数，调用业务逻辑，并返回响应。控制器位于web/controllers/目录下，分为前端控制器和管理端控制器。

示例：博客控制器

1
// 前端博客控制器
2
func NewBlogController() *BlogController {
3
    return &BlogController{
4
        BlogService: services.NewBlogService(),
5
    }
6
}
7

8
// 管理端博客控制器
9
func NewBlogController() *BlogController {
10
    return &BlogController{
11
        BlogService: services.NewBlogService(),
12
    }
13
}

1.5.2 业务逻辑层 (Services)#

业务逻辑层负责处理核心业务逻辑，位于web/services/目录下。

1.5.3 数据访问层 (DAOs)#

数据访问层负责与数据库交互，位于web/daos/目录下。

1.6 AI功能集成#

注：AI功能为个人修改版本新增功能，详情请参考 https://github.com/AI-FIRE/

系统集成了DeepSeek AI功能，相关代码位于以下位置：

pkg/beans/ai/: AI相关数据传输对象
pkg/models/ai/: AI配置模型
web/controllers/ai/: AI控制器
web/daos/ai/: AI数据访问
web/services/ai/: AI业务逻辑

AI接口示例：

1
// 直接返回型DeepSeek AI聊天接口
2
func (c *DeepSeekController) ChatFirstPageAi(ctx iris.Context) {
3
    // 处理AI聊天请求
4
}
5

6
// 流式传输型DeepSeek AI聊天接口
7
func (c *DeepSeekController) StreamChatFirstPageAi(ctx iris.Context) {
8
    // 处理AI流式聊天请求
9
}

1.7 开发环境搭建#

1.7.1 依赖安装#

Terminal window

1
go mod tidy

1.7.2 本地运行#

Terminal window

1
go run cmd\flygoose\main.go

1.7.3 配置说明#

在cmd/flygoose/flygoose-config.yaml文件中配置数据库连接信息：

1
# 服务端口
2
http:
3
  port: 29090
4
# 数据库配置
5
database:
6
  driver: mysql
7
  host: 127.0.0.1
8
  port: 3306
9
  name: db_flygoose
10
  user: root
11
  password: root

1.8 编译与打包#

1.8.1 本地编译#

Terminal window

1
# Windows平台编译
2
$env:GOOS="windows"; $env:GOARCH="amd64"; go build -o flygoose-api-2.0-win-amd64.exe ./cmd/flygoose
3

4
# Linux平台编译
5
$env:GOOS="linux"; $env:GOARCH="amd64"; go build -o flygoose-api-2.0-linux-amd64 ./cmd/flygoose
6

7
# macOS平台编译 (Intel芯片)
8
$env:GOOS="darwin"; $env:GOARCH="amd64"; go build -o flygoose-api-2.0-darwin-amd64 ./cmd/flygoose
9

10
# macOS平台编译 (Apple芯片)
11
$env:GOOS="darwin"; $env:GOARCH="arm64"; go build -o flygoose-api-2.0-darwin-arm64 ./cmd/flygoose

1.8.2 运行编译后的程序#

Terminal window

1
# Linux平台
2
chmod +x flygoose-api-2.0-linux-amd64
3
./flygoose-api-2.0-linux-amd64 -c flygoose-config.yaml
4

5
# Windows平台
6
flygoose-api-2.0-win-amd64.exe -c flygoose-config.yaml

1.9 健康检查#

系统提供了健康检查接口，用于验证服务是否正常运行：

Terminal window

1
curl http://localhost:29090/api/health

返回结果：

1
{"code":1,"data":null,"message":"success"}

二、管理端前端开发#

（管理端前端部分将在后续章节中详细介绍）

三、二次开发指南#

3.1 添加新功能模块#

3.1.1 创建数据模型#

在pkg/models/目录下创建新的数据模型。

3.1.2 创建数据传输对象#

在pkg/beans/目录下创建对应的数据传输对象。

3.1.3 创建数据访问层#

在web/daos/目录下创建数据访问层。

3.1.4 创建业务逻辑层#

在web/services/目录下创建业务逻辑层。

3.1.5 创建控制器#

在web/controllers/目录下创建控制器。

3.1.6 注册路由#

在inits/flygoose_init.go文件中注册新的路由。

3.2 AI功能扩展#

注：AI功能为个人修改版本新增功能，详情请参考 https://github.com/AI-FIRE/

系统支持扩展AI功能，可以在web/controllers/ai/、web/daos/ai/和web/services/ai/目录下添加新的AI接口和功能。

3.3 配置扩展#

在configs/config.go文件中添加新的配置项，并在cmd/flygoose/flygoose-config.yaml文件中配置对应的值。

四、部署说明#

4.1 服务器部署#

4.1.1 准备工作#

服务器或云主机（推荐配置：2核4G以上，操作系统：Ubuntu 20.04+）
MySQL 8.0+ 数据库
Nginx（可选，用于反向代理和HTTPS配置）

4.1.2 安装依赖#

Terminal window

1
# 更新系统
2
apt-get update
3

4
# 安装依赖
5
apt-get install -y vim wget curl mysql-server

4.1.3 配置数据库#

Terminal window

1
# 登录MySQL
2
mysql -u root -p
3

4
# 创建数据库
5
CREATE DATABASE db_flygoose DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
6

7
# 创建用户并授权
8
CREATE USER 'flygoose'@'%' IDENTIFIED BY 'flygoose';
9
GRANT ALL PRIVILEGES ON db_flygoose.* TO 'flygoose'@'%';
10
FLUSH PRIVILEGES;
11

12
# 退出
13
EXIT;

4.1.4 部署应用#

Terminal window

1
# 创建应用目录
2
mkdir -p /opt/flygoose
3

4
# 上传编译好的程序和配置文件
5
cd /opt/flygoose
6

7
# 修改配置文件
8
vim flygoose-config.yaml
9

10
# 赋予执行权限
11
chmod +x flygoose-api-2.0-linux-amd64
12

13
# 后台运行
14
nohup ./flygoose-api-2.0-linux-amd64 -c flygoose-config.yaml &

4.1.5 Nginx配置（可选）#

Terminal window

1
# 安装Nginx
2
apt-get install -y nginx
3

4
# 配置Nginx
5
vim /etc/nginx/conf.d/flygoose.conf

Nginx配置示例：

1
server {
2
    listen 80;
3
    server_name yourdomain.com;
4

5
    location /api {
6
        proxy_pass http://localhost:29090;
7
        proxy_set_header Host $host;
8
        proxy_set_header X-Real-IP $remote_addr;
9
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
10
    }
11
}

Terminal window

1
# 重启Nginx
2
systemctl restart nginx

4.2 Docker部署（可选）#

项目包含Dockerfile，可以使用Docker进行部署。

Terminal window

1
# 构建镜像
2
docker build -t flygoose-api .
3

4
# 运行容器
5
docker run -d -p 29090:29090 -v ./flygoose-config.yaml:/app/flygoose-config.yaml --name flygoose-api flygoose-api

五、接口文档#

详细的API接口文档请参考docs/接口文档.md文件。

六、常见问题与解决方案#

6.1 数据库连接失败#

检查数据库服务是否正常运行
检查数据库连接配置是否正确
检查数据库用户权限是否正确

6.2 服务启动失败#

检查端口是否被占用
检查配置文件是否正确
检查日志文件获取详细错误信息

6.3 AI功能无法使用#

注：AI功能为个人修改版本新增功能，详情请参考 https://github.com/AI-FIRE/

检查AI配置是否正确
检查网络连接是否正常
检查AI服务是否可用

飞鹅博客系统初始化及二次开发（一）博客前端

Fri, 01 Aug 2025 00:00:00 GMT

飞鹅博客初始化及二次开发指南（一）博客前端#

该网址即为此项目搭建智心一梦

1. 项目简介#

飞鹅博客是一个基于 Nuxt 3 + TypeScript 构建的现代化 AI 技术分享平台，集成了智能对话助手、技术博客、AI 资讯等核心功能。该项目采用前后端分离架构，前端使用 Nuxt 3 框架，支持服务端渲染和静态站点生成，为用户提供高性能的访问体验。

1.1 技术栈#

技术/框架	版本	用途
Nuxt	^3.4.3	前端框架
TypeScript	^4.7.2	类型检查
Vue	3.x	UI 框架
Pinia	2.0.14	状态管理
Element Plus	^2.3.4	UI 组件库
Ant Design Vue	^3.2.7	UI 组件库
Less	^4.1.3	样式预处理器
Axios	-	HTTP 客户端

1.2 核心功能#

智能对话助手：支持单次对话和流式对话两种模式
技术博客：文章列表、详情展示、分类标签
AI 资讯：最新 AI 动态展示和外部链接跳转
用户系统：登录、注册、个人信息管理
响应式设计：适配不同屏幕尺寸

2. 环境准备#

2.1 基础环境#

⚠️ 注意事项：由于 Nuxt 当前版本存在 bug，启动项目时必须使用 Node.js 16.x，否则可能出现 unused body 报错。
建议使用 nvm 或 fnm 快速切换 Node 版本：
Terminal window
1
nvm use 16
2
# 或
3
fnm use 16

Node.js >= 14.0.0（推荐 16.x）
Yarn >= 1.22.0 或 npm >= 6.0.0
Git
Node.js >= 14.0.0
Yarn >= 1.22.0 或 npm >= 6.0.0
Git

2.2 开发工具推荐#

Visual Studio Code
Vue DevTools
ESLint 插件
Prettier 插件

3. 项目初始化#

3.1 克隆项目#

Terminal window

1
git clone https://github.com/your-repo/flygoose-blog.git
2
cd flygoose-blog

3.2 安装依赖#

Terminal window

1
yarn install

3.3 配置环境变量#

在项目根目录创建 .env 文件，配置基础 URL：

Terminal window

1
# 开发环境
2
export BASE_URL=http://localhost:3000/api
3

4
# 生产环境
5
export BASE_URL=https://your-api-domain.com/api

3.4 启动开发服务器#

Terminal window

1
yarn dev

访问 http://localhost:3000 即可查看项目。

4. 项目结构分析#

4.1 目录结构#

1
├── api/                # API 请求封装
2
├── assets/             # 静态资源
3
│   ├── images/         # 图片资源
4
│   ├── less/           # 全局样式
5
│   └── movie/          # 视频资源
6
├── components/         # Vue 组件
7
│   ├── blog/           # 博客相关组件
8
│   ├── global/         # 全局通用组件
9
│   ├── index/          # 首页组件
10
│   ├── layout/         # 布局组件
11
│   └── special/        # 专栏相关组件
12
├── hooks/              # 自定义 hooks
13
├── layouts/            # 页面布局
14
├── middleware/         # 中间件
15
├── pages/              # 页面组件
16
│   ├── ai/             # AI 相关页面
17
│   ├── detail/         # 文章详情
18
│   └── specialColumn/  # 专栏页面
19
├── plugins/            # 插件
20
├── stores/             # Pinia 状态管理
21
├── types/              # TypeScript 类型定义
22
├── utils/              # 工具函数
23
└── nuxt.config.ts      # Nuxt 配置文件

展开收起

4.2 核心文件说明#

pages/index.vue：网站首页，包含英雄区域、AI 对话、博客入口和资讯展示
pages/ai/chatOnce.vue：单次对话组件，支持快捷问题和自定义问题
pages/ai/chatStream.vue：流式对话组件，支持实时打字效果
components/layout/：包含导航栏、侧边栏、页脚等布局组件
stores/user.ts：用户信息状态管理
api/index.ts：API 请求封装

5. 代码规范#

5.1 命名规范#

文件夹：小写，多个单词用连字符，如 ai-chat
Vue 文件：除了 index.vue 全部使用大驼峰，如 ArticleItem.vue
TypeScript 文件：使用小驼峰，如 useToken.ts
Class 名：多个字母用连字符，如 quick-questions
事件命名：触发的 DOM 事件命名为 handleXxxxClick，监听事件为 onXxxxChange

5.2 代码风格#

使用 ESLint + Prettier 进行代码检查和格式化
使用 TypeScript 进行类型检查
Vue 组件使用 Composition API
样式使用 Less 预处理器

6. 二次开发指南#

6.1 新增页面#

在 pages 目录下创建新的 Vue 文件，Nuxt 会自动生成路由：

1
<template>
2
  <div class="new-page">
3
    <h1>新页面</h1>
4
    <p>这是一个新添加的页面</p>
5
  </div>
6
</template>
7

8
<script lang="ts" setup>
9
// 页面逻辑
10
</script>
11

12
<style lang="less" scoped>
13
.new-page {
14
  padding: 20px;
15
}
16
</style>

展开收起

6.2 新增组件#

在 components 目录下创建新的 Vue 组件：

1
<template>
2
  <div class="new-component">
3
    <slot></slot>
4
  </div>
5
</template>
6

7
<script lang="ts" setup>
8
// 组件逻辑
9
</script>
10

11
<style lang="less" scoped>
12
.new-component {
13
  /* 组件样式 */
14
}
15
</style>

展开收起

6.3 添加 API 请求#

在 api/index.ts 中添加新的 API 请求：

1
export const getNewData = async (params: any) => {
2
  return await request({
3
    url: '/api/new-data',
4
    method: 'get',
5
    params
6
  })
7
}

6.4 状态管理#

在 stores 目录下创建新的状态管理文件：

1
import { defineStore } from 'pinia'
2

3
export const useNewStore = defineStore('new', () => {
4
  const data = ref([])
5

6
  const fetchData = async () => {
7
    const res = await getNewData()
8
    data.value = res.data
9
  }
10

11
  return {
12
    data,
13
    fetchData
14
  }
15
})

展开收起

6.5 修改主题样式#

在 assets/less/style.less 中修改全局样式变量：

1
// 主题色
2
@primary-color: #52c41a;
3
@success-color: #52c41a;
4
@warning-color: #faad14;
5
@error-color: #f5222d;
6

7
// 文字色
8
@text-color: #333333;
9
@text-color-secondary: #666666;
10
@text-color-tertiary: #999999;

7. 快捷问题按钮开发实例#

以 chatOnce.vue 中的快捷问题按钮为例，展示二次开发过程：

7.1 添加按钮到模板#

1
<div class="quick-questions">
2
  <button @click="handleFirstHandshake" class="quick-question-button first-handshake-button">
3
    第一次握手
4
  </button>
5
  <button v-for="(button, index) in quickButtons" :key="index" class="quick-question-button" @click="fillQuestion(button.message)">
6
    {{ button.buttonname }}
7
  </button>
8
</div>

7.2 实现按钮样式#

1
.quick-questions {
2
  display: flex;
3
  gap: 12px;
4
  margin-top: 12px;
5
  flex-wrap: wrap;
6
}
7

8
.quick-question-button {
9
  padding: 6px 12px;
10
  border: 1px solid #52c41a;
11
  border-radius: 16px;
12
  background: #f6ffed;
13
  color: #52c41a;
14
  font-size: 12px;
15
  cursor: pointer;
16
  transition: all 0.3s;
17
  white-space: nowrap;
18
  position: relative;
19
  overflow: hidden;
20

21
  &.first-handshake-button {
22
    border: 1px solid #ff7a45;
23
    background: #fff7e6;
24
    color: #ff7a45;
25

26
    &:hover {
27
      background: linear-gradient(135deg, #ff7a45, #ffac38);
28
      border-color: #ff7a45;
29
      color: #fff;
30
      box-shadow: 0 2px 8px rgba(255, 122, 69, 0.3);
31
    }
32
  }
33

34
  &:hover {
35
    background: linear-gradient(135deg, #52c41a, #73d13d);
36
    color: #fff;
37
    border-color: #52c41a;
38
    transform: translateY(-1px);
39
    box-shadow: 0 2px 8px rgba(82, 196, 26, 0.3);
40
  }
41
}

展开收起

7.3 实现按钮功能#

1
// 快捷问题按钮数据
2
const quickButtons = [
3
  { buttonname: 'AI 是什么？', message: '人工智能（AI）是什么？它有哪些主要应用领域？' },
4
  { buttonname: '机器学习入门', message: '如何入门机器学习？需要学习哪些基础知识？' },
5
  { buttonname: '深度学习框架', message: '目前主流的深度学习框架有哪些？它们各自的优缺点是什么？' }
6
]
7

8
// 填充问题到输入框
9
const fillQuestion = (message: string) => {
10
  userInput.value = message
11
}
12

13
// 处理第一次握手
14
const showHandshakeDialog = ref(false)
15
const authorName = ref('')
16
const authorNameError = ref('')
17

18
const handleFirstHandshake = () => {
19
  authorName.value = ''
20
  authorNameError.value = ''
21
  showHandshakeDialog.value = true
22
}

展开收起

8. 部署流程#

8.1 构建生产版本#

Terminal window

1
# 开发环境构建
2
yarn build:local
3

4
# 测试环境构建
5
yarn build_test
6

7
# 生产环境构建
8
yarn build

构建成功后，会生成 .output 目录。

8.2 使用 PM2 部署#

在项目根目录执行：

Terminal window

1
pm install pm2 -g
2
pm2 start pm2.config.js

8.3 配置 Nginx#

1
server {
2
  listen 80;
3
  server_name your-domain.com;
4

5
  location / {
6
    proxy_pass http://localhost:58081;
7
    proxy_http_version 1.1;
8
    proxy_set_header Upgrade $http_upgrade;
9
    proxy_set_header Connection 'upgrade';
10
    proxy_set_header Host $host;
11
    proxy_cache_bypass $http_upgrade;
12
  }
13
}

9. 常见问题与解决方案#

9.1 API 请求失败#

检查 BASE_URL 配置是否正确
确保后端服务正常运行
检查网络连接

9.2 样式不生效#

检查 Less 依赖是否安装
确保样式文件路径正确
检查 CSS 选择器是否正确

9.3 页面路由 404#

检查页面文件命名和路径是否符合 Nuxt 路由规则
确保布局文件存在

10. 项目维护#

10.1 代码更新#

Terminal window

1
git pull
2
yarn install
3
yarn build
4
yarn start

10.2 依赖更新#

Terminal window

1
yarn upgrade-interactive

10.3 日志查看#

Terminal window

1
pm2 logs

Pankitgg

仿openclaw调度，手搓一个免安装的windows个人助手，我管他叫智心一梦

初衷#

架构#

openclaw的架构#

目前架构#

开始使用#

下载安装#

开始使用#

设置#

员工#

会议室#

技能/工具#

宠物模式#

最佳实践（一场酣畅淋漓的会议）#

后续计划#

GitHub主页添加贪吃蛇贡献图（github美化一）

准备工作：创建 Profile README 仓库#

创建步骤#

核心步骤：配置 GitHub Action#

第一步：创建 Workflow 文件#

第二步：编写 snake.yml 文件#

第三步：配置仓库权限#

第四步：运行 Action 并验证结果#

最后一步：在主页展示贪吃蛇#

自定义配置#

2028全球智能危机（译）

序言#

智能过剩的后果#

一切的开始#

当摩擦归零#

从行业风险到系统性风险#

智能取代螺旋#

连环式相关押注#

抵押贷款问题#

与时间的赛跑#

智能溢价的终结#

选什么初始项目作为vibecodeing的初始化，最适用于AI全栈的开发框架one-is-all（一）

选型介绍#

使用（以trae/solo为例）#

一句话安装#

阿里PageAgent初试水，网页自动化agent

什么是PageAgent#

接入#

简单接入#

测试表单

提交的数据：

下一步#

自定义#

源码解析#

一小时基于pi-mono实现类似openclaw的agent系统，pi-agent上手实践（云端agent系列 二）

开整#

新建独立的 Agent 服务#

对接 E2B 沙盒流程#

前端 UI 增加技能管理#

1. 实现 /api/skills 接口（支持 multer 文件上传）#

2. 前端 UI 增加技能管理模块#

下一步#

一小时基于E2B实现一个完整的云端Agent，做一个云端沙盒助手（云端agent系列 一）

为什么#

简单架构#

开整#

一. e2b沙盒连接和使用#

二. 云端大模型\后端\前端 详细设计#

核心功能#

1 功能模块#

2. 核心流程#

实现及优化#

模型吞噬人类，社区主流思想的转变，从agent到harness，放开模型的手脚，疯狂的探索

模型吞噬人类#

社区主流思想的转变#

放开模型的手脚，疯狂的探索#

但是那些没有天赋的人呢?他们的人生从一开始就浪费了吗?

AI时代，你落后了吗，纠结良久最终我还是没有付费 not-by-ai 贴纸（待续）

一、AI时代，你落后了吗#

二、别感冒#

三、多吃饭#

四、not by ai#

消失的一个月，我做了什么（待续）

fresh2开发及快速入门（2）重构三国

一小时基于pi-mono实现类似openclaw的agent系统，pi-agent上手实践（云端agent系列二）

一小时基于E2B实现一个完整的云端Agent，做一个云端沙盒助手（云端agent系列一）

二. 云端大模型\后端\前端详细设计#