本文首发于个人公众号"一个AI产品经理的周记"。记录我在一家信息技术公司为期6个月的AI产品经理实习的思考沉淀,每周不限次更新,本周是第1周。核心业务脱敏,只聊个人视角的思考与成长。欢迎同行交流,码字不易,点个“在看”鼓励一下。
为什么中小公司需要技术型AI产品经理?
在Agent编码能力已经能秒杀初级工程师的2026年,为什么公司还要专门招一个AI产品经理?
因为既懂技术又懂场景的人,永远稀缺。
从中小公司视角出发,招AI产品经理的出发点是:能不能用最少的人,把“需求合理性 → 技术选型 → 技术部署”这条核心链路一口气打通?尤其是现在,Agent能写代码、能调接口,组织对产品经理的期待就升级为“一人包揽全链路”。至于公司技术能力边界之外的事,首选外包,而不是高薪养算法团队。
更底层的是,大量中小信息技术公司正面临如何用AI重新组织传统业务逻辑,提升生产效率的问题。这时,公司买断产品经理的其实是技术直觉,也就是那种看到业务痛点,立刻能在脑子里画出技术选型分支图,并且能平衡成本、性能、时间限制的决策能力。
所以,我给自己画了个公式:技术型AI产品经理的市场价值 = 技术理解力 × 需求理解力 × 限制条件决策力。三者缺一,就是个偏科生;三者在手,才敢说“我来负责”。
从“数据为王”到“经验为王”的趋势来启发工作方法
2026年,全球AI的底层逻辑正在悄悄转向。以前拼谁数据多,现在拼谁经验厚。
年初以来,Openclaw、Hermes这类Agent产品轮番登场,背后技术架构的演进路径非常清晰:提示词工程 → 上下文工程 →Harness工程。与之配套的“Skill”概念也在兴起,本质上就是用文档沉淀下来的最优工作路径,给模型搭一副“外在脚手架”,把不确定性驯化成可预期的系统表现。
这给了我一个很大的启发:我们当下给公司搭建的每一个AI功能单元,其实都是在为未来那套“传统业务+AI能力”全自动集成的系统做预演。我们现在写的每一份技术文档、设计的每一个评测标准,将来都会变成企业自身的“数字经验库”。
既然如此,为什么不直接用Agent的工作逻辑来组织我们自己的工作?
Harness——一种规划项目的工作方法论
我最近特别着迷于Harness架构——它之所以能保证Agent长时间稳定运行,是因为它把系统拆成了三个角色:
Planner(规划者):定宏观方向、整体排期;
Executor(执行者):从计划中拆出单项任务,细致落地;
Evaluator(评估者):审计执行结果,把关质量。
三者之间是两两协商、三方对齐的关系——规划与执行先对技术方案文档,执行与评估对验收指标,评估与规划对业务目标。全部对齐,才动工。
放到我们的日常工作里,这个启示太直接了:项目启动前,排期、执行预期、验收标准必须三方拉通,缺一个都不开工。现在AI编程工具大幅降低了执行门槛,规划者和评估者反而成了最关键的“守门人”。
规划者的核心能力,是以排期为单元,让每个阶段尽可能覆盖整条业务链。评估者则要分清楚两层评测:
技术评测:有学界和行业标准,照章办事;
业务评测:没有标准答案,只能靠实地调研去摸清真实场景的边界条件。
我越来越觉得,AI产品经理最不可替代的部分,恰恰是“和现实世界打交道”的能力。只有去和总监聊、去一线蹲、去听用户骂,然后才能定出合理的业务评测标准,再反推技术选型。没有调查就没有发言权。
白天上班,晚上“上论文”
如果白天是打工,晚上就是给自己补课。
我的习惯是每周至少刷1-2篇近期论文,尤其是语音、多模态、Agent框架方向的。重点关注这篇模型新增了什么能力?它的设计思路对我手上的项目有没有参照?
你理解的技术上限,就是你能做出的工程上限。很少有人天生就能拍板全套技术选型,所以只能在战争中学习战争。
举个本周遇到的真实案例:
我们准备做一个面向特定子方言群体的语音呼救装置。规划阶段就碰上一连串问题——
场景决定评测:呼救场景下,距离远近、音色差异、环境噪音、音量大小都得纳入业务指标,不能只比通用准确率;
评测决定数据:评测定完后,才能明确该采哪些数据、怎么采;
执行遇到限制:数据稀缺、微调后泛化能力差,怎么办?是先内部想办法,还是找外部合作?找合作的话,就得立刻切换角色去做联络和协调。
但如果认真地阅读近几年的部分ASR、TTS、VC等技术栈论文,就会发现部分模型在训练阶段的多任务训练中就已经包含了我们实际业务场景所需要的目标,比如呼救用语的热词识别问题,比如数据合成中的音色转换问题等等,许多问题还轮不到需要机构合作解决的地步,已有的技术积累已经能够解决这些问题。其实上述很多考虑也说明,产品经理的每一天,都是在不确定中做权衡,在限制条件下画最优路径。
如果你也在AI产品这条路上摸索,欢迎留言聊聊你的困惑或心得。
毕竟,AI会接管很多事,但真正理解业务、理解人性、理解限制的人,永远有活干。
下周见。