两个月完成 59 篇 AI 开发记录与 Golang 商业项目后，我总结的 AI 协作心法（上）

AI 能快速生成代码，却不会自动理解项目中的全部业务约束。完成一个 Go 商业级项目后，作者发现开发效率并不只取决于工具、Skill 或提示词模板，更取决于开发者能否准确描述需求、识别错误前提并审查最终实现。下面将从沟通方式和安全案例入手，梳理这段实战中形成的协作原则。

完工撒花???~

两个月了，一天 14-16 小时，单休；恭喜自己学会了 Golang 撒花???~

实战项目已达商业可用级别，而且完全免费开源，求 star：ai-go-admin（github | gitee），可视化CRUD真的非常强大，欢迎在线体验一下：demo.ai-go-hub.com/#/admin。

接下来就是纯纯的干货了，我将心法分为 核心理念、沟通技巧、安全、交叉验证、无需妥协与超预期、局限与低于预期 六章，全部是实战结论和经验；由于文章较长，我分为了上下两篇，同步发布，本篇含前三节。

核心理念

不知道有没有人看过最新一期（2026.8）Codex 负责人 Tibo 的访谈（经常按下重置按钮那个人），其中有一个核心观点是：

下一代 Agent 的核心，不是再加更多 Skill、Memory 或子 Agent，而是让这些机制“消失”。未来不再需要不断管理 skill 文件、Memory 和 Agent 网络。

我个人是非常认可的，我们不需要学工具（skill、记忆，全部都会过时），重中之重是学如何和 AI 沟通：一个需求你自己都不理解、说不明白、描述不清上下文，你凭什么认为 AI 能完美的帮你完成？而反过来，你知道达成需求的核心要素、或者你已经知道问题在哪儿，和 AI 配合起来自然也更加得心应手、丝滑顺畅（见沟通技巧）。

甚至 AI GO ADMIN 使用 Claude Code 实现了一大堆功能之后才第一次建立 CLAUDE.md 文件，整个 CC 完全处于只配好了 API KEY 的状态，应该有人不信，那么这一大堆功能具体指什么呢？ 配置系统（带自动发现、环境配置文件、环境变量覆盖）、数据库连接（带读写分离，支持链式+函数式选项自定义 db）、模型自动发现和迁移、四层业务架构的基类实现、自动发现和注册路由、统一响应结构和函数（也支持链式调用和函数式选项） 等等，还有完整的开发日志：第一篇

当开发者本身技术够硬时，所有工具都是花架子，大不了多浪费一些 token；注意，我并不是说这些工具无用，只是同 Tibo 观点一样：着重和 AI 本身的沟通能力；起码首先将注意力，全部放在沟通上，当你觉得自己已经和 AI 有一些默契的时候，再开始去了解一些精品 skill 是不错的选择。

和 AI 的沟通能力，只要用 AI，那么就是一直需要的，哪怕未来 AGI 出来你还是得描述自己的需求，大不了配个麦克风。

最后，不要报付费课，所谓老师，大多数都是闻到利益味道的投机份子，他搞不好也是昨天才开始研究，然后直接开始包装和疯狂打广告。

沟通技巧

1. 首先新手不要纠结提示词怎么写，你不是在写诗、写作文，直接把它当你的下属开始聊天就行了，可以有错别字，可以有语句不通，也可以有含糊不清，也可以让AI自己读暂存区和已打开的文件。
2. 在和 AI 达成初步默契之后，为了节约 token，也为了项目的健壮性，你就需要更加明确的描述你的需求了，请看举例：

例一、测试到 token 有效期异常

生成的代码人工测试到 token 有效期异常，你发现原来是：AI 错误的认为 Get 方法已经对 token 的有效期进行了检查，但实际上没有。

细节之处是，AI 之前已经有错误的认知了，并且根据错误认知写出了 BUG 代码。

此时你可以直接告诉 AI：我们测试到 token 有效期异常，AI 经过一通折腾，耗费大量 token，可能能够解决问题，但涉及 token 这种重要系统，你不知道它干了啥，也不知道到底找没找到问题根因，反正就是好像解决了。

