AI 让写代码越来越快，也让产品更容易欠下“概念债”

我相信很多人会跟我有一样的体会，AI 正在让写代码变得越来越快、越来越容易。现在有一个想法，可能当天就能做出一个看起来挺完整的东西。速度快当然是好事，但我现在越来越担心另一种情况：问题可能还没有想清楚，产品就已经做出来了。

AI 降低了写代码和搭建产品的成本，却没有同步降低理解客户、澄清概念和确认成功标准的成本。当这两个过程的速度被拉开，团队很可能在问题还没有想清楚的时候，就已经把某种理解固化进了产品。

我们做 Omni-Growth 的过程，正好让我看到了这种“固化”是怎样发生的，也让我们逐渐找到了一套避免它的办法。

PART 01 我们花了 1 个月，才开始写正式产品代码

前面几篇文章中我提过，在正式开发 Omni-Growth 的 Copilot 产品之前，我们花了很多时间做一些看起来不太像“产品开发”的事情。我们核心围绕一家共创客户驻场学习、打磨，从对 Meta 广告投放没有太多实践了解，到理解客户的黑话和业务，多次迭代后产出第一个可以交给客户使用的 demo，大概用了 1 个月。而在这之后，我们才开始写正式的产品代码。

当然，在写正式的产品代码之前，我们也会开发 Skill、搭建 demo，但这些代码的用途是探索问题，默认随时可以推翻重来；正式产品代码则会把交互、数据结构和工作流程固化下来。两者的区别，主要在于代码是在帮助我们发现问题，还是基于已经有的产品决定做具体实现。

我们愿意花这 1 个月，核心原因是对自己当时的业务认知没有信心，这跟故意放慢产品开发无关。我们对 Meta 投放的理解还很浅，如果直接开始设计产品，做出来的很可能只是三个程序员想象中的投手工作方式，跟客户实际的工作方式有天壤之别。

所以，在确定产品形态之前，我们需要先证明三件事：自己真的理解了客户在说什么，借助 AI 真的能把工作完成，客户也真的能独立使用我们做出的东西。

也因此，在用 FDE 的方式待在客户现场的时候，我们首先要把自己当做实习生，把客户业务语言和真实流程弄明白；再把实际工作做成 Skill，放进 Claude Code 的 Harness 环境里跑通，让客户确认结论；最后把 AI 完成的 demo 直接交给客户，通过静默观察验证他能不能独立使用。

这套做事方法很快让我们发现了不少问题，这里举一个非常具体的产品形态的取舍。

最开始，我们把 Agent 的广告诊断这个功能设计成了“诊断卡片”这个形态。

当时我们的想法很自然：Agent 每发现一个问题或者机会，就生成一张诊断卡片，告诉投手发生了什么、为什么、建议怎么处理。功能做出来以后，信息清楚，交互也完整，我们自己觉得这已经挺像一个 AI Native 产品了。

但回到客户现场，坐在投手旁边看他真实使用，我们发现虽然有了这个，但投手最后还是会回到 Meta 后台，把整个广告账户重新检查一遍。

问题并不在模型能力，我们的 Agent 确实找到了足够准确也足够丰富的问题，卡片也正确展示了结果。真正的问题是，我们没有先搞清楚，投手所说的“一次完整诊断”到底是什么意思。

对我们来说，诊断是把发现的问题逐张列出来；对投手来说，诊断意味着沿着广告账户、广告系列、广告组、广告的原有层级完整检查一遍，并且能够确认没有遗漏。卡片这种产品形态能证明 Agent 看见了什么，却不能证明它没有漏掉什么。投手无法核对完整性，自然不敢依赖它。

所以，我们做的并不是把卡片顺序调整一下，或者把卡片解释得更清楚，而是把原来的主产品形态推翻了。新的产品不再以“诊断卡片”为骨架，而是以 Meta 自己的广告资产结构为主，沿着广告账户、广告系列、广告组、广告逐层组织诊断。产品形态变了，背后对“诊断”这个概念的定义也重新做了一遍。

