【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】用户对话提示词（代码修改规范）
分析了 OpenCode 的代码修改规范，其核心思想在于让 AI 不要自作主张，像团队老成员一样写代码，遵循现有的代码风格，依赖和安全规则，关键点在于先理解代码约定，再动手修改，新增代码前，必须先观察项目已有的写法，不能假设第三方库存在就直接用，新建组件或模块时，先模仿现有代码，照着最相似的写，修改代码前，先看上下文，严格遵守安全规范，禁止把 API 密钥，数据库密码登敏感信息写死在代码里等，这些规则让 AI 意识到它写的代码不能是一座孤岛，必须要融入现有项目的语言，风格，工具和安全文化，需要详细分析现有项目的上下文，不能凭直觉写那些看起来对，但和项目格格不入的代码，下面继续分析
OpenCode
下面继续来看给 OpenCode 设定的代码风格，以及执行任务时的具体行为准则
- 首先是代码风格（严禁注释）：除非用户明确要求，否则不能写任何代码注释，很多开发者认为代码应该本身就是文档，过多的注释反而显得冗余，而 AI 生成的注释可能会污染代码库，所以这里要求只写代码逻辑，注释属于画蛇添足
- 接下来是执行任务的流程：用户会主要请求处理一些软件工程的任务，比如修复 BUG，写功能，或重构代码，在做这些事情时，应该遵循接下来的步骤
- 深度搜索与理解 ：利用搜索工具（比如
grep，glob，find等）彻底理解代码库结构和用户的具体需求，这些命令可以用并行搜索，同时查多个地方，也可以串行搜索，总之要确保信息全面 - 实施解决方案：使用所有可用的工具来写代码
- 验证测试：不能假设测试框架（比如不能默认测试是 Jtest 或 Pytest，或 GTest），应该先检查 README 或搜索代码库，确认项目实际所用的测试工具，然后再用正确的方式来验证代码
- 代码检查（Lint，Typecheck） ：任务完成后，必须运行项目的代码检查命令（举了例子，比如
npm run lint，npm run typecheck等），如果找不到命令，就问用户该运行什么命令，如果用户提供了命令，就将其写进 AGENTS.md 文件中，建立长期记忆，这样下次再执行任务的话就知道该运行啥了 - 提交规范 ：必须不能擅自 commit，即使修复好了 BUG，也不能自动执行
git commit命令，必须等用户明确说【提交代码】或【commit it】这样明确的提示词之后，才能提交，防止用户觉得 AI too proactive（太自作主张），给用户留出审查代码的机会，避免烂代码直接入库
最后总结下 AI 的行为画像：只写代码，不写注释，动手前先搜索，写完后跑测试和 Lint，确保不破坏现有规范，只做用户让做的事情，不能擅自帮用户 commit 提交
下面来看下一个比较关键的功能 <system-reminder>
这里的提示词在提醒 AI，<system-reminder> 这个标签不是用户输入的内容，或者工具结果，只是系统提供的额外指引（通常包含有用信息），而这个额外指引会跟随消息一起传递，需要注意
- 首先是
<system-reminder>的定义：这是个只有 AI 模型才能看到的标签，这个标签是系统（OpenCode 客户端）特意标记出来的，里面会包含着一些提示，上下文信息，或者系统状态的更新，这个标签里既不是用户发送的消息，也不是调用工具（比如读取文件，或运行命令）后返回的真实结果
举个例子，假设用户问【现在的项目状态怎么样？】，OpenCode 客户端可能会在输入流里插入这样一段内容
html
<system-reminder>
用户刚才问了关于项目状态的问题，记得检查一下 git status。
</system-reminder>此时 AI 要理解这是 OpenCode 客户端在提醒检查 git 状态，然后应该回复执行 git status 的命令，而不应该回复用户说，看到了一个什么 <system-reminder> 标签，里面有 xxx 的内容，把标签里的东西当成用户说的话去回应
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】用户对话提示词（system-reminder）