你还可以告诉 AI：Get 方法没有检查有效期，半句话直达问题核心，它大概率会按你的想法解决问题，你还可以加上后半句：在 Get 内加上检查 或者 Get 后额外检查。

例二、完整描述你的需求细节

配置系统规划如下，帮我实现：

• 使用 github.com/spf13/viper 管理配置
• 初版有 应用名称、开发服务端口号、数据库相关 配置项，放在一个配置文件内即可
• 所有配置文件，使用 YAML 格式保存于 config 目录下，配置系统能自动加载所有 YAML 配置文件，增加配置文件时，不需要手动改代码
• 额外一个 .env.yaml 环境配置文件，优先级最高，用于开发环境自定义数据库配置，GIT 需要忽略此文件
• 额外一个 .env.yaml.example 文件，GIT 不忽略，用于方便开发者将项目拉到本地之后，快速创建 .env.yaml 文件
• 数据库配置细节：以 type 字段表示数据库类型，默认使用 PostgreSQL 数据库；带有 max_open_conns 等连接池配置

理论再多不如实践，AI 编码就是一个你输入它输出的过程，只要你愿意对输出进行 review，自然能打磨出一个更好的自己和AI工具。

我个人比较重 review，而且做项目都只做精品，所以提示词都是聚焦于细分功能上，而不是直接让 AI 规划/拆分一整个应用，一次性出完整应用的路子，我个人认为还是太虚了，小应用/个人工作台/DEMO/外包 场景是可以的，详见下面的 安全、局限和低于预期 章节。

安全

AI 写代码非常快，任务可以并发开始，但是收尾只能人工一个一个来，这就导致很多人不再重视收尾，而是选择 看起来没问题就行，以下直接列两个我在实战过程遇到的安全问题以警醒诸位：

例一、意外的权限放行

背景：我们设计了两个中间件 middleware.AdminAuth()（认证）和 middleware.AdminPermission()（鉴权），前者完成管理员登录认证，记录登录态，后一个则基于前者的登录态进行鉴权。

AI 知道 AdminAuth 中间件的作用，然后开始制作 AdminPermission 中间件，它是这样写的：

admin := GetAdmin(c)
if admin == nil {
    // 未登录，由 AdminAuth 拦截 401，放行
    c.Next()
    return
}

action, nodeSuffix := extractAction(fullPath)
if nodeSuffix == "" {
    // 无法识别动作，放行
    c.Next()
    return
}

首先未登录的直接放行就是严重的错误，应该直接拦截，并提示未登录。其次 AI 写了一个从 fullPath 末尾提取当前动作的方法，如果提取失败，也放行，这与我们的设计不符，唯二放行规则应该是超管和存在匹配的节点。

例二、先检查密码，再检查人机验证码

我们已经完成了前端的 点选验证码组件 实现和服务端的 验证码生成、验证 功能实现，接下来为登录接口整合人机验证功能。

登录接口 /admin/login 其实也是现成的，只是之前没有人机验证，接下来的工作哪怕扫地阿姨都能轻松完成，但是 AI 给我拉了坨大的，如果不是有人工逐行 review，这次生成的代码会导致：重大系统漏洞且开发者还自我感觉良好。

提示词：

1. 登录页发起登录请求前，调起点选验证码组件
2. 携带验证码组件提供的 验证数据 请求登录接口
3. 服务端登录接口的控制器内对点选验证数据进行复验

大的来了，阅读过之前文章的朋友都知道，我一般是不上图的，但为防止读者认为我是编的，我截图了 AI 的输出：

最终完整代码如下：

是的，先查用户名、检查状态账号、验证密码，最后才检查了人机验证码是否正确。

聪明的读者已经明白了，黑客根本不需要提交正确的人机验证码，就能通过接口的返回确定密码是否正确，等黑客确定了正确的密码，然后从容的打开浏览器，输入账号密码，人工点选验证码，完成登录，好好的登录接口，被写成了正确密码测试接口。

以上就是前三篇，感谢阅读，也欢迎使用我们的开源后台：github.com/ai-go-hub/a…

还剩 交叉验证、无需妥协与超预期、局限与低于预期 三章，见下一篇