AI篇 工具

工具

AI在使用gh工具查询CI-job错误信息的时候,需要翻查很多层级才可以定位.
并且gh view会偶发卡死,会被bash工具调用上限时间掐死.

AI非常喜欢看开头和结尾,我们做工具可以更偏好开头和结尾.

我把聊天历史复制给让AI分析.

首次调用优化

  1. 这是真实的AI执行数据,请你设身处地的思考.
  • AI使用工具时候改变行为的契机是什么?
  • 为什么没有继续用原本方案?
  • 为什么遇到xx问题就改用其它了,这个xx根因是什么?
  • 数据噪声,数据量,格式不友好,你可以自行优化,你既是开发者也是用户.
  • 还有什么令你不舒服的?推荐修复,制定修复计划.
  1. 置顶错误
  • 优先展示总结 > 错误 > 警告 > 通过
    因为使用gh大部分情况是处理CI错误,针对这个场景,在首次调用工具的view命令就置顶错误.
  • 总结遇到尚未拉取,展示为按需阅读(尚未拉取)来进行渐进式披露.
    除非信息源(这里是github)提供了完整结构化查询.
  1. 参数宽容和转换
  • 如果遇到 参数失败 空数组[] 就补实现和转换参数,使其更加宽容.
  • 根据AI实际调用来补参数,可以用转换表来实现,目的是防止第一次错误.
    不要使用白名单,使用穿透启动参数到实际的消费点处理器,每个处理器上面做守卫.
  1. 优化提示
  • 错误和缺失的参数要提示:参数名称,并且提示参数类型(可以宽容处理但是不要掩盖错误)
  • 错误信息要诱导AI进行下一个工具调用和排查错误的方式.
  • 错误提示风格
    不要出现可能是xx或者yy原因导致,
    而是列出一个表,表示可能性名单,名单中列出调查工具名.
    用户未来可以继续维护这个表,使得工具更健壮.
  1. ADR080 启动参数执行
    使用真实的启动参数执行来代替测试,过程中遇到不正确的行为就去修复代码.
    仔细识别工具的返回值,遇到噪声,格式化错误,不舒服的地方,都要生成子任务,推荐用户后续修复.

  2. ADR132 部署
    在用户文件夹\bin\gh放一个无后缀的gh脚本,
    指向真实的jcc.exe,每次测试就复制文件过去替代,以此本机真实运行.

行号和分页

  1. 加注行号方便定位,并且提供行号定位功能.

  2. 多种阅读模式
    a,默认节省token:人类阅读纯文本和表格
    b,精简json
    c,完整json.
    系统变量进行切换.

  3. 并行下载

  • CI-job信息是可以并行下载的,那么下载并缓存持久化.
  • 不要全量拉取job日志
    优先拉取错误部分.
    让AI可以逐级展开,按需动态拉取,不然会触发github限流或者风控.
  • 数据清洗
    对日志进行格式化表达,
    剔除ANSI颜色,
    剔除已经pass通过的噪声,
    还可以根据历史构造错误日志的链路.
  • 格式无法识别的
    使用截断分页,诱导AI使用分页工具阅读.

海量的MCP工具

工具组别和说明

  1. 分班再分组
    先大类和小类,通过多层级渐进式阅读: 大类:gh工具 小类:查询功能
    工具层-脚本层-细粒度指令(例如win32API)
    AI不是不会用,而是遇到庞大的世界难以分层理解优先用哪个,选择困难会导致偏离任务.
    它也不知道用脚本会有破坏性动作,所以每次触发脚本我就系统提示词让它自行备份或者推荐用户备份.

  2. 情景模式
    除非模型内化了工具能力,不然工具肯定要说明书,这个说明书就是情景模式.
    遇到xx场景使用的扁平化阅读.
    我还在-h启动参数上面优先置顶这个情景模式阅读.

  3. 切词搜索和菜单搜索.
    菜单就是电视机菜单,固定形式暴露即可.
    而切词则是内部的所有提示词都拿出来切割,方便在使用中自行分析.

工具地图

  1. 映射表
    遇到螺丝A123就是要找螺丝刀K456
    这种映射表可以手写,
    更为聪明做法是做一个DAG,通过大量的使用频率进行动态推荐.
    用户自己的习惯通过关联性就可以推荐给AI.
{
工具名:xx
AI执行下一个工具频率: aa(0.6),bb(0.3),cc(0.1)
用户执行下一个工具频率: bb(0.8),cc(0.1),aa(0.1)
当前条件:
转移条件:
下一个工具推荐: bb
下一个工具组别推荐: OO
}

按转移条件分组,组内包含三个角色:

role 含义 AI 何时用
primary 首选,最可能成功 默认先调这个
fallback primary 失败/无结果时 primary 返回空或错误
refine 拿到数据后精炼 数据太大/太杂时

提示词

注入技巧

每次使用就注入系统提示词?
不,这样有庞大噪声,AI是会记得上下文很多东西的.
要使用冷却期,通过数分钟再次提示来动态注入.

跳出循环

AI在上下文太多时候,或者经历数小时运行多次上下文压缩摘要,
此时会产生一种状态就是遇到一个错误就会循环解决这个错误,或者做出错误决策.
我称之为:注意力涣散.

除了read,wirte,edit之外,针对bash:高频率使用某种工具时候.

第一轮:
1,阅读项目其它文件,文档,看看是否已经解决这个问题,是否有同类问题.
2,提示诱导使用web工具查询相关问题.
3,把混乱的功能进行单一职责之后,任务可能变得清晰,你可以推荐用户修复.

第二轮:
1,你的记忆可能存在错误,你要验证后再次推论,记忆只是线索不是真理,实时性可能已经不足了.
2,是否使用任务重排,避免单点问题干扰整体项目推进.
3,有没有可能任务前提就是错误的?去反思.

第三轮:
1,没收工具,使用冷却期.
2,进行深入思考并且得到分析链,不必在一轮上下文对话上面证明结论.
3,如果确实不可行就向用户报告.
4,冷却期间你可以构建n个思路的代码到文件中.

双击ESC清理掉计数
用户对话之后必然是想AI继续后续工作,也就是重置工具额度.

选择性忽略

工具提示词会很容易被AI忽略,
无论是子代理返回的报告,还是工具提示词,都会出现选择性忽略.
所以最好的做法还是扁平化计划,然后目标驱动.

唯一优化的点就是子代理返回结论,
约束一个结构,通过重新组装实现结尾提示词要倒装结构.

有时候让AI写功能代码,
做了a,然后不满意,让它明确删除a改为b,都会残留a,
所以删代码成为艺术,一次性把需求整理好,再次生成反而更好,多轮对话就是表现不佳.

posted @ 2026-10-08 16:29  惊惊  阅读(3)  评论(0)    收藏  举报