随笔 on 姚玉亮的网络日志

一次聊需求，三仓同落地：我的 superpowers 全栈开发工作流

Thu, 27 Aug 2026 09:00:00 +0800

一个跨三个仓库的需求

我最近接到一个挺典型的需求：数据集管理里，“文档核验"这个动作要留痕：谁核验的、什么时候核验的；核验完还要能按数据集分页翻历史记录；管理后台加一个"核验记录"入口，点击弹列表，下拉就能一直加载；上层的知识库问答服务也要同步暴露这个列表接口。

这个需求横跨三个仓库：数据集管理服务、数据管理后台、知识库问答服务。

以前这种需求在我这儿是这么过的：拉群对齐需求 → 各写各的需求文档 → 前后端各自开工 → 联调时发现字段名对不上、分页参数叫法不一样 → 返工。现在我用 Claude Code 的 superpowers 工作流走了一遍完整流程，发现整个链条可以压缩成四步：brainstorming 聊需求 → 方案对比 → 写 spec → 生成实施计划。

flowchart LR
 A["brainstorming 聊需求"] --> B["方案对比"] --> C["写 spec 落盘"] --> D["生成实施计划"] --> E["add-dir 挂三仓并行落地"]

第一步：先探索代码，再开口问

superpowers 的 brainstorming 第一步不是问"你想要什么”，而是先看项目上下文：路由注册在哪、handler 怎么写的、DAO 用的什么 ORM、前端页面结构、有没有现成的分页组件。

我让 Claude 把两个仓库都翻了一遍，结论：

数据集管理服务是 Hertz + GORM 的架构，核验逻辑在文档服务的 revise 方法里，文档表上已经有一个"核验状态"字段，核验时会把它置为"已核验"
管理后台是 React + antd，代码里已经有现成的 useInfiniteScroll 下拉加载 hook，数据详情页结构也很清晰

这一步的价值在于：问题基于真实代码，而不是基于想象。我不用花十分钟给 Claude 讲架构，它自己读出来的上下文，比任何人的转述都准确。比如"核验状态字段已经存在"这个事实，直接影响了后面的设计：记录表和状态字段是两回事，但很多人第一版设计会混在一起。

第二步：一次只问一个问题

brainstorming 最反直觉的一条规则是：一次只问一个问题。

我一开始也觉得慢。但跑下来发现，需求是逐层展开的：先问"核验记录需要存哪些字段"，确定存核验人和核验时间；再问"列表按什么过滤"，确定按数据集 ID；再问"前端入口放在哪"，确定放数据详情页。每个答案都会修正下一个问题，一次抛十个问题，模型只能靠猜排优先级，猜错一半就得返工。

对话节奏大概是这样的（简化示意，实际要比这细致）：

我：核验记录需要展示哪些字段？ Claude：先确认一下，除了核验人和核验时间，要不要把核验前后的版本号也存下来？这会决定表结构。我：先只存核验人和核验时间，跑通第一版。 Claude：好。那列表接口按数据集 ID 过滤、支持分页返回，这个方向对吗？

一次一个问题看着慢，其实最快：每个问题都建立在之前答案的基础上，方向不会歪。

第三步：给 2-3 个方案，而不是直接开写

需求聊清楚之后，brainstorming 会要求给出 2-3 个实现方案对比。这个需求当时有两个主流方案：

方案 A：复用现有的行为记录表。那张表是 JSON 半结构化的流水表，加一种行为类型就能记录，不用建新表。
方案 B：新建独立的核验记录表。字段干净，查询直接，列表接口就是一条简单的 WHERE dataset_id = ? 分页查询。

我选了 B。核验记录是高频查询的业务动作，独立表让列表接口简单直接；方案 A 虽然少建一张表，但查列表要拆 JSON，而且行为流水表的数据量会持续膨胀，不适合做业务查询的底座。

选完方案，设计按块确认：表结构一块、接口定义一块、前端改动一块、上层同步一块，确认完再写进 spec 文档，落盘到 docs/superpowers/specs/ 目录下。这份文档是后续实施计划的输入，也是代码评审时对照的依据：评审不再靠记忆，而是对着 spec 逐条核对。

第四步：add-dir 多项目，前后端同时动

