AI 写代码越来越强之后，工程圈的焦虑点悄悄换了位置：不再是「AI 会不会写」，而是「我们有没有把它用对、并且真的落地到生产」。

这两年冒出来的两个热词正好对应这两个焦虑：SDD（Spec-Driven Development，规格驱动开发） 管「怎么让 AI 做对的东西」；FDE（Forward Deployed Engineer，前沿部署工程师） 管「怎么让 AI 真的在客户的生产环境跑起来」。一个是方法论，一个是角色；看似不搭，其实是同一件事的两面。

这篇把它们讲清楚：是什么、为什么现在火、具体怎么做、以及有哪些坑。

术语歧义说明（先排除）：SDD 也常被当作「Software Design Document（软件设计文档）」、FDE 也有人指「Frontend Development Engineer（前端开发工程师）」。本文按 2025–2026 年 AI 工程语境写：SDD = Spec-Driven Development，FDE = Forward Deployed Engineer。若你问的是另一种含义，告诉我我另写一篇。

文中行业数据来自公开报道，统计口径与时点不一，已尽量标注来源，引用请以原文为准。

上一篇聊了低代码的发展史与 AI 时代的平台格局，那是「行业面」。这篇落到具体框架：国内最常被摆在一起比较的五个开源项目——amis、formily、tmagic、h5-Dooring、lowcode-engine，它们其实不在同一个赛道，硬比「谁更强」是错的问法。

这篇做三件事：先把它们分类（不同类的框架解决不同问题）→ 逐家拆定位与技术路线 → 给一张选型决策表和几个必踩的坑。文中的版本号与开源协议都来自 npm 元数据实测（2026-09），其余事实标注了来源。

一句话先给结论：做中后台页面 → amis；做复杂表单 → formily；做运营活动页 → tmagic / h5-Dooring；想自己造一个低代码平台 → lowcode-engine。

「低代码」这个词已经被喊了十多年，从「人人都能开发」的许诺，到被程序员吐槽「复杂了就做不了」，再到 2021 年前后的祛魅与退烧。而到了 AI 时代，它换了个马甲又回来了——Dify、Coze Studio、n8n 这些「编排 LLM 和工具」的平台，本质上就是新一代低代码平台，只是画布上的节点从「表单、审批」换成了「大模型、工具、知识库」。

这篇聊三件事：低代码的发展史、它当下的真实现状，以及 AI 时代这几家代表平台各自是什么、怎么选。

文中多数市场数据来自公开报道，统计口径与时点不一（尤其 star 数），已在文中标注时点，引用时请以官方为准。判断类观点是我的个人看法，欢迎拍砖。

在写用前端技术栈写 Agent那几篇时，我把「工具调用循环」讲清楚了，但一直没单独讲它的出处。这个循环不是工程实践中自然长出来的，它有篇明确的论文：ReAct。

这篇把 ReAct 讲透：它是什么、为什么重要、格式长什么样，然后用零依赖的纯 Node 手写一个真的能跑的 ReAct 智能体。最后是重点——我在本机真实跑出来的四个坑，其中有两个非常隐蔽：一个是不报错、只是静默返回空，另一个是模型会伪造工具的返回结果，然后基于伪造值自信作答。

声明：本文所有代码均在本机真实运行，走 DeepSeek 的 Anthropic 兼容端点（deepseek-v4-flash，一个推理模型）。所有输出、stop_reason、token 数都是实测值，不是我编的示意。

最近在写大模型 API 的流式（SSE），发现不少人分不清 SSE、WebSocket、长轮询的区别。这篇把 SSE（Server-Sent Events，服务端推送事件）单独拎出来讲透：它是什么、长什么样、什么时候用它，最后给一个原生 Node、零依赖的最小案例，跑起来给你看真实数据流。

上一篇文章盘点了一圈开源的写作 Agent（InkOS、Webnovel Writer、oh-story、chinese-novelist）——它们的共同特点是：能力强，但要么要命令行、要么要懂 prompt 工程，是为「愿意折腾的人」准备的。

这次换一个样本：OpenWrite 小说助手，一款面向普通网文作者的商业客户端。它把「AI 长篇连载」做成了下载即用、点鼠标就走的桌面产品，同时还对外开放了一套可自定义的 Skill 技能系统。这篇先花一小节带过它是什么、怎么用，然后从功能的角度逆推它的架构思路——不是搬运官方文档，而是基于教程里能看到的线索（内置 novel-writer skill 的完整 prompt、FAQ 对记忆机制的自述、各个操作流程），反推它做了哪些关键设计决策。

声明：本文非 OpenWrite 官方技术文档，属「产品架构读解」。凡教程里明确写到的我标注为事实；推断处会说明理由。依据的内部源文档：《OpenWrite 小说助手 - 使用教程》（见仓库 source/）。

AI 写小说这件事，已经从「让大模型一次性吐一章」进化成了「一套能长期连载、记得住设定、守得住伏笔的工程系统」。围绕这个需求，社区长出了一批 写作 Agent / Skill——有的是一套多 Agent 接力管线，有的是 Claude Code 的一键技能包。

这篇盘点 4 个有代表性的：InkOS、Webnovel Writer、oh-story-claudecode、chinese-novelist-skill。它们各自回答了「AI 写长篇」里不同维度的问题。

上一篇《TanStack Query 实战》里，一个收藏星标靠 useQuery / useMutation 把「缓存、竞态、取消、同步」全接管了，一行都没手写。但那篇留下一个反向的问题：如果不引入框架，这些事自己怎么写？

「库帮你做了」和「你知道它做了什么」是两回事。这篇把前端请求里最头疼的几件事——状态管理、缓存、去重、竞态、取消、重试——用纯手写的方式逐层拆开，讲清每一种的一般解法。理解了这些，再回头看 TanStack Query / ahooks，你就能看懂它们「为什么这么设计」。

上一篇《前端 RUM：真实用户性能监测》讲清了 RUM 是什么、怎么用浏览器的 Performance API 采数据。但「采集」只是开始——真正的工程难题在后面：数据怎么不丢地送出去、怎么存得又快又省、怎么从海量原始数据里榨出结论、怎么把结论变成报表和告警。

这篇把「自建 RUM」当成一条完整流水线来拆，深入每一个环节：采集 → 传输 → 接入 → 存储 → 聚合 → 分析 → 报表。每一层都给出取舍和可落地的方案。

「useEffect 是渲染后异步执行的副作用」——这句话对，但不完整。同样是 useEffect，useEffect(fn)、useEffect(fn, [])、useEffect(fn, [a]) 在 commit 阶段触发的时机和条件完全不同；再叠上 useLayoutEffect，时机又变了。

本文从 React 源码（open/react）出发，把「不同使用方式 → 不同 flag → commit 阶段不同挂载时机」这条链讲清楚。