从金融转编程，如今99% 的代码交给 AI。手工川借助多 Agent 工作流，将过去需要团队完成的产品开发压缩到一人一周。他相信，AI 降低的是编码门槛，而真正稀缺的是需求判断与产品定位的能力。
手工川本科读的是金融专业。最初接触编程，并不是因为想成为软件工程师，而是因为在投行实习期间，需要处理大量数据分析和抓取工作。大约在 2017 年，他逐渐发现计算机比金融更有趣，于是彻底转向了开发领域。
此后的时间里，他几乎每天都在思考怎样把代码写得更好。但即使生成式 AI 开始进入编程领域，他也并没有立即把开发工作交给模型——2023 年到 2024 年上半年，他认为 AI 生成代码与自己的质量要求之间仍有明显差距。
随着基于 Claude Sonnet 3.5 等模型的 Cursor 走红，他开始系统测试 AI 编程工具。结果让他意识到：模型生成代码的质量已经跨过了某个临界点——不再只是补全工具，而是能承担大部分实际编码任务的开发者。
从 2024 年 10 月开始，他逐渐停止手写代码。接近两年时间里，几乎所有项目都由 AI 完成编码。
AI 生成代码需要大量返工，自己手写仍是主力。模型可以补全函数，但很难稳定完成完整产品。
99% 代码交给 AI，人类只负责那 "起始与结束的 1%"——方向判断、需求定义与最终验收。
注：手工川强调，自己能够如此激进地采用 Vibe Coding，正是因为此前积累了足够多的软件开发经验——可以判断 AI 生成的代码是否合理，能在出现问题时定位方向。
因投行数据工作自学编程，发现计算机比金融更有趣
大学毕业，持续构建各类产品，创立手工川工作室 lovstudio.ai
开始系统使用 AI 编码，逐渐停止手写代码
99% 代码由 AI 完成，推动开源项目 YODA，形成多 Agent 开发工作流
手工川的产品方法论非常直接：不要追求第一次就生成商业级产品。先让 AI 交付一个 "59 分" 的版本——只要基本方向成立，就可以根据真实效果决定是否继续投入。
他通常会先向 AI 提出一个具体需求，让模型直接实现。出现问题后，再告诉模型"这里有问题，修一下"；如果希望避免同类错误重复发生，则继续增加约束。这种开发方式的目标不是完美，而是尽快看到一个可以运行的版本。
按照这套方式，他通常可以在一周内交付一个 MVP，并在一个月左右将产品相对稳定地上线。如果只是参考已有产品，更换 API、修改界面并适配新的需求，从一周到一个月基本可以由一个人完成。
注：开发时间缩短并不意味着工作消失——AI 生成代码很快，但验证功能、定位异常、处理边缘情况和修正产品体验，仍然占据开发者的主要时间。
手工川不会把所有任务交给同一个模型，而是根据不同模型的特点进行分工。他同时使用多种 Agent，并额外配置中转服务以接入不同模型。
如果一个 Agent 完成了一半任务，再交给另一个 Agent 继续，后者必须获取前一段工作的完整上下文。手工川的应对方式包括：在项目目录中使用 Agent.md 文件，把项目目标、规则和架构写进去，让所有 Agent 共同读取；或者把信息存入数据库、缓存、内存或 README 文件，形成文件级公共存储。
他还将已解决的、未来会重复出现的问题处理过程沉淀为 Skill。但提醒：并不是所有错误都适合写进 Skill——如果模型最终仍然没有解决，说明原路径可能就是错误的，应该更换思路，而不是把错误流程固化下来。
注：即使规则已经写进 Skill 或 Agent.md，模型仍然可能不遵守——这就是"上下文腐烂"。当上下文承载的信息过多，模型反而无法判断真正优先级。AI 开发环境不仅需要增加上下文，也要能够管理、裁剪和调试上下文。
手工川发现，身边的重度开发者几乎不会只用一种 Agent。他判断，未来一到两年内，同时使用多种 Agent 仍会是常态。基于这一需求，他找到一款开源工具并进行二次开发，最终形成了 YODA。
在同一个产品中自由切换 Codex、Claude Code、Gemini、Grok、Kimi 等 Agent，不再反复打开不同工具、复制文件和搬运上下文。
点击归档后，系统在后台静默完成代码整理、提交和推送，再关闭任务。整个过程不再需要重复发出指令，工作流不被打断。
侧边栏展示当前项目实际加载的全部上下文：系统提示词、项目提示词、已启用的 Skills、连接的 MCP 以及动态注入的 Prompt。用户清楚知道模型收到了哪些信息。
直接在 YODA 内部构建子应用，完成后继续在 YODA 中使用，形成类似 App Store、Lovable 的 Builder 模式。YODA 2.0 还将补齐搜索优化、增长和运营能力。
YODA 已开源。手工川并不把直接收费视为唯一目标——随着 AI 大幅降低前端开发门槛，单纯依靠界面和功能形成长期壁垒越来越困难。他更关注的是：什么样的开发工具能真正帮助用户做出高质量、商业级、解决现实问题的产品。
注：YODA 还引入了"独立分支开发、完成后自动合并"的工作流——AI 在独立分支中修改代码，完成后自动合并回主分支，将长达数十分钟的不可用时间压缩到几秒钟。
手工川曾经在 Claude 账号被封后，使用 API 同时深度开发多个 App。由于习惯使用 Opus 等高阶模型，一天的 API 费用达到 200-300 美元，三天累计约 600-700 美元。
注：费用基于 Opus 等高阶模型的重度使用场景。手工川认为，一个 Claude Max 或 Codex Max 账号通常已足够支持重度开发；如果长期把两个账号全部打满，就该考虑休息了。
相比开发成本，获客可能是更难的问题。手工川建议 Builder 采用 "Build + Influencer" 的方式：左手做产品，右手做个人影响力。通过公众号、视频号、X 或 YouTube 公开分享开发过程（Build in Public），产品发布后先观察市场反馈。
手工川还提醒，在国内经营 AI 公司仍然存在现实门槛：大模型备案、ICP 备案及相关电信业务许可。早期主要由头部模型公司完成备案，现在创业者可以通过与云厂商合作、获得授权等方式解决部分问题，但对于个人而言，合规和成本压力仍然存在。
没有工程经验的人可以自己完成产品原型，但原型验证有效以后，最好交给资深工程团队进一步完善。否则，普通用户还需要自行配置云服务器、数据库和部署环境，复杂度会迅速上升。
AI 正在让"人人都是开发者"从口号走向现实，但必须区分"掌握基础能力"和"成为专业人士"。当每个人都能用 AI 写代码时，真正稀缺的不再是编码技能，而是知道"该写什么"的需求洞察力、判断产品方向的直觉，以及为结果兜底的工程责任。未来一到两年内，同时使用多种 Agent 仍会是常态——不是模型不够强，而是不同模型的长板仍然不同。能管理好上下文流动的人，才能管理好 AI 时代的开发流程。
YODA 已开源，可在 GitHub 社区获取。手工川的全部开发方法论与工具链均已公开，适合希望构建多 Agent 工作流的开发者参考。