最近又开始折腾提示词了。
复杂的逻辑依靠AI来判别，如果不开深度思考，那就太慢了，用户等十几秒才能看到结果。
而且下游会有很多和系统、代码衔接的逻辑，所以我的模型输出是JSON格式，这个过程根本不适合给用户看，流式输出也就不合适了。
所以我在想：能不能不开深度思考，仅仅靠优化提示词，让模型的输出质量持平。
但每次都觉得这次的调优一定更好，但结果还是不稳定：有时对，有时错，有时干脆自作主张。
我们不能总是依赖模型进化来覆盖提示词能力。
直到我开始用学写代码的方式去写提示词，这些问题终于改善了。
01 提示词是工程，而不是写作
最开始写提示词，我以为就是寻常的内容：文风、修辞、语气？
但提示词的第一受众是AI，而不是人类。
这些修饰的语言："优美"、"极致"、"人话",其实在提示词里全是脏数据。
自然语言是创作，代码语言则是约束。当我们说"极致"和告诉模型可以自由发挥没有什么区别。
但提示词其实是定义。
试着把它当成一个函数：接收什么参数？基于什么条件？经过什么处理？返回什么格式？
每一步都应该是确定的，而不是看着办。
所以更合适的方式是用编程的方式写提示词，模型需要的是明确的指令和清晰的边界。
当你把提示词当成代码来写时，你会自然而然地把模糊的意图翻译成可执行的指令：
- 定义输入输出
- 用条件语句描述逻辑分支
- 用类型约束数据格式
02 提示词也应该高内聚、低耦合
海外的云服务商巨头 Cloudflare 在 2 月份推出了 Markdown for Agent，它的核心作用是把HTML转换成Markdown，因为原始的 HTML 充斥着大量的脏数据，很多的代码是为了人类的上限所设计的。
例如为了让人类捕获到信息焦点设计的缩进、换行、颜色、折叠等等，但AI不需要。
自然语言 → 结构化（Markdown）→ 格式化（JSON）
提示词其实也是一样的。最开始我们用自然语言写一段话，后来开始用 Markdown 结构化，再后来用我们发明了很多 JSON 格式。
所有文档都该重写一遍，AI才是最重要的读者，这里也有一些延伸阅读。
而如果是代码，那看待的视角、协作的方式一下就全部改变了。
我们的指令要让 AI 更容易读懂，JSON也更容易给下游的模型或者代码消化。
以前在产品设计中我们会习惯高内聚、低耦合，一个模块完成单一、明确的职责。
其实模型节点也是一样的，例如指代消解、意图识别、查询改写、实体提取、条件判断，这看起来是5件事，但其实都是为了服务一个目标，让我们能够路由到正确的Agent
不拆分的原因很简单，更多的节点意味着更多的耗时和成本，时延在C端几乎很难被忍受。
模型已经聪明到可以在一个节点里处理多个子任务：指代消解、意图识别、查询改写、约束补全、结构化输出。
这些完全可以放在一个模型节点的提示词里做。
但下一个重要的逻辑是：模块边界必须清晰。
外部：高内聚（一个节点承担目标相同的复杂任务）
↓
内部：低耦合（每个子任务独立，改动不影响其他）
例如很多提示词模版里面的角色、输入、背景、目标、行动其实都是在划分边界，让每个模块只负责一件事，这样调整某个功能时，才不会牵一发而动全身。
而且也能显著减少提示词里的废话，废话少了逻辑冲突也就少了，Token少了模型才能够更加稳定。
03 用编程工具写提示词才是版本答案
用 Chat类的AI，例如GPT或者Claude写提示词都会有个大问题：上下文污染。
每次不符合要求就要修改，但模型记得你之前说的所有话，在我们没有明确禁止的时候，就会开始推导你的想法，于是"自作主张"地把旧逻辑加回来，又或者偷偷删除掉一些东西。
但用 Claude Code / Trae 这些编程工具写提示词，完全是另一种体验：
1）文件在本地存储
提示词变成 .md 或 .json 文件，存储在本地，这样AI 按需加载，不需要在上下文里找东西，幻觉会大幅减少。
而且也方便两个版本做对比。
02 Git 版本管理
在不是大版本变化的时候，轻量的改动，可以 commit代码，还能让AI帮你总结，这次改动到底改动了啥，出现问题回滚的速度也会很快，人会忘、模型会忘，但 git 不会。
03 Diff 对比
而存在本地又有了Git之后，人工审核AI 改了什么会变得更加方便，不会再出现自己都忘记改了什么的情况，提示词在AI时代就是代码，就是规则，不能乱动。
04 Plan和智能推断
现在基本所有的编程工具都具备Plan模式了，基于Plan，我们可以不用从零到一的写提示词，通过不断地和AI对谈理清自己的思路，然后最后进行审核。
这里还有一个小技巧是，在思考的时候可以深度选择high或者extra high，然后在执行的时候选择medium提高执行速度。
而自己想要手动改动的时候，Trae还有一个很好用的功能， 会自动基于你的文件上下文推断你接下来要写什么，这也就是俗话说的：Tab大法好。
05 Code Review
既然我们已经认可我们写的就是“代码”，也使用了编程工具，那我们就可以用上很多很强大的能力了。
例如Claude Code 的 simplify 功能，本质上是在审查代码质量，但我们也可以用它来审查提示词质量。
/simplify指令输入后，Claude Code 会同时启动三个平行的 Agent，分别从代码复用、代码质量、运行效率三个角度审查你的改动。
那提示词复用、提示词质量、提示词效率也是相同的，前几天我用这个能力把我的提示词再次瘦身了20%。
而叠加Plan模式，我们可以继续和AI对齐优化的思路，比如：
这个模块的职责是否单一？边界是否清晰？改动这个区域会影响其他地方吗？有没有隐藏的耦合？
用 Code Review 的眼光审视提示词，你会发现很多"语感不错但结构糟糕"的问题。
04 模型、参数的影响远比提示词更重要。
这2个是最常被忽视的误区。
一遇到输出不稳定，第一反应是"改提示词"。但很多时候，问题根本不在提示词。
1）模型陷阱，新模型不一定强
遇见了新的模型我们总会很想快速的去重试，这里会有2种可能：同一个提示词，在 Kimi 上跑得好好的，放到豆包上可能就失效了。
第二个可能是之前出现的很多问题，新模型出来之后完全解决了。
跨模型复用同一套提示词，往往是调试惨案的开始。
不同模型的差异非常大：
- 指令遵循：有的模型更"听话"，有的更爱"自由发挥"
- 中文理解有的对中文语法更敏感，有的偏爱用英文思考
- 上下文稳定性：有的到后面就忘了前面的约束，不要迷信1M上下文，一般几万Token模型就开始出现幻觉了。
而模型进化带来的能力溢出，也意味着我们要再次去对提示词调优了，也许是减少一些重复，也许是可以让这个节点再次负荷更多的内容。
2 ）参数调整会有大惊喜
不同模型的参数其实是有很大差异的：
温度的配置范围、是否支持深度思考、是否支持思考强度、是否支持结构化输出、支持的图片格式....
有的时候调一百遍提示词，不如微调下参数，例如...JSON结构化输出。
以下的参数，云厂商、模型原厂都可能不太相同，可以用来参考。
maxoutputtokens-控制回答长度，防止发挥过度
thinking-深度思考开关
reasoning-深度思考强度
store-存储会话，其实模型自带了简单的上下文管理功能
response_format-强制输出格式
stream-是否流式输出，还是一次性返回结果
tools-模型可以调用的工具列表，包括mcp
temperature-越高随机性越强
想要做好AI产品真的要去啃接口文档，不然你可能要，手动注入上下文，用代码调用工具，设定调用轮次，做很多也许模型厂商已经有过的能力。
最后
最后就分享一个好气又好笑的发现：重复有时候比深度思考更高效。
深度思考模式下，模型会反复推敲你的意图，试图"理解"你的深层需求。但关掉深度思考后，模型更像一个直接的执行器。
调了无数次结构、格式、流程、删除冗余，但都达不到好的效果。
直到我把那句重要的话在开头、中间、文末重复了1次，忽然就稳定下来了。
虽然格式层面不干净，有了脏污染，但确实能够缓解模型失忆的情况。
比如，你不希望模型添加额外解释，不要只说一次，可以在开头、中间、结尾分别说一次。
