模型的新货架：从 Grok 4.6 上架 Pi 说起
#博客更新

先声明立场：我是 Pi 团队的人，这篇难免「利益相关」。但正因为在场内，有些观察比外面看得早一点——下面所有数据都是公开可查的。

先说结论

模型分发的主战场，正在从「上架应用商店」变成「进 agent 运行时」。

过去一周有两件事让我对这个判断确定下来：

1. 8 月 13 日，xAI 官宣 Grok 4.6 可以在 Pi 使用。 模型发布次日单独发一条平台上架公告——这个动作本身比那条帖子重要。
2. DeepSeek Harness 的模型适配层 dsh-llm-pi-ai，底层就是我们的 @earendil-works/pi-ai。 这是我上一篇写 Harness 插件时亲手发现的：156k star 的仓库，模型接入的缝是用 Pi 的 SDK 铺的。

一个是模型厂商把 Pi 当渠道来官宣，一个是框架作者把 Pi 当底座来依赖。方向一致：agent 运行时正在变成模型的货架。

两件事的细节

Grok 4.6 登陆 Pi

Grok 4.6 是 8 月 12 日发的，主打长程 agent、跨代码库分析和自我验证。首发帖累计 2500 万浏览、近 3 万赞。第二天，官方账号单独发了一条：「Grok 4.6 is now available in Pi」——10.4 万浏览、1273 赞。

把这两条帖子的关系看清楚：模型发布是新闻，「在哪个运行时里可用」是后续剧情。 剧情线还在继续：Perplexity 的 CEO 拿 Grok 4.6 当 orchestrator 跑了 Wide-And-Deep-Research 基准，结论是它在性能-成本曲线上位于帕累托前沿。注意这个用法——模型的评价场景已经从「聊天打分」迁移到「在某个运行时的编排下表现如何」。

pi-ai 在 Harness 的地基里

上一篇插件教程里我提过这事，这里补上量化的一面：

@earendil-works/pi-ai
周下载（8-15 ~ 8-21）：4,236,540
最新版本：0.84.2（8-14 发布）

DeepSeek Harness 把它用作 LLM seam——README 原话是 "Generic multi-provider adapter for the harness LLM seam backed by @earendil-works/pi-ai"。翻译一下：Harness 里每一次换模型、配 provider、接 OpenAI 兼容网关，底下跑的都是 pi-ai 的抽象。

这不是我们去找 DeepSeek 谈的合作，是他们选型选中的。被当成基础设施用，是对一个库最好的验证方式——比任何 benchmark 都硬。

为什么货架会易主

回头看技术产品史，分发渠道的迁移有迹可循：

● 搜索引擎时代，浏览器默认搜索引擎是渠道，Google 付费买位
● 移动时代，App Store 上架位是渠道，首发渠道能决定一款应用的命运
● 云时代，**云市场（Marketplace）**是渠道，企业软件先上 AWS Marketplace 再谈销售

AI 时代的等价物正在显形。模型能力在快速同质化——DeepSeek 8 月三连发（V4-Pro → V4-Flash API → Vision-Exp）、GLM、Kimi、Qwen 都在月更节奏里，当供给过剩，渠道价值就上升。而 token 消耗最大的场景已经不是聊天框，是 agent：一个长任务动辄几百次调用。模型厂商要抓住的，是这些调用的入口。

入口在哪？就在运行时的那个模型选择器里。上一篇我在 dsh 的 Web UI 里把 provider 从 DeepSeek 切到自定义的 mock——那个下拉菜单就是货架。用户在那个菜单里能看到谁、默认是谁、切换成本多高，决定了模型的实际市场份额。

DeepSeek 自己看得最明白：低价 API 加自研 harness，模型和货架一手抓。这是官方版答案。而 xAI 选择的是另一条路——不自己造货架，把模型铺进别人已有的货架，Pi 是其中之一。

站在货架上是什么感觉

坦白讲，感受是复杂的。

好的那一面：pi-ai 五个月做到周下载四百多万，说明「多 provider 抽象」这个判断做对了——开发者不想为每家模型写一遍适配，模型厂商也不想让集成成本挡住试用。

不安的那一面：当一个库从产品变成公共契约，它的错误预算就没了。 以前发个 0.x 版本改接口，坏的是自己的项目；现在底下压着 Harness 这样的框架和它们身后成千上万的会话，兼容性和版本语义就是别人的生产环境。dev preview 可以随便破兼容，底座不行——这也是我从 Harness 文档里读到 "breaking changes expected" 时格外有共鸣的原因：他们可以这么说，我们不能。

接下来会怎样

三个预测，放在这里等着验证：

1. 「available in X」会成为模型发布的标准动作。 X 是一张运行时清单，就像今天 App 官宣支持 iOS/Android 一样自然。下一个官宣登陆某个 agent 运行时的模型，不用等太久。
2. 运行时的竞争会从功能转向生态位。 功能会被抄平，「谁的模型选择器里有谁」「谁是新模型的首发渠道」不会。Harness 开源五天 7174 个插件仓库抢的就是这个位置。
3. 模型评测表会多出一列：在哪些运行时可用。 单独的分数不够了，编排质量正在成为模型表现的一部分——Perplexity 那个 orchestrator 实测就是预演。

