AI 原生应用开发方法

这套方法适合把 AI 当作产品主循环的一部分来设计，而不是只在传统应用外层接一个聊天入口。目标是让自然交互、可读产物和连续上下文成为默认路径。

适用场景

当你的应用需要处理以下事情时，优先使用这套方法：

• 用户希望先得到自然语言结果，再决定是否进入结构化操作
• 结果本身需要被人阅读、编辑、复核或转交
• 推理过程需要跨轮次持续，而不是一次性吐出答案
• 只有一小部分边界必须严格结构化，例如工具调用、存储、鉴权或外部 API
• 你需要在“文本工作流”和“程序边界”之间做清晰分层

核心判断

先问四个问题：

1. 用户真正要看到的主产物是什么？
2. 哪些部分必须由程序严格控制？
3. 哪些内容只要对人有用、对模型可继续工作，就不必强制成 schema？
4. 结构化失败时，主体验还能不能继续交付？

默认答案通常是：

• 主产物优先是自然回答、草稿、计划、摘要、复盘或报告
• 严格 schema 只放在硬程序边界上
• 结构化 sidecar 失败不应阻断主体验
• 工具边界可以结构化，但不必把整个工作流都结构化

默认架构

推荐把系统拆成三层：

1. 用户层：自然交互，输出对人可读的内容。
2. 工作层：承载推理、草稿、证据、待办和修订痕迹。
3. 边界层：工具调用、存储、鉴权、外部 API、审计等严格结构化接口。

默认流程是：先生成用户可读内容，再把必要的状态放进工作层，最后只在边界层使用严格 schema。

Context Window Framework

Context Window Framework 的重点不是“压缩成一个大对象”，而是把上下文组织成可选择、可排序、可复用的块。

常见块可以包括：

• conversation：最近对话
• working_notes：当前判断、假设、不确定点、下一步
• evidence：资料、来源、引用、检索结果
• constraints：规则、限制、目标、偏好
• tool_results：工具返回值、解析结果、外部数据
• memory：长期偏好、历史结论、项目事实
• review：修订记录、已确认结论、被推翻的判断

每个块都应带上最少但足够的元数据，例如来源、时间、可信度、相关性和是否过期。这样系统才能决定保留什么、丢弃什么、重新注入什么。

硬边界结构化

严格 schema 只在这些地方是必要的：

• 工具调用
• 搜索或检索查询
• 外部 API 输入输出
• 存储 ID 和引用
• 审计或可机读记录
• 需要明确校验的权限、状态或约束

不必强制结构化的地方：

• 面向用户的主回答
• 推理说明
• 假设讨论
• 自我修正
• 工作草稿
• 复盘叙述

关键原则是：结构化可以增强可靠性，但不应把模型可继续工作的文本流切断。sidecar 失败时，只要不触碰硬边界，主流程仍然应该把可读产物交付给用户。

工作文档

当模型需要持续推进任务时，优先使用 LLM 友好的 Markdown 或 YAML 工作文档，而不是脆弱的程序对象。

示例：

answer: |
  面向用户的简短输出。

current_view:
  conclusion: 当前最可能的判断
  uncertainty: 还未确认的点

next_steps:
  - 下一步检查
  - 需要查证的证据

constraints:
  - 必须满足的限制

evidence:
  - source: 来源或链接
    note: 摘要或短引文

把它当作工作文档，而不是稳定 API 契约。它的价值在于让模型继续思考、让人可以检查、让后续轮次可以接着做。

开发流程

实现 AI 原生功能时，按这个顺序推进：

1. 先定义用户可见的主产物。
2. 再划出硬程序边界。
3. 决定哪些内容必须结构化，哪些保持文本即可。
4. 设计上下文块、排序规则和保留预算。
5. 定义失败路径，尤其是工具失败、解析失败、置信度低和结构化失败。
6. 用真实用户场景写测试，而不是只测理想输入。

验收清单

交付前，检查这些问题：

• 主产物是不是自然、可读、可直接使用？
• 严格 schema 是否只出现在真正的程序边界？
• 工作文档能不能让模型继续推进下一轮？
• Context Window Framework 有没有明确的块、元数据和选择规则？
• sidecar 或结构化解析失败时，主体验是否还能继续？
• 工具边界是否清晰、可校验、可追踪？
• 测试是否覆盖真实用户场景，而不是只覆盖内部实现细节？