我用大模型砌“屎山雕花”：5天肝出几万行代码！产品经理的AI编程翻车记

五天，两万多行代码，重构三次。

我，一个基本不懂技术的产品经理，竟然用大模型"雕刻"出了一套看似能跑的房子。说实话，当我看着屏幕上密密麻麻的代码时，心情挺复杂的。

从 MCP 开始的“万能车床”

我先来讲讲最初接触 MCP 技术的经历。

为了解决工具接入能力不足的问题，Anthropic 公司推出了类似 MCP（Model Context Protocol）的协议，定义了应用程序和 AI 模型之间交换上下文信息的方式。这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型。可以把 MCP 想象成大模型的 USB 接口。

MCP 功能出现后，春节无聊的我抱着试试看的心态搭建了两个应用——百度搜索、股票搜索与分析。将股票封装了一套 web 服务并通过 mcp 调用。

Sample1 ：百度搜索服务接口定义示例 { "name": "baidu_search", "description": "使用百度搜索 API 获取网络信息", "functions": [ { "name": "search", "description": "根据关键词执行百度搜索", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" }, "limit": { "type": "number", "description": "返回结果数量上限" } }, "required": ["query"] } } ] } `

Sample 2 股票分析：当分析师提出"帮我分析最近三个月电动汽车行业的销售趋势"这样的请求时，MCP 协议使 AI 能够自动发现并调用这些服务。

提示词：

调用百度搜索完成一个 2024 年 Q4 的国内手机出货调研分析报告，并做一个可视化分析专题，将结果用 html 保存到本地文件 download/mcp 目录下面，命名为手机出货量分析。

过程中，自己也没想到没想到，这一试就停不下来了。那种感觉，就像是突然获得了超能力。以前需要"确定产品逻辑 -> 设计 -> 研发"的漫长流程，现在变成了：

• 把想法告诉 AI

• AI 直接产出高保真的交互原型

• 甚至是功能完备的产品 demo

原本需要几周等待的工作，几个小时就能搞定。瞬间感觉当一个产品经理掌握了大模型中高层次技能，确实有种"超蓝变身"的感觉。

深入"屎山"：两万行代码的诞生

有了第一次成功的经验后，我开始更大胆的尝试。在短时间内，我用大模型构建了一个某知识库应用可运行 demo ，就是在这种背景下诞生的。

Python 文件 193 个，共 31278 行代码；JavaScript 文件 96 个，共 9731 行；HTML 文件 136 个，共 23024 行，17 个智能体 ...

看着这些数字，连我自己都震惊了。

一个从来没碰过代码的人，竟然能在 5 天内"写"出这么多代码？

到 5 月份的今天我已经用该能力完成了 3 个“屎山”演示的构建 。但问题是：这真的是"编程"吗？

PS： 这个是我写的几千行提示词其中的三句与根目录项目的控制文件

AI 编程的甜蜜陷阱

门槛降低了，但天花板更高了

刚开始，我以为 AI 编程就是"自然语言编程"。想要什么功能，直接告诉 AI 就行。

结果发现，这 TM 是个巨大的误解。

当代码量超过几千行时，你会遇到这些问题：

架构选择的困境：前端用 Vue、React 还是纯 CLI？后端选 Go、Python 还是 Rust？数据库用 MySQL 还是 PostgreSQL？

对于我这种非工程师背景的人来说，这些选择就像是在外语考试中选择 ABCD，完全靠蒙。

有次我问 AI："用什么数据库比较好？"

AI 回答得很专业：MySQL 适合简单应用，PostgreSQL 功能更强大，Redis 适合缓存...

但它不会告诉我：你这个应用根本用不着复杂的数据库功能，SQLite 就够了。

版本管理的缺失：大部分人都在"Vibe Coding"——凭感觉写代码，但不做版本管理。就好像在深山老林里瞎转悠，不留回头路的标记。

我就是典型的反面教材。写到 1/3 重构了四次，另外过程中突然想改架构，直接就在原文件上改。结果改着改着，连自己都不知道哪些功能还能用。

等代码写到一半发现方向错了，想回滚？对不起，没路了。AI 告诉我一大堆东西，我回复了一句话：我不懂技术不知道如何改......

安全性的盲区：AI 联网后，投毒者可能通过各种方式污染生成结果。缺少 Code Review 的代码，安全性就有天然缺口。

我后来用大模型检查代码时发现，AI 生成的 API 调用居然把敏感信息以明文方式传输 。

还有其他很多，感觉就是坐在“屎山上雕刻”。哈哈，这个比喻很形象。

从"能跑"到"能用"的巨大鸿沟

更扎心的是，当你兴冲冲地写完几万行代码后，发现：

• 70% 的功能是重复的（不同页面写了相似逻辑）

• 性能问题一大堆（数据库查询效率低下）

• 用户体验惨不忍睹（界面逻辑混乱）

• 维护成本极高（找个 bug 要翻好几千行代码）

这就是"屎山"的本质：看起来很宏伟，实际上摇摇欲坠。

比如我做的某个搜索功能，AI 很贴心地为每个搜索请求都创建了新的数据库连接。结果并发一高，服务器直接爆了。

还有个更离谱的：AI 为了实现"智能推荐"，把所有数据都加载到内存里进行计算。1000 条数据没问题，10000 条数据就卡死了。

调试成了最大的噩梦

写代码容易，调试难。

当你的应用出现 bug 时，你面临的不是一个错误，而是一连串连锁反应：

• 前端报错："Cannot read property of undefined"

• 后端日志："Database connection timeout"

• 用户反馈："页面白屏了"

作为一个不懂技术的产品经理，我的调试过程基本上是这样的：

• 把错误信息复制给 AI

• AI 给出一个"可能的解决方案"

• 照搬 AI 的代码

• 告诉 AI 说我不懂代码，你直接给我修改。

• 引发新的 bug

• 回到步骤 1

最长的一次调试，我花了整整一天时间，就为了修复一个表单提交的问题。

还有个更离谱的，为了修改几个 bug 2 天的 token 消耗了 xxx, 我看完 emo 了。

ps: 这是我调试 bug 的内容:

我看到后台 log 有返回数据了（这是之前 bug：有一个报错， 就是在智能问答中，发去了消息成功（不管开关是否使用知识库都是同样问题），但是智能问答页面上的智能小助手还是... 没有正确把这个结果在前端显示。）

：127.0.0.1 - - [01/Apr/2025 09:27:06] "POST /smart-qa/ask/stream HTTP/1.1" 200 - 2025-04-01 09:27:07,020 [WARNING] app.services.stream_parser: 未知事件类型: message_end, 数据: {'event': 'message_end', 'conversation_id': 'ffdb0ce0-84a9-4647-a31c-811d2915825a', 'message_id': 'a0da8019-48cc-46e4-8438-2b8e5811706f', 'created_at': 1743470825, 'task_id': '1eb185a0-74f2-4359-b339-6b83fc2a89e1', 'id': 'a0da8019-48cc-46e4-8438-2b8e5811706f', 'metadata': {'retriever_resources': [{'dataset_id'.=

坐在屎山雕刻了“三朵花”的顿悟

第一次重构：发现架构的重要性

第一版代码写完后，我发现前后端耦合得一塌糊涂。一个简单的功能修改，需要同时改动十几个文件。

更要命的是，我根本不知道哪些文件之间有依赖关系。

有次想调整一个按钮的颜色，结果把整个用户管理模块搞崩了。后来才发现，那个 CSS 文件居然还控制着数据表格的样式。

这时我才意识到：AI 具备的是执行能力，不是架构思维。

它可以帮你写出符合语法的代码，但不知道什么时候该分层，什么时候该解耦。

第二次重构：学会与 AI 协作

吸取教训后，我开始尝试更科学的方法：

从高层到低层逐步提示：先描述整体目标，再细化到数据模型、API 设计，最后才是具体实现。

比如我会先说："我要做一个知识库系统，支持文档上传、搜索、分类"，然后再具体到"用户表需要哪些字段"、"搜索接口怎么设计"。

先写测试用例：明确预期功能，让 AI 根据失败的测试生成代码。这比用自然语言描述需求靠谱多了。

说实话，写测试用例对我这种产品经理来说也是个挑战。但逼着自己写，确实能把需求想得更清楚。

制定规则文件：为项目创建编码规范，包含使用的库、命名规则、架构模式。

我的规则文件长这样：

• 前端统一用 Vue 3 + Element Plus

• 后端统一用 Python Flask

• 数据库字段命名用下划线分隔

• API 响应格式统一用 JSON

• 错误处理统一返回 error_code 和 message

使用工作空间：把前后端代码放在同一个环境里，让 AI 理解全貌。

这个真的很重要。AI 能看到整个项目结构后，生成的代码一致性明显提高了。

第三次重构：接受"屎山"的现实

第三次重构时，我终于想通了一个问题：

也许"屎山"就是 AI 编程的必经之路。

为什么这么说？

四、"屎山"存在的合理性

快速试错的价值

传统开发流程下，一个 feature 从需求到上线，至少需要 2-4 周。而 AI 编程可以让你在 2-4 小时内看到可运行的原型。

哪怕是"屎山"，也能让你快速验证想法、收集反馈、调整方向。

在产品早期，这种快速迭代的价值远大于代码质量。

我用 AI 做的第一个搜索功能，虽然性能一塌糊涂，但至少让我确定了用户确实需要这个功能。如果按传统流程，光是写需求文档就得一周。

学习成本的权衡

对于非技术背景的产品经理来说，学会使用 AI 编程的成本，远低于学会传统编程。

即使生成的是"屎山"，也比完全不会编程要强。

至少你能：

• 快速验证产品想法

• 和技术团队更好地沟

• 通理解技术实现的复杂度

现在我和开发同学讨论需求时，再也不会说出"这个功能很简单，加个按钮就行"这种话了。

渐进式优化的可能

"屎山"不是终点，而是起点。

有了可运行的原型后，你可以：

• 找专业开发者进行代码 review

• 逐步重构核心模块

• 基于用户反馈确定优化重点

这比从零开始要高效得多。

而且，很多时候"屎山"的存在本身就是价值。它证明了这个想法是可行的，只是实现得不够优雅而已。

五、那些踩过的坑

过度依赖 AI 的判断

刚开始用 AI 编程时，我几乎把所有决策都交给了 AI。

AI 说用 Redis 做缓存，我就用 Redis；AI 说需要微服务架构，我就拆分服务。

结果搞出了一个 over-engineering 的怪物：为了实现一个简单的 CRUD 操作，竟然用了 6 个不同的服务。

后来我意识到，AI 的建议往往是"理论上最佳"，但不一定适合你的具体场景。

忽视性能和安全

AI 生成的代码在功能上通常没问题，但在性能和安全方面经常有坑。

比如我发现 AI 特别喜欢用嵌套循环解决问题，N²的时间复杂度张口就来。还有就是对用户输入基本不做验证，SQL 注入的风险很高。

这些问题，如果没有专业知识，很难发现。

代码复用率极低

AI 每次生成代码时，都倾向于写"完整"的解决方案，很少复用已有代码。

结果就是同样的逻辑在项目里出现 N 遍，每遍还略有不同。改个公共功能，要改十几个地方。

AI 编程的正确姿势

混合使用不同 AI 模型

经过这次折腾，我总结出一套相对靠谱的方法：

• 某模型用于规划功能和架构设计

• 某模型快速生成代码实现

• 某模型处理复杂的逻辑问题

PS(某模型请对着自行对号入座，2333)

每个模型都有自己的长处，组合使用效果更好。

遵循软件工程基本原则

AI 再强，也改变不了软件工程的基本规律：

• 模块化设计：将复杂问题拆分成小块

• 关注点分离：UI 逻辑和业务逻辑分开

• 版本控制：每个阶段都要有回滚能力

这些原则，AI 不会主动提醒你，需要人来把控。

我现在的习惯是：每实现一个功能，就提交一次代码。出问题了至少能回到上个稳定版本。

理性看待"屎山"的价值

说到底，"屎山"只是一个过程，不是目标。

关键是要明确你的预期：

• 如果是验证想法的 MVP，"屎山"完全可以接受

• 如果是要长期维护的产品，就需要专业团队介入

• 如果是学习技术的工具，"屎山"反而是很好的教材

客户沟通的新姿势

从"纸上谈兵"到现场演示

最让我兴奋的是，AI 编程彻底改变了我和客户的沟通方式。

以前的流程是这样的：

• 和客户开会，听需求

• 回去写 PRD，画原型图

• 再约客户确认需求

• 技术评估，出设计稿

• 再和客户沟通修改意见

现在？完全不一样了。

上周和某电商客户的会议就是个典型例子：

客户说想要一个智能客服系统，能自动回答用户问题，还要支持多轮对话。

以前我只能拿着纸笔记录，然后说"我们回去研究下技术方案"。

现在我直接说："您稍等，我现在就给您做一个 demo。"

然后当场用 AI 写了个简单的客服界面：

• 前端用 Vue + Element Plus，界面很酷炫

• 后端调用 GPT API，实现智能对话

• 加了几个预设的 FAQ，看起来很专业

半小时后，一个能跑的客服 demo 就出来了。客户当场就能体验，输入问题，AI 回答，多轮对话，样样都有。

客户的反应？

"哇，这个界面不错，但是能不能把这个按钮换个颜色？" "回答的语气能不能更亲切一点？" "能不能加个转人工的功能？"

你看，这才是真正的需求沟通。不是你想象客户要什么，而是客户真正用了之后告诉你要什么。

掌握的几个"装逼"技巧

经过这几个月的摸索，我总结出几个屡试不爽的客户沟通技巧：

技巧一：现场造轮子

客户说需求时，我会边听边在电脑上敲代码。看起来像在记录，实际上是在用 AI 快速搭建原型。

等客户说完，我的 demo 基本也做好了。

关键是要掌握好节奏：太快了显得不真实，太慢了失去惊喜感。我一般控制在 15-30 分钟。

技巧二：从小功能开始

不要一上来就做复杂系统，先从一个小功能入手。比如智能客服，我先做个简单的问答界面，让客户看到 AI 能回答问题。

然后根据客户反应，逐步加功能：多轮对话、知识库检索、转人工...

这样客户能看到整个产品是如何"生长"出来的。

技巧三：预埋几个"彩蛋"

在 demo 里提前准备几个小惊喜。比如客户问到某个功能时，我会说"巧了，我刚好做了这个"，然后展示一个看起来很复杂的功能。

实际上这些功能可能就是几行代码调用个 API，但视觉效果很震撼。

技巧四：让客户参与

最重要的是让客户觉得这个产品是"我们一起"设计的。

"您觉得这个按钮放哪里比较好？" "您希望这个颜色更深一点还是浅一点？" "这个功能的名字您觉得叫什么比较合适？"

然后现场修改，让客户看到自己的想法立即变成现实。

这种参与感是传统 PPT 和原型图永远无法提供的。

我的产品原型矩阵

经过最近几个月的折腾，我已经用 AI 构建了好几个产品的可运行原型：

• 智能客服系统：支持多轮对话，FAQ 自动匹配

• 文档知识库：内容类几个垂直领域的文档模版与结构自动分割、自动解析，智能搜索和问答

• 数据分析平台：各类文档导入，自动提取数据并做分析，自动生成图表和分析报告以及工程项目相关风险。

• 会议纪要助手：语音转文字，自动提取关键信息，与流程集成

• 内容审核工具：文本合规检查，敏感信息识别

以及合同审核与风险分析等......

当然了，每个原型都不算完美，但都能跑，都能让客户直观地感受到产品的价值。最关键的是，这些原型让我在客户面前的话语权完全不一样了。

以前客户会质疑："你们真的能做出来吗？"现在客户会说："这个功能不错，但我还想要..."从质疑能力，到讨论需求，这是质的飞跃。

AI 编程改变了什么

产品经理的能力边界

以前产品经理的工作止步于 PRD，现在可以直接做出可交互的原型。

这种变化不只是效率提升，更是思维方式的转变。当你能快速实现想法时，你会更大胆地去试错。

团队协作方式

有了 AI 编程能力后，我和技术团队的沟通方式完全变了。

以前：

• 我：这个功能能做吗？

• 技术：应该可以，但需要评估下

• 我：大概多长时间？

• 技术：暂时不好说，先调研下

现在：

• 我：我做了个原型，你看看技术实现有什么问题

• 技术：整体思路没问题，但这里的性能需要优化

• 我：好的，我先改改，你再看看

效率提升不是一点点。

对技术的理解深度

虽然写出的是"屎山"，但这个过程让我对技术有了更深的理解。

现在看技术方案时，我能大概判断实现的复杂度，也能理解为什么某些需求"看起来简单，做起来复杂"。

意外的商业价值

说个更实在的：这种能力直接提升了我的商业价值。

以前和客户谈项目，我需要带着技术同事，还要准备各种材料。现在我一个人就能搞定前期的需求确认和 demo 演示。

客户签约率明显提升了。不是因为我的销售能力变强了，而是因为客户能直观地看到产品的效果。

"眼见为实"这四个字，在 ToB 销售中太重要了。

最近有个客户直接说："你们这个 demo 做得不错，我们想直接基于这个原型来开发。"

当然，我很诚实地告诉他这只是个原型，真正的产品开发还需要专业团队。但至少，我们拿到了这个项目。

从"屎山"到"产品矩阵"

现在回头看，那些被我称为"屎山"的代码，其实构成了我的产品能力矩阵。

每个原型都像是一个"技能点"，让我能够快速应对不同类型的客户需求：

• 需要智能客服的，我有现成的 demo

• 需要数据分析的，我能现场做个图表

• 需要文档处理的，我有知识库原型

• 需要工作流的，我有审批系统模板

这些原型的技术质量可能不高，但组合起来的威力很大。

就像游戏里的技能树，单个技能可能很普通，但全部点满后就是另一个维度的存在。

写在最后

这段时间的 AI 编程经历，让我对技术有了全新的认知。

以前总觉得编程是工程师的专利，现在发现：在 AI 时代，编程正在成为一种新的表达方式。

就像当年的 PS 让设计门槛降低，AI 正在让编程门槛降低。

虽然我写出的是"屎山"，但这座"屎山"让我：

• 理解了产品实现的复杂度

• 学会了和 AI 协作的方式

• 获得了快速原型的能力

• 对技术有了更深的敬畏

更重要的是，它改变了我对产品开发的思维方式。

现在的产品经理，如果还停留在"写 PRD 交给研发"的模式，很可能会被时代抛弃。

未来的产品经理 = 产品经理 + 设计师 + 初级开发者。

而 AI，就是那个让这种融合成为可能的工具。

当然，这不意味着产品经理要替代工程师。专业的事情还是需要专业的人来做。

但至少，我们可以在"想法"和"实现"之间，建立一座更短的桥梁。

至于"屎山"？能跑就行。反正后面还有重构的机会。

而且说不定，过几年 AI 进步了，连重构都不用人操心了。

（这篇文章的观点可能仅从非技术角度阐述，但当下的折腾是最真实的。如果你也想尝试 AI 编程，建议先从小项目开始。别像我一样，一上来就奔着几万行代码去。）

该如何从屎山上下呢？请听下回分解。

后记：写完这篇文章，我突然想起一个问题：当 AI 能生成完美代码的那一天，"屎山"还会存在吗？也许不会，但至少现在，"屎山"是我们通向未来的必经之路。

文章来自于微信公众号“InfoQ”。作者是“松子（李博源）”。