拒绝“猜谜式”编程：从 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 框架。它包含四个核心要素：

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

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

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

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

图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- [] [附带测试用例]

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