上周我辅导一位朋友优化他的项目。
一开始，我还试着一步一步带他调：按钮要增加一点呼吸感，触发后要从右侧弹出抽屉，抽屉里有哪些字段，哪些字段需要保存，哪些只在本次会话里生效，数据从哪个入口取，动作完成后状态怎么变。
讲着讲着，我发现节奏完全对不上。
不是他不努力，也不是 AI 不够强，而是他听不懂这些基础概念。按钮、抽屉、字段、状态、持久化、接口、触发、回写，这些词在我这里是产品最底层的表达单元，在他那里还是一团“我想要一个差不多的效果”。
最后我只能直接接手，把需求完整描述给 AI，让 AI 按照更清楚的交互逻辑和数据边界去做。项目当然推进了，但这件事留下了一个更大的问题：
如果你不能清楚定义自己要什么，AI 越强，你越容易把项目做偏。
这不是某一个人的问题。
它会成为很多人进入 AI Coding、AI 产品、Agent 开发时遇到的第一堵墙。过去你不懂技术，还可以把想法讲给产品经理、设计师、研发，别人替你翻译。现在 AI 把执行能力放到你面前，你会突然发现：真正难的不是让 AI 写，而是你有没有能力把想法讲到 AI 能执行。
我之前写过一篇《AI Coding 不是写代码》，核心观点是：AI Coding 放大的不是敲代码速度，而是范围、上下文、验收和复盘。也写过《产品经理学 AI Coding，不是去抢生产代码》，里面讲到产品经理进代码库，不是为了替代研发，而是为了看见真实上下文。
这次观察，其实是同一条线的进一步展开。
AI 时代真正稀缺的，不是会不会点开一个工具，而是能不能把自己的需求变成可执行表达。
一、会聊天，不等于会提需求
很多人以为自己在向 AI 提需求，其实只是在向 AI 倾倒愿望。
“按钮动一点”“页面高级一点”“交互顺一点”“数据能保存一下”，这些话不是不能说，但它们只能表达感受，不能驱动产品实现。AI 接收到这种输入以后，只能根据常见模式去猜。它可能猜出一个看起来还不错的页面，也可能把关键逻辑全部绕过去。
真正的需求表达，要多问一层。
按钮为什么要动？是为了吸引注意，还是提示用户当前可操作？动效什么时候开始，什么时候停止，用户点击后是否要禁用按钮？侧拉抽屉从哪里弹出，遮罩要不要关闭，点击空白处是否收起，未保存内容是否提醒？字段保存到哪里，是保存到账号配置、项目配置，还是只保存在本次运行里？
这才叫提需求。
提需求不是把愿望说得更热情，而是把愿望拆成对象、动作、状态、规则和结果。你说不清这些东西，AI 就只能替你补。AI 一旦替你补，就会把你的产品判断变成模型的平均猜测。
这也是很多人用 AI 做产品时最隐蔽的风险：表面上每一步都有产出，实际上每一步都在丢失控制权。
二、AI 能执行，但不能替你承担定义责任
AI 可以替你生成很多东西，但它不能替你判断什么才算合格。
OpenAI 的提示工程建议里，反复强调清晰指令、上下文、目标、格式和示例。ISO/IEC/IEEE 29148 这类需求工程标准，也长期把需求的完整性、一致性、可验证性当成基本要求。换句话说，今天大家突然讨论“提示词”，其实并不是一个新问题。
它只是把软件工程里早就存在的老问题，推到了每个普通使用者面前。
过去，需求不清会让研发返工。现在，需求不清会让 AI 更快地产出一堆看似完成、实则不可用的东西。你让它做一个“资料管理功能”，它可以很快生成列表、搜索、上传、删除。可你没有说清楚权限、版本、归档、审批、日志、容量、异常恢复，它就不会天然知道这些业务约束。
DORA 2025 关于 AI 辅助软件开发的研究也有一个很关键的判断：AI 更像放大器，会放大组织原有的强项和弱点。这个结论放到个人身上同样成立。一个人本来就能讲清流程、边界和验收，AI 会让他更快闭环；一个人本来就靠感觉推进项目，AI 会让他的混乱更快显形。
所以，别把 AI 当成许愿机。
它更像一个执行力极强、但需要上下文的合作者。你给它边界，它就能推进；你不给边界，它就会猜。
三、技术基础，不是为了亲自写代码
普通人学技术，第一目标不是变成工程师，而是学会用工程语言表达自己。
很多人一听“技术基础”，马上会紧张：是不是要学编程？是不是要懂数据库？是不是要会写接口？
不一定。
但你至少要理解几个底层概念。页面上看见的东西，背后通常有组件；组件会有状态；状态变化需要触发；触发以后可能读取数据，也可能写回数据；有些数据要长期保存，有些只是临时上下文；有些动作可以自动完成，有些必须人工确认；最后还要有验收标准，判断这件事到底算不算做完。
这些不是程序员的黑话。
它们是数字产品的基本语法。
一个人不理解这些语法，就很难把自己的想法讲给 AI。你可能知道自己“想要好用一点”，但你不知道好用体现在哪个动作、哪个状态、哪个反馈、哪个异常处理里。你也可能知道自己“想要更智能”，但你说不清 AI 应该读什么、判断什么、输出什么、什么时候停下来。
这就是为什么我一直说，AI 原生产品经理不是多会写代码，而是能进入真实上下文。你不一定亲手改每一行代码，但你要知道需求最终会落到页面、数据、流程和验收里。
四、只讲效果的人，会把 AI 逼成猜谜游戏
“我要一个好看的效果”不是需求，“什么条件下出现什么反馈”才是需求。
还是拿那个按钮呼吸动效举例。
如果只说“按钮要有呼吸感”，AI 可能给你一个永远闪动的按钮。看起来有动态，但用户操作几分钟就烦。更合理的描述应该是：按钮在页面加载后轻微提示一次；当用户长时间未点击时，再出现一次弱提示；点击后立即停止动效，并进入处理中状态；如果接口返回失败，恢复可点击并显示错误原因。
侧拉抽屉也是一样。
你不能只说“点击后弹出一个抽屉”。你要说抽屉承载什么任务，是否允许关闭，关闭前是否检查未保存内容，提交后是否刷新主页面，哪些字段要保存，哪些字段来自上游数据，哪些字段由 AI 生成但需要人工确认。
字段持久化更是典型。
很多非技术背景的人会觉得“保存一下”很简单。可在产品里，保存到哪里、保存多久、谁能看、什么时候覆盖、失败后怎么重试、历史记录是否保留，都是产品判断。你不说清楚，AI 不会自动知道你的业务风险。
所以，真正的 AI 产品能力，不是把一句需求写得更长，而是把它写得更可验证。
五、用一把尺子，看你现在卡在哪一层
不要先问自己会不会用 AI，先问自己能不能把需求讲到哪一层。
我建议把 AI 需求表达能力分成五层。
L0，是愿望表达。你只能说“想要一个工具”“想要更智能”“想要更好看”。这一层最常见，也最容易让 AI 自由发挥。
L1，是界面表达。你能描述页面上有什么按钮、列表、弹窗、表单，但还说不清什么时候出现、为什么出现、出现后怎么变化。
L2，是交互表达。你开始能讲触发、反馈、状态、异常、确认和撤销，AI 做出来的东西开始接近可用。
L3，是数据表达。你能讲字段来源、保存位置、读取规则、权限范围、历史记录和同步关系，项目开始接近真实产品。
L4，是闭环表达。你能把目标、流程、数据、边界、验收和复盘连起来，让 AI 在一个可控范围内持续迭代。
多数初学者并不是卡在工具，而是卡在 L0 到 L2 之间。他们会说愿望，也能指出页面哪里不好看，但说不清一个动作背后的状态、数据和规则。
这时再看教程，效果有限。
因为真正缺的不是按钮在哪里，而是你脑子里还没有一套产品表达结构。
六、补技术基础，先练这六张卡片
不要从学一门语言开始，从把一个小需求讲清楚开始。
如果你现在技术基础薄弱，但又想真正用 AI 做产品，我建议先练六张卡片。每次提需求前，都把它们写出来。
这六张卡片看起来很基础，但它们会强迫你从“我要一个效果”，进入“我要一个可执行变化”。
比如你想做一个侧拉抽屉，就不要只写“点击按钮弹出抽屉”。你要写：谁点击，什么时候点击，点击前是否需要校验，抽屉显示哪些字段，字段从哪里来，用户修改后保存到哪里，保存失败如何提示，关闭时是否保留草稿，提交后主页面哪些数据要刷新。
写到这里，你已经不是在写提示词。
你是在写产品说明、交互说明和实现边界。AI 看到这样的输入，才有机会稳定产出。研发看到这样的输入，也会更容易判断工作量和风险。
七、最后：AI 不是降低表达门槛，而是降低执行门槛
未来真正被放大的，不是会提问的人，而是能定义问题的人。
很多人对 AI 有一个误解，以为它会让所有门槛都消失。我的判断正好相反：AI 会让低层执行更便宜，但会让高质量定义更值钱。
以前你不会写代码，一个想法可能停在脑子里。现在你不会写代码，也能让 AI 帮你做出页面、脚本、自动化流程和小产品。但这并不意味着你可以绕过基本功。因为 AI 做得越快，你越需要知道它做得对不对；AI 改得越勤，你越需要知道改动有没有破坏业务；AI 生成得越完整，你越需要知道哪些地方只是看起来完整。
所以，技术基础薄弱的人不是不能上车，而是要先承认自己缺的是表达结构。你不一定要一年后才开始做，但你要用接下来每一个小项目训练自己：把愿望写成对象，把对象写成动作，把动作写成状态，把状态写成数据，把数据写成边界，把边界写成验收。
这条路不花哨，但非常硬。
当你能把一个按钮、一个抽屉、一个字段、一次保存、一条异常、一段流程讲清楚，你就会发现 AI 终于不是在替你猜，而是在替你推进。到那个时候，AI Coding 才不只是写代码，AI 产品也不只是做页面。它会变成一种新的项目推进方式：人负责定义，AI 负责执行，人再负责验收和修正。
表达清楚自身诉求，在任何时代都是门槛很高的核心能力。
AI 只是把这件事变得更诚实了。
参考依据： OpenAI Academy 关于清晰提示和上下文的说明； IEEE 29148 系统与软件工程需求标准说明； DORA 2025 State of AI-assisted Software Development。