AI 时代的软件公司应该怎样组织?-夜雨聆风

AI 时代的软件公司应该怎样组织?

瓶颈正从写代码转向定义任务、提供环境和验证结果。产品、工程、实施和客户成功必须围绕同一套真实任务与评测协作。

当编码速度提高十倍，软件公司不会简单地变成“原来团队的十分之一”。

因为代码从来不是唯一瓶颈。

需求是否值得做，业务规则有没有矛盾，数据能否使用，系统怎样接入，错误由谁承担，结果是否真的改善——这些问题不会因为代码生成变快而自动消失。

相反，当实现成本下降，团队会同时尝试更多方案，产生更多变更和代码。新的瓶颈变成：能否清楚定义任务，给 Agent 提供足够环境，并快速判断结果好坏。

OpenAI 在内部 Agent 优先的工程实验中发现，人类工作重心从亲手实现，转向设计环境、表达意图和建立反馈机制。这个变化不只属于研发部门，也会扩散到整个软件公司。

产品经理：从功能负责人变成任务设计者

过去的产品文档常描述页面、流程和验收条件。

Agent 产品还需要定义目标、可用事实、工具、权限、失败边界和人工介入。产品经理要和客户一起把“帮我提升销售”这样的愿望，拆成可运行、可检查的工作闭环。

他最重要的产出不只是需求列表，还包括一套真实任务和成功标准。

如果团队连什么算完成都说不清，模型表现就只能靠主观体验判断。

编码 Agent 能承担越来越多实现、测试、重构和文档任务。工程师的杠杆来自让这些 Agent 更可靠地工作。

这包括清晰的代码库结构、自动测试、开发工具、权限隔离、日志、评测和回滚。工程师还要把业务系统能力封装成安全工具，让产品 Agent 能够调用而不能绕过规则。

未来优秀工程师未必写最多代码，但能建立一套让人和 Agent 持续高质量交付的环境。

实施团队往往最懂客户真实流程，也最清楚标准产品在哪里失效。

过去，这些知识常停留在会议、配置和个人经验里。AI 时代，实施人员需要把它们转化成流程模板、规则、工具说明、异常案例和评测数据。

这会让实施从项目成本中心，变成产品学习系统的一部分。

传统客户成功关注登录、功能采用和续费。Agent 产品更需要关注任务完成率、人工接管、错误、成本与业务结果。

客户成功团队会帮助客户决定自动化边界，复盘失败任务，发现新的例外，并把反馈送回产品与评测。

目标不再只是“让更多人使用”，而是“让更多工作在可接受风险下被完成”。

AI 产品最危险的销售方式，是用“全自动”“像专家一样”换取短期订单，再让交付团队承担无法兑现的承诺。

销售需要理解产品在哪些任务上经过验证，哪些动作需要人工批准，遇到什么情况会停止。清楚说明边界不一定削弱销售，反而是企业客户建立信任的基础。

Agent 上线后，需要有人持续观察任务、成本和风险。

这个能力可能由工程、数据、产品和运营共同组成，职责包括：维护评测集，分析失败，调整工具和指令，监控模型变化，处理事故，决定哪些场景可以提高自主程度。

它类似软件时代的 DevOps，但对象不只是服务器是否在线，还包括系统行为是否仍然符合业务预期。

组织真正改变，不能只靠新增职位。

一个实用做法，是让跨职能团队每周共同审查同一批真实任务：

这会把产品、工程、实施和客户成功拉回同一个事实基础。大家讨论的不再只是路线图和感受，而是系统在真实工作中做了什么。

一个极端是把 AI 当成降本工具，只要求每个部门减少人数。短期可能压低成本，长期却没有建立新的产品能力。

另一个极端是成立一个与主营业务隔离的 AI 实验室，做了很多演示，却接触不到真实数据、权限和客户流程。

更有效的方式，是让 AI 能力进入核心产品团队，同时给团队明确任务、真实环境和风险边界。

AI 时代的组织优势，不是谁买了最多账号，而是谁能更快完成“发现任务—做出系统—运行评测—处理失败—扩大边界”的循环。

最后一篇，我们把整个系列收束成一份行动方案：软件开发商现在应该做的七件事。

https://openai.com/index/harness-engineering/

https://openai.com/index/evals-drive-next-chapter-of-ai/