夜雨聆风我的AI学习笔记 002
围绕一个系统产品，对任务进行目标、上下文、工具、记忆、权限、兜底和验收闭环的全流程设计。
这两天我用 AI Coding 做了一个小项目：基于 DeepSeek API 的 Web 端 Chatbox。
项目本身不复杂：能聊天、支持流式输出、能渲染 Markdown、有历史会话、可以切换明暗主题、接入 Supabase 登录和云端存储，最后部署到 EdgeOne。
但做完之后，我反而觉得这个案例最有价值的地方，不是“做了一个聊天应用”，而是它很完整地走了一遍智能体应用的设计过程。
这件事到底要交付什么结果？
AI 需要哪些上下文？它能调用哪些工具？
哪些状态需要被记住？什么时候必须让人确认？结果如何验收？
这些问题想不清楚，AI应用的能力就要打折。
1. 起点不是模型，而是任务边界
一开始，我给 AI 的需求不是一句“帮我做一个聊天软件”，而是把目标、功能、约束、技术栈、界面风格和验收标准写清楚。
功能边界：首页就是对话页，输入框只支持文本，输出要流式返回并支持 Markdown 表格和代码块。
状态边界：侧边栏管理历史会话，支持新建、切换、删除，删除前需要二次确认。
上下文边界：每次请求只携带当前会话最近 20 条历史消息。
体验边界：PC 和移动端都要能用，主题色清晰，图标使用 lucide，不使用表情图标。
这里面有一个很关键的产品习惯：不要只描述愿望，要描述边界。
“做一个 AI 聊天应用”是愿望。
“输入是什么、输出是什么、状态在哪里、异常怎么处理、用什么技术栈、验收到什么程度”才是边界。
我现在比较推荐用这个结构写第一版需求：
目标：这个应用最终要解决什么问题
用户：谁在什么场景下使用
输入：用户或系统会给 AI 什么信息
输出：AI 需要返回什么结果
功能：页面、流程、交互、状态
约束：技术、性能、安全、权限、风格
上下文：参考文档、接口文档、业务规则
验收标准：怎样算真的完成
这套结构看似朴素，但它能把一个模糊想法变成 AI 可以执行的任务。
2. 从 Chatbot 到 Agent，差别在“有没有工作环境”
第一版 Chatbox 只是一个 Chatbot：用户输入文本，模型返回答案。但随着功能往后做，它开始具备一点 Agent 应用的雏形。
接入 DeepSeek API 后，它有了模型能力。
支持历史会话 后，它有了短期上下文。
会话保存在 localStorage 后，它有了本地记忆。
接入 Supabase 登录 后，它有了身份系统。
会话数据同步到数据库 后，它有了跨设备长期记忆。
部署到 EdgeOne 后，它从本地实验变成了可访问的线上应用。
这个过程给我的启发是：Agent 不是一个孤立的“聪明大脑”，而是一个被放进工作环境里的执行者。
任务目标：它要完成什么。
上下文：它依据什么信息判断。
工具：它可以调用哪些外部能力。
记忆：哪些信息需要跨会话保留。
身份：它代表谁执行。
权限：它能做什么，不能做什么。
反馈：结果如何被用户确认和纠正。
如果只接一个模型，那是 Chatbot。如果模型能理解任务、读取上下文、调用工具、保存状态、按权限行动，并且能接受人类反馈，它才更接近智能体应用。
3. 智能体应用设计，要先拆“状态”
这次 Chatbox 项目里，我最有感触的是“状态”的变化。
第一阶段，会话数据保存在浏览器本地。这个设计很适合原型验证，因为它简单、快、不需要后端。但它有一个明显问题：换浏览器、换电脑、清缓存，历史会话就没了。
于是第四阶段改成 Supabase 云端存储：会话表、消息表、用户 ID 绑定、页面加载时从数据库读取，新建会话、发送消息、删除会话都同步到数据库。
这一步看起来是技术改造，本质上是产品状态设计升级。一个智能体应用里，至少要想清楚四类状态：
临时状态：输入框内容、侧边栏是否展开、弹窗是否打开。刷新后丢了也没关系。
会话状态：当前对话上下文、最近 20 条消息、正在生成的回复。它决定 AI 此刻如何理解用户。
长期记忆：用户历史会话、偏好设置、常用模板、业务对象记录。它影响下一次使用体验。
业务状态：订单是否已审核、客户是否已跟进、工单是否已关闭。这类状态必须有权限、日志和人工兜底。
很多 AI 产品不好用，不是模型不够聪明，而是状态没有设计清楚。用户以为 AI 记住了，其实它没记住；用户以为 AI 已经保存了，其实只存在前端缓存；用户以为 AI 已经执行了，其实只是生成了一段建议。
4. 人机协同的关键，是“确认点”
在 Chatbox 里，有一个很小但重要的交互：删除会话需要二次确认。这不是为了显得严谨，而是因为删除属于不可轻易撤销的操作。
把这个逻辑放到更复杂的智能体应用里也一样：凡是会影响真实业务状态、资金、客户、权限、数据删除的动作，都应该有确认点。
AI 先完成初筛；
用户看到判断理由；
低风险动作可以批量处理；
高风险动作需要人工确认；
所有操作都写入日志；
人可以修改 AI 结果，修改会反哺规则或提示词。
不要急着追求“全自动”，先设计“可确认的自动化”。全自动听起来更酷，但可确认、可追溯、可纠偏，才更容易进入真实业务。
5. 一个可复用的智能体应用设计框架
结合这次 Chatbox 项目，我把智能体应用设计拆成 8 个问题。
第一，用户目标是什么？不是“用户想用 AI”，而是用户原本要完成什么任务。
第二，输入从哪里来？用户手动输入、上传文件、连接数据库、读取接口、搜索网页，输入来源决定上下文质量。
第三，AI 要输出什么？自然语言建议、结构化 JSON、可执行代码、审批结论、报告文档，还是直接调用业务系统。
第四，工作流是否稳定？步骤固定适合工作流；路径需要探索适合 Agent；只是问答，Chatbot 可能就够了。
第五，上下文是否稳定？上下文固定可用规则和模板；上下文分散则需要知识库、检索、数据库和权限控制。
第六，哪些状态要保存？哪些只在页面，哪些跨会话，哪些进数据库，哪些写入业务系统。
第七，哪些动作需要人确认？查询和草稿生成可以更自动；删除、审批、付款、发消息、改配置要有确认和留痕。
第八，怎样验收？不要只验收能不能跑，还要验收准确性、稳定性、异常提示、权限边界、移动端体验和跨设备一致性。
这 8 个问题，其实就是把 Agent 从“概念”拉回“产品”的过程。
6. 提示词要像 PRD，也要像验收单
这次项目能够一轮轮推进，一个关键原因是每一阶段都把需求写成了可执行任务。
第一阶段：基础聊天跑通。验证最小闭环：用户能输入，AI 能流式回复，Markdown 能渲染，会话能创建、切换、删除。
第二阶段：功能迭代。只增加主题切换功能，并明确“切换后刷新页面仍然保留”。
第三阶段：登录认证。增加登录页、邮箱密码校验、Supabase Auth、登录态保持、未登录重定向、退出登录。
第四阶段：数据持久化。把 localStorage 里的会话和消息迁到 Supabase，绑定当前用户，实现跨设备同步。
第五阶段：部署上线。构建项目，部署到 EdgeOne，拿到公网 URL，再用手机和浏览器验证。
一个智能体应用也可以这样拆：
第一层：能对话，能给出结果
第二层：能记住当前任务上下文
第三层：能接入真实数据源
第四层：能调用工具完成动作
第五层：能保存长期状态
第六层：能进入权限、日志和人工兜底体系
第七层：能部署给真实用户持续使用
很多项目失败，不是因为最后一层做不好，而是第一层还没闭环，就想直接做第六层、第七层。
7. 产品经理的设计对象变了
过去做产品，产品经理更多关注页面、流程、字段、规则、权限。这些仍然重要，但智能体应用多了一层新的设计对象：AI 的工作方式。
你需要设计它看到什么、记住什么、调用什么、什么时候停下来问人、什么时候继续往下做、失败时怎么解释。
智能体应用设计的核心，不是“让 AI 回答得更好”，而是“让 AI 在一个被设计好的工作环境里，稳定完成一件有业务价值的事”。
模型能力决定上限。产品设计决定它能不能真的进入业务。
结尾
我越来越觉得，产品经理学习 AI，不应该只停留在体验各种工具，也不应该一上来就追最复杂的 Agent 框架。
更好的方式，是从一个小应用开始，完整走一遍：
想法如何变成需求；
需求如何变成可执行提示词；
提示词如何驱动 AI Coding；
原型如何接入身份、数据和部署；
最后如何变成一个可验证、可迭代、可上线的产品。
这条路走一遍，对 Agent 的理解会比看十篇概念文章更扎实。
因为你会亲手看到：AI 应用真正难的地方，往往不在“AI”，而在“应用”。
