# AI 项目开发建议

> 目标：把一个 AI 想法从“模型 Demo”推进到“有人持续使用、结果可验证、成本可接受的产品”。

## 一句话结论

**不要先选模型或框架，先选一个高频、结果可判断、人工流程确实昂贵的问题；用最小可用工作流验证价值，再逐步增加 Agent、工具和自治。**

## 1. 先判断项目值不值得做

一个值得做的 AI 项目通常同时满足：

- 用户现在已经在做这件事，而不是被教育出一个新习惯；
- 任务重复、耗时或需要跨多个系统；
- 结果有相对清晰的正确标准；
- AI 的错误可以被发现、纠正或限制；
- 节省的时间、增加的收入或降低的风险足以覆盖模型和运营成本；
- 你拥有分发、数据、工作流、领域知识或反馈闭环中的至少一项优势。

### 先问这 6 个问题

1. 谁在什么场景下遇到什么具体问题？
2. 现在不用 AI 是怎么完成的，最贵的环节是什么？
3. 用户愿意为什么结果付费或持续使用？
4. 什么叫“做对”？能不能写成测试集或验收规则？
5. 错了会造成什么损失，谁来发现和兜底？
6. 第一周能不能用 1 个模型、3 个工具以内做出可用版本？

如果前四个问题答不清楚，优先做用户访谈和人工流程拆解，不要先搭 Agent 平台。

## 2. 从工作流而不是聊天框开始

一个产品化 AI 项目最好描述成：

```text
触发条件 → 输入资料 → AI 判断/生成 → 工具行动 → 验证结果 → 人工/系统决策 → 留下记录
```

例如“研究助手”不是“一个能聊天的机器人”，而是：

```text
用户给出问题
→ 搜索并筛选来源
→ 提取证据
→ 交叉核验
→ 生成带引用的结论
→ 检查引用是否支持结论
→ 返回报告与待确认项
```

产品价值通常来自完整流程的结果，而不是模型回答本身。

## 3. MVP 的正确顺序

### 阶段 A：人工辅助原型

先用人工挑选资料、人工检查结果，验证用户是否真的需要最终产物。此阶段可以使用模拟工具和固定数据，但必须明确标注。

### 阶段 B：单模型 + 少量工具

- 只接入完成任务所需的最少工具；
- 让模型处理判断和生成；
- 让程序处理权限、状态、格式和确定性规则；
- 每一步保存输入、输出和错误。

### 阶段 C：固定工作流

把稳定步骤写成程序流程，例如提取 → 分类 → 检索 → 生成 → 校验。固定流程通常比让 Agent 自由规划更容易测试、解释和控制成本。

### 阶段 D：按需加入 Agent

只有当步骤数量、工具选择或任务路径无法预先确定时，才让模型动态规划。对自治循环设置最大步数、预算、超时和停止条件。

### 阶段 E：生产化

补齐身份、权限、审计、监控、重试、回滚、人工审批、成本控制、数据保留和故障处理。

## 4. 架构分工：模型不要承担所有责任

### 模型负责

- 语言理解与生成；
- 分类、规划和候选方案；
- 在有限工具集合中选择下一步；
- 解释不确定性和提出澄清问题。

### 程序负责

- 权限和身份；
- 金额、额度、状态机和幂等性；
- Schema 校验、格式转换和确定性计算；
- 重试、超时、回滚和审计；
- 生产环境发布和数据访问。

### 人负责

- 高风险审批；
- 目标和评价标准；
- 例外处理和最终责任；
- 定期复核模型行为与业务结果。

## 5. 数据与上下文

不要把“拥有很多资料”误认为“拥有可用数据”。优先建设：

- 清晰的数据来源和许可记录；
- 去重、版本、时间戳和来源引用；
- 与真实任务对应的输入—输出样本；
- 错误案例、边界案例和拒答案例；
- 可检索、可更新、可删除的数据结构；
- 让模型能按需获取信息，而不是每次加载整个知识库。

对长任务，把长期规则、用户偏好、当前进度、证据和临时草稿分开存储。不要把所有东西堆在一个无限增长的对话里。

## 6. 评估先于优化

### 建立最小评估集

第一版不需要几千条数据，但要覆盖：

- 10–30 个正常任务；
- 5–10 个边界任务；
- 典型失败和恶意输入；
- 高成本、超时和工具失败情况；
- 需要人工升级的任务。

### 至少测这些指标