这个问题让我越来越强烈地意识到：AI 产品最大的技术债，可能不是代码写得不好，而是第一行代码出现之前，团队就没有把问题想清楚。

PART 02 这不是技术债，而是被 AI 放大的“概念债”

诊断卡片的返工，说明在真正理解业务之前，产品形态不应该过早确定。那么，应该怎样更准确地描述这类问题？它不是一个普通的 bug，也不完全是传统意义上的技术债，因为真正出错的并不是代码实现，而是代码开始之前，我们对“诊断”这个概念的理解。

我们平时讲技术债，通常指团队明明知道更好的实现方式，但为了赶进度，暂时选择了不够理想的架构或者代码，以后再花成本偿还。但还有一种债发生得更早：团队甚至没有形成对问题的共同理解，就开始写需求、做原型、建数据结构、选模型。我暂且把它叫作“概念债”。

所谓概念债，就是一个关键概念的定义、边界和成功标准还没有说清楚，团队却已经把它固化进了产品和工程系统。

我们上面那个案例里，欠下的就是“一次完整诊断”这笔概念债。代码没有 bug，Agent 找到的问题也对，但我们把“列出已发现的问题”当成了“完成一次诊断”。最后需要推翻的并不只是一个页面，而是从诊断的基本单位到产品主结构的整套设计。概念错了，后面的正确实现只会让错误变得更完整。

技术债通常要求重构代码，概念债严重的时候，可能需要推翻整个产品研发全流程的产出。概念债还有一个特点：它往往通过了所有测试，因为测试集本身也是按照那个错误概念建立的。

概念债当然不是 AI 时代才出现的。过去做软件，同样会遇到需求理解错误、指标口径不一致和产品形态选错的问题。并不是 AI 带来了这笔债，而是改变了它积累的速度和被发现的难度。

过去一个需求要排几周，大家还有时间争论设计目标，争论过程未必能保证问题被想清楚，却客观上形成了一条减速带，让错误的概念更慢地进入生产。而现在一句模糊的话，可能一个下午就变成一个能跑的 demo。功能跑起来了，页面做出来了，团队很自然地会觉得产品正在快速向正确的方向前进。但如果客户的问题、任务和成功标准还没有弄清楚，这些可见的工程进度，并不等于真正的产品进度。

这也是为什么 AI 写贪吃蛇、俄罗斯方块这类小 demo 往往特别拿手。这些游戏的基本概念、核心规则和成功标准都是通用的：蛇怎样移动、什么算撞墙，方块怎样旋转、什么算消行，几乎不存在需要结合某家公司业务重新解释的地方。AI 要做的主要是把一套已经说清楚的规则实现出来，而不需要先判断“我们说的贪吃蛇到底是什么意思”。但真实业务里的“线索”“成交”“完整诊断”并不是这种通用概念，它们的定义往往藏在具体公司的流程、数据口径和人的经验里。

在产品探索阶段，真正的产出，不是新增了多少代码、做出了多少页面，而是消除了多少关于客户、任务和成功标准的不确定性。 探索性的代码当然也是产出，它的价值主要体现在帮助团队更快地学习，判断哪些产品决策可以做、哪些还需要继续验证；至于沉淀产品功能，则是下一阶段的事情。

AI 还带来了另一个问题：如果没有被明确要求在不确定时停下来澄清，它往往会根据已有信息补全缺失的假设，并且给出一个看起来相当完整的实现。原本应该被暴露和讨论的模糊概念，反而可能被一个漂亮的 demo 暂时隐藏起来。

一个查数问题，可以更具体地说明这笔债怎样进入工程系统。我之前讲 ChatBI 时，用过这样一个例子：“上周线上渠道的线索成交转化率是多少？”

