上周，组里新来的实习生用GPT-5 Turbo，三小时搭了个内部数据看板。演示时挺惊艳，结果上线第二天就炸了17个bug：日期格式解析错、空值没处理，还有个API端点压根没做鉴权。
这场景不陌生吧？AI写代码是快，但直接扔进生产环境，跟买彩票差不多。
问题不在工具，在我们喂它的方式。
代码生成：先写规矩，再让AI填空
我现在的习惯是：先写约束，再让AI干活。
比如生成文件上传接口，我不会说“写个上传接口”，而是这样写提示词：
技术栈：FastAPI + PostgreSQL，Python 3.11
输入：multipart/form-data，文件大小限制10MB，仅接受 .csv/.xlsx
输出：JSON格式，包含 job_id 和 status 字段
边界：并发上传数≤5，超时自动清理临时文件
关键点是：AI擅长补全，但不擅长兜底。上下文越精确，生成的代码需要手动修补的地方就越少。团队实测，用这种约束模板生成的代码，集成测试通过率能从40%拉到85%以上。
另一个技巧是分层生成。别让AI一口气写完整个模块。先让它输出数据模型和接口定义，review通过后，再写业务逻辑层。每层插个人工检查点，比事后debug高效得多。
最近注意到一个动向：小模型在代码生成场景的性价比越来越高。像VibeThinker这类7B参数的模型，经过特定领域微调后，在垂直场景的表现能逼近通用大模型。这意味着可以用更低成本跑本地推理，不用每次都调API。
RAG文档处理：别让AI“瞎猜”
文档处理是AI最容易出错的场景。太多团队直接把PDF扔进向量数据库，指望RAG系统精准回答——结果往往是“一本正经地胡说八道”。
我的方案是三步结构化：
第一步：预处理清洗。 喂给AI之前，先用脚本把文档拆成结构化块。标题层级、表格、图表标注单独提取。现在主流的RAG框架（比如LlamaIndex 0.11+和LangChain 0.3+）都支持自定义文档解析器，可以针对不同类型文档写不同的拆分策略。
第二步：元数据标注。 每个文档块打上标签：来源文档、章节位置、更新日期、可信度等级。这步看似麻烦，但能让检索精度提升至少30%。特别是处理法规、合同这类对时效性敏感的文档时，元数据能帮你过滤掉过时信息。
第三步：检索后校验。 AI生成答案后，别直接返回给用户。加一层校验逻辑：检查引用的文档块是否存在、引用内容是否被正确转述、答案是否超出文档覆盖范围。超出的部分，强制标注“此部分为AI推测”。
这套流程编码量不大。我用FastAPI写了个中间件，核心逻辑不到200行，就把内部知识库的问答准确率从“勉强能用”提到了“可以直接给客户看”。
Agent协作：给AI划好“责任田”
多Agent协作现在很火，但也最容易失控。一个Agent调另一个Agent，信息层层传递，最后输出可能已经偏离原始意图十万八千里。
我的经验是：单Agent单职责，通信走契约。
具体做法：把复杂任务拆成多个独立Agent，每个只负责一个明确任务。比如一个“需求分析Agent”，输出格式是固定的JSON schema，包含用户故事、验收标准、技术依赖列表。下一个“架构设计Agent”只接收这个JSON，不接收原始需求文本。
这样一来，每个Agent的输入输出都是可预测、可验证的。出问题时，能快速定位哪个环节出错。
通信协议上，推荐用函数调用（Function Calling） 而不是自由文本。现在主流模型（GPT-5系列、Claude 3.5 Sonnet、Gemini 2.0等）都对函数调用支持很好。你定义好每个Agent暴露的工具和参数，模型会严格按schema生成调用指令，比让它“自由发挥”可靠得多。
一个实际案例：内部的周报自动化流程。过去一个Agent要完成“收集Jira数据→分析完成情况→生成文字摘要→发送到飞书”整个链条。现在拆成四个Agent，每个独立测试、独立部署。周报质量肉眼可见地提升，而且如果Jira接口挂了，其他三个Agent照样能跑，不会整个流程瘫痪。
工具不是瓶颈，工作流才是
回到开头那个实习生。后来帮他重构了流程：代码生成加上约束模板，前端组件用小模型本地跑，API层走分层生成加人工校验。同样的看板功能，重写花了两天，但上线后零bug。
AI工具的效率提升不是魔法，是工程。需要像设计软件架构一样设计AI工作流：定义好输入输出契约、加上校验和兜底逻辑、拆分职责让每个环节可验证。
随着小模型生态的成熟和Agent框架的标准化，这套方法的实施成本会进一步降低。但核心原则不变：AI负责提效，人负责把关。 顺序搞反了，再强的工具也只是个昂贵的玩具。