对我们自己，结论也简单：渠道不是终点。被依赖就要配得上依赖——接下来 pi-ai 的每个版本号，都是对下游的一份承诺。

参考资料

● xAI：Grok 4.6 is now available in Pi（数据来自 OKP genai-hot 追踪记录）
● dsh-llm-pi-ai README
● @earendil-works/pi-ai on npm
● 本系列前两篇：Hi, deepseek-harness! / 给 DeepSeek Harness 写插件

via 棒无

棒无

给 DeepSeek Harness 写插件：从 hello-plugin 到一条能力缝 - 棒无

实测跑通官方插件开发教程：写一个真有用的 web_fetch 工具，用 mock LLM 跑出真实调用轨迹（含截图），外加一个关于 Pi 的彩蛋。

给 DeepSeek Harness 写插件：从 hello-plugin 到一条能力缝
#博客更新

via 棒无

Telegraph

给 DeepSeek Harness 写插件：从 hello-plugin 到一条能力缝

先说结论 上一篇我把 Harness 关了，因为它的 Web UI 不是我的菜；但「一切皆插件」这个架构我认。这篇把官方插件教程（basic → framework → practice）从头跑了一遍，而且没停在 hello-world：我写了一个真正有用的 web_fetch 工具插件，并用官方 mock LLM 跑出了真实的调用轨迹，截图为证。 给 dsh 写插件的门槛比想象低：一个导出 apply(ctx) 的 TypeScript 函数就是完整的插件。 真正要掌握的其实不是 API，而是三个心智模型：…

Hi, deepseek-harness!
#博客更新

DeepSeek 于 2026-08-13 发布 Harness v0.1 开发者预览版，MIT 许可证开源

::github{repo="deepseek-ai/deepseek-harness"}

期待已久的 DeepSeek 官方 Harness 终于来了，我却体验不到十分钟就放置了（也许是我习惯了现有的 coding agent 的使用，目前依然是偏向 CLI）我们也有自己的基于 Pi 的 web UI 云端 agent——cohub

先声明一句：下面是个人体验 + 架构速读，不是评测。Harness 现在还是 developer preview，官方 README 自己都写了「未来将出现破坏兼容性的变更」，所以这篇写的是 2026-08-17 这一周的它。

先把事实摆一下

DeepSeek Harness（命令是 dsh）不是新模型，是一个 agent harness。官方主页把它概括成一句话：

Agent = Model + Harness

模型是灵魂，harness 是让 agent 认识环境、调用工具、在真实环境里持续干活的那一层。这层以前是各家 coding agent 各做各的，现在 DeepSeek 自己下场开源了一个。

发布一周的数据很夸张：

● GitHub 五天 15 万+ stars（我 8 月 18 号查 API 是 156,653，这个增速本身就少见）
● 官方 X 帖 19,000+ 赞、近 400 万浏览，HN 731 分
● 知乎热榜第一挂了 253 个回答，小红书出现成体系教程（「从 0 开始成为高手」这种）
● Ollama 社区已经在搞 ollama launch dsh，Reddit 有人拿 Qwen3.8-27B 塞进去实测，X 上有单卡 4090 48GB 跑 Q8 约 100 tokens/s 的帖子

生态第一波反应速度比很多模型发布都猛。装起来也确实快：

npx @deepseek-ai/dsh web

Node 环境有的话一条命令，浏览器打开 127.0.0.1:3080。

十分钟之后我把它关了

流程是这样的：起来之后是个 Web UI，先去 Settings 里填 DeepSeek API key，然后「Choose workspace」选一个项目目录，之后才能开会话。中间每一步都顺，没有报错，就是——

我是在终端里干活的人。我的日常是 Claude Code / Codex 这类 CLI 工具，一个命令进目录，直接开始改代码。Harness 第一版只有两个官方 profile：web 和 headless（headless 是跑一次性任务，打印结果退出）。没有官方 TUI。于是十分钟里我的注意力被「配 key、选 workspace、认识界面」吃掉了，还没走到真正干活那一步，就关掉了。

说实话，关掉它的时候我心里清楚：这不是它的问题，是我已经不是它的第一目标用户了。v0.1 明显是 web-first 的产品节奏，先让用户能在浏览器里看见轨迹、看 Trajectory 视图、点 fork/resume。这个选择对「想让更多人先上手」是对的，只是恰好跟我的肌肉记忆反着。

但我放下它，不是因为觉得它没东西。恰恰相反，睡前我又把它的架构文档读了一遍，然后觉得这事值得写下来。

它的架构是「真插件化」

「Everything is a plugin」这种话每家都在喊，但 Harness 是少数真的把这句话落到加载器层面的。底层是一个叫 Cordis 的元框架（DeepSeek 自己维护，还配了一篇论文），几个关键设计：

