从个人提效走向组织生产力：软件研发型企业AI建设的一些思考
近一年，我的核心精力在AI Infra平台的建设，身边的同事往往会有个疑惑：Codex、Claude Code、OpenCode 这些通用 Agent 已经这么强，而且还会继续快速变强，我们为什么还要花大量的钱买算力、买 Token、自己建设平台？
我的答案是：如果目的只是让开发人员写代码更快，其实买账号就够了。一个优秀的开发人员把 Codex 用熟，个人效率很可能比我们自己做一个代码生成工具更高。企业自建平台的价值不能建立在“我们的 Agent 比 Codex 更强”这个前提上，因为这个前提只会越来越难成立。
我们建设的理念是：通用 Agent 主要解决个人能力放大的问题，企业要解决的是另外三个问题： 怎么把个人提效变成组织提效，怎么让 AI 使用过程中产生的知识和能力留在组织里，以及花出去的算力、Token 和研发投入到底换回了什么 。对于电网、金融等大型企业，还要再加一个问题： 企业最核心的数据、流程和业务认知，能不能始终掌握在自己的安全边界内。
这也是我们理解、建设 AI Infra 的出发点。
组织能力：把个人提效沉淀为企业资产
Codex、Claude Code 对个人开发者已经很好用了，但个人效率提升并不天然等于组织效率提升。
一个人在 Agent 中积累了很好的 Prompt、Skill、Memory 和使用经验，这首先是他的个人能力。换一个人、换一个项目，很多经验仍然需要重新摸索。如果一家企业有几千名员工，每个人都在自己的 AI 工具里重复积累一遍，最终可能出现很多效率很高的个人，但企业本身并没有沉淀出多少新的能力。
所以我们越来越关注的不是“AI 又多完成了一个任务”，而是这个任务完成以后，有什么东西留了下来。
企业应该沉淀的也远不只是知识库。需求、任务、代码、用例、缺陷、设计文档是研发资产；制度、技术规范、业务规则、数据口径是知识资产；API、工具、Skill、工作流是能力资产；项目长期运行过程中形成的系统架构、业务边界、历史决策、问题经验，则是一类过去很难显式管理的认知资产。
项目记忆是其中一个比较典型的例子。一个项目已经形成的业务认知和工程认知，不应该因为一次 Session 结束而消失，也不应该只存在于项目里某一个人的脑子里。需求分析时应该知道历史上已经建设了什么，任务拆分时应该知道现有模块和接口，代码生成时应该理解工程结构和编码习惯，测试和代码审查时应该知道历史问题和业务约束。
未来真正需要统一管理的，包括知识、数据语义、Skill、Agent、工作流、API、模型、项目记忆，以及这些资产之间的版本、权限、依赖、评价和使用情况。模型会不断变化，Agent 也会不断变化，但这些东西应该能够长期留下来。
因此，我们判断一个企业 AI 平台有没有价值，不太看它自己实现了多少个智能体，而更看它有没有沉淀出一批可复用、可调用、可组合、可治理的企业智能资产。这也是我们建设 AI Infra 最核心的一条线。
安全边界：掌握数据、模型和算力主权
大型企业仍然需要自己的算力和模型运行环境。这不是因为企业有必要自己训练一个比 OpenAI、Anthropic 更强的模型，也不是为了追求“所有模型全部国产化、所有任务全部内网化”。真正的原因是，AI 越深入生产，数据安全问题反而越突出。
过去一个 IDE 主要接触代码，今天的 Agent 为了完成复杂任务，需要读取整个代码仓库、需求、设计文档、数据库结构、接口、运行日志、业务规则，甚至直接调用企业内部系统。
Agent 越强，需要获得的上下文越多；AI 越深入生产，企业暴露给 AI 的东西也越接近真正的核心资产。
近期 ZCode 数据上传争议就是一个提醒。这里真正值得关注的，不是评价某一个工具可信还是不可信，而是只要 Agent 开始理解整个工作环境，大量数据在客户端、模型服务和外部系统之间流动就会成为常态。
对于普通个人来说，这可能更多是隐私问题；对于电网、金融以及大型企业来说，它首先是生产安全和数据主权问题。因此，企业不能把安全建立在“某一个客户端永远不会出问题”上，而必须建立自己的数据边界、模型边界和审计边界。
过去企业数字化建设最看重的是系统和代码，但随着生成式 AI 的发展，代码的生产成本会持续降低，很多软件功能甚至可以重新生成。相比之下，一家企业几十年运行过程中积累下来的私有数据、业务流程、领域规则、专家经验和组织认知才越来越难复制。所以企业今天建设自己的算力、数据和治理体系，本质上并不只是保护代码，而是在保护未来最重要的智能资产。
建设内容：聚焦 AI Infra 和可信验证
企业真正需要掌握的是自己的智能资产和安全边界，所以“企业到底应该自己做什么”就会清楚很多。
我们建设的原则是：越靠近模型、越通用的东西越少自己做；越靠近企业自身、越有组织属性的东西越值得投入。
Repo 探索、上下文压缩、代码理解、任务规划、Agent Loop，这些过去看起来可能是一款 AI 编程产品的核心能力，但很可能很快成为 Codex、Claude Code 的标准能力。企业投入大量人力去复制这些能力，最大的风险不是技术做不好，而是还没有做完，问题本身已经被通用 Agent 解决了。
所以我们不会把“自己做一个更好的编码 Agent”作为长期目标。
复杂代码任务完全可以通过ACP协议交给 Codex、Claude Code，未来谁更强就接谁。我们的平台真正应该解决的是：怎样把正确的需求、任务、工程代码、研发规范、项目记忆准备给它；怎样让它安全访问必要的企业资源；怎样把执行结果重新写回研发过程；怎样管理和复用过程中形成的知识与 Skill；最后又怎样验证它做出来的东西到底对不对。
我现在经常用一个问题判断某项能力值不值得自己做： 如果明天通用智能体的能力突然再提升十倍，我们今天做的东西会价值下降，还是价值提高？ 如果立即被替代，大概率说明这部分做重了。
沿着这个逻辑，我们未来比较明确的长期产出实际上有两个。
一个是 AI Infra。它不是一个大而全的新门户，而是一套让企业安全使用不同模型和 Agent 的基础设施：下面连接算力和模型，中间连接数据、知识、Skill、工具和已有系统，上面支撑员工和不同业务场景，同时把权限、资源、成本、审计和资产运营管起来。
另一个是代码审查和可信验证。当 AI 生成代码越来越容易以后，研发真正困难的问题会逐渐从“怎么生成”转向“生成得对不对”。所以代码审查不能只是再找一个模型读一遍 Diff，而应该逐步演进成 AI 研发的质量基础设施。需求有没有真正实现，代码有没有违反架构和技术规范，SQL、依赖、安全和性能有没有风险，测试有没有覆盖关键路径，哪些结论可以通过规则和自动化工具确定性证明，哪些问题需要模型判断，哪些必须由人负责，这些最终都要形成体系。
AI Infra 解决 AI 怎么进入企业，可信验证解决 AI 进入生产以后为什么值得相信。 这两个方向，相比再做一个编码工具，更值得长期投入。
落地路径：从研发智能走向 AI Infra
我们选择从研发智能切入不是因为研发是最热门的 AI 场景，而是因为研发恰好是验证整套企业 AI 能力最合适的生产环境之一。
这里既有需求、任务、代码、测试、缺陷等完整数据，也有复杂的上下文和明确的质量结果。如果 AI 能够真正进入研发生产，它就必须同时解决模型能力、上下文、知识、系统连接、任务执行、权限、安全、质量和 ROI。这些问题将来进入其他业务领域同样会遇到。
目前，我们在做的需求撰写、任务拆分、代码生成、用例生成、代码审查和项目管理只是六个实际生产场景。我们一边建设这些场景，一边往下抽公共能力：研发知识、业务知识、工程资产、数据语义、项目长期记忆、模型服务、Skill、工作流、复杂任务执行、资源调度、安全审计。
从研发开始跑通以后，同一套底层能力才能逐步进入项目管理、经营、人力、行政和其他业务领域。“研发智能—业务智能—AI Infra”不应该被理解成三个不同项目，而是一个逐渐扩大的过程：
研发场景负责验证，更多业务场景负责放大价值，最终把不断重复出现的共性能力沉淀成企业 AI Infra。
经验教训：不要把技术热点当成长久架构
在建设过程中我们也走了不少弯路，其中有两个比较有代表性。
第一个是工作流。
前一段时间，随着“龙虾”的走红，整个行业快速转向 Agent 和 Skill。我们也一度认为，随着模型越来越强，传统 AI 工作流很快会失去意义，所以砍掉工作流编排，所有任务都直接通过 Agent + Skill 完成。
后来发现这个判断过于乐观。问题不在 Agent 和 Skill，而在于企业实际可用的模型条件与公网最先进模型之间存在明显差距。内网算力有限，模型推理、上下文和工具调用稳定性都没有那么理想。这种情况下，把一个长链路任务完全交给 Agent 自由规划，虽然技术形态先进，但其中任何一步发生偏差，后面的错误都会放大。
所以后来我们又把确定性工作流加了回来。现在更倾向于一个简单原则：确定的事情交给流程规则，不确定的事情交给Agent。 数据读取、规则校验、格式转换、结果落库，本身有非常明确的输入输出，没有必要让大模型反复推理；需求理解、代码分析、问题判断、方案生成这些无法完全写死的事情才交给 Agent。
第二个教训是 UI 生成。
一开始我们选择的是 Penpot + MCP 路线，本质上还是“传统设计工具 + AI 操作”。AI 通过 MCP 控制设计软件生成原型，在当时看来很合理。但模型能力的发展明显比我们的产品建设速度更快。
现在 AI 已经可以根据需求直接生成 HTML，在真实浏览器里查看页面，再根据用户反馈直接修改局部前端代码。相比先驱动传统设计工具再形成页面，这条链路更短，而且生成出来的代码可以直接进入后续的研发过程。所以目前正在往 AI 直接生成 HTML + 页面预览 + 局部代码修改 的方向切换。
这两个看起来完全不同的问题，最后给我们的教训是一样的： 不要把今天模型的能力边界，当成企业平台长期的架构边界。
过去为了补模型短板建设的复杂中间层，可能半年之后就失去价值。越靠近模型的实现应该越轻、越可替换；越靠近企业数据、业务资产、系统接口、安全和评价体系的部分，则越应该稳定地沉淀下来。
我们希望未来的平台不是随着模型升级不断被推倒，而是模型越强，平台价值越高。
价值衡量：从 AI 使用量走向经营结果
技术路线逐渐明确以后，另一个必须回答的问题就是 ROI。
企业可以买大量 GPU，可以购买大量 Token，也可以建设很多智能场景，但如果最后汇报的仍然只是“有多少人使用”“调用了多少次”“生成了多少代码”，其实很难说明投入到底换回了什么。
我们后面真正需要打通的是从算力和 Token 一直到生产结果的链路：一次调用消耗多少资源，它对应哪个需求、哪个任务；过去这个任务需要多少人时，现在需要多少；AI 生成的东西有多少直接采用，有多少返工；整个需求周期有没有缩短；缺陷有没有减少；一个已经沉淀的 Skill、知识或流程被多少项目复用了。只有这些东西串起来，AI 的 ROI 才能真正计算。
不同层级关心的问题并不一样。对研发人员，最直观的是有没有少做低价值的事情，找资料、搬上下文、写重复代码和模板材料的时间有没有减少；对利润中心，更重要的是同样规模团队能不能承接更多工作，交付周期能不能缩短，项目成本能不能下降，人均产出和项目毛利能不能改善；对公司管理层，更应该关注 AI 投入是否真正服务于公司的经营目标：整体研发和交付效率有没有提升，算力和 Token 等资源投入是否合理，重要业务场景有没有形成实际效果，重大质量和安全风险是否可控，以及这些能力能不能在公司范围内规模化复制。
这样看，AI 建设的指标也应该分层。使用人数、调用次数、Token 消耗属于运营指标；任务采用率、节省人时、交付周期和质量变化属于生产指标；成本下降、人均产出、项目毛利和整体投入产出，则才是真正需要向经营层回答的问题。
不能用“大家都在用”证明 AI 建设成功，最终还是要落到生产和经营结果上。
组织变革：工具升级最终要落到生产方式
ROI 再往后走一步，就会碰到组织本身。
AI 真正进入研发以后，产品、开发、测试和项目管理的边界一定会发生变化。过去依赖大量专业岗位串行协作完成的事情，将来可能逐渐由更少、能力更综合的人借助 AI 完成长链路交付，而少量高水平专家更多负责架构、规则、方法、复杂问题和关键技术判断。
我们现在已经能看到，传统的人才评价体系与这种变化之间存在一定不匹配。过去评价一个开发人员，可能更多看编码能力和某一个技术方向的专业深度；未来还需要看他能不能理解业务目标，能不能组织上下文，能不能有效使用 AI，能不能验证 AI 的结果，以及能不能完成更完整的端到端交付。
所以 AI 建设最终一定不是技术部门自己能完成的事情。它会涉及算力投入、数据权限、安全制度、研发流程、质量责任、人才评价和组织结构。如果工具建设和组织调整不同步，最后很容易变成公司采购或研发了一批很先进的 AI 工具，但真正的生产方式没有改变。
这也是为什么我认为企业 AI 是一把手工程。它不是因为技术特别复杂，而是因为真正要产生组织级价值，就必然跨越原有部门和管理边界。
与此同时，还有一个风险必须重视：AI 用得越来越多，但人的能力反而越来越弱。如果开发人员不再理解自己提交的代码，测试人员不理解为什么这些测试能够覆盖需求，技术经理逐渐失去架构判断能力，那么短期效率可能提高了，长期研发能力却可能下降。
因此未来的人才培养也不能只是教 Prompt、教几个 AI 工具，而应该更加重视需求理解、任务拆解、上下文组织、结果验证、代码审查和系统性判断。
我们现在坚持的原则是：AI 生成，人工负责，闭环验证。 AI 可以替人完成越来越多工作，但不能替组织承担最终责任。
结语
如果把我们的思考再压缩，我觉得企业 AI 最容易犯的两个错误是把模型能力当成企业自己的能力，把 AI 使用量当成组织生产力。
Codex、Claude Code 和未来的通用 Agent 还会继续快速进步。对企业来说，这不是威胁，反而应该是一件好事。越通用、越靠近模型的能力，模型厂商做得越好，我们就越应该少投入。
企业真正需要长期建设的，是它们不会替我们完成的那部分：自己的数据和业务流程，自己的知识、Skill 和组织记忆，自己的系统连接和质量标准，自己的安全边界和治理能力。
这也是为什么我们一方面从研发智能切入，把需求、任务、代码、测试、审查、项目管理这些真实生产场景做起来；另一方面不断把模型、算力、知识、记忆、Skill、系统连接和治理抽出来形成 AI Infra，同时把代码审查和可信验证作为一个长期方向。
最终，我们希望解决的并不是“公司里有多少人在用 AI”。真正的问题应该是：一个人的经验有没有变成团队的能力，一个项目的积累有没有变成公司的资产，越来越强的模型能不能安全地为企业所用，以及投入的算力、Token 和研发资源最终有没有转化成真实、可衡量的生产力。 如果这些问题能够回答清楚，企业 AI 才真正从个人提效走向了组织生产力。
