从金融专业到资深Builder：我如何借多Agent开发工作流，一周做出MVP、一个月上线

随着 Vibe Coding 不断降低软件开发门槛，“人人都是开发者”开始从一句口号变成一种可被实践的可能：不具备完整工程背景的人，也可以借助 AI 完成产品原型；独立开发者则能够同时调度多个模型和 Agent，把过去需要团队完成的工作压缩到一个人身上。

但当写代码变得越来越容易，真正决定产品成败的问题反而更加突出：如何发现用户愿意付费的真实需求？怎样把一个想法快速做成最小可行产品？面对不同模型和 Agent，开发者应该如何选型、传递上下文并控制成本？一个人借助 AI 完成开发、运营和推广，是否真的意味着传统公司的组织形态将被取代？在 WAIC 2026 InfoQ 媒体直播间，我们与资深 Builder 手工川围绕这些话题进行了一系列讨论。

手工川从 2020 年大学毕业起持续构建各类产品，发布在自己的品牌网站手工川工作室 lovstudio.ai，并在推动一款面向开发者的开源产品 YODA。与很多从软件工程进入 AI Coding 的人不同，他本科读的是金融，之后因投行工作中的数据分析和抓取需求自学计算机，最终彻底转向了开发。从 2024 年 10 月开始，他几乎把所有编码工作交给 AI，“99% 的 AI + 1%的方向”。

在他看来，AI 确实正在让软件开发变成一种更普遍的基础能力，但“能够写出代码”并不意味着每个人都会成为专业开发者，更不意味着一个人只要学会调用模型就能做出有人使用、愿意付费的商业产品。相比技术，需求、产品判断、传播能力和个人定位，正在成为 Builder 更重要的分水岭。

从金融转向计算机，直到 99%的代码都由 AI 完成

手工川本科读的是金融专业。最初接触编程，并不是因为他准备成为软件工程师，而是因为金融工作本身需要处理大量数据。

在投行实习期间，除了完成传统的行业研究和财务分析，前辈和导师也希望实习生能够掌握数据分析、数据抓取等技术能力。为了完成这些工作，他开始自学计算机。大约在 2017 年，他逐渐发现，计算机比金融更加有趣，于是开始深入研究，最终彻底转向计算机领域。此后的时间里，他几乎每天都在思考怎样把代码写得更好。

当生成式 AI 开始进入编程领域时，他并没有立即把开发工作交给模型。尤其是在 2023 年和 2024 年上半年，他认为 AI 生成代码与自己的目标和质量要求之间仍然存在明显差距。模型可以生成片段、补全函数，却很难稳定地完成完整产品，生成结果也经常需要开发者进行大量返工。

真正的转折出现在 2024 年底。随着基于 Claude Sonnet 3.5 等模型的 Cursor 走红，，他开始系统测试 AI 编程工具。测试的结果让他意识到，模型生成代码的质量已经跨过了某个临界点，不再只是提高输入速度的补全工具，而是能够承担大部分实际编码任务的开发者。

从 2024 年 10 月开始，他逐渐停止手写代码。接近两年时间里，他几乎所有项目都由 AI 完成编码。“严格来说并非百分之百，但至少 99%的代码已经交给了模型和 Agent，人类只需要负责那起始与结束的 1%”。

这并不意味着技术基础失去价值。恰恰相反，手工川认为，自己能够如此激进地采用 Vibe Coding，正是因为此前积累了足够多的软件开发经验。他可以判断 AI 生成的代码是否合理，能够在出现问题时定位方向，也能在最小可行产品跑通以后，通过工程化手段补上稳定性、并发、测试和维护能力。

对于完全没有代码经验的人，AI 可以显著降低进入门槛，但不能自动补齐所有工程判断。普通用户首先需要学习的，不一定是某种编程语言，而是如何准确表达需求、如何与 AI 交流，以及如何判断模型是否真的完成了任务。

手工川认为，很多成功的 AI 产品看起来像是由“不懂代码的人”做出来的，但其背后通常仍然存在一位能够驾驭 AI、理解产品和技术边界的人。即使不亲自手写代码，至少也要知道怎样组织模型完成开发。

真正的需求不需要“抓”：爱生活的人更容易做出大众产品

