从金融专业到资深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 提出方案并引导人完成探索。 按照这套方式，他通常