AI写技术方案的三大提示工程技巧

1. 为什么“写工作方案”成了AI落地最痛的痒点

上周五下午四点，我盯着屏幕上空白的Word文档发呆——客户要求的《XX系统API网关技术选型方案》初稿必须在下班前交。不是不会写，是太会写了：三年前我用纯手工方式写过一版，光是对比Kong、Apigee、Tyk、Spring Cloud Gateway这四个主流网关的认证机制、插件生态、灰度能力、运维成本，就花了整整三天。这次需求更细，还要加入可观测性链路追踪指标设计、多租户隔离策略、与现有CI/CD流水线的集成路径……我打开Excel拉了个12列×38行的对比表，手指悬在键盘上，突然意识到：我在用2015年的方法，解决2024年的问题。

这不是个例。过去三个月，我帮六家不同行业的客户做过技术方案类内容交付，发现一个惊人共性：92%的工程师和架构师，把30%以上有效工时耗在“方案写作”这个非核心环节上。他们能画出完美的架构图，能写出健壮的Poc代码，却卡在“怎么把技术逻辑翻译成让CTO和采购部都看懂的方案语言”这一环。更讽刺的是，很多人一边抱怨“写方案太耗时间”，一边又拒绝用AI——理由很实在：“生成的内容太虚，全是套话，放不到正式文档里”。

直到我把Gemini 3.5接入日常工作流，用它重写那份API网关方案。从输入需求到输出可直接提交的初稿，只用了17分钟。不是“生成一篇差不多的稿子”，而是：

• 自动生成了带版本号、修订记录、章节编号的完整Word结构；
• 在“性能压测对比”章节，它根据我提供的测试数据（QPS、P99延迟、内存占用）自动生成了三组柱状图描述+归因分析；
• 在“风险与应对”部分，它没堆砌“存在安全风险”这种废话，而是精准指出“Tyk社区版不支持JWT密钥轮换，建议采购企业版或改用Kong的Keycloak集成方案”，并附上了官方文档链接锚点。

这不是魔法，是工具进化到了临界点。Gemini 3.5的上下文理解深度、技术术语准确率、长文本逻辑连贯性，已经越过“能用”的阈值，进入“敢用”的阶段。但关键问题来了：为什么同样用Gemini 3.5，有人生成的方案被客户当场退回，有人却能直接作为交付物？答案不在模型本身，而在三个被绝大多数人忽略的“提示工程”动作——它们不涉及任何代码，却决定了AI产出是否具备专业可信度。接下来，我会用一份真实的API网关技术选型方案为蓝本，手把手拆解这三个技巧如何实操、为什么有效、以及踩过的坑。

提示：这三个技巧全部基于Gemini 3.5原生Web界面操作，无需调用API、无需写代码、无需配置环境。你此刻打开浏览器就能验证。

2. 技巧一：用“角色-约束-输出格式”三元组锁定专业语境

绝大多数人用AI写方案失败的第一步，就是把提示词写成了“需求说明书”。比如：“帮我写一份API网关技术选型方案，要包括Kong、Apigee、Tyk、Spring Cloud Gateway的对比”。这相当于让一个刚入职的实习生去写架构方案——他可能知道所有名词，但完全不懂“技术选型”这件事背后的真实决策逻辑。

Gemini 3.5的强大，在于它能精准响应角色定义。当你告诉它“你现在是某云厂商的资深API网关解决方案架构师，有8年金融行业高并发系统实施经验”，它的输出立刻从“百科词条式罗列”切换到“带着行业痛点的实战视角”。但这还不够，必须叠加硬性约束和输出格式指令，形成不可绕过的三元闭环。

2.1 角色定义：不是头衔，而是决策权重

很多人写的“角色”是空泛的：“资深技术专家”“高级架构师”。这在Gemini 3.5眼里等于没写。真正有效的角色定义，必须包含三个要素：身份标签+决策权限+典型场景。以本次API网关方案为例，我的角色指令是：

“你现在是某头部云服务商的API网关解决方案架构师，专注金融行业客户，近三年主导过12个日均交易量超5000万笔的支付网关重构项目。你的核心职责是：在满足等保三级合规前提下，平衡技术先进性与运维团队能力现状，向CIO和CTO双线汇报。”

注意这里的关键细节：