模型、工具、技能、会话、沙箱、存储、loop、调度、UI，全是插件。 官方原文列的就是这些，包括 agent loop 本身。没有「特权核心」——session log 可以换，agent loop 可以换，你是在旁边挂一个新插件，而不是 fork 仓库改源码。

注册是可逆副作用。 插件通过 ctx.effect() 挂注册，卸载时自动回滚。所以插件可以热加载、热卸载，不会像很多框架那样卸了还留一串幽灵 handler。

依赖通过注入声明。 插件声明 inject 它需要的服务（ctx.tools、ctx.llm、ctx.sessions），加载顺序由依赖关系推导，而不是手工写 boot 顺序。事件分 emit / waterfall / parallel / serial 四种派发模式，写在类型系统里。

组合靠 patch 层叠。 一次启动是这么叠出来的：

dsh-base（模型适配/工具/持久化/沙箱/审批/遥测）
  → dsh-web-app（浏览器应用）或 dsh-headless（一次性 runner）
  → profile 自己的 cordis.patch.yml
  → home 级 cordis.patch.yml
  → --patch 覆盖层

dsh --dump-config 能看到你这台机器实际 boot 出来的整棵树，树里任何一行都可以用你自己的 patch 换掉。这个设计对「个人魔改」和「企业定制」是同一个答案：不用改源码，改配置。

另外两个我觉得认真的地方：

● Every run is traceable。 模型看到的一切都进 append-only session log：system prompt、推理、工具调用与结果、子 agent 调度、上下文注入。Trajectory 视图按来源检视，fork / resume / replay 都基于同一条事件流。这个对调试 agent 比什么指标都有用。
● 四种 runtime mode。 Standard（全工具集）、Code（用模型生成的代码编排多轮工具调用）、Minimal（只剩 shell + 文件编辑器，拿来 benchmark 模型）、Creator（在内存里试插件）。最后一个模式说明他们想清楚了自己的开发者是谁。

我真正在意的：harness 层开始卷了

这件事比「DeepSeek 出了个 coding agent」重要。它意味着 harness 从一个各家私有的实现细节，变成一个公开的、有官方玩家的层。

● DeepSeek 的模型价格低（V4 Flash 公测那波降价很凶），harness 是模型的分发通道——低价的模型 + 好用的运行时，这个组合拳才是完整的
● 插件生态就是第二个分发通道：模型厂商、工具厂商、服务商都能通过插件进来，dsh-plugin topic 已经在运转，社区插件聚合站也出现了
● 社区验证了它的开放性：Qwen 模型、Ollama、J-Space（社区 harness，有人测出 Terminal Bench 87.9→90.1，社区基准非官方）都挂上去了

当然，也有实打实的风险：dev preview 阶段 API 会破，star 数不代表留存，插件生态要等真实的开发者留存才能判断。X 上有条评论我印象很深，大意是「插件化解决了生命周期和副作用，但拓扑不是语义——换工具容易，决定什么该重试、什么该升级给人，才是 harness 的难点」。我认同这个说法。这也是为什么我虽然十分钟就关了它，还是会把它的 repo 和社区 keep 在视野里。

和 cohub 的关系

disclosure：cohub 是我们公司（Viscept）的产品，基于 Pi 做的云端 agent，web UI。有人可能觉得「你们也是 web UI，怎么评价人家的 web UI」——正因为我们也在这条路上，我才更清楚 web-first 和 local-first 是两条不同的产品路径：

● Harness 是 local-first：你的代码、key、日志都在本机，装好即用，隐私边界清楚
● cohub 是云端的：环境在远端，从浏览器就能进，不用管本机依赖

两条路径都成立，目标用户有重叠但不完全一样。Harness 出来那天，Pi 的作者也在 X 上公开聊过（686 赞的那条），态度是欢迎的——harness 层有更多人认真做，对所有做 agent 产品的人都是好事。

最后

我现在的态度很简单：第一版还轮不到我日常用，但它把「一切皆插件」当真了，并且把可追踪性做成了运行时约束而不是宣传词。这两点，我会继续盯着。

下次它出 TUI 的时候，我会再花十分钟。

参考资料

● DeepSeek Harness 官方主页
● deepseek-harness GitHub（README / 架构文档 / CLI 文档）
● Cordis 论文：A Programming Paradigm for Spatiotemporal Composability
● OKP 证据页：DeepSeek Harness v0.1 热度追踪
● Reddit：Qwen3.8-27B + DSH 实测帖
● 知乎：Harness 评价讨论

via 棒无

Cohub

Cohub — create, play, and build with people and agents

A living Space for people and agents. Start on the web or from a local folder via CLI. Save Checkpoints. Publish Live Works.

Cohub 实操：用一个 Space 从零搭一个可发布的小工具
#博客更新

disclosure：这是我们公司（Viscept）做的产品，这篇是实操向，我会讲清楚每一步在干什么、有什么坑。

先说结论

如果你想试 Cohub，最快的入门路径不是看文档，而是走一遍真实的闭环：