设计获批后进入实施阶段。Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，这个需求一次挂了三个目录：

数据集管理服务：建表、在核验接口里写记录、新增分页列表接口
管理后台：数据详情页加入口、列表抽屉、下拉加载
知识库问答服务：同步暴露列表接口

多目录的意义不只是"能改多个仓库"，而是 AI 同时持有两边的上下文：字段名、接口路径、分页参数天然一致，联调成本趋近于零。以前前后端联调要查半天"到底叫 page 还是 current"，现在在计划阶段就把契约定死了，代码照着写就行。

几个真实的感受

一次一个问题反直觉，但确实是最快的提问方式。需求是逐层展开的，一次一个才能保证每个问题都有价值。
探索比提问重要。让 AI 先读代码，它问出来的问题才有质量；不探索就问，问的都是网上搜得到的通用问题。
设计文档不是走流程。跨仓库改动里，它是唯一让所有人（包括几周后的你自己）对齐的锚点。代码评审对着 spec 审，比对着记忆审靠谱一个量级。
YAGNI。AI 很容易过度设计，比如顺手提一句"要不要顺便做个操作审计"。不需要，砍掉。每个设计阶段都要主动问：这个功能现在真的需要吗？

建议

如果你也在用 AI 写代码，别只停留在"让它写函数"的层面。试试把流程也交给它：从一个小需求开始，完整走一遍 brainstorming → 方案对比 → spec → 计划 → 实现。第一次会不习惯"一次只问一个问题"，但跑完一个需求你就会发现，多花在澄清上的半小时，会在联调阶段加倍省回来。

我的 AI 时代后端工程师成长路线

Wed, 19 Aug 2026 10:30:00 +0800

问题背景

最近有几个刚工作两三年的后端朋友问我：AI 这么火，传统后端是不是要被淘汰了？要不要转算法？我自己这两年从宠物医疗 SaaS 走到企业级 AI 数据平台，又在业余时间开源了 alchemy-furnace，刚好完整经历了从"写 CRUD"到"做 AI 系统"的转变。这些路不一定适合每个人，但都是我真走过的。

第一阶段：把后端基本功打穿

AI 应用的后端依然是后端。模型推理只是其中一环，你还要处理认证、计费、并发、数据管道、可观测性、发布回滚。这些东西 LLM 帮不了你多少。

我在某 SaaS 公司那两年半，扎扎实实干了几件"不性感"的事：把宠物医疗 SaaS 系统从 fasthttp C/S 迁到 go-zero B/S，用 gRPC + Jaeger 做微服务拆分和链路追踪，对接 AI 影像判读接口。那时候没有 LLM 帮我写代码，gRPC 拦截器、服务注册发现、MySQL 分表、Redis 分布式锁，全是一行行啃文档啃出来的。

我的建议是：如果你工作不满三年，别急着追 AI，先把下面这些东西练到肌肉记忆：

一门主力语言到能读源码的程度（我是 Go，Gin、go-zero、Gorm、Wire 这些要知道它们怎么实现的）
MySQL 索引和事务、Redis 常用数据结构、MQ 的投递语义
一次完整的微服务拆分 + 链路追踪落地经验
容器化部署和基本的 Linux 排障

这些是你日后做任何系统的地基，AI 只会放大基本功的差距，不会抹平它。

第二阶段：主动靠近 AI 工程化

2023 年底我加入新团队，本来是做统一支付平台和统一认证中心这种传统后端项目，但我主动接了数据治理服务和数据集管理服务里和 AI 相关的部分。这是我职业路径上最关键的一个选择。

我的做法不是去学训模型（那是算法工程师的赛道，后端硬转性价比很低），而是切入模型和业务之间的工程层：

数据管道：S3 预签名上传、PDF 解析、Temporal Worker 数据质量规则引擎、MySQL + StarRocks 数仓、OpenAlex 数据同步。这些是典型的后端技能，但服务于 AI 数据。
向量和检索：文档解析后的向量化、知识图谱构建、向量库选型。不需要你懂反向传播，但要懂高并发、批处理、内存控制。
LLM 网关：知识库问答服务里做统一 LLM 适配层，屏蔽 OpenAI、Azure、VLLM、HuggingFace 的差异，做多模型路由、限流、降级、token 计费。这是后端最能发挥价值的地方。
Agent 和工作流：多轮对话、light_rag、MCP 工具调用、多步任务编排。这层需要理解 LLM 的能力边界，但工程骨架依然是状态管理、超时、重试、可观测性。

