Feichuan's Blog

Buffin Assistant 过程区折叠设计

Sat, 08 Aug 2026 07:24:00 GMT

For future Claude

这页沉淀 Buffin 桌面端「assistant 回复过程区折叠」的最终设计（2026-08-08，经 Deepseek V4 Flash 设计 + Claude Opus 5 独立评审交叉验证，代码证据抽查属实）。核心：无协议层 phase 时用「尾部反向扫」判定正文区，异常/中断路径不折叠，纯前端实现。实现此功能或讨论 session 折叠/分层呈现时先读这页，与 [[Codex App 过程输出与最终回答分层]] 对照。

Buffin Assistant 过程区折叠设计

[!abstract] 当前结论折叠单位是单条 assistant 消息内部：尾部正文（narrative）始终展开，之前的过程区（reasoning / 中间文本 / 工具调用 / control-receipt）折叠为一行 ToolGroup 风格摘要。正文判定用尾部反向扫（不是「最后一个 text part」）。仅正常完成（status=completed）且开关开启时自动折叠；interrupted / failed / 待响应交互禁止折叠。纯前端，不改 @buffin/api / daemon / provider。

需求演进（用户原话要点）

「session 单次会话结束的时候，把上面输出合并成一小块，输出一个总结，类似 CodeX 分层回答」
「只把最后一次，状态变更成已完成时，把最后一次以外的内容进行折叠，纯前端」
「做成设置项，可能是一个开关」
最终澄清：「折叠的是 assistant 回复，不是 user 回复。assistant 回复有工具调用、思考、正文输出，最后一段正文最长最有价值。把上面的输出折叠，就像现有 ToolGroup 一样，用户可收缩展开。纯前端展示，不需要派生新的数据模型」
补充：「还要考虑错误情况——用户手动暂停或出错时，折叠行为应该怎样」

已知客观事实（代码证据）

正文判定的三种失效形状（Claude 评审发现，抽查属实）

run 以 tool-call 结尾：mapTurnStatus（apps/daemon/src/agent/providers/codex/protocol.ts:774-779）对 unknown/inProgress 一律判 failed，中断/失败 run 常以工具收尾 → 「最后一个 text part」是中间文本，语义反了
零 text part：handleControlCompleted（session-store.ts:451-482）无 open message 时新建只含 control-receipt 的 complete message → 正文区为空，整条被藏
late delta：run.completed 后迟到事件仍被 reduce（session-runtime-store.ts:102-111 无 terminal gate）→ 新建 text part 使原正文塌进折叠区

status 链路现状

三个 provider（codex/claude/scripted）全部发送 run.completed 的 status，类型为必填 4 值 union（apps/daemon/src/agent/types.ts:589-591；发出点 protocol.ts:283、translator.ts:358、scripted/runner.ts:106/215）
wire 契约已有 status?: string（packages/api/src/session-events.ts:41），协议包不用改
前端丢弃点：handleRunCompleted(state, _event, ...)（session-store.ts:199-219）形参 _event 从未解引用，所有 message 一律标 complete
陷阱①：interrupted 混合用户中断与进程崩溃（drizzle-repository.ts:114-120 把 crashed 和 interrupted 都映到 Interrupted，仅 reason 能区分）
陷阱②：中断不发 input.resolved（service.ts:1196-1199），前端 inputAction 永久停在 pending —— 待响应判定必须用 message 终态短路，而非仅 isRunning（deriveSessionDomain 已有同款先例 session-domain.ts:19-24）
手动中断链路完整：use-session-actions.ts:48 → interruptCurrentRun → terminateAndBroadcast(run.id, ‘interrupted’)（service.ts:1200）；pause/resume 不存在

组件现状

ToolRowBase 受控/非受控双支持、懒挂载 + 关闭动画保挂载（ToolRowBase.tsx:55-69），6 例权威测试
折叠动效用 Base UI Collapsible + CSS 高度过渡（styles/index.css:184-194），不是 framer-motion AnimatePresence（后者只用于消息列表 SessionThread.tsx:80）
useAutoOpenDisclosure（use-auto-open-disclosure.ts:8-10）只有 setOpen(true)，只能自动开不能自动关，且 userToggledRef 是 per-mount（切 tab 丢 override）
PartGroup 的 tool-group 变体没有 partIndex（SessionThread.tsx:669），而 text/reasoning 有（:654/:663）——按 partIndex 切分需先补齐
findActiveNarrativePartIndex（thread-presentation.ts:47-60）是从末尾反扫找 narrative part 的现成先例

设计决策

1. 折叠单位与判定：尾部反向扫

过程区（可折叠）           正文区（始终展开）
reasoning / 中间text /     →   尾部连续 narrative
tool-call × N / receipts

判定：从 parts 末尾反扫，遇非 text/reasoning 即停；若尾部第一个就不是 narrative，整个过程区不折叠（安全默认，覆盖 tool-call 结尾、零 text、late delta 三种失效形状）。与 findActiveNarrativePartIndex 同构，零新概念。

2. 触发条件

自动折叠 ⇔ message 终态 = completed ∧ 开关 on ∧ 无待响应交互 ∧ 尾部为 narrative

interrupted / failed → 不折叠，保留错误上下文（对齐 Codex App 的 isTurnCancelled → shouldAllowCollapse: false，见 [[Codex App 过程输出与最终回答分层]]）
待响应 ask-user/approval（复用 isPendingInteraction，session-domain.ts:55-59）→ 不折叠；注意渲染侧 ?? 'pending' 兜底（SessionThread.tsx:289/316），undefined 必须同默认，否则待响应表单被折叠
纯文本回复（过程区为空）→ 不渲染折叠块，退化为现状

3. 组件与动画

同级复用 ToolRowBase（不包 ToolGroup），header 显示统计摘要（命令数 / 文件数 / 耗时，result 缺失按完成计，过滤 status !== 'completed'）
折叠动画：Base UI Collapsible + CSS 高度过渡
冲突处理：ToolRowBase 首次展开才挂载 → 默认折叠时过程区 MarkdownPart 从未挂载，usePlaybackBuffer 的 catch-up 会在完成帧硬切（影响限于 run 刚结束一帧）

4. 状态与开关

折叠状态放 SessionRuntimeStore（同 composerText 待遇，跨 tab 存活 override）；rollback resync 重建消息时 GC（session-runtime-store.ts:94-100）
开关 autoCollapseTurns（默认 on）：存 device-chrome-store（现成订阅层）或 prefs 补订阅层；关闭时追溯展开已自动折叠的区域
手动展开/收起优先级高于开关（user override 恒胜）

与 Codex 协议层 phase 方案的关系

维度	Codex App（[[Codex App 过程输出与最终回答分层]]）	Buffin 本方案
分层依据	协议层 `agentMessage.phase = commentary \| final_answer`	呈现层「尾部反向扫」位置判定
折叠时机	final answer 首个 item 开始	message 正常完成后
依赖	需要 provider 支持 phase（Claude 等不保证）	零协议依赖，全 provider 一致
异常路径	turn cancelled 不折叠	interrupted/failed 不折叠（同源语义）
成本	provider 归一化 + phase 持久化	前端一行 status 恢复 + 纯派生

两者不冲突：本方案是 phase 缺失时的替代路径；若未来接入 phase，折叠时机可提前到 final answer 开始，判定降级为增强而非必需。

边界情况清单

纯文本回复：不折叠，退化为现状
run 以 tool-call 结尾 / 零 text part：不折叠
truncated 工具输出（session-store.ts:23）：在折叠 header 提示
滚动跳变：use-auto-scroll-bottom 按 scrollHeight 判 following（:115），折叠使其骤减，需复核
rollback resync：按 messageId 存的折叠态需 GC
AskUserTool 中断后仍渲染可��交表单（SessionThread.tsx:286-299 未 gate 终态，既有问题会被「pending 不折叠」放大）

实施范围

纯前端：SessionThread.tsx（折叠容器 + header）、session-store.ts（恢复终态 status）、settings 新条目、i18n（en/zh-Hans/zh-Hant）。对应 GitHub issue：#215（buffin-ai/buffin）。

来源

Deepseek V4 Flash 设计 agent（herdr w19，2026-08-06，只读调研 + 4 项修订）
Claude Opus 5 独立评审（herdr w19，plan 只读模式，2026-08-08，NOT READY 后修正，评审全文写入 ~/.claude/plans/agent-claude-code-buffin-stateful-tiger.md）
Buffin 源码抽查（session-store.ts / thread-presentation.ts / SessionThread.tsx / use-auto-scroll-bottom.ts / protocol.ts / translator.ts / runner.ts / drizzle-repository.ts / service.ts，2026-08-08）
GitHub issue buffin-ai/buffin#215
[[Buffin Session 界面性能]] — 折叠已落地，但 mountChildren + keepMounted 让折叠内容仍占 DOM

MengTo Skills Handbook

Thu, 30 Jul 2026 01:20:00 GMT

For future Claude

这页是 MengTo/Skills 的本机使用手册：定义、场景、调用方法、流水线、118 个 skill 全表、安装落点与验收标准。2026-07-29 已全量装入 ~/.agents/skills / Pi / Claude。需要选设计/复刻/动效/游戏类 skill、或把参考变成可执行 prompt 时先读本页。它解决「知道好看，但 agent 做不稳」的问题，不是通用工程流水线（工程流看 [[Matt Pocock Skills 使用手册]]）。

MengTo Skills Handbook

一句话定义

MengTo/Skills 是一组面向 设计师 + builder + AI coding agent 的 操作手册（SOP）库。

每个 skill = 一个文件夹 + 必选 SKILL.md
目标：把「好提示词 / 抓取流程 / 实现套路 / 审美约束」固化成可重复执行的版本化文件
适用 agent：Codex / Claude / Cursor / Pi / 其他 只要能加载 SKILL.md
仓库定位不是「装完就变强的插件」，而是 任务路由到对应 runbook，再按输出合同交付

官方仓库：https://github.com/MengTo/Skills

与其他 skill 体系的边界

体系	解决什么	何时优先
MengTo/Skills	设计方向、参考复刻、落地页/动效/WebGL、可玩网页游戏、灵感资产生产	视觉与交互质量、从参考到 prompt/实现
[[Matt Pocock Skills 使用手册]]	grill → spec → tickets → implement / TDD / review	工程需求澄清、架构、实现闭环
[[pi-skills-handbook]] / [[Agent Skills 与 SKILL.md 工作流]]	Pi/通用 skill 机制与本机能力地图	先理解 skill 系统本身

不要混用场景：

做 CRUD / 修 bug / 写后端契约 → Matt / 工程 skill
做 Awwwards 级站、GSAP 叙事、Three.js 小游戏、视频转 superprompt → MengTo
两边可串联：先用 Matt 把产品边界问清，再用 MengTo 做视觉与交互实现

哲学（作者四条，决定怎么用）

来源：README Philosophy

Prompts are assets — 好 prompt 存文件、版本化，不当一次性聊天。
Specs beat vibes — 约束、层级、「一次只改 1–2 件事」优于模糊审美。
References beat paragraphs — 截图/视频比长描述更能携带字体、间距、节奏。
Skills are operating procedures — 写清何时用、先做什么、默认值、别踩什么坑。

Agent 使用时的翻译：

不要「参考一下 skill 写点东西」
要「严格按 skill 的 workflow + quality bar 跑完并验收」

本机安装状态（2026-07-29 核验）

项目	状态
源 skill 数	118
`~/.agents/skills`	118/118
Pi `~/.pi/agent/skills`	118/118 链接
Claude `~/.claude/skills`	118/118
本地缓存副本	`~/.cache/mengto-skills`
Eve / PromptScript	不支持 global，跳过
`~/.codex/skills` / `~/.cursor/skills`	未单独落点（CLI 全局安装未完整写入这两处）

分类计数（以本机缓存 agent-skills/**/SKILL.md 为准）：

分类	数量	内容倾向
web-design	79	落地页、风格系统、动效、WebGL、布局细节
game-development	19	Three.js/可玩网页游戏系统与 QA
codex	17	采集、复刻、审计、迭代验证、内容生产工作流
media	2	图库选图
ui	1	设计优先 prompt 结构
合计	118

安装命令（本机实际路径）：

# 网络直装不稳定时可先浅克隆
git clone --depth 1 https://github.com/MengTo/Skills.git ~/.cache/mengto-skills
npx skills add ~/.cache/mengto-skills -g --all --full-depth

直装等价写法：

npx skills add MengTo/Skills -g --all --full-depth

更新：

npx skills update -g -y
# 或重装缓存副本

注意：本机已有 gsap-core 等 GSAP 系列 skill；MengTo 的实现 skill 名是 gsap，二者并存，不互相覆盖。

文件夹契约

agent-skills/<category>/<skill-name>/
  SKILL.md        # 必选：frontmatter + workflow
  REFERENCES.md   # 可选：只放链接
  ARTICLE.md      # 可选：长文解释
  assets/         # 可选
  scripts/        # 可选
  demo/
    index.html    # 可运行 demo
    PROMPT.md     # 复刻/remix 提示

约定：

agent 只把 SKILL.md 当执行入口
REFERENCES.md 不塞进 workflow 正文
视觉 skill 常带 demo/，可先看 demo 再实现
skill 应 portable：无密钥、无私有路径、不绑定某个客户仓库

正确使用方法

核心心智（3 条）

Skill = 场景路由 + 作业流程，不是百科。
一次只加载最窄的 1 个，或一条明确流水线；禁止 118 个全塞上下文。
你提供触发条件与输入物；skill 负责步骤、默认值、输出合同与验收。

方法 A：单 skill 触发（最常用）

模板：

严格按 `<skill-name>` 执行。
输入：<视频/URL/HTML/截图/当前仓库文件>
目标：exact recreation | inspired adaptation
输出：按该 skill 的 Output Contract / Quality Bar
不要泛泛总结；缺输入先列缺口再停。

示例：

严格按 video-to-superprompt 执行。
输入：./refs/hero-scroll.mp4
模式：exact recreation
输出：单个 paste-ready superprompt + asset map

方法 B：流水线串联（设计复刻 / 灵感生产）

旗舰 web-design 流水线（README 推荐顺序）：

参考视频/站点
  → video-to-superprompt
  → stitched-full-page-capture
  → html-to-interaction-prompts
  → design-first-ui-prompting
  → landing-page / gsap / threejs / 具体风格 skill

步骤	Skill	产出
1	`video-to-superprompt`	可重建的超级提示词
2	`stitched-full-page-capture`	全页结构证据（不只 hero）
3	`html-to-interaction-prompts`	分节交互 prompt 包
4	`design-first-ui-prompting`	把模糊审美压成约束卡
5	实现 skill	真正落地代码

关键：前几步产出“可粘贴资产”，后几步才写代码。 否则 agent 容易直接“凭感觉生成一个差不多的页面”。

方法 C：实现型 skill（写/修代码）

用 gsap skill 修当前 hero → features 滚动叙事。
要求：timeline + ScrollTrigger pin + scrub
约束：只用 transform/opacity；React 用 gsap.context 清理；支持 reduced-motion

价值来源：

When to use
recipes / defaults
pitfalls（性能、清理、触发器、FOUC）

方法 D：约束型 skill（把审美说清楚）

design-first-ui-prompting 强制结构：

GOAL → FORMAT → LAYOUT → TYPE → COLOR → COPY → CONSTRAINTS → NEGATIVE

规则：

先锁定 layout + hierarchy + copy
变体 一次只改 1–2 个变量
排版不稳就 2-pass（先无字生成，再人工/Figma 排版）

方法 E：日常灵感资产生产

按 daily-ui-inspiration-capture 跑今天的包
输出目录：articles/YYYY-MM-DD-ui-inspiration-capture/
必须 5 个 references + full-page + section crops + motion frames

后续可接：

build-daily-inspiration-sites

把 5 个参考变成 5 个原创 Sites 构建任务。

三类 skill 的使用差异

类型	例子	你怎么用	产出形态
工作流 skill	`daily-ui-inspiration-capture`、`video-to-superprompt`	“按 workflow 跑一遍”	固定目录/固定格式资产
规范 skill	`landing-page`、`design-first-ui-prompting`	“先问齐信息，再按结构写”	信息清单 + 页面/提示词骨架
实现 skill	`gsap`、`threejs`、`tailwindcss`	“按 recipes + pitfalls 实现/修”	代码模式 + 性能/清理约束
风格系统 skill	`dark-glass-clean-layout`、`editorial-tech`	“整页采用这套视觉语法”	色/字/布局/材质默认值

场景路由表（先查这张）

你现在要做的事	首选 skill	备选/后续
视频/录屏 → 可重建提示词	`video-to-superprompt`	`stitched-full-page-capture`
已有 HTML → 分拆交互 prompt	`html-to-interaction-prompts`	各实现 skill
只截到 hero，结构不全	`stitched-full-page-capture`	`daily-ui-inspiration-capture`
每日灵感采集	`daily-ui-inspiration-capture`	`build-daily-inspiration-sites`
高转化单页落地	`landing-page`	`pricing-page`、`product-proof-saas`
提示词太虚、出图不稳	`design-first-ui-prompting`	风格系统 skill
Awwwards/作品集级整站	`build-awwwards-quality-sites`	`cinematic-gsap-lenis-motion-system`
GSAP 时间轴/滚动	`gsap`	`gsap-scrolltrigger-storytelling`、`animation-systems`
Three.js / WebGL	`threejs`、`webgl-landing-steering`	`vantajs`、`globe-gl`、`unicorn-studio`
可玩网页游戏	`build-isometric-arpg`	敌人/关卡/音频/QA 子系统
动效性能差	`optimize-web-animations`	`optimize-threejs-games`
任务要反复验证直到过线	`iterate-until-verified`	具体领域 skill
选营销图	`unsplash-asset-images` / `aura-asset-images`	—
写像 Meng 的 X 帖	`write-like-meng-on-x`	`x-bookmark-quote-posts`
审查是否抄参考太狠	`audit-reference-originality`	`generate-reference-inspired-brand-worlds`

旗舰 skill 深读

1) `video-to-superprompt`

何时用： 用户给了视频/录屏/链接，要求分析设计、动效、滚动、字体、WebGL，或生成可复刻 prompt。

工作流摘要：

定位源视频（本地/URL/上传）；不可访问就先停
技术检查：ffprobe + ffmpeg 抽关键帧
分层分析：故事 / 布局 / 运动 / 视觉 / 技术栈 / a11y·性能
资产地图（URL / 本地名 / 占位）
写 superprompt（默认单个 fenced text 块）
验证路径与代表性帧

输出模式：

Prompt only
Article
Implementation brief
Asset-generation pack

质量线：

不看原视频也能重建
运动机制要写死：pin、scrub、video.currentTime、mask、shader 等
每次都写 mobile + reduced-motion
明确 anti-patterns（通用 SaaS 段、装饰 blob、错误的 autoplay 等）

来源：agent-skills/codex/video-to-superprompt/SKILL.md

2) `landing-page`

核心判断： Landing page ≠ Homepage。

Homepage：多意图
Landing page：一个 offer → 一个受众 → 一个主行动

开工前必须收集：

页面目的 / 主 CTA / 转化定义
ICP、问题、前 3 个异议、流量来源、先验知识
证明材料与资产
品牌语气与设计方向

默认结构：

Above the fold：标题 / 副标 / 主 CTA / 一条证明 / Hero 视觉
Mid：问题→方案 / 利益点 / How it works / 社会证明
Bottom：FAQ / 风险逆转 / 最终 CTA

来源：agent-skills/web-design/landing-page/SKILL.md

3) `design-first-ui-prompting`

核心原则： Prompt like a design system, not a wish.

迭代规则：

第一稿锁定 layout + hierarchy + copy
variants 只改一个变量：angle / accent / card arrangement / background
保留本地 reference pack，不要让模型“记住品味”

来源：agent-skills/ui/design-first-ui-prompting/SKILL.md

4) `daily-ui-inspiration-capture`

不是截图倾倒，而是 article-ready bundle。

默认合同：

目录：articles/YYYY-MM-DD-ui-inspiration-capture/
文件：content.md + manifest.json + 本地图片/视频
正好 5 个 final references
每个 live 站：full-page + 连续 section crops + motion frames
去重：对比历史 manifest 的 title/URL/image URL

来源：agent-skills/codex/daily-ui-inspiration-capture/SKILL.md

5) `gsap`

何时用： 专业 UI 动效、时间轴编排、ScrollTrigger 叙事。

默认偏好：

动画 x/y/scale/rotation/autoAlpha，不动画 layout 属性
React/SPA 用 gsap.context() 清理
字体/图片稳定后再 ScrollTrigger.refresh()

来源：agent-skills/web-design/gsap/SKILL.md

你给 agent 的标准说法（可复制）

分析参考

严格遵循 video-to-superprompt。
输入：<视频或链接>
模式：exact recreation
输出：paste-ready superprompt + asset map
不要总结；section-by-section 写清运动机制

写转化页

用 landing-page skill。
先按 Before you design 问齐缺口。
结构按 Core structure；above the fold 只有一个主 CTA。

修动效

用 gsap skill。
目标：hero 入场 + 中段 pin + scrub。
禁止 animating top/left/width/height；卸载要清理；支持 prefers-reduced-motion。

压提示词

先跑 design-first-ui-prompting，把下面描述压成完整 prompt skeleton，
再生成 3 个 variants，每个只改一个变量。

日常灵感

按 daily-ui-inspiration-capture 执行今日采集。
输出 5 references 的完整 bundle，不要 README.md。

全量 skill 目录（118）

说明：下表 description 来自各 SKILL.md frontmatter，2026-07-29 从本机缓存抽取。执行时仍以对应 SKILL.md 正文为准。

Codex 工作流（17）

Skill	用途摘要
`article-prompts-to-skills`	文章/教程/prompt pack → 可复用 skill 包
`audit-reference-originality`	对照参考审原创性/抄袭风险
`audit-verify-explain-grade-5`	审计、用证据验证、用小学生能懂的话解释
`browser-video-recording`	把浏览器场景录成精致演示视频
`build-daily-inspiration-sites`	把每日灵感包变成 5 个原创 landing 构建
`daily-ui-inspiration-capture`	日更 UI 灵感采集与打包
`elevenlabs-tts`	ElevenLabs TTS / 本地 voice profile
`generate-reference-inspired-brand-worlds`	参考视觉 → 多套原创品牌世界
`html-to-interaction-prompts`	HTML → 截图背书的交互 prompt 文
`implement-fog-of-war`	Three.js 战争迷雾/感知系统
`iterate-until-verified`	任意重任务的执行-验证循环
`optimize-web-animations`	前端动画/Canvas/WebGL 性能优化
`performance-profiling`	Apple 平台 Instruments/MetricKit 性能剖析
`stitched-full-page-capture`	懒加载/动效/WebGL 页的可靠全页截图
`video-to-superprompt`	参考视频 → 超详细重建 prompt
`write-like-meng-on-x`	按 Meng 语料校准 X 帖风格
`x-bookmark-quote-posts`	书签 → 有来源的 quote-post 草稿

Media（2）

Skill	用途摘要
`aura-asset-images`	Aura Assets 选营销/设计图
`unsplash-asset-images`	Unsplash 按场景/裁切/比例选图

UI（1）

Skill	用途摘要
`design-first-ui-prompting`	设计优先、规格驱动的 UI prompt 系统

Game development（19）

Skill	用途摘要
`author-game-levels`	可读的扁平世界关卡编排
`build-game-audio-feedback`	战斗/状态/空间音频反馈
`build-game-camera-controls`	等距/跟随/遮挡/锁定/震动相机
`build-game-changelog`	游戏内 changelog 与发布 provenance
`build-game-inventory`	背包/装备/tooltip/拖拽/持久化
`build-game-map-editor`	浏览器地图编辑器
`build-game-monster-system`	怪物资产契约与集成
`build-hybrid-game-assets`	导入网格/程序化/AI 资产生成混合管线
`build-isometric-arpg`	可玩等距 ARPG 架构
`build-mobile-threejs-games`	移动端触控与安全区
`build-threejs-enemy-systems`	数据驱动敌人原型与招式
`build-vesperfall-review-assets`	Vesperfall 资源库审查对
`create-game-vfx`	可读且性能安全的战斗 VFX
`design-action-combat`	可读战术动作战斗
`design-game-encounters`	遭遇战节奏与 boss 阶段
`optimize-threejs-games`	游戏性能剖析与优化
`ship-web-games`	打包部署与生产冒烟
`test-playable-web-games`	可玩性 E2E + 浏览器证据
`tune-enemy-ai`	仇恨/走位/招式选择与可读 telegraph

Web design（79）

转化与整站

Skill	用途摘要
`build-awwwards-quality-sites`	高辨识度营销/作品集整站
`landing-page`	高转化单 offer 落地页
`pricing-page`	SaaS 定价页
`product-proof-saas`	以真实工作流/界面为证明的 SaaS 页
`operational-enterprise-ai`	企业 AI/自动化/审计边界产品页
`tailwindcss`	Tailwind 布局/字体/响应式/组件惯例
`animation-systems`	产品级动效原则与编排
`webgl-landing-steering`	WebGL 重落地页的视觉方向舵

运动与滚动叙事

Skill	用途摘要
`animation-on-scroll`	IntersectionObserver 滚动显现
`cinematic-gsap-lenis-motion-system`	GSAP + ScrollTrigger + Lenis 电影感系统
`cinematic-scroll-storytelling`	滚动驱动电影感 landing
`gsap`	GSAP timeline / ScrollTrigger / stagger
`gsap-scrolltrigger-storytelling`	sticky 产品叙事
`marquee-loop`	无缝无限跑马灯
`masked-reveal`	遮罩分词显现
`staggered-word-reveal`	轻量分词上浮显现
`scroll-progress-timeline`	流程步骤滚动时间线
`scroll-scrubbed-visual-sequence`	滚动擦洗视觉序列
`scroll-scrubbed-word-reveal`	滚动进度驱动逐词显现
`scroll-world-storytelling`	长文/案例 → 滚动世界故事页

WebGL / Canvas / 3D

Skill	用途摘要
`add-shader-cursor-trail`	WebGPU 光标尾迹
`background-grid-webgl`	透视网格背景
`cobejs`	轻量交互地球
`globe-gl`	globe.gl 数据地球
`globe-particles`	粒子球/环可视化
`matterjs`	Matter.js 2D 物理
`threejs`	Three.js 场景/加载/性能
`unicorn-studio`	Unicorn Studio 嵌入与性能
`vantajs`	Vanta 背景特效
`webgl-3d-object`	单物体 PBR/光照展示
`webgl-laser`	全屏激光背景
`shaders-cursor-ripples`	光标流体扭曲
`liquid-metal-border`	液态金属边框
`thinking-orbs`	AI loading/状态球体

CSS 细节与材质

Skill	用途摘要
`beautiful-shadows`	分层中性 elevation 阴影
`company-logos`	Iconify Simple Icons logo
`container-lines`	容器参考线与角标
`corner-diagonals`	斜切角/倒角
`corner-lasers`	角锚激光构图
`css-alpha-masking`	线性 alpha 边缘淡出
`css-border-gradient`	细腻渐变描边
`gooey-blob-system`	SVG 滤镜黏液团
`number-details`	01/02/03 装饰编号
`progressive-blur`	分层 progressive blur
`solar-duotone-bold`	Solar Duotone Bold 图标风格
`beam-glow-states`	border-beam 交互态光边
`reveal-hover-effect`	光标 spotlight 揭幕
`ambient-section-particles`	单 section 克制粒子氛围

布局系统

Skill	用途摘要
`agency-grid-layout-minimal`	极简 agency 编辑网格
`book-serif-index`	书档 serif + mono 索引
`editorial-tech`	杂志编辑感 × 产品科技细节
`framed-grid-layout`	可见边界线 + L 角框网格
`image-first-grid-layout`	图像主导网格
`nested-container-frames`	容器套容器框架
`split-layout-technical`	技术双栏分屏
`technical-wireframe-info-layout`	线框注解信息布局

视觉风格 / 页面气质

Skill	用途摘要
`atmosphere-background`	暗色大气光褶背景
`blue-cloudy-clean-modern`	明亮蓝天白云干净现代
`blue-laser-clean-glass-layout`	蓝激光 + 暗玻璃
`bright-green-tech-system-webgl`	亮绿技术系统 + WebGL
`clean-minimal-beige-light-mode`	米色极简浅色
`dark-blue-contrasting-clean`	高对比暗蓝
`dark-glass-clean-layout`	暗玻璃多栏工作台
`dither-background`	有序抖动暗底
`dither-laser-dark-mode`	抖动纹理 + 激光暗色
`framed-tech-dark-border-gradient`	框式暗技术 + 边框渐变
`funky-purple-container-tech`	紫调容器技术风
`glass-dark-mode-clock`	暗玻璃 + 表盘校准感
`glass-dark-ui`	可读对比的暗玻璃 UI
`high-contrast-skeuomorphic-clean`	高对比干净拟物
`light-mode-paper-technical`	浅色纸感技术风
`mesh-gradient-dark-blue-clean`	暗蓝 mesh gradient
`nested-container-clean-agency`	嵌套容器干净 agency
`orange-clean-paper-saas`	橙色纸感 SaaS
`skeuomorphic-ui`	分层拟物表面
`tech-green-dark-mode-modern`	墨绿信号暗色现代

叙事/产品专题页型

Skill	用途摘要
`documentary-brutalist-agency`	纪录片式粗野 agency
`editorial-portfolio-chapters`	作品章节主导作品集
`editorial-service-booking`	预约服务编辑感站点

什么时候不该用

情况	原因
普通业务逻辑 / API / 数据模型	不在 MengTo 射程，用工程 skill
已有精确设计稿只需像素实现	skill 会引入额外“审美自由”
description 不匹配却硬套	污染上下文，降低执行精度
一次加载十几个 skill 当灵感合集	稀释约束，违背「最窄匹配」
需要系统级 macOS 原生能力	这是网页/设计向库，不是 AppKit/SwiftUI 手册

质量验收清单（通用）

跑完任意 MengTo skill 后，至少检查：

是否读了对应 SKILL.md 而不是凭记忆
输入物是否齐全；缺则先列缺口
输出是否符合该 skill 的 contract（目录/格式/prompt 结构）
约束是否写成可执行规格（尺寸、缓动、层级、禁止项）
是否写了 mobile / reduced-motion / 性能边界（视觉类几乎总需要）
是否一次只改 1–2 个变量（迭代时）
参考是 evidence 还是装饰（截图/帧是否真被用进决策）

与本 vault / 本机 agent 的协作建议

Pi 会话：skill 已在 ~/.pi/agent/skills；对话中点名 skill 名即可。
Claude Code：~/.claude/skills 已有 118 个。
工程任务：继续用 [[Matt Pocock Skills 使用手册]]；视觉任务切 MengTo。
机制层：skill 格式与加载原理见 [[Agent Skills 与 SKILL.md 工作流]]、[[pi-skills-handbook]]。
前端资源页：实现细节还可交叉 [[前端设计资源-给Agent��]]。

已知限制 / uncertain

skills.sh 排行榜安装量与本仓库本地 118 是否完全一致：未交叉核验，uncertain。
Codex / Cursor 专用 skills 目录未完整落点：当前以 ~/.agents/skills + Pi/Claude 为准；若某 agent 只扫自己目录，需额外适配，uncertain 取决于该 agent 发现规则。
部分 skill 依赖 Codex in-app browser / 特定本地路径约定（如 daily capture 的 article 目录）；换到 Pi 时要在任务里显式改输出落点。
风格 skill 之间有重叠审美；同时启用多个风格系统会互相打架——应单选。

来源

MengTo/Skills GitHub
README.md
本机缓存：~/.cache/mengto-skills/agent-skills/**/SKILL.md（2026-07-29 安装快照，118 个）
代表性 skill 正文：video-to-superprompt、landing-page、design-first-ui-prompting、daily-ui-inspiration-capture、gsap

Codex App 过程输出与最终回答分层

Tue, 21 Jul 2026 16:59:00 GMT

For future Claude

这页解释 Codex App 为什么能在执行期间展示过程输出，并在最终回答开始后把过程区自动折叠。2026-07-22 通过 OpenAI Codex App Server 官方文档、Codex 开源协议源码、本机 Codex App 26.715.31925 的 app.asar 和 Buffin 本地实现交叉验证。处理 Buffin 的 commentary/final answer 分层、ActivityGroup、自动折叠或 Codex provider 事件归一化时先读这页。

Codex App 过程输出与最终回答分层

[!abstract] 当前结论 Codex App 不会在 turn 结束后由客户端重新总结过程日志。模型与 App Server 从协议层把中途播报标记为 agentMessage.phase = commentary，把最终回答标记为 agentMessage.phase = final_answer；命令、文件修改、reasoning 和工具调用则是独立 item。UI 在 final answer 开始后将先前 activity 收束为可折叠区，并把 final answer 独立展示。

已知客观事实

1. App Server 的层级是 Thread、Turn、Item

Thread 是一段会话，包含多个 turn。
Turn 是一次用户请求及其后续 agent 工作。
Item 是 turn 内的一项输入或输出，例如 user message、agent message、reasoning、command execution、file change 或 tool call。

客户端通过 turn/started 进入运行态，通过 item 事件增量构建界面，通过 turn/completed 获取整个 turn 的最终状态。turn/completed 的状态可能是 completed、interrupted 或 failed。

2. Item 有独立生命周期

所有 item 共享：

item/started → delta... → item/completed

item/completed 携带该 item 的权威终态。常见 delta 包括：

内容	协议事件
Assistant 文本	`item/agentMessage/delta`
Reasoning 摘要	`item/reasoning/summaryTextDelta`
原始 reasoning	`item/reasoning/textDelta`
命令输出	`item/commandExecution/outputDelta`
计划更新	`turn/plan/updated`
聚合 diff	`turn/diff/updated`

3. Assistant message 自带 phase

Codex 协议中的 MessagePhase：

pub enum MessagePhase {
    Commentary,
    FinalAnswer,
}

语义是：

Phase	语义	UI 归属
`commentary`	中途 preamble / progress narration；后面仍可能继续调用工具或输出消息	Activity / 工作过程
`final_answer`	当前 turn 的终局回答	独立最终正文
`null`	provider/model 未提供 phase	必须走兼容策略，不能武断分类

因此最终总结不是 UI 从工具日志里再次提炼，而是模型最后输出的独立 agentMessage：

{
  "type": "agentMessage",
  "text": "Implemented the change and verified the tests...",
  "phase": "final_answer"
}

Codex App 的界面状态机

Turn 相位

本机 Codex App 26.715.31925 的打包前端使用三态：

idle → prework → final_answer

压缩后的判断逻辑等价于：

function latestTurnPhase(turn) {
  if (turn.status !== "inProgress") return "idle"

  let hasCommentary = false
  for (const item of turn.items) {
    if (item.type !== "agentMessage") continue
    if (item.phase === "commentary") {
      hasCommentary = true
      continue
    }
    return "final_answer"
  }

  return hasCommentary || turn.firstTurnWorkItemStartedAtMs != null
    ? "prework"
    : turn.finalAssistantStartedAtMs == null
      ? "idle"
      : "final_answer"
}

其中 prework 不是 reasoning 的同义词，而是最终回答前的整个工作阶段，包括 commentary、工具调用和其他 activity。

自动折叠条件

本机 bundle 中的折叠函数等价于：

function resolveCollapse({
  hasFinalAssistantStarted,
  isTurnCancelled,
  hasRenderableAgentItems,
  forceExpanded = false,
  preventAutoCollapse,
  persistedCollapsed,
}) {
  if (!hasFinalAssistantStarted || isTurnCancelled || !hasRenderableAgentItems) {
    return { shouldAllowCollapse: false, isCollapsed: false }
  }

  return {
    shouldAllowCollapse: true,
    isCollapsed: !forceExpanded && (persistedCollapsed ?? !preventAutoCollapse),
  }
}

这意味着：

工作进行中：activity 展开，让用户看见 agent 正在做什么。
final answer 开始：允许把此前过程自动折叠，而不是必须等到 turn/completed。
用户选择优先：持久化的手动展开/折叠覆盖自动策略。
取消或无内容：不启用自动折叠。
turn 完成：负责关闭运行状态和记录最终 status，不承担最终回答分类。

折叠后的内容不是全部消失

Codex App 会先把 agent items 分成：

collapsibleEntries：普通工作过程，折叠后隐藏到 disclosure 内。
persistentEntries：即使过程区折叠也应持续显示的交互或结果。
preToggleEntries：放在折叠开关之前的内容。

因此正确模型是 过程内容分组后收束，不是收到 completion 后把整段 transcript 一刀隐藏。

协议到 UI 的完整链路

turn/started
  ↓
reasoning / commentary / commandExecution / fileChange / toolCall
  ↓
item/started → delta... → item/completed
  ↓
agentMessage { phase: final_answer }
  ↓
ActivityGroup 自动收束，FinalResponse 独立渲染
  ↓
turn/completed

Buffin 当前缺口

Buffin 已接入 Codex App Server，但当前归一化层丢掉了 agentMessage.phase：

apps/daemon/src/agent/providers/codex/protocol.ts 把所有 agentMessage 都映射成 message.completed { role: assistant }。
apps/desktop/src/renderer/features/session/models/session-store.ts 只区分 assistant 与 reasoning。
ReasoningBlock 当前用本地 open=true 初始化，完成后没有基于 final answer 的 activity-group 收束。

结果是 Buffin 无法可靠区分“干活途中播报”和“最终回答”，只能依赖位置或 run completion 猜测。

Buffin 推荐模型

事件契约

应在 provider 归一化层保留 phase：

type AssistantMessagePhase = "commentary" | "final_answer" | "unknown"

type MessageEvent = {
  type: "message.delta" | "message.completed"
  role: "assistant" | "reasoning"
  phase?: AssistantMessagePhase
  itemId?: string
  text?: string
}

unknown 或字段缺失必须保留兼容行为，因为 Codex 源码明确说明并非所有 provider/model 都稳定提供 phase。

展示分组

Turn
├─ UserMessage
├─ ActivityGroup
│  ├─ commentary
│  ├─ reasoning
│  ├─ tool calls
│  ├─ file changes
│  └─ approvals / input requests
└─ FinalResponse
   └─ agentMessage.phase = final_answer

折叠规则

