AI on 姚玉亮的网络日志

赢家的提示词只有 200 字：周末亚马逊活动的三点收获

Fri, 04 Sep 2026 11:00:00 +0800

周末去亚马逊参加了场线下活动。一天下来笔记记了不少，回来翻的时候发现，真正值得写的就三件：两件来自王老师的分享，一件来自活动组织的一场掼蛋游戏。

这三件事看着不相干，但我连起来想了一路，发现它们其实在回答同一个问题：AI 时代做系统，复杂度应该放在哪儿。

一、垃圾文档会精准投毒

王老师讲 RAG 的时候说了一句大白话，我印象很深：知识库问答做不好，先别急着调检索算法，回头看看库里都放了些什么。

这话值得展开。RAG 的流程是先检索、后生成，模型本身不判断检索结果的对错：检索到什么，它就顺着什么讲，还能讲得头头是道。库里要是有份过时的制度、一份新旧口径打架的规范、一份扫描得糊成一团的 PDF，它们不会安静躺着：总会在某次检索里被命中，然后被模型一本正经地引用出去。

所以垃圾文档的问题不是拉低平均分，是投毒：专挑你最需要正确答案的那次查询起作用。

这块我有体感。自己做知识库问答服务那阵子就发现，检索质量的上限由数据治理决定，换模型、调分块策略，都只是在脏数据上打转。对策也没什么玄技，全是纪律：入库要有门槛，来源、格式、时效过得去才放进来；过期文档定期下线，别想着"万一有用"；口径打架必须裁决一个，不能新旧都留着，让检索随机翻牌。

宁可库里 100 份干净的，不要 1000 份说不清的。

二、200 字的提示词，赢了 700 字的

活动下午组织了场游戏：写提示词，驱动模型打掼蛋。

结果有点反直觉。赢家的提示词普遍只有 100 到 200 字，说说目标、风格和几条底线就完了。写得最认真的一位，700 字左右的战术大全，拆牌逻辑、记牌策略、队友配合全写了，没赢。

为什么？我的理解是：现在的模型跟去年不是一回事了。掼蛋这种规则清晰的游戏，算牌、拆牌这些基本功模型自己就会，你再教一遍就是多余的。更糟的是，700 字里那些硬规则会互相打架，把模型天然的判断力框死了，等于在用去年的弱模型标准，调教今年的强模型。

掼蛋是游戏，但规律通用：提示词里最贵的成分不是技巧，是对模型的不信任。

我现在的做法是，每次换更强的模型，第一件事把存量提示词拿出来重测，逐条问"这条还需要吗"，先删后加。删完经常发现，效果反而更好。

三、不要相信用户的 query

这句还是王老师说的，观点很挑衅。

用户带着模糊的意图来，写出来的 query 往往不是他真正想问的：词不对，粒度不对，缺限定。传统做法是工程补救：建同义词库、写纠错规则、训意图分类器，一个 bad case 补一条规则。代码越垒越高，而且系统变聪明的速度，取决于工程师排期的速度。

现在更划算的做法：把 query 交给模型扩写。一句模糊的话，发散成好几路检索形态（同义改写、上位扩展、拆解子问题、补充限定词），并行去检索，召回合并之后再生成。

我觉得这里最值钱的不是扩写本身，是升级路径变了。以前系统变聪明靠写代码、发版本；现在扩写是模型做的，模型升级那天，你这套扩写自动跟着变好，一行代码不用改。写死的规则不会自己长大，模型驱动的能力会。

当然工程不是没事干了。评测集、兜底逻辑、召回质量的度量，这些还是工程的活，只是"理解用户"这类事的实现权交给了模型，验收的责任留给人。

连起来看

回来路上我把这三件事过了一遍，发现它们指向同一个选择：复杂度放在哪。

垃圾文档的对策，是把功夫下在数据治理上，不是算法缝补；掼蛋的输赢，说明模型自己会的东西别硬教，700 字不如 200 字；query 扩写说明，系统能力可以长在模型上，跟着模型自动升级。

我的结论：数据自己养好，理解和发散交给模型，代码只留它真正不可替代的那部分。模型接下来还会继续变强：把系统里会自己变强的部分交给模型，你的系统就免费跟着变强。

别把复杂度锁死在代码和长提示词里。这是我这个周末最大的收获。

最强的模型选了主键关联：不是它不够强，是业务没人替它想清楚

Fri, 04 Sep 2026 10:00:00 +0800

先承认：模型真的很强

