往前走一步，已经不是口号了

故事是这样的。

我们公司每周二周四都有一个会，叫项目进度例会。

我已经跟很多人说过很多次了，我觉得这个会不该开。

不是因为我讨厌开会。

虽然我确实也挺讨厌的。。。

而是因为这个会的存在，本身就说明了一件很荒诞的事。

我们居然还需要把一群人拉到一起，然后张口问一句，这个 task 现在什么进度了。

你想想看，这个动作其实很奇怪。

如果一个任务的进度是真的进度，它为什么不能体现在 GitLab issue 里？

如果一个任务已经提测了，QA 测完了，MR 也合并了，为什么系统里没有一个状态能表达这件事？

如果系统表达不了，那到底是系统的问题，流程的问题，还是我们压根没有认真想过这个问题？

这事儿听起来很小。

小到它只是一个周二周四的例会。

小到你甚至可以说，大家坐下来同步一下，也没什么大不了。

我非常理解这种感觉。

很多时候，一个团队里的事情就是这样跑起来的。有人问一句，有人答一句，有人顺手改一下飞书表格，项目好像也就继续往前走了。你说它错吗，好像也谈不上。

过去十几年，很多公司都是这么过来的。

但我最近越来越强烈地觉得，到了 2026 年，这种事已经不能再被当成正常状态了。

不是因为开会这件事突然变得罪大恶极。

而是因为 agent 时代来了以后，很多以前靠人肉补齐的缝，都会变得特别刺眼。

你以前可以说，没办法，系统不完善，所以人坐下来聊一下。

你以前可以说，没办法，流程就这样，所以产品、研发、测试、项目管理，大家多配合一下。

你以前甚至可以说，没办法，我们团队小，先跑起来再说。

但现在不一样了。

现在的问题是，如果一个信息没有结构化，如果一个状态没有进入系统，如果一个流程只能靠人嘴巴补齐，那它就很难被 agent 接住。

接不住，就不会自动化。

不会自动化，就会继续靠人肉。

继续靠人肉，就会继续开会。

然后大家一边说 AI 时代来了，一边周二周四坐在会议室里，问这个 task 到哪了。

这画面，我是真的觉得有点魔幻。

我不是在说项目管理这个角色没有价值，也不是说所有会都不该开。

恰恰相反，我觉得真正有价值的管理，不应该被这种低质量的信息搬运绑住。

如果一个人需要 monitor 项目进展，那他真正需要的是什么？

他需要的是在周二、周四，或者任何一个时间点，知道所有任务的真实状态。

注意，是状态。

不是大家对状态的口头描述。

这两个东西差别很大。

口头描述是这样的。

这个已经做完了，准备提测。

这个 QA 在看。

这个还有个小问题。

这个 MR 合了。

这个等一下我更新下表格。

听起来信息很多，对吧。

但这些信息如果只存在于一场会议里，或者只存在于某个人说完之后顺手更新的飞书表格里，那它对系统来说，几乎就是空气。

它没有变成 repo 的状态。

没有变成 issue 的状态。

没有变成 agent 可以读取、判断、汇总、追问、预警的状态。

所以最后你就只能继续问。

这才是我觉得这个项目进度例会不该开的原因。

我尊重沟通。

但好的沟通应该建立在系统上，不是建立在会议上。

举个特别具体的例子。

我们现在很多 issue label，大概就是 todo、doing、qa 这种状态。

它当然有用。

但你往下多想一步就会发现，它是不够的。

doing 进入 qa，只能说明功能进入了提测状态。

那 QA 人员已经测完了吗？

测完以后有没有发现 blocker？

没有 blocker 的话，MR 合并了吗？

MR 合并以后，这个功能算不算闭环？

如果 qa 这个 label 之后什么都没有，那后面这些状态去哪了？

它们没有消失。

它们只是从系统里消失了。

然后跑进了人的嘴里。

跑进了会议里。

跑进了项目管理同学的飞书表格里。

最后变成了一个很奇怪的局面，明明 GitLab issue 是任务的源头，MR 是代码变更的源头，QA 是质量状态的源头，但项目真实进度却要靠人坐在一起问出来。

你敢信？？？

更理想的状态应该是什么？

项目管理同学打开的不是一张需要手动维护的飞书表格，而是一个从 issue、MR、QA 结果自动汇总出来的视图。

哪些任务还在 doing，哪些已经提测，哪些 QA done 但 MR 没合，哪些 MR 合了但还没发布，agent 可以直接读出来。

人不需要先坐在一起问一圈，才能知道世界现在长什么样。

这就是我说的，没有想法，就没有行动。

这句话听起来很像鸡汤，但我想表达的不是鸡汤。

我想表达的是，如果一个人没有先把问题重新想一遍，他根本不知道该行动到哪里。