const canCollapse =
  hasActivity &&
  !turnCancelled &&
  (finalAnswerStarted || turnCompleted)

const collapsed = userOverride ?? (canCollapse && !preventAutoCollapse)

建议以 final answer 首个 item 开始作为主要自动折叠点，以 turn.completed 作为 phase 缺失时的兼容兜底。不要把 run.completed 当最终答案生成器。

与流式呈现两轴模型的关系

ActivityGroup 的展开/折叠与文本 reveal 是不同维度：

message.completed 只让 source sealed。
final_answer 决定 narrative 分区与 activity 收束时机。
skip | pace | hold 决定当前 surface 如何播放文本。
折叠状态决定用户是否看见 activity detail。

不能用一个 isFinished 同时承担这四种语义。相关状态所有权见 [[Buffin Session 呈现两轴模型]] 与 [[流式 UI 的数据完成态与播放完成态分离]]。

MVP 实施顺序

Codex adapter 保留 agentMessage.phase，补协议测试。
归一化消息事件增加可选 phase，不破坏 phase 缺失的其他 provider。
Session reducer 把 phase 持久化到 text part。
Presentation 将 commentary、reasoning 和 tools 归入 ActivityGroup。
FinalResponse 独立渲染；其开始时自动折叠 ActivityGroup。
用户手动展开后，本轮不再被后续事件强行折叠。
replay 已完成 turn 时直接使用终态折叠策略，不重演自动折叠动画。

验证清单

commentary 后继续 tool call，不会被误当最终回答。
final answer 首个 delta 到达时，activity 默认折叠。
用户手动展开后，新 delta 不会再次抢夺展开状态。
turn interrupted 时保留可见过程和错误上下文。
phase 缺失时仍能显示 assistant 文本。
replay completed turn 直接渲染稳定终态。
message.completed 不会让尚未播放完的文本硬切，遵守 [[Buffin Session 呈现两轴模型]]。

来源

Codex App Server 官方文档
OpenAI Codex App Server README
OpenAI Codex MessagePhase 源码
本机 /Applications/ChatGPT.app/Contents/Resources/app.asar，bundle id com.openai.codex，版本 26.715.31925，2026-07-22 只读核验

Agent AskUser 组件选型

Sat, 18 Jul 2026 07:15:00 GMT

For future Claude

这页记录 Agent Composer 中 AskUser 的 registry 候选、产品边界和当前推荐。它写于 2026-07-18，来源是 Shoogle registry 索引与 Buffin/Liquid Connector 原型讨论。设计或实现 AskUser、多问题表单、回答收据时应先读本页。

Agent AskUser 组件选型

当前结论

优先只读核验 @fluid/ask-user-questions，暂不直接安装。 它在索引描述中最贴近 Agent AskUser：支持多问题、单选/多选、Other 输入、Skip、数字键 1–9、自动前进和问题导航。视觉质量与源码依赖尚未打开核验，因此采用结论保持 uncertain。

AskUser 不应被压成横向工具条。Composer 内应承载完整问答流程；回答后由 Liquid Connector 分离成 compact receipt，thread 只保存问题摘要、回答和状态，不复制完整表单。这个边界延续了 [[Eyrie Agent Session UI 组件设计]] 与 [[Eyrie Session UI 优化方案]] 的 ticket/receipt 模型。

候选对比

候选	registry	能力	适用判断
ask-user-questions	@fluid	多问题、单选/多选、Other、Skip、快捷键、自动前进	功能首选，先核验源码与画面
question-flow	@tool-ui	多步问题与分支	适合复杂引导，但可能比 Composer AskUser 更重
choice-box	@intentui	结构化选择卡片	适合自行组合轻量 AskUser
choice-poll	@cult-ui	单选/多选、结果态、键盘导航	交互接近，但 poll 语义需要剥离
radio-group	@fluid	距离 hover、弹簧选择点、受控 API	完整组件过重时的原语备选
radio	@beui	layoutId 滑动指示点、按压反馈	适合强调单选反馈，不负责问题流程
radio-group	@smoothui	弹簧选择指示器	动效原语备选

Add targets

npx shadcn@latest add @fluid/ask-user-questions
npx shadcn@latest add @tool-ui/question-flow
npx shadcn@latest add @intentui/choice-box
npx shadcn@latest add @cult-ui/choice-poll
npx shadcn@latest add @fluid/radio-group
npx shadcn@latest add @beui/radio
npx shadcn@latest add @smoothui/radio-group

接入边界

Composer 是完整交互面。 展示问题序号、问题正文、纵向选项、Other 输入、Skip 和提交。
Liquid Connector 只负责状态转场。 它不拥有问答状态，只消费 pending/resolved 和 receipt 内容。
Thread 是历史摘要。 Answered/Skipped receipt 控制在一至两行，需要展开时再查看原问题详情。
多问题需要重新评估几何高度。 当前 React Liquid Connector 的 inputHeight 固定为 134；完整多问题不应通过继续缩小字号硬塞进去，应让 Composer 内容区可变高、分页，或把问答面板放在 liquid surface 上方的独立布局层。
模式切换只在稳定态进行。 分离或合并过程中切换 Approval/AskUser 会替换仍可见的 receipt，应禁用或排队到动画完成。

搜索记录

2026-07-18 使用 Shoogle MCP 的 registry name/description 全文索引检索：

choice：9/9
question：12/12
radio：展示 1–30/82
survey：请求被 rate limit，未取得结果

Shoogle 只证明 registry 元数据命中，不证明组件视觉质量、依赖质量或与现有 React/Tailwind 版本兼容。安装前仍需查看 demo、源码、依赖和 license。

原始材料

浮躁类似音乐

Thu, 16 Jul 2026 06:32:00 GMT

For future Claude

这页记录了王菲《浮躁》专辑的音乐流派归属，以及「轻盈、灵动、有鼓点」这一听觉偏好对应的四种音乐分类（Dream Pop、Trip-Hop、Shoegaze、Jangle Pop）及其入门推荐。当用户想找类似《浮躁》质感的音乐或需要理解这些流派的特征区分时，读这页。

王菲《浮躁》的音乐分类

《浮躁》（1996）在音乐分类上主要归属：

Dream Pop（梦幻流行） — 最核心分类。Wikipedia、Rate Your Music、UPEE 均标为 Dream Pop。Cocteau Twins 操刀的《分裂》《扫兴》是典型欧陆 Dream Pop。
Indie Rock / Art Pop — 辅助标签，反映专辑独立、艺术化取向。
北京摇滚 / 土摇 — 窦唯参与编曲和鼓（《无常》《浮躁》），注入北京摇滚气质，吉他带 Jangle Pop 明亮感。
Trip-Hop 影响 — 不占主体，但乐评指出 Trip-Hop 痕迹「因一种轻盈的需要」而存在；王菲后续在《情诫》《寓言》中更充分发展。

《浮躁》本质是一张以 Dream Pop 为底色，融合北京摇滚、北欧迷幻和 Trip-Hop 元素的杂糅之作。

四种匹配流派

需求关键词：轻盈 + 灵动 + 鼓点。

Dream Pop（梦幻流行）

维度	特征
轻盈感	大量混响、延迟，人声如雾如纱，氛围空灵
灵动	吉他旋律漂浮游移，合成器铺底轻盈
鼓点	通常不重，以舒缓底鼓和镲片营造呼吸感

代表艺人：Cocteau Twins、Beach House、Mazzy Star、Alvvays、Yndling

Trip-Hop（神游舞曲 / 吹泡）

维度	特征
轻盈感	迷离女声、阴暗氛围，节拍舒缓不压迫
灵动	鼓点灵活多变，大量切分音、后半拍，节奏型丰富
鼓点	核心特征——慢速但灵活的碎拍，常配厚重贝斯线

代表艺人：Portishead、Massive Attack、Tricky、Morcheeba、Sneaker Pimps

Shoegaze（盯鞋 / 自赏）

维度	特征
轻盈感	吉他噪音墙包裹人声，朦胧梦幻
灵动	吉他 feedback 和音墙中旋律漂浮
鼓点	藏在音墙后，但节奏扎实

代表艺人：My Bloody Valentine、Slowdive、Ride、Lush

Jangle Pop（叮当流行）

维度	特征
轻盈感	明亮清脆的吉他音色，阳光质感
灵动	旋律跳跃，节奏轻快
鼓点	轻巧干净，不抢戏

代表艺人：The Sundays、R.E.M.（早期）、The Smiths

入门推荐

Cocteau Twins — Heaven or Las Vegas（Dream Pop 巅峰，直接影响王菲）
Portishead — Dummy（Trip-Hop 圣经，鼓点灵活 + 迷离女声）
Beach House — Teen Dream（Dream Pop 轻盈教科书）
王菲 — Di-Dar / 寓言（Trip-Hop 方向的延续，尤其是《情诫》）

Jevons 悖论与 Agent 知识工作

Mon, 13 Jul 2026 16:58:54 GMT

Jevons 悖论与 Agent 知识工作

For future Claude

这页解释 Jevons 悖论如何被应用于 Agent 时代的知识工作，并区分总工作量、就业人数和岗位结构。页面创建于 2026-07-14，起因是 swyx 对 coding agent 与知识工作需求扩张的判断。讨论 AI 生产率、Agent 经济学、软件就业或职业结构变化时，应先读这页，避免把需求扩张误写成“无人被替代”。

核心结论

AI 降低每件知识成果的单位成本后，原本不值得做的需求会进入市场，因此知识成果总量可能增加。

这并不意味着就业人数必然增加。更准确的关系是：

总人力需求 = 知识成果数量 × 单位成果所需人力

AI 会降低“单位成果所需人力”；只有当“知识成果数量”的增长更快时，总人力需求才会上升。

一个数字例子

情形	单人年产出	市场总需求	所需工程师
没有 AI	10 个功能	100 个功能	10 人
AI 提效，需求不变	50 个功能	100 个功能	2 人
AI 提效，需求强烈扩张	50 个功能	1000 个功能	20 人

决定就业结果的变量不是生产率单独提高多少，而是需求增长能否超过生产率增长。

Jevons 悖论的原始含义

William Stanley Jevons 在《The Coal Question》中观察到：蒸汽机提高燃煤效率后，煤炭的单位使用成本下降，更多行业采用蒸汽动力，英国煤炭总消费量反而上升。

这个机制可以抽象为：

效率提高 → 单位成本下降 → 新用途变得可行 → 总需求扩张

将它迁移到 Agent 时代：

Agent 能力提高 → 代码/文档/分析更便宜 → 更多项目值得做 → 知识成果总量扩张

已知客观事实

Cursor：工作量和复杂度都在扩张

Cursor 的 Developer Habits Report 显示：

开发者每周新增代码均值从 2025 年初约 3,600 行增至 2026 年 5 月约 8,600 行。
2026 年 5 月，p50 约为 712 行/周，p90 约为 8,800 行/周。
代码行数不是完整生产率指标，但能够说明代码活动量正在增加。

Cursor 与芝加哥大学 Booth 商学院研究者对 500 家公司的研究还发现：

人均每周 AI 消息量增长 44%。
低复杂度消息增长 22%，高复杂度消息增长 68%。
文档、架构、代码审查和学习类任务分别增长 62%、52%、51% 和 50%。

这些数据支持“工具能力增强后，开发者使用更多 AI，并承担更复杂的工作”，但不能单独证明就业人数增长。

SignalFire：工程需求有韧性，但岗位分布恶化

SignalFire 2026 人才报告显示：

软件工程师占科技大厂新招聘的比例从 2019 年的 46% 升至 55%。
科技大厂整体招聘仍比 2019 年低 25%，工程招聘低 11%。
大厂 new grad / entry-level 招聘比 2019 年低约 65%。
前端工程师岗位在工程职位中的相对占比下降约 25%。

因此，“工程师在招聘结构中更重要”与“整个行业招聘增长”不是同一个结论。AI 可能扩大总产出，同时压缩初级、重复性或窄专业岗位。

事实与推论

已知事实

Agent 用户正在生成更多代码，并把 Agent 用于更复杂的任务。
工程岗位比设计、市场等职能更有韧性。
初级岗位和部分专业岗位的招聘明显收缩。

基于事实的分析

软件存在大量“以前能做但不划算”的积压需求，因此比需求封顶的行业更容易出现 Jevons 式扩张。
新增工作更可能集中在问题定义、架构、验证、整合、治理和责任承担。
“vibe coder”可以扩大软件生产参与者范围，但不等于传统工程岗位没有被重新分配。

uncertain

Jevons 效应是否会让所有知识行业的就业人数净增长。
当前工作量扩张能否长期抵消 Agent 的自动化速度。
新增岗位是否足以补偿初级岗位和专业岗位的减少。

适用边界

条件	更可能出现需求扩张	更可能出现岗位压缩
潜在需求	存在大量未满足、未立项需求	需求接近饱和
成本敏感度	成本下降会激活大量新客户	需求对价格不敏感
外部瓶颈	主要瓶颈就是知识劳动	瓶颈在监管、信任、物理资源或注意力
人类角色	判断、审核和责任仍重要	任务可完整标准化和自动验收
技能分布	从业者能驾驭 Agent 并扩大范围	工作主要由重复执行构成

对个人的含义

不要只优化“把旧任务做得更快”，还要寻找“过去因为太贵而没有做的事”。

职业上的关键能力会从单纯生产内容，逐渐迁移到：

发现值得解决的问题。
给 Agent 提供上下文与约束。
审核结果的正确性和价值。
把多个 Agent 产出整合成可靠系统。
对最终决策和后果负责。

这与 [[AI 并行工作与注意力管理]]、[[Agent Skills 与 SKILL.md 工作流]] 和 [[Agent 上下文窗口压力与压缩策略]]共同构成 Agent 时代的工作方法。

原始材料

品味与创造：损失函数视角

Thu, 25 Jun 2026 00:00:00 GMT

For future Claude

这页讨论「品味作为损失函数」的隐喻——为什么只用品味不做创造会让人变得狭隘，以及怎么判断自己的品味尺度是不是借来的。Agent 在讨论设计决策、创作焦虑、或用户提到「品味/挑剔/不敢动手」时应该读这页。

原文

当你停止创造，你的才能就不再重要，你所拥有只剩下你的品位。而品位会裹挟你，让你排斥他人，变得狭隘。所以，要创造。

上下文：前端设计与开发领域。原文进一步将品味描述为「一个人的损失函数」。

核心隐喻：品味 = 损失函数

损失函数只评价，不生成。 它告诉你当前输出离目标有多远，但不会替你缩小这个距离。

状态	品味的作用
有品味 + 有创造	品味是导航仪，每次输出后校准方向
有品味 + 无创造	品味变成纯粹筛选器 → 接受范围越来越窄 → 排斥异己

这就是「变得狭隘」的机制：品味从工具变成身份，身份需要捍卫，捍卫就排斥。

三层扩展

第一层：创造就够了吗？

不够。如果你的品味坐标系本身就是错的，创造只是加速跑错方向。

例子：做老年人挂号 App 的开发者，用 Stripe/Linear 的暗色极简风格当尺子。他越做越往那个方向靠，结果老年人完全用不了。他在创造，但用的是别人的损失函数。

第二层：怎么判断尺子对不对？

实事求是——看这个评价标准是从你要解决的具体问题里长出来的，还是从别处抄来的。

从项目内长出 → 自己的尺子；从别处移植 → 借来的尺子。

第三层：实践路径

先校准损失函数（实事求是：这个项目的成功用什么衡量？）
再创造（在正确的方向上缩小损失）
循环迭代（每一次输出后重新审视尺子是否需要调整）

消化成果

类比：Blog 重构时大量收集参考却迟迟不动手——收集在养品味，动手才是创造。

核心主张：平常心 + 实际动手。先校准尺子（实事求是），再创造。

判断：品味不够时盲目创造也有问题，但这个边界条件对大多数人（包括我）不适用——动手比继续挑剔更重要。

连接笔记：校准比创造更优先（2026-06-29 session）

与 [[安静状态的三层区分]] 同 session 产出。

原文说『先校准损失函数，再创造』——我在这轮 session 中体验到了这个模型的真实运作：

内部校准 ≈ 我花 80 多轮分辨安静的质地。 在 ability to act 之前，我需要先校准自己的『内部坐标系』——什么样的安静是满的、什么样的安静是锁死的、什么时候该等待、什么时候该动。

深层连接：

借来的尺子 ≈ 用别人的标准判断自己的状态是否『正常』
自己的尺子 ≈ 从实际体验中长出的安静区分能力
实际行动 ≈ 区分完成后自然产生的好奇心驱动探索（深海、wiki）

不要为了逃避校准而盲目创造。也要避免为了追求完美校准而永不行动。

前端设计资源-给Agent用

Mon, 22 Jun 2026 16:47:38 GMT

前端样式/设计资源 — 给 AI Agent 用

整理于 2026-06-14。每条附原始链接，可证。分六块：改 Agent 行为的 skill → 灵感/组件站 → 组件库推荐 → 2026 CSS 技巧 → 动效库 → 本地已装 skill。

相关笔记：[[前端交互效果收集]] | [[CSS]]

一、专门给 Agent 装的设计 Skill（npx 可装）

Skill	特点	链接
ui-skill (`/ui`)	设计系统优先，5 模式 plan/build/theme/motion/audit，写码前先跑无障碍+响应式检查；支持 Claude Code / Gemini CLI / Antigravity	https://github.com/lcanady/ui-skill
modern-frontend-skill v3	专为 2026：OKLCH token、scroll-driven 动画、Liquid Glass、View Transitions、Anchor Positioning，附反模式对照表	https://github.com/deveshpunjabi/modern-frontend-skill
better-web-ui	框架无关，30+ skill（add-ui、critique、depth、data-viz、empty-state、forms、hierarchy 等），让 UI 别再像 Midjourney 的 SaaS dashboard	https://github.com/aladicf/better-web-ui
better-react-web-ui	React + Tailwind + Shadcn 特化版，作者主力维护	https://github.com/aladicf/better-react-web-ui
ui-craft	28 个设计工程参考文档，给 Agent 注入品味知识（规则，非模板）	https://github.com/educlopez/ui-craft
OpenAI frontend-skill	官方：composition-first、双字体/单 accent、首屏当海报	https://developers.openai.com/blog/designing-delightful-frontends-with-gpt-5-4
awesome-agent-skills	聚合索引，1424+ skills，含 Anthropic/Vercel/Google Labs/Figma/Stripe/GSAP 等官方出品	https://github.com/VoltAgent/awesome-agent-skills

安装示例：

npx skills add aladicf/better-web-ui --agent codex
npx skills add educlopez/ui-craft

二、参考/组件网站

带 AI prompt（最适合 Agent）

UIDatabase — 每个 pattern 配可粘贴 prompt（Cursor/v0/ChatGPT）— https://uidatabase.com/guides/best-ui-design-tools-2026

灵感画廊（按用途，来源 Colorlib）

用途	站点
落地页（整页截图/滚动叙事）	Lapa Ninja / Land-book
获奖级视觉	Awwwards / CSS Design Awards / Godly
真实产品 UX 研究（60 万+ 截图）	Mobbin / Refero / Page Flows
SaaS UI 模式库（Notion、Linear、Intercom 等）	SaaSUI.design
配色/排版方向	Dribbble（可按颜色搜）/ Behance
克制/排版控	Minimal Gallery / SiteInspire
每日被动灵感	Muzli（Chrome 插件，聚合）/ Collect UI（按 404/login/pricing 分类）
灵感站聚合导航	TOOOLS.design（200+ 站索引）
13,400+ 组件 + 源码	Shuffle

最优组合：Mobbin + Refero 做 UX 研究、Awwwards/Godly 看视觉、Lapa Ninja 找落地页。

技术博客 / 案例

站点	说明
Codrops	前端动效/创意开发教程+案例拆解，含 Creative Hub 演示集、Webzibition 2000+ 精选站、Case Studies 深度复盘

移动端微交互

站点	说明
Screenlane	移动端 UI 细节动效截图，微交互参考宝库

2026 关键趋势：TypeScript、WCAG 无障碍、暗色/亮色主题、SSR 兼容已成标配。

库	定位	特点
shadcn/ui	复制粘贴式	完全控制源码，社区最大
Radix UI	无样式可访问原语	shadcn/ui 的底层依赖
React Aria	无障碍行为库	Adobe 出品，30+ 组件原语
Base UI	MUI 无样式版	Material 团队出品
MUI	成品组件库	Material Design
Ant Design	成品组件库	企业级
Magic UI	动画组件	设计感强，动效丰富
React Bits	动效组件	Framer Motion 驱动，视觉冲击力强
Fancy Components	创意组件	awwwards 风格，直接套用
Aceternity UI	炫技组件	3D 卡片、粒子等，适合 hero section
Origin UI	2025 新秀	现代审美，轻量
Cult UI	轻量组件	设计精致

四、2026 核心 CSS 技巧

来源：Modern CSS in 2026 (dev.to) · AppCommandos · 2026 CSS Features (Riad Kilani) · Web Standards 2026 Deep Dive

已全面可用（所有主流浏览器 baseline）

特性	用途	替代了什么
`:has()`	父选择器	JS class 切换
`@container` queries	组件级响应式（基于父容器）	全局 media query
CSS Nesting	原生嵌套	Sass/PostCSS 嵌套
`@layer`	级联层显式管理优先级	specificity 战争
`oklch()` + `color-mix()` + `light-dark()`	感知均匀色彩 / 动态混合 / 亮暗自动切换，纯 CSS 生成整套调色板	hex/rgb/hsl
`text-wrap: balance / pretty`	标题自动换行平衡	手动 `<br>`
View Transitions API	同文档 + 跨文档路由过渡动画	react-transition-group 等
Popover API	原生弹出层，自动处理顶层和焦点	手写 z-index + portal
Anchor Positioning	锚点定位（tooltip/dropdown 原生）	Popper.js / Floating UI
Scroll-driven Animations	`animation-timeline: view()` 滚动驱动，不占主线程	JS scroll 监听
`@starting-style`	首次渲染初始样式，弹窗入场无闪烁	`setTimeout` hack
`@scope`	样式作用域隔离	BEM / CSS Modules
`field-sizing: content`	输入框自适应内容大小	JS 计算高度

渐进增强（部分浏览器）

特性	状态
CSS `if()`	属性值内条件逻辑，Chrome 实验
Grid Lanes (Masonry)	原生瀑布流布局
Scroll-state queries	容器滚动/吸附状态查询

五、设计工具

工具	说明
Coolors	空格键刷配色方案，支持对比度检测和调色
Fontpair	Google Fonts 字体配对推荐
Typescale	视觉化字体比例生成器，直接输出 CSS 变量
CSS Gradient	可视化渐变生成，支持 mesh gradient 和径向渐变
SVG Repo	50 万+ 免费 SVG 图标
Rive	交互动画设计工具，比 Lottie 更强，直接嵌 React

六、动效库选型

来源：LogRocket 2026 测评 · GSAP vs Motion vs Spring · SmoothUI 对比

库	适用场景	特点	周下载量
Motion（原 Framer Motion）	通用 UI 动画、路由过渡、手势	声明式，React 首选，30.7k★	~300 万
TailwindCSS Motion	Tailwind 项目 CSS-first	零 JS，class 驱动	-
GSAP	复杂时间线、滚动叙事、SVG 形变	框架无关，Webflow 内置，行业标准	~100 万
React Spring	物理弹簧动画	29k★，API 小，弹簧物理模型	~78 万
Anime.js	轻量 SVG 动画	66k★	~20 万
AutoAnimate	列表增删动画	一行代码零配置	~40 万

选型速查

UI 交互 + 路由过渡 → Motion
复杂时间线 + 滚动叙事 → GSAP
物理质感动画 → React Spring
列表动画零配置 → AutoAnimate
Tailwind 项目 CSS-first → TailwindCSS Motion

七、本地已装 skill（无需联网，即用）

改进套件（impeccable 入口）：critique 评估 / audit 体检 / typeset·arrange·layout 排版 / colorize 配色 / distill 简化 / optimize 性能 / adapt 响应式 / harden 健壮 / clarify 文案 / extract 抽组件
风格强度：bolder / delight / quieter / overdrive / normalize
生成/规划：frontend-design、shape、make-interfaces-feel-better、teach-impeccable
动效：animate + GSAP 全家桶（gsap-core/gsap-timeline/gsap-scrolltrigger/gsap-react 等）
找参考/组件：design-explorer、component-scout、lazyweb-*
实时迭代/设计稿：agent-browser（真浏览器截图）、Pencil MCP（.pen 文件）

八、学习方法论

资源	作者	内容
Refactoring UI	Adam Wathan & Steve Schoger	实用 UI 改进技巧（书）
Laws of UX	Jon Yablonski	UX 定律速查卡片
animations.dev	Emil Kowalski	动效设计教学
Fixing Visual AI Slop	TrilogyAI	AI Agent 生成 UI 的设计标准文章

八、更多灵感站（2026-06 补充）

来源：TOOOLS.design 100 Best · FrontendPlanet 22 Sites

UI/UX 模式库

站点	说明
Design Spells	多学科设计灵感
Recent Design	最新设计趋势
UX Bites	UX 洞察
Design Vault	设计模式库
Details Matter	微交互画廊
Viewport UI	精选 UI 体验
Unsection	网站区块 + hover 效果
SaaSFrame	SaaS 设计灵感库

动效 / 创意

站点	说明
Landing Love	动画网站展示（含录屏）
Eyecandy	Motion graphics 展示
Hoverstat.es	实验性网站项目
The Whimsical Web	奇趣创意网站
Browsing Mode	极端创新设计
The FWA	技术创新奖项（老牌）

专项（按页面部件）

站点	说明
Supahero	Hero section 设计
Navbar Gallery	导航栏设计
Footer	页脚设计
404s	404 页面
Pricing Pages	定价页
OGimage.gallery	OG 社交图片

落地页 / 营销

站点	说明
One Page Love	单页网站
Landingfolio	落地页灵感
Page Collective	落地页大集合
Landdding	按行业分类优秀站
Commerce Cream	电商网站
Curated Web Design	按风格/行业分类

极简 / 暗色

站点	说明
Dead Simple Sites	极简网站
Dark Mode Design	暗色主题
Dark	暗色主题合集
httpster	独立创意工作室

其他垂直领域

站点	说明
Really Good Emails	邮件设计
Scrnshts	App Store 截图
iOS Icon Gallery	iOS 图标
HUDS + GUIS	HUD/科幻界面
The Brand Identity	品牌设计
CSS Nectar	按颜色/风格/国家筛选

九、项目实践

[[Eyrie Agent Session UI 组件设计]] — 这些资源的主要落地场景
[[流式Markdown与ToolCall渲染方案]] — 流式渲染选型
[[Unicode Braille Loading 组件库]] — loading 组件方向

Matt Pocock Skills 使用手册

Wed, 17 Jun 2026 17:06:00 GMT

For future Claude

这页是 mattpocock/skills 的本机对照地图。2026-09-07 对照 GitHub 主分支 v1.2.3（提交 3cca18b，2026-09-04）和本机 ~/.agents/skills：仓库 37 个 SKILL.md，Claude 插件正式收录 25 个，开发中 8 个，杂项 4 个，弃用桶已空。选工作流、核旧名、装或更新这套 skill 时先读本页。

Matt Pocock Skills 使用手册

当前版本结论

Matt Pocock Skills 是一组小型、可组合的工程工作流，不接管整个开发过程。它针对四类失败：

需求和 Agent 没对齐：用 grilling 把设计树问完。
项目里同一个词指三件事：维护 CONTEXT.md 和 ADR。
代码对不对没有反馈：TDD、诊断循环、Standards + Spec 双轴审查。
代码库越写越糊：找 deep module、接口和缝。

桶	数量	进 Claude 插件	建议
工程 + 效率（稳定）	25	是	日常用
开发中	8	否	可试，会变或消失
杂项	4	否	特定工具才装
弃用	0	—	删掉，不留尸
合计 `SKILL.md`	37		以 GitHub 主分支为准

2026-09-07 本机：npx skills add mattpocock/skills -g --all 已把这 37 条装到 ~/.agents/skills，Pi / Claude 目录是指向那里的符号链接。37 份 SKILL.md 与主分支字节一致。

WARNING

skills.sh/mattpocock/skills 的展示数量可能和仓库 SKILL.md 数不一致（历史发布、旧名、索引缓存）。以 GitHub 主分支和本机 ~/.agents/skills 为准。skills.sh 条数 uncertain。

安装

两条路，不要两条一起走，否则每条 skill 会出现两次。

Claude Code 插件（只读、随作者更新）

claude plugins install mattpocock-skills

已在 Claude Code 官方 marketplace，不用先加源。插件只带上面那 25 条稳定 skill，不含开发中和杂项。

可编辑副本（Codex / Pi / 其他）

npx skills@latest add mattpocock/skills

本机 2026-09-07 用的是全局全量：

npx skills@latest add mattpocock/skills -g --all

更新已装副本：npx skills update。每个仓库先跑一次 /setup-matt-pocock-skills：选 issue tracker（GitHub / Linear / 本地文件）、triage 标签、文档落点。

来源：仓库 README

调用模型

一条轴：谁能启动它。

类型	谁能启动	写法	description 写给谁
用户显式	只有人打出名字	Claude：`disable-model-invocation: true`；Codex：`agents/openai.yaml` 里 `policy.allow_implicit_invocation: false`	人（一行摘要，不要写「Use when…」触发清单）
模型可调用	人或模型	省略上面两项	模型（保留触发语义）

用户显式 skill 可以去调模型可调用 skill，不能再调另一个用户显式 skill。跨 skill 的真正调用要写成「Call the Skill tool with "grilling"」，不要指望正文里写 /grilling 就会开火。前置条件若是用户显式 skill（例如 setup-matt-pocock-skills），只能让人去跑，不能让 Skill tool 去调。

稳定插件 25 条现在是 14 用户显式 + 11 模型可调用（不是 2026-07 的 14+14）。本机 37 条合计 22 用户显式 + 15 模型可调用。

来源：invocation.md

稳定工程 Skill：18 个

用户显式：9 个

Skill	作用	适用场景
`ask-matt`	路由：该走哪条 skill / 流程；含会话阶段边界（continue / clear / handoff / subagent / compact）	不知道下一步该 grill、spec、prototype 还是 implement
`setup-matt-pocock-skills`	给仓库配 issue tracker、triage 标签、领域文档目录	每个仓库第一次用这套
`grill-with-docs`	追问方案，同时改 `CONTEXT.md` 和 ADR	有工作目录；重大功能或架构前
`triage`	按状态机处理别人丢进来的 issue/PR	原始 bug/需求 → Agent 可执行任务；`to-tickets` 产出的票不要再 triage
`improve-codebase-architecture`	扫 deep module 机会，出 HTML 报告，再追问你挑哪一条	定期治理，不是救火
`to-spec`	把已经谈完的内容收成 spec 并挂到 tracker	对话已结束，只需沉淀规格
`to-tickets`	拆成带阻塞边的 tracer-bullet tickets	多任务、多人或多 Agent
`implement`	按 spec/票实现，内部跑 `tdd`，提交前跑 `code-review`	需求和票已经就绪
`wayfinder`	超大工作画决策票地图，一次解一个决策（产出决策不是交付物）	目标大、未知多；地图清了再交回 `to-spec`，不要直接 implement

模型可调用：9 个

Skill	作用	适用场景
`prototype`	用可丢弃原型回答一个设计问题	逻辑/状态：单个可双击打开的 HTML；UI：同一路由上多套可切换变体。原型当主键源，落到 `prototype/<name>` 分支
`diagnosing-bugs`	先有变红的反馈环，再缩小、假设、插桩、修、回归；展示命令和产物前先打码密钥	难 bug、性能回退、偶发失败
`research`	后台对高可信一手源调研，落成带引用的 Markdown	API/框架事实，不要用它替代思考
`tdd`	红—绿—重构的垂直切片；只在事先和你约定的 seam 上测	新功能或 bug 适合先测
`domain-modeling`	主动挑战术语、用场景压测、当场改 `CONTEXT.md`/ADR	词含糊；只读 `CONTEXT.md` 不算走这条
`codebase-design`	deep module 词汇：小接口、干净缝、从接口测试	模块形状、缝该开在哪
`code-review`	相对某基点并行审 Standards 和 Spec	分支、PR、工作区 diff
`resolving-merge-conflicts`	按双方原始意图逐块解冲突，然后做完操作，不用 `--abort`	已经处于 merge/rebase 冲突
`wizard`	生成交互式 bash，带人走只有人能点的步骤（密钥、第三方后台、一次性迁移）	Agent 自己做不了的那截；能自己做就不要走这条

来源：Engineering README、plugin.json

稳定效率 Skill：7 个

Skill	调用	作用
`grill-me`	用户显式	无工作目录时的追问；不写 `CONTEXT.md`
`grilling`	模型可调用	真正的面试原语：按设计树一轮问完当前 frontier，事实派子代理查，决策留给你。`grill-me` / `grill-with-docs` / `triage` / `wayfinder` / `improve-codebase-architecture` 内部都走它
`handoff`	用户显式	把当前会话压成可带走的 markdown。窄用途：换 harness、换目录、交给同事、阶段中途分叉
`teach`	用户显式	在当前目录做跨 session 教学工作区
`to-questionnaire`	用户显式	答案在别人脑子里：追问的是「发给谁、要收回什么」，写成问卷
`wait-what`	用户显式	上一句没听懂，用 `CONTEXT.md` 里的词重新讲。修一句，不防下一句
`writing-for-agents`	模型可调用	写给 Agent 看的文档：skill、`AGENTS.md`/`CLAUDE.md`、指针文档。旧名 `writing-great-skills`

`grill-me` 与 `grill-with-docs`

维度	`grill-me`	`grill-with-docs`
工作目录	没有（或不该留纸面）	有��就该用这条
是否改 `CONTEXT.md` / ADR	否	是
面试原语	都是 `grilling`	都是 `grilling`

有仓库却走 grill-me，等于放弃纸面。答案在别人那里走 to-questionnaire，不要硬问自己。

杂项 Skill：4 个（不进插件）

Skill	作用	判断
`git-guardrails-claude-code`	Claude Code hook，拦住高风险 git	只对 Claude Code
`setup-pre-commit`	Husky + lint-staged + 类型检查 + 测试	JS/TS 仓库实用
`scaffold-exercises`	课程练习目录脚手架	主要给课程作者
`migrate-to-shoehorn`	测试里的 `as` 迁到 `@total-typescript/shoehorn`	高度特定

来源：Misc README

开发中 Skill：8 个

不进插件和顶层 README，无独立 docs 页，可能改掉或删掉。单独装：npx skills@latest add mattpocock/skills --skill=<name>。

Skill	作用	判断
`loop-me`	跨 session 追问自己，写出工作流 spec	实验
`claude-handoff`	把当前对话交给新的 Claude 后台 agent（`claude --bg`）	Claude 专用
`setup-ts-deep-modules`	dependency-cruiser 强制 TS 包只从入口进入	大 TS monorepo 可试
`implement-spec`	整份 spec 一张分支；票当任务图，就绪前沿并行子代理，收成一个 PR	新；和逐票 `implement` 不同
`retro`	会后改 steering / 规范 / 检查 / 工具	stub，还不能当功能用
`writing-fragments`	访谈采矿，先不结构	写作探索
`writing-shape`	把素材按段收成文章	写作收敛
`writing-beats`	按节拍组织素材	叙事

来源：In Progress README

已不存在的名字

弃用桶现在是空的：退休即删除，changeset 里写替代。下面这些名字不要再装。

旧名称	现状
`design-an-interface`	并入 `codebase-design`
`qa`	并入 `triage`
`request-refactor-plan`	用 `improve-codebase-architecture` → `to-spec` / `to-tickets`
`ubiquitous-language`	并入 `domain-modeling`、`grill-with-docs`
`edit-article`	主分支已无此目录
`obsidian-vault`	主分支已无此目录
`writing-great-skills`	改名为 `writing-for-agents`，无别名
`to-prd`	`to-spec`
`to-issues`	`to-tickets`
`review`	`code-review`
`decision-mapping` / `pathfinder`	`wayfinder`

相对 2026-07-13 手册的变化

当时写的是 39 条（28 稳定 + 7 开发中 + 4 弃用）。2026-09-07 核验后：

变化	说明
`wizard`	从开发中毕业，进工程、模型可调用
`to-questionnaire`	新稳定效率 skill
`wait-what`	新稳定效率 skill
`writing-for-agents`	可被模型调用（Codex 1.2.2 起）
`implement-spec`、`retro`	新开发中
grilling	不再一次一题；一轮问完当前 frontier
`prototype`	逻辑原型改为单个 HTML，不再是终端小程序
`diagnosing-bugs`	先打码密钥（v1.2.3）
`ask-matt`	增加 Phase boundaries 和 `PHASE-BOUNDARIES.md`

本机状态（2026-09-07）

项	值
版本	仓库 v1.2.3，主分支 `3cca18b`（2026-09-04）
实体目录	`~/.agents/skills`（37 条）
Pi	`~/.pi/agent/skills` 全是符号链接
旧副本备份	`~/Documents/skills-backup/2026-09-07-pre-matt-only/`
不在这套里的	`pi-goal-writer` 仍在 pi-goal 包内；`~/Documents/skills` 个人源未动

新开一轮 Pi 会话才会按这 37 条重新加载。

核心判断

最有价值的不是单个文件，而是这条循环：

对齐 → 规格 → 任务切片 → 小步实现 → 自动反馈 → 双轴审查 → 架构持续治理

它和 [[Agent Skills 与 SKILL.md 工作流]] 一致：skill 是可组合、可版本化的工作流资产，不是更长的 Prompt。

历史记录

2026-07-13 主张（已被本页取代）

当时对照主分支记为 39 个 SKILL.md：28 稳定、7 开发中、4 弃用；稳定恰好 14 用户显式 + 14 模型可调用。当时仍把 wizard 放在开发中，把 writing-great-skills 当作稳定效率 skill，并收录已不存在的 edit-article / obsidian-vault。grilling 仍按「一次只问一题」描述。2026-09-07 以 v1.2.3 覆盖上述数字和分类。

原始材料

paseo-architecture-blog

Fri, 12 Jun 2026 02:12:24 GMT

Agent 并行开发的冲突解决之道：从端口碰撞到平台层抽象

如果你觉得 PORT=3001 npm run dev 就够了，那你还没同时跑过三个 Agent。