这个阶段我最大的体会是：AI 工程化的核心难点不是调模型，而是让模型在一个不可靠的世界里可靠地工作。超时、幻觉、上下文溢出、供应商限流，这些问题的解法全是后端老功夫。

第三阶段：用全栈能力闭环一个产品

只会写后端，在 AI 时代会有明显的瓶颈。AI 应用的交互形态变化太快，等前端排期你就慢了半拍。我从 2025 年开始刻意练全栈，用 Claude Code 和 Cursor 独立交付前端页面。

alchemy-furnace 是第一次完整闭环：Go（Gin + GORM）做网关和多供应商适配，Python（FastAPI）做合成引擎（Promptbreeder 变异算子 + 血统追溯），Next.js 做前端，一个人三周搞定。这个项目在 GitHub 拿到 46 star 不是因为代码多牛，而是它证明了一个后端工程师借助 AI 工具可以独立交付完整产品。

我总结的 Vibe Coding 心法是：

后端契约定死再做前端（你的优势就在这）
TypeScript strict 全开，类型从 OpenAPI 生成
UI 选 shadcn/ui 这种源码可控的库，AI 生成质量高
小步快跑，每生成一块就在浏览器验证，别攒着

第四阶段：建立技术判断力

工具和框架会一直换，真正拉开差距的是判断力。这几年我刻意训练自己几件事：

选型时看权衡而不是看热度。Go 和 Python 混部选 gRPC 还是 HTTP？Temporal 还是裸 goroutine？RAG 还是 Agent？每个问题都没有标准答案，要能说出在你的场景下为什么这么选。
踩坑后写下来。我保持写博客的习惯，不是为了当博主，而是把每次排障和架构决策的思路固化下来，下次遇到类似问题能快速调用。
读优秀源码。go-zero、Gorm、Wire、eino、Temporal 的 Go SDK，读下来比看十篇架构文章有用。
做开源。alchemy-furnace 逼我把代码写得陌生人能看懂、把文档写明白，这个过程对工程能力的提升比上班写业务代码快得多。

踩坑与提醒

别被"全栈"骗了。什么都懂一点但没有一项能打穿，不如先在后端深扎。全栈是放大器，基本功为零的时候放大的是零。
别迷信新框架。今天这个 Agent 框架明天那个 RAG 库，大部分过半年就没人维护了。理解底层原理（状态机、流式、序列化、并发控制）比记住 API 重要。
别丢掉对业务的理解。我在某 SaaS 公司学到的最重要的东西不是 go-zero，而是理解医院和医生怎么用系统。脱离业务的架构是自嗨。
照顾好身体。这行是长跑，不是冲刺。

小结

AI 时代的后端工程师不是要被淘汰，而是要往上走一层：从"实现需求"变成"把模型能力工程化、产品化"。路径说起来朴素：基本功打穿，主动靠近 AI 工程化，练全栈闭环，建立判断力。我自己也还在这条路上，希望两年后回头看，这篇文章里的判断依然站得住脚。

两年八个月后端架构演进：从 SaaS 到 AI 数据平台

Tue, 19 Dec 2023 10:30:00 +0800

把这两年的技术栈摊开看，进进出出的东西不少：go-zero、Wire、Temporal、Hertz、eino……每次变化，都不是我追着潮流去的，是业务把新问题拍在面前，接住，才有下一步。

从宠物医疗 SaaS 到中台，再到 AI 数据平台，两年八个月，大概走了三段路。

先给飞行中的飞机换发动机

2021 年 4 月我加入一家 SaaS 公司，接手的第一个大项目，是把宠物医疗 SaaS 从 fasthttp C/S 架构迁到 go-zero B/S。老系统是个迭代了很多年的单体，所有医院共用一套代码、一个数据库，发版靠手动 FTP，回滚基本靠运气。

