AI编程的提示词，说白了就是你和AI助手之间的“沟通协议”。在过去这段时间里，我几乎每天都要跟AI打交道，从最开始问一句“帮我写个排序算法”，到后来发展成一整套能稳定产出高质量代码的提示词工作流。很多人觉得AI编程效果不稳定，我觉得九成问题不在模型，而在于我们根本没把需求说清楚。这篇博文就是我自己沉淀出来的提示词框架和模板，目标很简单：让AI一次听懂需求，少绕弯子，输出能直接用的东西。适合刚开始用AI写代码、以及正在为“AI生成代码质量差”发愁的朋友。
1. 为什么你需要一套属于自己的 AI 编程提示词
1.1 AI 编程助手不是搜索引擎，而是“新同事”
我在很多交流场合听到过同一个抱怨：AI写的代码不能看，或者看似能用但一跑就崩。很多人拿AI当搜索引擎用，丢一个问题，抄一段结果，能用就算走运，不能用就骂模型。但实际上，AI编程助手的正确用法更接近“带一个逻辑强但经验少的新同事”。你跟这个新同事描述需求，如果只说“帮我把这个模块优化一下”，他大概率不知道从哪里下手。你需要告诉他背景、目标、边界、技术栈、验收标准。这就是提示词存在的意义。
我自己的切身体会是，同一个模型，在“帮我写个登录接口”和“请基于当前项目的用户表结构，实现一个支持用户名密码登录的FastAPI接口，密码使用哈希存储，登录成功后返回JWT令牌，并处理用户不存在和密码错误的异常分支”这两种提示词下，产出质量完全不在一个层级。前者给的是教科书示例，后者才是在替你的项目解决问题。很多新手的误区正是把AI当成一个无所不知的答案机器，而忘了它其实是一个需要你“布置任务”的协作者。
1.2 “自用”提示词的价值：沉淀、复用、进化
你可能在网上见过各种“万能提示词模板”，什么“角色扮演某领域专家”“一步一步思考”。真要拿到项目里，你会发现大部分都不好用。原因很简单：网上模板面向的是公开的通用问题，而你的项目有自己独特的业务背景和技术约束。所以我坚持维护一套“自用”提示词库，也就是针对我个人经常遇到的任务类型，把上下文、约束、格式、示例都固化下来。这套东西用久了会进化的，每次发现某个提示词输出不稳定，我就拿出来改一版。相比每次临时写提示词，沉淀好的模板能省掉大量重复试错。
我举个例子，早期我写前端组件生成类的提示词，每次都要花很长时间描述组件风格、props、事件、状态管理方式。后来我把团队常用的组件规范整理成一段固定文案，存成文件，以后只要粘贴进去，再替换具体业务字段就行。这样做的回报是指数级的：每多一次复用，省下的时间就越多。更关键的是，当提示词库积累到一定程度，你会开始发现自己的思维模式也变清晰了，因为要把一件事写清楚，本身就在逼你拆解需求。
2. 拆解一套高效提示词的六个核心要素
2.1 角色设定：让模型进入工作状态
很多人忽略了角色设定的作用。你写“你是一名资深Python工程师”和写“帮我写代码”，同一模型给出的代码质量会有明显差异。因为角色描述会影响模型对回答风格、专业深度、术语使用方式的判断。我自己的经验是，角色设定不要大而空，最好带细节。比如“你是一名熟悉FastAPI和SQLAlchemy的Python后端工程师，擅长编写生产级代码，会主动考虑异常处理和性能问题。”这个“生产级”“主动考虑”等词其实是在悄悄改输出偏好。
角色设定的作用不在于“它真的是一个资深工程师”，而在于给模型一个合理的“输出分布锚点”。大模型本质是在预测最可能的文本序列，当你明确说“你是一名资深工程师”，它生成高专业度答案的概率就会上升。你甚至可以在角色设定里加入“你会编写测试用例”“你习惯在代码里写清楚关键逻辑注释”这类倾向性描述，这些都能直接体现在输出结果里。
2.2 任务描述：说清“做什么”与“做到什么程度”
任务描述是提示词的核心。我发现最容易翻车的地方是“边界模糊”。比如你说“写一个用户注册接口”，看起来很清楚，但AI不知道要不要校验邮箱格式、密码规则怎么定、重复用户名怎么办、返回码用几位的、要不要记录日志。所以要给任务加验收标准。我的做法是，在提示词里明确“完成定义”：“请实现用户注册接口，输入参数为username、email、password，需校验邮箱格式，密码至少8位且包含字母和数字，重复用户名返回409和具体错误信息，其他异常统一返回500。”这样一来，AI输出不再是一堆猜测性的代码，而是围绕验收标准展开的具体实现。
任务描述里还有一类常见遗漏，就是“不要做什么”。AI对默认行为的依赖很强，如果你不告诉它“接口不需要支持分页”“不需要做权限校验”，它往往会自行加上一堆你可能不需要的功能。所以我在任务描述里习惯于既写“要什么”，也写“不要什么”。这种负面约束能大幅减少修改成本。
2.3 上下文注入：给模型喂够但别喂撑
上下文管理是AI编程里最难的一环。大模型存在上下文窗口限制，你一次性贴上十万行代码，它必然“失忆”或者忽略重点。我通常遵循三个原则：优先贴和当前任务直接相关的文件，而不是整个项目；贴代码时做最小化裁剪，去掉无关的import和日志；在上下文里用自然语言总结关键约束，而不是把所有代码都丢进去。比如你要改某个函数，贴函数定义和调用点就够了，不要贴整个模块。
我还发现一个容易被忽视的细节：上下文的排列顺序会影响模型注意力。模型对开头和结尾部分的关注度往往高于中间部分。所以我会把最核心的任务描述放在提示词开头，把关键约束写在结尾处，中间放背景信息或代码。这就有点像跟人沟通时先说结论再说背景，对方更容易抓住重点。
2.4 约束条件：技术栈、风格、禁止事项
AI默认会使用它训练数据里最常见的写法，不一定符合你的项目规范。所以约束条件必须写得非常具体。举个例子，有人说“用Python写一段读取CSV的代码”，AI可能用pandas，但如果你要求“仅使用标准库”，它就会改用csv模块。约束条件还可以包含禁止事项，比如“不要使用全局变量”“不要用eval”“不要引入未使用依赖”“不要额外压缩代码，保持可读性”。这些负面清单对规范输出效果很明显。
技术栈版本也要写清楚。我有一次让AI写一段SQLAlchemy代码，没说版本，结果它生成了SQLAlchemy 2.0风格的写法，而我的项目还在用1.4，最后不得不手动改。后来我养成了习惯，提示词里必带技术栈版本号，比如“Python 3.11 + FastAPI + SQLAlchemy 1.4 + PostgreSQL 15”。这个细节看起来不起眼，但能省下大量“语法适配”时间。
2.5 输出格式：结构化结果更利于复用
提示词里明确输出格式，会让结果直接落地。我的习惯是要求代码块带上语言标注、说明写在代码块外、或者要求给出“修改文件”“新增文件”“测试命令”三个分区。举个例子，我经常用这种指令：“请给出修改后的完整函数代码，使用python代码块包裹，并在代码块前用一段话说明修改思路。”这样贴回编辑器时不会夹带多余内容。
我还喜欢要求AI在给出代码之后，附带“验证步骤”或“风险点”。比如生成一个新接口时，让它在代码后面列出“可能的失败场景”和“对应的处理方式”。这相当于让AI自己给自己做review，有时候它能列出一些我没想到的边界情况。输出格式的等价物是“交付清单”，你越明确清单格式，AI越会按清单逐项交付。
2.6 少样本示例：给一个“标准答案”当标杆
少样本示例是提升输出稳定性的利器。模型看过一个“标准答案”之后，会更倾向于模仿这个答案的结构和风格。高效做法是：在提示词里给出一个小的成品示例。比如你要AI写一个查询接口，可以先给它一个现有的、质量比较好的查询接口作为示例，然后说“请按照同样的风格和结构实现订单查询接口”。实测下来输出结果的风格一致性会明显提升。
少样本示例不需要太长，一个精简的代码片段就够了。关键要选一个你满意的高质量代码，而不是随便拿一段。因为模型会模仿你给的示例的各个方面，包括命名习惯、注释风格、异常处理方式。如果你给的示例有坏味道，输出的结果也会带坏味道。我通常会放两个示例：一个展示理想结构，一个展示你需要避免的写法，效果很好。
3. 我在实际项目里沉淀的几套提示词模板（可直接抄作业）
3.1 新功能模块生成模板
这个模板非常适合从零生成新的文件或模块。它的结构是“角色设定 + 业务背景 + 任务 + 技术栈 + 验收标准 + 输出格式”。我随便写一个我常用的模板：
你是一名资深Python后端工程师，熟悉FastAPI和SQLAlchemy，编写代码时注重异常处理、日志和性能。 业务背景：我们的系统需要新增一个“用户积分变动记录”功能，用于记录用户积分的收入和支出流水。 任务：设计并实现积分流水表的模型、创建接口和查询接口。 技术栈：Python 3.11 + FastAPI + SQLAlchemy 2.0 + PostgreSQL。 要求： 1. 模型包含字段：id、user_id、change_amount、balance_after、change_type（income/expense）、remark、created_at。 2. 创建接口接收user_id、change_type、amount、remark，需要校验金额大于0，并且用户存在。 3. 查询接口支持按user_id分页查询流水。 4. 所有接口返回统一结构：{"code": 0, "message": "success", "data": ...}。 5. 使用SQLAlchemy 2.0的Mapped和mapped_column写法。 输出：给出完整的模型代码、接口代码、以及依赖注入方式。代码用python代码块包裹。这个模板可以直接替换业务名词使用。关键是验收标准部分，AI会用尽全力满足你列出的每一条要求。如果你有更复杂的领域约束，比如“积分不能为负”“流水不能修改只能追加”，也要写进去。用在生成新功能时，这套模板的成功率非常高，基本可以做到“一次生成、微调即用”。
3.2 代码重构与优化模板
重构类任务有一个坑：AI可能在你要求“优化”时把好好的代码改成另一种风格，甚至改变行为。我的做法是先让AI“复述计划”，再动手。模板如下：
你是一名资深Java工程师，下面待重构的代码来自某个内部系统，重构时要保持外部行为和接口签名不变。 代码： [贴代码] 任务：分析这段代码的问题，给出重构方案。 要求：先列出具体问题（至少三点），再按优先级给出重构步骤。不需要直接写代码，等我说“开始重构”后再输出代码。先分析、后动刀这个节奏非常有用，能大幅降低“AI一顿操作把功能改坏了”的风险。我见过太多人让AI直接重构，结果AI把原本能跑的老代码改成了一套风格迥异的新架子，反而引入了新问题。让它先给方案，你审核通过后再动手，相当于把“决策权”留在了自己手里。
3.3 单元测试生成模板
写单元测试是AI编程最顺手的场景之一，但生成的测试经常充斥着无效断言。我建议用“覆盖率+边界用例”驱动：
你是一名熟悉pytest的Python开发者，下面是对一个函数的实现代码： [贴代码] 任务：为这个函数编写单元测试。 要求： 1. 覆盖正常路径、边界值和异常路径。 2. 使用pytest框架和fixture组织测试数据。 3. 断言要具体，不能只写“不为None”。 4. 额外补充至少三个容易被遗漏的边界用例。 输出：完整的测试代码，使用python代码块包裹。边界用例提示词很有效，AI通常能想到空输入、超大数值、重复调用等问题。你甚至还可以加一句“请模拟外部依赖的异常”，让AI用mock把数据库连接失败、网络超时等场景也覆盖进去。单元测试生成类提示词是我使用频次最高的场景之一，因为这类任务的验收标准非常清晰，AI输出质量也最稳定。
3.4 Bug 排查与调试模板
调试是最能体现“上下文细节”价值的场景。你不能只问“为什么报错”，要把完整信息给AI：报错信息、相关代码、输入数据、期望结果。我的模板：
我有一段代码出现报错，请帮我定位原因并给出修复方案。 报错信息： <贴报错堆栈> 相关代码： <贴最小化代码> 输入数据： <贴触发问题的输入> 我的期望：<说明期望行为> 修复要求：优先修改局部代码，不要大范围重构；如果有多种方案，请说明各自的权衡，并推荐一种。我见过太多人贴一半代码就去问，AI只能盲猜。把完整链路给足，一次修对的概率会明显提升。调试类提示词还有一个好处是能帮你快速理解依赖关系。AI通过分析堆栈和相关代码，经常会指出“这个错误不是因为当前方法，而是因为上游调用传入了空值”之类的深层原因，这种跨文件排查能力恰恰是人工最容易遗漏的。
3.5 代码审查（Code Review）模板
代码审查需要AI站在“挑刺”的角度，但大多数模型默认是“夸夸党”。所以要在提示词里立规矩：
你是一名经验丰富的代码审查者，请用严格的标准审查下面代码，重点关注潜在的bug、安全隐患、性能问题、可维护性问题。 代码： [贴代码] 要求： 1. 分成“阻塞问题”“建议优化”“细节问题”三个列表输出。 2. 每个问题都要说明理由和修复建议。 3. 如果代码没有问题，也要明确说“未发现阻塞问题”，不要用空话凑数。AI的审查效果和专业度有关，但对常见问题（空指针、SQL注入、重复代码、魔法数字）的判断非常靠谱，适合当第二双眼睛。我通常会在提交MR之前用这个模板过一遍自己写的代码，它常能发现一些“当局者迷”的低级问题。尤其是潜在的空值处理和未关闭的连接资源，AI对这些模式的识别比大多数人都敏锐。
4. 实战案例：从需求到可运行代码的全过程
4.1 场景设定：某个内部数据平台的后端接口开发
为了说清楚提示词怎么迭代，我复盘一次真实过程。假设我在某个内部数据平台要开发一个“指标配置保存接口”，技术栈是Python 3.11 + FastAPI + SQLAlchemy 1.4。当时我对需求理解还不完整，第一版提示词写得很随意：
帮我写一个指标配置保存接口结果AI返回了一个极其简化的接口，只有表名、字段、路由，没有校验、事务和日志。这算是我踩过最经典的坑：任务越模糊，输出越“骨架”。拿到那个版本时我第一反应是“AI真垃圾”，但冷静下来发现，问题出在“我压根没给验收标准”。AI不知道这个接口要不要校验字段唯一性，也不知道要不要事务，更不知道统一的返回结构长什么样，它只能按照训练数据里最常见的“教程接口”来输出。
4.2 第一版提示词的效果与问题
第一版生成的代码，问题集中在三块：没有处理字段缺失导致的报错、保存过程没有事务包裹、返回结构跟项目已有接口不一致。这三个问题都不是AI能力不够，而是我没告诉它需要什么。看过输出之后，我意识到这个任务需要“先补充背景，再细化验收标准”。于是我把“内部数据平台管理员在页面上填写指标信息”这个业务动作也描述进去，因为一旦AI理解了使用场景，它就会自动联想到“配置重复”“非法SQL”“数据源表不存在”等业务层面的校验逻辑。
4.3 迭代优化后的提示词与最终效果
我改写的第二版提示词是：
你是一名资深Python后端工程师，熟悉FastAPI、SQLAlchemy和Pydantic。 业务背景：我们的内部数据平台有一个“指标配置”页面，用户填写指标名称、计算口径、数据源表、更新频率后点击保存，前端会向后端发送一个保存请求。 任务：实现POST /api/metrics/config 接口，保存指标配置并返回保存后的配置详情。 技术栈：Python 3.11 + FastAPI + SQLAlchemy 1.4 + Pydantic v2。 具体要求： 1. 请求体字段包括：name（必填）、calculation_sql（必填）、source_table（必填）、update_frequency（可选，默认daily）、description（可选）。 2. 使用Pydantic模型做请求体校验。 3. 保存时开启事务，失败要回滚。 4. 配置表不存在时自动创建表，字段与请求体对应，并额外记录created_at、updated_at。 5. 成功返回{"code": 0, "message": "success", "data": {...}}，失败返回对应的业务错误码和消息。 6. 使用日志记录保存过程中的关键事件。 输出：完整接口代码，使用python代码块包裹，包含模型定义、依赖注入、路由函数。同样是AI，这一版给出的代码基本可以直接用，事务、日志、统一返回结构都齐了。区别就在于我在提示词里给出了技术栈版本、验收标准、业务背景，还指定了Pydantic v2的细节。我还额外验证了一个细节：如果name重复，AI确实返回了业务错误码而不是直接抛500。这让我意识到，事实是“AI能不能生成生产级代码”的答案，很大程度上取决于“你给的输入是不是生产级提示词”。
4.4 过程中踩过的坑与思考
复盘这次实践，最深的体会是“提示词成本其实是一次性投入”。如果你准备用AI把同一个模块写五次，那每一次花三分钟写清楚提示词，比五次都花十分钟事后改代码要划算得多。另一个体会是我学会了“跟AI确认理解”：在任务比较复杂时，我会在提示词末尾加一句“如果需求描述有歧义，先列出你的假设，再开始写代码”。这个技巧能提前把误解暴露出来，避免后端接口写完了才发现前端要的字段不一样。有些AI工具还支持“链式思考”，让它先分析需求再动手，效果更好。
我还发现，在初版提示词效果不好时，不要急于在新对话里完全重写，而是在当前对话里“追问式修改”。比如让AI修改返回结构、补充事务、加上异常处理，这种逐项纠偏往往比换一个重新生成更高效，因为模型已经掌握了前面几轮的上下文，你只需要在剩余问题上打补丁。
5. 提示词调优的进阶技巧：从“能用”到“好用”
5.1 多轮对话里的“追问式”调优
提示词优化不是一次性成型的。我常用的模式是：第一轮给宽泛任务，让它先出方案；第二轮针对方案中的细节继续追问；第三轮才要求“按这个方案写代码”。这样做的好处是，每个轮次的信息量都控制在小范围，模型不容易迷失。比如在做架构设计时，我不会直接说“设计一个订单系统”，而是先让它列出模块划分，然后选定某一个模块继续细化，最后再让它输出该模块的代码。
追问式调优还有一个好处：你可以在每一轮中“纠正方向”，避免最终产出严重偏离需求。比如AI给出的方案里使用了缓存中间件，但你的项目暂时不需要缓存，那就直接追问“如果去掉这个中间件，你觉得性能瓶颈会在哪里？”这种对话式探索能把AI的“隐性假设”都逼出来，让你对方案的取舍有更完整的认识。
5.2 让 AI 先给方案再写代码
这条和上一条相关，但值得单独提出来。很多编程任务可以拆成“方案”和“实现”两个阶段。方案阶段不接触代码，只讨论思路、数据结构、接口设计；实现阶段再把已经确认的方案固化到提示词里，让AI照着写。这种做法的本质是把“大任务”拆成“若干小任务”，每一段的上下文都更加聚焦，生成质量自然更高。
我自己的习惯是，在实现阶段会把方案阶段的结论复制进新对话的提示词开头，然后写“请按照上述方案实现，不要偏离方案中的设计决策”。这样做既避免了上下文太长导致模型混乱，又确保了最终代码和方案一致。尤其是在设计复杂的业务模块时，这个“两段式”流程能让AI的输出稳定保持在方案框架内，而不是天马行空。
5.3 善用温度参数与生成长度
如果你用的是可以调参的AI编程工具，温度参数值得好好玩。生成代码时建议把温度调低，尽量保持输出的确定性，减少“自由发挥”带来的随机bug。但在头脑风暴类任务里，比如“这个接口还有哪些异常情况要考虑”，可以稍微调高温度，让AI发散出更多思路。生成长度也要注意，有的工具默认输出偏短，遇到复杂模块会被截断，可以明确设置一个较大的max tokens，或者在提示词里强调“请完整输出整个文件，不要省略”。
具体温度值不用死记，我一般代码生成用0.2以下，方案讨论用0.5到0.7，创意输出用0.8以上。如果你的工具不允许直接调温度，也可以通过“提示词”来模拟：要求“给出最保守的实现方案”会偏向低温度效果，要求“多给出几种可能性”则偏向高温度效果。
5.4 建立“提示词版本库”与复盘习惯
我建议所有人维护一个本地的提示词版本库，格式不复杂：一个文件夹，每个任务类型存一个markdown文件，里面记录初版提示词、效果评价、改版原因和最新版本。一开始不用做成体系，只要在踩坑后记得回去更新文件就够。我自己的库已经积累了几十个条目，包括“MySQL慢查询分析”“JVM参数解读”“前端组件生成”“YAML配置文件检查”等，每次要用直接打开复制，写着写着就会形成肌肉记忆。
复盘时多问自己三个问题：这次输出里最不满意的地方是哪里？它在提示词的哪个位置被误导了？下次如何改写对应段落？这三个问题会逼你从“AI不行”切换成“提示词可以优化”的思维模式。我见过最快成长的同学，不是技术最强的，而是最愿意复盘提示词的人。因为每一轮输出都是“反馈信号”，你要做的不是抱怨信号太弱，而是调优提示词这个“信号发射器”。
6. 常见问题与排查速查表
6.1 AI 答非所问
遇到这种情况，先检查提示词里是不是混入了太多无关信息。上下文一多，模型会抓不到重点。解决方法是把任务描述提到提示词最前面，并且单独用一段“你只需要做X，不要做Y”来隔离任务边界。还有一种情况是模型的注意力被角色设定带偏了，比如角色设定里吹了太多“你是全栈专家，精通前端、后端、运维、安全”，它可能就不知道该优先写哪一部分。
我在一次让AI“帮我设计数据库表”时，角色设定里写了一堆“熟悉高并发架构”，结果AI花了大量篇幅讨论分库分表和消息队列，而我其实只要一个简单的业务表单。后来我把角色设定改成“熟悉中小型业务系统建模”，输出立刻收敛了。这也印证了一个技巧：角色设定也要和目标任务的复杂度匹配。
6.2 代码风格不一致
生成的代码和项目现有代码风格对不上，是高频问题。这通常是因为提示词里没有陈述风格要求。我的应对是在模板中固定加入一行：“请使用项目现有的命名约定，类名采用大写驼峰，函数名采用小写驼峰，注释使用中文。”如果你维护了项目的代码规范片段，可以把它放进“长期上下文”里反复使用。
如果AI还是“我行我素”，最直接的办法是给一个真实的项目文件作为风格示例。比如把你的一个老接口文件贴进去，然后说“参照这个文件的代码风格”。模型对真实示例的模仿能力远超你写十条风格描述。这个方法在我处理旧项目时特别好用，因为旧项目的代码风格往往很难用规则穷尽，但给一个样板文件，AI立刻就能学会。
6.3 上下文一大就“失忆”
大语言模型的上下文窗口固然越来越大，但“塞得下”不等于“记得住”。当你在同一轮对话里连续贴了几百行代码之后，模型经常忽略前面约定的约束条件。我的办法是“关键约束重复出现在最近区域”：在提示词的末尾，再次用一两句话概括最重要的约束，比如“再次提醒：不要修改接口签名”“不要使用sqlite方言”。这种小重复能明显减少失忆问题。
还有一种更彻底的方案：开新对话。如果当前对话已经展开了很多轮，而你要把它当成一个新任务来处理，不妨把核心上下文重新整理一遍，填进新会话。别舍不得旧对话，旧的“记忆”往往包含大量噪声，新会话干净清爽的上下文反而更有利于高质量输出。
6.4 幻觉代码（用不存在的库/方法）
AI会“一本正经地胡说八道”，比如编造不存在的第三方库方法名、虚构某个框架的API。要降低幻觉概率，最有效的方法是喂给它真实的代码片段，利用少样本把模型拉回“见过的代码真面目”。如果幻觉还是出现，不要争辩，直接让它“搜索你本地环境里XX库的版本信息”，或者把官方文档片段贴进上下文。我在踩过几次坑之后就养成了习惯：凡是AI写出来的涉及不熟悉API的代码，一律先翻文档确认再合入。
另外，可以让AI在输出代码时标注“哪些API是从项目现有代码推断的，哪些是标准库，哪些是第三方库”。这样你在review时可以去重点确认第三方库的部分。幻觉并不可怕，可怕的是你没意识到它在幻觉。把“可疑点”显式暴露出来，再逐项验证，才是真正安全的用法。
6.5 提示词越长效果越差
提示词不是越长越好。我见过有人写了两千字提示词，结果输出质量反而下降。原因可能是关键信息被大量次要描述稀释了。我的原则是“长短结合”：背景信息控制在三四句，技术栈加约束控制在五六条，示例控制在十个代码块以内。如果提示词超过了一屏，你就要反思是不是把不必要的历史对话也塞进来了。更好的做法是开启新对话，把核心上下文重新组织一遍再下发任务。
所谓“自用”提示词，核心是“你知道它为什么有效，并且能随时调整它”。网上那些看似厉害的超长模板，往往有大量情绪化描述和空洞的“请务必保证高质量”，这些内容除了浪费token，并不会提升输出质量。精简到“背景、任务、约束、输出格式”四段式，是性价比最高的结构。
我最后再分享一个小技巧：每次AI输出的代码，无论看起来多漂亮，我都不会直接合入主分支。我会先跑一遍测试、做一轮人工review，再交给CI去跑静态检查。不是不相信AI，而是“它写得快，你审核得更快”才是正确的工作节奏。这套自用提示词框架回头想想，改变的不仅是代码产出效率，更让我养成了把需求想清楚再动手的习惯。希望这篇分享能给你一些启发，如果你也在用AI编程，建议从今天开始维护自己的提示词小本子，用不了几次，你就能明显感受到差别。
