Cursor写事故改进项提示词如何保留有效信息

【每条改进项必须含明确动作动词、责任角色、截止时间（2026-07-25格式）、验证方式】；禁用模糊动词与抽象名词，绑定具体字段、数值及接口契约；明确上下游责任断点，验证方式+时间锚点+交付物格式三行连续固化。

你需要在Cursor中生成事故改进项清单，但每次输出都遗漏关键动作主体、交付时限、验证方式等可执行要素，导致改进计划无法落地或责任不清。

用结构化锚点锁定改进项三要素

第一步：在提示词开头用【】包裹不可协商的硬性条件。例如：【每条改进项必须含明确动作动词（如“上线”“修订”“接入”）、责任角色（如SRE组/支付团队）、截止时间（精确到日，格式2026-07-25）、验证方式（如“通过压测报告截图确认”）】。Cursor会将方括号内内容识别为高优先级指令，不参与摘要压缩，避免把“接入熔断”压缩成“加强稳定性”。

第二步：对易被泛化的动词强制绑定执行粒度。比如不能只写“优化超时配置”，要写成“将订单服务调用风控服务的Feign超时从3s→8s，并同步更新application.yml中feign.client.config.default.connectTimeout字段”。【模糊动词+无字段名+无数值变更，Cursor默认按通用建议填充，常填错配置路径或单位】。

第三步：禁用抽象名词替代可执行动作。删掉“提升意识”“完善机制”“加强协同”这类表述——它们无法被验收，Cursor会自动补全虚构动作，如“组织三次跨部门培训”，而你实际只需要一条配置变更。

保留上下游系统对接细节

方法一：直接粘贴原始事故报告中的接口契约片段
把事故中暴露问题的API调用原文复制进来。例如：“POST /v2/order/confirm → 调用库存中心 /api/inventory/deduct 接口，超时阈值当前为1500ms，下游返回code=503时未触发降级”。这比写“修复库存接口超时”更可靠，Cursor能据此生成带fallback逻辑的代码段。

方法二：用「→」符号显式标记数据流向与责任断点
写成“用户下单请求 → 网关Nginx → 订单服务 → 库存服务 → 数据库”。并在断点后加括号标注责任方：“库存服务（由仓储平台组维护）→ 数据库（DBA团队负责容量扩容）”。不写清这个归属链，Cursor可能把扩容动作错误分配给开发团队。

【禁止用‘相关方’‘有关部门’等模糊称谓描述责任主体——Cursor会按字面概率采样，可能生成‘由架构委员会审批’这种无法执行的条款】。

固化验证闭环与时间锚点

① 在提示词末尾固定一行验证要求：“每条改进项末尾必须附验证方式，格式为‘验证：[具体操作]+[预期结果]’，例如‘验证：查看2026-07-20后Kibana中inventory.deduct.timeout.error指标下降90%’。”

② 紧接着写时间锚点：“所有截止时间必须基于事故发现时间（2026-07-12 14:33）向后推算，短期项≤3工作日，中期项≤10工作日，长期项需标注季度目标。”

③ 最后加一句交付物约束：“输出仅允许为纯文本列表，每行一条改进项，禁止编号、禁止表格、禁止加粗，首字母小写，动词开头。” 这三行必须连续出现，Cursor会将其合并为一个验证上下文块。