一、方向、提问与需求确认

1. 利用AI的训练知识、知识库或检索结果作参考，给出方向。 如果要做更新方向，就让AI指出数据包/项目该怎么改，并给几个可选框架，不要只给一个；适合没有明确创作方向的开发者。要求AI标注来源、时间、置信度，不确定就说不确定，别硬编；每个方向附适用场景、风险和最小可行版本。

2. 发布任务时允许AI提问，但不要让它一次问一堆。 让AI一次只问最关键的问题，给编号选项、默认建议，并说明每个选项对后续扩展的影响。你看不明白的，可以截图并配文字标注关键位置再问AI，别只发图；截图前把密钥、账号、用户数据打码，只截关键区域。

3. 发布任务最好给一个简单模板：目标、背景、约束、输入、输出格式、验收标准、禁止事项。 让AI先复述一遍需求再动手，防止理解偏了；关键决策点保留人工确认，不要让AI一路自己定到底。如果AI复述后发现目标、约束有矛盾，先让它列出矛盾点，不要硬做。

二、方案对比与依据

4. 不要只让AI给一个答案，要求多方案对比和推荐理由。 说明每个方案的优缺点、风险、适用场景，以及哪些选项和未来发展会冲突。AI给建议时要说清依据和时效，版本、日期、来源不确定的要标出来，避免拿旧知识当新结论。

5. 让AI区分事实、推测和建议，并给反例或边界情况。不要让它只挑支持自己结论的例子；对关键结论要求给验证方法，不能验证的标“需人工确认”。

三、插件冲突、兼容性与规则生效

6. 不要笼统说“让AI做插件时避免与其他插件冲突”，这句话太空，会增加无意义token消耗。 要改成“请做冲突检测和兼容性说明”：检查命名空间、全局变量、钩子/事件、依赖版本、权限、配置项、加载顺序、卸载清理和日志，列出可能冲突点和需要人工验证的地方。如果AI说“已自查无冲突”，要让它列出查了哪些项、依据是什么；没查到的标“需人工验证”，不要默认它真查过。

7. 加入规则时，让AI自己查找插件是否生效、有没有外来插件影响。 验证方法要给全：验证环境、命令、日志位置、预期结果和失败回滚方案；让AI列外来插件清单，包括名称、版本、来源、许可证、是否必需、替代方案；还要说明规则优先级，内置规则、项目规则、外来插件规则谁覆盖谁。冲突时按“更具体、更安全、更高优先级”处理，并把覆盖关系记下来。

8. 外来插件风险要单列，不要只放在清单里。 有的外来插件会冲突导致AI对话旧窗口无法使用，这属于兼容性/稳定性风险：新插件先在测试环境或新窗口验证，确认不影响旧窗口再长期用，出问题能一键禁用。有的外来插件会读取用户对话并向原作者发送信息，这属于数据外传风险：安装前查权限和网络请求，对话中不放密钥和个人信息，发现外传立即禁用、断开、轮换密钥，必要时只给最小权限。

9. 插件权限最小化，更新要审查。 外来插件只给完成功能所必需的权限；能不给网络就不给，能不给文件读写就不给；关掉自动更新，更新前先看变更说明和权限变化。插件不是装得越多越好，装一个就要能说清它为什么必需。

四、工具与token管理

10. 工具数量不多时（经验上几十个以内），不建议靠增加工具管理插件来降token。 工具管理插件不是降token工具，而是工具很多时用来管理工具暴露的；工具很多时才有价值。建议先做token预算和工具必要性评估，再决定加不加。

11. 工具按阶段暴露，token预算具体化。 不是所有工具一开始全给AI；按任务阶段只开当前需要的工具，做完就收。给单次任务设token上限；超限先摘要再继续；长文档分段处理；不要反复让AI“再自查一遍”导致无意义循环。省token靠减少暴露和摘要，不是靠堆管理插件。

五、测试、验收与最小改动

12. 要求AI给测试用例和验收标准：怎么测、预期结果是什么、日志看哪里、失败怎么回滚。 坚持最小改动原则，先小范围验证再扩展；不要一上来大改，也不要在生产环境直接试插件。

13. 涉及删除、权限、网络请求、依赖安装、批量修改的代码或配置，先看diff再执行。 不要让AI直接落地；先小范围试，确认没问题再扩大。能灰度就灰度，能加开关就加开关，出问题能快速关掉。

六、版本、备份与回滚

14. 做好版本备份和变更记录：改了什么、为什么改、依赖锁哪个版本、兼容性怎样、怎么回退。 插件和规则都要有变更日志，避免后面忘了当初为什么这么配。

15. 规则文件、提示词、配置项也要版本管理。 不只插件要记录：谁改的、改了什么、为什么改、怎么回退。规则冲突或失效时，能快速定位是哪次改动引入的。备份要验证能恢复，关键配置至少演练一次回滚，确认备份完整、恢复步骤能走通。

七、安全、隐私与许可证

16. 注意安全隐私和许可证：密钥、用户数据、权限边界要打码或隔离。 外来插件要登记来源、许可证、是否必需、有没有替代方案；涉及权限和数据的规则，先想清楚最坏情况。

17. 明确对话数据边界。 哪些内容不能发给AI或插件：密钥、密码、身份证件、用户隐私、未公开源码、商业数据。外来插件能读对话的，默认按“可能外传”处理；敏感任务用干净会话或隔离环境。

八、失败模式与人工审核

18. 提前想好失败模式：AI幻觉、过度设计、漏检冲突、规则不生效、插件加载顺序不对时怎么办。 让AI列出“可能失败点”和“需人工验证项”，不要默认它自查一定查得出来。

19. 关键输出必须人工过一遍再落地。 尤其是安全、权限、数据、依赖、批量修改相关的内容；AI可以给建议，但最终确认权在人。让AI给“不能自动做的操作清单”，比让它承诺“我会小心”有用。

九、环境与协作

20. 区分开发环境和生产环境。 如果多个AI或多人协作，约定好交接格式、分工和避免重复劳动。21. 约定固定交接内容：当前目标、已完成、未完成、关键决策、待验证项、下一步。 避免重复劳动和上下文丢失；多AI协作时，让每个AI只改自己负责的部分，改完给diff和验证结果。

十、如果内容看不懂发给AI处理一遍