这篇文章想记录的，不是某个功能终于做完了，而是两次很痛、但事后看都很值得的收缩。

一次是收缩产品范围。
一次是收缩架构幻想。

我后来才意识到，这两个决定其实都在做同一件事：

把注意力从“看起来完整”拉回“真正成立的核心路径”。

一、第一个决定：先砍范围，再谈完整

三个月前，我给 OpsMind 列过一张很完整的能力清单：

• 聊天工作台
• 知识库
• 数据库直连
• 报告导出
• Skill 扩展
• 落地页

当时我觉得这些能力缺一不可。

数据分析工具如果没有数据库直连，好像就不够专业；
没有报告导出，好像就留不住成果；
没有 Skill 扩展，好像未来也很难讲。

于是我真的开始把这些都往里做。

代码库里陆续出现了数据库连接、报告生成、技能注册这些模块，架构文档也越来越像一个“完整平台”。

但问题也很快出现了。

数据库连接不是一个按钮，而是一整套连接池、权限、密钥存储和方言差异。
报告导出不是一个导出接口，而是一整套渲染、分页、字体和格式系统。
Skill 扩展也不是多加几个 prompt，而是协议、生命周期和调用边界。

每一个“顺手补上”的配套能力，背后其实都是一个独立子系统。

结果是，三个月过去了，最应该打磨的核心体验反而还没稳：

上传文件 -> 提问 -> 看到一张可靠的图表

我后来才承认，自己当时并不是在做一个产品，而是在做一个“平台已经成熟”的幻觉。

于是我做了第一个决定：

把 db_connections、reports、skills、data-sources 从 v1.0 范围里拿掉，先归档，不继续投入。

那次提交一口气删掉了 3508 行代码。

删完之后我最明显的感受不是“损失”，而是轻。

代码库变轻了。
任务边界变轻了。
我的注意力也终于回到了真正该先做对的地方。

二、这次收缩让我重新理解了一件事

功能不是天然的资产，很多时候它首先是债务。

只要一段功能代码进入系统，它就会自动带来后续成本：

• 要测试
• 要维护
• 要解释
• 要兼容别的链路
• 要让用户真正理解为什么存在

如果用户还没走到需要它的阶段，这些成本就不会转化成价值，只会持续占用注意力。

这也是我后来越来越认同的一种区分：

“先做完整再上线”，更像工程师本能。
“先把最小成立路径做对，再看用户真正缺什么”，更像产品判断。

这两种思路都没错，但它们适合的阶段完全不同。

在还没有足够真实反馈之前，开发者最容易高估的，往往不是执行能力，而是自己对需求的判断力。

我当时一直在假设用户需要 MySQL 直连。
但如果连第一个真实高频场景都还没跑出来，我其实根本不知道，用户更在意的到底是数据库接入，还是先把 Excel 上传分析这条链路做顺。

三、第二个决定：推翻那套“预猜式”核心架构

如果说第一个决定是在砍功能范围，那第二个决定就是在砍我已经投入最多时间的实现路径。

最初为了让 AI 自动生成图表，我搭过一套自己以为很精细的流程：

LLM 决定图表类型
  -> LLM 推断列映射
  -> 预设渲染器执行

围绕这条链路，我写了大量配套代码：

• 图表类型判断
• 列名模糊匹配
• 时间轴修正
• 高基数列告警
• 重试机制
• 大量 prompt 调优

它在 demo 里不是不能用。

但真正让我开始警觉的是另一件事：

这套系统总是在修 bug，却从来没有“修好了”的感觉。

后来我才想明白，问题不在 prompt，也不在某一个判断分支，而在架构前提本身。

在这套方案里，LLM 负责先猜对：

• 哪张图更合适
• 哪一列该做 X 轴
• 哪一列该做 Y 轴

但执行环境里的很多关键信息，它其实在“猜”的时候根本看不到：

