三成
选模型、写提示词、搭一条检索链路、把第一个可用版本跑起来 —— 这部分现在非常快。快到会产生一种错觉：这件事已经做完了。
一个能在会议室里让所有人点头的 demo，两周就能有。我做过很多次，每次都很顺利。
七成
然后是剩下的部分。列出来一点都不性感：
- 状态存在哪里，进程死了会发生什么
- 依赖的外部服务超时了，用户看到什么
- 并发上来之后，哪个环节先崩
- 谁能看到哪些数据，这个边界放在应用层还是数据库层
- schema 要改的时候，已经在跑的客户怎么办
- 出问题时，能不能在五分钟内定位到是哪一层
- 改动上线前，有没有东西能拦住一个会打破契约的提交
这七件事里没有一件和 AI 有关。它们是软件工程。但正是它们决定了一个系统能不能被真实业务依赖。
Demo 和产品之间的距离，几乎全部由不涉及模型的工程构成。
一个具体的例子
应急呼叫系统里，模型部分是这样的：LLM 加一条 RAG 链路，接地到 SOP 文档。这部分的设计和实现，大概两周。
剩下的时间花在哪了？
- 把通话状态搬到 Redis，让任何 worker 都能接管任何一通电话
- 设计心跳和 watchdog，让崩溃在十秒内被发现
- 把整条链路改成流式，让首字音频从 6.8 秒降到 2.3 秒
- 调 VAD，让系统不打断一个紧张的人
- 做四级降级，保证最坏情况下有人接
- 处理打断，让系统不和被困的人抢话
这些工作没有一项会出现在模型的技术报告里。但如果少做任何一项，这个系统都不能上线 —— 不是「体验差一点」，是不能上线。
这对决策者意味着什么
如果你正在评估要不要做一个 AI 项目，或者要不要信任一个团队来做，有三个问题比「你们用什么模型」有用得多：
- 当模型超时或返回错误时，用户看到什么？没有想过这个问题的团队，还没有开始考虑生产环境。
- 数据的权限边界在哪一层？如果答案是「我们在代码里都加了判断」，那这个边界迟早会漏。
- 这个东西上线之后，怎么知道它变差了？没有衡量手段的 AI 系统，会以一种没人察觉的方式慢慢退化。
模型是会变的 —— 每隔几个月就有更好更便宜的。但上面这三件事一旦做错，换任何模型都救不回来。
带走的规则
判断一个 AI 系统成熟度，别看它最好的时候有多聪明，看它最差的时候有多体面。
The 30%
Choosing a model, writing the prompt, wiring a retrieval chain, getting a first working version running — that part is now very fast. Fast enough to create an illusion that the job is done.
A demo that makes everyone in the room nod takes about two weeks. I've built that demo many times and it always goes smoothly.
The 70%
Then there's the rest. Written out, none of it is glamorous:
- Where state lives, and what happens when a process dies
- What the user experiences when an external dependency times out
- Which component fails first as concurrency rises
- Who can see which data, and whether that boundary sits in the app or in the database
- What happens to customers already running when the schema has to change
- Whether you can find which layer broke within five minutes of it breaking
- Whether anything stops a commit that quietly breaks a contract
Not one of those seven is an AI problem. They're software engineering. And they are exactly what decides whether a business can depend on the system.
The distance between a demo and a product is made almost entirely of engineering that has nothing to do with the model.
A concrete example
In the emergency call system, the model portion looks like this: an LLM plus a RAG chain grounded in SOP documents. Designing and building that took roughly two weeks.
Where did the rest of the time go?
- Moving call state into Redis so any worker can take over any call
- Designing heartbeats and a watchdog so a crash is detected within ten seconds
- Converting the whole chain to streaming, taking first audio from 6.8 seconds to 2.3
- Tuning VAD so the system doesn't interrupt a frightened person
- Building four tiers of fallback so that in the worst case, a human answers
- Handling barge-in so the system doesn't talk over someone who is trapped
None of that appears in any model's technical report. And leaving out any single one of them means the system cannot launch — not "launches with a rough edge", cannot launch.
What this means if you're deciding
If you're weighing whether to build an AI project, or whether to trust a team with one, three questions are far more useful than "which model are you using":
- What does the user see when the model times out or errors? A team that hasn't thought about this hasn't started thinking about production.
- Which layer holds the data permission boundary? If the answer is "we check it everywhere in the code", that boundary will leak eventually.
- Once it's live, how will you know it got worse? An AI system without measurement degrades in ways nobody notices until a customer does.
Models change — there's a better and cheaper one every few months. Get those three wrong, though, and no model rescues you.
The rule I kept
To judge an AI system's maturity, don't look at how clever it is at its best. Look at how dignified it is at its worst.