创建一个 Space → 和 Agent 说需求 → 它建文件/装依赖/跑起来 → Save 存 Checkpoint → 发布成 Work

整个过程大概 20 分钟。这篇文章记录我实际跑通的步骤，包括遇到的坑。

第一步：创建 Space

Cohub 的核心单元是 Space。你可以把它理解成「一个隔离的开发环境 + 对话 + 文件系统 + Agent」。

用 CLI 创建（cohub 是官方 CLI）：

# 安装（如果你还没有）
npm install -g @neta-art/cohub-cli

# 登录
cohub auth login

# 列出你的 spaces
cohub spaces ls

# 创建新 space
cohub spaces create --name "my-first-tool"

或者直接在 web 上点 New Space 也行。我建议至少 CLI 装一个，因为后面很多操作 CLI 更快。

第二步：和 Agent 提需求

创建之后，打开 Space，跟 Agent 说你要做什么。关键是要把需求讲清楚，就像跟一个工程师同事提需求：

帮我做一个 Markdown 转 HTML 的小工具，输入一段 markdown，输出渲染后的 HTML。要能选样式主题，还要有一个预览区域。

注意几个点：

1. 说目标，不说实现。不需要告诉它用什么库，它会自己选。
2. 一次一个需求。第一轮先让它把核心功能做出来，再迭代加功能。
3. 它可以读写文件、跑命令。Agent 不是只回复文本，它会在 Space 的文件系统里创建文件、装依赖、跑 dev server。

第三步：看它干活，必要时纠偏

Agent 开始干活后，你会看到它：

● 创建项目文件（package.json、源码等）
● 跑 npm install 装依赖
● 启动 dev server，暴露预览端口

这里有个经验：Agent 第一次做出来的东西，大概率不是你要的最终版。正常的迭代节奏是：

第一轮：核心功能能用
第二轮：你试了，提反馈（"样式太丑""这个按钮没反应"）
第三轮：它改，你再试

在 Cohub 里，你可以在同一个 Space 的预览区直接试它做出来的东西，不用自己本地跑。这个循环比「聊天里来回贴代码」高效得多。

第四步：Save（Checkpoint）

当你对当前状态满意（或者到了一个里程碑），存一个 Checkpoint：

cohub -s <space-id> spaces checkpoints create --message "markdown-to-html v1 done"

为什么这个重要：

1. 它是不可变快照。之后再怎么改，都能回到这个点。
2. 可以 fork。从这个 Checkpoint 分支出新想法，不影响主线。
3. 是可分享的稳定基底。别人可以基于你的 Checkpoint 继续工作。

这比 git commit 更像「存档」——你随时能回到任何有意义的时刻。

第五步：发布成 Work

这是 Cohub 和大多数 AI 工具最大的区别：Agent 的产出可以直接发布成一个公开可访问的页面（Work）。

# 把项目构建成静态文件后发布
cohub -s <space-id> spaces files ls

# 发布目录为 Work
cohub -s <space-id> works publish my-tool --file dist/index.html

发布后你会得到一个公开 URL，任何人打开就能用你做的工具。这个 Work 还可以：

● 配置访问权限
● 用 Work Commerce 变现（卖功能解锁/积分）
● 被 fork 和 remix

实际遇到的坑

坑 1：Agent 装依赖慢

第一次让 Agent 跑 npm install，如果网络慢会等很久。解决办法：让它用国内镜像，或者先用最简依赖把核心跑通，再逐步加。

坑 2：端口预览 vs 实际发布

开发时 Agent 起的 dev server 端口，和发布后的静态托管不是一回事。如果你做的是 SPA 或需要后端的应用，发布时要注意：

● 纯前端 → 构建后发布 dist/ 即可
● 需要后端 → 用 Cohub 的 Sandbox 能力或对外部 API

坑 3：迭代时别丢上下文

每轮给 Agent 反馈时，引用具体现象（"点击提交后没反应"）而不是模糊的（"好像不太对"）。Agent 在同一 Space 里有完整上下文，具体反馈能让它精准修改。

写在最后

Cohub 最有意思的地方，是把「和 AI 协作做东西」从聊天里搬到了一个有文件、有环境、能发布的真实空间里。

你可以把它当：

● 快速原型工具（几分钟做个工具验证想法）
● 一个带 Agent 的完整开发环境
● 一个内容/工具的分发平台（Work）

如果你还没试过，建议按这篇的流程走一遍。从"让 AI 聊天"到"让 AI 帮你把东西做出来并发布"，这个转变，用了才知道。

----------------------

● 产品：cohub.run
● CLI：npm install -g @neta-art/cohub-cli
● 生态索引：github.com/markbang/awesome-cohub

via 棒无

Cohub

Cohub — create, play, and build with people and agents

A living Space for people and agents. Start on the web or from a local folder via CLI. Save Checkpoints. Publish Live Works.

Docker 生产实践：从能跑到跑得稳的 Checklist
#博客更新

先说结论

「Docker 能跑」和「Docker 能稳定跑」是两回事。本地 docker run 一次成功，和在生产集群里扛住流量、重启、扩容，中间隔着不少坑。

