跳转至

集成 AI 工具 — 提示词的结构、五条纪律与一张责任清单

这一章讲什么: 全书辅线(AI 怎么用)的正面总攻:提示词怎么写、生成代码 怎么验收、调试重构怎么借力、以及什么时候绝不能信它。 它在全书链条里的位置: 前面八章里 AI 都是以「某一节的辅助者」出场, 这一章把它单独摆上桌:工具的能力边界、使用纪律、伦理责任。 如果说前八章教你「用 Go 造系统」,这一章教你「造系统时那只 AI 的手该放哪」。 主线例子(贯穿本章): 同一件事——「写一个并发安全的内存缓存」—— 三次提示的进化: vague 版 → 具体版 → 模板版,看输出质量如何随提示结构变化。

1. 顶层全景:本章的一张地图

  ① 提示的语法(§2):四个要素、三个模板、三个工具三种写法
  ② 生成的验收(§3):AI 是脚手架引擎,五步质量保证兜底
  ③ 调试与重构借力(§4):栈轨迹翻译、静态分析聚类、模式级重构
  ④ 性能优化借力(§5):画像解读 + 四个微优化例
  ⑤ 责任清单(§6):许可证 ▪ 幻觉 ▪ 隐私 ▪ 过度依赖 —— 什么时候绝不能信

原书在章首钉死了基调:AI 模型是模式识别器,不读心—— 「它们从你给的文字信号里推断意图」1。所以提示词工程的本质不是「咒语」, 是把意图表达清楚——这也是本章标题(Prompting)的真正含义。

2. 提示的语法:四要素、三模板、三工具

2.1 四要素(原书列的清单)

要素 回答的问题 缺了它的后果
Task(任务) 要造什么、修什么、解释什么 输出泛泛
Context(上下文) 现有代码、架构约束、Go 版本、并发考虑 代码接不进你的系统
Constraints(约束) 性能要求、惯用法、库偏好、错误处理风格 风格漂移、返工
Format(格式) 只要代码?先解释?逐步推理?给几个方案? 答非所问

原书的判据很直白:「Without these elements, AI tools often produce generic or suboptimal code.」2

2.2 主线例子三次进化

第一次(vague,反面教材):

「Write a Go function to process orders.」

——会得到一段语法正确、跟你系统毫无关系的玩具代码。

第二次(具体,单要素加强):

「Write a Go function ProcessOrders that takes a slice of Order structs, validates required fields, logs invalid entries, and inserts valid records into a PostgreSQL database using the database/sql package. Use context.Context for cancellation and return descriptive errors.」

——函数名、输入、校验、日志、库、取消、错误风格全部点名3。这是原书给的 正面例,质量立刻上一档。

第三次(模板,全要素):

Task: 写一个并发安全的内存缓存 Context: 用在 HTTP 服务的 handler 里,多 goroutine 并发读写 Constraints: 用 sync.RWMutex;条目带过期时间;后台 goroutine 定期清理; 所有方法收 context.Context;不许有全局变量 Format: 完整实现 + 注释,再给一段用法示例

同一件事,三个版本——输出质量的差别不在模型,在你。(后两个提示的原型 均出自原书 §2 的示例4。)

2.4 三个工具,三种提示形态

ChatGPT(对话式): 吃完整句子。四条技巧5:

  1. 显式需求——上面第二次进化就是;
  2. 贴现有代码/约束——「这是我的 UserRepository 接口,改成全方法收 ctx、 用预编译语句、不许引外部 ORM」;
  3. 要对比和权衡——「给两种 worker pool 写法,比较高竞争下的性能特征」 ——IDE 工具做不到的事,对话式独有;
  4. 要逐步推理——「一步步解释这个 goroutine 模式为什么竞态,再给修复版」。

GitHub Copilot(行内补全): 不吃长句,吃意图饱满的注释 + 函数签名。 原书给了标准形状6:

// FetchUser loads a user from PostgreSQL by ID.
// Requirements:
// - Use context.Context
// - Return sql.ErrNoRows when the user is not found
// - Use prepared statements
// - Map fields into the User struct
func FetchUser(   // 签名一打,Copilot 自动补全函数体

更妙的是示范效应:项目里先写一个标准错误包装器,之后 Copilot 在新函数里 会照着用——「提示」在这里变成塑造代码库风格的策略6。

Amazon Q Developer(云感知): 提示里点名云上下文,它就用 AWS 原生写法 ——「生成一个读 DynamoDB 的 Go Lambda,支持 ctx 取消,返回结构化错误」7。

2.5 三个可复用模板(原书给了就照抄)

  1. Task + Context + Constraints + Format——万能模板,例:「重构这个 handler 用 ctx 版数据库操作;签名不变;参数化查询;结构化 JSON 错误;只给代码。」8
  2. Explain → Generate → Improve 循环——先解释、再生成、再按约束改进, 「模仿资深工程师的评审循环」9;
  3. 诊断模板——「这是错误和代码。解释根因,给个修复,再给一个更优实现。」10

三个反模式(原书点名):没具体性的、把不相关任务混在一起的、没有约束的 (「让它快点」——多快?)11

2.6 反例与正例的对照(原书两两成对)

把原书的反模式和对应好提示摆在一起,差距一眼可见:

反例(别这么写) 正例(换成这样) 差在哪
「Write some Go code for caching.」 「写一个并发安全缓存:sync.RWMutex、过期清理、ctx 支持、无全局变量。」 有没有约束
「Build a worker pool and also write docs for my API.」 拆成两次提问,一次一个任务 一次只干一件事
「Make this faster.」 「在保持分配不增的前提下,把这个循环的耗时降一半。」 「快」有可验收的定义
只贴报错 报错 + 相关代码 + 期望行为 + 实际行为 信息密度

第四条是实践里最常见的缺口:报错信息本身不包含你的代码,AI 只能猜。 贴上下文不是礼貌,是输入质量——第 1 章「LLM 不读心」的又一次兑现。

2.7 同一件事,三个工具三种写法(原书三连)

同一个「并发缓存」需求,原书给了三个工具的提示形态,对照着看:

  • ChatGPT(对话): 一段话讲清全部要求,它回多文件实现 + 解释;
  • Copilot(注释): 
    // NewCache creates a concurrency-safe cache with expiration.
// Use RWMutex. Launch a background goroutine to clean expired
// entries every interval.
    写完签名,函数体自动来;
  • Amazon Q(云语境): 加一句「for an AWS Lambda function, no global state, DynamoDB fallback」,输出自动带上 AWS SDK 的写法。

要点:工具越靠近编辑器,提示越靠近代码;工具越靠近对话,提示越靠近需求文档。 混着用(拿对话式长提示去喂行内补全)是新手最常见的浪费。

3. 生成的验收:AI 是脚手架引擎

原书给 AI 的定位一句话:「human-led architecture plus AI-generated boilerplate」 ——人定架构,AI 出脚手架12。生成的正确姿势是迭代反馈环而不是一锤子13:

  ① 说清目标(特性、约束、性能预期、上下文)
  ② 生成初版
  ③ 自己审:低效?漏边界?反模式?
  ④ 点名改进:「改成 sync.Pool」「修潜在竞态」「改进错误包装」
  ⑤ 落地:go vet ▪ golangci-lint ▪ 测试全过,再合入

质量保证五件套(对着 AI 产物逐件上)14:

工具/手段 查什么
go vet / staticcheck / gosec(安全专用) 静态毛病与安全隐患
Benchmark AI 声称的「优化」要用真数据验
单元测试(让 AI 给自己的代码生成测试) 覆盖率与自证
go test -race 并发代码生死线
项目一致性 命名、依赖、接口兼容

原书的比喻值得记住:把 AI 当初级工程师——快、勤快、有创造力, 但每一件产出都要 review14。还可以让 AI 审自己:「Review the following Go code for concurrency issues」——创作和验证双层都用它15。

4. 调试与重构借力

调试三招16:

  1. 栈轨迹翻译——贴 panic trace,它指出最深的那帧:OrderService.Process(0x0, …) 的接收者是 nil → 构造路径缺了初始化。给的是假设,验证靠你加日志/断点;
  2. 静态分析聚类——go vet/staticcheck/gosec 几十条警告贴进去, 让它按主题分组(未查错误、内存低效、ctx 误用、SQL 注入风险)再逐个给修法;
  3. 日志分诊——「为什么运行 5 分钟后延迟飙升」→ 它列嫌疑:goroutine 无界累积、 rows.Close() 忘了关、慢消费者背压。

重构四板斧(与第 03 章互补):长函数拆助手、乱目录理层次(/domain 逻辑挪 /internal、只在该有的地方引接口)、散兵游勇收编模式(重复 SQL → repository 方法、 散落 goroutine → 受管 worker pool)、性能导向改造(预分配、sync.Pool、锁减粒度)17。

结对体验: Copilot 实时看到你在写低效的 nil-slice append,主动建议 items := make([]Item, 0, len(rows))——但每一条建议都要当场接受或拒绝, 目标是智能协作,不是盲自动化18。

代码库导师: 「解释请求怎么穿过 handler-service-repository」「这文件可能的 竞态有哪些」——新人 onboarding 的 comprehension layer19。

4.1 让 AI 当代码库导师:五个 onboarding 问法

「代码库导师」是原书 debug/refactor 之外最被低估的用法——新人(或三个月后的 你自己)面对陌生代码库时,先把这些问题问一遍,再读代码验证:

  1. 「解释请求怎么穿过这个 handler-service-repository 结构,每层各干什么。」
  2. 「这个包里哪些类型是被外部依赖的?改动哪个接口会影响最多调用方?」
  3. 「这个文件可能的竞态有哪些?作者用了什么同步手段?」
  4. 「画一下这条数据从进来到落库的完整路径,标出每一步可能失败的地方。」
  5. 「如果我要加一个新端点,照现有模式该动哪几个文件?」

用法边界:AI 的答案是一张地图草案,不是地形本身——它答「接口在哪」, 你要打开文件确认「接口真长这样」;它标出的失败点,对着第 04 章的错误链走一遍 才算数。原书原话的意思没变:它提供 comprehension layer(理解层), 减少的是上手时的认知疲劳,不是免除你读代码。

4.2 重构对话的三段式(原书方法的完整形态)

把 §2.5 的「Explain → Generate → Improve」落成一段真实对话的形状(演示):

  你:「解释一下这个 200 行的 ProcessReport 在干什么,分几个阶段。」
  AI:(给出阶段划分——先核对它说对了没有)
  你:「按这个划分拆成函数,签名保持向后兼容,错误用我们项目的 wrap 风格。」
  AI:(给出拆分——跑 go vet 和测试)
  你:「第二个函数还是太长,而且它里面的 map 没加锁,我们服务是多实例的,再改。」
  AI:(给出改法——再跑 -race)

三段各有一次人的动作:核对理解、跑测试、指出具体缺陷。省掉任何一段, 质量就退回「AI 自己写自己爽」。

5. 性能优化借力:画像解读 + 四个微优化例

AI 在性能上的正当位置:解读画像、提假设、写候选实现; pprof 和 benchmark 负责判决20。原书的例子:

  • 锁竞争例:profile 显示 map 锁占 38% 运行时间 → AI 建议分片 map、缩锁宽、 原子更新、加缓存;
  • 例一至例四的通用形状:channel 无缓冲卡生产者 → 加缓冲;循环里 go process(item) → 固定池;锁包了整个循环 → 本地算完只锁加法; 每轮迭代 make([]byte, 1024) → sync.Pool21。

每一例都要复读第 08 章的判据:AI 出假设,数字出判决。

6. 责任清单(全书最硬的一节)

原书用了全章近三分之一的篇幅讲边界——这在同类书里少见,也是最值钱的部分。

幻觉与过时 API: 语法对、逻辑错的代码;并发原语用错(竞态的 channel 用法)、 不安全的默认值;用废弃的 io/ioutil、旧版库。对策:拿文档或 go doc 逐条核22。 过度自信偏差:AI 错得理直气壮——「像审初级工程师一样审它,别当权威」23。

安全与隐私: 往提示里贴代码 = 把代码送出你的机器。三条纪律: 敏感数据先脱敏(把真实值换成假的、但格式一致的替代品,如把真手机号换成 138**0000);机密代码只用自托管/本地模型;遵守组织的数据留存政策24。 AI 自己会生成硬编码凭证(把本该可配置的值写死在代码里)、弱哈希、不充分的输入校验——安全审计一件不能省**25。

许可证与归属: 谁拥有 AI 生成的代码?各家服务条款不同;早期 AI 生成过 近似抄袭的片段。纪律:没许可别把公司代码贴进公有 AI;输出过一遍开源合规流程; 提交历史里记录 AI 的贡献——进生产的代码,无论谁写的,责任都是你的26。

过度依赖与技能退化: AI 越能干,人越要警惕失去:系统思维、算法推理、 并发排障的手感。原书的处方:用 AI 增强学习,而不是替代思考27。

AI 搞不定什么(原书单): 深度耦合的多模块系统;微服务全景;重度接口/ 泛型/自定义类型的项目;goroutine 生命周期微妙的并发系统—— 这些场景里,架构判断只能是人28。

负责任使用七条(原书收尾,照抄级别)29:

  1. 把 AI 当协作者,不当权威;
  2. 并发密集、性能关键处必审;
  3. 提示里不放私密/敏感/受监管数据;
  4. 生产代码记录 AI 参与;
  5. 核许可证与合规;
  6. 「看着对」也要做安全和性能审计;
  7. 用 AI 学,不用 AI 替。

判断(我们的,不是书里的): 这一章最该带走的是它的不对称: 前半章(提示技巧)两年就会过时——工具换代,技巧重来; 后半章(责任清单)十年后还成立——幻觉、隐私、责任归属不是某个模型的毛病, 是「概率生成器」这个物种的属性。读这章请把力气花在后者。 如果错,会错在: 如果未来的工具把「验证」也自动化了(自动跑测试、自动证明), 责任清单会大幅缩短——但「进生产谁负责」这一条,只要法律责任还在人身上, 就缩不掉。

7. 可带走的

  1. 提示四要素:Task / Context / Constraints / Format,缺一个输出降一档。
  2. 三模板:万能模板、Explain→Generate→Improve、诊断模板(错误+代码→根因+修复+更优版)。
  3. 三工具三写法:ChatGPT 吃句子、Copilot 吃注释+签名、Amazon Q 吃云上下文。
  4. Copilot 的示范效应:先写一个标准件,它会照着续——提示是风格策略。
  5. 生成五件验收:vet/staticcheck/gosec、benchmark、测试(让 AI 自产)、-race、项目一致性。
  6. 「AI 当初级工程师」——快而勤,件件要审。
  7. 调试三招:栈轨迹翻译、静态分析聚类、日志分诊——全是假设,验证在人。
  8. 性能协作的铁律:AI 出假设,pprof/benchmark 出判决。
  9. 幻觉对策:对照 go doc;过度自信偏差:错得理直气壮。
  10. 隐私三纪律:脱敏、机密用本地模型、守组织政策。
  11. 许可证:输出过合规流程,提交历史记 AI 贡献,责任永远在你。
  12. AI 的四个禁区:深耦合模块、微服务全景、重泛型项目、微妙并发——架构判断只能是人。

8. 原文地图

主题 原书章 原文位置
模式识别器、不读心 9. Integrating AI Tools in Go Development text/19-ch09-9-integrating-ai-tools-in-go-development.txt:74(搜「pattern recognizers」)
四要素 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:79(搜「The Task: What needs to be built」)
ChatGPT 四技巧 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:89(搜「Prompting Techniques for ChatGPT」)
Copilot 意图注释 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:134(搜「Writing Effective Prompts for GitHub Copilot」)
Amazon Q 云上下文 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:171(搜「As of the latest updates」)
三模板 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:194(搜「Prompt Structuring Patterns」);诊断模板见 :218
三反模式 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:224(搜「Avoiding Anti-Patterns」)
脚手架引擎定位 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:277(搜「AI as a Scaffolding Engine」)
迭代反馈环 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:343(搜「Iterative Coding Workflows」)
质量保证五件套 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:383(搜「Quality Assurance」);初级工程师比喻见 :393
栈轨迹翻译 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:428(搜「AI-Assisted Debugging Workflows」)
静态分析聚类 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:37(搜「Static and Runtime Code Analysis」)
重构四板斧 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:490(搜「AI-Assisted Refactoring」)
结对与代码库导师 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:532(搜「Pair Programmer」)text/19-ch09-9-integrating-ai-tools-in-go-development.txt:548(搜「Learn from the Codebase」)
性能四例 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:731(搜「Performance Refactoring Examples」)
幻觉与过时 API 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:809(搜「Hallucinations」)text/19-ch09-9-integrating-ai-tools-in-go-development.txt:823(搜「Outdated API」)
隐私三纪律 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:837(搜「Security and Privacy Risks」)
许可证与归属 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:782(搜「Ownership, Licensing」)
过度依赖 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:883(搜「Skill Degradation」)
AI 的禁区 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:891(搜「Limitations of AI」)text/19-ch09-9-integrating-ai-tools-in-go-development.txt:900(搜「Large Codebases」)
负责任七条 同上 text/19-ch09-9-integrating-ai-tools-in-go-development.txt:916(搜「Guidelines for Responsible Use」)

  1. 出处:「9. Integrating AI Tools in Go Development」第 72–88 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:74,搜「pattern recognizers」)。原文:「AI models are pattern recognizers… They do not read minds; instead, they infer intent from the textual signals given to them.」 ↩

  2. 出处:同章第 74–88 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:79,搜「The Task: What needs to be built」;「Without these elements」见 :86)。 ↩

  3. 出处:同章第 94–103 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:94,搜「Provide Explicit Requirements」)。ProcessOrders 提示为原书原例。 ↩

  4. 出处:同章第 199–222 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:199,搜「Task + Context + Constraints + Format」);缓存提示的部件(并发安全缓存、RWMutex、过期、后台清理)见 :236 与text/19-ch09-9-integrating-ai-tools-in-go-development.txt:305–341。 ↩

  5. 出处:同章第 89–132 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:89,搜「Prompting Techniques for ChatGPT」;四种策略逐条见 :94–130)。 ↩

  6. 出处:同章第 134–167 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:134,搜「Writing Effective Prompts for GitHub Copilot」;意图注释例见 :141;示范效应见 :161)。 ↩↩

  7. 出处:同章第 169–192 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:171,搜「As of the latest updates」;Lambda 提示见 :177)。 ↩

  8. 出处:同章第 199–209 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:200,搜「Template:」)。 ↩

  9. 出处:同章第 211–216 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:211,搜「Explain + Generate + Improve」)。 ↩

  10. 出处:同章第 218–222 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:218,搜「Diagnostic Prompt Pattern」)。 ↩

  11. 出处:同章第 224–230 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:224,搜「Avoiding Anti-Patterns in Prompting」)。 ↩

  12. 出处:同章第 277–297 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:277,搜「AI as a Scaffolding Engine」)。「human-led architecture plus AI-generated boilerplate」见 :294。 ↩

  13. 出处:同章第 343–364 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:343,搜「Integrating AI into Iterative Coding Workflows」)。 ↩

  14. 出处:同章第 383–399 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:383,搜「Quality Assurance for AI-Generated Go Code」)。「treated as a junior developer」见 :393。 ↩↩

  15. 出处:同章第 395–399 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:395,搜「audit its own output」)。 ↩

  16. 出处:同章第 428–488 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:428,搜「AI-Assisted Debugging Workflows」;panic trace 例见 :440)。 ↩

  17. 出处:同章第 490–531 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:490,搜「AI-Assisted Refactoring」;四板斧见 :496–530)。 ↩

  18. 出处:同章第 532–546 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:532,搜「Pair Programmer」;make 预分配建议见 :540)。 ↩

  19. 出处:同章第 548–558 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:548,搜「Learn from the Codebase」)。 ↩

  20. 出处:同章第 707–730 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:707,搜「Measuring, Profiling, and Validating」;38% 锁例见 :723)。 ↩

  21. 出处:同章第 731–768 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:731,搜「Performance Refactoring Examples」;四例见 :732、:744、:750、:765)。 ↩

  22. 出处:同章第 809–829 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:809,搜「Hallucinations」;io/ioutil 例见 :825)。 ↩

  23. 出处:同章第 831–835 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:831,搜「Overconfidence Bias」)。 ↩

  24. 出处:同章第 837–846 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:837,搜「Security and Privacy Risks」)。 ↩

  25. 出处:同章第 848–855 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:848,搜「Security Anti-Patterns」)。 ↩

  26. 出处:同章第 782–807 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:782,搜「Ownership, Licensing, and Attribution」)。 ↩

  27. 出处:同章第 883–889 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:883,搜「Skill Degradation」)。 ↩

  28. 出处:同章第 891–914 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:891,搜「Limitations of AI」;大型代码库四项见 :900)。 ↩

  29. 出处:同章第 916–929 段(text/19-ch09-9-integrating-ai-tools-in-go-development.txt:916,搜「Guidelines for Responsible Use」)。 ↩