问题不在端口，在假设

2026 年，AI Coding Agent 已经能独立完成从写代码到提 PR 的全流程。但当你想同时跑三个 Agent——一个做登录模块、一个做支付、一个修 Bug——你会发现世界崩塌了。

不是模型不够好，不是上下文不够长。是 Agent A 的 dev server 占了 3000 端口，Agent B 的 dev server 直接 EADDRINUSE 炸了。

更隐蔽的是：Vite 的 HMR WebSocket 固定占用 24678 端口。就算 HTTP 端口全部分配了不同值，三个 Vite 实例的 WebSocket 还是会撞在一起，热更新集体失效。你改了一行代码，浏览器不刷新，Agent 以为自己改坏了，又改回去——然后陷入死循环。

这不是配置问题。这是架构问题。

第一性原理：三个冲突，一个根源

我们先把问题拆到最底层。

冲突一：端口是全局命名空间

TCP 端口是一个操作系统级的单例资源。:3000 同时只能被一个进程绑定。这跟 Redis 的 KEYS *、跟全局变量、跟单线程模型的共享状态——是同一类问题：共享可变状态在并发下的必然冲突。

冲突二：WebSocket 端口是影子资源

Vite 把 HMR WebSocket 设计为独立端口，且不跟随 HTTP 端口变化。这是框架级别的硬编码假设——“一台机器只会跑一个 Vite”。在 Agent 时代，这个假设失效了。

冲突三：文件系统是共享的

两个 Agent 同时 npm install，同时写 src/auth.ts，同时跑 npm run build。工作目录是同一个。依赖安装互相覆盖，构建产物互相污染。

这三个冲突有一个共同根源：开发工具链假定”一个项目 = 一个开发者 = 一个运行实例”。Agent 打破了这个假定，但没有提供替代方案。

四条路径，只有一条能治本

路径 A：手动换端口

PORT=3001 npm run dev

问题：它能解决 HTTP 端口，解决不了 Vite 的 WebSocket 端口。三个 Agent 就是三个手动配置点。四个服务（前端、后端、数据库、Redis）就是 3×4=12 个手动配置点。而且这些数字需要你自己记住——Agent A 的预览在 :3001，Agent B 在 :3003，手机上看还得输 IP:端口。

结论：O(N×M) 的手工复杂度，不可扩展。

路径 B：Docker 容器隔离

services:
  app:
    ports:
      - "0:3000"  # 随机宿主机端口

问题：Docker 太重。每次创建 Agent 任务需要拉起全套容器，冷启动 10-30 秒。Agent 改一行代码想预览效果，等容器重启的时间够它写完整个函数了。而且容器内的 node_modules 无法共享，3 个 Agent 就是 3 份完整的 node_modules，磁盘和安装时间都翻倍。

结论：隔离足够，但太重、太慢。Agent 需要的是”瞬时隔离”。

路径 C：Git Worktree + 手动编排

git worktree add ../feat-auth feature-auth
cd ../feat-auth && npm ci
PORT=3001 npm run dev  # 还得记着这个端口

问题：Worktree 解决了文件隔离，端口还得手动管。你知道 feat-auth 用了 :3001，feat-payment 用了 :3002——但一个月后回来再看，那些数字早就忘了。

结论：有隔离但缺编排，手工管理的上限是 2 个 Agent。

路径 D：平台层抽象（Paseo 的做法）

把端口分配、请求路由、文件隔离从应用层提升到平台层。开发者只声明”我有什么服务”，平台负责分配资源、建立路由、透传流量。

你写的：paseo.json（声明式）    →    运行时自动变成：隔离 worktree + 唯一端口 + 可读 URL + WS 透传

结论：把 O(N×M) 降到 O(1)。这才是治本。

Paseo 的四层模型

Paseo 的冲突解决不是一个功能，而是一套分层架构。每一层独立解决一个问题，层与层之间通过明确的接口（环境变量、URL 格式、worktree 路径）耦合。

第一层：Git Worktree —— 文件系统隔离

这是最底层。每个 Agent 获得一个独立的 Git worktree——一份代码的平行副本：

~/.paseo/worktrees/
└── 1vnnm9k3/                    ← 源仓库路径的 hash
    ├── tidy-fox/                ← Agent A：feature-auth 分支
    │   ├── src/  node_modules/  paseo.json
    └── bold-owl/                ← Agent B：feature-payment 分支
        ├── src/  node_modules/  paseo.json

Worktree 不同于 git clone——它共享 .git 对象库，创建几乎瞬间完成，磁盘开销仅增量文件。每个 Worktree 拥有独立的 node_modules、独立的 .env、独立的构建缓存。

工程意义：Worktree 不是新鲜事物（Git 2.5 就有了），但把它作为 Agent 的基础设施原语，是一种设计选择。它比 Docker 轻得多（毫秒级 vs 秒级），比手动 cp -r 安全得多（git 保证了可追溯和可合并），且天然与 Git 工作流融合（Agent 的改动就是普通分支，review 就是普通 diff）。

第二层：动态端口分配 —— 网络命名空间隔离

有了独立的工作目录，还需要独立的网络端口。Paseo 的做法是声明式：项目通过 paseo.json 声明自己有哪些服务，daemon 在运行时分配端口。

{
  "scripts": {
    "web": {
      "type": "service",                          // 标记为长期运行的服务
      "command": "npm run dev -- --port $PASEO_PORT",  // 用变量，不写死
      "port": 3000                                 // 默认端口（可选）
    },
    "api": {
      "type": "service",
      "command": "go run . --port $PASEO_PORT"
    }
  }
}

关键设计决策：

1. 为什么是 $PASEO_PORT 而不是自动检测端口？

因为自动检测有竞态条件。Agent A 检测到 14001 空闲，但在它 listen() 之前，Agent B 也可能检测到 14001 空闲。daemon 作为唯一调度者，先分配、后启动，避免了所有竞态。

2. 为什么不在 daemon 里强行改写进程的网络栈？

技术上可以通过 LD_PRELOAD 劫持 bind() syscall，或者用网络命名空间。但这会让 dev server 的日志和实际监听的端口不一致，调试噩梦。Paseo 选择了一个更干净的方案：约定优于注入——项目遵守”用 $PASEO_PORT”的约定，daemon 提供环境变量。

3. 为什么端口是分配而非共享？

因为不同 worktree 的 dev server 可能跑不同版本的代码、不同的数据库状态。共享端口意味着共享后端状态，这会引入更隐蔽的 bug——Agent A 改 API 返回格式，Agent B 的前端莫名其妙报错，因为它们在共用同一个 API 进程。

第三层：反向代理 —— 人类可读的路由

端口是机器友好的（:14001），但对人类是噪音。Paseo 的反向代理把数字端口映射为可读 URL：

http://web--feature-auth--my-app.localhost:6767
      ─┬── ────┬───── ──┬──
       │       │         └─ 项目名
       │       └─ 分支名
       └─ 服务名

这个 URL 格式有几个精细的设计：

1. 用 -- 分隔，不用 /

/ 会让浏览器把 web 当作路径而非域名的一部分。-- 是合法的主机名字符，且几乎不会出现在实际的服务名或分支名中。

2. *.localhost 不需要 DNS

现代操作系统（macOS、Linux、Windows 10+）自动将 *.localhost 解析到 127.0.0.1。零配置。

3. URL 是确定性的

同一个 worktree 的同一个 service，每次重启 URL 不变。因为 URL 只依赖三个稳定的标识符（服务名、分支名、项目名），而不依赖端口号。你可以把这个 URL 存书签、写进 README、发到 Slack——都不会过期（除非 worktree 被 archive）。

第四层：WebSocket 透传 —— 代理的最后一公里

反向代理最难处理的协议就是 WebSocket。HTTP 请求是一次性的——代理转发请求、收到响应、关闭连接。WebSocket 是长连接——代理需要把 TCP 连接升级为全双工隧道，然后一直维持。

Paseo 的反向代理在检测到 Upgrade: websocket 请求头后，自动完成升级握手，后续帧双向透明转发。这意味着 Vite 的 HMR、Next.js 的 Fast Refresh、Webpack 的 WDS 热更新全部正常工作，不需要任何额外配置。

为什么 Nginx 做不到”零配置”？

Nginx 必须显式声明 proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection "upgrade"。这不是 Nginx 的缺陷——Nginx 的设计目标是通用反向代理，它不能假设所有后端都是 WebSocket。但 Paseo 的设计目标就是 dev server 代理，所有 dev server 都可能发出 WebSocket 升级请求，所以这个假设是安全且合理的。

工程谱系：这不是凭空发明

Paseo 的设计不是凭空冒出来的。它在工程史上有四条清晰的谱系：

1. 十二因子应用（12-Factor App）

十二因子的第三因子是”配置存储在环境变量中”——端口不应写死在代码里，而应通过 PORT 环境变量注入。Paseo 的 $PASEO_PORT 就是这个原则的 Agent 时代延续。

2. 服务网格（Service Mesh）

Istio/Envoy 的 Sidecar 模式：应用不需要知道网络拓扑，sidecar 透明代理所有流量。Paseo daemon 就是 Agent 的 sidecar——Agent 只知道 $PASEO_PORT，不知道前面有反向代理、不知道还有其他 Agent 实例、不知道自己的 URL 是什么。

3. 平台工程（Platform Engineering）

Heroku、Fly.io、Kubernetes 的核心思想：开发者声明意图，平台负责调度资源。paseo.json 就是声明，“启动 web 和 api”就是意图，daemon 就是调度器。

4. 声明式基础设施（Declarative Infrastructure）

Terraform、Kubernetes YAML、Nix Flake——“描述想要的状态，而非执行的步骤”。Paseo.json 描述”这个项目有哪些服务”，而不是”在 14001 端口启动 web，在 14002 端口启动 api”。后者是命令式，前者是声明式。

如果拆成独立模块

Paseo 的四个核心能力，每一个都可以拆成独立可复用的模块：

模块	职责	接口	独立可行性	已有竞品
Worktree Manager	创建/管理隔离工作区，生命周期钩子	`Create(opts) → Workspace`, `Archive(ws)`	🟢 零外部依赖	无直接竞品
Port Allocator	为多进程分配互不冲突的 HTTP+WS 端口	`Allocate(key, PortHTTP/PortWS) → int`	🟢 最易独立	comport (Rust)
Reverse Proxy	Host 头路由 + WS 自动透传	`AddRoute(hostname, target)`, `RemoveRoute(hostname)`	🟡 需定义路由管理协议	Caddy/Traefik（偏静态配置）
Env Injector	向子进程注入服务地址，实现零配置服务发现	`Register(svc)`, `EnvFor(svcName) → []string`	🟢 纯数据结构	Docker Compose 网络别名（容器层）

组合方式：这四个模块只依赖一个共享的 Service 定义结构体，彼此间无代码耦合。你可以只引入 Port Allocator 来管理 monorepo 的并发 dev server，也可以全栈引入四个模块来构建自己的 Agent 平台。

拆分价值：如果有人想写一个新 Agent CLI（不管基于 Claude、Codex、还是自定义模型），不需要从零实现 worktree + 端口管理。直接引入这四个模块，专注做 Agent 逻辑。就像 express 之于 Node.js HTTP，这些模块可以成为 Agent 开发环境管理领域的标准组件。

一个可能的开放标准：Dev Workspace Spec

如果这四层不只是 Paseo 的内部设计，而是社区标准，可以定义一个 dev-workspace.json：

{
  "$schema": "https://dev-workspace-spec.dev/schema.json",
  "version": "1.0",
  "project": "my-app",
  "services": {
    "web": {
      "command": "npm run dev",
      "httpPort": 3000,
      "wsPort": 24678
    },
    "api": {
      "command": "go run .",
      "httpPort": 8080
    }
  },
  "setup": "npm ci && cp .env.example .env",
  "teardown": "rm -rf .cache"
}

这个 spec 可以同时被 Paseo、Multica、CI 系统、甚至 VS Code 插件消费。git clone 一个项目 → 它自带 dev-workspace.json → 任何兼容的 runtime 自动创建隔离 worktree + 分配端口 + 启动所有服务 + 生成预览 URL。不管你用什么工具，体验完全一致。

这定义了 Agent 时代的开发环境标准。

结语

Paseo 的四层模型回答了这个问题：

当开发不再是”一个人 + 一个 IDE”，而是”多个人类 + 多个 Agent + 多台机器”，开发工具链需要做出什么改变？

答案不是更好的端口管理器、不是更重的容器、不是更复杂的 CI 配置。答案是把环境管理从应用层提升到平台层——就像 Kubernetes 把部署从”SSH 到机器上手动启动”提升到”声明 Pod 的期望状态”。

Worktree 隔离、动态端口、反向代理、WS 透传——这些单独看都不新鲜。但把它们组合成一个声明式、零配置、瞬时创建的开发环境层，是 Agent 时代的基础设施创新。

工具会变，模型会变，但这个”声明意图 → 平台分配 → 透明路由”的模式会留下来。因为无论是什么 Agent、什么框架、什么语言，不想管端口是普遍需求，“写完代码能立刻看到效果”是永远不会过时的体验。

Paseo 是开源项目（AGPL-3.0），代码托管在 github.com/getpaseo/paseo。

让界面「有感觉」的细节

Sun, 10 May 2026 07:00:00 GMT

好的界面从来不是一个大招搞定的，而是一堆小细节叠加出来的。这篇文章整理了让 UI 从「能用」变成「好用」的实用技巧，附带可交互的 demo。

简历计划

Fri, 06 Mar 2026 15:19:41 GMT

所有简历都在关键信息进行了打码, 请放心观看

1

2

3 2026-08-05 | 三份简历 OCR 提取 + 前端 vs Agent 前端写法对比 + ATS 机制

说明：下方简历 1-3 的正文为图片 OCR 提取（macOS Vision 框架），个别字符可能有识别误差，数字与专有名词已尽量保留。原始图片见上方。

一、简历 1：纯前端方向（27 届，两段中大厂实习）

教育：2023.09-2027.06 计算机科学与技术；CET6 622；GPA 专业前 30%；省服务外包大赛三等奖、挑战杯人工智能+专项赛全国二等奖
实习 A：海康威视（2025.11-2026.03）协议管理平台 PMP2.0 前端开发
- 设计双栈（idStack/pathStack）高亮引用，JSONPath 路径追踪与整块锁定高亮，MutationObserver 支持虚拟滚动动态同步
- 双式大数据树渲染：<1300 行用 el-table，超阈值切换 xntree 虚拟树，treeToList 扁平化 + 深拷贝隔离响应式
- Vite 构建优化：按需加载 + Tree Shaking，首屏 LCP 缩短 1.7s
- 工业协议业务组件：Modbus 寄存器动态映射、协议导入自动化、树形表格递归级联，跨系统操作耗时降约 70%
实习 B：杭州聚数智创（2025.03-2025.06）实验室安全准入系统
- qiankun 微前端架构，模块拆分与子应用协作
- 富文本编辑器调研对比，WangEditor v5 二次封装（题库图文混排、多媒体）
- vue-i18n 国际化，主应用下发语言上下文动态切换文本/日期/数字格式
- 大文件分片上传：MD5 校验、断点续传、失败重试

点评：典型传统前端简历。技术栈全、性能数字多（LCP、耗时降 70%），但技能栏零 AI 关键词，投 Agent 岗会被 ATS 过滤；且每条职责偏”做了什么”，少数有量化但缺口径说明。

二、简历 2：前端 + AI 萌芽（26 届，React Native 交易所）

技能栏：前端基础（HTML5/CSS3/ES6+/TS）、框架生态（React/Next.js/React Native/Zustand/Tailwindcss/Vue）、工程化（Vite/Webpack/Turborepo/npm/pnpm/ESLint/Prettier）、服务端（Node.js/NestJS/MongoDB）、AI 应用落地（LangChain.js/RAG 架构实践）
实习：Hibit 加密货币交易所 App（Android/iOS）双端开发（2025.02-2025.08）
- 行情展示、资产信息等核心模块交互与性能优化
- 独立负责 RN 旧版升级至最新稳定版并迁移新架构，解决依赖兼容性
- 分模块验证 + 回滚机制，升级对线上用户无感
另一段经历技术栈：TypeScript / Web Performance API / Web Vitals / React Native / Vue2

点评：过渡形态。技能栏已带一行 AI（LangChain.js/RAG），但项目主体仍是纯前端（RN 升级），AI 没有项目证据支撑——是”写了关键词但面试撑不住追问”的典型。

三、简历 3：Agent 前端向（中南大学 985，28 届）

教育：2024.09-2028.06 计算机科学与技术；天梯赛全国三等奖、湖南省程序设计大赛二等奖、蓝桥杯省一等奖
技能栏（精选）：前端 React/Vue3/Next.js；客户端 Electron/Tauri/Flutter；后端 Node.js(Express)/Spring Boot；AI：了解 LLM、Agent、RAG、MCP、Skill 和 Harness 等内容，熟悉 Codex 和 Claude Code 的使用；工程化 Webpack/Vite/Rollup；性能优化（SSR/SSG、FCP/LCP 实践）；Git/Docker/Linux/Nginx/CI/CD
项目 1：CSU Star 一站式平台（团队负责人，Next.js+App Router+Zustand+Axios+Tailwind+TS+COS）
- Axios 拦截器双 Token 无感刷新；RBAC+Zustand 多角色鉴权
- 腾讯云 COS+CDN：防盗链、QPS 限流、Header 安全配置，防 XSS/CSRF/DDOS，异常请求拦截率 89%
- 分页请求/懒加载/骨架屏/静态缓存，LCP 降至 0.26s；GitHub Actions CI/CD 四端同步迭代
项目 2：FaceIt 模拟面试（前端开发，React19+TS+React Router+Zustand+SSE+TTS）
- 封装 useStreamResponse / useTypewriterText 实现打字机 SSE 流式输出
- react-markdown + remark-gfm + react-syntax-highlighter，白名单安全清洗
- 讯飞 ASR + Bilibili TTS → 浏览器 TTS 降级策略，纯语音链路面试
- Zustand 原子化状态，持久化认证缓存与对话上下文
项目 3：World Echo AI 音乐生成（客户端开发，Flutter+Dart+Provider+Dio+SSE+socket.io+just_audio）
- 文字/图片/声音多模态输入生成歌曲；Dio 请求层封装 Token 注入、SSE 流式响应解析
- SSE 实时展示生成阶段/进度/结果，优化长耗时等待
- socket.io 广场歌曲无感推送；just_audio 全局播放器

点评：方向正确的 Agent 前端简历——技能栏点名 LLM/Agent/RAG/MCP/Skill/Harness，三个项目两个是 AI 应用（SSE 流式、RAG、语音链路、安全清洗全都有）。缺口：AI 链路缺 Agent 特有量化（任务完成率、工具调用成功率、端到端延迟、token 成本），且未写统计口径；面试官对 SSE 打字机、markdown 清洗、TTS 降级每个点都可以连续追问（见[[面试题]] 的 AI 面经高频考点）。

四、前端 vs Agent 前端简历：四个维度差异

维度	纯前端	Agent 前端	依据
技能栏	框架/工程化/网络/测试，按工具名分类	写能力不写框架名：ReAct 推理循环、工具编排、错误恢复/降级、Agent 与 Workflow 选型边界	卡码笔记四方向写法
项目结构	功能清单 + 性能数字	四要素：一句话总结+业务场景+核心能力；技术决策+量化结果；难点=问题+方案+效果	手把手改简历帖（浏览 8666）
量化指标	LCP/FCP、首屏耗时、包体积	追加：任务完成率、工具调用成功率、幻觉率、推理延迟、首 Token 延迟、QPS、Token 成本、显存	卡码笔记指标分类
JD 关键词	React/Vue/TS/Webpack/性能/微前端	SSE/WebSocket、RAG、MCP、Function Calling、LangChain、Prompt、向量库、Memory、Eval/Harness	BOSS JD 对比（薪资 20-40K vs 40-150K+）

核心洞察（BOSS JD 帖）：AI Agent 工程师不是替代前端，而是在前端之上的能力叠加——“传统前端基础（必备）”。

常见减分项（多帖交叉）：

周期短却堆 RAG/流式/鉴权/复杂治理 → 深度存疑
Agent 只写”调模型、接工具”，不触及运行时、状态机、评测、观测与人在回路
每个技术名词都是追问入口：写「基于 RAG 优化问答」就要能答为什么用 RAG、文档怎么切、召回怎么做、准确率怎么评估、知识怎么更新
技术栈罗列与”把 package.json 打印出来”无异
性能数字无统计口径与复现方式

五、ATS 机制详解（2026）

1. ATS 是什么

ATS（Applicant Tracking System）自动收集、解析、评分、排序简历。流程：接收 → 解析文本 → 与 JD 关键词匹配 → 评分排序（只推荐前 10-20%）→ 人工审核。

反传言：92% 招聘者称自家 ATS 不会自动拒人；真实机制是 99.7% 用关键词/Boolean 搜索排序——匹配差的简历沉到后台第 5 页，不是被拒而是没人看到。

2026 变化：主流 ATS 在经典解析器上加 LLM 语义打分（Oracle 提交即打 0-5 分），能判断经历含义与 JD 对齐度，非纯关键词。

2. 各家 ATS 打分差异

系统	打分方式
Workday	重关键词匹配 + 严格日期解析
Greenhouse	不做算法评分，拒绝均为人工决定
Lever	AI 语义匹配，认可同义词
iCIMS	Boolean 式技能匹配
Taleo	最老精确匹配，最严格

3. 关键词策略

目标匹配度 75-85%（Jobscan 推荐 75%，严格 JD 要 90%）；100% 通常=堆砌，过不了人工关
关键词嵌进真实 bullet，不平铺
国内（AI 筛简历帖）：NLP 语义理解已替代 70% 基础人筛；能区分「优化了接口速度」vs「延迟 500ms→50ms」；写 RAG 必须配套向量库/Embedding/LangChain，技术栈不闭环会降分
按 JD 定制两个版本：投 Agent 岗缺 AI 关键词直接沉底；投纯前端岗堆 RAG/MCP 反被判不相关

4. 格式规则

标准字体（Arial/Calibri）、11-12pt、简单项目符号、标准板块标题、单栏布局、.docx 或简单 PDF；避免图片/表格/文本框/分栏。约 35% 淘汰与能力无关，纯格式/关键词问题。

六、来源

BOSS JD 对比：https://www.nowcoder.com/discuss/885626300134588416
手把手改简历：https://www.nowcoder.com/discuss/883032780106432512
卡码笔记四方向写法：https://notes.kamacoder.com/jianli/llm/llm_15.html
简历减分问题：https://www.nowcoder.com/discuss/864516869779222528
前端转 Agent 信号：https://www.nowcoder.com/discuss/879078076276105216
27 届 Agent 简历写法（50 追问）：https://www.nowcoder.com/discuss/906102877850980352
AI 筛简历：https://www.nowcoder.com/discuss/867127642368065536
ATS 2026 指南：https://www.clever.cv/zh/blog/ats-friendly-resume-guide-2026
ATS 七步法：https://developer.volcengine.com/articles/7660471069102669878
关键词匹配 Prompt：https://aitoolsguidebook.com/zh/articles/resume-keyword-matching-prompts/
ATS 打分机制：https://resumeoptimizerpro.com/blog/how-is-ats-score-calculated
Jobscan AI 筛简历：https://www.jobscan.co/blog/blog-ai-resume-screening/

OpenClaw 架构解析：一个生产级 AI Agent 是如何设计的

Thu, 05 Mar 2026 09:29:41 GMT

OpenClaw 架构解析：一个生产级 AI Agent 是如何设计的

OpenClaw / MiniClaw / Anthropic SDK / Vercel AI SDK / pi-ai / parallel-code / Git Worktree

1. OpenClaw 架构与服务分层

定位

OpenClaw 是一个网关（Gateway），一个坐在 AI 模型和外部世界中间的单体运行时，不是框架。

五层服务

第一层：渠道适配层（Channel Adapter）

把 Discord、Telegram 等不同平台的输入转成统一消息格式，顺便提取附件。一个 Agent 挂多个渠道靠的就是这层。

第二层：网关服务器（Gateway Server）

流量总入口。Session Router 判断消息属于哪个会话，然后交给 Lane Queue（车道队列）做并发管理，避免多个对话同时跑的时候请求撞车或上下文串了。

第三层：Agent Runner（智能体运行器）

管模型选择、API Key 轮换冷却、提示词拼装和上下文窗口。

第四层：Agent Runtime / Agentic Loop

跑完整的 AI 循环：从会话历史和记忆里拼上下文 → 调模型 → 执行工具（浏览器自动化、文件操作、Canvas、定时任务等）→ 把更新后的状态存下来。

就是模型说”我要调工具”，系统执行，结果塞回去，模型再想，再调，直到搞定为止。

第五层：Memory & Skills

文件都很朴素：

events.jsonl：逐行审计日志
MEMORY.md：Markdown 格式的记忆，存摘要和经验
skills/：Markdown 技能文件，按关键词匹配动态加载

Mini Claw 生态

项目	语言	定位	学习价值
htlin222/mini-claw	TypeScript	极简替代品	理解 Agent Loop
xprilion/miniclaw	Python	生产就绪版	完整服务分层实现
mattdef/miniclaw	Rust	边缘计算版	<15MB，256MB RAM 能跑
PLKwan/miniclaw	—	AI-native 无配置版	skills-over-features 思路

2. Claude Agent 内部决策流程

工具类型决策

收到用户消息
  ↓
意图识别：是否需要实时信息？
  ↓
选择工具类型：
  web_search（宽泛查询）
    → web_fetch（深入具体页面）
    → bash/file（文件操作任务）
    → 直接回答（知识性问题，无需工具）

和 OpenClaw 的对照

OpenClaw 层	Claude 的对应
Channel Adapter	claude.ai 界面 / API → 统一消息格式
Session Router	对话历史上下文
Agent Runner	系统提示词 + 工具列表注入
Agentic Loop	tool_call → result → 再推理 → 再 tool_call
Memory (AGENTS.md)	系统提示 + 用户偏好
Skills	`/mnt/skills/` 文件系统

3. 工具调用的完整生命周期

第 1 步：发送请求（带工具定义）

POST /v1/messages
{
  "model": "claude-sonnet-4-6",
  "tools": [
    {
      "name": "get_weather",
      "description": "查询指定城市的天气",
      "input_schema": {
        "type": "object",
        "properties": {
          "city": { "type": "string" }
        },
        "required": ["city"]
      }
    }
  ],
  "messages": [
    { "role": "user", "content": "新加坡今天天气怎么样？" }
  ]
}

第 2 步：模型返回 `tool_use` 块

{
  "role": "assistant",
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_01XyZ",
      "name": "get_weather",
      "input": { "city": "Singapore" }
    }
  ],
  "stop_reason": "tool_use"
}

注意 stop_reason 是 tool_use，说明模型主动停下来等结果，不是对话结束。

第 3 步：执行工具，回传结果

{
  "messages": [
    { "role": "user", "content": "新加坡今天天气怎么样？" },
    {
      "role": "assistant",
      "content": [{ "type": "tool_use", "id": "toolu_01XyZ", ... }]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "tool_result",
          "tool_use_id": "toolu_01XyZ",
          "content": "{ \"temp\": 31, \"humidity\": 84, \"condition\": \"Partly Cloudy\" }"
        }
      ]
    }
  ]
}

注意 tool_result 挂在 user role 下面，不是 assistant。工具执行的结果属于”外部世界”的返回，放在 user 侧。

第 4 步：生成最终答案

{
  "role": "assistant",
  "content": [{ "type": "text", "text": "新加坡今天天气部分多云，气温 31°C..." }],
  "stop_reason": "end_turn"
}

流程总结

用户消息
  ↓
模型 → stop_reason: "tool_use"   （模型不知道天气，停下来）
  ↓
你的程序调用真实 API
  ↓
tool_result 作为 user 消息回传
  ↓
模型 → stop_reason: "end_turn"   （现在知道了，给出答案）

一句话：模型本身不执行任何工具。它只输出”调用意图”，HTTP 请求、数据库查询这些活儿全是你的程序干的。模型是调度者，不是执行者。

4. Anthropic SDK：Tool 传入与背后逻辑

Python SDK 示例

import anthropic
import json

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_weather",
        "description": "查询指定城市的实时天气。当用户询问天气时调用此工具。",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {
                    "type": "string",
                    "description": "城市名，如 Singapore 或 New York"
                },
                "unit": {
                    "type": "string",
                    "enum": ["celsius", "fahrenheit"],
                    "description": "温度单位"
                }
            },
            "required": ["city"]
        }
    }
]

# 第一次调用
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "新加坡今天多少度？"}]
)

tool_use_id = response.content[0].id
result = get_weather(**response.content[0].input)

# 回传结果
response2 = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    messages=[
        {"role": "user", "content": "新加坡今天多少度？"},
        {"role": "assistant", "content": response.content},
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": tool_use_id,
                    "content": json.dumps(result)
                }
            ]
        }
    ]
)

背后的 5 个逻辑

tools 参数被注入系统提示词

传入 tools 时，API 会自动拼一段系统提示：

In this environment you have access to a set of tools...

<functions>
{ "name": "get_weather", "description": "...", "parameters": { ... } }
</functions>

工具不是什么魔法，就是被转成 prompt 里的文字描述。模型靠读这段文字来”学会”怎么调用。

tool_result 挂在 user role 下

消息模型只有 user 和 assistant 两种 role，工具执行属于外部世界的返回，归 user 侧。

tool_choice 控制调用策略

tool_choice={"type": "auto"}                        # 默认，模型自行决定
tool_choice={"type": "any"}                         # 必须调用某个工具
tool_choice={"type": "tool", "name": "get_weather"} # 只能调这个工具
tool_choice={"type": "none"}                        # 禁止调用工具

并行工具调用

模型可以在一次响应里返回多个 tool_use 块，全部执行完后一起回传：

{
    "role": "user",
    "content": [
        {"type": "tool_result", "tool_use_id": "toolu_001", "content": "31°C"},
        {"type": "tool_result", "tool_use_id": "toolu_002", "content": "12°C"},
    ]
}

Tool Runner（自动化 Agentic Loop，Beta）

Tool Runner 是个可迭代对象，自动循环处理工具调用。token 用量超过阈值时会自动压缩生成摘要，让长任务可以突破上下文窗口限制。

5. Vercel AI SDK：自动化 Loop

和原生 SDK 的区别

原生 SDK 给你原材料，loop 自己写。Vercel AI SDK 给你成品流水线，execute 绑定加自动循环。

示例

import { tool, generateText } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';
import { z } from 'zod';

// 定义时直接绑定执行函数
const getWeather = tool({
  description: '查询指定城市的实时天气',
  inputSchema: z.object({
    city: z.string().describe('城市名'),
    unit: z.enum(['celsius', 'fahrenheit']).optional()
  }),
  execute: async ({ city, unit = 'celsius' }) => {
    const data = await fetchWeatherAPI(city);
    return { temp: data.temp, condition: data.condition };
  }
});

// 自动循环直到没有工具调用
const { text, steps } = await generateText({
  model: anthropic('claude-sonnet-4-6'),
  tools: { getWeather },
  stopWhen: stepCountIs(10),
  prompt: '新加坡和东京今天天气怎样，哪个更适合旅游？'
});

SDK 内部自动干了什么

你调用 generateText(tools, stopWhen)
  ↓
SDK 发请求 → 模型返回 tool_use
  ↓
SDK 自动找到 execute 函数并调用
  ↓
SDK 自动构建 tool_result 消息
  ↓
SDK 自动再发一次请求（新的一步）
  ↓
重复，直到 stop_reason = "end_turn"
  ↓
返回最终 { text, steps }

人工审批门控（AI SDK 6）

const deleteFile = tool({
  description: '删除文件',
  inputSchema: z.object({ path: z.string() }),
  needsApproval: true,   // 暂停，等人点确认
  execute: async ({ path }) => { /* ... */ }
});

三种执行位置

类型	在哪执行	怎么触发
Server Tool	服务器（Node.js）	`execute` 函数自动调用
Client Auto Tool	浏览器	`onToolCall` 回调
Client UI Tool	浏览器	渲染组件，等用户操作

6. 三方 SDK 横向对比

工具定义方式

SDK	Schema 格式	执行绑定	类型安全
Anthropic 原生	JSON Schema（纯对象）	手动	无
Vercel AI SDK	Zod	`execute` 绑定	有
pi-ai	TypeBox	`execute` + `onUpdate` 回调	有

Agent Loop 控制方式

	Anthropic SDK	Vercel AI SDK	pi-ai
Loop 方式	自己写 while	`stopWhen: stepCountIs(n)`	自动循环，无 maxSteps
停止控制	手动 break	`stopWhen` 条件	信任模型自己判断
流式事件	无内置	`onStepFinish` 回调	完整事件流
多 Provider	只支持 Anthropic	支持	支持（含 OpenRouter）

pi-ai 独有的东西

Session 树状结构：Session 以树状存储，可以在会话中分支。比如开一个支线任务去修 bug，不消耗主会话的 context，修完后回滚到主会话之前的位置。

pi-ai 的包分层：

pi-ai              ← 只要 LLM 通信（多 Provider 统一接口）
pi-agent-core      ← 需要 tool loop（Agent 运行时）
pi-coding-agent    ← 需要完整 coding agent
pi-tui             ← 需要 TUI 终端界面

OpenClaw 本身用的就是 pi SDK。

选型

你的场景是什么？
│
├── 需要完整控制 / 学习底层原理
│   └── Anthropic 原生 SDK（手动 loop）
│
├── 快速构建 Next.js / React 应用
│   └── Vercel AI SDK（上手最快，生态完整）
│
└── 构建 Terminal 工具 / 编码 Agent / 嵌入 OpenClaw 类产品
    └── pi-ai（最灵活，无框架锁定）

7. parallel-code 多 Agent 并行架构

是什么

parallel-code 是一个 Electron 桌面 App，把三件事捏在一起：

每个 Agent 有独立 GUI 面板
每个任务自动用 git worktree 做隔离
支持同时派 N 个任务然后走开

怎么跑的

用户点击「新建任务」
  ↓
Electron 主进程自动执行：
  git worktree add .trees/task-name -b task-name
  ↓
在新目录 spawn 一个 pty（伪终端）进程
  运行 claude / codex / gemini CLI
  ↓
Electron renderer（前端）通过 IPC 订阅终端输出流
  在 UI 里渲染每个 Agent 的面板

隔离分三层

文件系统隔离  → git worktree（每个 Agent 在不同目录）
进程隔离      → 独立 pty 进程（每个 Agent 有独立的 env 和 PATH）
上下文隔离    → 每个 CLI 进程有独立的会话历史

8. Git Worktree 完整解析

Git 内部数据模型

.git/
├── objects/          ← 对象数据库（所有内容存在这里）
│   ├── pack/         ← 压缩后的对象包
│   └── ab/cd1234...  ← 单个对象（blob/tree/commit/tag）
├── refs/
│   ├── heads/        ← 本地 branch 指针
│   │   ├── main      ← 内容: "a1b2c3d4..."（一个 commit hash）
│   │   └── feature   ← 内容: "e5f6g7h8..."
│   └── remotes/      ← 远程 branch 指针
├── HEAD              ← 当前激活的 branch（"ref: refs/heads/main"）
├── index             ← Staging Area（暂存区）
└── config            ← 仓库配置

objects/ 是仓库的真实数据，文件内容、目录结构、提交历史全在里面。HEAD、index、工作目录都只是”视图”。

普通 clone 浪费磁盘

git clone repo/ project-feature-auth   # .git/objects/ → 500MB
git clone repo/ project-feature-ui     # .git/objects/ → 再复制 500MB
git clone repo/ project-bugfix         # .git/objects/ → 再复制 500MB
# 总计：1.5GB，其实是同一份数据复制了三次

Worktree 的磁盘结构

git worktree add .trees/feature-auth -b feature-auth
git worktree add .trees/feature-ui   -b feature-ui
git worktree add .trees/bugfix-api   -b bugfix-api

my-project/
├── .git/
│   ├── objects/                   ← 唯一的对象数据库（所有 worktree 共享）
│   ├── refs/heads/
│   │   ├── main
│   │   ├── feature-auth
│   │   ├── feature-ui
│   │   └── bugfix-api
│   │
│   └── worktrees/                 ← 每个附加 worktree 的元数据
│       ├── feature-auth/
│       │   ├── HEAD               ← "ref: refs/heads/feature-auth"
│       │   ├── index              ← 独立的暂存区
│       │   ├── gitdir             ← 指回主 .git 的路径
│       │   └── commondir          ← "../../" 告诉 Git 去哪找 objects/
│       ├── feature-ui/
│       │   ├── HEAD               ← 独立 HEAD
│       │   └── index              ← 独立暂存区
│       └── bugfix-api/
│           ├── HEAD
│           └── index
│
├── src/                           ← 主工作区文件（main branch）
│
├── .trees/feature-auth/           ← 附加工作区（feature-auth branch）
│   ├── .git                       ← 不是目录！是一个文件
│   │   └── 内容: "gitdir: ../../.git/worktrees/feature-auth"
│   └── src/                       ← 独立的工作文件
│
├── .trees/feature-ui/
└── .trees/bugfix-api/

每个 Worktree 独立和共享的部分

独立的：

工作目录（磁盘上的文件）
HEAD（当前指向哪个 branch）
index（暂存区，git add 的内容）
MERGE_HEAD / CHERRY_PICK_HEAD（进行中的操作状态）
未提交的修改

共享的：

objects/（所有 commit、文件内容的数据库）
refs/（所有 branch 和 tag 的指针）
config（remote 配置、用户信息）
hooks/（git hook 脚本）

同一 branch 不能被两个 worktree 同时 checkout

# 假设 main 已经在主工作区被 checkout
git worktree add .trees/main-copy main
# 报错：fatal: 'main' is already checked out at '/my-project'

Git 用 .git/worktrees/<name>/locked 文件来记录锁定状态，防止冲突。

常用命令

# 创建新 worktree（自动创建新 branch）
git worktree add .trees/feature-auth -b feature-auth

# 创建新 worktree（从指定 commit/branch 开始）
git worktree add .trees/hotfix origin/main

# 查看所有 worktree
git worktree list
# 输出：
# /my-project              a1b2c3d [main]
# /my-project/.trees/feature-auth  e5f6g7h [feature-auth]

