企业官网建设流程全解析

AI 驱动的命令行工具开发短记：别让演示效果骗了你

我第一次给命令行 Agent 做演示时，只准备了一个格式很整齐的编译错误。它能找到文件、给出修改建议，看起来很顺。换成一段带 ANSI 颜色码的终端输出后，解析就失败了。这件事提醒我：演示能说明“这个路径跑得通”，却不能说明工具面对别的输入也可靠。

我现在会把测试留在本地：输入使用自己写的合成日志，不放项目路径、仓库内容或环境变量。每个用例只问一个问题，例如“工具能否从输出里取出错误码”。模型只负责把文本整理成约定的 JSON；命令执行、文件读取和最终修改仍由程序控制。

use serde::Deserialize; #[derive(Debug, Deserialize, PartialEq)] struct ToolRequest { tool: String, query: String, } fn parse_tool_request(reply: &str) -> Result<ToolRequest, serde_json::Error> { serde_json::from_str(reply) } #[test] fn accepts_a_known_tool_only() { let reply = r#"{\"tool\":\"search_error\",\"query\":\"E0382\"}"#; let request = parse_tool_request(reply).unwrap(); assert_eq!(request.tool, "search_error"); assert_eq!(request.query, "E0382"); }

这个测试只验证输出格式，不代表模型理解了 Rust，更不能直接放行工具调用。下一层还要检查工具名是否在白名单里、查询词是否为空，并给每次调用设超时。模型返回的内容只是候选请求；我会先让它在模拟工具上跑，再人工查看结果，确认没有误读日志后才考虑接入真实命令。

测试集也不必很大。先收集几种我确实遇到过的输入：普通编译错误、空输出、乱码片段和过长的一行日志。每次修复一个问题，就补一条回归用例。这样即使下一次演示很顺，也知道它覆盖了什么、还没覆盖什么。