完工撒花🎉🎉🎉~
两个月了，一天 14-16 小时，单休；恭喜自己学会了 Golang 撒花🎉🎉🎉~
实战项目已达商业可用级别，而且完全免费开源，求 star：ai-go-admin（github | gitee），可视化CRUD真的非常强大，欢迎在线体验一下：demo.ai-go-hub.com/#/admin。
接下来就是纯纯的干货了，我将心法分为 核心理念、沟通技巧、安全、交叉验证、无需妥协与超预期、局限与低于预期 六章，全部是实战结论和经验；由于文章较长，我分为了上下两篇，本篇含后三节，前三节在此。
交叉验证
交叉验证说白了就是使用不同的模型 / Agent 独立产出结果然后汇总，最常见的用法是：同一份提示词，同时发给不同模型 / Agent，各自独立输出，之后人工聚合结果。
我一般是确定某个功能的技术方案之前，把需求写好发给不同的 AI，让 AI 推荐一下社区有无现成的标准库，有无惯例、标准实现等；AI 是有幻觉的，它可能瞎编，所以我一般还会让它提供证据，比如 GitHub 的 star 数量及仓库链接。
你还可以额外开个会话窗口，复制所有 AI 的回答，让它最终整理一遍，并提供不同方案的置信度分数，然后你再看，只是这样用一定要保持上下文隔离和干净，避免 AI 的从众效应。
第二常用的就是 CC / Codex 里边换个模型，让它扫一下最近提交的代码，看看有无优化空间，比如：交叉验证AI模型的工作成果。
还有一种终极的用法，多个模型定义好不同的身份，准备好上下文，然后让他们辩论，当然这种有点太花哨了，我没有使用过。
无需妥协与超预期
无需妥协
有时候就像快递的最后一公里：功能已经很好的完成了，但还有一点优化空间，而且这点优化一般还比较麻烦；
人类的精心是有限的，以前的话，这一点优化往往就是放弃了，或者写个TODO注释（可能永远都是个TODO😂）。
而在AI时代，我们只需要多发送一条信息，举例如下：
在一个后台请求中，我们已经读了 tokens 表、验权读了 admin_rules；后面为了个后台日志的标题字段，我们又加了两个 SQL 查询权限节点的标题（如：角色组管理 > 编辑），父级子级标题，一共查两次，有了标题之后，管理员日志的可读性会高很多。
但这非常不合适，毕竟只是日志而已，所以这里直接让 AI：在单条 SQL 查询中准备好标题
go
fmt.Sprintf(
"SELECT c.title, COALESCE(p.title, '') AS parent_title FROM %s AS c LEFT JOIN %s AS p ON p.id = c.pid WHERE c.name = ?",
tableName, tableName,
)下次再遇到这种想要妥协的时候，记得其实只需要多发一句话。
超预期
其实很多开发者用AI久了，都会遇到很多超预期的情况，比如：
实战 Blog 的第 24 篇：一行提示词抽出完美网站首页。
再比如随时可以让 AI 罗列所有可能的解决方案，这一点其实是最常用的。
还有 AI 默默为你完成的代码优化，以下这些修改，不是我让它改的，提示词没有提及任何需要让它改动或是优化的词语，都是它自己在整理过程中进行的修改，AI 版本好在哪里，欢迎大佬们评价：
ts
const { oldIndex, newIndex } = evt
// 交换变量，原版
[state.fileList[oldIndex], state.fileList[newIndex]] = [state.fileList[newIndex], state.fileList[oldIndex]]
// AI 版
state.fileList[newIndex] = [state.fileList[oldIndex], (state.fileList[oldIndex] = state.fileList[newIndex])][0]
ts
// 原版
const isImageType = () => props.type == 'image' || props.type == 'images'
// AI 版
const isImageType = computed(() => props.type == 'image' || props.type == 'images')局限与低于预期
这里谈的不是哲学问题，而是实战中遇到的一些局限和低于预期，还是直接举两个例子吧：
例一、静态登录页面仿制失败
不知道你有没有听说过之前比较火的：眨眼小人静态登录页，页面上的四个小人，会看向你的鼠标，输入密码时会捂住双眼或看向它处，挺有趣的，如下图：
这个登录页是 MIT 开源的，我们可以直接使用，仓库 README 还挂上了原仓库链接，感谢大佬。
我让 AI 帮我仿制一下这个登录页，而且直接提供了 gitee 链接，接下来请欣赏 AI 的成果：
说实话，都给我看笑了😂。后续是手动 clone 了项目源代码，然后只让 AI 进行微调实现了想要的功能。
本例原开发日志在：眨眼小人登录页制作
例二、迁移布局系统失败
我尝试直接让 CC 一次性将 BuildAdmin/web 的后台五种布局（默认、经典、左分双栏、顶侧双栏、单栏）全部 迁移 过来，源代码是 clone 好的，直接提供文件位置给到 AI。
最后花费 11 分钟，37 个文件新增/修改；说实话，总体还可以了，虽然不知道为什么只迁移了一种布局，但能打开，效果也不错。
但是，37 个文件是没法 review 的，这是一个灾难，而且初步检查就发现很多文件相对原来的做过修改，然后各个文件散布着未使用的导入、代码格式错误等。
所以说，那些说让 AI 直接将整个系统从 PHP 迁移至 Go 这类的，非常不靠谱，特别是带前端的系统，单纯的服务端，带单元测试的还会，直接迁移理论上问题不大？
AI 使用心法这就结束了，感谢阅读，也欢迎使用我们的开源后台：github.com/ai-go-hub/a...