北京
模型能力在快速提升，但进入真实业务系统后，AI 依然会遭遇大量信息缺口——历史设计原因、规则适用范围、代码当前状态，这些信息如果每次都靠人在对话里重新讲解，AI 的表现就会受制于对话长度和个人表达能力，结果不稳定。大淘宝技术团队在实践总结中指出：业务 AI 研发的真正瓶颈是上下文，而非模型能力。
这个判断来自他们从 AI 辅助编程走向完整 AI 驱动研发体系的探索。团队提出的解法是"本地优先：Agent + 文件夹 + Git"——把业务知识、源代码、项目规则和验证证据组织在同一个工作空间里，让 Agent 直接操作文件系统，同时连接外部动态事实，构建稳定、一致的上下文。
迭代过程本身就是知识飞轮
这套体系里，每个迭代阶段都在为下一个阶段生产上下文。PRD 补充业务定义，技术方案记录系统链路，测试校验它们，归档时再把确认后的知识回流到 wiki。知识建设成为真实产品迭代的副产物，再逐步变成后续迭代的加速器。
关键点在于：项目开始时无需完美知识库。团队通过 Price360-KB 项目验证了这一点——在真实产品迭代中持续完善知识，而不是等知识库建好再启动。迭代过程本身就是知识飞轮，越转越快。
三层结构：项目 Harness 怎么设计
项目 Harness 采用三层结构设计，把上下文、规则和验证证据组织成机器可读的形态。配合机器可读的迭代协议，Agent 能检索上下文、生成产物、执行检查、调用工具、收集证据；人负责描述需求、选择方案、确认测试设计、验收预发结果，以及授权合并和生产发布。
这种分工的核心是：人负责决策，Agent 负责把决策执行完整。Harness 把人的业务判断传递到后续文件、代码、测试和状态中，在缺少证据或越过授权边界时阻断流程。人不再需要持续看护操作步骤。
未来：技术人员更接近 FDE 角色
文章预判，随着模型和通用 Agent 能力继续提升，项目 Harness 会收缩，但业务知识治理和质量责任不会消失。未来技术人员将更接近 FDE（前端开发工程师）角色，需要深入理解业务、设计项目规则，并对端到端交付结果负责。
文章金句点明了这个趋势："业务 AI 研发的上限不只由模型决定。模型决定通用能力，上下文决定它在具体项目中能走多远。"当模型能力继续扩大，业务技术人员真正需要守住的是对业务的理解、对系统的连接能力，以及对结果的责任。
这套实践给团队的启示是：与其等一个完美的知识库，不如让知识在迭代中自然生长。上下文不是一次性建好的，而是在每个 PRD、每份技术方案、每次测试归档中持续积累的。当知识飞轮转起来，AI 在具体项目中的表现才会真正稳定。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