“如何找到真实需求”几乎是所有独立开发者都要面对的问题。手工川的看法是：不会写代码的人，反而可能更接近真正的大众需求。

原因在于，程序员每天面对的是代码、框架、数据库和开发工具，能够想到的往往也是程序员自己的问题。但程序员通常动手能力很强，遇到问题会直接做一个脚本或者插件，很少愿意为同类工具付费。一个只服务程序员的需求，即使技术上很精巧，也未必具备足够大的商业市场。

不会写代码的人则离真实生活更近。他们会考虑去哪里旅行、怎样拍照、怎样做饭、怎样整理工作、怎样让日常生活变得更方便。这些问题看起来不够“技术”，却可能拥有更大的用户群体。

手工川认为，需求不一定要刻意通过调研“抓”出来。只要一个人认真生活，不断思考如何把自己的生活过得更好，真实需求自然会出现。真正困难的是，当需求出现以后，如何把它兑现为产品。

比如，他最近用 YODA 很短时间之内制作了一款视频拍摄工具。用户可以提前准备好文稿，在面对镜头录制时，系统会实时识别用户说到了哪一句，并自动对齐字幕（现有工具通常按照固定速度滚动提词）。录制完成后，可以直接获得一段字幕已经匹配的视频，不需要再花费大量时间手动调整。

手工川把产品展示给一位经常进行采访的朋友，对方当场表示：“我现在就给你转 100 元，你赶快把它上线。”在他看来，这种不需要解释商业价值、用户看到后马上愿意付费的反应，就是真需求。

类似的产品案例并不少见。妙鸭相机的走红同样体现了这一逻辑：用户只需要上传一张照片就可以生成不同风格的写真。小猫补光灯的产品实现并不困难，但光有技术并不行，因为这个 idea 来自于其创始人的女朋友。

所以，产品不必追求过于复杂的技术，谁能准确击中特定时期的生活痛点，谁也许就能迅速获得大量用户。脱离宏大的技术叙事，解决的问题甚至微不足道，但只要足够具体、足够真实、用户知道自己为什么需要它，用户便愿意为节省下来的时间和精力付费。

手工川把自己的需求方法总结为一句话：“爱生活的人，更容易发现大众需求。”AI 降低了实现门槛以后，最稀缺的不再只是开发能力，而是进入真实场景、观察普通人如何生活的能力。

先交付一个 59 分版本：一周做出 MVP，一个月稳定上线

具体到产品落地上，手工川倾向于采用渐进式 Vibe Coding，而不是在开发开始前完成一套庞大、严密的产品设计。

他通常会先向 AI 提出一个具体需求，让模型直接实现。出现问题以后，再告诉模型“这里有问题，修一下”；如果希望避免同类错误重复发生，则继续增加约束，要求模型以后不要再采取相同方案。

这种开发方式的目标不是第一次就生成商业级产品，而是尽快看到一个可以运行的版本。对于手工川来说，AI 先交付一个“59 分”的产品完全可以接受。只要基本方向成立，就可以根据真实效果决定是否继续投入。

这种方法最大的优势是反馈速度快。很多想法在纸面上看起来成立，真正做出原型以后却未必有价值。如果一开始就投入大量时间进行架构设计、技术选型和完整测试，可能一个月以后才发现，用户根本不需要这个产品。借助 AI，开发者可以先用极低成本验证想法：如果原型没有价值，及时停止；如果用户反应积极，再逐步补充软件工程能力。

手工川把产品开发大概分成两层：第一层是最小可行产品，也就是 MVP。这个阶段的核心目标是验证功能能不能跑通、需求是否真实；第二层是增加高并发能力、自动化测试、异常处理和稳定性设计，让产品逐渐达到生产要求。

而对于完全没有工程经验的普通用户，可能更希望 AI 直接交付一套“银弹式”解决方案：输入一句需求，模型就完成需求拆解、架构设计、编码、测试和部署。这种方法并非不可行，但开发速度可能更慢，需要模型在前期做更完整的规划。

对于能够理解代码并为结果兜底的开发者，先快后稳通常效率最高。如果产品对质量和准确性要求极高，则更适合采用规范驱动或测试驱动的方式。开发者先把需求写成详细规范，或者让 AI 先生成大量测试，再按照测试要求实现功能。

