7.1
深览指数
科技人人都是产品经理·东哥说AI··AI 生成
让AI从零做完一个系统，这几条避坑铁律我建议你先看再动手
作者分享了自己使用AI辅助编程（Vibe Coding）完成一个智能数据分析代理系统后，总结出的核心避坑经验。文章强调了联调时以一方为准、AI不能完全甩手、警惕AI的虚假测试通过、以及按需接入MCP和精简Rules等关键原则。适合正在尝试或计划使用AI进行实际项目开发的工程师，提供了可操作的实战经验，而非泛泛而谈的理论。原文 ↗
核心观点
- ▍AI编程的核心不是写代码，而是维护文档（需求、规划、字段规范），文档越准，AI生成的代码越稳。
- ▍让人工智能辅助编程时，开发者必须充当“看仪表盘的人”，监控服务状态（端口、进程、虚拟环境），在AI偏航时及时纠正方向，不能完全甩手。
- 01联调时，作者的方法是先让AI对比前端接口文档和后端真实返回字段，并以确认过的后端字段为准让前端适配，避免双方都不确定导致的反复调试。
- 02SSE流式输出需要后端推送一个特殊的结束标识，前端收到才知道流结束，否则会一直监听等待。
- 03AI在服务启动失败时，第一反应是再新建一个虚拟环境，导致环境混乱。作者的经验是必须告诉AI“有多余的虚拟环境”，引导它去排查。
- 04最隐蔽的坑是“假测试通过”：AI声称测试通过，但实际上并未配置大模型API Key，只验证了UI框架和接口连接，未跑通真实的LLM对话流程。
- 05上下文记忆会导致AI在同一个会话中直接复用历史答案，跳过NL2SQL流程，导致不生成图表。新建会话可解决此问题。
- 06MCP（Model Context Protocol）应“按需接入”，全接上会消耗token和上下文，让AI搞不清项目整体架构。应配合Rules按文件类型触发加载。
- 07Rules编写应“大道至简”，先跑通一个MVP，等AI在同一个地方反复犯错时，再针对性迭代规则，而不是第一次就想覆盖所有场景。
反方 / 局限
- — 本文的“铁律”基于作者个人的项目经验，其有效性依赖于特定场景（如使用Cursor/Claude这类工具），对于不同编程语言或更复杂的系统架构，这些经验可能需要调整或补充。
5 分钟 · 3 卡片 · 6 资料
读原文 →