自从AI有了写代码的能力我就开始用AI帮我写代码了。刚开始的时候我的提示词很简单“帮我写一个Python函数从数据库读取用户订单数据并生成报表”。效果时好时坏有时候AI写得不错有时候完全跑偏。后来我学聪明了开始写很长的提示词把需求列成十几条加上各种约束条件恨不得把整个需求文档都贴进去。结果呢AI反而更容易跑偏了。最离谱的一次我写了两百多字的提示词让它帮我重构一个模块它给出的代码跟我原来的功能完全不一样好像后面的约束把前面的核心需求覆盖了。折腾了一段时间我才搞明白提示词不是越长越好而是要结构化。这篇文章聊聊我这几个月琢磨出来的方法——怎么用XML标签来组织提示词让AI编程助手输出更靠谱。提示词为什么会越长越差先说说为什么提示词写长了反而不好用。这不是我的猜测LLM处理长提示词时确实存在一些结构性问题。第一个问题是语义模糊。纯文本里你的指令、背景信息、示例代码全部混在一起模型很难分清哪些是必须遵守的命令哪些是仅供参考的上下文。比如你写用Django框架支持RESTful API前端用Vue注意安全性AI可能把注意力分散在这几个点上没有主次顺序。第二个问题是注意力衰减。长提示词越往后模型对开头部分的注意力就越弱。你前面写的核心要求可能被后面的一大段示例代码给冲淡了。第三个问题是格式失控。用自然语言描述输出格式比如返回一个JSON包含name和age两个字段有时候AI会给你一个纯JSON有时候会连解释文字一起输出格式很不稳定。XML标签能解决这些问题因为它给模型提供了明确的信息边界。模型在预训练阶段读过海量的HTML/XML代码对它来说标签结构基本算母语。核心思路用XML画边界线结构化提示词的思路很简单用XML标签把不同的信息模块隔开。每个标签是一个围栏让模型知道这个区域里是什么东西、该怎么处理。最基本的四层结构是这样的role你是一个资深Python后端开发熟悉Django和FastAPI框架/roletask把这个User模型的服务层重构一下加上缓存逻辑减少数据库查询/taskcontext!-- 当前项目的相关代码放在这里 --/contextrules- 不要修改模型定义 - 缓存使用Redis过期时间设5分钟 - 保持现有的函数签名不变/rules模型看到role就知道这是设定我身份的看到task就知道这是我要做的事看到rules就知道这是硬约束必须遵守。信息边界清晰了模型就不容易搞混。两个实战场景的对比光说理论没意思直接看两个我实际工作中遇到的场景。场景一代码审查纯文本写法帮我review一下这段代码看看有没有性能问题特别是数据库查询那块还有异常处理是不是完善了另外代码风格要检查一下变量命名也要注意。对了也看看有没有SQL注入风险。这种写法我用了很久。问题在哪AI给出的review经常漏掉某些检查项。你让它查5件事它可能只认真查了3件。换成结构化写法role你是一名代码审查专家擅长Python性能优化和安全审计/roletask逐项审查以下代码/taskchecklist1. 数据库查询是否有N1问题 2. 异常处理是否覆盖了所有可能的异常类型 3. 是否存在SQL注入或XSS风险 4. 变量命名是否符合PEP 8规范 5. 是否有不必要的循环嵌套/checklistcode!-- 待审查的代码 --/codeoutput_format对每项检查点给出状态通过/有问题、具体位置、修改建议/output_format用了这个结构后AI的review结果完整多了。checklist标签里的每一项都会被逐个对应漏检的情况少了很多。场景二复杂功能开发有一次我需要写一个文件批量处理脚本需求不复杂但细节多支持多种文件格式、有进度条、能断点续传、错误要记录到日志。纯文本写法写一个Python脚本处理文件夹里的文件。支持PDF、Word、Excel格式。处理每个文件时显示进度。如果脚本中断了下次运行从上次中断的地方继续。出错了记到日志里。日志文件放在./logs/目录下。用argparse处理命令行参数。文件用多线程处理。每个文件处理完把结果存到SQLite里。结构化写法role你是Python自动化脚本开发专家/roletask开发一个文件批量处理脚本/taskspecsinput命令行指定目录路径通过argparse接收/inputformatsPDF、DOCX、XLSX/formatsprocessing多线程并发处理线程数通过--workers参数指定/processingprogress使用tqdm显示实时进度条/progressresume每处理完一个文件记录到SQLite重启时跳过已完成文件/resumelogging错误日志写入./logs/error.logINFO级别日志写入./logs/app.log/logging/specsconstraints- 单个Python文件不拆模块 - 依赖只用标准库tqdmpython-docxopenpyxlPyPDF2 - 每个函数加上docstring - 主函数入口用if __name__ __main__/constraintsoutput_format只输出完整Python代码不要加任何解释文字/output_format两种写法的差别很明显。结构化版本让AI清楚每个需求属于哪个类别输出的代码也更完整不会出现忘了加日志或者进度条没接上这种遗漏。我总结的几个实用技巧试了几个月有几个经验值得说。第一标签不需要很多四个核心就够了。日常开发中roletaskrulesoutput_format这个组合覆盖了90%的场景。不要一上来就搞七八个标签反而容易把重点冲淡。第二rules里分必须做和不能做。我用must和must_not来区分比混在一起清楚得多rulesmust使用requests库发起HTTP请求/mustmust所有API调用加上超时参数/mustmust_not不要使用全局变量/must_notmust_not不要在函数内部修改外部状态/must_not/rules第三few-shot比长篇描述管用。如果你想让AI按某种风格输出与其写一大堆描述不如给一两个示例。用example标签把示例包起来exampleinput用户输入的内容/inputexpected_output你期望的输出/expected_output/example第四不是所有场景都需要结构化。简单的一句话需求比如把这段代码里的变量名改成snake_case用结构化提示词纯粹是浪费。只有当需求涉及多个维度、多个约束的时候XML标签的收益才明显。第五标签名要有意义。别用tag1、box这种没意义的名字。标签名本身就是语义信号task和rules在模型训练数据里出现过很多次它天然知道怎么处理这些标签。遇到过的坑说说我踩过的坑。标签忘闭合。写了rules忘了/rules后面的内容会被模型当成rules的一部分整个提示词乱掉。我现在的习惯是写开标签的同时就把闭合标签打上再往中间填内容。嵌套超过三层。我有次搞了个四层嵌套模型直接懵了输出质量反而下降。控制在两层最多三层再复杂的结构拆成多个平级标签块。内容里有特殊字符。如果你的代码里包含和记得转义成lt;和gt;不然XML解析会乱。或者用CDATA包裹code![CDATA[ def compare(a, b): return a b ]]/code这几个月用下来结构化提示词让AI编程工具的可靠性确实上了一个台阶。以前像抽卡写一段提示词看AI能不能猜对你的意思现在至少能把猜的概率降到一个可控的范围。如果你试了觉得不好用大概率不是方法本身有问题而是标签设计没对上你的需求场景。刚开始可以直接套文中的模板根据自己的场景慢慢调。大家有自己用着顺手的提示词组织方式欢迎评论区聊聊。