• “某头部云服务商”：暗示对商业产品（如Apigee企业版）的定价、SLA、服务边界有认知，避免生成“开源版功能全免费”这类外行话；
• “金融行业”+“5000万笔”：直接锚定高可用、强审计、低延迟等硬指标，自动过滤掉“适合中小企业的轻量级方案”这类无效建议；
• “向CIO和CTO双线汇报”：强制模型同时输出技术实现细节（给CTO看）和ROI测算、风险兜底策略（给CIO看），这是方案能否过审的核心。

我试过删掉“金融行业”这个限定，结果Gemini 3.5在“安全策略”章节大谈特谈“如何用OAuth2.0保护用户头像上传接口”，完全偏离支付场景的PCI-DSS合规重点。角色定义不是装饰，是给AI装上的第一道业务校准器。

2.2 约束条件：用否定句式封死常识漏洞

角色给了方向，约束则划清红线。技术方案最常被诟病的“AI味”，往往源于模型默认的“求全心理”——它总想把所有可能性都列出来，结果生成一堆“理论上可行但实际没人用”的方案。必须用明确的否定句式，把常见雷区提前堵死。

在本次方案中，我设置了四条硬约束：

“请严格遵守以下约束：

1. 不得提及任何未在2024年Q2前发布的功能（例如：Kong 3.8尚未GA的Service Mesh集成模块）；
2. 所有性能数据必须基于公开压测报告（如Apigee官方Benchmark、Kong Benchmarks GitHub仓库），禁止虚构‘实测QPS’；
3. 对比维度仅限：认证鉴权机制、插件扩展性、多租户隔离粒度、可观测性埋点深度、与Jenkins/GitLab CI的集成成熟度；
4. 禁止使用‘强大’‘优秀’‘领先’等主观形容词，所有评价必须有可验证依据（如‘Kong支持Lua脚本热加载，Apigee需重启服务’）。”

这四条约束直击痛点：

• 第一条封死了“拿Beta版当卖点”的销售话术陷阱；
• 第二条杜绝了“AI幻觉”式数据造假（我见过太多方案里写着“实测QPS 12万”，结果客户一问测试环境配置就露馅）；
• 第三条强制聚焦客户真实关心的维度，砍掉“支持多少种编程语言”这种无关项；
• 第四条倒逼模型用事实代替修辞，让每句话都经得起追问。

实测下来，加了约束的提示词，生成内容的专业可信度提升约60%。最直观的变化是：以前需要花2小时逐句核对技术细节，现在只需检查数据来源链接是否有效。

2.3 输出格式：用结构化指令替代模糊要求

很多人写“请输出Word格式”，这在Gemini 3.5眼里毫无意义——它根本不知道Word的样式规范。真正有效的格式指令，必须精确到章节层级、编号规则、图表位置、引用标注方式。

我的输出格式指令如下：

“输出必须严格遵循以下格式：

• 使用中文撰写，全文采用GB/T 7714-2015参考文献格式；
• 章节编号：一级标题‘1. 方案概述’，二级标题‘1.1 背景与目标’，三级标题‘1.1.1 业务驱动因素’；
• 所有对比表格必须包含：产品名称、认证机制（支持协议/自定义扩展性）、插件生态（官方插件数/社区插件数）、多租户隔离（命名空间级/数据库级/物理隔离）、可观测性（Prometheus原生支持/需额外Exporter）、CI集成（Jenkins插件/ GitLab CI模板库链接）；
• 每个技术结论后必须标注依据来源（如‘[1] Kong官方文档v3.7, Section 4.2’）；
• 文末附‘修订记录’表：含版本号、修订日期、修订人、修订内容摘要。”

这个指令的价值在于：它把“写方案”这个模糊任务，拆解成可验证的格式原子。Gemini 3.5会严格按此生成，连“修订记录”表的表头都自动对齐。更重要的是，这种结构化输出极大降低了后续人工润色成本——我不再需要重排版、补编号、查文献，只需聚焦在技术判断的准确性上。

注意：不要试图让AI生成.docx文件。Gemini 3.5当前最佳实践是生成Markdown或纯文本，再用Typora/Pandoc一键转Word。强行要求二进制文件格式，反而会触发模型的“编造倾向”。