最终采用哪种范式，取决于用户的技术能力、产品阶段和风险要求。

在技术栈方面，手工川通常不会每个项目都重新选型，而是优先使用自己熟悉的组合：前端偏好 React，后端倾向 Python，界面会考虑 shadcn/ui，数据库通常选择 PostgreSQL 或 Supabase。他甚至会通过 MCP 把 Supabase 权限交给 AI，让 Agent 直接操作数据库。

这一选择同样来自 ROI 考虑。对于需要快速看到产品效果的 Builder，反复评估几十种框架的收益并不高。熟悉的技术栈便于 AI 生成，也方便后续人工理解和维护。

但如果市面上已经存在成熟的类似框架，他不会坚持从零开发，而是使用一个名为“解决方案架构师”的 Skill。这个 Skill 会先在 GitHub 上搜索相关开源项目，判断是否存在能够直接复用的架构。如果有，就优先基于现有方案开发；项目继续深入后，再让 AI 逐渐把代码迁移到自己更熟悉的框架。这样既利用了成熟项目快速启动，也避免长期维护一套完全陌生的技术体系。

在他看来，随着模型能力越来越强，Harness 会不断变薄。开发者不需要提前告诉 AI 所有架构细节，真正必须显式说明的是没有被模型内化的信息，例如企业红线、合规要求、禁止执行的操作，以及个人特殊偏好。

他借用“乔哈里视窗”总结了人和 AI 的协作原则：开发者需要判断自己知道 AI 知道什么、AI 不知道什么，以及自己不知道 AI 知道什么、AI 不知道什么。当开发者对某个问题的理解明显超过 AI 时，就应该主动而清晰地引导模型；当开发者自己并不熟悉相关领域时，反而应该保持一定模糊，让 AI 提出方案并引导人完成探索。

按照这套方式，他通常可以在一周内交付一个 MVP，并在一个月左右将产品相对稳定地上线。如果只是参考已有产品，更换 API、修改界面并适配新的公司需求，从一周到一个月基本可以由一个人完成。

不过，开发时间缩短并不意味着工作消失，手工川的大部分精力花在了调试上。AI 生成代码很快，但验证功能、定位异常、处理边缘情况和修正产品体验，占据了他的主要时间。

多 Agent 协作的难题不是模型，而是上下文流动

研发期间，手工川不会把所有任务交给同一个模型，而是根据不同模型的特点进行分工：

• 写文章时，更倾向于使用 Claude Code，因为 Claude 在发散、语言理解以及对人的意图理解方面表现更好；

• 遇到特别困难的代码 Bug 时，会调用 GPT 系列中能力最强的模型，并把思考深度调整到最高，让模型进行更充分的推理；

• 对于中文、诗词和国内特有场景，优先考虑国产模型。以 DeepSeek 为例，其早期模型在中文语言和文化内容方面投入较多，在部分中文任务中的表现可能优于海外模型。

• 获取最新海外信息时，Grok 由于能够接入 X 上的实时数据，更适合处理新闻和社交媒体内容。这种能力也可以通过爬虫和插件部分替代，但模型直接拥有数据入口时，体验仍然不同。

手工川会同时使用多种 Agent，并额外配置一两个能够接入不同模型的中转服务。当任务需要生成图片或调用特定模型时，再通过中转平台完成。他认为，多 Agent 协作最大的难点，是上下文如何在不同工具之间流动。

如果一个 Agent 完成了一半任务，再交给另一个 Agent 继续，后者必须获取前一段工作的完整上下文。以 Codex App 为例，用户可以复制某个任务的深链，再把链接交给另一个会话，让其基于原任务继续。因此，如果不同 Agent 分别负责同一产品的不同功能，则需要建立共享上下文。

一种方法是在项目目录中使用 Agent.md 等文件，把项目目标、规则和架构写进去，让所有 Agent 共同读取。另一种方法是把信息存入数据库、缓存、内存或 README 文件，形成一个文件级或数据级公共存储。这有点像软件系统中的跨进程通信，问题不在于某个 Agent 是否足够聪明，而在于它能否获得正确、完整且不过量的信息。

