复杂任务很少能靠一句提示词稳定完成。即使模型能写出正确的局部代码，也可能找错文件、理解错约束，或者在缺少验证时过早宣布完成。
一种更实用的思路，是同时设计三个部分：让它看到什么、让它怎样推进，以及让它在哪些地方停下来核对。
上下文：提供当前步骤需要的材料
把整个资料库一次塞进对话，并不等于已经建立了项目理解。材料中可能混有旧版本、无关日志和互相冲突的描述。输入量增加，筛选负担也会增加。
可以先给一份任务简报：
- 目标：要改变哪一个用户行为，完成后能看到什么结果。
- 现状：相关入口、关键文件、已有规则与已知限制。
- 约束：兼容要求、允许修改的范围、必须保留的行为。
- 证据：复现步骤、输入样本和当前报错。
- 验收：用什么操作证明结果符合要求。
这份简报是起点。执行中发现新的依赖，再补充对应材料；需求发生变化时，标明哪个版本生效。
流程：让中间结果可以被检查
一个通用的编码流程可以是：理解现状 → 确认问题 → 形成方案 → 实现一个可验证的改动 → 验证 → 交付。
重点不在步骤数量，而在每一步留下什么证据。例如“理解现状”的产物应当包含现有入口和关键依赖；“完成验证”的产物应当是实际运行结果，而不是一段预期描述。
对于路径明确的重复任务，固定工作流通常更容易检查；对于需要探索的问题，可以给 Agent 更多选择空间，同时设置检查点。Anthropic 的实践文章也区分了预先定义执行路径的工作流与由模型动态决定步骤的 Agent。这里借用的是这种设计区分，不是某个产品版本的操作教程。
边界：把关键动作写清楚
在任务开始前，说明哪些动作可以直接执行，哪些动作需要满足条件。例如允许修改指定目录和运行本地验证；发布前必须核对版本与验证结果；涉及不可逆的数据操作时先准备备份和恢复办法。
边界越具体，越容易落实。仅仅写“注意安全”“不要乱改”，很难帮助 Agent 判断下一步。
检查点也应根据风险设置：修正一个文案与变更生产数据，不需要采用相同的流程。
RAG：补充材料，也需要核对材料
检索增强生成把外部检索结果带入生成过程。它能帮助系统取得模型参数之外的资料，但最终表现还受资料质量、检索结果、推理和验证方式影响。
因此，接入资料库之后仍要检查：是否检索到正确版本，是否遗漏关键限制，引用能否回到原文，以及答案是否超出了证据。代码任务还需要顺着调用、依赖和数据流理解关系，不能只因为两段文字相似就认为它们可以互换。
开始前的三个问题
- 当前步骤需要哪些事实，哪些内容只是背景？
- 下一步会产出什么可以核对的结果？
- 出现偏差时，怎样及时发现并恢复？
把这三个问题回答清楚，比单纯增加提示词长度更容易形成可维护的协作方式。具体效果仍需用真实任务验证。