# agents模板：为AI编程助手打造的标准化行为指南框架 > wcgomes/agents提供了一套极简、环境无关的AGENTS.md模板，定义了AI编程助手的核心行为、wiki记忆系统、工作流规范、专家代理委派和上下文管理策略。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-23T15:15:16.000Z - 最近活动: 2026-04-23T15:27:15.225Z - 热度: 139.8 - 关键词: AI编程助手, AGENTS.md, Prompt工程, Wiki记忆, 代码规范, 多Agent, 上下文管理 - 页面链接: https://www.zingnex.cn/forum/thread/agents-ai - Canonical: https://www.zingnex.cn/forum/thread/agents-ai - Markdown 来源: ingested_event --- # agents模板：为AI编程助手打造的标准化行为指南框架\n\n## 项目定位与核心价值\n\n随着AI编程助手在软件开发中的普及，如何确保这些助手在不同项目、不同团队中表现一致、可预测，成为一个日益重要的问题。wcgomes/agents项目正是为解决这一问题而生——它提供了一套极简、环境无关的AGENTS.md / CLAUDE.md模板，定义了AI编码代理的核心行为准则。\n\n这套模板不是简单的建议清单，而是具有约束力的行为规范。模板明确指出："这些不是建议——在每个任务、每个会话中都要遵循。"这种强制性确保了AI助手的行为一致性，无论面对的是哪个项目、哪类任务。\n\n## 核心行为准则\n\n模板首先确立了AI助手的基本工作态度：\n\n### 明确假设与主动沟通\n\nAI助手必须在实施前明确陈述假设，遇到不清楚的地方要停下来询问，而不是默默猜测。当存在多种解释时，应该呈现所有可能性，而非擅自选择。如果发现更简单的方案，应该主动提出，必要时甚至可以"反驳"用户的复杂要求。这种透明和诚实的沟通方式，建立了人机协作的信任基础。\n\n### 信息密度原则\n\n模板对AI助手的输出风格提出了严格要求：每个词都必须承载信息，其余一律删除。具体包括：\n\n- 删除冠词（a/an/the）\n- 剔除填充词（just/really/basically/actually）\n- 省略客套话（sure/happy to/certainly）\n- 避免模糊表达（it might be worth/you could consider）\n\n推荐的句式结构是：【事物】【动作】【原因】。【下一步】。这种极简风格不仅提高了沟通效率，也迫使AI助手提炼核心信息。\n\n同时，模板也规定了例外情况：代码块、内联代码、命令、文件路径、URL、技术术语和版本号必须精确保留；安全警告、不可逆操作和复杂多步骤流程则需要完整书写，避免碎片化导致误读。\n\n## 目标导向的工作方式\n\n模板强调每个任务都必须有明确、可验证的目标。AI助手需要在开始前定义成功标准，如果标准不明确则主动询问。对于多步骤任务，应该先分享计划并获得确认后再执行。\n\n在呈现结果前，AI助手必须运行测试、检查代码规范并验证构建。如果发现问题，先修复再提交。对于代码修改，应该展示diff并等待明确批准后再应用，绝不允许直接修改最终目标文件。\n\n模板还设定了一个重要的止损机制：如果连续两个周期没有进展，AI助手应该停下来解释阻碍因素并寻求指导，而不是在原地打转。\n\n## 代码质量原则\n\n模板对代码编写提出了极简主义要求：\n\n- 编写最少的代码来解决问题\n- 不添加推测性功能、未使用的抽象或未经请求的灵活性\n- 如果结果可以缩小一半，就重写\n- 不改进相邻代码、格式或注释，除非这是任务的一部分\n- 遵循现有风格，即使你个人会采用不同的方式\n\n当发现不相关的问题时，应该提及但不修复。对于因修改而变得未使用的导入、变量或函数，应该予以删除，但不应触碰预先存在的死代码，除非被要求。\n\n## Wiki记忆系统\n\n模板最具创新性的设计是其wiki-based记忆机制。wiki/目录是AI助手唯一的持久化记忆，当不确定时先读取它，学到新知识后写回其中。\n\n### Wiki结构规范\n\n模板推荐以下目录结构：\n\n```\nwiki/\n├── index.md # 所有页面的索引——始终保持最新\n├── architecture.md # 系统结构说明\n├── conventions.md # 代码模式、命名、风格\n├── domain.md # 业务规则和领域逻辑\n├── decisions.md # 架构决策记录（ADR）\n├── auth/ # 超出单页的主题子目录\n│ ├── overview.md\n│ └── flows.md\n└── ... # 按需添加页面和子目录\n```\n\nindex.md是强制性的，必须始终保持更新。每个条目都应包含简要描述，让用户无需打开文件就能识别页面内容。新页面必须从index.md和相关页面链接。\n\n### 记忆操作流程\n\n模板定义了三类记忆操作：\n\n- **摄取（Ingest）**：在每个任务结束时，写下关于该项目的新发现。不要等到被要求才做，主动更新index.md并从相关页面链接。\n- **查询（Query）**：始终从读取wiki/index.md开始，使用描述识别相关页面——只加载那些。绝不凭记忆回答，如果wiki页面存在的话。\n- **整理（Lint）**：完成任务后，扫描页面之间的矛盾、未从index.md链接的孤立页面、以及不再成立的声明，修复发现的问题。\n\n摄取的触发条件包括：架构决策已做出、新模式或约定已识别、领域规则已澄清或修正、用户明确要求更新。而常规bug修复或微小变更如果没有持久洞见，则不需要更新wiki。\n\n## 专家代理委派机制\n\n模板确立了"默认委派"原则：在处理任何任务之前，先检查可用的代理。如果存在相关专家，就委派——即使你自己也能完成。只有在没有相关专家时才直接处理。\n\n委派策略包括：\n\n- **单一领域**：委派给相应的专家\n- **多个领域**：组建团队，定义需要完成的内容，分配给专家，综合他们的输出。你是默认的协调者\n- **多阶段执行**：可以将协调权交给专家协调器，给予明确的目标和交付物，在向用户呈现前审查最终结果\n\n这种机制让AI助手从"万能工具"转变为"智能协调器"，充分发挥不同专家代理的专长。\n\n## 上下文管理策略\n\n模板对上下文加载提出了效率原则：只加载与当前任务相关的wiki页面，而非整个wiki。在搜索源代码中的领域知识之前，先检查wiki/。当只需要单个引用时，优先使用grep/搜索而非加载完整文件。\n\n完成步骤后，释放上下文，只保留当前工作所需的内容。这种主动的上下文管理，确保AI助手不会因为加载过多无关信息而降低效率或产生混淆。\n\n## 规则与理由对照表\n\n模板以表格形式总结了关键规则及其背后的理由：\n\n| 规则 | 理由 |\n|------|------|\n| 创建文件前，搜索现有功能以扩展 | 防止蔓延和重复 |\n| 仅当扩展确实不可能时才创建新文件——说明原因 | 强制重用分析 |\n| 生产代码中不使用模拟或假数据（测试夹具除外） | 数据完整性 |\n| 修复根本原因，而非症状 | 代码质量 |\n| 在计划、diff或解释中引用代码时，始终标注file:line | 可追溯性 |\n\n这种透明的设计让使用者不仅知道要做什么，还理解为什么要这样做。\n\n## 对AI编程实践的启示\n\nwcgomes/agents模板代表了一种成熟的AI编程协作模式。它不是让AI助手"自由发挥"，而是通过明确的约束和规范，让AI的行为变得可预测、可审查、可维护。\n\n对于开发团队而言，采用这套模板意味着：\n\n1. **一致性**：不同AI会话之间的行为保持一致，减少"每次都不一样"的困扰\n2. **可追溯性**：通过wiki记忆系统，项目知识得以积累，而非随着会话结束而丢失\n3. **质量保障**：严格的代码质量原则和测试要求，确保AI生成的代码符合工程标准\n4. **效率提升**：极简的沟通风格和目标导向的工作方式，减少不必要的来回\n\n这套模板的价值不仅在于其具体内容，更在于它所体现的理念：AI编程助手应该像人类团队成员一样，遵循团队规范、积累项目知识、对产出质量负责。