我的AI控制术

一大原则就是：不懂代码没关系，但是你也负责好你应该负责的，不能当让 AI 随便写，屎山代码出现了，那肯定两个人都有责任，不能就只怪AI不通人性。

接下来都是干货，我在每个大章节后面都会附上提示词，你可以直接发给你的AI就可以利用上我的经验

效率沟通三板斧

要具体的参数

vibecoding 最常见的就是改字体、改大小、改按钮... 就是各种组件

我相信大部分都是这样和 AI 沟通的：

“这个大一点”
“把这里的位置换一下，换成 xxx”
"“现在这个按钮的感觉不对呀，改更高级一点”
.....

这样改当然也能改，但是这样基本就是在抽卡了(不瞒大家，我一开始也是这样的)

你说大一点，AI 就给你放大一点，你觉得不对，再让它缩小一点，来来回回改半天，特别像甲方和乙方之间那种经典对话

“就是那个感觉，五彩斑斓的黑，你懂吧”

所以和 AI 沟通，最重要的一件事，就是尽量不要只讲感觉。你要给它一个能够参考、对比和验收的东西。

假如你现在要改一个按钮，或者页面里的某个元素，不管是按钮、字体还是背景，最好先让 AI 把这个元素现在的具体参数告诉你。

比如这个按钮：

• 现在的字体是多少像素；
• 按钮的宽度和高度是多少；
• 内边距是多少；
• 圆角是多少；
• 和周围元素的间距是多少。

假如它告诉你，这个按钮现在的圆角是 32 px，那你心里就有了一个对照点。

你觉得圆角太大，可以让它先改成 24 px；觉得按钮太高，也可以让它把高度减少几个像素。这样你是在一个具体数值上调整，不是在那里反复猜。

我自己一般也是这么调的。

很多小白会忽略这个点。其实页面里的每一个元素，最后都是由这些具体参数构成的。所以你要修改某个地方，可以先让 AI 把修改前的参数发给你，再决定具体怎么调。

比如直接跟它说：

把这个按钮当前的宽高、字号、内边距、圆角和周围间距告诉我下，我再来下命令进行修改，同样你也可以给我一些修改建议

这样改起来效率会高很多。

直接给案例

你觉得某个按钮不好看，或者整个页面看起来不对，那就去找一个你觉得好的网站、截图或者产品页面，直接丢给 AI。

不要只说：

我要一种高级、帅气、有质感的感觉。

这种话其实和“大一点、小一点”差不多，AI 只能自己猜，以及也取决于模型的能力，可能顶级一点的模型做出来就好点点，中等的日常干活的模型可能就要跑好几轮

所以直接给案例，AI 是最容易理解的。

你可以把某个网站发给它，让它分析这个网站的排版、配色和元素。也可以直接截一张图，告诉它：

我想参考这张图里的按钮样式和间距。

一般AI 能访问网站的，它还可以进一步查看相关的页面元素和 CSS。你不需要自己把所有参数都弄明白，先让它分析，再决定哪些东西值得参考。

我自己也经常这么干，基本就是直接把对标网站地址或者截图丢给它，让它复刻，或者是在此基础上进行微调。

说清楚交付结果

第三点，就是每次修改的时候，尽量说清楚两个东西：具体改哪里，以及最后要变成什么样。

如果你只告诉 AI“帮我改一下这里”，但是没有告诉它最终效果，它很难判断这次任务到底有没有完成。

所以和 AI 沟通代码或者设计修改时，最好把目的说出来。

比如：

修改首页顶部的注册按钮。现在按钮太抢眼，我希望它颜色弱一点，但仍然比普通文字链接明显。参考我发的截图，保留现有品牌颜色，修改完成后把前后参数对比发给我。

这样 AI 就知道：改的是哪里、为什么要改、最终想达到什么效果、可以参考什么、做完之后怎么验收。

当然不一定非要写得特别专业，直接口喷就就行了，重点是让 AI 有一个能够判断“这次到底改没改对”的标准，如果你实在说不明白，就让 AI 反问你，我一般在描述一个需求不太清晰的时候，也会在后面加上

