企业官网建设流程全解析

Jason Liu 这个名字，关注大模型应用开发的人应该不陌生。他是 Instructor 库的作者，也是 LiteLLM 的核心维护者之一，长期泡在 LLM 工程化的一线，写了不少关于结构化输出、函数调用、Agent 设计这些“脏活累活”的经验。他最近反复强调的一个观点，概括起来就是“轻量思考”——不是教人偷懒，而是劝大家在动手写 AI 应用前，先别急着上重框架、堆复杂流程，先用更轻的方式把问题想透。这个建议我觉得非常值得聊，它直接戳中了很多团队在 LLM 项目里“重投入、低产出”的痛点。这篇就围绕 Jason Liu 的思路，结合我自己做过的几个项目，把“轻量思考”到底是什么、落地时怎么做、边界在哪里，一次讲清楚。

适合看这篇的，主要是两类人：一类是刚接触 LLM 应用开发，喜欢跟风上 Agent 框架、但经常被复杂抽象绕晕的开发者；另一类是已经在做 AI 应用，但发现 Prompt 越来越难调、链路越来越难维护，想换个思路做减法的技术负责人。内容不会涉及太深的研究算法，更多是工程落地层面的思路和方法。

1. “轻量思考”的来源：一个常年写 LLM 框架的人，为什么反框架

1.1 从 Instructor 的设计哲学看他的技术偏好

先说点背景。Instructor 这个库的核心能力，是让大模型的输出直接映射到 Pydantic 模型上，也就是说，你可以定义好一个数据结构，模型返回的内容会被自动校验、补全、重试，直到符合结构要求。这个设计背后有个很明确的判断：LLM 的文本生成能力再强，在工程里真正可靠的是“结构”。

Jason Liu 在多次分享里都提到过一个观点：开发者最大的幻觉，是以为模型“理解”了业务逻辑。实际上，模型只理解文本模式，不理解你的系统约束。所以他的做法是把业务逻辑尽量放在代码里，把模型的职责收窄到“从自然语言里抽取信息”和“根据指令生成文本片段”。这正是“轻量思考”的雏形——不要指望模型像个全能 agent 一样替你思考，而是让模型作为你代码逻辑里的一个组件，插拔清晰，边界明确。

这套思维其实和传统软件工程里的“单一职责原则”一脉相承。你会发现 Instructor 没有试图去解决的问题，比如多轮对话管理、长期记忆、任务规划，它一概不碰。这些复杂的职责被刻意排除在框架核心之外，留给开发者自己去组合。Jason Liu 经常说的一句话，大意是框架越少，你需要做对的决策就越少，你的系统就越可控。

1.2 “轻量思考”不是什么：别把降低思考量理解成降低要求

“轻量思考”这个名字很容易被误解成“别想太多，赶紧写代码”。恰恰相反，它要求你在动手前把问题想得更透，只不过思考的对象不是“模型会怎么想”，而是“我的系统需要什么输入、什么输出、什么边界条件”。

我自己刚接触 LLM 开发时，最常见的工作方式是这样的：拿到需求，先找一个 Agent 框架，定义一堆 Tool，再把历史对话塞进去，然后开始调 Prompt。搞了两周，发现模型经常调用错误的工具、漏掉必要参数，问题出在哪儿都说不清楚。后来用 Jason Liu 的思路重新过了一遍，才发现大部分复杂度是框架自带的，而不是业务本身要求的。

所以“轻量思考”的核心是：区分哪些复杂度来自业务真实需求，哪些复杂度来自技术选型。真实业务要处理多轮纠错、权限校验、知识库检索，那这些必须有；但如果只是因为“用了框架就得按框架的抽象写代码”，这部分复杂度就是可以砍掉的。轻量思考不是不做设计，而是把设计重点放在“数据怎么流转”而不是“模型怎么思考”上。

2. 为什么 AI 应用容易陷入过度设计，轻量思考怎么破局

2.1 一上来就搭框架的冲动，源自对不确定性的恐惧

我自己踩过最大的坑，是在一个知识库问答项目里，一开始就选了一个重量级 Agent 框架。当时的心态很简单：既然要做的功能多，那框架的功能越全越好，后面不用再改。结果框架的学习成本、概念负担、版本兼容问题，直接拖慢了项目节奏。

