过去一年，软件公司讨论 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 产出变成客户可验证的业务结果。这件事，不会由任何通用工具自动完成。
