AI 产品真正稀缺的，还是功能吗？Are features still what AI products lack?
当生成、对话和 Agent 功能越来越容易复制，真正难以复制的是问题判断、系统边界、验证闭环和信任。As chat, generation, and agent features become easier to copy, I find the harder work in problem judgment, system boundaries, verification, and trust.
如果用功能清单比较 AI 产品，这张表永远写不完。
能对话、能搜索、能总结、能生成图片、能调用工具、能自动执行任务。今天仍然新鲜的能力，可能很快就会出现在另一个产品里；一个团队花很久做出的功能，也可能随着模型或平台升级，突然变成基础能力。
这并不意味着功能不重要。没有可用的能力，产品只是一个愿望。但当越来越多团队可以调用相似的模型、接入相似的工具时，只回答“它能做什么”，已经很难解释一个 AI 产品为什么值得存在。
我越来越想追问的是：功能之外，真正稀缺的是什么？
先判断什么值得交给 AI
AI 很擅长让一个想法迅速显得可行。输入一句需求，很快就能得到一套界面、一段流程，甚至一个可以演示的 Agent。速度带来的危险是，我们可能在还没弄清问题之前，就开始优化答案。
一个产品要帮助长辈使用手机，真正的问题是缺少语音助手吗？也可能不是。障碍可能来自害怕误操作、看不懂系统提示、记不住连续步骤，或者在需要求助时说不清自己卡在哪里。
如果问题判断错了，再聪明的模型也只是在更高效地绕开真实困难。
所以第一种稀缺能力，是定义问题。它要求产品进入具体情境，分清用户说出的要求、实际承担的成本和系统真正能够改变的部分。很多时候，最重要的决策不是增加一个 AI 功能，而是删掉一个并不需要 AI 的环节。
产品是一份关于边界的承诺
传统软件通常在等待明确指令，Agent 则开始观察、计划、调用工具并影响外部世界。能力越主动，边界就越重要。
我喜欢把一个完整过程拆成几个动作：观察发生了什么，形成计划，选择工具，执行改变，再验证结果。它看起来像一条顺畅的自动化流水线，但每两个动作之间都藏着问题。
系统观察了哪些数据？计划依据是否充分？工具拥有什么权限？改变能不能撤回？验证失败之后，是重试、降级，还是交给人？
如果这些问题没有答案，“自动执行”就只是一场顺利路径上的演示。
在健康、家庭、财务和业务决策等场景中，好的 AI 产品不只要说明自己会做什么，也要清楚说明自己不会做什么。它需要在低风险任务中减少摩擦，在高风险节点请求确认，在证据不足时承认不确定，并为人工接管留下自然的入口。
边界不是能力不足之后的补丁。它本身就是产品的一部分。
从回答正确，到事情真正完成
许多 AI Demo 结束在一句看起来不错的回答。但真实用户关心的通常不是“回答生成了吗”，而是“我的事情解决了吗”。
假设一个长辈说：“我想和女儿视频。”系统识别了意图，并给出一段操作说明，这只能算完成了第一步。接下来还要知道对方使用什么应用，当前手机处于什么状态，用户有没有跟上，遇到弹窗怎么办，拨通之后是否需要停止指导。
如果中途出现陌生链接、付款提示或权限请求，原本简单的任务还会突然改变风险等级。此时继续追求自动完成，可能反而违背用户利益。
所以我理解的产品闭环，不是让 AI 多说几句，而是让系统对结果负责：能够确认目标、跟踪过程、检查结果，也能在失败时安全退出。
这也是我对 FDE / AI 应用工程感兴趣的原因。真正的交付并不是把一个通用能力扔进业务现场，而是把模糊需求拆成可验证的步骤，把异常、回滚和人审一起设计进去，再用真实反馈判断它是否值得继续。
信任来自可预期，而不是拟人化
我们很容易通过语气、头像和人格设定，让 AI 显得更像一个人。但“像人”并不等于“值得信任”。
真正的信任往往来自一些不那么戏剧化的细节：它不会在不确定时装作确定；不会悄悄扩大权限；不会把一次成功说成始终可靠；不会为了留住用户制造焦虑；也不会在做不到时把责任推给一句笼统的免责声明。
用户不必知道系统背后的全部技术，但应该能够预期：接下来会发生什么，我能否停止，出了问题该找谁，以及这一次操作留下了什么记录。
这种可预期性很难通过一次发布建立。它来自一次次一致的行为，也来自团队愿意诚实地记录失败。
功能会趋同，判断会留下
当基础能力越来越普及，AI 产品的差异可能不会主要来自“比别人多一个按钮”，而来自一组更慢的积累：对场景的理解、对风险的克制、对失败的设计、对结果的验证，以及与真实用户共同建立的信任。
功能可以被复制，界面可以被模仿，提示词也很难成为永久壁垒。真正不容易被复制的，是一个团队长期在同一类问题里形成的判断：知道什么时候该自动化，什么时候该让人出现；知道哪些成本可以降低，哪些责任不能被隐藏。
所以，AI 产品真正稀缺的，或许从来不只是功能。
稀缺的是，在能力不断扩张时，仍然知道为什么而做、为谁而做，以及应该在哪里停下。
A feature comparison of AI products could go on forever.
They can chat, search, summarize, generate images, call tools, and carry out tasks. A capability that feels new today may soon appear in another product. A team can spend months building a feature, only to see a model or platform update make it a standard offering.
Features still matter. Without working capabilities, a product is a wish. But as more teams gain access to similar models and tools, describing what a product can do tells me less about why it deserves to exist.
I keep wondering what remains scarce beyond those features.
First, decide what deserves AI’s involvement
AI can make an idea look feasible in a short time. A brief request can produce an interface, a workflow, or even an agent ready for a demo. At that speed, we risk improving an answer before we understand the problem.
Suppose I want to help older adults use smartphones. Do they need another voice assistant? Perhaps their difficulty comes from fear of a wrong tap, confusing system messages, too many steps to remember, or not knowing how to describe where they’re stuck.
If I misread the problem, a smarter model may help me work faster while leaving the difficulty untouched.
The first scarce capability, then, is problem framing. I need to work within a specific situation and distinguish what someone asks for from the costs they bear and the parts a system could change. Sometimes the useful decision is to remove a step that never needed AI.
A product makes a promise about its boundaries
Traditional software tends to wait for explicit instructions. Agents begin to observe, plan, call tools, and affect the world outside the interface. As they act with more initiative, I need clearer boundaries.
I like to break the process down: observe what happened, form a plan, choose a tool, make a change, and verify the result. It sounds like a smooth automated sequence. Between each pair of steps, though, I have questions to answer.
Which data did the system observe? Does it have enough evidence for its plan? What permissions does the tool hold? Can the change be undone? After a failed check, should it retry, fall back to a simpler approach, or hand over to a person?
Without answers, an “autonomous” demo shows me only the path where things go well.
In health, family care, finance, and business decisions, I want an AI product to state what it will not do as clearly as what it will. It should reduce friction in low-risk tasks, ask for confirmation at high-risk steps, acknowledge uncertainty when evidence is thin, and leave a clear way for a person to take over.
I consider those boundaries part of the product from the beginning, rather than something to add after discovering a limitation.
A good answer is only part of getting something done
Many AI demos end with a plausible answer. Users tend to care about whether they have resolved the thing they came to do.
Imagine an older person saying, “I want to video-call my daughter.” Recognizing the intent and producing instructions gets them through a first step. The system still needs to account for which app they use, what is on the phone now, whether they have followed the instructions, what to do about a pop-up, and when to stop guiding once the call connects.
An unfamiliar link, payment prompt, or permission request can change the risk of that task midway through. Continuing toward automatic completion may then work against the user’s interests.
For me, completing the product workflow means taking responsibility for the outcome: confirming the goal, following progress, checking the result, and providing a safe exit when something fails.
That is also what draws me to forward-deployed engineering (FDE) and AI application engineering. Delivering useful work takes more than dropping a general-purpose capability into a business setting. I need to break an unclear request into testable steps, account for exceptions, rollback, and human review, then use feedback from practice to decide whether the approach deserves more work.
Trust takes predictable behavior
Tone, avatars, and personality settings can make AI seem more human. They give me little reason on their own to trust it.
I look for less theatrical details. Does it admit uncertainty? Does it stay within the permissions I gave it? Does it distinguish one successful attempt from consistent reliability? Does it avoid creating anxiety to keep me engaged? If it cannot help, does it offer something more useful than a broad disclaimer?
Users do not need to understand all the technology behind a system. They should be able to anticipate what happens next, whether they can stop it, whom to contact if something goes wrong, and what record the operation leaves.
A team cannot establish that predictability in one launch. It takes consistent behavior over time and a willingness to document failures honestly.
Similar features still leave room for different judgments
As basic capabilities become more common, I suspect AI products will differ less through an extra button and more through work that takes time: understanding a setting, exercising restraint around risk, preparing for failure, checking outcomes, and earning trust with real users.
Others can copy features, imitate interfaces, and reproduce prompts. A team’s accumulated judgment about a particular kind of problem is harder to reproduce. They learn when to automate and when to involve a person, which costs they can reduce, and which responsibilities they must keep visible.
Perhaps features were never the only scarce part of AI products.
As capabilities keep expanding, I want to keep asking why I am building something, whom it serves, and where I should stop.