<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>产品 on LeoChu Space</title>
    <link>https://leochu.work/blog/tags/%E4%BA%A7%E5%93%81/</link>
    <description>Recent content in 产品 on LeoChu Space</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Mon, 13 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://leochu.work/blog/tags/%E4%BA%A7%E5%93%81/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ChatSQL之我见</title>
      <link>https://leochu.work/blog/tech/ai/chatsql%E4%B9%8B%E6%88%91%E8%A7%81/</link>
      <pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://leochu.work/blog/tech/ai/chatsql%E4%B9%8B%E6%88%91%E8%A7%81/</guid>
      <description>&lt;p&gt;这两年，AI技术越来越成熟，在很多场景上给不同的岗位提供了大量的生产力。
但是作为数据行业从业人员，其中有个场景我想泼一下冷水。
比如被讲得很热的ChatSQL。&lt;/p&gt;
&lt;p&gt;接个大模型，挂上数据库，做个对话框，让业务一句话取数，仿佛传统 BI 的门槛一下子就要被抹平。&lt;/p&gt;
&lt;p&gt;这种想象不是完全没有根据。只要场景足够干净，问题足够标准，今天的模型确实已经能生成一段相当像样的 SQL，甚至把结果也答得像模像样。&lt;/p&gt;
&lt;p&gt;但我对 ChatSQL 的判断一直比较克制。不是因为它没用，而是因为它在企业里真正要解决的，从来都不是&amp;quot;写出一条 SQL&amp;quot;这么简单。&lt;/p&gt;
&lt;h2 id=&#34;一chatsql-最难的不是生成而是语义&#34;&gt;一，ChatSQL 最难的不是生成，而是语义&lt;/h2&gt;
&lt;p&gt;很多人第一反应是：模型还不够强，等下一代就好了。&lt;/p&gt;
&lt;p&gt;这个判断的问题在于，它把 ChatSQL 的核心难点理解成了生成能力。&lt;/p&gt;
&lt;p&gt;可在企业环境里，模型最先撞墙的地方往往不是不会写 SQL，而是不知道你们公司到底在说什么。&lt;/p&gt;
&lt;p&gt;&amp;ldquo;活跃客户&amp;quot;怎么算？&lt;br&gt;
&amp;ldquo;新增付费用户&amp;quot;包不包含试用转正？&lt;br&gt;
&amp;ldquo;业绩下滑&amp;quot;看收入、利润，还是回款？&lt;/p&gt;
&lt;p&gt;这些问题本质上都不是自然语言理解问题，而是业务语义问题。模型可以把一句话翻成查询，但它翻不了一家企业内部本来就没有统一好的口径。&lt;/p&gt;
&lt;p&gt;所以 ChatSQL 如果一上来就做成&amp;quot;人话转 SQL&amp;rdquo;，最后大概率不是输在模型，而是输在语义基础太薄。&lt;/p&gt;
&lt;h2 id=&#34;二语义层很重要但它不是银弹&#34;&gt;二，语义层很重要，但它不是银弹&lt;/h2&gt;
&lt;p&gt;讲到这里，很多团队会自然转向另一个答案：那就建语义层。&lt;/p&gt;
&lt;p&gt;这个方向没错，但也很容易被误解。&lt;/p&gt;
&lt;p&gt;语义层的价值在于，把常见指标、维度、实体关系和口径规则结构化，让模型不必每次从数据库字段里重新猜业务世界。没有这层东西，系统几乎很难稳定。&lt;/p&gt;
&lt;p&gt;但语义层本身不是一个轻巧组件，它更像是一种治理成果的交付形式。&lt;/p&gt;
&lt;p&gt;换句话说，语义层不是补丁，而是地基的外化。&lt;/p&gt;
&lt;p&gt;如果企业本来就没有统一指标、没有稳定口径、没有明确的责任边界，那语义层也只是把混乱包了一层更漂亮的壳。它让问题显得更工程化，但并不会自动把问题解决。&lt;/p&gt;
&lt;p&gt;所以我更愿意把它理解成入场券，而不是终局方案。没有它，很难上线；只有它，也过不了关。&lt;/p&gt;
&lt;h2 id=&#34;三demo-证明不了产品成立&#34;&gt;三，Demo 证明不了产品成立&lt;/h2&gt;
&lt;p&gt;ChatSQL 最容易骗人的地方，就是 Demo 总是很好看。&lt;/p&gt;
&lt;p&gt;因为 Demo 里的问题通常都被精心挑过：定义清楚，范围有限，口径提前对齐，数据表也知道该怎么连。这样的条件下，模型表现出色并不奇怪。&lt;/p&gt;
&lt;p&gt;但产品成立的标准完全不是这个。&lt;/p&gt;
&lt;p&gt;真正的用户问题通常带着模糊、跳跃和上下文缺失。很多人问的不是一个可以直接翻译的问题，而是一个需要先被澄清的问题。&lt;/p&gt;
&lt;p&gt;比如：&amp;ldquo;最近业绩下滑的团队有哪些？&amp;rdquo;&lt;/p&gt;
&lt;p&gt;一个靠谱的分析师听到这句话，第一反应不会是立刻写 SQL，而是先追问。最近是多久，业绩看什么，下滑按什么基线，异常值要不要去掉，外包团队算不算。&lt;/p&gt;
&lt;p&gt;也就是说，真实分析过程本来就不是一次翻译，而是一段澄清和收敛的过程。&lt;/p&gt;
&lt;p&gt;而大多数 ChatSQL 产品，目前只接住了&amp;quot;生成查询&amp;quot;这一步，却没有接住分析师原本承担的职责：澄清、解释、回退、修正、多轮一致性。&lt;/p&gt;
&lt;p&gt;所以 Demo 证明的是模型有翻译能力，不等于产品已经具备交付能力。&lt;/p&gt;
&lt;h2 id=&#34;四chatsql-最脆弱的地方是信任不是准确率均值&#34;&gt;四，ChatSQL 最脆弱的地方是信任，不是准确率均值&lt;/h2&gt;
&lt;p&gt;很多讨论喜欢问：&amp;ldquo;准确率做到 80% 多，能不能上线？&amp;rdquo;&lt;/p&gt;
&lt;p&gt;这个问题本身问得就有点偏。&lt;/p&gt;
&lt;p&gt;如果 ChatSQL 只是给分析师自己做探索，用来找方向、提假设、少写点重复 SQL，那么它不需要像财务系统一样严苛。因为分析师本身有判断力，答偏了也知道怎么纠回来。&lt;/p&gt;
&lt;p&gt;但如果它要直接进入经营分析、财务对账、审计追责这种高责任场景，标准就完全不同了。&lt;/p&gt;
&lt;p&gt;这些场景里，决定系统能不能活下来的，不是平均准确率，而是关键问题能不能稳定答对，答错了能不能被及时发现，发现之后能不能追溯。&lt;/p&gt;
&lt;p&gt;因为用户对这类系统的信任建立得很慢，崩塌得却很快。十次答对未必能让人真正依赖它，但一次关键错误，足以让整个部门彻底弃用。&lt;/p&gt;</description>
    </item>
    <item>
      <title>精益创业</title>
      <link>https://leochu.work/blog/reading/%E7%B2%BE%E7%9B%8A%E5%88%9B%E4%B8%9A/</link>
      <pubDate>Sun, 09 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://leochu.work/blog/reading/%E7%B2%BE%E7%9B%8A%E5%88%9B%E4%B8%9A/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;Eric Ries《精益创业》。核心观点：创业不是把想法尽快做大，而是用最小成本持续验证“哪些假设成立”。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id=&#34;核心观点&#34;&gt;核心观点&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;创业的核心单位不是产品，而是学习。&lt;/strong&gt; 如果一个团队发布了很多功能，却没有获得更清楚的用户认知，本质上并没有前进。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;MVP 的重点是验证，不是简陋。&lt;/strong&gt; 它的价值在于用最小代价测试关键假设，而不是随便做个半成品糊出去。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;增长必须建立在可重复的因果关系上。&lt;/strong&gt; 偶然增长不等于找到模式，真正有价值的是知道“为什么用户会留下来”。&lt;/p&gt;
&lt;h2 id=&#34;印象较深的部分&#34;&gt;印象较深的部分&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;很多团队失败不是因为不努力，而是一直在高效地做错事。&lt;/strong&gt; 这句话几乎适用于所有产品开发。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;转向不是失败，而是认知更新。&lt;/strong&gt; 当关键假设被验证为错误时，继续硬推才是真正的浪费。&lt;/p&gt;
&lt;h2 id=&#34;读后感&#34;&gt;读后感&lt;/h2&gt;
&lt;p&gt;这本书最好的地方，是它把创业从激情叙事拉回到验证逻辑。创业不是证明自己有多投入，而是在不断回答：这个问题到底存不存在，这个解法到底成不成立。&lt;/p&gt;
&lt;p&gt;不只是创业者，做产品的人读这本书也很合适。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
