在一次成功的交互之后，人工智能支持演示可能看起来已经完整：一条消息到达，模型选择一个工具，然后出现一个精心修饰的答案。
令人不安的工程问题随即出现：
你会让它把那个答案发送给真实用户吗？
这种张力并非表明你落后了。它体现了展示模型能力与承担生产决策责任之间的区别。
模型可以分类文本、提取结构并起草看似合理的回复。但这些能力都无法证明回复是正确、经授权、安全或与你当前产品一致的。因此，有价值的工程工作并不是让模型显得更加独立，而是决定独立性必须在何处停止。
在本教程中，我们将构建一个具有刻意限制辅助功能的 Node.js 支持工作流：
- 用户提交一条支持消息。
- 应用程序存储原始消息。
- 模型提议一个类别、紧急程度和草稿。
- 确定性策略检查标记敏感案例。
- 人工编辑、批准或拒绝该提议。
- 只有经批准的文本才会进入交付适配器。
- 当提示词或模型发生变化时，可以重放保存的示例。
助手可以提议，但不能发送。
在编写提示词之前定义边界
一个支持系统至少包含三种类型的决策：
| 决策 | 适合人工智能辅助？ | 最终权威 |
|---|---|---|
| 总结长消息 | 通常适合 | 模型输出，按需审查 |
| 建议队列或类别 | 通常适合 | 应用程序策略或审查员 |
| 决定用户是否有权获得退款 | 不适合 | 授权人员或计费系统 |
| 确认数据已删除 | 不适合 | 经验证的后端操作 |
| 披露安全细节 | 不适合 | 安全策略和授权人员 |
| 起草友好的解释 | 通常适合 | 人工审查员 |
| 发送解释 | 在此设计中不适合 | 人工批准关卡 |
这种区分防止了一种常见的类别错误：流畅性不等于权威性。
我们将在代码中强制执行三个不变量，而不是要求模型记住它们：
- 提议不能直接转换为
已发送状态。 - 隐私、安全、计费和账户访问消息始终被标记为敏感。
- 原始请求、提议、提示词版本、模型标识符和最终回复保持可区分。
设置项目
使用 Node.js 20 或更高版本，以便使用内置的 fetch 应用程序接口。
mkdir bounded-support-assistant
cd bounded-support-assistant
npm init -y
npm install express better-sqlite3 zod
mkdir src
在 package.json 中添加模块支持和脚本：
{
"type": "module",
"scripts": {免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
