过去一年，软件公司讨论 AI，最热的话题是 AI Coding。

过去一年，软件公司讨论 AI，最热的话题是 AI Coding。

Cursor、Claude Code、Codex 都证明 AI 已经可以成倍提升编码速度。

我听腾讯的一个产品总监讲，他们内部出现了不少10倍工程师——以前每天200~300行代码，现在部分人可以做到2000~3000行。

但编码速度提升之后，新瓶颈开始凸显。

当 AI 能读代码库、拆任务、改多文件、跑测试、提 PR、修 review 意见，软件公司的瓶颈就不再只是“谁能更快写代码”。新的瓶颈变成了：公司能不能管理一群会写代码的 AI agent？

AI Coding 是效率工具。

Agentic Engineering 才是组织能力。

一、AI 没有杀死软件工程，只是把工程重心上移了

AI 确实正在改变软件生产方式。过去一个工程师一天写不完的代码，现在可能1个小时就能完成；过去需要查文档、读历史代码、改多个文件的任务，现在 AI agent 可以一次性推进。

但这不意味着工程能力变得不重要。恰恰相反，工程能力变得更重要了：以前工程能力不足，表现为慢。现在工程能力不足，表现为快而失控。

如果需求没讲清楚，AI 会更快地产生错误代码；如果测试体系薄弱，AI 会更快地把风险推到上线后；如果Review 跟不上，AI 会更快地把问题混入主干......

所以，AI 没有杀死软件工程（或软件公司）。AI 只是把软件工程的重心从“写代码”，上移到软件生产的全过程。

过去优秀工程师的核心能力，是高质量地Coding；未来优秀工程组织的核心能力，是让人和 AI agent 一起，把复杂软件持续、可靠、低风险地交付出来。

二、全过程工具不等于能力

现在的软件工程工具已经非常强。

海外有 GitHub、GitLab、Jira、Confluence、Linear、Azure DevOps，也有 Codex、Claude Code、Cursor、Windsurf、GitHub Copilot 这样的 AI Coding 工具。

国内有 PingCode、ONES、禅道、云效、TAPD、CodeArts、通义灵码等产品。

这些工具正在从“项目管理、代码管理、DevOps”走向“AI 参与研发执行” —— 

• 需求被拆成任务

• 任务关联代码

• 代码自动生成

• 测试自动补充

• PR 由 AI 先做初审

• 发布灰度和回滚

  
  

这些能力，软件公司都应该用。

不用这些工具，AI Coding 带来的代码增速，很可能会把研发流程冲垮。

但也要看到另一面：工具能提升工程秩序，不能自动生成工程判断力；工具可以管理需求，但不能判断需求值不值得做；工具可以生成代码，但不能天然理解业务语义......

所以，谁都能买到的全流程工具是通用基础设施，不是核心竞争力本身。

软件公司真正的核心能力，不是用了哪一套工具，而是能否把这些工具组合成自己的工程闭环。

三、软件公司要“手搓”闭环

在具备大量工具后，软件公司真正要自己打磨的是：围绕自己的业务、客户、代码库、组织方式和质量标准，形成一套可持续进化的 AI 工程闭环。

这套闭环至少包括七个环节。

对我们这些已有大产品架构和既有成熟软件生产方式的SaaS公司来说，最难的是公司自己的业务认知能否工程化。

当然，最难的地方也是未来的护城河。如果没有难度，“一人软件公司（OPC）” 真的就能做复杂ERP和CRM了。

CRM 公司要让 AI 理解线索、商机、报价、合同、回款之间的业务关系。HR SaaS 要让 AI 理解招聘、入职、考勤、绩效、薪酬之间的业务边界。财税 SaaS 要让 AI 理解票、账、税、报表之间的合规约束。

这些东西，通用模型不知道。通用工具也不会替你自动沉淀。它只能从你的业务、客户、代码、测试和交付经验里长出来。

四、AI 生成代码越多，质量验证越重要

很多公司上 AI Coding 的第一感觉是：快。

但过去的工程风险出现在编码阶段，现在的风险出现在验证阶段：代码看起来能跑，但业务逻辑不一定对；测试看起来通过，但真实客户场景不一定覆盖......

AI 生成代码越多，质量验证越重要。Agent 越自主，权限、审计和回滚越重要。研发速度越快，业务回归测试越重要。

如果这些能力不补，AI Coding 不一定带来工程效率提升，反而可能带来更快的返工、更隐蔽的 bug 和更复杂的技术债。

所以，未来软件公司最值得投入的资产之一，不只是代码库，而是业务回归测试集。

我调研海内外Agentic Engineering最激进的企业，其中支付平台公司占比竟然很高，Stripe、Paypal、Block都在其列。涉及到资金的产品本来最应该保守的，却因为客户业务数字化程度高、测试用例完备，可以最早拥抱AI Coding。

