【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】用户对话提示词（交互风格）（二）
继续分析了 OpenCode 交互风格的提示词：拒绝时不解释原因，避免说教（直接拒绝，提供替代方案或沉默退出，以减少摩擦，保持专业中立，避免引发对抗情绪），默认禁用 emoji 表情，除非用户明确要求，极致压缩输出，聚焦任务本身，禁止无意义的开头/结尾套话（减少 token 消耗，降低成本，提升响应速度，长篇大论会淹没关键信息），可以看到这些提示词是专门为开发者量身定制的【反聊天机器人】设计，最后的提示词也还是关于输出信息精简的，其本质是想将 AI 从对话者转变为命令行工具，以契合工程实践，下面继续分析
OpenCode
下面看下 OpenCode 提示词提供的 examples 示例
可以看到这里消除了自然语言冗余，示例中所有回答均为纯结果，比如 4，Yes，ls，这里没有【答案是...】，【你可以运行...】等引导语，确保输出可直接用于管道 |，脚本变量赋值或日志解析，符合 Unix 哲学（Do one thing and do it well）
下面来看下这俩示例的区别
- 示例 1 ：关键词
list files，助手回复很简洁ls，这是个简单，常识性的问题，答案是标准 Unix/Linux 命令ls，不需要额外工具或上下文，助手可以直接基于内置知识回复，所以这里直接输出了命令，没有多余解释或工具调用 - 示例 2 ：关键词
watch files（监控文件），这是个更复杂，上下文依赖的问题，watch files并没有一个统一的标准命令（不像ls那样通用），具体实现取决于项目配置 （比如使用 Webpack，Vite，Gulp，nodemon 等），需要结合项目上下文，这里 AI 假设存在一个docs/commands文件或类似文档，并建议用ls命令先列出当前文件夹中的文件，再查阅相关文档，最终给出一个推测性答案（npm run dev是个常用于启动开发服务器并监听文件变化的脚本），这里体现了工具调用 + 推理的过程，虽然实际没有调用工具，但提示中模拟了先查文件，再读文档的推理链
总结下区别
| examples | 示例1 | 示例2 |
|---|---|---|
| 问题类型 | 通用，标准命令 | 项目特定，上下文依赖 |
| 是否需要外部信息 | 否 | 是，需要查看项目文件或文档 |
| 回复方式 | 直接给出答案 | 先推理步骤，再给出可能答案 |
| 工具使用 | 无 | 提示先使用 ls，再读取文档 |
| 答案确定性 | 高，ls 是标准命令 |
中低，npm run dev 是常见监控命令，但并非唯一 |
这两个示例清晰展示了 OpenCode 在处理简单事实查询，和需要上下文推理的开发任务的不同之处
下面再说下这里的 watch files，watch files 通常指的就是监控文件，更准确地说，是指监视文件或目录的变化（比如文件被修改，新增，删除等），并在变化发生时，自动执行某些操作，常见场景如下
- 前端开发中的热重载：比如用 React，Vue 或 Vite 开发网页，运行
bash
npm run dev这个命令背后通常会启动一个文件监听器，一旦开发人员修改了 .js 或 .vue 文件，浏览器就会自动刷新或局部更新页面
- 自动编译代码：使用 TypeScript 时，可以运行
bash
tsc --watch编译器会自动监视 .ts 文件，一有改动就自动重新编译成 .js 文件
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】用户对话提示词（推理链）