我是一个 Full-Stack Builder。
从 Java、Web、移动端，到 Linux、嵌入式，再到今天的 AI Agent，我一直在做的事情其实没有变：把一个真实的问题，变成能够运行的软件。
技术一直在变，但把这些经历放在一起，我越来越觉得：
其实我一直在做同一件事——理解一个真实的问题，把它变成软件，然后把软件真正交付出去。
从 Java 和 CRM 开始
职业生涯最早接触的是 Java 和 JavaScript，在企业 CRM 项目里做数据库设计、JDBC、JSP 和 JavaScript 应用开发。
但真正让我受益的，并不只是这些技术。
企业项目通常需要直接面对客户：和客户的项目负责人沟通，接触实际使用系统的员工，有些项目还要到客户现场进行实施和开发。
客户不会告诉你：
“请帮我设计一个三层架构。”
他们通常只会告诉你：
“我们现在的业务是这样做的，希望系统能够这样工作。”
然后开发者需要自己把这些需求转换成数据库、后端逻辑、页面和部署环境。
现在回头看，这种工作方式其实已经很接近今天大家所说的 FDE（Forward Deployed Engineer）：
理解业务 → 解决问题 → 开发系统 → 部署实施 → 获取反馈 → 持续迭代。
只是当时还没有 FDE 这个名字。
Java 这门底子其实一直没扔。 最近做的 spring-rbac、spring-order、spring-harness 三个 Spring 项目，让我把过去的企业软件经验和现在的 AI 工程实践重新连接了起来——从 RBAC 鉴权、订单一致性，一路做到 AI Agent 底座。
换工作：开始面对不同的客户和技术
后来换了工作，跳槽到一家新加坡老板的公司。
一些开发需求来自新加坡总部。
Java SSH、PHP CodeIgniter、Flex……
Flex 那套富客户端的思路——组件化 UI、数据绑定、跑在容器里——放到今天看，就是 Electron 和 Tauri。后来我把这条线真正落了地，用 Electron 做了一串桌面应用：ai-workbench、DataPulse、SpecPulse，以及后面会提到的数字人应用 Firefly。Tauri 这条线也起了头——Rust + React 的桌面工具脚手架 desktop-kit，正在开发中。
其中还主导过瑞士客户的租房网站项目——那时我已经担任技术经理。
也是在这个阶段，我开始越来越多地阅读英文技术文档。
这段经历让我逐渐意识到：
软件开发真正困难的地方，往往不是掌握某一种语言，而是面对一个陌生的问题，快速找到合适的解决方式。
技术只是工具。
客户、业务、环境和交付目标，才是问题本身。
从 Web 走向网络与嵌入式
后来进入中兴通讯，开始接触网络路由相关工作，也负责过 3G 网管平台的告警模块，以及包括告警箱在内的联调测试。
再后来进入 Actiontec，进一步接触 Linux、C、Openfire、XMPP、VoIP、Cordova 混合应用以及路由器相关的嵌入式开发。
这段经历让我第一次真正进入软件和硬件交界的世界——软件不再只是运行在服务器上的 Web 应用，而是运行在网络设备和嵌入式 Linux 系统中。
其中一个让我印象很深的项目，是用 C 在设备端生成 Web UI 组件，再交给浏览器做页面组装——从今天看，这和后来的服务端渲染、组件化 UI 颇有相似之处。这个思路后来也促使我重新思考嵌入式 Web 与 SSR 的结合——c-cgi 就是这个想法的一次尝试。
在 Actiontec 后期，我也开始直接接受美国总部 CTO 的技术协调和项目发布安排，参与跨地域的项目协作——也是在这里，我形成了一个朴素的工程视角：
软件不是孤立存在的，它最终一定要运行在某个真实的环境里，并解决某个真实的问题。
React 出现以后：重新理解前端
后来进入创业团队，开始负责前端开发管理。
那个阶段，Facebook React 和 React Native 还处于比较早期的阶段。
我们开始尝试 React、React Native，并开发社交应用 Eengoo。
团队 CTO 来自 Amazon。
这也是我比较早接触现代前端工程体系的一段经历——而 React Native，则把从 Cordova 开始的跨平台移动线接了下去。
这条线也没有停在当年——最近的 contacts-assistant 就是用 Expo + React Native 构建的本地优先 AI 通讯录应用。
回头看，这条技术线是：
Cordova → React → React Native → 小程序 → Node.js
技术形态发生了很大的变化。
但对于 Builder 来说，变化其实很简单：
产品怎么变化，就换一种方式把它建出来。
Node.js：Full-Stack 能力逐渐成形
在携程工作的阶段，我开始大量使用 Node.js。
其中一个比较有意思的项目，是使用 Node.js 对原有的 .NET 攻略网站进行现代化改造。
当时并没有直接把原来的 .NET 系统推倒重写。
而是让 Node.js 去解析原有的 .NET 模板标签，并负责页面渲染。
也就是说：
新系统不一定要消灭旧系统，也可以先建立一层兼容和连接。
这种渐进式迁移的思路，在今天依然非常常见。
当然，那时候说的 Full-Stack，更多是指用 JavaScript 一门语言打通前后端。今天的全栈概念已经宽得多——Python、Java、Go、Rust 这些后端语言，同样是全栈版图的一部分。这个扩展，在我后来的经历里也一直在发生。
与此同时，我开始开发自己的项目脚手架工具。
从 NSBP-CLI 到后来的 NSGM-CLI，把项目初始化、工程配置等重复工作逐渐抽象成工具。
后来我才发现，这其实是自己一直以来比较明显的一个习惯：
遇到重复的问题，就想办法把它抽象成工具。
这个习惯后来也自然延伸到了自动化和 AI。
在携程时，我负责过 trip.com blog 的富文本编辑器。最近重新想起这段经验，是因为想到一个问题：跟 AI 聊天，输入为什么基本只能是普通文本？字体、颜色、大小，作者想传达的感觉，还有夹杂在正文里的图片和视频，都在「普通文本」里丢掉了。
我想让模型真正「读懂」富文本：文本结构序列化成 Markdown，样式和排版渲染成快照交给视觉模型去「看」，图片和视频走多模态输入。这个想法也成为我最近正在尝试的一个方向——把当年做编辑器的经验，接到 AI 时代的问题上。
AI 数字人：一段短而密集的 3D 交付
离开携程后，我在全特做了一段全栈开发。
项目是迪士尼度假区的 AI 数字人客服系统。我们用 Next.js + React 搭前端，Three.js + react-three-fiber 做网页端 3D 数字人渲染和口型/表情同步，接入 Azure ASR/TTS 与 FunASR 双通道语音，再通过 Socket.io 打通语音输入、打断，以及声音、动作、表情的三路同步。
知识库管理端的前端直接复用了前面提到的 nsgm-cli。
作为一次阶段性的探索，项目在一个月内上线了第一个可运行版本，之后陆续解决了 iOS / Android 的 WebGL 和音频兼容问题。
这段经历虽然短，但让我提前摸到了后来 AI 时代的真实手感：
AI 项目的交付，难点从来不在某一个单点技术，而在于把渲染、语音、知识库这些能力组装成一个真正能跑的产品。
这个方向我没有停下来——后来把数字人做成了自己的应用 Firefly · 萤火数字人，技术细节展开写过两篇复盘：用 React Three Fiber 打造会对话的 3D 数字人、firefly-studio 架构复盘。
支付验证：重新回到复杂的真实业务
之后参与 PayPal 相关项目。
包括客户身份验证平台（CIP），以及支付系统升级相关工作。
在 AI Payment Upgrade 项目中，参与从传统的 NVP、SOAP、Payment V1 向 Orders V2 REST / SDK 方向迁移。
这类项目的特点是：
代码只是其中的一部分。
还需要处理 Docker 环境、Python 自动化、Playwright、测试、验证、报告，以及各种真实业务场景下的兼容问题。
例如，把原本需要人工完成的验证过程变成自动化流程。
这让我重新体会到早期做企业项目时的那种感觉：
一个真正的工程问题，从来不是“写完代码就结束了”。
而是：
环境能不能跑？
流程能不能执行？
结果能不能验证？
问题能不能定位？
最终能不能交付？
这条「真实业务 → 自动化 → 验证」的主线，后来直接延伸成了我的 Agent 工程化方向——软件最终要运行在真实环境里，Agent 也一样。
这也让我重新思考一个问题：如果软件工程本身可以被拆解、执行和验证，那么 Agent 是否也可以用同样的方式参与其中？
PSE（Planner–Specialist–Evaluator）这个思路，就是在回答这个问题的过程中逐渐形成的——后来我在多个主流 Agent 框架中一一实践，写成系列：文档即状态机、LangGraph、LlamaIndex、AutoGen、CrewAI。
AI：不是重新开始，而是重新组合
后来 AI 开始快速进入软件开发。
很多人会把 AI 看成一次新的技术转型。
对我来说，它更像是一次能力重组。
过去的工作方式大致是：
人理解需求 → 人设计 → 人写代码 → 人测试 → 人部署
而现在逐渐变成：
人理解需求 → 人设计系统 → Agent 执行 → Tool 提供能力 → Workflow 组织任务 → 自动验证 → 人最终确认
我开始关注的，也不再只是「怎么调用一个模型」，而是怎么让模型真正参与软件构建：
Agent 负责什么？
Tool 如何提供能力？
Skill 如何沉淀经验？
Workflow 如何组织任务？
Harness 又如何让整个过程变得可控、可验证？
这些问题看起来都很新。
但它们指向的依然是一个非常老的问题：
如何让软件更有效地完成真实任务。
从写代码，到构建能够参与写代码的系统
这也是我现在理解 Vibe Coding 的方式，展开写过一篇《我越来越少逐行看 AI 写的代码》。
Vibe Coding 对我来说，并不是：
“我不会写代码了，让 AI 帮我写。”
恰恰相反。
它让我开始关注更高一层的问题：
- 整个系统应该怎么设计？
- Sandbox 如何控制执行环境？
- UI 如何让这些能力真正被使用？
过去，我主要通过代码直接构建软件。
现在，我开始尝试构建一种新的软件：
一个能够参与软件构建的软件系统。
这也是我持续开发 Resolve Studio、Resolve TUI、Resolve Harness 等项目的原因。
Resolve Studio 不是为了再做一个 Agent 聊天界面。
我更想解决的是：能不能把这些已经验证过的 Agent、Tool、Skill、Workflow 组织起来，变成一个真正用于软件构建的工作台？
我越来越感兴趣的，不只是：
怎么写一个应用？
而是：
怎么构建一个能够帮助人持续构建应用的系统？
我可以成为自己的客户
做开源项目时，这种感觉很强烈：没有签约的公司，也没有明确的客户，需求从哪来？
我可以成为自己的客户。
一个反复遇到的问题，可以变成一个项目；一个重复的工作，可以抽象成 Tool；一个可以复用的经验，可以沉淀成 Skill、组织成 Workflow。
而当这些项目被开源以后，真实使用者的问题和场景，会自然地流回来，于是形成一个循环：
需求 → 构建 → 发布 → 使用 → 反馈 → 再构建
这和最早做客户项目没有本质区别——变的不是做事方式，而是客户的形态：从签约的公司，变成一群真实但不特定的使用者。
FDE：一种我熟悉的工作方式
现在市场上出现了 AI FDE、AI Builder、Forward Deployed Engineer 等新的岗位。
这些名字对我来说并不陌生。
因为很早以前做 CRM 的时候，我就在做：
客户沟通 → 理解需求 → 设计系统 → 开发 → 部署 → 获取反馈 → 迭代。
我对 FDE 感兴趣，并不是因为这是一个新的岗位名称，而是因为它背后的工作方式，我其实已经做了很多年：进入真实环境、理解问题、快速构建、验证结果，再把解决方案沉淀成可以复用的工具。
当然，典型 FDE 所要求的长期驻在客户现场、频繁出差和持续救火，并不一定是我希望长期选择的工作形态。我看重的是这种工作方式本身，而不是非要去某一个岗位。
后来交付的东西变成了 Web、移动应用、嵌入式系统、支付系统和身份验证平台。
现在则开始变成：
Agent、Tool、Skill、Workflow。
所以我并不认为自己是突然从传统软件开发“转型”到了 AI。
更准确地说：
软件的形态一直在变化，而我一直在扩大自己的建造能力。
我一直是一个 Builder
如果非要给这段职业生涯一个标签，我的答案是：
Builder
以前建造的是应用。
后来建造的是工具。
现在开始建造能够建造软件的系统。
Keep Building.
如果你手上有一个足够真实、但还没有清晰答案的问题，或者正在搭一个想把 AI 真正落地的团队，欢迎找我聊聊。把模糊的问题变成能运行、能验证、能交付的东西——这是我一直在做、也最擅长的事。
完整的职业经历整理在我的线上简历。
AI Agent 工程化，真正需要补的是什么？
不是急着学某个框架，而是把工程能力平移过来：验证方法论（如何给可执行结果写验收标准）、环境治理（Docker/沙箱让 Agent 输出可复现）、以及自动化思维（把重复的人工步骤变成脚本和测试）。我在 PayPal 支付验证里实践的 PSE 三角色循环，本质就是把“人写代码 → 人验证”提升为“人设计系统 → Agent 执行 → 自动验证”。
为什么把这些工具做成开源项目？
很多项目就是从“自己反复遇到的问题”生长出来的——装环境、抓热点、写总结、做验证。开源之后，反馈回路从“单一客户”变成“一群真实使用者”，他们的问题和需求推着工具继续进化。工作方式还是最早做客户项目的那一套，只是“客户”的边界更开放了。
发表回复