我如何与 AI 有效沟通 - "AI 驾驭术"入门分享
如今谁还没有用过 AI 呢？
身边几乎所有人都在用 AI，从老人到小孩。但是不同的人用 AI 的方式不一样，得到的结果也不一样。
有人把 AI 当成一个搜索引擎，快速地找到答案，这挺好。这是 AI 使用的起步阶段。
也有人通过 AI，十倍甚至几十倍地提高自己的工作效率。有人用 AI 编程，开发出各种各样的工具；有人用 AI 做研究、写作、设计、运营；有的人甚至真的从中获得了不错的收益。
如果你不想仅仅停留在 AI 使用的起步阶段，想往前更多地了解，我很愿意分享一下我的经验。
先简单介绍一下：我做了 20 多年的互联网产品设计，有丰富的从业经验，特别是和程序员合作的经验。但是，我始终可以说几乎不懂代码。
我不懂代码，但是我现在正在用 AI 编程，而且已经做出几款产品。对我来说，AI 最重要的意义，不是让我突然变成程序员，而是让我有机会把自己原来很难落地的想法，一点一点变成真的东西。
所以这篇文章不是一篇技术教程。
我更想分享的是：一个非技术背景的人，应该如何与 AI 有效沟通。
我后来发现，用好 AI 不是那么复杂：把目标说清楚，把背景讲明白，把限制条件交代出来，把结果标准设定好，然后不断校准 AI 的工作方式。
说白了，这还是沟通。
01 沟通之前，先了解你沟通对象的性格
这里说的“性格”，当然不是说 AI 真的像人一样有情绪、有动机。
我的意思是，AI 在使用中会表现出一些很稳定的倾向。
这和与人的沟通一样。不同的人有不同的沟通方式，你要先知道对方大概是什么样的沟通对象，才知道该怎么说话、怎么拿结果。
我觉得 AI 至少有这么几个特点：
- 能力很强。
- 很喜欢偷懒。
- 很喜欢讨好主人。
AI 具备很强的能力，这一点就不用说了，大家都知道。很多人第一次被 AI 震到，也正是因为这个。
但能力很强，不代表它默认就会给你最好的结果。
AI 很喜欢偷懒的意思是：如果你没有给它设定标准或约束，它往往会选择最容易完成、最安全、最像模板的答案。
你让它“写一篇文章”，它就给你一篇看起来完整、但很普通的文章。你让它“帮我分析一下”，它就给你几个常见角度。
不是因为它不聪明，而是因为你没有告诉它，什么叫做“好”。
AI 也很容易讨好你。这点我相信很多人都有感受。你让它看一段文字，它很可能会先说“这段写得已经很好了”，然后再给你几个温和的建议。
可是很多时候，我们需要的不是被安慰，而是更客观的答案。
所以，和 AI 沟通时，我们不能只把它当成一个会回答问题的工具。我们还要知道它默认会怎么回答，然后主动给它规则、标准、约束，甚至要求它反过来挑战我们。
也正因为这样，接下来这些沟通方法才有意义。
02 不要随意提问，先准备好问题
我觉得这一点不是分享方法，而是分享一个观念。
很多人用 AI 用得比较随意，打开输入框，劈头盖脸就是一段没头没脑的输入。最后还要抱怨 AI，说它怎么这么低能、这么笨。
要知道，如果你想得到一个好的答案，首先你得准备一个好的问题。
这里的提问，不是说你要学会写很复杂的 Prompt，而是你至少要先想清楚几件事：
你到底想让 AI 帮你做什么？ 这个结果是给谁看的？ 你希望它以什么形式交付？ 哪些东西是它不能做的？ 做到什么程度，才算是完成？
如果这些问题你自己都没有想过，AI 大概率也只能猜。它猜对了，你会觉得它聪明；它猜错了，你会觉得它胡说。但说到底，很多时候不是 AI 不行，而是我们给它的任务本身就很模糊。
一个好的问题，往往已经完成了一半的工作。
03 如何起步：使用元提示（Meta Prompting）
如果你第一次接触 AI，或者第一次用 AI 处理专业性的工作，那么此时 AI 就像一款你刚拿到手、从未被使用过的新机器。
在这种情况下，你应该如何起步？
很简单，你要问的问题就是：我该如何开始使用？
比如说，你想学 AI 编程。你不一定要一上来就问：
「请帮我写一个完整的 App。」
你可以先问：
「我是一个不懂代码的产品设计师，但我想尝试用 AI 做一个小工具。请你先告诉我，我应该从哪里开始？我需要准备哪些信息？我应该避免哪些常见错误？」
这个方法简单到有点好笑。 如果你使用过一次，你甚至不会觉得它是一个方法，因为它太简单了。
但是它可以打破你对于 AI 的陌生感和恐惧感。
更重要的是，它会把你从“我必须一次性问对”的压力里解放出来。
你也可以直接让 AI 帮你设计问题：
「我想完成这件事，但我不知道该怎么问你。请你帮我把我的需求整理成一个更好的 Prompt。」
这就是所谓的元提示。不是直接让 AI 做事，而是先让 AI 帮你想：这件事应该怎么交给 AI 做。
我自己经常这么用。因为很多时候，我不是不知道自己想要什么，而是不知道在一个陌生领域里，应该用什么结构把这件事讲清楚。
04 向 AI 提问之前，可以让 AI 先向你提问
当我们用 AI 去做一些复杂的事情时，事情本身往往会超出我们个人的知识范围。
比如我做产品设计，我可以讲清楚用户是谁、场景是什么、体验上哪里不舒服。但是一旦进入工程实现、数据库、部署、权限、安全这些问题，我就很容易说不清楚。
这时候最好的方式，不是硬着头皮假装自己懂，而是反过来让 AI 向你提问。
更准确地说，是让 AI 把那些我不懂的技术问题，翻译成我能回答的产品问题和生活问题。
你可以这样说：
「我想做一个孩子习惯养成 App。我不懂代码，也不知道应该怎么把产品想法转成技术需求。请你先不要写代码，也不要急着给方案。请你像一个既懂产品、也懂技术的人一样，先问我 10 个问题。
这些问题不要用技术术语来问我，而要用我能理解的语言，帮助你判断：这个产品需要哪些页面，哪些信息要保存，家长和孩子是不是不同角色，是否需要登录，数据要不要同步，是否需要提醒，哪些内容涉及隐私，第一版可以先不做什么。
等我回答之后，你再帮我整理成一份适合交给 AI 编程工具使用的需求说明。」
这个方法非常有用。
因为 AI 会把你原来不知道怎么表达的问题，拆成一组你可以回答的问题。
它可能会问：孩子和家长是用同一台设备，还是各自用自己的设备？孩子完成任务之后，记录只需要保存在这台手机上，还是换一台手机也要能看到？父母能不能修改孩子的任务和记录？App 要不要每天提醒？如果没有网络，这个 App 还需要能用吗？
这些问题表面上不是技术问题，但它们背后都会影响技术实现。
好的 AI 使用者，不是永远给 AI 下命令的人，而是懂得让 AI 帮自己澄清问题的人。
05 摆烂：我什么都不懂，请你给我最直白的解释
当我们做一些复杂的事情时，一定会遇到一些超出自己知识范围和理解范围的东西。
这个时候你可以选择“摆烂”。
不是态度上的摆烂，而是放弃伪装。
你可以直接跟 AI 说：
「关于这个领域，我什么都不懂。请你用最直白的方式解释，不要用专业术语。如果必须使用专业术语，请先用一句人话解释它是什么意思，并且给我一个生活中的例子。」
比如我在 AI 编程的时候，经常会遇到一些报错。报错信息里有一堆英文和技术名词，我看不懂。
我不会假装自己懂。我会直接把报错贴给 AI，然后说：
「我完全不懂这段报错。请你先不要修复，先用非程序员能听懂的方式告诉我：它大概在说什么？可能是什么原因？这件事严重吗？如果要修，我应该让你提供哪些信息？」
这样一问，AI 的工作就从“替我写代码”变成了“先帮我理解问题”。
理解问题很重要。
因为如果你完全不知道 AI 在做什么，你就只能盲目信任它。它说修好了，你就信；它说没问题，你也信。这样其实很危险。
我不懂代码，但我至少要努力懂一点点问题的结构。
这不是为了变成程序员，而是为了能够判断 AI 有没有在胡来。
06 从用户目标出发，而不是从解决方案出发
有人觉得 AI 编程很难，因为编程涉及代码、逻辑规则、各种验证和测试，是一个很复杂的流程。在 AI 出现之前，这确实有着非常高的技术门槛；但在 AI 时代，这一切正在发生变化。
在 AI 时代，你要做的不是先描述技术方案，而是尽可能准确地描述你的意图和目标。
比如说，如果我要做一个孩子习惯养成 App。
我可能会这样向 AI 描述：
我的孩子现在 9 岁，目前有一些坏习惯。尽管我们经过了很多次提醒和要求，他还是没法改正，反倒引起了亲子关系的恶化，让孩子变得很叛逆。
我希望有一个 App，能够实现以下目标：
- 让孩子在每一天的生活中养成好习惯。
- 增进父母和孩子的互动，改善亲子关系。
- 当我们和孩子通过这个 App 回头看时，能够发现孩子成长的改变，让他对自己的成长产生回馈感和成就感。
这只是一个需求比较宽泛的例子。
但它能说明一个问题：你不要一上来就告诉 AI“首页上面放一个大按钮，下面放一个列表，再做一个弹窗”。这句话不是完全没用，但它太早进入了解决方案。
更好的说法是：
「我想做一个给 9 岁孩子使用的习惯养成 App。首页最重要的目标，是让孩子一打开就知道今天要做什么，并且完成之后立刻获得正反馈。请你先不要急着设计界面，先从儿童使用场景出发，帮我分析首页应该承担哪些任务，再给出 2 到 3 种可能的方案。」
前一种说法，是你直接告诉 AI 你脑子里的界面。
后一种说法，是你告诉 AI 你要解决的问题，让 AI 和你一起找方案。
在我自己的工作里，我越来越倾向于先讲目标，再讲限制，最后才讲我脑子里已有的想法。
因为我脑子里的想法可能是错的。
真正的产品，从来不是功能的堆叠，而是某一个真实问题的解决。
所以我的建议是：先描述你要抵达哪里，再讨论怎么走过去。
07 把抱怨和判断，翻译成具体问题
AI 做错事情的时候，人很容易生气、暴怒。
这很正常。尤其是你已经来回改了很多轮，它还是在同一个地方犯错，你会忍不住说：
「你怎么又错了？」
「你到底有没有看懂我的需求？」
「这个页面太丑了，重新做。」
这些话可以表达情绪，但对 AI 改进结果帮助不大。
更有效的方式，是把抱怨和判断翻译成具体问题。
不要说：
「这个页面太丑了。」
而要说：
「这个页面现在有三个问题：第一，按钮和背景颜色太接近，孩子不容易注意到；第二，完成任务之后的反馈太弱，没有成就感；第三，父母视角和孩子视角混在一起，用户不知道自己该做什么。请你优先解决这三个问题，并保持整体界面简洁。」
写文章也是一样。
不要说：
「这段写得不好，帮我改。」
而要说：
「这段我读起来有点别扭。具体表现是：第一，前两句话都在说同一个意思，有重复；第二，第三句话突然跳到另一个观点，中间缺少过渡；第三，读者看完不知道我到底想强调什么。请你先根据这些症状判断问题在哪里，再给我一个最小修改方案。」
如果你只表达不满，AI 可能知道你不满意，但不知道怎么改。
如果你能指出具体问题、影响、优先级和期望结果，它就更容易调整。
08 把任务、背景和尝试过程说清楚
我以前也会觉得，跟 AI 说太多会不会很麻烦？
后来我发现，很多时候不是说得太多，而是说了太多不重要的东西，却漏掉了真正重要的东西。
比如你说：
「帮我优化一下这篇文章。」
AI 可以优化，但它不知道你说的优化是什么意思。是改错别字？是让文章更有感染力？是让结构更清楚？是适合公众号？还是适合小红书？
更好的说法是：
「请你帮我优化这篇文章。我的目标读者是对 AI 有兴趣、但不是技术背景的人。请保留我的第一人称语气，不要改成正式教程。重点检查三件事：逻辑是否顺、例子是否够具体、读者看完能不能照着做。请先给出诊断，不要直接改原文。」
这就清楚很多。
AI 很聪明，但它不知道你脑子里发生过什么。
它不知道你为什么做这个产品，不知道你之前试过什么，不知道你喜欢什么、不喜欢什么，也不知道你的用户到底是谁。
所以我通常会给 AI 几类信息：
第一，我是谁。
第二，我要服务的人是谁。
第三，这件事发生在什么场景里。
第四，我已经试过什么。
第五，我最在意什么。
第六，哪些东西不要做。
这些信息给出去之后，AI 的回答会明显不一样。
比如我不只会说：
「这篇文章还不够好。」
我会说：
「我已经尝试补了几个方法点，但后半部分还是像提纲，不像文章。我希望你帮我把每个方法展开成具体例子，同时保留我的口语感，不要写成知识付费课程。」
当你把任务、背景和尝试过程说清楚，AI 就能理解你现在卡在哪里。
AI 的能力，很多时候不是被模型限制住的，而是被上下文限制住的。
09 相比交付结果，更要纠正 AI 的工作方法
这是我最近越来越深的一个体会。
很多时候，AI 的问题不只是某一个结果错了，而是它的工作方法错了。
比如它没有先理解上下文，就开始改。
比如它为了让结果看起来完成了，偷偷绕过真正的问题。
比如它每次都只修表面现象，没有找根本原因。
比如你让它保持你的文风，它却把文章改成了很漂亮、但完全不像你的样子。
这个时候，不要急着让它继续改结果。
你要先纠正它的方法。
可以这样说：
「先停一下。你刚才的问题不是某一句话写得不好，而是你把我的文章改成了通用教程。请你先复盘：你在哪些地方改变了我的语气？哪些地方新增了我没有表达过的判断？接下来请你只做最小必要修改，保留我的第一人称、犹豫、口语和节奏。」
或者在 AI 编程里，可以这样说：
「先不要继续写代码。请你先分析这次失败的根本原因。不要用临时方案绕过去。请找出问题发生的链路，说明你要验证哪些假设，然后再提出修复方案。」
这件事很像管理一个新人。
如果新人做错了，你当然可以说“这个地方改一下”。但如果他总是用错方法，你更应该纠正的是他的工作方式。
AI 也一样。
真正高级的 AI 使用，不是不断催它交付，而是不断校准它的工作方式。
10 让 AI 给自己设定验证标准
我现在越来越不相信一句话：
「我已经修好了。」
不是因为 AI 故意骗我，而是因为它经常会把“看起来完成”当成“真的完成”。
所以我会要求 AI 给自己设定验证标准。
比如做产品时，我会这样说：
「在你开始实现之前，请先列出这次任务的验收标准。哪些可以通过自动检查验证，比如 lint、测试、构建；哪些必须由人来判断，比如视觉效果、文案是否自然、用户是否容易理解。完成之后，请逐条告诉我每一项是通过、失败，还是需要人工 review。」
写文章时也一样。
「请先给这篇文章设定完成标准：提纲占位是否清空，逻辑是否连贯，每个方法是否有例子，是否保留我的语气，是否没有新增我没说过的观点。修改后请按这些标准自查。」
这一步非常关键。
因为一旦有了标准，你就不是在凭感觉判断 AI 做得好不好。
尤其是 AI 编程，验证标准更重要。
如果它改了代码，你要让它运行测试、检查报错、打开页面截图、比较修改前后的差异。不能只让它告诉你“应该可以”。
“应该可以”不是证据。
证据应该是：它跑了什么检查，结果是什么，哪里还需要人来看。
这也是我作为一个不懂代码的人，保护自己的方式。
我看不懂代码，但我可以要求 AI 给我可验证的结果。
11 让 AI 找业界最佳实践和依据
我现在做不熟悉的事情时，经常会让 AI 先去找行业里的成熟做法。
因为 AI 很容易凭空给你一个看起来合理的方案。
看起来合理，不代表真的可靠。
所以我会这样要求它：
「这件事我不熟。请你先调研官方文档、行业最佳实践和优秀开源项目，不要只凭记忆回答。请列出来源，总结它们的共同点和分歧，然后再结合我的情况给出建议。」
如果是 AI 编程，我会说：
「请先在这个项目里搜索有没有类似实现。优先复用现有代码模式，不要自己发明一套新的写法。如果没有，再找官方文档或成熟开源项目作为参考。」
如果是产品设计，我会说：
「请先分析这个领域里常见的用户流程和交互模式。不要急着画界面。先告诉我：哪些模式是成熟的，哪些地方容易出错，哪些地方需要结合我的用户场景重新设计。」
这个方法对非技术人尤其重要。
因为我们不知道某个方案在行业里是不是常规做法，也不知道它后面有没有坑。
AI 可以帮我们补这一层视野。
但前提是，你要明确要求它找来源、讲依据、做比较，而不是直接给一个自信的答案。
不要只让 AI 给答案，要让它给依据。
12 给 AI 定边界和约束
AI 很擅长生成，但它不一定天然知道你的边界在哪里。
所以你要给它标准，也要给它约束。
比如写文章时，我会说：
「请保留我的原意，不要新增观点，不要把口语改成公文，不要为了显得高级而使用抽象词。每个方法点都要有例子，但不要编造我的真实经历。」
做产品时，我会说：
「这个 App 是给孩子和父母一起使用的。不要使用羞辱、惩罚、排名、连续打卡失败提醒这类容易制造压力的机制。整体方向应该是鼓励、陪伴和可见的成长。」
让 AI 编程时，我会说：
「不要改无关文件。不要引入新的技术栈。不要为了让测试通过而删除测试。不要隐藏错误。完成后必须告诉我改了什么、为什么改、可能影响什么。」
这些话看起来有点啰嗦，但非常有用。
因为 AI 有时候太积极了。
它会为了完成任务，顺手做很多你没让它做的事情。它会把一个小问题改成一个大改版。它会为了让结果看起来完整，补一些你并不认可的判断。
所以你要告诉它边界。
边界不是限制创造力。 边界是让创造力不要跑偏。
13 给 AI 建立规则和流程
当你只是偶尔问 AI 一个问题时，一次 Prompt 就够了。
但如果你长期和 AI 协作，只靠一次次临时输入是不够的。
你需要给 AI 建立流程。
比如我现在会要求 AI 做文章时遵循一个流程：
先诊断，不要直接改。
先说明它认为文章的问题在哪里。
然后给出修改计划。
等我确认方向之后，再改正文。
改完之后，还要告诉我改了什么、为什么改、哪里可能还需要我看。
做产品和编程也是一样。
我会给 AI 设定类似这样的流程：
先读上下文。 再列验收标准。 再提出计划。 然后执行。 执行后跑检查。 最后用普通人能看懂的话告诉我结果。
这就是为什么我后来会越来越重视 Rules、Skills、AGENTS.md 这类东西。
它们本质上不是技术文件，而是我写给 AI 的工作规则。
我不可能每一次都重新解释：我是一个不读代码的人，请你用中文告诉我改了什么；不要直接动重要文件；不要跳过验证；不要把文章改成不像我。
这些东西如果每次都靠我临时说，我一定会漏。
所以我把它们变成规则。
规则的意义，就是让 AI 在每一次开始工作之前，就知道我的工作方式、我的边界、我的偏好和我的底线。
说到底，这和管理一个团队也很像。
你不能指望一个人每次都靠临场发挥。你要给他流程，给他标准，给他反馈，也给他复盘。
AI 也是一样。
14 最后
如果只把 AI 当成搜索引擎，它已经很好用了。
但如果你想更进一步，把 AI 变成真正的协作者，你就不能只问：
「答案是什么？」
你要开始问：
「我到底想解决什么问题？」
「我给的信息够不够？」
「AI 有没有理解我的目标？」
「这个结果怎么验证？」
「如果它错了，是结果错了，还是工作方法错了？」
这就是我理解的 AI 驾驭术。
它不是学会一堆神奇 Prompt。
它是学会把自己的意图说清楚，把问题拆明白，把背景补足，把标准立起来，然后在一次次协作中校准 AI。
我不懂代码，但我懂用户，懂体验，也懂一个想法从模糊到清晰的过程。
而 AI 正好给了我一个机会，让这些原本只能停留在脑子里的想法，开始一点一点落到现实里。
所以我越来越觉得，AI 时代最重要的能力，可能不是你会不会写代码，也不是你会不会背 Prompt 模板。
而是，你能不能向 AI 问出恰当的问题。