拒绝“猜谜式”编程：从 Google PTCF 到 AI 编程五要素框架

前言：

在 AI 辅助编程（AI Programming）日益普及的今天，很多开发者发现：AI 写代码很快，但写出能用的代码很难。 往往是因为我们陷入了"模糊指令"的陷阱。

本文将剥离理论概念，直接通过对比案例和结构化图表，带你掌握基于提示词的 AI 编程 核心心法，重点解析 Google PTCF 框架 与AI 编程五要素通用写作框架。

1. 什么是提示词工程？

提示词工程 (Prompt Engineering) 并非高深莫测的玄学，它的本质是在用户意图 与模型能力之间建立一座桥梁。

核心认知 ：

提示词工程的核心思想与传统软件工程中的需求分析高度相似。

传统开发：向人类同事描述需求，对方有背景知识，可以主动追问。

AI 编程：向对技术极度敏感的大模型描述需求，它没有背景知识，无法主动追问，只能依赖你提供的文字工作。

因此，输入文本的内容、结构和细节，直接决定了模型的推理路径和最终输出。

2. 常用技术与 Google PTCF 框架

在动手之前，我们需要掌握一些基础战术。表1 列出了几种最常用的提示词技术：

表 1：常用提示词技术速查表

技术名称	核心思想	典型示例	适用场景
零样本提示	直接描述任务，不提供示例	"将下面这段代码的注释翻译为英文"	任务明确，AI 已有足够训练数据
少样本提示	提供 2~5 个输入-输出示例	先给出 2 个正确的函数命名示例，再要求 AI 命名新函数	需要固定输出格式或特殊风格
思维链提示	要求 AI 在给出答案前进行逐步推理	"请先分析这段代码的问题所在，再给出修复方案"	复杂逻辑分析、Bug 诊断
角色提示	为 AI 设定一个专业身份	"你是一位有 10 年经验的 Python 后端工程师"	需要特定领域专业知识
结构化提示	使用 Markdown 标题、代码块等组织信息	用 `## 项目背景` `## 约束` 等标题分隔不同信息	大多数编程任务

在此基础上，Google 在其官方指南中提出了更系统的结构化框架------PTCF 框架。它包含四个核心要素：

角色 (Persona)：你希望 AI 以什么身份回答？（例如："你是一位专注于 Python Web 后端开发的高级工程师..."）
任务 (Task)：你要 AI 完成什么具体动作？（例如："为用户服务实现一个分页查询接口"）
上下文 (Context)：AI 需要哪些背景信息才能完成任务？（例如：技术栈、数据库表结构、相关代码片段、约束条件）
格式 (Format)：你希望输出什么结构结果？（例如："只输出代码，包含类型注解，附带 pytest 测试"）

3. AI 编程的独特性与挑战

虽然 PTCF 是通用框架，但在 AI 编程场景中，我们需要特别注意以下三点独特性：

技术上下文的重要性远高于通用场景：AI 生成的代码正确性取决于大量隐性技术约束（版本兼容性、架构风格、团队规范）。没有充分上下文的提示词，AI 只能依赖训练数据中的"平均经验"，结果往往与实际需求存在偏差。
输出的正确性有客观标准：与 AI 写文章不同，AI 生成的代码有明确的对错之分（能不能运行、性能是否达标）。这意味着你可以在提示词中给出具体的验收标准，让 AI 在输出时进行自我检验。
迭代效率比一次完美更重要：在实际编程中，通常不需要一次得到完美的答案，而是需要快速得到一个可以迭代改进的起点。

图1 展示了 AI 编程中提示词工程的完整作用链路：

(注：此处展示了从用户模糊想法 -> 提示词工程补充上下文/明确目标 -> 大语言模型 -> 代码采纳/人工审查 -> 可用代码的闭环流程)

4. 实战核心：AI 编程五要素通用写作框架

为了将 PTCF 框架落地到具体的代码生成任务中，我们总结了一套包含 5 个核心要素 的通用写作框架。只有当所有要素都被清晰说明时，AI 才能真正地"理解"任务，而不是"猜测"任务。

4.1 五要素详解

1. 项目背景 (Project Background)

这是最容易被忽视的部分。告诉 AI 当前的项目情况，尤其是影响最为显著的部分。

技术栈：明确版本（如 Python 3.12 + FastAPI 0.115）。
项目概况：这是什么系统，当前模块承担什么职责。
相关文件：与任务直接相关的类、函数或数据结构定义。

2. 需求描述 (Requirement Description)

清晰、具体地描述你想要 AI 做什么。避免使用"优化一下"、"写个接口"等笼统表述。

错误示范："帮我优化这个查询函数"。
正确示范 ："当前函数存在 N+1 查询问题，请使用 SQLAlchemy 的 selectinload() 重写，使包含 100 个订单的查询次数降低到 3 次以内"。

3. 修改范围 (Modification Scope)

明确告知 AI 可以修改哪些内容 ，以及哪些不允许改动。这是防止 AI 过度扩展修改范围的关键要素。

可以修改 ：order_service.py 中的 get_orders_with_items() 函数。
不得修改 ：该函数的输入参数和返回值类型；models.py 中的任何数据库模型定义；不得引入新的第三方依赖。

4. 约束边界 (Constraints & Boundaries)

列出技术或业务上的硬性约束，这些是 AI 必须遵守的底线。

安全约束：禁止字符串拼接 SQL，必须使用参数化查询。
性能约束：接口响应时间 P99 不超过 200ms。
编码规范：遵循 PEP8，使用类型注解，函数长度不超过 50 行。
业务规则：金额计算必须使用 Decimal 类型，禁止使用浮点数。

5. 验收标准 (Acceptance Criteria)

告诉 AI 什么样的输出才算达到要求。好的验收标准有两个特点：可以被自动化验证，以及覆盖主要的异常场景。

功能正确：传入 user_id，返回该用户的所有订单及其关联订单项。
性能要求：使用 100 个订单的测试数据，数据库查询次数不超过 3 次。
空结果处理：当 user_id 对应的用户没有订单时，返回空列表，而非抛出异常。
附带单元测试：至少覆盖正常情况、空结果和用户不存在 3 种场景。

4.2 通用提示词模板

将上述 5 个要素组合起来，就可以形成一个可复用的 AI 编程提示词模板：

复制代码

1## 项目背景
2[技术栈及版本、项目架构概述、相关代码片段]
3
4## 需求描述
5[具体、可客观验证的任务描述]
6
7## 修改范围
8- 可以修改：[列举]
9- 不可修改：[列举]
10
11## 约束边界
12- [安全约束]
13- [性能约束]
14- [编码规范]
15- [其他约束]
16
17## 验收标准
18- [] [标准 1：正常情况]
19- [] [标准 2：异常情况]
20- [] [标准 3：性能要求]
21- [] [附带测试用例]

经验法则 ：

判断提示词是否足够完整有一个实用的经验法则：把这个提示词交给一位刚加入团队、完全不了解项目的初级工程师，他能不能在没有任何额外信息的情况下理解任务、完成实现并写出测试？ 如果可以，这个提示词就是足够完整了。