接到一个“用AI从0开始做复杂项目”的需求或者自己有这个念头我一般不会先急着打开对话框让它“帮我写代码”。因为复杂项目真正难的地方从来不是某一行代码怎么写而是需求怎么理清、模块怎么拆、依赖怎么管理、最后怎么验证。AI确实能干活但它最大的价值不是替代你写程序而是帮你把“一团乱麻”变成“一堆可执行的小任务”。这篇文章我尽量把整套思路摊开讲包括拆任务、选工具、写提示词、防AI胡说八道以及我在实际项目中踩过的坑希望能给正在计划用AI搞大工程的人一个参考。1. 想清楚“复杂项目”和AI的能力边界1.1 复杂项目到底难在哪复杂项目不是“代码量大”这么简单。我做了几年项目管理最深的体会是复杂项目的难来自“隐藏依赖”。你做一个电商后端订单模块要调用库存模块库存模块要依赖商品模块的数据结构商品模块又牵涉多语言和权限体系。改订单模块的一个字段类型库存模块可能就崩了。如果你脑子里的“项目地图”不够完整到处都是这种暗雷。还有个难点是需求不清晰。很多时候客户或者你自己只说得出“我要一个自动处理工单的系统”但细分下来工单有哪些状态、谁来分派、超时怎么通知、通知走邮件还是企业微信、历史记录要不要归档这些都是决策点。一个刚起步的人容易被这种模糊性吓住。第三个难点是验证成本高。小项目写完了跑一下就知道行不行大项目需要测试用例、数据构造、边界条件、回滚方案。很多从0开始做复杂项目的人根本没建好验证体系代码写了一半才发现架构错了推倒重来。这时候AI的角色就很有意思。它虽然不是一个“全知全能的老工程师”但它可以当一个极其擅长整理信息、发散思路、快速生成草案的助手。你把模糊需求丢给它它能列出一堆问题清单你把模块设定发给它它能补全你没想到的边界情况。关键在于你要知道它哪些话能信哪些话必须自己再验证。1.2 AI的边界它能补全信息但你得负责“验收”大模型的核心机制不是“理解”而是根据前文预测下一个最合适的词。这意味着它给出的大部分内容是“统计上合理”的但不一定“客观上正确”。它有几个很明显的能力限制上下文窗口有限。现在的模型能接收几万甚至十几万的token听着很大但一整个复杂项目的代码量动辄几十万行你不可能全塞进对话框。它只能看到你给的片段所以经常会出现“改了这个忘了那个”的情况。知识有时效性。模型训练数据有截止日期你问它某个新发布的框架版本它可能一本正经给一个不存在的API。不了解你的私有数据。没有你的库表结构、公司内部规范、用户真实行为数据它就只能泛泛输出。你如果不把关键约束喂给它它默认给你一套“通用方案”然后你落地时发现根本不匹配。会产生幻觉。在代码领域常见的是“编造不存在的函数”或者“建议一个看似合理的packagemanager命令结果实际不存在”。所以我的态度很简单AI是有用的但每个结果都要当做一个需要审查的草案。不是拿到就信也不是全盘否定而是快速用它能跑的优势加快你的决策速度再用你的经验和验证手段兜底。2. 搭建一个“人机协作”的完整工作流2.1 从零开始的四个阶段用AI做复杂项目最怕的是“从第一章开始就让它写到底”。我通常会把整件事分成四个阶段每个阶段都给人机协作留下接口。探索与拆解把目标说清楚让AI帮你发散问题、识别依赖、给出风险评估。这个阶段的产物是一份“问题清单”和“任务拆分表”。架构与选型有了拆解结果后让AI参与技术栈选择、模块划分、数据流向设计。这个阶段产出“文件结构”和“核心接口设计”。开发与实现按模块逐个生成代码。每次只让干一个模块干完立刻本地跑通、提交版本。验证与收尾生成测试用例、模拟数据、部署脚本、用户文档。在复杂项目中验证所占的精力常常比编码还大。你会发现每个阶段都有一份可验收的中间产物。这比“AI给我写了一个项目”然后你无从下口检查要健壮得多。人负责在每个阶段入口和出口做决策AI负责在中间大量生成内容。2.2 为什么这个流程能跑通核心原因是降低“上下文丢失率”。如果你从第一句话开始就把所有需求交给AI对话前几轮还好到后面它会忘掉最开始的约束。像我以前试过让AI直接写一个小型内容管理系统开头还知道要有多租户隔离写到第8个文件就把登录逻辑、租户ID丢得一干二净。后来我就痛改前非每进入一个新阶段都重新整理一份“约束摘要”粘贴给AI而不是让它凭记忆一路写下去。另一个原因是便于纠错。拆解阶段的差错成本最低代码阶段的差错成本已经高一些到测试阶段才发现接口设计错了那代价就很大。先计划、后编码看起来多花了些时间实际省掉了大量重写成本。我自己做过统计一个中等复杂度的项目如果跳过计划直接让AI开写大约60%的模块在后期需要返工而先花一个下午把任务拆解、接口约定、验收标准写清楚返工率能降到20%以下。3. 工具选型AI IDE、大模型API、AI Agent怎么搭配3.1 AI编程工具四个类型对号入座现在市面上能帮写代码的AI工具很多我用了不少这里不具体评测某个牌子只说我认可的分类方式。工具类型适合场景主要特点注意点通用对话模型需求拆解、思路梳理、代码片段生成使用简单适合“问”不会自动读你本地代码需要你提供上下文AI编程IDE插件在编辑器里直接补全、改代码能读当前打开的文件和仓库索引对仓库上下文的理解深度取决于工具大型仓库还是容易“犯糊涂”命令行AI助手终端下看日志、解释报错、跑命令适合运维和调试场景配置复杂需要谨慎授权AI Agent框架自动执行多步骤任务比如“改代码-跑测试-修错误”能协同工具链自主迭代容易失控必须在沙盒环境运行对于从0做一个复杂项目我建议的组合是通用对话模型 AI编程IDE插件。通用模型管方案设计和任务拆解IDE插件管代码生成和重构。如果一个模块的编写逻辑特别重复还可以让AI Agent去批量处理但没必要开篇就上Agent先把手感和上下文管理练好。3.2 AI Agent把复杂流程交给调度层AI Agent是现在很火的方向它的思路是让AI不只“生成内容”而是“执行任务”。比如一个编码Agent可以自动读取你仓库里的代码找到某个函数修改它然后运行测试根据报错继续修复直到通过为止。听起来很美好但在复杂项目里我劝你一定要加护栏。AI Agent的自主性越强破坏力也越大。它可能会擅自修改你没有授权的位置可能为了跑通测试而绕过正确逻辑甚至执行一些危险命令。正确的用法是把Agent限制在“单个任务”和“受控环境”内。比如在Docker容器或者虚拟环境里让它修改一个模块代码配合版本管理允许它试错但随时可以回滚同时限制它使用的命令白名单、网络访问范围、文件修改目录。用自己的主目录来跑Agent是在给自己埋雷。3.3 多模型协作让不同模型做不同的事我最近很迷一种方式让不同的AI干不同的活而不是只盯着一个模型。比如我会拿一个上下文窗口大的模型去做需求分析和文档整理因为它擅于长对话换一个在代码生成上更稳的模型去写核心算法模块再换一个专门做安全审查的模型去审代码里的注入、越权风险。让“测试模型”和“开发模型”彼此独立相当于让AI互相质检。这种多AI协作不是形式主义。每个模型的训练数据、调优方向、性格特点都不同同一个问题会给出不同答案。我多次发现一个模型认为“没问题”的实现另一个模型一针见血指出边界条件漏了。关键是要让AI输出的是“可验证的信息”而不是“绝对结论”。你跟它说“请指出这个函数在哪些输入下会失败”它的批判性输出往往比直接让它写代码更靠谱。4. 提示词工程从0到1的核心实操4.1 一条好用的万能提示词结构很多人问我“提示词怎么写才能让AI听话”我的答案是不要背模板而是理解结构。下面这个结构我一直在用几乎覆盖所有复杂项目阶段。项目背景…… 目标用户…… 技术栈……如果没有写“你来推荐但需要说明理由” 硬约束……性能、平台、安全、预算、截止时间 第一步任务……一次只给一个任务 验收标准……我怎么判断你干得好逐条解释一下项目背景让AI知道你这不是一个孤立的提问而是处于某个上下文里。目标用户技术选型和交互方式都会因此不同。给程序员用的工具和给行政用的工具界面复杂度和容错要求完全两回事。技术栈避免AI给你推一个完全陌生的框架。如果你没偏好让它给方案并且你要让它给方案理由而不是只报菜名。硬约束这是最容易漏的。你告诉它“不要用外部依赖”“必须在离线环境运行”“响应时间不能超过200ms”它才会在多个方案之间做出正确取舍。第一步任务复杂项目的一次提示词只能拆一小步。不是“帮我做一个系统”而是“帮我列出这个系统需要哪些子模块每个子模块的输入输出定义”。验收标准没有验收标准AI会给一份看似全面实则空洞的答案。你写了“逻辑可以用表格表达每条需求后面标上优先级”它就知道该写成什么样。4.2 分阶段示例从一句话到可运行代码我举一个具体的例子假设我想做一个“自动整理会议纪要并按优先级生成任务”的小工具。第一轮提示词我这样写项目背景团队每周开会需要把录音转成文字然后提取待办事项。 目标用户项目组5-8人技术基础一般给PM使用。 技术栈可以用Python也推荐更合适的。 硬约束希望在本地运行不上传隐私数据最终输出Markdown文件。 第一步任务请帮我拆解这个项目的完整任务清单包括功能模块、每个模块的边界、需要的数据格式。 验收标准清单里每个任务都要有交付物和验收方式。AI会给我一个清单音频读取、语音识别、说话人区分、摘要生成、任务抽取、Markdown导出。里面可能还多给出“关键词高亮”“历史记录管理”等这些我会根据范围标记为“后续版本”。第二轮让它选型基于上面的任务清单推荐具体的Python库和调用方式。每个选择都要提供理由和替代方案。第三轮让它按模块写代码。比如我先让它实现“音频读取和语音识别”这个小模块。它会给我一段可运行的代码片段。我在本机跑通、确认输出格式没问题之后再让它写“任务抽取模块”。每次只推进一个子任务这样可以避免上下文混乱。最后一轮让它生成测试请为“任务抽取”模块设计测试用例覆盖正常输入、空文本、多任务、无日期、重复任务、超长文本。然后生成pytest代码。你看整个过程没有一句“请你把整个项目写出来”但最后所有模块拼到一起就是一个完整项目。这是一个从0开始搭复杂项目时最稳妥的推进方式。4.3 让AI先出计划再出代码我还有一个习惯禁止AI“边想边写”。我会明确告诉它“先不要写任何代码只输出文件目录结构、每个文件的核心函数和它们之间的调用关系。等我确认后再开始写第一个文件。”为什么要这样做因为AI生成代码时容易“即兴发挥”。在没有全局约定的情况下它每个文件都自己设计数据格式最后你想把它们拼起来就会遇到“这边返回字符串那边期待字典”这种低级错误。先出计划相当于提前定好了接口契约代码生成阶段只需要照着填内容。实际执行中我会把AI给的“计划”复制保存新建一个约定文件放进项目仓库。后续所有对话我都要求它遵守这份约定。如果它想改某个接口必须说明理由。这个动作看似有点严苛但能保住复杂项目的系统性。5. 调试、测试与幻觉治理5.1 报错排查人机对话的“三板斧”每次拿到一段AI生成的报错代码我不会直接让AI“修复”而是按顺序做三件事。第一把完整报错信息、相关代码片段和运行环境说明一起贴回去。很多AI回答不准确是因为你只贴一句“有报错帮我看看”它压根不知道是什么环境、什么版本、什么依赖。第二让AI先解释原因不给解决方案。你可以说“请你先分析这段报错产生的原因指出是代码逻辑问题、依赖版本问题还是环境问题”。让它多想想它会避免直接给一个“看起来能跑”的补丁。第三让它提供多个方案并说明代价。比如修复版本冲突既可以通过升级依赖解决也可以通过改调用来绕开。你要问清楚这么做对现有模块的影响然后自己拿主意。我踩过一个很典型的坑AI为了修一个导入错误建议我“把整个依赖链升级到最新版本”。结果升级完以后另一个模块用了旧API直接崩了。后来我学乖了凡是AI建议改依赖版本我都要它解释“为什么必须升、影响面多大、有没有不升级的办法”。5.2 测试设计让AI扮演“破坏者”复杂项目最怕的就是“开发自测太温柔”。自己写代码时会有“这应该没问题”的心理暗示测试用例往往只覆盖正常路径。现在我会专门开一个对话让AI充当测试负责人角色提示词如下你是QA专家。需求是[粘贴模块需求]。请你先列出这个模块可能出错的所有情况不考虑面子专门往坏处想。然后再为每种情况设计一个测试用例。这个提示词有奇效。它让我意识到自己的代码里有多少个未曾设想的输入。比如一个日期参数我以为只可能是“2024-05-01”这种格式但AI提出“闰年”“时间戳字符串”“11月31日”“空串”“带时区偏移的ISO格式”这些都是真实世界会出现的脏数据。另外让AI生成测试数据也很方便。比如现在需要模拟一批订单数据字段包括金额、状态、用户ID、创建时间我只要把字段约束告诉它它一分钟就能生成CSV样例省去我手写50行数据的功夫。生成后你自己肉眼过一遍再抽几个用例人工算一下就可以放心跑测试。5.3 建立“护栏”代码评审、类型检查、版本管理AI代码的质量时好时坏如果你不设护栏它会在你没注意的地方埋雷。我这里有三个建议。加静态检查和类型检查。在Python项目里用mypy在JS/TS项目里用ESLint和tsc。AI生成的代码很容易出现动态类型上的草率处理。类型检查能在一开始就拦截很多低级错误。每次生成完都要跑一遍测试再合并。不要让AI“一口气把所有文件写完后一起调试”。一个模块一个模块地跑哪里坏了立刻让AI修成本最低。所有AI修改必须走版本管理。我用Git做小步提交。每次让AI改完一个功能代码能跑了立刻commit。如果后面AI改坏了什么东西我直接回顾前一个commit而不是费劲去找哪一行变了。复杂项目里回归成本高能随时回滚就是救命稻草。6. 常见问题速查表与独家心得6.1 问题速查表我整理了做AI辅助开发时最常见的几个问题用一张表说明怎么判断和处理。现象可能原因处理办法AI给的技术方案过时训练数据截止或偏好冷门方案让它注明方案版本再用最新文档核对关键API生成的代码运行报错依赖版本不匹配、接口签名猜错贴完整报错信息让它解释原因再决定修复方向写到后面忘了前面的约束上下文窗口有限拆分子任务每次带上“约束摘要”或换用长上下文模型让AI Agent运行成功后改坏了其他功能Agent执行边界过宽用沙盒限制目录和命令把任务范围缩到最小AI输出看起来完整其实缺了核心逻辑并没有真正理解业务只是堆词要求它先列出逻辑步骤并说明假设人工检查后再写实现生成测试全通过但真实场景仍出错测试用例和业务场景不一致用真实数据跑一遍增加边界用例让QA角色重新审需求这里的核心不是“出了问题让AI背锅”而是你要有一个判断流程先判断信息是否完整再判断方案是否经过验证最后判断影响面。每一层都能过滤掉一部分AI幻觉。6.2 我自己的几点实操体会第一AI是放大器不是替代品。如果你的目标感很强它能帮你把执行力放大很多倍如果你根本没想清楚要什么它能在一小时内生成一堆漂亮但无效的代码。用AI之前至少要能一句话说清“谁在什么场景下需要解决什么问题”。第二上下文质量优先于速度。我宁可花两分钟写一段详细提示词也不愿意花二十分钟去猜AI为什么会给我一个偏答案。写提示词这个过程本身就在逼我把事情想清楚这比AI给的结果更值钱。第三把AI当实习生带但别当永久工具人。我会把需求拆得很细让它先列计划、再写代码、再写测试每一步都要求它自我解释。这样培养出来的工作流不管AI技术怎么迭代你都会很稳。它会偶尔偷懒会自作主张但你能用自己的经验死死压住它。最后再分享一个我坚持了很久的小习惯每天结束工作前我会把当天所有AI对话里的关键结论和决策抄到一个项目文档里第二天开工直接看这个文档。复杂项目周期动不动几个月记忆靠不住对话记录太散唯一的稳定信息源就是你亲手维护的上下文。只要做到这一点你离“用AI从0做完一个复杂项目”这件事就已经成功了一大半。