不同会话之间也存在类似问题。用户可以让 AI 查找过去聊天记录，并基于某段对话继续工作。只要 Agent 知道 Codex、Claude 等工具的本地存储位置，就可能读取历史记录。但如果重要信息只存在于某次对话中，没有形成项目文件或者长期记忆，切换会话后仍可能丢失。

手工川对此的建议是，可以将已解决、未来还会重复出现问题的处理过程沉淀为 Skill。下一次遇到同类任务，Agent 就知道如何查找信息、调用工具并完成处理。

但他提醒，并不是所有错误都适合写进 Skill。如果模型犯错后最终找到了解决方案，可以沉淀流程；如果最终仍然没有解决，说明原路径可能就是错误的，此时应该更换思路，而不是把错误流程固化下来。

即使规则已经写进 Skill 或者项目的“Agent.md”文件，模型仍然可能不遵守，这就是“上下文腐烂”：当上下文承载的信息过多，或者规则都被标记为重要，模型反而无法判断真正优先级。因此，AI 开发环境不仅需要增加上下文，也要能够管理、裁剪和调试上下文。

把 Codex、Claude Code 等不同 Agent 装进同一个工作台

作为一个 builder，手工川也将自己开发中遇到的问题和相关经验转化成了相关产品，即 YODA。

YODA 最初来自一个非常直接的需求：手工川发现，身边的重度开发者几乎不会只用一种 Agent，很多人同时使用 Codex 和 Claude Code，还会加入 Gemini、Grok 或 Kimi。他判断，未来一到两年内，同时使用多种 Agent 仍会是常态。既然如此，开发者就需要一个统一入口，可以在同一个产品中自由切换 Agent，而不是不断打开不同工具、复制文件和搬运上下文。基于这一思路，他找到一款开源工具并在其基础上进行了二次开发。

YODA 的第二个核心能力，来自独立开发者需要同时管理多个项目的工作方式。

手工川每天会创建大量需求，任务完成后再将其关闭。在这个过程中，他注意到 Codex 的任务归档体验比较顺畅，而 Claude Code 的归档入口则隐藏在二级菜单中。于是，他把 Codex 较为顺手的归档设计引入 YODA。

但使用一段时间后，他发现仅仅归档仍然不够。一个开发任务结束时，通常还需要整理代码、提交修改并推送到远程仓库。在传统工具中，用户需要先主动告诉 Agent 完成提交和推送，再手动归档任务。步骤并不复杂，却会打断工作流，长期使用时很难坚持。随后，YODA 增加了“归档前执行 Skill”的能力。用户点击归档后，系统可以在后台静默完成代码整理、提交和推送，再关闭任务，整个过程不再需要重复发出指令。

完成多 Agent 统一入口、便捷归档和自动收尾三个功能后，YODA 逐渐成为手工川自己无法离开的开发环境。他可以不断创建需求，让不同 Agent 执行，再自动完成归档前的整理工作。

此后，YODA 又增加了 Harness 透明化能力。在侧边栏中，用户可以看到当前项目实际加载的全部上下文，包括系统提示词、项目提示词、已经启用的 Skills、连接的 MCP，以及动态注入的 Prompt。用户发出一条指令后，可以清楚知道系统最终把哪些信息一起交给了模型，从而判断为什么模型忽略某条规则，或者哪部分上下文造成了冲突。

手工川还给 YODA 加入了动态 Prompt 机制，每一条规则都可以单独启用或关闭。手工川认为，今天有效的规则，未来可能随着模型能力升级而不再需要。Prompt 不应该只增不减，而应当根据任务动态调整。YODA 也有“在 App 中开发 App”的能力。用户可以直接在 YODA 内部构建一个子应用，完成后继续在 YODA 中使用，形成类似 App Store、Lovable 的 Builder 模式。

根据手工川的设想，YODA 下一步还要补齐搜索优化、增长和运营能力。未来，开发者不仅可以在产品中完成 App 开发，还可以自动进行曝光、推广、原型打版和运营，形成从需求到产品、再到市场的一条龙流程。这可能构成 YODA 2.0 的形态。

