用途
Polite-MCP 约定面向作者自己的购物/分类信息自动化仓库族（含 olx-polite-mcp、emag-polite-mcp、altex-polite-mcp、freshful-polite-mcp、temu-polite-mcp），描述智能体在这些仓库中协作时应遵循的行为规则。它区别于 mcp-server-shipping（同一批仓库的开发循环与分发机制），也区别于机器上始终加载的通用指令文件；这里规定的都是领域专属约定——针对用户本人实时、已登录的个人账号做自动化。安装在其他环境时约定仍可阅读，但仓库名属于作者本人。
主要能力与约定
1. 首次实时变更操作前必须确认
在一次会话中，针对用户实时、个人、已登录账号执行第一个真实会改变状态的浏览器操作之前（例如真实的加入购物车点击，而不是只读操作），应停下来通过 AskUserQuestion 询问，而不是直接执行——即便该操作范围很窄、成本很低、可回滚。提问时应把它表述为一次性的、有范围的测试（说明将运行什么，以及适用时说明之后会撤销/还原），而不是笼统的授权请求。一旦获批并确认了行为形态，同一会话内后续同类操作无需再次确认。
理由：该仓库族本就把结账/个人账号类操作视为比普通读取风险高得多的类别（各仓库自己的边界文档都有说明，例如「结账永不自动化」、不破解验证码）。对真实账号的首次实时变更测试属于同一类别，即使具体动作本身很小。freshful-polite-mcp 在 2026-08-14 实测确认：在首次加入购物车测试前先询问，得到了干脆、低摩擦的「可以，在一件便宜商品上测试」的回复，是正确的默认做法，而非过度谨慎。
2. 逐项交互式决策应分批，不要让用户打一长串答案
当工作流需要用户做若干小而独立的决定时（例如「这 8 件商品各要几件？」），应使用 AskUserQuestion 分批提问，每批约 4 个，并在第一个选项预填推荐默认值；不要抛出一个大列表，让用户在一次回复里把所有答案都敲出来。
理由：Freshful 重购流程中的明确反馈——「给这些东西都提个数量建议，一件一件问我，必须是交互式的，如果让我把那些都打出来，用户体验就毁了。」让用户输入一长段结构化回复，体验比短的引导式问答差，尽管两者传达的信息相同。
应用方式：只有当一个决定无法这样拆分、或项目太多以致分批不再轻量时，才保留一次自由文本提问；到那个程度应考虑流程本身是否要重构（例如把「大概该补的」与「很少动的」分开，而不是把所有条目平铺分批）。
当页面是许多同质项目、且每项都有合理默认值时——商品清单上的数量就是这种情况——并且超出两次 AskUserQuestion 调用能覆盖的范围，那么一张由用户按索引编辑的预填表格是更轻的形态，而且它仍是同一条规则而非例外：反对的从来都是把每个答案都打出来，而这里的常见回复只需一个词元。用户在同一流程中主动提出（2026-09-26）：「显示一张 10 件商品、带建议数量的表格，让用户说哪些不要，其实更快……应该以索引为基础，这样打字更少。」当天在八个页面实测运行，每条回复都是 2 到 11 个字符的索引表达式，没有一条需要澄清。适用条件：
- 常见情形只需一个词元（ok），例外是索引（-3,7、5x2、only 1,2,9）；
- 行号跨页面连续编号（1–10 之后是 11–20）——因为上一张表仍在屏幕上，按页面的 -5 会在两张表之间产生歧义；
- 在任何不可逆操作之前，用一行回显解析结果——这是打错的索引与真实购物车中错误商品之间唯一的屏障；
- AskUserQuestion 仍负责页面级的下一步/完成步骤、上面的首次实时变更确认，以及任何歧义大到只能靠猜的回复。
不适用于一组真正不同的二选一决策：没有共同默认值时，表格比批量提问更差的交互面。已实践的例子：freshful-polite-mcp 的 reorder-suggest 技能。
3. 先写 PLAN.md，再（或同时）实现
当研究/探测阶段（实时 CDP 探索、API 探测、DOM 检查）得出了改变或确认计划的结果时，应先把这些结果写入仓库的 PLAN.md——作为独立章节，并匹配该文档现有的叙述风格——然后或同时再写实际实现代码。不要把发现只留在对话里就直接写代码。
理由：明确指示，freshful-polite-mcp（2026-08-14）：「把所有东西留在计划里，然后再实现，这样很好。」这符合该仓库族既有的模式：PLAN.md（单个单体文件——该族早于 plan-conveyor 技能所记录的 plans/YYYY-MM-DD-topic.md 约定，尚未迁移过去）是架构为何如此的持久记录；代码注释回指它，而不是重新解释。
应用方式：在这类仓库中做完任何实时探测/研究之后，先更新 PLAN.md 的相关章节——标记已解决的开放问题、添加带日期的发现章节、重述/扩展发现涉及的边界决策——然后再进入实现。即使那一次用户没有明确要求写下来，也这样做；把它当作默认的先后顺序。
使用方式
该技能以约定文本形式提供，安装后在相关仓库的智能体会话中生效。核心动作包括：
- 首次真实变更（如加购）前用 AskUserQuestion 发起一次性范围测试确认；
- 多个独立小决策用 AskUserQuestion 分批（约 4 个/批）并预填推荐默认值；
- 大量同质项且有默认值时改用带索引的预填表格，行号跨页连续，不可逆操作前回显解析结果；
- 研究/探测结果先写入 PLAN.md 再实现。
适用场景
适用于作者本人的 *-polite-mcp 个人自动化仓库族（olx-polite-mcp、emag-polite-mcp、altex-polite-mcp、freshful-polite-mcp、temu-polite-mcp）中，针对用户本人实时登录账号的自动化流程，尤其是重购、批量选购数量确认、以及需要与用户进行多次小决策交互的任务。已实践案例包括 freshful-polite-mcp 的 reorder-suggest 技能。
限制
这些约定针对作者本人的机器与账号；安装在其他环境虽仍可阅读，但仓库名属于作者本人。该族将结账/个人账号类操作视为高风险类别（如「结账永不自动化」、不破解验证码），首次实时变更测试也按同类处理。「结账永不自动化」等边界仅见其仓库自身文档，本技能未展开具体边界清单。关于收费、价格、支持平台等信息，资料暂未提供。