# 删除 worktree
git worktree remove .trees/feature-auth

# 强制删除
git worktree remove --force .trees/feature-auth

# 清理已手动删除的 worktree 的残留元数据
git worktree prune

为什么 AI Agent 并行要用这个

Agent 1 在 .trees/feature-auth/ 运行
  → 读写文件：只影响这个目录
  → git add / commit：只提交到 feature-auth branch
  → 跑测试：在这个目录的代码上跑

Agent 2 在 .trees/feature-ui/ 运行
  → 完全感知不到 Agent 1 的存在
  → 两个 Agent 可以同时改"同名文件"（如 src/app.ts）
     但在不同 branch 上，完全不冲突

隔离靠的是 Git 原生的分支机制，在文件系统层面就把冲突的可能性断掉了，不需要应用层加锁。

9. 用 pi-ai 复现 parallel-code

方案一：Node.js 纯代码并行

import { createAgentSession } from "@mariozechner/pi-coding-agent";
import { execSync } from "child_process";
import path from "path";

function createWorktree(taskName: string, baseBranch = "main") {
  const worktreePath = path.resolve(`.trees/${taskName}`);
  execSync(`git worktree add ${worktreePath} -b ${taskName} ${baseBranch}`);
  return worktreePath;
}

async function spawnAgent(taskName: string, prompt: string) {
  const worktreePath = createWorktree(taskName);

  const { session } = await createAgentSession({
    sessionManager: SessionManager.inMemory(),
    workingDirectory: worktreePath,   // ← 隔离点
  });

  return session.prompt(prompt);
}

// 用 Promise.all 并行跑多个 Agent
const tasks = [
  { name: "feature-auth",   prompt: "实现 OAuth2 登录流程" },
  { name: "feature-search", prompt: "实现全文搜索功能" },
  { name: "bugfix-api",     prompt: "修复 /api/users 的 500 错误" },
];

const results = await Promise.all(
  tasks.map(({ name, prompt }) => spawnAgent(name, prompt))
);

方案二：Orchestrator 模式

class ParallelOrchestrator {
  private tasks = new Map<string, TaskState>();

  async dispatch(taskName: string, prompt: string) {
    const worktreePath = this.createWorktree(taskName);
    const session = await this.createSession(worktreePath);

    this.tasks.set(taskName, { status: "RUNNING", worktreePath, session });

    // 不 await，让它在背景跑
    session.prompt(prompt).then(() => {
      this.tasks.get(taskName)!.status = "COMPLETE";
    });
  }

  status() {
    return [...this.tasks.entries()].map(([name, state]) => ({
      name, status: state.status, branch: name
    }));
  }

  async merge(taskName: string) {
    execSync(`git merge ${taskName}`, { cwd: process.cwd() });
    execSync(`git worktree remove .trees/${taskName}`);
    this.tasks.delete(taskName);
  }
}

parallel-code vs pi-ai 方案

隔离层	parallel-code	pi-ai 方案
文件系统	git worktree（独立目录）	git worktree（独立目录）
Agent 上下文	独立 CLI 进程	独立 `session` 内存对象
会话历史	进程级隔离	`SessionManager.inMemory()` 各自隔离
GUI	Electron 面板	需自己实现
合并流程	点击按钮 PR	`git merge` 命令

整理自对话学习笔记。

Anthony Fu 的 Vue3 开发规范完整解读

Wed, 11 Feb 2026 04:00:00 GMT

// ❌ 避免：一个文件包含所有逻辑 // UserManager.ts (800 lines) export class UserManager { validateUser() { /* 50 lines / } fetchUserData() { / 100 lines / } updateUserProfile() { / 150 lines */ } // … }

// ✅ 推荐：按职责拆分 // validation.ts export function validateUser(user: User) { /* … */ }

// api.ts export function fetchUserData(id: string) { /* … */ }

// profile.ts export function updateUserProfile(data: ProfileData) { /* … */ }


**类型与常量分离**

```ts
// types.ts
export interface User {
  id: string
  name: string
  role: UserRole
}

export type UserRole = 'admin' | 'user' | 'guest'

// constants.ts
export const DEFAULT_PAGE_SIZE = 20
export const MAX_RETRIES = 3
export const API_ENDPOINTS = {
  users: '/api/users',
  posts: '/api/posts',
} as const

// user-service.ts
import type { User, UserRole } from './types'
import { API_ENDPOINTS } from './constants'

export async function fetchUsers(): Promise<User[]> {
  const response = await fetch(API_ENDPOINTS.users)
  return response.json()
}

运行时环境标注

编写同构代码时，为环境特定的代码添加明确的注释：

// ✅ 明确标注环境依赖
// @env browser
export function getWindowSize() {
  return {
    width: window.innerWidth,
    height: window.innerHeight,
  }
}

// @env node
export function readConfigFile() {
  return fs.readFileSync('./config.json', 'utf-8')
}

// ✅ 同构代码无需标注
export function formatDate(date: Date): string {
  return date.toISOString()
}

TypeScript 最佳实践

显式返回类型

// ❌ 避免：隐式返回类型
export function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0)
}

// ✅ 推荐：显式返回类型
export function calculateTotal(items: Item[]): number {
  return items.reduce((sum, item) => sum + item.price, 0)
}

// ✅ 复杂类型提取为类型别名
export type AsyncResult<T> = Promise<{ data: T; error: null } | { data: null; error: Error }>

export function fetchData<T>(url: string): AsyncResult<T> {
  // ...
}

避免复杂内联类型

// ❌ 避免：复杂内联类型
function processUsers(
  users: Array<{
    id: string
    profile: {
      name: string
      email: string
      settings: {
        theme: 'light' | 'dark'
        notifications: boolean
      }
    }
  }>
) {
  // ...
}

// ✅ 推荐：提取类型定义
interface UserSettings {
  theme: 'light' | 'dark'
  notifications: boolean
}

interface UserProfile {
  name: string
  email: string
  settings: UserSettings
}

interface User {
  id: string
  profile: UserProfile
}

function processUsers(users: User[]) {
  // ...
}

注释哲学

解释”为什么”而非”怎么做”

// ❌ 避免：无意义的注释
// 循环遍历用户数组
users.forEach(user => {
  // 打印用户名
  console.log(user.name)
})

// ✅ 推荐：解释为什么这样做
// 使用 setTimeout 0 延迟执行，确保 DOM 更新完成后再计算高度
setTimeout(() => {
  const height = element.offsetHeight
}, 0)

// ✅ 解释非直观的业务逻辑
// 价格计算需要先扣除折扣，再加税费，顺序不能颠倒
// 因为税费基于折后价计算（符合当地税法要求）
const finalPrice = (price - discount) * (1 + taxRate)

测试规范（Vitest）

文件组织

src/
  utils/
    format.ts          # 源代码
    format.test.ts     # 测试文件
  components/
    Button.vue
    Button.test.ts

测试结构

// format.test.ts
import { describe, it, expect } from 'vitest'
import { formatCurrency, formatDate } from './format'

describe('formatCurrency', () => {
  it('should format USD correctly', () => {
    expect(formatCurrency(1234.56, 'USD')).toBe('$1,234.56')
  })

  it('should handle zero', () => {
    expect(formatCurrency(0, 'USD')).toBe('$0.00')
  })

  it('should round to 2 decimal places', () => {
    expect(formatCurrency(1.234, 'USD')).toBe('$1.23')
  })
})

describe('formatDate', () => {
  it('should match snapshot', () => {
    const date = new Date('2024-01-15T10:30:00Z')
    expect(formatDate(date)).toMatchSnapshot()
  })
})

工具链速查

@antfu/ni - 通用包管理器命令

命令	npm	yarn	pnpm	bun
`ni`	`npm install`	`yarn install`	`pnpm install`	`bun install`
`nr dev`	`npm run dev`	`yarn run dev`	`pnpm run dev`	`bun run dev`
`nu`	`npm update`	`yarn upgrade`	`pnpm update`	`bun update`
`nun lodash`	`npm uninstall lodash`	`yarn remove lodash`	`pnpm remove lodash`	`bun remove lodash`
`nci`	`npm ci`	`yarn install --frozen-lockfile`	`pnpm install --frozen-lockfile`	`bun install --frozen-lockfile`
`nlx vitest`	`npx vitest`	`yarn dlx vitest`	`pnpm dlx vitest`	`bunx vitest`

TypeScript 配置标准

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "lib": ["ESNext", "DOM", "DOM.Iterable"],
    "jsx": "preserve",
    "strict": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "isolatedModules": true,
    "noUncheckedIndexedAccess": true,
    "paths": {
      "~/*": ["./src/*"]
    }
  }
}

关键配置说明：

moduleResolution: "bundler" - 适配 Vite/Rollup 等现代打包工具
noUncheckedIndexedAccess: true - 索引访问返回 T | undefined，更安全
strict: true - 启用所有严格类型检查

ESLint 配置

# 安装
pnpm add -D @antfu/eslint-config eslint

# 运行
pnpm run lint --fix

// eslint.config.js
import antfu from '@antfu/eslint-config'

export default antfu({
  vue: true,
  typescript: true,
  formatters: {
    css: true,
    html: true,
    markdown: true,
  },
})

Git Hooks 配置

# 安装
pnpm add -D simple-git-hooks lint-staged

// package.json
{
  "simple-git-hooks": {
    "pre-commit": "pnpm lint-staged"
  },
  "lint-staged": {
    "*.{js,ts,vue}": "eslint --fix"
  }
}

pnpm Catalogs 最佳实践

# pnpm-workspace.yaml
catalogs:
  # 生产依赖
  prod:
    vue: ^3.5.0
    pinia: ^2.2.0
  
  # 内联依赖（会被打包）
  inlined:
    lodash-es: ^4.17.21
  
  # 开发依赖
  dev:
    vitest: ^2.0.0
    typescript: ^5.6.0
  
  # 前端特定依赖
  frontend:
    unocss: ^0.63.0

// package.json
{
  "dependencies": {
    "vue": "catalog:prod",
    "lodash-es": "catalog:inlined"
  },
  "devDependencies": {
    "vitest": "catalog:dev",
    "unocss": "catalog:frontend"
  }
}

第二部分：Vue 3 核心规范

基于 Vue 3.5，优先使用 TypeScript 和 <script setup>

偏好设定

场景	推荐方案	原因
语言选择	TypeScript	类型安全、更好的 IDE 支持
脚本格式	`<script setup lang="ts">`	更简洁的语法、更好的性能
响应式选择	`shallowRef` > `ref`	大多数场景足够用，性能更好
API 风格	Composition API	更好的逻辑复用和类型推导
Props 解构	❌ 不推荐	会丢失响应式

标准组件模板

<script setup lang="ts">
import { computed, ref, watch, onMounted } from 'vue'
import type { ComponentPublicInstance } from 'vue'

// Props 定义
interface Props {
  title: string
  count?: number
  disabled?: boolean
}

const props = withDefaults(defineProps<Props>(), {
  count: 0,
  disabled: false,
})

// Emits 定义
interface Emits {
  update: [value: number]
  submit: [data: { name: string }]
}

const emit = defineEmits<Emits>()

// Model 双向绑定
const modelValue = defineModel<string>({ required: true })

// 响应式状态
const isLoading = ref(false)
const items = ref<Item[]>([])

// 计算属性
const displayTitle = computed(() => {
  return props.disabled ? `${props.title} (已禁用)` : props.title
})

// 侦听器
watch(() => props.count, (newVal, oldVal) => {
  console.log(`Count changed from ${oldVal} to ${newVal}`)
})

// 生命周期
onMounted(() => {
  console.log('Component mounted')
})

// 方法
function handleClick() {
  emit('update', props.count + 1)
}

// 暴露给父组件（defineExpose）
defineExpose({
  focus: () => {
    // 暴露的方法
  },
})
</script>

<template>
  <div>
    <h1>{{ displayTitle }}</h1>
    <button @click="handleClick" :disabled="disabled">
      Count: {{ count }}
    </button>
  </div>
</template>

<style scoped>
/* scoped 样式 */
</style>

关键导入速查

// 核心响应式 API
import {
  ref,           // 深层响应式
  shallowRef,    // 浅层响应式（推荐）
  reactive,      // 深层响应式对象
  shallowReactive, // 浅层响应式对象
  readonly,      // 只读代理
  computed,      // 计算属性
  watch,         // 侦听器
  watchEffect,   // 副作用侦听器
} from 'vue'

// 生命周期钩子
import {
  onMounted,
  onUpdated,
  onUnmounted,
  onBeforeMount,
  onBeforeUpdate,
  onBeforeUnmount,
} from 'vue'

// 组件通信
import {
  defineProps,
  defineEmits,
  defineModel,
  defineExpose,
  defineSlots,
  provide,
  inject,
} from 'vue'

// 工具函数
import {
  nextTick,      // 等待 DOM 更新
  toRef,         // 转换为 ref
  toRefs,        // 解构保持响应式
  unref,         // 解包 ref
  isRef,         // 判断是否 ref
  markRaw,       // 标记为非响应式
} from 'vue'

// 类型工具
import type {
  Ref,
  ComputedRef,
  ComponentPublicInstance,
  PropType,
} from 'vue'

ref vs shallowRef 性能对比

// ref - 深层响应式（递归代理所有层级）
const deepState = ref({
  user: {
    profile: {
      name: 'John',
      settings: {
        theme: 'dark',
      },
    },
  },
})

// 任何层级的修改都会触发响应
deepState.value.user.profile.settings.theme = 'light' // ✅ 响应式

// shallowRef - 浅层响应式（只代理第一层）
const shallowState = shallowRef({
  user: {
    profile: {
      name: 'John',
      settings: {
        theme: 'dark',
      },
    },
  },
})

// 只有整体替换才会触发响应
shallowState.value.user.profile.settings.theme = 'light' // ❌ 不会触发
shallowState.value = { ...shallowState.value } // ✅ 触发响应

// 性能建议：大部分场景使用 shallowRef 足够

第三部分：Vue 3 最佳实践与常见陷阱

响应式系统

问题	建议
ref vs reactive 如何选择？	优先使用 `ref`。`ref` 可以存储任何类型，而 `reactive` 只能用于对象。`ref` 在重新赋值时保持响应性，`reactive` 不行。
什么时候用 shallowRef？	存储大型数据结构（如长列表、复杂嵌套对象）时，用 `shallowRef` 避免深层代理的性能开销。更新时需要整体替换对象。
如何阻止对象变成响应式？	使用 `markRaw()`。例如存储第三方库实例（Chart.js、Monaco Editor）时，避免不必要的代理。
多次修改 ref 会触发多次渲染吗？	不会。Vue 会将同一 tick 内的更新批量处理。如需立即看到 DOM 变化，使用 `await nextTick()`。
ref 解包规则是什么？	在模板中自动解包（`{{ count }}`）。在 `reactive` 对象中自动解包（`state.count`）。在数组和 Map/Set 中不解包（需要 `.value`）。
解构 props 会丢失响应性吗？	是的。使用 `toRefs(props)` 或 `toRef(props, 'key')` 保持响应性，或在 computed/watch 中访问 `props.xxx`。

计算属性

问题	建议
计算属性可以有副作用吗？	不应该。计算属性应该是纯函数，只做计算和返回值。副作用应该放在 `watch` 或 `watchEffect` 中。
为什么计算属性是只读的？	默认只读，但可以提供 setter。推荐只读设计，修改应通过源数据。
计算属性什么时候重新计算？	只有当依赖的响应式数据变化时才重新计算（懒执行 + 缓存）。这是相比 `method` 的主要优势。
计算属性的条件依赖如何工作？	只追踪当前执行分支的依赖。`if (flag) return a` 时只追踪 `flag` 和 `a`，不追踪 `else` 分支。
计算属性内使用 array.map 有性能问题吗？	有。每次重新计算都会创建新数组。考虑使用 `shallowRef` 存储映射结果，或在 `watch` 中手动更新。

侦听器

问题	建议
watch 的 getter 函数是什么？	`watch(() => obj.count, ...)` 中的箭头函数。推荐用 getter 而非直接传对象，可以精确控制依赖。
deep: true 有性能问题吗？	有。深度侦听需要遍历对象的所有属性。只在必要时使用，或用 getter 函数精确指定依赖。
immediate: true 的执行时机是什么？	立即执行一次，此时 DOM 可能未挂载。需要访问 DOM 时注意判断。
flush 选项有什么区别？	`pre`（默认）：DOM 更新前执行。`post`：DOM 更新后执行。`sync`：同步执行（避免使用）。
如何在侦听器中访问旧值？	`watch(source, (newVal, oldVal) => {})`。注意对象类型的 `oldVal` 和 `newVal` 可能指向同一个引用。
watch vs watchEffect 如何选择？	`watchEffect`：自动追踪依赖，简洁。`watch`：显式指定侦听源，可访问旧值，更精确。

组件通信

问题	建议
可以修改 props 吗？	不可以。Props 是单向数据流，只读。需要修改时，emit 事件或使用 `defineModel`。
自定义事件会冒泡吗？	不会。Vue 的自定义事件不像原生 DOM 事件那样冒泡，只触发直接父组件的监听器。
组件名应该用什么格式？	PascalCase（`MyComponent.vue`）。在模板中可以用 `<MyComponent>` 或 `<my-component>`，推荐前者。
defineExpose 何时使用？	当需要父组件通过 ref 调用子组件方法时。默认 `<script setup>` 不暴露任何内容。
如何获取组件实例的类型？	`InstanceType<typeof MyComponent>`，配合 `ref<InstanceType<typeof MyComponent>>()`。

Props 与 Emits

问题	建议
Boolean props 的转换规则？	`<MyComp disabled>` 等价于 `:disabled="true"`。`<MyComp>` 则是 `undefined`（除非有默认值）。
解构 props 会丢失响应性吗？	是的。`const { title } = defineProps()` 会丢失响应性。使用 `toRefs` 或直接访问 `props.title`。
props 命名约定是什么？	JS 中用 camelCase，HTML 中用 kebab-case。`defineProps<{ userName: string }>()` → `<Comp user-name="John">`。
emit 事件命名约定？	JS 中用 camelCase，HTML 中用 kebab-case。`emit('updateValue')` → `@update-value="handler"`。
defineModel 的优势是什么？	简化 `v-model` 实现，自动生成 prop 和 emit。支持修饰符（`.trim`、`.number` 等）。

模板语法

问题	建议
v-html 安全吗？	不安全。可能导致 XSS 攻击。只用于可信内容，或使用 DOMPurify 等库清理。
v-if 和 v-for 能同时用吗？	Vue 3 中 `v-if` 优先级高于 `v-for`，但不推荐同时使用。应该用 computed 过滤或嵌套 template。
v-if vs v-show 如何选择？	`v-if`：条件渲染，切换开销高。`v-show`：CSS 切换，初始渲染开销高。频繁切换用 `v-show`。
key 的作用是什么？	帮助 Vue 识别节点，优化 diff 算法。列表渲染必须提供唯一 key，避免用 index。
如何绑定多个属性？	`v-bind="attrs"` 可以一次性绑定对象的所有属性。例如 `v-bind="{ id: 'foo', class: 'bar' }"`。

表单与 v-model

问题	建议
defineModel 的修饰符如何使用？	内置 `.trim`、`.number`、`.lazy`。自定义修饰符通过 `defineModel` 的第二个参数处理。
v-model 在组件上的原理？	语法糖：`:modelValue="value" @update:modelValue="value = $event"`。多个 v-model：`v-model:title`。
如何在 v-model 更新后访问 DOM？	使用 `await nextTick()`，因为 Vue 异步更新 DOM。
textarea 的 v-model 和插值的区别？	`<textarea v-model="text">` 正确。`<textarea>{{ text }}</textarea>` 不生效，textarea 不支持插值。

事件处理与修饰符

问题	建议
.once 修饰符如何工作？	事件只触发一次后自动移除监听器。`@click.once="handler"`。
.exact 修饰符的作用？	精确匹配修饰键。`@click.ctrl.exact` 只在按下 Ctrl（无其他键）时触发。
.passive 和 .prevent 冲突吗？	冲突。`.passive` 告诉浏览器不调用 `preventDefault()`，两者不能同时使用。
自定义事件可以用修饰符吗？	可以，但需要在子组件中通过 `defineEmits` 的第二个参数手动实现验证逻辑。

生命周期

问题	建议
生命周期钩子必须同步注册吗？	是的。必须在 `setup` 或 `<script setup>` 的同步代码中调用，不能在 `setTimeout` 或 `async` 函数中。
onUpdated 钩子性能如何？	会在任何响应式数据变化导致的重新渲染后调用，可能频繁触发。谨慎使用，考虑用 `watch` 替代。
如何在组件外部注册生命周期？	使用 `effectScope` 创建作用域，在其中注册钩子。

插槽

问题	建议
插槽的作用域是什么？	默认插槽只能访问父组件的数据。作用域插槽通过 `v-slot="slotProps"` 接收子组件传递的数据。
defineSlots 的作用？	仅用于类型定义，帮助 TypeScript 推导插槽的 props 类型。不影响运行时。
插槽的 fallback content 是什么？	`<slot>默认内容</slot>` 中的默认内容，当父组件不提供插槽内容时显示。
动态插槽名如何使用？	`v-slot:[dynamicSlotName]` 或 `#[dynamicSlotName]`。

Provide / Inject

问题	建议
应该用什么作为 injection key？	使用 Symbol 而非字符串，避免命名冲突。`export const userKey = Symbol('user')`。
注入的数据可以修改吗？	可以，但建议 mutations 集中在 provider 组件，通过提供修改方法而非直接暴露响应式状态。
如何为 inject 提供类型？	`const user = inject<User>(userKey)` 或在定义 key 时指定 `InjectionKey<User>`。

组合式函数

问题	建议
命名约定是什么？	以 `use` 开头，camelCase。例如 `useMouse`、`useFetch`。
返回值应该是什么？	返回包含响应式状态和方法的对象。使用 `readonly()` 保护内部状态。
何时使用 options 对象模式？	参数超过 2 个时推荐。`useFetch(url, { method, headers, onSuccess })`。
组合式函数可以嵌套调用吗？	可以。一个组合式函数可以调用其他组合式函数。

// 示例：标准组合式函数
export function useMouse() {
  const x = ref(0)
  const y = ref(0)

  function update(event: MouseEvent) {
    x.value = event.clientX
    y.value = event.clientY
  }

  onMounted(() => window.addEventListener('mousemove', update))
  onUnmounted(() => window.removeEventListener('mousemove', update))

  return {
    x: readonly(x),
    y: readonly(y),
  }
}

Composition API

问题	建议
为什么用 Composition API 替代 mixin？	Mixin 有命名冲突、来源不清晰、难以重用等问题。Composition API 通过函数组合解决这些问题。
Composition API 和 React Hooks 有什么区别？	Vue 的 setup 只执行一次，不受闭包陷阱影响。React Hooks 每次渲染都执行，需要依赖数组。
何时仍然使用 Options API？	简单组件、团队不熟悉 Composition API、维护老代码时可以使用 Options API。

自定义指令

问题	建议
必须清理副作用吗？	是的。在 `unmounted` 钩子中清理事件监听器、定时器等，避免内存泄漏。
指令命名约定？	以 `v` 开头。注册时用 camelCase（`vFocus`），使用时用 kebab-case（`v-focus`）。
可以在组件上使用指令吗？	可以，但不推荐。指令会应用到组件的根元素，多根元素组件会报警告。

过渡与动画

问题	建议
Transition 只能包含单个子元素吗？	是的。多个元素需要用 `v-if` / `v-else` 或 `TransitionGroup`。
为什么列表项需要 key？	`TransitionGroup` 使用 key 追踪元素移动，实现平滑的移动动画。
mode 属性的作用？	`out-in`：旧元素先离开，新元素再进入。`in-out`：新元素先进入，旧元素再离开。
如何自定义动画时长？	通过 `duration` prop：`<Transition :duration="500">` 或 `{ enter: 500, leave: 800 }`。

KeepAlive

问题	建议
max 属性的作用？	限制缓存组件数量，超出时移除最久未访问的。`<KeepAlive :max="10">`。
组件必须有 name 属性吗？	使用 `include` / `exclude` 时需要。`<script setup>` 组件名默认是文件名。
特殊生命周期钩子？	`onActivated`（激活时）、`onDeactivated`（停用时）。用于处理缓存组件的状态恢复。

异步组件

问题	建议
delay 选项的作用？	延迟显示加载状态，避免加载很快时出现闪烁。默认 200ms。
hydration 策略是什么？	Vue 3.5+ 支持延迟 hydration：`defineAsyncComponent({ loader, hydrate: 'visible' })`。

TypeScript 集成

问题	建议
如何为 defineProps 提供类型？	基于类型：`defineProps<{ title: string }>()`。基于运行时：`defineProps({ title: String })`。推荐前者。
withDefaults 如何使用？	`withDefaults(defineProps<Props>(), { count: 0 })`，为类型定义的 props 提供默认值。
如何获取组件实例类型？	`InstanceType<typeof MyComponent>`，用于 ref 的类型标注。

// 完整示例
import MyComponent from './MyComponent.vue'

const compRef = ref<InstanceType<typeof MyComponent>>()

onMounted(() => {
  compRef.value?.focus() // 类型安全的方法调用
})

SSR 注意事项

问题	建议
如何避免跨请求状态污染？	每个请求创建新的应用实例。避免在模块顶层创建响应式状态。
服务端可以使用哪些 API？	不能用 `window`、`document` 等浏览器 API。生命周期只有 `setup`、`onServerPrefetch`。
getSSRProps 的作用？	在 SSR 时修改组件 props，常用于注入服务端数据。

性能优化

问题	建议
props 稳定性为什么重要？	子组件使用 `shallowRef` 时，props 引用变化会触发重新渲染。尽量保持 props 引用稳定。
何时使用虚拟滚动？	渲染超过 1000 项的列表时。使用 `vue-virtual-scroller` 等库。
v-once 和 v-memo 的区别？	`v-once`：只渲染一次，永不更新。`v-memo`：条件性跳过更新，依赖数组未变时复用。

SFC 特性

问题	建议
如何在 scoped 样式中修改子组件？	使用 `:deep()` 伪类：`.parent :deep(.child) { }`。
scoped CSS 的限制？	不影响子组件的根元素（会自动添加 scoped 属性）。深层元素需要 `:deep()`。

插件开发

问题	建议
插件应该用 provide/inject 吗？	是的。插件通过 provide 提供功能，组件通过 inject 使用，比全局属性更灵活。
注入 key 命名约定？	使用 Symbol 避免冲突：`export const myPluginKey = Symbol()`。
如何为插件添加类型支持？	通过模块扩展：`declare module 'vue' { interface ComponentCustomProperties { $myPlugin: MyPlugin } }`。

第四部分：为什么选择 UnoCSS 而不是 Tailwind CSS？

核心论点：UnoCSS 是 Tailwind 的超集

UnoCSS 不是 Tailwind 的竞争者，而是增强版。通过预设系统，UnoCSS 可以 100% 兼容 Tailwind 语法：

// uno.config.ts
import { defineConfig, presetWind } from 'unocss'

export default defineConfig({
  presets: [
    presetWind(), // Tailwind CSS v3 兼容
    // 或 presetWind({ version: 4 }) // Tailwind CSS v4 兼容
  ],
})

使用 presetWind 后，所有 Tailwind 类名都能正常工作：

<!-- Tailwind 语法完全兼容 -->
<div class="flex items-center justify-between p-4 bg-blue-500 text-white rounded-lg shadow-md hover:bg-blue-600 transition">
  <span class="text-xl font-bold">完全兼容</span>
</div>

UnoCSS 的独家能力

1. 纯 CSS 图标（零 JS 运行时）

UnoCSS 通过 presetIcons 支持 10 万+ Iconify 图标，编译为纯 CSS，零 JavaScript 运行时开销：

pnpm add -D @iconify-json/carbon @iconify-json/mdi

<!-- 直接用 class 引用图标，无需导入 -->
<div class="i-carbon-logo-github text-2xl" />
<div class="i-mdi-home text-red-500" />
<button class="i-carbon-arrow-right hover:i-carbon-arrow-right-filled" />

编译结果（纯 CSS）：

.i-carbon-logo-github {
  display: inline-block;
  width: 1em;
  height: 1em;
  background: url("data:image/svg+xml;utf8,...") no-repeat;
  background-size: 100% 100%;
}

对比 Tailwind + React Icons：

Tailwind：需要导入 React/Vue 组件，增加 bundle 体积
UnoCSS：纯 CSS，零 JS，图标按需编译

2. 属性化模式（Attributify）

避免 class 字符串爆炸：

<!-- Tailwind：class 字符串过长 -->
<button class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded-lg shadow-md transition duration-300 flex items-center gap-2">
  提交
</button>

<!-- UnoCSS：属性化模式 -->
<button 
  bg="blue-500 hover:blue-600"
  text="white"
  font="bold"
  p="y-2 x-4"
  rounded="lg"
  shadow="md"
  transition
  duration="300"
  flex
  items="center"
  gap="2"
>
  提交
</button>

3. Variant Group（变体组简写）

<!-- Tailwind：重复写 hover -->
<div class="hover:bg-red-500 hover:text-white hover:scale-105">

<!-- UnoCSS：Variant Group -->
<div class="hover:(bg-red-500 text-white scale-105)">

4. 自定义规则引擎

Tailwind 需要配置复杂的插件系统，UnoCSS 支持正则和函数定义原子类：

// uno.config.ts
import { defineConfig } from 'unocss'

export default defineConfig({
  rules: [
    // 正则匹配：自定义间距
    [/^m-(\d+)$/, ([, d]) => ({ margin: `${d}px` })],
    
    // 函数定义：自定义颜色
    ['text-brand', { color: '#3b82f6' }],
    
    // 动态值：任意单位
    [/^gap-(\d+)(px|rem|em)$/, ([, num, unit]) => ({ gap: `${num}${unit}` })],
  ],
  shortcuts: {
    // 快捷组合类
    'btn-primary': 'bg-blue-500 text-white px-4 py-2 rounded hover:bg-blue-600',
  },
})

5. 编译模式（Compile Class）

将多个原子类编译为一个哈希类，减少 HTML 体积：

<!-- 开发模式：原子类 -->
<div class="flex items-center gap-4 bg-blue-500 p-4">

<!-- 生产模式：编译为单个类 -->
<div class="uno-abc123">

<style>
.uno-abc123 {
  display: flex;
  align-items: center;
  gap: 1rem;
  background: #3b82f6;
  padding: 1rem;
}
</style>

对比总结

特性	Tailwind CSS	UnoCSS
基础原子类	✅ 完整支持	✅ 完全兼容（presetWind）
图标方案	需要额外库（React Icons 等）	✅ 内置 10 万+ 图标（纯 CSS）
属性化模式	❌ 不支持	✅ presetAttributify
Variant Group	❌ 不支持	✅ `hover:(bg-red text-white)`
自定义规则	复杂插件系统	✅ 正则/函数直接定义
编译模式	❌ 不支持	✅ 编译为哈希类
性能	JIT 编译快	✅ 更快（Vite 原生）
生态整合	Standalone	✅ Vite/Nuxt 深度集成

与 Anthony Fu 技术栈的协同

Vite 原生设计：UnoCSS 为 Vite 设计，HMR 极快
Nuxt 一等公民：@nuxt/unocss 开箱即用
作者生态：Anthony Fu 同时是 UnoCSS 和 Iconify 的作者，工具链深度整合

完整配置示例

// uno.config.ts
import {
  defineConfig,
  presetAttributify,
  presetIcons,
  presetTypography,
  presetUno,
  presetWebFonts,
  transformerDirectives,
  transformerVariantGroup,
} from 'unocss'

export default defineConfig({
  // 预设
  presets: [
    presetUno(), // 默认预设（类似 Tailwind）
    presetAttributify(), // 属性化模式
    presetIcons({
      scale: 1.2,
      cdn: 'https://esm.sh/',
    }),
    presetTypography(), // 排版预设
    presetWebFonts({
      fonts: {
        sans: 'Inter',
        mono: 'Fira Code',
      },
    }),
  ],

  // 转换器
  transformers: [
    transformerDirectives(), // @apply 指令
    transformerVariantGroup(), // Variant Group
  ],

  // 自定义规则
  rules: [
    ['text-brand', { color: '#3b82f6' }],
  ],

  // 快捷方式
  shortcuts: {
    'btn': 'px-4 py-2 rounded inline-block cursor-pointer',
    'btn-primary': 'btn bg-blue-500 text-white hover:bg-blue-600',
  },

  // 主题扩展
  theme: {
    colors: {
      brand: {
        primary: '#3b82f6',
        secondary: '#8b5cf6',
      },
    },
  },
})

安装命令：

pnpm add -D unocss
pnpm add -D @iconify-json/carbon @iconify-json/mdi

第五部分：配套工具链一览

工具	用途	推荐理由
Vue 3.5+	渐进式 JavaScript 框架	Composition API、性能优化、TypeScript 支持
Nuxt 3	Vue 元框架	SSR/SSG、文件路由、服务端 API、SEO 优化
Pinia	状态管理	直观的 API、完整的 TypeScript 支持、Vue DevTools 集成
Vite	构建工具	极速 HMR、原生 ESM、Rollup 生产构建
VitePress	静态站点生成器	Vue 驱动、Markdown 扩展、主题定制
Vitest	单元测试	Vite 原生、与 Jest 兼容的 API、快速执行
UnoCSS	原子化 CSS 引擎	Tailwind 超集、纯 CSS 图标、Vite 深度集成
pnpm	包管理器	磁盘高效、严格依赖管理、monorepo 支持
VueUse	组合式函数集合	200+ 实用工具、SSR 友好、Tree-shakable
Slidev	开发者幻灯片	Markdown 编写、Vue 组件、录制功能
tsdown	TypeScript 打包工具	零配置、类型声明生成、ESM/CJS 双输出
Vue Router	官方路由	嵌套路由、导航守卫、动态路由匹配

快速开始命令

# 创建 Vue 3 项目（Vite）
pnpm create vite my-vue-app --template vue-ts

# 创建 Nuxt 3 项目
pnpm dlx nuxi@latest init my-nuxt-app

# 添加 UnoCSS
pnpm add -D unocss

# 添加 VueUse
pnpm add @vueuse/core

# 添加 Pinia
pnpm add pinia

# 添加 Vitest
pnpm add -D vitest

总结

Anthony Fu 的开发规范强调：

类型安全优先：TypeScript + 显式类型定义
性能意识：shallowRef > ref、避免深度侦听、虚拟滚动
工具链协同：Vite + UnoCSS + Vitest 深度整合
代码质量：单一职责、ESLint 自动化、Git Hooks
现代化实践：Composition API、<script setup>、组合式函数

通过遵循这些规范，可以构建更快、更可维护、更具扩展性的 Vue 3 应用。

参考资料：

antfu/skills - Anthony Fu 的技能标准文档
Vue 3 官方文档
UnoCSS 文档
VueUse 文档

译者注： 本文基于 antfu/skills 仓库于 2026 年 2 月的内容整理翻译，随着生态演进，部分实践可能更新，请以官方文档为准。

Lenis 与 GSAP ScrollTrigger 深度解析

Thu, 29 Jan 2026 16:50:00 GMT

Lenis 与 GSAP ScrollTrigger 深度解析

在现代网页设计中，流畅的滚动体验已经成为高品质网站的标配。本文将深入剖析 Lenis 平滑滚动库与 GSAP ScrollTrigger 的协作原理，带你从底层理解如何打造丝滑的滚动动画。

一、浏览器原生滚动 vs 虚拟滚动

原生滚动的局限

浏览器原生的滚动机制虽然简单直接，但存在明显的问题：

// 浏览器原生滚动
window.scrollTo(0, 1000);  // 立即跳转，生硬

// 用户滚轮事件
document.addEventListener('wheel', (e) => {
  // 浏览器直接改变 scrollTop，没有缓动
  window.scrollY += e.deltaY;  
});

主要问题：

❌ 滚动是离散的、跳跃的
❌ 没有惯性效果
❌ 不同设备滚动速度差异大
❌ 无法自定义缓动曲线

虚拟滚动（Lenis）的核心思想

Lenis 通过”虚拟滚动”技术彻底改变了这一现状：

真实滚动：
┌─────────────┐
│  viewport   │ ← 固定不动（overflow: hidden）
└─────────────┘
      ↓
   内容通过 transform 移动
      ↓
┌─────────────┐
│   content   │ ← transform: translateY(-1000px)
│             │
│   (很长)    │
└─────────────┘

工作流程：
用户滚轮 → Lenis 监听 → 计算目标位置 → RAF 动画循环 → 更新 transform

关键点：页面实际上没有滚动，只是内容元素通过 transform 属性在移动，产生滚动的视觉效果。

二、Lenis 配置详解

基础配置示例

const lenis = new Lenis({
  wrapper: document.querySelector(".smooth-wrapper"),
  content: document.querySelector(".smooth-content"),
  duration: 1.2,
  easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t)),
  orientation: "vertical",
  gestureOrientation: "vertical",
  smoothWheel: true,
  wheelMultiplier: 1,
  smoothTouch: false,
  touchMultiplier: 2,
  infinite: false,
});

关键参数深度解析

1. `wrapper` 与 `content`：双层结构的必要性

<div class="smooth-wrapper">     ← wrapper（视口，overflow: hidden）
  <div class="smooth-content">   ← content（被移动的内容）
    <article>...</article>
    <article>...</article>
  </div>
</div>

为什么需要两层？

wrapper：固定尺寸的视口容器，用户实际看到的区域
content：真实内容容器，通过 transform: translateY() 移动

这种分离设计是虚拟滚动的基础，wrapper 负责”窗口”，content 负责”画布”。

2. `duration: 1.2`：缓动响应时间

// 注意：这不是"滚动到目标位置的总时间"！
// 而是"缓动响应速度"

// 举例：
用户滚轮滚动 100px
    ↓
Lenis 不会立即移动 100px
    ↓
而是在约 1.2 秒内"追赶"到目标位置
    ↓
产生平滑、有惯性的效果

数值越大，滚动越”慵懒”；越小，响应越灵敏。

3. `easing` 函数：自定义缓动曲线

easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t))
//       ↑
//    t = 0 到 1 的进度值

