1. 从一句话到上线这套打法到底在解决什么问题“帮我做一个能记录每天喝水量的 App最好能提醒我还能看一周的统计。”——如果你接过这种需求大概会先愣三秒功能边界在哪用什么技术栈谁来设计界面后端要不要上线走什么流程更关键的是客户只给了你一句话剩下的全靠你自己脑补。WorkBuddy FDE 这套实战手册要解决的就是这种“一句话需求”到“真正上线一个 App”之间的巨大鸿沟。FDE 是 Forward Deployed Engineer 的缩写直译过来叫“前线部署工程师”这个角色最早在 To B 服务领域被广泛使用——不是坐在办公室里等需求文档而是直接扎到客户现场把模糊的业务诉求翻译成可运行的系统。WorkBuddy 则是一套围绕 AI Coding 构建的工作台它把 DeepSeek 这类大模型能力、项目脚手架、缓存管理、多环境切换这些琐碎但关键的环节打包在一起让一个人或者一个小团队能在极短时间内把想法跑通。这套内容适合三类人第一类是想转行做 FDE 但不知道从哪下手的开发者第二类是接了外包项目却总在需求对齐和交付节奏上翻车的独立开发者第三类是用 AI Coding 工具写了不少 Demo 但从来没真正上线过一个完整 App 的爱好者。我会把 90 天的路径拆成可执行的阶段每个阶段告诉你该做什么、为什么这么做、踩过哪些坑。不是理论是我自己从零跑通过好几遍的实操记录。2. 先搞懂 WorkBuddy 和 FDE 到底怎么配合2.1 WorkBuddy 不是 IDE它是你的项目管家很多人第一次接触 WorkBuddy 会误以为它是个代码编辑器其实不是。它更像一个“项目生命周期管理器”——你告诉它你要做什么它帮你把项目结构搭好、把 AI Coding 的上下文准备好、把缓存和依赖管明白。我实测下来它最核心的价值有三个项目脚手架一键生成不用再手动django-admin startapp或者配vite它根据你的需求描述直接给出可运行的初始结构。AI Coding 上下文管理DeepSeek 这类模型在长对话里容易“忘事”WorkBuddy 会把项目关键文件、接口定义、数据模型这些上下文自动喂给模型减少胡编乱造。多环境切换与缓存隔离开发、测试、生产环境的配置和缓存目录分开管理避免“本地跑得好好的一上线就崩”。注意WorkBuddy 的缓存目录默认在用户目录下如果你做的是多项目并行一定要在设置里把每个项目的缓存路径分开否则会出现 A 项目的依赖把 B 项目搞崩的情况。这个坑我踩过两次排查了大半天。2.2 FDE 的核心能力模型翻译、拆解、兜底FDE 不是单纯写代码的人。我总结下来一个合格的 FDE 需要三种能力第一是翻译能力。客户说“我要一个像抖音那样的 App”你不能真的去写推荐算法而是要翻译成“短视频上传、列表播放、点赞评论、基础推荐按时间倒序”。这个翻译过程决定了项目边界边界不清后面全是坑。第二是拆解能力。把翻译后的需求拆成可独立交付的模块。比如“喝水记录 App”可以拆成用户系统先不做用本地存储、记录模块、提醒模块、统计模块。每个模块单独可测最后组装。第三是兜底能力。客户临时加需求、服务器挂了、第三方接口变了你得有预案。FDE 的兜底不是写更多代码而是提前留好扩展点和降级方案。2.3 为什么选 DeepSeek 作为 AI Coding 的底座热词里出现了 DeepSeek、Claude Code、Codex 接入 DeepSeek 这些说明大家都在找性价比高的 AI Coding 方案。我选 DeepSeek 的理由很实际对比维度DeepSeek其他方案代码生成质量中上Python/JS 尤其稳部分模型在特定语言上更强长上下文保持较好配合 WorkBuddy 的上下文管理够用原生上下文长的模型有优势成本低适合高频调用部分模型按 token 计费较贵中文需求理解好毕竟中文语料多部分模型对中文需求有偏差我不是说 DeepSeek 全面碾压而是在“一个人做完整 App”这个场景下它的综合性价比最高。你完全可以在 WorkBuddy 里切换不同的模型但 90 天路径里我默认用 DeepSeek 来跑。3. 90 天路径从一句话到上线的完整节奏3.1 第 1-15 天需求翻译与项目骨架这个阶段的目标只有一个把一句话变成一份可执行的需求清单并且把项目跑起来。第 1-3 天需求翻译。拿“喝水记录 App”举例我会做三件事把原始需求写成用户故事“作为用户我想记录每次喝水的量以便知道今天喝了多少。”列出必须有的功能记录输入毫升数、列表按时间倒序、统计今日总量、近 7 天趋势。明确不做的功能用户登录、社交分享、云端同步。这些不是不重要而是第一版不做。实操心得需求翻译阶段一定要写“不做什么”这比“做什么”更重要。我见过太多项目死在范围蔓延上。第 4-7 天技术选型。一个人做 App我的默认组合是前端React Native跨平台一套代码跑 iOS 和 Android或者 Flutter。如果只做 Android直接 Kotlin。后端如果不需要云端同步直接本地 SQLite如果需要用 Django DRF 或者 FastAPI。AI CodingWorkBuddy DeepSeek负责生成重复性代码和排查错误。热词里有“django创建app”说明很多人用 Django 做后端。我的建议是如果只是练手或者内部工具Django 的 admin 后台能省你很多时间如果是面向 C 端的 AppFastAPI 更轻量。第 8-15 天项目骨架搭建。在 WorkBuddy 里新建项目选择对应的模板。以 React Native FastAPI 为例WorkBuddy 会生成project/ ├── mobile/ # React Native 前端 ├── server/ # FastAPI 后端 ├── shared/ # 共享类型定义 └── workbuddy.json # 项目配置然后跑通“Hello World”级别的端到端流程前端发一个请求后端返回数据前端展示。这一步看起来简单但很多项目就是卡在“环境跑不起来”上。3.2 第 16-45 天核心功能开发与 AI Coding 实战这个阶段是重头戏我会把核心功能拆成若干个小任务每个任务用 AI Coding 辅助完成。第 16-25 天数据模型与本地存储。喝水记录 App 的核心数据模型很简单# server/models.py class WaterRecord(BaseModel): id: int amount_ml: int recorded_at: datetime前端用 SQLite 或者 AsyncStorage 存本地数据。这里有个坑React Native 的 AsyncStorage 是异步的如果你在组件挂载时直接读可能读到空值。我的做法是封装一个useStoragehook统一处理加载状态。第 26-35 天记录与列表功能。用 WorkBuddy 的 AI Coding 生成基础 CRUD 代码然后手动调整 UI。DeepSeek 生成的 React Native 代码质量还不错但样式部分通常需要自己改。我的经验是让 AI 生成逻辑自己写样式这样效率最高。第 36-45 天统计与提醒。统计功能用 SQL 的GROUP BY按天汇总提醒功能用react-native-push-notification。这里要注意 iOS 和 Android 的权限申请差异AI 生成的代码往往只覆盖一个平台。常见问题DeepSeek 生成的代码有时会引用不存在的库或者过时的 API。我的排查方法是先看 import 语句再去官方文档确认版本兼容性。WorkBuddy 的依赖检查功能可以帮你发现一部分问题但不能全指望它。3.3 第 46-70 天联调、测试与性能优化第 46-55 天端到端联调。前端和后端分开开发时接口对不上是常态。我的做法是先用 OpenAPI 或者 TypeScript 类型定义把接口契约固定下来前后端都按这个契约写。WorkBuddy 支持从后端代码自动生成前端类型定义这个功能省了我很多时间。第 56-65 天测试。一个人做项目测试要抓重点单元测试核心逻辑统计算法、数据校验必须覆盖。集成测试前后端接口联调用 Postman 或者 pytest 跑一遍。手动测试在真机上跑一遍完整流程尤其是权限申请、通知、后台切换这些场景。第 66-70 天性能优化。喝水记录 App 的性能瓶颈通常在列表渲染和数据库查询。列表用FlatList的keyExtractor和getItemLayout优化数据库加索引。这些优化 AI 不一定主动帮你做需要你自己判断。3.4 第 71-90 天打包、上线与迭代准备第 71-80 天打包。React Native 用react-native bundle打包Android 生成 APK 或者 AABiOS 需要 Xcode 归档。这里最大的坑是签名和证书尤其是 iOS。我的建议是提前一周开始搞证书不要等到最后一天。第 81-85 天上线。Google Play 和 App Store 的审核规则不一样。Google Play 相对宽松App Store 对隐私政策和权限说明要求严格。提前准备好隐私政策页面和权限使用说明。第 86-90 天迭代准备。上线不是终点。我会在这个阶段做好三件事埋点记录用户行为知道哪些功能用得多。崩溃监控接入 Sentry 或者 Firebase Crashlytics。反馈渠道在 App 里留一个反馈入口或者用问卷收集。4. 实操中最容易翻车的五个环节4.1 缓存目录混乱导致项目跑不起来WorkBuddy 的缓存目录默认在~/.workbuddy/cache如果你同时跑多个项目依赖版本冲突是大概率事件。我的做法是每个项目在workbuddy.json里指定独立的缓存路径{ cacheDir: ./.workbuddy-cache, model: deepseek, contextFiles: [server/models.py, mobile/src/types.ts] }这样每个项目的缓存隔离切换项目时不会互相干扰。热词里有“workbuddy缓存目录怎么更改”说明这个问题很普遍。4.2 AI 生成的代码“看起来对跑起来错”DeepSeek 生成的代码有个特点结构很漂亮但细节容易出错。比如生成一个 React Native 组件它可能会用useEffect但忘记加依赖数组导致无限循环。我的排查流程是先看控制台报错定位到具体文件和行号。检查 import 的库是否存在、版本是否兼容。检查异步逻辑是否有竞态条件。如果还找不到把相关代码片段贴回 WorkBuddy 让 AI 自己分析。实操心得不要盲目信任 AI 生成的代码尤其是涉及生命周期、异步、权限的部分。我一般会让 AI 生成后自己再过一遍重点看边界条件。4.3 需求蔓延导致 90 天变 180 天这是 FDE 最常犯的错误。客户说“能不能加个社交分享”你觉得“就加一个按钮的事”结果分享要涉及用户系统、图片生成、第三方 SDK 集成一周就没了。我的应对策略是所有新需求先记录不立刻做。评估影响如果超过 2 天工作量放到下一版。和客户确认优先级是必须现在做还是可以等。4.4 上线前的证书和签名问题iOS 证书、Android 签名、推送证书这三样东西任何一个出问题都上不了线。我的检查清单检查项iOSAndroid签名证书有效期、私钥备份keystore 文件、密码推送证书APNs 证书或 KeyFCM 配置隐私政策App Store 必须Google Play 必须权限说明每个权限都要有用途描述同上4.5 上线后没人用怎么办技术上线只是第一步获客是另一回事。我的建议是上线前就想好前 100 个用户从哪来朋友圈、相关社群、垂直论坛。不要指望应用商店的自然流量那需要 ASO 和推广预算。5. 工具链与效率提升的实战配置5.1 WorkBuddy 与 DeepSeek 的联动配置在 WorkBuddy 里配置 DeepSeek 作为默认模型需要在设置里填入 API Key 和模型名称。我的配置如下{ aiProvider: deepseek, model: deepseek-coder, maxTokens: 4096, temperature: 0.3, contextWindow: 32000 }temperature设 0.3 是为了让代码生成更稳定不要太高。contextWindow根据项目大小调整太大浪费 token太小 AI 会忘上下文。5.2 用 AI Coding 生成重复性代码的正确姿势AI Coding 最擅长的是“有明确模式的重复代码”。比如CRUD 接口数据模型定义单元测试模板样式文件我的做法是先手写一个“样板”然后让 AI 照着样板生成其他类似的。这样比直接让 AI 从零生成准确率高很多。5.3 版本管理与回滚策略一个人做项目也要用 Git而且要有清晰的分支策略main稳定版随时可上线dev开发版日常提交feature/xxx新功能分支每次上线前打 tag出问题可以快速回滚。WorkBuddy 有 Git 集成但我建议还是用命令行更可控。6. 从 FDE 视角看 AI Coding 的边界与机会6.1 AI 能做什么不能做什么我用了大半年 AI Coding总结下来AI 擅长的生成模板代码、解释报错、写测试用例、重构简单函数、翻译代码逻辑。AI 不擅长的理解模糊需求、做架构决策、处理平台特定问题如 iOS 权限、优化性能瓶颈、保证代码安全。FDE 的价值就在于把 AI 擅长的部分交给 AI自己专注在 AI 做不了的地方。6.2 一个人做完整 App 的可行性以前一个人做 App 需要前端、后端、设计、测试、运维现在有了 AI Coding 和 WorkBuddy 这类工具一个人确实能跑通全流程。但前提是需求足够聚焦不贪多。技术栈足够熟悉不边学边做。有清晰的 90 天节奏不无限期拖延。我实测下来一个功能简单的工具类 App从零到上线90 天是可行的。但如果是社交、电商这类复杂应用一个人做会非常吃力。6.3 后续可以扩展的方向这个项目跑通后你可以往几个方向扩展多端适配从 React Native 扩展到 Web 端用同一套后端。云端同步加用户系统和云数据库支持多设备同步。AI 功能集成比如用 DeepSeek 做智能提醒根据用户习惯推荐喝水时间。自动化部署用 GitHub Actions 做 CI/CD提交代码自动打包。我个人在实际操作中的体会是不要一开始就想做“大而全”的东西。先把一个最小可用的版本跑上线拿到真实用户反馈再迭代。AI Coding 降低了写代码的门槛但没有降低做产品的门槛。需求判断、优先级排序、上线节奏这些还是得靠人。
