我把做 SaaS 产品当作爱好。Jurfi 上线时，这些项目给我带来的收入仍然是 0。写出来多少有点扎心，但这也是故事的一部分：我继续做，是因为我确实喜欢构建产品。Jurfi.com 是最新的一个。
Jurfi 是一个在浏览器中创建结构化法律文档草稿的工作室。我做它，是因为有一个很具体的问题一直让我不满意。从空白页面开始很慢，但模糊的 AI 回答又会制造相反的问题：文字很多，却没有清晰的文档结构，也没有明显的检查路径。我想要的是中间状态：更明确的输入、确定的文档形态，以及一份可以检查而不是直接相信的工作草稿。
从空白页面到结构化草稿
很多实用文档都从同样几个麻烦的问题开始：这里应该有哪些信息？顺序是什么？我漏掉了什么？Jurfi 想降低这些摩擦，覆盖网站和 SaaS 政策、服务协议、租赁文件、信函、索赔材料、收据，以及其他人们确实需要的实用文档。
基本思路很简单：不要从空白页面开始，而是从表单或模板开始。填写相关信息，生成结构化工作草稿，然后再检查和修改结果。
- 通过简单的表单和模板创建法律文档草稿。
- 直接在浏览器中生成结构化草稿。
- 把草稿保存在本地，而不是把每次迭代都当成一次性文本。
- 减少文档混乱和重复的手工拼装工作。
我刻意把结果叫作草稿。一份文档可以看起来非常完整，却仍然不适合某个特定法域、合同、业务或争议。排版漂亮并不能证明法律上的正确性。
工具的边界比功能列表更重要
最重要的产品决定不是再加一个模板，而是明确 Jurfi 不应该假装自己是什么。它不是律师，我也不会把它描述成一个可以解决所有复杂法律问题的系统。
我想提供的价值更窄，也更实际：速度、结构和清晰度。更快地从空白页面到一份连贯的工作草稿，把输入信息显式化，减少重复拼装，然后批判性地阅读结果。如果一份文档涉及重要的法律或财务风险，专业人士的审阅仍然是合理的下一步。
这个边界很重要，因为生成文本可以听起来非常自信，同时仍然不完整或错误。对法律文档工具来说，隐藏这种不确定性会是糟糕的产品决定。与其让产品看起来像魔法，我更愿意把限制说清楚。
这里的“浏览器型”到底是什么意思
工作流以浏览器为中心，草稿可以保存在本地。这个设计对我很重要，因为如果每次修改都散落在标签页、聊天窗口和复制出来的文本片段里，文档工作很快就会变得混乱。
但我也不想把这个功能扩张成超出事实支持范围的隐私承诺。可以确认的具体能力是：“草稿可以保存在本地。”这并不等于声称所有工作流中的每个操作都必然只发生在设备上。实际意义更简单：草稿可以继续作为一份文档被编辑，而不是又一个一次性回答。
产品上线，不等于会被发现
上线之后，最不确定的部分是 discovery。我确实在措辞、review 流程和文档质量上投入了精力。接下来就是我无法直接控制的部分：人们是否会找到这个产品。
情绪化的说法是：“现在该 Google 做它那部分了。”技术上更准确的说法没那么让人安心。Google 自己的文档明确说明，即使页面符合要求，也不保证会被 crawl、index，或在 Search 中展示。Crawling、indexing、ranking 和 traffic 是不同阶段；认真发布一个产品并不会自动带来其中任何一个。
对 side project 来说，这个区分很有用。我能控制自己做什么、发布什么，以及如何准确解释它。我无法控制搜索多快发现它，也无法控制这种发现是否会转化成用户。
我从这个项目里带走的东西
即使增长很慢，我仍然很高兴做了 Jurfi。我的结论不是法律文档起草很简单，也不是 AI 消除了困难部分。恰恰相反：文档的后果越重要，明确的工作流和可见的限制就越重要。
- 当输出有可预测的结构时，使用结构化输入。
- 把生成文本当作工作草稿，而不是正确性的证明。
- 明确区分软件辅助和专业判断。
- 把 review 留在工作流里，不要把 generation 当作终点。
- 把产品质量和搜索表现分开看；前者不保证后者。
这就是我希望 jurfi.com 达到的标准：更少的文档混乱、更少的重复工作，以及一条更清晰的路径，从“我需要这份文档”到“我有一份真正可以检查的草稿”。