上下文瓶颈才是AI研发真正的绊脚石：项目Harness实战方法论

当业界普遍将目光聚焦于大模型能力突破时，另一条更务实的技术路径正在悄然成型——从AI辅助编程工具的局部提效，走向完整的AI驱动研发体系。这条路径的实践者发现，业务AI研发的真正瓶颈从来不在于模型有多强大，而在于能否为AI提供足够精准、持续更新的上下文信息。Price360-KB项目的探索表明，当上下文治理成为研发体系的核心工程问题，AI的效能才能真正释放。本文将系统梳理这一实践的方法论与核心洞察，为正在探索AI驱动研发的企业提供可落地的参考框架。

模型能力的边界与上下文的天花板

大模型能力的快速迭代正在刷新我们对通用智能的认知上限，然而当这些强大的模型进入真实业务系统时，却常常表现得像个不了解项目背景的新手。它不知道某段代码是当前链路还是历史遗留，不知道某个业务规则只适用于特定场景，更不知道项目积累的设计决策背后有着怎样的权衡逻辑。这种信息缺口不会因为模型更强就自动消失，反而会因为AI被赋予更复杂的任务而变得更加突出。业务AI研发的天花板，由模型能力和上下文质量共同决定，前者决定通用能力的基线，后者决定在具体项目中能走多远。

本地优先：文件夹+Git的轻量化知识治理

面对上下文瓶颈，一种务实且高效的解法正在被验证——以本地文件夹为载体，以Git为版本控制核心，构建轻量级的项目知识治理体系。将业务知识、源代码、项目规则、验证证据组织在同一工作空间，通过Git的分支、提交和评审机制管理知识演进，无需建设复杂的知识管理平台。这种「本地优先」理念的核心在于：稳定上下文进入Git实现版本化管理，动态事实通过MCP或CLI从权威系统实时查询，两者在Agent执行时汇合。知识更新路径越短，与真实代码发生漂移的机会就越少。

三层结构构建可演进的迭代闭环

在通用Coding Agent之上叠加项目级Harness，形成可演进的研发闭环机制。协议层定义事实源、研发阶段、人工决策点与授权边界，明确人机协作的职责划分；能力层将PRD撰写、技术方案设计、测试用例生成、故障排查等任务封装为可组合的领域Skill；执行层通过确定性脚本完成工作区检查、产物校验、状态同步和发布门禁。三层结构各司其职：协议说明应该怎样做，Skill组织任务执行，脚本把不能靠语言自觉保证的质量门禁执行到底。这种分层设计使得项目规则可以独立于模型或Agent产品迭代，当模型能力增强时，项目Harness可以收缩而非堆叠。

知识飞轮驱动持续迭代与价值沉淀

迭代过程本身就是知识生成的最好时机，而非等知识库完善后才开始使用AI。每一次需求从PRD到归档的完整循环，都在为下一个循环生产上下文——PRD补充业务定义，技术方案记录系统链路，开发和测试继续校验这些链路，归档时再将确认后的长期知识回流到wiki和tech文档。知识会反过来影响下一轮迭代：有了业务规则，Agent写PRD时不需要从零推测概念；有了跨系统链路图，技术方案更容易找到真正的改造点；有了历史用例，测试也不用每次重新发明验证方法。因此项目不需要一个完美的知识库起步，知识建设可以成为真实产品迭代的副产物，逐步演化为后续迭代的加速器，形成正向飞轮效应。

当模型和通用Agent能力持续增强，项目Harness的边界会相应收缩，但业务知识治理、质量责任和端到端交付结果负责的角色不会消失。未来技术人员将更接近FDE角色，深入理解业务逻辑、设计项目规则、连接系统能力，并对最终交付结果承担完整责任。这不是AI取代人，而是人机协作边界的一次重新校准——让人的判断力与AI的执行力在正确的分工中各尽其能。