他可能很忙。

可能每天都在跟进很多任务。

可能开了很多会，改了很多表，催了很多人。

但他没有想到，原来自己真正要解决的问题，不是怎么把会开得更高效，而是怎么让这个会不再需要存在。

这个差别太大了。

一个是在旧系统里更努力。

一个是在重新定义系统。

顺着这个再往外聊一点。

我们公司创业到现在 10 年了，坦率的讲，是一家很传统、很专一的产品公司。

团队不大，小而美。

工程团队其实一直挺强的，大家也不是那种只想混日子的人。很多人对产品本身，对系统本身，对把东西做得更好这件事，是有追求的。

当然，今天我不想聊产品怎样，公司怎样。

我真正想聊的是，到了 2026 年，所有公司都在面对一个很类似的问题。

组织范式开始变了。

岗位角色开始变模糊了。

以前你说自己是前端工程师，那你就做前端。你说自己是 QA，那你就测功能。你说自己是 PM，那你就跟项目进度。

边界很清楚。

甚至清楚到有点舒服。

但 agent 时代来了以后，这个舒适区开始被拆掉了。

不是老板要拆。

不是管理者想折腾。

而是技术本身把这件事推到了每个人面前。

以前公司有一句口号，叫「往前走一步」。

我一直觉得这句话挺好的。

它不是要求每个人无止境加班，也不是让大家什么都管，什么都背锅。

它更像是一种做产品公司的精神气。

你不是只能待在自己的岗位说明书里。

你不是前端工程师就只能写组件。

你不是测试就只能点页面。

你不是项目管理就只能拉会和改表。

你是在创造一个东西。

创造这个词挺大的，但落下来其实很具体。

你看到一个流程很蠢，能不能多想一步。

你看到一个状态表达不了真实进度，能不能多想一步。

你看到一个 agent 明明可以干掉重复劳动，能不能多想一步。

过去，这种多想一步，可能是一种加分项。

你愿意做，大家会觉得你有热情，有激情，有 ownership。

你不愿意做，好像也能过。

反正系统就是这样，公司就是这样，流程就是这样，大家也都这么过来了。

但现在，我觉得它正在从加分项变成入场券。

你已经不是愿不愿意往前走一步的问题了。

你是必须往前走一步。

因为如果你不走，agent 会逼你走。

更准确地说，是那些会使用 agent、会重新定义问题、会把旧流程改造成新系统的人，会把你留在原地。

这话听着有点刺耳。

但我有时候觉得，他说的确实就是事实。

很多人会问，那我到底怎么才叫有想法？

这问题其实很难。

因为如果一个人很多年都待在舒适区里，他不是不愿意有想法，他是真的想不出来。

他会把眼前的一切当成默认设置。

周二周四开项目进度例会，是默认设置。

issue label 只有 todo、doing、qa，是默认设置。

QA 完了以后靠人嘴说，是默认设置。

项目管理手动改飞书表格，是默认设置。

一个 bug 修完以后，commit 就只是 commit，是默认设置。

仓库里的历史经验散落在 MR、issue、聊天记录、脑子里，也是默认设置。

默认设置最可怕的地方就在这里。

它不会让你痛到立刻跳起来。

它只会一点点消耗你。

消耗会议时间，消耗注意力，消耗组织记忆，消耗大家对创造这件事的热情。

最后大家都很忙。

但系统没有变聪明。

这才是最可惜的地方。

前面这个例子，说的是信息怎么进系统。

再往下走一步，还有一个更狠的问题。

系统能不能从自己的失败里进化？

说到这个，我再举一个我最近特别在意的例子。

Hermes 今年 2 月 25 日推出，到现在已经 3 个多月了。

它有一个我觉得非常关键的方法论，就是 agent 可以根据用户的实际使用，自己提炼 skills，然后越用越好用。

大白话讲，就是用户在真实工作里反复怎么用、哪里卡住、哪里需要补规则，agent 不只是把这次任务做完，而是把这些使用痕迹反过来整理成下一次可以复用的工作方法。

这不是写一份静态说明书。

这是让系统从使用里长出经验。

这件事很重要。

不是因为 Hermes 这个产品本身有多神奇。

而是因为它给了我们一个非常清楚的范式。

一个系统不是靠一开始写一份完美说明变聪明的。

它是靠使用，靠反馈，靠失败，靠把失败提炼成新的技能，慢慢变聪明的。

你看，这话放在 agent 上很好理解。

那为什么放回代码仓库，很多人就不想了呢？

一个 repo，每天都在产生 bugfix commit。

每一个 bugfix commit，背后其实都有一个 failure mode。

为什么这个 bug 会出现？

为什么之前的 skill 没有避免它？

为什么 agent 修这个 bug 的时候走了弯路？

为什么某个模块反复出现同一种问题？