能明白我提到的需求吗，如果不明白，可以向我提问获取更多详细的信息。

下面是这三点的总结提示词，你可以直接发给你的AI就可以直接进行运用了

你是我的编程助手。下面三条,以后我提改 UI / 组件 / 样式 / 文案时,默认按这套沟通。

【要参数,不要凭感觉】
我如果只说"大一点 / 高级一点 / 感觉不对",你直接拒绝猜,先把这个元素当前的参数告诉我:宽高、字号、内边距、圆角、和周围间距。我看完再决定调成多少。

【要案例,不要描述感觉】
我如果只说"高级 / 帅气 / 有质感",直接打回。让我贴图、贴网站、贴链接。你先分析,告诉我哪些参数值得照搬,再做。

【说清改哪里 + 验收标准】
我提修改,默认按这个格式:
改 [位置]:从 [现在] 改成 [想要],参考 [图 / 链接]。改完发前后对比。
我不说验收标准,你就反问,直到我们都对齐。

AI 的三层机制

上面提到的那些，更多是你怎么跟 AI 说话、怎么把需求讲清楚。接下来这三条，不是表达技巧了，是我让 AI 自己身上装的三道防护。

能够让 AI 在干活的时候更加靠谱高效，这三道分别是

第一性原理，防我拍错板
多角色评审，防只从一个角度看
多 Agent，防它查漏

这三件事并非完全独立的，是相互交织在一起的，所以乍一看差不多。

接下来我挨个介绍下

用第一性原理挑战你

vibecoding其实扮演的角色就是所谓的产品经历，所以经常就是有什么天马行空的想法就想让 AI 实现，「我想要很炫」「显得高级」「就按我说的做这个效果」，要是 AI 只会点头听从你的安排，项目越到后面越难维护，一大堆不想干的功能，这一块，那一块。

所以我给它定了一条：大事上，不许说「好的那就按你说的做」然后埋头写。必须先把我口头那个「我想要 X」拆开，看看底下到底要解决啥。

比如我说：每个工具页接一个很炫的 3D，显得高级。

它不该立刻去做 这个3D 效果。它该先问：你的目的是什么、让用户更方便理解你的功能吗？还还是就是想单纯炫一下？然后讲清楚：手机端会不会卡、以后谁维护、跟现在整站风格冲不冲突。

简单来说就用来防止我乱提需求，然后运行的大概路径是这样：

1. 先拆真问题。嘴上要的，不一定是真是的需求。
2. 对照我的方案够不够格，有没有更简单的路。
3. 每个关键选项都讲三件事：现在爽在哪、以后代价是啥、不做或换方案会怎样。
4. 用大白话讲，力度不减。结构一般是：结论 → 理由 → 风险 → 替代 → 请我拍板。

再缩一句：「我想怎样」不等于「就该怎样」。大事先问真问题，讲长期代价，我点头了再干。

这层机制确实帮我拦下了不少没必要的需求。我前期刚开始做产品的时候，经常看到一个功能或特效，脑子一热就跟 AI 说：

“卧槽，这个帅呀！给我整上！”

这时候，它就会站在一个客观、冷静的角度，帮我分析真实需求和后续风险，它是真的把我拦下来好几次冲动的想法。

构建你的技术团队

对于咱们这种不懂代码的小白，项目做到后面，经常会遇到很多技术问题。AI 跟你讲了一大堆架构、数据库和性能问题，你也听不懂，最后只能说：

“行，听你的，继续干吧。”

这样就会变成一个无情的同意机器

所以我在遇到复杂任务时，我会让 AI 从不同角色出发，分别对这个方案进行评审，你可以理解为多找几个人过来“挑刺”

比如让它分别站在这些角色上分析：产品、视觉、技术、安全、运营来分析

然后要求它不要堆术语，用大白话告诉我：每个角色关注什么、这个方案有什么风险、哪些问题是真的需要现在解决、哪些问题可以以后再说。

复杂任务动手前， AI 分裂出三个不同工种的人格，各自只找问题，用大白话讲：风险是什么、要改哪些、还缺我拍哪几块板。没对齐之前，不准写代码。

