今天和一位大厂产品经理聊 AI Coding。
他不是来问“哪个工具最好用”。他的困惑更真实：AI 已经能写很多代码了，为什么一到复杂项目，还是会卡住？为什么有些人越用越快，有些人只是多了一个会生成代码的聊天窗口？
聊到最后，他说自己要回去消化一下，找两个复杂项目先试。
我觉得这句话，比很多工具教程都重要。
AI Coding 的门槛，从来不是让 AI 写几段代码。真正的门槛，是你能不能把一个模糊想法，变成 AI 能持续推进、能被人验收、能在项目里沉淀的工作范围。
Summary
AI Coding 不是补全代码，而是把意图翻译成工程上下文。
工具在清晰任务上提速明显，但复杂项目会考验范围、测试、协作和判断。
产品经理学 AI Coding，不是转行写代码，而是掌握“可执行表达”。
最快的学习方式，是做复杂项目，然后把别人教会。
一、真正的困惑：AI 会写代码了，项目为什么还是慢
很多 AI Coding 的低效，不是模型不够强，而是人给它的项目边界太松。
一个小页面，AI 很容易做出来。
一个后台表单，AI 也能很快拼好。
但真实项目不是这样运行的。真实项目里，有登录态，有权限，有数据流，有异常状态，有老代码，有接口约束，还有一堆没有写在需求里的默认规则。
这些东西，平时靠人沟通。
你开会解释一遍，对方理解一半。你写文档补一遍，开发又根据经验改一半。最后到了验收环节，大家才发现：页面是有了，但业务跑不通。
AI Coding 不是把沟通消灭掉。
它只是把沟通提前了。提前到你给 AI 下任务的那一刻。
你说“帮我做一个项目管理系统”，AI 只能猜。
你说“这个系统面向咨询项目负责人，先做项目列表、任务拆解、交付物上传、风险提醒，权限只分负责人和成员，验收标准是能完成从新建项目到生成周报的闭环”，AI 才开始进入项目。
二、第一层能力：把需求写成机器能接住的范围
会用 AI Coding 的人，第一步不是提问，而是定范围。
范围不是一句“我要做什么”。
范围至少包含五件事：谁使用、在哪个场景使用、要完成什么动作、不能越过什么边界、怎么判断做完。
这其实是产品经理最熟悉的能力。
只是过去这些能力服务于人。现在还要服务于 AI。
比如你要做一个内部小平台，不要先让 AI “写前端”。先让它理解项目范围：
1 目标对象是谁：运营、项目经理、销售，还是管理层。
2 最短闭环是什么：新建、编辑、流转、查看，还是导出。
3 第一版不做什么：不做复杂权限，不做消息推送，不做移动端深度适配。
4 验收靠什么：页面能打开，数据能保存，关键路径能跑通，异常能提示。
这一步做好，AI 才像一个工程搭档。
否则它只是一个很勤快的代码生成器。
三、第二层能力：别让 AI 一口气干完
复杂项目最危险的状态，是 AI 看起来完成了，其实没有被真正验收。
很多人用 AI Coding，会有一个冲动：把需求一次性丢进去，然后等它生成一个完整项目。
这在演示里很爽。
在真实项目里很容易翻车。
因为项目越复杂，隐藏假设越多。AI 生成得越快，你越难知道它到底在哪些地方做了判断。
正确的方式，是把 AI 当成可以连续交付的小团队，而不是一次性交付的魔法按钮。
先让它读项目结构。
再让它输出实现计划。
然后分模块执行。
每做完一步，都让它自己跑检查，再让人做关键验收。
这个动作看上去慢一点。
但它能避免最贵的返工：你以为项目做完了，最后发现数据模型、权限边界、核心流程全都要重来。
四、产品经理最该练的，不是代码，而是可执行表达
AI Coding 会放大产品经理的表达质量。
你表达得粗，AI 就会替你猜。
你表达得细，AI 就会替你推进。
这不是要求产品经理都变成工程师。
恰好相反，AI Coding 让产品经理终于可以更接近“Builder”的位置。你不一定亲手写每一行代码，但你必须能把业务判断写成可执行的工程语言。
什么叫可执行表达？
不是“这里体验要好一点”。
而是“用户第一次进入时，如果没有项目数据，展示空状态；空状态有一个新建按钮；新建成功后回到列表第一行；如果保存失败，保留表单内容并提示重试”。
不是“权限要简单”。
而是“项目负责人可以编辑全部字段，成员只能更新自己负责的任务状态，访客只能查看交付物名称，不能下载附件”。
当你能这样说话，AI 就不再只是写代码。
它会开始帮你把产品判断落成系统行为。
五、为什么要做两个复杂项目，而不是看十个教程
AI Coding 的认知，只能在复杂度里长出来。
简单项目会给人一种错觉：我会了。
你做一个 Todo List，AI 很快完成。你做一个登录页，AI 也很快完成。
但这些项目不会暴露真正的问题。
真正的问题会在第二天出现：字段要改，数据要迁移，接口返回不稳定，页面状态互相影响，旧功能被新功能改坏，部署后环境变量不对。
所以我建议他回去做两个复杂项目。
一个选自己熟悉的业务。
一个选自己不熟悉的业务。
熟悉业务，能训练你把隐性经验写出来。你会发现，很多你以为大家都懂的规则，AI 根本不知道。你必须把它翻译成场景、字段、状态、边界。
不熟悉业务，能训练你向 AI 提问。你会被迫让 AI 先解释领域、拆解对象、列出风险，再开始实现。
这两个项目做完，你会明显感觉到一件事：你学到的不是某个工具按钮，而是一种新的项目推进方式。
六、最好的学习方式，是把别人教会
教学不是传播知识，教学是压缩自己的认知模型。
聊到最后，我给了他一个建议：下次可以试着教别人。
这不是客气话。
很多能力，自己会用的时候，其实还不稳定。你以为自己懂了，只是因为你能在熟悉场景里跑通。
但当你要教别人，你必须回答三个问题：
1 第一步到底做什么，为什么不是别的。
2 失败时怎么判断，是需求不清、上下文不足，还是代码执行错了。
3 哪些经验可以复用，哪些只是这次项目的特殊情况。
能讲清楚这些，你就不只是“会用工具”。
你开始拥有自己的 AI Coding 方法。
这一点对产品经理尤其重要。
因为产品经理原本就站在业务、设计、技术、协作之间。AI Coding 出现后，这个位置会变得更关键。你不再只是把需求递给研发，而是把需求整理成一个可以被 AI 和人共同执行的上下文。
七、明天就能开始：三张卡片，先把项目跑起来
别急着研究全部工具，先把自己的项目表达方式改掉。
如果你想真正进入 AI Coding，明天可以先写三张卡片。
第一张是项目卡。写清楚项目目标、使用对象、第一版闭环、暂不支持的范围。不要追求完整，先追求可执行。
第二张是任务卡。把项目拆成三到五个小任务，每个任务只解决一个问题。比如先做数据结构，再做列表页，再做详情页，再做权限，再做导出。每张任务卡都要有输入、输出和验收方式。
第三张是复盘卡。每次 AI 做完后，不只看结果，还要记录它为什么跑偏。是上下文缺失，还是你没有说边界？是一次给的任务太大，还是缺少测试？这些记录会变成你的下一版提示词，也会变成团队的协作规范。
这三张卡片做起来很朴素。
但它们会改变你和 AI 的关系。
你不再是站在旁边催它“快点写”。你开始像一个项目导演，给出范围，给出镜头，给出验收，允许它发挥，但不允许它失控。
这也是 AI Coding 对组织最现实的意义。
它不是让每个人都变成程序员，而是让更多业务骨干具备工程化表达能力。过去，很多想法会卡在“我不会写代码”。现在，真正的卡点变成“我能不能把想法说清楚、拆明白、验得住”。
当产品经理、运营负责人、流程负责人都开始具备这种能力，组织里的沟通会变短。不是因为大家少说话，而是因为每一次表达都更接近可执行状态。
所以，AI Coding 的终点不是代码。
它的终点，是把人的判断沉淀成可以反复调用的项目能力。
八、最后：真正会被放大的，是清醒的人
AI Coding 不会自动奖励使用者，它奖励那些能定义问题的人。
你把它当成自动写代码的工具，它就只能帮你省下一些手工活。
你把它当成项目推进的新接口，它就会逼你重新理解需求、范围、协作和验收。
这就是我今天最想写下来的判断。
AI Coding 的核心不是“AI 会不会写”。
而是你会不会把一个真实项目，拆成 AI 能执行、人能判断、团队能复用的连续动作。
这件事学不会，换再多工具也只是热闹。
这件事学会了，一个产品经理也可以更接近创造者的位置。
先做两个复杂项目。
再把别人教会。
这是最短的路。
参考资料：GitHub 关于 Copilot 对开发效率影响的研究、Google DORA 2024 报告，以及 METR 2025 年对经验丰富开源开发者的实测，都指向同一件事：AI 能提速，但提速发生在清晰任务、稳定流程和可靠验收之中。
GitHub Copilot productivity research · DORA 2024 Report · METR AI productivity study