当一个团队合作足够久之后，某些实践会变得“隐形”。拒绝一个 PR 的资深工程师，并不会去查阅清单；她几乎在瞬间就能判断出：错误处理不完整、抽象做得太早、命名没有遵循团队约定。同样的直觉也会影响她如何提示 AI 生成代码、如何提出重构请求，以及在认为一项工作完成之前，她会要求 AI 检查什么。你若让她解释，她当然可以解释；但在实际发生的那一刻，这其实是基于多年代码评审、生产事故和架构讨论所形成的模式识别。这类隐性知识（该生成什么、该检查什么、该标记什么、该拒绝什么）是团队最有价值、也最脆弱的资产。它存在于人的头脑中，通过结对协作和代码评审缓慢传递，并且会在人员离开时一并流失。
在此前的工作中，我曾描述过一些可以提升单个开发者与 AI 协作效果的技术：共享经过整理的项目上下文、结构化设计讨论、将决策外化为持续更新的文档。它们都能帮助某一个人获得更好的结果。但它们都没有解决另一个不同的问题：同一团队里的两个开发者，使用同样的工具、同样的代码库、同样的项目上下文，却产出实质上不同的结果。差距不在于 AI 对项目了解多少，而在于 AI 被告知要如何运用这些知识。指令因人而异，而且这种差异体现在各种交互中，而不仅仅是代码评审。
那些决定 AI 如何生成代码、如何重构既有系统、如何检查安全漏洞、或如何审查拉取请求的标准，不应该只是 Slack 里流传的小技巧，或仅存于资深工程师脑中的经验之谈。它们应该成为可版本化的工件，以一种能被所有人一致执行的形式，把“我们在这里是怎么做事的”编码进去。
一致性问题
当 AI 辅助开发的效果取决于是谁在写提示词时，资深工程师就会成为瓶颈——不是因为代码是他们写的，而是因为只有他们知道该要求什么。
我反复观察到这种模式。资深工程师在要求 AI 生成一个新服务时，会凭直觉补充说明：遵循我们的函数式风格，使用现有的错误处理中间件，把代码放在 lib/services/ 下，类型必须显式声明，使用我们的日志工具而不是 console.log。让 AI 做重构时，她会说明：保持公开契约不变，避免过早抽象，函数要小且职责单一。让 AI 做安全检查时，她知道要明确要求：检查 SQL 注入，验证每个端点上的授权，确保密钥没有被硬编码。
而经验较少的开发者，面对同样的任务，往往只会让 AI “创建一个通知服务” 或 “整理一下这段代码” 或 “检查一下这是否安全”。同样的代码库，同样的 AI，但在每一次交互中——不只是评审——质量门槛却完全不同。
这并不是初级开发者的错；他们只是还没有形成那种直觉。但这种不一致代价高昂。一个开发者写提示词时，AI 生成的代码会偏离团队约定；换另一个开发者时，又能对齐。重构质量会因提出请求的人不同而波动。安全检查能发现什么问题，也取决于是谁来描述问题。技术债会以不均匀的方式不断累积。
人们的第一反应往往是把它当作技能问题来处理：培训初级工程师、写更好的文档、增加结对编程。这些方法当然有帮助，但它们都很慢，也无法扩展。团队中的知识其实已经存在；它只是缺少一种可以被一致传播的载体。真正需要的是一种方法：把资深工程师凭直觉应用的东西，变成每个人都能使用的能力——不是作为需要记住的建议，而是作为能被执行的指令。
这是一个系统问题，而不是技能问题。既然如此，也就需要系统性的解决方案。
本系列前面的技术，解决的是 AI 知道什么的问题。Knowledge Priming 让 AI 了解项目约定。Design-First collaboration 帮助团队在架构上达成一致。Context Anchoring 则让这种一致性在跨会话场景中得以持续。而本文讨论的是另一件事：无论是谁在写提示词，都让 AI 一致地应用团队的判断，并且贯穿所有重要交互。
可执行治理
团队一直都在尝试把标准编码下来。难点始终在于文档与实践之间的落差。放在 wiki 上的一张清单，前提是有人去读、记得住，并且能在时间压力下持续执行。以我的经验，大多数“标准固化”工作，往往都是悄无声息地失败在这道鸿沟里。
AI 指令以一种有趣的方式改变了这种局面。以 AI 指令编码的团队标准，不再依赖某个人是否记得去执行。指令本身就是执行。当开发者通过一条嵌入了团队架构模式的指令来生成代码，或者运行一条编码了团队威胁模型的安全检查指令时，这些标准会作为工作流的副作用自动生效，而不再是一个需要靠自觉额外完成的步骤。治理本身，就是工作流。
我觉得，把这件事理解为两个动作会很有帮助：
从隐性到显性。 第一步大家并不陌生：把资深工程师凭直觉掌握的东西写下来。不同之处在于，目标形式不再是 wiki 页面或检查清单，而是一套 AI 可执行的结构化指令。写下来的过程会暴露出许多此前从未被清晰表达的假设。究竟什么才算“严重”的安全问题，什么只是“重要”问题？这些对资深工程师而言往往是直觉性的区分，对 AI 来说却必须被精确定义。
从文档到执行。 第二步才是真正关键的。Lint 规则是版本化配置文件，而不是个人偏好。CI/CD 流水线是可执行定义，而不是描述部署步骤的 wiki 页面。AI 指令也应属于同一类：它们是会执行的配置，而不是提供信息的文档。当这些指令存在于代码仓库中，通过拉取请求进行评审，并且默认共享给每个人使用时，它们就具备了与其他团队基础设施同等的地位。开发者不必在脑中记住团队全部标准；他们只需要调用一条指令。团队的判断就会被一致地应用——不是因为开发者背下来了，而是因为基础设施已经把它编码进去了。
这看起来是什么样子
一个结构良好的可执行指令，有着清晰可辨的“解剖结构”：四个部分，各司其职。无论这条指令用于什么目的，这种结构都适用。
-
角色定义。不是因为 AI 需要一个人格设定，而是因为角色决定了它应具备的专业水平和观察视角。“角色：按照团队架构模式实现新服务的资深工程师”与一个泛泛的提示词相比，会建立完全不同的基线。这个角色，就是后续所有指令被应用时所依赖的透镜。
-
上下文要求。也就是指令运行前所需的前提条件：相关代码、项目架构上下文的访问权限、适用的约束条件等。这样做是把依赖显式化，而不是寄希望于开发者自己记得提供。
-
分类标准。类别的重要性往往高于具体条目本身。对于生成类指令，类别可能包括：架构合规（必须遵守）、约定遵循（应当遵守）、风格偏好（有则更好）。对于安全类指令，则可能包括：严重漏洞（阻断项）、重要问题（必须在合并前解决）、建议项（跟踪并评估）。对于评审类指令，可能包括：阻断性问题、重要发现和建议。这种优先级结构编码的是团队的判断，而不只是团队的知识。它告诉 AI，也通过 AI 告诉开发者，什么才是最重要的。
-
输出格式。应采用结构化回应，包括摘要、分类后的发现以及明确的下一步动作。这样的格式可以确保同一条指令在不同运行之间、由不同开发者使用时，输出仍然具有可比性；而一旦多人开始频繁使用同一套指令，这种特性就非常重要。对于生成类指令，这种结构体现为产出代码本身的完整性和组织方式——不是“问题报告”的格式，而是输出结果所遵循的约定。
这一原则适用于 AI 交互的完整范围。例如：
-
生成（Generation）：编码团队如何构建新代码（架构模式、命名、错误处理、测试要求），使输出从第一版起就与团队保持一致。
-
重构（Refactoring）：编码团队如何改进既有代码（保持契约不变、避免过早抽象、优先渐进式变更）。
-
安全（Security）：编码团队的威胁模型（检查什么、如何评定严重程度），使安全检查更贴合团队实际，而不是泛泛而谈。
-
评审（Review）：编码团队在评审中关注的内容（架构一致性、错误处理、类型安全、代码约定），并采用一致的严重性分级结构。
保持指令小而专一。更小的指令更容易聚焦，也更容易维护，并且能够更灵活地组合。
让隐性知识浮现出来
创建这些指令最有意思的部分，在于知识提取的过程。它本质上是一场针对团队资深工程师的访谈，通过一组尖锐的问题覆盖完整开发流程：哪些架构决策绝不能留给个人自由裁量？生成代码里最常被纠正的是哪些约定问题？哪些安全检查是靠直觉自然执行的？什么情况会在评审中被立刻否决？一次干净的重构与一次过度设计的重构，分界线在哪里？
这些回答会直接映射到指令结构上。不可妥协的架构模式，会成为生成约束。高频纠正项，会变成约定检查。安全直觉，会成为威胁模型条目。评审中的否决理由，会成为关键检查项。反复出现的错误，会变成需要标记的反模式。某种意义上说，这些访谈本身就在“写”指令；创建的过程，就是把隐性知识组织成显式、分级的检查项。
我发现，这个过程的价值甚至超出了最终生成的那些指令本身。在一个项目中，知识提取的讨论暴露出：两位资深工程师对于什么算“严重”安全问题、什么只是“重要”问题，其实有着不一样的阈值。这个分歧此前从未暴露，因为他们各自评审的是不同的拉取请求。共同编写一条共享指令的过程，迫使这种区分必须被明确下来。而当团队里一位经验较少的开发者开始使用最终产出的指令后，效果立竿见影：他第一次做评审，就指出了一个新加端点缺失授权检查的问题——这类问题过去通常只有碰巧由资深工程师来评审时才会被发现。这些指令并没有让这位开发者“变得更有经验”；它们只是让他缺乏经验这件事，不再那么昂贵。
标准如何融入工作流
这些指令不是单一用途的工具。它们可以应用在开发工作流的不同节点，而应用的节点会决定它们的价值体现方式。
在生成阶段，当开发者要求 AI 创建新服务、实现某个功能或编写测试时，生成类指令能够确保输出从一开始就符合团队约定。这里是编码化标准最能发挥杠杆作用的地方：它在偏差发生之前就加以预防，而不是事后再去发现。
在开发过程中，重构类指令能让改进始终与团队规范保持一致，而安全类指令则会应用团队自己的威胁模型，而不是泛用清单。标准贯穿整个开发过程，而不是在最后被“外挂”上去。
在评审阶段，当开发者完成一项工作（无论是 AI 生成还是手工编写）时，评审类指令会施加团队的质量门槛。但评审阶段其实是发现偏差的最后机会——标准越早在工作流中被应用，最终流到评审环节的问题就越少。
可选地，一些团队还会把这些指令扩展到 CI 流程中，作为自动化一致性检查。CI 级别的指令必须足够快，不能拖慢流水线；必须足够可预测，避免产生嘈杂的误报；并且需要像其他 CI 门禁一样，以同等严格的纪律来维护。
校准
当团队规模大到仅靠口头沟通已无法维持一致性时，这种方法的价值最大。一个实用的判断标准是：如果 AI 辅助产出的质量会随着写提示词的人不同而明显波动，或者如果生成和评审工作总是流向少数几个人，因为只有他们知道如何有效地写提示词，那么这种不一致本身就是一个信号。五人团队也许还不需要这样做；十五人团队几乎肯定需要。
成本是真实存在的。创建高质量指令需要投入——要做知识提取访谈、起草、迭代。过于规定细节的指令会变得脆弱；它们会在边缘场景下产生误报，或者与本来合理的实现差异发生冲突。随着标准演进，还会带来维护负担。此外，也存在过度工程化的风险：并不是每一种 AI 交互都值得单独为其设计一条专用指令。
以我的经验，正确的起点是一条指令。生成类或评审类指令通常最具价值；它们覆盖最常见的工作流、最大的质量落差，以及最明显的一致性问题。其他指令应当在采用之后再逐步增加，而不是在采用之前就一股脑铺开。
结论
从根本上说，这是一种转变：把原本存在于个人头脑中的判断，转化为作为共享基础设施被执行的判断。资深工程师的直觉——她会检查哪些模式、执行哪些约定、标记哪些风险——不必继续停留在个人层面，也不必继续不可扩展。它们可以被提取出来，编码为可版本化的指令，并在每一位开发者、每一次与 AI 的交互中被一致地应用。
这种机制本身并不新鲜。团队早已通过 Lint 规则、CI 流水线和基础设施即代码来做类似的事。AI 带来变化的，是可编码内容的范围。Lint 能捕获语法和风格问题；可执行的团队标准则可以编码架构判断、安全意识、重构理念和评审严谨性——这些知识过去通常只能通过结对协作、导师带教和多年共同工作经验来传递。
这些标准最有意思的特性，在于它们归团队所有。它们存在于代码仓库中，通过拉取请求演进，并会在实践暴露出缺口时持续改进。每一条遗漏了某些内容的指令，都是一条等待更新的指令；而那次更新，就是一个由整个团队共同评审的提交。标准不仅仅是团队知识的产物；它们还是团队知识被编码、共享和精炼的机制。
