停止编写提示。开始构建 AI 系统。
Source: Dev.to
状态: 草稿
Source: …
1. 真正的升级：从 Prompt 到 Engineering Loop
在传统软件中，你编写的是确定性的代码。
在 AI 系统中，行为是 概率性的——你不再硬编码逻辑，而是 塑造它。
难点不在于生成文本；而在于 在成千上万次交互中控制行为。
控制来自于对循环的工程化。
AI Engineering Loop
+------------------+
| GOAL |
+------------------+
↓
+------------------+
| SUCCESS CRITERIA |
+------------------+
↓
+------------------+
| TEST CASES |
+------------------+
↓
+------------------+
| PROMPT + CONTEXT |
| VERSION |
+------------------+
↓
+------------------+
| MEASUREMENT |
+------------------+
↓
+------------------+
| ITERATION |
+------------------+
↺- 如果在编写 Prompt 之前 没有定义成功标准，那就不是工程化。
- 如果 没有在结构化案例中测试行为，那就不是工程化。
- 如果 无法比较版本并衡量改进，那就不是工程化。
否则，你仅仅是在 实验。
2. Prompt Engineering 是基本要求
一个可预测的提示包含以下结构：
| 要素 | 描述 |
|---|---|
| ROLE | 模型应扮演的角色 |
| CONTEXT | 背景信息 |
| TASK | 模型必须完成的任务 |
| CONSTRAINTS | 行为限制 |
| REFERENCES (examples & anti‑examples) | 风格/质量指南（示例与反示例） |
| OUTPUT FORMAT | 答案的期望格式 |
这提升了可靠性，但提示结构类似于 function signature —— 必要但不充分。
当你开始提问：
- 在 20 回合之后会发生什么？
- 在 1,000 位用户之间会发生什么？
- 在对抗性输入下会发生什么？
- 当工具执行真实操作时会发生什么？
此时你不再是设计提示，而是在设计 systems。
3. Context Engineering: 大多数团队忽视的学科
- Prompt engineering = 你说的内容
- Context engineering = 模型看到的内容
在生产环境中，模型的 context window 包含：
- 系统指令
- 对话历史
- 检索到的文档
- 工具输出
- 记忆摘要
- 集成状态
它们共同竞争 有限的 token——一种稀缺资源。
- 上下文过多 → 注意力被稀释。
- 上下文无关 → 推理崩溃。
- 将指令与不可信数据混合 → 行为不可预测地变化。
这不是 bug；这是 物理规律。
Context Window Architecture
+------------------------------------------------------+
| CONTEXT WINDOW |
+------------------------------------------------------+
| [SYSTEM INSTRUCTIONS] |
| - Role |
| - Rules |
| - Constraints |
+------------------------------------------------------+
| [RETRIEVED DOCUMENTS] |
| - High‑signal chunks only |
+------------------------------------------------------+
| [TOOL RESULTS] |
| - DB queries |
| - Code output |
+------------------------------------------------------+
| [CONVERSATION MEMORY] |
| - Summarized prior turns |
+------------------------------------------------------+- 将所有内容全部塞入上下文会 降低质量。
- 积极进行内容筛选会 提升稳定性。
RAG（Retrieval‑Augmented Generation）不是 功能，而是 记忆架构。外部知识必须：
- 建立索引
- 正确分块
- 进行排序
- 以纪律性注入
检索不佳会破坏生成质量。
4. 工具使用：当文本变为行动
当你的模型能够调用工具时，你不再是一个聊天机器人——你拥有了一个 agent。
最小代理循环
用户请求
↓
模型决定：是否需要工具？
↓
[tool_use call]
↓
外部工具执行
↓
[tool_result returned]
↓
模型继续推理
↓
最终输出此循环驱动：
- AI 辅助的编码系统
- 基于数据库的助手
- 自主工作流
- CI 集成的代理
工具同时提升杠杆效应和风险。 验证：
- 工具输入
- 工具输出
- 执行边界
- 失败状态
否则系统将以自信的方式 错误地行动。
5. 安全是架构性的
大型语言模型模糊了 指令 与 数据 之间的界限。
如果 不可信内容 进入与系统规则相同的上下文空间，行为可能被操纵。
这是一种 结构性 问题，而非边缘案例。安全必须内建于循环中：
- 将系统规则与用户内容分离。
- 对检索到的文档进行清理。
- 验证工具调用。
- 包含对抗性测试案例。
- 进行红队情景演练。
如果你的代理能够行动，它就可能被 利用。请相应地进行设计。
6. AI 产品系统栈
AI 原生产品 不是 “Model + Prompt”。它是一个 分层系统。
+--------------------------------------------------+
| AI PRODUCT SYSTEM |
+--------------------------------------------------+
| 1. Prompt Specification (versioned) |
| 2. Context Architecture Map |
| 3. Retrieval Layer (memory + chunking strategy) |
| 4. Tool Layer (controlled action surface) |
| 5. Evaluation Suite (automated + human review) |
| 6. Security Layer (injection defenses) |
| 7. Iteration Loop (continuous improvement) |
+--------------------------------------------------+没有这些层，你得到的只是 demo，而不是产品。
7. Visual Checklist: AI Product Builder Kit
Use this as a founder checklist.
Day 1 — Define Success
- 用户画像
- 核心工作流（5–7 步）
- 明确的成功指标
- 已定义的失败案例
- 风险清单
Artifact: LLM Success Spec
Day 2 — Prompt Library
- 基于角色的系统提示
- Few‑shot 示例
- 反例
Samples
Output contracts
Artifact: Promptbook v1
Day 3 — Context Map
- 什么应放入系统？
- 什么被检索？
- 什么是记忆？
- 什么是动态状态？
Chunking strategy
Artifact: Context Architecture Diagram
Day 4 — Tool Loop
- 实现 2–3 个有意义的工具
- 验证输入
- 记录使用情况
- 测试失败情况
Artifact: Tooling Spec + Working Tool
Day 5 — Evaluation Suite
- 30–60 条测试用例
- 正常情况
- 边缘情况
- 对抗性案例
- 自动评分
Artifact: Eval Suite v1
Day 6 — Prototype
- AI 辅助实现
- 集成测试框架
- 最小可部署系统
Artifact: Working Prototype
Day 7 — Ship Discipline
- 完整评估运行
- 上下文清理
- 安全审查
- 版本文档
Artifact: AI Product Builder Kit v1
最终思考
- 模型访问正变得像商品一样。
- 提示技巧已成为商品。
- API 集成已成为商品。
什么不是商品：
- 评估纪律
- 上下文架构
- 安全工具集成
- 迭代速度
防御壁垒不在于谁拥有最好的模型。
而在于谁能围绕模型构建最好的系统。
那就是工程。
这就是 AI 原生公司获胜的方式。