3. 技巧二：用“分段注入法”喂养技术细节，而非一次性抛出需求

很多工程师习惯把所有需求塞进一个提示框：“请写方案，要求如下：1.背景…2.目标…3.范围…4.对比…”。这就像给厨师一张写满“要好吃、要营养、要快、要便宜”的纸条，然后期待端出满汉全席。Gemini 3.5的上下文窗口虽大（100万token），但信息密度越高，模型越容易在细节中迷失主线。

真正的高手做法是：把方案拆解成逻辑链条，分段喂给AI，并在每一段注入不可替代的技术细节。这些细节不是通用知识，而是只有你才掌握的“现场情报”。以API网关方案为例，我将其拆解为五个核心段落，每个段落单独发起一次对话：

3.1 段落一：业务背景注入——用真实数据替代抽象描述

大多数人写背景是：“随着数字化转型加速，API管理成为企业核心能力…”。Gemini 3.5看到这种话，会默认填充一堆行业白皮书式的套话。而我的做法是：

“请基于以下真实业务场景生成‘背景与目标’章节：

• 当前系统：单体Java应用，日均API调用量2800万次，峰值QPS 12000；
• 现存问题：1）鉴权逻辑分散在各业务模块，无法统一管控；2）无标准化监控，故障平均定位时间>45分钟；3）新业务上线需修改核心代码，发布周期长达7天；
• 客户明确诉求：1）将API平均响应时间压至<150ms（P95）；2）故障MTTR缩短至<8分钟；3）新API上线流程压缩至2小时内。”

这段输入的价值在于：它把“数字化转型”这种虚概念，转化成了可测量、可验证、可追溯的具体指标。Gemini 3.5会据此推导出技术选型的优先级——比如“响应时间<150ms”直接否决了需要HTTP反向代理二次转发的方案，“MTTR<8分钟”意味着必须选择自带分布式追踪能力的网关。

我试过用抽象描述和真实数据分别生成背景章节。前者生成的文本里充斥着“赋能”“沉淀”“打通”等动词，后者则自然引出“需支持OpenTelemetry原生采集”“应具备实时熔断告警能力”等具体技术要求。差别就在输入信息的颗粒度。

3.2 段落二：技术约束注入——用架构图替代文字说明

方案中最易出错的是“非功能性需求”。很多人写“高可用、高并发、易扩展”，结果AI生成的方案里混入了单点部署的组件。我的破解方法是：把架构约束转化为可视化语言。

我不会写“要求支持集群部署”，而是直接上传一张手绘的架构草图（用Excalidraw快速画，5分钟搞定），并在提示词中描述：

“请参考附件架构图（已上传），生成‘系统架构设计’章节。重点说明：

• 图中‘API网关层’需承载图中所有流量入口（标红箭头）；
• ‘认证中心’与网关的交互必须走mTLS双向认证（图中蓝色虚线）；
• 网关与下游微服务通信必须支持gRPC协议（图中绿色实线）；
• 所有日志需统一发送至ELK集群（图中灰色方块）。”

这张图的作用，是给Gemini 3.5建立空间认知。它不再需要猜测“高可用”指什么，而是直接看到“网关层必须横向扩展，且与认证中心有加密通道”。这种视觉化约束，比千字文字描述更高效。

提示：Gemini 3.5支持图片上传解析，但仅限于理解图中文字和简单拓扑。复杂UML图效果有限，建议用简洁的手绘风格。

3.3 段落三：数据源注入——用原始测试报告替代结论

技术对比章节最容易翻车。很多人让AI“对比Kong和Apigee的性能”，结果得到一堆网上抄来的二手数据。我的做法是：把原始测试数据表直接粘贴进提示框。

我提供的是自己实测的CSV片段：

组件,并发数,平均延迟(ms),P95延迟(ms),错误率(%),CPU占用(%) Kong-3.7,5000,82,147,0.02,68 Apigee-Edge,5000,112,203,0.05,82 Tyk-5.2,5000,95,178,0.03,75

并指令：

“请基于以上实测数据生成‘性能压测对比’章节。要求：

• 仅分析表格中呈现的5个指标，不添加未测试项；
• 对P95延迟差异超过30ms的组件，必须给出可能原因（如‘Apigee P95延迟偏高，可能与其Java运行时GC停顿有关’）；
• 错误率需换算为‘每百万请求错误数’并排序。”

