前阵子我这非码出身的产品，靠 AI 写代码差点没把自己坑哭，本来以为输入三两句人话，就能搞定以前半天拉人开会、半天催程序员的活，这怎么不算一种魔法？结果验收自己让 AI 写的代码时，发现好几个功能需求一开始压根没思考到，要改的时候才傻了眼 ，我居然亲手让 AI 写出了传说中的 “屎山代码”，这才真正体会到程序员那些吐槽 memes 背后的泪。

后来实在没辙，我在播客《十字路口》里翻到了救星，这期节目采访了 Claude Code 榜一的刘小排，人家不仅是 AI 创业者，还有十年猎豹软件 “产品 + 程序员” 的经历。说实话，一开始我还觉得他说的 “避免屎山要先写需求文档” 太基础，产品经理天天干这事能有啥新鲜的？但跟着他的方法试了一遍才发现，这里面的门道真不是随意写写那么简单。

刘小排说的第一步，是别在聊天框里打一行零散需求，得用飞书、Notion 或者 Markdown 编辑器，写一份完整的 PRD。里面得有背景、目标、功能详述，连性能、安全这些非功能性需求，还有界面原型、流程图都不能少。你可别觉得这是麻烦，书写的时候实则是在强迫自己把每一个细节想清楚。

我自己写的时候就发现，本来以为 “用户注册” 挺简单，写着写着就想到 “邮箱没注册成功咋提示”“密码丢了咋找回” 这些漏洞，相当于自己先当了第一道过滤器。而且给 AI 的上下文越清晰，它就不用瞎猜你的需求，这份文档后来还成了我验收 AI 产出的基准，省了不少扯皮的事。

写完 PRD 也不是直接让 AI 写代码，刘小排说这步最关键，我照着他说的，把 PRD 给了 Claude，还特意加了个指令：“你当技术负责人，先出份实现方案，要包含架构、模块、接口设计、技术选型还有风险难点，我们得讨论下。”

本来想直接让 AI 写代码省时间，后来发现这么做反而更高效，AI 一下子从 “代码工人” 变成了 “架构师”，想问题的角度都宏观了。有次我做 “商品列表筛选” 功能，AI 在方案里提到 “大数据量下筛选会卡顿，得加缓存”，这正好是我 PRD 里没思考到的技术难题，提前就把屎山可能长出来的温床清掉了。

等技术方案评审通过，确认没啥遗漏了，再让 AI 编码，刘小排说 “要像管理顶尖程序员一样管 AI，别把它当许愿机”，这话我目前特别认同。他这套方法能管用，本质是把 “产品定义” 和 “技术实现” 拆成了两个阶段，跟大公司的开发流程一模一样。人家十年猎豹的经历可不是白来的，那些软件开发的经验，早就变成了他跟 AI 打交道的方法。

实验后的醒悟：AI 不是许愿机，经验才是关键

光说不练假把式，我还拿 Deepseek 做了个实验，先让它生成 “用户输邮箱密码注册” 的需求，再让它分别写 “屎山代码” 和 “非屎山代码”。对比完我才清楚，“非屎山” 好在哪。安全上，它用参数化查询防 SQL 注入，密码还做了加盐哈希；清晰到函数名列如 get_db_connection、hash_password，一看就知道是干啥的，还有文档字符串解释；而且用 try-except 抓异常，with 语句自动关连接，后续想加 “注册发欢迎邮件”，不用改核心逻辑就能加。

后来我又让 Deepseek 生成符合规范的 PRD，结果懵了 ，我根本判断不了这份 PRD 是不是过度设计，也不知道它给的评审案例靠不靠谱。无奈之下才想清楚，不是方法不管用，是我自己的问题。一方面我架构能力不够，另一方面这个 “用户注册” 需求是我随意编的伪需求，没从业务角度认真思考过，就像学生应付作业似的。

如此看来，这套方法实则要求提需求的人得有经验，能评审 AI 给的方案对不对，这也难怪有经验的老鸟配 AI 越来越厉害，新手却容易拔剑四顾心茫然，AI 压根没降低对人的要求，只是把能力重心从 “怎么实现（How）” 转到了 “做什么（What）” 和 “为什么（Why）” 上。

我还查过一个电商公司的案例，他们用刘小排的方法做 “商品秒杀” 功能，产品团队先写了含 “并发量、库存防超卖” 的 PRD，让 AI 出方案后，技术团队又补充了 “库存预扣减逻辑”，最后 AI 写的代码上线后，bug 率比以前直接写代码降了不少，后来加 “秒杀代金券” 功能，也只是新增模块，不用重构。很显然，需求清晰了，后续的麻烦就少了。

刘小排在播客后半段也没给啥代码案例，反而说 “要读文档、看功能，结合实际工作再应用”，这点我特别认同，AI 只是拉近了需求和落地的距离，真正避免屎山的，是你写的每一个 Prompt、认真思考的结果，还有不断迭代试错。我之前总想着靠 AI 一步到位，后来发现 “不是天生会的，而是用出来的”，这话才是避屎山的真正补完之道。

AI 时代避坑：别光靠工具，能力重心要转对

目前再看 AI 时代的变化，真不是以前想的 “会写代码就行”，LinkedIn 上有份报告说，目前 “AI 辅助开发工程师” 岗位，对 “需求拆解能力” 的要求比两年前高了不少。毫无疑问，AI 没让专业能力的要求变低，只是换了个方向。以前得懂 “怎么写代码”，目前更得懂 “怎么定义需求、怎么评审方案”。

我自己从一开始被屎山坑，到后来用刘小排的方法顺利落地两个小功能，最大的感受是：别害怕 AI 写代码，也别把它当万能的。作为产品或者新手，重点是把 PRD 写扎实，学会让 AI 出方案，再结合自己的经验把关。如此一来，不仅能避免技术债堆积，产品也能更稳、更快、更好用。

实则不管你是不是技术出身，只要用对方法，AI 就能帮你把事做好，关键是别图省事跳过关键步骤，毕竟好产品从来不是靠 “许愿” 来的，是靠一步一步扎实的操作磨出来的。