项目开始前我们做了一次很认真、也很传统的工作量评估。产品经理负责梳理流程前端开发管理交互后端开发搭建服务算法工程师处理模型测试工程师负责验收。五个人预计三到四周。而我只有七天。这并不是一个“一人替代五人”的效率神话。真正让我按时交付的也不是连续熬夜而是主动缩小问题、复用成熟能力并把原本需要多人协调的工作压缩成一条可以自动运行的流水线。最终做出来的产品并不复杂用户提交一份内容需求系统自动拆解任务生成文案和视觉素材等待用户确认后再统一导出。它不是一个无所不能的 AI 平台只是一个边界明确、能够完整运行的产品。这篇文章记录的是我如何在七天内完成它。第一天先删掉一半需求项目最初的需求文档有十几页。用户体系、团队空间、历史版本、素材管理、模型选择、数据看板、在线编辑、权限控制……每个功能单独看都合理放在一起却足以拖垮任何一个短周期项目。我没有立即开始写代码而是先问了一个问题用户第一次打开产品时最想完成的动作是什么答案不是注册账户也不是管理素材。而是输入一个需求然后拿到可以继续修改的内容。因此第一个版本只保留了四个步骤输入需求 ↓ 拆解任务 ↓ 生成内容 ↓ 确认并导出账号系统暂时使用最简单的登录方式历史记录只保留最近任务在线编辑器也只提供必要能力。第一天结束时我还没有完成任何页面却删除了接近一半的计划功能。后来回头看这可能是七天里最重要的一次开发工作。短周期项目失败往往不是因为代码写得太慢而是因为一开始就试图解决太多问题。第二天先让整条链路跑起来我没有按照“后端完成后再开发前端”的顺序推进。这种方式适合职责明确的团队却不适合单人开发。一个人最容易掉进的陷阱是花三天搭建漂亮的底层结构第四天才发现产品主流程根本走不通。所以我先做了一条很粗糙的纵向链路。前端只有一个输入框和一个按钮后端只有一个接口数据暂时保存在本地数据库。用户输入需求后服务端把任务发送给模型再将生成结果直接返回页面。当晚产品已经能够完成第一次端到端运行。页面很丑错误处理几乎不存在刷新后部分状态还会丢失。但它已经是一个产品而不是几组互不相连的代码。我把这种方式叫作“先打通再加固”。只要主链路能够运行后面的每一次开发都会变成局部改进而不是在黑暗里猜测不同模块能否拼到一起。第三天把模型隔离在业务之外最初的代码直接在业务逻辑中调用模型。很快问题就出现了。文案生成需要文本模型视觉素材需要另一类模型。不同任务的参数、返回结果和失败方式并不完全一致。如果继续把调用代码散落在各个服务里后面每增加一种能力都要修改大量业务代码。于是我增加了一层模型适配器。interfaceModelProvider{generateText(input:TextTask):PromiseTextResult;generateImage(input:ImageTask):PromiseImageResult;getTaskStatus?(taskId:string):PromiseTaskStatus;}业务层不再关心请求具体发往哪里只需要描述任务constresultawaitprovider.generateText({scene:product_intro,prompt:userInput,format:markdown});适配器负责把统一任务转换为对应的请求格式再把不同响应整理成业务能够识别的结果。这层抽象看起来多写了一些代码实际却节省了大量时间。模型变化时我只需要调整适配器业务流程、页面状态和数据库结构都不必跟着修改。在这个阶段我将部分模型能力通过 grsai 接入。它在项目里的位置只是模型网关相关配置和入口放在 https://grsai.com业务代码中没有出现具体服务名称。这样处理还有一个好处模型服务不是业务本身。产品真正应该沉淀的是任务流程、用户数据和交互体验而不是对某个请求地址的依赖。第四天把耗时任务改成异步文本生成通常可以在一次请求中返回但图片等任务可能需要更长时间。如果前端一直等待 HTTP 请求完成会遇到几个问题页面容易因为超时显示失败用户刷新后无法恢复任务同一任务可能被重复提交后端难以统一管理重试。我将生成流程改成了异步任务。前端提交需求 ↓ 服务端创建任务 ↓ 返回 task_id ↓ 任务队列执行 ↓ 更新任务状态 ↓ 前端获取结果任务状态被简化为五种typeTaskStatus|pending|running|succeeded|failed|cancelled;数据库只记录必要字段CREATETABLEtasks(idTEXTPRIMARYKEY,typeTEXTNOTNULL,statusTEXTNOTNULL,input_jsonTEXTNOTNULL,output_jsonTEXT,error_messageTEXT,created_atDATETIMENOTNULL,updated_atDATETIMENOTNULL);为了避免用户重复点击我还为任务生成了幂等键。相同用户在短时间内提交相同内容时系统会返回已有任务而不是再次创建。这套设计没有使用复杂的分布式架构。第一个版本的请求量有限一张任务表加一个轻量队列已经足够。过早引入庞大的基础设施只会把七天项目变成七周项目。第五天让 AI 输出变得可控让模型返回内容并不难。难的是让它每次都返回系统能够处理的内容。最早的版本要求模型输出 JSON但测试时经常遇到字段缺失、格式错误以及正文外出现解释文字等情况。只要一个字符不符合预期后续流程就可能中断。我做了三层处理。第一层是约束输出结构{title:string,summary:string,sections:[{heading:string,content:string}]}第二层是服务端校验。模型返回结果后先经过 Schema 验证不符合要求就进入修复流程。第三层是允许降级。如果结构化解析仍然失败系统会保留原始文本用户至少能够看到内容而不是只得到一个错误页面。核心逻辑大致如下constrawawaitmodel.generateText(task);constparsedschema.safeParse(raw);if(parsed.success){returnparsed.data;}constrepairedawaitrepairOutput(raw);if(repaired.success){returnrepaired.data;}return{title:生成结果,summary:,sections:[{heading:正文,content:raw}]};这一天我最大的感受是AI 产品的工程重点并不是如何成功调用模型而是如何处理模型没有完全按照预期工作的时刻。第六天测试主流程而不是追求测试数量只剩两天时我没有时间为每个函数编写完整测试。于是我把有限精力集中在最危险的路径上用户能否成功创建任务任务失败后能否重新执行页面刷新后能否恢复状态模型返回异常格式时系统是否仍然可用同一请求会不会被重复处理导出的内容是否与页面确认版本一致。我还准备了一组固定输入作为最小回归测试集一句话的简单需求包含多项约束的长需求中英文混合内容空输入和超长输入容易触发格式问题的特殊字符连续重复提交的相同任务。每次修改核心逻辑后我都会重新运行这组输入。测试覆盖率并不漂亮但真正影响交付的错误基本都能被发现。对七天项目来说这比追求一个看起来很专业的覆盖率数字更有价值。第七天停止开发新功能最后一天最容易犯的错误是看到产品已经能够运行便想再增加几个功能。我也产生过这种冲动。要不要加模板市场要不要支持多人协作要不要让用户自由切换模型要不要增加数据统计最后我把这些想法全部放进了下一版本列表。第七天只做三件事修复阻断主流程的问题补充日志和错误提示从新用户视角完整运行产品。我还删除了几个已经写完、但会让操作变复杂的入口。功能已经完成并不意味着它必须出现在产品里。隐藏不成熟的能力有时比添加新功能更需要判断力。晚上十点我从空白页面开始走了一遍流程输入需求提交任务等待生成修改内容确认结果导出文件。整个过程顺利完成。我终于可以把任务状态改成“已交付”。一个人完成不等于一个人包办所有能力复盘这七天我并没有真正完成五个人的全部工作。我没有建立复杂的设计系统没有开发完整的权限平台没有训练模型也没有搭建大规模基础设施。我做的是另外一件事把必须由人完成的产品判断留给自己把已经成熟的通用能力交给现有工具。这也是 AI 时代单人开发方式最明显的变化。过去一个产品需要先组建团队再按照职责拆分工作现在可以先围绕核心流程组合数据库、部署平台、模型接口和现成组件然后根据真实需求逐渐替换其中的部分。个人开发者不需要拥有所有能力。他需要知道哪些东西值得自己写哪些东西应该抽象哪些东西可以直接使用以及哪些需求暂时不应该做。七天项目带给我的五个结论第一先缩小问题再提高开发速度。范围控制带来的效率远高于任何代码生成工具。第二尽早完成端到端链路。一个粗糙但能够运行的产品比五个精致却无法连接的模块更有价值。第三把模型调用和业务逻辑分开。模型会变化接口也会调整但业务流程应该保持稳定。第四默认外部服务可能失败。超时、重试、幂等和降级不是上线后的优化而是 AI 产品的基础能力。第五到时间就停止增加功能。交付的关键不是做完所有设想而是让一个完整场景真正可用。一个人、七天做出原本计划由五个人开发的产品听起来像一个关于效率的故事。但对我而言它更像一个关于取舍的实验。真正提高效率的不是让我写得更快而是让我更早知道哪些代码根本不需要写。