如何明确需求并检查 AI 构建的客户需求应用

客户需求应用的起点很简单：让客户告诉你需要什么，再给团队一个统一的位置查看这些需求。

要让它实际可用，表单需要保存提交内容、说明哪些字段未填写，并把员工查看页面限制在合适的人员范围内。

通过 Leina 的应用构建，可以用对话创建包含后端逻辑和数据库存储的全栈 Web 应用。先参考下面的需求准备第一版，再检查实际行为，然后交给真实用户。

明确第一版的最小范围

用 AI 生成应用时，可以先做一个便于核对的小版本，再逐步增加通知、CRM 同步、附件和优先级标签等功能。

组成部分	第一版需要具备什么	暂时不加入什么
公开表单	客户姓名、需求详情和必填校验	文件附件和多步骤表单
数据库	持久保存记录，并自动记录提交时间	自动优先级评分或 AI 情感标签
员工页面	只读查看已提交记录，按最新优先排序	CRM 双向同步和自动回复邮件
反馈	确认数据库写入成功后才显示成功提示	数据库确认前提前显示成功状态

同时明确谁可以查看每个页面。这个示例中，访客提交需求，获授权的员工读取记录。询问 Leina 能怎样实现这种分工，并核对实际能力；这里列出的是待验证的需求。

提供可以观察和核验的需求

可以在 Leina 应用构建中复制并调整下面的请求：

构建一个客户需求 Web 应用，提供两个不同的页面：

公开需求表单：

字段为“客户姓名”和“需求详情”，两项都必填。

在客户端和服务端校验输入；空内容或只有空格时，拒绝提交并显示字段错误。

确认记录已经写入数据库后，才显示成功提示。

员工查看页面：

用清晰的表格或列表显示所有已提交需求，最新记录排在前面。

显示客户姓名、提交时间和完整需求内容。

访问控制：

所有公开访客都能访问提交表单。

员工查看页面仅允许已登录并获授权的团队成员访问。

说明这两个页面可用的访问控制方式，并标明无法实现的要求。开发过程中使用虚构的测试记录。发布前，先准备好供我检查的版本。

完成四项基础验收

在测试应用中完成下面四项检查。它们可以发现第一版中常见的问题；实际使用前，还应根据目标场景继续检查访问和数据处理方式。

1. 追踪一条提交记录的存储位置

提交一条便于识别的内容，例如“测试：增加每周摘要功能”。在员工页面检查字段，刷新页面，再从后端存储或另一个已授权浏览器会话中查找同一条记录。

刷新后仍显示记录只是初步检查：localStorage 这样的浏览器存储也会在刷新后保留数据。检查实际保存的记录，才能确认数据写到了哪里。无法检查存储时，把这一项标为待确认。再提交第二条需求，确认第一条没有被修改。

2. 空内容提交检查

尝试不填写字段，或仅输入空格后提交。

预期行为： 表单指出缺失字段、阻止提交，并且数据库中没有新增空白记录。

3. 多行内容与特殊字符检查

提交包含换行、项目符号、引号以及 &、<、# 等字符的需求。检查员工页面能否保留格式，是否出现乱码或转义错误。

4. 无痕窗口访问检查

复制员工页面 URL，在没有登录的隐私或无痕浏览窗口中打开。

预期行为： 应用要求登录或拒绝访问。也要测试一个已经登录、但没有员工查看权限的账号。页面被隐藏或显示登录界面，并不能单独证明底层数据请求受到保护。如果所需限制尚未实现，应继续使用虚构数据，直到问题解决。

用客户需求应用检查清单记录实际观察。

每次修正一种行为

发现问题时，给出具体、范围清楚的修正要求：

提交空需求时，表单没有保存记录却显示成功。请改为在字段旁显示必填错误，保持正常提交可用，并保留已有测试记录。

每次修正后，同时验证错误路径和正常提交，检查是否影响了原本正常的行为。

发布并逐步投入使用

完成检查，并确认应用适合目标用户后：

整理测试数据： 识别并移除自己为测试创建的虚构记录。
核对访问： 使用应用实际提供的控制方式，验证谁可以提交、谁可以读取已保存记录。
发布并验证： 在 My Apps 中找到应用，按可用的发布流程操作。在发布后的版本中再次检查提交与访问，再分享表单链接。

指定负责查看新需求的人，保留尚未解决的限制。团队使用小版本、明确下一步需要之后，再增加功能。