如果我们把这些 commit 串起来看，会发生什么？

commits -> eval case -> failure mode -> skill creator -> repo skill。

这不就是一条非常自然的闭环吗？

你甚至不需要把它想得多复杂。

bugfix commit 是事实。

eval case 是把事实变成可复现的题目。

failure mode 是把题目背后的失败模式说清楚。

skill creator 是把失败模式写进仓库自己的工作方法。

repo skill 是让下一个 agent 不要再踩同一个坑。

这件事听起来是不是很顺？

顺到我现在回头看，甚至觉得它有点过于明显。

但比较有意思的地方就在这里。

Hermes 已经出来 3 个多月了。

公司里依然没有人自然想到，完全可以把同样的理论迁移到代码仓库里。

我说这个不是为了批评谁。

因为说实话，我自己也经常这样。

很多想法不是一眼就能看到的。你得先被某个问题卡住，先对某个荒诞场景有不舒服的感觉，然后再顺着那个不舒服往下追。

但这也正是我想说的。

想法不是凭空来的。

想法来自于你不再把默认设置当成默认设置。

你先觉得不对劲。

然后追问为什么。

然后回到第一性原理。

然后再问，如果今天有 agent，这件事应该怎么做？

这就是想法的来源。

不是坐在会议室里脑暴一句「我们要更 AI Native」。

那没什么用。

真正有用的问题是，为什么这个项目进度还要靠嘴问？

为什么这个状态没有进入 GitLab？

为什么这个 bugfix commit 没有变成 eval case？

为什么这个 repo 不会从自己的历史里学习？

为什么每个新 agent 进来，都还像失忆一样重新踩坑？

这些问题一问出来，行动才会出现。

否则行动就是空的。

你让大家主动一点。

主动什么？

你让大家往前走一步。

往哪走？

你让大家用 AI。

用 AI 干嘛？

问题没有被重新定义之前，行动就只能停在口号上。

这也是为什么我现在越来越不喜欢那种很泛的 AI 转型叙事。

什么拥抱 AI，什么提升效率，什么重塑组织。

这些话都对。

但它们太大了。

大到落不到一个周二周四的项目进度例会。

大到落不到一个 qa label 后面缺失的状态。

大到落不到一个 bugfix commit 后面藏着的 failure mode。

真正的转型，一定会落到这些很小、很具体、很烦人的地方。

因为组织的运行方式，本来就是由这些小地方组成的。

你每天怎么知道任务进度。

你怎么判断一个功能真的闭环。

你怎么让一个新人理解仓库历史。

你怎么让 agent 不重复犯错。

你怎么把一次修 bug 的经验，变成下一次不出 bug 的机制。

这些东西合在一起，才叫组织能力。

不是 PPT 上的组织能力。

是真正在地上跑的那种。

说到这里，我突然想起一个画面。

马斯克当年搞星舰回收，最后大家看到那个「筷子夹火箭」的瞬间，都会觉得太离谱了。

那么大一个火箭，回来以后被发射塔夹住。

这画面天然就有一种荒诞感。

你第一反应可能是，这也行？

但它最打动我的地方，不只是技术多牛。

而是背后的那种思考方式。

不要先问以前是不是这么干的。

不要先问岗位边界是不是这么分的。

不要先问这个事情归谁负责。

先问，我到底想解决什么问题。

如果目标是让火箭快速复用，那为什么一定要有传统意义上的着陆腿？

如果目标是 monitor 项目进度，那为什么一定要开项目进度例会？

如果目标是让 repo 越用越聪明，那为什么 bugfix commit 不能反过来训练 repo skill？

我当然不是说我们每个人都要去夹火箭。

那太离谱了。

我们也夹不了。

但一个小团队里的「筷子夹火箭」，可能就是先干掉一个不该存在的会。

可能就是补上一个缺失的 issue label。

可能就是让 agent 每次修完 bug，都把失败模式写回 repo skill。

可能就是把一个过去靠人肉经验撑着的流程，变成系统自己可以读取、判断、追问、改进的结构。

这已经很了不起了。

真的。

很多时候，所谓创新不是突然发明一个惊天动地的新东西。

而是你终于发现，一个大家习以为常的旧动作，其实早就不该存在了。

然后你把它拿掉。

这一下，系统就往前走了一步。

我知道，有些人看到这里可能会觉得压力很大。

好像现在每个人都得变成产品经理，都得懂工程，都得懂 agent，都得懂组织设计。

我非常理解。

因为这件事确实不轻松。

岗位边界变模糊，对大厂是冲击，对我们这种小而美的团队也是冲击，而且不是一点点冲击。

以前你可以用专业边界保护自己。

我是前端，这不是我该管的。

我是测试，这不是我该想的。

我是项目管理，我只负责同步进度。