迁移动作是先按业务域拆服务：医生端、医院管理、HIS 对接、AI 影像判读各自独立，服务间用 gRPC，Jaeger 做链路追踪。go-zero 的工具链帮了大忙，.api 文件直接生成路由和代码骨架，团队上手很快。同期还做了经营数据分析平台，加上 C 端顾客小程序和 B 端管理小程序，后端用同一套微服务撑住多端。

那阵子最大的收获其实不在某个技术点上。数据双写、灰度切流、老接口兼容，这些活儿教科书不教，但每天都在做。说白了，就是学着在不停机的前提下，给飞行中的飞机换发动机。

中台教会我的，是边界

2023 年 12 月，我加入一家科技公司，一开始主导统一支付平台和统一认证中心。这两个项目和 SaaS 时代最大的区别在于：它们不是单一产品，是要给多条业务线复用的中台。

统一支付平台做了三端分离支付、订单状态机、RSA/SHA 签名的 OpenAPI、动态计费引擎和对账导出。状态机是核心。一笔订单从创建到回调成功，可能经历十几次状态跃迁，任何一个分支没覆盖到，就是资损。我的做法是用显式状态机表加幂等键，把每条跃迁写死，不给隐式状态留活路；对账用 Excelize 导出，再和渠道逐笔比对。

统一认证中心是另一种复杂度：OAuth2/OIDC、RSA 签发 JWT、SSO、多应用 AppID/AppSecret、AppRole 团队隔离、RBAC，还要支持可插拔 Provider（腾讯云 SMS/SES/Captcha），以及微信、企微、飞书登录。我用 Wire 做依赖注入，Service/DAO 分层，最后的效果是新增一种登录方式，只需要实现一个 Provider 接口。

这个阶段，我的架构审美从"能拆就拆"转向了"该合就合"。中台的价值其实在复用，但过度抽象会把所有业务方绑死。

边界划在哪里，比用什么框架重要得多。

核心矛盾换成了长流程

从数据治理服务开始，工作的性质又变了。S3 预签名上传、PDF 解析、Temporal Worker 数据质量规则引擎、MySQL 加 StarRocks 数仓、OpenAlex 学术数据同步。这套东西的核心矛盾，不再是"高并发业务"，而是"长流程数据管道"。

Temporal 把我从手写状态机和重试里解放出来：Activity 失败自动重试，Workflow 状态持久化，比 go-zero 时代裸写 goroutine 加补偿逻辑稳太多。后来做数据集管理服务，Hertz 做接入，eino 和 pond 跑高并发的文档解析、向量化、知识图谱构建，存储用 GaussDB 和 MongoDB。那是我第一次认真处理 GPU/CPU 混合调度和大文件内存控制，好在 pond 的 worker pool 把并发度压在了下游能承受的范围内。

再往后是知识库问答服务，做企业级 LLM 知识库问答，问题又换了一茬：多轮对话、light_rag、MCP 工具调用、多模型路由。统一 LLM 适配层把 OpenAI、Azure、VLLM、HuggingFace 的差异屏蔽掉，业务侧只认一个 ChatCompletion 接口。我看着它从一个能跑的 DEMO，长成能接公司多个业务线的平台，中间踩的坑比前两年加起来还多。

没变的是这几件事

技术栈从 go-zero 扩到 Hertz、eino、Temporal，架构从微服务扩到数据管道和 AI 平台。但有几件事，从头到尾没变：

可观测性要先于功能。没有日志、指标、trace 的系统，跑得再快也不敢上线。
状态和边界是复杂度的根源。订单状态机、Temporal Workflow、Agent 多步任务，本质都是在管理状态跃迁。
选型服务于场景。gRPC 还是 HTTP、Temporal 还是裸 goroutine、RAG 还是 Agent，答案永远在具体场景里。
发布和回滚能力是底线。KubeSphere 容器化让发布效率提升约 80%，故障回滚在 5 分钟内，这比任何架构炫技都实在。

我没有刻意追过技术潮流，只是被业务推着走，遇到什么问题就解什么问题。回头看，真正的成长是面对一个全新领域时，能快速抓住核心矛盾，再用工程化的方式把它落地。

这条路还在继续。

封面图：M McBey / Flickr · CC BY 2.0