在之前的文章中，曾向大家推荐过一种更高效的人与大模型交互方法：即通过编写Spec文件来与Agent进行交互，其本质是通过结构化提示词文件，更有效地驱动AI辅助编码工具完成任务。这种方法提供了一种有效的实践路径：通过编写包含总体任务目标、多个分解任务描述、回溯检测动作、外部引用文档地址、以及明确的约束条件等关键信息的Markdown格式文件，可以有效引导Cursor、Windsurf、Cline等辅助编码工具，获得远超简单提示词的执行效果。根据我在AI辅助编码、代码评审等领域的实践经验，结构化提示词不仅能有效指导大模型工具高质量地完成任务，还能降低工具行为失控的风险。近期，我注意到新推出的Gemini-Cli、AMP等工具也都采用了结构化提示词的方式（非强制，但推荐实践），这也表明结构化提示词能够大幅提高人机交互效率，已成为业界的普遍共识。这种提效作用并非仅限于AI辅助编码工具，而是普遍适用于各类AI Agent。本文中，我将结合这一行业趋势和我的实践体会，深入分析结构化提示词的优势与应用。欢迎大家指正。人使用AI Agent的根本目的，在于追求生产效率的提升，这实质上是对现有生产工具的一次变革。正如交通工具从步行演变为马车，再进化到汽车，每一次演进都指向更高的效率和能力。我们使用Agent的阶段也从简单的大模型交互，发展到如今的Agent模式。大模型的作用也从完成简单任务的人机协同，发展到可以独立完成复杂任务的Agent。在大模型简单交互阶段，我们提出一个问题，大模型直接回复一个答案。随着模型能力的快速迭代和增强，我们已不再满足于一问一答式的交互，转而追求其独立完成更为复杂的任务。因此，我们也从简单的提问，发展到需要为Agent提供一份完整的执行规划的阶段。假设你希望工程师来实现一个公众号文章查询的功能。新手小A接到这个要求后，可能会直接上手开始开发；而有经验的小B，可能会主动追问你“同时支持多少人访问？”“权限管控措施是什么？”“是否需要审计日志？”等问题；资深的老C则会更进一步，首先和你深入探讨这个需求的目标、期望解决的核心问题，以及最终用户群体，然后再针对性的讨论具体实现细节。小A具备开发所需要的基础技能，但缺乏深入了解任务背景的经验（上下文理解能力不足）；小B有了解项目背景的意愿，但其经验积累仍显不足（上下文获取和关联能力有限）；而老C这些年，掉了太多次坑，改了太多屎山代码，积累了丰富的实战经验（强大的上下文处理能力和庞大的知识库体系），使其处理起问题来更加的游刃有余。如果我们将上述例子中的程序员替换成Agent，现阶段大部分Agent的行为表现，确实更接近程序员A。它们通常不会对问题进行进一步追问，更不会主动尝试了解您的最终意图。究其原因，这与大模型的上下文处理能力、Agent的处理机制等都有密切关系。这个特点就是导致你觉得Agent不好用的一个很重要的原因。从模型能力来看，其已经具备了处理复杂任务的能力，并且仍在快速成长。但从实际表现来看，总觉得有些差强人意。要么感觉效果不达预期，要么用起来总是不那么放心。但是不用吧，你又担心自己错过AI行业的发展。总之，就是既怕Agent没用，又怕Agent乱来的矛盾心理。产生这种感觉的根本原因，可能就是人对模型的期待已从简单的协助升级为独立处理复杂任务，但同时，我们与Agent的交互方式，却仍停留在简单的会话阶段。我们期待模型能够独立完成复杂任务，同时又期待它能理解我们缺少背景信息的简单提示词。我们希望模型能更懂“我”，但从实际表现来看，Agent的行为有时确实更像直男，它的“直”都体现在输出结果上了。所以在现阶段来看，我们不能完全指望模型来进行主动追问，它在这方面还存在诸多不足。从大模型的工作原理来看，其是结合训练数据和给定输入来预测最可能的下一个输出Token。它们不具备人类意义上的深层意图理解，也缺乏人类社会所共有的共识和各类暗知识（即未被明确表达的上下文信息）。当提示词过于简单和模糊不清时，模型的输出预测会面临过多的可能性，从而导致生成关联度和准确度不高的输出。1. 不一致性与可变性高：由于目标定义过于模糊和宽泛，模型的输出结果往往不稳定，甚至出现较大差异，表现出较低的一致性和可靠性。例如，“做一个AI聊天网站”就不如“参考ChatGPT网站，使用Next.js框架创建一个聊天网站”更加准确。2. 缺乏有效控制：由于缺少明确的约束信息，模型难以准确把握具体要求，导致Agent的行为存在不可控的风险。例如，“实现订单的CRUD功能”，就不如“当前项目为Spring Boot架构的后端项目，实现基于数据库表orders的CRUD操作，不允许增加新的第三方包依赖，不允许修改controller、service包以外的代码”更加受控。3. 上下文信息流失：由于未能提供足够的上下文信息，或受限于模型对长上下文的处理能力，导致模型在复杂任务的执行上效率低下，甚至出现任务遗漏的情况。例如，“参考新浪微博，开发一个微博系统。”（这个例子相对宽泛，需要更多上下文说明）。结构化提示词之所以有效，根源在于它们能够将人类社会中的潜在共识、固有常识以及暗知识等未明确表达的上下文信息，清晰且系统地提供给大模型。它们充当了一个关键的接口，将人类的高层次目标，转化为Agent能够有效处理的精准低层次指令。通过明确提供意图、上下文、约束、参考文档等关键信息，结构化提示词能有效减少大模型的“猜测”，从而指导其更高效地完成任务，显著提高准确性和一致性。最终，这使得大模型的统计学特性能够紧密围绕人类目标，高效地趋向最终任务目标，从而实现更高效、更有效的交互体验。1. 上下文和背景信息：提供相关的领域知识、事实或数据，帮助模型理解请求范围，避免模糊或不相关的回应。例如，“扫描目录结构和文件，分析代码实现，生成描述报告”。2. 清晰具体的指令：明确说明任务，使用动作动词，避免模糊不清的表述。例如，“实现公众号文章查询功能”。3. 约束信息：明确指定任务的限制条件。例如，“仅修改AController文件，严禁修改其他文件，严禁引入新的代码包”；“仅以表格形式进行展现”。4. 引用外部文档或示例：提供具体的接口文档或输入/输出示例，这有助于模型更准确地响应，在处理复杂任务时尤其有效。例如，“参考DeepSeek接口文档实现”。5. 角色设定：在使用通用大模型时，必须明确指定AI所扮演的角色，以提高回答的准确性和相关性。但在使用AI辅助编码工具或特定Agent时，由于Agent自身已对提示词进行过预处理，此步骤通常可以省略。6. 回溯检查（Double Check）：提供明确的再次确认要求，指导Agent对已完成任务进行自我核验，以提高最终准确性。对于结构化提示词的编写，业界目前已发展出多种方法论。在此，我简单介绍两个：1. 对于确定性任务（例如：辅助编码、代码评审等），可重点考虑思维链（Chain-of-Thought, CoT）方法。CoT是一种提示技术，它鼓励模型通过逐步推理来分解问题，从而生成更连贯、更准确的响应。例子：使用deepseek-r1生成的CoT格式提示词，用来完成代码评审。请作为AI代码评审助手，对以下代码进行详细评审。使用思维链（Chain-of-Thought）方法，逐步执行以下步骤，并在每个步骤中展示您的推理过程。确保评审覆盖代码风格、潜在错误、安全性、性能和可维护性。最后，总结评审结果并提出具体改进建议。
**评审步骤（一步一步思考）：**1.**步骤1: 检查代码风格和格式** - 推理：分析代码是否符合常见编码规范（如命名约定、缩进、注释、模块化）。例如，检查变量名是否清晰、函数是否简短、注释是否充分。 - 输出：列出风格问题（如有），并引用相关规范（如PEP 8 for Python）。
2.**步骤2: 识别潜在错误和边界条件** - 推理：逐行扫描代码，查找逻辑错误、异常处理缺失、边界情况（如空输入、溢出）和资源泄漏（如未关闭文件）。考虑输入范围、循环条件和错误处理机制。 - 输出：指出潜在错误，并解释风险（如崩溃或数据损坏）。
3.**步骤3: 评估安全性** - 推理：检查常见安全漏洞（如注入攻击、XSS、敏感数据暴露）。分析输入验证、数据 sanitization、依赖库漏洞（如使用过时库）和权限控制。 - 输出：标记安全问题，并参考标准（如OWASP Top 10）。
4.**步骤4: 分析性能和优化** - 推理：评估算法效率（时间/空间复杂度）、资源使用（如内存、CPU）和可扩展性。识别瓶颈（如嵌套循环、重复计算）和优化机会（如缓存或异步处理）。 - 输出：提出性能改进建议，并估算潜在提升。
5.**步骤5: 审查可维护性和最佳实践** - 推理：检查代码可读性、测试覆盖（如单元测试缺失）、文档和设计模式使用。确保遵循语言或框架的最佳实践（如DRY原则）。 - 输出：指出可维护性问题，并建议重构或测试策略。
**最终输出要求：**-以JSON格式输出结果，包含以下字段： -`summary`: 总体评审摘要（如严重问题数量和优先级）。 -`step_details`: 每个步骤的推理、发现和建议（按步骤1-5组织）。 -`overall_recommendations`: 具体改进建议列表。-语言：中文（除非代码为其他语言）。-注意：推理过程必须详细、逐步展示，避免跳跃。
2. 对于推理类任务（例如：创意写作、探索性问题解决，包括文章编写、数学问题求解等），则可考虑思维树（Tree of Thought, ToT）方法。ToT的核心在于模拟人类解决复杂问题时的思考方式，通过分解问题、探索多种可能路径、评估与选择、必要时进行回溯、最终整合形成解决方案。例子：使用deepseek-r1生成的ToT格式提示词，用来生成穿越小说。
**任务：**构思一个新颖的穿越小说核心设定和精彩开篇（300-500字）。要求：非主流穿越方式、独特有限金手指、开篇展现核心困境/反差、风格轻松幽默带爽感。**请严格使用“思维树”方法分步骤创作：**1.**步骤一：生成核心设定分支（世界观&穿越方式&初始困境）*****分支A(穿越方式)：**基于“非主流”要求，生成**3种**离奇/荒诞/有创意的穿越触发方式（例如：被古董马桶吸入、在吐槽大会现场被观众怨念送走、误食了外星文明的“时空跳跳糖”、参加沉浸式剧本杀结果系统故障被永久绑定等）。**评估：**哪个方式最具趣味性和故事延展性？哪个能自然引出初始困境？***分支B(世界背景)：**根据选定的穿越方式，构思**2种**反差巨大的穿越目标世界（例如：从现代社畜穿成修仙界即将被献祭的炉鼎/穿成星际战甲里负责刷马桶的AI/穿成古代宫廷御膳房负责给皇帝试毒的太监/穿成魔法世界被诅咒只能变成仓鼠的王子）。**评估：**哪个世界与主角原身份反差最大？哪个能更自然地制造核心冲突？***分支C(初始困境)：**结合选定的穿越方式和世界背景，为主角设计**2种**开篇即面临的、紧迫且极具反差的困境（例如：刚睁眼就被绑上祭坛/发现自己是全星际唯一需要“充电”的战甲AI且电量只剩1%/皇帝马上就要用膳自己必须试毒/诅咒发作即将变仓鼠并被猫盯上）。**评估：**哪个困境最能瞬间抓住读者？哪个能最好地引出主角性格或金手指？2.**步骤二：设计主角与金手指分支（人设&能力&限制）*****分支D(主角原身份&性格)：**为穿越前的主角设计**2种**有特点、能与穿越后困境产生有趣互动的原身份和性格（例如：现代顶级杠精键盘侠/社恐程序员/美食探店主播/二手书摊老板）。**评估：**哪种身份/性格在穿越后面对困境时能产生最大的戏剧冲突或喜剧效果？***分支E(金手指概念)：**基于“独特且有限制”要求，构思**3种**有趣的非战斗/非直接无敌型金手指（例如：【精准吐槽能量收集系统】吐槽越精准越能获得能量，但能量只能用于具现化吐槽对象/【万物皆可吃鉴定术】能鉴定任何物品的“可食用性”和效果，但必须真吃下去/【社恐值转换器】社恐值越高，获得临时性隐匿/小范围空间跳跃能力越强，但社恐值爆表会强制原地石化/【错别字法则】写下的错别字会扭曲现实，但扭曲效果随机且不可控）。**评估：**哪个金手指最具新颖性？哪个与主角原身份/性格/困境结合能产生最多笑点和爽点？哪个的限制条件最有戏剧张力？***分支F(金手指限制与困境结合)：**将选定的金手指与**步骤一**选定的初始困境结合，设计**1-2种**主角在开篇如何**笨拙/意外/搞笑地**首次运用（或试图运用）金手指来尝试破局，但可能因为限制或操作不当引发新的小麻烦或产生意外效果。**评估：**这个首次运用是否能展现金手指的核心机制和限制？是否能制造紧张感和趣味性？3.**步骤三：整合与开篇写作（冲突聚焦&风格确立）*****整合设定：**将前面步骤选定的最优分支组合起来：*穿越方式：`[从步骤1A中选择]`*世界背景：`[从步骤1B中选择]`*初始困境：`[从步骤1C中选择]`*主角原身份/性格：`[从步骤2D中选择]`*金手指：`[从步骤2E中选择]`(核心机制：`[...]`，关键限制：`[...]`)*首次金手指运用尝试：`[从步骤2F中选择]`***核心冲突聚焦：**明确开篇需要展现的核心冲突是什么？（是生存危机？身份暴露风险？尊严挑战？还是与金手指限制本身的斗争？）***开篇写作要求：*****开头Hook：**用选定的“初始困境”场景**立即**抓住读者（如：祭坛火焰已燃起/电量警报狂响/毒羹就在眼前/猫爪已伸到头顶）。***主角亮相：**快速展现主角穿越后的懵逼、原身份/性格带来的反应（吐槽/社恐发作/职业病犯了）。***金手指亮相：**在主角尝试解决困境时，**自然且戏剧化**地引出金手指的首次运用（或尝试），突出其独特性和限制带来的窘迫或意外之喜。***风格基调：**贯穿轻松幽默的语言（主角内心吐槽/荒诞情境描写），在危机中制造反差笑点，同时让读者感受到主角利用金手指（哪怕笨拙地）争取一线生机的“爽感”。***结尾钩子：**开篇结尾处留下一个悬念或新的小转折（例如：金手指生效了但效果奇葩/困境暂时缓解但引来更大麻烦/发现了金手指的隐藏副作用/关键反派或重要配角首次登场）。***回溯检查：**检查整合后的设定是否满足所有初始要求？开篇是否涵盖了关键元素（穿越方式提及/困境/人设/金手指）？幽默感和爽点是否自然？4.**步骤四：输出最终成果*****核心设定简述：**(1-2句话概括穿越方式、世界、主角、金手指及核心限制)。***精彩开篇正文：**(按照步骤三的要求，撰写300-500字的开篇章节，包含Hook、主角亮相、困境展现、金手指首次运用尝试、风格体现和结尾钩子)。**请清晰展示你在步骤一、二、三中的关键分支生成内容、评估选择理由以及最终的整合设定。最后输出步骤四的核心设定简述和开篇正文。** 1. Gemini-Cli：根据公开资料显示，Gemini-Cli采用了README.md、docs/index.md、docs/cli/commands.md这三个格式化文件，系统地描述了其整体能力、扩展工具和接口信息。体现了结构化提示词在复杂工具设计中的重要应用。2. AMP：根据其官方最佳实践，AMP强烈推荐采用更小粒度、更明确的指令与Agent进行交互，并直接建议使用AGENT.md文件作为交互格式。AMP工具自动生成的AGENT.md文件包含了运行命令、项目结构、核心组件、代码风格等多个关键信息，为Agent提供了清晰的运行上下文。PleaseanalyzethiscodebaseandcreateanAGENT.mdfilecontaining:1.Build/lint/testcommands-especiallyforrunningasingletest2.Architectureandcodebasestructureinformation,includingimportantsubprojects,internalAPIs,databases,etc.3.Codestyleguidelines,includingimports,conventions,formatting,types,namingconventions,errorhandling,etc.Thefileyoucreatewillbegiventoagenticcodingtools(suchasyourself)thatoperateinthisrepository.Makeitabout20lineslong.IfthereareCursorrules(in.cursor/rules/or.cursorrules),Clauderules(CLAUDE.md),Windsurfrules(.windsurfrules),Clinerules(.clinerules),Gooserules(.goosehints),orCopilotrules(in.github/copilot-instructions.md),makesuretoincludethem.Also,firstcheckifthereisaAGENT.mdfile,andifso,updateitinsteadofoverwritingit. #AgentGuidelinesfortest-deepeval##Commands**TestCommands:**-Runalltests:`pytestsrc/tests/`-Runsingletest:`pytestsrc/tests/test_llm_deepeval.py::test_basic_story_generation`-Runwithverboseoutput:`pytest-vsrc/tests/`-Activatevirtualenvironment:`sourcevenv/bin/activate`(runbeforetests)##Architecture**ProjectStructure:**-`src/lib/llm_service.py`-CoreLLMserviceclasses(DeepSeekLLM,QwenLLM)-`src/tests/`-DeepEvaltestsuiteforhorrorstorygenerationevaluation-`.deepeval/`-DeepEvalconfigurationandcachefiles-`requirements.txt`-Pythondependencies(deepeval,openai,pytest,httpx,python-dotenv)**KeyComponents:**-DeepSeekLLM:CustomDeepEvalmodelusingDeepSeekAPIforevaluations-QwenLLM:AlibabaQwenmodelforhorrorstorygeneration-Environmentvariables EEPSEEK_API_KEY,ALIYUN_QWEN_API_KEY(in.env.local)##CodeStyle**Language:**PythonwithChinesecommentsanddocumentation**Imports:**FollowstandardPythonimportorder(stdlib,third-party,local)**ErrorHandling:**RaiseValueErrorformissingAPIkeys,printandre-raiseforAPIfailures**TypeHints:**Usetypingmodule(Optional,Dict,List,TypedDict)**Async:**SupportbothsyncandasyncmethodsinLLMclasses**Environment:**Usepython-dotenvfor.env.localfileloading 可参考我之前的文章Windsurf：基于AI Agent的开发范式实践（总结篇）#项目名称{根据需求文档，填写项目名称}##项目描述{根据需求文档，填写项目描述}##功能描述{根据需求文档，提炼功能点，并逐一列举}##依赖文档{该部分可填写依赖的文档，例如：外部API文档、接口请求和应答样例、数据库设计文档等}##任务描述1.扫描项目目录结构，确定所有代码和配置文件的位置。2.实现功能{该部分根据需求文档，提炼所有要实现的功能。并将这些功能编写为大模型容易理解的任务描述，并逐一列举如下：-1.要完成的任务点1-2.要完成的任务点2-3.要完成的任务点n}3.再次检查实现功能一节的全部任务，确保每项都已经按要求完成。4.根据实现功能一节的全部任务，编写自动化测试代码。5.执行自动化测试代码，并确保全部通过。6.生成报告，写入markdown格式的文件。##任务约束1.仅完成任务描述一节的任务，不要扩大修改范围。2.可以对代码目录结构进行重构，但请务必在生成报告中说明修改的原因。3.如有进一步的修改建议，请在生成报告中说明。结构化提示词的优势在于提供了完整的上下文、清晰的指令、明确的约束、外部参考示例等信息，并引入了回溯检查这一关键动作。其不仅仅是一种技巧，更是提升人与AI Agent交互效率的关键方法。当然，遵循奥卡姆剃刀定律，如果简单的提示词已能有效解决问题，那么确实没有必要引入更为复杂的结构化提示词。如果能够通过简单格式化的提示词解决问题，那么就没必要追求什么CoT、ToT方法。但如果你在实际应用中遇到了复杂任务处理困难、Agent行为难以控制、或输出结果质量不稳定等问题，那么结构化提示词将是一个值得尝试且行之有效的解决方案。 | 
