# 前微软x字节工程师王启源：独立开发中人机协作比例已反转至机器99%人1%

- 来源：向阳乔木 (@vista8)
- 发布时间：2026-07-04 23:08
- AIHOT 分数：70
- AIHOT 链接：https://aihot.virxact.com/items/cmr6is4mu03b9slf0lv1cxbls
- 原文链接：https://x.com/vista8/status/2073423638003408970

## AI 摘要

前微软Azure ML及字节AI Copilot核心开发者王启源在直播中分享独立开发经验。他称大厂规范流程是双刃剑，既保护项目也拖慢速度。过去一年人机协作比例从人60%机器40%反转至近三个月机器99%人1%。主力工具包括Claude Code（短平快任务）、Codex（长程探索）和GLM 5.2（简单任务）。他对好Harness的定义是用最少token达到模型能力上限，并指出Loop Engineering本质是Harness的一部分。人类保留的1%集中在架构设计、Debug和产品方向把控。

## 正文

http://x.com/i/article/2073423473985134592

# 前微软x字节工程师转型独立开发：大厂那套方法论，出来后反而没用

今天邀请我的前同事、好友王启源参加「未来硅世界」第十八期的直播。

直播回放在这里：

> https://waytoagi.feishu.cn/minutes/obcnmd5jbdj54q46193458vu

让 Claude Sonnet 5 写了总结：

他说当时没看懂 OpenAI

启源在微软 Azure 机器学习平台工作的时候，曾服务过两个大客户：波音和星巴克。

还有一个不起眼的小客户，做了一个模型，叫 GPT-3。

"我们当时还试用过，觉得，唉，这个东西有什么用呢？好像也没有什么用处。"

后面的故事大家都知道了。

这个细节来自一场深夜直播。

嘉宾启源，前微软 Azure ML 工程师，前字节 AI Copilot 产品的核心开发者，现在是一名独立开发者。

## 大厂的规范性，是同一枚硬币的两面

问启源大厂经历对独立开发最大的帮助是什么，他的回答很干脆：规范的研发流程。

哪些事该做，哪些不该做，一个产品怎么从 0 到 1 走完整套流程，这套方法论能帮你避开很多小白坑。

反过来问最没用的是什么，答案还是它。

很多人离开大厂后会陷入一个误区：想在没有配套团队和基础设施的情况下，重新发明一套大厂的轮子。审批流程、上线规范、各种检查清单，这些东西在大厂里是保险丝，出了大厂反而成了自己捆住自己的绳子。

同一套东西，是硬币的两面。

关键不是要不要流程，而是分清楚哪部分在保护你，哪部分只是让你慢下来。

## 日本，一个活化石博物馆

启源做过不少日本企业的 AI 咨询项目，他形容日本的 IT 市场像一个活化石博物馆：同一个国家里，能找到上世纪六七十年代还在运行维护的银行系统，也能找到最前沿的大模型应用。

具体到项目上，他给一家日本电商做推荐算法，做千人千面的个性化推荐。

这件事国内十几年前淘宝就玩得很成熟了，对方公司现在才刚开始做。

但与此同时，他又在同一批客户里做 AI Agent 项目，帮客户自动分析电商数据、优化广告投放，这个方向国内大厂也还在探索期。

严格来说，这算不上技术落后，更像是一种奇特的共存：老项目没人愿意扔掉继续跑着，新项目也在同步推进。

国内一旦有更好的技术栈，几乎是集体切换，很少有人守着十年前的方案不动。

## 一个被放弃的项目：产品能力的天花板长什么样

启源在字节时有个想法：做一个 AI 生成动漫短剧的工具。

最初是从个人爱好出发，他喜欢看漫画，想让 AI 根据自己喜欢的小说自动生成漫画。

想法一步步膨胀：有了漫画，为什么不做视频？需求越加越多，最后超出了他对产品的掌控能力。

背后有两层原因，值得拆开看。

第一层是精力问题。

这半年 AI 视频赛道太卷，新工具几乎每天都在冒出来，注意力很容易被带走，很难专注做好最初想做的那件事。

这个困境不是新鲜事，《人月神话》上世纪八九十年代就写过：想做一个大而全的工具，往往越做越难完成。

放到 AI 时代，同样的剧本又演了一遍。

第二层更本质：他和合伙人都不是这个赛道最痛的那个人。

启源的初心是想看自己喜欢的动漫内容，但 AI 漫、AI 剧的产能已经很大，脑洞也够多，他更多是消费者心态而非创作者心态，做出来的东西自己都过不了自己那关。