Jason Liu 对这种现象有个很有意思的观察：很多团队之所以选重框架，不是因为业务需要，而是因为不想面对“从零开始做决策”的焦虑。框架替你规定好了 Agent、Tool、Memory、Planner 这些概念，你觉得心里有底了，但实际上这些概念是不是适配你的场景，没人知道。

轻量思考的破局方式，是强迫自己回答四个问题再写代码：

• 用户输入是什么，格式固定吗？
• 我期望的输出是什么，结构化的还是自然语言的？
• 中间要经过几个步骤，这些步骤是固定顺序还是动态决定的？
• 出错时我能接受重试几次，代价有多大？

这四个问题不需要任何框架就能回答。而一旦回答清楚，你会发现至少一半所谓的“Agent 能力”根本用不上。

2.2 流程固定用代码，流程动态才考虑模型决策

业界关于什么时候该用 Agent、什么时候用普通 pipeline，其实有过很多讨论。Jason Liu 的原则非常直接：能用代码写死的流程，绝不让模型参与决策。理由很简单，模型决策有概率性，同样的输入今天走这条路、明天走那条路，这对调试和测试都是灾难。

我后来在一个客户工单分类系统里实践了这个原则。最初版本我让模型自己判断“该查订单、查物流还是直接回复”，结果准确率忽上忽下。后来改成：先用一个轻量分类模型把工单分成三类，再按类别各自走固定处理流程，结构化的查库逻辑交给代码处理，只有最终的回复文案交给模型生成。改完之后，准确率不仅提升了，而且每次出问题都知道该排查哪一段。

这就是典型的重心转移：把模型从“流程决策者”降级为“步骤执行者”。很多 AI 应用不稳定，不是模型不够聪明，而是把太多决策压给了模型。流程稳定的部分应该彻底代码化，模型只负责它真正擅长的自然语言理解和生成。

2.3 先定 Schema，再写 Prompt，顺序反了会一直返工

Jason Liu 的另一个高频建议，是先定义数据结构，再围绕结构写 Prompt。这个顺序看似简单，但绝大多数开发者是反着来的——先写 Prompt 让模型吐自然语言，然后再从文本里解析字段，解析失败就加正则、加重试，最后变成一团乱麻。

我建议的顺序是这样的：

1. 先画出这个功能涉及的所有实体和字段，例如“订单号、用户问题、分类、处理结果”；
2. 用 Pydantic 或者 TypeScript Interface 把这些字段定义成强类型；
3. 让模型直接以 JSON 格式返回，并用校验库做类型校验；
4. 校验失败就带着错误信息重试一次，而不是默默解析出半成品。

这样做的底层逻辑是，把大模型当成一个“函数”，输入是用户消息加指令，输出是符合既定 Schema 的 JSON。这个“函数”内部怎么想的不重要，只要输出结构稳定，上层业务代码就能像调普通函数一样调它。轻量思考在这里的体现就是：不要尊重模型输出的“自由意志”，要尊重你自己定义的结构约束。

3. 实操落地：三个场景演示如何践行“轻量思考”

3.1 场景一：用户意图识别与槽位填充

第一个场景是智能客服里的意图识别。很多人第一时间想到微调模型或者上对话理解平台，但 Jason Liu 的思路会先问一句：你的意图类别有多少种？槽位是固定的还是开放的？

以我做过的一个售后支持系统为例。当时需要识别用户的问题是“退货”“换货”还是“维修”，同时抽取“订单号”“商品名称”“问题描述”三个槽位。我的做法非常轻量：

系统提示词里写清三类意图的定义、三个槽位的 JSON 结构，再给两个 few-shot 示例，然后让模型直接返回 JSON。没有用任何 RAG，没有知识库，也没有复杂的对话状态管理。上线后准确率稳定在 92% 以上，对不上的那部分主要是用户表述本身模糊，靠人审兜底。

这里的关键是，意图类别只有三种，槽位边界清楚，模型完全能够胜任。轻量思考的价值在于识别出“这件事不需要重型方案”，帮你省掉不必要的架构成本和延迟。

3.2 场景二：用工具调用替代 Agent 编排

Agent 是现在最热门的概念，但 Jason Liu 对 Agent 的态度一直比较谨慎。他在多个场合提到，大部分业务里的“智能体”其实只是“带工具调用的多步骤流程”，没必要套用复杂的规划算法。