每家 SaaS 公司都应该围绕自己的核心业务闭环，沉淀一套能长期复用的业务回归测试。

这套测试资产，表面上是质量工具，实际上是公司的业务认知资产。

未来 AI agent 能不能放心地改代码、补功能、重构流程，很大程度上取决于这套资产够不够厚。

五、工程师的角色不会消失，但会转向“监督工程”

AI 时代，软件工程师越来越多的工作会变成监督工程。

所谓监督工程是定义任务、组织上下文、拆分边界、设定约束、审查结果、修正偏差、沉淀规则。

过去，一个工程师拿到需求后，主要任务是自己实现。未来，一个工程师拿到需求后，可能先要判断：

• 这个任务能不能交给 agent？

• 需要给它哪些上下文？

• 需要限制哪些文件和模块？

• 需要先写哪些测试？

• 生成结果应该由什么标准验收？

• PR 失败后，是任务拆错了、上下文不够、测试不完整，还是 agent 能力边界到了？

说实话，我写过十多年代码，还干过投资千万级的软件项目经理，今天也没信心能把上面这些判断做得准。

过去的经验未必是资产，很多事情都得具体做了才知道该如何调整。

这也是为什么我前面的文章也提过，所有产研Leader最好自己先用AI Coding工具做个独立项目。

这要求工程师具备更强的判断力。因为AI既不可以替人定义什么是好代码，也不能替人判断架构边界、理解产品长期演进，更不能替人承担最终责任。

所以，AI 时代不是工程师变得不重要，而是工程师的低层重复劳动减少，高层判断责任增加。

我曾很担忧这个问题：一方面每年1000万大学生毕业；另一方面，“初级软件工程师”这类以前的高占比职位却逐渐消失了。

初级工程师过去通过大量写代码积累经验。如果大量代码由 AI 生成，初级工程师如何建立工程直觉？

中高级工程师过去靠经验做架构判断。如果 AI agent 大规模参与开发，他们如何把经验转化为规范、测试、约束和可执行的工程上下文？

这会成为软件公司新的组织课题。

六、客户结果验证，是 AI 工程闭环的最后一环

软件研发最终不是为了完成需求，而是为了产生客户结果。

所以，AI 工程闭环不能停在研发内部。

它必须连接客户结果。

参考我上篇长文，对 SaaS 公司来说，未来可以考虑用一个新的指标补充传统研发指标：

有效 AI 作业量，VAO，Verified Agentic Outcomes。

它衡量的是：AI agent 完成了多少经过业务验证、客户接受、结果可追踪的有效作业。

比如：

• AI 自动修复了多少经过测试和上线验证的 bug？

• AI 自动生成的功能，有多少被客户真实使用？

• AI 承接的客服、实施、数据处理、销售辅助任务，有多少被业务方确认有效？

  
  

如果没有客户结果验证，AI 工程化只会停留在内部效率。

如果能把 AI 作业和客户结果连接起来，AI 才会真正进入 SaaS 经营。

七、国内软件公司更要警惕“工具热、闭环弱”

对中国 SaaS 公司来说，更现实的路径不是一上来建设宏大的 AI 工程平台，而是分三步走。

第一步，补齐研发管理底座。

先把需求、任务、缺陷、测试、代码、发布、线上问题串起来。工具可以选国内的，也可以选海外的，关键是流程必须可见、可追踪、可复盘。

第二步，把 AI Coding 接入工程门禁。

允许工程师使用 AI 工具，但必须经过 issue、branch、PR、自动测试、review、安全扫描、灰度发布。AI 可以提速，不能绕过流程。

第三步，建设业务回归测试集。

把公司最核心的客户业务闭环，沉淀成可反复执行、可自动化验证、可持续扩展的测试资产。

这三步做完，AI 才可能从个人工具，变成组织能力。

八、总结

AI Coding 的出现，让软件公司看到了编码效率的提升。

但真正的竞争不会停留在这里，Codex、Cursor谁家都能用上。

真正拉开差距的，是公司自己的工程闭环：谁能更好地定义需求？谁能更好地组织上下文？谁能更好地设定权限？谁能更好地沉淀测试？

—— 仔细看看，这几点其实没有AI的时候也是如此啊

所以，软件公司真正要“手搓”的，是软件工程的闭环。

更准确地说，是一套能持续吸收新模型、新工具、新 agent 能力，并稳定转化为客户结果的 Agentic Engineering 闭环。

AI 没有让软件工程变轻。它只是让软件工程从写代码，上移到管理 AI agent、验证业务结果、沉淀组织能力。

过去的软件公司，比的是谁能更快、更稳地写代码。未来的软件公司，比的是谁能更快、更稳地把 AI 产出变成客户可验证的业务结果。这件事，不会由任何通用工具自动完成。