AI端到端全流程交付
引言：从狂热到阵痛，三个月实践沉淀下的AI协作心法
你一定在各种短视频里刷到过，有人宣称用AI"一句话就能生成一个完整的产品"。最初，我也曾被这种狂热的情绪所感染，幻想着只要掌握了"魔法咒语"，一天做一个产品原型将不再是梦。然而，当真正将AI应用到实际工作中时，我才体会到理想与现实的巨大鸿沟。
我最初的尝试，为了做一个页面，花了整整5天，反复迭代了74个版本才勉强达到想要的效果。这次与最初设想形成鲜明对比的挣扎，是一堂关于AI落地现实的、痛苦但必要的入门课。
正是这段从狂热到阵痛的经历，迫使我从混乱无序的摸索中冷静下来。历经三个月的踩坑和不断实验，我与团队逐渐沉淀出了一套稳定、高效的AI协作工作流。本文将分享的，正是这套工作流背后的核心"军规"与实践框架，希望能帮助你少走弯路，真正将AI的潜力落地到日常的研发工作中。
1. 我的AI编程探索之旅：四个阶段的演进与蜕变
本章将按照时间线，详细回顾我的AI编程探索之旅。它始于个人初次接触AI编程的震撼，经历了掌握生产级AI原型设计的精通，发展到推动团队全面拥抱AI的赋能，并最终在项目中实现了端到端AI全流程交付的巅峰。这不仅是一条个人技能的成长路径，更是一场团队协作模式的深刻变革。
1.1. 阶段一：初体验 — 从"一句话原型"的震撼到74次迭代的"阵痛"
2025年4月，我初次感受到"一句话生成产品原型"带来的震撼，这颗种子就此埋下。然而，理想的丰满很快被现实的骨感所击碎。当我尝试将AI应用于一个实际项目时，为了实现一个页面，我花费了整整5天时间，与AI反复拉扯，迭代了惊人的74个版本。这次"痛苦"的经历让我清醒地认识到，将AI从一个新奇的玩具转变为可靠的生产力工具，需要一套截然不同的方法论。这次心态的转变，是我从天真幻想迈向务实探索的真正起点。
1.2. 阶段二：精通 — 构建生产级原型工程，实现效率倍增
从2025年5月到12月，我将重心放在了如何体系化地利用AI进行生产级原型设计。在此期间，我们完成了多个关键项目，包括复刻驾驶舱产品原型、赋能外呼产品团队，以及交付员工画像、架构治理等多个设计项目。
我们发现，单纯生成独立的HTML文件拓展性差，组件复用率极低。关键的突破在于建立了一套基于现代前端框架（如React）的"原型设计工程资产"。在这个统一的工程基础上，AI可以复用沉淀下来的通用组件库和页面模板，保证了设计的高度一致性。这一转变让我们实现了设计效率的n倍提升，完成了从"游击战"到"体系化作战"的关键蜕变。
1.3. 阶段三：赋能 — 推动团队全面拥抱AI编程
个人实践的成功让我意识到，更大的价值在于赋能整个团队。从2025年8月开始，我开始在团队中大力推动AI编程。这一过程也伴随着公司AI工具策略的演进：
- 自研探索 (2024年2月-5月): 我们最初尝试自研IDE插件，但很快发现自研ROI不高，投入人力巨大却难以在短期内看到显著提效。
- 拥抱商业化 (2024年6月-2025年3月): 团队转向拥抱商业化产品，引入了通义灵码和GitHub Copilot进行试点。
- 全面转向Cursor (2025年5月至今): 随着Claude 3.7等里程碑式模型发布，商业AI编程工具的能力迎来质变。我们果断全面转向编码能力更出色的Cursor。
团队的反馈极其积极。Cursor的账号申请数量从最初的250个迅速增长，到9月份已累计申请了800个，覆盖了前后端大部分同学。数据最有说服力：到2025年10月，我们团队的需求交付中，超过95%的工作已由AI主导完成。
1.4. 阶段四：巅峰 — 跑通端到端AI全流程交付
"数据看板"的开发，是我们将AI能力推向巅峰的标杆案例。在这个项目中，我们首次跑通了从产品设计到前后端开发、再到测试的AI驱动端到端完整交付流程。
- 产品设计： 我们利用AI模型（Gemini 3.0）的强大理解能力，仅用半天时间就完成了第一版产品原型。更重要的是，我们拿着这个可交互的原型直接与CTO沟通方案，讨论更聚焦，决策更高效。
- 开发阶段： 确认后的原型被直接导入现有工程，由AI辅助生成对应的前端代码。在后端，我们让AI基于原型建议API设计，并采用分步实现策略，最终在不到2小时内高效完成了所有API的开发，且第一版代码无任何报错。
- 测试与质量保障： 在这个环节，AI甚至给出了意料之外的创新方案。它建议在端到端测试中引入内存数据库，在项目启动时自动建表并插入测试数据，极大提升了测试容器的加载速度。此外，我们让AI根据API设计预先生成JSON响应格式，这不仅验证了API设计的正确性，生成的JSON数据还被直接复用为Postman的自动化测试用例。
这些成功的实践背后，是一套系统化的框架在支撑，它将零散的技巧固化为了团队可复制的能力。
2. AI编程的实践框架：从通用基础到四象限应用
为了将AI编程从少数人的"奇技淫巧"提升为整个团队可复制的系统能力，我们总结出了一套实践框架。它包含三大通用基石，作为所有场景下与AI协作的基础；以及一个基于"复杂度"和"规模"二维度量的四象限应用模型，为不同类型的开发任务提供场景化的应对策略。
2.1. 通用实践：三大基石
这三大基石是高效AI协作的"地基"，贯穿于所有开发活动中。
- 提示工程 (Prompt Engineering): 高质量的提示词是与AI沟通的基础。一个有效的提示应包含清晰的目标、充足的上下文信息和明确的输出格式要求。在适当的时候提供少量示例（Few-Shot Prompting），能显著提升AI的理解和输出准确性。
- 规则与治理 (Rules & Governance): 我们通过建立项目级规则（如Cursor中的.cursor-rules文件）为AI协作设立"护栏"。这些规则定义了项目的技术栈、代码风格和规范，确保AI生成的代码与现有项目保持高度一致，显著减少了后期的人工审查和修改成本。这一基础原则通过分配专家"岗位"和创建项目专属"入职手册"等具体策略得以实践，我们将在下一章深入探讨。
- 上下文管理 (Context Management): AI的"记忆"是有限的，混乱的上下文会导致指令失真。我们坚持"一个需求，一个对话"的原则，为每个独立的任务开启一个全新的对话窗口（New Chat Window），以此来保持上下文的纯净，这是最高效简单的上下文管理策略。
2.2. 四象限应用：场景化策略
我们将开发任务按"复杂度"和"改动规模"两个维度划分，形成了四象限模型，以匹配不同的应对策略。
- 第一象限 (低复杂度·小改动):
- 场景特点: 日常开发中常见的、范围明确、目标清晰的任务。
- 典型案例: 日常Bug修复、MCP优化、UI布局微调、Git问题解决。
- 应对策略: Build / Plan -> Build
- 第二象限 (低复杂度·大改动):
- 场景特点: 代码逻辑本身不复杂，但涉及范围广、重复性高的例行任务。
- 典型案例: 大规模代码重构或为整个模块集成单元测试。
- 应对策略: Plan + Build + To-Do List 和 Code Check
- 第三象限 (高复杂度·小改动):
- 场景特点: 涉及新算法或复杂业务逻辑，实现范围和影响不明确的探索性挑战。
- 典型案例: 探索新的架构治理方案。
- 应对策略: Split Task (任务拆分) 和 Spec Coding (规范驱动编码)
- 第四象限 (高复杂度·大改动):
- 场景特点: 系统性风险高，需严谨拆解和规划的艰巨任务。
- 典型案例: 从零开始开发一个新的MCP Tool。
- 应对策略: Spec Coding (规范驱动开发) 和 Split Task & To-Do List
框架的有效落地，最终依赖于开发者底层思维的转变和核心策略的运用。
3. AI编程的底层思维与核心策略
工具和框架只是表象，真正决定人与AI协作效率上限的，是我们的底层思维模式和核心策略。本章将揭示那些最具颠覆性的秘诀，它们能将AI从一个"什么都懂一点"的通用工具，转变为深刻理解你项目的"专业伙伴"。
3.1. 思维重塑：你是机长，AI是副驾驶
要用好AI，第一步是心态归零。最有效的协作心智模型是：把它当成你的实习生，而你是它的管理者（TL）。这意味着你需要主动地去规划、拆解、监督和修正它的工作，而不是被动等待一个完美的答案。
同时，必须牢记另一个核心原则：你是机长，AI是副驾驶。AI是强大的副手，可以帮你加速，但绝对不能替你思考和负责。你必须对AI生成的每一行代码进行严格的审查、理解和测试。这不仅是一个技术问题，更是我们作为工程师的职业素养和工程责任心的体现。
3.2. 沟通精要：让AI像专家一样思考与协作
低效的"猜谜式"沟通足以摧毁你的耐心。以下策略能让你的指令像专家一样精准：
- 分配"岗位": 我们通过配置角色规则，为AI设定不同的专家身份，强制它在特定场景下，必须戴上特定的"专家帽子"。这极大地提升了产出内容的专业性。我们常用的角色包括：@产品经理、@架构师、@后端/前端开发、@代码评审员、@测试工程师。
- 喂给"入职手册": 通过配置项目级规则（Project Rule），我们为AI提供了一份"入职手册"。其中详细规定了项目的技术栈、各层职责、编码规范（如推崇使用卫语句）、依赖工具（如指令它统一使用Hutool）等。这一步将AI从通用工具"训练"成了"入乡随俗"的专业团队成员。
- 先"沟通"再"动手": 面对复杂任务，我们坚持先在"Ask模式"（对话模式）下与AI充分讨论并确认方案，再切换到"Agent模式"（执行模式）让它动手修改代码。这体现了与AI"协作"而非单向"命令"的思维，能极大避免方向性的错误。
- 精准表达: 为了让AI精准理解意图，我们利用stwise这类插件直接选中页面元素生成结构化指令；通过add context功能限定修改范围；并直接将页面截图和浏览器报错信息作为上下文提供给AI，让它拥有诊断问题的"地图和说明书"。
3.3. 工作流升级：从"一口吃胖子"到"分而治之"
面对一个完整的功能模块开发，最忌讳的就是"一口吃个胖子"。开发者应扮演"项目经理"的角色，遵循"沟通 -> 拆分 -> 实现"的原则，将大任务拆解成AI可执行的小块。
- 后端工作流示例:
- 需求理解: 使用@产品经理角色输入PRD，与AI确认需求。
- 生成技术方案: 切换到@架构师角色生成技术方案。
- 方案评审与细化: 人类开发者评审方案，并指令AI细化接口实现逻辑。
- 分步生成代码: 方案确认后，逐个功能、逐个接口地生成代码。
- 测试验收: 调用@测试工程师生成测试用例进行验证。
- 前端工作流示例: 前端团队封装了一套更高效的"Workflow"。通过激活工作流，我们可以直接提供后端的语雀技术方案链接作为核心上下文。工作流会在每个阶段结束后暂停，生成文档等待开发者进行阶段性确认（Stage-Gate），然后才进入下一阶段。对于复杂页面，它支持增量生成，先构建框架再填充细节，极大地保证了开发过程的可控性。
3.4. 基础为王：AI时代，基本功反而更重要
这是一个反常识但至关重要的观点：想用好AI，你反而需要掌握扎实的前端基础知识，尤其是HTML和CSS布局（如Flexbox）。
原因在于，AI生成的页面，最难调试的就是布局和样式。当AI给出的布局不符合预期时，如果你完全不懂CSS，就只能和它进行低效的"猜谜式"沟通。但如果你懂基本原理，就可以直接给出精准指令，例如"将此容器的display改为flex，并设置justify-content为space-between"。这让你从一场依赖运气的对话，转向一场由你主导的、精准控制的对话。
4. 结论：AI不是要替代你，而是要解放你
回顾全文，你会发现，驾驭AI的关键，与其说是提示词的技巧，不如说是一套正确的心态、系统化的工作流和扎实的基本功。
AI的出现，并不会轻易替代产品经理或开发者。恰恰相反，它正在把我们从大量重复、繁琐的原型绘制和代码编写工作中解放出来。这让我们拥有了更多宝贵的时间，可以去和业务方深入沟通、去孵化酝酿已久的新创意、去做那些真正需要人类智慧和同理心的、更有价值的事情。
当AI接管了"画图"和"搬砖"的工作，产品经理和开发者的核心价值又将演变成什么？这是一个值得我们每个人深思的问题。