他提到一本书《Rework》（中文叫《重来》），里面有个观点叫先自挠其痒：做事情要先能挠到自己身上真实存在的痒处，解决自己的问题，再考虑做大做强。

与其想象一个"别人可能会怎么用"的完美产品，不如聚焦眼前能立刻解决的小工具。

## 一年时间，人机分工比例是怎么反转的

问起过去一年常用工具的变化，启源给出一条清晰时间线：

一年前主力 ChatGPT 和 Cursor，人机比例大概是人 60% 机器 40%，AI 写完代码人要认真 Review 一遍才决定要不要用。

半年前更多用 Claude Claude，比例反转到人 40% 机器 60%。

近三个月，基本是机器 99% 人 1%。

最近一个月，量大管饱的 GLM 5.2（Z Code）也进了常用工具列表，主要处理相对简单的任务，省着主力工具的额度。

留下的 1% 到底是什么？架构设计、Debug 思路，还有最关键的一点：产品方向的把控。

他举了个具体例子。

他最近在研究 C.elegans（秀丽隐杆线虫）的神经网络模拟项目，这是脑神经科学领域很早就有的研究，科学家分析过这种小蠕虫全部的神经连接图谱（connectome）。

启源想在计算机里训练出这种虫子的趋光性，让 AI 搭建框架的时候，AI 为了用最小成本完成任务，倾向于直接跳过神经元之间端到端的物理模拟，给出一个数学近似结果。

但这不是启源想要的，他想探索的正是神经突触之间具体是怎么连接的。

这时候人的作用，就是不停地把 AI 拉回正确的方向。

这里有个洞察：人和 AI 都有用最小成本完成任务的本能，区别在于人有目标，而 AI 不知道你脑子里那部分没说出口的上下文。

这 1% 的价值，正是替 AI 补上这块认知空白。

至于 小龙虾、Hermes这类产品，启源用得不多，他把它定位成个人助手而非 Coding 工具，适合处理规律性的日常事务，而他的大部分工作都是和代码打交道，Claude Code 和 Codex 基本能覆盖 90% 以上的需求。

## 从 Chat Coding 到 Loop Engineering，本质是什么在增强

Vibe coding、spec coding、harness、loop engineering，AI领域新词太多，很容易让人头晕。

启源给了个简洁框架：

背后是两条曲线同时在涨：模型能力在增强，人对 AI 协作的工程认知也在增强。

具体演化路径：

- Chat Coding：人和 AI 对话，AI 给代码片段，人手动粘贴进项目里，只能做没界面的小脚本，比如一键清理桌面

- Vibe Coding：AI 能生成完整界面，但没什么美感，人还得懂前后端怎么连接

- Spec Coding：把想法写成足够清晰的文档交给 AI，能实现六七成，效果完全取决于 spec 写得好不好

- Harness：几句话就能做出一个 MVP，界面美感也在线，不再依赖详细 spec，靠给 AI 足够的上下文和脚手架去做长程探索

- Loop Engineering：本质上是 Harness 的一部分，更强调对目标的持续追寻，保证长程任务不跑偏

启源直言，Loop Engineering 这个词最近比较火，但本质上还是 Harness 的一部分，强调的是循环加目标校验这个具体技巧，没有新的范式。

未来会怎样？

如果这个理念继续演化，人可能只需要提出问题和边界条件，AI 就能给出经过深思熟虑的探索结果，不需要人补充太多隐性上下文。

这基本上就是 vibe coding 理念走到尽头的样子，某种意义上的人机共生。

## 什么是好的 Harness，以及 AgentOS 的未来

启源对好 Harness 的定义很朴素：用尽可能少的 token，尽可能高的利用率，达到模型能力的上限，而不是拖累它。

他举了个反例，某些小龙虾类 Agent 产品消耗的 token 特别多，说明对 token 的有效利用率不高。

再往下看，Harness 会怎么演化成 AgentOS？

启源的类比很有意思：大模型从诞生第一天起，工作方式就很像一台操作系统。

上下文窗口对应 CPU 能处理的数据量，模型推理对应计算过程，记忆系统对应存储系统。

所谓 AgentOS，不是要吃掉 Harness，而是 Harness 这条演化路径走到极致的样子，上下文管理和操作系统管理虚拟内存，底层逻辑是相通的。

## 实战工作流：两个官方工具互相 Review

启源目前主力两个工具是 Claude Code 和 Codex：

