文章目录让 AI 把话说明白Karpathy 的建议与实用中文技巧一、Karpathy 为什么提到航空写作规范二、把建议写成一个可复用的提示词三、同一段材料怎样解释得更清楚A普通要求与连续说明B使用清晰表达提示词对比时先检查什么四、实际使用时怎样选择输出形式从解释走向检查参考来源与自测记录让 AI 把话说明白Karpathy 的建议与实用中文技巧AI 给出一大段解释你读完却还要追问到底谁来做什么情况下做出了错怎么办先看一句设定的技术说明在请求超时而任务可能已经由后端处理的情况下应在保持原有幂等标识的前提下根据限定的重试次数和等待间隔进行后续处理。这句话提到了超时、重试和幂等但你仍然不知道该怎么处理。谁来重试最多几次“后续处理”具体是什么一部分信息被挤在长句里另一部分根本没有交代。要解释清楚得把已有信息组织好也得承认哪些信息还缺着。一、Karpathy 为什么提到航空写作规范Karpathy 在原帖中提出随着模型自主完成更多工作人会把更多精力放在理解和监督它的结果上。让输出容易理解因而越来越重要。这是他对工作变化的判断。[1]他的文字建议很具体让模型用 ASD-STE100 解释问题。如果觉得规范太严格可以要求“做到八成接近 ASD-STE100”。“八成”是一个放宽风格要求的说法并没有对应的合规评分。[1]ASD-STE100 是一套用于航空维修文档的受控英语规范包含写作规则和通用词典。它限制词语的用法减少同义词轮换也允许使用符合规则的领域技术名词和动词。[2]想想开头那句话。如果“后端”指的就是“服务端”一直叫“服务端”你就少一次猜测写清“客户端重试”动作的执行者也明确了。把条件放在它控制的动作旁边你更容易判断这条规则什么时候适用。在中文里我更愿意把这些原则具体写出来同一个对象用同一个名字谁做什么说清楚原因、条件和结果接得上。短句有助于阅读但拆开之后逻辑关系仍要保留。二、把建议写成一个可复用的提示词沿着这个思路可以把规范名称和具体要求合在一起。规范名称提供方向具体要求说明我们希望模型怎样解释。下面这个提示词可以换入技术说明、通知或其他需要理解的内容。读者和用途按需填写结构则由内容决定。任务 解释下面的内容或问题让读者容易理解、抓住重点。 内容或问题 [填写内容或问题] 读者与用途可选 [填写读者与用途] 要求 - 借鉴 ASD-STE100 的清晰表达原则使用常用词和自然短句统一术语明确谁做什么必要的术语解释清楚。 - 按读者理解所需的顺序组织内容说清原因、条件和结果步骤或比较需要时再分点。 - 解释给定材料时保留其中的事实、数值、条件、例外和不确定性补充解释或例子须与原材料区分信息缺口明确指出。 - 表达自然像当面解释不为缩短句子破坏逻辑不把推测写成事实不重复铺垫或总结。 输出 直接给出解释遵循指定的语言和格式未指定时沿用输入语言。“保留条件、例外和不确定性”是这次实践加入的要求。它提醒模型也提醒读者一句话更顺并不意味着内容更准确。这里借鉴 ASD-STE100 的清晰表达原则中文仍按中文的习惯组织。三、同一段材料怎样解释得更清楚回到开头的重试问题。那句话没有给出具体次数和等待时间模型无法仅靠改写补出答案。下面换成一段信息较完整的设定材料看看提示词怎样组织它。下面将连续说明与按清晰表达要求组织的回答作比较。A 是人工构造的写作示例B 是当前对话内生成并由同一模型自查的回答没有独立 API 调用、隔离的对照实验或读者测试。[5]客户端调用 POST /jobs 创建任务。请求超时时服务端可能已经创建任务。客户端最多额外重试两次每次重试前等待 1 秒且必须沿用首次请求的幂等键。对于已成功创建的任务服务端在 24 小时内收到相同幂等键的请求时返回原结果不重复创建任务。收到 HTTP 400 时客户端停止重试并提示参数错误。两次重试后仍然超时客户端记录错误并结束本次请求。设定材料中的条件与动作客户端调用 POST /jobs 创建任务请求超时服务端可能已经创建任务收到 HTTP 400客户端最多额外重试两次每次重试前等待 1 秒沿用首次请求的幂等键任务已成功创建且服务端在 24 小时内收到相同幂等键的请求服务端返回原结果不重复创建任务两次重试后仍然超时客户端记录错误并结束本次请求客户端停止重试并提示参数错误A普通要求与连续说明普通要求可以写成任务 根据上面的接口规则解释客户端如何处理请求超时和参数错误。 要求 - 仅依据材料回答不补充材料外的事实。 输出 中文说明。下面是根据材料构造的一段连续说明客户端通过 POST /jobs 创建任务而请求超时并不一定意味着创建失败因为服务端可能已经完成了任务创建因此客户端可以在每次等待 1 秒后最多额外重试两次但必须保持首次请求的幂等键不变以便服务端在任务已成功创建且相同幂等键的请求发生在 24 小时内时返回原结果避免重复创建任务。如果收到 HTTP 400客户端应停止重试并提示参数错误如果两次重试后仍然超时则记录错误并结束本次请求。A 保留了设定材料的规则。阅读时你需要从第一个长句里自己拆出超时含义、重试条件和服务端行为。B使用清晰表达提示词这里使用第二节的通用提示词。填入的具体问题是“请解释以下接口规则让读者清楚超时或参数错误后应怎样处理”读者与用途是“读者了解客户端和服务端需要查阅重试条件”。下面是本次生成的回答保持原文客户端通过POST /jobs创建任务。请求超时后服务端可能已经创建任务因此超时不等于创建失败。**超时后怎么重试**客户端最多额外重试两次。每次重试前等待 1 秒并沿用首次请求的幂等键。**为什么保留幂等键**对于已经成功创建的任务服务端在 24 小时内收到相同幂等键的请求时会返回原结果不重复创建任务。**收到 HTTP 400**客户端停止重试并提示参数错误。**两次重试后仍超时**客户端记录错误并结束本次请求。新回答按遇到的情况组织超时后怎么重试为什么保留幂等键收到参数错误后怎么办重试仍然超时又怎么办。你可以先找到自己的问题再看对应的规则。从这个例子看值得关注的变化是整理工作由谁承担。A 需要读者自己拆出关系新回答先把关系摆出来。句子可以长一点但如果读者能直接找到条件对应的动作解释仍然可能更容易使用。对比时先检查什么对比的第一步是回到原材料核对意思。把一项限制删掉文字往往更顺读者却可能据此作出错误判断。先核对数值和条件。是否保留“最多额外重试两次”“每次等待 1 秒”返回原结果的“任务已成功创建”“24 小时内”“相同幂等键”三个条件是否仍然同时成立再核对语气和新增内容。“可能已经创建”有没有变成“已经创建”回答有没有自行加入退避算法、更多重试次数或者其他接口行为然后检查关系。谁重试谁返回结果条件是否贴在它控制的动作旁边同一个对象有没有换名字让读者误以为是另一个东西最后带着问题查找答案。收到 HTTP 400 后还要等 1 秒再重试吗两次重试仍超时下一步是什么这些答案能否直接找到本次逐项自查中A 和新回答都保留了设定规则。新回答的条件和动作可以按情况查找但这还不能证明读者理解得更快、更准确也不能用构造的 A 推出提示词带来了多大提升。其他作者的小测试也有分歧。Lucian Ghinda 用四段代码做了两轮比较指定 ASD-STE100 后句子变短但部分检查事实的覆盖减少了。[3] StashBase 的另一组说明性文本测试则保留了全部八项检查事实答案总长度也没有明显缩短。[4] 两组测试的材料和设置不同都不足以推出普遍结论。它们提醒我们句子变短、答案变短、事实保留完整需要分别检查。而“是否容易理解”还要看读者能不能找到信息、解释关系、据此作出正确判断。四、实际使用时怎样选择输出形式先想清楚读者拿到答案后要做什么。如果是查规则或执行步骤文字通常就是合适的起点。像这段重试说明读者需要快速找到次数、间隔和停止条件按情况分点有用。如果要理解为什么必须保留幂等键则需要把“可能已经创建任务”和“避免重复创建”的关系连起来只有步骤还不够。同样是文字组织方式也应随用途变化。查阅材料可以分点讲清原理需要连贯解释写博客还要让读者知道这个例子为什么出现在这里下一段准备回答什么问题。Karpathy 原帖还谈到图示、交互网页和讲解视频。[1] 当困难在于模块关系、参数变化或动态过程时可以考虑这些形式。本例的规则用文字能够交代无须为了覆盖所有形式再制作一套图示或视频。我的判断是选择形式时还应考虑读者能否检查它条件在哪里依据是什么有疑问时能否回到对应内容。呈现再流畅如果关键条件难以核对仍会增加判断的负担。从解释走向检查从这个例子再往前想一步解释和审查可以共用一套结构。次数、时间和停止条件有了明确的位置读者就能逐项对照原材料检查模型有没有改动它们。文字组织得清楚也可以帮助我们发现错误而不只是找到答案。同时读懂一句话和知道怎么执行仍有区别。开头的说明即使拆成短句只要没有重试次数和等待时间就无法给出完整的操作依据。表达规则能帮我们看出缺口缺失的事实还得查证。这让我更愿意把“解释清楚”落在两个问题上哪些关系需要先替读者理出来哪些事实还需要核实前一个问题减少阅读中的猜测后一个问题保留判断的依据。这样使用文字建议也呼应了 Karpathy 所说的理解和监督。参考来源与自测记录Andrej Karpathy 原帖页面中收录的原帖转录。本文主要实践其中的文字建议。ASD-STE100 官方 FAQ官方介绍。Lucian GhindaExplain to me in Simple Technical English。StashBaseASD-STE100 in Claude: CLAUDE.md, Output Style or Skill?。