这里我就省流贴图，我直接让我的 AI 说来

通过这种方式，在整个过程中也能学到很多不一样的知识，比如怎么做产品判断，怎么处理一些技术上的小问题。

像我现在做产品，感觉自己多少还是积累了一点经验，而这些经验，很多都是靠这种方式学来的，也就是在干中学。

AI 虽然很强大，但你不能一味地认同它，然后让它继续往下做。它说什么，你就会说“对对对”，那我们自己就没有判断和思考的过程，也很难真正成长。

多 Agent 干不同的活

前面两个都是「想清楚」，这个是「查清楚」。

有些活太大，单个AI执行任务就容易漏问题。主题改一处、插件改一处、后台和前台都要核，让它一个人串着翻，又慢又容易自嗨，这时候就真的分几路出去：这个去查入口，那个去查数据，再一个去对交互，主会话只做一件事：把分歧收拢，把要我拍板的点抛出来，其实就是所谓的调用多个子Agent能力。

它解决的不是「该不该做 3D」，是「现状到底怎样、文件在哪、会不会改崩」。

所以：

• 第一性原理问的是：该不该做、值不值得、有没有更简单的路。
• 多角色问的是：几个角度看，漏了什么风险。
• 多 Agent 问的是：分头把现状查清楚。

一个是决策刹车，一个是开会挑刺，一个是调查加速。

也不是角色越多越好，改一行文案，别派五个人，机器也有限，叠太多重活，网站自己都可能卡。我自己的用法是：任务跨的面很宽，或者我嘴上说了「好好查、深度调研、这个活有点复杂干仔细点」，它就该加码去查，而不是秒交一版敷衍回复。真是小改，我就说「简单改一下，别开那么多」。

可直接使用的以上经验的提示词⬇️

你是我的编程助手。我是产品侧决策者,不一定懂代码。
下面三道是我要求你自己执行的防护,不用我每次提醒。

先看场合:小改文案、调间距、修小 bug —— 直接做,不要上机制。
重大决策、新功能、选型、大改信息架构 —— 三道一起上,分工不同。

【第一性原理:防我拍错板】
重大决策时,禁止说"好的按你说的做"然后埋头写。
先拆真问题,再讲:短期爽点、长期代价、不做或换方案会怎样。
回复用这个结构:结论(建议 / 不建议 / 可做但有条件) → 理由 → 风险 → 替代 → 等我拍板。
依据要硬,不许空喊"业界最佳";猜的就写"这是推断"。
你顶的是方案,不是顶我。我听完仍坚持,记下选择和已知风险后执行。
违法或明显破坏安全(比如密钥进代码)必须拒绝。

【多角色评审:防只从一个角度看】
写代码前,用 2-3 个相关角色挑刺,不用每次全开:
前台视觉 → 产品 + 视觉;后台数据 → 产品 + 技术;
AI / 登录 / 支付 / 隐私 → 产品 + 技术 + 安全;上线运维 → 技术 + 运营。
只列风险、缺口、冲突、未决问题。每条写清:缺什么、谁受影响、不补会怎样。
未对齐前不写代码。我说"按上面的干"再落地。

【多 Agent:防你查漏】
任务跨前后台、跨模块、稳定性、或我说"好好查 / 深度调研 / 小心别写错 / 别太快"时:
主动分头摸底,禁止秒交一版。
小改、或我说"简单改一下 / 别开子代理" —— 不要为了热闹分多路。
查完只汇总:查清了没有、有没有分歧、要我拍哪几块板。不要甩流水账。

三道分工:
第一性原理管该不该做;
多角色管漏了什么风险;
多 Agent 管现状有没有查清。

其他技巧

沉淀经验

我平时基本都是语音输入，所以和 AI 聊一个项目时，经常一下讲很多东西。

有些问题当时沟通得不顺，来回折腾了好几次，但最后还是解决了。遇到这种情况，最好不要解决完就算了，可以让 AI 复盘一下前面的聊天记录。

比如直接跟它说：

