动词开头写法是什么
动词开头写法是把要求改写成祈使句：动词 + 对象 + 验收标准。写「找出下面日志里所有 ERROR 行，按时间顺序输出表格」，而不是「帮我看看这日志有什么问题」。区别不在礼貌，而在可执行性：前者指明了动作、对象和产出形式，模型不需要猜你想要什么；后者留出太多解释空间，模型的回应通常是一段泛泛的评述。
一个句子一个主要动词
「分析并总结并翻译并排版」这类连续动词容易被模型理解成一次输出里完成四件事，实际每个子任务的质量都会下降，失败后也无法定位是哪一步出问题。能各自验收的动作就拆成多次调用；确实强耦合的（同一段推理内顺带格式化）可以留在一次调用里。
怎么写
| 结构 | 动词（提取/改写/对比/判断）+ 对象 + 标准或输出格式 |
|---|---|
| 常用动词 | 提取、列出、对比、判断、改写、压缩、按…分组、标注 |
| 位置 | 放在任务型提示的首句，后面再补约束与格式 |
| 自检 | 把该句单独交给同事执行，对方不做追问就能动手，说明写清了 |
| 避免 | 疑问句与客套开场：能帮我……吗 常被当成对话请求而非任务 |
典型使用场景
- 日志与报错分析：从「看看有什么问题」改成「列出所有 ERROR 行并给出直接原因」
- 文档压缩：从「总结一下」改成「压缩为 5 条要点，每条不超过 40 字」
- 数据核对：写清比哪两列、以哪边为基准、差异怎么输出
- 代码审查：写清检查维度（空值、越界、并发）与输出形式（文件行号 + 问题）
- 内容改写：写清目标读者、保留项与字数，避免生成风格飘忽的长文
改写对照
改写对照
差：帮我看看这段日志有什么问题，能不能优化一下？
好：找出下面日志中所有 ERROR 行，按出现顺序输出表格：
时间 | 错误码 | 可能的直接原因（每个一行，不展开修复方案）。
差：总结一下这个文档。
好：把该文档压缩为 5 条要点，每条不超过 40 字，保留所有数字与专有名词。
差：这段代码安全吗？
好：逐行检查下面函数是否存在数组越界与未校验的空值，输出可疑行号 + 原因。模糊请求与可执行写法
| 模糊写法 | 问题 | 可执行写法 |
|---|---|---|
| 帮我优化一下 | 优化目标未知，可能改成你不想要的方向 | 在保持接口不变的前提下，把该函数的嵌套层级降到 3 层以内 |
| 看看有没有问题 | 问题类型无边界，输出泛泛而谈 | 找出该配置里会导致启动失败的三类问题，按风险排序 |
| 详细讲讲 | 详细程度没有验收标准 | 按 定义 / 参数 / 示例 三段各写 100 字左右 |
| 总结一下 | 保留项与长度都未定 | 输出 5 条要点，保留全部数字与日期 |
把动词句写在最前，约束与格式写在后面：前置的动作为任务定调，后面的条款作为补充，比全部挤在一句话里更容易被遵循。
同一条提示里出现两个互不相关的动词（判断优先级 + 翻译成英文）时，先看它们能否分别验收，能拆就拆成两步。