这篇文章是我在生产环境踩过之后总结的 Checklist。不追求面面俱到，只讲高频、高影响的十件事，按重要程度排序。

1. 镜像尽量小，但要小得有理

镜像体积直接影响拉取时间和启动速度。常见手段：

● 用 alpine 或 distroless 作为基础镜像
● 多阶段构建：构建阶段用全量镜像，运行阶段只拷贝产物
● 清理不必要的缓存和包管理器元数据

# 多阶段构建示例
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
EXPOSE 3000
CMD ["node", "dist/index.js"]

但注意：不是越瘦越好。distroless 没有 shell，调试会很痛苦；alpine 的 musl libc 偶尔和依赖有兼容问题。先瘦到合理范围，别为了几十 MB 自找麻烦。

2. 非 root 用户运行

默认容器内是 root，这是安全大忌。一旦容器被攻破，攻击者就是 root 权限。

FROM node:20-alpine
# 创建非 root 用户
RUN addgroup -S app && adduser -S app -G app
USER app

大多数官方镜像现在都支持直接切用户。这一步成本极低，收益很高。

3. 健康检查必须配

没有健康检查，编排系统（K8s/Swarm）就不知道你的容器是不是真的活着。进程在不代表服务可用。

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD wget -q -O - http://localhost:3000/healthz || exit 1

注意 start-period——给应用启动留时间，别一上来就被打回。

4. 日志打 stdout，别写文件

容器里的日志应该走 stdout/stderr，由编排系统收集，而不是写到容器内的文件。原因：

● 容器文件系统是临时的，重启就没了
● 你没法轻易拿到容器内的文件
● 云平台（CloudWatch、ELK、Loki）都从 stdout 收集

所以应用日志直接 console.log/print，别自己写日志文件轮转。

5. 资源限制，不是可选项

不设 --memory 和 --cpus 限制，一个失控的容器能拖垮整个节点。

# docker-compose 或 k8s 里都要设
resources:
  limits:
    memory: 512M
    cpus: "0.5"
  reservations:
    memory: 256M

limits 一定要设，reservations 至少给一个合理值。这是生产环境第一道防线。

6. 环境变量和密钥，别硬编码

镜像里不要写死任何密钥。用：

● 环境变量（运行时注入）
● Docker secrets / K8s secrets
● 专门的密钥管理（Vault、云厂商的 secrets manager）

镜像一旦构建就难以「撤销」里面硬编码的密钥。密钥泄露的补救成本远高于一开始就用环境变量。

7. 固定依赖版本，别用 latest

FROM node:20-alpine 里的 20 可能今天和明天解析到不同的小版本。生产环境要可复现：

● 基础镜像用精确 tag（如 node:20.18.0-alpine）
● 依赖锁文件（package-lock.json / poetry.lock）进镜像
● 有需要时用 digest 固定镜像

可复现 = 可回滚 = 可调试。

8. 处理僵尸进程和信号

容器作为 PID 1 时，要正确处理信号（SIGTERM）和孤儿进程。常见方案：

● 用带 PID 1 处理的运行时（如 tini）
● 确保应用能优雅关闭（监听 SIGTERM，完成在途请求）

RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["node", "dist/index.js"]

不然 docker stop 会变成 kill -9，数据库写一半就没了。

9. 镜像构建也要考虑 .dockerignore

.dockerignore 能大幅减少构建上下文和镜像体积，避免把 node_modules、.git、日志、临时文件打进去。

node_modules
.git
*.log
.tmp
dist

这也是多阶段构建里第一层就过滤掉的东西。

10. 一个容器一个职责

别在一个容器里跑 web + worker + cron。拆开：

● 各自独立扩缩容
● 一个挂了不影响其他
● 日志、健康检查、资源限制都更清晰

一个容器只做一件事，是容器化最大的架构收益。

验证清单

改完以后，跑一遍这个验证：

# 1. 镜像构建成功且体积合理
docker build -t my-app .

# 2. 容器能启动且健康检查通过
docker run -d --name test -p 3000:3000 my-app
docker inspect --format='{{.State.Health.Status}}' test
# 期望: healthy

# 3. 优雅停止
docker stop test
# 观察日志是否有优雅关闭记录

# 4. 资源限制生效
docker run --rm -m 256m my-app
# 期望: 超出限制时 OOM，而不是拖垮宿主

写在最后

这十条里，健康检查、资源限制、非 root、日志走 stdout 是成本最低、收益最高的四项，强烈建议从这些开始。

容器化不是终点，只是起点。把这些基础打牢，后面接 CI/CD、上 K8s 才会顺。

如果哪条你踩过不同的坑，欢迎交流。

via 棒无

棒无

Docker 生产实践：从能跑到跑得稳的 Checklist - 棒无

把容器从"本地能跑"带到"生产稳定"，我总结了 10 个最常见的坑和对应的最佳实践：镜像体积、安全、健康检查、日志、资源限制。

Neta Studio：用 AI 造一个可以走进去的世界
#博客更新

via 棒无