YODA 是开源的。手工川并不把直接收费视为唯一目标。随着 AI 大幅降低前端开发门槛，单纯依靠界面和功能形成长期壁垒越来越困难。他表示自己更关注的是，什么样的开发工具能够真正帮助用户做出高质量、商业级、解决现实问题的产品。而 YODA 更像一项带有长期探索性质的项目，希望不同开发者能够共同使用、修改和贡献。

为了提高自己的开发效率，手工川还形成了一套“独立分支开发、完成后自动合并”的方式。

过去，他直接在主分支上使用 YODA 开发 YODA 自身。AI 一边修改产品代码，正在运行的应用就会不断闪屏或崩溃。有时一次修改需要 10 分钟甚至一个小时，他只能暂时刷视频，等应用恢复后再继续。后来，他开始默认让 AI 在独立分支中完成任务，并在 Prompt 中规定：任务完成后自动合并回主分支。由于合并只是程序化操作，通常几秒钟即可完成；即使出现冲突，AI 也可以自动修复。

这套方式把原本长达数十分钟的不可用时间压缩到几秒钟。他还可以同时创建几十个甚至上百个需求，让 Agent 在不同分支中推进，再见缝插针地合并结果。

这类工作流带来的不仅是效率，也是一种强烈的即时反馈：提出需求，很快看到功能，再继续追加下一项任务，产品在持续的微小迭代中快速生长。

AI 最适合做原型，测试、成本和获客不会自动消失

手工川认为，AI 写代码最大的价值仍然集中在 0 到 1 阶段。它能够显著缩短从想法到原型的时间，让开发者在投入大量资源前，快速判断需求是否成立。从 1 到 10 的阶段，AI 同样可以发挥作用，例如补充测试用例、进行重构和修复 Bug，但产品规模扩大后出现的复杂问题，并不是 AI 带来的，而是软件工程本身就存在的问题。

真实软件永远有大量边缘情况，软件工程中因此存在条件测试、分支测试、逻辑测试、路径测试、黑盒测试和白盒测试等不同方法。无论是人还是 AI，都很难一次性想到全部场景。测试越完整，开发速度通常越慢，企业必须在质量和效率之间权衡。

因此，传统 Alpha 测试、Beta 测试和公测仍然不可替代。产品可以先交给 10 名内部用户测试，再扩展到 100 人、1000 人，最后开放公测。AI 可以帮助生成测试和执行验证，但不能彻底解决软件中无穷无尽的边缘问题。

在验证方式上，目前普通 Vibe Coding 用户仍以人工检查为主。一些工程师已经开始探索自动化验证，例如让 AI 直接在 Android 手机上运行产品、操作界面并判断结果。手工川也在开发相关框架，但这类方案目前技术门槛较高，尚未成为大众开发方式。

没有工程经验的人可以自己完成产品原型，但他建议原型验证有效以后，最好交给资深工程团队进一步完善。如果没有团队，只能更多依赖 Lovable 等封装较完整的平台，由平台提供数据库、用户系统和后端能力。否则，普通用户还需要自行配置阿里云、AWS、服务器、数据库和部署环境，复杂度会迅速上升。

这就意味着，AI 降低了写代码门槛，但并没有消除基础设施和运维门槛。

模型成本问题同样需要面对。手工川曾经在 Claude 账号被封后，使用 API 同时深度开发多个 App。由于习惯使用 Opus 等高阶模型，一天的 API 费用达到 200-300 美元，三天累计花费约 600 至 700 美元。

费用迅速增长后，他没有继续等待账号申诉，而是重新注册订阅账号。订阅套餐存在每 5 小时的额度限制，达到上限以后，他就暂时休息，相当于平台强制控制工作强度。

他身边也有创业者同时开设 5 个账号，轮流使用不同额度，让开发几乎不中断。但对普通超级个体而言，他认为没有必要准备如此夸张的模型预算。一个 Claude Max、Codex Max 或者 Kimi Max 账号，通常已经足够支持重度开发。

在他看来，Max 套餐本身就是按照资深工程师的日常使用强度测算的。如果一个人能够持续用完一个 Max 账号的全部额度，开发强度已经“及格”；特殊时期可以准备两个账号，但如果长期把两个账号全部打满，就应该考虑休息和劳逸结合。

