现在的程序员，做的事并没有变简单，只是内容变深了、变复杂了。当你觉得 AI 很强时，可能只是任务太简单。真正复杂的任务，永远需要你付出足够的精力和时间去打磨那些属于你自己的 SKILL。
我最近看那些所谓的“提示语工程黄金准则”越来越不爽了。是的，前两天我刚分享过一次，但我发现大家理解得不太对，或者说我当时没有讲明白。
满大街都在教你“扮演一个资深专家”、“给 AI 一些赞美”、“一步步思考”，这些老掉牙的教条在 AI 编程和 Agent 漫天飞的今天，不仅是废话，甚至成了绊脚石。信息爆炸时代，如果你还在用 1.0 时代的聊天逻辑去对付 2.0 时代的智能体，那你不仅是在浪费自己的 token，更是在亲手束缚 AI 的手脚。
有读者给我留言，说这些东西落伍了，是的，老六条法则确实落伍了，盲目奉行只会让你陷入低效的泥潭。今天，我们得聊聊真正能打的“新六条”。
过去我们总喜欢说：“你是一个拥有 20 年经验的资深安全专家”。大家觉得只要给了定义，AI 就能脱胎换骨。
但在现在，大语言模型已经足够强悍。你给它一个“资深安全专家”的身份，可能反而限制了它的视野。如果一个问题同时涉及安全与架构，它到底是该按安全专家的刻板架构来，还是兼而有之全盘考虑效率？角色设定无法突破模型的知识边界，反而可能放大某种偏见，把模型引进信息的狭隘胡同。
当然，我不是说角色定义完全没用，而是你得明白什么时候它是一种保护，什么时候是枷锁。比如写小说，你可以说“你是一位富有经验的新式小说家”，这是一种文体导向。但在处理复杂的业务逻辑时，给它特定的理论框架（如 AWS 架构原则）远比给它一个虚无缥缈的身份更有用，例如：
“请根据 AWS Well-Architected Framework 中的最小权限原则，审查以下 IAM 策略并指出风险。”
很多人还在纠结要不要在提示词里写“请一步步思考”。事实是，在 Antigravity 这种现代 Agent 工具里，这已经是铁律，是内化在 Implementation plan 里的基本机制。
Agent 早已明白：思维链（CoT）不是一种技巧，而是一种生存方式。如果你只是写个简单的小工具或说明书，根本不需要你废话。但如果你在搞垂直领域的复杂业务逻辑，你依然需要这种步步为营的思维。
我常用的方式是把它们联合起来：先在 thinking 标签里做逻辑分析，再到 review 标签里搞评审，最后才给出 final_verdict。这叫专业，不叫玄学。
给个综合示例：
“……请先在
<thinking>标签内对整个任务写下你的逻辑分析及执行步骤，接着在<review>标签内写下评审意见，然后根据评审意见自我修正，最后再在<final_verdict>标签内给出你认为最专业的结论。”
以前我们要 AI “不确定就说不知道”，是为了防幻觉。现在 AI 动辄处理百万级上下文，幻觉已经不是核心矛盾了。它现在已经很少产生幻觉了，你已经多少时间没有看到 AI 产生幻觉了？
这时候，这条规则变成了一把双刃剑。
如果是搞严谨的项目，你当然要它“极度自信才回答”；但如果我在搞文学创作，还加这种紧箍咒，那就是在扼杀 AI 的想象力。我需要它的想象瑰丽奇幻，需要它飘逸，这时候更适合的提示语是：
“你要充分发挥想象力，所思所想俱瑰丽奇幻且又合乎逻辑”。
而如果我在写论文，最适合的提示语仍然是：
“请你只在极度自信时回答，不确定就说‘不知道’，谢谢。
这条规则永远不会过时，甚至越来越重要。
在这个 Agent 协同的时代，我们给 AI 看的东西、AI 吐出来的东西，都必须是结构化的。为什么？因为我们要实现自动化，我们要让程序能精准解析。
别再发一段乱七八糟的文字了。把信息塞进标签里，让 AI 把结果也吐进标签里。这种输入输出的结构化，是流程化协作的基石，是实现“自造工具”的前提。
给个综合示例吧：
“我给你的信息放在了
<tag>...</tag>标签内……请将你提取到的车牌号放在<plate>标签内，将最终的理赔判断放在<final_verdict>标签内。输出时请以 time json 字符串开头：{time:……”
但要记住，我给出的示例永远只是示例，它不是准则。准则需要你自己理解、内化，然后应用于自己的创作实践中。
说一千道一万，看别人的准则永远是在看别人的生活。
前两天我看到一句话，深有感触：只有自己内化的 SKILL 才是真正的 SKILL，仓库里或硬盘里的，那只是别人的东西。每个人需要的技能都不同，你必须形成自己的技能并内化下来。
这是一个不但有工具使用，还可以自造工具的时代。有扳手钳子，也有能制造扳手钳子的车床。
我最近就在优化我自己的技能库，我使用法则新六条优化技能也就一句话的事：
“请按照以上提示工程新六条，依次优化 .gemini/skills 目录下的每个 SKILL”。
就这一句，比你研究一百遍SKILL都好使。所谓提示语工程的法则，是 SKILL 的 SKILL。
最后明确一下，我给出的示例只是示例，并不是万能钥匙。你要理解，然后应用。别再拷贝了，去创造吧。
2026年05月21日
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。