你的产品合法吗？一次车祸教会我的产品设计课
起因
我在加州出过一次车祸。对方全责，但当时完全不懂理赔流程，最后拿到的赔偿远低于应得的。事后把经历分享到社交媒体，两年过去了，仍然不断有人来问我怎么处理。
这个持续了两年的需求信号让我觉得值得做成产品。核心判断是：简单车祸案件（对方全责、责任清晰），大部分工作不需要律师，需要的是 process knowledge。把这些知识系统化，用 AI 辅助用户走完全流程，就是一个"TurboTax for car accident claims"。
用 gstack 做产品 review
这时候正好 YC CEO Garry Tan 开源了 gstack，一套 Claude Code 的工具集，里面有二十多个 skill，覆盖从产品设计到 QA 到发布的完整流程。我决定用它的 /office-hours skill 把产品跑一遍。
/office-hours 模拟 YC office hours 的流程：六个 forcing questions，逼你回答"谁在用""他们现在怎么解决""你的最窄切入点是什么"这类问题。它不会点头说"great idea"，而是会挑战你的前提假设，把你没想到的盲区逼出来。
跑下来的收获有两层。
第一层是产品设计本身。/office-hours 指出我们原来的 AI chatbot 形态对目标用户是错误的：车祸受害者不是 tech-savvy 的人，如果他们需要"想清楚该问什么问题"才能用，产品就已经失败了。它建议改成 guided workflow，AI 嵌入每个阶段作为 contextual help，而不是一个通用聊天框。这个 insight 直接改变了产品形态。
第二层更关键：它点出了一个我从未认真思考过的法律风险。
结论：你这个产品需要 attorney 签字才能上线。
坑在哪里
这个法律风险叫 UPL，Unauthorized Practice of Law（非法执业）。
在美国，没有律师执照的人或组织，不能对具体的人的具体情况提供法律建议。这条线看起来模糊，但边界其实很清晰：
- 教用户"加州的 comparative fault 规则是什么"：合法。这是 legal education。
- 告诉用户"根据你的情况，你应该索赔 $50,000"：违法。这是 legal advice。
Stanford CodeX 对最近一个案子的分析提出了一个清晰的判定框架，叫 Uncrossable Threshold：你的产品，要么是设计来提供 general information 的，要么是设计来对具体用户的具体情况给出 tailored conclusion 的。一旦 by design 跨过这条线，disclaimer 救不了你。
我设计的产品，在 AI 助手这一层，几乎每一条都踩在了这个边界上。
这个坑有多普遍？看看已经踩进去的人：
DoNotPay，自称"世界上第一个机器人律师"，2024 年被加州集体诉讼，2025 年 FTC 罚款 $193,000，永久禁止"机器人律师"宣传。问题的根源甚至不是产品功能本身，而是那句 marketing："世界上第一个机器人律师"。这个名字让产品的每一个功能都变成了 UPL 的证据。
2026 年 3 月，Nippon Life Insurance Co. 起诉 OpenAI：一个当事人用 ChatGPT 分析自己律师的信件，ChatGPT 告诉她"你被 gaslighted 了"，她解雇律师、以 ChatGPT 为"co-counsel"在一个已结案的案件里提交了 21 份 motion。原告要求 $10M 惩罚性赔偿。
不只是法律行业
和朋友讨论之后，我发现这个模式在所有需要执照的行业都存在：
法律：不能替代律师提供 advice，但可以做 education。会计：给 small business 提供 accounting tool 可以，提供 accounting service 不行。医疗：健康信息 app 可以做，根据症状给诊断建议就进入了 practicing medicine without a license 的领域。
规律是：regulated profession 的 license 要求是 AI 产品的天然门槛。 AI 在知识层面完全有能力做这些事，但执照是一个 statutory 层面的垄断，跟 AI 能力无关。
那 TurboTax 是怎么做成的？因为美国国会专门为 tax preparation 创建了一条不需要 CPA 执照的 unregulated lane。IRS 允许任何人作为 tax preparer 帮人准备报税文件，软件生成报表，用户自己提交。但在法律领域，没有类似的 statutory exception。
从第一性原则规避风险
在产品设计的最顶层加了一个约束条件。
如果你是创业者或独立开发者，在碰任何涉及 regulated profession 的产品之前，先问自己一个问题：
你的产品是在替代一个需要执照的人的工作吗？
如果答案是 yes，你有三条路：
路径一：从 advice 转向 tool / education。 你不能告诉用户"你应该怎么做"，但你可以教用户"法律是怎么规定的"，给他工具让他自己判断。LegalZoom 的整个商业模式建立在这个定位上：标准化法律文件模板、guided questionnaire，但每一页写着"We are not a law firm"。这句话不是脚注，是整个产品合法性的结构支撑。2015 年 LegalZoom 打赢了 North Carolina Bar 的 UPL 指控，确立了 self-help legal tool 的合法先例。我们的产品也走了这条路，核心原则八个字：教，不判；导，不代。
路径二：找执照持有者合作。 产品本身不做专业判断，但有持照专业人士为内容背书。我们的做法是 attorney engagement pipeline：上线前律师审核全部内容和 AI 的 sample responses，签字后才能上线，上线后每月合规抽查。
路径三：拿到那个执照。 如果你真的想做 legal advice as a service，创建一个有律师的实体。最难但最彻底。
核心 takeaway：合规不是上线前加一行 disclaimer 的事，它是 Day 0 的产品设计决策。disclaimer 不改变产品的本质，你的产品是怎么设计的，它就是什么。
写在最后
产品设计中很多坑是 technical 的：架构选错了，性能不达标，UX 不好用。这些坑踩了可以改。
Regulatory 的坑不一样。它直接否定你产品存在的合理性。如果在设计阶段没想清楚，等产品做完了才发现核心功能有法律问题，面临的不是"怎么修"，而是"要不要继续做"。
我的教训是：如果当时没有用 gstack 做一遍系统性的 review，我可能已经带着这些法律风险上线了。工具的价值不只是帮你写代码，而是在你 all-in 之前帮你找到那些你不知道自己不知道的东西。
合规边界不是创新的障碍，它是设计约束。就像物理定律对建筑设计一样，regulated profession 的 license 要求就是你的"物理定律"。约束内依然有大量空间做出有价值的产品。关键是，你得在画第一张草图之前就知道这条线在哪里。