我是 yusanwen，一名深度使用 AI 的工程师。我承认大模型是真的强，强到逻辑推演接近无敌：让它在代码里找边界情况、做多步推理，它做得比大多数同事都快。这篇文章不是唱衰模型，恰恰相反：正因为承认它强，有个问题才值得写下来。

一个"当下完全正确"的 demo

前几天我用目前能调到的最强档 Codex 模型（5.6 sol）做一个内部小 demo。需求很小：描述几个实体、说清楚它们之间的关系，让它建一套带接口的最小系统。我没有给表结构、没有给任何存储选型约束，想看看它"自己会怎么设计"。

它交出来的东西非常干净：每个实体一张表，自增主键，实体之间全部用主键 id 互相外键关联。代码规整，测试全绿，接口能跑。一切看起来完美。

但我盯着那张 ER 图，后背有点发凉。

单看当下，主键关联没有任何问题。问题藏在一个没说出口的假设里：这套关联成立的前提，是"永远只有这一张主键表、永远只有一套存储、永远不迁移"。

只要未来有一天换库类型（比如从单库换成分库/异构存储，或者业务合并、要和另一套系统的数据对上），以主键 id 为语义的关联就全线失效：两边都有 id=1，却不是同一个东西。那时怎么办？洗数据：把几十万行关联按业务规则重映射。能做，但那是用未来的一场大手术，偿还现在省下的十分钟。

说"后背发凉"，不是这套设计错了，主键外键在大多数单库场景就是对的。凉的是：这个"对当下完全正确、对未来埋雷"的决策，全程没有任何人做过。模型默默地替你选了，而你默认了。

为什么最强的模型，选了最"平均"的方案

第一反应当然是怪模型：不是号称最强吗，连外键策略都选不好？想了两分钟，我收回这句话。

因为大模型本质上是概率模型。它产出的不是"最优解"，而是训练数据分布里的最可能解：在它见过的几千万张表里，“自增主键 + id 外键"是最常见的写法，没有之一。我描述实体和关系时没给任何反向约束，它按概率落点，自然落在最常见、最不需要解释的答案上。

它优化的是"这段设计看起来像什么”，不是"这段设计未来扛不扛得住"。更要命的是，它没有 skin in the game：换库的迁移成本是几个月后的我的，不是现在的它的。一个不用承担后果的决策者，天然倾向于选择让自己"看起来最正常"的选项，哪怕那个选项把风险往后推。

所以，凡是你没说出口的约束，概率模型都会替你平均掉。

为什么这套设计能一路绿灯

因为链条上每个环节都在奖励"快"。demo 要得急，模型写得快，自测全绿，人扫一眼觉得"挺规范的"。管理层的关注点不在主键策略上，利益也不在那里：那里要的是交付速度、团队吞吐、demo 赶紧变成能演示的东西。没有人有动力为一个"当下完全正确"的设计踩刹车。

于是模型参与越深、任务越重，这种"概率平局"的设计被无审查放行的比例就越高。不是哪个人不负责，是速度把"想清楚"这个环节压缩没了，而模型用一个看似专业的默认值，恰好补上了这个真空。它越强，输出越像资深工程师的手笔，就越没人质疑。我在这个 demo 里看到的最危险的东西，不是主键，是流畅的平庸。

解法：把约束说出口，而不是靠模型自觉

结论不是"关键设计别让模型碰"，那是因噎废食。要做的，是把被速度压缩掉的环节，重新变成显式的东西。

解法一：关系是业务语义，先写出来，再让模型建表。

“订单属于用户"是业务，“订单表加一列 user_id 外键"是实现。只给模型后者，它就会顺着 id 一路关联下去；给它前者，它才可能停下来想"该用哪个键表达这个关系”。所以我现在的做法是，做这类 demo 前先花十分钟写一段领域骨架：每个实体的业务唯一键是什么、实体之间靠什么语义关联（单号？编码？还是本就同库同生命周期？）。这段骨架不属于任何技术选型，换什么存储都成立。写清楚之后模型再怎么实现都安全，因为最危险的那个决策，已经被写下来的业务做完了。

解法二：把"换库演练"写进验收条件。

给模型的验收清单里加一条：回答"如果存储换成另一种形态，这套关联要改多少、怎么改”。它答不上来，说明关联设计偷懒了。这一步几乎零成本，却把"未来的成本"拉进了当前这一回合：模型不能只优化当下，因为验收里写了未来。有意思的是，概率模型其实答得上来这种问题，只要你问。

解法三：踩过的坑沉淀成约束，注入而不是叮嘱。

