北京
同样是让AI调用一个API、解析一个配置文件、按列限制换行文本，你每次都用自由形式的提示词去描述。周一运行时还好好的步骤，到了周二就可能“自由发挥”，等到周五，整个流程已经像即兴爵士一样不可控。更糟的是，你图省事直接把密钥粘进了对话里，一个本应藏在 .env 文件里的凭据，就这样变成了提示词中的明文泄漏。
重复提示的根本问题在于：模型每次都在从零解释你的指令，而不是执行一套固定的逻辑。同样的输入可能产生不同的输出，行为漂移根本没有征兆。而且每重复一遍任务，都要用令牌把已经讲过的规则再讲一遍，消耗的上下文空间越来越大，真正有用的信息反而被挤了出去。
手动调用API时，你很容易漏掉重试和退避逻辑，一个 429 状态码就能让任务直接终结，而不是等一秒再试。一旦在自由提示的过程中出了问题，你还得重新翻阅长长的对话记录去找原因，远远不如看一行调用堆栈来得直接。
更好的做法是：先梳理出那些输入固定、输出也固定的技能步骤，然后用一门具备测试框架的语言把它们写成真实的脚本，而不是再写一段说明文字。把脚本所需的每份凭据都移进 .env 文件，在运行时加载，别让配置散落在代码各处。对于每一个外部 API 调用，都加上重试、超时和速率限制退避，确保偶发故障不会让整个任务挂掉。
接下来像对待任何代码变更一样，为脚本补上单元测试，让回归错误在测试阶段就暴露出来，而不是直接流到用户那里。再把脚本提交一次正常的代码评审，之后每次调用这个技能，脚本都会以完全一致的方式执行。
这样做之后，模型只需要负责脚本做不了的判断——比如决定该调哪个脚本。你还可以反过来让模型去审计已经在生产环境中运行的技能，找出那些还在用自由形式动作完成的步骤，比如对同一个站点发起好几次 WebFetch 调用，然后指出哪些可以直接用单一 API 调用替代成脚本。
最终你会发现，确定性回来了：同样的输入永远返回同样的输出，你不会再被毫无缘由的行为变化浪费精力。速度也上来了：脚本毫秒级运行，不用等待模型往返去处理那些根本不需要判断的逻辑。令牌成本大幅降低，因为留在代码里的逻辑不需要每次都塞进上下文窗口重新解释。可测试性让每一次变动都像普通代码一样可控。而经过评审的脚本，也从根本上杜绝了模型在需要安全的步骤里临时起意、即兴发挥的可能性。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
