模型够强，写代码就不愁——这个假设在真实业务需求面前不堪一击。一家厂商技术团队在多机房、跨前后端的存量系统上做 AI 编码冷启动时发现：限制落地的不是推理能力，而是两件更基础的事——AI 能看到的信息不够干净，想让它做什么说得不够清楚。他们基于一个消息互动策略引擎项目的方法论实践，把交付时间压缩了三分之二。这篇把方法骨架和可迁移的经验拆出来。
三个共性问题
背景缺失：关键决策不在代码里，而在文档、群消息、会议纪要甚至开发者记忆里。AI 缺了这些背景，只能写出语法正确、架构跑偏的方案。需求模糊：需求散落在 PRD 和聊天记录里，编码时没有一份完整说明，AI 靠上下文自行补充，补着补着就偏了。经验留不住：会话窗口一关能力归零，个人摸索的经验变不成项目资产。这三条在跨多个存量工程、多机房、前后端同时改动的场景被急剧放大。
上下文工程：先决定给什么，再谈怎么说
材料比措辞值钱。
实践中同一需求喂不同材料，产出质量天差地别。与其反复打磨提示词措辞，不如想清楚这次会话该放进哪些代码、文档、约束。可操作的原则有三条：会话长期状态与单次任务输入分开管理；上下文按命名清楚、顺序固定的模块拼装；每个执行环节只加载最小必需信息，不够再通过工具现场取。落到工程上，在代码库根目录维护一份项目说明，写清架构、编码约定、历史坑点，作为跨会话的长效记忆——AI 开发前已经把项目看懂，而不是一边写一边猜。
规格驱动：把人的判断前置
规格驱动的递进层级有三档：规格优先、规格锚定、规格为源。务实的选择是不追求规格自动生成全部代码——那对形式化程度要求太高，现实业务满足不了——而是规格先行加 AI 实现、自动化测试、人工评审把关。判断做什么、不做什么、怎么验收的决策权留给人，AI 在约定边界内把活干快干稳。价值在歧义消除上：比如商业账号与策略的绑定关系、超时无回复时流程由谁推进，这类问题不前置澄清，实现出的调度逻辑必然跑偏。
知识沉淀的三种打包方式
经验别锁在个人会话里。
让 AI 能力从个人本事变成团队资产，靠三种形式。技能封装：把编码规范、安全审查要点、中间件用法整理成可加载的技能文件，每个会话默认携带，相当于把资深工程师的经验预制进工具。负向约束沉淀：AI 反复踩同一个坑时，把教训写成不允许这样做的约束进项目规范，后续会话天然绕开，不靠人盯。效能飞轮：每次交付后把新约束、新约定回写知识库，AI 反复犯的错同步固化成规则。
冷启动的执行顺序
方法内核是两条主线构成循环：历史知识沉淀回答 AI 凭什么看懂项目，范式化开发回答需求来了怎么做对。执行顺序严格是先沉淀再开发：知识盘点（以"AI 必须知道但代码推断不出来"为标准筛出多机房转发链路、业务全流程、外部平台对接规范三类）、结构化组织（主文档答系统是什么、细节放独立引用文档）、按需加载（一次会话塞得越少注意力越集中）、持续回写。然后每个新需求走五阶段闭环：需求规格化、规格评审、受控实现、验证联调、知识回写。
可迁移的验收建议
照这套方法落地，验收看四个指标：AI 生成的架构决策与既有架构的一致率——盘点出的项目说明是否真的被会话消费；同一需求的重做次数是否随技能沉淀递减；负向约束命中情况——历史坑点是否在新需求中零复发；交付周期对比。冷启动最大的误区是跳过沉淀直接让 AI 写需求，结果每个会话都在盲人摸象——先给 AI 一张系统地图，再谈效率，顺序和源团队的实践一样，不能反。
评论0