SOLO搭建智能体法律行业
从零到一，我用SOLO AI助手搭建了一个刑事辩护律师智能Agent工作台
2026年4月
第一章：缘起——为什么我要搭建一个法律AI Agent
先自我介绍一下，我是一名刑事辩护律师，执业多年，主要做刑事案件。盗窃、诈骗、毒品、故意伤害、帮信罪……这些罪名我都打过交道。刑事辩护这个领域，说句实在话，门槛高、压力大、责任重。一个案子办下来，光案卷材料可能就有几十本，每本几百页，你要逐字逐句地看，不放过任何一个可能影响定罪量刑的细节。
更重要的是，我是一名"重度AI用户"。从最早期的通用大模型对话工具，到后来的各种AI编程助手、AI写作工具、AI法律检索工具，我几乎全都用过。可以说，我是法律行业里最早一批拥抱AI的律师之一。这几年下来，我用过不下十几款AI工具，有的用来做法律检索，有的用来辅助写文书，有的用来做案件分析。但说实话，没有一款工具能让我真正满意——它们要么功能太单一，要么理解能力太差，要么操作体验太拉胯。每次用完都有一种"差一口气"的感觉，好像工具是有了，但离真正提升工作效率还差得远。
如果你是一名律师，或者你身边有律师朋友，那你一定听过这样的抱怨："案卷看不完，辩护词写到手抽筋，法律条文翻到眼花。"这不是夸张，这是法律行业的日常。每天面对堆积如山的案卷材料，每一个案件都涉及大量的法律法规、司法解释、判例分析，光是把这些材料消化完就已经够让人头疼了，更别说还要在此基础上撰写专业的法律文书。
记得刚入行那会儿，带我的老律师跟我说："做刑辩，最重要的就是细心。"他说得没错，但细心是有代价的——你需要花大量的时间去反复核对每一个细节，每一条法律条文都要精确到第几条第几款。一个看似简单的盗窃案，可能涉及刑法第264条、相关司法解释、地方量刑指导意见，再加上类似案例的检索，光是准备工作就要花上好几天。入行这么多年，我深刻体会到传统工作方式带来的种种不便。
传统的工作方式，说白了就是"人肉搜索引擎"。遇到法律问题，先打开电脑上的法律法规数据库，输入关键词搜索，然后在海量的结果中一条一条地筛选出相关的条文。这个过程不仅耗时，而且容易遗漏。人不是机器，总会有疏忽的时候。有时候一个关键的法律条文没有检索到，可能就会影响到整个案件的辩护策略。更让人崩溃的是，不同的数据库之间格式不统一，检索体验也参差不齐，有时候为了找一个条文，要在好几个平台之间来回切换。
辩护词的撰写更是一项浩大的工程。一份高质量的辩护词，不仅需要准确引用法律条文，还需要结合案件事实进行深入分析，提出有说服力的辩护观点。这要求律师既要有扎实的法律功底，又要有出色的文字表达能力。说实话，每次写辩护词的时候，我都觉得自己不是在当律师，而是在当作家——一个需要反复修改、推敲每一个用词的作家。而且每个案件的情况都不一样，你没办法直接套模板，必须根据具体案情量身定制。
除了案卷和文书，律师的日常工作还包括大量的沟通和协调。要和当事人沟通案件进展，要和检察官交流辩护意见，要和法官讨论庭审安排，还要和团队成员协作分工。这些工作虽然不涉及具体的法律技术，但同样需要花费大量的时间和精力。有时候一天下来，光是处理这些事务性的工作就已经精疲力尽了，根本没有时间坐下来好好研究案件。
正是在这样的背景下，我开始关注AI技术在法律领域的应用。说实话，一开始我是持怀疑态度的。法律是一个高度专业化的领域，涉及到大量的专业知识和逻辑推理，AI真的能胜任吗？但是，随着大语言模型技术的飞速发展，我逐渐改变了看法。现在的AI已经能够理解和生成相当复杂的法律文本，能够进行基本的法律推理，甚至能够根据案件事实提出初步的辩护思路。虽然它还不能完全替代律师，但作为一个辅助工具，它的潜力是巨大的。
AI Agent（智能体）的概念更是让我眼前一亮。传统的AI工具，比如ChatGPT，虽然能够回答法律问题，但它缺乏主动性和连续性。你问一个问题，它回答一个，然后对话就结束了。但AI Agent不同，它可以持续地、主动地为你工作。它可以帮你管理案件信息，可以自动检索相关法律条文，可以根据你的需求生成法律文书初稿，甚至可以提醒你即将到来的庭审日期。它就像一个24小时不休息的法律助手，随时待命。
那么，为什么选择SOLO作为开发工具呢？这就要说到我的技术背景了。坦白说，我不是一个专业的程序员。虽然大学的时候学过一些编程基础，但那都是很久以前的事了。如果要我用传统的开发方式来搭建一个AI Agent工作台，光是搭建开发环境、学习框架、调试代码这些前置工作，就足以让我望而却步了。但是SOLO改变了一切。
SOLO是一个AI编程助手，它的核心理念就是"你说需求，它写代码"。你不需要懂复杂的编程语法，不需要了解框架的底层原理，只需要用自然语言描述你想要的功能，SOLO就能帮你生成相应的代码。更厉害的是，它不仅能写代码，还能帮你调试、优化、甚至重构。它就像一个全栈AI工程师，从头到尾陪你完成整个项目的开发。对于我这样一个"半路出家"的法律人来说，SOLO简直就是为我量身定做的开发工具。
就这样，带着对法律AI的憧憬和对SOLO的好奇，我开始了这段从零到一的搭建之旅。接下来，让我详细地讲述这个过程，希望能给同样想用AI技术提升工作效率的朋友们一些参考和启发。
第二章：认识SOLO——我的AI编程搭档
在正式开始搭建项目之前，我觉得有必要先介绍一下SOLO这个"搭档"。毕竟，整个项目的开发过程，基本上就是我和SOLO两个人（好吧，一个人和一个AI）的协作过程。了解SOLO的能力，有助于你理解后面我会描述的那些"神奇"的开发体验。
SOLO是什么？简单来说，它是一个AI驱动的编程助手平台。但如果你只把它当成一个"高级版的代码补全工具"，那就太小看它了。SOLO的核心能力远不止于此。它更像是一个完整的AI开发团队——产品经理、架构师、前端工程师、后端工程师、测试工程师，这些角色它都能胜任。你只需要扮演"甲方"的角色，提出你的需求和想法，SOLO会帮你把需求转化为可运行的代码。
首先说说SOLO的代码生成能力。这是它最基础也是最核心的功能。你只需要用自然语言描述你想要实现的功能，比如"我需要一个聊天界面，左边显示对话历史，右边显示案件信息"，SOLO就能理解你的意图，并生成相应的代码。而且它生成的代码不是那种"能跑就行"的demo级别代码，而是结构清晰、注释完整、符合最佳实践的生产级代码。这一点让我非常惊讶，因为我之前用过一些代码生成工具，生成的代码往往需要大量的手动修改才能使用，但SOLO生成的代码质量真的很高。
SOLO的代码生成能力不仅体现在单个功能的实现上，还体现在它对整个项目的理解能力上。它会根据你的需求描述，自动规划项目的架构，设计合理的目录结构，选择合适的技术栈。比如在我的项目中，我告诉SOLO我要做一个法律AI Agent工作台，它就自动帮我规划了前后端分离的架构，前端使用Vue3 + Element Plus，后端使用FastAPI，并且给出了完整的目录结构和技术选型方案。这种"从需求到架构"的能力，对于一个非专业程序员来说，简直是雪中送炭。
再来说说SOLO的项目管理能力。开发一个完整的项目，不仅仅是写代码那么简单。你还需要规划开发步骤、管理文件结构、处理依赖关系、调试错误……这些工作对于专业开发者来说可能是家常便饭，但对于我这样的"业余选手"来说，每一步都可能是一个坑。SOLO在这方面表现得非常出色。它会自动把整个项目拆解成多个步骤，按照合理的顺序逐步执行。每完成一个步骤，它会告诉你完成了什么，接下来要做什么。如果某个步骤出了问题，它会自动分析错误信息，尝试修复，然后继续执行。这种自动化的项目管理能力，大大降低了开发的门槛。
特别值得一提的是SOLO的浏览器调试能力。在开发前端界面的时候，实时预览是非常重要的。SOLO可以自动启动一个本地服务器，在浏览器中打开你正在开发的页面，并且实时显示代码修改的效果。更厉害的是，如果页面出现了问题，SOLO可以自动打开浏览器的开发者工具，查看控制台日志，分析错误信息，然后定位到具体的代码位置进行修复。整个过程你只需要坐在旁边看着，SOLO会自己完成所有的调试工作。这种"自动调试"的能力，在我遇到那些让人抓狂的Bug时，真的帮了大忙。
除了以上这些核心能力，SOLO还有一些让我印象深刻的特点。比如它的上下文理解能力——在整个开发过程中，SOLO会记住你之前说过的话、做过的修改、遇到的问题，所以你不需要每次都从头解释你的需求。比如它的多轮对话能力——你可以和SOLO进行持续的对话，逐步细化和调整你的需求，它会根据你的反馈不断优化代码。比如它的学习能力——随着项目的推进，SOLO会越来越了解你的项目结构和编码风格，生成的代码也会越来越符合你的期望。
所以，为什么说SOLO是"全栈AI工程师"呢？因为它确实具备了一个全栈工程师应该具备的所有能力：需求分析、架构设计、前端开发、后端开发、数据库设计、API设计、调试测试、代码优化……而且它的效率比人类工程师高得多——毕竟它不需要休息，不需要查文档，也不会因为写了一天的代码而头昏脑涨。当然，SOLO也不是完美的，它也有理解偏差的时候，也有生成错误代码的时候。但总体来说，它给我的开发体验是非常正面的，尤其是在我这样一个非专业开发者的手里，SOLO让我能够做出超出我能力范围的产品。
在后面的章节中，我会详细描述我和SOLO协作开发的全过程。你会看到SOLO是如何理解我的需求、如何规划项目架构、如何一步步实现各个功能模块的。你也会看到我们遇到了哪些问题、是如何解决的。希望通过这些真实的开发经历，让你对SOLO的能力有一个更直观、更全面的了解。
最后说一句心里话。作为一个已经重度使用AI工具很久的法律人，我自认为对AI的能力上限是有认知的。但SOLO给我的体验，真的让我刷新了对"AI编程助手"这个概念的理解。它不是那种你说了半天它还理解不对的"人工智障"，也不是那种只会写两行Hello World就完事的玩具。它是真正能理解复杂需求、能独立完成大型项目、能在遇到问题时自己排查修复的"AI工程师"。说真的，这是我第一次遇到这么丝滑的AI协作体验——丝滑到有时候我会怀疑，对面坐的到底是一个AI还是一个经验丰富的全栈开发工程师。这种体验，用过的都懂。
第三章：项目规划——从需求到架构
在正式动手写代码之前，做好项目规划是至关重要的。这就好比盖房子之前要先画好图纸一样，没有一个清晰的规划，后面开发过程中就会走很多弯路。虽然SOLO有很强的自动规划能力，但作为"甲方"，我还是要先把需求想清楚，才能让SOLO更好地理解我要做什么。
首先进行需求分析。作为一名刑事辩护律师，我的核心工作场景有哪些呢？我仔细梳理了一下，大概可以分为以下几个方面：
第一，法律咨询与对话。这是最基础也是最高频的工作场景。当事人会通过各种渠道向我咨询法律问题，我需要根据他们描述的情况，给出专业的法律意见。很多时候，当事人描述的情况是模糊的、不完整的，我需要通过追问来获取更多的信息，然后综合分析，给出有针对性的建议。如果有一个AI助手能够帮我处理初步的法律咨询，筛选和整理案件信息，那将大大提高我的工作效率。
第二，案件管理。一个律师手上同时处理多个案件是常态。每个案件都有大量的信息需要管理：当事人信息、案件基本信息、案卷材料、辩护策略、庭审日程、工作进度……如果这些信息都靠脑子记或者用Excel表格管理，不仅效率低下，而且容易出错。我需要一个能够集中管理所有案件信息的系统，能够方便地查看和更新案件状态。
第三，法律知识库。法律是一个知识密集型的行业，律师需要掌握大量的法律法规、司法解释、指导案例等。虽然现在有很多法律数据库可以使用，但它们大多是通用的，缺乏个性化的整理和标注。我希望能够有一个自己的法律知识库，把我常用的法律条文、典型案例、辩护技巧等整理归类，方便随时查阅和引用。
第四，文书起草。辩护词、法律意见书、取保候审申请书、质证意见……律师需要撰写的法律文书种类繁多，每一种都有特定的格式和要求。虽然很多文书有模板可以参考，但每次都需要根据具体案情进行大量的修改和调整。如果AI能够根据案件信息自动生成文书初稿，那将节省大量的时间。
第五，日程管理。律师的时间安排非常紧凑，庭审、会见、阅卷、开会……各种事务交织在一起，如果不做好时间管理，很容易遗漏重要的事项。一个智能的日程提醒系统，对于律师来说是非常实用的。
需求梳理清楚之后，接下来就是技术选型了。说实话，这部分我基本上是交给SOLO来决定的。我只需要告诉SOLO我的需求是什么，对技术有什么偏好（如果有的话），SOLO就会给出合理的技术选型方案。在我的项目中，SOLO推荐了以下技术栈：
前端：Vue3 + Element Plus。Vue3是目前最流行的前端框架之一，它的组合式API（Composition API）设计非常灵活，适合构建复杂的交互界面。Element Plus是Vue3的UI组件库，提供了丰富的现成组件，可以大大加快开发速度。这个选择我非常满意，因为Element Plus的组件风格简洁专业，很适合法律行业的应用场景。
后端：FastAPI。FastAPI是Python的一个现代Web框架，它的特点是高性能、易使用、自带API文档。选择FastAPI的一个重要原因是，后端需要对接大语言模型的API，而Python在AI领域有着无可比拟的生态优势。各种AI相关的SDK和工具，基本上都优先支持Python。用FastAPI做后端，可以很方便地集成大语言模型的能力。
大语言模型：支持多种模型的灵活切换。考虑到不同场景可能需要不同能力的模型，系统设计上需要支持模型的灵活配置和切换。具体的模型名称和API地址属于敏感信息，这里就不详细展开了，总之系统支持配置多个模型端点，用户可以根据需要选择使用。
系统架构方面，SOLO帮我设计了前后端分离的架构。前端负责用户界面的展示和交互，后端负责业务逻辑的处理和AI模型的调用。前后端通过RESTful API进行通信。这种架构的好处是前后端可以独立开发和部署，互不影响。而且如果以后需要做移动端或者桌面端，后端的API可以直接复用。
在模块化设计方面，系统被划分为以下几个核心功能模块：
对话工作台模块：这是系统的核心模块，提供与AI进行法律对话的界面。用户可以在对话中咨询法律问题、讨论案件策略、请求生成法律文书等。对话支持多轮交互，上下文连贯，并且支持创建多个独立的对话会话。
案件管理模块：用于管理案件信息，包括案件的基本信息、当事人信息、案卷材料、辩护策略等。用户可以创建、编辑、删除案件，也可以在对话中引用案件信息，让AI基于具体的案件上下文提供更精准的法律建议。
知识库模块：用于存储和管理法律知识，包括法律法规、司法解释、典型案例等。用户可以手动添加知识条目，也可以让AI自动从对话中提取和整理有价值的法律知识。
文书起草模块：提供法律文书的模板和自动生成功能。用户可以选择文书类型，输入关键信息，AI会根据模板和案件信息生成文书初稿。用户可以对初稿进行编辑和修改，直到满意为止。
设置模块：用于配置系统的各项参数，包括模型选择、API配置、界面主题等。这个模块让系统具有更好的灵活性和可定制性。
规划做好之后，我对整个项目有了清晰的认识。虽然功能不少，但有了SOLO这个"全栈AI工程师"的加持，我对完成这个项目充满了信心。接下来，就是激动人心的实战开发环节了。
第四章：实战开发——与SOLO的协作全过程
这一章是整篇文章的核心，我会详细记录我和SOLO从零开始搭建这个法律AI Agent工作台的全过程。每一个功能模块的实现，每一次遇到问题和解决问题的经历，我都会如实记录下来。希望通过这些详细的描述，让你感受到与SOLO协作开发的真实体验。
4.1 后端搭建：FastAPI框架与API接口设计
后端是整个系统的"大脑"，负责处理业务逻辑和调用AI模型。我告诉SOLO："我要用FastAPI搭建后端，需要实现对话接口、案件管理接口、知识库接口和设置接口。"SOLO很快就理解了我的需求，并且给出了一个清晰的后端项目结构。
SOLO首先帮我创建了FastAPI项目的基本结构，包括主入口文件、路由模块、数据模型、配置文件等。它生成的代码结构非常清晰，每个文件都有明确的职责。主入口文件负责创建FastAPI应用实例和注册路由，路由模块按照功能划分，数据模型使用Pydantic定义，配置文件使用环境变量管理敏感信息。
在API接口设计方面，SOLO帮我设计了以下核心接口：对话接口支持发送消息和获取对话历史，案件管理接口支持案件的增删改查操作，知识库接口支持知识条目的管理和检索，设置接口支持系统配置的读取和更新。每个接口都遵循RESTful设计规范，请求和响应的数据结构都有清晰的定义。
模型对接是后端开发中比较关键的一环。由于涉及API密钥等敏感信息，具体的对接细节在这里就不展开说了。SOLO在这方面表现得非常专业，它帮我把API密钥等敏感信息通过环境变量的方式管理，而不是硬编码在代码中。它还实现了模型调用的封装层，支持灵活切换不同的模型端点，这样以后如果需要更换模型或者增加新的模型，只需要修改配置就可以了，不需要改动业务代码。
在后端开发过程中，SOLO还帮我处理了很多细节问题。比如，它实现了请求的参数校验，确保传入的数据格式正确；它添加了错误处理中间件，统一处理各种异常情况；它还配置了CORS（跨域资源共享），这样前端在开发环境中就可以直接调用后端接口，不会遇到跨域问题。这些细节虽然不起眼，但对于保证系统的稳定性和开发体验来说非常重要。
整个后端搭建过程，SOLO基本上是一气呵成的。我只需要描述需求，它就能生成高质量的代码。偶尔遇到一些我不确定的地方，比如"对话历史应该存储在哪里"这样的问题，SOLO会给出几个选项让我选择，然后根据我的选择来实现。这种交互方式非常自然，就像和一个经验丰富的同事讨论技术方案一样。
4.2 前端开发：Vue3组件化开发与路由设计
后端搭好之后，接下来就是前端开发了。前端是用户直接接触的部分，界面的美观程度和交互体验直接影响用户的使用感受。我告诉SOLO：“前端用Vue3 + Element Plus，需要实现对话页面、案件管理页面、知识库页面和设置页面，要有侧边栏导航。”
SOLO首先帮我搭建了Vue3项目的基本结构。它使用了Vite作为构建工具，配置了路由（Vue Router）和状态管理（Pinia）。项目结构非常规范，组件按照功能模块组织，公共组件放在单独的目录中，工具函数和常量也有专门的文件管理。
在路由设计方面，SOLO帮我规划了以下路由：首页是对话工作台，这是用户最常用的页面；案件管理页面用于查看和管理所有案件；知识库页面用于管理法律知识条目；设置页面用于配置系统参数。每个路由都配置了对应的组件，并且设置了合理的页面标题。
组件化开发是Vue3的核心理念之一。SOLO在这方面做得非常好，它把每个页面都拆分成了多个可复用的组件。比如对话页面，它拆分成了消息列表组件、消息输入组件、对话侧边栏组件等。每个组件都有清晰的props定义和事件接口，组件之间的通信通过props和emit来实现，状态管理则通过Pinia来处理。这种组件化的设计方式，不仅让代码结构更加清晰，也方便了后续的维护和扩展。
在状态管理方面，SOLO帮我设计了几个核心的Pinia Store：对话Store管理对话列表和当前对话的消息；案件Store管理案件数据；设置Store管理系统配置。每个Store都定义了state、getters和actions，数据流非常清晰。而且SOLO还实现了数据的本地持久化，这样即使刷新页面，用户的数据也不会丢失。
侧边栏导航是整个应用的"骨架"。SOLO使用Element Plus的菜单组件实现了一个美观的侧边栏，支持折叠和展开。菜单项包括对话工作台、案件管理、知识库和设置，每个菜单项都有对应的图标。侧边栏的样式和整体界面风格保持一致，深色背景配合浅色文字，看起来非常专业。
4.3 对话系统实现：HTTP请求与消息持久化
对话系统是整个应用最核心的功能，也是技术实现上最复杂的部分。一开始，SOLO尝试使用WebSocket来实现实时通信，但在实际测试中发现WebSocket连接在某些网络环境下不太稳定（这个坑在第五章会详细讲）。经过讨论，我们决定改用HTTP请求来实现——用户发送消息后，前端通过HTTP POST请求将消息发送到后端，后端调用AI模型获取回复，然后将回复返回给前端。
虽然HTTP请求不如WebSocket那样"实时"，但对于法律咨询这种场景来说，完全够用了。用户发送一个问题，等待AI思考并回复，这个过程中用户本来就需要等待。而且HTTP请求的实现更简单、更稳定，不容易出现连接中断的问题。SOLO帮我实现了一个优雅的消息发送机制：用户点击发送后，消息立即显示在界面上（乐观更新），同时显示一个"正在思考"的加载动画，等后端返回结果后，再将AI的回复追加到消息列表中。
消息持久化是另一个重要的功能。一开始的实现中，消息只存储在内存中，刷新页面后消息就丢失了。这显然是不行的。SOLO帮我实现了消息的本地持久化——每条消息都会保存到localStorage中，页面加载时从localStorage中读取历史消息。这样即使关闭浏览器再打开，之前的对话记录也还在。同时，后端也实现了消息的数据库存储，为以后实现多设备同步打下了基础。
在对话系统的实现过程中，还有一个细节值得一提：消息的流式显示。当AI生成较长的回复时，如果等它全部生成完再显示，用户需要等待很长时间，体验不好。SOLO帮我实现了流式输出——AI每生成一段文字，就实时显示在界面上，就像ChatGPT那样一个字一个字地"打"出来。这个功能大大提升了用户的等待体验，让对话过程更加自然流畅。
多对话管理也是对话系统的一个重要功能。用户可能同时在进行多个法律咨询，每个咨询都是一个独立的对话。SOLO帮我实现了对话列表功能，用户可以创建新的对话、切换不同的对话、删除不需要的对话。每个对话都有独立的上下文，AI会根据当前对话的历史消息来理解用户的意图，提供连贯的法律建议。
4.4 UI美化升级：深色主题、动画效果与响应式布局
功能实现之后，接下来就是UI美化环节了。一个专业的法律工具，界面不仅要好用，还要好看。我告诉SOLO："我想做一个深色主题的界面，要有动画效果，要支持响应式布局。"SOLO二话不说就开始了美化工作。
深色主题是法律行业应用的一个趋势。很多律师习惯在晚上加班工作，深色主题可以减少眼睛的疲劳。SOLO帮我设计了一套完整的深色配色方案：背景使用深灰色（#1a1a2e），侧边栏使用更深的颜色（#16213e），卡片和对话框使用稍浅的灰色（#0f3460），文字使用浅色（#e0e0e0），强调色使用蓝色（#4fc3f7）。这套配色方案既专业又舒适，看起来很有科技感。
动画效果是提升用户体验的重要手段。SOLO帮我添加了多种动画效果：页面切换时有平滑的过渡动画，消息出现时有淡入效果，按钮点击有缩放反馈，侧边栏折叠有滑动动画。这些动画虽然细微，但让整个应用感觉更加"活"了，不再是一个冷冰冰的工具。SOLO使用了CSS transition和animation来实现这些效果，代码简洁高效。
响应式布局是现代Web应用的标配。律师们可能会在不同的设备上使用这个工具——办公室的电脑、家里的笔记本、出差时的平板电脑。SOLO帮我实现了完整的响应式布局：在大屏幕上，侧边栏和主内容区并排显示；在中屏幕上，侧边栏可以折叠为图标模式；在小屏幕上，侧边栏变成抽屉式，通过点击按钮弹出。对话界面也做了响应式处理，消息列表和输入框在不同屏幕尺寸下都能正常显示和使用。
在UI美化的过程中，SOLO还帮我处理了很多细节。比如，它优化了消息气泡的样式——用户消息靠右显示，使用蓝色背景；AI回复靠左显示，使用深色背景。消息气泡有圆角和阴影效果，看起来像现代即时通讯应用的风格。它还优化了输入框的设计——支持多行输入、支持Shift+Enter换行、支持Enter发送，还添加了一个发送按钮和一个附件按钮（虽然附件功能还没有实现，但按钮先预留着）。
经过这轮UI美化，整个应用的视觉效果有了质的飞跃。从一个简陋的原型，变成了一个看起来相当专业的法律AI工具。我在朋友圈发了几张截图，好多律师同行都来问这是什么工具，能不能试用。那一刻，我觉得所有的努力都值了。
第五章：踩坑实录——那些让我抓狂的Bug
如果说前面的章节讲的是"高光时刻"，那这一章讲的就是"至暗时刻"了。开发过程中遇到的那些Bug，有的让人哭笑不得，有的让人怀疑人生，但每一个都让我学到了宝贵的经验。下面就来盘点一下那些让我抓狂的Bug。
坑1：消息位置左右反转——用户消息和AI回复搞反了
这是开发过程中遇到的第一个让人哭笑不得的Bug。当我第一次测试对话功能的时候，我发现一个奇怪的现象：我发送的消息显示在左边，AI的回复反而显示在右边。这完全反了！按照常规的聊天界面设计，用户的消息应该在右边，AI的回复应该在左边。
我仔细检查了代码，发现消息组件中有一个`isUser`属性用来判断消息是否来自用户。如果`isUser`为true，消息靠右显示；如果为false，消息靠左显示。逻辑看起来没问题。那问题出在哪里呢？
排查了半天，我终于发现了问题所在：在后端返回消息数据的时候，`role`字段的值是"assistant"（表示AI回复），但前端在解析的时候，把判断逻辑写反了——它把`role === “assistant”`的消息当作用户消息来处理了。一个简单的逻辑错误，却导致了完全相反的显示效果。
修复方法很简单，把判断逻辑改正过来就行了。但这个Bug给我上了一课：在处理数据流向的时候，一定要仔细核对前后端的数据约定，确保两边的理解是一致的。
坑2：WebSocket连接不稳定导致输入框卡死
这个坑是让我最头疼的。一开始，对话系统使用WebSocket来实现实时通信。在本地开发环境中一切正常，但当我把应用部署到服务器上之后，问题就来了：WebSocket连接经常莫名其妙地断开，而且断开之后前端没有正确处理，导致输入框变成了"只读"状态——用户无法输入任何内容，只能刷新页面。
我尝试了各种方法来解决这个问题：添加心跳机制保持连接活跃、实现自动重连逻辑、增加连接状态的UI提示……但WebSocket的稳定性问题始终没有得到根本解决。有时候网络波动一下，连接就断了；有时候服务器负载高一点，连接也会断。而且在某些网络环境下（比如公司网络、手机热点），WebSocket根本就连接不上。
最后，我做出了一个"痛苦"的决定：放弃WebSocket，改用HTTP请求。虽然这意味着放弃了"真正的实时通信"，但对于法律咨询这个场景来说，HTTP请求完全够用。用户发送一个问题，等待AI回复，这个过程本来就不是毫秒级的。改用HTTP之后，稳定性问题彻底解决了，再也没有出现过输入框卡死的情况。
这个坑让我明白了一个道理：技术选型不能只看"酷不酷"，要看"适不适合"。WebSocket确实很酷，但对于这个项目来说，HTTP请求才是更合适的选择。实用主义，有时候比技术主义更重要。
坑3：浏览器缓存问题——改了代码但页面不更新
这个坑虽然不大，但出现的频率非常高，几乎每天都会遇到好几次。每次SOLO帮我修改了前端代码之后，我在浏览器中刷新页面，发现界面完全没有变化。一开始我还以为是SOLO的代码有问题，反复让它检查和修改。后来才发现，是浏览器的缓存搞的鬼——浏览器缓存了旧的JS和CSS文件，所以即使代码已经更新了，页面显示的还是旧版本。
解决方法其实很简单：强制刷新（Ctrl+Shift+R或者Cmd+Shift+R），或者打开浏览器的开发者工具，勾选"Disable cache"选项。但问题是，每次都要手动操作，非常烦人。后来SOLO帮我在Vite的配置中添加了文件名哈希（content hash），这样每次文件内容变化时，文件名也会变化，浏览器就不会使用缓存的旧文件了。
另外，SOLO还帮我配置了Service Worker的缓存策略，确保在更新代码后能够及时清理旧缓存。虽然这些配置对于专业前端开发者来说是基础知识，但对于我这样的"业余选手"来说，如果没有SOLO的帮助，可能要花很长时间才能找到原因和解决方案。
坑4：模型选择器选不中——字段名不匹配
这个坑堪称"最隐蔽的Bug"。设置页面有一个模型选择器，用户可以从下拉列表中选择要使用的AI模型。下拉列表能正常显示模型列表，但当我点击某个模型选项时，选择器并没有选中它——下拉列表关闭后，显示的还是之前的选项。
我让SOLO排查这个问题，它检查了前端的绑定逻辑，看起来没有问题。它又检查了后端返回的数据格式，也看起来正常。那到底哪里出了问题？
经过仔细的对比分析，SOLO终于发现了问题：后端返回的模型数据中，主键字段名是`id`，但前端在选择器组件中绑定的值字段（value-key）设置成了`model_id`。由于字段名不匹配，选择器无法正确识别每个选项的值，所以无论点击哪个选项都无法选中。
修复方法就是把前端的value-key从`model_id`改成`id`，或者把后端返回的字段名改成`model_id`。我们选择了修改前端，因为后端的数据库结构已经定好了，改起来影响面更大。
这个Bug让我深刻体会到了前后端数据约定的重要性。如果在一开始就明确定义好数据接口的字段名称和格式，后面就可以避免很多这种"低级错误"。
坑5：对话切换后消息丢失——没有实现消息持久化
这个坑的发现过程非常"戏剧性"。有一次，我在一个对话中问了AI一个很复杂的法律问题，AI给出了一个非常详细的回答。我觉得这个回答很有价值，就切换到另一个对话去处理别的事情。等我切回来的时候，发现之前的对话消息全都不见了！那一刻，我的心情可以用"崩溃"来形容。
原因很简单：一开始的实现中，对话消息只存储在组件的state中，切换对话时state被覆盖，之前的消息自然就丢失了。这就像你在一个记事本上写了东西，然后翻到另一页写字，再翻回来的时候发现之前写的内容被擦掉了。
SOLO帮我实现了完整的消息持久化方案：每条消息在创建时保存到localStorage，切换对话时从localStorage中加载对应对话的消息，删除对话时同时删除对应的消息记录。后来还在后端添加了数据库存储，实现了消息的持久化和多设备同步。
这个坑虽然解决起来不难，但给我的教训很深刻：在开发任何涉及用户数据的功能时，一定要考虑数据的持久化存储。不能只依赖内存中的状态，因为内存中的数据是脆弱的——页面刷新、组件卸载、应用关闭，都可能导致数据丢失。
以上就是开发过程中遇到的五个主要Bug。每一个都让我头疼不已，但每一个也都让我学到了新的东西。如果你也在做类似的项目，希望这些"前车之鉴"能帮你少走一些弯路。当然，有了SOLO的帮助，这些坑的排查和修复过程都比预想的要顺利得多。如果不是SOLO帮我自动分析错误日志、定位问题代码，我可能还在第一个坑里挣扎呢。
第六章：SOLO的超强能力展示
经过前面几章的描述，相信你对SOLO的能力已经有了一定的了解。但我觉得还不够，所以我决定在这一章中，更加集中和系统地展示SOLO在项目开发过程中展现出的各项超强能力。这些能力不仅让我这个非专业程序员能够完成一个专业级的产品，更让我对AI辅助开发的未来充满了期待。
首先是自然语言编程的能力。在整个开发过程中，我几乎没有手动写过一行代码。所有的代码都是通过自然语言描述需求，由SOLO生成的。比如我说"我需要一个深色主题的聊天界面，左边是对话列表，右边是聊天区域"，SOLO就能理解我的意图，生成完整的Vue组件代码。它不仅实现了基本的布局结构，还考虑到了消息的显示样式、滚动行为、响应式适配等细节。这种"你说需求，它写代码"的体验，对于不擅长编程的人来说，真的是一种解放。
当然，自然语言编程并不意味着你可以随便说，SOLO就能完美理解。在表达需求的时候，还是需要尽量清晰和具体。比如你不能只说"做一个好看的界面"，而要说"做一个深色主题的界面，背景色用深灰，卡片用圆角，按钮有hover效果"。描述越具体，SOLO生成的代码就越符合你的期望。不过即使你的描述不够精确，SOLO也会通过追问来澄清需求，或者生成一个基础版本让你在此基础上提出修改意见。
其次是自动调试的能力。这是SOLO让我最惊叹的功能之一。在开发过程中，每当出现Bug或者界面显示异常的时候，SOLO会自动打开浏览器进行调试。它会查看页面的实际渲染效果，打开开发者工具检查控制台日志，分析网络请求的响应数据，甚至检查DOM元素的计算样式。然后它会根据这些信息，定位到问题所在的代码位置，并提出修复方案。整个过程完全自动化，我只需要等待SOLO的调试结果。
举个例子，有一次页面的布局出现了错位，左侧边栏和右侧内容区重叠了。我告诉SOLO"页面布局有问题"，SOLO就自动打开了浏览器，检查了页面元素的尺寸和位置，发现是CSS的flex布局设置有误——侧边栏的宽度没有正确设置，导致内容区被挤压。SOLO立刻修改了CSS代码，刷新页面后布局就正常了。从发现问题到修复完成，前后不到两分钟。如果是我自己来排查，可能要花上半个小时。
第三是代码重构的能力。随着项目的推进，代码量越来越大，有时候会出现代码结构不够清晰、重复代码较多等问题。SOLO可以帮助进行代码重构，优化项目结构。比如有一次，我发现对话组件的代码变得非常臃肿，一个文件就有好几百行。我让SOLO"优化一下对话组件的代码结构"，它就把原来的大组件拆分成了多个小组件——消息列表组件、消息气泡组件、输入框组件、工具栏组件等，每个组件各司其职，代码变得清晰易读。
SOLO的重构能力不仅体现在组件拆分上，还体现在代码优化上。它会检查代码中是否存在性能问题（比如不必要的重新渲染）、是否有安全隐患（比如XSS漏洞）、是否符合最佳实践（比如合理的错误处理），然后给出优化建议或者直接进行修改。这种"代码审查+自动修复"的能力，对于保证代码质量非常有帮助。
第四是持续迭代的能力。一个产品从原型到成品，需要经历多次迭代。每一次迭代都可能涉及新功能的添加、现有功能的修改、Bug的修复等。SOLO能够很好地支持这种持续迭代的开发模式。它会记住项目的整体架构和已完成的功能，在每次迭代时基于当前的项目状态进行修改，而不是从头开始。这意味着你可以逐步完善你的产品，每次只关注当前需要修改的部分，不用担心"牵一发而动全身"。
在我的项目中，从最初的原型到最终的成品，大概经历了十几次迭代。每次迭代都是基于上一次的成果进行的——比如先实现基本的对话功能，然后添加案件管理，再优化UI，再修复Bug……SOLO在每次迭代中都能准确地理解我要修改什么，并且在不影响已有功能的前提下完成修改。这种持续迭代的能力，让整个开发过程变得非常高效和可控。
最后，我想总结一下SOLO给我带来的最大价值：它让我一个非专业程序员也能做出专业级的产品。在没有SOLO之前，我从未想过自己能够独立开发一个Web应用。但现在，我不仅做出了一个功能完整的法律AI Agent工作台，而且在开发过程中学到了很多关于软件工程的知识——项目管理、代码架构、调试技巧、版本控制……这些知识虽然不能让我变成一个专业的程序员，但至少让我能够更好地理解技术、更好地与技术团队沟通、更好地利用技术工具来提升工作效率。
SOLO不是在替代程序员，而是在降低编程的门槛，让更多有想法、有需求但缺乏编程技能的人能够把自己的想法变成现实。这对于法律行业来说尤其有意义——因为我们最了解自己的需求，如果能够自己动手解决需求，就不需要依赖外部技术团队，效率和灵活性都会大大提高。
第七章：最终成果展示
经过前面几章的开发和迭代，这个法律AI Agent工作台终于从一个模糊的想法变成了一个实实在在的产品。在这一章中，我将向大家展示最终成果的各项功能，并通过截图让你直观地感受这个产品的界面和交互体验。
对话工作台是整个系统的核心功能。打开应用后，用户首先看到的就是对话工作台的首页。左侧是对话列表，显示所有历史对话，用户可以创建新对话、切换对话、删除对话。右侧是聊天区域，展示当前对话的消息记录和输入框。在没有开始对话的时候，聊天区域会显示一个欢迎界面，引导用户开始使用。整体界面采用深色主题设计，专业而不失现代感。
在对话功能方面，用户可以输入任何法律问题，AI会基于其法律知识库给出专业的回答。回答的内容包括相关法律条文的引用、法律原理的解释、实务操作的建议等。对于刑事辩护领域的常见问题，比如"盗窃罪的量刑标准是什么"、“取保候审的条件和流程”、"如何进行无罪辩护"等，AI都能给出相当详细和专业的回答。
自媒体创作模块是我在规划时特别设计的一个功能。作为一名刑事辩护律师，除了日常的办案工作，我也经常在微信公众号、知乎等平台发表法律科普文章。这不仅是个人品牌的塑造，也是法律服务的一种延伸。SOLO帮我设计了自媒体创作模块的完整框架，包括AI辅助写作、多平台内容适配、内容模板库和数据分析四个核心功能。虽然目前这些功能还在开发中，但整体架构和UI设计已经完成，后续只需要接入相应的AI接口就可以快速上线。
综合知识库模块是整个工作台的"大脑"。律师的工作离不开大量的法律法规、司法解释、指导案例等专业资料。传统的法律检索方式效率低下，而且检索结果往往不够精准。SOLO帮我设计的综合知识库模块，支持按类别管理法律知识条目，包括法律法规、司法解释、指导案例、辩护技巧等。用户可以随时添加、编辑和删除知识条目，并通过关键词快速检索。这个模块的设计理念是：让律师拥有一个属于自己的、个性化的法律知识管理系统，把常用的法律条文和案例整理归类，方便在办案过程中随时查阅和引用。
案件管理模块是律师日常工作中最基础也是最核心的功能。一个律师手上同时处理多个案件是常态，每个案件都有大量的信息需要管理。SOLO帮我实现的案件管理模块支持案件的创建、编辑、删除和搜索，用户可以为每个案件添加详细的描述和标签，包括案件类型、当事人信息、案件状态、重要日期等。案件列表以表格形式展示，支持按状态筛选和按关键词搜索，让律师能够快速找到需要的案件信息。
以上就是这个法律AI Agent工作台的最终成果展示。从对话工作台到自媒体创作，从综合知识库到案件管理，每一个功能模块都是围绕刑事辩护律师的实际工作需求来设计的。这些功能模块共同构成了一个完整的法律AI工作台，为刑事辩护律师提供全方位的AI辅助支持。
第八章：总结与展望
写到这里，这篇文章也接近尾声了。回顾整个项目的开发过程，从最初的一个想法，到需求分析、技术选型、架构设计、功能开发、UI美化、Bug修复，再到最终的产品成型，整个过程历时大约两周。对于一个非专业程序员来说，能够在两周内独立完成一个功能完整的Web应用，这在没有AI辅助的时代是难以想象的。
这个项目的成功，很大程度上要归功于SOLO。是SOLO让我能够跨越编程技能的鸿沟，把脑海中的想法变成了现实。在整个开发过程中，SOLO不仅是一个代码生成工具，更像是一个耐心的导师和可靠的搭档。它帮我理解技术概念，帮我做出技术决策，帮我排查和修复问题，帮我优化和完善产品。没有SOLO，这个项目可能永远只是一个想法。
当然，这个产品还有很多可以改进的地方。在未来的规划中，我打算从以下几个方面继续完善：
第一，增强AI的法律专业能力。目前的AI模型虽然能够回答常见的法律问题，但在处理复杂的、疑难的法律问题时，还有提升空间。我计划通过fine-tuning（微调）的方式，用大量的法律专业数据来训练模型，提升其在法律领域的专业水平。同时，也计划接入更多的法律数据库和判例库，让AI能够基于更全面、更权威的数据来提供法律建议。
第二，完善案件管理功能。目前的案件管理功能还比较基础，只支持基本的增删改查操作。未来计划添加更多实用功能，比如案件时间线的可视化展示、案件关联人员的网络关系图、案件材料的智能分类和标注等。这些功能将帮助律师更高效地管理案件信息，更直观地了解案件全貌。
第三，实现多端同步和协作。目前的应用只支持单设备使用，未来计划实现多设备的数据同步，让律师可以在电脑、平板、手机等不同设备上无缝切换使用。同时，也计划添加团队协作功能，支持多人同时处理一个案件，共享案件信息和对话记录。
第四，加强数据安全和隐私保护。法律行业对数据安全和隐私保护的要求非常高。未来计划添加数据加密、访问控制、操作日志等安全功能，确保当事人的信息和案件数据得到最高级别的保护。所有敏感数据在传输和存储过程中都会进行加密处理，只有授权的用户才能访问相应的数据。
最后，我想给想用SOLO搭建Agent的朋友们一些建议：
首先，一定要先想清楚你要做什么。虽然SOLO很强大，但它不能替你思考。在开始开发之前，花时间做好需求分析和产品规划，把你要做什么、为什么做、怎么做想清楚。需求越清晰，SOLO的理解就越准确，生成的代码质量就越高。
其次，不要怕犯错。开发过程中一定会遇到各种问题和Bug，这是正常的。SOLO有很强的调试和修复能力，大部分问题它都能帮你解决。即使遇到它解决不了的问题，你也可以通过搜索和学习来找到答案。每一次犯错和修复，都是一次学习和成长的机会。
第三，保持耐心和迭代思维。不要期望一次性就做出完美的产品。先做出一个能用的最小版本（MVP），然后在此基础上逐步迭代和完善。每一次迭代都聚焦于一个具体的目标，比如"这次迭代我要优化对话体验"，“下次迭代我要添加案件管理功能”。小步快跑，持续改进，最终你会得到一个超出预期的产品。
第四，善用SOLO的全部能力。SOLO不仅能写代码，还能帮你做需求分析、架构设计、代码审查、性能优化等工作。充分利用它的各项能力，让它成为你的全方位开发搭档，而不仅仅是一个"代码生成器"。
希望这篇文章能够给对AI Agent开发感兴趣的朋友们一些启发和帮助。AI技术正在深刻地改变各行各业，法律行业也不例外。作为法律从业者，我们应该积极拥抱这些新技术，用它们来提升我们的工作效率和服务质量。而SOLO这样的AI编程工具，为我们提供了一条低门槛的路径，让我们能够亲手参与到这场技术变革中来。
未来已来，让我们一起拥抱它吧。
版权声明
本文版权归作者所有，未经授权，禁止任何形式的商业转载和使用。
本项目（刑事辩护律师智能Agent工作台）的全部知识产权归作者所有，包括但不限于系统架构设计、功能模块规划、UI/UX设计方案、前端代码、后端代码、数据库设计等所有技术成果和智力成果。
本文中涉及的所有API密钥、模型配置、后端地址、服务器信息等敏感信息均已做脱敏处理，文中出现的"***"或"已脱敏"字样即为脱敏标记。任何人不得试图从本文中提取或还原相关敏感信息。
本文中展示的代码片段仅用于技术交流和学习目的，已经过脱敏处理，不代表完整的生产代码。严禁将本文中的任何代码片段用于商业项目或未经授权的产品开发。
本文中展示的产品截图、UI设计图、架构图等均为作者本人项目的真实展示或设计成果，未经授权不得用于任何其他产品或项目。
如需转载本文用于非商业目的，请注明出处并保留版权声明。如需合作或授权使用，请联系作者。
本文发布日期：2026年4月