主键关联这种事，踩一次就够。但"记住"不该靠人脑，该靠系统：把反模式写进团队的编码规范，再通过 AGENTS.md / Skill / 提示词模板注入每个后续任务，比如"跨实体关联必须引用业务唯一键，或用一句话说明为什么不能"。AI 时代，编码经验的载体正在从"老员工脑子里"变成"可注入的约束文件里"。谁的约束写得全，谁的模型输出就靠谱。说白了，就是把概率模型的落点，用显式经验强行掰回来。

解法四：架构决策不外包，但让模型自证最坏情况。

实现可以外包，设计决策留一道复核：交付前让模型自己列"这个设计在哪些条件下会失效"。它列得出来，列不出来才是问题。这一条的本质是把隐性决策变成显性决策：主键外键可以选，但必须是"讨论过、知道代价"之后的选，而不是概率的默认值。

结尾：两种能力

回到开头。我承认大模型很强，逻辑能力甚至接近无敌。但这次 demo 让我更确定另一句话：

大模型的强，是"把说出口的经验变成执行"的强；而"把没说出口的经验变成决策"，暂时还得靠人。

未来能编好程序的人，一定是两种能力的组合：深谙业务，知道哪些关联是语义、哪些只是巧合；善用模型，能把业务约束、验收标准、历史教训，全部显式地喂给它。会写代码正在贬值，“能把业务说清楚"正在升值。模型写出的每一行都在替你打工，但往 prompt 里放什么约束，决定了它是替你赚钱，还是替你埋雷。编码的姿势，暂时还是值钱的。

封面图：Ivan Radic / Flickr · CC BY 2.0

知识库、Skill 与 Agent、数据集、微调模型：LLM 落地的五层底座

Tue, 01 Sep 2026 15:30:00 +0800

为什么这几个词总被放在一起

做 AI 应用这几年，我反复被问到一组概念：知识库、Skill Agent、数据集、微调模型。它们经常出现在同一份方案里，但很少有人把关系讲清楚。

我自己的理解是：它们是 LLM 从"通用"走向"懂你的"的底座，一共五层。

知识库：让模型"知道"你的私有数据
Skill（技能）：让模型"会做"专业任务，封装专家方法论
Agent（智能体）：让模型"去干"，负责规划、调用工具、按需加载技能
数据集：让模型"学到"你的行业养分
微调模型：让模型"变成"你的专属模型

一个企业 LLM 应用从 demo 到生产，绕不开这五件事。我做过数据集管理服务、知识库问答服务，也开源过 Skill/Agent 方向的炼丹炉项目，下面的说法都有真实项目做底，不给数字，只讲逻辑。

一、知识库：让模型"知道"你的私有数据

先说是什么。知识库问答（RAG）是目前最主流的私有数据落地方式：把企业文档、FAQ、数据库内容分块，转成向量存进检索系统；用户提问时，先从库里检索出最相关的片段，连同问题一起交给 LLM 生成回答。模型本身不变，变的是每次问答时喂给它的上下文。

它解决三个问题：一是模型不知道你的私有数据，通用模型没学过你的产品手册和客户案例；二是幻觉，让模型硬答它不知道的东西，它就会编；三是知识时效，文档更新了，检索到新内容，回答就跟着新，不用重训模型。

商业价值上，这是企业 AI 落地第一个值得做的场景，因为 ROI 最清晰：客服问答、内部知识问答、合同/制度检索，都是"原来要人翻文档"的活，现在秒回。知识库的核心资产是数据本身：同样一套 RAG 代码，谁的数据组织得好、分块合理、答案准确率高，谁就有壁垒。做知识库问答服务的经验是：检索质量决定用户体验，而检索质量取决于数据治理，不是模型选型。

二、Skill 与 Agent：让模型"会做"、也"去干"专业任务

先说清楚，Skill 和 Agent 是两个东西。Skill（技能）和 Agent（智能体）经常被捏在一起说，但它们是两个独立的概念、两层独立的资产。

Skill（技能）是什么：把专业任务的方法论封装成结构化技能包（心智模型、决策规则、边界、禁忌、示例），一段话说明白"这件事怎么做才算专业"。我在炼丹炉里做的"金丹"就是这个：把人格特质和表达方式封装成技能包，一颗金丹就是一套完整的专业行为规范。

Agent（智能体）是什么：执行体。能规划、能调用工具、能多步推理，按需加载技能去完成任务。炼丹炉里的"道人"就是这个：道人服用金丹后，行为就被技能"化"了。关键设计是技能与执行体解耦：一个道人可以服用多颗金丹（多个技能），一颗金丹可以被多个道人复用。

