手工川从金融转行，2024 年底起 99% 的代码由 AI 完成。他总结出一套“先交付 59 分版本”的开发方法——一周做出 MVP，一个月稳定上线。在他看来，AI 降低编码门槛后，需求判断与产品能力才是真正的分水岭。
手工川的起点不是计算机实验室，而是投行的数据分析需求。本科读金融的他，在实习中发现需要处理大量数据抓取与分析工作，2017 年自学编程，随后彻底转向计算机领域。
转折发生在 2024 年底。基于 Claude Sonnet 3.5 的 Cursor 走红后，他系统测试了 AI 编程工具，发现生成代码的质量已经跨过临界点——不再是补全片段，而是能承担大部分编码任务。从那以后，他几乎不再手写代码。
但他并不认为技术基础可以跳过。恰恰相反，正是过去的工程经验让他敢于激进采用 Vibe Coding——他能判断 AI 生成的代码是否合理，能在出问题时定位方向，也能在 MVP 跑通后补上稳定性与测试。
手写代码 → 架构设计 → 完整测试 → 上线。周期长，前期投入大，验证需求慢。
快速出原型 → 验证需求 → 加固上线。AI 承担编码，人负责判断方向与质量兜底。
注：两种方式的本质区别在于“先验证还是先建造”。AI 大幅降低了试错成本，使得先跑通再加固成为可能。
手工川的开发方式以“快”为核心：向 AI 提出需求，直接生成，有问题再修。目标是尽快看到一个可运行的版本，而不是第一次就交付商业级产品。
他把开发分为两层：第一层是 MVP，核心目标是验证功能与需求是否真实；第二层是生产级加固——增加并发能力、自动化测试、异常处理，让产品逐渐达到上线标准。
注：59 分指“功能可跑通但还不完善”的状态，核心是快速验证，而非质量妥协。加固阶段再补上软件工程能力。
这套方法的优势在于反馈速度。很多想法在纸面上成立，做出原型后才发现没有价值。AI 帮助以极低成本验证想法——不行就停，行就加固。手工川还借用“乔哈里视窗”总结人机协作原则：开发者需要判断自己知道 AI 知道什么、AI 不知道什么，以及自己不知道 AI 知道什么、AI 不知道什么。
手工川不会把所有任务交给同一个模型，而是根据特长分工：
注：每个模型各有所长，手工川会同时使用多种 Agent，并额外配置中转服务接入不同模型。
多 Agent 协作最大的难点，不是模型能力，而是上下文如何在工具之间流动。如果一个 Agent 完成一半任务，交给另一个继续，后者必须获取完整的上下文。
在项目目录中使用 Agent.md 等文件，把目标、规则和架构写进去，让所有 Agent 共同读取。也可以把信息存入数据库、缓存或 README 文件，形成公共存储。
当上下文承载过多信息，模型反而无法判断优先级。手工川的解法：将已解决、未来还会重复出现的问题处理过程沉淀为 Skill，但注意——最终没有解决的就不要固化，说明原路径可能错误。
基于这些经验，他开发了 YODA——一个开源的多 Agent 统一工作台。核心能力包括：多 Agent 切换、便捷归档、归档前自动执行 Skill、Harness 透明化（侧边栏展示完整上下文），以及“在 App 中开发 App”的能力。
手工川的规划中，YODA 下一步还要补齐搜索优化、增长和运营能力，形成从需求到产品再到市场的一条龙流程——这可能构成 YODA 2.0 的形态。
AI 降低了编码门槛，但 需求、产品判断、传播能力 正在成为 Builder 真正的分水岭。一人公司不是目的，创造价值才是——未来最稀缺的，不是写代码的能力，而是进入真实场景、观察普通人如何生活的能力。
YODA 已开源，可在 GitHub 上获取。手工川的工作流与 Skill 体系也公开分享，适合希望提升 AI 开发效率的 Builder 参考。
YODA 开源地址 → 前往 GitHub手工川工作室：lovstudio.ai