AI native 这个词在近两年的技术圈里被反复提起，但围绕它的争议从来没有停过。最近 Meta 被曝出放弃内部“AI native 计划”，甚至曾计划将部分团队裁员 60%，这一事件把“AI native 到底是不是伪需求”这个问题重新拉回台面。对于一个真正做过 AI 项目的团队来说，这个现象并不难理解：AI native 不是一句口号，也不是简单接入大模型 API，而是一套涉及数据、模型、评估、人机协作和组织结构的完整工程体系。如果不先解决基础设施和评估闭环，任何激进的团队规划都会在落地阶段被成本和不确定性反噬。
下面从工程实践角度拆解：AI native 到底是什么、一个最小的 AI native 服务长什么样、为什么这类项目容易在团队落地时翻车，以及如果要在自己的业务里推进，应该按什么顺序做。这里不会讨论具体公司的内部管理细节，只聚焦在技术团队真正需要面对的问题。
1. AI native 不是接入大模型 API，而是一套工程体系
很多团队把“项目里调用了大模型接口”当成 AI native，这是最普遍的误解。AI native 的核心在于：应用从设计之初就把模型能力当成主干模块，而不是把模型当作一个外部工具在某个角落调用。
1.1 从“AI 增强”到“AI native”的差别
传统软件如果加一个 AI 功能，通常是在已有业务流程上增加一个模型接口，比如给客服系统加一个自动回复，给编辑器加一个摘要按钮。这种模式可以称为 AI 增强，业务逻辑、数据模型和交互流程仍然以确定性代码为主，模型只是其中一个子模块。
AI native 应用则相反，业务链路本身就由模型决策来驱动。举例来说：
- 智能客服不再只有“规则匹配 + 模型生成回复”，而是由模型理解用户意图、判断是否需要查数据库、决定调用哪个工具、组织最终答案。
- 代码生成工具不再只是“补全当前行”，而是把整个开发任务拆解成子任务，模型来规划文件结构、生成代码、执行测试并修复报错。
- 数据分析产品不再只是“输入 SQL 出报表”，而是让模型理解业务问题、自动生成查询、解释结果、给出下一步建议。
这意味着系统必须围绕模型的不确定性来设计。你需要处理模型会出错、会输出异常格式、会偏离目标、会超出上下文限制等场景。传统软件要求的单元测试、异常处理和性能监控，在 AI native 系统里依然存在，但多了模型质量、提示词版本、检索召回率、工具调用成功率这些新维度。
| 对比维度 | AI 增强 | AI native |
|---|---|---|
| 模型地位 | 可选模块，关闭后系统仍可用 | 核心引擎，关闭后主流程不可用 |
| 数据处理 | 模型输入输出为主，数据管道可选 | 需要向量库、缓存、日志回流形成数据闭环 |
| 质量保障 | 对输出结果抽查即可 | 需要评估集、测试用例、人工反馈循环 |
| 稳定策略 | 权重下均衡可用错误提示 | 需要降级链路、重试、工具校验、人工接管 |
| 团队技能 | 普通后端加提示词调优 | 需要工程、算法、数据、产品共同配合 |
1.2 AI native 容易翻车的地方：交付物边界模糊
传统项目的需求可以写成明确验收标准：“用户点击按钮后，系统在 3 秒内返回结果。”AI native 项目很难这样定义验收标准，因为同一句用户输入，模型可能给出不同质量的输出。
翻车点往往不在模型本身，而在没有人定义“什么算可用”。如果没有建立一套由测试问题集、评估指标、可接受阈值组成的验收机制，项目就会一直处于“看起来能跑，但不敢上线”的状态。
另一个翻车点是在架构上过度设计。业务还没跑通，就先搭建了完善的模型网关、多模型路由、数据回流平台、评测平台。这种投入看起来是为未来做准备，但在业务指标没有验证之前，所有基础设施的成本都不会被业务方认可。合理的做法是先跑一个最小闭环，再逐步扩展架构。
2. 一个最小可运行的 AI native 服务，需要哪些技术件
不讨论概念，直接把一个最小的 AI native 服务搭起来。这里的示例采用 Python + FastAPI + OpenAI 兼容接口，并配合向量检索和工具调用，实现一个具备“查资料、算数据、做总结”能力的智能体雏形。
2.1 核心组件拆分
一个最小 AI native 服务至少包含三部分：
- 模型接入层。负责与大模型接口通信，配置模型名、密钥、超时和重试。
- 检索与记忆层。把业务资料切成片段存入向量库，用户提问时先召回相关片段，作为上下文传给模型。
- 工具调用层。模型需要获取实时信息、执行计算或调用外部系统时，通过工具描述让模型生成结构化调用参数，由后端真正执行。
除了这三个核心部分，还应该有请求日志、反馈记录和评估结果存储。哪怕是最小示例，也应该把日志打印做好，否则后续无法排查模型乱答的问题。
2.2 环境准备与项目结构
建议使用 Python 3.10 及以上版本，先创建虚拟环境：
python -m venv .venv source .venv/bin/activate pip install fastapi uvicorn openai chromadb pydantic python-dotenv如果使用的是标准 OpenAI 兼容接口，还需要准备环境变量文件.env：
OPENAI_API_KEY=your_api_key_here OPENAI_BASE_URL=https://api.openai.com/v1 OPENAI_MODEL=gpt-4o-mini项目结构保持简单：
ai_native_demo/ ├── .env ├── main.py ├── memory.py ├── tools.py └── requirements.txt这里的memory.py负责向量库和文档召回，tools.py负责模型要调用的外部函数，main.py负责组装对话流程和提供 HTTP 接口。实际项目中可以根据团队习惯拆分更多模块，但最小闭环只需要这三个文件。
2.3 代码实现：检索 + 工具调用 + 对话服务
先实现向量检索模块。这里使用 Chroma 的内存模式，不需要额外启动数据库服务：
# memory.py import os import chromadb from chromadb.utils import embedding_functions client = chromadb.Client() collection = client.get_or_create_collection( name="business_docs", embedding_function=embedding_functions.OpenAIEmbeddingFunction( api_key=os.getenv("OPENAI_API_KEY"), model_name="text-embedding-3-small" ) ) def add_docs(docs: list[str], ids: list[str]): collection.add(documents=docs, ids=ids) def search(query: str, top_k: int = 3) -> list[str]: result = collection.query(query_texts=[query], n_results=top_k) docs = result["documents"] if docs: return docs[0] return []注意：OpenAIEmbeddingFunction依赖 OpenAI 的 embedding 接口，如果本地测试时不想依赖远程接口，可以换成chromadb自带的DefaultEmbeddingFunction或本地 embedding 模型，但检索质量会受模型影响。
接着实现工具模块：
# tools.py import json import datetime def get_current_date() -> str: return datetime.date.today().isoformat() def calculate(expression: str) -> float: # 只允许简单算术表达式，生产环境必须做更严格的校验 allowed = set("0123456789+-*/(). ") if not set(expression).issubset(allowed): raise ValueError("invalid expression") return eval(expression) # noqa: S307 TOOLS = [ { "type": "function", "function": { "name": "get_current_date", "description": "获取当前日期", "parameters": {"type": "object", "properties": {}} } }, { "type": "function", "function": { "name": "calculate", "description": "计算简单数学表达式", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，如 1+2*3"} }, "required": ["expression"] } } } ] def call_tool(name: str, arguments: str) -> str: try: args = json.loads(arguments) if arguments else {} if name == "get_current_date": return get_current_date() if name == "calculate": return str(calculate(args.get("expression", ""))) return f"unknown tool: {name}" except Exception as e: return f"tool error: {str(e)}"评估表达式使用eval只是为了简化演示，生产环境不能直接这样写，建议使用asteval这类安全解析库，或者把表达式转成抽象语法树后再判断节点类型。
最后是主服务：
# main.py import os from fastapi import FastAPI from pydantic import BaseModel from openai import OpenAI from dotenv import load_dotenv import memory import tools load_dotenv() app = FastAPI() client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL"), ) MODEL = os.getenv("OPENAI_MODEL", "gpt-4o-mini") class ChatRequest(BaseModel): message: str history: list[dict] = [] SYSTEM_PROMPT = "你是一个业务助手。请先利用历史消息和检索资料，在需要时调用工具，最后用中文回答。" def build_messages(req: ChatRequest) -> list[dict]: retrieved = memory.search(req.message) context = "\n".join(retrieved) if retrieved else "没有检索到相关资料。" messages = [{"role": "system", "content": SYSTEM_PROMPT + "\n参考资料：\n" + context}] messages.extend(req.history[-6:]) # 只保留最近 6 轮，控制上下文长度 messages.append({"role": "user", "content": req.message}) return messages @app.post("/chat") def chat(req: ChatRequest): messages = build_messages(req) for step in range(3): # 限制工具调用轮数，避免死循环 resp = client.chat.completions.create( model=MODEL, messages=messages, tools=tools.TOOLS, tool_choice="auto", temperature=0.2, max_tokens=1024, ) msg = resp.choices[0].message if msg.tool_calls: messages.append({ "role": "assistant", "content": msg.content or "", "tool_calls": [tc.model_dump() for tc in msg.tool_calls] }) for tc in msg.tool_calls: result = tools.call_tool(tc.function.name, tc.function.arguments) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": result }) continue return {"reply": msg.content} return {"reply": "处理超时或工具调用次数过多，请稍后重试。"}这个代码已经构成了一个最小的 AI native 服务：模型是决策者，它可以自主决定是否调用工具、调用哪个工具、如何组织最终回答。后端的检索模块也参与了决策：没有检索到资料时，系统会明确告诉模型“没有相关资料”，避免模型编造事实。
3. 关键参数和配置，决定系统上限的是细节
最小示例跑通之后，真正影响系统质量的是各类参数。很多团队在同一个模型下效果不同，差别就在于参数配置和上下文组织方式。
3.1 模型参数
这里整理常用参数的含义和推荐范围。
| 参数 | 含义 | 推荐初始值 | 调大影响 | 调小影响 |
|---|---|---|---|---|
temperature | 输出随机性 | 0.2 | 回答更多样，更可能偏离事实 | 更稳定，但可能机械重复 |
max_tokens | 单次最大生成长度 | 1024 | 允许更长回答，但成本增加 | 回答可能被截断 |
top_p | 概率累积采样范围 | 0.9 | 更多候选词参与采样 | 更保守 |
presence_penalty | 是否鼓励讨论新话题 | 0 | 回答更容易扩展新内容 | 更容易集中在已有主题 |
frequency_penalty | 是否惩罚重复内容 | 0 | 减少重复表述 | 反复说同一意思 |
在实际项目中，建议固定temperature和top_p，不要两者同时频繁调整。max_tokens要结合业务回答长度设置，智能客服通常 512 到 1024 足够，生成长文档场景可能需要 2048 以上，但也要警惕截断问题。
错误配置的典型现象是：温度调到 1.5 后，同一个用户问题每次都返回不同答案，业务方无法验收。排查时一定要先看配置是否被业务代码覆盖，很多团队在客户端又传了一次参数，导致服务端配置被覆盖。
3.2 检索参数
| 参数 | 含义 | 推荐初始值 | 调大影响 | 调小影响 |
|---|---|---|---|---|
chunk_size | 文档切分长度 | 500 字 | 上下文更完整，但噪音更多 | 定位更准，但可能丢失关键信息 |
chunk_overlap | 相邻切片的覆盖长度 | 100 字 | 减少信息断裂 | 内容可能被截断 |
top_k | 召回片段数量 | 3 | 上下文更丰富，但可能超出窗口 | 更聚焦，可能漏掉关键资料 |
embedding_model | 向量化模型 | text-embedding-3-small | 检索效果更强，但成本更高 | 成本低，长尾语义可能不准 |
检索参数不是越大越好。top_k过大时，模型会被无关片段干扰，反而降低回答准确度。切分文档时，建议优先按章节和标题切分，而不是简单按固定字符数切分。如果资料是 Markdown 或 HTML，可以先解析标题层级，再把每个二级标题下的内容作为一个切片单位。
3.3 工具调用参数
工具调用的稳定性受函数定义影响很大。函数名要简洁清晰，参数描述要写清楚单位和格式。示例中的calculate函数要求expression是字符串，模型可能传入"1+2*3"或"1 + 2 * 3"，后端要能处理空格和不同符号。
工具调用轮数限制也必须设置。示例中限制为 3 轮，避免模型在连续工具调用中进入死循环。生产环境中，每次工具调用都要有超时、日志和结果校验，超时工具要返回明确错误信息，让模型知道这次调用失败。
| 参数 | 含义 | 默认建议 | 错误表现 |
|---|---|---|---|
max_tool_steps | 最大工具调用轮数 | 3 到 5 | 不设时可能死循环 |
tool_timeout | 单个工具超时 | 5 秒 | 工具阻塞导致请求超时 |
retry_times | 工具失败重试次数 | 1 | 不重试时偶发失败直接中断 |
function_description | 函数用途说明 | 要与业务意图精确一致 | 描述模糊导致模型乱选工具 |
4. 运行验证：如何判断这个 AI native 服务真的可用
代码写完后，不能只看服务能不能启动。判断一个 AI native 服务是否可用，需要覆盖正常链路、工具调用链路和异常链路。
4.1 启动服务并发送测试请求
启动服务：
uvicorn main:app --host 0.0.0.0 --port 8000推荐使用 curl 或 Postman 发起测试请求。先测简单问题：
curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{"message": "今天是几号？"}'预期输出中应该包含今天的日期，且调用链路会先触发工具get_current_date。如果模型没有调用工具而是直接回答，需要检查函数描述是否清晰，或检查模型是否支持工具调用。
再测试需要计算的问题：
curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{"message": "帮我计算 (12+8)*3 的结果"}'预期输出为 60。如果calculate工具被多次调用，说明模型第一次解析参数出错，后端返回了错误信息，模型根据错误信息重新调用。这其实是可接受的，但要看日志确认失败原因。
4.2 验证工具调用链路
工具调用链路是否正常，不能只看最终回答。建议在日志里输出完整的调用事件：
[1] assistant tool_calls: get_current_date, arguments: {} [2] tool result: 2025-01-15 [3] assistant tool_calls: calculate, arguments: {"expression": "(12+8)*3"} [4] tool result: 60 [5] assistant final: (12+8)*3 的结果是 60。在tools.call_tool中增加print或日志记录，并按调用轮次输出。这样可以判断：哪个工具被调用、参数是什么、返回结果是什么、模型是否基于结果继续生成。
排查工具问题时遵循以下顺序：
- 参数解析是否成功。
- 工具业务逻辑是否报错。
- 返回内容是否符合模型预期。
- 模型是否在下一轮正确使用工具结果。
- 是否超出工具调用轮数限制。
4.3 评估指标：准确率、时延、成本和失败率
在开发环境里人工看几次回答只能算烟雾测试。要判断系统是否达到可上线标准，至少需要建立一个评估集，例如 20 到 50 条代表性用户问题，并标注预期回答或预期行为。
| 指标 | 含义 | 学习环境阈值 | 生产环境建议 |
|---|---|---|---|
| 回答准确率 | 人工判定回答是否符合预期 | 80% 以上 | 95% 以上（不同业务差异较大） |
| 工具调用成功率 | 工具调用次数中成功比例 | 90% 以上 | 99% 以上 |
| 平均响应时延 | 从请求发出到返回完整回答的时间 | 3 秒内 | 建议按场景确定，5 秒以上需考虑流式 |
| 单次请求成本 | 模型 token 费用 + 工具资源消耗 | 能接受即可 | 需要设置告警和限额 |
| 无效回答率 | 模型拒绝、乱答或答非所问的比例 | 小于 10% | 需要持续压到 1% 以下 |
这里的关键是“预期行为”而不是“预期文本”。对于工具调用类问题，预期行为是正确计算并返回结果；对于检索类问题，预期行为是回答引用了检索到的资料；对于无关输入，预期行为是合理拒绝，而不是编造答案。
模型评估集要定期更新。业务资料变化、用户问题变化、模型版本升级后，都要重新跑一遍评估集，避免只测几个用例就认为系统稳定。
5. AI native 项目为什么容易被叫停：从团队和组织视角复盘
回到开头提到的 Meta 事件。虽然具体细节没有披露，但类似“AI native 计划被放弃”的现象在行业内并不罕见。从工程和团队协作的角度看，AI native 项目翻车的常见原因是可以归纳出来的。
5.1 常见叫停原因
| 叫停原因 | 工程信号 | 组织信号 |
|---|---|---|
| 业务价值不清晰 | 只有 Demo，没有上线指标 | 业务方无法说清用户付费用什么 |
| 评估体系缺失 | 模型回答质量无法量化 | 每次演示都要人工“精心设计”样例 |
| 数据质量不足 | 检索召回结果混乱 | 知识库没有维护人，资料过期严重 |
| 成本不可控 | 单次请求成本远超预期 | 财务报告里 AI 费用持续飙升 |
| 技术债务过高 | 提示词和代码耦合严重，无法升级模型 | 团队不敢修改任何配置 |
| 组织技能错配 | 平台工程师做不了模型评估，算法工程师不熟工程 | 团队之间互相等对方交付 |
很多团队把失败归因于“模型不够好”，但实际测试会发现，换成更强的模型后，准确率只提升几个百分点。真正的问题出在数据、评估和工具链没有跟上。
一个典型的路径是：管理层提出“全面 AI native”，团队立刻开始重构所有系统，但业务指标没定义，数据没有梳理，模型选型没做对比。三个月后发现 Demo 能跑，放到真实流量里效果很差，于是项目被叫停。问题不在 AI 方向，而在推进方式。
5.2 “裁员 60%”这类计划错在哪里
标题里提到的裁员计划，从工程管理角度更值得警惕。AI native 转型并不等于“把原来的团队裁掉 60%，再招一批搞大模型的人”。一个成熟的 AI native 团队需要的是多种技能的组合：
- 熟悉业务和数据的后端工程师，负责接口、存储、工具调用。
- 有模型调优和评估经验的人，负责提示词、检索、质量评估。
- 懂产品和交互的人，负责定义用户场景和验收标准。
- 数据工程师，负责知识库建设、数据回流和指标监控。
如果只保留算法团队，缺少后端和数据人员，模型效果再好也无法进入生产。如果只保留后端，缺少算法评估能力，AI 功能会像一个不可维护的黑盒。
裁掉 60% 的激进方案意味着项目已经在商业验证之前就假设了“少数人能完成多数人的工作”。但 AI native 系统上线后需要持续维护、评估和迭代，而不是一次性交付。真正合理的组织结构是：先保留核心工程和数据能力，再引入算法评估能力，逐步调整角色边界，而不是一次性大换血。
5.3 从 PoC 到生产要过的关
项目叫停通常发生在从 PoC 到生产的过渡期，最常见的问题是“Demo 演示效果好但无法规模化”。规模化需要解决至少四个问题：
- 性能：模型响应慢，需要流式输出、缓存、并发控制。
- 安全：用户输入和工具调用缺少鉴权、限流、内容过滤。
- 可观测：没有日志追踪、成本统计、质量监控。
- 可回滚：模型升级后效果变差，无法快速切回旧版本。
如果你在一个团队里负责推进 AI native，建议在项目启动时就和各方对齐这四件事。不要等到生产事故出现后再补，因为那时候业务方已经对项目失去信心。
6. AI native 落地排错手册
下面整理 AI native 服务上线后最常见的四类问题，每类都按“现象、原因、排查方式、解决建议”排列。
6.1 模型乱答、不按格式输出
现象：模型输出大段无关内容，或没有返回约定的 JSON 格式，导致下游解析失败。
| 检查点 | 操作 | 判断标准 |
|---|---|---|
| 系统提示词 | 查看提示词里是否明确要求输出格式 | 提示词要给出示例输出 |
| temperature | 检查是否被调得过高 | 结构化任务建议 0 到 0.3 |
| 工具描述 | 检查函数参数说明是否清晰 | 参数缺少枚举值时模型容易乱传 |
| 历史消息 | 检查前几轮是否污染了上下文 | 历史消息里如果出现乱答，后续会受影响 |
| 模型能力 | 确认模型是否支持 JSON 或工具调用 | 部分轻量模型不适合严格结构化输出 |
解决方案是输出校验层，而不是纯靠提示词。建议在代码里使用 Pydantic 或 JSON Schema 校验模型输出，失败时自动重试一次或提示用户重新表述。
6.2 上下文超限和记忆丢失
现象：对话到第 8 轮后，模型忘记用户早些时候说过的信息，或者直接报上下文超限错误。
原因通常是直接把完整历史消息全部塞给模型。很多模型上下文窗口有限，而且随着对话变长，模型会越来越难从长文本中提取关键信息。
| 方案 | 优点 | 缺点 |
|---|---|---|
| 截断最近 N 轮 | 简单，节省 token | 丢失早期关键信息 |
| 对历史做摘要 | 保留核心内容 | 摘要有信息损耗 |
| 向量记忆检索 | 按需召回相关信息 | 需要额外检索逻辑 |
| 关键信息持久化 | 用数据库保存用户偏好 | 需要抽取和维护字段 |
在示例代码里，req.history[-6:]就是最简单的截断方案。生产环境建议把“当前意图直接相关的内容”放到主上下文，把“历史事实”放到摘要或检索记忆里。
6.3 工具调用参数错误
现象：模型调用了工具，但参数格式不对，比如calculate收到expression: "1+2x3"，后端无法计算。
原因有两类：一是函数描述没有写清参数格式，二是模型本身数学表达不准确。解决方案是：
- 在工具函数入口做参数标准化，比如统一替换
x为*。 - 对参数做预校验，如果校验失败，返回模型可读的错误信息。
- 在提示词里给一个工具调用示例。
- 增加工具调用重试，但限制重试次数。
注意：工具返回的错误信息是给模型看的，不是给终端用户看的。不要让模型把底层的 Python 异常直接抛给用户。
6.4 检索结果质量差
现象：模型回答明显没有引用正确资料，或者把不相关的内容当成依据。
这是 RAG 类 AI native 服务最常见的问题。排查链路：
- 先看检索结果：把用户问题输入
memory.search()，直接打印召回片段。 - 如果召回的片段本身不相关，问题出在向量化或切分方式。
- 如果召回片段相关但模型没用上，问题出在提示词或上下文组织。
- 如果相关片段被后面的无关片段淹没了，需要调整
top_k或增加重排序环节。
推荐做法是增加一个 rerank 步骤，先用向量检索召回 10 条候选，再用交叉编码器或更简单的关键词过滤把 top 3 捞出来。这个方案能显著提升回答质量，成本增量也不大。
7. 推进 AI native 的最佳实践和下一步
最后给出可复用的实践建议，按优先级排序。
7.1 先跑通最小闭环，再谈组织调整
不要在验证之前做大团队重构。推荐路径是：
- 选择一个人工成本最高、数据相对完整、可量化收益的业务场景。
- 用最少代码搭出示例里的智能体服务，接真实数据。
- 用 20 到 50 条测试问题验证效果，记录准确率和成本。
- 如果指标达到预期，再考虑增加基础设施和团队投入。
- 如果指标达不到，先修数据、检索和提示词，不要急着换更大模型。
7.2 建立数据回流和评估平台
AI native 系统上线不是终点，而是评估数据的起点。生产环境至少要记录以下信息：
- 用户原始输入。
- 模型最终输出。
- 是否调用工具，工具结果是什么。
- 用户是否点击了“有帮助”或“无帮助”。
- 模型输出时使用的会话和检索上下文版本。
这些数据沉淀下来后，才能持续优化提示词、微调模型或切换模型版本。没有数据回流，AI native 永远停留在“人工调提示词”阶段。
7.3 适合直接做 AI native 的场景和暂时不适合的场景
| 场景 | 适合程度 | 原因 |
|---|---|---|
| 企业内部知识问答 | 高 | 知识库边界明确，可以控制数据质量 |
| 客服辅助工单生成 | 高 | 人机协作，模型出错可人工修正 |
| 代码生成与检查 | 中 | 需要结合编译器和测试工具做闭环 |
| 自动化报表解读 | 中 | 结果可比较，评估指标清晰 |
| 高并发交易决策 | 低 | 模型不确定性难以满足风控要求 |
| 涉及强监管的合同审核 | 低 | 出错后果严重，暂时需要人工兜底 |
如果业务属于“低”列，不等于不能用 AI，而是更适合采用 AI 增强模式：模型建议，人工决策；或者先在小范围上线，让人工审核成为必要环节，再逐步扩大自动化比例。
7.4 发布前检查清单
- [ ] 是否建立了至少 20 条测试问题的评估集。
- [ ] 检索召回结果是否由人工抽查，召回相关度是否达标。
- [ ] 工具调用参数是否有校验，错误信息是否可读。
- [ ] 是否设置工具调用轮数上限和单次请求超时。
- [ ] 是否对用户输入和模型输出做了内容过滤和限流。
- [ ] 是否记录了完整日志，包含模型名、提示词版本、工具调用链、耗时、费用。
- [ ] 模型升级后是否跑过回归评估。
- [ ] 是否定义了系统不回答的场景和兜底话术。
- [ ] 生产环境是否保留了关闭模型、切回旧配置的开关。
- [ ] 是否明确了数据回流方式，能追踪每次回答的质量。
如果这份清单里有超过两项没有落实，建议不要直接上线，因为这些问题在上线后都会变成不可控的故障，最终消耗的是团队对 AI native 的信任度。
AI native 本身没有错，错的是把它当成万能口号、跳过工程验证直接大规模推进。真正扎实的路径是从一个最小闭环开始，把数据、评估、工具调用、可观测性逐步补齐。做到这一步之后再谈组织升级，才不会被模型热潮牵着走，也不会因为一次项目叫停就全盘否定方向。