// 这是一个"ease-out"曲线：
// t=0   → 0      (开始快)
// t=0.5 → 0.999  (中间快)
// t=1   → 1      (结束慢)

// 效果：滚动快速启动，然后自然减速停止

你可以使用任何缓动函数，比如：

t => t：线性
t => t * t：ease-in
t => 1 - Math.pow(1 - t, 3)：ease-out cubic

4. `smoothWheel: true`：惯性滚动的关键

// false: 每次滚轮事件立即到达目标
document.addEventListener('wheel', (e) => {
  scrollTo(current + e.deltaY);  // 立即跳转，无缓动
});

// true: 滚轮事件累积速度，产生惯性
let velocity = 0;
document.addEventListener('wheel', (e) => {
  velocity += e.deltaY;  // 累积速度
  // RAF 循环中逐渐应用速度，形成惯性
});

开启后，滚动会有”物理感”，就像真实世界中推动一个物体。

Lenis 内部运作机制

// Lenis 内部简化版伪代码
class Lenis {
  raf(time) {
    // 1. 获取当前滚动位置
    const current = this.scroll;
    
    // 2. 获取目标位置（用户想滚动到哪里）
    const target = this.targetScroll;
    
    // 3. 计算差值并应用缓动
    const delta = target - current;
    const easedDelta = delta * this.easing(progress);
    this.scroll += easedDelta;
    
    // 4. 更新 DOM（核心！）
    this.content.style.transform = `translateY(-${this.scroll}px)`;
    
    // 5. 触发 scroll 事件供外部监听
    this.emit('scroll', { scroll: this.scroll });
    
    // 6. 继续下一帧
    requestAnimationFrame((t) => this.raf(t));
  }
}

关键点：

使用 requestAnimationFrame 保证 60fps 流畅度
每帧计算缓动，逐渐接近目标位置
通过 transform 而非 scrollTop 移动内容（GPU 加速）

三、ScrollTrigger 与虚拟滚动的冲突

ScrollTrigger 的默认行为

// ScrollTrigger 默认监听 window.scroll 事件
window.addEventListener('scroll', () => {
  const scrollY = window.scrollY;  // 获取滚动位置
  
  // 检查每个 trigger 元素
  triggers.forEach(trigger => {
    const rect = trigger.element.getBoundingClientRect();
    if (rect.top < window.innerHeight) {
      trigger.activate();  // 触发动画
    }
  });
});

核心问题：Lenis 不触发 scroll 事件

// Lenis 的滚动是虚拟的：
content.style.transform = 'translateY(-1000px)';
//                        ↑
//                 DOM 没有真正滚动！

// 所以：
window.scrollY                  // 永远是 0 ❌
document.documentElement.scrollTop  // 永远是 0 ❌

// ScrollTrigger 完全检测不到滚动！

这就是为什么简单地结合 Lenis 和 ScrollTrigger 会失败的原因。

四、scrollerProxy：桥接两个世界

为什么需要 scrollerProxy？

scrollerProxy 是 GSAP 提供的 API，用于告诉 ScrollTrigger：

如何获取自定义滚动容器的滚动位置
如何设置滚动位置
容器的边界信息

完整配置示例

ScrollTrigger.scrollerProxy(".smooth-wrapper", {
  // 1. 滚动位置的获取/设置
  scrollTop(value) {
    if (arguments.length) {
      // ScrollTrigger 想设置滚动位置
      lenis.scrollTo(value, { immediate: true });
    }
    // ScrollTrigger 想获取滚动位置
    return lenis.scroll;  // 返回 Lenis 的虚拟滚动位置
  },
  
  // 2. 容器边界信息
  getBoundingClientRect() {
    return {
      top: 0,
      left: 0,
      width: window.innerWidth,
      height: window.innerHeight,  // 视口高度
    };
  },
  
  // 3. 定位模式
  pinType: wrapper.style.transform ? "transform" : "fixed",
});

深度解析每个方法

`scrollTop(value)`：双向桥接

scrollTop(value) {
  if (arguments.length) {
    // 有参数 = ScrollTrigger 想设置滚动位置
    lenis.scrollTo(value, { immediate: true });
    //                      ↑
    //         立即跳转，不要动画
    //        （ScrollTrigger 自己控制动画）
  }
  // 无参数 = ScrollTrigger 想获取当前位置
  return lenis.scroll;  // 返回虚拟滚动位置
}

// ScrollTrigger 内部会频繁调用：
const pos = scroller.scrollTop();  // 获取位置
scroller.scrollTop(1000);          // 设置位置（用于 pin 等功能）

`getBoundingClientRect()`：定义视口

getBoundingClientRect() {
  // ScrollTrigger 需要知道"视口"的位置和尺寸
  return {
    top: 0,        // 容器顶部 = 视口顶部
    left: 0,
    width: window.innerWidth,
    height: window.innerHeight,  // 容器高度 = 视口高度
  };
}

// ScrollTrigger 用它来计算：
// "trigger 元素距离容器顶部的距离"
// "start/end 位置的具体像素值"

为什么是固定值？ 因为 .smooth-wrapper 总是填满整个视口，所以边界就是窗口边界。

`pinType`：固定元素的定位方式

pinType: wrapper.style.transform ? "transform" : "fixed"

// 用于 ScrollTrigger 的 pin 功能
// 如果容器使用了 transform，固定元素也要用 transform
// 否则用 CSS fixed 定位

同步更新机制

// Lenis 每帧更新时，通知 ScrollTrigger
lenis.on("scroll", ({ scroll, limit }) => {
  ScrollTrigger.update();  // 强制 ScrollTrigger 重新计算所有触发器
});

// ScrollTrigger.update() 内部做什么？
// 1. 调用 scrollerProxy.scrollTop() 获取最新滚动位置
// 2. 重新计算所有 trigger 的状态（是否进入触发区）
// 3. 激活应该播放的动画

完整的同步代码：

// 在 GSAP ticker 中运行 Lenis
gsap.ticker.add((time) => {
  lenis.raf(time * 1000);  // time 是秒，Lenis 需要毫秒
});

// 禁用 lag smoothing，避免帧率波动时的卡顿
gsap.ticker.lagSmoothing(0);

// 当 ScrollTrigger 刷新时，也刷新 Lenis
ScrollTrigger.addEventListener("refresh", () => lenis.resize());

五、实战：博客列表滚动动画

完整配置代码

// 初始化动画
function initScrollAnimations() {
  const blogItems = document.querySelectorAll(".blog-item");
  const scroller = document.querySelector(".smooth-wrapper");

  blogItems.forEach((item, index) => {
    // 设置初始状态
    gsap.set(item, {
      y: 100,       // 向下偏移 100px
      opacity: 0,   // 完全透明
    });

    // 创建滚动触发动画
    gsap.to(item, {
      y: 0,           // 移动到原位
      opacity: 1,     // 完全不透明
      duration: 1.2,  // 动画持续 1.2 秒
      ease: "power3.out",  // 缓动函数
      scrollTrigger: {
        trigger: item,                 // 触发元素
        scroller: ".smooth-wrapper",   // 自定义滚动容器
        start: "top bottom-=100",      // 开始位置
        end: "top center",             // 结束位置
        toggleActions: "play none none none",
        markers: true,                 // 调试标记
      },
    });
  });

  ScrollTrigger.refresh();
}

参数详解

`trigger: item`

视口 (viewport)
┌─────────────────┐
│                 │
│                 │  ← item 的位置
└─────────────────┘
       ↑
  监听这个元素相对于视口的位置

`scroller: ".smooth-wrapper"`

// 告诉 ScrollTrigger：
// "不要监听 window，监听 .smooth-wrapper"

// ScrollTrigger 会：
// 1. 查找之前定义的 scrollerProxy(".smooth-wrapper")
// 2. 使用 proxy 的 scrollTop() 获取滚动位置
// 3. 使用 proxy 的 getBoundingClientRect() 计算边界

`start: "top bottom-=100"`

语法: "[trigger位置] [scroller位置]"

"top bottom-=100" 含义：
┌──────────────────┐ ← scroller top
│                  │
│   viewport       │
│                  │
│                  │
├──────────────────┤ ← scroller bottom
│      ↑           │
│    100px         │
├──────────────────┤ ← bottom-100 (触发线)
│      ↑           │
│  当 trigger.top 到达这里时开始动画
│                  │
└──────────────────┘

// 效果：元素还没完全进入视口时，就提前开始动画

`end: "top center"`

"top center" 含义：
┌──────────────────┐ ← scroller top
│                  │
├──────────────────┤ ← scroller center (50% 高度)
│      ↑           │
│  trigger.top 到达这里时动画结束
│                  │
└──────────────────┘ ← scroller bottom

// 动画从 start 到 end 之间的滚动距离内完成

`toggleActions: "play none none none"`

toggleActions: "onEnter onLeave onEnterBack onLeaveBack"
//              ↓       ↓        ↓           ↓
//           向下滚   向下滚    向上滚      向上滚
//           进入     离开      再次进入    再次离开

"play none none none" 含义：
- 向下滚动进入触发区：play（播放动画）
- 向下滚动离开触发区：none（保持状态）
- 向上滚动回到触发区：none（保持状态）
- 向上滚动离开触发区：none（保持状态）

// 效果：只在第一次进入时播放一次，之后保持结束状态

// 其他常用配置：
// "play reverse play reverse"  - 完全可逆的动画
// "play pause resume reset"    - 离开时暂停，回来时继续

六、完整的事件流程图

用户滚动鼠标滚轮
    ↓
Lenis 监听 wheel 事件
    ↓
Lenis 计算目标滚动位置
    ↓
Lenis RAF 循环（每帧）
    ↓
应用缓动，更新 lenis.scroll
    ↓
更新 content.style.transform = `translateY(-${scroll}px)`
    ↓
触发 lenis.on('scroll') 事件
    ↓
调用 ScrollTrigger.update()
    ↓
ScrollTrigger 调用 scrollerProxy.scrollTop()
    ↓
ScrollTrigger 获取最新虚拟滚动位置
    ↓
ScrollTrigger 遍历检查所有 trigger
    ↓
计算 trigger 元素的 getBoundingClientRect()
    ↓
判断是否进入触发区域
    ↓
触发区域内的动画开始播放
    ↓
GSAP 更新元素的 transform/opacity 等属性
    ↓
浏览器重绘（GPU 加速）
    ↓
用户看到流畅的滚动动画

七、常见问题与调试技巧

问题 1：动画完全不触发

症状： 滚动页面，元素没有任何动画效果。

排查步骤：

// 1. 检查 scrollerProxy 是否配置
console.log(ScrollTrigger.getScrollFunc(".smooth-wrapper"));
// 应该返回一个函数，如果是 null，说明 proxy 未配置

// 2. 检查 Lenis 是否正常工作
lenis.on('scroll', (e) => {
  console.log('Lenis scroll:', e.scroll);  // 应该看到滚动值变化
});

// 3. 检查 ScrollTrigger 是否收到更新
lenis.on('scroll', () => {
  console.log('Updating ScrollTrigger');
  ScrollTrigger.update();  // 确认这行有执行
});

// 4. 检查 scroller 参数
gsap.to(".item", {
  scrollTrigger: {
    scroller: ".smooth-wrapper",  // 必须匹配 scrollerProxy 的选择器
  }
});

问题 2：markers 位置不正确

症状： 开启 markers: true 后，绿色/红色标记线位置异常。

原因： getBoundingClientRect() 返回值不正确。

解决：

getBoundingClientRect() {
  return {
    top: 0,                    // 必须是 0
    left: 0,                   // 必须是 0
    width: window.innerWidth,  // 视口宽度
    height: window.innerHeight, // 视口高度（不是 wrapper.offsetHeight！）
  };
}

问题 3：滚动不流畅或卡顿

可能原因：

RAF 同步问题

// 确保 Lenis 在 GSAP ticker 中运行
gsap.ticker.add((time) => {
  lenis.raf(time * 1000);  // 注意：time 是秒，需要转换为毫秒
});

// 禁用 lag smoothing
gsap.ticker.lagSmoothing(0);

动画性能问题

// ❌ 不好：使用 width/height/top/left（触发 layout）
gsap.to(element, { width: 500, height: 300 });

// ✅ 好：只使用 transform 和 opacity（GPU 加速）
gsap.to(element, { 
  x: 100,       // transform: translateX
  y: 50,        // transform: translateY
  scale: 1.2,   // transform: scale
  opacity: 0.5  // opacity
});

过多的 ScrollTrigger 实例

// ❌ 不好：为每个元素创建独立的 ScrollTrigger
items.forEach(item => {
  gsap.to(item, {
    scrollTrigger: { trigger: item }
  });
});

// ✅ 更好：批量处理
gsap.to(".item", {
  y: 0,
  stagger: 0.1,  // 交错动画
  scrollTrigger: {
    trigger: ".container",  // 统一触发区域
  }
});

调试工具箱

// 查看所有 ScrollTrigger 实例
ScrollTrigger.getAll().forEach((st, i) => {
  console.log(`Trigger ${i}:`, {
    trigger: st.trigger,
    start: st.start,
    end: st.end,
    scroller: st.scroller,
    progress: st.progress,  // 当前进度 0-1
  });
});

// 手动刷新所有 ScrollTrigger
ScrollTrigger.refresh();

// 查看当前滚动位置对比
console.log({
  lenis: lenis.scroll,        // Lenis 虚拟滚动位置
  window: window.scrollY,     // 应该是 0
  proxy: ScrollTrigger.getScrollFunc(".smooth-wrapper")(),  // 应该等于 lenis.scroll
});

// 杀死所有 ScrollTrigger（重新初始化时）
ScrollTrigger.getAll().forEach(st => st.kill());

八、性能优化建议

1. 使用 will-change 提示浏览器

.blog-item {
  /* 提前告诉浏览器这些属性会变化 */
  will-change: transform, opacity;
}

/* 但不要滥用！只在必要时使用 */
/* 过多的 will-change 会消耗内存 */

2. 批量处理元素

// ✅ 推荐：使用 stagger 批量动画
gsap.to(".blog-item", {
  y: 0,
  opacity: 1,
  stagger: {
    each: 0.1,        // 每个元素间隔 0.1 秒
    from: "start",    // 从第一个开始
  },
  scrollTrigger: {
    trigger: ".blog-list",
    start: "top bottom",
  }
});

3. 防抖/节流滚动事件

// 如果你需要在滚动时执行自定义逻辑
let rafId;
lenis.on('scroll', (e) => {
  // 使用 RAF 防抖
  if (rafId) return;
  rafId = requestAnimationFrame(() => {
    // 你的逻辑
    console.log('Scroll position:', e.scroll);
    rafId = null;
  });
});

4. 懒加载动画

// 只为视口附近的元素创建 ScrollTrigger
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      // 元素接近视口时才创建动画
      createScrollAnimation(entry.target);
      observer.unobserve(entry.target);
    }
  });
}, { rootMargin: "200px" });

document.querySelectorAll('.blog-item').forEach(item => {
  observer.observe(item);
});

九、总结

Lenis + GSAP ScrollTrigger 的组合强大之处在于：

Lenis 提供丝滑的虚拟滚动体验
ScrollTrigger 提供强大的滚动动画能力
scrollerProxy 桥接两者，让它们完美协作

关键要点：

理解虚拟滚动的本质：内容通过 transform 移动，而非真实滚动
scrollerProxy 是连接 Lenis 和 ScrollTrigger 的关键
性能优化：优先使用 transform 和 opacity，避免触发 layout
调试技巧：善用 markers、console.log 和 ScrollTrigger API

掌握这些原理后，你就可以打造出媲美 Apple、Awwwards 获奖网站的高品质滚动体验了！

参考资源

被 AI 逼疯的前端：从手搓流式打字机，到浏览器端跑 React

Thu, 08 Jan 2026 14:37:48 GMT

为了防止被认为是菜鸡, 所以先说一句, 第一关到第三关我还是会的 😭 面试官不要再学历挂我了好吗

前言：上周一，产品经理搬着椅子坐到了我旁边：“咱们的 AI 助手体验太‘古典’了，请求发出去要转圈五秒钟才吐字。你看人家 ChatGPT，那个字是一个个蹦出来的，多解压！还有，能不能让 AI 给我写个 React 组件，直接渲染出来让我点？就像那个 Gemini Canvas 或者 Vercel v0 一样？”

我看着手里还在用 await fetch().json() 的代码，陷入了沉思。这不是加个 CSS 动画能解决的事，这是一场从网络层到渲染层的全面重构。

这几天，我像是经历了一场前端技术的“大航海”，踩了无数坑，终于把这套 流式渲染（Streaming Rendering） 架构跑通了。这篇文章就是我的“航海日志”，希望能帮同样在做 AI 应用的兄弟们少掉几根头发。

第一关：放弃 `setInterval` —— 真正的流式传输

刚接手时，由于思维还停留在传统的 CRUD 模式，我天真地想：后端能不能先把生成好的文案发给我，我自己在前端搞个 setInterval，每 50ms 往 div 里追加一个字？

被打脸的瞬间：这种“伪流式”根本解决不了核心痛点——首字节延迟（TTFB）。如果是复杂的推理任务，后端生成完整回复可能需要 15 秒。难道让用户盯着空白屏幕转圈看 15 秒？AI 时代，“快”不代表总时长短，而代表“响应开始得早”。

所以，必须上 Server-Sent Events (SSE) 或者 HTTP Chunked Transfer。

1.1 `fetch` 的另一面

我开始深入研究 fetch API。以前我们只用 response.json()，但面对流，我们要用 response.body.getReader()。

这扇新世界的大门打开后，全是坑：

// ❌ 错误示范：以为拿到的是字符串
const reader = response.body.getReader();
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  console.log(value); // 打印出来全是 Uint8Array [233, 189, 128...] ???
}

1.2 致命的 Unicode 截断

拿到的 value 是 Uint8Array 二进制流。必须引入 TextDecoder 来翻译。

这里藏着一个巨大的隐患：中文和 Emoji 是多字节的。

一个汉字（如“好”）占 3 个字节。网络传输时，TCP 包可能会把这 3 个字节切开：前一个 Chunk 包含前 2 个字节，后一个 Chunk 包含第 3 个字节。

如果你直接 decode 前一个 Chunk，会得到一个乱码符号 “。

✅ 正确姿势：

必须配置 { stream: true }，告诉 Decoder 内部维护一个 buffer，如果字节没凑齐一个字，就先攒着不吐出来。

JavaScript

const decoder = new TextDecoder('utf-8');
// 必须处理流式解码，防止汉字被截断导致乱码
const chunk = decoder.decode(value, { stream: true });

第二关：页面在跳舞？—— Markdown 渲染的“防抖”算法

流接通了，字也能吐出来的。我兴冲冲地把这段实时变长的文本丢进 react-markdown 里，结果迎来了第二个噩梦：Layout Shift（视觉抖动）。

2.1 灾难现场还原

当 AI 试图写一段代码时，它是这样吐字的：

收到 `👉 页面渲染为普通文本。
收到 “ 👉 解析器认为这是 行内代码 (Inline Code)，瞬间把这行字变成了灰色背景的小方块，字体变小，行高变矮。
收到 “ ` 👉 砰！解析器判定这是 代码块 (Code Block) 的开始，页面瞬间撑开一个占据整行宽度的黑色大框，把下面的内容全部顶飞。

在这个毫秒级的过程中，页面像是在蹦迪，忽大忽小，用户体验极差。

2.2 主动干预算法：看不清，就别画

查了一圈资料，没找到现成的库能完美解决这个问题。于是我写了一个预处理函数（Middleware），核心逻辑只有一句话：“看不清，就别画”。

我们需要在数据交给 Markdown 组件之前，先进行清洗。

核心代码逻辑：

TypeScript

