你是否也经历过这样的绝望——面对同一个AI，别人能让它写出惊艳的代码，而你的AI却常常答非所问、漏洞百出？在十三Tech的一年半实践中，我从"人工智障"的抓狂阶段，进化到了AI像"专家"一样心有灵犀。秘密不在AI本身，而在我和你"说话"的方式完全不同。
大家好，我是十三！
用AI辅助编程的这一年半，我走过一条从绝望到惊喜的进化之路。刚开始，我天真地把AI当"许愿池"，结果得到漏洞百出的代码；后来我学会给AI"提工单"，效率大增但遇到瓶颈；再后来我把AI当"结对专家"，产出质量质的飞跃；直到最后，我把需求沉淀成可复用的"规则集"，AI每一次输出都像出自资深开发者之手。
这篇文章，是我四个阶段的完整进化史，以及帮你跳过所有深坑的独门心法。
第一阶段：AI是"许愿池"，而我是"听天由命"的赌徒
刚开始，我的Prompt是这样的：
"帮我用Go写个文件上传功能。"
我天真地以为AI无所不能，结果它给了我一段漏洞百出的代码，别说并发了，连基本的错误处理都没做。我骂骂咧咧地改了半天，心想："这玩意儿，真不靠谱！"
这就是第一个陷阱：把AI当"许愿池"，把结果交给运气。 你会发现，AI时灵时不灵，你对它的信任也忽高忽低，完全无法把它纳入稳定的生产力工具。
第二阶段：AI是"工具人"，而我是只会"派活儿"的包工头
我很快进化到第二阶段：学会了给AI"提工单"，附上具体的上下文。
"请参考我项目中的
storage/local.go文件，为它补充完整的单元测试。"
这一下，AI的产出质量稳定多了。我开始把它当成一个"工具人"，让它干各种脏活累活。那段时间，我效率大增，甚至有点小得意。
但很快，我又撞墙了。
我的"AI工具人"能完美执行明确的指令，可一旦我让它干点有"创造性"的活儿，比如"设计一个更优雅的架构"或"更有创意地优化这段代码"，它给我的答案就变得非常空洞和模板化。
我痛苦地意识到，我一直在把它当一个流水线工人，而不是一个能激发我灵感的"人"。
第三阶段：AI是"结对专家"，而我是"打破砂锅"的面试官
为了突破瓶颈，我开始琢磨怎么和AI"深度对话"。我不再满足于"是什么"，而是开始追问"为什么"。我尝试像面试官一样，去考察它的"技术品味"。
"你现在是一位资深的Go架构师。我需要你为我司的电商系统设计一个"优惠券服务"，请给出你的技术选型、API设计和核心数据表结构，并详细阐述你为什么这么设计，以及你考虑了哪些潜在的风险。"
我开始给AI赋予角色（Persona）、要求它提供多种方案并对比优缺点（Refinement）。AI从一个听话的"工具人"，摇身一变成了我的"结对技术专家"。
认知再次升级：AI的水平，取决于我提问的深度。 我问得越深，它反馈的价值就越大。
第四阶段：AI是"系统组件"，而我是"规则"的制定者
到了这个阶段，我已经能和AI高效协作了。但我又有了新的"不满"：每次开启一个新的对话，我都得像祥林嫂一样，重复声明一遍我的要求："你要用Go，要注意并发安全，你的代码风格要简洁……"
这太低效了！于是，我开始探索更高阶的玩法：将我的要求，沉淀成一套可复用的"规则集"（Rule）。
project-engineering-spec.md
- API规范: 所有对外API必须遵循RESTful风格，错误响应体必须符合规范。
- 代码规范: 所有Go代码提交前，必须通过
golangci-lint检查。- 数据库规范: 所有MySQL表名必须使用复数形式，字段名使用蛇形命名法（snake_case）。
- Git规范: Commit Message必须遵循
feature/bug/temp:的格式。
我把这套"工程规范"配置成AI的默认规则。从此，AI的每一次输出，都像是出自我们团队中一个训练有素的资深开发者之手，稳定、可靠、且心有灵犀。
核心进化：我们不再是AI的使用者，而是AI工作流的"设计者"。
我的独门心法：PRIDE提问框架
复盘这四个阶段，我把那些最精华、最高效的提问技巧，从无数次失败和成功中，千锤百炼，提炼成了一个简单好记的框架，我称之为 "PRIDE" Prompt框架。
这套私房秘籍，就是我的AI从"人工智障"蜕变为"专家"的秘密。它代表着我们工程师的骄傲，也涵盖了一个优质Prompt应该具备的五个核心要素：
type GoodPrompt struct {
Persona string // 角色定义
Requirement string // 需求描述
Information string // 信息注入 (上下文)
Demonstration string // 范例演示
Expectation string // 期望定义 (输出格式)
}
**P - Persona (角色定义) **
"你是谁？" 这是驯服AI的第一步。先给它戴上"紧箍咒"，定义它的身份。
- 智障模式: "写个Redis缓存逻辑。"
- 专家模式: "你是一位资深的Go架构师，精通缓存设计模式，尤其擅长处理高并发场景下的缓存穿透和雪崩问题。"
**R - Requirement (需求描述) **
"你要做什么？" 拒绝模糊，拥抱明确。把你的需求像写技术文档一样写清楚。
- 智障模式: "优化下代码。"
- 专家模式: "请重构以下
GetUser函数，解决N+1查询问题。目前的实现在for循环里多次查询数据库，请用一次WHERE user_id IN (...)的查询来替代它。"
**I - Information (信息注入) **
"这是你需要的所有资料。" 别让AI猜。把它完成任务需要的所有上下文，一次性"喂"给它。
- 智障模式: (假设AI是你肚子里的蛔虫)
- 专家模式: "为了帮助你完成重构，以下是相关的代码：\n\n
go\nfunc GetUser(...) {...}\n"
**D - Demonstration (范例演示) **
"照这个学，照这个做。" 与其费力描述，不如给个范例。AI的模仿能力，超乎你想象。
- 智障模式: "注释要写好点。"
- 专家模式: "请遵循下面的注释规范。例如：\n\nGood Case:\n
go\n// GetUser retrieves a user by their ID.\nfunc GetUser(id int) (*User, error) {...}\n"
**E - Expectation (期望定义) **
"我要这样的结果。" 明确告诉AI，你期望它以什么样的格式、什么样的风格输出。
- 智障模式: (让AI随意发挥，然后对着结果骂街)
- 专家模式: "请以Markdown格式输出。首先，提供重构后的完整代码。然后，用表格对比优缺点。最后，解释你的核心思路。"
展望下一阶段：从"对话"到"工作流集成"
我个人认为在未来的1到2年的时间里Prompt Engineering将进入下一个阶段，将不再是我们与AI之间一次次的'对话'，而是将AI无缝地集成到我们熟悉的工程工作流中。
想象一下，未来的git命令可能会变成这样：
# 当前：手动暂存，手动写commit message
git add .
git commit -m "feature: add user login API"
# 未来：AI自动生成commit message
git commit --ai
# AI分析代码变更，自动生成 -> "feat(auth): add user login API with JWT support"
或者，未来的Code Review流程：
"我们不再是手动评论，而是可以对一段代码@一个AI专家：'@GoConcurrencyReviewer，请检查这段代码是否存在数据竞争风险。' AI会自动运行检测工具、分析逻辑，然后给出一个专业的审查报告。"
这个阶段，AI不再是一个独立的"聊天窗口"，而是变成了我们IDE、Git、CI/CD流水线中一个个可以被调用的、专业的"函数"或"服务"。我们对AI的"提问"，也从自然语言，演变成了对这些AI服务的"API调用"。这，可能才是离我们最近、也最激动人心的未来。
总结
与AI协作的这一年半，我经历了四个阶段的进化：
- 第一阶段：许愿池——把AI当万能工具，结果交给运气，产出质量极不稳定
- 第二阶段：工具人——学会给AI提工单、附上下文，效率大增但遇到创造力瓶颈
- 第三阶段：结对专家——赋予AI角色，要求多方案对比，AI成为真正的技术搭档
- 第四阶段：规则制定者——将需求沉淀为可复用的规则集，AI输出稳定如资深开发者
核心心法：AI的水平，取决于你提问的深度。当你开始认真地"教"AI时，你思考问题的角度也会变得前所未有的清晰。
十三Tech将持续分享AI协作的进阶方法论，帮助每一位开发者驯服自己的AI搭档。
关于十三 Tech 资深服务端研发，AI实践者，专注分享真实可落地的技术经验。 相信AI是程序员的最佳搭档，而非替代者。 让每一个程序员都能写出更优雅的代码！
联系方式：569893882@qq.com GitHub：@TriTechAI