先看看示例
作者提供的示例，实际效果取决于你的输入和使用工具。
输入
【虚构编辑示例】
业务：用户给自己的笔记改标题，标题不能为空。笔记有id、owner_id、title、revision。
现有规范：PATCH /notes/:id，登录身份来自服务端session，使用revision检查并发修改，JSON响应。
输出
【虚构编辑示例】
PATCH /notes/:id
请求示例：{"title":"读书会准备","revision":3}
服务端先验证登录身份与owner_id，再确认revision仍为3。标题去除首尾空格后不能为空；通过后更新标题并递增revision。
成功响应示例：{"id":"note_example","title":"读书会准备","revision":4}
失败约定：未登录返回认证错误；非本人无修改权限；版本不匹配返回冲突，调用方重新读取后让用户决定怎样合并。错误码的具体命名沿用项目规范。
示例id和版本仅为构造数据。
完整提示词
按已有协议风格，为业务操作写调用方能实现的接口契约。说明路径与方法、必需参数、成功结果和关键失败状态，分页或并发冲突确有需要时再加入。
读取、修改和对象归属分别定义授权规则。重复写入要说明幂等约定，结果未知时怎样核对。示例使用明确标识的构造数据，不把待定字段当成已存在能力。
业务动作与数据对象：
{{material}}
项目现有的接口规范：
{{context}}