前段时间，我在 Lenny's Podcast 上听到 OpenAI Codex 桌面应用的产品与工程负责人 Andrew Ambrosino 说了一句话：
"The implementation is actually not the expensive part anymore. It's, dare I say, taste."
实现已经不再是昂贵的部分了，我敢说，是品味。
这句话让我重新审视了自己这段时间做 AI 产品的经历。
我在 DeepSeek Harness（DSH）上做了一个插件，叫 KNIT。大部分实现由 AI Coding 辅助完成，我没有亲手逐行编写插件的主要代码。
但这不意味着整个过程只需要告诉 AI 一句需求。
恰恰相反，真正让我反复推敲的，是做什么、不做什么，哪些结果可以接受，哪些错误绝不能发生，以及怎么判断一个功能到底有没有用。
回头看，我逐渐意识到：AI 降低的是实现门槛，不是产品判断的成本。
下面结合 KNIT 的开发经历，聊聊我对这件事的理解。
一、产品不是从功能列表开始，而是从真实摩擦开始
KNIT 最初来自一个非常具体的问题。
我使用 DSH 时，Agent 一天可以生成很多文档。产出速度很快，但文档一多，找东西反而成了问题。
例如，昨天生成的 changelog 在哪里？刚刚讨论过的那份方案，怎样才能快速找回来？
DSH 自带的最近文件功能，解决的是"我最近打开过什么"。但对话结束之后，我真正需要的，往往不是最近打开过的文件，而是当前任务最相关的内容。
于是，我开始尝试做一个插件，让它根据当前对话，从工作区中找出更相关的文档。
一开始，我没有把它设计成一个完整的平台，也没有预先规划很多模块。我先解决自己每天都会遇到的麻烦，再根据实际使用情况逐步扩展。
后来，KNIT 的问题定义也发生了变化。
它不再只围绕 Markdown 文档，而是逐步将源码和媒体纳入同一条上下文检索链路。检索结果也不仅仅是一份列表，而是区分主要、辅助和相关上下文，并追踪这些内容是否被 Agent 读取、读取后有没有发生变化。
产品的起点是找文档，后来逐渐变成了一个更完整的问题：
Agent 正在处理当前任务时，工作区里哪些内容最值得先看？这些内容又有没有真正被读取和持续跟踪？
这里还有一个值得说明的细节。
KNIT 的插件市场下载计数曾超过 3000，但下载计数并不等于 3000 名真实用户，更不能直接证明用户已经持续使用或验证了产品价值。
我不打算拿一个漂亮的数字，替代真正的产品验证。
对我来说，更值得复盘的是：我怎样从一个实际问题出发，一步步确定这个产品应该做什么，以及哪些东西不应该做。
二、AI 一句话能做出 Demo，但不能替你做完判断
使用 AI Coding 的人，大概都经历过这样的过程：
你提出一个需求，AI 很快就能生成代码，搭出一个能运行的 Demo。
但 Demo 能运行，只说明某条路径跑通了。一个功能能不能真正使用，还取决于它在异常情况、边界条件和真实任务中表现如何。
KNIT 的开发过程中，我做过几个看起来很小、实际上会影响产品可信度的决定。
1. 不展示看似精确的相关度分数
我考虑过是否要给每份推荐文档展示一个相关度分数，最后选择不展示。
原因是，检索分数依赖当前的候选集合和排序规则。用户或 Agent 很容易把一个相对排序值，理解成绝对可信度。
一个文件排在第一位，只能说明它在当前检索规则下更靠前，不代表它一定是正确答案。
所以，我更倾向于直接提供排序结果以及可核验的命中理由，而不是给出一个容易被过度解读的数字。
2. 找不到正确项目时，宁可报错，也不做错误兜底
假设 Agent 找不到当前会话对应的工作区。
一种做法是继续向外搜索，试图找一个看起来相似的项目，让流程尽量跑下去。
另一种做法是明确告诉用户没有找到正确的会话或工作区。
我更倾向于第二种。
因为在上下文检索中，返回空结果和返回错误结果不是一回事。
没有结果，Agent 还知道自己缺少信息；错误的文件却可能被当成正确的项目上下文，进一步影响后续推理和修改。
有些场景下，拒绝提供不可靠的结果，比强行给出一个答案更有价值。
3. 有成本的功能，不应该默认替用户做主
我还考虑过使用统计功能。
这类功能能够帮助我了解插件的使用情况，但也会带来额外的 token 成本。
因此，我选择让统计功能默认关闭，由用户决定是否开启。
这些决策都不复杂，但它们说明了一件事：产品开发并不只是把需求变成代码，还包括持续判断哪些价值值得实现、哪些成本应该由谁承担，以及什么行为可能伤害用户对产品的信任。
这大概就是我开始理解的"品味"。
它不只是视觉审美，更包括对产品边界、使用成本、异常行为和系统整体目标的判断。
三、不要只看功能跑通，还要看真实结果
AI 产品容易出现一个问题：功能看起来比以前好了，但我们未必知道整体效果是否真的改善。
我在测试 KNIT 时做过一次对照实验。
安装 KNIT 之后，Agent 找文件的表现更好，但在当时那组测试中，文件读取次数反而从平均 4.75 次增加到了 6 次。
如果只关注检索是否命中，这看起来是一个不错的结果；如果同时考虑读取次数和 token 成本，就需要进一步解释：为什么读取变多了？
它可能意味着 Agent 找到了更多值得读取的内容，也可能意味着它仍然需要额外读取才能确认信息。
仅凭这一个指标，我还不能得出整体效率一定提高的结论。
这不是一项足以推广到所有任务的大样本实验，而是一次值得继续追查的对照观察。
我认为这里有一个重要的经验：
不要只挑能证明自己做对了的指标，也要认真看那些暂时解释不了的结果。
对于 AI 工具，至少需要区分几个问题：
- 找到的内容是否更相关？
- Agent 是否减少了不必要的探索？
- 读取成本和执行时间有没有变化？
- 最终任务是否更容易完成？
- 用户是否更敢于使用结果？
这些指标并不总是同步改善。检索更准确，不代表读取次数一定更少；生成速度更快，也不代表结果更可靠。
我更愿意把产品验证看成一个持续发现问题的过程，而不是上线前找几个数字证明功能有效。
四、把这套方法带到业务中：先挑一个流程，亲自跑透
接下来，我想把这种做法带到企业内部的 AI 提效实践中。
我越来越不愿意一上来就问："这个业务能不能接入 AI？"
我更想先弄清楚：这个流程究竟在哪里让人难受，AI 能解决其中的哪一段，以及解决之后怎样判断它是否真的有价值。
例如，设计流程表面上的痛点可能是 AI 画图慢，但真正影响交付的，也可能是生成结果不能直接使用，需要大量修改。
运营流程表面上的问题可能是查数慢，但真正的阻碍，也可能是数据来源不清楚、结果难以核验，导致运营人员不敢直接拿去汇报。
这些是我准备进一步验证的判断，而不是已经验证完成的结论。
因此，我会优先挑一个高频、边界相对清晰、结果可以观察的场景，自己从头到尾跑一遍。
我的思路大致分成四步。
第一步：先确定一个具体流程。
不要同时铺开设计、运营、客服和法务。先找到一个真实发生、反复出现的问题，把场景的起点和终点说清楚。
第二步：亲自完成整个流程。
从拿到输入开始，一直到交付结果、核验结果和处理异常。不要只体验 AI 生成的那一瞬间，而要观察前后环节怎样衔接。
第三步：找到真正的阻塞点。
不要预先认定问题就是效率低，也不要看到一个环节能用 AI，就急着给它接上模型。
要弄清楚，流程究竟卡在等待、重复操作、信息查找、结果核验，还是用户不敢承担错误结果的风险。
第四步：只改造最有价值的一段，再比较前后差异。
先做最小的可用方案，再观察耗时、返工、错误和结果采纳情况。发现效果不好，就继续定位问题，而不是为了证明 AI 有价值，强行把流程包装成一个成功案例。
我希望最后留下的，不只是一个能演示的 AI 功能，而是一个经过真实流程验证、其他人也能复用的样板。
五、实现越容易，越需要知道什么时候不做
Andrew Ambrosino 在访谈中还谈到，大量原型可以同时出现。真正重要的，是从这些尝试中判断哪些值得保留、怎样组合，以及它们应该如何融入完整的产品。
这让我想到，AI Coding 并不意味着产品经理不再需要写文档、做原型或者规划。
更准确地说，我们需要根据当前的问题，选择合适的工作方式。
当问题本身还没有想清楚时，可能更需要研究和文档；当我们要验证交互是否成立时，原型可能更合适；当一个方案已经有了明确边界，就可以让 AI 更快地完成实现，再通过真实使用不断修正。
关键不是追求某一种固定流程，而是知道当前最需要什么证据。
如果只是因为 AI 能轻松做出一个功能，就不断增加功能，那么实现成本下降，反而可能让产品越来越复杂。
如果每次实现之后，都能进一步明确问题、验证假设、排除错误方向，那么低成本实现才真正转化成产品优势。
回到 KNIT，我并不认为自己已经找到了一套适用于所有 AI 产品的标准答案。但这段经历至少让我更清楚地认识到：会让 AI 做东西，只是开始；知道为什么做、怎样判断做得好不好，以及什么时候不应该继续做，才是更值得持续练习的能力。
实现变便宜了，品味才是稀缺。
如果你也在做 AI 产品或 Vibe Coding，与其一开始就做一个大而全的工具，不如先选一个自己熟悉的流程，亲自跑透。
看看究竟是什么让你反复返工，是什么让你不敢相信结果，又是什么证据能够说明问题真的得到了解决。
有时候，最有价值的产品能力，不是让 AI 多做一些，而是知道应该让它做什么，以及做到什么程度才算真正有用。
参考资料
- Andrew Ambrosino，Lenny's Podcast：《OpenAI Codex lead on the new shape of product work》
www.lennysnewsletter.com/p/openai-co... - KNIT GitHub 仓库
github.com/PolinniZhon...