长程、探索性任务用 Codex，日常短平快任务用 Claude Code。

原因是 Claude Code 在复杂长程任务里容易取巧，还会过度自信。

他举了个具体例子：做反汇编还原二进制代码这类硬骨头任务时，Claude Code 经常会说"这个做不了，那个符号找不到，我们换个方法吧"，而 Codex 会像老黄牛一样一点点尝试各种办法往下啃。

但对于日常写个 feature 这种短平快任务，Claude Code 的执行力反而更好。

另一位嘉宾向阳乔木补充了他观察到的 Codex 的问题：

写长篇小说这种长上下文任务时，Codex 会明显偷懒；做表单卡片类内容多的任务，会填充一些看起来完整但实际空洞无意义的内容。

这也是为什么多模型互相监督、互相迭代改进很有必要。

具体工作流举例：做编译器项目时，用 Claude Code 写代码、聊设计，同时让 Codex 去 review 结果、补单元测试，两边互相校验。

向阳乔木补充了一个特别实用的建议：买一个 VPS 和一个域名，自己搭一套 Harness 框架。

域名绑定 Cloudflare 后有域名管理 API，可以让 AI 自动完成域名解析配置。

另外 VPS 本身是 Linux 服务器，天然支持 AI 最熟悉的命令行操作，支持 SSH 登录后做大量部署工作。

以前觉得自己不懂运维就没法独立部署网站，现在这套流程可以完全交给 AI 来做。

成本也不高，域名和 VPS 加起来一年也没多少钱。

现场还演示了实际效果：一句话让 AI 在半小时内生成一个 Skill 推荐网站，27 分钟做出一个播客索引网站。

整个流程就是告诉 AI 要做什么网站、用什么域名、抓取哪些数据源、用什么方式部署，剩下的全部交给 AI 完成。

关于工具互调：Codex 可以调用 Claude Code，官方双方都做了插件支持，如果不会配置，直接让 AI 帮你写一个 MCP 来实现调用也完全可行，不局限于这两个工具，GLM 等其他模型同样可以这样接入。

## 学习方法论：深度靠品味，广度靠不脱离人民群众

启源的学习心法分两部分。

深度上，要培养对知识的判断品味。

很多领域你没跨过门槛就觉得枯燥无聊，其实是没找到正确的入口，好的文章和作者能帮你跨过那道门槛。

有了这个 Sense（感觉） 之后，刷社交媒体、看文章都会带着自己的筛选标准去看。

广度上，不能脱离人民群众太远。

程序员这个群体接触的社会面天然比较窄。

AI 出现之前，他会专门注册不同的社交账号，给自己设定人设，比如外卖小哥、中年大叔、宝妈，定向点赞相应内容，训练推荐算法的偏好，借此看到更完整的社会图景。

AI 时代最大的变化是：以前很多想了很久也没结论的问题，现在能快速和 AI 讨论出结果，省下大量时间。

他举了两个生活化的例子：

- 一个是研究了很久的 C.elegans 神经网络课题，现在可以直接和 AI 一起推进

- 另一个是女朋友想吃咖喱，以前要自己搜索不同流派咖喱的成分比例，现在跟 AI 聊几句就能梳理清楚。

向阳乔木补充了一个获取一手信息的方法论，来自万维纲和好友祥叔：

- 创作消费比：一本书作者花一两年写出来，读者几天看完，这个信息密度值得优先利用。论文也是同理，别人做了大量实验，你半小时能 get 到核心要点

- 看聪明人周末在研究什么：Anthropic 这类公司的员工会把自己的工程实践写成文章分享出来，认真看这些内容，能比业界早一年理解到 MCP、Skills 这些概念是怎么诞生的

- 找专家深度交流：没有直接渠道的话，优质播客是不错的替代品，国内推荐42章经、张小珺这类节目。

直播里还提到一个观众提的问题：他有位博导朋友说，AI 不用学，直接对话就行了。

启源和向阳乔木的回应很实在：如果你自己本身有立场、有审美判断力、有质疑能力，确实可以直接对话解决问题。但如果这个根基不够扎实，学一下 prompt 和基础的 AI 原理，能让你更快建立起对 AI 能力边界的认知。

这不是学不学的问题，是有没有判断力打底的问题。

向阳乔木还提到自己去年花了大量时间研究 prompt，直到现在写 skill 都很受益，因为 skill 很多时候就是 prompt 加工程组合加脚本，三者缺一不可。