- 任务成功率；
- 关键事实或字段准确率；
- 引用/证据支持率；
- 工具调用正确率；
- 人工接管率；
- 平均成本和 P95 成本；
- 平均延迟和 P95 延迟；
- 重试率、失败率和安全违规率；
- 用户是否继续使用或完成后续动作。

### 评估顺序

```text
先看最终结果
→ 再看工具调用和中间步骤
→ 找到最常见失败模式
→ 修改提示/工具/流程
→ 重新跑同一批任务
```

不要只用一条漂亮 Demo 判断项目成功，也不要只追求模型 benchmark 分数。

## 7. 工具与集成设计

每个工具都应该明确：

- 什么时候使用；
- 输入参数和示例；
- 输出结构；
- 权限范围；
- 成本和延迟；
- 失败方式；
- 是否有副作用；
- 是否支持幂等、撤销或预览。

读工具与写工具分开。搜索、读取、草拟可以自动执行；发送、发布、付款、删除、改权限默认进入审批流。

## 8. 什么时候做多 Agent

只有在以下情况出现时才拆多 Agent：

- 不同角色需要不同工具或权限；
- 不同任务需要不同专业指令和评价标准；
- 子任务真正可以并行；
- 单 Agent 上下文已经难以维护；
- 需要明确的 handoff 和责任边界。

不要为了“看起来先进”而拆多个 Agent。多 Agent 会增加协调成本、延迟、状态同步、错误传播和调试难度。

## 9. 安全与可靠性基线

涉及外部系统时，至少准备：

- 最小权限和工具白名单；
- 沙盒或隔离运行环境；
- 网络 allowlist；
- 单次和每日预算；
- 最大执行步数；
- 超时、重试和熔断；
- 人工审批点；
- 全链路日志和审计记录；
- 敏感数据脱敏、保留和删除策略；
- 回滚或补偿流程。

AI 系统的“可解释”不等于模型写了一段解释。更重要的是：能查到它看了什么、调用了什么、改变了什么，以及结果如何被验证。

## 10. 成本控制

成本优化顺序建议是：

1. 减少无效任务和无意义的 Agent loop；
2. 缩短上下文，按需检索；
3. 使用缓存和结构化中间结果；
4. 简单任务路由到更便宜模型；
5. 对昂贵工具和深度推理设置预算；
6. 最后才考虑模型微调或更复杂的基础设施。

每个任务记录 token、工具调用数、重试数、耗时和最终成本。没有成本数据，就无法判断产品是否能规模化。

## 11. 生产发布检查清单

### 产品

- [ ] 用户和触发场景明确
- [ ] 结果价值可以被用户感知
- [ ] 失败时有可用的人工或备用流程
- [ ] 用户知道 Agent 能做什么、不能做什么

### 工程

- [ ] 工具权限最小化
- [ ] 状态和任务可恢复
- [ ] 重试不会造成重复副作用
- [ ] 有超时、限额、日志和告警
- [ ] 有测试数据和回归评估

### 安全

- [ ] 敏感操作需要审批
- [ ] 外部输入不会直接覆盖系统指令
- [ ] 沙盒和网络访问已限制
- [ ] 关键数据有脱敏和删除策略
- [ ] 可追溯每次 Agent 执行

### 运营

- [ ] 监控成功率、成本、延迟和人工接管率
- [ ] 有用户反馈入口
- [ ] 有版本回滚方案
- [ ] 有模型、工具和提示变更记录

## 12. 最小可行项目模板

```text
项目名称：
目标用户：
高频任务：
现有人工流程：
AI 负责：
程序负责：
第一版只允许使用的工具：
成功标准：
必须人工审批的动作：
评估集规模：
单任务成本上限：
上线前验证方式：
失败后的备用流程：
```

## 推荐阅读来源

- Anthropic — Building effective agents：<https://www.anthropic.com/engineering/building-effective-agents>
- Anthropic — Effective context engineering：<https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents>
- OpenAI — A Practical Guide to Building Agents：<https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf>
- OpenAI — Evaluate agent workflows：<https://developers.openai.com/api/docs/guides/agent-evals>
- Google — Agent Development Kit：<https://adk.dev/>
- Microsoft — AI agent orchestration patterns：<https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns>
- Cursor — Scaling long-running autonomous coding：<https://cursor.com/blog/scaling-agents>

## 最后判断

一个 AI 项目真正的护城河通常不是“接了哪个模型”，而是：

- 对真实工作流的深度理解；
- 高质量任务数据和评估集；
- 可验证的结果与来源；
- 与业务系统的集成；
- 权限、审计、反馈和持续改进闭环；
- 用户愿意反复使用的分发场景。
