每份修改计划末尾必须生成Markdown格式的检查表，含且仅含四项：【影响范围】定位…扫描…、【兼容性】确认…是否仍能…、【回滚路径】执行哪条SQL/命令/Git commit哈希、【验证方式】断言…或curl -I返回200等可执行指令，缺一不可。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让DeepSeek在每次生成代码修改计划时，自动附带一份可逐项核对的检查表，确保修改覆盖所有必要环节，避免遗漏关键步骤或副作用。
明确检查表结构要求
在提示词开头直接定义检查表必须包含的四大维度：【影响范围】、【兼容性】、【回滚路径】、【验证方式】。这四个字段缺一不可，否则DeepSeek会默认只输出笼统的“测试一下”这类无效描述。
告诉模型：“每份修改计划末尾必须生成一个Markdown格式的检查表，用- 开头的无序列表，每项以【字段名】冒号起始，后面接具体、可执行的动作。”
绑定检查项与具体代码行为
方法一：用动词锚定动作类型
在提示词中为每个字段指定强制动词——【影响范围】必须用“定位…”开头，“扫描…”结尾；【兼容性】必须含“确认…是否仍能…”句式；【回滚路径】必须写明“执行哪条SQL/哪段命令/哪个Git commit哈希”；【验证方式】必须出现“断言…”或“curl -I 返回200”等真实终端指令。
方法二：给字段加最小颗粒度约束
例如：【验证方式】下至少列出1个单元测试用例名称（如test_user_login_with_expired_token）、1个API端点（如POST /v2/auth/refresh）、1个数据库校验语句（如SELECT COUNT(*) FROM audit_log WHERE action='role_update'）。
强制嵌入检查表生成触发机制
第一步：在提示词末尾添加固定指令：“请严格按以下三步输出：① 修改计划正文；② 空一行；③ 检查表（仅含4项，不加标题，不编号，不换行）。”
第二步：追加一句硬性限制：“若未生成检查表，或检查表项数≠4，或任意一项未包含可执行动作，则整份输出视为无效，需重新生成。”
第三步：提供一个正确示例片段（仅1行），如：- 【影响范围】：定位调用链中所有含cache_key前缀的get_user_by_id()调用 → 扫描service/user.go与api/v1/handler.go两处。
这一步最关键：DeepSeek依赖显式结构信号触发格式化输出，纯自然语言描述“请附检查表”大概率被忽略。
