AI Coding 的下一步：从工具提效到知识驱动的研发变革
这篇文章最想纠正的误区，是大家太容易把“Agent 越强，研发就会自动质变”当成既定事实。作者的判断更冷静：企业级业务研发里，AI Coding 的提效已经发生了，但真正改变角色分工和流程形态的质变，还没有到来。
原因并不神秘。问题不主要出在模型不会写代码，而是出在很多复杂需求里，人并没有把任务目标、背景约束和领域知识稳定地交给 AI。
文章用了一个很有用的视角来看这件事：从“人 -> 系统”变成“人 -> AI -> 系统”之后，链路中间多了一层理解和转换，信息失真概率天然会升高。团队现在大量讨论的是 C 端，也就是 AI 怎么更好地规划、调用工具、生成代码；但 A 端，也就是人类怎么把复杂任务准确交给 AI，反而经常被忽略。
如果任务只是“升级一个 JDK 版本”或者“做一个活动页”，目标传达并不难，工具提效会非常直接。但企业内部的业务需求不是这样。它往往同时要求：
- 了解领域模型和业务流程
- 知道组织内部的技术栈和基础设施约束
- 遵守团队自己的代码规范、评审习惯和发布规则
- 在现有仓库里定位、修改并验证真实代码
也就是说，很多企业级需求并不是“AI 不会写”，而是“AI 不知道该在什么边界里写”。这一步如果还要靠人工临时拼接 Prompt、口头传授背景、反复补充上下文，成本就很难降下来。
原文最核心的判断，其实是把重心从“Agent 能力建设”往“专家知识沉淀机制”上挪。作者没有否认基础模型和 Agent 还会继续变强，而是强调业务研发团队真正能形成竞争力的，不在于自己去追逐每一波工具形态，而在于把专家知识变成可以被 AI 消化的长期资产。
文中把这个过程称为“系统性降熵”，我觉得很准确。今天很多团队的问题不是没有知识，而是知识到处都是：
- 跟着不同 Code Agent 方案各建一套知识库
- 把知识散在代码仓库、MCP 暴露的数据源、内部文档和个人经验里
- 上下文工程靠熟练工“手搓”，缺少统一标准
结果就是知识重复建设，输入方式各不相同，可复用性很差。看起来每个团队都做了很多工作，组织层面的规模效应却没有出来。
所以作者的建议不是“业务团队也去拼 Agent 底层能力”，而是反过来：把模型和工具看成会持续迭代的公共变量，把知识系统看成自己必须掌握的长期变量。
这篇文章后半段最扎实的部分，是它把业务研发需要提供给 AI 的知识按层拆开了。不是简单说一句“建知识库”，而是明确分成四层：
- 基础技术层：技术栈规范、中间件、CI/CD、安全与质量约束
- 业务层：领域模型、产品架构、核心流程、关键 API 和业务规则
- 团队层：团队约定、协作方式、开发习惯
- 仓库层：项目结构、模块索引、关键入口、精确代码定位
这个分层的意义很大。它说明业务研发真正缺的不是一个“万能提示词”，而是一套能让 AI 逐层补齐语境的知识供给系统。一个新入职但基础很强的高级工程师，如果拿不到这些信息，也同样不可能马上写企业业务代码。对 AI 来说，这件事没有本质区别。
文章还强调了两点，我觉得尤其重要。
第一，知识资产要统一管理，而不是绑死在某一个 Agent 或 IDE 上。否则工具一换，知识就得跟着重建。
第二，最难的是业务层知识，因为它最隐性、最易变，也最依赖人脑。这里不能指望架构师或开发者长期手工维护，而要走自动化提取加人工确认的路线。谁能把这件事做成，谁才可能在企业级 AI Coding 上获得持续优势。
原文不是在鼓吹“程序员要被替代”，它真正想说的是：一旦专家知识沉淀机制建起来，研发效率的瓶颈会从“写出代码”转向“定义目标、组织知识、做出架构判断”。
这会带来两个长期变化。
一个是研发流程会越来越完整地接入 AI。从需求理解、设计约束、编码实现到验收交付，知识层都会被提前注入，而不是只在写代码那一段出现。
另一个是程序员的工作重心会移动。作者把未来角色概括成更偏“产品工程师”和“业务架构师”，我基本认同。不是因为编码消失了，而是因为编码越来越像链路中的执行中段，真正稀缺的能力会更靠近问题抽象、系统理解和知识组织。
这篇文章的价值，不在于它给出了一个立刻可落地的标准方案，而在于它把企业研发里 AI Coding 的主要矛盾讲清楚了。很多团队现在还在追问“哪个 Agent 最强”“哪个 IDE 更好用”，但如果目标传达复杂度没有被工程化处理，工具升级带来的收益迟早会被手工补上下文的成本吃掉。
所以这篇文章真正值得带走的，不是“知识库很重要”这句空话，而是一个顺序判断：先承认企业级研发的难点在知识传递，再把专家知识当成独立系统建设，最后才谈工具如何接入和放大收益。这个顺序不对，AI Coding 很容易一直停留在局部提效。