## 非工程师玩 vibe coding，最容易漏掉什么

有观众问：普通人觉得自己能 vibe coding 了，真正上线一个产品最容易被忽视的是什么？

启源的答案落在工程能力上，具体说是二八定律：20% 的代码完成 80% 的核心需求，剩下 80% 的代码在处理你平时看不见的部分，比如用户登录态的 Cookie 管理、数据校验、并发处理、财务相关的稳定性。

一个网站要能注册用户，插一条数据库记录可能不到 30 行代码。

但围绕用户登录态展开的一整套逻辑，才是真正的工程量所在。

这些东西自己用没问题，一旦要给陌生人用，就是能不能真正上线的分水岭。

普通人最大的限制，是不知道自己不知道什么。

好消息是不知道不代表学不会，遇到问题随时可以问 AI，让 AI 告诉你该补哪块知识，这个学习成本已经被大幅拉低了。

反过来，给非工程师的建议是：把自己的 Domain knowledge（专业知识） 发挥到最大。

启源举了个例子，一位摄影师用 Vibe coding 做了个胶片自动去色罩的工具，这种细分需求恰恰是程序员想不到的，因为色罩这个概念只有真正玩胶片的人才懂。

这就是非工程师相对于工程师的优势所在，你的专业背景和生活经验才是最值钱的部分。

有观众提到现在很多低代码平台（比如秒哒）已经把登录、收费系统这些工程细节都包好了，是不是就不用学工程能力了？

启源的回答很中肯：如果平台能力覆盖你的需求，那当然是最好的选择，不需要重复造轮子。

但边界在于，一旦你的项目复杂到平台脚手架搞不定，还是要回到工程能力这个底层问题上来。

## 软件公司会崩吗：答案藏在"社会必要劳动时间"里

传统按 License 收费的 SaaS 公司，启源认为大概率会崩溃，理由：开源复制的速度太快了。

他举了个真实例子，一个叫 Vibe Island 的效率小工具本来卖 60 块钱，没过多久市面上就出现了免费开源版本。

但软件行业本身不会消失，因为定价的本质不是需求本身，而是社会必要劳动时间。

哪怕现在有 AI 辅助，如果做出一个东西依然需要三个月到半年的持续投入，或者烧 token 的成本本身就不低，这个产品依然有付费价值，因为大部分人没时间也没意愿自己复现这个成本。

开源本身只是商业模式的一种，不是目的本身。

启源举了个具体例子：终端工具 cmux，基础功能全部开源免费，但手机远程控制这个进阶功能需要按月订阅付费。

类似的还有 Linux 系统本身免费，但企业要买 Red Hat 或 Ubuntu 的服务支持才能获得靠谱的售后。

这种"基础免费加增值收费"或者"基础免费加维护服务收费"的模式，在软件领域相当常见。

## AI 对话怎么整理，有没有必要

日常和 AI 聊出来的洞察太多，怎么归纳？

多个嘉宾态度很一致：没必要事无巨细地整理。

启源的解释是，AI 对话整理本质上是一个信息压缩的过程，而目前最好的压缩工具就是人脑，真正重要的知识你会反复搜索反复回看，自然就留在脑子里了，日常对话大部分价值没那么高，不值得费心去记。

向阳乔木提到一个更具体的做法，来自一位朋友 TW93：让 Codex 定期整理自己最近几周的对话记录，提炼出自己的偏好，固化进 skill 库里。

比如你多次提到不喜欢某种配色，这些其实是你自己的隐性经验，值得让 AI 提炼出来变成长期记忆，而不是当成普通对话一划而过。

主持人元子分享了自己更系统的做法：用 Gemini 处理长会议内容，配置好模板化的提示词一键插入，聊完后用另一个工具把内容拆成 Markdown 卡片导入 Obsidian，方便后续检索。

她还特别提到只导出自己提出的问题，不关心 AI 回答了什么，因为复盘的核心是搞清楚自己到底在问什么。

她甚至把每天的时间日志、情绪状态都记录下来喂给 AI，让 AI 持续做自我画像更新。

核心逻辑是：人的记忆会骗人，只有用客观事实做迭代依据才靠谱，这个方法论她把它用到了时间管理等各个方面。

## 怎么开发一个 Skill，别只讲理念

有观众提了个具体问题：只看方法论文章，还是不知道该怎么下手写 Skill。

向阳乔木分享了自己的真实心路历程：官方文档一开始看着挺复杂，要写 Markdown 文档，还要描述执行细节和脚本，后来发现官方有个 Skill Creator 工具能帮你创建。