我做一个“周报助手”的时候，最初的设想是让 Agent 自己决定：先读取本周提交记录、再汇总项目进度、最后写成周报。看起来很美，但模型经常在“读取记录”之后就停下来，或者跳过某个步骤。后来我按照轻量思考拆了一下：读取记录用代码直接做，汇总数据用模板拼出来，只有“写一段自然的周报描述”这一步交给模型。整个流程变成：

1. 代码查询代码仓库和项目管理系统，拿到本周 commit 和任务状态；
2. 按固定模板生成结构化数据；
3. 把数据送给模型，让它用自然的语气写成人话；
4. 输出 markdown 周报。

这个方案跑了大半年，再也没出现过“Agent 中途罢工”的情况。我理解 Jason Liu 说“少用 Agent”不是否定 Agent，而是提醒大家：Agent 框架引入的自主性和不可预测性，只有在流程本身充满不确定性时才值得付出。流程一旦跑顺，立马回归到普通代码，这才是长期维护的正道。

3.3 场景三：模型分层——所有请求都走大模型，就是最大的浪费

轻量思考在资源层面还有一个重要体现：不要所有请求都用最强的模型。GPT-4 级别的模型和轻量模型，价格和延迟差很多倍，但并非所有任务都需要那么强的推理能力。

我在一个信息抽取项目里做过对比：抽取出入口、日期、金额这些固定字段，用轻量模型和用顶级模型，准确率差距不到 2%，但成本差了将近 10 倍。于是我把任务分了两层：简单字段抽取走轻量模型，复杂语义判断（例如判断合同里是否存在隐含的违约责任）走强模型，两边通过同样的 JSON Schema 输出，上层代码完全无感。

这种分层策略就是 Jason Liu 常说的“模型也是需要管理的资源”。轻量思考不仅指流程设计上的克制，也包括模型选择上的理性。别总想着用一个万能大模型解决所有问题，拆开来看，很多任务根本不需要“思考”。

4. 轻量思考在模型推理层面的延伸：控制推理深度，别让模型想太多

4.1 让模型“少想”，反而能提升稳定性

Jason Liu 建议用“轻量思考”，在提示词层面有一个非常直接的体现：不要一上来就要求模型“一步一步地思考”，也不要让它自由发挥太长的推理链。原因在于，推理步数越长，模型跑偏的概率越高，输出延迟也越大。

我自己测试多轮对话去重和摘要任务时就发现，当你让模型“深入思考用户意图”时，模型经常把简单问题复杂化。比如用户问“你们几点上班”，模型非要把经营范围、客服时间、节假日安排全猜一遍，然后给出一大段话。反而是我加了一句“不需要分析背景，直接基于已知信息回答”，输出立刻干净很多。

这背后的原因是，大模型的推理能力是概率性的，每一步都引入选择，选择就有出错的可能。轻量思考的提示词策略应该是：“只给最少必要信息，只要求输出必要结果”。如果你确实需要复杂推理，就在独立步骤里显式地要求模型做，并且把中间推理结果放在数据结构里，方便追踪，而不是混在最终回答里。

4.2 控制输出 token，减少“废话”和“幻觉”

输出 token 的长度，和模型的幻觉概率呈正相关。这个规律虽然不绝对，但在实践中很常见：模型说得越多，越容易编造细节。Jason Liu 团队在多个开源库里都强调过 response model 和 max_tokens 的组合使用。

实操上我的习惯是两步走。第一，用结构化输出格式限定模型的产出边界，例如“只返回 JSON，不要任何解释文字”。第二，在合理范围内尽量压小 max_tokens。这不仅能省钱，还能逼着模型只输出关键信息。比如生成商品简称时，max_tokens 设为 40，模型就不能长篇大论地给你写营销文案，只能给一个短句，这正好满足需求。

很多人在意“模型不够聪明”，但我见的更多情况是“模型太爱表现”。轻量思考要求你在设计阶段就把模型的“废话空间”给堵死。

4.3 评测也要轻量：用 30 条样本找方向，别等 1000 条才动手

说到这，可能有人会问：轻量思考对系统设计有指导意义，那对评测和调试呢？也有。很多团队搞评估一上来就想要几千条标注数据、全自动测评平台，结果连第一步的提示词都还没定下来。