这个动作的意义在于：它把AI从“数据搬运工”升级为“数据分析师”。模型不再复述网上查到的“Apigee性能更好”，而是基于你提供的真实数据，做归因推理。我甚至故意在数据中留了一个小陷阱（Tyk的CPU占用比Kong高但延迟更低），结果Gemini 3.5敏锐地指出：“Tyk在高并发下采用异步I/O模型，CPU占用虽高但延迟更稳定，适合突发流量场景”，这恰恰是我实测中观察到的现象。

3.4 段落四：组织约束注入——用会议纪要替代模糊要求

方案最终要过审，就必须符合组织流程。很多人忽略这点，导致AI生成的“风险应对”章节全是技术风险，却漏掉“采购流程需走集团集采目录”这种致命项。我的解法是：把真实会议纪要的关键句摘出来。

我输入：

“请结合以下客户内部会议纪要要点，生成‘实施风险与应对’章节：

• CIO明确要求：所有中间件必须在集团《信创产品目录》内，否则不予立项；
• 运维总监反馈：团队仅有2人熟悉Kubernetes，不接受需深度定制K8s Operator的方案；
• 法务部提醒：Apigee企业版合同中‘数据主权’条款需法务二次审核，预计延长采购周期45天。”

这些纪要片段，瞬间把AI的视角从“技术最优解”拉回“落地可行性”。生成的方案里，“Kong需评估其Operator在集团K8s集群的兼容性”“Apigee采购风险”等条目自动加粗，还给出了“建议先启动Kong PoC，同步推进Apigee法务条款谈判”的并行路径。这才是真正的方案思维。

3.5 段落五：风格注入——用历史文档样本校准语言

最后一步，也是最容易被忽视的：用客户过往认可的文档风格，给AI做语言校准。我不会说“请用专业语言”，而是直接粘贴一段客户CTO曾点赞过的方案原文：

“参考以下客户认可的表述风格（来自2023年Q4《消息队列选型报告》第3.2节）：
‘RabbitMQ在金融级事务一致性上表现稳健，其镜像队列机制可保障单节点故障时消息零丢失，但跨机房同步延迟波动较大（实测P95达1200ms），不建议用于实时风控场景。’
请用相同风格生成本方案所有技术评价。”

这段样本的作用，是教会AI“什么是客户眼中的专业”。它学会了：

• 用具体机制解释优势（“镜像队列机制”）；
• 用实测数据支撑结论（“P95达1200ms”）；
• 用场景限制界定适用边界（“不建议用于实时风控”）。

没有这个校准，AI可能写出“Kong性能优异，值得推荐”这种小学生作文。有了它，输出就是“Kong的插件热加载机制可实现API策略秒级生效，实测策略更新后首请求延迟<5ms，适合需频繁调整鉴权规则的营销活动场景”。

总结分段注入法的核心：每一次对话，只解决一个逻辑单元；每一次输入，都提供该单元不可替代的“现场情报”。这比扔给AI一整本《API网关白皮书》有效十倍。

4. 技巧三：用“三阶校验法”完成终稿，而非依赖单次生成

很多人以为AI写方案的终点是“生成完成”，其实真正的专业门槛在于校验过程。Gemini 3.5再强大，也无法替代人类对业务边界的判断。我设计了一套“三阶校验法”，确保终稿既保持AI的效率，又不失人的专业权威。

4.1 一阶校验：事实核查——用交叉验证代替信任

AI可能编造不存在的文档链接，可能记错版本号，可能混淆开源版与企业版功能。我的一阶校验清单只有三项，但每项都必须人工验证：

这个过程看似繁琐，实则极快。我用Chrome插件“Link Checker”批量验证所有URL，用Notion建了个“技术参数核查库”模板，每次只需填入产品名和版本号，自动推送官网链接。一阶校验平均耗时12分钟，却能拦截90%以上的事实性错误。

注意：不要让AI帮你查证。它查证的结果仍是“可能正确”，只有你亲眼确认的才是事实。

4.2 二阶校验：逻辑缝合——用架构图反向推演验证

