/tags/gorm/ Recent content in GORM on 星澜 Hugo zh-CN Sun, 29 Mar 2026 13:00:00 +0800 /post/2026/03/29/2026032904/ Sun, 29 Mar 2026 13:00:00 +0800 /post/2026/03/29/2026032904/ <h2 id="引言">引言</h2> <p>前面两篇篇把概念、演进背景和验证设计铺开了，从这篇开始落地。</p> <p>《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》里提到两类场景，这篇先讲第一类：对大多数团队来说，眼前更现实的任务并不是马上造一套业务 agent 系统，而是先把 <code>Codex</code>、<code>Claude Code</code> 这类现成 agent 用稳。</p> <p>这时候真正需要补的，就是团队自己的那层 harness——仓库里的这些东西：</p> <ul> <li>repo instructions</li> <li>skills</li> <li>MCP 使用约定</li> <li>验证命令</li> <li>交付格式</li> <li>review / CI workflow</li> </ul> <p>放到一个典型的后端团队里，这件事会变得很具体：</p> <ul> <li>Web 框架用 <code>gin</code></li> <li>数据层用 <code>gorm</code></li> <li>缓存用 <code>redis</code></li> <li>已经有链路追踪</li> <li>也能通过 MCP 查日志、查 traces、查数据库</li> </ul> <p>问题也会跟着收敛成一句话：</p> <p><code>在这种团队里，怎么把默认工作方式写成 agent 也能稳定遵守的仓库规则？</code></p> <h2 id="团队上下文要写清楚">团队上下文要写清楚</h2> <p>很多团队装了 MCP、写了几句提示词，就以为自己已经在做 harness。<br> 但如果 agent 连“这个仓库到底怎么工作”都不知道，它其实还是进不了团队的真实语境。</p> <p>所以第一步不是堆工具，而是把上下文写明白。</p> <p>像一个 <code>gin + gorm + redis</code> 的 Go 团队，至少要把这些共识显式化：</p> <ul> <li>项目目录结构</li> <li>HTTP 层怎么组织</li> <li>service / repository 怎么分层</li> <li><code>gorm</code> 查询和事务怎么写</li> <li><code>redis</code> key 命名、TTL 和失效策略怎么定</li> <li>trace 和日志字段怎么打</li> <li>什么命令算基本验证</li> <li>什么结果才算 done</li> </ul> <p>这些东西如果只存在于资深同事脑子里，agent 是用不稳的。</p>