function smoothMarkdown(content: string) {
  // 1. 防抖策略：如果末尾悬挂 1 个或 2 个反引号，先暂时切掉不渲染
  // 只有当攒够 3 个变成了 ```，或者是 `text` 这种明确格式时才放行
  if (content.endsWith('``')) {
    return content.slice(0, -2); // 🔪 切掉，等下一个包
  } else if (content.endsWith('`')) {
    return content.slice(0, -1); // 🔪 切掉
  }
  
  // 2. 自动闭合：防止代码块渲染了一半样式崩坏
  const codeBlockCount = (content.match(/```/g) || []).length;
  if (codeBlockCount % 2 !== 0) {
    return content + '\n```'; // 🧱 帮它补全
  }
  
  return content;
}

加上这段只有几行的代码后，那个“闪烁的灰色小方块”彻底消失了。用户看到的是：文本 -> 文本 -> 稳稳出现的黑色代码框。丝滑！

第三关：不仅是聊天 —— 复杂数据的 NDJSON 救赎

需求升级了。产品经理不满足于纯文本，想让 AI 在聊天中直接丢出一个实时的“销售报表”或者“用户信息卡片”。

3.1 `JSON.parse` 的死穴

纯文本流我搞定了，但结构化数据怎么办？

如果我让 AI 返回一个巨大的 JSON，万一它生成到一半卡住了，前端拿到的就是个残缺的字符串 {“user”: “Ale…。

这时候 JSON.parse 是极其严格的，会直接报错抛出异常。我们总不能等整个 JSON 传完了再渲染吧？那流式就没意义了。

3.2 救星：NDJSON (Newline Delimited JSON)

我引入了一个后端架构模式：Single Request, Multiple Updates。

简单说，就是让后端别一次性把所有数据给我，而是像发弹幕一样，把一个大任务拆成多个小事件，用换行符分隔：

JSON

{"type": "init", "status": "thinking"} \n
{"type": "user_info", "data": {"name": "Alex", "role": "admin"}} \n
{"type": "chart_data", "data": {"q1": 100}, "isPartial": true} \n

3.3 前端 Buffer 池设计

在前端，我不能简单地 split(‘\n’)，因为网络包的边界可能刚好切在一行 JSON 的中间。

我必须设计一个 Buffer 缓冲池：

JavaScript

let buffer = '';
while (true) {
  const { value } = await reader.read();
  buffer += decoder.decode(value, { stream: true });
  
  // 关键：按换行符切割，但要保留最后一个可能不完整的片段
  const lines = buffer.split('\n');
  buffer = lines.pop(); // 把最后那半句塞回 buffer，等下一次拼接
  
  for (const line of lines) {
    if (line.trim()) {
      dispatch(JSON.parse(line)); // 放心 Parse，这一行肯定是完整的
    }
  }
}

这种感觉就像是在拼图，后端不断递给我碎片，我实时把它们拼到 Redux/Context 的状态树上。页面不再是尴尬的“Loading”，而是生动的**“Growing”**。

第四关：魔法时刻 —— 浏览器端编译 (Runtime Bundling)

这是最让我头秃，也最让我兴奋的一关。

产品经理指着 Vercel v0 说：“你看人家，生成的 React 代码直接就跑起来了，还能点，还能交互。咱们能不能也搞一个？”

灵魂发问：

AI 返回的是字符串啊！浏览器只能跑 JS，怎么跑 JSX？而且 React 组件通常还要 import { Button } from ‘antd’，浏览器去哪找 node_modules？

4.1 玩具版：Iframe + Babel Standalone

一开始，我试着在 Iframe 里硬塞了一个 babel.min.js。

原理：利用 Babel 在浏览器端实时把 JSX 编译成 React.createElement。
结果：简单的 <div>Hello</div> 能跑。但一旦 AI 写了 import，控制台直接炸了：Uncaught ReferenceError: require is not defined。

我意识到，我缺的不是编译器，而是一个打包器 (Bundler)。

4.2 工业版：拥抱 Sandpack (Web Worker Bundler)

深挖之后，我发现了 Vercel v0 背后的神级技术栈：Sandpack（源自 CodeSandbox）。

它的原理极其硬核：它在浏览器里起了一个 Web Worker，在这个 Worker 里运行了一个微型的 Webpack。

它是怎么工作的？

拦截 Import：当代码里出现 import { BarChart } from 'recharts'。
动态拉包：Worker 拦截请求，去专门的 CDN (如 esm.sh) 拉取 recharts 的元数据和代码。
内存构建：它在内存里建立虚拟文件系统，把这些包和 AI 生成的代码打包在一起。
安全执行：最后把打包好的 JS 丢给 Iframe 执行。

我的集成代码：

JavaScript

import { Sandpack } from "@codesandbox/sandpack-react";

// AI 生成的代码流直接喂给 files
<Sandpack 
  template="react"
  files={{
    "/App.js": aiGeneratedCode, // 👈 就算是流式传输的残缺代码，它也能容错
  }}
  customSetup={{
    dependencies: {
      "recharts": "latest", // 👈 预置好依赖，AI 随便调
      "lucide-react": "latest"
    }
  }}
/>

那一刻，屏幕上那个柱状图随着 AI 的打字机效果一点点画出来，还能跟随鼠标交互时，我感觉自己不再只是一个写页面的前端，而是在构建一个**“容器”**。

总结：从“切图仔”到“容器架构师”

回顾这几天的折腾，从一开始的懵懂无知到现在的豁然开朗，我发现 AI 时代的前端开发逻辑变了：

以前：我们追求静态的完美（Pixel Perfect），所有的状态、文案、组件都是预设好的。
现在：我们追求动态的流畅（Streaming Perfection）。我们要处理的不仅是数据流，还有视觉流、代码流。
以前：我们写代码给浏览器跑，我们是代码的创造者。
现在：我们写环境让 AI 的代码跑，我们成了代码的“监护人”和“架构师”。

这条路还在继续，但我已经不再迷茫了。下一个挑战：如何在浏览器里跑 Python 进行数据分析？WebAssembly，我来了！

拒绝临时性-生活AI版

Sun, 28 Dec 2025 05:46:45 GMT

你说说你说说, AI 咋就这么会写呢

什么是「临时性生活」

人一旦习惯用“临时”来定义当下，就很容易在不知不觉中，把整个人生过成一段无限期的过渡期。

我们太熟悉这种话术了——
“等我熬过这段时间就好了。”
“等条件再好一点再说。”
“现在没必要讲究。”

刘震云说过一句话，大意是：

骗子最常用的伎俩，就是编造辉煌的过去，许诺精彩的未来，然后让你牺牲现在。

后来我意识到，“临时生活”其实也是同一种结构。
只是这一次，骗子不是别人，而是我们自己。

所谓临时性生活，并不是生活真的短暂，而是一个人把现实当成过渡，把希望全部押在未来，从而不断合理化对当下的敷衍与忍耐。

临时生活最常见的样子

它通常发生在某段“正在路上”的时期：
实习、备考、刚到一座新城市、刚换工作。

你住在一个不太理想的房间里，也知道这只是暂时的。于是，面对每天的生活，你会在下面两种选择中，几乎下意识地走向其中一种。

A：典型的「临时生活」心态

你心里很清楚地告诉自己：
“这只是个睡觉的地方，反正很快就要走了。”

桌子乱了，你也懒得收拾。衣服随手丢在椅子上，只要还能坐就行。
外卖到了，你直接在塑料盒里吃，甚至不拿出来，免得弄脏桌面。
吃饭的时候刷着短视频，眼睛在看，脑子却是空的。你说这是放松，但心里始终悬着明天的事。

你真正的潜台词是：
“我真正的人生，还没开始。”

现在的一切，不过是用来熬过去的。

B：拒绝「临时感」的心态

你同样知道这房子是租的，是过渡的。
但你也清楚一件事：你正在这里度过的每一分钟，都不会重来。

于是你花了十分钟，把桌面整理了一下。
衣服挂好，空瓶子丢掉，铺上一块干净的桌布，或者打开一盏暖光的台灯。

外卖到了，你把它倒进常用的碗里，给自己倒一杯水。
哪怕只有你一个人，你也坐直了身体，认真吃完这一顿。

吃饭的时候你不刷手机，放一首熟悉的歌，或者看一部一直想看的电影。
饭后你会感觉到一种真实的“休息感”，而不是空虚后的疲惫。

你心里想的是：
“哪怕明天就要离开，今晚我也要把自己照顾好。”

我不把生活的尊严，寄托在未来。

临时性生活的本质

临时性生活，本质上是一种逃避。

它让人沉迷于一个想象中的未来：
等考完这场试、等工作稳定、等条件成熟，生活就会自动进入一个更好的阶段。

但问题在于——
生活并不会“突然开始”。

核心误区：等待开始的幻觉

临时生活最致命的地方，在于它制造了一种错觉：

只要我熬过这一段，生活自然会变好。

可现实是，未来并不会奖励一个长期习惯敷衍的人。
如果你现在习惯凑合、忍耐、将就，那么这种惯性，大概率会被你一并带进所谓的“好日子”。

更隐蔽的危险：披着努力外衣的逃避

临时生活之所以危险，是因为它看起来很正当。

表面上，你在忍耐、在奋斗、在为未来做准备。
但实际上，你在一点点切断自己与当下生活的联系。

你不愿意经营居住环境，因为“反正要走”。
你不愿意投入关系，因为“迟早会分开”。
生活被压缩成最低配版本，只剩下生存功能。

你不是没有付出，而是把一切情感、秩序和尊严，都延迟到了未来。

最昂贵的代价：能力的退化

真正不可逆的损失，往往发生在你毫无察觉的时候。

当你长期练习忍耐和敷衍，你会慢慢失去一些能力：
感受快乐的能力，
专注当下的能力，
以及掌控生活的信心。

等你终于走到那个期盼已久的“稳定阶段”，
你可能已经不知道，怎样好好生活了。

破局之道：从「将来再说」到「现在开始」

拒绝临时生活，并不是放弃奋斗，也不是假装一切都很完美。

它只要求一件事：
在不完美的条件下，依然认真对待正在发生的生活。

不是等有空了再照顾身体，而是在忙碌中也不彻底透支自己。
不是等稳定了再生活，而是在动荡中，依然保持基本的体面和秩序。

未来不会凭空降临。
它只是由无数个被认真对待的今天，一点点累积而成。

每日自检

每天结束时，可以问自己三个简单的问题：

我今天有没有心不在焉地活着？
我有没有为了所谓的“将来”，而敷衍了今天？
有哪些事情，其实今天就可以开始？

这不是为了苛责自己。
只是为了确认——
今天，我有没有再把人生往后推一天。

不必追求立刻改变。
但每一次不再“临时”的选择，都会在你身上留下痕迹。

拒绝临时性-生活

Sun, 28 Dec 2025 05:09:36 GMT

什么是临时性生活?

所谓“临时性生活”，并不是生活真的短暂，而是一个人用“将来会更好”作为借口，系统性地放弃对当下生活的经营与尊重。

人一旦习惯用 “临时”来定义当下, 就会在不知不觉中将整个人生过成一段无限期的过渡期 全天下的骗子只有一个伎俩，那就是编造辉煌的历史，并许诺你精彩的未来，然后，要你牺牲你的现在。我被这种伎俩骗的太久了，于是习惯的用“临时”来定义当下。很多事情本来可以立马开始的，但就是说不清道不明的，要等条件好一点再开始。 ¹ From Zhihu

临时性生活最常见的几种形态是:

只要我度过这段时间, 生活就会一个崭新的阶段, 而我可以在新的阶段开始一个美好的生活
你正在一段过渡期 (实习, 准备考研, 刚到新城市), 你租了一个并不算太好的小单间, 或者住在拥挤的宿舍中, 接下来的选择中你更倾向于选择 A/B？
1. A:典型的“临时生活”心态
  1. 你心里想：“这只是个睡觉的地方，反正过几个月我就搬走了/考上就解脱了，没必要折腾。”
  2. 关于环境：你把椅子上的衣服随手推到床上，腾出一个坐的地方。你不打算收拾桌子，觉得“反正还会乱，等我有空了/搬家了再好好布置”。
  3. 关于晚餐：你没有把外卖倒进碗里，而是直接打开塑料盖子，甚至都不把外卖拿出来，就在塑料袋里吃（怕漏油弄脏桌子）。
  4. 关于时间：你一边吃，一边机械地刷着短视频，或者看着并不感兴趣的剧。你告诉自己这是在“放松”，但其实心里很空虚，还在焦虑明天的计划。
  5. 内心潜台词： “现在的日子就是为了熬过去的。等我以后有钱了/成功了，我要住在宽敞的房子里，每天做精致的饭菜，好好享受生活。”
2. B：拒绝“临时感”的心态
  1. 你心里想：“虽然这房子是租的/临时的，但我在这里度过的每一分钟，都是我生命的一部分。”
  2. 关于环境： 你花 10分钟 快速整理了一下桌面，扔掉空水瓶，把衣服挂起来。你可能还在桌上铺了一块便宜但干净的桌布，或者开了一盏暖色调的台灯。
  3. 关于晚餐： 你把外卖倒进自己喜欢的陶瓷碗里，倒了一杯水。即使是一个人的晚餐，你也坐直了身体，认真地去品尝食物的味道，而不是囫囵吞枣。
  4. 关于时间： 吃饭时你没有刷手机，而是放了一首喜欢的歌，或者看了一部一直想看的好电影。吃完饭，你感到一种真实的“休息感”和“回血感”。
  5. 内心潜台词： “哪怕明天就要搬走，今晚我也要让自己过得舒服、体面。我不把生活的尊严寄托在未来，我要在现在的限制里，过得尽量好。”

临时性生活就是, 幻想一个美好的未来, 并在一条名为未来的岔道上一路狂奔, 缺忽略了名为当下的正道。

当然也有很多别的词语、词汇来概括: 实事求是, 活在当下, 第一性原理。

临时性生活的坏处

核心误区 : “等待开始”幻觉

心态: 只要我熬过这一段时间（考完这场, 找到新工作,）, 美好的生活就会自动降临
现实: 生活不会因为你达到某个阶段就突然变好, 如果我习惯了凑合和敷衍, 这种惯性会延续到我所谓的未来当中。

隐蔽的危险: 披着努力的外衣

过去我常常认为自己的努力的, 直到今天我才发现做的是无用功。

这种心态最可怕的地方在于它 具有欺骗性

表面上： 你看起来很努力，在为了未来忍耐、奋斗。
实际上： 你切断了与当下的联系。你不愿意经营生活环境（比如租房就不布置），不愿意建立深度关系（比如觉得迟早要分开）。
后果： 生活只剩下吃饭、睡觉、打卡和熬时间，而不再让人感到被滋养。

不可逆的代价：能力的丧失

文章提出了一个非常痛点的警示：有些东西是无法在未来补回来的。

消耗品： 健康、专注力、热情、好奇心。
能力的退化： 如果你长期练习“敷衍”和“忍耐”，你会逐渐丧失“感知快乐”和“掌控生活”的能力。当你终于等到了所谓的“好日子”，你可能已经失去了享受它的心境和能力。

破局之道：把“将来再说”变成“现在开始”

文章给出的解决方案不是让你放弃奋斗，而是改变对待当下的态度。

承认现实： 外部环境永远不会完美（永远有压力和风险）。成熟是学会在不完美中建立秩序。
具体行动：
- 不是等有空了再健身，而是忙碌中也要照顾身体。
- 不是等稳定了再生活，而是即使在动荡中，也要保持内心的体面和自尊。
核心逻辑： 未来的美好生活，是由无数个“被认真对待的今天”累积而成的，而不是某一天突然掉下来的奖赏。

每日自检清单

每天结束时, 问自己三个问题（问 AI 告诉他你今天做了什么）:

我今天有三心二意吗？心猿意马
我今天有没有为了所谓的 “未来” 而敷衍/牺牲现在?
有哪些我今天就可以做但没有做的事？

不必奢求短期的骤然改变, 而是坚持长期主义, 不必因为忘记一两次而烦恼, 但要为每次坚持的自己鼓掌。

刘震云说：骗子再高明，其实用的都只有一个伎俩，那就是：编造辉煌的过去，并许诺你精彩的未来，然后，蛊惑你牺牲现在的所有_生活_虚幻_宜善 ↩

Tmux速记

Sun, 21 Sep 2025 14:25:17 GMT

提升命令行使用体验──tmux 终端复用 - LUG @ USTC

Tmux 使用教程 - 阮一峰的网络日志

App+1 | AeroSpace：消除窗口重叠，世界属于平铺 - 少数派

NOTE

+ Tmux 是什么? Tmux 是一个可以保存终端状态和记录的终端复用器 (Terminal MultipleXer). 可以保存一个终端并在以后重新连接并且显示之前的输出. 并且可以在同一个终端内创建多个窗口 (分屏) ,每个窗口都运行独立的 Shell 进程.

Tmux 的原理: 将终端(Terminal)和会话(Sesstion)进行了分离, 用户可以随时退出(detach)当前会话, 会话会在后台保持运行, 之后用户可以通过 (attach) 重新连接上会话.

常用命令

Tmux 有两种操作方式, 一种是通过键盘触发键 ctrl+b 一种是直接在终端输入 tmux 命令.

新建会话: tmux new -s <sesstion-name> 默认窗口编号是 0, 之后是 1 以此类推
分离会话: tmux detach 将当前会话和终端窗口分离 ctrl + b d
显示会话列表: tmux ls or tmux list-session ctrl + b s
接入会话: tmux attach -t <session-name> or <number> 输入名称或编号
杀死会话: tmux kill-session 参数和上面相同
切换会话: tmux switch 相同
重命名会话: tmux-rename-session -t 0 <new-name> ctrl+b $

窗格操作

Tmux 可以将一个终端窗口(Window)分成多个窗格 (Pane), 每个窗格运行着不同的 Session 实例.

划分窗格: tmux split-window <option> 将窗口划分为上下两个窗格若带上 -h 则划分为左右两个 ctrl+b % 左右划分, ctrl+b " 上下划分
修改聚焦的窗格 (移动光标所在窗格): tmux select-pane -LRDU 将光标移动到 左右下上 窗格 (基于当前位置)
交换窗格位置: tmux swap-pane -LRDU 将当前窗格移动到 左右上下 窗格
- Ctrl+b <arrow key> 光标切换到其他窗格
Ctrl+b ;：光标切换到上一个窗格。
Ctrl+b o：光标切换到下一个窗格。
Ctrl+b {：当前窗格与上一个窗格交换位置。
Ctrl+b }：当前窗格与下一个窗格交换位置。
Ctrl+b Ctrl+o：所有窗格向前移动一个位置，第一个窗格变成最后一个窗格。
Ctrl+b Alt+o：所有窗格向后移动一个位置，最后一个窗格变成第一个窗格。
Ctrl+b x：关闭当前窗格。
Ctrl+b !：将当前窗格拆分为一个独立窗口。
Ctrl+b z：当前窗格全屏显示，再使用一次会变回原来大小。
Ctrl+b Ctrl+<arrow key>：按箭头方向调整窗格大小。
Ctrl+b q：显示窗格编号。

面试题

Tue, 16 Sep 2025 07:41:21 GMT

1.具体在做小程序的什么？（我在实习中提到【公告通知】这个功能）
2.微信订阅消息推送的链路，用户怎么收到推送的？想了解用到什么协议
3.get 和 post 怎么理解？
4.get 和 post 在网络传输链路上有什么区别？
5.小程序上也有 url 的长度限制吗？（上个问题我说到了 get 的 url 长度限制）这个限制是谁做的？
6.简单请求和飞简单请求？
7.自定义请求头是指什么？（上个问题我提到复杂请求可能是包含自定义请求头）
8.get 幂等，post 非幂等，主要什么原因导致的这种区别？
9.URI 是指？（我提到 uri，面试官说没有太理解到 uri 的概念）所有请求都一定是返回 uri 吗？
10.get 请求的默认缓存能力？
11.浏览器缓存有磁盘缓存和内存缓存，这个了解吗？浏览器怎么控制这两个缓存空间？两个的主要作用？
12.强缓存和协商缓存什么时候走内存/磁盘缓存？
13.settimeout 时间不准确的问题？
14.setTimeout 与浏览器渲染帧率的关系？
15.requestAnimationFrame 怎么解决 settimeout 时间不准确的问题？
16.async/await 和 promise 怎么解决回掉地狱？两者有什么区别？
17.两个数组相加在浏览器中执行结果：[1, 2, 3] + [4, 5, 6]？
18.解构赋值通过什么触发的？解构赋值是什么?（这个问题是因为我上个问题做错了，我以为两个数组相加就直接是对应索引值相加，解释时提到【解构赋值】，所以面试官才问的）
19.用 var 实现 const，写伪代码即可
20.实现 promise.all

作者：拜托 offer 吻上来
链接：https://www.nowcoder.com/feed/main/detail/82f6c6b453994a2fa6ed9827d316f936?sourceSSR=search
来源：牛客网

小鹏前端一面

1.浏览器渲染？
2.reflow，repaint
3.CSS 选择器优先级如何计算？
4.什么是 BFC？如何触发？
5.什么是 DOCTYPE？
6.盒模型有哪两种？区别是什么？
7.原型和原型链？
8.js 事件传播机制
9.防抖和节流的区别？各用在什么场景？
10.Promise ？如何链式调用？
11.async/await 的本质？
12.常见的 HTTP 状态码有哪些？
13.GET 和 POST ？
14.浏览器缓存有哪几种？如何设置？
15.Vue 双向绑定的原理是什么？
16.Vue 组件通信有哪些方式？
17.虚拟 DOM 和真实 DOM？
18.Vue 路由的模式及区别？
19.前端性能优化从哪些方面入手？
20.模块化规范有哪些？CommonJS 和 ES6 Module 区别？
21.TypeScript 相比 JS 的优势？
22.interface 和 type
23.如何检测前端内存泄漏？
24.如何调试前端代码？有哪些工具？
还有些项目内容#我的秋招日记##听到哪句话代表面试稳

作者：SssRi
链接：https://www.nowcoder.com/?
来源：牛客网

影石前端一面(已过)

八股

html 渲染，遇到 script 标签会怎样
async 和 defer 有啥区别，怎么执行的
http 缓存(强缓存，协商缓存)

4.跨域

5.跨域的表现是什么样的，发出去无响应/压根没发?

6.请求发出去以后，根据啥判断是否跨域?

option 请求

8.介绍一些 es6 和更新的 API

9.箭头函数和 function 区别

事件循环

11.怎么利用事件循环机制，优化大量计算导致的页面卡顿问题

12.了解 requestAnimationFrame 吗，他在事件循环中的位置是啥

13.怎么理解 react 中的 hooks，为啥不用类组件，好在哪

14.自己有封装自定义的 hook 吗?为啥不用普通的方法函数

15.有了解 ahooks 库里的 useAsync 吗，啥原理

AI 的数据流式返回是啥原理?(实习相关)
Zustand 和 Redux 是啥区别
setState 为啥不能立刻拿到更新后的值

场景

1.浏览器输入 url 之后，白屏时间过长，哪些环节可以优化

2.可以用缓存优化吗

3.如果分页的时候快速连续点了第二页和第三页，结果第二页的请求比第三页的返回更慢，出现问题，因为其实想看第三页。怎么解决这个问题

作者：Offer 心愿达成中
链接：https://www.nowcoder.com/?
来源：牛客网

字节前端一面（75 分钟）

自我介绍
介绍一下项目及基础架构
项目拷打（大约 20 分钟、围绕简历提问）
性能优化怎么做的（大约 20 分钟）

性能优化会从性能指标到阶段分析到优化细问

JSBridge 和客户端底层怎么进行通信的
Ts 的 keyof、tyoeof、泛型、装饰器；ts 在前端工程化有什么作用呢
JS 基础数据类型、通过哪些方法可以判断一个变量是数组类型？（问了 5 种方法）
做移动端的时候怎么保证视觉的还原度
如果视觉走查的某个视觉问题反复调整都无法完美还原怎么解决
AI 视觉稿转代码详细说说
为什么移动端上图片会展示模糊呢？
DRP 对图片渲染模糊有什么关联
移动端的动画选型和动画类型
有没有自己使用过 canvas 做一些绘制或动画渲染呢？
js 驱动的动画遇到卡顿怎么优化和处理呢
重绘重排在渲染层为什么会有不同的性能影响
React 的常用 hooks；
React 对比直接使用 js 有什么提升？
React18 之前的版本对比 React18 有什么不同
服务端渲染 ssr、rsc 与 csr 的对比；水合失败会怎样
http 0.9, http 1.0 ,http 1.1， http2，http3 的区别，队头阻塞在各个阶段的问题和解决方案
TCP vs UDP，介绍一下 TCP 的慢启动，强缓存+协商缓存
csrf xss
加密方式了解哪些，介绍一下对称加密，非对称加密
日常怎么使用 AI 的，在工作中有哪些提效
两道题

26.1. 手写数组的 flat 方法

26.2. 手写一个 PromiseAll，写完后顺便问了 Promise 的其他方法

整个过程都通过聊天去问一些问题，面试体验很棒，回答的还不错，百分之 95 都回答上来了，手写题也是秒了，结果还是挂了

作者：关关过的奋斗青春
链接：https://www.nowcoder.com/?type=818_1
来源：牛客网

Fiber

React 16 以前是同步任务, 不可中断, 导致更新容易卡死。

Fiber 架构是将一个庞大的更新任务, 拆分成 可中断, 异步, 可恢复的微小工作单元 (Fiber)

每完成一个单元就将控制权交还给浏览器, 检查是否有更高优先级的任务 (用户输入, 滚动, 其他地方的动画)

为了实现 可中断, React 将工作流拆分成了两个阶段

渲染/调和阶段
1. 可中断的异步 working in process tree
2. 计算出所有节点的变更
3. 可以暂停, 重做, 丢弃, 没有影响用户的副作用
提交阶段 (Commit Phase)
1. 不可中断的同步阶段

2026-07-15 11:21 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com "前端" "Agent" "面经"；site:nowcoder.com "前端" "Agent" "简历"；site:nowcoder.com "AI Agent" "前端" "面试"
新增面经：5 条；新增简历/岗位材料：3 条。
数据来源：https://www.nowcoder.com/feed/main/detail/0eb3f9b46a4843c086f6d575d20b15b4；https://www.nowcoder.com/feed/main/detail/0ee219e39f254208bef730ca1e928fcc；https://www.nowcoder.com/feed/main/detail/350d8666f74a4d5cb35c4f6abd07dfda；https://www.nowcoder.com/feed/main/detail/4e8cafa5d36c43f9b1c3a4e0c0e5cbc8；https://www.nowcoder.com/feed/main/detail/96cc5b7e2cb84f148eb48be23952f647；https://www.nowcoder.com/discuss/879078076276105216；https://www.nowcoder.com/feed/main/detail/21ecd02d94d2403f94d508bb8a209eba；https://www.nowcoder.com/feed/main/detail/5ac85cc8e30142689e7d0bd6294ded05

面经

快手 AI Agent 前端二面

原帖问题与答案：原帖列出 9 个问题，均未提供答案。
1. React Fiber 架构解决了什么问题，工作原理是什么？
2. 开发 Agent 产品时，如何实现流畅的打字机输出？
3. 如何处理 Agent 长文本中的 Markdown 和 LaTeX 公式渲染？
4. 项目如何做前端性能优化，有哪些量化指标？
5. Webpack 构建流程是什么，做过哪些打包优化？
6. 为什么需要微前端，常用方案有哪些？
7. Agent 复杂状态应用选择什么状态管理方案，为什么？
8. 是否了解小程序、KwaiNative 等跨端方案？
9. 前端如何捕获异常，如何监控白屏？
可复习问题：
1. Agent 流式打字机、Markdown/LaTeX 渲染和复杂状态管理如何设计？
2. 前端性能、构建、跨端与异常监控如何落到量化指标？

百度 AI Agent 前端研发实习生面经

原帖问题与答案：原帖列出 40 个技术问题，均未提供答案。
1. AI 辅助开发的完整工作流和真实使用场景是什么？
2. 如何固化 AI 工作流的 case、方案和收益？
3. 如何把能力封装为 Skill，如何定义触发条件和意图识别中的人工干预？
4. 多 Skill 串行或嵌套时，如何处理依赖冲突、参数不兼容和编排优先级？
5. AI 工作流上线后如何做全链路监控、异常告警和幻觉兜底？
6. Agent 为什么选 LangChain，而不是直接调用 OpenAI 接口？
7. 文案解析到自动剪辑是否独立开发，有哪些优化点，Skill 如何定义和拆步？
8. 为什么引入有限状态机，6 个核心状态和流转规则如何用 transitions 实现？
9. 如何保证状态幂等并防止任务重复执行？
10. 任务成功率 99.5% 如何统计，每条任务是否标记状态？
11. 调度、工具编排和异步流程是否独立完成？
12. 使用什么大模型，如何控制调用成本？
13. 如何排查和熔断状态机卡死、悬停与死循环？
14. FFmpeg 导致 CPU 或内存突增时，Agent 如何动态限流、分片和降级？
15. 切换国产大模型时，提示词和工具调用逻辑要改什么？
16. 海量积压时，RabbitMQ 死信队列和延迟队列如何保障稳定消费？
17. 旧埋点为什么需要深层组件嵌套传参？
18. 为什么用 Context 优化埋点，作用域是全局还是组件级？
19. 优化前后组件嵌套结构有什么变化？
20. 新旧埋点并行改造时，如何保证旧代码和线上运行稳定？
21. Context 频繁更新引发重渲染时，memo、useMemo、useCallback 如何落地？
22. 大规模存量页面如何灰度上线新埋点，AB 分流和数据校验怎么做？
23. AI 对话为什么优先 SSE 而不是轮询？
24. SSE 与 WebSocket 有什么区别，能否独立实现聊天通信逻辑？
25. SSE 返回什么数据结构？
26. 如何实现断线自动重连、指数退避和断点续传，避免丢文本？
27. 打字机逐字输出如何实现，渲染间隔设多少？
28. 超长文本打字机卡顿如何用分片和异步队列优化？
29. 音频可视化效果和处理后的数据格式是什么？
30. 基于 FFT 的完整开发思路和技术选型依据是什么？
31. 频谱柱状高度如何适配不同屏幕？
32. 移动端后台锁屏导致音频采集中断时，如何捕获并重启 WebAudio 上下文？
33. FCP、LCP 通过什么方式采集？
34. 首屏性能优化前后如何对比，为什么主动做性能埋点？
35. 页面滚动优化是自研还是第三方库？
36. LCP 被大体积音频阻塞时，预加载和分片加载如何落地？
37. Agent 和普通 Chatbot 有什么区别？
38. Agent 的核心组成模块有哪些？
39. RAG + Agent 中如何用重排和过滤改善检索幻觉、无关文档召回？
40. Multi-Agent 如何设计分工和冲突协商机制？
可复习问题：
1. Skill 编排、状态机、幂等、熔断、成本和可观测如何组成可运行的 Agent 工作流？
2. SSE 重连、断点续传、打字机性能和 WebAudio 可视化如何实现？
3. RAG 检索质量与 Multi-Agent 协作如何落地？

百度 AI Agent 前端二面

原帖问题与答案：正文明确提到 3 个问题，均未提供答案；配图中的其他问题无法从 Scrape 正文证明。
1. 如何实现带超时时间和超时次数的 Promise 重试？
2. Zustand 为什么轻量化？
3. 如何结合工作流进行开发？
可复习问题：
1. Promise 重试如何同时控制单次超时和总重试次数？
2. Zustand 的轻量化体现在哪里？
3. Agent Workflow 如何映射到实际开发流程？

商汤科技 AI Agent 开发面经

原帖问题与答案：原帖列出 4 个问题，均未提供答案。
1. 设计类似 LangFlow 的 AI Agent 工作流编排画布时，选择什么技术栈，核心难点是什么？
2. RAG 系统中，前端如何优化长文档展示和引用来源跳转？
3. AI 时代前端工程师的角色发生了什么变化？
4. 如何在 AI 快速迭代时兼顾团队技术栈的稳定性与前瞻性？
可复习问题：
1. Agent 可视化编排画布的节点模型、连线、状态同步与性能难点是什么？
2. RAG 长文档和引用跳转的交互如何设计？

百度 Agent 前端一面

原帖问题与答案：
1. 日常开发如何使用 AI？原帖回答涉及让 AI 编写覆盖正常和边界情况的测试脚本。
2. 已有测试 Skill 时如何使用，如何确保执行？原帖回答涉及渐进式加载 Skill，以及用固定 Workflow 承载主流程、由 Agent 或 LLM 执行节点任务；面试官补充可把 Workflow 写入 system prompt。
3. 项目打字机效果如何实现，帧率如何计算？原帖未提供答案。
4. Markdown 渲染如何防 XSS？原帖只提到 GFM 白名单，未展开。
5. 什么是 CSRF 攻击？原帖未提供答案。
6. 为什么 AI 输出用 SSE 而不是 WebSocket？原帖未提供答案。
7. AI 生成歌曲耗时较长时，如何改善等待体验？原帖未提供答案。
8. 等待进度条当前 task 如何实现？原帖提到 SSE 自定义事件，未展开。
9. 为什么播放器使用全局状态管理？原帖未提供答案。
10. 如何根据音乐做音波震动效果？原帖回答可用现成库，或定期分析音乐特征生成主波频并用噪声模拟小波频；面试官补充音乐文件可解析为包含特征信息的数组。
11. 为什么项目使用 Next.js？原帖提到高交互区域不适合使用 SSR。
12. 知道哪些性能指��，如何监测？原帖未提供答案。
13. 简历中的性能优化具体怎么做？原帖未给出细节。
14. AI 是否会取代前端？原帖未提供答案。
15. 了解哪些动画库或 UI 库？原帖未提供答案。
可复习问题：
1. 如何用 Skill + Workflow 固化 AI 测试流程并保证节点执行？
2. SSE 自定义事件如何驱动任务进度和流式文本？
3. Markdown 安全、音频可视化、SSR 边界和性能指标如何回答？

简历/岗位材料

2026 年，AI 全栈时代到了，前端简历别再只写前端技术了

信号：
1. 原帖认为仅写调模型、工具调用和聊天界面缺少区分度，项目应体现 Agent Runtime、显式状态机、评测回归、可观测、安全、成本和人工干预。
2. 前端优势应落在过程可视化、步骤和工具状态、审批、中断重试、异常恢复，以及 token 和成本展示。
3. 简历中的性能数字需要说明统计口径和复现方式，项目描述需要包含场景、难点、个人职责和可验证结果。
可追问方向：Agent Loop 如何显式建模；步数、超时、预算和取消如何由 Runtime 控制；高风险工具调用如何审批；trace、评测集和发布闸门如何闭环；token、step、progress 事件如何统一建模。

通过 JD 看 AI 时代前端开发者需要具备的技能

信号：
1. 原帖归纳的前端 Agent 岗位能力包括 React/Vue/TypeScript、状态管理、可视化编辑器、SSE/WebSocket，以及 Agent 多轮对话和工作流界面。
2. AI IDE 方向涉及 Monaco Editor、WebAssembly、代码生成与理解、知识问答、插件生态和工具链。
3. 多模态方向涉及 Canvas/WebGL/WebGPU、WebRTC、内容预览编辑、FPS 和内存优化；AI 工程化还涉及模型接入、Token、缓存、延迟、数据脱敏和内容审核。
可追问方向：Agent 编排画布如何建模；SSE/WebSocket 如何选型；Monaco 与 AI 代码生成如何集成；多模态预览的性能如何衡量；模型输出如何做安全合规。

前端转 Agent 是如何拿到三个大厂 offer 的

信号：
1. 原帖将前端转 Agent 的真实技术点归纳为上下文管理、工具调用、任务轨迹、Memory/State、成本和延迟控制，而不是只写 Prompt + API Demo。
2. 前端的状态管理、模块化、API 设计和工程结构可以迁移到 Agent Loop、Tool、Observation 和 Context Engineering。
3. 项目描述应给出 latency、token cost、success rate 等量化指标，说明方案取舍，并强调解决具体问题和落地。
可追问方向：Agent 轨迹如何记录和回放；Tool 与 Observation 如何设计；上下文和状态如何管理；延迟、token 成本和成功率如何定义统计口径。

2026-07-15 12:04 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com "前端" "Agent" "面经"；site:nowcoder.com "前端" "Agent" "简历"；site:nowcoder.com "AI Agent" "前端" "面试"
新增面经：5 条；新增简历/岗位材料：5 条。
数据来源：https://www.nowcoder.com/discuss/892108187820650496；https://www.nowcoder.com/feed/main/detail/22c08e97f0e34becbae6d388131209f3；https://www.nowcoder.com/feed/main/detail/0be454f3836b44bab988cc3c1130b5e1；https://www.nowcoder.com/discuss/866140938798718976；https://www.nowcoder.com/feed/main/detail/563b8cda26004293afcd5098b53fded0；https://www.nowcoder.com/discuss/868082243900559360；https://www.nowcoder.com/feed/main/detail/85c91d9e791449a684a6364f6fd95cf4；https://www.nowcoder.com/feed/main/detail/291ba3fdde0d498cb84e9e89e23d3160；https://www.nowcoder.com/discuss/861207388076900352；https://www.nowcoder.com/discuss/897824104030531584。

面经

知乎前端面经

原帖问题与答案：
1. SSE 流式返回机制。原帖未提供答案。
2. 图表生成失败怎么考虑。原帖未提供答案。
3. MCP Server 怎么理解。原帖未提供答案。
4. AI 上下文治理，包括污染、回退、Sub Agent 隔离、压缩、Skill。原帖未提供答案。
可复习问题：
1. SSE 流式返回机制是什么？
2. 图表生成失败时如何处理？
3. 如何理解 MCP Server？
4. 如何处理 AI 上下文污染、回退、Sub Agent 隔离、压缩与 Skill？

美团前端暑期一二面面经

原帖问题与答案：以下问题原帖均未提供答案。
1. 如何理解 AI？分享哪些好用的 AI 工具，主要用 AI 解决什么问题？
2. 项目中很多场景可由 AI 完成，应该怎么看，未来如何提升竞争力？是否实际尝试过 AI 工具？
3. 智能对话平台项目中，AI 对话流式输出为什么用 SSE 而不是 WebSocket？SSE 的好处、原理、断线风险与心跳保活如何处理？
4. 为什么选 DeepSeek？项目的关键技术点和 AI 部分如何实现？
5. 项目代码中 AI 生成占比多少，如何让 AI 生成代码并把控质量？AI 输出不符合预期甚至“欺骗”时如何处理？
6. 性能优化是否由 AI 辅助，优化代码由谁编写？
7. 如何处理语音噪声？若让 AI 做前端语音降噪，如何提出实现要求并验证方案可靠性？
8. 如何测试验收项目，如何覆盖弱网、噪音和真实使用场景？
9. 用过哪些 AI 工具，如何使用？是否部署过 LLM 服务？
10. AI 自动生成周报任务如何理解并拆分模块？数据如何采集、采集哪些信息？哪些步骤必须人工介入？空数据如何处理？
11. AI 自动生成周报工程目录中各 TS 文件有什么作用，为什么设计 base collector 基类，数据处理模块处理什么，还可如何改进？
12. AI 时代如何应对多端技术要求，如何保持对 AI 代码的判断力，看不懂时怎么办，如何快速提升技术认知？
可复习问题：
1. SSE 流式输出、断线恢复与心跳保活如何设计？
2. 如何控制 AI 生成代码的质量并完成工程验收？
3. 如何拆解 AI 自动生成周报任务并划定人工介入边界？
4. 如何验证 AI 提供的前端语音降噪方案？

前端+AI 面试题真题

原帖问题与答案：
1. SSE 与 WebSocket 有什么区别？原帖从通信方向、协议、数据类型、重连、使用成本和适用场景进行对比：SSE 基于 HTTP、服务端单向推送、只传文本且浏览器支持自动重连，适合 AI 流式输出；WebSocket 为 ws/wss 全双工协议，支持文本和二进制，需要自行实现心跳与重连，适合聊天、游戏和协同编辑等双向实时场景。
2. RAG、Agent、Function Call、MCP、Skills 是什么？原帖将 RAG 概括为先检索再生成，Agent 负责规划并调用工具，Function Call 用于调用外部接口，MCP 统一模型与工具的通信，Skills 封装可复用能力。
3. 个人 AI 技能如何描述？原帖列出提示词工程、RAG 私有知识库、Agent 工作流与 Function Call、前端对话界面与流式输出、多 Agent 协作及需求拆解和方案落地。
4. 主流模型及应用场景有哪些？原帖列举 GPT-4o、Gemini、Claude、Llama、文心一言、通义千问、讯飞星火和 Kimi，并给出概括性特点；这些特点未提供进一步证据，标记 uncertain。
5. 使用哪些 IDE，如何对比？原帖比较 VS Code、WebStorm、Cursor 和 Zed，并建议按日常开发、AI 开发和大型项目选择。
6. 如何理解多 Agent？原帖描述为主管 Agent 分配任务、多个智能体分工执行并汇总，列出 AutoGen、CrewAI、LangGraph。
7. AI 在实习部门有哪些应用场景？原帖列出智能客服与内部问答、代码生成、文档生成与总结、页面生成、自然语言转图表和测试生成。
8. ReAct 与 Transformer 如何理解？原帖将 ReAct 概括为思考、行动、观察的循环，将 Transformer 概括为以自注意力理解上下文的模型基础架构。
9. 现有需求如何用 AI 实现？原帖给出需求拆解、/plan、/spec、实现、测试、上线优化的步骤，并要求关注幻觉、流式稳定性和异常处理。
可复习问题：
1. SSE 与 WebSocket 如何按 AI 交互场景选型？
2. RAG、Agent、Function Call、MCP、Skills 如何协作？
3. 多 Agent 的分工、通信与汇总流程是什么？
4. 如何用 /plan 和 /spec 把现有需求拆解为可实现、可测试的 AI 功能？

为什么 AI Agent 多用 SSE？以及 SSE 和 WebSocket 技术选型

原帖问题与答案：为什么 Agent 项目选择 SSE 而不是 WebSocket？原帖认为，大模型对话多为服务端到客户端的单向流式输出，SSE 基于 HTTP，接入和运维成本较低，并支持自动重连；当场景需要语音实时打断、多端协同、高频双向交互或二进制传输时，应考虑 WebSocket。原帖把 SSE 称为“长轮询升级版”，这一表述不严谨，标记 uncertain。
可复习问题：
1. 为什么 AI Agent 流式输出通常优先考虑 SSE？
2. 哪些实时交互场景必须改用 WebSocket？
3. SSE 与 WebSocket 在重连、心跳、多实例和运维上的成本分别是什么？

前端面试中怎么应对 AI 相关问题

原帖问题与答案：
1. 工作中如何使用 AI，主要解决什么问题，如何更高效使用 AI？原帖建议基于真实场景诚实回答，并补充 AI 痛点和 Prompt 设计等思考。
2. Model、Agent、RAG、MCP、Vibe Coding、Function Calling 等概念如何区分与关联？原帖建议掌握概念及相互关系，未提供具体答案。
3. 流式数据交互如何实现？原帖未提供答案。
4. MCP Server 如何传递数据？原帖未提供答案。
可复习问题：
1. 如何用真实项目说明 AI 工具的使用方式与边界？
2. Model、Agent、RAG、MCP、Vibe Coding、Function Calling 有什么区别与联系？
3. 前端流式数据交互和 MCP Server 数据传递如何实现？

简历/岗位材料

开源 Agent 项目推荐 + 如何用它们丰富简历

信号：
1. 原帖把已合并 PR、针对具体问题的深度实践、源码分析文章和 Issue 排查列为可验证的开源产出，强调必须写清改动内容，而不是只写项目名或“跑通”。
2. 对前端方向，原帖点名 Open WebUI 的 Streaming 展示、工具调用可视��、多轮对话和文件上传；也建议自行开发 MCP Server，或为 Agent 项目接入 Langfuse 可观测性。
3. 原帖建议简历项目包含明确问题、技术取舍、对比实验与结论；文中的具体 PR 数量和性能指标均是写法示例，不是作者已验证成果。
可追问方向：Streaming 与工具调用 UI 如何组织？MCP Server 的工具注册、参数 Schema 和通信如何实现？如何用 Trace 回放 Agent 步骤并验证改进效果？

前端转 AI Agent

信号：
1. 原帖列出的前端切入方向包括 AI 应用端 Agent、MCP/工具调用、RAG、全栈 Agent、企业流程 Agent、端侧 WebLLM 与 Agent 平台。
2. 可迁移能力集中在 SSE 流式渲染、复杂交互与状态管理、工具调用前端对接、引用溯源、文档渲染、Node 服务和浏览器运行时。
3. 原帖关于“薪资高”“爆款”“无缝转型”等市场判断没有数据支撑，标记 uncertain。
可追问方向：如何渲染工具调用与流式事件？如何管理多轮会话和记忆状态？如何在浏览器端运行轻量模型并处理性能与隐私？

适合写进简历的 Agent 项目推荐

信号：
1. 原帖认为适合面试展开的项目需要同时体现业务场景、系统设计和工程实现，而不只是接入模型。
2. AI Coding/代码仓库问答可涉及代码切片、RAG、Tool Calling、上下文、状态管理、AST、调用链与测试生成；Deep Research 可涉及查询拆分、多源抽取、去重、重排和引用。
3. 长期记忆/个人知识库可围绕长短期记忆划分、写入时机和旧信息污染展开；AIOps 可围绕日志、指标、告警、runbook 与人工接管展开。
可追问方向：代码仓库如何切片和组织上下文？联网研究结果如何去重、重排并保留引用？长期记忆如何写入、召回和避免污染？

一个好的简历 Agent 项目，必须具备的几个关键因素

信号：
1. 原帖建议项目覆盖 API 服务、数据库、会话管理、日志、错误处理、兜底与并发处理，体现可上线的系统工程能力。
2. Agent 能力应体现意图识别、任务路由、工具调用或多 Agent 协作；原帖同时指出，并非所有场景都需要 Multi-Agent，单链路工作流可能更可控。
3. 上下文管理、Trace/Session/User 维度的可观测性和自动化评测被列为可深入追问的工程点。
可追问方向：什么时候选择单 Agent 工作流或 Multi-Agent？如何治理上下文共享与污染？如何记录工具调用、模型请求并构建自动化评测？

做了个 AI Agent 面试题库

信号：
1. 原帖公开了一个 React + Ant Design 前端、FastAPI + SQLite 后端的 Agent 面试题库，并明确说明主要由 Cursor/Claude Code 生成。
2. 项目使用 SQLite FTS5 做全文检索，并以关键词匹配方式关联开源项目；作者明确承认答案由 AI 生成，可能不准确。
3. 该项目真实技术点是 AI 辅助实现、全文检索和知识引用；内容正确性验证与相关度算法仍是明显追问点。
可追问方向：如何审核 AI 生成代码和答案？为什么选择 FTS5，如何评价检索质量？关键词相关度如何升级为可验证的召回与排序方案？

2026-07-16 12:52 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com "前端" "Agent" "面经"；site:nowcoder.com "前端" "Agent" "简历"；site:nowcoder.com "AI Agent" "前端" "面试"
新增面经：0 条；新增简历/岗位材料：1 条。
数据来源：https://www.nowcoder.com/feed/main/detail/871d36feff2d4411a26ec7baf0127675。

简历/岗位材料

教你如何快速包装简历（Agent相关）

信号：
1. 原帖建议 Agent 项目写清多步任务分解、任务状态机、模型推理与规则约束结合的路由，以及统一、可插拔的工具接口。
2. 稳定性与工程化技术点包括参数和 Schema 校验、重试与 fallback、长短期记忆及上下文压缩、日志与 tracing、任务级监控。
3. 原帖建议用任务完成率、工具调用准确率、响应延迟和 token 成本建立评估闭环；其中 X% 和 XX% 均为占位写法，并非可验证成果，标记 uncertain。
可追问方向：任务状态机和 tool routing 如何实现；RAG 的向量检索、语义重排与 Agent 决策上下文如何协同；记忆压缩、超时降级、评测集和 tracing 如何形成工程闭环。

2026-07-16 12:57 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com "前端" "Agent" "面经"；site:nowcoder.com "前端" "Agent" "简历"；site:nowcoder.com "AI Agent" "前端" "面试"
新增面经：0 条；新增简历/岗位材料：0 条。
数据来源：本次无新增原帖。
本次没有新的高相关材料。

2026-07-16 13:08 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：9 条；新增简历/岗位材料：1 条。
数据来源：https://www.nowcoder.com/feed/main/detail/bb9e8c5b9fd5442aa0483b7af4a3d5e9；https://www.nowcoder.com/feed/main/detail/0f17e1b2e9214f778e7889e434f74ed9；https://www.nowcoder.com/feed/main/detail/80693d262a7b439f87b85f6e8cd209d9；https://www.nowcoder.com/feed/main/detail/cbefd28f5deb40efb773da3a67c10089；https://www.nowcoder.com/feed/main/detail/0377a25b259144819db05ff6e84cf602；https://www.nowcoder.com/feed/main/detail/a38f79a2f03c4e2faccff2d7a052ac2d；https://www.nowcoder.com/discuss/868996108591120384；https://www.nowcoder.com/discuss/868998856070000640；https://www.nowcoder.com/discuss/873899049244508160；https://www.nowcoder.com/feed/main/detail/0d226871ed4d4ca4a0adbd338678797c。

面经

快手前端 AI 应用开发一面

原帖问题与答案：以下问题原帖均未提供答案。
1. 事件循环中微任务和宏任务的执行顺序是什么？
2. AI 流式输出中的 SSE 和 WebSocket 有什么区别？
3. 如何实现带并发控制的 Promise 控制器？
4. TypeScript 泛型及 extends 关键字有什么作用？
5. CSS 如何实现类似 ChatGPT 对话框的自动滚动到底部效果？
6. 如何判断包含大、中、小括号的字符串是否合法？
可复习问题：SSE 与 WebSocket 如何选型；Promise 并发控制如何实现；聊天列表自动滚动如何处理。

快手暑期 AI 前端一面

原帖问题与答案：以下问题原帖均未提供答案。
1. 请做自我介绍。
2. 实习的核心需求是什么？
3. 实习项目有哪些难点？
4. 自研项目的进展和产品方案是什么？
5. 是否开发过 Agent？
6. 当前前后端 HC 是否紧缩？原帖转述面试官称 AI 破坏了原有工作流，但没有进一步证据，标记 uncertain。
7. 前后端入职后是否都会以 Agent 开发为核心，主要做 Agent 工作流和部署？原帖转述面试官回答“确实”，适用范围不明，标记 uncertain。
可复习问题：如何证明自己开发过 Agent；实习项目与 Agent 工作流、部署需求如何关联。

美团 AI Coding 前端开发一面

原帖问题与答案：以下问题原帖均未提供答案。
1. JavaScript 事件循环中宏任务和微任务的执行顺序是什么？
2. Flex 如何实现垂直居中且两端对齐？
3. SSE 和 WebSocket 有什么区别，为什么 AI 对话多用 SSE？
4. 如何实现考虑循环引用和 Symbol 的深拷贝？
5. TypeScript 泛型是什么，如何提取 Promise 返回类型？
6. 如何求无重复字符的最长子串长度？
可复习问题：AI 对话为何选择 SSE；深拷贝与 Promise 类型工具如何实现。

阿里云 AI 应用开发前端一面

原帖问题与答案：以下问题原帖均未提供答案。
1. SSE 与 WebSocket 有什么区别，AI 对话为什么通常选择 SSE？
2. LLM 返回 Markdown 流时，如何处理代码块或公式截断造成的渲染闪烁？
3. 如何用 Fetch API 的 ReadableStream 实现简单的流式数据解析器？
4. Promise.all、Promise.allSettled 和 Promise.race 有什么区别，在 AI 场景中如何应用？
5. 对话界面如何自动滚动到底部，同时允许用户向上查看历史消息？
6. Record、Partial、Pick 等高级类型在 AI 接口响应定义中有什么作用？
可复习问题：流式 Markdown 如何稳定解析；ReadableStream 如何跨 chunk 缓冲；自动滚动如何区分程序滚动与用户滚动。

得物 AI 应用开发前端一面

原帖问题与答案：以下问题原帖均未提供答案。
1. AI 流式输出中的 Markdown 标签被截断时，前端如何渲染？
2. 什么是 RAG，前端可以参与哪些环节？
3. 如何通过 Prompt Engineering 减少前端请求的 token 消耗？
4. AI 聊天消息很多时，如何保证滚动平滑？
5. 如何防范 Prompt Injection？
6. AI 项目的性能监控有哪些特殊指标？
7. 通用 AI Chat 组件应设计哪些 Props 和 Slots？
8. AI 接口网络抖动时，前端重试机制如何设计？
9. 向量数据库如何用于前端，前端是否需要处理向量化？
10. 如何实现支持拖拽上传、预览并可被 AI 解析的附件功能？
可复习问题：AI Chat 组件契约如何设计；流式 Markdown、长列表、重试、附件与安全如何组成完整交互链路。

MiniMax 前端 AI 开发实习一面

原帖问题与答案：以下问题原帖均未提供答案。
1. SSE 与 WebSocket 有什么区别，AI 对话为什么多采用 SSE？
2. AI 聊天列表的长文本渲染卡顿如何处理？
3. 如何用 Fetch 处理 ReadableStream，模拟 AI 流式输出？
4. 自动滚动到底部如何处理用户手动向上滚动的冲突？
5. Promise.all 和 Promise.allSettled 有什么区别，调用多个模型接口时如何选择？
6. CSS 如何实现类似 ChatGPT 的打字机光标闪烁效果？
可复习问题：长文本流式渲染如何控制更新频率；多模型并发的失败语义如何选择；滚动锚定如何实现。

字节剪映暑期实习 AI 前端一面

原帖问题与答案：以下问题原帖均未提供答案。
1. AI Agent 系统的背景、职责和落地成果是什么？
2. 主从 Agent 如何分工？
3. 从 Agent 数量如何确定，如何避免重复探索？
4. MCP 和 Tool Calling 有什么区别？
5. Skill 和固定 Workflow 有什么区别，如何选型？
6. 如何复用 Agent 经验并优化 Memory？
7. Next.js 电商项目的核心工作、难点和方案是什么？
8. CSR、SSR、SSG 的区别、优缺点和适用场景是什么？
9. SSR 和 CSR 哪个维护成本更高，为什么？
10. TLS 1.2 与 TLS 1.3 的握手有什么区别？
11. HTTPS 如何防止中间人攻击？
12. 超卖问题的根因和解决方案是什么？
13. 智能商品查询助手的架构、问题和优化手段是什么？
14. Rerank 的作用是什么？
15. 为什么商品推荐使用 RAG，而不是直接使用大模型？
16. 如何寻找两个无限输入流共同出现的元素？
17. 个人项目和团队项目有什么区别，协作中遇到过什么痛点？
可复习问题：主从 Agent 如何控制并行与重复探索；MCP、Tool Calling、Skill、Workflow 如何划分；RAG 推荐为什么需要 Rerank。

字节剪映暑期实习 AI 前端二面

原帖问题与答案：以下问题原帖均未提供答案。
1. 实习项目的背景、职责和成果是什么？
2. 系统优化如何定位根因、制定方案并验证效果？
3. Memory 复用机制的初衷、实现、存储和管理方案是什么？
4. 为什么选择主从多 Agent 架构，和其他架构相比有哪些取舍？
5. 当前技术瓶颈和后续迭代方向是什么？
6. ReAct、Self-Discovery、Plan-and-Execute 的原理与适用场景是什么？
7. 电商 RAG 智能导购的功能、链路和效果是什么？
8. RAG 召回准确率如何逐步优化？
9. 如何测量召回率？
10. 为什么只用商品标题向量化，而不使用全字段？
11. RAG 项目还有哪些优化方向？
12. Agent 项目最大的系统难点是什么，如何解决？
13. Agent 模块耦合严重、调试成本高时，如何解耦？
14. 是否有大模型微调实践？
15. 大模型微调的核心难点是什么？
16. Prompt 工程和模型微调如何权衡？
17. AI 对前端工程师有什么影响？
18. 如何理解 AI Native 前端工程师？
19. 为什么应聘剪映，求职动机是什么？
20. 对剪映产品和前端团队有哪些了解？
21. 如何用 JavaScript 实现最大并发数为 2 的异步 Scheduler？
可复习问题：多 Agent 架构如何选型与解耦；Memory 如何存储和复用；RAG 召回率如何测量；Prompt 与微调如何选择。

2026 年前端面试中的 AI 工作流问题

原帖问题与答案：
1. 日常 AI 工作流是什么？原帖将流程分为上下文准备、需求分析、代码生成、自动验证、上线优化五阶段；涉及 Rule、MCP、Skills、任务拆分、测试、CI、Code Review、监控和知识库更新。
2. 如何保证 AI 生成代码的质量？原帖回答包括开发前的规范与架构约束，开发中的上下文和 Skill，提交时的静态检查、测试与人工 Review，以及运行时监控反馈。
3. 使用哪些 AI 工具，各自优势是什么？原帖按 Cursor、Claude/GPT-4 和 ChatGPT 分别对应日常编码、复杂方案分析和快速学习查询；其中具体使用频率只是作者个人情况。
可复习问题：如何把 AI 编码工作流固化为可审计流程；Rule、MCP、Skill、测试、CI 和监控如何形成质量闭环。

简历/岗位材料

前端 AI 岗位需要达到的能力强度

信号：
1. 原帖列出的前端基础包括 JavaScript/TypeScript、React 或 Vue、工程化、Node.js，以及 AI 流式输出所需的 SSE/WebSocket。
2. AI 应用能力包括模型 API、流式输出、多轮对话、Prompt、RAG、Agent 工具调用、多模态处理和生成式 UI。
3. 进阶方向包括 Transformers.js、WebGPU、模型优化和隐私计算；原帖将部分能力称为“必备”或“大厂刚需”，但没有岗位样本支撑，标记 uncertain。
可追问方向：模型流式事件如何映射到前端状态；RAG 与 Agent 工具调用如何接入 UI；WebGPU 端侧推理如何处理性能、模型体积和隐私。

2026-07-17 12:08 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：4 条；新增简历/岗位材料：1 条。
数据来源：https://www.nowcoder.com/feed/main/detail/8f02ab1b4ca9428bbc9340c21116a1ab；https://www.nowcoder.com/feed/main/detail/6bdd0e226e2f4f06a17d21399d0e610c；https://www.nowcoder.com/discuss/801188664293277696；https://www.nowcoder.com/discuss/889546972099584000；https://www.nowcoder.com/feed/main/detail/64bfe39a748343b8b4dbf63eac676e5f。

面经

字节前端实习二面面经

原帖问题与答案：以下相关问题原帖均未提供答案。
1. AI Agent 怎么使用，平时如何在自己的项目里落地 AI 实践？
2. AI 使用过程中有哪些令人难受的地方，或者希望大模型改进什么？
3. 是否尝试过 Workflow 这种固定的大模型工具？
4. 是否使用过 Skill 来沉淀自己的方法论？
可复习问题：
1. 如何用真实项目说明 AI Agent 的落地方式？
2. Workflow 与 Skill 分别如何固化 AI 开发流程和方法论？

360 前端二面

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 流式对话的实现原理是什么？
2. 在 AI 项目中如何实现用户权限管理？
3. 操作权限如何实现？
4. 多模态 AI 工具调用对工作和生活有什么影响？
5. 如何看待 AI 代替前端？
6. 知识库文件解析预览如何做性能优化？
7. RAGFlow 和 Dify 有什么区别？
8. 大模型 Function Calling 的函数如何调用？
可复习问题：
1. AI 项目的用户权限、操作权限与工具调用权限如何分层？
2. 流式对话、知识库预览和 Function Calling 如何组成前端交互链路？

腾讯前端二面

原帖问题与答案：
1. 大模型流式输出是什么原理？原帖括注答案为 SSE，未进一步展开。
2. SSE 和 WebSocket 有什么区别，应用层是什么协议，基于 UDP 还是 TCP？原帖未提供答案。
3. 为什么 WebSocket 不用 UDP，为什么 HTTP/3 可以用 UDP？原帖未提供答案。
可复习问题：
1. 大模型流式输出为什么可以使用 SSE？
2. SSE、WebSocket 与 HTTP/3 的应用层和传输层关系是什么？

27 届暑期前端高频面试题汇总

原帖问题与答案：以下为原帖明确列出的前端 AI/Agent 相关问题，原帖均未提供答案。
1. 为什么 ChatGPT 使用 SSE 而不是 WebSocket，流式输出为什么不用其他方式？
2. SSE 流式 Markdown 语法不完整时如何处理？
3. SSE 断线重连、ping 心跳、AbortController 边界情况和降级兜底如何设计？
4. AI 生成代码和项目规范冲突时如何约束，大项目 token 爆炸如何处理？
5. 团队是否使用 Rules 或 Skills 沉淀，解决什么问题？
6. AI 对话上下文过长导致语义偏移时，如何做上下文摘要压缩？
7. Markdown 如何安全渲染并防止 XSS？
8. AI 模块在 Monorepo 中应该放在哪里？
9. AST 静态分析如何生成文档供 AI 理解上下文？
10. RAG 如何计算 chunk 相似度，效果不好如何优化，AI 胡言乱语如何处理？
11. HyDE 是什么，用户模糊意图如何改写，为什么这与 RAG 不冲突？
12. 嵌入模型、切分策略、重叠步长与会话长记忆如何设计？
13. ReAct 与 Workflow 的核心差异是什么？
14. MCP 与 A2A 有什么区别，MCP 协议内部是什么样的？
15. MCP 与 Skills 有什么区别，模型如何知道存在某个工具，Agent 有哪些编排范式？
16. 使用过哪些 AI 工具，AI 生成代码占比多少，哪些代码适合由 AI 生成？
17. Vibe Coding 的一般流程是什么，中途出错如何改正，如何转向 Spec Coding？
可复习问题：
1. SSE、流式 Markdown、重连和安全渲染如何构成稳定的 AI 对话前端？
2. Rules、Skills、MCP、A2A、ReAct 与 Workflow 如何划分职责？
3. RAG、上下文压缩和 AST 文档如何改善模型输入质量？

简历/岗位材料

巨量星图大模型应用前端 Agent 招聘

信号：
1. 原帖明确招聘前端工程师（Agent 方向），支持应届生和实习生投递。
2. 前端工作场景包括智能脚本生成、创意策划、内容推荐的交互与可视化。
3. 团队方向同时覆盖大模型、多模态应用与内容营销 Agent 系统，但原帖未进一步给出前端技术栈或任职要求。
可追问方向：智能脚本生成、创意策划和内容推荐场景的前端交互与可视化如何设计；更具体的技术实现无法从原帖证明，标记 uncertain。

2026-07-18 12:05 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：2 条；新增简历/岗位材料：0 条。
数据来源：https://www.nowcoder.com/feed/main/detail/719c5519554c4d1885baf5f31ce4ae00；https://www.nowcoder.com/feed/main/detail/a1a64c32b2034659a369003b79edf5d7。

面经

磐松前端一面

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 项目和市面上已有的 DeepSeek 问答平台有什么区别？
2. Agent 具体是怎么封装的？
3. AI 回答返回的数据以什么形式展示到前端页面，为什么不用 WebSocket？
4. 弱网、断连或响应数据缺失时有什么兜底策略；回答中途停止后，下次如何完整渲染该消息？
5. AI 回答的历史记录如何处理，历史数据能存多少条，是否有限制？
6. 聊天对话页面如何优化大量历史数据，是否了解或使用过虚拟列表？
可复习问题：
1. 项目和市面上已有的 DeepSeek 问答平台有什么区别？
2. Agent 具体是怎么封装的？
3. AI 回答返回的数据以什么形式展示到前端页面，为什么不用 WebSocket？
4. 弱网、断连或响应数据缺失时有什么兜底策略；回答中途停止后，下次如何完整渲染该消息？
5. AI 回答的历史记录如何处理，历史数据能存多少条，是否有限制？
6. 聊天对话页面如何优化大量历史数据，是否了解或使用过虚拟列表？

腾讯前端实习面经

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 平时开发和学习是否使用 AI，开发项目时使用哪些 AI 工具？
2. Cursor Agent 辅助开发有哪些坑？
3. AI 编程有哪些最佳实践或工作流，Skill、MCP 如何帮助开发？
4. 除开发外，哪些编程节点或流程可以用 AI 提效？
5. 如何 Review 或测试 AI 产出以避免幻觉？
6. 如何把多 Agent、Team 模式或 Agent 质检接入开发流程，同时提高效率和代码质量？
7. 如何关注快速迭代的 AI 知识、理论和实践，近期 Git 上有哪些热门 AI 编程项目？
8. 是否搭建过 OpenClaw？
9. 实现流式传输时为什么选择 RxJS 而不是原生 EventSource，RxJS 的核心价值是什么？
10. SSE 和 WebSocket 有什么区别？
11. 流式输出在前端如何渲染，是逐字追加 DOM 还是缓冲后批量更新，如何处理频繁 DOM 更新的性能问题？
12. 文件上传解析中前端负责哪些部分？
13. AI 辅助编码和独立编码分别应如何看待？
14. Skill 和 MCP 有什么区别，是否开发过 Skill？
15. OpenClaw 如何实现用户需求？
可复习问题：
1. 平时开发和学习是否使用 AI，开发项目时使用哪些 AI 工具？
2. Cursor Agent 辅助开发有哪些坑？
3. AI 编程有哪些最佳实践或工作流，Skill、MCP 如何帮助开发？
4. 除开发外，哪些编程节点或流程可以用 AI 提效？
5. 如何 Review 或测试 AI 产出以避免幻觉？
6. 如何把多 Agent、Team 模式或 Agent 质检接入开发流程，同时提高效率和代码质量？
7. 如何关注快速迭代的 AI 知识、理论和实践，近期 Git 上有哪些热门 AI 编程项目？
8. 是否搭建过 OpenClaw？
9. 实现流式传输时为什么选择 RxJS 而不是原生 EventSource，RxJS 的核心价值是什么？
10. SSE 和 WebSocket 有什么区别？
11. 流式输出在前端如何渲染，是逐字追加 DOM 还是缓冲后批量更新，如何处理频繁 DOM 更新的性能问题？
12. 文件上传解析中前端负责哪些部分？
13. AI 辅助编码和独立编码分别应如何看待？
14. Skill 和 MCP 有什么区别，是否开发过 Skill？
15. OpenClaw 如何实现用户需求？

2026-07-19 12:03 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：0 条；新增简历/岗位材料：0 条。
数据来源：本次无新增原帖。

本次没有新的高相关材料。

2026-07-20 12:07 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：2 条；新增简历/岗位材料：1 条。
数据来源：https://www.nowcoder.com/discuss/868928829648031744；https://www.nowcoder.com/feed/main/detail/c9840d6bc86749ca95897e2bfd3b5116；https://www.nowcoder.com/discuss/859392487968759808。

面经

影刀 AI 前端一面，惨不忍睹

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 为什么会有给 AI 使用的 sandbox，它解决什么问题，是否用过？
2. LLM Playground 如何实现？
3. SSE 和 Socket 有什么区别，为什么流式输出使用 SSE 而不是 Socket？
4. 模型流式输出时刷新页面或切换会话，如何保证返回后对话继续；SSE 断开后如何恢复？
5. 用户点击停止时如何设计中止；前端取消 Fetch 后，后端 SSE 如何停止？
6. 提供给 LLM 的 Tool 是否由前端实现，Web Search 如何调用？
7. 是否参与过 Agent 开发，是否了解 LLM 的运行过程？
8. 用户输出与模型输入是什么关系，多模态消息和纯文本消息有什么区别？
9. 为什么使用 SWR，为什么需要请求缓存？
10. 项目如何实现国际化？
11. 全球论坛中，如何让海外用户看到中文帖子的英文版本？
12. 后端应在什么时机翻译？
13. 相同文本是否需要重复翻译，如何优化；实时论坛中请求缓存是否仍有必要？
可复习问题：
1. 为什么会有给 AI 使用的 sandbox，它解决什么问题，是否用过？
2. SSE 流中断后如何恢复会话，并协调前后端真正停止生成？
3. 提供给 LLM 的 Tool 是否由前端实现，Web Search 如何调用？
4. 是否参与过 Agent 开发，是否了解 LLM 的运行过程？
5. 多模态消息和纯文本消息有什么区别？

Dify 前端实习一二面

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 平时在工作中如何使用 AI，具体用于哪些方面？
2. 是否使用过 Claude Code？
3. 是否使用过 Dify？
4. 对当前 AI 的看法是什么？
5. 是否了解 Dify？
6. 什么是 Agent？
可复习问题：
1. 平时在工作中如何使用 AI，具体用于哪些方面？
2. 是否使用过 Claude Code？
3. 是否使用过 Dify？
4. 对当前 AI 的看法是什么？
5. 什么是 Agent？

简历/岗位材料

大厂前端岗位 JD：总结前端 AI 学习路线

信号：
1. 原帖汇总的前端 AI 场景包括 AI IDE、Agent 平台、多模态创作、AI 全栈和可视化 AI 交互；具体 JD 内容主要以图片呈现，无法从抓取文本逐项核验，标记 uncertain。
2. 原帖明确列出的 Agent 平台前端职责包括多 Agent 协同界面、可视化编排工具，以及 Agent 交互、RAG 检索过程展示和多轮对话管理。
3. 原帖列出的相关工程能力包括模型 API 接入、SSE/WebSocket 流式输出、Token 消耗优化、WebGL/WebGPU/WebRTC、实时通信、性能优化与安全合规。
可追问方向：Agent 交互界面如何展示规划和工具调用；RAG 检索过程如何可视化；多轮对话状态如何管理；SSE/WebSocket 如何选型；Token、推理延迟和前端性能如何协同优化。

2026-07-21 12:07 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：2 条；新增简历/岗位材料：0 条。
数据来源：https://www.nowcoder.com/feed/main/detail/9a7e06328014454aababb71d441b1f65；https://www.nowcoder.com/feed/main/detail/e17421f1011649018c99aad1427ad902。

面经

前端小厂面经

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 项目是智能体吗？
2. 是否了解过 AI 工作流？
可复习问题：
1. 项目是智能体吗？
2. 是否了解过 AI 工作流？

前端 AI 项目：面试官高频拷打问题

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 项目业务价值是什么，为什么要做 AI 赋能前端场景？
2. 大模型接口怎么选，云端模型和开源模型有什么区别，选型依据是什么？
3. 框架和渲染方案为什么这样选，针对 AI 流式场景做了哪些适配？
4. 大模型流式返回如何实现，SSE、Fetch Streaming、WebSocket 有什么区别，如何落地选择？
5. 分片数据如何解析和逐字渲染，如何解决乱码、断行和拼接异常？
6. 如何实现请求中断、重复请求拦截，AbortController 如何使用？
7. 多轮会话上下文如何拼接传递，存在哪些 Token 开销？
8. 长对话卡顿如何优化，如何做上下文压缩和历史消息裁剪？
9. 对话记忆采用本地还是服务端存储，各自优缺点是什么？
10. Prompt 提示词工程做了哪些优化，如何提升回答准确度？
11. Markdown、代码块、公式等复杂内容如何渲染？
12. 函数调用、MCP 协议和 AI 工具联动时，前端如何配合？
13. 长文本渲染和海量聊天记录导致页面卡顿时如何解决？
14. 骨架屏、加载状态、断网重连和异常降级方案如何设计？
15. AI 高频请求场景如何使用防抖、限流和接口缓存？
16. 项目开发的最大难点是什么，如何排查流式接口异常？
17. 敏感词过滤、内容安全和输入边界校验如何处理？
18. 是否了解前端本地 AI、WebLLM 和 RAG 的前端落地思路？
可复习问题：
1. AI 流式响应、增量解析、中断和异常恢复如何组成稳定的前端链路？
2. 多轮上下文、记忆存储和长对话性能如何协同设计？
3. MCP、函数调用和 AI 工具联动时，前端承担哪些职责？
4. 前端本地 AI、WebLLM 和 RAG 分别适合哪些落地场景？

2026-07-21 12:39 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：4 条；新增简历/岗位材料：1 条。
数据来源：https://www.nowcoder.com/discuss/863430474180333568；https://www.nowcoder.com/discuss/864153617182355456；https://www.nowcoder.com/discuss/864449317648490496；https://www.nowcoder.com/feed/main/detail/129eaa1c20444651ac3b932e200d3da4；https://www.nowcoder.com/discuss/882681718157672448。

面经

聊一聊最近碰到的一些 Agent 面试题（一）

原帖问题与答案：
1. ACP 的设计思路和解决的问题是什么；ACP 与 MCP 是否冲突；为什么选择 REST 而不是 gRPC 或 WebSocket？原帖回答：ACP 用框架无关的 REST/HTTP 连接 Agent，以 Agent Card、Task、Message、Artifact 描述发现、任务生命周期、过程消息和产物，支持同步及异步/SSE；MCP 连接 Agent 与工具，两者解决不同层面的问题；选择 REST 是以生态可达性换取极端性能。
2. MCP 与 Agent Skills 的设计差异是什么，分别适合什么场景；Skills 无进程隔离有哪些风险；二者未来是否会合并？原帖回答：MCP 通过独立 Server、JSON-RPC 和凭证隔离连接外部能力，Skills 以 SKILL.md 向 Agent 注入行为规则；外部系统和合规场景偏 MCP，行为规范和本地工作流偏 Skills；Skills 共享 Agent 权限，因此只应加载可信来源；原帖判断二者更可能互补而非合并。
3. Agent Memory 如何设计，短期、长期、情景记忆分别解决什么问题；如何防止记忆污染；如何改善不相关召回？原帖回答：短期记忆承载当前上下文，长期记忆保存跨会话知识，情景记忆保存完整任务经历；写入需设置成功门槛、独立质量评估、冲突审核和置信度衰减；召回可结合混合检索、元数据过滤、重排和使用反馈。
4. RAG 架构及从原型到生产的优化点是什么；RAG 与微调如何选择和结合；如何评估 RAG；多轮对话有哪些特殊挑战？原帖回答：基础链路是索引、检索、生成，生产优化覆盖语义切块、混合检索、查询改写、Reranker、元数据过滤和上下文组装；RAG 适合动态/私有知识，微调适合行为和风格，二者可结合；评估需拆分检索与生成指标；多轮场景还需处理问题改写、对话指代和上下文膨胀。
可复习问题：ACP、MCP、Skills 如何分层；Agent Memory 的写入与召回如何形成质量闭环；RAG 如何从检索原型演进到可评估的生产系统。

28 届实习拷打：一场面试的 23 个 Agent 问题

原帖问题与答案：原帖围绕“工具调用失败怎么办”串联 23 个问题。第 10 题只给出提示词及入参/出参设计的简略回答，第 19 题提到用 Agent 可观测平台溯源；总体回答框架是先用模型选型、工具描述和入参校验减少失败，再用可观测性区分意图、参数与工具故障，最后做重试、备用工具和最终兜底。其余问题原帖未提供完整答案。
1. 什么是 Agent，它由哪些部分组成？
2. 为什么需要引入工具，单纯大模型为什么不够？
3. 工具给大模型扩展了哪些能力？
4. 什么是 Function Call？
5. 什么是 MCP，它由哪些部分组成？
6. Function Call、MCP 和工具有什么区别？
7. Skill 与 Function Call、MCP 有什么区别？
8. Skill 有哪些特性？
9. MCP 和 Skill 哪个占用的上下文更大？
10. 如何写好一个工具？
11. 提示词工程的方法论是什么？
12. 如何理解上下文工程？
13. 上下文工程与提示词工程有什么区别？
14. 如何避免不同用户的上下文互相污染？
15. 如何保存、隔离、选择和压缩上下文？
16. 如何持久化上下文，OpenClaw 是怎么做的？
17. 平时使用哪些模型或 AI 工具，Agent 系统为什么选择当前模型而不是其他模型？
18. 如何做工具入参校验，有哪些现成手段？
19. 如何判断工具调用失败源于意图识别错误、入参错误还是工具掉线？
20. 知道哪些 Agent 系统可观测平台？
21. LangSmith 和 Langfuse 有什么区别，如何选择？
22. 工具重试仍失败时怎么办？
23. 备用工具也失败时怎么办？
可复习问题：工具调用失败如何按“预防、观测溯源、重试、降级、人工兜底”设计；上下文隔离、持久化和压缩如何落到多用户 Agent 系统。

聊一聊最近碰到的一些 Agent 面试题（五）

原帖问题与答案：
1. 如何开发高质量 Agent Skill，好的 SKILL.md 应包含和避免什么；如何测试 Skill；Skill 触发条件冲突怎么办？原帖回答围绕清晰的触发描述、具体可执行步骤、渐进式加载、少写模型已知常识，并通过正向/负向触发用例和真实任务测试；冲突时应收窄描述、明确优先级或合并重叠 Skill。
2. 开发 MCP Server 要考虑哪些设计决策和常见坑；工具描述由谁写；一个 Server 放多少工具？原帖回答覆盖工具边界、Schema、错误返回、状态、安全与可观测性；工具描述需要 Server 开发者与 Agent 使用者协作；工具数量没有固定上限，关键是领域内聚并避免把大量无关工具同时暴露给模型。
3. .cursorrules、CLAUDE.md、AGENTS.md 如何配置才有效；与对话指令冲突时听谁的；团队是否应提交 Git？原帖回答强调规则要具体、可执行、分层且避免冗长冲突；实际优先级取决于宿主的指令层级；团队共享规则应版本化提交，个人偏好不应混入共享文件。
4. Agent 输出不符合预期时如何调试，与传统代码调试有什么区别；有哪些快速诊断经验？原帖回答要求记录完整轨迹，逐段检查输入上下文、模型决策、工具参数、工具结果和最终生成；Agent 的非确定性意味着还要固定模型参数、保存重放样本并用评测集比较。
5. 什么是 Prompt 缓存，它如何影响 Agent 成本与性能；与 RAG 是否冲突？原帖回答：缓存复用稳定前缀的计算结果，可降低长系统提示和工具定义的首 Token 延迟与成本；需把稳定内容放前、动态内容放后；RAG 提供动态知识，缓存复用稳定前缀，两者不冲突。
6. Agent 如何做灰度发布和 A/B 测试，与传统软件有何不同；如何确认 Prompt 改进不是巧合？原帖回答强调对 Prompt、模型、工具和参数做版本化及稳定分流，同时观察任务成功率、质量、成本、延迟和安全指标；需要足够样本、统计显著性和离线评测交叉验证。
可复习问题：Skill、MCP Server 和 Rules 文件如何分别形成可维护接口；Agent 的调试、缓存、灰度与实验体系如何工程化。

大模型应用开发面经（5 年经验）

原帖问题与答案：原帖汇总作者近半年多家公司实际面试，以下相关问题均未提供逐题答案。
1. LangChain、AutoGen 和 LiteLLM 分别如何使用？
2. 为什么手写 Agent 而不使用框架？
3. MCP 是什么，与 Function Call 有什么区别，是否实践过？
4. 是否了解 A2A？
5. ReAct 如何实现？
6. CoT 为什么有效，有什么缺点？
7. Prompt Caching 是什么？
8. temperature、top-p、top-k 分别是什么，不同场景如何设置？
9. RAG 是��么，最难的部分是什么？
10. 文档切割策略有哪些，如何避免切断语义？
11. 什么是多路召回？
12. 文档如何存储，粒度多大，使用什么数据库？
13. 为什么使用图数据库？
14. 是否比较过向量数据库，Qdrant 的性能、数据量和瓶颈如何？
15. 如何减少大模型幻觉？
16. 微调与 RAG 各有什么优缺点？
17. 如何量化检索效果和回答效果？
18. 如何做任务拆分，为什么拆，效果如何提升？
19. Text-to-SQL 如何实现并提高准确率？
20. 为什么以及如何润色 Query？
21. Code Generation 如何实现并保证准确性？
22. 如果重新设计系统会怎么做 Replan？
23. Workflow 效果如何量化？
24. 介绍自己的 Agent 项目。
25. 长短期记忆如何实现、存储和使用，粒度如何选择？
26. Function Call 如何实现？
27. Agent 项目最大的难题是什么，如何提升效果并降低延迟？
28. 端到端延迟如何优化？
29. Single-Agent 与 Multi-Agent 有哪些设计方案？
30. 反思机制如何实现，为什么需要它？
31. 如何看待当前 LLM 应用的趋势和方向？
32. 为什么使用 WebRTC，它与 WebSocket 有什么区别？
33. 如何保证 Agent 服务高可用和稳健？
34. LLM 服务并发过高时如何处理？
35. 如何评估项目的实际落地效果？
可复习问题：Agent 框架与协议如何选型；RAG、Workflow、Memory 与 Reflection 如何量化效果；Agent 服务如何优化延迟、并发与高可用。

简历/岗位材料

企业级 AI 智能体项目 Super Agent

信号：
1. 原帖项目使用 Vue 3、TypeScript、Vite 构建前端，后端采用 Java 17、Spring Boot 3、Spring AI/Spring AI Alibaba，并组合 MySQL、PGVector、Elasticsearch、Neo4j、Redis、MinIO 和 Kafka。
2. 项目把用户输入处理为五步前置编排、三层执行器路由、三级知识路由和双通道检索，并明确实现歧义澄清、问题改写、Parent-Child 块聚合、RRF、Rerank、证据预算与无证据短路。
3. Agent 工程点包括 ReAct 循环、Checkpoint、MCP 动态工具发现、安全沙箱、调用次数上限、工具重试与兜底、三种会话记忆、集群级会话锁及全链路可观测。
可追问方向：前端如何呈现三层执行器、检索证据和工具调用轨迹；Vue 3 客户端如何管理流式对话、Checkpoint 与会话恢复；调用预算、重试、会话锁和无证据短路如何共同避免死循环、重复处理与幻觉。

2026-07-22 12:08 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：0 条；新增简历/岗位材料：0 条。
数据来源：本次无新增原帖。

本次没有新的高相关材料。

2026-07-24 12:09 | Firecrawl 牛客前端 Agent 同步

本次检索词：site:nowcoder.com 前端 "AI" "一面"；site:nowcoder.com 前端 "大模型" "二面"；site:nowcoder.com 前端 "MCP" 面试；site:nowcoder.com 前端 "工作流" 面试；site:nowcoder.com "智能体平台" 前端；site:nowcoder.com "大模型应用" 前端招聘
新增面经：2 条；新增简历/岗位材料：0 条。
数据来源：https://www.nowcoder.com/feed/main/detail/b98c9db8c09b4120b38aeb3cb65f178c；https://www.nowcoder.com/feed/main/detail/844b4fb4257345608054e55b378c2a34。

面经

前端面试：5 个高频 AI 问题与前端向回答

原帖问题与答案：
1. AI 大模型会取代前端吗，前端的核心价值是什么？原帖回答：AI 会重构工作方式，但交互体验、业务理解、性能优化、工程架构、跨端兼容、安全和用户体验仍由前端把控；前端会转向与 AI 协作并聚焦复杂决策。
2. 前端如何接入大模型，常用方案有哪些？原帖回答：可由后端封装模型接口、前端负责流式渲染与对话交互；也可使用 WebLLM、Transformers.js 在浏览器运行轻量模型，或封装 AI 搜索、智能提示等通用组件；前端还要处理 SSE/WebSocket、上下文、加载态和异常兜底。
3. 项目中如何用 AI 提升前端开发效率？原帖回答：用于生成基础页面、表单、表格、动画代码，辅助编写正则、工具函数、Hooks 和接口类型，支持代码审查、Bug 定位与性能优化，并把重复工作交给 AI、由开发者把控复杂逻辑和架构。
4. 前端如何实现 AI 流式对话的打字机效果？原帖回答：使用 SSE 或 Fetch 流式读取后端分块内容，通过 ReadableStream 接收并渲染 chunk，配合防抖、中断、重发、异常重试和虚拟列表处理体验及长对话性能。
5. AI 给前端带来了哪些新产品形态？原帖回答：智能表单、AI 设计稿转代码、智能客服或对话助手、语音交互与可视化界面、AI 低代码生成模块，以及按用户行为调整主题、布局和内容的个性化 UI。
可复习问题：
1. AI 大模型会取代前端吗，前端的核心价值是什么？
2. 前端如何接入大模型，常用方案有哪些？
3. 项目中如何用 AI 提升前端开发效率？
4. 前端如何实现 AI 流式对话的打字机效果？
5. AI 给前端带来了哪些新产品形态？

蚂蚁大安全前端一二三面面经

原帖问题与答案：以下相关问题原帖均未提供答案。
1. 实习项目中的大模型部分是什么？
2. 有哪些大模型相关科研或学习经历，做过哪些 AI 和前端结合实践？
3. 是否做过大模型硬件推理加速，是否训练过模型？
可复习问题：
1. 实习项目中的大模型部分是什么？
2. 有哪些大模型相关科研或学习经历，做过哪些 AI 和前端结合实践？
3. 是否做过大模型硬件推理加速，是否训练过模型？

2026-08-05 | 牛客秋招提前批同步（人工检索）

本次检索背景：2026-08-05，正值 2027 届秋招提前批窗口（拼多多 7.6 开、百度 8 月初笔试、快手快Star/联想/米哈游/OPPO 2027 已开）。
新增面经：10 条；新增简历/岗位材料：7 条。全部带来源链接。
同步方式说明：与之前 Firecrawl 定时同步不同，本次为人工 web_search + 页面抓取，面经正文以抓取到的完整题目为准。

面经（2026 年 7-8 月最新）

吉比特前端实习面经 2026.7.9（前端工程师精选面经合集内）

原帖问题与答案：以下问题原帖均未提供答案。
1. 之前实习/学习中印象深刻的经历
2. vue2 和 vue3 响应式的具体区别与原理
3. 从输入 URL 到浏览器渲染的完整过程
4. 重绘和重排、以及分别发生在渲染哪个阶段
5. 避免重绘重排的优化手段
6. AI 在工作中怎么运用、如何打造 AI Harness 工程
7. Agent 的组成是哪些
8. MCP 和 Skill 的区别
9. MCP 由哪几部分组成、怎么开发
10. 场景题：金融网页需要快速更新（不及时更新损失巨大），作为前端怎么做（作者坦言没答好）
可复习问题：MCP 组成与开发、Agent 组成、AI Harness 工程化叙事。

快手主站 2026 秋招前端二面（发布于 2025-09，26 届秋招参考）

原帖问题与答案：以下问题原帖均未提供答案。
1. 事件循环相关代码输出分析
2. 如何判断元素是否在视口
3. 浏览器 DevTools 中 Performance 面板有什么用
4. 如何提升首屏加载速度
5. Vue 的 nextTick 有什么用
6. 如何实现缓存
7. 项目相关
8. 从零设计一个弹窗组件考虑什么、自定义样式怎么做
9. 项目中为什么同时用 Vite + Webpack
10. 函数式/面向对象/过程式编程的区别
11. 手撕：拍平数组并去重排序、括号匹配
12. 如何学习新技术栈、印象深刻的学习经历
可复习问题：组件设计题、构建工具并存的原因、手撕数组与括号匹配。

菜鸟 26 秋招前端二面（纯场景题）（发布于 2025-11）

原帖问题与答案：以下问题原帖均未提供答案。
1. 复杂 B 端「创建物流订单」页面的组件架构与状态管理设计
2. 拖拽排序、动态增删表单项的实现思路
3. 「天眼」物流大屏：ECharts/AntV G6/L7 选型 + 海量数据渲染性能
4. H5 包裹实时轨迹（地图+时间轴）设计、与高德地图交互
5. 驿站站长工作台 PC 端首页加载慢的排查优化（考虑 B 端特点）
6. 高实时性数据更新方案：轮询/WebSocket/SSE 优劣分析
7. 对菜鸟业务的了解、前端核心技术挑战
可复习问题：B 端组件架构、可视化大屏选型与性能、实时数据通道选型。

字节前端风控一面（含作者复盘）（发布于 2026-03）

原帖问题与答案：以下问题原帖均未提供答案，作者附带答题复盘。
1. 盒模型参数、box-sizing
2. 多列布局用什么渲染方式（grid vs table）
3. Tailwind 与传统 CSS 最大区别、tailwind 缺点
4. Vue2/Vue3 最大差异（defineProperty/Proxy）
5. 浏览器缓存工作方式（Cache-Control/ETag、强缓存 vs 协商缓存、304）
6. 跨域、CORS、同源策略（协议/域名/端口、ACAO/ACAC、Cookie 携带）
7. CSRF
8. Cookie vs JWT（作者复盘：JWT 是 base64 明文+签名，不是密文）
9. EventLoop 宏任务/微任务/rAF + 代码输出题（顺序 1432）
10. html 中 async/defer 的含义
11. Vite 开发环境为什么快（ESBuild、按需编译）
12. Tree Shaking 机制与一票否决情况（CJS 动态导入、全局副作用）
13. 手撕：多层嵌套数组展平
14. base 地、实习时长、到岗时间；反问环节仓促，最终挂了
可复习问题：缓存控制头细节、JWT 明文签名机制、Tree Shaking 失效场景。

前端大厂高频面试真题（最常见版）（发布于 2026-03）

原帖按六大类汇总，均未提供答案：JS 基础（闭包/this/原型链/Promise/宏微任务/防抖节流）、浏览器网络（URL 全过程/渲染/HTTP 握手/缓存/跨域）、Vue 响应式与 React Hooks+Fiber、工程化（Webpack/代码分割/tree shaking/LCP/FCP/首屏/移动端适配）、手写（Promise/防抖节流/深拷贝/call-apply-bind/去重 flat）、场景题（定位卡顿白屏/虚拟列表/弹窗组件/监控错误捕获）。
可复习问题：无新增考点，适合做自检清单。

拼多多 2027 届校招笔试真题+解析（开发/算法/数据分析/前端全方向）（2026-08-03 发布，网申至 8.23 截止）

原帖为 2027 届笔试真题复盘贴，覆盖前端方向；正文题目以图片呈现，无法从文本逐项核验，标记 uncertain。

百度 2027 届校招笔试真题+解析（2026-08-05 当天发布，算法+后端方向）

原帖为笔试复盘贴，题目以图片呈现，标记 uncertain。

Agent 开发岗最新学习技术总结（全站热榜第 3）

信号：核心刚需为 Python+FastAPI 搭 Agent 后端、RAG（混合召回/重排/Agentic-RAG/GraphRAG）、LangChain+LangGraph；侧面反映 27 届 AI 岗位能力要求。

腾讯 WorkBuddy 实习内幕（全站热榜第 10）

信号：腾讯 WorkBuddy 实习的面经、薪资、转正避坑点合集。

AiCoding 真的是万能解法吗？（2026-07-30）

信号：AI 生成代码”看起来对、跑起来不对”的踩坑讨论（业务上下文缺失、字段约束未知、系统上下文不感知），对「面试中如何评价 AI 辅助开发」类必问题有参考价值。

简历/岗位材料（2026 年最新）

2026 校招新变局：如何搞定 AI 筛简历

信号：AI 筛简历（NLP 语义理解/结构化提取）已替代 70% 以上基础人筛；语义理解能区分「优化了接口速度」与「API 延迟从 500ms 降至 50ms」；技术栈需形成闭环（写 RAG 就要有向量库/Embedding/LangChain 配套）；真实性校验成为筛选维度。

简历模板分享·按岗位划分直接套用

信号：前端版含技术栈写法 + 项目亮点提炼方式；回复「模板」获取。

长得再好看，简历写得烂也是达咩（面试官看简历习惯）

信号：白底简洁、校招一页（社招最多两页）、不写无关证件/兴趣、实习经历匹配度优先、总分形式自我评价放第二 part。

2026 大厂校招避坑全攻略

信号：招聘节奏提前（7 月提前批）、弱化学历重实战（项目/实习权重超 50%）、投递「精」比「多」重要 10 倍、AI 岗位成主角（文中具体占比为作者个人观察，标记 uncertain）。

27 届简历求锐评 / 27 届前端简历求评价

信号：牛客简历板块当前活跃讨论，可参考别人的被批点与改��。

2026 年大厂前端面试手写题库已开源（2.3k star）

信号：JavaScript HOT 100（Promise 系列、flat、call/apply/bind、深拷贝、发布订阅等），中大厂突击用。

2026-08-05 | AI 流式专题：SSE 解析四层管线（参考答案，interview-drill 沉淀）

适用：SSE vs WebSocket、fetch+ReadableStream 自实现解析类问题。百度/快手/美团/阿里云 Agent 面经高频追问点。

速记

SSE 基于 HTTP 单向推送，EventSource 原生自动重连 + Last-Event-ID 续传，但只能 GET 且不能自定义 header；业界用 fetch + ReadableStream 自解析以支持 POST 与鉴权。解析器按「字节→文本→行→事件」四层管线设计，每层只处理自己那层的不完整状态。

四层管线

字节→文本：TextDecoder 必须传 { stream: true }（内部缓存未完成多字节序列，如 你 的 E4 BD / A0 分到两个 chunk 时），否则半个字符变 � 永久损坏；结束后 decoder.decode() flush 尾部。
文本→行：buf += decode(u8, {stream:true}) 后 split(' ')，最后一段永远留回缓冲（可能是半行）。
行→事件：状态机维护 field/value，空行 line==='' 即事件结束，组装派发后重置；兼容 \r （Windows 服务端，否则事件永不结束）；data: 多行以拼接；: 开头为注释行忽略；id: 更新 lastEventId。
断线续传：lastEventId 是应用层事件游标，不是 TCP seq 字节偏移；EventSource 原生自动携带 Last-Event-ID 重连，fetch 自实现要手动在重试请求头加 Last-Event-ID，且 lastEventId 必须放解析器作用域（循环外）持久化。

易错点清单

#	坑	后果
1	decode 忘传 stream:true	半个 UTF-8 字符→`�`
2	split 后末段不留缓冲	丢行/丢事件
3	不处理 `\r
`	空行判定失效，事件永不结束
4	多 data 行不用
拼接	多行 JSON 压扁，parse 失败
5	lastEventId 不持久化	断线后续传失效
6	不检查 res.ok / res.body 为空	4xx 也进流式循环，静默吞错

参考实现骨架

const decoder = new TextDecoder('utf-8');
let buf = '', field = '', value = '', lastEventId = '';
const reader = res.body.getReader();
while (true) {
  const { done, value: u8 } = await reader.read();
  if (done) break;
  buf += decoder.decode(u8, { stream: true });
  const lines = buf.split('
');
  buf = lines.pop();
  for (const raw of lines) {
    const line = raw.replace(/\r$/, '');
    if (line === '') { if (field) { onEvent({id: lastEventId, event: field, data: value}); field=''; value=''; } continue; }
    if (line.startsWith(':')) continue;
    const i = line.indexOf(':');
    const f = i === -1 ? line : line.slice(0, i);
    const v = i === -1 ? '' : line.slice(i+1).replace(/^ /, '');
    if (f === 'data') value = value ? value + '
' + v : v;
    else if (f === 'id') lastEventId = v;
    else field = f;
  }
}

关联

与 [[流式 UI 的数据完成态与播放完成态分离]] 同一思想：解析层处理「不完整状态」，渲染层处理「完成态才升级」。
关联面经：快手 AI Agent 二面（打字机/流式）、百度一面（SSE 重连/断点续传）、阿里云一面（ReadableStream 跨 chunk 缓冲）。

流式 Markdown 截断渲染（参考答案，interview-drill 沉淀）

适用：阿里云/得物/MiniMax/快手面经高频题「流式代码块/公式截断如何避免闪烁」。

结构宣言模板：“我会从四个维度处理：渲染分层、升级时机、频率控制、安全。“（开放题先给框架再展开）

① 流式期间渲染什么（分层渲染：缓冲区 + 增量解析）

原理：Markdown 解析器假设输入完整；未闭合代码块、未配对公式符、未结束链接语法都会误判 → 界面跳变。
已闭合块：增量解析（remark/markdown-it 流式）正常渲染，输出 AST 增量；未闭合尾部：pending 标记进缓冲区，走轻量层（纯文本 / 简化 pre），不高亮不解析；公式未配对不触发 KaTeX 显示原文。

② 升级渲染时机（sealed 触发 + 块级 dirty）

数据流结束（source sealed）或某块刚闭合时触发升级：应用高亮、公式、链接、表格。
块级 dirty 标记 + 稳定 key（消息 id + 块序号）：只重渲变化块，避免整条消息重建 DOM 与滚动跳动。
高亮/公式升级时初始化，先清理旧实例防重复初始化。对应 [[流式 UI 的数据完成态与播放完成态分离]]。

③ 频率控制（合并提交）

不逐 token 触发框架渲染：文本缓冲 + requestAnimationFrame / 16-50ms 合并一次提交。
memo / 稳定 props 防止无关块重渲染；打字机走轻量 textContent，重量渲染低频；超长文档叠加虚拟列表。

④ 安全（AI 输出全程视为不可信输入）

流式尾部按纯文本（textContent），不用 dangerouslySetInnerHTML；完成态白名单清洗：react-markdown + remark-gfm + 过滤 javascript: 协议、禁 script/自定义标签。
未闭合代码块 pending 不高亮，避免 highlight.js 对不完整代码抛错或输出错乱。

边界与易错点：升级渲染与打字机动画的节奏分离（完成态才硬切）；高亮重复初始化；超长文档滚动锚定。

Agent 前端 / AI 前端面经专题（2026.08 搜集）

搜集时间：2026-08-07 | 来源：牛客网面试经验中心 + 掘金/思否/卡码笔记等外部搜索关联：[[AI-Design-Workflow与Design-System一面题库]]

米哈游 Agent 开发提前批一面（2026.08.01）

来源：牛客岗位方向：Agent 开发 | 浏览 3276 | 偏 workflow agent + RAG

平时怎么使用 AI coding？
如何保证 AI coding 生成代码的质量？
AI 幻觉产生的原因是什么？
DeepSeek、OpenAI 这类模型 API 有哪些接口？
如何解决模型回答的事实性和忠实度问题？
Skill 和 MCP 有什么区别？
Skill 有哪些特性？
个人 agent 项目深挖（围绕 Agent 的实际流程展开）
手写题（二选一）：
- A：Python 实现一个装饰器，用于打印 log
- B：ACM 模式：输入若干组（售价、售出、买入），输出售价最低的前4个，且售出和买入都不为 0

总结：项目深挖占比高，Agent 实际流程是核心考点。

字节剪映 Agent 一面（2026.08.03）

来源：牛客岗位方向：Agent 开发（剪映）| 浏览 6.2W 创作者 | 前40min 项目拷打 + 后20min 手撕

项目深挖（极硬核，代码级追问）

Workflow 中的原子性在项目里怎么体现？
- 职责单一：每个节点只做一件事
- 执行可回滚：Saga 模式，每个节点配补偿操作
Workflow 是怎么搭建的？开源还是自研？
- 自研 + 开源组件混搭（Airflow 思想 + 业务层自研）
- 节点注册机制：统一接口，启动时动态加载
Workflow 每个节点是怎么控制的？
- eval 机制：每个节点执行完过一个 eval 判断
- EvalResult: passed/score/reason/next_action(continue/retry/abort/branch)
- 重试策略按失败类型：超时→指数退避；输出质量→调 prompt；依赖服务→检查状态
Eval 的评判标准和结果怎么影响后续？
- 格式校验（pydantic schema）
- 质量评分（BERT-base 或 LLM-as-Judge）
- 业务规则（视频时长≤60s、标题非空等硬规则）
- eval 结果作为 feature 输入后续节点
Workflow 和 Agent 的 Loop 各自怎么设计？业务中的 Workflow 怎么往 Loop 上设计？
- Workflow Loop = 确定性循环（循环次数已知）
- Agent Loop = 不确定性循环（ReAct 模式，Agent 自己决定）
- 设计思路：Loop 作为 Workflow 的特殊节点（外层 Workflow 兜底可控，内层 Loop 灵活）
视频上行 Workflow 优化
- 并行化：转码和封面生成无依赖，并行执行
- 异步化 + 事件驱动
- 节点粒度超时和降级（LLM 审核慢 → 降级到规则引擎，准确率损失≤3%）
长任务稳定性 / 微服务设计
- Checkpoint 机制：节点执行前后保存状态到 Redis+DB
- 挂了从上一个 checkpoint 恢复

SSE 流式聊天 + Agent 工作流面经（2026.08.05，小厂前端）

来源：牛客浏览 474 | 关键词：SSE、Agent 工作流编辑器、AI 护城河

SSE 流式聊天怎么保证大段文本吐出页面不卡顿，组件重渲染怎么优化？
为什么用 monorepo（代码复用，拆分子包）
Fiber 的引入解决了什么
React 19 新特性 / Vue 了解程度
Three.js 离屏渲染？切换场景怎么防止内存泄漏？
用过 vibe coding 工具吗
CSS 居中 / flex:1 是哪三个属性缩写 / animation transforming
宏任务与微任务
Node.js
（换面试官）用过什么 vibe coding 工具，怎么保证代码符合要求？
如果让你设计一个 AI Agent 的工作流可视化编辑器，你觉得应该怎么设计？
前端在 AI 领域的护城河
流式返回数据频繁，怎么优化内容
接到不明确需求怎么做

拼多多 pdd 前端提前批一面 + 二面（2026.08.07）

来源：一面牛客 | 二面牛客

一面

项目的虚拟滚动怎么做的
手写一个 fps 函数
…（更多项目深挖）

二面（全程拷打项目，不问八股）

收集类名：['a',{'b':true},{'c':false},['d',['e']]] ===> 'a b d e'
写一个倒计时组件
手写 Promise.all
首屏优化怎么做的
三级缓存怎么做的
图片格式
懒加载怎么做的
怎么获取真实用户的首屏时间（非实验室数据）
有没有沉淀 AI 工作流或者 Skill
实习时公司用 AI 有没有做什么限制

腾讯 TEG 前端一面（2026.08.05，日常实习）

来源：牛客 | 浏览 912

垂直居中 / CSS 布局（flex、grid）
BFC 是什么
闭包、防抖、节流
代码输出题
更新代码后用户显示旧的，怎么排查？
缓存类型有哪些？
跨域问题
事件循环
防抖
TypeScript 和 JavaScript 的关系
interface 和 type 的区别
算法：链表排序

字节前端一面（2026.08.05）

来源：牛客 | 浏览 717

npm 理解：type/module/main/版本号差异
ESM 和 CJS 区别
Vite 和 Webpack 差异
设计模式有哪些
手撕单例模式、发布订阅模式
布局 flex
事件循环
Nginx 跨域怎么解决

蔚来汽车前端一面（2026.08.05）

来源：牛客 | 提到 Agent

自我介绍
我看你提到了学习后端和 Agent，你未来更倾向于前端、后端还是算法等等岗位？
…（后续问题待展开）

字节抖音生活服务前端二面（2026.08.05，日常实习）

来源：牛客纯聊天风格：兴趣爱好、怎么学前端、个人优缺点

外部搜索：Agent 开发岗面经汇总（2026）

以下为 web_search 搜集的外部资源，内容为摘要 + 链接。

字节 Agent 开发四面面经（卡码笔记）

来源：卡码笔记 21 道大模型面试题，从 Prompt 到 Agent 到 MCP，四面全覆盖。考点：ReAct、Function Calling、MCP、RAG、SFT/RLHF/DPO、Agent Skill、混合路由优化。

字节/腾讯/阿里 Agent 开发岗面试横评

来源：发现AI | dormon.net

字节：技术密度最高

Agentic CPT → SFT → RL 三阶段训练
工具调用死循环处理（最大迭代 + 循环模式检测 + 异常回流 + 人工降级）
React 框架细节

腾讯：工程协议通才

Agent 生态理解广度
协议标准到工程落地

阿里：架构设计 + 业务落地

Tools / Workflow / Agent 三者区别
架构格局 + 落地细节

2026 AI Agent 岗面试三 offer 复盘（思否）

来源：SegmentFault 三个岗位：某电商 AI Agent 开发 / 某大模型独角兽 Agent 应用高工 / 某云计算厂商智能应用开发专家

一面核心考点

Agent 框架选型（为什么选 LangChain 而非其他）
工具调用机制设计
错误处理与重试策略

二面核心考点

Agent 记忆系统设计
多 Agent 协作架构
评估与调试方法论

大厂 Agent 面试核��知识地图（掘金）

来源：掘金五维度考点：推理框架 / Agent 工程 / RAG / 工具调用 / 评估调试核心问题：你的

Agent 前端面经高频题目 + 参考答案（2026.08 整理）

基于米哈游/字节剪映/pdd/腾讯/小厂等真实面经提炼，按维度分组

Q1：Skill 和 MCP 有什么区别？

Skill：面向 Agent 的能力封装单元。一个 Skill 包含 system prompt + 工具定义 + 输出格式约束 + 执行策略，Agent 根据任务自动路由到对应 Skill。

自包含、可组合、有边界
适用场景：Agent 内部能力复用，团队间共享标准化能力包

MCP（Model Context Protocol）：面向模型与外部工具/数据源的通信协议。定义了模型如何发现、调用、接收外部服务的标准接口。

协议层、解耦、生态
适用场景：跨系统工具集成、第三方服务接入

核心区别：Skill 是「能力的封装」（what to do），MCP 是「能力的通信协议」（how to connect）。一个 Skill 内部可能通过 MCP 调用外部工具，但 Skill 本身还包含 prompt 策略、eval 判断、输出约束等 MCP 不管的东西。

Q2：AI 幻觉产生的原因？如何解决事实性和忠实度问题？

原因：

训练数据含错误/过时信息，模型学到的是统计模式而非事实
自回归生成追求语义连贯而非事实准确，前文偏离后会「自洽地编下去」
知识截断 + 概率采样引入随机性

解决方案：

RAG：检索知识库注入 context，基于真实文档回答
Grounding：强制引用来源，输出标注出处
Eval + 事后校验：NLI 蕴含检测，不达标则重试/拒绝
CoT + 自我反思：先推理再回答
结构化输出：JSON schema 约束，减少自由发挥
多轮验证：Agent 调搜索工具交叉验证关键事实

Q3：SSE 流式聊天怎么保证大段文本不卡顿？组件重渲染怎么优化？

卡顿根因：每个 token 触发 setState → React 重渲染 → 频率极高（每秒几十次）→ 主线程阻塞。

优化方案：

层级	手段	原理
数据层	useRef 累积 + rAF batch flush	不是每 token 触发渲染，攒一批再更新
渲染层	React.memo / 局部更新	只重渲染最后一条流式消息，历史消息不动
渲染层	直接操作 DOM（逃逸 React）	流式阶段直接 textContent 追加，流结束再同步 state
Markdown	增量解析（incremark 等）	不全文 re-parse，只解析新增部分
Markdown	延迟渲染复杂块	代码高亮/表格等流结束再渲染，流中只展示纯文本
CSS	content-visibility: auto	历史消息跳过渲染计算
React 18	startTransition	markdown 重渲染标记为 transition，用户交互优先
进阶	Web Worker	markdown 解析放 Worker，主线程只负责 DOM

最佳实践：ref 累积 + rAF 批量 flush + 最后一条消息单独组件 + 增量 markdown 解析器。

Q4：设计一个 AI Agent 工作流可视化编辑器

三层架构：

UI 层：DAG 画布 + 节点面板 + 属性配置 + 调试面板（React Flow / X6）
模型层：Workflow DSL（节点/边/条件/循环的 JSON 定义）
执行层：调度引擎 + eval 网关 + checkpoint + 日志

关键设计点：

节点类型：LLM 节点、Tool 节点、条件分支、循环（for/Agent Loop）、人工审核节点
DSL 设计：编辑器操作 → JSON/YAML workflow 定义，可导入导出、版本管理
实时调试：节点状态可视化（pending/running/success/fail）、断点暂停、手动修改 context
变量系统：节点间 context 传递，可视化数据流向
eval 集成：每个节点可配置 eval 规则，不通过时红色标记 + 自动重试/分支

Q5：前端在 AI 领域的护城河

核心论点：AI 能生成代码，但不能替代「人机交互的设计与工程」。

复杂交互体验：流式渲染/打字机/token 动画/多模态混排——纯前端工程问题
性能与体感：60fps/首屏秒开/弱网降级——AI 生成代码难以自动处理
可视化编排：Agent 工作流编辑器/节点画布/拖拽连线——高度定制 UI 交互
端侧 AI：WebGPU/WASM 跑小模型/浏览器端 embedding——前端是唯一触达用户设备的层
产品感知：loading 时机/流式 vs 一次性/错误态展示——产品+设计+前端的交叉领域

Q6：Workflow 中的原子性怎么体现？怎么回滚？

原子性：

职责单一：每个节点只做一件事
状态不可分割：要么完全成功，要么完全失败

回滚——Saga 模式：每个节点注册 execute() 和 compensate()，失败时逆序执行补偿操作。

Checkpoint：每个节点成功后保存 checkpoint 到 Redis+DB，挂了从最近 checkpoint 恢复。

Q7：Workflow Loop vs Agent Loop？怎么融合？

	Workflow Loop	Agent Loop
确定性	确定的（循环次数/条件明确）	不确定的（Agent 自行决定）
控制者	编排引擎	Agent 自身（ReAct: think→act→observe）
终止条件	固定条件/计数器	Agent 判断完成 / max_iterations

融合：Agent Loop 封装为 Workflow 的特殊节点。外层 Workflow 保证可控（超时兜底、日志可观测），内层 Agent Loop 保证灵活性。

Q8：工具调用死循环怎么处理？

四道防线：

最大迭代次数：硬上限 max_iterations
循环模式检测：连续 N 次相同 tool + 相同参数 → 强制退出
异常回流：把状态 + 历史 action 重新交给 Agent，注入提示「你陷入了循环，换一种方式」
人工降级：异常回流后仍循环 → 暂停通知人工介入

Q9：eval 机制怎么设计？

三类评判标准：

格式校验：Pydantic / JSON Schema（字段是否齐全）
质量评分：LLM-as-Judge / BERT 打分（score ≥ 阈值）
业务规则：硬编码（duration ≤ 60s / title not empty）

结果影响后续：

passed=True → 继续
retry → 调整 prompt 后重试（最多 3 次）
branch → 走备选路径
abort → 终止 + 告警

进阶：eval score 作为 feature 注入下游节点 context，后续节点感知「前序质量」并调整策略。

Q10：流式返回数据频繁更新的工程优化（补充）

双缓冲：实时追加 buffer + 已渲染快照，rAF 时 swap
Web Worker：markdown 解析放 Worker
content-visibility: auto：历史消息跳过渲染
React 18 startTransition：非紧急渲染让位用户交互

Q11：DeepSeek / OpenAI 模型 API 有哪些接口？

接口	功能
/chat/completions	对话补全（tools/stream）
/embeddings	文本向量化
/images/generations	图片生成
/audio/transcriptions	语音转文字
/audio/speech	文字转语音
/files	文件管理
/fine-tuning/jobs	微调任务
/assistants	Assistant API
/responses	Responses API（新，支持 tool + 上下文）

DeepSeek 特色：兼容 OpenAI 格式 + FIM 补全 + reasoning_content 字段（思维链）。

Q12：如何保证 AI Coding 生成代码的质量？

Prompt 工程：明确约束写入 system prompt（语言/框架/风格/测试）
Context 管理：只喂相关代码文件，减少噪声
生成后校验：ESLint/TypeCheck + 生成测试跑一遍 + diff 过 CI
人工审核：AI 生成 → 人 review → merge
限制作用域：每次只生成一个函数/组件
沉淀 Rule：团队编码规范写成 AI 可读的 rule file（cursor rules 等）

Q13：有没有沉淀 AI 工作流或者 Skill？（pdd 二面原题）

答题思路（结合自身经验）：

把常用 Agent 操作封装为 Skill（如：代码审查 Skill、部署 Skill、文档生成 Skill）
每个 Skill 有标准接口：system prompt + tool list + output schema + eval 规则
工作流沉淀：将多 Skill 编排为可复用的 workflow template（如：PR 流程 = lint Skill → review Skill → test Skill → merge）
版本管理：Skill 有版本号，团队内共享 registry
效果度量：记录每个 Skill 的成功率/耗时/token 消耗，持续优化

计算机网络谢希仁

Mon, 15 Sep 2025 08:07:58 GMT

互联网的重要基本特点什么样的网络是计算机网络 Internet 和小写的 internet 的区别互联网的组成互联网中核心部分中起特殊作用的是路由器作用是分组转发三种交换技术与特点

物理层

物理层的主要作用: 透明的传输比特流

确定与传输媒体接口有关的特性

计算机网络性能指标

速率

速率指的是本地机器端口能够发送数据的单位时间. 比如说 Mac 的雷电接口, 可以传输 30Gbps 的数据. 速率的单位是

带宽

带宽通常有两种意义

某个信号具有的频宽宽度. 信号的带宽是指信号所包含的各种不同的频率成分所占据的频率范围
表示网络中某通道传送数据的能力, 即表示单位时间内网络中某信道所能通过的 最高数据率

在计算机网络中指的带宽通常是指第二种, 单位是 bit/s 也就是 “比特每秒”

数字数据转数字信号称为编码数字数据转为模拟信号称为调制

常用的编码方法

曼彻斯特编码计算方式: 标记 位中心 的向上/向下曲线. 上 0 下 1
差分曼彻斯特编码计算方式: 标记 位开始边界 的跳变, 有跳变表示 0, 无跳变表示 1.

基本的带通调制方法

将各种数字基带信号转换成适于信道传输的数子频带信号的过程称为调整 (modulation)

常用的信道复用技术

频分复用 (FDM): 所有用户在同样的时间占据不同的带宽资源
时分复用（TDM): 所有用户在不同时间占据同样的频带宽度（分时不分频）
统计时分复用 (Statistic TDM): 改进的时分复用, 能

网络层

4.6 互联网的路由选择协议

4.6.1 有关路由选择的几个概念

1. 理想的路由算法

路由选择协议的核心就是路由算法

理想的路由选择算法的特点:

算法必须是正确和完整的。正确: 沿着各路由表所指引的路由, 分组一定能够达到目的网络和目的主机。
算法在计算上简单。
算法能够自适应通信量和网络拓扑的变化。即自适应性, 在网络中的通信量发生变化时, 算法能够自适应的改变路由以实现各链路的负载均衡。
算法应具有稳定性。在网络通信量和网络拓扑逐渐稳定的情况下, 路由算法应收敛于一个可接受的解, 而不应使得路由不停地变化。
算法应该是公平的。即平等的处理每个分组 (除去少数优先级)
算法应该是最佳的。应当能够找出最好的路由, 使分组平均时延最小, 网络吞吐量最大。但相对于网络的可靠性来说, 往往应该舍去一定的性能而保持稳定。

从路由算法能否自适应来划分, 只有两大类。即 静态路由选择策略 与 动态路由选择策略。静态路由选择也叫 非自适应路由选择、动态路由选择也叫 自适应路由选择。

静态路由选择（对于简单的小网络, 完全可以采用静态路由, 用人工配置每一条）
1. 优点: 简单和开销小
2. 缺点: 不能及时适应网络的变化。
动态路由选择（适用于复杂的大网络）
1. 优点: 能够较好的适应网络状态的变化
2. 缺点: 配置较为复杂, 开销较大

2. 分层次的路由选择协议

互联网(Internet) 采用的路由选择协议主要是自适应的、分布式路由选择协议。由于以下两个原因, 互联网采用分层次的路由选择协议:

互联网的规模非常大。如果让所有的路由器知道所有的网络应该怎样到达, 则路由表将非常大。而路由之间交换信息的带宽就会让互联网的通信链路饱和。
许多单位不希望外界了解自己单位网络的布局袭击和本部门采用的路由选择协议。但同时希望连接到互联网上

为此, 可以把整个互联网划分为许多较小的自治系统 (autonomous system), 一般记为 AS

AS 是在单一技术管理下的许多网络、IP 地址以及路由器, 而这些路由器使用一种自治系统内部的路由选择协议。每一个 AS 对其他 AS 表现出的是一个单一和一致的路由选择协议策略。这样, 互联网就把路由选择协议分为两大类, 即:

内部网关协议 IGP(Interior gateway protocol), 即在一个自治系统内部使用的路由选择协议, 这与互联网中的其他自治系统选择什么路由选择协议无关, 目前这类路由选择协议使用的最多是是 RIP 和 OSRF协议（IS-IS 也有）。
外部网关协议 EGP(External Gateway Protocol), 若源主机和目的主机处在不同的 AS 中, 那么在不同自治系统 AS 之间的路由选择就需要使用外部网关协议 EGP, 目前使用最多的外部网关协议是 BGP 4 的版本。

两个自治系统之间的路由选择也叫做 域间路由选择(interdomain routing), 而在自治系统内部的路由选择叫做 域内路由选择(intradomain routing)

4.6.2 内部网关协议 RIP

1. RIP 协议的工作原理

RIP（Routing Information Protocol）是内部网关协议 (IGP) 中最先得到广泛应用的协议, 中文译名是 路由信息协议。RIP 是一种分布式的 基于距离向量的路由选择协议, 最大的优点是简单。

RIP 协议要求网络中的每一个路由器都要维护从 它自己 到其他每一个目的网络的距离记录（距离向量）。定义如下:

从一路由器到直接连接的网络的距离为 1. 从一主机非直接连接的网络的距离定义为所经过的路由器数 +1 。 +1 是因为达到目的网络后就进行直接交付。而到直接连接的网络的距离已经定义为 1.

距离称为“跳数”（hop count）, 每经过一个网络, 跳数就 +1, 显然, 一个分组经过的网络数越少, 那么这条路由就越好, 即越短越好。 RIP 允许一条路径最多只能包含 15 个网络, 因此, 当距离等于 16 时即相当于不可达。可见 RIP 只适用于小型互联网。

RIP 不能在两个网络之间同时使用多条路由。RIP 选择一条具有最少网络数的路由（即最短路由）, 哪怕还存在另一条高速（低时延）但网络数较多的路由

RIP 协议与下一节的 OSPF 协议, 都是分布式路由协议。他们的共同特点就是每一个路由器都要不断地和其他一些路由器交换路由信息。

我们一定要弄清以下三个要点:

和哪些路由器交换交换信息?
交换什么信息?
在什么时候交换信息

RIP 协议的特点是:

仅和相邻路由器交换信息。如果两个路由器之间通信不经过另一个路由器, 那么这两个路由器就是相邻的。RIP 协议不与不相邻的路由器交换信息。
路由器交换的信息是本路由器当前所知道的全部信息, 即自己现在的路由表。也就是说, 交换的信息是:“我到本自治系统中所有网络的（最短）距离, 以及到每个网络应经过的下一跳路由器”。
按固定的时间间隔交换路由信息, 例如, 每隔三十秒。然后路由器根据收到的路由信息更新路由表。当网络拓普发送变化时, 路由器也及时向相邻路由器通告变化后的路由信息。网络中的主机虽然也运行 RIP, 但只被动的接受路由器发来的路由信息。

在路由器刚刚开始工作时, 路由表是空的。然后路由器就检查各个端口, 得到直接相连的几个网络的距离（1）. 接着, 每个路由器也只和数目有限（较少）的相邻路由器交换并更新路由信息。

看起来协议 RIP 有些奇怪，因为“我的路由表中的信息要依赖于你的，面你的信息又依赖于我的。”然而事实证明，通过这样的方式一一“我告诉别人些信息，而别人又告诉我一些信息。我再把我知道的更新后的信息告诉别人，别人也这样把更新后的信息再告诉我”，最后在自治系统中所有的节点都得到了正确的路由选择信息。在一般悄况下，协议 RTP 可以收敛，并且过程也较快。“收敛”就是在自治系统中所有的节点都得到正确的路由选择信息的过程

路由表中最主要的信息就是: 本路由器到某个网络的最短距离, 以及应经过的下一条的地址。路由表更新的原则就是找出每个目的网络的最短距离。这种更新算法又称为 距离向量算法。下面是 RIP 使用的距离向量算法定义:

2. 距离向量算法

对 每一个相邻路由器发送过来的 RIP 报文, 执行以下步骤

将地址为 X 的相邻路由器发来的 RIP 报文, 修改此报文中的所有项目: 把 '下一跳'字段中的地址都改为 X,并把所有距离字段+1 。每个项目都有三个关键数据, 即: 目的网络 Net, 距离 d, 下一跳路由器 X.
对修改后的 RIP 报文中的每一个项目, 进行
1. 若原来的路由表中没有目的网络 Net, 则把该项目添加到路由表中¹
2. 若在, 则查看本路由器中下一跳路由器的地址。
  1. 若下一跳路由器地址是 X ,则把收到的项目替换原路由表中的项目²
  2. 若不是（即 到目的网络 Net,但下一跳路由器不是 X）,
    1. 若该项目的距离 d 小于路由表中的距离, 则进行更新。³
    2. 否则什么都不做
若 3 分钟还没有收到相邻路由器的更新路由表, 则把此相邻路由器标记为不可达路由, 即把距离设置为 16
返回。

RIP 协议让一个自治系统中的所有路由器和自己相邻的路由器定期交换信息, 并不断更新路由表。使得 每一个路由器到每一个目的网络的路由都是最短的。

RIP 报文由首部和路由部分组成。在路由部分要填入 自治系统号 ASN(Autonomous System Number), 这是使 RIP 有可能收到本自治系统外的路由选择信息。还要指出目的网络地址（包括子网掩码）、下一跳路由器地址以及到此网络的距离。一个 RIP 报文最多有 25 个路由, 如超过, 必须再用一个 RIP 报文来传送。

3. 坏消息传播的慢

RIP 存在的一个问题是当网络出现故障时, 要经过较长的时间才能将此信息传送到所有的路由器。你来我往, 直到 16

4.6.3 内网网关协议 OSPF

1. OSPF 协议的基本特点

OSPF (Open Shortest Path First), 开放最短路径优先, 它是为了克服 RIP 的缺点而在 1989 年提出来的。OSPF 的原理很简单, 但实现较为复杂。 Open 表示 OSPF 不受某一厂家限制, 而是公开发表的。“最短路径优先”是因为使用 Dijkstra 提出的最短路径算法 SPF。现在使用的 OSPF 协议是第二个版本

OSPF 最主要的特征就是使用了 链路状态协议（link state protocol）, OSPF 的特点是:

向本自治系统中的所有路由器发送信息。这里使用的是 泛洪法 （向所有相邻的路由器发送信息, 收到消息的相邻路由器又给自己的相邻路由器发送此信息（但不发给刚刚发来信息的路由器））（一传十, 十传百）。这样整个区域内所有路由器都得到了这个信息的副本。
发送的信息是与本路由器 相邻的所有路由器的链路状态, 但是这只是路由器所知道的 部分信息。所谓的 “链路状态” 就是说明本路由器都和那些路由器相邻, 以及该链路的 “度量”（metric）。 OSPF 将这个度量用来表示费用、距离、时延、带宽, 等等。这些都由网络管理人员来决定, 因此较为灵活。有时为了方便就称这个度量为 “代价”。应当注意, 对于 RIP 协议, 发送的信息是 “到所有网络的距离和下一跳路由器”。
当链路状态发送变化或每隔一段时间（如 30 分钟）, 路由器向所有路由器用 泛洪法 发送链路状态信息。

由于各路由器之间频繁的交换链路状态信息, 因此所有的路由器最终都能建立一个链路状态数据库（link-state database）, 这个数据库实际上就是 全网的拓扑结构图（有点像数据结构中图的二维数组表示法）。这个拓扑结构图在全网范围内是一致的(这也称为 链路状态数据库的同步)。因此, 每一个路由器都知道全网共有多少个路由器, 以及哪些路由器是相连的, 其代价是多少, 等等。每个路由器使用链路状态数据库中的数据, 构造出自己的路由表（比如 Dijkstra 的最短路径算法）。相反的, RIP 协议虽然知道所有的网络的距离以及下一条路由器, 但却 不知道全网的拓扑结构（只有到了下一个路由器, 才能知道怎么走）。

OSPF 的链路状态数据库能够较快地进行更新。OSPF 的更新过程收敛得块是其中药有点

泛洪法：保证链路状态广告在全网几乎同步地传播，是 OSPF 快速更新的核心。
触发式增量更新：仅在链路变化时立刻泛洪最新 LSA，避免周期性的全量刷新。
序列号/寿命/校验：确保只保留最新、正确的信息，防止冗余与冲突。
分层（Area）：限制泛洪范围，进一步提升更新效率。
可靠的传输与抑制机制：防止广播风暴，同时保证每台路由器都能收到最新 LSA。

为了使 OSPF 能够用于规模很大的网络, OSPF 将一个自治系统再划分为若干个更小的范围, 叫做 区域（area）。每一个区域都有一个 32 位的区域标识符（点分十进制）。一个区域的路由器最好不要超过 200 个

划分区域的好处:

泛洪法交换链路状态信息的范围局限于每一个区域, 减少通信量
对区域进行封装, 每一个区域内部的路由器都只知道本区域的完整网络拓扑, 而不必知道其他区域的网络拓扑情况, 而交由其中一个连接另一个区域的路由器来处理。
OSPF 采用 层次结构的区域划分, 在上层的区域叫做 主干区域（backbone area）。主干区域的标识符规定为 0.0.0.0。主干区域的作用是用来连通下层的区域。
从其他区域来的信息都由 区域边界路由器（area border router） 进行概括。

在上图中, 路由器 R3,4,7 都是区域边界路由器, 显然, 每一个区域都应当至少有一个 区域边界路由器。在主干区域的路由器叫做 主干路由器(backbone router), 如 R3,4,5,6,7. 一个主干路由器可以同时是区域边界路由器, 如 R3,4,7。在主干区域内还要有一个路由器专门和本自治系统外的其他自治洗头交换路由信息。这样路由器叫做 自治系统边界路由器, 如 R6.

除了以上几个基本特点以外, OSPF 还具有下列的一些特点:

OSPF 允许管理员给每条路由指派不同的代价。例如, 高带宽的卫星链路可以设置为较低的代价, 但对于时延敏感的业务就可以设置为非常高的代价。因此, OSPF 对于不同类型的业务可计算出不同的路由。
若同一个目的网络有多条相同代价的路径, 那么可以将通信量分配给这几条路由。这叫做多路径间的负载均衡 (load balancing)

2. OSPF 的五种分组类型

OSPF 共有以下五种分组类型:

问候 (hello) 分组, 用来发现和维持邻站的可达性。
数据库描述（Database Description）分组, 向邻站给出自己的链路状态数据库中的所有链路状态项目的摘要信息。
链路状态请求（Link State Request）分组, 向对方请求发送某些链路状态项目的详细信息。（得到上一步的摘要后）
链路状态更新（Link State Update）分组, 用泛洪法对全网更新链路状态。这种分组是最复杂的, 也是 OSPF 协议最核心的部分。
链路状态确认（Link State Acknowledgedgment）分组, 用来对链路更新分组的确认。

省略一些… 太多了（我靠）

表明这是一个新的目的网络 ↩
用新的路由信息替换掉旧的路由信息 ↩
若新的路由距离大于原来的, 则会花费更多时间, 所以只更新更短的 ↩

Linux学习

Mon, 08 Sep 2025 07:36:55 GMT

- 短命令可组合 -- 长命令不可组合

[当前用户名@主机名当前路径]$ $ 普通用户 # root 用户

在 Shell 中 . 代表当前目录, 在操作当前目录下的文件时非常好用

cp -i(强制覆盖) /etc/NetworkManager/conf . 移动至当前目录

chmod <number> or <option>

option: [u(user) || g(group) || o(other) || a(all)]+(rwx)
number: 八进制下的 rwx 权限 (111 = 7 110 = 6) 每一位代表每个组

Strapi踩坑指南

Mon, 14 Jul 2025 10:03:48 GMT

最近接了一个单子前端已经写好但是需要一个简单 CMS 来管理数据,最终选择了 Strapi 主要是看中了他 Headless CMS + RestFul API+开源的优势. 接下来简单说一下我遇到坑与难点

populate 深层数据

比方说我们有这样一个结构

interface Person{
	name:string,
	age:number,
	components:Components(可以理解为对象)
}

那么自动生成的链接就是 GET /api/person/documentId 和 /api/persons 在默认情况下返回的数据是不带components的,也就是下面这样

// /api/persons
[
{
name,
age,
}...
]

在官方文档中提供了一个简单办法,那就是 /api/persons?populte=* 这样的话就可以获取到所有第二层的数据(就是说非基本数据,官方以层级来解释). 但是这个方法有两个缺点，第一个 URL 不干净了(悲),第二个就是 只能获取到第二层的数据 无法处理多层嵌套的情况比方说， Strapi 目前提供了三种Content-Type分别是 集合类型(Collection Types),单个类型(Single Types)和组件(Conponents). 而基本类型中又有引用(稍后提到)和 Component 组件这两种类型可以在当前的类型中引用或嵌入一个对应类型的对象,日常开发中可能嵌套多层. 虽然官方也提供了基于上述方法populate的扩展比如/api/persons?populate[A][populate][underAObjectName] 但是还是太麻烦了.好在官方是支持自定义处理方法的,

What is custom handle method?

在/src/api/类型名/controllers/ 目录下有这样的工厂代码

import { factories } from "@strapi/strapi";

export default factories.createCoreController("api::overview.overview", {});

如果我们想自定义返回的结构与层级,又不想改 url,可以直接在第二个参数里写入对应路由的方法,例如

import { factories } from "@strapi/strapi";

export default factories.createCoreController("api::overview.overview", {
  async create(ctx, next) {
    let data = await strapi.documents("api::overview.overview").create({
      populate: {
        //这个是引用类型的数据

        records: {
          populate: {
            // 等同于 {populate:*}

            image_url: true,
          },
        },
      },
    });
  },

  async find(ctx, next) {},

  async findOne(ctx, next) {},
});

by the way, 媒体库中的图片在返回的时候也是只返回documentId,要想直接获得 url 需要加一个 populate

自定义路由

这个比较简单. 只需要在 /api/[自定义名字]/controllers 和 /api/[自定义名字]/router写入对应的

场景	路径
小型功能	`grill-with-docs` → `to-spec` → `implement`
大型、多 session	`grill-with-docs` → `to-spec` → `to-tickets` → 每票 `implement`
巨型、未知多	`wayfinder`（决策票）→ `research` / `prototype` → 清了再 `to-spec`
Bug	`diagnosing-bugs` → `tdd` 回归 → 修 → `code-review`
架构治理	`improve-codebase-architecture` → `codebase-design` → `grill-with-docs`
别人丢来的 issue	`triage` → 就绪后 `implement`
答案在别人那里	`to-questionnaire` → 收回来再 `grill-with-docs` / `to-spec`
上一句没听懂	`wait-what`
只有人能点的步骤	`wizard`

Feichuan's Blog

Buffin Assistant 过程区折叠设计

For future Claude

Buffin Assistant 过程区折叠设计

需求演进（用户原话要点）

已知客观事实（代码证据）

正文判定的三种失效形状（Claude 评审发现，抽查属实）

status 链路现状

组件现状

设计决策

1. 折叠单位与判定：尾部反向扫

2. 触发条件

3. 组件与动画

4. 状态与开关

与 Codex 协议层 phase 方案的关系

边界情况清单

实施范围

相关页面

来源

MengTo Skills Handbook

For future Claude

MengTo Skills Handbook

一句话定义

与其他 skill 体系的边界

哲学（作者四条，决定怎么用）

本机安装状态（2026-07-29 核验）

文件夹契约

正确使用方法

核心心智（3 条）

方法 A：单 skill 触发（最常用）

方法 B：流水线串联（设计复刻 / 灵感生产）

方法 C：实现型 skill（写/修代码）

方法 D：约束型 skill（把审美说清楚）

方法 E：日常灵感资产生产

三类 skill 的使用差异

场景路由表（先查这张）

旗舰 skill 深读

1) video-to-superprompt

2) landing-page

3) design-first-ui-prompting

4) daily-ui-inspiration-capture

5) gsap

你给 agent 的标准说法（可复制）

分析参考

写转化页

修动效

压提示词

日常灵感

全量 skill 目录（118）

Codex 工作流（17）

Media（2）

UI（1）

Game development（19）

Web design（79）

转化与整站

运动与滚动叙事

WebGL / Canvas / 3D

CSS 细节与材质

布局系统

视觉风格 / 页面气质

叙事/产品专题页型

什么时候不该用

质量验收清单（通用）

推荐学习顺序（本机已安装后）

第 1 天：建立“规格 > 感觉”

第 2 天：参考 → 资产

第 3 天：实现一层

第 4 天：闭环

若做游戏

与本 vault / 本机 agent 的协作建议

已知限制 / uncertain

来源

相关页面

Codex App 过程输出与最终回答分层

For future Claude

Codex App 过程输出与最终回答分层

已知客观事实

1. App Server 的层级是 Thread、Turn、Item

2. Item 有独立生命周期

3. Assistant message 自带 phase

1) `video-to-superprompt`

2) `landing-page`

3) `design-first-ui-prompting`

4) `daily-ui-inspiration-capture`

5) `gsap`