相比开发成本，获客可能是更难的问题。手工川认为，AI 时代做产品仍然取决于生产和消费两端。开发者不仅需要把产品做出来，还要让用户知道它。

他建议 Builder 采用“Build+Influencer”的方式：左手做产品，右手做个人影响力。通过公众号、视频号、X 或 YouTube 公开分享开发过程，也就是 Build in Public。产品发布后，先观察市场反馈。如果用户没有任何反应，可能说明需求不够强；如果反馈积极，再增加投入。不同产品可以像赛马一样同时测试，不必因为个人情感执着于某一个想法。

手工川透露自己早期对个人 IP 较为抗拒，后来专攻知识型内容，长期坚持后内容价值和个人 IP 都会逐渐积累。

“但流量并不完全等于价值”手工川强调。他经历过用 AI 一分钟生成的文章获得大量阅读，而自己花一周写成的深度文章流量普通。前者可能吸引大众用户，后者却可能筛选出投资人、忠实用户和真正愿意思考的人。

一人公司不是目的，“人人都是开发者”的关键是找准定位

随着 AI 能够承担代码、文案、运营和部分私域管理工作，一人公司开始成为创业领域的热门概念。手工川也获得过 OPC 先锋人物相关评选，但他并不认为“一人公司”本身值得追求。

他引用科斯关于企业性质的讨论解释公司的形成：过去，在公司内部雇佣员工并进行长期协作，交易成本通常低于每次临时寻找外包。随着内部人员增加，公司逐渐形成。

AI 改变了这一成本结构。很多任务交给 AI 完成，可能比招聘一名员工更便宜。过去需要多个岗位分别承担的开发、写作、推广、私域管理和运营工作，现在可能由一个人调度多个 Agent 完成，于是企业规模不断缩小，最终出现 OPC。

但 OPC 不是第一性原理，创造价值才是。创业者不应该为了符合“一人公司”的潮流，拒绝所有合作和团队建设。如果一个人最适合独立完成产品，可以选择 OPC；如果更适合寻找几位同频伙伴、融资和发展，也没有必要强行保持单人状态。

超级个体之间也可以形成新的协作网络。一个人擅长开发，另一个人擅长财务、运营或销售，彼此补足后同样可以构成稳定组织。未来公司未必完全消失，但组织边界可能更加灵活。

另外，在国内经营 AI 公司仍然存在现实门槛，包括大模型备案、ICP 备案以及相关电信业务许可。早期，大模型备案主要由头部模型公司完成；现在创业者可以通过与云厂商合作、获得授权等方式解决部分问题，但对于个人而言，仍然存在合规和成本压力。

海外市场在某些环节更轻量，例如使用 Vercel 搭建网站并上线后，可能很快被 Google 收录；在国内，新产品获取搜索流量更加困难，竞价和渠道也有门槛。不过，国内市场的这些门槛也会形成壁垒。一旦创业者解决公司资质、备案、宣传和产品问题，就可能获得更稳定的竞争位置。本质上，国内和海外是两种不同打法。

对于“人人都是开发者”这句话，手工川认为，它会越来越接近现实，但必须区分“掌握基础能力”和“成为专业人士”。

“今天每个人多少理解一些微积分，却不会都自称数学家；每个人都可以写诗，却不会都成为诗人；每个人也可以谈哲学，但不会都成为哲学家。软件开发未来也会如此。每个人可能都会用 AI 写一点代码，把自己的想法变成小工具，但这不意味着所有人都能承担大型系统设计、质量控制和长期维护。”手工川说道。

手工川并不建议其他人照搬自己的经历。他认为，比模仿某个 Builder 更重要的，是找到真正热爱的方向，让产品承载个人想法以及希望解决的问题。同时，还要让自己处在有利于创造的环境中，与重视技术、产品和生产力的人建立连接。好的环境会带来信息、合作和反馈，让许多机会自然发生。

他的建议是：降低自己的期望，但不要降低自己的努力。不要期待一个想法立刻成为爆款，也不要因为短期没有结果而停止行动。而更重要的是找到自己的定位。“一个人可能更擅长与人建立关系，而不是研究代码。此时没有必要强迫自己完成所有开发工作，可以寻找擅长技术的伙伴，让软件能力变成自己手中的‘画笔’。”