一篇写给“Yi经开始Zuo AI，但不想停留在 Demo 阶段”的前端工程师。

hen多团队在接入 AI 后hen快会遇到这些问题：Prompt 不稳定、结果难以复现、无法debug、 性差、成本失控… Ru果你kan到这里说明你Yi经不是在“用 AI”了。你正在思考如何把 AI 工程化。

一、从“用 AI”到“工程化 AI”

这个Zui值得你搞。 现在大家dou在讨论如何利用大型语言模型 来提升效率、创新产品。但鲜有人关注：如何将 LLM 集成到可靠、可维护的软件系统中。 这才是决定你Neng否在未来脱颖而出的关键。

二、AI Harness：让 AI 可控

别上来就要大而全。 你先Zuo一个MVP Harness，结构如下：

核心理念

AI Harness = 让 AI 从“Neng用”变成“可控、可测、可观测、可回归”的工程系统

没这个，你的 AI 项目迟早变成玄学现场。

基本结构

runAI

👉 每个场景：

const prompt = 你是一个AI助手...

这会导致后面：

type ChatMessage = { id: string role: 'user' | 'assistant' | 'tool' content: string status?: 'streaming' | 'done' | 'error'}

然后写个 runner：

, "mustNotInclude":  } }, { "id": "case-", "scene": "bug-fix", "input": "修复 React useEffect 重复请求问题", "expected": { "mustInclude":  } }]

三、分层设计 1️⃣ UI 层

职责：用户交互界面。

前端别碰太多模型细节，UI 层只管：

负责：

显示结果；收集用户输入；调用 API。

hen多人一上来就想：

把所有的逻辑dou塞到前端，直接调用 OpenAI API。 这绝对是错误的Zuo法！

2️⃣ AI Service 层

👉 相当于AI 的 BFF

👉 你就无法 debug

现实一点说： 这层负责封装 LLM 调用细节；处理 prompt 构建和解析；管理工具调用；实现错误处理和重试机制。

谁会用 AI？随着 AI 处理任务复杂度的增加，工程重点经历了三个阶段的演进:

3️⃣ Tool 层

searchDocs

runTests

createPatch

4️⃣ Observability 层

这是hen多人Zui容易漏的。

你觉得回答geng好了不代表真geng好了。

要记录所有关键信息:

请求参数

模型版本

prompt 内容

工具调用

输出结果

耗时

5️⃣ Eval / Regression 层 四、核心代码结构

src/├── ai/│ ├── core/│ │ ├── ai-service.ts│ │ ├── model-router.ts│ │ ├── prompt-builder.ts│ │ ├── output-parser.ts│ │└── trace.ts│ ││├── scenes/│ │├── bugFixScene.ts│ │└── faqScene.ts│ ││└── tools/│ │├── searchDocsTool.ts│ │└── runTestsTool.ts│ │└── eval/│ └── datasets/└── server/└── api/└── apps/└── chat/

五、场景抽象

export interface AIScene{ name: string tools?: string model?: string buildPrompt: Promise parseOutput: unknown}

六、不要把AI当成一个“万Neng函数” 七 、

---