导语
开发者在用 AI Coding Agent 时，经常会遇到一个现象：需求写得并不完整，Agent 却能补出一套还算像样的实现方案。
这不是因为模型真的知道业务现场，而是因为它把大量代码、文档、Issue、PR、技术问答里的模式压缩进了参数里。
但这个能力有边界。做工程落地时，理解这个边界比单纯夸模型聪明更重要。
正文
1. 模糊需求为什么能被模型理解
开发现场很少有完美需求。
常见输入可能是这样：
这个规则执行模块要支持一条规则跑多个 encounter。
部分失败不能影响整体。
返回要有汇总统计。
candidate_retrieval 不满足就直接未命中。
这段话并没有完整说明数据结构、接口协议、错误码、执行流程、字段含义。
但模型通常能补出一些合理结构，比如：
RuleExecutor
EncounterDataLoader
ExecutionItemResult
ExecutionSummary
is_hit
error_code
items[]
原因不复杂。
模型见过大量类似工程文本：接口文档、后端设计、异常处理、批量任务执行、结果汇总、规则引擎、测试用例。
它把这些模式压缩成了可复用的生成能力。
所以当需求里出现“批量”“部分失败”“汇总统计”“错误码”这些信号时，模型会自动展开成一套常见工程结构。
2. Agent 的理解，很依赖上下文管理
Agent 能不能做对，不只取决于模型参数，也取决于上下文给得是否足够。
比如让 Agent 改一个接口，如果只说：
改成新的返回结构
它大概率会乱猜。
如果补充：
统一返回结构为 code/message/data。
发送消息接口入参是 list<message>。
message 只包含 role 和 content。
返回字段只有 is_complete、detailed_rule_understanding、assistant_response。
删除无用 session 代码。
模型就能把任务拆得更准：
修改 schema
调整 controller
清理 service 中的 session 依赖
更新前端请求结构
补充错误响应
同步接口文档
这说明 Agent 的“读懂”，不是凭空发生的。
它需要上下文作为解压依据。
上下文越明确，模型越不需要脑补。脑补越少，工程风险越低。
3. Skill、RAG、工具调用，本质是把压缩拆到外部
在复杂系统里，不能只依赖模型参数里的压缩结果。
因为参数里的知识有几个问题：
不可控
不可追溯
不一定新
不一定符合当前项目约束
所以实际做 Agent 时，常见做法是把一部分知识放到外部：
Skill：沉淀固定流程和操作规范
RAG：补充项目文档、业务规则、接口说明
Tools：执行真实查询、测试、文件读写、构建命令
Memory：保留长期偏好和历史决策
这几个东西不是为了显得架构复杂，而是为了减少模型乱猜。
比如规则引擎里字段路径必须来自标准数据结构，这种约束就不应该只放在一句提示词里。更合理的做法是把数据结构、合法 path、字段类型、可用算子放到明确的上下文或校验工具里。
模型负责理解和生成，程序负责校验和执行。
这是 Agent 工程化的基本分工。
4. 不能把“会补全”当成“能负责”
模型很擅长补全工程模板。
接口文档缺字段，它会补。 异常码缺分类，它会补。 前端页面缺状态，它会补。 单测缺用例，它也会补。
但补出来的东西未必符合当前系统。
比如：
它可能新增不存在的字段
它可能假设数据库表结构
它可能忽略历史兼容
它可能把业务失败写成系统异常
它可能让前端和后端返回结构不一致
这就是把语言规律直接当工程事实的风险。
模型压缩的是通用工程经验，不是你的项目真实状态。
所以在 Agent 开发里，一定要有校验层：
schema 校验
字段路径校验
类型校验
接口契约测试
单元测试
端到端测试
日志和回放
模型负责生成候选方案，工程系统负责把候选方案变成可信结果。
5. 提示词不是越长越好，而是越可执行越好
很多失败的 Agent 提示词有一个共同问题：写了很多原则，但没有给模型可执行约束。
比如：
要严谨
要高质量
要符合最佳实践
不要出错
这些话作用有限。
更有效的是：
只允许修改 backend/api/rule_executor 下的文件。
接口返回必须符合 BaseResponse。
field_path 必须来自 searchable_paths。
表达式只允许比较、布尔、in、len/any/all/sum/min/max。
遇到 encounter 不存在，返回 ITEM_NOT_FOUND。
允许部分 item 失败，并在 summary.failed_count 中统计。
这种提示词不是情绪要求，而是工程约束。
模型更容易根据这些约束展开任务，也更容易被测试验证。
结尾
大模型能理解模糊需求，是因为它压缩了大量语言和工程模式。
但在真实开发里，不能只依赖这种“压缩后的经验”。
Agent 要落地，需要把隐含知识外显出来：文档、Schema、工具、测试、校验、日志、回放，一个都不能少。
模型可以帮我们更快生成代码和方案，但工程质量仍然来自明确约束和可验证流程。
把模型当成一个强补全器，比把它当成一个全知工程师更安全。