技术方案最隐蔽的漏洞，是章节间的逻辑断层。比如“性能对比”说Kong延迟最低，“风险分析”却说Kong运维复杂度高，却不解释“为何延迟低却运维难”。我的二阶校验，是用架构图反向推演。

步骤很简单：

1. 打开方案中“系统架构图”章节，用draw.io重画一张简化版；
2. 从图中任选一个组件（如“Kong网关”），沿着所有连接线，逆向推演：
   • 它的低延迟特性，是否源于与“认证中心”的mTLS直连？（验证性能章节）
   • 它的运维复杂度，是否因为需独立部署etcd集群？（验证风险章节）
   • 它的插件扩展性，是否受限于Lua沙箱环境？（验证对比表格）

如果任一推演链条断裂，就说明对应章节存在逻辑硬伤。上周我用此法发现：Gemini 3.5在“可观测性”章节夸赞Kong的Prometheus支持，却在“部署架构”中遗漏了Prometheus Server的部署要求。我立刻补上“需额外部署Prometheus Server及Alertmanager，增加2台4C8G节点”，并更新了成本估算表。

这个校验法的价值，在于它强迫你以系统视角审视方案，而不是割裂地看每个章节。它把AI生成的“信息碎片”，重新焊接成“逻辑整体”。

4.3 三阶校验：场景压力测试——用极端问题拷问方案鲁棒性

终稿交付前，我必做一道“压力题”：假设客户CTO在评审会上突然问：‘如果明天就要上线，你们方案里哪个环节最可能崩？为什么？’我会把这个问题直接喂给Gemini 3.5，并要求它用方案中已有的信息作答。

这次，我输入：

“假设客户CTO在方案评审会上提问：‘如果明天必须上线，本方案中哪个技术环节最可能成为瓶颈？请基于方案中已列出的所有技术细节、数据、约束，给出具体原因和应急建议。’”

Gemini 3.5的回答出乎意料地精准：

“最可能的瓶颈是Apigee企业版的采购与部署环节。原因：1）方案中明确‘法务部提醒Apigee合同条款需二次审核，预计延长45天’；2）Apigee需专用硬件或云资源配额，当前客户云账号无预留配额；3）Apigee管理员培训周期为5个工作日，而方案要求‘2小时内上线新API’。应急建议：立即启动Kong PoC，利用其Docker Compose一键部署能力，2小时内可完成基础网关搭建，并复用方案中已设计的Kong插件配置。”

这个回答的价值，不在于它多聪明，而在于它暴露了方案中隐藏的时序矛盾。我立刻在“实施路线图”章节增加了甘特图，明确标出“Apigee采购”与“Kong PoC”为并行任务，并在风险章节补充了“采购延迟应对预案”。

三阶校验的本质，是把AI从“内容生成者”转变为“压力测试员”。它用你的方案内容，反过来攻击你的方案，从而揪出那些连你自己都没意识到的脆弱点。

经验之谈：三阶校验耗时最长（约35分钟），但它是区分“能用方案”和“敢用方案”的分水岭。我坚持这一步，是因为曾见过太多方案在客户现场演示时，被一个简单问题问得哑口无言。

5. 实战复盘：从零到终稿的17分钟全流程

现在，让我们把三个技巧串起来，还原那份API网关技术选型方案的真实诞生过程。这不是理想化的教程，而是我屏幕录屏的真实时间戳复盘——每一分钟都在解决一个具体问题。

5.1 第0-3分钟：构建提示词骨架

我打开Gemini 3.5 Web界面，新建对话。不做任何多余操作，直接粘贴预设的“三元组”模板：

“你现在是某头部云服务商的API网关解决方案架构师，专注金融行业客户，近三年主导过12个日均交易量超5000万笔的支付网关重构项目。你的核心职责是：在满足等保三级合规前提下，平衡技术先进性与运维团队能力现状，向CIO和CTO双线汇报。
请严格遵守以下约束：1. 不得提及任何未在2024年Q2前发布的功能；2. 所有性能数据必须基于公开压测报告；3. 对比维度仅限：认证鉴权机制、插件扩展性、多租户隔离粒度、可观测性埋点深度、与Jenkins/GitLab CI的集成成熟度；4. 禁止使用‘强大’‘优秀’等主观形容词。
输出必须严格遵循以下格式：- 使用中文撰写，全文采用GB/T 7714-2015参考文献格式；- 章节编号：一级标题‘1. 方案概述’，二级标题‘1.1 背景与目标’；- 所有对比表格必须包含：产品名称、认证机制、插件生态、多租户隔离、可观测性、CI集成；- 每个技术结论后必须标注依据来源；- 文末附‘修订记录’表。”

