很多AI任务失败，不是因为模型不会改代码，而是它读错了上下文。它可能信了过时的文档，把路线图当成既定事实，把AI辅助说明当成产品规则，从一个失败样本过度泛化，或者找到一个同名但已废弃的实现。
这就是为什么项目专属的AI交付流程不该简单让AI"读取整个仓库"。它应该为任务准备一个上下文包。
更多上下文并不总是更好。把所有东西都塞给AI很诱人，但在真实项目中，这往往让结果更糟。太多上下文会分散模型注意力。混乱的文档让临时决定看起来像是永久性的。过长的对话历史可能复活已经被否决的方案。
项目需要的是窄上下文，而非最大上下文。窄上下文意味着任务只获得它需要的事实，误导性材料默认不被暴露。
真相来源必须明确。上下文包里最重要的字段就是真相来源。在代码库中，当前代码和测试往往比旧文档更权威。在产品项目中，公开的能力声明应该基于README、用户文档、发布产物和可运行的演示。在知识发布系统中，公开内容必须追溯到来源，而非仅依赖摘要。
没有明确的真相来源，AI倾向于把可用材料当成同等可靠。这很危险，因为真实项目材料存在层级：代码和测试可能优于旧文档；当前产品文档可能优于早期路线图；项目本地事实可能优于中央方法论；原始证据可能优于AI摘要；公开声明必须比内部计划更保守。上下文包应该声明这些优先级。
一个实用的上下文包可以很简单：与任务相关的项目规则、真相来源文件、相关的规格说明、架构决策记录、问题、PR或运行手册、相关的测试、固件、截图或追踪记录、已知失败、验证命令、可能被修改的文件、绝不能碰的文件、以及上下文冲突时的优先规则。这比让智能体自己搜索整个仓库更可控。
通用智能体工具能提供强大的模型、shell访问、文件编辑、MCP、子智能体和钩子。但它们默认无法知道你项目的真相层级。比如，TidalFi的工作者必须知道哪些路径涉及资金、交易、KYC或生产发布；SketchUp Agent Harness的工作者必须知道设计模型、来源证据和SketchUp场景如何关联；知识发布工作者必须知道知识库拥有双语候选内容，而网站拥有渲染和部署。
这些不是通用工具事实，而是项目上下文。上下文包还能防止过度泛化。AI很容易把一个例子变成通用规则。在调试任务中，如果智能体看到一次失败的测试，它可能假设整个模块都有问题。上下文包可以标记："这是一个孤立的回归，不要重构整个子系统。"
上下文包也防止权限蔓延。如果没有明确的边界，AI可能修改它不该碰的文件。上下文包应该列出禁区：配置文件、认证逻辑、计费代码、合规审计日志。这些不是建议，是约束。
构建上下文包不需要复杂基础设施。它可以是一个脚本，为每个任务组装相关文件；可以是CI中的预检查，在智能体运行前验证上下文；可以是代码库中的约定，比如.context/目录存放规则文件；也可以是任务模板，为重复工作类型预填充上下文。
关键转变是从"让AI读一切"到"告诉AI该读什么"。这不是限制AI，而是给它正确的输入。当上下文包明确、有优先级、针对任务时，AI表现更好。它做出更少假设，遵循实际规则，避免已知的死胡同。
项目专属的AI交付流程应该投资在上下文准备上，而不是更大的模型或更多的token。正确的上下文让普通模型做出好决策。错误的上下文让最好的模型失败。
热门跟贴