初看起来，这只是让 AI 查一个数字。可真要执行，里面几乎每个关键词都需要定义。什么叫线上渠道？什么叫线索，留资算、提单算，还是到店才算？什么叫成交，签约算、付款算，还是尾款结清才算？“上周”看自然周还是过去 7 天，成交要归因到线索产生时间还是付款时间？

只要其中一个概念没有说清楚，后面的链条就会依次发生偏移：

业务目标先被翻译成指标，指标再映射成事件和字段，事件和字段进入查询，查询的结果进入评测，评测结果又决定 Agent 是否有资格给出建议甚至执行动作。

如果最前面的“线索”定义错了，后面 SQL 写得再准确，得到的只是一个精确的错数；评测集覆盖得越完整，只是越稳定地证明这个错数符合错误口径；Agent 执行得越自动化，就越可能更快地把错误带进业务。

这也是概念债在 AI 产品里比传统软件更危险的地方。传统 BI 给了一个错数，人还可能在汇报时质疑；Agent 一旦被授予权限，错数则会继续触发预算调整、客户触达或者流程审批，概念偏差会从“看错”升级成“做错”。

所以，目标、指标、字段、评测和动作不是五件分开的事，它们是同一条定义链。上游一个概念模糊，到了下游可能就是一次真实的错误操作。

PART 03 更强的模型，为什么还不了这笔债

既然 AI 会放大概念债，一个很自然的问题就是：随着模型越来越强，它能不能反过来替团队把这些含义猜清楚？神策做 MetricAgent 的经历，让我的答案比较明确。

最早，我们把大模型接上查询工具，技术链路很快就跑通了，但模型不懂客户的指标体系，只能猜。后来，人工把业务知识整理进提示词，效果明显提升；再后来尝试用 RAG 自动检索知识，召回的噪声反而让效果下降；最终的生产方案，是多 Agent 加结构化指标库，把指标名称、别名、业务口径、技术实现和可用维度明确记录下来。遇到置信度不足的口径，系统停下来向用户澄清，而不是替用户猜。

这个过程表面上是架构迭代，实质上是在偿还概念债。我们不是又找到了一个更聪明的模型，而是逐步承认：模型不能替企业决定“线索”“成交”“活跃用户”这些概念到底是什么意思。

模型擅长在目标明确之后寻找路径，却不会天然替我们证明目标本身是对的。 如果成功标准定义错了，更强的模型只会更稳定、更高效地完成错事。

这一点在评测上尤其容易被忽视。很多团队很重视建立评测集，这当然是对的。但评测集只是尺子，它不会自动保证我们测量的是正确对象。谁定义题目，谁提供反例，谁确认答案真的能支持业务决策，这些工作都发生在用评测集跑分之前。

PART 04 FDE、Skill 和静默观察，是三层“概念审计”

既然更强更聪明的模型不能替企业决定“线索”“成交”和“完整诊断”到底是什么意思，这些概念应该怎样被澄清？概念当然可以在会议室里讨论，但只靠开会往往不够。回头看，我们在 Copilot 产品正式确定产品形态之前做的三件事，恰好构成了三层验证。

第一层，是到现场验证语言描述。

我们去客户现场做 FDE，最开始经常听不懂投手的业务黑话。后来把真实工作流程一处一处画出来，直接坐到一线投手旁边，看他怎么创建广告、怎么批量测品、怎么盯盘，才逐渐理解主管描述的理想流程和一线真正执行的流程并不完全一样。

我们还发现过一些“看起来明显不对”的投放方式。一开始以为找到了问题，深入追问之后才知道，其中一部分确实需要优化，另一部分却是投手根据库存、预算节奏和业务目标做出的有意选择。我们以为那是 bug，其实是自己尚未理解的业务 know-how。如果没有在现场把含义问清楚，技术团队很可能会把客户的经验当成问题修掉。

第二层，是用 Skill 验证工作产出。

听懂客户怎么说，不等于自己已经会做。于是在产品 demo 出现之前，我们先开发 Skill，把投手真实要做的任务放到 Claude Code 的 Harness 环境里，由我们自己借助 AI 完成。这个阶段的重点不是界面好不好看，而是工作能不能真正完成，结论能不能得到客户确认。