Telegraph

Neta Studio：用 AI 造一个可以走进去的世界

disclosure：这是我们公司（talesofai）的产品，这篇文章不是纯客观测评，但我尽量讲技术和设计。 先说结论 大部分人知道捏Ta（Nieta），是因为 AI 生图。但 neta.art 背后真正有意思的东西是 Neta Studio——一个 AI 世界观引擎。 你给它一句话描述一个世界，它帮你把这个世界造出来：角色、场景、故事线、视觉小说、交互地图、甚至可玩的小游戏。不是生成一段文字或一张图就完了，而是生成一个可以走进去、可以交互、可以 fork 给别人继续扩展的世界。 这件事的难点不在于 AI…

#博客更新

2026年7月29日 Everyday we talk a little less. 半个月辗转了两个地方 我还没忘记自己是谁。如果哪天我们分开了，希望是山有雾..... 最近上班有点透支了 我是棒无，最近打算重启博客了！ 在毕业后的一个多月里，我度过了很漫长的日子

via 陪棒无度过漫长岁月

Cohub：让人和 Agent 真正在同一个空间里干活
#博客更新

via 棒无

Telegraph

Cohub：让人和 Agent 真正在同一个空间里干活

先说结论 如果你用过各种 AI 编程工具，大概率遇到过同一个问题：聊完就没了。对话记录在，但文件、环境、上下文散落各处，换个会话就得从头来。 Cohub 想解决的就是这件事--不是给你一个更好的聊天框，而是给你一个能干活的空间。 具体来说，Cohub 是一个浏览器端的 Space，人和 Agent 在同一个空间里：有文件系统、有沙箱执行、有会话、有 checkpoint 存档、还能把成果发布成公开的 Work。它不是我见过的大多数 "AI + 编辑器" 的路子，更像是把一个完整的开发环境做成了可以和人协作的活的载体。…

修 Traefik Kubernetes Gateway CPU 尖刺
#博客更新

via 棒无

Telegraph

修 Traefik Kubernetes Gateway CPU 尖刺

先说结论 这次问题不是“Traefik 转发慢”，也不是单个请求路径的问题。 它更像一个控制面成本被放大的例子：Kubernetes 对象一变，Traefik 的 Kubernetes provider 收到 informer 事件，然后重新构建动态配置。单次 rebuild 看起来没什么，但当 EndpointSlice、Node 心跳、Gateway/Route 数量一起上来以后，就会变成很密的 CPU 尖刺。 我这次在本地 ~/code/traefik 的 fix/k8s-gateway-cpu-spikes…

#博客更新

20226年6月5日 结束了大学生涯 希望再走的慢一点慢一点.... 好长时间没发了 可能最近真的很忙吧 加油

via 陪棒无度过漫长岁月

让 AI 写好前端，我现在会先把这些话说清楚
#博客更新

先说结论。

让 AI 写好前端，重点不是多给它一点“灵感”，而是先把它容易乱跑的边界收紧。

我这阵子在折腾一个 tmux 相关的 web 项目，页面和终端渲染被我和 AI 来回改了很久。改到最后我越来越确定一件事：

前端做不好，很多时候不是模型不会写代码，而是我们喂给它的要求太松了。

你如果只说一句“帮我做个好看的页面”，它大概率会回到最常见的网页套路：

● hero 很大
● card 很多
● badge 一排
● shadow 和 radius 也不缺
● 看起来很努力，但就是没有自己的味道

它能把东西做出来，但不一定能做成你想要的样子。

1. 先分清楚：你到底要它做什么

这个问题看起来简单，但其实最关键。

很多前端任务混着三件事：

● 页面结构：信息怎么排
● 视觉方向：看起来是什么气质
● 交互边界：哪些地方脆弱，不能乱碰

如果这三件事混在一起，AI 就会很容易把注意力放错。

比如我那个项目里，终端视口其实是最脆弱的部分。它不是普通卡片，也不是普通文本块，更不是一个可以随便加阴影、加浮层、加复杂布局的区域。

它更像一个设备边界。

所以我后来改法就变了：

● 产品骨架先稳定
● terminal 只负责 terminal
● 外层 chrome 只负责信息和操作
● 视觉装饰尽量收敛

这一步很重要。因为如果你不先告诉模型“哪个模块不能乱碰”，它就会自然而然把每个模块都当成可优化对象。

2. AI 最容易回退到模板味

这个我觉得是 AI 前端里最常见的问题。

只要 prompt 稍微模糊一点，它就会滑回训练数据里的高频网页模式。

结果通常长这样：

● 结构没错
● 组件也齐
● 配色也不丑
● 但一眼看上去就是“AI 做的”

为什么会这样？

因为模型默认会选最稳的解，而不是最有个性的解。

而所谓“稳”，对很多前端任务来说，恰好就是模板味。

所以如果你真的想让它写出有 taste 的页面，不能只让它“自由发挥”，而要给它更具体的偏好：

● 这个产品像什么
● 不是哪个风格都能用
● 哪些元素默认不要
● 哪些信息一定要先出现
● 哪些层级必须压住

