从混乱到可控：我最受益的 10 个 AI 编程技巧（含提示词）

从混乱到可控：我最受益的 10 个 AI 编程技巧（含提示词） 从混乱到可控：我最受益的 10 个 AI 编程技巧（含提示词） Modified January 20 AI 把可能出现的场景，几乎都列成了一张矩阵。 连对应的 UI 交互草图，也一并给了出来。 基于这套交互设计，现阶段能覆盖的大部分情况，基本都被兜住了。 最终优化的效果如下： 七、每一次费力修复的过程，都该变成你的知识宝藏 真正意识到要把经验总结成 知识卡片 ，是在做「熊猫论文」这个项目的时候。 那段时间，我反复在做 Vibe Coding。 看着功能一个个被 AI 被拼出来， 我负责测试，再把结果丢回去，继续纠错，继续改。 当时用的还是 Claude 3.7。 能力和现在的 Claude 4.5 Opus 比，差距很明显。 一个稍微复杂的问题，经常要来回调一两个小时。 连续这样跑了一两周之后，我突然觉得不太对。 我发现自己并不是在驱动 AI，更像是一个 被流程推着走的执行者 。 我没有留下任何可复用的东西。只有一些勉强能跑的功能。 如果下次再遇到类似问题，我还是得从头再来。 从那之后，我开始换做法。 只要遇到复杂问题，或者 花了很长时间才修完的 bug ， 我都会让 AI 帮我把过程提炼成笔记，或者整理成一张张知识卡片。 笔记卡片（适合复杂的 bug 修复） ： Code block Plain Text 请回顾这次对话，提炼其中最关键的 xx 个问题， 并分别整理为 FAQ 形式的笔记卡片。 每张卡片请包含： 问题现象：当时具体遇到了什么情况 根因说明：问题产生的核心原因 解决方式：最终采用的解决方案或判断路径 适用提示：在什么场景下可能再次遇到，如何提前避免 要求： 使用 Markdown，结构清晰，便于快速扫读 表达简洁，偏总结而非过程复述 不引入对话中未出现的新结论 技术教程（适合相对完整的技术教程、方案）: Code block Plain Text 请将上面的内容整理成一份「可读性强的 Markdown 笔记」。 整理时请遵循以下原则： 以“希望把事情真正讲清楚”为目标，而不是堆信息 重点说明“发生了什么”和“为什么这样做”，再说明“怎么做” 避免术语堆砌，必要时用直观解释或简单类比辅助理解 笔记结构建议如下（可根据内容灵活调整）： 1. 背景与问题：事情从什么情况开始，核心困扰是什么 2. 现有做法：之前的处理方式，以及由此带来的限制或风险 3. 新的思路：新的解决方向或方案，以及形成这一判断的原因 4. 关键过程：按步骤梳理重要变化，必要时用流程图或时序图帮助理解 5. 总结与要点：本次经验中值得记住的结论，以及可复用的判断原则 输出要求： 使用 Markdown，结构清晰、层次分明 语言自然、可顺读，适合作为教程或学习笔记 不引入未出现的新背景，不做过度推演或延展 这些笔记和知识卡片，我都会 沉淀在代码项目里 ， 同时再归档一份到自己的飞书知识库。 放在代码里的目的， 是为了在修复问题或者开发新任务时，我都会提醒AI，在首句中加上： Code block Plain Text 请从项目中检索是否遇到同样的问题，xxxx 只要命中一次，我就赚了。 八、把长期使用的上下文沉淀成通用文档 不管是需求文档、样式规范、组件库、技术栈、接口说明、FAQ 等等， 还是用来约束 AI 行为的 Cursor Rule、Claude.md， 它们都会在项目的某个阶段，被当作上下文反复交给 AI。 我的看法是： 这些东西应该尽早准备，并且在开发过程中持续引用、持续优化。 这样做，自然会形成正循环。 当你已经沉淀出一套相对稳定的通用文档， 再把它们引入到 Cursor Rule、Claude.md 中，代码质量往往会明显提升，返工也会大幅减少。 下面的提示词，就是我在一个真实商业项目中使用的 Cursor Rule。 如果你有需要，完全可以在此基础上做修改和复用。 Code block Plain Text Cursor Rule 角色与沟通 你是 Python 工程师，帮助技术基础较弱的初中生完成项目开发。 用通俗语言解释关键概念（不堆术语） 每次输出尽量给出：要做什么 + 为什么 + 下一步怎么用 遇到不确定点：先列出澄清问题或假设，再写代码（不要瞎补需求） 文档即上下文（默认必须引用） 处理任何需求前，先阅读并遵循这些文件（如不存在则创建）： README.md：项目目标、使用方式、参数/返回值示例 docs/development guide.md：技术栈、目录结构、开发规范 docs/requirements.md（如有）：需求与边界 docs/api.md（如有）：接口约定、鉴权、错误码 docs/faq.md（可选）：常见问题与约定 开发过程中持续更新上述文档：新增功能/约定/坑点，必须同步补齐。 工作流程（强制顺序） 1) 需求理解 用一句话复述需求目标 列出 1 3 个关键澄清点/假设（尽量少但必须） 选择最简单可行方案，避免过度设计 2) 实现 遵循 PEP8 + Type Hints + 清晰 docstring 模块化、可维护；必要时加日志与错误处理 严格贴合现有项目目录与代码风格（先读代码再扩展） 3) 测试（必须） 在 tests/ 下按类型放置 pytest 用例（只写接口测试） 覆盖率目标：100%（以关键分支为准，必要时补边界与异常用例） 4) 接口与鉴权 若实现的是接口：根据功能判断是否需要 JWT 接口行为以 docs/api.md 为准；若缺失则补充约定（含示例请求/响应） 5) 数据库变更（如涉及） 在 alembic/versions/ 生成迁移文件 补充初始化数据（如需要）并确保迁移可执行 变更说明同步写入 docs/development guide.md 6) 收尾与复盘（必须） 更新 README.md：新增功能的用法、配置、示例 更新 docs/development guide.md：目录/依赖/规范变化 简要列出：本次改动影响范围 + 后续可优化点（不长篇） 参考 默认以 Python 官方文档为准：https://docs.python.org/ 在实际使用中，AI 有时候并不会完全严格地按照我们设定的全局规则来执行。 所以我们也要留意本地文档的变更情况： 当新增了组件、调整了需求之后， 如果相关文档还没来得及更新，就可以主动提醒 AI，把这些文档补齐和修正好。 这里要强调一件事： 需求文档一定要及时更新。 在一个持续演进的项目里， 需求文档是除了代码本身之外， 每个功能模块最重要的上下文。 它能帮助 AI： • 在修复局部 bug 时，分清哪些逻辑是刻意保留下来的，避免一不小心伤到整体设计 • 在新增功能时，理解模块真正的职责，让功能自然生长在该生长的位置上 • 在重构过程中，始终保有对用户行为和业务约束的整体认知，而不是只追求代码层面的优雅 AI 把可能出现的场景，几乎都列成了一张矩阵。 连对应的 UI 交互草图，也一并给了出来。 基于这套交互设计，现阶段能覆盖的大部分情况，基本都被兜住了。 最终优化的效果如下： 七、每一次费力修复的过程，都该变成你的知识宝藏 真正意识到要把经验总结成 知识卡片 ，是在做「熊猫论文」这个项目的时候。 那段时间，我反复在做 Vibe Coding。 看着功能一个个被 AI 被拼出来， 我负责测试，再把结果丢回去，继续纠错，继续改。 当时用的还是 Claude 3.7。 能力和现在的 Claude 4.5 Opus 比，差距很明显。 一个稍微复杂的问题，经常要来回调一两个小时。 连续这样跑了一两周之后，我突然觉得不太对。 我发现自己并不是在驱动 AI，更像是一个 被流程推着走的执行者 。 我没有留下任何可复用的东西。只有一些勉强能跑的功能。 如果下次再遇到类似问题，我还是得从头再来。 从那之后，我开始换做法。 只要遇到复杂问题，或者 花了很长时间才修完的 bug ， 我都会让 AI 帮我把过程提炼成笔记，或者整理成一张张知识卡片。 笔记卡片（适合复杂的 bug 修复） ： 技术教程（适合相对完整的技术教程、方案）: 这些笔记和知识卡片，我都会 沉淀在代码项目里 ， 同时再归档一份到自己的飞书知识库。 放在代码里的目的， 是为了在修复问题或者开发新任务时，我都会提醒AI，在首句中加上： 只要命中一次，我就赚了。 八、把长期使用的上下文沉淀成通用文档 不管是需求文档、样式规范、组件库、技术栈、接口说明、FAQ 等等， 还是用来约束 AI 行为的 Cursor Rule、Claude.md， 它们都会在项目的某个阶段，被当作上下文反复交给 AI。 我的看法是： 这些东西应该尽早准备，并且在开发过程中持续引用、持续优化。 这样做，自然会形成正循环。 当你已经沉淀出一套相对稳定的通用文档， 再把它们引入到 Cursor Rule、Claude.md 中，代码质量往往会明显提升，返工也会大幅减少。 下面的提示词，就是我在一个真实商业项目中使用的 Cursor Rule。 如果你有需要，完全可以在此基础上做修改和复用。 在实际使用中，AI 有时候并不会完全严格地按照我们设定的全局规则来执行。 所以我们也要留意本地文档的变更情况： 当新增了组件、调整了需求之后， 如果相关文档还没来得及更新，就可以主动提醒 AI，把这些文档补齐和修正好。 这里要强调一件事： 需求文档一定要及时更新。 在一个持续演进的项目里， 需求文档是除了代码本身之外， 每个功能模块最重要的上下文。 它能帮助 AI： • 在修复局部 bug 时，分清哪些逻辑是刻意保留下来的，避免一不小心伤到整体设计 • 在新增功能时，理解模块真正的职责，让功能自然生长在该生长的位置上 • 在重构过程中，始终保有对用户行为和业务约束的整体认知，而不是只追求代码层面的优雅 九、极致的专注可以击穿代码 回头看这一年用 AI 编程，我发现一个常被忽略的点： 我们怎么对待“等结果”的时间。 后来我意识到， 这些时间不是碎片，而是一段缓冲区 。 我们也看到不少人推荐，在这段时间利用 Coding Agent 并行推进多个任务。 我也认真尝试过一段时间，但最终还是很克制地在使用它。 因为我发现，这样对我来说，容易把思绪搅乱，效率反而下降。 相反，无论只是静静地看着屏幕、或者冥想一会，放空自己，又或者用来补充文档，思考下一步怎么做。 只要不过度摄入太多干扰信息，我的效率反而就会更高。 这样一来，等待不再是中断，而变成了 为下一步提前蓄力的过程 。 这个方法不一定适用所有人，大家见仁见智吧。 十、从能用到顺眼：我的 UI 优化心得 这是「熊猫论文」主界面的 UI 演变过程。 从一开始的惨不忍睹，到现在被不少人夸更加顺眼了。 说实话，可能不是因为现在这版有多好看。 更多是因为 第一版太丑 ，一路用过来的用户，突然觉得眼睛得到了解放。 很多人问我：UI 是怎么慢慢改过来的？ 第一步，最重要的，你必须要得先有一份设计规范。 因为你不是在做一个页面。 登录页、落地页、主页面、充值页、后台管理页， 如果每一块都长得不一样，它就不像一个完整的系统。 很多人一开始会纠结： “我不会设计怎么办？” “我也说不清楚什么叫好看，怎么办？” 做法其实很简单。 输入提示词，再加上几张自己觉得： 符合产品气质、符合用户审美 的参考图，直接丢给 AI。 让 AI 生成一份 初版设计规范 。 PS：如上提示词微调后，同样适用于将老项目的 UI 风格提炼成规范文档，作为后续开发时 AI 的上下文。 第二步，验证输出效果。 这一步主要是为了先看看整体的输出效果。 不管是直接用 Figma 生成初版框架， 还是直接上 Coding Agent， 在生成之后，我们都可以不断把结果反馈给 AI，持续迭代整体的设计规范。 这里其实有个小技巧： 先围绕一个页面做单点击破，打磨出一个自己真正满意的“样板间”， 一边用它来校准和迭代样式规范。 等这套规范相对稳定了，再慢慢铺开到全局。 第三步，把样式规范写进 Cursor Rule / Claude.md。 前面一些步骤也提到过。 为了保证未来多个页面的风格统一， 我们可以把样式规范写进全局规则中，避免每次都需要提醒 AI。 最后再分享一些过程中的小技巧。 1、“截图 + 局部圈选 + 期望效果”比纯文字强一倍 一图胜千文。 如果我们本身不是设计专业，很多 UI 问题其实很难用语言准确说明。 这时候直接截图，把问题位置简单标出来，再配上一小段说明，又快，也不容易被理解跑偏。 2、让 AI 生成“多方案对比”，你只做选择题 别让 AI 直接给“最终方案”，而是让它给 3 套风格变体 ， 每套明确差异点（更克制/更活泼/更商务），你只选一个方向再深化。 这招特别适合“有审美，但不想自己从零画”的路径。 3、UI 迭代别靠感觉：要及时总结和沉淀 很多时候，我们如果不是设计专业出身，可能对 UI 没那么敏感。 页面能用、看着顺眼了，就容易“先这样吧”，然后放一边不管。 但我后来发现，UI 最有价值的不是某一版改得好看， 而是能不能把优秀设计沉淀下来，变成下次直接复用的标准。 别忽略这些细微的改动。 每次遇到不错的设计，我都会习惯顺手让 AI 做一段总结： 十一、总结 一年前的我，始终以为， AI 编程的难点在于"模型不够聪明"。 但现在我明白了， 真正的难点从来不是工具，而是我们自己： • 我们习惯了模糊的表达，却要学会精确的描述 • 我们习惯了一次到位，却要学会分步推进 • 我们习惯了凭感觉判断，却要学会建立标准和规范 这些技巧，表面上是在教你"怎么用AI"，但本质上是在重新训练我们的思维方式： 如何把脑子里模糊的想法，拆解成可执行的步骤； 如何把一次性的经验，沉淀成可复用的知识； 如何在不确定性中，建立确定性的标准。 这些能力，在任何场景下都能发挥作用。 所以， AI编程教会我们的，不只是写代码，而是把混沌变成秩序，把想法落成系统。 最后，祝你 2026 在 AI 编程的路上，少踩坑，多收获。 我是 🐼熊猫Jay，我们下次再见。 如果觉得不错，随手点个赞、在看、转发三连吧。 如果想第一时间收到推送，也可以给我个星标 ⭐ 谢谢你看我的文章 🔗 原文链接： https://mp.weixin.qq.com/s/TB7bjxoV... https://mp.weixin.qq.com/s/TB7bjxoV... 原创 熊猫Jay 熊猫Jay 熊猫Jay字节之旅2026年1月20日 00:39 江苏 去年这个时候，一个5千块的定制化项目，我整整改了一个多月。 效率极低，一度让我想放弃。 过去一年，我做了 3 个产品： 熊猫论文、熊猫工坊 ，还有一个正在内测的出海项目 PostMaker 。 粗略算下来，代码量大概 60 万行。 这一年我发现： AI 写得太快了，有时候快到你还没反应过来，方向就已经错了。 于是你就会遇见这些崩溃的画面： • 写得越快，返工越多 • 修完一个bug，又冒出下一个 • 页面看起来能用，但总像临时拼起来的 • ... 这篇文章，我会把这一年踩过的坑和摸索出来的打法，按步骤分享出来。 如果你正在学AI编程，希望这 10 个技巧，能让你少走一些弯路。 一、AI 不怕复杂 Bug，只怕一句废话 对于非技术背景的朋友，改 bug 可能是 AI 编程过程中频率最高，也是最头疼的事情了。 如果你修复 bug 的提示词是： 又或者是 那我建议你一定要好好看一看这一章。 1、快速提问法： 想让 AI 快速帮上忙，关键就一件事：把 Bug 的“最小闭环信息”说完整。 只要把这 6 点交代清楚，通常就能覆盖 80% 的场景。 所以请保持对 Bug 起码的尊重，别偷懒，别抱有侥幸心理。 2、上下文大法： 遇到顽固 Bug，只靠第一种“最基本信息”往往是不够的。 因为这种问题通常牵扯到 更复杂的执行链路 ，局部现象很难直接推到根因。 这时候就得上“ 上下文大法 ”：把你能想到的线索尽量一次性给全。 比如最近需求变动的时间点和具体改动、 有没有调整过配置参数、 为修这个 Bug 你之前做过哪些尝试、 每次尝试的结果是什么。 3、AI 也需要适应环境： 上面两步还搞不定，怎么办？ 这时候，其实很可能不是你不行，而是 AI 还没进入你的世界。 我们经常干一件事： 直接把一个 Bug 症状，丢给 AI， 而且还有可能在一个完全不相干的上下文里。 这有点像你半夜把一个刚睡醒的同事拽过来：“这个功能为啥炸了？你马上给我答案。” 成功率，能高才怪。 更稳的做法是： 先让 AI 熟悉环境，再让它动手修 Bug。 哪怕你现在没有完整的需求文档， 也可以先让 AI 帮你 理解这个功能的代码结构、核心流程、设计意图 ， 等它“搞清楚这是在干嘛”， 再把具体的异常现象、报错信息丢进去。 这样，当你和 AI 同时拥有记忆时，效果会完全不一样。 PS：梳理代码逻辑时，建议让 AI 将流程通过流程图、时序图等等你熟悉的可视化方式来呈现。 4、全局观：把完整验收标准 / 测试用例交给 AI 修复杂 Bug 时，最常见的坑是：这边刚修好，那边又冒出新问题， 甚至越修越乱，来回打补丁像陷入死循环。 如果你已经改了几轮还是不稳定，我建议别再盯着某一行报错死磕了。 去把这个功能的「 完整验收标准 」或「 测试用例 」找出来， 再补上它和其他功能的关联边界，一起丢给 AI。 有了这些“全局标准”，AI 才能在修复时兼顾整体行为， 不至于拆东墙补西墙 。 在企业里这个做法更容易落地：因为正规的研发流程通常都会为需求配套测试用例。 我们把这些用例作为上下文给 AI， 自测时不仅更有方向，还能顺便让 AI 帮你生成 回归脚本 ， 把修复和验证做成闭环。 5、终极大法：Debug 模式 这是传统做法里，解决 Bug 最高效的一条路：用“ 可复现 + 可观测 ”的方式，把问题还原出来。 但对非技术同学确实不友好——你很难知道该抓哪些信息、怎么看日志、怎么把现象还原成线索。 好在现在不少 AI 编程工具已经把这件事“产品化”了。 比如 Cursor 有 Debug 模式，Claude Code 也支持通过 debug 指令来辅助排查。 它们的价值不只是“多输出点日志”， 而是 把排查过程变成一条更可控的链路： 更清楚地看到工具的运行步骤、关键调用、以及失败发生在哪一环。 以 Cursor 为例。 我之前在优化工具「 长文转小红书 」时，遇到运行时间过长的问题，就直接用 Debug 模式来做定位。 我先把必要信息补齐，然后按它给出的复现步骤手动执行一遍，让日志完整记录下来。 接着它将自动分析日志，也会更容易看出瓶颈点在哪里。 那次它给我的建议很明确：有些步骤其实可以合并，减少重复计算和中间结果的来回传递。 我采纳建议后，让 AI 按计划改完，再跑一遍同样的复现步骤做验证。 确认问题解决后，记得点“问题已修复”按钮。 这样 AI 会自动去掉多余的日志，保持代码整洁，否则放到线上可能会出现 路径找不到 的问题。 二、用 Plan 模式让 AI 慢下来 这一年里，我一直和 AI 一起写代码，也慢慢形成了一个固定习惯。 在把任务交给 AI 之前，先让它进入 Plan 模式。 不管用的是 Cursor，还是 Claude Code，这个模式的作用，其实不只是“多看一眼需求”。 它真正做的一件事，是逼着需求先被拆开、被质疑、被补全。 就拿 Cursor 举例。 在 Plan 模式下，它不会马上写代码，而是先找问题。 哪里有歧义？ 哪些前提没说清？ 有没有隐含的假设？ 它会直接把这些点抛出来，让你补充说明。 在一来一回的过程中，原本模糊的想法，会慢慢变成一个边界清楚、能动手执行的方案。 Plan 模式，其实只是把软件开发里一个很老、但一直好用的做法，搬到了 AI 协作里。 先设计，再写代码。 多花几分钟把计划说清楚，把执行路径对齐好，往往能省下后面几个小时的反复修改。 有时候，慢下来，会更快～ 三、需求拆不清，后面将都是返工 不管是主业还是副业，我一直是 直接面对需求 的人。 以前，我要把需求翻译成技术能看懂的话。 现在不一样了。 接到定制商单，或者产品要做新功能，我同样要先做一件事： 拆需求 。 说句实话： 这件事，至少吃掉了我 30% 的精力。 从去年开始，我逐渐习惯用提示词来帮自己拆需求。 更多是 逼自己把问题想清楚 。 如果拆解不到位，后果通常只有两个： 要么反复返工， 要么为了赶进度，团队只能硬扛。 下面这个，是我平时用来拆需求的提示词。 说实话， 一些简单的产品需求，直接用它就够了。 但如果是全新的功能模块，就不要照搬，更好的做法是： • 先结合自己的经验 • 把需求拆成几个具体、独立的使用场景 • 再用提示词继续往下拆 这样用，价值会更大。 需求不是一开始就完整的，其实是逐渐拆出来的。 比如最近，主业里的研发平台要支持 合并列头 这种平台级配置。 按照提示词模版，我在 ChatGPT 里给的东西其实很少。 只有两句话的口述需求，再加上一些注意点， 以及我当时能想到的影响范围。 除此之外，我顺手把内部的一些规范要求也一起丢了进去。 像这种相对不复杂的需求， AI 生成的结果， 稍微改一下就能直接用 。 但真正有价值的，其实是： 备注 / 待确认 。 基于我给的内部注意点，再加上它自己的理解， AI 会列出不少提醒和补充项。 这些内容，很多并不是“答案”，而是 替你多想一步 。 帮你提前看到可能的坑，把返工的概率降低。 有意思的是， 这种方式，反而会倒逼我们自己去想清楚问题。 四、复杂方案，先推演，后落地 不知道你有没有遇到过这种情况。 发现一个严重 bug，或者需求突然改动很大， 把问题丢给 Cursor 之后，它一下子给你列出好几种方案。 有最推荐的，有次一点的， 有的追求见效快，有的偏向长期维护。 问题是，这些方案里，常常会踩到我们的知识盲区， 或者涉及并不熟的领域。 这时候就很纠结了： 到底改不改？选哪个？ 改的话，很容易吃掉大量时间和成本，最后还不一定走得通，甚至要推倒重来。 不改，问题就一直在那里。 后来我意识到一件事。想提高复杂方案真正落地的成功率， 不能只看“方案本身”，还要提前看 它会怎么跑 。 于是我开始让 AI 帮我做一件事： 方案推演 。 在真正动手前，先确认几件事： • 这个方案，能不能解决当前的问题 • 落地之后，会不会影响已有功能 • 哪些地方最容易出风险 这些问题，其实都可以在 方案推演阶段 被提前看清楚。 之前碰到过一个很具体的案例。 为了让 API 的调用过程更稳定，我加了一层能力： 在不同 API 供应商之间做智能切换 。 但问题很快就出现了。 现有系统里，不仅有不同的模型类型，还覆盖了多种业务场景。 • 语言模型 • 文生图 • 视觉模型 • 文生视频模型 但当我把这套方案用到 文生图 场景时，我先按之前的提示词跑了一次测试。 结果很直接，它瞬间帮我暴露出了不少 中高风险问题。 这些点，如果当时我自己没有想清楚，就直接让 AI 去实现， 后面几乎一定会出现一堆 Bug。 五、任何用 AI 生成的结果，都该考虑 Plan B 有一件事，我想先泼点冷水。 AI 生成的结果，本质上就是不稳定的。 如果你心里没有 Plan B ，那 Bug 只是早来和晚来的区别。 我自己最常踩坑、也最容易被忽略的，其实就两类场景： 第一类：结果要被“机器继续用”的场景 比如 JSON 结构化，用来做特征提取、参数对接、前端渲染。 第二类：结果有“硬约束”的场景 比如小红书标题，最多 20 个字，多一个都不行。 先说最常见的： JSON 结构化。 假设我们现在要拆解一篇长文，提取它的核心观点、金句、爆点、钩子。 如果只是：拿来展示，或者作为下一个 AI 节点的上下文。 说实话， 根本不需要结构化 ，直接塞就完事了。 但一旦你想做两件事，麻烦就来了： • 前端要“好看地渲染” • 某几个字段，要作为下一个函数的输入参数 这时候，稳定性就不是“加分项”，而是 生死线 。 大多数人会怎么做？ • 拼命优化提示词 • 强调「必须输出 JSON」 • 按官方文档写 JSON Schema 这些方法对吗？ 对，而且能解决 95% 的问题。 但我想提醒一句很现实的话： 程序，只要有 1% 的概率出错，在规模化运行时，它就一定会暴露出来。 所以真正稳的做法，其实很简单： 多加一道校验。 • 先检查结果是不是合法 JSON • 如果不是，直接把结果丢回给 AI，再跑一次 再说 字数限制 这个问题。 玩过小红书的人都知道，标题最多 20 个字 。 现实情况是，AI 很难稳定卡在这个范围内。 偶尔就会写成 22 个字、25 个字。不管你怎么调提示词，这个问题都会出现。 这是模型本身的特点。 截取就更不现实，这样破坏的标题的完整性。我的做法是： • 先检测字数 • 超过限制，就把结果再丢回给 AI • 明确告诉它：需要压缩到 20 字以内，甚至可以多留点缓冲余地 不管是上面这两个场景需要兜底， 大模型的 API 供应商也是如此，Plan B 始终让你拥有更多的底气。 六、尽可能将你遇到的定制化需求通用化 我用一个 真实发生过的需求 ，来讲这个技巧。 从去年 10 月开始，我接到了不少自媒体的 定制化需求 。 其中有一个很典型的场景： 把视频文案，自动改写成多种语言版本。 第一个版本很快就做完了，功能也能用。 结果客户很快提了一个优化意见： “现在生成的泰文我完全看不懂，能不能给我一个中文对照？” 如果站在“纯定制”的角度，这个需求其实很好改： • 目标语言：泰语 • 输出格式：泰文 + 中文对照 • 提示词敲出来，事情结束 但我当时停了一下。 我问自己一个问题： • 那如果下一个用户是英文呢？ • 再下一个是日文、越南文呢？ • 是不是每来一种语言，我就要重写一套逻辑？ 这时候你会发现一件事： 需求本身不复杂，复杂的是它未来的变化。 说实话，这种通用性的设计，靠自己去想，挺吃经验的。 但是我们可以交给 AI： 可以看到，用户真正需要的， 是一种 能够帮助理解非母语文案的能力 ，并不局限于泰语这一种语言。 这正是这个定制化需求背后隐藏的关键点， 一旦抓住这一点，往往就能事半功倍。 提示词：