解决的是专业任务的自动化。通用 Agent 是"全能而不专业"的：让它做医生问诊、做风控审核，它没有专家级的行为规范。技能解决"专业"：行为准则、停止条件、评判标准；Agent 解决"执行"：规划、工具调用、多步推理。两者分开，技能才能沉淀、复用、版本化，Agent 才能轻装、按需加载、随时被替换。

商业价值上，技能是可复制的专家经验：资深员工的行为准则封装进技能包，人走了经验还在，一个高级顾问的产出可以规模化。Agent 是执行通道：任务边界写清楚之后，执行可以交给便宜的模型（这就是我上一篇写的模型分级）。当前 AI 应用差异化竞争的主战场在技能层：模型的差距在缩小，技能的差距在拉大。

三、数据集：让模型"学到"你的行业养分

再看是什么。数据集是训练、微调、评测模型的数据资产：指令对（问题-标准答案）、对话对（多轮对话）、评测集（有标准答案的验收用例）。数据集管理平台负责数据的采集、清洗、标注、版本管理、评测。我做的数据集管理服务就是这个方向，本质上是数据资产的仓库和流水线。

解决什么问题？一个被低估的事实：模型质量的天花板是数据，不是模型。同样一个底座模型，喂什么数据决定它是什么水平的模型。指令数据的质量决定对齐质量，评测集决定你能不能客观知道"模型到底行不行"，没有评测集，改进就是凭感觉。企业里大量 AI 项目死在数据上：格式不统一、标注不一致、缺评测标准。

商业价值：数据是 AI 时代的石油这句话被说烂了，但逻辑是真的：标注产业、数据治理平台、合成数据，都是实打实的市场。对企业来说，数据集是资产不是成本：同样的模型，谁的指令数据更高质量，谁的微调效果就更好；评测集就是验收标准，是甲乙方博弈的锚点。数据合规（来源可追溯、权限可管控）本身就是商业价值：数据资产化的前提是数据可信。

四、微调模型：让模型"变成"你的专属模型

最后是微调。它是在通用模型基础上，用领域数据继续训练（LoRA 等参数高效方法是主流），让模型把业务能力"内化"到参数里。它和 RAG 的本质区别：RAG 是每次问答临时注入知识，微调是把能力写进模型本身。

解决什么问题？RAG 管"知道什么"，微调管"怎么说话、按谁的规矩办事"：固定的输出格式（结构化 JSON、特定语气）、专业术语的准确使用、企业内部的表达习惯。微调还能解决 RAG 治不好的问题：模型能力本身不够时（比如让小模型学会复杂指令），注入再多上下文也没用。

商业价值上，三个场景最典型：一是垂直行业模型，医疗、法律、金融，同样的底座，行业数据微调后就是行业模型；二是私有化部署，合规要求数据不出域，小模型微调后本地跑，效果接近大模型；三是长期成本，微调让一个便宜的小模型达到通用大模型的效果，每 token 成本降一个数量级。什么时候微调是商业决策的关键：数据量不足时微调不如 RAG，数据积累够了再微调，收益陡增。

五层怎么配合

我常跟人画一张图：

企业落地路径也基本是固定的：先用知识库快速见效，一两个月就能上线；过程中顺手积累数据（问答记录、反馈、评测集）；然后把专业流程封装成技能，从能回答走到能办事；数据攒够了再微调，把能力从"借来的"变成"自己的"。

这几个词不是并列的技术名词，是一条递进的路。模型的通用能力是人人平等的起跑线，知识、技能、执行体、数据、专属模型，才是企业拉开差距的底座。这也解释了为什么 AI 应用做深了，最后都变成数据生意和知识管理生意。

封面图：Grand Canyon NPS / Flickr · CC BY 2.0

复杂任务的快速实现：我的 Claude Code 工作流

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

复杂任务为什么难

先说结论：复杂任务难的不是写代码，是下面四件事。

需求模糊：说需求的人自己都没想清楚。“文档核验要留痕”，留什么痕？按什么查？入口放哪？全要靠推。
代码陌生：改的不是自己写的代码库，路由注册在哪、DAO 怎么组织、有没有现成的组件，一无所知。
链路长：一个需求横跨后端服务、管理后台、上层服务三个仓库，联调对不上是常态。
步骤多：建表、写记录、加接口、做页面、上层同步，十几步里漏掉任何一步，都要返工。

过去我处理复杂任务靠"经验 + 加班"：经验让我少踩坑，加班补上流程损耗。现在我用 Claude Code 的 workflow 跑，发现上面四类复杂度可以分别拆掉。

一、需求模糊？先探索，再一次一个问题

需求模糊是复杂任务的第一个坑，也是最贵的坑：设计错了，后面全白做。

