ARTICLE · 1070565
AI与律师的生活02|我不会写软件,但我用AI给自己的团队做了一套案件管理系统
02
我不会写软件，但我用AI给自己的团队做了一套案件管理系统
AI对我的改变，不只是让我写东西更快。更大的变化是，我开始尝试把自己的办案方法、工作习惯和那些每天觉得“不爽”的地方，真正做成一个可以运行的系统。
去年，我写过一篇《律师的最佳AI使用工具——Ima》。
那时候我研究AI，最关心的问题其实很直接：哪个AI更好用？哪个知识库更适合律师？谁处理法律文本更稳定？
后来我开始越来越多地使用ChatGPT、Claude，也越来越习惯把AI放进真实案件里。
现在再回头看，我发现自己已经不太纠结“哪个AI最好用”了。因为真正限制我的，很多时候不是AI不够聪明，而是自己的工作本身还没有被组织好。
以前我在找一个更好用的AI。后来我开始想，能不能给AI一个真正可以进入的工作系统。
01 · FROM TOOL TO WORKFLOW
AI很聪明，但我的工作还是散的
最开始，我和很多人一样，主要拿AI做检索、整理、分析和起草。
它们确实很好用。面对一份长材料，可以迅速提炼重点；遇到不熟悉的问题，可以先搭出分析框架；需要形成文字时，也能帮助整理表达。对于法律工作中大量重复、琐碎但又需要保持准确的内容，这种帮助非常直接。
但用得越多，我反而越明显地发现一个问题：
AI能回答问题，但它不知道这个案件今天到底进行到哪一步了。
02 · WHY
“案程”最开始，其实只是一些很烦的小问题
我已经记不太清楚，“案程”这个想法到底是哪一天开始出现的。
它不是某一天突然冒出来的计划，更像是在每天办案的时候，不断出现一句：
这个东西如果能自动就好了。
一个案件七天没有推进，能不能提醒我？保全快到期了，为什么一定要靠人脑记？调查令交出去以后，能不能自动进入“等待反馈”？今天已经记录过的工作，为什么月底还要重新整理一遍？
慢慢地，这些问题开始连在一起。
我真正想做的，不是一个复杂的律所OA，也不是再做一个网盘，而是把案件、事项、推进记录、期限、风险和协作关系放到同一个工作空间里：打开系统，就能知道哪些事情今天要处理，哪些案件正在等待反馈，哪些事项已经逾期，以及一段时间内究竟做过什么。
最初的原则
一件事情尽量只录入一次。系统应该告诉成员下一步做什么，而不是单纯帮我们存东西。
03 · BUILD
问题是，我是一个文科生
我的计算机基础，大概就是以前接触过一点Python。
UI设计不会，数据库不会，服务器部署不会，域名、网络、前后端这些东西，以前跟律师工作基本没有关系。
但AI出现以后，这件事情的门槛突然变了。
我不需要先学会怎么写一套完整的软件。我可以先把业务问题讲清楚，再让AI一点一点把律师语言翻译成字段、界面、数据库和程序逻辑。
有一段时间这种反差还挺明显：白天可能还在法院跑执行、打法官电话、整理调查令，晚上回来研究的却是UI、数据库、服务器和域名。
我会和AI讨论：这个按钮应该放在哪里？为什么成员保存以后刷新就没了？两个人同时修改一个案件怎么办？服务器更新以后怎么保证原来的数据还在？
以前这些问题在我看来都属于“程序员的工作”。现在我当然也不会因为把系统搭出来就觉得自己成了程序员，但AI确实把一个原来离我很远的事情，拉到了一个我至少可以动手试试的位置。
2026 年 9 月 2 日至，第一版框架和本地测试版逐渐成形。现在回头看，最能代表那个阶段的不是某个漂亮页面，而是第一份数据导入模板：案件、事项、进展、风险与期限、团队成员、客户和机构经验，被第一次放进同一套关联结构里。
04 · REAL USE
第一次“做出来”不难，真正困难的是让大家每天用
第一版真正能跑起来以后，我一开始其实挺兴奋。
第一版工作台很简单：几张统计卡片、近三日事项、需要关注的案件和系统提醒。它离成熟产品很远，排版和交互也有不少问题，但最核心的工作关系已经出现了——案件不再只是一个名称，事项也不再只是表格里的一行字，它们开始具有负责人、状态、期限、反馈和历史记录。
但团队一开始使用，问题马上就出来了。
9 月 8 日，系统进入团队试用，建立了 7 个成员账号。随后，问题也真正开始出现：首次登录如何处理，角色之间能看见什么，保存失败怎样提示，两个人同时修改会不会互相覆盖，删除的数据能不能找回，代码更新时怎样避免影响已有数据……
这时我才明白，做出一个页面和做出一个能长期使用的系统，完全是两回事。
在后续迭代中，我接触到的内容越来越不像一次简单的“AI 编程尝试”：本地数据库、备份与恢复、代码和数据分离、服务器部署、域名、HTTPS、多人协作、权限控制、冲突保护、导入校验、版本公告……这些原本离我很远的词，最后都变成了一个个必须解决的具体问题。
从 V0.1.0 的团队试用，到 V1.0.1 的日历修复和外观主题，版本公告留下了 18 个发布节点。系统陆续增加或调整了案件中心、事项池、风险与期限、推进时间线、系统日历、CRM、团队实务知识库、费用报销、工作日志与汇总、管理看板和 AI 助手。
但功能越多，越不能只追求“能用”。有些页面需要固定在一个视口内，让列表自己滚动；有些筛选应该收进统一入口；管理看板只能向特定角色开放；报销既可能关联案件，也可能属于团队支出；AI 可以帮助生成事项或推进记录，但最后一步必须由操作者确认。
这些细节看起来不如“AI 自动办案”吸引人，却决定了一套系统是否真的适合团队。
05 · ITERATE
然后，我写出了4000多字修改意见
01“UI有点丑，调整一下。”
02输入了一大段，误点弹窗外面全部没了，至少留个草稿。
03日历一天很多事项，怎么才能看清楚？
04悬浮窗口太灵敏，鼠标根本移不到真正想看的日期。
系统真正投入使用以后，我一边自己使用，一边收集团队成员的反馈，陆陆续续记下了4000多字修改意见。
这份反馈对我的价值，甚至超过了最初把系统搭出来。因为使用者不会因为一个功能“技术上已经实现”就接受它。他们更关心的是：信息是不是一眼能看懂，列表会不会过长，字体和操作是否统一，新增一条记录要不要反复跳转，某个提醒是否真的出现在需要它的时候。
因此，后来的很多迭代并不是继续增加功能，而是在重新整理页面层级、统一字体和颜色、调整左右比例、压缩多余文字、改造筛选方式、重做日历和周视图，并补上角色权限、费用状态、节假日和团队协作的细节。
这些东西看起来一点都不高级，但我后来反而觉得，一个系统真正好不好用，往往就是这些小地方决定的。
软件不是“设计”出来的，很多时候，是“用”出来的。
06 · AI INSIDE
后来，我又把AI真正接进了系统
后来把 DeepSeek 接入系统，希望它既能根据自然语言创建事项、记录推进，也能回答“我下周有几个庭要开”“上次在某个案件里和证券公司说了什么”一类问题。
最开始的效果并不好。它有时回答不出已有的开庭安排，也找不到某个事项下已经记录的和谈情况。
这件事反而给了我一个很重要的认识：AI 的回答质量，不只取决于模型，也取决于系统有没有把正确的数据、检索范围和上下文交给它。
如果开庭信息存在日历字段里，推进情况藏在事项记录下，而助手只搜索了案件名称，再聪明的模型也无法凭空知道答案。真正需要解决的是数据怎样被结构化、检索怎样覆盖不同记录、结果怎样注明来源，以及使用者只能查询自己有权限查看的内容。
所以，案程里的 AI 助手最终被限定为“先检索、再整理、涉及写入必须确认”。它不是替代经办人作出判断，而是帮助经办人更快找到散落的信息，并把一句自然语言转换为待确认的操作。
AI的回答质量，不只取决于模型，也取决于系统有没有把正确的数据、检索范围和上下文交给它。
所以现在我更倾向于让AI负责“先检索、再整理、涉及写入必须确认”。它可以帮助我更快找到信息，但最后的业务判断仍然应该留在人手里。
07 · VIBE CODING
我现在怎么看Vibe Coding的问题
这段经历让我看到 Vibe Coding 很明显的价值：它大幅降低了一个非技术背景的人验证想法的门槛。过去可能因为成本太高而永远停留在纸面上的需求，现在可以先做出原型，再放进真实环境中验证。对一个小团队而言，低成本、稳定、强客制化地解决自己的工作问题，本身就很有价值。
但它也有清晰的边界。
AI 可以生成页面、修改代码、解释错误，却不会自动理解团队真正的权责关系；它可以快速给出一个看似合理的方案，却不能替代真实用户的反馈；它能让系统运行起来，却不会替你承担数据安全、权限错误、备份失效和长期维护的责任。
能生成，不等于能上线。能上线，也不等于能长期使用
最开始用AI，我最兴奋的是：以前一个小时做的事情，现在二十分钟。
这种效率提升当然还在。
但现在我越来越觉得，这可能不是AI对我最大的改变。
更大的变化是，我开始重新设计自己的工作。
以前：遇到问题 → 解决掉
后来：重复出现 → 做模板
再后来：模板还不够 → 做流程
现在：流程稳定 → 能不能放进系统
以前，我用AI解决问题。现在，我开始尝试用AI把一些问题做成以后不用再解决的问题。
至于案程最后会变成什么样，我现在其实也不知道。
它可能会越来越完整，也可能长期只是我们几个人使用的一个小工具。
但这件事情本身已经足够有意思。
一个律师，可以把自己每天办案过程中那些特别细碎的“不爽”，一点一点变成需求，再把需求变成一个真的可以运行的系统。以前这件事情离我很远，现在已经真的发生了。
 | 钟永成律师 上海泰亚律师事务所 主要办理强制执行、终本后财产调查、恢复执行、执行衍生诉讼及股东等责任主体追责。 |
《AI与律师的生活》记录AI进入真实律师工作以后，我自己的使用、试错和阶段性理解。
LAWYER · AI · WORKFLOW