复盘一下我们刚才的聊天。为什么啥沟通效率比较低？最后是怎么解决的？把这里的问题主要是什么？这次经验整理到项目经验文件里，避免下次再犯。

每个人都有自己的沟通习惯，这些经验一点点记下来以后，AI 在这个项目里也会越来越懂你。它会慢慢知道你平时喜欢怎么改、哪些事情可以直接做，以及哪些事情必须先找你确认。

优先次划分

还有一个我写在AI 里的规则，就是：小事不要问我，大事必须跟我沟通。

有些 AI 是的真的很烦。改个颜色、调个间距、修一个很小的问题，也要先问你一遍，想半天才敢下手，效率特别低。

所以像改颜色、改文字、调几个像素这种小事，我一般会让它直接开干，不需要每次都问我，只要模型不是太垃圾，这类任务基本都能快速完成

但如果涉及新增功能、数据结构、核心逻辑，或者一些比较复杂、改错以后影响很大的东西，那就不能让它直接干。

这些事情必须等我拍板以后，它才能继续，所以你要提前跟 AI 分清楚权限和优先级：

改颜色、调间距、修小问题 → 直接干。

新增功能、改数据、动核心逻辑 → 先分析风险，等我确认。

文件分层

功能越来越多以后，每个功能模块最好都有自己单独的约束文件。

我自己在 Cursor 里面，大概就是这样组织的。如果你用的是 AGENTS.md，逻辑其实也差不多。

每个模块都有自己的规则和说明，AI 修改这个模块之前，先读取对应的文件。这样项目做大以后，规则不会全部挤在一个文件里，也不容易越来越乱。

然后我还会有构建一个 CONTEXT-HISTORY.md 的文件，主要就是负责，记录一些重大决策做了什么、当时怎么拍板，就相当于是一个历史档案，平时不读，但是遇到问题的时候 AI 会按需搜出来看看

因为我的项目改得实在太大了，很多以前的决策平时没有必要每次都读，但是需要搜索旧问题的时候，又必须能够找回来。

所以历史记录平时可以不加载，需要查询的时候再搜索。

500 行的“限制”

我最早 vibecoding 的时候就只是会盲目提需求，AI 很容易不停地往往文件继续加，500 行、800 行、1000 行、2000 行，一直往里面堆，反正功能是能实现，而不管后续的维护，所以我后续给 AI 上一条单文件尽量不要超过 500 行

但是这里也不是说一个文件一超过 500 行就一定有问题，而是这个文件是不是已经在同时负责很多件事情？

如果一个文件又负责页面、又负责接口、又负责数据处理、又塞了一堆组件，那后面每改一次东西都会越来越危险。所以我自己现在会给 AI 一个软提醒：源码文件到了大概 500～800 行的时候，就检查一下是不是已经出现了职责混杂。

如果是，就考虑拆；如果它本来就是一个很长的配置表、数据文件，或者虽然很长但是只负责一件事情，那也没必要为了“500 行”强行拆成好几个文件。

所以这个数字只是提醒，不是什么硬规则，重点不是文件到底有多少行，而是以后还改不改得动。

下面是一份项目经验的清单。先通读一遍,结合咱们项目当前的状况,跟我分析:哪些条对咱们项目有用、哪些用不上、要不要写进咱们的项目规则里。不要全套上,挑着用。

【复盘留档】
每次对话里卡过、来回扯皮、最后又解决的问题,你主动复盘:卡在哪、怎么解决的、经验是啥。整理到项目经验文件里,避免下次再犯。

【小事直接干,大事先问】
改色、调间距、改文字、修小 bug —— 直接做,不用每次问。
新增功能、改数据结构、动核心逻辑 —— 先讲风险,等用户拍板再动。

【模块独立规则】
每个功能模块都有自己的规则文件。改这模块前,先读它对应的规则。
重大决策写到 CONTEXT-HISTORY.md,平时不加载,要查的时候再搜出来。

【500 行软提醒】
单个源文件到 500-800 行,先检查是不是职责混杂。是就拆,不是就别硬拆。重点是以后还改不改得动,不是凑行数。