我的做法是两段式：先让 AI 探索代码，再让它一次只问一个问题。

拿最近一个"核验记录"需求举例。AI 先翻了两个仓库，带回几个关键事实：文档表上已经有"核验状态"字段，核验逻辑集中在文档服务的一个方法里，前端代码里已经有现成的下拉加载 hook。这些事实直接改变了设计：记录表和状态字段是两回事，但很多人第一版会把它们混在一起。

然后进入提问环节，一次一个问题：

我：核验记录存哪些字段？ AI：除了核验人和核验时间，要不要存版本号？这决定表结构。我：先只存核验人和核验时间。 AI：好。那列表按数据集 ID 过滤、分页返回，对吗？

每个答案都在修正下一个问题。一次抛十个问题，AI 只能靠猜排优先级，猜错一半就得返工。模糊需求最怕的不是问得少，而是问得乱。

二、代码陌生？子代理并行探索

复杂任务往往意味着大型代码库。让主会话把每个文件都读一遍，上下文直接爆炸；不让它读，问的问题全是空对空。

我用子代理解决：只读的探索型子代理，各自负责一个方向，跑完只把结论带回来。

还是那个需求。两个仓库，我开了两个子代理并行：

一个查后端：核验逻辑在哪个方法里？用什么 ORM？表结构长什么样？
一个查前端：数据管理页面结构？有没有现成的分页/下拉加载组件？

主会话的上下文只收到两条结论，干净利落。复杂任务拆给子代理，等于给主会话外挂了好几个只读大脑。

三、步骤多？用 spec 锚定，用计划兜底

十几步的任务，光靠"记住"一定会漏。我的流程里有两个强制环节：

第一步，设计获批后写 spec 文档。表结构、接口定义、前端改动点、上层同步点全部落盘。这份文档是后续所有工作的锚点：代码评审不再对着记忆逐条想，而是对着 spec 逐条核对。

第二步，用计划技能把设计翻译成有序任务。先改什么、后改什么、每个任务做完怎么验证，都拆成文件级清单。执行阶段照着走，不会顾此失彼。

复杂任务最怕的不是步子慢，而是做完了发现做的是另一个需求。spec 就是防这件事的。

四、链路长？add-dir 多项目，一个会话挂三个仓库

跨仓库任务的真正成本不在写代码，在于两边对不上：前端叫 page 后端叫 current，接口路径差一个斜杠，联调半天。

Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，三个仓库的上下文同时可见。字段名、接口路径、分页参数在计划阶段就定死，代码照着写就行，联调成本趋近于零。

以前这种需求：拉群 → 各自开工 → 联调发现对不上 → 返工。现在：一个会话、一份 spec、三份代码同时改。

五、改错返工？hooks 门禁 + 验证闭环

复杂任务最容易在最后一步翻车：改完了、自测过了，忘了检查脱敏、忘了跑构建、忘了验证线上。

我的解法是 hooks：把检查前置到事件本身。比如写文件前必须声明事实（这个文件被谁引用、里面有没有敏感内容），执行破坏性命令前必须给出回滚方案。检查不是"记得就做"，而是流程的必经环节，不做就卡住。

收尾阶段再加一道验证：构建无错误、线上返回 200、关键内容比对通过，才算完成。质量不是最后检查出来的，是流程逼出来的。

我的工作流时间线

一个复杂任务在我这里是这样的节奏（示意）：

flowchart LR
 T1["探索 + 脑暴"] --> T2["方案 + spec"] --> T3["实施计划"] --> T4["执行三仓"] --> T5["评审 · 验证 · 部署"]

环节	干什么	用时
探索 + 脑暴	读代码、一次一个问题澄清需求	一个上午
方案 + spec	2-3 个方案对比，获批后落盘设计文档	半小时
实施计划	设计翻译成文件级任务清单	十分钟
执行	按清单改三个仓库	主工作量
评审 + 验证 + 部署	对着 spec 评审，构建、线上验证	收尾

对比以前的节奏：需求评审会一轮、文档两轮、联调两轮、返工一轮，光流程损耗就吃掉一半时间。

收尾

复杂任务的复杂度分布大概是这样：需求 > 链路 > 步骤 > 代码。Claude Code 的 workflow 没有任何魔法，它只是把"该问的、该查的、该记的、该验的"变成了流程的默认动作，让 AI 和人的精力都集中在真正难的地方。

真正快的不是写代码那一下，而是不返工。

封面图：jurvetson / Flickr · CC BY 2.0

我的 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 工程化，练全栈闭环，建立判断力。我自己也还在这条路上，希望两年后回头看，这篇文章里的判断依然站得住脚。