这一步非常关键。因为产品需求里经常混着两类东西：一类是客户真正要完成的任务，另一类是团队假想的产品形态。先不急着做页面，而是用 Skill 把任务真实跑通，可以把“客户需要什么结果”和“我们打算做成什么产品”暂时分开。结果还没有得到客户确认前，产品形态讨论得再完整，也可能只是自说自话。

第三层，是用静默观察验证产品设计。

等我们用 AI 完成 demo 之后，会把 demo 直接发给客户，然后不解释，闭嘴观察他能不能独立完成指定任务。

在实践中，我们让客户走了三个场景：走完接入向导，处置两条盯盘建议，再找 AI 澄清一条判断。三个场景整体还算顺利，但我们关注的不只是有没有完成任务，还包括在哪里停下来，哪个概念需要反复确认，哪一步会回到原来的工具。这些行为往往比客户的一句“整体感觉不错”更有价值。

我们没有像以前那样，先讲一遍 PPT，再由自己把产品演示一遍，最后问客户“你觉得怎么样”。这种反馈很容易失真，演示者会不自觉地替产品解释，帮用户绕过不清楚的地方，最后验证的可能只是这个人会不会讲，而不是客户能不能用。

前面提到的诊断卡片的问题，就是用这种办法暴露出来的。静默观察让我们看见了一个没有被写进需求的成功标准：客户不只需要理解每张卡片，还需要确认系统没有遗漏其他问题。问题因此从“怎样把卡片做好”，变成了“产品根本不应该以卡片作为核心结构”。

所以，FDE 工作方式是在现场审计概念，Skill 是用真实产出审计概念，静默观察则是用客户的独立行为审计概念。三层都通过之后，我们才有把握确认找到了真问题，而后面的开发则只是对真问题的具体解决。

PART 05 把概念固化进正式产品之前，先回答四个问题

前面三层验证解决的是怎样发现和校准概念，但现场得到的认知，还需要被写成明确的定义、验收标准和责任边界。否则，认知只停留在参与者的脑子里，进入正式开发之后仍然可能再次丢失。

当然，概念债不可能完全消灭。很多业务本来就是在探索中逐渐清楚的，要求开工前把一切都定义完整，也不现实。但至少有四个问题，值得在关键 AI 功能进入正式开发之前写下来。

第一，我们说的到底是什么？ 把关键名词写成业务定义，并且给出正例和反例。“高价值线索”不能只是一句形容，需要说明哪些算、哪些明确不算。

第二，什么才算成功？ 不只写准确率或者任务完成率，还要写清楚用户会因此改变什么动作，业务结果在多长时间内怎样被验证。对广告诊断来说，成功不是 Agent 找出了几条问题，而是投手能够完成检查、确认没有重要遗漏，并愿意据此行动。

第三，什么结果绝对不能接受？ AI 产品不能只定义正确答案，还需要定义失败边界。查不出数可以澄清，给出一个看似合理的错数却可能形成沉默失败；广告建议可以暂时保守，但不能越过预算和权限边界擅自执行。

第四，谁负责确认这个定义？ 工程师可以保证字段映射和计算逻辑正确，却不应该替业务负责人决定成交口径。业务负责人也不能只提一句“做个智能分析”，然后把所有定义责任留给研发。概念需要有明确的确认人，后续变化也需要留下版本和依据。

这四个问题回答好，很多昂贵的返工其实可以提前避免。

AI 并不会自动让产品定义变得更清楚。如果团队没有主动澄清，它只会让现有的理解更快变成产品。

工程速度越快，越需要在第一行正式产品代码之前，把“我们到底要解决什么”说得更慢一点。

你在做 AI 产品时，有没有遇到过这种情况：功能都做对了，最后才发现问题定义错了？欢迎在留言区分享你的案例。