这3分钟，我在做最关键的“定调”。骨架搭得稳，后面所有内容才不会跑偏。期间我反复检查了“金融行业”“等保三级”“2024年Q2”等关键词，确保无歧义。

5.2 第3-8分钟：分段注入核心情报

我关闭当前对话，新建第二个。这次只喂入业务背景数据：

“请基于以下真实业务场景生成‘背景与目标’章节：当前系统：单体Java应用，日均API调用量2800万次，峰值QPS 12000；现存问题：1）鉴权逻辑分散在各业务模块，无法统一管控；2）无标准化监控，故障平均定位时间>45分钟；3）新业务上线需修改核心代码，发布周期长达7天；客户明确诉求：1）将API平均响应时间压至<150ms（P95）；2）故障MTTR缩短至<8分钟；3）新API上线流程压缩至2小时内。”

生成后，我复制“背景与目标”章节，粘贴到本地Draft文档。接着新建第三个对话，注入架构图描述；第四个对话，粘贴实测CSV数据；第五个对话，输入会议纪要要点。每个对话控制在90秒内完成，生成即用，不修改。这5分钟，我像流水线工人一样精准执行，不思考，只注入。

5.3 第8-12分钟：生成与整合初稿

所有分段内容生成完毕后，我回到第一个对话（三元组骨架），在底部追加：

“现在，请整合以下已生成内容，输出完整方案：
[粘贴‘背景与目标’章节]
[粘贴‘系统架构设计’章节]
[粘贴‘性能压测对比’表格及分析]
[粘贴‘实施风险与应对’章节]
要求：保持原有格式规范，自动补全缺失章节（如‘结论与建议’‘附录’），所有引用链接需可点击。”

Gemini 3.5开始整合。这4分钟里，我做了两件事：

• 用VS Code打开Draft文档，把AI生成的Markdown粘贴进去；
• 同时打开Kong/Apigee官网，准备一阶校验。

当AI输出“结论与建议”章节时，我注意到它写道：“综合推荐Kong，因其开源免费且性能最优”。我立刻在Draft文档中手动修改为：“综合推荐Kong社区版作为PoC首选，因其开源免费且性能满足基线要求；Apigee企业版作为长期演进选项，需同步推进法务条款谈判”。——这就是人的价值：AI给出选项，人做决策。

5.4 第12-17分钟：三阶校验与终稿定型

最后5分钟，是真正的专业时刻：

• 第12-13分钟：一阶校验。我点击方案中所有[1][2][3]链接，确认Kong文档指向v3.7，Apigee Benchmark链接有效，Tyk的GitHub仓库更新日期为2024-05-22。发现一处链接失效，立即替换为Wayback Machine存档链接。
• 第13-15分钟：二阶校验。我用draw.io重画架构图，从Kong网关出发，逆向验证了“mTLS直连降低延迟”“etcd集群增加运维负担”“Lua插件支持自定义鉴权”三条逻辑链，全部闭合。
• 第15-17分钟：三阶校验。我输入CTO压力题，得到前述精准回答。据此在“实施路线图”中新增并行任务标识，并在“风险分析”末尾添加“采购延迟应对预案”子章节。

17分钟结束，我按下Ctrl+S保存Draft文档，导出为PDF，邮件发送给客户。全程没有一句“AI生成”，所有内容都经过我的专业判断与修正。客户回复：“比上次外包公司做的方案更扎实，特别是风险应对部分，直接解决了我们的顾虑。”

这17分钟，不是AI在替我工作，而是我借AI之力，把原本需要3天的手工劳动，压缩到一杯咖啡的时间。提速十倍的真相是：AI负责信息处理与模式匹配，人负责价值判断与责任担当。工具再快，也快不过一个清晰的头脑；方案再好，也好不过一个敢签字的名字。

最后分享一个心得：我从不用AI生成“致谢”或“免责声明”这类边缘内容。真正的专业，始于对核心价值的绝对掌控，终于对每个字的责任感。