AI Native 产研实验 2/n：角色认知的壁垒，比技术问题更难搞

晚上跟下属喝了点酒，想着还是更新一下。实验算是启动了。今天太忙，我让产品和技术在会议室讨论了一天，结论是什么样我还不知道，后面更新。

实验算是正式启动了，后面不定期更新进展，至少两周一次更新，欢迎关注。

上一篇说到我们打算找两个项目来验证 AI Native 协作这条路。当天我们就找了一个。。

产品经理找了一个系统里的小规模需求,这套系统已经跑了大概五年,是一套非常庞大的微服务架构。选它有两个原因:第一,不急着上线,春节前搞定就行,风险可控;第二,老系统的文档往往最混乱,如果 AI 在这种条件下都能工作,那新项目就更不在话下。我想看看 AI 对老代码的理解能力到底能到什么程度。

但一上手就碰了一鼻子灰。产品之前准备的文档还是传统方式，在各种 Wiki 上画的图、导出的文件。丢给 AI 一看,效果很差。这不意外, 在一个信息庞大的脑图和复杂的流程图上 AI 并不能理解的很好。所以我当场做了一个决定:推倒重来,现场把文档改成 Markdown 或者其他模型可读的格式。

改完之后再丢给 AI,效果有了明显提升。我们先不急着写代码,而是不停地用 AI 优化和解析,看看需求分析最终能达到什么层面。基于这套五年老代码,现在的 AI 能够生成的文档基本上能解决 80% 以上的问题。这个数字是初步评估,不是最终结论,但至少让我们看到了可能性。

说实话,这个 80% 的数字让我挺意外的。五年的老系统,微服务架构,文档早就不知道散落在哪些角落了,AI 居然还能分析出这么高的准确率。这让我意识到,AI Native 的改造不一定要从新项目开始。老项目也可以,甚至老项目的价值更大——因为它们的文档往往更混乱,更需要 AI 来理解和整理。

但这个过程中,我发现了一个比技术问题更棘手的东西:角色认知的壁垒。

当我要求产品经理把 XMind 脑图改成 Markdown 文档时,我能感觉到一种不适应。这不是技能问题——Markdown 很简单,任何人都能学会。这是角色认知问题。产品觉得自己就应该画原型图,开发觉得自己就应该写代码,测试资源(我们是跨团队协调的)觉得自己就应该写测试用例。大家对于各自角色的定位和定义其实是根深蒂固的。

"我是产品经理,我的工作就是画原型图。为什么要我写 Markdown?"

这种思维是根深蒂固的。如果能进一步打破这种思维,改观会非常大。但问题是,我怎么打破?

我不能强制要求大家改变思维方式,那样只会适得其反。也不是要让产品经理学会写代码,或者让开发学会画原型图。我想要的是让大家意识到:在 AI Native 的协作模式下,角色的边界可能需要重新定义。

这不是"大家不愿意学习"的问题,这其实更深层的组织心理问题。每个人都在自己的角色里做到了极致,但整体穿接起来依然别扭。上一篇提到的"局部最优、全局次优",在这次试点中体现得淋漓尽致。

我开始思考一个问题:如果 AI 能够理解需求、生成文档、甚至写代码,那么产品、开发、测试这些角色的边界到底应该怎么画?是不是应该从"我负责什么工具"变成"我负责什么决策"?

比如,产品经理的核心价值不是画原型图,而是判断需求的优先级、理解用户的真实诉求。如果 Markdown 能让 AI 更好地理解需求,那为什么不用?开发的核心价值不是敲代码,而是设计系统架构、做技术决策。如果 AI 能写 80% 的代码,那开发应该把精力放在那 20% 最关键的部分。

但这些都是我的想法。大家能不能接受,我是不确定的。

这次试点还有一个意外收获:我们发现,AI 对老系统的理解能力超出预期。五年的代码,微服务架构,依然能分析出 80%+ 的准确率。这说明什么?说明 AI Native 的改造不一定要推倒重来,老项目也可以逐步迁移。

但这个 80% 也让我保持警惕。80% 的解决率听起来很高,但剩下的 20% 可能是最难的部分。而且这个 80% 是在"需求分析"这个环节,真正到了开发、测试、上线,会不会遇到新的问题?我不知道。

我也不确定角色认知的壁垒能不能打破。并且从团队的角度来讲不能强制推行,那样只会让大家反感。我只能让大家看到价值,然后自然而然地接受。

也许,当大家真正体验到 AI Native 协作带来的效率提升时,角色边界会自然而然地模糊。或者,也许我想错了。

接下来我打算继续在这个老项目上深入,看需求分析能推进到什么程度。同时准备一个新项目做对比。我想看看,在新项目上从一开始就用 AI Native 的方式,会不会更顺畅。

角色认知的壁垒可能是整个实验最大的挑战。但如果我们不尝试,就永远不知道答案。

我们继续试。

这是「AI Native 产研实验」系列的第二篇。感兴趣的话，欢迎加个关注，后续更新不迷路。