AI篇 工具
工具
AI在使用gh工具查询CI-job错误信息的时候,需要翻查很多层级才可以定位.
并且gh view会偶发卡死,会被bash工具调用上限时间掐死.
AI非常喜欢看开头和结尾,我们做工具可以更偏好开头和结尾.
我把聊天历史复制给让AI分析.
首次调用优化
- 这是真实的AI执行数据,请你设身处地的思考.
- AI使用工具时候改变行为的契机是什么?
- 为什么没有继续用原本方案?
- 为什么遇到xx问题就改用其它了,这个xx根因是什么?
- 数据噪声,数据量,格式不友好,你可以自行优化,你既是开发者也是用户.
- 还有什么令你不舒服的?推荐修复,制定修复计划.
- 置顶错误
- 优先展示
总结>错误>警告>通过
因为使用gh大部分情况是处理CI错误,针对这个场景,在首次调用工具的view命令就置顶错误. 总结遇到尚未拉取,展示为按需阅读(尚未拉取)来进行渐进式披露.
除非信息源(这里是github)提供了完整结构化查询.
- 参数宽容和转换
- 如果遇到
参数失败空数组[]就补实现和转换参数,使其更加宽容. - 根据AI实际调用来补参数,可以用转换表来实现,目的是防止第一次错误.
不要使用白名单,使用穿透启动参数到实际的消费点处理器,每个处理器上面做守卫.
- 优化提示
- 错误和缺失的参数要提示:参数名称,并且提示参数类型(可以宽容处理但是不要掩盖错误)
- 错误信息要诱导AI进行
下一个工具调用和排查错误的方式. - 错误提示风格
不要出现可能是xx或者yy原因导致,
而是列出一个表,表示可能性名单,名单中列出调查工具名.
用户未来可以继续维护这个表,使得工具更健壮.
-
ADR080 启动参数执行
使用真实的启动参数执行来代替测试,过程中遇到不正确的行为就去修复代码.
仔细识别工具的返回值,遇到噪声,格式化错误,不舒服的地方,都要生成子任务,推荐用户后续修复. -
ADR132 部署
在用户文件夹\bin\gh放一个无后缀的gh脚本,
指向真实的jcc.exe,每次测试就复制文件过去替代,以此本机真实运行.
行号和分页
-
加注行号方便定位,并且提供行号定位功能.
-
多种阅读模式
a,默认节省token:人类阅读纯文本和表格
b,精简json
c,完整json.
系统变量进行切换. -
并行下载
- CI-job信息是可以并行下载的,那么下载并缓存持久化.
- 不要全量拉取job日志
优先拉取错误部分.
让AI可以逐级展开,按需动态拉取,不然会触发github限流或者风控. - 数据清洗
对日志进行格式化表达,
剔除ANSI颜色,
剔除已经pass通过的噪声,
还可以根据历史构造错误日志的链路. - 格式无法识别的
使用截断分页,诱导AI使用分页工具阅读.
海量的MCP工具
工具组别和说明
-
分班再分组
先大类和小类,通过多层级渐进式阅读:大类:gh工具 小类:查询功能
工具层-脚本层-细粒度指令(例如win32API)
AI不是不会用,而是遇到庞大的世界难以分层理解优先用哪个,选择困难会导致偏离任务.
它也不知道用脚本会有破坏性动作,所以每次触发脚本我就系统提示词让它自行备份或者推荐用户备份. -
情景模式
除非模型内化了工具能力,不然工具肯定要说明书,这个说明书就是情景模式.
遇到xx场景使用的扁平化阅读.
我还在-h启动参数上面优先置顶这个情景模式阅读. -
切词搜索和菜单搜索.
菜单就是电视机菜单,固定形式暴露即可.
而切词则是内部的所有提示词都拿出来切割,方便在使用中自行分析.
工具地图
- 映射表
遇到螺丝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,
所以删代码成为艺术,一次性把需求整理好,再次生成反而更好,多轮对话就是表现不佳.
浙公网安备 33010602011771号