Jason Liu 的建议是反过来的：先准备 30 到 50 条典型样本，人工看模型输出，用肉眼记录哪里不对，改完提示词或代码再重跑一遍。这个循环跑上三轮，你对问题的理解会比盲目堆数据深刻得多。

我实践下来，这个“小步快跑”的方式确实有效。通常第一轮你会发现 10 个问题里有一半是 Schema 设计不合理，第二轮再发现几个语义理解错误，第三轮基本能把关键路径打磨到满意水平。等到最后的评估，再用相对大的样本量化指标也来得及。轻量思考不是拒绝评测，而是拒绝在问题还没定义清楚前，就投入大量资源搭建评测基础设施。

5. 常见问题与边界：轻量思考不是银弹，知道什么时候该放弃

5.1 实际项目中常见的几个纠结点和化解方法

在这一节，整理几个我做项目时常遇到的问题，和你分享一下我的处理经验。

这五个问题我全遇到过。印象最深的是“改一个场景崩另一个场景”，当时我还在用一段超长 Prompt 管理所有意图，最后花了三天拆成了五个子 Prompt，问题才彻底解决。这就是典型的“重思考失败，轻思考救场”。

5.2 什么时候必须上重方案，轻量思考的边界要划清楚

说完了轻量思考的优点，也得客观讲清楚它的边界。确实存在一些场景，靠轻量思考和简单 Prompt 是解决不了的，这时候硬撑反而会误事。

第一类是开放式创作任务，比如写小说大纲、做营销策划。这类任务的核心价值就是模型的发散性思考，你不能用一个死 Schema 把它的输出框死。这时候“重思考”不是浪费，而是必要的创造力投入。

第二类是面向非结构化文本的复杂语义推理，例如诉讼材料审查、医疗报告解读。这类任务输出结构相对固定，但内部推理链条深、前提条件多，需要模型综合上下文做推理。这种情况下，可以把轻量思考体现在数据流分层上，但推理部分要给模型足够的空间和上下文。

第三类是超长上下文依赖的任务。比如分析整本合同的违约风险，或者跨多文档寻找因果链。这类任务不适合本地单轮 Prompt，需要真正的检索与多跳推理框架。这种场景下，适当引入 Agent 式编排是合理的，但建议你仍然以“人审界面 + 分步结果展示”的方式保留控制权，而不是完全放任模型自动跑。

判断标准很简单：如果你能明确列出每一步做什么，那就用代码写死；如果你根本列不出来，只能靠模型临场发挥，那才该考虑复杂方案。Jason Liu 的“轻量思考”真正反对的不是复杂方案本身，而是“明明流程可控，却偏要靠模型随机探索”这种设计心态。

6. 从“轻量思考”到“轻量团队”：一种可以外溢的工作习惯

写到这里，我想分享一点超出技术本身的感悟。Jason Liu 建议的“轻量思考”，表面上是技术选型和架构设计的取向，实际上是一种工作习惯。它要求你在做任何东西之前，先问一句：“最低成本解决这个问题的方案是什么？”

这个习惯在团队协作里也一样适用。我做项目的时候见过不少团队，开会聊了三个小时 Agent 架构，却没人先把输入输出的字段定义下来。如果大家先花半小时把 Schema 定了，把关键路径画清楚，那个架构会可能根本不需要讨论。思考的颗粒度会影响行动的成本，而轻量思考就是在提醒你：把思考花在真正影响结果的地方。

我现在的日常工作方式，已经变成了“先写数据结构，再写提示词，最后写胶水代码”。看起来比一开始起个 Python 脚本慢一点，但返工率大大降低。遇到的很多问题，也都能很快定位到是数据结构定义得不够好，还是模型对某类输入天然不够敏感。

Jason Liu 的思路有没有争议？有。比如有人觉得他太保守，错过了 Agent 的红利期；也有人认为他的方案只适合理解为“工程化 prompt”的场景，处理不了真正的开放智能。这些声音都有道理，但在大多数依赖 AI 提效的业务系统里，稳定性和可维护性远比灵性重要。就冲这一点，我认轻量思考这套理念。

如果你现在正被一个复杂的 AI 项目搞得焦头烂额，不妨停下来试试 Jason Liu 的路线：把任务拆成最小可验证的步骤，先定义清楚数据结构，再用最轻的方式做通一版。很多时候你会发现，你并不需要一个庞大的框架，你只是需要想明白自己要什么。