这不是限制 creativity。

相反，这是在给 creativity 一个能落地的边界。

3. 第一屏不是信息仓库

我现在越来越不喜欢那种什么都往第一屏塞的做法。

很多 AI 页面看起来“内容很多”，实际上是没想清楚第一屏到底干什么。

第一屏最重要的不是堆信息，而是先把这几件事说清楚：

● 这是什么产品
● 它和别的东西有什么不同
● 用户为什么应该继续看下去
● 你这个页面的主情绪是什么

如果第一屏什么都想讲，最后通常什么都讲不清楚。

我现在比较认可的一种方法是：

● 第一屏只负责建立身份
● 第二屏再补场景
● 第三屏讲功能细节
● 最后再给操作入口

也就是每一段只做一件事。

这个原则看起来朴素，但很好用。因为 AI 很容易把 section 写成平铺直叙的内容清单，而不是有职责的页面段落。

4. 默认不要卡片，真的有用

这个判断很狠，但我发现它很好用。

很多 AI 页面的问题，本质上是太喜欢卡片了。

什么都要卡片：

● hero 里要卡片
● 特性区要卡片
● CTA 附近也要卡片
● 甚至一段说明文字也要 border + shadow + radius

最后页面就很“忙”，但没有重点。

我现在会先问自己一个问题：

如果去掉 border、shadow、background、radius，这块内容还成立吗？

如果还成立，那它大概率就不该是卡片。

这个判断能帮你砍掉很多不必要的视觉噪音。

而且它特别适合拿来约束 AI，因为模型很爱“补装饰”。你不给规则，它就一直补。

5. 先定设计系统，再让它写

AI 写前端最怕的不是不会写，而是写着写着风格漂了。

今天一套颜色，明天又一套按钮，后天再换一层背景逻辑，最后整个页面就散了。

所以我现在更倾向于先定这些东西：

● background / surface / text / muted / accent
● 主要字号层级
● 按钮风格
● 间距节奏
● 圆角和边框的使用规则

这套东西最好在 prompt 之外就先写成 token 或设计说明。

因为 AI 其实挺擅长遵守“明确的系统”，不太擅长自己现场发明一套又一套。

如果你一开始就把系统定住，它后面写页面会稳很多。

6. 视觉参考比“高级”这种词更重要

“高级”“极简”“有氛围”这些词，听起来很对，但其实很滑。

模型看到这种词，往往只能往自己最熟的方向靠。

所以我现在更愿意直接给它：

● 参考图
● mood board
● 颜色锚点
● 字号节奏
● 气质描述

因为这些东西比“高级一点”这种抽象词有用得多。

前端设计不是让模型猜，而是让它有一个明确的视觉方向可以靠。

尤其是有 taste 的项目，很多时候不是模块不够，而是审美方向不统一。

7. 给它页面叙事，不只是组件清单

这个点我觉得也很关键。

很多人让 AI 做页面的时候，给的是组件列表：

● header
● hero
● feature cards
● CTA
● footer

但页面不是部件拼装，它应该有自己的叙事。

比如：

● 先建立身份
● 再补场景
● 再讲差异点
● 最后落到动作

如果你只给模块，它就会把这些模块平均地摆出来。

如果你给的是叙事，它才知道每个 section 的职责。

我现在会直接在需求里写：

● 第一屏负责什么
● 第二屏负责什么
● 哪些内容要晚一点出现
● 哪些元素不能抢主视觉

这会比“做个漂亮页面”有效得多。

8. 验证链路要早点放进去

前端最烦的一种情况是：

代码看起来对，页面其实不对。

比如：

● 移动端溢出
● fixed 层遮住按钮
● 某个断点布局崩了
● 终端视口尺寸不对
● 页面 chrome 压到内容

这些东西只看代码经常看不出来，必须跑起来看。

所以我现在会尽量让 AI 带着验证去改，而不是只让它改完代码就算了。

最简单的方式就是：

● 跑测试
● 看截图
● 检查响应式
● 确认关键交互能点

如果能加 Playwright 这种自动化检查，会更稳。

它不是为了“显得工程化”，而是真的能减少很多肉眼不容易发现的问题。

9. 我现在让 AI 写前端的默认流程

我大概会这么做：

先写清楚边界

● 这个页面是给谁用的
● 它是管理台、控制台，还是展示页
● 哪个区域是脆弱区，不能乱改
● 哪些模块可以大胆做视觉

再给明确的 taste

● 深色还是浅色
● 克制还是热闹
● 偏产品感还是偏编辑感
● 更像工具，还是更像作品

然后给验证目标

● 桌面端要怎样
● 移动端要怎样
● 关键状态要怎样
● 不允许出现什么问题

最后再让它动手

这样出来的结果通常比“直接开始写”稳很多。

10. 说到底，前端不是堆组件

我越来越觉得，AI 前端最重要的不是“会不会生成页面”，而是你有没有把 art direction 这件事交代明白。

LLM Wiki：把上下文编译成会生长的知识库
#博客更新