• 某一列唯一值太多，不适合饼图
• 某一列空值率很高，直接算比例会失真
• 某一列的数据类型脏得比列名看起来复杂得多

也就是说，我一直在让模型对一个它还没真正接触到的执行现场做预判。

这不是 prompt 的问题。
这是设计问题。

四、真正更合理的路径，是让模型先执行再修正

后来我去看主流 AI 分析产品和代码执行产品的做法，才慢慢意识到：

更稳的路径通常不是“先猜对再执行”，而是：

LLM 写代码
  -> 在真实环境里执行
  -> LLM 读取结果、报错和图表
  -> 再做下一轮修正

这两种思路最大的差别，不是实现细节，而是学习来源。

“预猜式”架构里，模型只能靠提示和历史经验去猜。
“代码执行式”架构里，模型可以直接从真实结果里学习。

一个 KeyError 会直接暴露真实列名。
一张空图会直接暴露数据分布。
一次报错会直接告诉模型，问题到底出在语法、映射还是数据本身。

我后来接受了第二个决定：

推翻那套围绕预设渲染器堆出来的核心路径，把核心体验重新收敛为：

上传文件 -> 对话分析 -> 代码执行 -> 返回图表与结论

现在 OpsMind 的代码执行沙箱用的是 E2B，LLM 直接写 Python，在真实执行结果上迭代。

少了一层“我替模型预先设计完整世界”的执念，系统反而更清楚了。

五、这件事真正提醒我的，不只是架构，而是提问方式

回头看，那三个月里我并不是没有努力。

我写了很多代码。
我做了很多调优。
我也一直在和 AI 助手协作。

问题在于，我问的问题一直不够对。

我当时更常问的是：

“怎么把我现在这套方案继续优化下去？”

但真正应该先问的问题，其实是：

“这个领域里，更成熟的做法本来是什么？”

这也是我后来对 AI 协作更警惕的一点。

AI 很擅长沿着当前方向帮你补得更完整：

• 扩展函数
• 增加兼容逻辑
• 增加重试
• 把局部实现做得更漂亮

但如果方向本身是错的，它也会非常高效地陪你把错误方向走得更深。

这不是 AI 的问题。

更准确地说，是因为我当时把 AI 放在了“帮我优化现有方案”的位置，却没有先把“现有方案是否值得继续”这个判断做掉。

六、这两个决定，最后都指向同一件事

一个决定是砍功能。
一个决定是改架构。

表面上看，它们发生在不同层面。

但如果把它们放在一起看，本质上其实是同一种纠偏：

1. 不要过早追求“看起来完整”

范围太满，会让产品失焦。
架构太满，会让系统失真。

2. 先确认核心路径成立，再扩外围系统

如果核心体验还不稳定，外围能力越多，系统越重。
如果执行路径前提就错了，局部优化越多，返工成本越高。

3. 有时候最贵的不是推翻，而是舍不得推翻

真正让我后面轻松很多的，不是前面三个月写过多少，而是终于愿意承认：

现在停下来重做，代价比继续在错误方向上推进更低。

七、如果让我重来一次

如果今天重新开始做 OpsMind，我会更早做三件事：

1. 先查清这个问题在行业里最常见、最成熟的解法是什么。
2. 在没有真实用户反馈之前，对“我觉得用户会需要”的功能保持克制。
3. 把判断标准从“功能多不多”换成“核心路径稳不稳”。

现在回头看，OpsMind 的 v1.0 范围其实清楚很多了：

• 聊天工作台
• 知识库
• 上传文件后的对话式分析
• 基于真实执行结果的图表生成

没有数据库直连。
没有报告导出。
也暂时没有技能市场。

但我反而觉得，它第一次更像一个产品了。

技术产品的成长，不只是不断往上加能力。

很多时候，它更依赖三种判断：

• 选择先做什么
• 选择暂时不做什么
• 选择在什么时候承认原来的方向不够对

这三件事，我在 OpsMind 上各学了一次。

学费是三个月。

现在看，付得不算亏。