我是研发，我只负责把需求做完。

这些话在过去某些场景里是合理的。

甚至是必要的。

没有边界，组织会乱。

但在 agent 时代，边界不应该消失，边界应该变得更有弹性。

你仍然有自己的专业主场。

但你不能只把自己锁在主场里。

你得能跨出去一点点，看见上下游，看见系统摩擦，看见那些原本没人负责但确实在消耗组织的东西。

也许没人明确说，这个事情应该由你负责。

但你可以先把问题说清楚。

说清楚，就是往前走一步。

你可以先做一个很小的实验。

实验，就是往前走一步。

你可以先让 agent 跑一次，把 GitLab issue 状态和 MR 合并状态对齐起来，看看项目进度能不能自动汇总。

这也是往前走一步。

你可以先抽 20 个 bugfix commit，让 agent 帮你归纳 failure mode，看能不能生成 3 条 repo skill。

这还是往前走一步。

往前走一步，不是让你一下子变成另一个人。

它不是一场人格改造。

它更像是一种新的工作习惯。

看到旧流程的时候，多问一句，这件事能不能被系统表达。

看到重复沟通的时候，多问一句，这个信息为什么没有进入源头。

看到 agent 犯错的时候，多问一句，这个错误能不能变成下一次的 skill。

看到一个没人负责的缝的时候，多问一句，如果我不填，它是不是会永远在那里。

我自己的感受是，未来组织里真正稀缺的人，可能不是单纯执行力最强的人。

而是能发现这些缝，并且愿意把缝变成系统的人。

这类人很难被岗位名字定义。

他可能是前端。

可能是 QA。

可能是 PM。

可能是工程 leader。

可能只是某个对事情不太能忍的人。

他看到项目进度例会，脑子里想的不是怎么把会议纪要写得更漂亮。

而是这会为什么还在。

他看到 bugfix commit，脑子里想的不是这个 bug 终于修完了。

而是这个 bug 为什么会出现，下一次 agent 能不能不要再踩。

他看到 Hermes 的 skill 提炼机制，脑子里想的不是这个工具不错。

而是这个方法论能不能搬到我们的代码仓库里。

这种人，就是我理解的 agent 时代的组织节点。

不是 title 上的节点。

是实际让组织变聪明的节点。

说实话，这篇文章不是一个成熟的方法论。

我自己也还在摸索，也还在试，也经常想得很兴奋，做起来又发现一堆坑。

比如让 issue label 反映真实状态这事，听着简单，真做起来肯定会遇到很多麻烦。

谁来维护 label？

怎么避免大家乱打？

怎么定义 QA done？

怎么让 MR 合并、测试状态、发布状态之间有一致的关系？

怎么让 agent 读出来的是事实，而不是又一层被污染的数据？

这些都不是一句话能解决的。

repo skill 的闭环也一样。

commits -> eval case -> failure mode -> skill creator -> repo skill，听起来很顺，但真跑起来也会有一堆问题。

commit 信息不干净怎么办？

bugfix 和 feature 混在一起怎么办？

failure mode 归纳错了怎么办？

skill 写得太泛，下一次没用怎么办？

skill 写得太细，维护成本爆炸怎么办？

所以我不是在说，这些事情明天就能一键解决。

没有。

一开始一定会很笨。

甚至可能比手动做还慢。

但这个笨拙的过程，可能就是 agent 时代最重要的学习过程。

因为你不是在学一个工具按钮怎么点。

你是在学怎么把一个旧问题，重新定义成一个可以被系统解决的问题。

这件事，才是关键。

回到最开始那句话。

没有想法，就没有行动。

但这里的想法，不是灵光一闪，不是脑暴金句，也不是大谈战略。

它是你面对一个旧流程的时候，突然停下来问了一句。

为什么是这样？

它是你面对一个默认设置的时候，突然不太舒服。

这个状态为什么不在系统里？

它是你面对一个 agent 的时候，突然意识到。

如果它可以读，可以写，可以总结，可以回放，可以提炼，那很多过去靠人肉维持的组织动作，都应该被重新想一遍。

往前走一步，已经不是口号了。

它变成了一种很具体的能力。

重新定义问题的能力。

把经验结构化的能力。

把重复动作系统化的能力。

把 agent 接进组织运行链路里的能力。

最后再说回那个项目进度例会。

也许它不会马上消失。

很多事情都不会马上消失。

但我希望至少从今天开始，我们看它的眼神能变一下。

不要再把它当成一个理所当然的会。

把它当成一个信号。

一个提醒我们，系统还没有足够聪明的信号。

一个提醒我们，还有人肉劳动没有被重新定义的信号。

也是一个提醒我们，该往前走一步的信号。

以前往前走一步，是一句鼓励。

现在往前走一步，是组织能不能继续进化的分水岭。