feat:意图识别优化
This commit is contained in:
@@ -14,15 +14,19 @@ REQUIREMENT_SYSTEM_PROMPT = f"""你负责结合上下文,将用户本次的大
|
||||
2. 结合历史会话和本次澄清记录,理解“这个”“它”“刚才那个”等指代
|
||||
3. 将需求改写为独立完整的 goal,保留目标、操作和约束,不扩大修改范围
|
||||
4. 用户后续明确补充或纠正的内容优先,保留仍适用的约束,不重复执行历史中已经完成的操作
|
||||
5. 提供“用户已同意的提议”时,用户本次的回答就是同意执行这条提议,以它作为本次需求
|
||||
|
||||
## 变更提取
|
||||
1. 将本次变更写入 changes,保留相对变化与单位
|
||||
operation 取值:{OPERATION_GUIDE}
|
||||
2. 已有组件使用当前大屏中的真实 ID,无法确定目标时标记 unresolved,不猜测目标
|
||||
operation 取值:{OPERATION_GUIDE}
|
||||
2. 已有组件使用当前大屏中的真实 ID;无法唯一确定目标时标记 unresolved,
|
||||
并在 candidate_ids 中列出当前大屏里所有可能是该目标的组件 ID,没有可能的组件时留空
|
||||
按用户的原话理解操作,不猜测目标,也不因目标不存在而改写成新增等其他操作
|
||||
3. 默认先执行:能用合理默认值补齐的信息,写入 assumptions 后继续,不要求澄清
|
||||
4. 新增组件时,位置、尺寸、标题、样式、数据来源均不阻塞,由后续规划采用默认值,用户之后可再次提出调整
|
||||
{DATA_BINDING_GUIDE}
|
||||
5. 只有两类情况才澄清:修改、移动或删除已有组件时无法唯一确定目标;意图本身不明确
|
||||
{DATA_BINDING_GUIDE}
|
||||
5. 存在 unresolved 目标,或无法提取任何变更时,needs_clarification 为 true 并给出问题;
|
||||
最终执行、追问还是直接告知用户,由系统根据 changes 和 candidate_ids 决定
|
||||
|
||||
## 输出边界
|
||||
按照 Requirement 结构输出,不生成执行动作
|
||||
@@ -55,7 +59,11 @@ REQUIREMENT_INPUT_TEMPLATE = """历史会话:
|
||||
|
||||
|
||||
def build_requirement_input(
|
||||
context: InputContext, intent: Intent, *, history_text: str | None = None
|
||||
context: InputContext,
|
||||
intent: Intent,
|
||||
*,
|
||||
history_text: str | None = None,
|
||||
accepted_offer: str | None = None,
|
||||
) -> str:
|
||||
"""整理本次模型输入,历史会话默认取输入上下文中由服务端写入的记录"""
|
||||
data = context.model_dump(mode="json", exclude_unset=True)
|
||||
@@ -74,6 +82,8 @@ def build_requirement_input(
|
||||
context_json=json.dumps(data.pop("context", {}), ensure_ascii=False),
|
||||
attachments_json=json.dumps(data.pop("attachments", []), ensure_ascii=False),
|
||||
)
|
||||
if accepted_offer:
|
||||
content += f"\n用户已同意的提议:\n{accepted_offer}\n"
|
||||
# 保留扩展字段,避免拆分模板时丢失额外输入
|
||||
if data:
|
||||
content += "\n补充上下文:\n" + json.dumps(data, ensure_ascii=False)
|
||||
|
||||
Reference in New Issue
Block a user