答案是：删除模糊指令，用编号①②③明确限定输出；用标签或行号锚定日志范围；将开放式动词替换为闭环动作词并规定硬性格式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在Cursor里写日志分析提示词时，模型输出的结论东一块西一块，没有聚焦核心问题，根本没法直接用于排查或汇报。
先锁定日志分析的真实目标
打开你正在写的提示词文件，把开头那句“请分析以下日志”删掉——这句话本身不带任何判断标准，模型只能按自己理解的“分析”自由发挥。
在原位置换上明确指令：【只回答三个问题：错误发生在哪一行？根本原因是什么？修复动作具体到命令或代码行】。这三个问题必须用编号①②③严格列出，不能合并、不能加“可能”“建议”等模糊词。
这一步做完后，模型输出会立刻收束——它不再需要猜测你要什么，而是被强制进入结构化应答路径。
用日志片段锚定上下文范围
方法一：把原始日志截成三段粘贴，每段前加标签：[ERROR]、[CONTEXT]、[TRACE]。只保留报错行本身、报错前2行、报错后3行堆栈。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
方法二：在提示词里写死行号约束：“请严格基于第17–22行内容作答，超出此范围的推断视为无效”。Cursor会据此过滤无关信息，避免模型从日志末尾突然扯出一个“内存泄漏”的臆测结论。
注意：不要粘贴整段Nginx access.log或K8s event list——模型看到几百行就会自动找“规律”，反而编造关联性。
禁用开放式动词，替换为闭环动作词
第一步：搜索你提示词里所有“分析”“查看”“检查”“思考”“考虑”类动词，全部删除。
第二步：替换成“提取”“定位”“比对”“验证”“输出”——这些动词自带结果导向。例如把“请分析服务启动失败原因”改成“请提取systemctl status输出中Exit code非0的行，并比对journalctl -u xxx.service -n 20中最近一条ERROR级日志的timestamp是否匹配”。
第三步：在每条指令末尾加硬性格式要求，如“输出格式：【行号】+【原因短语】+【执行命令】，三项用｜分隔，不换行，不加标点”。
