同样的 AI，有人能让它写出靠谱的代码，有人却总得到答非所问的结果。差别通常不在工具，而在你怎么跟它说话。

大家好，我是十三！欢迎来到十三Tech。

用 AI 辅助编程这一年半，我走过一条慢慢进化的路：一开始把 AI 当「许愿池」，得到的代码漏洞百出；后来学会给它「提工单」，效率上来但撞到瓶颈；再后来把它当「结对专家」，产出质量明显上了个台阶；到最后，把要求沉淀成一套可复用的「规则集」，AI 每次输出都接近一个训练有素的资深开发者。

这篇文章把四个阶段、以及一个把优质 Prompt 拆成五要素的框架梳理一遍。

和 AI 协作的四个阶段

第一阶段：把 AI 当许愿池

刚开始我的 prompt 是这样的：

帮我用 Go 写个文件上传功能。

我以为 AI 无所不能，结果它给了一段漏洞百出的代码——别说并发，连基本错误处理都没做。改了半天，心想「这玩意儿不靠谱」。

第一个陷阱就在这：把结果交给运气。 AI 时灵时不灵，你对它的信任也跟着忽高忽低，没法把它当成稳定的生产力工具。

第二阶段：学会给 AI 提工单

很快我进化到第二阶段：给 AI「提工单」，附上具体上下文。

请参考我项目里的 storage/local.go，为它补完整的单元测试。

这一下产出质量稳定多了。我开始把它当「工具人」，让它干各种脏活累活，效率大增。

但很快又撞墙了。 它能完美执行明确的指令，可一旦让它做点需要判断的事——比如「设计一个更优雅的架构」或「更有创意地优化这段代码」——答案就变得空洞、模板化。

我意识到，自己一直把它当流水线工人，而不是一个能激发灵感的搭档。

第三阶段：把 AI 当结对专家

为了突破，我开始琢磨怎么和 AI「深聊」。不再满足于「是什么」，而是追问「为什么」，像面试官一样考察它的技术品味。

你现在是一位资深 Go 架构师。请为我们的电商系统设计一个「优惠券服务」：给出技术选型、API 设计和核心表结构，并说明你为什么这么设计、考虑了哪些潜在风险。

我开始给 AI 赋予角色（Persona），要求它给多种方案并对比优缺点（Refinement）。它从一个听话的工具人，变成了我的结对技术专家。

认知又升了一级：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 工作流的设计者。

PRIDE：把优质 Prompt 拆成五要素

复盘这四个阶段，那些最管用的提问技巧，可以归成一个框架，我叫它 PRIDE——正好覆盖一个优质 Prompt 该有的五个要素：

PRIDE 提问框架

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 是你肚子里的蛔虫）
  • 清晰：附上相关代码，比如 func GetUser(...) {...} 的现有实现。

D — Demonstration（范例演示）：「照这个学。」与其费力描述，不如给个范例——AI 的模仿能力很强。

  • 模糊：「注释写好点。」
  • 清晰：给一个 Good Case，比如 // GetUser retrieves a user by their ID.

E — Expectation（期望定义）：「我要这样的结果。」明确输出格式和风格。

  • 模糊：（让 AI 随意发挥，然后对着结果骂街）
  • 清晰：「用 Markdown 输出：先给重构后的完整代码，再用表格对比优缺点，最后解释核心思路。」

下一个阶段：从对话到工作流集成

接下来一两年，Prompt Engineering 会进入下一个阶段：不再是和 AI 一次次「对话」，而是把 AI 集成进工程工作流。

想象一下，未来的 git 可能是这样：

# 现在：手动暂存、手写 commit message
git add .
git commit -m "feature: add user login API"

# 未来：AI 分析变更，自动生成 message
git commit --ai
# → "feat(auth): add user login API with JWT support"

Code Review 也一样：对一段代码 @ 一个 AI 专家——「@GoConcurrencyReviewer，检查这段代码有没有数据竞争」——它会自动跑检测工具、分析逻辑，给出专业审查报告。

到这个阶段，AI 不再是一个独立的聊天窗口，而是 IDE、Git、CI/CD 流水线里一个个可调用的「函数」或「服务」。我们对 AI 的「提问」，也从自然语言，演变成对这些 AI 服务的 API 调用。

写在最后

这一年半，我和 AI 的协作走了四个阶段：

  • 许愿池：把 AI 当万能工具，结果交给运气，产出不稳。
  • 工具人：学会提工单、附上下文，效率大增但缺创造力。
  • 结对专家：赋角色、要方案对比，AI 成为真正的技术搭档。
  • 规则制定者：把需求沉淀成可复用规则集，输出稳定如资深开发者。

一句话总结：AI 的水平，取决于你提问的深度。 当你开始认真地「教」AI，你自己思考问题的角度也会变得清晰得多。

关于十三 Tech

资深服务端研发工程师，AI 编程实践者。专注分享真实的技术实践经验，相信 AI 是程序员的最佳搭档。