via 棒无

Telegraph

LLM Wiki：把上下文编译成会生长的知识库

TL;DR Karpathy 这个 LLM Wiki 想法，我觉得最重要的地方不是“用 AI 总结文档”，而是它换了一个知识库的维护方式： 不要每次提问时才从原始资料里重新检索、重新拼答案，而是让 LLM 持续把资料编译成一个结构化、可链接、会更新的 Markdown Wiki。 说白了，传统 RAG 更像是“临时翻资料回答问题”，LLM Wiki 更像是“先把资料整理成一本不断修订的内部手册”。 这两件事听起来都和知识库有关，但实际体验差别很大。 RAG 的问题是，它经常没有积累。你今天问一个问题，它…

Vite+ 会成为我的新前端默认工具链吗
#博客更新

via 棒无

Telegraph

Vite+ 会成为我的新前端默认工具链吗

结论先说。 如果今天让我新开一个前端项目，我大概率会优先考虑这套组合： Vite 8 作为 dev/build 的基础 Vite+ 作为统一入口，接管 create、dev、build、test、lint、format、run Oxlint + Oxfmt 替代大部分 ESLint / Prettier 的日常反馈链路 Vitest 4 做单测、组件测试和 Browser Mode Playwright 负责真正的端到端和移动端模拟 monorepo 场景下，用 Vite+ 的 task runner …

#博客更新

2026年4月19日 一切都会到来 写完了毕业论文，完成了最后一次体测，日子就这样一天天过去，亲爱的朋友，我们来日方长

via 陪棒无度过漫长岁月

#博客更新

2026年4月9日 请保持幸福

via 陪棒无度过漫长岁月

这份写给工程师的 ML Primer，真正厉害的是它重新组织了技术教育
#博客更新

via 棒无

Telegraph

这份写给工程师的 ML Primer，真正厉害的是它重新组织了技术教育

结论先说。 我把 dreddnafious/thereisnospoon 这份 primer 从头读了一遍，最后的判断是：它当然是一份很好的机器学习入门材料，但它最值得研究的地方，其实不是“把 ML 基础讲明白了”，而是它示范了一种更适合 AI 时代的技术内容形态。 说具体一点。 它不是在写一本传统教材，也不是在做一篇“神经网络扫盲文”。它真正做的事情，是先给工程师搭一套可以长期复用的心智模型，再把那些本来应该发生在老师、同事、mentor 身上的追问，留给你和 AI agent 在阅读过程中继续展开。…

GPT-5.4 做前端 为什么终于没那么模板味了
#博客更新

via 棒无

Telegraph

GPT-5.4 做前端 为什么终于没那么模板味了

结论先说。 OpenAI 这篇《Designing delightful frontends with GPT-5.4》里，我觉得最有价值的不是“GPT-5.4 更会做前端了”这句宣传话，而是它终于把一个很多人已经隐约感觉到的事实讲明白了： AI 做前端时，真正决定结果的，往往不是模型会不会写代码，而是你有没有把视觉约束、页面叙事、设计系统和验证链路交代清楚。 换句话说，前端质量不是一句“帮我写个 landing page”换来的。模型当然比以前强了，但如果输入还是模糊的，它依然会滑回那种最常见、最安全、也最没记忆点的网页模板。…

Agent 真正难的不是 Loop 而是工程系统
#博客更新

via 棒无

Telegraph

Agent 真正难的不是 Loop 而是工程系统

结论先说。 如果你最近在做 Agent，我觉得最容易踩的坑，不是模型不够强，而是太早把注意力放在模型本身，反而忽略了更影响结果的那几层工程系统：验证、上下文、工具、记忆和边界控制。 我刚看完 Tw93 那篇《你不知道的 Agent：原理、架构与工程实践》，里面有不少内容我挺认同。但我不想再把原文复述一遍，这篇我只提炼我觉得最值得带回项目里直接用的部分。 如果只记一句话，就是： Agent Loop 很小，真正决定系统能不能跑稳的，是 Loop 外面的工程设计。 1. Agent Loop 其实没那么神秘…

#博客更新

2026年3月19日 偶尔也会很累 近期变得忙起来了 觉得搞完论文中期汇报就好了 结果越来越忙....

via 陪棒无度过漫长岁月

Fuwari 里接 usememos 图文流 我是怎么做的
#博客更新

via 棒无

Telegraph

Fuwari 里接 usememos 图文流 我是怎么做的

结论先说，我这套“图文”功能本质上不是给 Fuwari 塞了一个复杂插件，而是做了一页单独的 Astro 页面 + React 客户端组件，再让它直接去请求 usememos 的 API，把 memo 数据转成适合博客浏览的卡片流。 真正关键的不是“把 API 调通”，而是中间那层数据清洗和展示重组：图片要从正文和附件里同时提取，标签行要去掉，作者信息要补齐，外链图片还要做一次 CDN 归一化。做完这些之后，图文页才像产品，不像接口调试页。 这篇我就按我博客现在的真实实现，拆一遍完整链路。 先看整体结构…