经过一段时间的研究和实践，我发现 Copilot 这类 AI 工具实际上可以被深度”引导”，甚至达到一种”洗脑”的效果，让它们按照我们的意愿来行动。
它们并不是魔术盒子，而是遵循一套输入-输出原则的系统。如果我们能给它提供明确的指导和原则，它就能相应地调整自己的输出。
这个思路促使我整理了一个专门用来给 GitHub Copilot”洗脑”的指令集：prompts。
这个仓库里不是代码，而是一系列指导 AI 行为的 Markdown 文件。每个文件就像是给 AI 的一份规范或指南，告诉它应该怎样思考和行动。
这套指令能解决什么问题？
使用 AI 编程助手时，我们通常会遇到这些问题：
生成的代码能运行，但结构混乱，难以维护
没有考虑边界情况和异常处理
代码风格不一致，命名随意
缺乏适当的测试覆盖
不遵循项目已有的架构模式
这套指令集就是为了解决这些问题而设计的。它告诉 AI 该如何思考软件设计、如何编写清晰的代码、如何进行测试驱动开发，以及如何分解复杂问题。
指令集的构成
整个指令集分为几个主要部分：
核心行为定义：这部分告诉 AI 应该如何进行思考和工作，包括：
如何保持项目知识的连贯性（memory-bank）
如何有条理地回应用户（response-and-prompt-guidelines）
如何遵循 TDD 工作流（programming-workflow）
如何分解复杂任务（workflow-and-task-splitting）
代码质量规范：这部分告诉 AI 什么是好代码，什么是坏代码：
代码标准和最佳实践（code-standards）
代码异味和应避免的反模式（avoid-bad-smells）
如何编写有效的测试（testing-guidelines）
流程模板：这部分提供了从需求到实现的结构化方法：
如何将模糊的想法转化为明确的计划（req）
如何协助业务分析师编写用户故事（ba）
工具使用指南：这部分包含了一些高级技巧：
如何使用顺序思考解决问题（sequential-thinking）
快捷指令系统（shortcut-system-instruction）
这些指令是怎么起作用的？
你可能会好奇，为什么一些 Markdown 文件就能让 AI 变得这么听话？
我在研究这些指令的时候发现，它们其实就是几个简单的套路。比如，我给 AI 安排了不同的”角色”——有时候它是个健忘的工程师（所以必须写文档），有时候它是业务分析师的助手。这样一来，AI 就会按照角色来思考问题。
还有一个很有效的技巧是强制它”慢思考”。很多指令都要求 AI 必须一步一步地展示思考过程，不能直接给答案。这就像我们做数学题时要求”列出解题步骤”一样。
最有意思的是”自我批判”这一招。我发现如果让 AI 在给出解决方案后，再强制它自己找毛病，代码质量会提升很多。就像程序员写完代码后再做一遍 code review。
另外，我还设计了一些结构化的模板。比如写测试用例必须按照固定格式，写需求必须一个章节一个章节地来。这样 AI 就没法偷懒，必须把每个环节都考虑到。
说白了，这套指令的核心就是不让 AI “想当然”。它必须按照预设的流程来工作，该问的问题不能跳过，该考虑的边界情况不能遗漏。
如何在实际工作中使用这套指令
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