但用多了会发现官方工具不够完善，所以他和姚老师各自写了自己的 Skill Creator，加上了稳定触发的判断、约束条件校验这些细节，并且都开源在 GitHub 上。

具体流程是：先用自己的元 Skill（Skill Creator）去创作新 Skill，再用一个专门写好的分享 Skill 去发布 Skill。

但 Skill 只是第一步，因为大部分内容是 AI 写的，还要不断实测、发现执行问题、让 AI 自己反思迭代。

他还分享了一个测评方法：为了对比不同前端设计 Skill 的效果，他让 AI 抓取全网最火的前端设计 Skill，用多个任务用 Subagent 分别跑一遍，把不用 Skill、用官方 Skill、用 Taste skill、用 impeccable skill 的结果放在一起对比，挑一个或多个最满意的 Skill 作为迭代起点，开发自己的 Skill。

有观众进一步追问：本地 Skill 在 Codex 里跑得很好，但迁移到公司内部或者线上平台给别人用时，思维方式和执行结果都变得不太一样，该怎么办？

向阳乔木的回答：这是因为线上环境的模型、系统提示词、已安装的工具都跟本地不一样，结果自然会有差异，这属于目前行业基建还没跟上的问题，腾讯、字节等大厂都在做 Agent 托管基建方案。

## 几个容易被忽略的实用细节

直播里还聊到几个具体但很实用的信息：

关于注册域名：如果面向国内用户开发的网站，不建议选 .ai 后缀，国内目前不支持 .ai 域名备案（除了智谱等），买.com就行。

备案流程现在已经比较方便，可以远程办理，一周左右就能搞定，此后长期稳定可用。

微信里分享自己做的网站，只要单日访问量不超过 20 万，正规备案过的网站是不会被限制的。

关于 Codex 的数据会不会丢：

有观众担心把 Codex 里的项目搬到别的平台是不是杞人忧天。

启源的回答很干脆：Codex 的绝大部分对话 session 都存在本地，不用太担心。

但如果是 ChatGPT 网页端的对话，因为没有类似的本地保存机制，最好养成习惯定期用导出功能把有价值的内容存下来。另外元子提到，她朋友做过一个小工具，能一键导出本地 Codex、Claude Code 等各种 Vibe Coding 工具的历史 session，感兴趣的话可以找一下。

关于 ADHD 和信息过载：

启源引用了一句"Attention is all you need"，注意力本质上就是每个人的货币。

他的建议是把时间硬性划分开，工作时间就专心跟 AI 处理工作内容，不要工作聊一会儿又切到生活话题。

如果实在做不到硬性划分，退而求其次的办法是先记录下自己实际的状态，过几天回头看这些记录，问题往往自己就浮现出来了。

向阳乔木现场还演示自己开发的 AI 资讯工具，一个收录了 46 个海外 newsletter 的 RSS 阅读器，每篇文章都能一键用 DeepSeek 翻译成中文，读到有价值的链接还能直接收录到站内。

> https://rss.qiaomu.ai/

更多工具在

> https://www.qiaomu.ai/

关于工程能力的入门书籍：

与其啃传统的设计模式这类偏抽象的教材，元子推荐了三本更基础也更好读的书：《程序是怎么跑起来的》《Linux 是怎样工作的》《计算机是如何工作的》，都是日本工程师写的科普向读物，读起来像故事书，对理解 AI 编程能帮你做到什么很有帮助。

启源的观点更直接：带着具体项目问题去学，永远比抽象地啃书更快，遇到问题直接问 AI 解决就是最快的路径。

## 写在最后

十年前，一个不起眼的小客户在微软的机器学习平台上跑出了 GPT-3，当时没人觉得这东西有什么用。

提醒我们：技术的拐点往往发生在没人当回事的时候，而真正决定你能不能踩上这个点的，从来不是工具本身，是你有没有那个判断力和好奇心，愿意多看一眼。

架构设计留给人，debug 思路留给人，产品的本心和边界留给人，学习路径的取舍也留给人。

工具在替你写代码、替你部署网站、替你填表格，但不会替你决定要不要做这件事，更不会替你守住做这件事最初的理由。

如果你正打算开始一个独立项目，不妨先问自己启源那句反问：这个产品是不是解决了你自己身上最痛的那个点。

想清楚这一点，再决定要不要注册域名、搭 Harness、开始 Vibe coding。
