#怎么提需求

先告诉 AI Agent 你要完成什么业务，再补充规则和结果。文件怎么组织、接口怎么实现，可以让它读取当前项目后提出方案。

#从一次具体操作说起

「做一个订单系统」太宽泛。列表里有什么、谁能修改、何时算完成，都需要 AI Agent 猜。把第一轮缩小，会更容易得到可检查的结果。

回头看第一个功能里的那段需求：它说清楚了入口（从菜单进入订单列表）、数据（订单号、客户名称、金额）、操作（新增、编辑）、限制（金额非负、订单号唯一）、范围（先不做审批和通知）和完成标准（刷新后数据仍在）。AI Agent 有空间按项目约定实现，你也有依据检查。新的需求可以照着这几项来写。

#把影响结果的规则补齐

不需要一开始就写很长的需求文档。先补充会改变行为的几类信息：

「只有自己能看」需要进一步说明“自己”指创建人、负责人还是所属部门。遇到不确定的规则，让 AI Agent 先列出问题，确认后再实现。

#给一个正常例子和一个失败例子

例子能让同一句规则少一些歧义：

比如，ORD-001 的客户是青禾商贸，金额是 1280 元，应能保存。
再次新增 ORD-001 时应提示重复，不创建第二条。
输入 -1 元时应拒绝保存，并说明金额不能为负数。

界面有明确要求时，可以补充参考图或说明按钮、字段顺序。没有要求的地方，让 AI Agent 沿用项目现有风格，避免每一页都重新设计。

#修改现有功能时说明要保留什么

订单列表已经可以新增和编辑。
这次只增加按客户名称搜索，保留现有字段、入口和保存行为。
清空搜索后显示全部当前有权访问的订单。
完成后重新检查新增和编辑没有受到影响。

告诉它当前状态，比反复发送最初的整套需求更容易控制改动范围。

#让它带着验证结果交付

可以在需求末尾加一句：

完成后列出改动文件、实际执行的检查和结果。
没有验证到的部分单独说明；检查失败时先解释原因，不要跳过。

接下来按检查 AI Agent 的产出实际操作；较大的需求先参考做复杂功能拆分。